I’ve been building a blog generation API inside WordPress — the kind of system where the API endpoint, AJAX handlers, content generation flow, and publish functionality already existed and worked fine. I just needed one more feature.
Update existing posts.
That’s it. Sounds like a 20-minute task.
I asked Claude Code to implement it.
A few seconds later, it came back with a confident, well-structured plan:
- a new API endpoint
- a new AJAX handler
- separate update APIs
- an additional content-update flow
Basically, an entire parallel architecture. For one feature.
And here’s the uncomfortable part — it read well. The code was clean, the naming was consistent, the structure looked like something out of a “best practices” tutorial. If I’d been half paying attention, I would have merged it.
The moment I stopped it
I paused and asked myself the only question that actually mattered: does any of this new architecture need to exist?
The system already had a working flow for creating a post. All I needed was a branch in that same flow:
if (post_id exists) → update the post
else → create a new postNo new endpoint. No duplicate AJAX handler. No second content pipeline sitting next to the first one, quietly diverging over time.
Just one change: swap createPost() for updatePost() when a post_id is already present, and let everything upstream of that — the API layer, the AJAX handler, the content generation logic — stay exactly as it was.
Same request shape. Same validation. Same publish flow. One conditional.
Why this is scarier than it sounds
The dangerous part isn’t that AI writes bad code. It usually doesn’t. The dangerous part is that AI-generated complexity is confident. It’s syntactically correct, logically consistent, and dressed up in patterns that look like “proper software architecture.” There’s no red flag waving at you. It just quietly hands you more surface area than the problem asked for.
And if you’re not the one holding the line, that complexity compounds:
- duplicate systems that drift apart over time
- abstractions nobody asked for
- parallel APIs doing 90% the same thing
- a maintenance burden that looks like “scale” but is actually just weight
You don’t notice it in one sitting. You notice it three months later when you’re debugging two update paths instead of one, and you can’t remember why the second one exists.
The actual skill AI didn’t replace
This is the part I keep coming back to after 12+ years of building WordPress systems from scratch — themes, plugins, integrations, all of it.
A junior developer asks: can AI write this code? Almost always, yes.
A senior developer asks: should this code exist at all?
That second question is the entire job. It’s not about typing speed or syntax knowledge — AI has that covered. It’s about having enough architectural context to look at a “reasonable-sounding” solution and recognize that it’s solving the wrong-sized problem.
AI is an extraordinary accelerant. It will hand you a working system in seconds. But it doesn’t know your existing architecture the way you do, it doesn’t feel the cost of a duplicate endpoint six months from now, and it has zero incentive to say “actually, you don’t need any of this — just add a condition.”
That’s still on us.
The takeaway
The fastest fix I shipped this week wasn’t the one AI proposed. It was the one I got to after rejecting AI’s first answer and asking a smaller, sharper question.
In the AI era, writing code is no longer the bottleneck. Judgment is. And judgment — the instinct to say “wait, why are we building a second system for a one-line change” — is still very much a human skill.
That question alone saved what would’ve been weeks of unnecessary maintenance down the line.