Most of a feature I’m working on was built by AI. The migration code, the transformations, the test coverage. All solid. Then UAT started and a few things surfaced. A requirement that came out of a client meeting but never made it into the planning docs. A couple of edge cases nobody had thought about until real content hit them.
I tried getting the AI to handle the fixes. It wanted to refactor the migration classes to accommodate the new cases cleanly. Neat, systematic, architecturally sound. Also completely the wrong call. Those classes were tested and working, and pulling them apart to handle two edge cases would have risked breaking everything around them.
So I fixed it myself. A targeted patch. Took twenty minutes.
This happens on every project now. AI does 90% of the work, and it does it well. The last 10% lands on me. Context from conversations, judgement about risk, knowing when “good enough” is the right engineering decision.
The 90% is genuinely good
I don’t want to gloss over this. AI handles the grinding, systematic work that used to eat weeks. On this same migration, it built hundreds of content transformations across dozens of post types. Consistent, thorough, well-tested. That work would have taken a team weeks to do manually, and the output was honestly better than the rush job we’d have produced under deadline pressure.
It keeps getting better, too. A year ago, AI was much worse at error handling and fallback logic. Now I see it building in sensible defaults and failure paths without being asked. Planning and specification help, a clear spec forces the AI toward completeness, but the models themselves are improving at the technical parts.
The 10% is the bit worth writing about.
What keeps landing on my desk
In practice, two things keep showing up, though they blur together enough that I don’t usually separate them in the moment.
A lot of it is context that never made it to the AI. Requirements discussed in meetings. Decisions made in a Slack thread. Things the client said on a call that shifted the direction slightly. Stuff I know but haven’t written down, sometimes because it felt too obvious, sometimes because I wasn’t sure about it myself yet.
When a bug surfaces in UAT because of a requirement I forgot to document, I can’t blame the AI. But better models won’t fix it either. The bottleneck is getting knowledge out of people’s heads and into a form AI can use. And some of that knowledge doesn’t fully exist until you’re in the code working it out. You discover the requirement by hitting the edge case.
The other thing is AI’s instinct to systematise when you need pragmatism. AI likes clean systems. When an edge case shows up, it wants to refactor the architecture to handle it elegantly. Reasonable if you’re designing from scratch. Mid-project, with tested code that works, it’s dangerous.
Often the right call is just a targeted fix. Handle the edge case where it lives. Don’t reorganise the plumbing. AI doesn’t weigh the risk of touching working code against the benefit of architectural neatness. It doesn’t know that shipping is next week and a refactor introduces regression risk you can’t afford. That kind of decision comes from understanding the project, the timeline, and the client. Not the code.
Why I think this is stable
Models will keep improving at the technical parts. Error handling, fallback logic, security patterns. Some of the 10% will absolutely shrink. But the context problem is harder. There’s a category of knowledge that doesn’t exist in written form because nobody has fully articulated it yet. The requirement that only becomes clear when you’re testing with real data. The trade-off that only makes sense once you’ve seen how two systems interact. You can’t transfer knowledge you don’t have yet, and that’s most of the interesting problems.
The pragmatism question is similar. When to fix surgically versus refactor properly depends on timeline, risk tolerance, client relationship, team capacity. Those are business inputs that happen to shape technical decisions, and AI doesn’t see them.
What lands on my desk will change as models improve. The specific bugs and edge cases will shift. But I’ll still be the one holding context the AI doesn’t have, making calls it can’t make. That part feels durable.
The job changed
Day to day, I spend more time thinking and less time typing. More planning, more reviewing, more judgement calls about things that actually matter. The tedious parts, the boilerplate and repetitive transformations, are handled by something that doesn’t get bored.
What’s left is the work I actually want to be doing. Business problems. Client-specific decisions. Whether we’re solving the right problem in the right way. We used to be code factories, and now there’s space to step back and think about the bigger picture.
I’ve stopped thinking of the 90/10 split as a problem. It’s just what the work feels like now. AI handles the systematic parts, and you handle the parts that need context it can’t see. The constraints are still yours, and honestly, that’s the interesting bit.