Six Months with AI Coding Tools — What Actually Changed About How I Work
Not productivity metrics or hype. Just an honest account of what shifted, what didn't, and the part nobody talks about: what it did to how I think.
I resisted AI coding tools longer than most people I know. The demos looked impressive, but the gap between "impressive demo" and "useful on a real codebase with real constraints" has burned me before. So I waited, watched, and eventually got tired of being the person in the room who hadn't actually tried the thing they had an opinion about.
Six months later, my take is more complicated than I expected. Not because the tools are bad — they're genuinely good — but because the way they changed my work isn't what I would have predicted.
The speed gains are real. But the more interesting change was slower and harder to measure: it shifted where I spend my cognitive energy.
What got faster
The obvious stuff first. Boilerplate generation is genuinely faster. Writing a new API route, scaffolding a form with validation, setting up a new component with the right TypeScript interface — these used to be tedious not because they were hard but because they required typing out things you already knew. That friction is mostly gone. I spend maybe a third of the time I used to on the mechanical parts of writing code.
The less obvious gain was with unfamiliar territory. When I need to work in a part of the stack I don't know well — writing a Dockerfile, setting up a CI pipeline for a new runtime, using an API I've never touched — the AI fills in the knowledge gaps fast enough that I can move without stopping to read documentation for twenty minutes first. It's not that the documentation got worse; it's that the synthesis layer between "what I need to do" and "what the docs say" is now mostly automated.
- Writing tests for existing functions — describe what it should do, get a solid first draft
- Refactoring repetitive patterns across multiple files simultaneously
- Debugging error messages with unfamiliar stack traces
- Generating types from JSON payloads or API responses
What didn't change
The things that are actually hard in software engineering are still hard. Deciding how to structure a feature so it doesn't become a maintenance burden in six months. Identifying the right abstraction boundary between modules. Understanding why a bug exists at a systems level, not just where it manifests. Knowing when a "simple fix" will create a worse problem downstream. The AI can suggest a solution quickly. It cannot tell you whether that solution fits the context of your specific codebase, team, and product.
This sounds obvious, but it matters because there's a failure mode I've seen on some teams where the AI's confidence — it always sounds confident — substitutes for the engineer's judgment. The suggestions aren't always right, and in a complex codebase they can be subtly wrong in ways that compile and pass tests but create problems later. The critical skill is still knowing enough to evaluate what you're given.
The thing nobody talks about
Here's the part that surprised me most: I write fewer comments now. Not because I'm lazier, but because the loop between "I have a rough idea" and "there's code on screen I can react to" is so much shorter that I spend more time in the reactive, editing mode and less time in the generative, blank-page mode.
That shift has a cost. I've noticed I sometimes accept a solution that's close enough without fully understanding why it works. When that happens with something I'll need to maintain, it creates a hidden deficit — code I own but don't fully understand. I've had to be deliberate about pausing to actually read and understand what gets generated, especially for non-trivial logic. The tool is fast. The understanding still has to come from me.
The AI makes the bad habit of moving too fast much easier to fall into. The discipline of actually reading and understanding code you own is your responsibility now more than ever.
Where I've landed
AI coding tools are now part of my workflow in the same way that a good linter is: I'd notice immediately if they were gone, but they're not what makes the work good or bad. The quality of the architecture, the clarity of the abstractions, the stability of the codebase over time — those still depend on judgment and craft that the tools don't affect.
What I do think has changed permanently is the expected baseline. Code that would have taken a junior engineer a day to write can be drafted in an hour. That means the competitive advantage has shifted even further toward the engineers who can evaluate, structure, and make good decisions about code — not the ones who can produce it fastest. If that sounds like good news for experienced engineers, I think it is. The parts of the job that are genuinely hard got a lot harder to automate.