I have been building WordPress themes for about 16 years now. I started with child themes, then builders, and then moved into custom development with Underscores. But I’ve never really delved (I think we can use this word again, right?) into plugin development. I taught myself to code in olden times, using BBEdit and Dreamweaver. I never picked up (nor was I interested in) build processes, React, tooling (gross). What I do know, and am interested in, is how the web is supposed to work for people: the conventions that we rely on, what makes an experience inclusive and accessible, and what a given use case technically requires versus opting for the shiniest solution.
With the help of AI, those years of practical experience were all I needed to start building my own plugins, first with Claude and now with Studio. There have been small utilities I’ve wanted for various sites over the years, and usually the plugin I found in the WordPress Repository often felt like overkill (a multi-tool, plus an upsell!). With Studio’s AI agent, I’ve been able to build the simple, single-purpose versions myself: an accessible promotion banner that can display on specific pages and be dismissed, a small SVG shape generator for when a design needs to be less boxy, an admin utility that alerts me when a client’s domain is about to expire, so I can send a reminder before I get the “my site is broken!” email.
I know what I want these tools to do, how I think they should do it, and what requirements to check for. Without AI, it is unlikely that I would have made it through the plugin-architecture learning curve on my own. I can do anything, but not everything, as David Allen might remind me.
This is the positive outcome of what’s happening with AI right now. But the other side of this new capacity we all have is the tendency to get caught up in the machine’s momentum and accept what gets created at “It works! (P.S. I’m clearly a genius.)”
(A)I Made This
Someone recently shared a calendar tool a volunteer had built to embed on their website. It looked polished (if a tad Design By Claude). Attractive layout, categorized events, a clever interface. They’d built it with an AI agent platform, start to finish, without writing a line of code by hand. Impressive!
I noted that font size was a bit small and then tried to tab through it with my keyboard.
It didn’t work. No focus states, no logical tab order, interactive elements you couldn’t reach. A visitor using a screen reader or navigating without a mouse would have been locked out entirely. The client had been visually wowed and both they, and the volunteer, had no idea that what they had made was completely inaccessible. Not only did this person not write the code, they didn’t really have the code, not to debug, maintain, or explain. They had a working demo hosted within an app that they didn’t own.
Making things is exciting
Look, I know the thrill of making something work with your own bare hands. I don’t want to be the kind of elitist knowledge worker that says, “Only real developers can touch code”. The whole World Wide Web is founded on universal access. Making things means exploring, testing assumptions, screwing it up. That’s how we learn.
For years, “this looks a little rough” was a decent proxy for “this was made by someone still learning, proceed with caution.” Sloppy code usually looked sloppy. But the clues that told us things weren’t working in the past are (almost) gone. What many AI tools produce is clean, conventional, reasonably well-structured code that works like magic.
From convivial tool to … weapon of capitalism?
For most of the twentieth century, things were built to be opened. You could pop the back off a radio, replace a tube, and figure out what was happening in there even if you weren’t the one who built it. Over time, that stopped being true.
The Phoebus cartel famously agreed to cap lightbulb lifespans in the 1920s specifically to keep people buying replacements. Cars went from machines that a relatively handy person could tune up in their driveway to rolling computers that lock diagnostics behind proprietary tools. Farmers had to fight John Deere for the legal right to fix their own tractors, because the software wouldn’t let anyone but an authorized dealer touch it. The right-to-repair movement exists because manufacturers found that making things un-fixable was a durable business model.
The philosopher Ivan Illich had a term for an alternative long before the advent of “smart” anything: a convivial tool, one people can understand, adjust, and repair themselves, versus an industrial tool that makes us dependent on someone else to keep it running. The internet of things pushed a lot of ordinary objects (thermostats, doorbells, light switches) into IP controlled territory. You don’t fix a smart lock. You wait for a firmware update, and hope the company still exists, or you replace the whole thing.
The web was designed to be on the convivial side of that line. View source is right there in the browser. An entire generation of self-taught developers (Hello, world!) learned by looking at how other people’s pages worked, taking them apart, and making changes. That openness is why the web, like the printing press, was able to connect people and become a defining technological and cultural force.
An AI-generated product you can’t read or maintain is problematic. In this case, it’s not that people sat down and decided to make plugins or apps un-fixable, but that’s a possible future when the barrier to producing drops at a speed well past comprehending what the heck you are doing.
You may enjoy my article, “Harder, Better, Faster, Stronger: AI Anxiety Ain’t New“. Learn what “workism”, Lord Alfred Tennyson, and bananas have in common.
Right now, a lot of AI tooling is priced like a loss leader. It’s cheap or free while companies fight for market share and habit formation. Once enough of us are building things we can’t maintain without the tool that built them, the pricing has room to move, and we won’t have much leverage. It’s not so different from the printer-and-cartridge model, or the appliance you can’t repair without the manufacturer’s proprietary part: the dependency is built in before anyone’s paying attention to what it’ll cost once we’re locked in.
And I can’t leave this section without saying it: none of this is truly free or cheap. Every plugin an AI generates for you, every draft, every image — it’s not fluffy and weightless. It’s server farms, drinking water for cooling and burning power at a scale most of us never have to look at (yet). Read more about the energy use and climate footprint of big tech.
With great power, comes great responsibility
AI has genuinely expanded what a solo developer or a small in-house team can produce. That’s a tangible benefit, an objectively good thing. Someone with no coding background can now build a tool that solves a real life problem they have without a huge budget or a developer on staff.
Between the eureka moment of “It works!” and understanding enough about how it works to be responsible for it, lies a world of complex unknowns.
As I’ve said previously about web accessibility, ignorance of the law does not grant you immunity from its rules. Whether you are a developer, a volunteer, or a business owner — if you ship it to the public, you own it. Can your product or app be maintained by you, or is “ask the AI to fix it” the only path forward when something breaks? Does it work as intended for every visitor, not just the ones who are most like you? Does it meet whatever bar the project is held to — WCAG for a government or public-facing site, HIPAA-adjacent handling for a healthcare client, basic security hygiene for anything touching user data?
Asking questions is still the strongest tool in your toolbelt
This applies whether you’re evaluating a plugin from the WordPress repository or something you built yourself with an AI assistant. Before it goes live — especially in front of the public, or anywhere near sensitive data — ask:
- Can someone here actually read and maintain this code? Can a genuine human on your team open the file, understand it, and change it without starting from scratch.
- Has it been tested with a keyboard and a screen reader? Visual polish tells you nothing about whether it’s usable. Tab through it. Try it with a screen reader.
- What happens when the person who built it moves on? If the answer is “no one else can touch it,” you don’t have a tool, you have a liability with a deadline.
- Does it actually meet the compliance bar this project requires? A government contract, a healthcare client, an accessibility commitment — these aren’t optional extras layered on top of “does it work.” They’re part of what “done” means, and AI has no idea what your project’s specific obligations are unless someone tells it, checks its work, and keeps checking.
These are the kinds of questions we ask ourselves as developers before shipping something. When AI makes it possible to sail past the friction of decision-making and still end up with something that looks finished, the burden is on us as creators to push back and do some due diligence.
Featured image: A scene from ReBoot, an awesome Canadian animated series that was briefly on TV on Rochester, NY during my youth. Characters exist in the “mainframe,” a computer generated world, and had to keep the universe safe from the evil viruses known as Megabyte and Hexadecimal.
