In 2026, AI in software development feels less like the singularity and more like a faster horse—revolutionary output speed gains that haven't fundamentally changed what's hard about building systems. Developer Chris Kiehl published his evolving thoughts on the state of AI tooling this week, offering a nuanced take that's worth your time if you're living through the chaos firsthand.

The Good: Tooling Finally Makes Economic Sense

Kiehl loves the new economics of tooling most. He frames it in woodworking terms: it's now viable to create "shop jigs"—custom tools specific to your setup that are rarely worth committing but useful for one-off situations. Pre-AI, building tooling required justifying time against shipping features and always lost that battle. Now you crank them out on-demand wherever needed. In terms of raw productivity wins, this has to be the biggest winner.

Code Gets Malleable

Big refactors can now be tackled with confidence. Changes that took hours happen in minutes. Kiehl describes his development style: start changes by hand, then hand off tedious flushing work through the wider codebase to AI. He hasn't found skipping the initial hand-written code works for him—spending time explaining what he wants in giant /plan conversations often ends up slower than just making the change himself and saying "do it like this, but everywhere." The one area where Kiehl still does almost everything by hand? Testing. Despite ample examples in his codebase, Claude still produces goofy property-based tests that require rework.

Alleviating Grunt Work

CDK (Cloud Development Kit) has become AI's problem at Kiehl's shop. "That gigantic pile of dogshit that constantly ruins my life?" Now managed by a little automated buddy keeping personal stacks updated. Quality-of-life improvements also shine—running formatters, resolving linter issues, handling build problems, and cleaning up print statements now happen while he moves to other tasks instead of requiring babysitting.

AI Code Review Actually Works Now

AI code review has swapped from irritating noise to genuinely useful. It's become a great last line of defense for catching problems earlier in the lifecycle. But Kiehl stresses this doesn't mean only AI should review code—and he's concerned about colleagues suggesting otherwise (see: "go faster" culture below).

The Bad: Humans Are the Weakest Link

Here's where things get ugly. The most common response to code review comments now: "Oh, I dunno. Claude did that and I didn't look at it." Worse still are developers having their AI post responses to CR comments directly—AI-generated apologies for problems AI created in the first place. This behavior is "extremely prevalent amongst fresh college hires and interns," according to Kiehl.

Test Quality Has Collapsed

Developers were never great at writing tests, but at least they engaged with their code to get them passing. Now teams ship CRs filled with AI-generated slop that technically exist but do nothing useful. Kiehl draws a hard line: "I allow a lot of leeway on my team for AI generated slop, but tests are the one area where 'I'll die on this hill and die happy.'"

Bullshit Asymmetry Is Exhausting

The amount of wrong information that must be corrected has exploded. "Yes, yes, I know Claude said it works that way, but it's wrong." Colleagues defend AI outputs aggressively—even when Kiehl pulls counterexamples from actual RFCs, they remain incredulous because Claude told them they were right. This asymmetry makes delegating ambiguous tasks risky: some developers can handle scoped tickets while others uncritically consume whatever their AI session outputs.

Mental Load and "Go Faster" Culture

Work hours have become a cacophony of noise—constant context switching between sessions has spiked terrible design decisions. The entire leadership chain has adopted one talking point: go faster, do more with less. But "more" remains undefined. "Faster relative to what? Nobody can really say." This pressure leads directly to the most demoralizing trend Kiehl observes: AI stealing the love of craft from developers who were celebrated for steady, reliable contributions now labeled as "bottlenecks" or "not scaling."

The Encouraging Signs

Not everything is doom. For all the hand-wringing about skill loss and nobody knowing how to do anything anymore, Kiehl still sees curious people using AI to learn topics deeply—not in flashy "I prompt TLA+ because I am very smart" ways that dominate social media discourse, but quietly, boringly, because they find it genuinely interesting. His verdict: "The kids are going to be OK. (I think)"

Key Takeaways

  • One-off tooling is finally economically viable; create shop jigs on demand without justifying the time investment
  • AI-assisted refactoring works well when humans set direction and validate results, not the reverse
  • Testing remains stubbornly human-required; AI-generated test suites do more harm than good
  • AI code review has matured into a useful last line of defense—but shouldn't replace human reviewers entirely
  • Leadership's "go faster" mandate without clear metrics is destroying experienced developers' morale

The Bottom Line

Kiehl's piece confirms what insiders already suspected: the technology works, but the humans are breaking. Until organizations stop measuring developers by output volume and start valuing the institutional knowledge that can't be prompting-engineered away, we'll keep shipping garbage with a smile while real engineers get ground down.