10x Speed, Zero Structure

Reflections | Business Evolution

Building the kind of structure that the fastest-moving startup I've ever worked in doesn't seem to need in the same way.

I recently joined an early-stage startup — not as CTO, not as engineering lead, but as an individual contributor. It's a different seat than I've been in for a long stretch of my career, and it's given me a view I wasn't expecting.

The people leading the company are roughly ten years younger than me. Gen Z, mostly. And the way they build is genuinely different from anything I've been part of before.

Ideas turn into shipped features on a timeline that would have been unthinkable a few years ago.

A lot of it comes down to vibe coding and a near-total comfort with AI as a default tool, not a novelty. There's still review — every PR gets a look — and core functionality still goes through an alignment meeting before anyone commits to a direction. But the weight of it is completely different. Review is fast, not a gate. Alignment happens once, for the decisions that actually need it, not as a recurring ritual for everything.

I've spent years leading teams and building the muscle to avoid exactly the kind of mistakes that this pace seems to invite.

And yet — it's working.

I want to be honest about this rather than defensive: the structure I've spent my career building wasn't arbitrary.

Process, alignment, review cycles, documentation, sign-off — all of it existed for a reason. Engineering time used to be the bottleneck. Mistakes were expensive to unwind. Coordinating a team without some shared scaffolding meant chaos.

That world made structure a rational response to real constraints.

The question worth sitting with is whether those constraints still hold in the same way.

There's an obvious pushback here, and I don't think it should be dismissed.

Raw velocity isn't free. Vibe-coded decisions made in minutes can carry technical debt that takes months to unwind. Fast, ungoverned choices compound — quietly, until they don't.

And there's a subtler cost: institutional memory. Light review catches a lot, but it isn't the same as documentation, and a quick nod in an alignment meeting isn't a paper trail. The why behind a decision still tends to live in memory rather than in writing — fine until someone's busy, or gone, or simply forgets.

LLMs are getting fast at learning a codebase's own patterns — how a team names things, structures things, makes decisions — often faster than a new human hire would. And the documentation itself is changing shape. Skill files and MD files written for an AI to read back aren't the same as a wiki page written for a human, but they do capture intent, and they do it almost as a byproduct of working with these tools at all.

But even that argument needs an asterisk now.

The old argument was: no docs, no memory. The new one is closer to: the memory is there, it's just increasingly machine-readable instead of human-readable.

That's not nothing. It doesn't erase the cost — a model inferring intent from patterns can still infer wrong, the same way a new hire can. But it does mean the gap between "documented" and "undocumented" is narrower than it used to be.

It would be easy to frame this as old model versus new model, and pick a winner.

I don't think that's the right lens.

What I'm actually watching is a fork. AI-native companies, built for this speed from day one, with no legacy process to unlearn. And companies like the ones I used to lead — built in an era where structure was the price of scale, now having to strip that structure back down to compete.

Unlearning is harder than never having learned in the first place.

Which one wins may depend less on the era a company was born into, and more on the kind of problem it's solving. Some problems reward speed above everything. Others still punish it.

I don't think the answer is "adopt more structure" or "move faster and stop worrying." Both are too easy.

What I've actually taken from this is a sharper question to ask before reaching for either instinct: is this decision one where being wrong is cheap to fix, or expensive?

Vibe code the cheap ones. Slow down for the expensive ones.

The teams that figure out how to tell the difference — not the fastest teams, not the most structured ones — are the ones I'd bet on.