The gap generation tools leave open
Lovable, v0, Bolt — they all solve the same problem: go from idea to something visible in minutes. And they're good at it. You describe what you want, the tool generates code, and you see a working UI in your browser.
The problem is what happens next. The generated code is a single-file monolith with inline styles, no tests, no separation between business logic and presentation, and dependencies pinned to whatever version the model was trained on. It works as a demo. It does not hold as a product.
This isn't a criticism of those tools — they're prototyping tools, and they're excellent at prototyping. The mistake is treating their output as production code.
The gap generation tools leave open is not speed. You can't outrun Lovable on speed, and we don't try. The gap is: who checks the work, who signs it, and what trail exists when it breaks?
By default, the answer from Lovable is: no one, no one, and none.
8,000 commits to main
Open a Lovable project's git history running on default settings. You'll find hundreds or thousands of commits from lovable-dev[bot] directly on main — no review step, no authoring human. Lovable does support branch creation and GitHub sync, and you can open a PR if you opt into that workflow. But the default is straight to main, and Lovable has no built-in code review of its own. Review is on you, via GitHub, if you remember to set it up.
Each commit is the tool rewriting large sections of the codebase to accommodate the next prompt. This isn't version control — it's an undo stack. You can't git bisect it. There's no provenance tying a change to a source, a passing test, and a human who signed it. If something breaks in production, you're searching a wall of AI-generated diffs with no rationale.
We work differently. Every change is a branch. Every branch has a PR. Every PR has a provenance trail showing what changed, why, and which verifiers ran. A human engineer reviews and signs it before it merges. The git history reads like a log of decisions, not a stream of consciousness.
Here is what a signed commit looks like when it lands: auth/session.ts · +14 / −9 · commit a2c91 · signed by an engineer who reviewed it. The diff is cited against nextjs.org cookies() docs, verified against the OWASP cookies cheatsheet, tested by session.spec.ts (4/4 pass), and pinned to next@14.2.5 and iron-session@8.0.3. Trail archived at /launches/2026-05-14/2a91 — re-run any check months later.
This is what a merge-able commit looks like. Not because we require ceremony — because this is what lets you answer "how do you know this works" when someone asks.
Architecture from day one
Vibe-coded projects start with no architecture. The tool generates whatever structure makes the current prompt work. By the time you have ten features, you have ten different patterns for doing the same thing.
We start with the architecture: the right folder structure, the right patterns for your stack. API routes separated from business logic. Database access behind a proper data layer. Configuration externalized. Error handling consistent. Not because we love ceremony — because this is what lets you ship changes six months from now without breaking things.
The developer agent enforces this. It won't generate a database query inside a React component. It won't put business logic in an API handler. It won't inline environment variables. These aren't style preferences — they're engineering constraints that keep your codebase workable as it grows.
Separation of concerns
In a vibe-coded project, the UI component fetches data, transforms it, handles errors, manages state, and renders — all in one function. It works until you need to change any one of those things without breaking the others.
We build with proper layers. Presentation knows how to render. Business logic knows the rules. Data access knows the database. Each layer has a clear contract with the others. Swap your database without touching your UI. Redesign your frontend without rewriting your API.
This is basic software engineering. The reason generation tools don't do it is that it's harder to generate — you need to understand the system, not just the current prompt. Our agents understand the system because they read your codebase before they write.
Tests are not optional
Lovable generates no tests by default. It can write frontend (Vitest/RTL), edge, and browser tests on request — but its own docs say test verification "runs only when you ask." v0 generates no test suite. Cursor will write tests if you ask, but not by default. The result in every case: code that works right now and no reliable way to know if it still works after the next change.
Our developer agent ships every function with tests — not because tests are virtuous, but because tests are how you know your code works after the next change, and the change after that, and the dependency update six months from now. CI runs on every push. If they fail, the change doesn't merge. That's the difference between it works on my machine and it works, and here's the proof.
The test suite is also a verification surface. When the agent makes a change, it runs your existing tests first. Failures surface in the provenance trail. The change does not ship. The last signed merge on midnight-mvp: 24 tests pass · 0 failed · 380 ms.
Infrastructure included
Lovable Cloud is managed: auto-deploys, SSL, global CDN, and a real Supabase integration out of the box. For prototyping, that is genuinely useful. The documented constraint: Lovable Cloud cannot be self-hosted or run inside your VPC. You cannot bring your own Kubernetes, add your own observability stack, or configure your own CI/CD without leaving the integrated platform entirely. The exported app (Vite + React + Supabase) can be moved to GitHub and hosted elsewhere — but at that point you are no longer using Lovable's integrated environment, and the ops burden shifts entirely to you.
Every launch.ist project runs on isolated Kubernetes — your own namespace or dedicated cluster. GitOps (push to deploy), CI/CD pipelines, Postgres, Valkey, MinIO, Grafana observability, TLS, and backups. From $59/month. The infrastructure is yours. You are not a tenant on a shared platform.
The DevOps agent provisions all of this. You bring your domain. We handle the rest. Your project is production-grade from the first deploy, not after a painful migration months later. If it breaks at 2am, the monitoring tells you what happened — not your users.
The humans own the outcome
We're not a wrapper around a language model. We're a development agency — engineers who've shipped production systems for banks, startups, and infrastructure companies. The agents are our tools, not our product.
When we say the code is production-quality, the claim is checkable: the trail shows the sources cited, the versions pinned, the CVEs scanned, the SBOM-verified licenses cleared, the tests that passed, and the engineer who signed the merge. You can re-run any check months later to detect drift. The provenance outlives the run.
Generation tools generate and walk away. We sign and stay.
The right path to production isn't the fastest path. It's the path where you don't have to rebuild everything when you get your first real users.
Generation tools generate and walk away. We sign and stay.