on vibe coding

Everyone is obsessed with how much faster coding agents have made us, but very few people are asking what we're losing in exchange. We celebrate that we can now build applications four times faster, but we rarely stop to ask whether we still understand the software we're building.

For years, software engineering rewarded people who lived inside a codebase. You spent weeks implementing a feature. You knew every function, every class, every API call because you personally wrote it. When a production bug appeared three months later, you didn't need documentation. You had intuition. You remembered why certain decisions were made because you were there when they happened. That intuition wasn't written down anywhere. It was built through thousands of tiny decisions over hundreds of hours.

AI completely changes that equation.

Today you can ask an agent to implement an authentication system, generate the backend, write the frontend, add tests, update the database schema, and even generate documentation before you've finished your morning coffee. It feels incredible. Productivity has exploded. But something subtle has happened in the background. You spent fifteen minutes reviewing code instead of three days writing it. You gained output, but you lost immersion.

That's the paradox. AI is making us dramatically more productive while simultaneously reducing our familiarity with our own systems. The faster you build, the larger your application becomes. The larger your application becomes, the harder it is to understand. Eventually your codebase grows faster than your mental model can keep up.

I think that's why so many experienced engineers are starting to feel like they're constantly onboarding into their own projects. It's a strange feeling. You built the application yourself, yet every week you have to ask the AI to explain how something works because you don't remember writing it. Not because you're a bad engineer—but because the bottleneck shifted from writing software to understanding software.

What's fascinating is that this isn't really a software engineering problem. It's a psychology problem.

Our brains build expertise through repetition. When you spend hours solving a problem yourself, your brain constructs thousands of invisible connections. You remember why you rejected one implementation. You remember the bug that forced an architectural change. You remember why a database index exists. Those memories become intuition.

But if AI compresses eight hours of work into twenty minutes, your brain never gets enough repetitions to build those mental models. You receive the outcome without experiencing the process.

It's the difference between writing a book and proofreading one. You can review every sentence carefully, but you'll never know the story as deeply as the person who struggled to write every chapter. That's exactly what's happening with AI-generated software.

This creates a completely new challenge for modern engineering teams. The problem isn't writing code anymore. It's preserving context.

Historically, documentation was treated as something developers hated. We'd promise to write docs later, then never touch them again. But maybe documentation itself isn't the answer. Maybe what we actually need is something much smaller.

Imagine every significant AI-generated change leaving behind a receipt instead of a giant document.

Why was this change made?

Which files were touched?

What assumptions were introduced?

What existing features could break?

Which tests actually passed?

Suddenly you're not reading hundreds of pages of documentation. You're reading the decision history of the software. That's much closer to how humans naturally understand complex systems.

Another interesting idea from this discussion is that developers may be transitioning into something that looks less like software engineers and more like engineering managers. You're no longer responsible for writing every line. You're coordinating work, reviewing outputs, making architectural decisions, identifying risks, and deciding whether the AI's solution should actually exist. In many ways, every engineer is becoming the lead engineer of a team whose members happen to be AI agents.

But there's a danger here. If we become too detached from the implementation, software slowly drifts toward chaos. AI loves creating abstractions. It loves generating helper functions, utility classes, wrappers, and layers that technically work but slowly increase complexity. Individually they're harmless. Together they become technical debt at a speed we've never experienced before.

That's why I don't think AI replaces engineering discipline. It makes engineering discipline more valuable than ever.

Architecture matters more.

Naming matters more.

Code reviews matter more.

Testing matters more.

Because you're generating so much more software every single day.

One comment in this discussion made an observation I thought was brilliant. They described the problem as "context inversion." Before AI, you knew the "why" before the "what." You made the decision first, then wrote the code. With AI, you often see the finished implementation before fully understanding the reasoning behind it. You're reconstructing intent after the fact instead of creating it in the first place. That subtle inversion completely changes how we learn.

I also don't believe the solution is simply "review more code." Eventually codebases become too large for any human to hold entirely in their head. Instead, we need better systems for retrieving understanding. AI shouldn't only generate code. It should generate explanations, architectural maps, dependency graphs, decision histories, and blast-radius analysis. If AI is creating the complexity, it should also help us navigate it.

This is why I think the future software engineer isn't the person who writes the fastest code. It's the person who builds the best systems around AI. Systems that preserve context. Systems that maintain quality. Systems that make understanding scale just as quickly as code generation.

Because if AI continues improving—and I think it absolutely will—the scarce resource won't be code anymore.

It will be understanding.

And the engineers who master that shift won't just build software faster.

They'll build software that can still be understood five years later.