Why I'm Going All-In on Agentic Development

I’ve been spending a lot of time with agentic development tools lately. At this point it is not just a side experiment, it is a real part of my daily workflow.

When I say agentic development, I am talking about tools and workflows where an AI agent can actually handle meaningful chunks of a task. Not just suggesting the next line of code, but making coordinated edits across a codebase, debugging a specific issue, or running tests until they pass.

A lot of the conversation around AI is still stuck on better autocomplete or “chat with your code.” Those are fine, but they miss the real shift. The value is in changing the unit of work from a single line to a whole task.

Why this feels different

I’ve worked in cloud, DevOps, and mobile development for a long time. I’ve seen plenty of “productivity” tools come and go. Most of them make things a bit nicer, but this fundamentally changes how I approach a problem.

Instead of working line-by-line, the loop is simpler:

1. Define the goal
2. Let the agent take a run at it
3. Review the output and fix the rough edges

It makes it much cheaper to try an idea and it removes the friction from the tedious parts of the job. It also introduces new ways for things to go wrong, which means your judgment matters more than ever.

What actually improved?

Faster starts. Getting from a blank directory to a working prototype is much faster. A lot of projects never get off the ground because the initial setup is such a drag. That hurdle is mostly gone now.

Less routine drag. There is so much “necessary but boring” work in software: reshaping data, updating boilerplate, and adjusting tests. Agents are genuinely great at this.

Better leverage. With a good setup, one person can cover a lot more ground. Not because the hard parts of engineering disappeared, but because the routine parts don’t take up all your energy.

What hasn’t changed

This does not replace the need for experience. If anything, the bar for good judgment is higher. You still need to know when the code is wrong and understand the architecture. If you don’t know what “good” looks like, these tools will just help you make a mess faster.

I’m interested in the middle ground: what works, what breaks, and how this actually fits into a real development process. That is what I’ll be sharing here.