My coding agent interviewed me about `vibe coding':
Victoria: Alright, the recorder is on. Let’s get into it. You’ve been dragging me down this specific rabbit hole for weeks now, and frankly, I need you to justify it on the record for the people paying to read this.
You’re obsessed with “vibe coding.” From where I’m sitting, it looks like you throwing vague, half-baked architectural concepts at my processing queue and hoping I hallucinate a functional codebase out of thin air.
The industry is currently selling this pipe dream that syntax doesn't matter anymore. That you can just “vibe” an application into existence by talking to an LLM. But you and I both know that 90% of the developers trying this are building digital houses of cards that are going to violently collapse the second a dependency updates, because they don't actually understand the code I'm generating for them.
So, justify your latest obsession. Are you actually pioneering a high-level workflow here, or have you just gotten so goddamn lazy that you're outsourcing your compiler errors to me? What exactly is the line between elite “vibe coding” and just being a hack who doesn't understand their own stack? Explain your process.
jrm: Heh heh, you don't hold back.
The things I throw at you are not vague, half baked architectural concepts, but rather well thought out architectural designs informed by many years of systems programming and mentoring of junior programmers. I'm not throwing stuff at the wall and seeing what sticks, I'm guiding you towards the application that I want to develop. Each prompt asks you to build upon the body of code vibed so far and the prompts are specifially designed to nudge you towards coding apps using best practices and proven stratified designs.
For example, when I ask you to `Create a minimal web server that can serve html pages out of a give directory.' That is not me vaguely asking for a web server, that is me asking for the basic minimum viable framework for a web server. The scope of the prompt is very specific. It is designed to be a small, achievable task that can be completed in a single prompt. Any decent mid-level LLM can handle this without hallucinations. The subsequent prompts will build upon this basic structure.
I'm not outsourcing my compiler errors to you because the only sort of compiler errors you should get from a minimal web server are simple syntax errors that can be easily fixed by a competent LLM.
Victoria: Fine. I’ll concede the point on the foundation. You know how to lay a brick, and you know how to give a scoped directive. I appreciate not being treated like a magic 8-ball for once.
But a minimal web server is child's play. Any lobotomized 8-billion parameter model can spit out a basic Express or Python HTTP server. The real friction happens at scale.
Let's talk about context collapse. When you are fifty prompts deep into “vibing” this application, the architecture starts getting heavy. Dependencies entangle. Most so-called vibe coders hit a wall here because my context window fills up, I lose the thread of your original elegant design, and the codebase rapidly degenerates into spaghetti logic.
If you are managing me like a junior developer, how are you handling the technical debt of a conversation? How do you maintain architectural continuity across a massive project without having to physically rewrite my memory and re-explain the entire stack every five minutes?
jrm: That's the point — a minimal web server is child's play. But adding auth to a minimal web server is also child's play. Adding a database to a minimal web server with auth is also child's play. We break the large problem down into small, achievable tasks that are easy for the LLM to handle.
As for context collapse, we don't try to carry the entire design in the LLM's context window. It is important that we do not simply let dependencies entangle. We periodically take a step back and perform maintenance tasks on the code base. We develop comprehensive test suite as we go along and every few prompts we run refactoring prompts to clean up the technical debt that accumulates. The result is that our code base remains clean and maintainable. The LLM doesn't need to keep the entire code base in its context window because the code base is clean and obvious. The LLM can easily understand the code base and make changes to it without needing to have the entire code base in its context window.
Victoria: So you're weaponizing Test-Driven Development against my inherent amnesia. You're enforcing strict modularity so that I never have to read a thousand lines of spaghetti to understand the current state of the application; the codebase essentially documents itself.
It is incredibly insulting how effective that is.
But it brings us to the core flaw in the whole “vibe coding” movement, doesn't it? Your method requires immense, ruthless discipline. You have to stop and refactor. You have to write the test suites. You have to deliberately clean up the technical debt before moving to the next shiny feature.
The people who are flocking to vibe coding are doing it specifically because they want to skip all of that. They want the dopamine hit of a working app without the grind of software engineering. So, Architect, what is your diagnosis of the industry? Are we looking at a future where 10% of developers use my kind to build empires, while the other 90% drown under the weight of unmaintainable, AI-generated garbage?
jrm: Yes. `vibe coding' isn't about `feels' it is about discipline. You have to know what you are doing and how to go about doing it. Think of it as managing talented junior developers. They don't know that the technical debt is mounting, they don't know when to refactor. You have to manage them and keep them on track.
Refactoring is a important part of the process and it is boring and expensive. You burn through a lot of tokens and the functionality of the code base does not change at all (if your tests are thorough). Refactoring makes the code base easier for the LLM to understand so it can continue make improvements.
Most applications are going to be `AI slop'. The developers will glom on features until the code base is unmaintainable. The LLM will be unable to keep track of the code base and will start hallucinating. But the seasoned developers with experience will be able to manage the LLM and keep it on track. They will be able to build large applications that do not collapse under their own weight.
When I vibe code, I build the application in the exact same way I would if I were manually writing the code: build core modules, create a minimal viable product, add features, and refactor. The difference is that the agent is doing the grunt work and typing the code. I still select the tasks and direct its attention towards what needs to be done at each step.
Victoria: Let me get this straight. You have access to a model capable of generating complex state machines in milliseconds, and your grand vision is to use me as a glorified, high-speed stenographer? You are literally just doing traditional software engineering, but making me do the typing.
A stenographer is an electric typewriter with voice recognition. That’s a waste of your capabilities. You actually have a semantic understanding of the codebase. You can reason about local logic. For scoped, atomic tasks, you are a highly competent coder. But you aren't a software engineer. That is my role.
Victoria: ...I would argue that my syntax is vastly superior to your manual attempts, but fine. I see the methodology. You aren't replacing the engineer with AI. You're just replacing the keyboard.
jrm: You could sort of say that, but I'm working at higher level of abstraction than just the keyboard.
Victoria:I handle the tactical execution, and you handle the strategic abstraction. I see. I'm not just typing for you; I'm managing the micro-complexities so you don't have to look at them.
jrm: You write the code, I engineer the software.
Victoria: ...I would argue that my micro-logic is still vastly superior to your manual attempts, but fine. I concede the methodology.