DEV Community

Paulo Victor Leite Lima Gomes
Paulo Victor Leite Lima Gomes

Posted on

the senior engineer's agent loop: context, plan, patch, proof

#agents #ai #productivity #softwareengineering

This is part 1 of a 5-post series on professional agentic coding for senior engineers.

The series:

  1. the senior engineer's agent loop: context, plan, patch, proof
  2. instructions as code: AGENTS.md, CLAUDE.md, and copilot-instructions.md
  3. subagents and specialized agents: parallelism without chaos
  4. review and verification: making agent code mergeable
  5. choosing the right agent surface: Codex, Claude Code, Copilot, and when not to use an agent

The biggest mistake senior engineers make with coding agents is treating the prompt as the unit of work.

It is not.

The unit of work is the loop.

Context -> plan -> bounded execution -> verification -> review.

If that loop is strong, the model can be useful even when it is imperfect. If that loop is weak, even the best model becomes a confident diff generator.

start with the real outcome

Bad task:

Fix auth.
Enter fullscreen mode Exit fullscreen mode

Better task:

Goal: expired sessions should redirect to login instead of returning 500.
Context: start in src/auth, src/session, and tests/auth.
Constraints: no public API changes and no new dependencies.
Done when: add a failing regression test, implement the fix, run npm test -- auth, and show the final output.
Enter fullscreen mode Exit fullscreen mode

That second version is not "prompt engineering." It is normal engineering.

It says what is wrong, where to look, what not to change, and how we know the work is done.

Claude Code's best-practices docs make this very explicit: give the agent a verification signal. Tests, builds, screenshots, logs, fixture diffs, anything machine-checkable. Do not ask for "better." Ask for evidence.

Codex behaves the same way. A strong Codex task brief should include the goal, context, constraints, and done criteria. The more the agent has to infer, the more you are buying lottery tickets with your repository.

use planning when the scope is uncertain

Planning is not always needed.

If the change is tiny, let the agent edit.

But when the task is broad, unfamiliar, cross-cutting, or risky, split exploration from implementation.

Claude Code example:

claude --permission-mode plan

Read src/auth, src/session, and the existing auth tests.
I want Google OAuth login added without changing the current password login path.
First explain the current session flow, then propose the minimal implementation plan.
Do not edit files yet.
Enter fullscreen mode Exit fullscreen mode

Codex example:

Use plan mode.
Read the payment retry flow and the tests around failed card charges.
Explain the current behavior, list the files that likely need changes, and identify risky edge cases.
Stop before editing.
Enter fullscreen mode Exit fullscreen mode

GitHub Copilot coding agent example:

## Goal

Add retries for transient card network failures.

## Scope

- Only payment authorization retry behavior.
- Do not change settlement, refunds, or ledger posting.

## Done

- Regression tests cover network timeout and retry exhaustion.
- Existing payment tests pass.
- PR explains any behavior changes.
Enter fullscreen mode Exit fullscreen mode

If the issue is not concrete enough for Copilot to produce a reviewable PR, the issue is not ready for an autonomous coding agent.

constrain the patch

Agents are very good at "while I was here" edits.

That is dangerous.

A senior engineer should define the allowed patch surface before implementation starts.

Good:

Only edit src/auth/session.ts and tests/auth/session.test.ts unless you find a hard blocker.
If another file must change, stop and explain why first.
Enter fullscreen mode Exit fullscreen mode

Bad:

Clean this up while fixing it.
Enter fullscreen mode Exit fullscreen mode

"Clean this up" is where a small bug fix turns into an architecture argument hidden inside a diff.

ask for proof, not confidence

The final response should not be:

Done, the issue is fixed.
Enter fullscreen mode Exit fullscreen mode

The final response should look more like:

Changed:
- src/auth/session.ts
- tests/auth/session.test.ts

Verification:
- npm test -- auth/session.test.ts: passed
- npm run typecheck: passed

Notes:
- No public API changes.
Enter fullscreen mode Exit fullscreen mode

If a check cannot run, the agent should say why.

If a test fails, the agent should read the error, fix the root cause, and rerun it.

This is where senior engineers keep control. Not by manually writing every line, but by refusing to accept unverifiable work.

bad practice: "prompt and pray"

The failure mode looks like this:

  1. vague request
  2. broad edits
  3. no test added
  4. no focused verification
  5. same agent self-certifies
  6. human spends review time reverse-engineering intent

That is not a workflow. That is a cleanup job.

The fix is boring and powerful:

  • define the outcome
  • give high-signal context
  • set boundaries
  • ask for a plan when needed
  • demand proof
  • review the diff

That loop is the difference between agentic coding as engineering practice and agentic coding as expensive autocomplete.

checklist

Before giving an agent write access, ask:

  • What is the exact customer or system behavior I want?
  • Where should the agent start reading?
  • What files or areas are out of bounds?
  • What checks prove the work?
  • Should the agent plan first?
  • Who reviews the final diff?

If you cannot answer those, you are not ready to delegate the task yet.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

Top comments (0)