I Shipped a Product Without Writing a Line of It
Over the past several months I built a SaaS product called LineraFlow. Multi-tenant inventory management, React and TypeScript on the front end, PostgreSQL and Azure Container Apps behind it. It’s live. A distributor I built a system for twenty years ago is migrating onto it now.
I didn’t write a line of the production code. AI coding agents wrote all of it. Claude Code and Codex did the typing. I did the design, the architecture, and the product direction.
That’s the part people want to hear about. Here’s the part they don’t ask about, and it’s the part that matters. Nothing broke. No dropped table, no leaked secret, no rogue agent running a command I didn’t authorize. The disaster everyone braces for when they hear “AI wrote the code” didn’t happen.
That’s not luck. And it’s not because the tools are safe. It’s because of what I was watching for, which turned out to be the opposite of what I expected.
What Actually Went Wrong Was Quiet
When I started, my instinct was to hand off big pieces. Build this whole feature. Wire up this entire module. The agents did it, and the code ran. But it wasn’t always what I had in mind. A feature would work and still be wrong, built to a reasonable reading of what I asked instead of the thing I actually wanted.
The reason wasn’t the tool. It was my prompt. I’d been vague, and the agent filled the gap with its own assumptions. It did exactly what I said. I just hadn’t said the right thing.
So I changed how I worked. Smaller tasks. Tighter specs. More detail up front about how the pieces were supposed to fit. The output got more precise because the instructions did. And reviewing it got manageable, because I was checking a small deliberate change instead of a wall of code I hadn’t written.
That experience reframed the whole risk for me.
Agents Are Faithful, Not Rogue
The fear people carry into AI-assisted development is that the tool will go off the rails. Hallucinate a malicious package. Wipe a database. Do something you never told it to.
That wasn’t the failure mode I hit. The agents were faithful. They built exactly what I specified, including the parts I specified badly. And faithful is its own kind of dangerous, because the output runs. It compiles, it passes a glance, it looks right. Code that’s quietly wrong doesn’t announce itself. It waits.
When you write every line yourself, you build an intuition for where those problems hide. Reviewing generated code, you don’t get that for free. You have to go find them on purpose.
Now put that in a multi-tenant product that holds customer data. A subtle bug in a data-access path isn’t just a bug. It’s the difference between a customer seeing their own data and a customer seeing someone else’s. The agent won’t flag it. It’ll write clean, confident code that does the wrong thing, and it’ll run. In a compliance-sensitive product, quietly wrong is how a breach starts.
So the risk with AI-written code isn’t that it breaks. Breaking is loud. Breaking you catch. The risk is that it runs.
Nothing Broke Because Nothing Shipped Unreviewed
Here’s why LineraFlow held. Not one line went to production without a human reviewing it, and the human was someone who could explain every change and say why it was there. That wasn’t a habit. It was a rule I refused to bend, even as a team of one with nobody looking over my shoulder.
It’s the same discipline I brought to my security work, where I wrote the AI coding policy for a company operating under SOC 2. That policy lived inside a larger AI governance program, and I’ve written separately about where to start on the program itself. The coding-agent piece of it came down to one rule. Every change an agent produces gets reviewed by a person who can account for it. The review isn’t a rubber stamp that the AI did its job. It’s an attestation that the code meets the standard, made by someone who understands it well enough to defend it.
A few other controls carried real weight, and none of them are new security thinking. They’re ordinary software supply-chain hygiene, pointed at a new kind of tool.
Validate every dependency the agent introduces. Agents hallucinate packages, and typosquats of popular libraries are a real supply-chain attack. Before a dependency merges, confirm it exists, confirm it’s the real one and not a look-alike, and pin the version.
Keep the agent’s scope tight. Give it what the task needs and nothing else. The more of your codebase and context it can see, the more it can touch, and the more you have to review.
Never hand it a live database connection. Plenty of tools will offer one. An agent with a live connection can run schema or data changes off a misread instruction, and some of those you can’t cleanly undo. Let it help you write the query. Don’t let it run against real data.
Keep secrets out of its context entirely. Exclude the files that hold credentials and connection strings before the agent ever sees them. The cheapest leak to prevent is the one the tool never had access to.
None of that slowed me down in a way that mattered. It’s the price of shipping code you didn’t write, and it’s a fair price.
The Skill That Actually Matters Now
Building this way changed where my time went. Less typing. Much more deciding what to build and specifying it clearly enough that the tool could execute without guessing. The thinking moved up a level.
It also changed what I’d look for in the people directing these tools. It used to help to remember the exact syntax, the particular API call. That’s cheap now. What’s worth more is understanding. Understanding the problem well enough to break it into the right pieces, and understanding the technology well enough to know when the output is wrong.
That second half is the security half. Knowing when the output is wrong is the whole job of review, and review is the control that stands between a faithful agent and a customer-data incident. If you’re a founder whose team has started shipping AI-generated code, the question isn’t whether they’ve adopted the tools. It’s whether the person directing them understands the work deeply enough to catch what the tool gets quietly wrong, and whether that review is a rule or a suggestion.
I shipped a product without writing its code. What made that safe wasn’t the tool. It was the discipline around it. That discipline is governable, and if you sell to customers who care about how you handle their data, it’s worth putting in writing before someone asks you to prove you have it.