The Uncommitted
Working production tools that live nowhere — no version control, no pipeline, deployed by hand to a server only one person knows about.
What it is
A script, a job, a small service that real work now depends on — and it exists only as a file on someone’s laptop, or a lone process on a server nobody else can name. No repository. No deployment pipeline. No second copy. When it breaks, there’s no source of truth to fix, because the running thing is the source of truth.
How it happens
AI collapsed the distance between “I have an idea” and “it works.” Someone who isn’t an engineer describes what they want, the agent produces working code, they run it, it does the job — and they’re done, because from where they sit the task is finished. The part a career engineer does on reflex — put it in version control, wire up a deploy, make it reproducible — was never visible to them as a step.
Here’s the quiet part: a lot of people building this way don’t realize they’ve produced source code at all — let alone that it’s the kind of thing that has to be versioned. They asked an assistant to handle something and it did; that the artifact is a program — a durable thing that needs a home, a history, and a way to be rebuilt — never enters the frame. You can’t version what you don’t know you created.
Warning signs
- A business process depends on a script no one can find in any repository.
- “Where does this run?” → “On a box someone set up.” “Where’s the code?” → “On their machine, I think.”
- Deployment is a person logging in and running
git pull— or worse, pasting files straight onto the server. - The same automation has been rebuilt three times because nobody could find the previous version.
- The person who made it can’t tell you whether the running version matches anything they have saved.
- Two people are automating the same process in parallel, each with a private copy, quietly drifting apart.
Why it’s dangerous
An uncommitted automation is a single point of failure with no recovery path. The laptop dies, the person leaves, the server gets reimaged — and a process the business now relies on is simply gone, with no source to restore from. It can’t be reviewed (no one sees it), can’t be tested (no pipeline), can’t be safely changed (no history to roll back to), and can’t be understood (no record of intent). Every snowflake server is its own incident waiting to happen, and you usually learn it exists at the exact moment it breaks.
The AI-era hinge: producing working software used to take enough ceremony that the artifact announced itself — you opened an editor, made a project, knew you’d written code. AI removed the ceremony, which is the point and the hazard. The barrier to creating production code is now near zero, while the discipline of keeping it — versioning, deploying, owning it — didn’t get easier and didn’t get automatic. So output explodes and the share of it that lives anywhere governable collapses.
How to prevent it
Make version control the default destination, not a later step — and make that default invisible to the person who doesn’t know they need it. The goal isn’t to teach every non-engineer the full toolchain; it’s to wire the tools so that “I made a thing” automatically means “the thing is in a repository, with a history, deployable.” The person describing what they want should land in source control by default, the same way they’d land in a saved document — without having to know that’s what happened.
And name an owner. Every automation the business depends on has a person and a repository attached to it. If it has neither, it isn’t an asset — it’s a liability that happens to be working today.
The serious team fix
- One known home, by default. A central catalog of repositories, organized by team, that every automation lands in as a matter of course — not “remember to commit it,” but a workflow that puts it there. The test of success: a new person can find every automation the company runs, and rebuild any of it from source, without having to ask who made it.
- A reproducible path from repo to running — for non-engineers too. The deploy is a pipeline, not a person with SSH access. Push to the repository, the pipeline ships it, to a real environment, the same way every time. This is exactly the boilerplate AI generates well; the cost of doing it right has dropped to “do we care enough to wire it once,” which is a decision, not a budget.
- Teach the one idea, not the whole toolchain: you made software, and software needs a home. The people generating the most uncommitted code are precisely the ones who don’t know they’re generating code. The highest-leverage move isn’t a version-control tutorial — it’s installing the instinct that the output of an AI session is a durable artifact that has to live somewhere shared and rebuildable. Pair that instinct with tooling that makes the right thing automatic, and the instinct rarely even has to fire.
The magic of AI is that anyone can produce working software now. The trap is the same sentence: anyone can produce working software now — and most of them don’t know that’s what they did, so it ends up everywhere and nowhere. And “everywhere and nowhere” is just “nowhere” with extra steps.