April 7, 2026
LinkedIn Post | LinkedIn Article
There are plenty of reasons to be cautious about AI tools. Error rates and hallucinations. The quiet reproduction of poor design choices or substandard programming patterns. The ever-present risk of unintended consequences. None of this is controversial at this point, and I’ve even covered some of this in prior posts here.
What’s discussed far less is the leverage of turning the same AI tool that generated a problem into a tool for diagnosing and correcting it. Done well, this improves not just the quality of what you’re building, but the quality of how you’re building it, shifting the use of AI from a “convenient accelerator” to a mechanism for steadily reducing friction and error over time.
Continuing with the relatively approachable work I described in the previous article, I’ve been using Claude while enhancing a WordPress‑based site. The site also relies heavily on Pods, a fairly common data container for WordPress. Nothing exotic or particularly cutting‑edge. But, representative enough.
My work with Claude here was very standard for the “new normal.” I was the orchestrator, the feature-describer and sanity-checker, and Claude was the eager implementer of these ideas. This is part of the seismic role and skill shift we are seeing, and part of the quandary organizations face in assessing internal talent and deciding what talent they should be acquiring: technical resources now direct as much as-if not more than-they implement.
Back to the work in WordPress. Over a short development cycle, Claude and I worked through a half‑dozen items on a loose roadmap: adding PHP functions for specific data calculations, improving data display, building a small admin interface to address data quality issues, and refactoring PHP and CSS code that former‑me had written that made present‑me cringe.
All of that worked. The tasks were completed. The versions of my custom plugin ticked upwards in an encouraging manner from 0.9 to 1.0 to 1.1 and eventually, something impressive looking like 1.4.2. From a feature perspective, things were “done.”
But. Something felt off.
Some of the code paths I reviewed seemed unnecessary. Parts of the documentation we had been generating along the way were oddly structured. There was no single dramatic failure, just a growing sense that complexity had accumulated faster than necessary.
So instead of adding more features, the next step was clearly to step back and audit the work. Doing this, however, didn’t require us to switch roles: I was still the orchestrator, and Claude still the over-eager doer.
But, for the next iteration, I asked Claude to review the entire plugin with a narrow set of concerns: consistency, duplication, and leftover artifacts from earlier work. We identified opportunities to move logic out of PHP and into configuration or admin‑level controls, where future‑me could reason about and maintain things more easily. I had Claude separate documentation into two streams-a slow‑changing technical reference and a more fluid knowledge base-explicitly framed around what it (not me, it) would need to know if we were starting together from a clean slate.
This is a vital, subtle lesson that I learned with difficulty. We’ll cover it in more detail in a future post, but the key thinking point is that the documentation you need can be, and probably is, very, very different than the documentation Claude needs.
The constraints mattered. This wasn’t a single prompt. The work was broken into steps. Changes were proposed at the level of intent first, and only reviewed at the code level as necessary.
The result was noticeably better than the initial generation phase. Fewer odd suggestions. Fewer instances of over‑engineering. And, importantly, consistent identification of remnants from its own earlier efforts—duplicated logic, buried CSS rules, structures that might have made sense locally but were clear weak spots when elevated to system‑wide protocols.
This shouldn’t be surprising. Pattern recognition, comparison, consolidation, and cleanup are all well aligned with what these systems do well. What’s easier to miss is that this dynamic doesn’t require sophisticated agent frameworks or fully autonomous workflows. It applies just as much to everyday, lightweight usage.
Right now, a great deal of attention-and money-is flowing into tools and consulting practices focused on reflexive, self‑correcting AI systems. Much of that work is thoughtful and valuable. But the underlying idea scales down quite cleanly: even in relatively modest contexts, deliberately folding the tool back over its own output changes the quality of the result.
The shift here isn’t technical so much as behavioral.
We need to build muscles around treating AI output as provisional, around expecting revision, around explicitly designing the rules of engagement to maintain space for critique by design. Once you adopt that posture, the risk profile changes: the primary danger is no longer that the tool will make mistakes, it’s that you’ll accept them. Once you see that clearly, not building in reflexive use starts to look less like a missed opportunity and more like an avoidable liability.
And this reflexive, folded-back-on-itself use of AI is where the real leverage is. But. It. Can. Be. Hard. Hard and frustrating in weirdly surprising ways. But that’s a post for another week.