# "Why does the AI always leave a few blocks out?"

> Source: <https://dev.to/dexterlung/why-does-the-ai-always-leave-a-few-blocks-out-48ab>
> Published: 2026-07-21 13:57:23+00:00

您的瀏覽器不支援音檔播放。[下載音檔](https://assets.coffeeshooters.com/completeness-baseline-en/completeness-baseline-en.m4a)

I asked an AI to build me a brand website. What came back had a header with two links, no "About" page at all, and an admin panel that worked — but with no button anywhere on the site that reached it. Backend 90, frontend 10.

My first guess was that it was being lazy. It wasn't. This is a *structural* problem — and the design principle that fixes it turned out to be one I'd reused, without noticing, **seven times** in my own toolchain.

This piece is about that principle. But first the "leaves a few blocks out" pain, because it has a name — and I suspect no one's named it.

I went digging into why these tools (mine included) "leave a few blocks out," and found they all verify the *same* thing:

"Is everything you

declaredinternally consistent?"

and never:

"Does this

kindof thing have what it'ssupposedto?"

That gap is fatal. You ask for a brand site, mention two pages, and every check faithfully confirms those two pages link to each other — then passes green. It never asks "a brand site is *supposed* to have an About page," because **nothing in the system holds a standard for what a brand site looks like.** Garbage in, *verified* garbage out.

That's the missing piece: a **completeness baseline** — *a standard of what a kind of deliverable should contain, that you check the real thing against.* Not internal consistency. Whether what's supposed to be there, is.

I'm not the only one who felt this. In Thomson Reuters' write-up of Claude Forge, the author drops one line: *"Passing tests is necessary, but not enough."* He **felt** the next layer — and didn't build it. Everyone's hit this pain; nobody grew the baseline.

My fix isn't "ship a built-in website template" — that would wreck the people building an API, an automation, a bot, anything non-web. It's an **axis**: first classify *what kind* of thing this is, and let each kind carry its own baseline of "what complete looks like":

And completeness is three layers, not a yes/no: **exists → reachable → substantiated.** That last one gets dropped the most: an About page that needs a photo isn't done until there's an *image slot* on the page **and** a path in the backend to actually put a photo in it — not just a wall of text. Web completeness is only *one* cell on the axis — which is why "you can't make 'web app' the only standard" is satisfied **by design**, not by exception.

That's the completeness baseline.

Once that baseline was in, I kept building — wiring the pipeline so it runs from an idea (or an audit of an existing project) all the way to delivery. And I noticed something strange: **every piece I added was the same design decision wearing a different outfit.**

**(1) Capability-gated, not identity-gated.**

The tool doesn't ask "am I Claude?" It asks "is *this capability* present?" — present, use the rich interaction; absent, degrade gracefully to plain text. Why it matters: the same thing runs on Claude Code, Cursor, or a bare LLM without breaking. **Detect the capability, not the identity.**

**(2) Public engine, private values.**

I open-source the engine, but keep my hard-won know-how — house conventions, a list of security traps, table names — in a *private* repo, **injected at runtime through that same capability gate**, never leaked. A public user without my private file just gets neutral defaults, completely undisturbed. My habits stay mine: not imposed, not exposed.

**(3) Propose, don't auto-advance.**

At the end of each stage, the system *proactively offers* the next step — but the human decides. **What's automated is the flow, not the judgment.** I even refused to make "auto-fix what the audit found" fully automatic: first it triages (genuinely fix-now / deliberately deferred / already correct), the human picks which to fix, and for the dangerous ones (touching row-level security, permissions) it stops and shows you the SQL before applying anything.

The meta-observation is the real one: **these aren't three features. They're one design philosophy in three outfits.** I counted — from the questioning interface, to knowledge injection, to stage handoffs, to a security gate, to the audit-then-fix loop, to the hook that makes a handoff fire deterministically — I made the same decision **seven times.** When you catch yourself making the same design call a seventh time, that's not repetition. That's a **law**. Name it.

I won't claim "no one's done this," so I actually checked — English and Chinese. Honest verdict:

So my novelty isn't in any single point — it's in the **combination** plus the framing of seeing them as *one law*. I'm saying that conservatively, because someone's unindexed repo or private essay may well have done something similar. But three rounds of searching didn't surface it, which is itself a signal.

Design aside, the rest is cost. I ran a **single controlled experiment** (N=1, labeled honestly): same spec, same decomposition rules, same prompt — **only the model changed.** Sonnet vs Opus, one decomposition each.

Those are precisely the errors that *propagate downstream* into integration breaks. So this N=1 (I'll take it to N≥3 before treating it as hard evidence) says: **the cheap model carries the mechanical bulk — 80% there and cheaper; the expensive model is worth its cost only on the "refuse to invent, catch the contradiction" judgment that prevents propagation.** Which is exactly why my pipeline assigns a model *per goal* and keeps an *independent audit* as a safety net.

Not "the expensive one is better." It's: **automate the flow, tier the judgment, and keep a human gate where errors propagate.**

If I positioned this as "an AI pipeline from idea to delivery," it'd get compared to Devin, v0, bolt — and I'm not in their quadrant. They sell magic, one-click, hands-off. I built the **opposite**:

For a one-person shop or small team, this isn't "a stronger agent." It's a **moat design pattern**: open-source the engine, accumulate your private know-how, take it to clients — instead of betting everything on a black box you can't see into.

The most practical thing I learned: **you don't stop "leaving a few blocks out" with a stronger model or more magic.** You stop it by (1) giving the system a *completeness baseline* that knows what a kind of thing should look like, (2) baking your conventions into reusable parts, and (3) automating the flow but never the judgment.

And — when you catch yourself making the same design decision a seventh time, stop. That's not you repeating yourself. That's a law you've been using but never said out loud. Name it. It might be exactly the thing everyone else is using too, and nobody's said yet.

*Source: a June 2026 conversation that grew from "the header only has two links" to "a portable security gate + end-to-end handoffs." The design decisions are recorded as ADR-001 through 007 in the public repos' DESIGN-NOTES. Prior-art and the full A/B data are kept separately.*