Two guys in the jungle. A tiger charges at them. One guy kneels down to tighten his shoelaces. The other yells, “What are you doing? You can’t outrun a tiger!” First guy says, “I don’t have to outrun the tiger. I only have to outrun you.”
One mistake I see a lot of engineers make when thinking about the impact AI will have on the software industry is to think in edge cases.
“LLMs can’t write C compilers correctly, psh! LLMs can’t write code in this very old and large codebase! LLMs can’t fix this very difficult and complex bug that took me two weeks to figure out.”
You don’t judge the impact of a technology on an industry by looking at one end of a spectrum only. You need to look at the other end too, and the average.
And for AI to have a dramatic, nothing-will-be-the-same impact on software as an industry, it doesn’t need to be better than the best engineer you know. It only needs to be better than the average.
I recorded a short video: “I am the bottleneck now.” As others have pointed out, yes, I’ve always been the bottleneck. I guess I should’ve said instead: “I am a very, very narrow bottleneck now.” But the point of the video wasn’t necessarily that I can now often copy & paste text from one tool into the other and code gets written and I can push it straight up. I recorded the video because I wanted to share that punchline with the customer coming back to me and, more importantly even, to explain why I don’t think that our existing software development tooling is built for this new future. Because it’s strange to assume that with these models getting better and better, and their ability to write good code on first try improving, we’ll keep opening tickets in Linear, pasting them into an agent, having them open a PR on GitHub, only for another agent to review it, so that we can then hit merge. This whole flow was built for humans. It’s based on the assumption that code is slow and expensive to write. That’s no longer true and the tools will collapse into the new truth.
And here’s Armin, riffing on the idea of bottlenecks and how they shift in technological revolutions and what it means for software: The Final Bottleneck.
And here’s stevey with other thoughts along the same lines, the lines pointing towards where this is headed: The AI Vampire.
And here it’s the Harvard Business Review saying that AI doesn’t reduce work, but intensifies it: “Over time, this rhythm raised expectations for speed—not necessarily through explicit demands, but through what became visible and normalized in everyday work. Many workers noted that they were doing more at once—and feeling more pressure—than before they used AI, even though the time savings from automation had ostensibly been meant to reduce such pressure.”
But then here’s Cate Hall: Do Less. “In retrospect, what went wrong at the retreat was the same thing that went wrong with my reading binge, it was just the pattern repeating at a deeper level. The part of me doing the scanning and releasing — the monitoring layer, the internal project manager — was the thing that actually needed to go offline. Rather than relaxing in the relevant sense, I was using my optimization machinery to simulate relaxation at a very convincing level of fidelity while the machinery itself hummed along at full speed. […] And if your optimizing machine is still humming along, even if you are doing rest-like activities, you are not truly resting. Reading The Power Broker in your spare time, not because you are genuinely interested, but because you can’t bear to be the only person at your SF dinner party who hasn’t? Still optimizing. Cooking the most impressive dinner possible for your friends, so you can convince them that you’re worthy of love, rather than making something you enjoy producing? Still optimizing.”
More on bottlenecks: “This, to me, is the real risk. Software broadly commoditizes, with a new crop of software / value emerging. A big constraint to the development of software is engineering resources. Before the cloud, a constraint was how quickly could you stand up racks of servers to support user growth. In the cloud era that was commoditized, and engineering resources became the constraining factor (how quickly could you develop software). With AI, that constraining resource (engineering velocity) is going away.”
The o16g Manifesto. o16g stands for Outcome Engineering. “It was never about the code.”
“Those of us building software factories must practice a deliberate naivete: finding and removing the habits, conventions, and constraints of Software 1.0. The DTU is our proof that what was unthinkable six months ago is now routine.”
23 lessons you will learn living in a very snowy place. Lovely. Great writing, made me smile a lot.
Twenty Five Years of Computing. Very, very good. Twenty five years of loving computing, I’d say.
“It was May 15th, 2024. My mom’s 60th birthday. Instead of planning a birthday message, I was checking my phone for an acquisition term sheet from a $40 billion company. Unfortunately, when I finally got the email, it was not the yes or no response I had been hoping for. It took almost four years before we finally found the right buyer. I wished a book like this existed at the time. If you are going through an M&A as a founder or are curious about my journey, I hope this book will be helpful to you.” Very, very interesting. I’ve been in a M&A-like situation once and it’s shaped me and my professional outlook like few other things. What I learned is: (1) you can talk and make promises for months but nothing counts until an actual contract is signed and even then I wouldn’t relax yet (2) the bigger company can wait until you die.
Benedict Evans had a killer line in his latest newsletter: “A chatbot might be a new, different, and expanded way to handle those kinds of improved problems - it won’t replace software, but expand the space around it. In other words, there is software that is formalised, institutionalised process, and then there is software that is improvisation. You won’t replace process with improvisation - you don’t replace Salesforce with ChatGPT any more than you replace it with Excel. But there’s a lot more that you could automate if you could improvise more.”
“A first look at the interior and interface of the Ferrari Luce.” This isn’t a car newsletter and I don’t own any Ferraris, but this is interesting “because it’s the work of Sir Jony Ive, the man who steered the design trajectory of Apple” and Mike Matas and others and, well, even if we don’t and never will drive this Ferrari, this will have an effect, just like Miranda Priestly said it in Devil Wears Prada.
“But on the whole, the economic transition that AI is ushering in will be much gentler than people seem to think. COVID is a terrible analogy for what’s coming. The ordinary person, the person who works at a regular job and doesn’t know what Anthropic is and invests a certain amount of money in a diversified index fund at the end of each month: that person will most likely be fine. I don’t think they have much to worry about from AI.”
Even three months ago, no: three weeks ago, I would’ve said that Andreas’ predictions here are too out there, too crazy. Now I agree with everything he’s saying here 100%: “Is software development completely and utterly beeped?”
As someone who closes all his browser tabs many times per day I 100% agree with this: the secret to structuring your work is “nothing”. Of course, if you’re a tab hoarder, you’ll disagree. And there’s no way I can convince you to change your ways, nor is there any way you can convince me to change mine. It’s how it has been and how it will be. Our two factions, our peoples, tab closers and tab hoarders, desk cleaners and desk pilers, will exist until the death of the tab, locked into a cosmic dance, forever pushing and pulling each other, one closing and the other opening. That’s how it’s written.
Third time I’m reading this, George Saunder’s My Writing Education. It’s so very good and this line has been stuck in my head since the first reading, many years ago: “It is as if that is the point of power: to allow one to access the higher registers of gentleness.”
“Writing about ‘the obvious’ is a useful service. Often people doubt what their own experience is telling them until someone else helps confirm their suspicions and put them into words.” Perfectly put, by Simon Willison.
“Spotify says its best developers haven’t written a line of code since December, thanks to AI.” I’ve written a handful, I’d say. And: “my name is jessie frazelle and i have not touched code in an editor since october.”
Ben Thompson was a guest on Cheeky Pint and this portion here, on US vs. European companies, is especially interesting. As a German who’s been working for German companies half his career and US companies the other half, I find the analysis to be spot on: US companies focus on making more profit instead of optimizing cost and European companies focusing on optimizing cost and efficiency.
This is Kella Byte, who’s been tweeting about databases for as long as I can remember: Building A Distributed SQL Database in 30 Days with AI.
“A terminal weather app with ASCII animations driven by real-time weather data.
Features real-time weather from Open-Meteo with animated rain, snow, thunderstorms, flying airplanes, day/night cycles, and auto-location detection.”
David Crawshaw, articulating it very, very well: “Understanding is an iterative process. Write code, run, think, write some more. No-one ever came up with a design, wrote the code, compiled then shipped. Removing most of the writing radically changes that iterative loop. [Reply tweet:] Absolutely in a good way. I can have an idea, prototype it three different ways and make a call based on a real attempt to build it, in a few hours. In the old software world, we would have had a week of meetings to decide if the prototype was worth the effort.”
Thoughtworks organized a retreat “to wrestle with the questions that matter most as AI reshapes how we build software” and published a summary. There are some very interesting things in there. Nothing new to any reader of this newsletter, I’m sure, but interesting because things we’ve been doing are described very explicitly: “This middle loop involves directing, evaluating and fixing the output of AI agents. It requires a different skill set than writing code. It demands the ability to decompose problems into agent-sized work packages, calibrate trust in agent output, recognize when agents are producing plausible-looking but incorrect results and maintain architectural coherence across many parallel streams of agent-generated work. […] These are skills that experienced engineers often possess, but they are rarely explicitly developed or recognized in career ladders.”
I’m collecting some testimonials for this newsletter, because I noticed that its landing page is seriously outdated. If you enjoy reading this newsletter and it means something to you, feel free to hit reply and let me know.