If you ever tried the recent slate of AI agents (post Opus 4.5) you probably went through a mental journey that is remarkably similar for all of us:

OMG, this thing is incredibly powerful, I can’t believe it managed to fix that bug / implement that feature / create this tool that I’ve been meaning to write for years

Quickly followed by:

OMG, we (software developers) are all cooked

If you carry on down that path, the next insight is more interesting. Yes, the cost/effort of plausible code generation has collapsed. But, the cost of delivering high quality, well tested and compliant software has not. Corporations rely on their software passing certain quality and legal bars, and none of these have fundamentally changed.

Think back to when you got your first computer and started writing code. That sense of wonder when “Hello World” appeared on your screen. The dizzying feeling that you could make this strange machine do what you told it to. This feeling is useful again. It’s much better to mess around with these new AI tools and get your hands dirty building stuff than to sit there having opinions about them.

Some of the readers of my Beyond Clojure blog series have asked about my opinion on clojure.spec, and if it solves Clojure’s ’type problem’. Implying whether its presence makes me look more favorably on Clojure. Here are some of my thoughts.

This is a post in the Beyond Clojure blog series, in which a Clojure developer looks at typed languages for web app development. In this episode we look at front-end development in the language Elm.

Front end development targeting web browsers is a ghetto, everybody seems to agree. The core tools at our disposal are the amalgamation of ideas and accidents thrown together without much overall strategy. One positive development in recent years has been the drastic improvement of the JavaScript (JS) engines in popular browsers. They have now gotten so good that it’s a valid option to treat JS as a compilation target. This fact is one of the drivers behind the explosion of JS transpilers, there are now literally hundreds of languages that (either primarily or as an after-though) can compile to JS. These languages range from light syntax improvements (ala CoffeScript) to full blown languages with big runtimes and everything in between.

This is a post in the Beyond Clojure blog series, in which a Clojure developer looks at typed languages for web app development. This is by no means a complete survey of the Haskell web development landscape, rather a random collection of thoughts.

If you are interested in typed functional languages one stands taller than the rest. It’s impossible not to get sucked into the Haskell vortex, but why fight it? In spite of its reputation of being extremely hard to learn and even harder to master, there are several excellent resources out there and you are guaranteed to learn lots of very valuable lessons.

Here we are, after five years of learning and later doing Clojure full time, I’ve come to the point where I am seriously looking around for alternatives. I’ve gotten very comfortable working in Clojure, and it has and will continue to serve me very well. But getting comfortable has a flip-side, you stop caring.

I recently tried to use Datomic in anger in a project. Here are some things I learned.

By reading the title of this post, you might think this entry is about using some clever Emacs skills to find bugs in old software. But no, it’s actually about hunting down bugs in Emacs itself (which incidentally happens to be very old software).

I’ve been quite vocal about my opinions on development environments and automating the creation of them on this blog and elsewhere. Boiling it down to the two points I feel most strongly about:

1. Always develop in a production-like environment
2. Automate the creation of these environments