IDE Agents & Cursor Workflows

The agent loop

An IDE agent is a loop, not a chatbot:

User goal → Plan → Select context → Generate/edit → Run tools (terminal, linter, browser) → Observe results → Iterate → Present diff

Understanding this loop lets you steer instead of hope. You're the tech lead; the agent is a fast intern with terminal access.

Cursor modes (mid-2026)

Mode	Best for	You do	Agent does
Ask	Understanding code, exploring options	Read answers, decide	Search, explain, suggest
Agent	Implementation, multi-file changes	Review diffs, approve commands	Edit files, run terminal, iterate
Plan	Architecture, ambiguous features	Approve/reject plan steps	Break down task, propose approach
Debug	Investigating failures	Provide repro steps	Trace errors, propose fixes

Rule: use Ask to understand, Plan to design, Agent to implement. Skipping Plan on complex features produces confident wrong code faster.

When to delegate vs pair

Delegate to agent	Pair (you drive)
Boilerplate, CRUD, test scaffolding	Architecture decisions
Renames across files with clear scope	Security-sensitive code
Bug fixes with clear repro + failing test	Performance-critical paths
Documentation, comments, README updates	API design with external consumers
Repetitive refactors (pattern is established)	First implementation of a new pattern

The agent is best when the spec is clear and the pattern exists. You're best when the problem is ambiguous or the stakes are high.

Multi-file editing patterns

Agents struggle with cross-cutting changes unless you help:

1. Scope explicitly — list files in your spec; use @-mentions
2. Sequence the work — "First update the interface, then implement, then update callers"
3. Checkpoint — review after each logical step, not after 15 files change
4. Run tests between steps — agent can fix forward if tests catch regressions early

Bad: "Migrate all endpoints to the new auth middleware" Good: "Migrate GET /users first. Update handler, add test, run test suite. Stop if tests fail. Then we'll do POST /users."

Terminal and tool access

Agents with terminal access can run tests, linters, and builds — this is the verify loop from LLM Foundations in action. But:

• Approve destructive commands — never auto-run rm -rf, force pushes, or prod deploys
• Sandbox awareness — agent may not see your full environment (env vars, VPN, credentials)
• Long-running commands — set timeouts; agents can hang on npm install or integration tests

Workflow patterns that scale

1. Spec → Agent → Review → Test → Merge The default loop. Write the spec first (Context Engineering).

2. Red-Green with agent Write failing test yourself → agent implements → you verify green → agent refactors.

3. Agent draft, human rewrite Agent produces 80% solution → you rewrite the critical 20%. Faster than from scratch, safer than blind merge.

4. Parallel agents (careful) Two agents on independent files/tasks. Never two agents on the same file simultaneously.

5. Agent for research, you for decision Agent reads docs/codebase → summarizes options → you pick → agent implements.

.cursorignore and indexing

Exclude from indexing: node_modules/, build artifacts, secrets, large binary assets, generated code. Polluted indexes produce irrelevant context and slow retrieval.

Include: source, tests, configs, ADRs, rules, skills.

Interview framing

"I use agent mode for scoped implementation with explicit file lists and test verification. I use plan mode before multi-file features. I never auto-approve destructive terminal commands. The agent is a fast executor; I retain architecture and review authority."

Senior signal: Describe a real workflow with mode transitions: "I started in Ask to understand the auth flow, switched to Plan for the migration approach, then Agent for the first endpoint with tests."