I couldn't have fixed this website problem without AI. AI caused it.

AI made a technical publishing system accessible to me, then broke it by ignoring a constraint it had not checked.

I recently asked AI to publish an article to my Editorial Intelligence website.

It created the file, added the metadata and committed everything to GitHub. The article appeared to be published.

Except it wasn’t on the website.

This is the kind of technical problem I probably would not have attempted to fix myself a few years ago. I’m not a developer. I don’t have the expertise to move confidently between Astro content collections, GitHub commits, build validation and Vercel deployments. More importantly, I don’t have the time or inclination to learn all of that whenever one article refuses to appear.

AI made the diagnosis possible.

There was, however, a complication.

AI had caused the problem.

The mistake looked completely plausible

Every article on the site has metadata, including a set of tags. The site uses a controlled vocabulary: only tags already defined in its content schema are allowed.

AI invented three reasonable-looking tags: “writing”, “creativity” and “authorship”.

They accurately described the article. They were also invalid.

Astro rejected the content during the build. Vercel therefore kept the previous working version of the site live. GitHub contained the new article, but production did not.

Nothing visibly broke. The website stayed online. It simply continued showing the previous set of articles rather than publishing the new one.

That is a useful example of how AI fails inside technical systems. It did not produce obvious nonsense. It made a contextually sensible decision that violated a constraint it had not checked.

The tags looked right to me because, semantically, they were right. The system knew something more specific: they were not part of the approved vocabulary.

AI made the system accessible, not simple

Once I noticed the article was missing, AI compared the GitHub source with the live site, inspected the content schema and found the invalid tags. It replaced them with approved alternatives and retriggered the deployment.

That still wasn’t the same as proving the article was live. A valid GitHub commit, a successful build and a page available to a reader are three separate states. The process had to continue until production matched the intended outcome.

I would not have known where to begin manually.

I might have searched for why an Astro article was missing, opened Vercel, looked through build logs, tried to understand GitHub Actions and eventually discovered the schema. Or I might have decided that publishing one article was not worth spending an afternoon learning an unfamiliar technical stack.

This is where AI changes what I can do.

It does not make me a developer. It allows me to operate a system whose individual components I only partly understand. I can define the outcome, recognise that the result does not match it and use AI to move through the technical layers between the two.

That is a significant expansion of capability. It is also more conditional than the usual “anyone can build now” argument suggests.

The guardrail mattered as much as the AI

AI was not the only reason this worked.

The site had a schema that rejected unknown tags. The build failed rather than allowing inconsistent metadata into production. Vercel preserved the last successful version instead of replacing it with a broken one.

Those controls were designed by people who understood the system more deeply than I do.

Without them, the AI-generated mistake might have reached the site unnoticed. The fact that AI could diagnose the failure does not make the surrounding engineering less important. It makes good engineering more valuable because many more people can now operate the system without understanding all of its internal rules.

This changes how I think about AI-enabled building.

The interesting capability is not that a non-developer can ask AI to create a website. It is that a non-developer can continue operating, changing and repairing one after the initial demonstration is over.

But that only works when the system makes failure visible, rejects invalid changes and preserves a safe state.

The skill is knowing the outcome

I still needed to notice that the article was absent.

AI initially treated the successful GitHub commit as publication. Technically, one action had completed. Editorially, the task had failed.

The important judgement was knowing that “present in GitHub” and “available to a reader” were not the same outcome.

That feels like a more realistic description of AI capability than either extreme. I do not need to become an expert in every tool involved. I do need enough understanding to define what success looks like, question a confident but incomplete answer and keep following the evidence across systems.

AI caused this particular failure because it acted before checking an existing constraint. It helped fix the failure because it could inspect that constraint once the mismatch became visible.

That is not magic. It is a new working relationship between human judgement, machine capability and technical guardrails.

I couldn’t have fixed this website problem without AI.

The reason I had to fix it was AI.

Both things can be true.