Experience Is Pattern-Matched Failure

The Vibe Coding Problem

I vibe-coded two apps: a habit tracker and a singing app. Described what I wanted, let Claude generate the code, ran it, iterated on errors. Both went from idea to working prototype in hours. The singing app is production-ready, targeting the Play Store. I'm also honest about what happened next. Both apps hit a wall where the AI-generated code stopped being enough. Auth flows, platform-specific constraints, Capacitor bridge configurations, the last mile before something is actually publishable. Solving those required understanding what the generated code was doing. Not just running it. Reading it, reasoning about it, knowing where to look when it broke. That's the pattern nobody talks about with vibe coding. The first 80% is fast. The last 20% requires everything the first 80% let you skip.

What Experience Actually Is

Experience is not years on a resume. It's the accumulated residue of things that went wrong. Every bug you've debugged leaves a trace. Not a conscious memory, necessarily, but a pattern: a sense that "this kind of problem usually comes from that kind of mistake." Every architecture that failed at scale teaches you what to look for in the next architecture. Every production incident burns a heuristic into your nervous system that no amount of reading can replicate. I learned this from documentation, not code. At Logpoint, I covered six security products I didn't understand. SIEM, SOAR, UEBA. I wrote about systems that confused me until the confusion became comprehension. That year of friction is why I could later build an AI system that evaluates documentation quality: I had internalized what good docs feel like, not as a checklist, but as a bodily sense. The debugging wasn't in code. It was in prose. But the pattern is identical. Experience is pattern-matched failure, and there is no shortcut to building that library.

Velocity vs. Direction

Vibe coding optimizes for velocity. How fast can I go from idea to working code? By that metric, it's extraordinary. A developer with an LLM can produce working software faster than the same developer without one. But velocity without direction is just speed. And direction comes from knowing which of the infinite possible implementations will actually hold up under load, under edge cases, under the accumulated entropy of a growing codebase. That knowledge doesn't come from the LLM. It comes from the developer. Specifically, from the developer's library of past failures. A vibe coder who has ten years of experience and uses an LLM to accelerate their work is dangerous in the best sense. They know what to ask for. They know what to check. They can read the generated code and spot the subtle issues because they've written (and debugged) that kind of code before. A vibe coder with no experience is building a house of cards at impressive speed.

I'm somewhere in the middle. I have enough foundation in Python and data science to evaluate AI-generated code in those domains. When Claude writes React components for my singing app, I'm trusting the surface. I know this about myself. That awareness is the minimum bar.

The Power Tool Analogy

A table saw in the hands of an experienced carpenter produces precise, beautiful cuts in a fraction of the time it would take by hand. The tool amplifies existing skill. A table saw in the hands of someone who has never worked with wood produces... results. Sometimes good results, by accident. Sometimes dangerous results. The tool doesn't know the difference between a skilled user and an unskilled one. It just cuts. LLMs are table saws for code. They amplify whatever you bring to them. Bring experience, and they make you faster. Bring nothing, and they give you speed without the judgment to use it well.

Why This Matters Now

The current moment is unusual because we have a generation of developers who are being told, implicitly and explicitly, that they don't need to build the failure library. The tools handle it. Just describe what you want. And the tools do handle it. Right up until they don't. Right up until the LLM generates a race condition that only manifests under production load. Right up until the architecture it suggests works fine for a hundred users and falls apart at ten thousand. Right up until the code passes all the tests but misses an edge case that an experienced developer would have caught on sight. At that point, the question becomes: does anyone on the team have the pattern library to diagnose this? Or did everyone skip the stairs and take the elevator?

The Synthesis

I'm not arguing against AI tools. I use them every day. They make me measurably more capable. I built a macOS productivity app, a vocal training app, and a personal habit tracking system with AI assistance. All three shipped. All three work. But they work because I built the foundation first, in my own domain. I spent years writing documentation badly before I could write it well. I spent months debugging evaluation pipelines before I could trust the numbers. That friction is the residue that makes me effective with the tools. Experience is pattern-matched failure. The patterns only form through friction. The friction is the point.

Power tools in trained hands build houses. Power tools in untrained hands build fast. Only one of those things has a foundation.