How Yellowhead Digital builds with AI
AI writes all our code. Governance decides what ships. This is the operating system we run on every change — built by watching the companies that didn't have one.
Last week, a piece of our software failed review — and the reviewer wasn't human.
The code in question does something simple to describe: when our diagnostic examines a business, it checks whether the company's mobile apps on Apple's App Store and Google's Play Store actually match up — same app, both stores, consistent identity. The logic looked right. The automated tests passed. A human had already read the code and approved it.
Then we handed it to an adversarial reviewer — an AI whose only job is to break things before customers find them. It invented a fictional company with a deliberately awkward app setup, ran that fake company through our logic, and demonstrated that we would have counted one app as two. It didn't just raise a concern; it proved the flaw, and added the example to our test suite so the same mistake could never quietly return.
The fix took an hour. The bug never reached a customer report.
That's one catch. Our development log has hundreds like it — because we run every change through this gauntlet, which we built after watching what happens to companies that didn't have one.
The fear about AI-built software is correct
Everyone evaluating AI-assisted development is afraid of the same thing: software nobody fully understands, shipped fast, failing silently, and constantly.
The fear is justified, and there are at least two famous public examples. McKinsey — the consulting firm — built an internal AI platform called Lilli, reportedly used by most of its tens of thousands of consultants. In March 2026, security researchers at Codewall showed it could be broken into through a classic injection attack. But the attack wasn't the real story. The investigation found that of the roughly 200 endpoints that the platform exposed, 22 had shipped with no authentication at all. No login check. Open doors.1
An Endpoint is a door into a system, a distinct address where software accepts requests.
Lovable — the world's most popular AI-assisted "vibe coding" platform — was exposing sensitive client data for months: passwords and API keys stored in plain text, unsecured endpoints, and no automated system designed to catch unauthorised access to users' data. According to researchers, some free apps — and their users — created on Lovable before November 2025 may still be at risk.2
Here's the diagnosis that matters: nobody at McKinsey decided to leave 22 doors unlocked. Nobody at Lovable decided to flagrantly risk user's data. That's the point — nobody decided anything. When you build 200 doors at high speed, simply 'remembering' to add the lock fails eventually, no matter how good the builders are. Security that depends on someone remembering is not security. It's a streak.
The industry's answer to this fear is mostly to slow down, or to hope. Ours is neither. AI writes our code — not most of it, all of it. Governance decides what ships.
The operating system
Yellowhead's platform — the diagnostic engine, the customer dashboard, the billing and account layers — is written entirely by AI, with one human doing the two things humans do best: deciding what gets built, and reviewing what got built. We treat sole AI authorship as a feature, not a confession. A codebase with one author has one style — no personal quirks and no "that's just how the last developer did it" — and that consistency is precisely what makes it reviewable, by humans and machine examiners alike.
What makes this safe isn't the reviewer's vigilance. It's a written operating system that runs the same way on every change.
It includes:
A constitution the AI reads before every working session.
Our conventions, known mistakes, and security defaults live in a standing instruction document. "Every new door gets a lock, and removing one requires a written, recorded decision" isn't something anyone has to remember — it's a law the AI must re-read every time it starts work.
A written record of intent.
What the system is for, how it's shaped, and what state it's in are maintained as living documents alongside the code. Anyone — human or AI — can pick up the project cold and know where it stands and why, without archaeology through old conversations.
A quality gate before anything goes live.
Every change must pass automated checks before it can be published. The rare exception — pushing a change through directly in an emergency — has to be justified in writing. Boring, until you notice that most fast-moving software disasters begin with "it was a small change."
An independent examiner after every change.
Each saved change is reviewed by a separate AI examiner checking three things: does it work, is it secure, and can it be explained? A change that works but can't be clearly understood fails review, because code nobody understands is where the next silent failure hides.
Our AI examiner has caught features that were switched off without anyone noticing and checks that flagged the wrong businesses. Memorably, it found a dozen newly added evidence signals that were being collected and stored, but not yet delivered to the part of the system that scores them. No customer was misled — scores were built correctly on the evidence that did arrive — but reports were running less informed than we'd designed them to be. Every status light said the system was working, because "collect and store the evidence" was being done perfectly. It took our own review process to ask the question no test had encoded: does anything read this yet?
An adversarial reviewer on significant changes.
Separate from the examiner, a second AI reviews major work with instructions to attack it, not admire it. That's the reviewer from the opening paragraph — the one that invents fictional companies to prove a flaw exists rather than offering an opinion that one might.
A canary after every release.
Coal miners carried canaries because the bird noticed bad air before people did. Our version: immediately after changes to a report go live, we run multiple diagnostics against real businesses and check that the results still make sense. A release isn't "done" when the code is published. It's done when the canary comes back healthy.
Receipts by construction.
Significant decisions are written down with their reasoning at the moment they're made. The most sensitive records in our system can be added to but never edited or erased — so history can't be quietly rewritten. And access to customer data is enforced by the database itself, which refuses to hand data to the wrong account — rather than trusting every piece of application code above it to remember to check.
Self-improving systems.
When we catch an error, it isn't logged and forgotten. The lesson is baked-in. Our AI agents setup guardrails to prevent similar failures in the future.
And one house rule we'd defend anywhere: a system that recovers silently is a system that lies to you. When one of our data sources fails and a backup covers for it, we log the failure loudly anyway. A quiet recovery looks identical to success — and a business that can't see what's failing inside its own systems is running on faith. (If that sentence sounds like our sales pitch, it's because it is. More on that below.)
The receipts
Six months. One operator. Roughly 1,900 recorded changes to the product. Every major batch of work has had the gauntlet catch something real before customers saw it: scoring logic reading from the wrong place, the app-matcher double-count, and backups quietly masking dead integrations.
None of these catches required brilliance in the moment. They required the system to run — the same way, every change, with no exceptions.
Why this matters to anyone but us
Because this is the product.
Yellowhead Digital aims to be your marketing infrastructure intelligence partner. Therefore, we hold ourselves to a high standard. Our platform, its cornerstone Diagnostic report, and everything other tool that builds upon it must be reliable, accurate, and instill confidence in our clients.
Our Architect service designs and builds marketing infrastructure for businesses — with AI in the build loop, because that's where the economics have gone. The question every buyer should now ask anyone building software with AI is: what stands between the AI's output and my production system? Our answer is the operating system above — and the reason we can describe it precisely is that we run it on ourselves, daily, on the codebase our own revenue depends on.
The deeper claim: understandability is a security property. Software is now reviewed by machines as well as people, and that will only accelerate. Systems built fast and unregulated today become systems nobody — human or machine — can safely review tomorrow. The discipline isn't a tax on AI's speed. It's what makes the speed safe to keep.
Governance doesn't mean slow, it means acceleration with confidence.
Notes & sources
- 1. Codewall (2026). How We Hacked McKinsey's AI Platform, Lilli. Codewall Security Research. Published 9 March 2026. codewall.ai. See also: Outpost24 analysis (outpost24.com) and 1Kosmos breach summary (1kosmos.com).
- 2. Inigra (2026). Lovable Security Breach: What We Found. inigra.eu. See also Lovable's incident response: lovable.dev.
Want the operating system above running your next build?
If you want the forensic view of your own stack, start with the free Diagnostic. And if you want this governance layer running on what you build next, talk to us about our Architect service.