DEV Community

Paulo Victor Leite Lima Gomes
Paulo Victor Leite Lima Gomes

Posted on

how senior engineers should code with agents without becoming reviewers of chaos

#ai #softwareengineering #codex #productivity

The worst way to use coding agents is to treat them like magic juniors.

You throw a vague task over the wall.

The agent edits ten files.

The diff looks plausible.

The tests maybe pass, maybe were not run, maybe do not exist.

Then the senior engineer becomes a reviewer of chaos.

That is not productivity. That is outsourcing entropy.

The better way to think about agents is this: senior engineers are not becoming prompt operators. They are becoming supervisors of small engineering loops.

The loop matters more than the prompt.

Context -> action -> verification -> review.

If that loop is tight, agents are useful. If that loop is vague, agents just generate expensive uncertainty with nice indentation.

the senior engineer still owns the work

Agents do not remove ownership.

They make ownership more important.

A senior engineer should still own the architecture, the boundaries, the risk, the tests, the review, and the decision to merge.

The agent can investigate. It can propose a plan. It can write a regression test. It can implement a narrow change. It can run commands. It can summarize logs. It can open a PR. It can even review another agent's diff.

But the senior engineer owns the shape of the problem.

This is the difference between professional agentic coding and vibe coding.

Vibe coding asks:

can you fix this?

Professional agentic coding asks:

fix expired sessions returning 500 instead of redirecting to login. Add a regression test first. Keep the public API unchanged. Use the existing token-refresh pattern. Run the focused auth tests and show the final output.

One is a wish.

The other is a work order.

define done in a way a machine can check

Claude Code's best-practices docs make a simple point that applies to every agent: give it a verification signal.

That can be tests, a build, a typecheck, screenshots, fixture diffs, log output, or a specific command result.

This is not bureaucracy. It is how you prevent "looks good" from becoming the acceptance criteria.

Bad:

Fix auth.
Enter fullscreen mode Exit fullscreen mode

Better:

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, 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 prompt is longer, but it is not prompt theater. It gives the agent a target, a search area, boundaries, and proof.

Codex works the same way. A good Codex task brief should include the goal, relevant context, constraints, and "done when." The less the agent has to infer, the less random the diff becomes.

explore before editing when the scope is uncertain

For tiny edits, just ask for the edit.

For broad or unfamiliar changes, do not start with write access.

Start with exploration.

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 the riskiest edge cases.
Stop before editing.
Enter fullscreen mode Exit fullscreen mode

This is not about slowing down. It is about separating two different jobs.

Exploration asks: what is true?

Implementation asks: what should change?

If you mix them too early, the agent often starts "fixing" a system it does not understand yet.

keep repo instructions short and real

Claude has CLAUDE.md.

Codex has AGENTS.md.

Both are useful. Both can become garbage.

Good repo instructions include things the agent cannot reliably infer:

  • install commands
  • focused test commands
  • repo layout
  • code style that is actually enforced locally
  • weird environment setup
  • dangerous areas
  • "do not" rules
  • PR expectations
  • what counts as done

Bad repo instructions include everything someone ever wished the team remembered.

The agent does not need a 1,500-line onboarding wiki pasted into context. It needs the few facts that change the next action.

A useful AGENTS.md snippet looks like this:

## Commands

- Install: pnpm install
- Test API package: pnpm --filter @app/api test
- Typecheck: pnpm typecheck

## Engineering rules

- Prefer existing repository patterns over new abstractions.
- Do not add production dependencies without explicit approval.
- For bug fixes, add a regression test before changing behavior when practical.

## Done means

- Relevant tests pass.
- Typecheck passes for changed packages.
- The final response lists commands run and checks that could not run.
Enter fullscreen mode Exit fullscreen mode

That is enough to improve behavior.

"Write clean code" is not enough. It is not a rule. It is a bumper sticker.

use subagents for noise, not shared-state chaos

Subagents are useful because context is not infinite.

Anthropic's guidance on context engineering frames context as a scarce attention budget. That is exactly right. If the main thread is full of logs, dead ends, screenshots, and unrelated docs, the agent gets worse.

Use subagents to isolate noisy work.

Good Claude Code pattern:

Use a subagent to inspect token refresh edge cases.
It should report only file references, risks, and suggested tests.
Do not modify files.
Enter fullscreen mode Exit fullscreen mode

Good Codex pattern:

Review this PR using parallel read-only subagents.
Spawn one for security/correctness, one for missing tests, and one for maintainability.
Wait for all three, then summarize findings by severity with file references.
Enter fullscreen mode Exit fullscreen mode

Bad pattern:

Spawn six agents to all edit the payment service at the same time.
Enter fullscreen mode Exit fullscreen mode

That is not parallelism. That is a merge conflict generator with confidence.

Parallel agents are best for read-heavy work: research, triage, review, log analysis, test gap identification, and alternative plan generation.

For write-heavy work, use separate worktrees or very clear ownership boundaries. Otherwise the human becomes the conflict resolver, which is exactly the job the agent was supposed to reduce.

use fresh-context review

The same agent that wrote the code is not the best judge of the code.

It has the same assumptions. It remembers its own plan. It is primed to believe the diff makes sense.

Use fresh context.

Claude Code pattern:

Open a fresh session or reviewer subagent.
Review this diff for auth/security risks only.
Report file/line references, risk, and suggested fixes.
Do not modify files.
Enter fullscreen mode Exit fullscreen mode

Codex pattern:

/review
Review the branch diff against main.
Focus on correctness, regressions, missing tests, and security issues.
Enter fullscreen mode Exit fullscreen mode

This is one of the simplest professional upgrades.

Writer agent implements.

Reviewer agent reviews.

Human engineer decides.

let agents use real engineering tools

Do not paste random snippets and ask the agent to guess the repository.

Let it use the same tools you use:

  • rg to search
  • gh to inspect issues, PRs, and checks
  • test runners
  • linters
  • typecheckers
  • local docs
  • logs
  • screenshots for UI work
  • database fixtures when relevant

The agent should not hallucinate the repo layout when it can read the repo.

The agent should not guess whether tests pass when it can run the tests.

The agent should not say "the PR should be fine" when it can inspect the checks.

This is why permissions matter. Give enough tool access to verify work. Keep write access bounded to the task.

manage context deliberately

Long-running agent chats rot.

They accumulate old assumptions, failed attempts, unrelated tasks, stale logs, and decisions that were true yesterday.

Senior engineers should treat context like memory pressure in a production system.

Clear between unrelated tasks.

Use subagents for log-heavy investigation.

Summarize only the facts that matter:

  • modified files
  • commands run
  • failing checks
  • decisions made
  • open risks
  • exact next step

Do not drag the whole debugging novel into the next implementation prompt.

The point is not to give the model everything.

The point is to give it the smallest useful truth.

automate after the workflow is stable

Claude Code hooks, repo instructions, Codex skills, project automations, and subagent templates are powerful.

They are also a way to automate bad habits.

First, run the workflow manually.

See what the agent forgets.

See which checks actually catch problems.

See where permissions are too broad.

Then encode the stable parts.

Good automation:

After editing TypeScript files, run pnpm typecheck for changed packages and report failures.
Enter fullscreen mode Exit fullscreen mode

Bad automation:

Always fix everything automatically.
Enter fullscreen mode Exit fullscreen mode

The first one tightens the loop.

The second one hides the blast radius behind confidence.

what senior engineers should stop doing

Stop asking agents for broad rewrites without target behavior.

Stop accepting "looks good" as verification.

Stop letting one context hold onboarding, debugging, implementation, PR review, and random questions.

Stop filling CLAUDE.md or AGENTS.md with generic wisdom nobody follows.

Stop running parallel write agents in one checkout.

Stop using auto permissions before the workflow is predictable.

Stop treating agent output as junior engineer output while skipping the review you would give a junior engineer.

And definitely stop saying "the AI did it" as if that changes accountability.

It does not.

a better default workflow

For most non-trivial work, I like this loop:

  1. Ask the agent to inspect and explain the relevant area.
  2. Ask for a minimal plan.
  3. Approve or adjust the plan.
  4. Ask for a narrow implementation with a machine-checkable definition of done.
  5. Run tests, typecheck, build, or UI verification.
  6. Use fresh-context review.
  7. Fix the findings.
  8. Commit only the intended diff.
  9. Capture durable lessons in repo instructions only if they will help next time.

This is not slow.

It is faster than cleaning up a 2,000-line diff that solved the wrong problem.

the real skill

Agents make senior engineers faster when the senior engineer brings senior judgment to the workflow.

That means scope.

Boundaries.

Architecture.

Verification.

Review.

Operational reality.

The model can generate code. That is useful.

But the professional advantage is not "I can ask for more code."

The advantage is "I can turn ambiguous engineering work into bounded loops that produce evidence."

That is the job now.

Not prompting harder.

Engineering better.

sources

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

Top comments (0)