Don't Be Careful, Be Competent
On the fallacy of "writing code is low level thinking", the ability to get things done, and the Faustian bargain of vibe coding.
Near the end of Mission Impossible: Dead Reckoning, Tom Cruise is about to do a scene so outrageous that will have a lot of people howling in the theater.
In his crusade to destroy the Entity, a sentient AI, he’s got to jump into a moving train and rescue one of his teammates. This time, however, as he gets closer and closer to the train on his motorbike, he arrives at the edge of a cliff, and is told to use his parachute, and jump.
So, he jumps.
If you’ve watched the behind the scenes, you know that this scene is actually more scary than it looks. It is arguably one of the best stunts in cinema history: a motorbike jump off a cliff into a base jump. The cliff is real, the motorbike and the parachutes are real and, of course, the stuntman is Tom Cruise himself.
He said he wanted to do it since he was a little kid.
There is something gripping about the Mission Impossible franchise or the Jason Bourne saga that other action movies like Fast & Furious or Mad Max can’t simply replicate.
Yes, there’s impossibly high stakes, cars racing and explosions in all of them. But you can measure the emotional difference of leaving the theater after watching Tom Cruise jump of a cliff, or climb the Burj Khalifa, and after watching Vin Diesel “drive” a sportscar from one of the Etihad Towers to the other.
The difference, of course, is that you can believe the former, but not the latter.
I don’t want to argue that there’s one type of action movies that are “better” than others. Leave that to Rotten Tomatoes. What I want to persuade you is that there is a kind of action movie that’s impossible to replicate by others, no matter how much money, technology or people you put into it, and that this difference is precisely what make these movies unique and immediately recognizable by the broader public, while the others blur into a cloud of sameness (“was this movie before, or after Paul Walker’s accident?”).
Having spent huge amounts of money on a movie, the outcome is vastly different when the work involves some member of the staff saying “Vin, look focused and angry behind the wheel, we’ll do the rest”, or Tom Cruise laying out his plan to the safety guy, getting some push back from him, then getting a new safety guy.
The difference boils down to the creator’s vision.
Weirdly enough, software engineering has been drifting away in a similar cloud of sameness for a long time. Since the 2010s, virtually all software engineers work under the umbrella of Agile and Lean methodologies, and nowadays the only effective difference between the large enterprise and the small startup is that the former has more ceremony, and the latter has less people.
This, however, is ripe for change, now that there’s a machine that can write code for us.
The invention of LLMs and coding agents has, for the first time in history, unlocked the possibility of one-person teams. Just as cloud computing allowed companies to avoid buying servers upfront, LLMs allow them to avoid hiring large engineering teams upfront, keeping headcount small, reducing coordination overhead, and minimizing the need for middle management.
However, much like the first news program on television were just someone repeating on camera what they had just broadcasted on radio, early adopters of LLM have focused on replicate the human scaffolding of enterprise software organizations into their own workflows. These “AI-native” companies “hire” agents and give them tasks to do, and use “loops” as the artificial equivalent of middle manager, whipping and “harnessing” the agent until the task is done.
It is tempting to put distance between you and the code that makes your product. Coding is, after all, mentally demanding, and we know from the work by Kahneman and Tversky that humans are repelled by mentally demanding work.
The promise of a machine that can do the low level thinking for us is too good to pass on.
Still, you must still write most of the code yourself. Not because LLMs don’t deliver; they may very well do. But because the writing of the code is the highest level of thinking you can make.
What you have to do isn’t to let the LLM run amok, and build the tooling around it to prevent bad things from happening. What you have to do is, for the first time in software history, be in total control of a software system no unaided human can build on their own.
Tom Cruise has a saying that deeply resonates with this:
Don’t be careful, be competent.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. This is the only newsletter on Earth tailor made for the engineers who build money software. And in these engineers’ minds, the most important question right now has to do with this brand new machine that promises to take most code-related jobs, and leave the rest unrecognizable.
My gut tells me that this is just marketing. If your company decides to fire you on the grounds that AI can replace you, they’re either wrong, or commanding a ship that will be automated away by somebody else. Which means that, in the end, you were better off leaving the company anyway.
Building software will always be an activity that requires humans, just like ChatGPT has eliminated the stock photograph industry, but not photographers. The reason isn’t that there’s something called “taste” that can’t be replicated by machines (most people have Big Mac levels of taste about many things), but because using LLMs to replicate enterprise software organizations won’t give you enterprise levels of success.
Let me tell you why, and what you should do instead.
From Zero To One
“What is morality?” she asked.
“Judgement to distinguish right and wrong, vision to see the truth, courage to act upon it, dedication to that which is good, integrity to stand by the good at any price. But where does one find it?”
The young boy made a sound that was half-chuckle, half-sneer: “Who is John Galt?”
— Ayn Rand, Atlas Shrugged
Peter Thiel’s book Zero To One: Notes on Startups, or How to Build the Future made a profound influence on me when I read it, about ten years ago.
On a superficial reading, Thiel’s claim simply echoes Christensen’s concept of disruption from The Innovators Dilemma. Thiel’s point, however, is much deeper than that: Zero to One is a book about the practical aspects of building a company meant to disrupt an industry, from the kind of ideas that are “disruption material”, the kind of founder, the kind of funding, the kind of business model, the kind of team.
Thiel’s argument is that only the startups that are weird and absurd to the general public can succeed. That heresy is the point.
This article is the application of such thinking to LLMs: the AI-native companies that will succeed will have their engineers writing the code by hand.
That’s because the real obstacle between a company and the ability to create value has never been speed to market, or productivity. In software, the biggest obstacle is, and always will be, the gap between what the customer needs, and is willing to pay for, and the implementation of a product that satisfies that need.
Speed has always been a catalyst. A company gathers feedback from a potential customer, and the race is to nailing down a product that satisfies it. Because of the dynamics of disruption, enterprise companies won’t even address that need: these are not the customers they’re looking for. That’s what give startups a chance to succeed (and why only heretical companies can eschew competition from incumbents).
So the race isn’t against enterprises, but against other startups. But the thing is that it isn’t really a race on a defined track, but a treasure hunt in the dark. That’s why Medium, with a 5 year head start and millions of dollars in the bank was brought to its knees by Substack: Medium was trying to become another New York Times; Substack wasn’t.
Agile may finally be dead, after all
“The F-18 Natops. Contains everything they want you to know about your aircraft. I’m assuming you know the book inside and out.”
“Damn right!”
“So does your enemy.”
What’s changed is that, now that there’s an LLM out there, and that everyone has it, undifferentiated software won’t cut it anymore.
The software products that will win have a point of view. A vision, coherent from the top down. A single, unified mental model of what the customer needs, and how and why the product address that need.
Let us call that conceptual integrity.
Conceptual integrity, a contribution from Brooks’ Mythical Man Month, makes the product easier to develop and easier to use. This integrity pervades every decision in software, down to the line of code. And you haven’t heard of conceptual integrity because it has been remarkably absent from Agile discourse.
In other words, Agile is all about collaboration. Which sounds like a good thing, but it really isn’t. What you want instead is having as little collaboration as you can get by.
The only reason you need to collaborate is because you can only build so much of the product in a given time, up to some standards, and maintain those standards.
But now that there’s a tool that can help you build and understand the code you write, the threshold of collaboration you need has gone down, sharply. To the point where Agile may be actively harmful to the interests of a company.
Maybe you shouldn’t be token-maxxing, but sense-making-maxxing.
The Real Villain is Convenience
Fidelity to a coherent vision about a software product, all in the head of one person, may now be possible.
What stands in your way is your own unwilligness to get down into the trenches and understand the code, line by line, aided by some new piece of technology that could make that understanding faster. Not to engage in the kind of apathy and disengagement that comes from the fact that someone told you that there’s a thing that can do it for you.
That’s the mission, should you choose to accept it.
I’ve always seen every piece of technology as a Faustian bargain, some smaller and some bigger. We use our GPS to orient ourselves, and have given up on having a sense of our surroundings or engaging with strangers (something that used to give some quirky flavors to our holidays and make for good anecdotes later). We use search engines to ask questions, failing to curate our own sources of information, failing prey to lies and deceit.
Technology is what can, and will, be enshittified.
Another approach to build software
I encourage you to keep writing code with your own hands, to keep reading the docs yourself, and to spend your time focused on the minutia of functions, methods and classes.
You’ll quickly notice, as I have, the following.
First, you’ll reengage with your job in a way that you didn’t noticed you were missing. You weren’t that productive to begin with, because the off times between writing the prompt and looking at the outcome were spent on your phone, on Slack, or drinking coffee. There’s nothing as joyful as being engaged on a single, well defined task of moderate difficulty, making progress, and seeing it to completion. What’s now well known as flow.
Second, you’ll noticed over time that you’re more knowledgeable than your peers in some area of the product in a way that’s richer and more nuanced. Obviously, it is a consequence of the fact that they’re letting AI write the code for them, and you don’t. It could be a remark you hear yourself saying on a meeting, an edge case they’ve overlooked, or a solution to a problem they didn’t consider because of some seemingly disconnected parts of the system. You’ve earned it: it’s your time to shine.
And third, you’ll realize that you’re actually in a better position to prompt the machine for suggestions. You’re behind the wheel, ready to reengage with the LLM for brainstorming, rubber duck debugging, and review, but not delegation.
This, in time, is how software engineers will work. There’s simply no way around it. The rest will burn out from the inhumane task of prompting prompts to prompt prompts all day long.
Is the software engineer industry going to change? No doubt about it. But it isn’t going to look like Fast & Furious, with ever more technology creating ever more unimaginative slop.
It’s going to look more like single humans, on a motorbike, with a parachute on their back.
Ready to jump and see what happens.
This was it for this week in The Payments Engineer Playbook. I’ll see you next week.