Skip to content

Journal · Jul 3, 2026

3 min read

AI agents in the dev workflow: where they earn their keep

I run agentic tooling every day. What actually moved delivery speed wasn't the model — it was the specs, tests and guardrails I wrapped around it. A grounded account, with the parts that still don't work.

Daniel Oseguera

Daniel Oseguera

Full Stack + AI Engineer

I run agentic tooling every day — Claude, OpenCode, Cursor, a few MCP servers wired into the repo. The honest headline isn’t “AI writes my code now.” It’s that I spend less time on the boring middle of a task: reading unfamiliar files, writing the test I already know the shape of, and typing the same migration for the fourth time.

Where the leverage actually is

The wins are unglamorous and specific:

  • Mechanical edits across many files. Rename a field, update every call site, fix the tests. The agent doesn’t get bored and I don’t fat-finger it.
  • Writing the first draft of a test. It gets the setup and fixtures close enough that my real job is asserting the behavior, not the boilerplate.
  • Reading code I didn’t write. “Explain how this refund flow decides what to retry” is answered in seconds against the actual source, not my memory.

What they don’t do well: decide what the system should do. That part is still mine, and it’s the part that matters.

Give it the map, not the maze

The biggest quality jump came from MCP servers that expose the real context instead of hoping the model guesses:

  • a server over the repo’s schema and migrations;
  • a server that runs the test suite and returns structured failures;
  • a server that reads our design docs and ADRs.

When the agent can query the actual database schema, it stops inventing columns. Context beats cleverness — every time.

Specs before tokens

Unstructured prompting produces unstructured code. So we write the spec first, in the repo, as a test we can run:

Scenario: A captured payment is not charged twice
  Given a payment with idempotency key "abc"
  When the same command is delivered again
  Then the ledger shows exactly one capture
  And the second call returns the original result

That file is the contract. The agent’s job is to make it pass; mine is to make sure it describes the behavior I actually want.

Guardrails that keep the speed honest

Speed without a brake is just a faster way to ship a bug. The rules I won’t bend:

  • Everything runs in CI. Agent-authored code gets the same gates as mine.
  • Small diffs. A 40-file change I can’t review is a liability, not velocity.
  • Tests are non-negotiable. If it can’t be tested, it isn’t done.
  • No green without a red. New behavior needs a failing test first.

What still doesn’t work

Long-horizon, multi-day tasks drift. The agent loses the thread across sessions, so I keep work in small, verifiable slices. And when it’s confidently wrong, it’s wrong at speed — the review step is what catches it, not the model.

The model is a fast, tireless junior with no memory and too much confidence. Treat it that way and it’s genuinely useful.

The workflow change is real, but it isn’t magic. It’s a spec, a test runner, and a human who still knows what “correct” means.

End of entry

More notes from the field notebook.