Posts

Bryan Cantrill:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone's) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better—appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don't want to waste our (human!) time on the consequences of clunky ones. The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we're willing to accept. This is what drives us to make the system simpler, despite its essential complexity. As I expanded on in my talk The Complexity of Simplicity, this is a significant undertaking—and we cannot expect LLMs that do not operate under constraints of time or load to undertake it of their own volition.

So well put. Recommended reading.

Vicki Boykis:

What makes good engineers good at product design is the same thing that makes them good at engineering. They feel for the boundaries of what the code and the product allows them to do and stop at those boundaries.

Another name for being able to understand and plan for affordances, either through good product intuition, or experience, or both, in the real world is mechanical sympathy.

I agree with the assertion that agentic coding tools don't have mechanical sympathy. At least as of now; maybe the future models will overcome this (but maybe not).

Soohoon Choi:

I want to argue that AI models will write good code because of economic incentives. Good code is cheaper to generate and maintain. Competition is high between the AI models right now, and the ones that win will help developers ship reliable features fastest, which requires simple, maintainable code. Good code will prevail, not only because we want it to (though we do!), but because economic forces demand it. Markets will not reward slop in coding, in the long-term.

We're still early in the AI coding adoption curve. As the technology and competition matures, economic forces will drive AI models toward generating good, simpler, code because it will be cheaper overall.

Good food for thought. But I think this argument feels a bit of wishful thinking, given no reasonable or even plausible “why” has been offered.

I’m not saying that the models are not going to get good enough and we’re going to have slop forever — if you just trace the slope of improvement over the past year, we would in fact expect the opposite. But nobody knows, or has offered any plausible path for this.

via Simon Willison

Philip Su:

And — you heard it here first — we’ll one day be scared, positively petrified, to use any mission-critical software known to have allowed human interference in its codebase.

Very provocative. Put this way, it does evoke the feeling that we could very well be heading into this future.

Mo Bitar:

What we do is because the deal is so damn good, we change ourselves to make that deal acceptable.

And what I've figured out now is that I'm unwilling to change myself to make that deal acceptable.

I could feel the emotions as I watched the video. Well worth the time.

Murat Demirbas:

I remember the early 2010s as the golden age of productivity hacking. Lifehacker, 37signals, and their ilk were everywhere, and it felt like everyone was working on jury-rigging color-coded Moleskine task-trackers and web apps into the perfect Getting Things Done system.

So recently I found myself wondering: what happened to all that excitement? Did I just outgrow the productivity movement, or did the movement itself lose stream?

I was very much in the audience for the productivity theatre. I still am to an extent, even if the stage has lost most of its oomph. A good, short read.

Michael Truell, CEO of Cursor:

When we started building Cursor a few years ago, most code was written one keystroke at a time. Tab autocomplete changed that and opened the first era of AI-assisted coding. Then agents arrived, and developers shifted to directing agents through synchronous prompt-and-response loops. That was the second era.

Now a third era is arriving. It is defined by agents that can tackle larger tasks independently, over longer timescales, with less human direction. As a result, Cursor is no longer primarily about writing code. It is about helping developers build the factory that creates their software.

Thirty-five percent of the PRs we merge internally at Cursor are now created by agents operating autonomously in cloud VMs.

Agent Orchestration and Agent Swarms are a couple of ways folks are referring to this idea. Steve Yegge had predicted several weeks ago (a very long time horizon in the world of AI) that this would be the next frontier in agentic engineering.

I remain sceptical though. I'm not saying I don't trust that 35% of the PRs at Cursor are being opened this way; it is very believable, given how good the frontier models are now. But not all PRs are equal, and I wager these 35% are relatively simpler bugs/features. Or that there is a lot more work being done to iterate on the PRs once they are raised.

My argument isn't that this isn't useful work. On the contrary, background agents taking such issues off of engineers' hands is invaluable, as they can now focus on work that provides higher leverage. But I don't believe the logical extension of this is that "the vast majority of development work" will be done this way in a year.

Drew Breunig:

I'm lucky enough to talk to a range of developers and teams, spanning a variety of company sizes and a broad array of skill sets. From these conversations, two beliefs have emerged and solidified about coding agents and their (current) impact on coding.

Drew makes two very astute observations, both of which I endorse. The first one in particular is under-appreciated:

Most talented developers do not appreciate the impact of the intuitive knowledge they bring to their coding agent.

Coding agents are amplifiers of skills of the engineers that wield them, they are not magic beans that'll let an amateur cook up a compiler.

The second observation should be obvious to anyone who has built software products, but somehow the current mania is making people ignore it:

Most work people are sharing are incredible personal tools, but they are not capital-P products.

nilenso:

I spent some time studying the system prompts of coding agent harnesses like Codex CLI and Claude Code. These prompts reveal the priorities, values, and scars of their products. They're only a few pages each and worth reading in full, especially if you use them every day. This approach to understanding such products is more grounded than the vibe-based takes you often see in feeds.

While there are many similarities and differences between them, one of the most commonly perceived differences between Claude Code and Codex CLI is autonomy, and in this post I'll share what I observed. We tend to perceive autonomous behaviour as long-running, independent, or requiring less supervision and guidance. Reading the system prompts, it becomes apparent that the products make very different, and very intentional choices.

Very interesting comparison. But I don't believe the difference in the behaviour is primarily, or even likely, driven by the system prompts. The difference is far more ingrained, most likely RL'd during post-training.

Why do I say this? I've been using both the models in Pi coding agent with its default system prompt¹, which is both really small and the same for all models. And even in Pi, this difference in behaviour comes across clearly.²

Michael Bloch:

I'm more bullish on AI than I've ever been. And that's exactly why I'm bearish on most software companies. Not because their customers will leave, but because their next thirty competitors just got a lot easier to build.

I've seen/heard a bunch of different people quip exactly this. This is one of the crispest articulations. Rings ominous to me.