// AI Deep Dive
Rent the Factory, Own the Blueprints
Vibecoding platforms will build your app in an afternoon. The question that decides whether that was a good idea: who owns the process that keeps it alive?
EXECUTIVE SUMMARY
Vibecoding platforms promise software without engineers, and they mostly deliver it — for the first month. Then the app matters, something breaks, and the question changes from "can AI build this?" to "who owns what keeps it running?" This week's argument: the app was never the asset. The process that keeps software alive is — and that process comes down to four things you can name in plain words: a spec (one page saying what the app does), a repo (the place your code lives), a reviewer (a second AI that checks the first one's work), and tests (proof it still works after a change). Right now, most businesses are renting all four without reading the lease.
45 percent of AI-generated code samples carried flaws from the industry's most-wanted list of known security holes in Veracode's tests of more than 100 models — the raw material is fast, not clean. What separates a working app from a liability is everything that happens after generation.
The exits are not equal. Base44's export hands you the frontend while the database, login system, and business logic stay on its servers; Lovable syncs a full React and TypeScript codebase to your own GitHub, by its own account. Two platforms, one pitch, opposite answers on ownership.
The payoff lives in the process, not the generator. PwC's research on the agentic development lifecycle found teams applying AI across six or more lifecycle stages release nearly twice as often, with reported defect reductions of up to 96 percent.
Use the platforms for speed — but own the spec, the repo, and the review gates. The factory is the durable asset, not the app.
// The Hook
The Factory I'm Building on Nights and Weekends
For the past few months I've been building my own software factory. Not a product — a process. Every project I vibe-code now starts with a written spec, lives in its own GitHub repo, gets written by one AI model and reviewed by a different vendor's model, and doesn't ship until generated tests pass. It's unglamorous plumbing, and it has changed what I can trust myself to build.
I got here the honest way: I vibe-coded things that worked right up until they didn't. A tool would produce something impressive in an hour, I'd use it for three weeks, and then a change I couldn't inspect would break something I couldn't see. The demo was mine. The destiny wasn't.
I spent years in the open source world, and the durable lesson from that era wasn't that anyone can contribute code — it's that process is what makes strangers' code trustworthy. Linux didn't win because its code was magically better. It won because of how changes got proposed, reviewed, tested, and merged. The code was the output. The process was the invention.
So when I look at today's vibecoding platforms, I ask the process question first. I don't want to reinvent the wheel — GitHub exists, testing exists, review exists. But I do want to own my own destiny, and that means the assembly of those parts has to be mine. If a one-person publishing operation is asking these questions, a company with customers and compliance obligations can't afford not to.
// The Deep Dive
Rent the Factory, Own the Blueprints
The conventional wisdom has settled fast: vibecoding platforms are how business software gets built now. Describe the app, watch it appear, click deploy. The platforms are genuinely good at this, and the market has responded — every week another team ships an internal tool that would have sat in an IT backlog for two quarters.
But two different questions are being answered as if they were one. "Can AI build your app?" — settled, yes. "Should the platform that built it own your software's entire life?" — barely examined. The first question is about speed. The second is about those four unglamorous things — the spec, the repo, the reviewer, the tests — that determine whether software survives contact with month two. And one sentence to hold onto before the numbers start: none of this requires you to write code. Every step below is a checklist, and the agents handle the technical parts.
What the platforms actually sell
A vibecoding platform compresses all four of those things into a chat box. That's the convenience — and it's real. It's also the catch, because what disappeared into the box wasn't just complexity. It was your visibility into how the software gets made, checked, and changed. I learned this the annoying way, and the costs show up at three levels.
For the individual builder, generation without inspection means shipping unreviewed code by default. Veracode's testing across more than 100 models found 45 percent of AI-generated code samples carried flaws from the industry's most-wanted list of known security holes — not exotic attacks, the kind every professional checks for first.
For teams, the volume compounds. GitClear's analysis of 8.1 million pull requests found technical debt rising 30 to 41 percent after AI coding tools arrive, with code duplication running at four times historical rates. Generation got fast; review capacity didn't.
For the organization, it's an ungoverned attack surface growing at enterprise scale. A Cloud Security Alliance research note reports a scan of 5,600 production vibe-coded apps in which not one had the standard safeguard against one of the oldest tricks on the web — a malicious site piggybacking on a user's logged-in session — and counts officially cataloged security flaws in AI-generated code rising from 6 in January to 35 in March of this year.
Renting vs. owning, stage by stage
Think of it like housing.
Stage 1 — The furnished apartment. For a demo, a landing page, an experiment, the walled garden is the right answer. The platform owns everything and that's fine — exit cost is zero because there's nothing to take.
Stage 2 — The app starts to matter. Real users, real data, a workflow that breaks when the app does. This is where moving day stops being theoretical.
Stage 3 — Moving day: the exits diverge. Base44 will export your React frontend — and not the database, login, or business logic that make it work. Run the export and you get what that analysis calls a pretty shell: the furniture, not the plumbing. Lovable, by contrast, syncs a standard React/TypeScript codebase to your GitHub with two-way sync — a vendor-authored claim, but an architecturally different promise.
Stage 4 — Process becomes the product. Forrester's read on agentic software development is that leading organizations now treat AI-generated code with the same or higher rigor as human-written code, developers spend more time reviewing and orchestrating than typing, and the spec drives the work. Even approvals are going machine-speed: Anthropic made autonomous operation the default in its coding tool after its automated safety screens caught 89 percent of deliberately dangerous commands versus 13.6 percent for fatigued human reviewers.
What leaves with you on moving day | Walled-garden platform | Code-first platform | Your own factory |
|---|---|---|---|
Frontend code | Yes | Yes | Yes |
Backend and data | No | Mostly | Yes |
The process — spec, review, tests | No | Partially | Yes |
Building your factory without reinventing it
Remember the promise above: checklists, not code. Each phase below took me an evening or less — and when I got stuck, I had an agent walk me through the step.
Phase 1: Own the artifacts (this week).
Ownership starts with possession — cheap, boring possession.
Create a GitHub repo for every AI-built app you're running, and connect it from the tool you build in
Export everything exportable today; write down what isn't — that list is your exposure
Write a one-page spec per app: what it does, who uses it, what data it touches
Phase 2: Install the checks (this month).
The quality gates are the factory's whole point, and the evidence says they're cheap.
Route every meaningful change through a second model from a different vendor — pairing two models cut error rates from 14 percent to under 4, with humans reviewing only the 13 percent of cases where they disagreed
Require generated tests alongside generated code, and run them before anything deploys
Never let the writing model review itself — when two models are both wrong, they pick the same wrong answer 50 to 71 percent of the time, so cross-vendor disagreement is the signal worth paying for
Phase 3: Decide what you rent (every quarter).
Renting is a strategy when it's priced. Make it a decision, not a drift.
Keep platforms where exit is cheap: prototypes, internal tools with exportable code
Put a review date on every platform dependency — retire, replace, or knowingly keep
Run the moving-day test once a year: could you redeploy this app without the platform? If no, that's a priced risk, not a surprise
The success factors are the same four every time: the spec exists before the code, a different vendor's model does the review, the repo is the source of truth, and moving day gets priced before adoption — not after the hundredth prompt.
Common Missteps
Confusing the demo with the deed. Every platform's first hour is magical — that's the sales motion. Ownership only gets tested on moving day, so test it in week one, while leaving is still cheap.
Building the factory from scratch. The opposite error. You don't need to invent version control, testing, or review tooling — GitHub and generated tests exist. Own the assembly, not the machine tools.
Letting the model grade its own homework. Same-model review feels like rigor and measures almost nothing — correlated errors pass their own inspection. The reviewer must come from a different vendor, and unanimous agreement on high-stakes output still earns a human spot-check.
Treating the platform as the villain. Rented speed is legitimate — the furnished apartment is the right choice for real categories of work. The failure isn't renting; it's renting without pricing the move.
Key Takeaways
Ask the moving-day question before the first prompt. What leaves with you — code, data, backend, process? Base44 and Lovable answer it in opposite ways, and neither answer is on the pricing page.
Assemble the factory from parts you already own. A GitHub repo, generated tests, and a second model's review cover most of the lifecycle for close to free. Don't rebuild the machine tools; own the assembly.
Make a different vendor's model your reviewer. Two wrong models agree on the same wrong answer up to 71 percent of the time. Disagreement between vendors is the cheapest error map you can buy.
Judge every tool by the maintainer it leaves behind. The goal isn't software built fastest — it's software the people who understand the business can still safely change a year later.
// What This Means for Your Planning
In planning terms: your company already has a second software portfolio. It's the apps your people built by describing them — and it's growing faster than the official one. Treat it the way you'd treat any portfolio: inventory it, know where each app's code and data live, and know what it would cost to move.
The boardroom assumption to challenge is "we'll standardize on a platform and the platform will handle it." Platform selection is a line item. Process ownership is the decision. A platform can genuinely accelerate you and still be the wrong place to store your company's operational knowledge — those are separate evaluations, and the second one rarely gets run.
For the next budget cycle, the factory is nearly free and the exposure isn't: repos cost nothing, cross-model review costs pennies per change and buys near-elimination of a double-digit error rate, and generated tests come with the code. Fund a quarter-long pilot: pick five vibe-coded apps that matter, move them through the three phases above, and measure two things — hours to pass each app's moving-day test, and defects the second model caught before users did.
Then bring this question to the next technology review: if our vibecoding platform disappeared on Friday, what would we still own on Monday — and who here could keep it running?
