I’ve been building software for over a decade. I’ve watched a lot of “revolutionary” tools come and go: IDEs with AI features, smart linters, auto-generated code that generated mostly garbage. So when AI coding assistants started getting serious traction a couple years back, I was skeptical. Cautious, even. I’d been burned before by tools that promised to change everything and mostly just added friction.
A year and a half later, I owe some of those tools an apology.
This isn’t a post about whether AI will “replace developers.” That conversation is tired and mostly hypothetical. What I want to talk about is more specific: what it feels like, day to day, to work alongside AI coding agents in 2026. Something genuinely shifted in the last year or so, and the coverage has been either breathless hype or reflexive dismissal. Neither is useful.
The Autocomplete Era Is Over
For a long time, “AI coding” basically meant smarter autocomplete. Copilot suggesting the next line. ChatGPT explaining what a stack trace meant. Useful in small ways, but still fundamentally you doing the work, with a slightly more attentive IDE.
That started changing when agentic tools got serious. But even then, they were flaky. They’d confidently write the wrong thing. They’d lose context halfway through a task and circle back to where they started. I tried a few and mostly went back to my own instincts, mumbling something about “not ready yet.”
What changed was the context window situation combined with actual reasoning improvements. Claude 4 came out in May 2025, and the step up in reasoning quality for agentic work was real. Models that can hold a large codebase in working memory and reason across it are a different category of tool. I spent last month rebuilding part of an AEM project with one of these agents running alongside me, and the experience was genuinely different from anything I’d tried before.
Not magic. Not perfect. But different in a way that matters.
What Works Now
Here’s what I’ve found useful, without dressing it up.
Boilerplate is effectively gone. Not just reduced. Eliminated. I haven’t written a new servlet skeleton, a DTO class, or a Sling model from scratch in months. The agent does it right on the first try, matches the conventions already in the codebase, and doesn’t require babysitting. This alone saves a meaningful chunk of time each week.
Cross-file refactoring surprised me more than anything else. I asked an agent to rename a set of methods across a large project, including tests, documentation, and related config files, and it handled it better than I expected. It caught dependencies I would have missed. It made a couple of mistakes too, but so would I.
I’ve also used it to make sense of legacy code I’ve inherited. Some of it is, charitably, a mess. Asking “what does this do and why would anyone write it this way” has saved me hours of archaeology on more than one occasion. The explanations are sometimes wrong or incomplete, but they give me a starting point instead of staring at the void.
Writing tests for code I didn’t write is something I hate doing. The agent doesn’t seem to mind. It’ll generate a reasonable test suite for a class I hand it, and about 80% of the cases it thinks of are ones I’d have written myself. The other 20% are either wrong or testing things that don’t matter, but the starting point is useful.
What Doesn’t Work (Yet)
There are real limitations and I’m not going to gloss over them.
Architectural decisions are still yours. Agents are great at execution but genuinely bad at “should we even build it this way.” They’ll implement whatever you ask, often competently, even if the approach is wrong for your situation. You need to know what you’re building and why. The agent doesn’t.
Debugging complex state issues is hit or miss. Runtime bugs that depend on specific data states, race conditions, or environment-specific behavior: the agent mostly guesses. Sometimes the guess is right. More often it’s not, and you waste time chasing a confident-sounding wrong answer.
Trust calibration is the ongoing cost of using these tools. The hardest part isn’t using the tool. It’s knowing when to trust its output. I’ve been burned by code that looked right and wasn’t. I review everything, which adds time back in. The net gain is still positive, but it’s not the 10x productivity story some people are selling.
The Skill Nobody Talks About
Here’s the uncomfortable part: using these tools effectively is itself a skill. A non-trivial one.
Writing prompts that get good results, knowing how to decompose a task so the agent doesn’t get confused, understanding when to give more context vs. when to step in yourself. This is real work. And from what I’ve seen, senior developers tend to get more out of AI agents than junior ones. Which is counterintuitive if you thought AI would level the playing field.
What it’s actually doing is amplifying whoever is using it. If you know what good code looks like, you’ll catch mistakes and course-correct. If you don’t, you’ll ship the mistakes.
I’m genuinely uncertain what that means for developers earlier in their careers, trying to learn the craft. The feedback loop that teaches you good patterns, writing code, seeing it fail, understanding why, might be getting short-circuited in ways that aren’t obvious yet. I don’t have a clean answer to that. But I think it’s worth saying out loud instead of pretending AI is some great equalizer.
Where This Is Going
The pace of improvement is genuinely hard to keep up with. Models that seemed impressive six months ago feel dated now. Agents that could handle small isolated tasks last year are tackling full features with minimal intervention today.
My guess is that within a year or two, the question won’t be “do you use AI in your development workflow.” It’ll be “how, and how well.” The developers who’ve been figuring that out now are going to have a meaningful edge.
I’m still figuring it out. Some days the agent genuinely impresses me. Some days it confidently wastes my time. The ratio is improving.
But I’m past the point of pretending I can ignore it.