Say an analyst writes a SQL script that scores call notes. It works. Two other teams ask for copies. Six months later, finance uses its output to true up bonuses, it runs off a laptop when someone remembers to run it, and nobody has looked at it since it shipped.
That’s the problem: code built outside the data team that the business now depends on, with none of the machinery production code normally gets. AI coding tools made it common. In Stack Overflow’s 2025 Developer Survey of 49,000 developers, 84% use or plan to use AI coding tools, and only 29% trust the output to be accurate. Those are professionals who review code for a living. The analyst’s script hasn’t had that review.
DataKitchen’s You Built the Thing. Now You’re Stuck Running It. puts building at about 20% of the work. Running it is the other 80%, and that part never ends.
The code isn’t the problem
The script usually works on the day it ships. What breaks it is everything around it. A column gets renamed and the dashboard fails silently. An API token expires every 90 days. A join quietly drops 3% of rows, and nobody finds out until someone is underpaid. A database password sits in plain text. None of that is a coding error. It’s missing machinery.
| Gap | What happens without it | What closes it |
|---|---|---|
| No tests | A join drops 3% of rows and the report still renders | Tests on inputs and outputs |
| No version control | Nobody can say which version produced last quarter’s number, and there’s nothing to roll back to | Git, with every change reviewed |
| No monitoring | A renamed column is found by a VP who already forwarded the chart | Freshness, volume, and schema monitors |
| Runs on a laptop | It runs when someone remembers | A schedule on the shared platform |
| Credentials in the script | A password in plain text, a token that expires unnoticed | Secrets held by the platform, owned by IT |
Why rebuilding is the wrong default
The post lays out three usual exits, and each one loses something. Keep running it yourself, and it fails in public during your vacation. Hand it to IT, and a careful rebuild arrives in 2027 doing less than what you have now. Pay an outside firm by the hour, and the code becomes theirs.
IT’s caution is earned. They get paged when it breaks and answer to audit. But a rebuild throws away the part that works, which is the business logic, to get the part that’s missing, which is the machinery. Add the machinery and keep the logic.
The test rule from The Seven Deadly Sins of AI-Generated Data Pipelines applies here too: an agent never grades its own homework. If AI wrote the code, a test written by someone else, or generated from the real data, has to check it.
Vibe to Prod
DataKitchen’s name for this is Vibe to Prod. The term borrows from vibe coding, building software by describing it to an AI tool and accepting what it writes. The service takes the code as it is. DataKitchen engineers fix what the AI got wrong, add tests, git, and monitoring, fit it into your Databricks or Snowflake, and run it. You keep a development copy and the right to change the logic with any AI tool. Changes pass the tests, get a quick review, and go live.
Everyone in data is about to spend 80% of their time talking to a language model explains why this gets bigger: once everyone can generate code, everyone will, and there’s no “promote to prod” button in a chat window. Somebody has to build one: tests, a review gate, and a promotion process.
It’s a paid service, run by the engineers behind DataKitchen’s AI data engineering work. The table above works without buying anything, if you have an engineer with the time. Most teams in this spot don’t, which is how the script ended up on a laptop.