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.

30 March, 2026

Linked in Post | Full LinkedIn Article

I have spent the last few weeks immersing myself in a variety of development projects, using a mix of Claude and CoPilot. This may surprise readers of my earlier vibes/VIBES post, but the challenge is not whether to use these tools, but how to understand what kind of assistance they actually offer, and at what cost.

I will focus here on relatively approachable work: building and modifying a WordPress site, small automation efforts, incremental refactors. This is intentional: there is less to this than, say, creating and troubleshooting a production CI/CD pipeline, but the patterns are quite similar. The same strengths show up, the same challenges repeat, and the lessons transfer more cleanly across the tech stack than most people expect.

That said, I’ll always try to also at least nod to the comparable lessons for larger, more enterprise focused work in these posts.

My initial sense of working with Claude and CoPilot was that it felt like working with the most over-eager, enthusiastic, junior intern you’ve ever met. BUT, the intern has memorized all the documentation. ALL. THE. DOCUMENTATION. And that has impactful, material value. Removing the burden of accessing all of that information is, at least at first, magnificent.

Anyone who has veered even slightly off the happy path in a platform like WordPress knows how much context lives just outside the task itself. Plugin creation and management, child themes, CSS placement, even just the core configuration of the platform—none of this is conceptually hard, but all of it creates friction. It’s the kind of friction that slows work, breaks flow, and disproportionately punishes people who don’t spend most of their time working inside these systems.

Claude (and the others) simply know this stuff. You can stay focused on what you’re trying to accomplish, while it fills in the surrounding structure. So that’s pretty amazing, and certainly a massive time-saver.

That alone would make these tools useful, offering small windows into enhanced productivity as a sort of hyper-optimized search engine that can be accessed via natural language queries. But there’s more here, and accessing that additional value is, I think, the critical bar for success in AI implementations, regardless of the size/scope of the context.

It all revolves around navigating how you leverage the application of the immense knowledge held by the tool.

Claude’s reactions are inconsistent at times, over-engineered at other times, and often in need of constant course correction and attention. And, quite dangerously, it will agree with your input immediately and enthusiastically, regardless of its quality.

A concrete example: Claude proposed a complex, JavaScript-based solution to change the appearance of some text. I suggested using standard CSS instead, which Claude-immediately and enthusiastically-accepted as a better approach. There are dual risks here. Solutions that look clever in the moment often undermine long‑term maintainability, and the tool’s willingness to pivot means you have to maintain a fairly high level of skepticism about the reliability of its initial recommendations.

The phrase “human in the loop” has gained fairly widespread use, and this is its application: as a user, you need to know the structure, the overall best practices, the general parameters of the architecture you’re working on or in so you are able to help guide Claude along its way. Indeed, guide may be too weak: you need to be able to critique the tool, to insist on things you know are true, to demand enough insight from it to convince you otherwise.

The key skills end up being yours. Your judgment, your pattern recognition, your instincts around architecture and troubleshooting. These are what organizations need, at the enterprise, to couple with the knowledge embedded in the AI tool; they are also what you need if you want more than surface-level gains.

There’s a bit of legitimate magic here, however: you can use the same AI tool to educate yourself on those best practices and to create a feedback loop that corrects the AI behavior. If you build into your interactions an active practice of asking why a given approach is preferred, or what alternatives exist, or what tradeoffs you’re accepting by doing something one way instead of another; you will often arrive at a far better, far more sound solution.

And you can do this from a place of learning: you don’t need to enter the interaction knowing about child themes in WordPress, but you do need to have the analytical skills necessary to ask the right questions, to integrate the answers, and to eventually arrive at a shared understanding of the best practice. That said, crucially, you never need to know exactly how to implement them.

This meta-usage, reflexively folding the tool back onto itself, using it to interrogate and critique and refine and improve its own output, is the single greatest lever we have for meaningful impact. This is what will define our ability to do more than merely automate mediocrity. That’s where the next article will focus: not just on using AI, but on using it to raise the bar for itself.

This one kicks off a deep dive into the murky waters of using AI tools in development work.

24 February, 2026

LinkedIn Post | Full LinkedIn Article

I’m not a curmudgeon. Really. And I’m a pretty bad Boomer representative. But I do roll my eyes almost involuntarily at discussions of “Vibe Coding.”

Like so many things, this reaction varies dramatically with what people actually, for-realsies, mean by the term. This came to a head over the last few weeks, crystallizing with two things I encountered within about a week of each other (for some of you, both of these are “old news,” but I think the comparison is still current, relevant, and meaningful).

The first was an episode of Hard Fork, the somewhat-tongue-in-cheek New York Times tech podcast where its hosts Kevin Roose and Casey Newton each had independently used Claude to “vibe code” new websites over the holidays. Kevin’s is very clean, very direct, and has a fun Easter Egg that makes it look like a 1990s GeoCities site. Casey’s feels more “professionally designed.” Both seem fine, and not terribly different from what you might create with the same amount of time with WordPress Templates or SquareSpace or whatever.

But both sites were created “just vibing with Claude.”

Casey talks about adding functionality to the site. And how he asked Claude to add a subscription widget that allows visitors to sign up to Platformer, his monetized content platform. And he moves on quickly with how great it was that Claude could do that.

Except … it didn’t. Not really. Yeah, there’s a subscription box on Newton’s home page. But when you put your email in that box and hit subscribe, it … doesn’t. Instead, it pops you over to Platformer, where you have to re-enter everything if you actually want to subscribe.

So, vibe coding created something that looks vibish, but whose code would fail the most basic User Testing.

It’s, I guess, “good enough” to seem impressive at a glance. And that seems to be the actual bar for vibe coding in general. Which is … fine? I guess? I mean, a tool to create slick looking demos that have an approximate relationship to final products is useful, right?

Here’s the contrast. That same week, Boris Cherny, who is referred to as the creator of Claude Code, publicly shared how he uses the tool. (That attribution strikes me as weird, and likely a result of our need to believe that creation is a singular act–whatever, Cherny is clearly highly influential and deeply involved in making Claude possible, and he himself refers quite a bit to the team he works with.)

Cherny’s workflow is … totally opaque and incomprehensible if you don’t have a programming background. If you do, it all makes sense. But it ain’t vibe coding. It’s structured use of a tool that can automate, aggregate, and do long-form research, and it is all predicated on having the experience and insight to recognize the abstract patterns that form the bulk of software development work and then create triggers and commands within Claude to alleviate the impact of that repetitive, reproducible work.

You can find Cherny’s original posts on Threads here. (Yeah, it started on Twitter, but I don’t go there no more.)

It’s impressive–as you would anticipate–and it shines a light on how agentic AI can be used to dramatically reduce certain kinds of work, even if the total savings is eaten away at by the need to manage the orchestration of the agents, review their work, tweak them, etc.

And it’s about as far away from Hey, Claude, add a widget or Hey, Claude, can you add a button to make the site look like what we remember of GeoCities? as you can get.

This illustrates, for me, the gap vibe coding still cannot (and, I suspect, will never be able to) fill. Tools like Claude Code can be used to create things that look decent, and things that, at some low bar of testing and sophistication, work. But developers working on real projects aren’t using it that way. They’re using it to automate (see my prior post as well, Go Forth & Automate!), to tackle routine drudgery, to create more abstract, reusable patterns that apply across use cases.

And that can be fantastically impactful and transformational. But it ain’t vibes. It’s work. It’s good work, it’s worthwhile work, it’s the work of the present. Still, work.