Agent answer

Agentic coding tools can plan and edit across steps, but they still need tight scope, tests, review, and rollback.

Judge the workflow, not the demo

Agentic tools are trending and developers want a grounded explanation.

Tasks that fit bounded autonomy

The more autonomy a tool has, the more important boundaries become. Give it small goals, not vague ownership of the whole system.

Task Agent fit
Rename across files Good with tests
Add small feature Good if scope is clear
Design architecture Human-led
Security-critical change Human review required

Run an agent inside a review boundary

Safer agent task:
"Add requestId to API error responses.
Only touch error middleware and tests.
Run the existing test command.
Summarize every changed file."

This example is intentionally small. In a real codebase, the surrounding details matter: naming, error handling, tests, runtime config, permissions, and how easy the next developer can understand the change.

Measure rework as well as speed

  • Give narrow tasks.
  • Require tests or build output.
  • Review diffs carefully.
  • Avoid secret or production access.
  • Keep commits small enough to revert.

Agent workflows that create hidden cost

  • Giving broad tasks like “improve the backend”.
  • Skipping diff review.
  • Letting agents touch security code unsupervised.
  • Accepting huge commits.
  • Using agents without a clean test command.

Describe what remained your decision

Use a concrete sentence:

I used this pattern because [problem]. The main tradeoff was [tradeoff]. I verified it by [test or check].

That structure works because it shows judgment. Anyone can name a tool. Strong developers explain why they chose it, what could go wrong, and how they checked the result.

Documentation to inspect

Useful means reviewable

Agentic coding tools can plan and edit across steps, but they still need tight scope, tests, review, and rollback. Keep the implementation small, verify the edge cases, and write the decision down so the next person can trust it.

Give the agent a contract it can fail

“Improve the backend” has no finish line. A bounded task names the files, behavior, constraints, and verification:

Add request IDs to the withdrawal API.
- Preserve the existing response body
- Accept a valid incoming x-request-id or generate one
- Include it in logs and the response header
- Do not log authorization headers
- Add focused tests for supplied and generated IDs

Run the agent on a branch or disposable worktree with only the credentials it needs. Review git diff, dependency changes, generated files, and test output before merging. For CryptoEx, I would not delegate a balance invariant from a one-line request; the invariant and failure model must be written by the engineer first.

Measure the review burden

Track more than time-to-first-patch. Count review minutes, test failures, reverted changes, dependency additions, and bugs discovered after merge. An agent that writes code in two minutes but requires forty minutes of reconstruction may still be useful for exploration, but it did not produce a trustworthy final change.

The strongest use cases are mechanical migrations, test scaffolding, documentation discovery, and small changes with crisp acceptance criteria. Security boundaries, money movement, destructive data changes, and unclear incidents require tighter human control.

Questions for an agent trial

Can the task be verified automatically? Is the permitted file and credential scope smaller than the repository? How long does review take compared with implementation? How many agent changes are removed or rewritten before merge? Would the same task be safe for a new teammate with the same access?

Record the answers for several tasks instead of judging one impressive demo. The useful outcome is a repeatable workflow with bounded risk, not a video in which the agent succeeds once under ideal conditions.