Evolving Thoughts on AI
Published: 2026-06-28
Everything is different and yet the same. In 2026, AI feels less like the singularity and more like a faster horse. Yes, yes, it's revolutionary and enables everyone to do wonderful things they could have never done without it, but what has actually changed beyond output speed? Everything that was hard about building and maintaining systems still seems hard.
But things change fast. My opinions from last year are outdated. Here are more opinions that will age poorly.
The Good:
Tooling
I love this more than anything else. To put it in woodworking terms, it's now economic to create "shop jigs." They only make sense for your setup. They're rarely worth committing. They're often built to be used once and thrown away. Pre-AI, tooling was something that was an investment. You had to justify spending the time. And because of that, it generally had to be broadly "useful." That scarce time was weighed against "shipping features" or whatever and always lost. Now you can crank them out on-demand, wherever you need them. In terms of raw productivity boosts, this must be the biggest winner.
Code is more malleable
Big refactors can be tackled with confidence. Changes that would take hours can be done in minutes. It's easier than ever to write good code.
I've settled into a development style that starts a change by hand but then hands it off to Claude to finish up the tedious part of flushing it through the wider codebase. I know some don't bother writing code by hand anymore, but I haven't found that to work for me. I spend so much time trying to explain what I want in a giant /plan conversation that it ends up slower than me just making the change, pointing at it, and saying "do it like this, but everywhere"
The one place I still do just about everything by hand is testing. Claude knows everything about the APIs of property based testing libraries, but really struggles to understand how they should be used. Despite the ample examples in our codebase from which to draw, it'll still do goofy things that lead to me just doing it myself. A bad test suite can ruin a good codebase. Constant vigilance is required. Now more than ever.
Plus, good Property Based Tests are suspiciously small. Generating a bunch of test code is usually a symptom of insufficient thinking.
Alleviating grunt work:
A lot of software development is tedious, uninteresting grunt work. Offloading this to AI has been awesome.
CDK? That gigantic pile of dogshit that constantly ruins my life? That's Claude's problem now. I've got my little buddy automatically keeping my personal stacks up to date for me. If I weren't so worried about becoming Yet Another Team that has AI destroy a production environment, I'd lean harder into having Claude manage all CDK deployments so that I can be free. But... that day is far in the future (if ever).
I also love the little quality of life improvements. The most annoying part of any code change is the final busy-work of running formatters, resolving linter issues, resolving build issues, running tests, etc. It previously required baby sitting and frequent restarts to handle the small issues that arise ("oh, whoops. Left over print statement"). Now? AI kicks it over the line while I go do other things.
AI Code Review is suddenly useful
AI code review has swapped from irritating noise to useful. This has always been the area I'm most hyped about. I like types for a reason. I like static analysis for a reason. I want tools that catch problems earlier in the lifecycle. AI Code Review tools have become a great last line of defense.
But AI code review being useful doesn't mean only AI should review code. (imho)
The number of people suggesting this in earnest is growing (see: "go faster" below). I don't know what to do other than post the same two essays over and over.
I relate it to legacy systems. The thing that makes working with legacy projects hard has very little to do with the specifics of the code (though, it's usually trash) and everything to do with the fact that you have no "theory" associated with the code. The service runs the way it runs because that's the way it was running when you showed up. When it runs a different way and alarms fire? Who knows. The service isn't "yours." It behaves the way it does because of a philosophy you can only approximate over time through induction. The innumerable, invisible decisions which led to its operating model are not available to you.
I do think it's good that some teams are trying this, though. Maybe Peter Naur was an idiot and the dude with a Claude subscription knows better. Only time will tell. For now, I have to do on-call rotations, carry a pager, and get yelled at when we affect customers. So, old habits die hard. I'm going to err on the side that thinks being deeply engaged with the code is valuable over the long term.
The Bad:
The worst part of AI is the people
The increasingly common response to CR comments:
"Oh, I dunno. Claude did that and I didn't look at it"
Or they do the far, far worse thing of have their AI post a response to the comments.
"You're right to push back on this. I should have blah blah"
This is extremely prevalent amongst fresh college hires and interns. They'll even ferry Slack conversations to Claude. It's hard to articulate the level of disappointment I feel when I realize a fellow human being has chosen to be nothing more than a lossy interface for Claude.
The bar has dropped to the floor
Developers have never been good at writing tests. But at least they wrote them. In the old days, they'd have to engage with their code on some level in order to get their tests passing. Now people cut CRs filled with "tests" that they haven't looked at and that do nothing. You'd hope this was isolated to newbies, but seemingly everyone has embraced it. 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"
The mental load
Work hours are a cacophony of noise. You're constantly context switching and juggling sessions. The number of terrible design calls I've made over the last few months has shot through the roof. The Task loading is beyond what can be managed effectively.
Bullshit asymmetry
The amount of wrong information that must be corrected is exhausting and time consuming. "Yes, yes, I know Claude said it works that way, but it's wrong." "Yes, yes, I know it linked you to the RFC that 'proves' it works that way, but implementations often depart from..." "Yes, I can show you, but it would take time for me to..." This continues on until you waste a bunch of time pulling a counter example to ultimately just receive continued incredulity from the asker. Claude said they were right! Why aren't you accepting that they're right!?
This problem has made it very hard to delegate certain kinds of tasks. The lukewarm bodies sitting in front of a Claude session uncritically consuming its output can cause more harm than good. But this isn't that different from how it's always been. There are people you trust to do ambiguous tasks and there are people you give well scoped "(have Claude) do what this ticket says." The trick is not confusing the two groups.
The Demands for Increased Performance
The entire leadership chain has adopted one talking point: go faster. "Do more with less." More, more, more. But "more" also remains undefined. "Go faster" relative to what? Nobody can really say. Just do "more." Faster.
That leads to...
The Demoralizing
It has stolen the love of the craft from many people. "Engineering culture" has always been comprised of a small few. The passionate have always been outnumbered. Now they're drowning. Leadership wants "more" and they want more now. Those who have be celebrated for providing a steady pace of development over the span of years now find themselves "a bottleneck" or "not scaling" or "slowing others down." They're watching a culture that took pride in the number of "9s" disintegrate around them. In its place, they're told to get used to "Correction of Errors" again. Go fast at the expense of all else. Many struggle in this new world.
We're working on economic timelines. Over the long haul, we'll see who is right. But it will take an uncomfortable amount of time. Adjustments will only be made once it's felt in somebody's pocket book.
I find myself thinking a lot about the book Liftoff, which chronicles the early days of SpaceX. They moved at an incredible pace, but also found that there's an upper limit to how fast you can iterate before things start falling apart at the seams. Right now, it feels like we're pushing up to that edge. But many are going beyond it. Things, and people, are beginning to break.
The Encouraging
For all the kvetching on the internet about "skill loss" and how nobody will know how to do anything anymore, there still seems to be a lot of curious, interested people out there who use AI to learn new topics deeply. Not in the flashy "I prompt TLA+ because I am very smart" way that's so common on the internet right now, but in quiet, boring way: because they find it interesting.
The kids are going to be OK.
(I think)