AI Built It in an Afternoon. The Faults It Left Are the Ones AI Search Can't See Past

The story going around every agency Slack right now is that AI finally killed the hard part of building software. Prompt it, watch a working prototype appear before lunch, ship it. The build is solved and the thinking is optional.

The reality is more interesting. AI made the prototype cheap. It did not make the judgment cheap, and it did not delete it. It moved the judgment downstream, into the undocumented reasons behind a decision, the small wrong choices no user can name, the markup that functions but doesn't cohere. For a digital agency, that relocation is not just craft debt. The same faults that make a fast build hard to maintain are the faults that make a site hard for AI systems to read and cite. Skip the judgment and you pay twice, once in rework and once in invisibility. This is where the work actually goes when AI writes the first draft, and how to build the review layer that catches it.

"It ships, users can use it" and the faults hiding underneath

AI-assisted building is the default now, not the fringe. Across the 49,000-plus developers in Stack Overflow's 2025 developer survey, 84% use or plan to use AI tools in their workflow, up from 76% a year earlier, and about half of professional developers reach for them daily. Google's separate research agrees: the 2025 DORA report, drawn from nearly 5,000 technology professionals, found 90% now use AI at work.

There is no clean Australian or UK figure for how many agencies build this way, so read those as international numbers with a local overlay. The nearest local marker is directional: ANZ Banking Group reported that more than 7% of its code over a six-month period was AI-generated, a share expected to keep rising, across roughly 7,000 engineers on GitHub Copilot. That figure is from FY24 and now sits around 20 months old, so take it as evidence adoption went mainstream in Australia, not as a current rate.

Underneath a build that genuinely works, the faults stay quiet. One designer, writing in a UX Collective essay on senior judgment, describes AI-built prototypes that ship and that users can use, yet carry "interactions that are slightly off, components that don't quite fit the pattern." The diagnosis is exact: it's "the accumulation of choices made without a framework for what 'right' looks like beyond 'it functions.'"

Even the tooling vendors concede the gap. Shipping Canva Code 2.0 for building sites from prompts, the Australian-born platform had its own head of AI products admit the limit of vibe-coded output: "A tool that only solves for 'does it work' and ignores 'does it feel like mine' is solving half the problem." That is Canva framing its own positioning, so read "half the problem" as a vendor line. It still points at something real, the identical heading hierarchies, rounded buttons and dusky purple gradients that make AI-built sites "look like everyone else."

Skipping the spec doesn't remove the work, it relocates the failure

The failure doesn't vanish when you skip the spec. It resurfaces after deploy, where it costs more to find. The clearest read on this is The Register's write-up of CloudBees' 2026 State of Code Abundance report, an international enterprise survey in which 81% of tech leaders reported increased production issues linked to AI-generated code, even though 92% believed that code was production-ready before deployment. In the same study, 61% of code is now AI-generated or AI-assisted, 69% cite AI-introduced security vulnerabilities, 63% report compliance issues, and only 12% have any dedicated AI governance. As Averlon's chief executive put it, "When failures happen post-deployment, it signals that the validation process itself isn't keeping pace." That is the relocation stated as a number: the work moves from the spec you skipped to the incident queue you didn't budget for.

The faults that travel best are faults of omission, and those are the ones AI can't reason its way out of. A Trans-Tasman security specialist, Sam Shute, warns that AI-assisted coding is a "force multiplier for human errors" for flaws like insecure direct object references, because AI "doesn't truly understand... whether a certain piece of information should be known by just the submitting user, internal only users, or all users." He points to the API weakness introduced in 2018 that surfaced in the 2022 Optus breach. Who should see what is a "why" question, AI fills it in confidently, and a fast review rarely catches it. Ownership doesn't transfer either: when the Godot game engine drowned in unvetted pull requests, it banned almost all AI-contributed code on the grounds that "AI cannot take responsibility, and we can't trust heavy users of AI to understand their code enough to fix it."

Right-size the documentation to the blast radius

So let's be exact about the fix, because "write more docs" is the wrong lesson and "write none" is how we got here. AI-assisted coding made the heavy 20-page product requirements document a visible bottleneck, as a LogRocket analysis of PRD alternatives argues, but skipping documentation entirely creates its own failures. It offers one governing question: "What's the blast radius if something goes wrong?" You match the format to the answer, the way you'd never buy the same insurance for a bike as for a building.

The lighter formats on the menu are product briefs, decision logs, RFCs, tickets, prototypes and AI specs. The catch the same analysis flags: tickets and prototypes capture what to build, not the "why" or how the decision got made, which is the exact gap an AI-assisted build leaves. Documentation's job shifts from exhaustive spec to capturing that reasoning, sized to how much damage the decision can do. For an agency, the practical version is a short decision log on the high-blast-radius calls: auth, data access, anything a client is regulated on. Not a novel, just a paragraph on why, so the next person, or the next model, isn't guessing.

Why "it functions" is invisible to a client and fatal in AI search

Your client can't see any of this, which is the trap. A prototype that "functions" looks finished from the outside, so the faults never reach a conversation until something breaks. The place they surface first, quietly, is AI search. The structural weaknesses that make a build hard to maintain are the same ones that make a page hard for an AI system to parse and cite.

The benchmark behind that claim needs stating carefully. Search Engine Land's report on the Walker Sands B2B AI Search Visibility Benchmark, which analysed 828 enterprise B2B companies, found the median brand ranks for about 9,700 keywords yet is cited in just 3% of the AI Overviews summarising those searches. Near-zero citation is attributed to deeper structural issues: "content that's unstructured or difficult for systems to parse," alongside thin topical authority. The unstructured markup and incoherent patterns a fast build leaves behind are precisely what an AI system skips over. (Search Engine Land is owned by Semrush, and the benchmark is US-centric, so treat it as a directional signal, not a local law.)

A caution on the vocabulary: the label for this work is still contested. Some call it GEO or AEO, while Google's public position is that good SEO is good GEO, so treat AI search visibility as an extension of the fundamentals, not a separate discipline with its own guaranteed rulebook. The mechanism stays concrete: structure a parser can follow, answers that resolve a real question, depth across related pages. The judgment a fast build skips is the same judgment that earns a citation.

The review layer: catching what a fast build can't see

Here is where an agency wins back the value AI compressed. A build that only clears "it functions" routinely misses duties a senior reviewer catches on sight, starting with accessibility. Australia's federal Digital Inclusion Standard requires services to meet WCAG 2.2 Level AA and comply with the Disability Discrimination Act 1992, with compliance for existing public-facing services applying from 1 January 2026, and the DDA duty reaches private-sector sites generally. In Britain, the Equality Act 2010 obliges service providers to make "reasonable adjustments", and meeting WCAG 2.2 AA is how organisations evidence them for websites and apps. An AI prototype rarely handles contrast, keyboard and screen-reader operability, or semantic structure on its own, and that same semantic rigour is exactly what makes a page parseable and citable in AI answers. One review pass, two payoffs.

The review layer matters more now, not less, because adoption has outrun trust. In the same developer surveys that show near-universal AI use, only around 29% of developers trust AI accuracy, down from roughly 40%, and about 30% report little or no trust in AI-generated code. Teams are shipping faster than they believe their own tools. For an agency without an in-house senior-dev or SEO bench, a structured review is where the missing judgment lives, and it's a repeatable, billable QA pass rather than a one-off rescue.

Key takeaways

• AI-assisted building is mainstream (84% of developers in Stack Overflow's 2025 survey), so the differentiator is no longer speed of build, it's the review that catches what the build skipped.
• Skipping the spec relocates the failure downstream: 81% of tech leaders in CloudBees' international survey saw more production issues from AI code, while 92% thought it was ready before deploy.
• Right-size documentation to a decision's "blast radius," capturing the "why" that tickets and prototypes omit, especially on auth, data access and regulated flows.
• Structural faults and AI-invisibility are one problem: unstructured, hard-to-parse output keeps a site out of AI answers, per the US-centric Walker Sands benchmark.
• Bake WCAG 2.2 AA into the review. It satisfies AU DDA / UK Equality Act duties and produces the semantic structure AI systems need to cite you.

Frequently asked questions

What does AI-assisted development quality mean if the prototype already works?

It means the decisions a build makes beyond "it functions," and whether they hold up. A UX Collective essay describes AI-built prototypes that ship and work while carrying "interactions that are slightly off, components that don't quite fit the pattern," the accumulation of choices made without a framework for what "right" looks like. Working is the floor, not the finish line.

How do you right-size documentation for an AI-assisted build?

Match the documentation to the decision's "blast radius," the LogRocket framing for how much damage a wrong call can do. Skip a full spec for low-risk changes, but capture the "why" that tickets and prototypes leave out on high-stakes work like authentication and data access, using a short decision log rather than a 20-page PRD.

Why would an AI-built site struggle to appear in AI search results?

Because the structural weaknesses that make a fast build hard to maintain also make it hard for AI systems to parse. Search Engine Land's report on the Walker Sands benchmark of 828 B2B companies attributes near-zero AI citation to "content that's unstructured or difficult for systems to parse" and thin topical authority. The terms GEO and AEO are still contested and the benchmark is US-centric, so treat it as directional.

Does AI-assisted coding introduce more bugs or security issues?

The evidence points that way. In CloudBees' 2026 international survey, 81% of tech leaders reported increased production issues linked to AI-generated code and 69% cited AI-introduced security vulnerabilities, and an Australian security specialist warns AI is a "force multiplier for human errors" for omission-based flaws like insecure direct object references. A structured review layer is how teams catch these before deployment.

Ready to see what your fast builds are hiding?

If your team is shipping AI-assisted work faster than anyone can review it, that's the moment to add a QA layer rather than slow the build down. M2.0's Website Review is a structural and AI-readiness pass over a build, checking the semantic structure, accessibility and parse-ability a fast prototype skips, the same rigour that decides whether a site stays out of AI answers or into them. Packaged as a billable add-on to existing client work, it supplies the senior judgment the build relocated, without you hiring a bench to do it.