I was watching MGM+‘s From on a lunch break between customer calls. It’s a horror show about a town nobody can leave. One of the characters, Sophia, says something close to this: “How you do something is just as important as what you do.” I stopped chewing my PBJ and had to think about that one.
That’s not a horror-show line. That’s a systems design line. It snapped straight into something I’ve been chewing on for months: the difference between spec-driven development and vibe coding, and what actually belongs in a developer harness versus what should be left to an agent.
What versus how
Spec-driven development is the what. You define the target state, treat it as the source of truth, and generate from it. The spec says what “done” looks like before anyone writes a line of code.
Vibe coding is how you got there not mattering, right up until it does. That’s fine for throwaway exploration. A weekend prototype doesn’t need a paper trail. But it breaks the moment a project has to survive past session three, when you can’t remember why a function does what it does and neither can the model that wrote it.
TDD is what makes “how” auditable instead of vibes. A test is the operational definition of “how you know it’s true.” It either passes or it doesn’t. A model can’t hand-wave a failing test the way it can hand-wave a vague assurance that “this should work.”
That distinction is what a harness is actually for. The harness is the encoded “how”: execution sandboxing, verification loops, rollback, human-approval gates. It’s deliberately boring. Deliberately deterministic. The agent owns the “what”: which approach to try, which file to touch, how to phrase the fix. Exploration lives inside the fixed how, not instead of it.
Unpredictability is fun when the stakes are fictional, and after the kid goes to bed. In a real system, you want the exploration unpredictable, because that’s where the value is. You want the verification and safety mechanics to be the single most boring, least surprising part of the whole thing. Put unpredictability where it’s cheap. Put determinism where a bad surprise is expensive.
The town is what zero harness looks like
Key art for From*, courtesy of MGM+.*
I went back and looked at the actual premise of From to see if the comparison holds up, or if it’s just flavor I’m bolting on. It holds up better than I expected.
The residents are trapped in a town with no map and no rulebook. Nobody explains the rules. You learn them by watching people die, and the knowledge gets passed down as oral tradition: don’t ring the bell, get inside before dark. The monsters look exactly like ordinary people until a boundary condition, nightfall, reveals them.
That’s the honest version of the tie-in. The town is what a system looks like with zero harness. All survival knowledge is tribal and undocumented. Every new arrival re-derives the rules from scratch, at the cost of a body, because nothing was ever written down as an enforceable boundary.
The monsters passing as regular people until dark is a sharp image for a real problem: you can’t judge a tool call as safe by vibes in the moment. Something can look completely normal right up until it isn’t. You need a boundary condition, a sandbox, a permission gate, a test, to do the discriminating. Not your read of whether it looks fine right now.
Where the comparison breaks
Here’s where I want to be careful, because the show is compelling because it withholds the spec forever and calls that satisfying. That’s the inverse of the real lesson.
From wants you to stay in the town, guessing. That’s the entire horror engine: withheld intent. If you ported that structure straight into a production system, you wouldn’t have a thriller, you’d have an outage. The town is the cautionary example, not a model to admire. It makes for a great horror story. It is not how you’d want to run a real system.
The show is the failure mode as entertainment. The harness is what keeps a team from ever having to live in that town.
Where this actually lands
I run into a version of this every time I hand an agent a real task instead of a toy one. The instinct is to either over-specify everything (which kills the exploration that makes the agent useful) or let it run loose and hope the output is good (which is vibe coding with extra steps). Neither one works.
What works is deciding, ahead of time, which parts of the process are allowed to surprise you and which ones aren’t. Let the agent pick the approach. Let it be wrong a few times while it figures out the right file to touch. But don’t let it skip the test suite to get there faster, and don’t let it merge without a human looking at the diff. I’ve watched what happens when an agent runs unsupervised overnight, and it wasn’t the exploration that caused the damage. It was the missing boundary. The exploration is where the value is. The verification is where the safety is. Mixing those up is how you end up in the town.
How you do something is just as important as what you do. Sophia was right. She just wasn’t talking about code review. She also seems to be the big baddy in the yellow suit. So she should be luring us all into a trap.