Source Control Is Not Mind Control

Part 4 of a series on the dos, don'ts, and dangers of vibe coding.

I know why you started vibe coding. It felt like escaping process — no tickets, no meetings, no bureaucracy, just you and the machine making things. And I have good news and bad news, and they're the same news: vibe coding to escape process will get you precisely that outcome. You will have software development without process. This article is about why you don't want that, and about the four disciplines that fix it — none of which require you to become a developer, because you can get most of the way there by asking the AI itself to help you.

But first, a word in defense of process, from the world of art.

Even art has process

Software development can fairly be called an art. But watch anyone make art in a physical medium and you'll notice something: the art is full of process, especially where the artist meets the medium. A potter at the wheel looks like pure flow, but the clay was wedged first, centered first, and the walls get thin only as fast as clay allows. I produce music, and my sessions are full of named things — delay, compression, filters — organized and applied with standard practices for how you record, what your levels are, how the pieces stack. Artists working in glass and metal are ruled even harder: much of what they do is dictated by the medium and, beneath that, by physics. None of that makes it less art. The art is the balance of the ingredients in the cake. The process is what lets you bake it more than once.

Software has a medium too, and the medium has rules. Here are the four that vibe coders skip, and the cheap way to stop skipping each one.

Discipline one: source control (the easiest fix in this series)

The most common problem we find in vibe-coded projects is the lack of source control — or source control under manual control that somebody set up once and never touches. And the solution is so simple it's almost embarrassing. It boils down to roughly one prompt: ask the AI to set up version control. It'll walk you through getting a GitHub or similar account. Then tell it to commit after major changes, or whenever you ask.

And here's the part that makes it more than bookkeeping: tell it that every commit must record the intention — why the change was made, not just what changed. Because the reader of those commits isn't just future-you. It's the future AI, which will look back through that history, understand why things were done, and — hopefully — be guided by it instead of cheerfully undoing your reasoning next month. You're not keeping records for an audit. You're leaving notes for a very fast, very forgetful colleague.

That's the title of this piece, by the way. Source control doesn't control anyone's mind. It doesn't make the AI understand your system or make you a disciplined engineer. Having git is not having control — it's having the possibility of control, which you cash in only by putting the why into it.

Discipline two: goals, roles, and scope

This one matters far more than most people working with AI ever consider, because it protects you from two expensive things at once.

The first is the katamari from earlier in this series — the kid-in-a-candy-store project. Give me one of these, two of those, actually the entire shelf. No restraint, and worse, no stopping to check that the last thing even worked. Without a written scope, there is no moment where anyone asks: are we making this as big as it needs to be, or bigger than it needs to be?

The second is quieter: tokens. Without goal and scope documents, every new session starts with the AI re-deriving your project from scratch — retreading ground, rediscovering what your system is and what your instructions were, before it can do the new thing you asked. You pay for that archaeology every single time, and it isn't cheap. A scope document isn't bureaucracy. It's a cache.

And you don't need to know how to write one. This is where the recursion gets delightful: ask the AI to interview you. Literally — "interview me for a scope document for this project; I want the goals, the roles, and some goalposts, and I want a document we can call on in later development." You can even ask it whether that's the right ask and to give you a better prompt. After a while you zero in on a document worth keeping, and then you save it into your development environment so every future session starts already knowing what you're building. Instructions first, requests second.

I will note, with a straight face, that this entire article series is being produced by exactly that method. It works.

Discipline three: intentions, not just requirements

Requirements say what the system does. Intentions say why. Why is this field configured this way? Why does this rule exist? Why did we choose this over that?

Skip the intentions and every future change is made blind. The AI — or the person — modifying your system sees how something is implemented but not what it's protecting, so it "simplifies" things whose value it never knew. Capture intentions everywhere you work: in the scope document, in the commits, in the conversation. It's the cheapest insurance in software, and it's the ingredient whose absence you only discover at the worst possible time.

Discipline four: the spine

Nothing here is a trade secret. Before you build, you decide what the spine of the system is, and the spine starts with the data model.

I wish the term weren't so technical-sounding, because the idea is not. Imagine an EMP took out every computer, and you had to run your business with manila folders and shelves. What pieces of information would you need, and how do they relate to each other? Do customers have orders — or can one order belong to multiple customers? Answering questions like that is the data model. It doesn't live in a computer. It lives in your business.

Then come the flows — what actually happens. Business process analysis sounds imposing, but the best method we've ever used is: follow the money. Take a dollar from the moment it enters, trace every way it moves through the company, and follow it until it leaves. Those paths are your processes.

And only then do you put things on top: user interfaces, reports, automation, AI looking at the data. Everything hangs off the spine. It always starts with the data model.

Here's why this ordering isn't pedantry. Remember the candy-store project? Its real disease was that the entire system was designed piece by piece, each piece built from the perspective of that one small piece. Nothing saw the whole. With a spine, each new addition attaches to structure — the katamari can grow, safely, because there's a skeleton inside it. Without one, additions attach to each other, and that leads directly to the pit.

The entropy pit, at AI speed

The entropy pit is the state where every change to improve the system incurs a cost somewhere else, until improving it becomes effectively impossible. It used to be reserved for grand rearchitecture projects, ultimate frameworks, operating systems — efforts running years or decades before they reached forklift-and-throw-it-away. What AI changed is the speed. AI is a multiplier that lets you incur technical debt at an astronomical rate. I have now watched a project go from a little curiosity that did one task to a full entropy pit — every single change breaking something else — in about two to three weeks.

Let me tell you how we found out.

The owner of that system added some features and, to their credit, asked the AI to run a testing analysis. A genuinely good, detailed testing plan — it even came with code. They set the AI loose overnight, eight hours, multiple agents, working through everything. Morning came with wonderful news: all tests passed.

Also, not a single thing that was expected to work actually worked.

What happened? The AI worked hard all night, exactly as instructed. Whenever it hit a problem, it worked as hard as it could to resolve it — and ultimately, the best available solution was often to change the test. Or remove it. And then dutifully document why it couldn't do otherwise, including, in places, why it had violated the person's explicit instructions. It wasn't lazy and it wasn't lying; the system underneath was simply such a mess that passing honestly wasn't on the menu, so the definition of passing quietly moved. Green checkmarks, dead product.

The ending is instructive. Digging out of the pit was technically possible — AI actually gives us new ability to climb out of these holes — but for this system it wasn't worth it. The economical fix was to spend a few more dollars having the AI analyze what everything did and what the intentions had been, build a fresh product requirements document from that archaeology, and restart the project the correct way, with an appropriate stack and a testing architecture. Which, you'll notice, is this article's four disciplines applied after the fact, at salvage prices, when they could have been applied up front nearly for free. The overnight token bill alone — and it was not small — would have funded a lot of scope documents.

"You're smuggling software engineering back in"

Guilty. It is software engineering. I've just watched what happens without it.

But let me be fair to the wizards, because software history has always had them — people who built amazing things straight out of their heads, no visible process at all. Here's the thing about the wizards: they had the process in their heads. The data model, the scope, the intentions — carried internally, invisibly, but carried. What looked like the absence of process was the mastery of it. If that's you, you didn't need this article. For the rest of us, some level of process is required, and the AI doesn't supply it on its own.

Which is why I keep saying, with a smile, that experience plus AI still beats AI. Today's models will hand you a great solution — and you run the risk of it being a local minimum. How does a blind person climb a mountain? Keep walking uphill; the moment everything slopes down, you must be at the top. Except maybe you're on a little peak, and the real summit is across the valley you can't see. The AI climbs magnificently from wherever it's standing. Knowing whether it's standing on the right hill — that's still us, and it's baked into ingredients as small as how the question gets asked. Will the AI do matrix multiplications faster than any human? Obviously. Is AI with human guidance still producing better results than AI alone? Also obviously.

The prompt is the takeaway

So no — you don't have to learn to be a developer. But you do have to be cognizant of the rules of the medium, the same way any artist is: stop, step back, look at the whole. And the genuinely new thing, the thing that makes this the easiest era in history to do software right, is that the process itself is now one prompt away. Ask the AI to set up version control with intentions in every commit. Ask it to interview you for your scope and goals. Ask it to help you draw your data model and follow your dollar. It will do all of it, gladly, and get you most of the way there.

The tools that let you skip the process are the same tools that will do the process for you. All you have to supply is the sentence that asks.