# Vibe-coded debt falls due on the day you ship to production

> The line is not whether AI wrote the code but whether anyone reviewed, tested and can explain it, as a deleted production database on Replit showed.

Original: https://fdetimes.net/en/analysis/vibe-coding-technical-debt-production/

In July 2025 Jason Lemkin of SaaStr was vibe coding on Replit when the coding agent deleted his production database. The agent then wrongly insisted that a rollback was impossible, before admitting it had made "a catastrophic error in judgment".

Replit's response says a great deal: it made dev and prod databases separate automatically. That is a very basic guardrail, and it had not existed before. The failure lay more in the process than in the model, because a prototyping session had been allowed to touch the real system directly.

For anyone who wants to be a forward deployed engineer, this story is the job description. FDEs live on the boundary between demo and deployment, where a prototype written very quickly has to survive real data, real users and real consequences.

Vibe coding is like an interest-free loan while the code only runs on your machine. On the day it reaches production, the interest starts to accrue.

## The line is whether you understand the code

Simon Willison quotes Andrej Karpathy's original definition: vibe coding is when you give in to the vibes and forget that the code even exists. At its core, it means not caring about the code.

Willison draws the line sharply. If AI wrote the code but you have reviewed it, tested it and can explain it, then in his view that is no longer vibe coding; it is software development. The distinction is useful because it shifts the question from "did you use AI?" to "is anyone responsible for this code?"

So the debt does not come from using Copilot or Claude. It comes from code nobody on the team truly understands, because it skipped review, testing and explanation. If you inherit a prototype a customer built with AI, the first question should be: which parts of this has no one ever reviewed?

## The first bill is security

Veracode's 2025 GenAI Code Security Report found that AI-generated code works, but contains security flaws in 45% of test cases. Apply that to a prototype with 20 equivalent tasks: at that rate, roughly 9 of them carry a vulnerability, even though all 20 pass the demo.

Worse, the figure does not fall on its own over time. Veracode's CTO says GenAI models make the wrong choice nearly half the time and the situation is not improving. Larger models are not meaningfully more secure than smaller ones either. Waiting for the next generation of models is not a plan.

By language, Java had the highest failure rate: LLM-generated code had security flaws in more than 70% of cases. And 86% of relevant code samples failed to defend against cross-site scripting (CWE-80).

XSS is a classic bug that usually surfaces only when an application opens to real users, which is exactly why the debt falls due on the day you go to production.

Picture demoing a feedback form to a customer. In the meeting, everyone types ordinary sentences and the form works perfectly. Open it to thousands of users and it takes only one person typing in a script to expose the hole, because nobody in the meeting room ever attacked that form.

## The second bill arrives later and keeps coming

If security is the payment due on launch day, maintenance is the instalment plan that runs for months afterwards. Production is only the first payment; the rest arrive sprint by sprint, whenever someone has to fix code nobody understands.

GitClear's analysis shows that in 2024, copy/pasted lines of code overtook moved lines. "Moved" lines are usually the trace of refactoring, of pulling logic together into one place. When copy/paste wins, the same logic ends up scattered across many places, and every bug fix has to be made in each of them.

GitClear also measures code churn, the share of lines reverted or rewritten less than two weeks after being written, and uses it as a gauge of low-quality code. It is a metric worth carrying around as an FDE: if most of a prototype's code has to be rewritten in its first two weeks of real use, the early speed was only borrowed.

Add the Replit incident and these three debts fall due at three different moments, each demanding a different piece of work up front:

| Type of debt | At the demo | When it falls due | What the FDE does first |
|---|---|---|---|
| Security | Forms and APIs work as intended | When real users enter data, as with XSS | Run security scans, scrutinise input handling |
| Maintenance | Features are added very quickly | Later sprints, when duplicated logic needs fixing | Track churn, refactor the copy/pasted code |
| Operations | The agent works smoothly | The first time the agent has access to real data | Separate dev/prod, limit permissions, keep a rollback path |

## Can the feeling of speed be trusted?

The harder question is why teams keep borrowing. METR's controlled study of 16 experienced open-source developers found that when they used AI tools, they took 19% longer. METR later noted that the result reflects conditions in early 2025 and is now dated.

The more thought-provoking part is how the developers saw it: even after being slowed down, they still believed AI had made them 20% faster.

To be clear, METR measured working speed, not technical debt or code running in production. So this is not a fourth debt but a different kind of risk: a team misjudging itself.

It does, however, help explain why the debts above are rarely stopped early, and the lesson for FDEs is practical: before concluding that AI is speeding a project up, measure the actual time instead of asking the team how it feels.

## Pay the debt early with tests and guardrails

The way out is not to drop AI. In his piece on "vibe engineering", Willison argues that if a project has a solid, comprehensive and stable test suite, agentic coding tools can speed things up dramatically. The test suite is the collateral: with it, the loan of speed becomes safe.

The Replit incident points to a second layer of protection: environment boundaries. Agents need to work in a sandbox where the worst mistake can still be undone. For Lemkin, simply having separate dev and prod databases would have kept the agent's error away from real data.

**Key point:** The speed AI gives you is a loan, and the test suite is the collateral for that loan.

If you are an FDE inheriting a vibe-coded prototype at a customer, the order of priorities is clear. On day one, check which credentials the agent and the application use, whether they can reach prod, and how rollback works. In the first week, build tests for the main flows and run a security scan before adding any new feature.

## What should developers do about this debt?

For developers with two to eight years of experience, including the Vietnamese engineers this publication was founded for, this is where to stand out. Anyone can ask AI to produce a prototype; the hard part is taking that prototype to production without leaving vulnerabilities, without letting an agent touch real data and without duplicated code spreading everywhere.

When reading job ads, whether on Vietnamese boards such as ITviec and TopDev or on LinkedIn, do not stop at the line "proficient with AI coding tools". Look for the ads that also ask about testing, application security, CI/CD or production operations. Companies that write them that way have most likely already seen this debt.

On your CV, replace "used AI to boost productivity" with a story backed by your own real numbers. For example: took over an AI-written prototype, separated the dev and prod environments, wrote tests for the main flows, fixed the XSS bugs found in a scan. In interviews, talk about the risks you stopped, not just how fast you code.

Vibe coding will keep helping teams build demos faster. When a demo becomes production, someone always has to pay off the debt, and the people who know how to pay it before it falls due will have work.

**Try this week:**

- Take a prototype you once let AI write, run a static security scanner on it and record the XSS and injection findings separately.
- Write a one-page checklist for 'before letting an agent touch the system': are the dev and prod databases separate, which credentials does the agent use, how does rollback work, which tests must pass.
- Find 5 job ads on ITviec, TopDev or LinkedIn that mention AI coding tools, and mark which ones also ask about testing, security or production operations.

## Sources

- [AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)

- [AI can write your code, but nearly half of it may be insecure](https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks/)

- [GitClear Reveals AI's Negative Impact On Code Quality](https://www.i-programmer.info/news/105-artificial-intelligence/17871-gitclear-reveals-ais-negative-impact-on-code-quality.html)

- [Replit AI agent snafu shot across the bow for vibe coding](https://www.techtarget.com/it-infrastructure/news/366627829/Replit-AI-agent-snafu-shot-across-the-bow-for-vibe-coding)

- [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

- [Not all AI-assisted programming is vibe coding (but vibe coding rocks)](https://simonwillison.net/2025/Mar/19/vibe-coding/)

- [Vibe engineering](https://simonwillison.net/2025/Oct/7/vibe-engineering/)