A new kind of project has started arriving in our maintenance queue: the site nobody wrote.
The owner described what they wanted to an AI tool, iterated until it looked right, and shipped it. Sometimes it's a whole marketing site. Sometimes it's a WordPress plugin that does one specific thing the business needed. And to be clear: it usually works. The tools have gotten genuinely good, and we're not here to sneer at them. We use AI in our own work every day.
But "it works" and "it can be maintained" are different properties, and the gap between them is where we now spend a surprising amount of our time.
What we find under the hood
The pattern is consistent enough to describe. AI-written code tends to be locally reasonable and globally incoherent. Each function makes sense. The file as a whole has three different naming conventions, two ways of talking to the database, and a dependency that was fashionable in the training data but abandoned since. Nothing is wrong exactly. There is just no single mind behind it, and you can feel that the moment you need to change something.
The more serious issues are quieter:
- Security assumptions nobody made on purpose. Form handlers without rate limiting, uploads without type checks, queries assembled a little too creatively. A human developer skips these out of laziness; an AI skips them because nobody asked.
- No update story. A vibe-coded plugin pinned to today's WordPress internals has no author watching the release notes. Core moves, the plugin stays, and eventually something gives.
- Invisible complexity. The site does more than anyone remembers asking for. Features that were generated, half-used, and forgotten still run, still load, and still expand the attack surface.
The month-six problem
None of this bites at launch. It bites in month six, when the business wants one small change, and the person who "wrote" the code cannot answer a single question about it. The AI session is gone. The context is gone. What's left is source code with no author, and someone has to become its author before anything can safely change.
That's the actual work now: adoption, not authorship. We read the code the way you'd read an inherited codebase, write down what it really does, add the tests it never had, and fix the assumptions no one made on purpose. After that, it's a normal site with a normal maintenance plan, and it can grow up like one.
If you're building with AI anyway
Do it with eyes open. Keep the prompts and the reasoning somewhere permanent, because that's the closest thing to documentation the project will have. Ask the tool to explain its security choices, then verify them. And before the site takes real traffic or real money, have a human developer read it end to end once. Not to rewrite it. Just to become the person who can answer questions in month six.
Because every site ends up with a maintainer eventually. The only choice is whether that happens calmly, or during an incident.