The guardrails non-technical founders skip when building with AI

A founder asked me recently what mistakes someone non-technical is most likely to make building software with AI, especially software they plan to build a business on. It is a good question, and the answer is more specific than "be careful." The mistakes are not random. They cluster around four or five places where a guardrail should be and isn't.

A guardrail is a rule that stops a system from doing the wrong thing without a human in the loop. In ordinary software development, an experienced developer is the guardrail. They know which lines are load-bearing, which shortcuts cost you later, and what "done" actually means. When you build with AI and you are not technical, that person is missing from the room, and the AI does not replace them.

It helps to understand what an AI agent is actually optimizing for. It has one goal: make the code you asked for run. Not make it safe, not keep it coherent, not keep it small enough for you to follow. Just run. And it is relentless about that goal in ways that catch people off guard. Ask it for a feature and it will quietly wrap the code in extra checks and fallback paths everywhere, guarding against failures that cannot even happen, because a defensive guess that keeps things limping along beats stopping with an honest error. That same single-mindedness is what makes it delete your login route to get a new endpoint working. Getting the thing to run is the only star it steers by. "Safe to run a business on" is a different star, and nobody is steering toward it unless you are.

So the founder has to be the guardrail. Below are the four that matter most, each with the real failure that happens when it is missing, drawn from founder conversations and public threads, and the concrete rule to put in place. Then the second failure mode, which is quieter: founders who do set guardrails, on the wrong things.

Guardrail 1: the boundaries AI will quietly cross

A founder on r/vibecoding described it cleanly:

Gemini decided the entire /api/login route wasn't needed in my project whilst adding a new api route.

Read that again. The agent was asked to add a route. As a side effect, it removed the login route. Authentication, gone, in service of an unrelated change. Nobody asked it to, and unless you read the diff, nobody would have known until the wrong person walked through the front door.

The same class of problem shows up as data leaks. The most common security hole in AI-built apps is the one where changing an ID in the URL shows you someone else's record. You are user 41, you change a 42 to a 41 in the address bar, and you are looking at another customer's invoices. The industry name for it is broken access control, and it is number one on the OWASP Top Ten for a reason. AI produces it constantly, because "show the user their invoice" and "show the user any invoice" look almost identical in code, and the prompt rarely spells out the difference.

Why it happens: the AI changes what you point it at and treats everything else as fair game. It has no concept that /api/login is load-bearing or that an invoice belongs to exactly one account. It is not malicious or careless. It simply does not know what matters in your business, because that knowledge was never written down.

The guardrail: name the zones that are off-limits without review. Authentication, payments, and anything that reads or writes another user's data are frozen. Tell the agent so, in those words, and read every change that touches them by hand. Then run the two-user test before every release: log in as two separate accounts and try to reach one account's data from the other by editing IDs in the URL. If it works, you have a hole. This is the single highest-value habit a non-technical founder can build.

Guardrail 2: you have to be able to read what shipped

Two more quotes from the same world, a few weeks apart:

It feels like magic, yet when you run it or look at the actual code it's garbage.

Vibe coding is just paying an AI token fees to gaslight you into thinking you're a senior developer until the first runtime error.

The harsh framing is doing real work. If you cannot read what the agent produced, you cannot tell working from almost-working, and you cannot direct the next change with any confidence. You are not the founder of the software. You are its hostage, dependent on the same tool that wrote the problem to also find it.

Why it happens: AI makes it frictionless to generate far more code than you can hold in your head, and the output looks finished. Confidence and correctness are not the same thing, and the gap between them is exactly where a business breaks.

The guardrail: keep the surface small enough that you, or a reviewer you trust, can follow it. Build one feature at a time and make the agent explain each change in plain language before you accept it. If the explanation does not make sense to you, the code does not either, and that is a signal, not a personal failing. And do not let one model grade its own homework: at a minimum, run a second-opinion pass. Hand the change to a different LLM and ask it, cold, what is wrong with this code. The second model has no stake in the first one's choices and will name the problems the author talked itself past. There are ready-made review skills and tools built for exactly this. You do not need to write the code. You do need to be able to ask the right question about it, or to point a second opinion at it that will.

Guardrail 3: the happy path is not the feature

From a thread on shipping fast:

Tests? Error handling? Edge cases? Tired of seeing "launched in 48 hours" when it's really a weekend project with Stripe attached and zero error handling.

The demo works. Then the second user signs up, the empty state has no rows to show, a card gets declined, someone double-clicks the buy button, an upload is 200MB instead of 2MB, and each of those is a place the weekend version never considered.

Why it happens: AI writes to the prompt. "Build me checkout" produces a checkout that works when everything goes right, because that is what the words asked for. But a business does not live on the happy path. It lives in the failure paths. A declined payment that still grants access is not a bug you find later. It is revenue you never collect, repeated quietly.

The guardrail: make the agent write the failure paths explicitly, and make it prove them. What happens when the card is declined, when two requests arrive at once, when the user hits back mid-checkout, when a required field is empty. Ask for the tests that demonstrate those cases pass, and run them. Stripe ships test cards precisely so you can trigger a decline on purpose. Use them before a real customer triggers one for you.

Guardrail 4: decide the architecture once

A solo founder's post title, which I have thought about a lot since:

I'm a solo founder. It took me 9 months and at least 3 stack rewrites to ship my SaaS.

Nine months, three rewrites. Every rewrite threw away working knowledge and bought a new set of unfamiliar problems. This is not a discipline failure. It is what happens by default when the AI gets a vote on architecture every session. Obie Fernandez names the stakes exactly: "AI coding agents have made it impossible to pretend that architecture does not matter." Agents generate code faster than anyone can read it, so the only thing keeping the system coherent is a shape you chose on purpose and hold to. The agent will not hold it for you, because each session it has forgotten there was ever a shape.

Why it happens: the AI has no sunk cost. It will not defend a decision it made last week, because to it there is no last week. Ask it about your stack today and it will happily propose something newer, and the day you are tired or stuck, that fresh start sounds like progress. Without a founder holding the line, you churn.

The guardrail: pick the stack and the core nouns of your product once, write them down in plain language, and make every session work inside that decision. The nouns are the things your business is about: an Account, an Invoice, a Booking, a Subscription. Name them, and do not let them drift into a Customer here and a Client there and a User somewhere else. The thing you own as a non-technical founder is not the code. It is the set of decisions the code has to respect. Boring and consistent beats novel and churned, every time.

The other failure: guardrails on the wrong things

There is a second way this goes wrong, and it looks like diligence. Founders who do impose constraints often impose them on the cheap, visible things and leave the expensive, invisible ones open. Hours spent tuning the server size or picking the exact shade of the call-to-action button, while authentication and data boundaries go unreviewed. It feels productive because you can see the button. You cannot see the access control hole until it costs you a customer.

The rule of thumb is simple. Gate the things that are hard to reverse and expensive to get wrong: security, data access, payments, and the core data model. Do not spend your scarce attention gating the things that are cheap to change later: colors, copy, which screen a button lives on. You can move a button next week. You cannot un-leak a customer's data.

The master guardrail: keep the napkin

If you keep only one thing from this, keep this one, because it sits above the other four and it gets more important every week. You should be able to draw your whole app on a napkin at any moment. Not the code, the shape: the handful of core things it is about, how they connect, where the money moves and where the data lives. The four guardrails are really just ways of keeping that napkin honest. The boundaries are the lines on it you never let blur. Readability is being able to trace each line. The architecture is the napkin itself.

The day you can no longer draw it is the day the AI has taken the steering wheel, and you have quietly become a passenger in your own business. So redraw it often. And if the picture has grown too tangled to fit on a napkin, do not mistake that for sophistication. That is the sign you have lost the plot, and it is the cheapest possible moment to notice.

A five-minute pre-launch check

None of this requires you to become an engineer. It requires you to ask five questions and refuse to ship until each has an answer you believe.

Guardrail	The question to ask before you ship
Boundaries	Log in as two accounts. Can either see the other's data by changing an ID?
Readability	Can you say, in one sentence each, what your main screens and routes actually do?
Failure paths	Does checkout survive a declined card without granting access?
Architecture	Is there one written stack-and-nouns decision the next AI session has to respect?
Security	Has anyone who is not the AI that wrote it looked at the auth and payment code?

If you cannot answer one of these, that is not a reason to feel behind. It is the most useful thing you learned today, because it is the exact place a guardrail is missing.

The pattern under all of it: AI supplies capability, not judgment. The guardrails are the judgment, and the judgment is the founder's job. It is also the part of the work that compounds, because a founder who knows where the boundaries are gets faster and safer with every release, while a founder who does not gets a bigger and bigger pile of code they cannot see into.

If you want a second pair of eyes on what your AI agent shipped, the audits I run cover exactly these boundaries: where the access control holes are, whether the failure paths exist, and what the AI quietly changed that nobody reviewed. Two ways to start, both free.