Evolving thoughts on AI - BlogomatanoEvolving Thoughts on AI

Published: 2026-06-28<br>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.<br>But things change fast. My opinions from last year are outdated. Here are more opinions that will age poorly.<br>The Good:<br>Tooling<br>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.<br>Code is more malleable<br>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.<br>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"<br>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.<br>Alleviating grunt work:<br>A lot of software development is tedious, uninteresting grunt work. Offloading this to AI has been awesome.<br>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).<br>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.<br>AI Code Review is suddenly useful<br>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.<br>But AI code review being useful doesn't mean only AI should review code. (imho)<br>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.<br>Programming as Theory Building<br>No Silver Bullet<br>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.<br>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.<br>The Bad:<br>The worst...