Rigor should track with consequence

There’s a growing backlash to vibe coding, and a lot of it is fair. We’ve seen plenty of examples where nobody really understands what was generated, the software grows beyond its original purpose, and eventually a team is left trying to maintain something whose behavior and architecture nobody can confidently explain. The instinct to respond by putting more emphasis on understanding, review, testing and maintainability makes sense. For production software, especially software that customers depend on, that discipline matters enormously.

Where this starts to go wrong is when we apply the same standard of engineering rigor to every piece of software we create.

Software has never really been one category of thing. The code controlling a critical production system and the script someone writes to automate a spreadsheet are both technically software, but we have never treated them as though they deserve the same development process. AI has dramatically widened that spectrum because it has lowered the cost of creating useful software. Things that previously would never have justified engineering investment can now become working applications in hours or days, so we naturally have to change the calculation...

Imagine five people on an internal team are spending hours every week manually combining information from a few different systems. The proper long-term solution is already planned, but it is six weeks away. Someone can spend an afternoon vibe coding a small internal application that eliminates most of that work tomorrow. Maybe they don’t understand every generated function. Maybe the architecture isn’t particularly elegant. Maybe the test coverage is terrible. If the application has five users, contains no sensitive data, can’t affect production, and is going in the trash six weeks from now, those things may simply not matter very much (though you should really be honest with yourself when assessing the lifespan - how many production-critical applications at your last couple companies clearly started as "quick fixes" or "temporary solutions" and are still underpinning everything that matters, 5...10...20 years later?).

Requiring that application to meet the engineering standards of your production stack could actually be a poor engineering decision. You might spend more time reviewing, testing, documenting and hardening it than the tool will ever save. Worse, the additional friction might mean it never gets built at all, leaving people doing something manually that a cheap piece of software could have solved.

Today's development reality makes this kind of short shelf life software incredibly inexpensive. That is one of the more interesting changes happening in software development right now, as we can build software for problems that previously weren’t valuable enough to deserve software.

The useful question, then, is how much rigor a particular piece of software deserves. Consider it as a sliding scale driven by a few factors: how many people will use it, whether those people are internal or external (relevance: external users bring with them a consideration of brand impact / your company reputation), what happens when it fails, what systems and data it can access, and how long we expect it to exist. A tool used by four engineers for a month belongs at a very different point on that scale than something used by thousands of customers for the next five years.

At one end you have disposable software. Prototypes, experiments, one-off analysis tools and temporary internal applications. Optimize heavily for speed of development and time-to-first-use. Let your preferred coding model generate most of it. Accept ugly architecture. Keep the investment proportional to the expected life and consequences of the thing.

Move along the scale and the expectations increase. An internal application that becomes part of how a department operates deserves more attention. Tests start to matter more. Security and access controls matter. Someone needs to understand how it works. You need to think about what happens when the person who created it leaves. The fact that it began life as a vibe-coded experiment doesn’t prevent it from becoming real software, but its engineering maturity needs to grow with its importance.

At the other end of the scale sits long-lived production software, customer-facing systems, critical infrastructure, safety-sensitive systems and anything where failure carries serious consequences. Here the standard should be high. Engineers need to understand the behavior of the system regardless of whether a human or a model wrote the original code. Changes need appropriate review and testing. Architecture and maintainability matter because other people will be living with those decisions for years.

The obvious failure mode is that temporary software has a habit of becoming permanent. The three-week internal tool becomes unexpectedly useful, five users become fifty, and six months later it is quietly part of an important business process. That doesn’t mean the original decision to build it quickly was wrong. It means the classification changed. Engineering rigor shouldn’t be determined permanently at the moment a repository is created. It should increase as the audience, lifespan and consequences increase.

That also means teams need to be comfortable occasionally saying, “This worked, people depend on it now, so it’s time to rebuild or harden it.” The first version already did its job, it proved the problem was worth solving and delivered value while doing so. Treating that first version as disposable can be a feature of the strategy rather than evidence that the strategy failed.

This is where some of the conversation around vibe coding feels too binary. Either AI-generated code is unlocking an incredible new development model, or it is creating an incomprehensible pile of technical debt that we will spend the next decade cleaning up - there's less discussion of the middle ground where both are possibilities or risks (delete as applicable!) but really, both can be enabled or mitigated accordingly, by virtue of being different applications of the technology.

The engineering skill that becomes more important in an AI-assisted world is knowing which one you are building, and as ever - before you do anything - map out the process flow you're tackling, and understand your goal before anything gets built. No technological advancement will ever account for not knowing how the operation works, and what you want to achieve.