Agentic Engineering: How Coding Agents Changed My Workflow

A year ago, AI in my editor meant smarter autocomplete. Today I hand an agent a ticket, a few constraints, and a test command — and it opens a pull request. That shift is real, and pretending it isn't is how you get left behind. But the engineers winning with agents are not the ones who trust them most. They're the ones who delegate most deliberately.

Delegate the mechanical, own the architecture

Agents are extraordinary at the work that is tedious but well-defined: wiring a new endpoint to match an existing one, migrating a hundred call sites, writing the tests you already know you need. They are far weaker at the work that defines whether a system survives contact with scale — data modeling, boundaries, failure modes. So I keep a hard line: the agent writes the code, but I own the architecture. I decide the shape; it fills it in.

The agent is only as good as its context

The single biggest predictor of a good agent result is not the model — it's what the model can see. Point it at the right files, the existing patterns, the test that defines "done," and quality jumps. Drop it into a vague prompt with no examples and you get plausible nonsense. I spend more time curating context than writing prompts now. That's the actual skill.

Verify like you don't trust it

An agent that passes tests has not proven correctness — it has proven the tests pass. I read every diff. I run it. I look specifically at the seams the agent can't reason about: concurrency, auth, money, anything irreversible. The fastest way to lose the speed an agent gives you is to ship its mistake to production and spend a week unwinding it.

What actually changed

I ship more, but my job didn't shrink — it moved up a level. Less typing, more reviewing, scoping, and deciding. The leverage is enormous, and so is the responsibility. An agent multiplies whatever judgment you bring to it. Bring none and it multiplies that too.