Hisham AlhussainAbout a year ago, I was pretty skeptical about coding agents. I'd tried a few, and while the demos were impressive, my real experience was a lot of cleaning up confident but wrong code. I figured they'd be useful for boilerplate and not much else.
I was wrong. Today a coding agent is involved in a big part of my work, and the way I spend my days has genuinely changed. I wanted to write down what shifted, partly for you and partly for future me.
I write less code and more specs
The biggest change is where my time goes. I spend a lot more time up front deciding what I want: writing down the goal, the constraints, how to tell if it worked. Then the agent does a lot of the typing.
It turns out the quality of what I get back depends almost entirely on how clearly I explain what I want. Vague request, vague result. The skill that matters most now is the same one that makes someone a good tech lead: being clear about what "done" means.
Plan first, then build
For anything bigger than a quick fix, I have the agent explore the code and propose a plan before it writes anything. I read the plan, push back where it's wrong, and only then let it build. That step catches most of the "it completely misunderstood the task" problems before they cost me anything.
Tests became more important, not less
If the agent can run tests, it can check its own work. So I care about tests more now than I ever did. A codebase with good tests is one where I can hand off bigger tasks with confidence. A codebase without them is one where I have to check everything by hand.
I keep notes for the agent
Every project I work on now has a short file explaining how things work: how to run it, how to test it, the conventions, the gotchas. I write it for the agent, but honestly it helps new humans on the team too. I also keep reusable instructions for tasks I do often, so I'm not explaining the same thing every time.
What I still don't hand over
There's a lot I'm happy to delegate. But some things stay with me:
- Architecture decisions. The agent can suggest options, but I decide how the system fits together.
- Security-sensitive code. Auth, permissions, anything touching secrets or money. I write or review that line by line.
- Anything irreversible. Deploying to production, migrating data, deleting things. I want my hands on those.
- Final review. I read every diff before it's merged. Every one. "The agent wrote it" is never an excuse for a bug.
The honest downsides
It's not all great. It's easy to get lazy and accept code you don't fully understand. Agents can be confidently wrong in subtle ways, especially in less common parts of a codebase. And reviewing a lot of generated code is its own kind of tiring. I've had to be deliberate about staying sharp.
Where I've landed
A year in, I think of a coding agent as a very fast, very well-read collaborator who needs clear direction and a careful reviewer. I get a lot more done, and more of my time goes to the parts of the job I actually enjoy: figuring out what to build and why.
If you're still skeptical, I get it. I was too. Try it on a real task, with a clear spec and good tests, and see how it feels.