Tom Renner explaining inevitabilism.

People advancing an inevitabilist world view state that the future they perceive will inevitably come to pass. It follows, relatively straightforwardly, that the only sensible way to respond to this is to prepare as best you can for that future.

This is a fantastic framing method. Anyone who sees the future differently to you can be brushed aside as “ignoring reality”, and the only conversations worth engaging are those that already accept your premise.

“We are entering a world where we will learn to coexist with AI, not as its masters, but as its collaborators.” – Mark Zuckerberg

“AI is the new electricity.” – Andrew Ng

“AI will not replace humans, but those who use AI will replace those who don’t.” – Ginni Rometty

These are some big names in the tech world, all framing the conversation in a very specific way. Rather than “is this the future you want?”, the question is instead “how will you adapt to this inevitable future?”. Note also the threatening tone present, a healthy psychological undercurrent encouraging you to go with the flow, because you’d otherwise be messing with scary powers way beyond your understanding.

Scott Jenson talking about anthropomorphizing of LLMs and touching upon the difference between summary and shortening. I recommend reading the entire post to avoid taking the subtext below out of context..

[…] we say they can “summarize” a document. But LLMs don’t summarize, they shorten, and this is a critical distinction. A true summary, the kind a human makes, requires outside context and reference points. Shortening just reworks the information already in the text.

Here is an example using the movie The Matrix:

Summary

A philosophical exploration of free will and reality disguised as a sci-fi action film about breaking free from systems of control.

Shortening

A computer hacker finds out reality is fake and learns Kung Fu.

There’s a key difference between summarizing and simply shortening. A summary enriches a text by providing context and external concepts, creating a broader framework for understanding. Shortening, in contrast, only reduces the original text; it removes information without adding any new perspective.

Thomas Dohmke—ex CEO of Github—shares his take on the AI vs Developer+AI argument. He still thinks developers will need to get their fundamentals right, review and verify AI generated code, understand and design. But then also acknowledges that AI is going to bring in a significant change in the way developers code in the future.

Developers rarely mentioned “time saved” as the core benefit of working in this new way with agents. They were all about increasing ambition. We believe that means that we should update how we talk about (and measure) success when using these tools, and we should expect that after the initial efficiency gains our focus will be on raising the ceiling of the work and outcomes we can accomplish, which is a very different way of interpreting tool investments. This helps explain the – perhaps unintuitive at first – observation that many of the developers we interviewed were paying for top-tier subscriptions. When you move from thinking about reducing effort to expanding scope, only the most advanced agentic capabilities will do.

The last sentence in bold ties back to the title of this post.

Colton Voege arguing that AI is not making software engineers 10x as productive.

10x productivity means ten times the outcomes, not ten times the lines of code. This means what you used to ship in a quarter you now ship in a week and a half. These numbers should make even the truest AI believer pause. The amount of product ideation, story point negotiation, bugfixing, code review, waiting for deployments, testing, and QA in that go into what was traditionally 3 months of work is now getting done in 7 work days? For that to happen each and every one of these bottlenecks has to also seen have 10x productivity gains.

Any software engineer who has worked on actual code in an actual company knows this isn’t possible.

AI is making coding—which is a small portion of what software engineers do—10x productive. That too, sometimes. Colton Voege touches upon quite a few other topics. A worth while read.