Vibe Coding Is a Shein Haul: Why Speed Without Craft Is a Landfill

Andrej Karpathy described vibe-coded software as "free, ephemeral, malleable, discardable after single use." The same week, Shein listed 10,000 new clothing styles in a single day. Read both sentences again. They describe the same thing.

I spent seven years leading product at Qonto, a 500,000-customer fintech. Before that, I built two core banking systems from scratch. I've watched codebases that ship fast and compound, and codebases that ship fast and collapse. The difference was never speed itself. It was whether the people building understood the system they were building inside.

The Parallel Nobody Wants to Hear

Fast fashion produces 92 million tonnes of textile waste per year. The Atacama Desert in Chile has become a dumping ground for unsold clothes, visible from satellite imagery.

Software is running the same playbook. 80% of features in the average product are rarely or never used. 95% of downloaded apps get abandoned within a month. Developers spend 42% of their working week on technical debt. The collective maintenance bill sits at $1.52 trillion in the US alone.

Polyester in one case. Code in the other. Same economic dynamic.

The False Tradeoff

Here's the catch. Most people frame this as "speed vs. quality." You can ship fast or you can ship well. Pick one.

That framing is wrong.

DORA has studied high-performing engineering teams for nearly a decade. Their finding is consistent and unambiguous: teams that score high on speed also score high on quality. Every time. The tradeoff doesn't show up in the data.

Martin Fowler calls this the Design Stamina Hypothesis. Good design starts slightly slower but accelerates development over time. The payoff line arrives in weeks, not months.

His conclusion: internal quality isn't tradable because reducing it slows you down. The purpose of internal quality is to go faster.

Stripe ships hundreds of times per day across a 20-million-line Ruby codebase. Teams using AI under architectural guidance shipped features 35% faster while maintaining quality standards. Teams without that oversight saw initial velocity gains followed by a 27% slowdown within nine months.

The tradeoff isn't between speed and quality. It's between feature-level thinking and system-level thinking.

Systems Thinking Is the Skill

When I led the billing refactor at Qonto, the hardest part wasn't writing code. It was seeing the system. How our code, product, teams, and business strategy were intertwined. How a change in billing would ripple through ops, legal, customer support, and six other squads shipping in parallel.

We mapped every dependency across the organization. We built causal loop diagrams showing what would break if a migration step was delayed. That allowed us to re-sequence work and avoid firefighting later. We shipped the full refactor without blocking other teams from delivering value.

That's systems thinking. Not a methodology. Not a framework. The ability to understand how parts of a system interact, and how changes in one part ripple across the whole.

Donella Meadows wrote the foundational text on this in 2008. Her insight: system behaviors come from the system's structure, not from external events. If your codebase accumulates debt, the cause isn't lazy developers. It's feedback loops, incentive structures, and architectural decisions that make debt the path of least resistance.

Rich Hickey put it differently: "Simplicity is a choice. If you are not able to reason about your program, you cannot confidently make changes." That's the connection between systems thinking and shipping speed. When you can reason about the whole, you can change any part without fear.

Why This Matters Now

IBM published a piece this year arguing that vibe coding and systems thinking aren't opposites. They're complements. Use vibe coding for ideation and rapid prototyping. Use systems thinking for the architecture that holds it together.

Werner Vogels used his final AWS re:Invent keynote to define the "Renaissance Developer" as someone who thinks in systems, not functions. Ahmad Al-Dahle, Meta's VP of GenAI, wrote that "code was always the medium; judgment was the craft." The two were conflated only because you couldn't exercise judgment without doing the typing. AI separated them.

Here's what I've seen change in practice. When code generation is near-free, the bottleneck shifts. It's no longer "can we build this?" It's "should we build this, and how should it connect to everything else?" That second question is systems thinking. And it's the one nobody's automating.

What I Got Wrong

I'll be honest: I used to frame this as a tradeoff too.

When AI coding tools got good enough to be useful, I shipped fast and planned to fix later. The dopamine hit of a working prototype in 30 minutes is real. But three months later, the code I'd shipped fast was the code I couldn't modify without breaking something else.

The mistake wasn't shipping fast. The mistake was shipping at the feature level instead of the system level. I was solving each problem in isolation. I wasn't asking what Meadows would call the second-order question: "What happens next if I do this?"

Margaret-Anne Storey at the University of Victoria introduced a concept this year that crystallized it for me: cognitive debt. Technical debt lives in code. Cognitive debt lives in the team's understanding. Even well-written AI-generated code can create cognitive debt if nobody understands why the decisions were made.

A systems-thinking product engineer doesn't accumulate either kind. Not because they ship slower. Because they design at a level where fast shipping doesn't create wreckage.

The Bar Should Be Higher

Linear built a $1.25 billion company with about 100 employees. Their engineering velocity stays high because they're not drowning in accumulated debt. Their secret isn't talent alone. It's that they say no constantly, at the system level, to features that would create complexity without proportional value.

Nathan Sobo, the CEO of Zed, wrote something that stuck with me: "In a world of abundance, the bar should be higher for quality."

Fast fashion proved that making things cheaper and faster doesn't make them better. It makes them disposable. 92 million tonnes of disposable.

Software doesn't have to follow the same path. The DORA data says the tradeoff is false. Fowler's Design Stamina Hypothesis says good design pays off in weeks. Stripe's numbers say architectural oversight makes you faster, not slower.

The question isn't "speed or quality." The question is whether you think in features or in systems.

Vivienne Westwood said it about fashion: "Buy less. Choose well. Make it last."

The software version: Write less. Design well. Make it last.

At Well, we build financial intelligence software with AI at the center. Speed matters in our world. But the speed we trust is the kind that comes from understanding the system you're building inside, not the kind that comes from generating code without knowing where it fits. Only one of those compounds. And compounding is the only moat.