Jam sessions vs studio production
Two postures for AI agents in a living codebase
One year ago, Andrej Karpathy gave us a useful name for a thing many of us were already doing: vibecoding. You describe the shape of what you want, the model splats out code, you nudge it with “nah, more x, less y,” and you keep iterating until the behaviour looks right.
I want to give a name to something many organisations are already doing: autocoding. The difference is in the name:
Vibecoding: vibe-checking output and steering agents with vibes (“that looks right, nah more X”)
Autocoding: empowering agents to work in increasingly long autonomous loops within the context of a professional codebase that can’t tolerate an outage.
If Steve Yegge was ahead of the curve on vibecoding, Ramp is ahead of the curve on autocoding. Check out their technical blog post.
The secret to autocoding is giving the agent the right back-pressure: tight feedback loops that reliably punish wrong moves and reward correct ones fast enough that the agent can course-correct without your babysitting it on every step.
This lets AI agents take increasingly confident autonomous steps in the context of a living codebase—steps that not just the agent but that you can verifiably exercise oversight in.1
Vibecoding’s primary constraint is the speed of insight: get something working fast enough to learn what you actually want or to obtain an app you wouldn’t spend the time to code otherwise. Keeping up with the volume of generated code is optional, and correctness is… a spectrum.
Autocoding’s primary constraint is correctness + oversight: making changes that will survive reviews and production reality in a world where your code has consequences (including 3am “will page you” consequences). Speed still matters but is constrained by ability to oversee the code and trust it.
If you’ve ever recorded music, these modes should be deeply familiar:
vibecoding is jam sessions: iterate on riffs, chase a feel, record later maybe.
autocoding is studio production: click track, stems, takes, checks; you want to automate drudge work, but with professionalism.
Both skills play into each other.
You can vibecode your way into a good riff (plan) to record (autocode) for real.
You can use autocoding to vibecode more effectively, by adding tests, linting, and specs to enhance how autonomously your AI agent resolves issues before presenting you with an output to vibecheck.
Why care about the distinction?
The distinction matters because autocoding isn’t “vibecoding but better”—they’re just different situational postures. Organisations shouldn’t be afraid of vibecoding; they should contain it to the edges of their codebase.
Moreover, autocoding is a useful OKR organisations can adopt: how long can agents autonomously work while getting useful work done? Anything that helps with that—closing the loop with docs, specs, locally runnable production stacks, skills—helps with that OKR. It’s a more focused, principled, and constrained metric than “brr make engineers use AI because I heard that’s good.”
At Softmax, we have certain sections in our codebase designed “vibecoding-friendly” where reviews are optional, and code flows in a frenzy. Luckily, the outputs of this code are easily checked, and they meet the rest of the code via a concretely defined interface. We even have Gas Town running at full blast in these special development zones. If this sounds interesting to you, you might want to join us.
The secret to vibecoding, meanwhile, is taste + fast iteration: you’re using your internal sense of “this is the right shape” in place of formal requirements, and picking problems where being approximately right is valuable and being formally correct is optional. The trick is to have the agent run as long as possible while being tight enough that taste can actually steer.