Craft vs Outcomes: The Real Divide AI Is Exposing

There’s a divide in software development that’s always existed but rarely gets named. Some developers fall in love with the craft itself, the elegance of a well-factored system, the satisfaction of a clean abstraction. Others just want to ship something that works and move on to the next problem.

I’ve worked with both types for years. The tension between them used to simmer quietly. AI is turning up the heat.

The Economics Changed

Writing code used to be expensive. When implementation takes 10 hours, every shortcut matters, every abstraction that saves future time earns its keep, and deep fluency with a language or framework translates directly into speed.

When implementation takes 10 minutes, a lot of that calculus breaks down. Most developers are at least trying it. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process, and 51% of professional developers use them daily.

I watched a developer on a team I advise spend most of a day writing a beautifully architected data transformation pipeline. Clean separation of concerns, well-named functions, comprehensive error handling. Meanwhile, another developer on the same team generated a working version with AI in about 20 minutes, reviewed it, cleaned up the rough edges, and moved on to the next feature.

The elegant version was genuinely better code. But the pipeline processes a nightly CSV import that nobody looks at unless it breaks. Six months from now it’ll probably be rewritten anyway when the data format changes. The “worse” version was the right call.

Where Craft Still Wins

That story might sound like I’m dismissing craft. I’m not.

I’ve seen the opposite play out too. A startup I worked with let AI generate most of their authentication layer, and the code worked fine until it didn’t. The edge cases around session management and token refresh were subtly wrong in ways that only showed up under load. Fixing it cost them a week of downtime debugging and a painful incident with a key customer. That failure mode is the most common one developers report. The top frustration in the same Stack Overflow survey, cited by 66%, was “AI solutions that are almost right, but not quite,” and 45% said debugging AI-generated code is more time-consuming.

Authentication, payment processing, public APIs, anything security-critical or customer-facing: these are places where understanding the code at a deep level pays for itself many times over. Craft is load-bearing there.

The developers who care about clean architecture, who think about failure modes, who refactor until the system is easy to reason about, they’re invaluable when the stakes are high.

Where Craft Becomes a Trap

The problem is when craft orientation becomes a default mode rather than a deliberate choice.

I’ve seen teams spend weeks perfecting internal admin tools that three people use. I’ve watched developers resist AI tooling because it produces code that’s “not how I would write it,” even when the output is correct and readable. I’ve sat in code reviews where the feedback was essentially aesthetic: rename this variable, extract this into a helper, use a different pattern. All technically valid. None of it moving the product forward.

The craft instinct is powerful, and it doesn’t have an off switch. When your identity is built around “I write good code,” it’s hard to accept that sometimes good enough is actually better than good.

What AI Actually Changes

This divide existed long before AI. AI just made the costs visible.

When everyone writes code by hand, the craft-focused developer and the outcome-focused developer both spend similar amounts of time on implementation. The craft developer produces better code, and the time difference isn’t dramatic enough to force a conversation about priorities.

AI blows that gap wide open. The outcome-focused developer finishes in a fraction of the time. Suddenly the team has to reckon with a question that was always there but easy to avoid: what are we actually optimizing for?

One honest caveat about “a fraction of the time.” In July, METR published a randomized controlled trial where 16 experienced open-source developers worked 246 real tasks in mature projects they’d contributed to for an average of five years. With AI allowed, tasks took 19% longer. The developers themselves estimated afterward that AI had made them 20% faster.

METR is careful to say this doesn’t prove AI fails to speed up most developers. I read it as a map of where craft lives. Big, mature codebases with high quality bars, worked by people who know them deeply, are exactly where the speedup shrinks or disappears. The nightly CSV import is the opposite kind of work, and that’s where I keep seeing the speedup.

The answer is context-dependent. A fintech startup handling money needs more craft in its core systems than a marketing site that’ll be redesigned in a year. The right approach changes based on what you’re building, who’s using it, and how long it needs to last.

The Learning Moves

The skills that matter are shifting, and they aren’t getting any smaller. The AI discourse tends to miss that.

Knowing loop syntax matters less. Knowing whether you should build the system at all matters more. Understanding API semantics matters less. Understanding how your architecture will evolve as the business grows matters more.

The developers who thrive with AI redirected their learning toward problem decomposition, system design, and understanding the business domain. The fundamentals didn’t change. The layer they operate at did.

The Honest Version

I used to be firmly in the craft camp. I took pride in elegant code, spent extra time making things clean, and genuinely enjoyed the puzzle of finding the right abstraction.

I’ve shifted. Years of shipping products taught me that a working thing in front of real users generates more insight than a beautiful codebase nobody’s using yet. AI accelerated this shift because it made the tradeoff starker, but the underlying lesson was already there.

The best developers I work with have figured out how to be deliberate about when each mode applies. They write careful, well-tested code for the core systems that hold everything together. They move fast and accept imperfection for everything else. AI makes that split easier to execute, because the “move fast” part got dramatically faster.

What matters is whether you’re choosing your approach consciously or just defaulting to what feels comfortable.

If you’re working out where that line sits for your own team, I do Claude Code coaching on your codebase, from a 45-minute session for $99 to a half-day with your team for $599.