Why "Good Enough" Code Wins

Software development in the age of AI is going to require us to loosen up a little.

We've spent years—decades, even—building a culture around code craftsmanship. Clean architecture. Elegant abstractions. PRs that get sent back three times because someone spotted a slightly verbose variable name. We treated code like we were carving it into stone tablets that future generations would study.

This tweet caught some fire. It's controversial. But I do believe it to be true, even after reviewing the feedback.

The Shift Nobody Wants to Talk About

Here's the uncomfortable reality: AI-assisted development has fundamentally changed the economics of code quality.

When it took a week to build a feature, you damn well wanted that feature to be built right. The cost of iteration was high. The cost of refactoring was higher. So we optimized for getting it perfect the first time.

But when you can spin up a working prototype in an afternoon? When AI can help you refactor entire modules in minutes instead of days? The calculus changes completely.

Call the output "slop" if you want. Some of it is. But here's the thing—if you're demanding perfection on every pull request while your competitors are shipping ai-generated code that works, you're fighting from a disadvantaged position.

What "Good Enough" Actually Means

Let me be clear about what I'm not saying. I'm not advocating for:

• Security vulnerabilities
• Broken functionality
• Intentional technical debt
• Lower quality in the long run

What I am saying is that there's a massive gap between "this code will cause problems" and "this code offends my aesthetic sensibilities."

A lot of what we call code quality is really just code preference. And preferences are expensive when they slow you down.

That function could be decomposed more elegantly? Sure. But does it work? Is it readable enough? Will it matter in six months when you've either pivoted or rewritten it anyway?

Most code has a shorter shelf life than we like to admit.

The Competitive Reality

Here's what I'm seeing in the market right now:

Teams that have embraced AI-assisted development and loosened their quality gates are shipping 3-5x faster than teams still operating under pre-AI standards. They're testing more ideas. They're learning from users faster. They're iterating while others are still debating architecture.

Some of their code is ugly. Some of it will need to be rewritten. But they're in the market, getting feedback, building revenue, while the perfectionists are still polishing.

Shipping velocity matters as much as perfection. It always has.

The New Skill: Knowing When to Care

The developers who thrive in this new era won't be the ones who abandon standards.

Core infrastructure that everything depends on? Yes, take your time. Get it right.

Experimental feature you're testing with 1% of users? Ship it. Learn. Iterate or kill it.

The ability to shift between these modes—to know when you're building a foundation versus when you're running an experiment—that's a skill.

Let Go of the Ego

I think a lot of resistance to this shift is really about identity. We built careers on being craftspeople. Some of what we valued was arbitrary.

The best engineers I know have always been pragmatists. They cared about outcomes, not aesthetics. They wrote beautiful code when it mattered and functional code when it didn't.

AI just made the gap between those two approaches a lot more visible—and a lot more expensive.

So loosen up a little. Ship the thing. Learn from users instead of hypotheticals.

AI-generated code that works beats masterpieces that never ship.

— Ry