The all-or-nothing stance that dominates AI discourse is not helpful. Neither of the extreme positions “we don’t use AI here” and “we let Claude yolo all our code” are productive. Both stances are basically positions taken to avoid having to think about the actual problem: how let a powerful new tool into an establish org / codebase without either pretending it doesn’t exist or using it and breaking the code with hundreds of invested man-years?

Simon Willison’s great collection of Agentic Engineering Patterns includes an excellent post called “Hoard things you know how to do”. The short version is that you should collect examples of how to solve problems, in code preferably, so you can show your AI agent later. One line in particular is worth pulling out:

“The key idea here is that coding agents mean we only ever need to figure out a useful trick once.”

Read more...

Code is not scarce anymore. If anything, we are heading into the opposite world: too much plausible code, not too little. That does change the job. Raw code production is less scarce than it was. But the job was never just typing anyway. Good developers always brought other things to the table, and those things matter even more now.

Judgment matters. Debugging matters. Taste matters. Systems thinking matters. Tradeoff analysis matters. Being able to explain what the system is doing and why it’s doing it matters. Saying no matters. Deciding what gets reused and what gets thrown away matters. A lot of what you’re actually paying for in a strong senior engineer is fast, correct judgment over and over again.

The big change is just this: plausible code is now much cheaper to produce. Getting from a vague thought to something that looks like software is dramatically easier than it was. That does not mean building good software is suddenly easy. But it does change what matters more.

The weird consequence is that the explanation of what you actually want starts to matter more. If code can be regenerated quickly, then more of the value shifts into direction. What problem is actually worth solving? Which tradeoff matters? What kind of change should even exist in the first place, really?

In many software companies the percentage of AI generated code is going up fast. The code churn is accelerating because of both developer-led features and fully automated AI cleanups and codemods. Many developers feel much more productive and their number of landed changes has gone up a lot. The shipped code seems to work ok, and if not the AI agent can often root cause and fix bugs quickly.

AI makes it much easier to outpace shared understanding of the codebase. What’s happening now in many large codebases is that teams keep shipping while quietly losing the plot.

AI tooling is not hitting the software industry in a uniform way. The YC startup bubble gets most of the attention and that distorts the picture. Move fast and break things is simply not viable in big parts of the industry.

Take heavily regulated industries like finance. It’s easy to mischaracterize these companies as slow moving or even lazy, when really they’re solving a harder problem. Generating plausible code faster is clearly useful. But a bank is not being asked to optimize for plausible code. It’s being asked to produce changes that can be explained, reviewed, approved, operated, and defended later. Regulation doesn’t make that pressure go away. It changes the terms on which you are allowed to respond to it.

If you have spent time with the recent slate of AI agents (post Opus 4.5) you probably went through roughly the same mental journey as the rest 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

Read more...

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. That feeling is useful again. It is 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.