A note about the ranch
Catching mistakes before they are made
8 min read
AI should be part of how this business builds things. This is not an argument against that. AI is faster, cheaper to iterate, and produces more output from the same resource. Used well it is a genuine competitive advantage.
The question is not whether to use AI. The question is whether a mistake made at machine speed gets caught before or after it reaches the business.
Right now, nothing is catching it before. And that has a cost.
Catching mistakes after — a real example
A formal code audit was recently run on three PHP files at the heart of the plate builder — critical checkout code that handles how customers configure and buy products. The files were AI-assisted. The audit was run after the code was already in production.
Twenty findings. Nearly a third of the codebase — 560 lines — serving no necessary purpose or duplicated unnecessarily.
In plain English, here is what was found.
Debug notes left running in production. Approximately 40 development annotations were left active in live code — the kind of notes a developer leaves for themselves while building, never intended to be seen outside a development environment. In production, these are visible to anyone who knows where to look. They describe exactly how the system works internally. This is information the business would not want competitors or attackers to have.
A cache system silently defeated. Two lines of code — written to solve a specific problem during development — were left in place on the live site. The effect: every customer who visits the site downloads every asset from scratch, every time, on every page view. The browser's ability to remember what it already downloaded — one of the most basic performance tools available — was switched off without anyone noticing. Slower pages. Higher server load. Worse ad performance. On every visit.
A known timing problem papered over. A part of the checkout had a timing issue the original author could not solve cleanly. Rather than fixing it, four separate delays were added in sequence — each one hoping to land at the right moment. This is the kind of fix that works until it doesn't. When it stops working, during peak trading, nobody will immediately know why — because the fix was never documented and the underlying problem was never resolved.
The same code maintained in two places. Two files — nearly identical, 95% the same — exist separately rather than as one shared file. A fix applied to one will not automatically apply to the other. Bugs will persist in whichever copy someone forgot to update. This doubles the maintenance cost of every future change.
Nearly a third of the code doing nothing. 560 lines that are duplicated, leftover, or serving no current purpose. Every unnecessary line is a line that could hide a problem, complicate a diagnosis, or slow down a future fix. On critical checkout code, that is not a small concern.
This is what catching mistakes after looks like. The code was live. The audit found the problems. The fix cost is real and ongoing. A guardrail before the build would have cost a conversation. The audit after cost significantly more — and that is one audit, on three files, on one site.
Catching mistakes before — a missed opportunity
A member of the team recently built a set of internal dashboards using AI. The result was genuinely impressive — data that was previously inaccessible became available quickly, customer service improved, and a real operational problem was solved. That is AI working well. That win is real and should not be undermined.
But the build happened before any conversation about how to build it.
Had the conversation happened first — "what are you trying to achieve, and what does it need to handle long-term?" — the answer would have shaped the foundation. The business has over 80,000 orders across three years and growing. The data includes customer details, order history, and email records. The right foundation for that volume, that sensitivity, and that growth trajectory is a robust database on the same stack as everything else the business runs.
The foundation chosen works today. It was the right choice for getting something built quickly. It may not be the right choice when the data doubles, or when two people need to access it simultaneously, or when the business needs to connect it to something else.
A five minute conversation before the build catches that. Not to block the work — to make the work better. Same outcome. Sounder foundation. No future migration cost.
That is what guardrails before the build look like. Not slower. Smarter.
The pattern
Both examples share the same shape. Someone wants to build something — the goal is legitimate. AI makes it possible to build it quickly. The build happens before the right conversation. The result works on the surface, in the demo, on the happy path. The problems underneath accumulate silently. The cost arrives later, at a worse time, at a higher price.
This pattern is not anyone's fault. It is what happens when a powerful tool operates without a process designed to match its speed.
AI builds at machine speed. Humans catch problems at human speed. Without a guardrail designed for the gap between those two speeds, the problems accumulate faster than they can be caught.
Right now there is no such guardrail. And the business is planning to scale from five sites to sixteen on the same basis.
Why this is urgent now
New AI-generated code is currently being integrated into a site that was previously rolled back. The original failure was not fully diagnosed. The new code has not been reviewed. The combination of two unstable things does not produce one stable thing — it produces something nobody fully understands that fails in ways nobody can predict.
When this was flagged as a concern, the response was that it is not for production yet.
That is a reasonable position. It is also, based on the documented history of this ranch, not how it stays. Code that appears to work gets pushed. Deadlines create pressure. The gate that was supposed to stay closed gets opened because the horse looks ready.
The guardrail has to exist before the pressure arrives. Not as a response to it.
The recommendation
AI is not the problem. The absence of process around AI is the problem. The recommendation is not to use less AI. It is to use AI properly — which means two non-negotiable conditions before any AI-assisted code touches the business.
Condition one — conversation before build. Before AI is used to build anything, a brief conversation establishes: what is the goal, what does it need to handle long-term, what stack should it sit on, what should it connect to, what should it avoid. This does not slow the build. It shapes it. The dashboard would have been built the same way — just on the right foundation.
Condition two — review before production. Before any AI-assisted code reaches a live environment, someone who understands the codebase reviews it. Not the person who built it. Not a skim. A review — the kind that would have caught 560 unnecessary lines, a defeated cache system, and debug logs running in production before any customer saw them.
These two conditions are the paddock. The horse goes through the paddock before it goes through the gate. Not because the horse is probably bad — because the paddock is how you know.
The solution already exists
This is not a proposal for something new. Two documents have already been written that define exactly what this looks like in practice.
AI Use Commandments — ten rules, plain English, one page. Covers what AI can and cannot touch, how changes are reviewed, how audit trails are kept, and how rollback works. Written for every person on the team.
AI Delivery Process — four review gates that implement the two conditions above. Conversation before build. Review before production. A rule that protects junior team members from being asked to build on unreviewed foundations. A 90-day audit to catch anything that slips through.
Both documents exist. Both are ready. Neither has been mandated.
The ask is the mandate — from the Boss, applying to everyone, not subject to deadline pressure or the argument that the code is not for production yet.
The AI delivery process is the standard. It applies to everyone. Nothing AI-assisted reaches production without going through the paddock. This is not optional.
That sentence changes the risk profile of this business permanently — and it makes every site launched from this point forward worth more, because it was built on a foundation someone checked.
At scale
The business is planning to move from five sites to sixteen. All on shared infrastructure. All increasingly built with AI assistance. All subject to the same pressure to ship quickly.
At five sites, a problem on one site is a problem on one site.
At sixteen sites on shared infrastructure, a problem introduced through unreviewed AI code is potentially a problem on every site simultaneously — the same checkout bug, the same security gap, the same defeated cache system, running across every storefront at once.
The guardrails do not get easier to introduce as the ranch gets bigger. They get harder. The right time to put the paddock in place is before the herd doubles — not after the next horse goes through the fence.