Is vibe coding creating a hidden technical debt crisis?
Yes. The debt is not in the code the AI writes, it is in the infrastructure and ownership you never get. The app works in a sandbox you do not control, on billing you cannot predict, with no path to the cluster it runs on.
Last updated
Yes. The debt is not in the code the AI writes, it is in the infrastructure and ownership you never get. The app works in a sandbox you do not control, on billing you cannot predict, with no path to the cluster it runs on.
What is the hidden debt in a vibe-coded app?
The app works right now. That is the trap. You are paying $25-100/mo to Lovable or Bolt plus $20-59/mo for Vercel or Supabase, and the app answers on a URL. But the source is in a proprietary format or a visual builder's export, not a repository you could run anywhere. The runtime is a sandbox owned by the platform. Leaving means starting again. That is the debt: a working app with no path to owning the infrastructure underneath it.
The debt compounds when the app needs to change. A demo that later needs to take money is not upgraded in place. Payments and persistence reach into every part of the app, so it is rebuilt as the type it should have been. If you vibe-coded a demo and now need a product, you are paying for the rebuild in time and tokens, and the original build taught you nothing about what runs underneath.
Why does the debt stay hidden?
Because the app works. The failure does not appear until you try to leave, scale, or change something fundamental. The hosted builder absorbs the infrastructure complexity, so you never see it, and you never learn it. When the billing spikes or the platform changes its terms, you discover that the working app was never yours in the way that matters.
A real example of what hides underneath a running system: on this platform, Longhorn was configured with multiple replicas on what was a single node. The replication traffic and disk contention starved etcd until the control plane crash-looped and the cluster stopped responding. The fix is a rule rather than a setting: on a single node, one replica. Redundancy across replicas of the same disk is not redundancy, it is load. That kind of knowledge is what vibe coding in a sandbox never teaches you, and it is what bites when you finally own the infrastructure.
What happens when the debt comes due?
You try to deploy somewhere you control, and you discover the source is not portable. Or you try to upgrade a dependency and it crash-loops. On this platform, an image tag moved from Postgres 15 to 16. Postgres does not upgrade its data directory across a major version on start, so the container came up, refused the existing data, and restarted forever. The database is now pinned to its major version, and a major upgrade is a deliberate migration, never a tag change.
These are not theoretical. They are the cost of not understanding what runs under your app. In a hosted builder, you never see them because the platform absorbs them into its own incident log. When you own the cluster, you see them, and you fix them with a rule rather than a setting. If you want to understand why one-shotting the whole app is the fragile part, read /learn/why-one-shotting-your-whole-ai-app-is-the-fragile-part. If you are already feeling the pain of leaving a hosted builder, /learn/what-happens-after-my-lovable-plan covers the exit.
How do you pay down the debt before it is due?
You own the cluster from the first deploy. The app runs on K3s in a namespace that belongs to your account, deployed as a Helm release. The source is a real repository, not a proprietary format. You can join your own hardware to the cluster over a private network, and pods schedule onto it like any other node. Nothing about the runtime is invented here: Kubernetes, Helm, Postgres, Docker. Somebody who knows those knows this.
The blueprint step is where you catch the wrong assumption before it becomes debt. Before anything is built, the platform proposes an editable capability blueprint. A wrong assumption is cheap to fix there. After the build, it is not. That is the structural answer to hidden debt: make the assumption visible before the code exists, and make the infrastructure visible after it does.
my-app.engineer puts the app in a cluster you own from the first deploy. The source is a repository. The runtime is K3s, Helm, Postgres, Docker. The debt that comes from never owning the infrastructure does not accumulate here, because there is no sandbox to leave.