AI wrote most of the code on a multi-week build I led — a product-recommendation tool that guides hosting shoppers to the right plan. It also confidently tried to ship a cart that showed the wrong price, a “talk to sales” bar nobody could see, and a screen that said the same thing four times. None of those would have failed a glance. Every one of them was caught by something I knew that the model couldn’t.
That gap — between what the model can generate and what someone in the trenches actually knows — is the whole game. This is the back-and-forth, the domain knowledge behind each save, and the four-rule framework that ties it together.
It’s a loop, and the human owns the hard half
I didn’t open with “build me a quiz.” I started by naming the real problem: shoppers land on a wall of near-identical plans, can’t tell them apart, and leave. The job was killing decision paralysis, not “a quiz.” Frame it that way and the requirements, the validation, and the success metric all follow. Then the work runs as a loop, not a handoff — and most of the value lives in the last box.
1AI is a fast junior, not an oracle
The most useful reframe I can give you: treat AI output like a strong junior’s first pull request. Fast, capable, often 80% there — and never merged to production unreviewed. The speed is real; the authority is not. Confidence is its default setting, not a signal that it’s right. I set the relationship up front: AI drafts, I own the merge. That one sentence is the entire safety model — and everything below is what “owning the merge” actually looks like.
AI generates faster than any human can. That speed is only an asset if a human owns the judgment.
2Depth of input determines quality of output
The glamorous version is “I asked AI and it built the tool.” The real version is the work I did before it wrote a line — assembling the ground truth that only someone close to the product would even know to gather:
- The full product spec, and every plan’s real specs
- All pricing tiers across every billing term, plus the renewal rates
- Licensing tiers and their thresholds
- Every pre-install application with its minimum system requirements
- Every parameter the configurator URL actually accepts
- The exact analytics-tagging pattern we run in production
Knowing which of these matter — and that renewal rates and URL params would bite us later — is itself domain knowledge. A generalist hands the model a paragraph; an expert hands it the map.
The depth of what you feed AI determines the quality of what comes back.
3Validate against production reality
Nothing is trusted until it’s checked against the live system and real data. The analytics tagging is the cleanest example of why.
Here’s the production tagging pattern. Note the element-type is NULL and one trigger uses the “body” label — keep it exactly, then verify every tag against the live page before we ship.
Those look like violations of the tagging standard — should I correct them to the compliant values?
No. Leave them. “Fixing” them is the bug.
Our dashboards were calibrated to those exact “wrong” values months ago — segments, click maps, trended reports all key off them. Making them spec-compliant would throw no error and silently break every report downstream. The model optimizes for the standard; I optimize for not detonating the reporting layer. That’s not in any doc it can read.
Then there’s the other half of validation: after launch, the data gets a vote. The numbers said the quiz converted far better than the page average — and that almost nobody was clicking it, because it was a ghost button buried next to a louder CTA. We’d have spent weeks “improving” a tool that was already working. The data found the real problem; reading it correctly is the skill.
4“Looks right” ≠ “is right”
This is the rule that earns the other three — and where blind trust gets expensive. AI’s mistakes aren’t obvious garbage; they’re plausible, confident, and correct-looking in isolation. Three from this one build.
The cart that would have shown the wrong price.
Cart links are wired up — one path per plan.
That defaults to a one-year term. The page advertises a longer term, so the cart will show a different price than the card. Add the term parameter to the URL.
Our docs say the term is set on the cart page, not via the URL.
The docs are behind. In production the URL param wins — use it.
The live cart’s real behavior contradicted our own internal documentation. The model can only read the docs; it can’t know production drifted from them. That gap — between what’s written and what’s true — is exactly where AI ships a confident, plausible bug, and it would have hit a buyer with a price change at the worst possible moment.
The sales bar nobody could see.
Make the “talk to sales” bar more visible — but not more blue, we’re already blue-heavy.
Switched it to a light grey.
Invisible. Warmer grey, deeper shadow?
Done — warmer grey.
Still invisible. Any option other than blue?
Flipped the whole bar to dark navy.
There it is.
Tone inversion is the standard move for a low-emphasis element that still must be seen — it’s exactly what Apple Pay and Stripe Connect do for their “talk to us” footers. The model knew that pattern; it didn’t reach for it because I’d framed the brief as a color problem when it was really a contrast problem. AI will faithfully optimize the wrong objective if you hand it one — naming the real problem is the expert’s job.
The screen that said the same thing four times.
The secondary CTA doesn’t fit above the fold — shrinking the padding to make room.
Stop compressing. Look at the words: “Find your fit,” “Made just for you,” a “YOUR MATCH” progress label, and a “YOUR MATCH” eyebrow. Same idea, four times. Cut the duplicates.
This was an information-architecture problem wearing a layout costume. The model optimized within the design it was given; the redundancy was in the design. Recognizing “this is a content problem, not a spacing problem” — and that repetition dilutes rather than reinforces — is taste built from doing this for years. Deleting the duplicates recovered the space instantly.
AI alone is a sure-shot fail on any high-stakes surface — not because it’s dumb, but because it has no taste for what’s actually wrong, only for what looks right. The output is most dangerous precisely when it’s most convincing, and the only thing standing between “looks right” and “is right” is someone who knows the territory.
The part that gets more true as models improve
Put the four rules together and you get a way of working: frame the real problem, feed it production truth, let it generate fast, and validate hard against reality — looping until it holds. Done this way you move faster than working solo and ship cleaner than AI-alone.
And here’s the counterintuitive part. The faster and better the models get, the more the bottleneck — and the moat — becomes the human’s domain knowledge: the production reality that isn’t in the docs, the pattern literacy, the downstream dependencies, the taste to spot what’s quietly wrong. That’s not the thing AI is about to replace. That’s the thing that makes its speed safe to use.
When you build with AI, what’s the last thing you caught that the model was sure was right — and what did you know that it couldn’t?