Preface
illustrationAs I write these lines, in the next window a program I did not write is rebuilding another program I did not write either, and every so often I glance over at it the way a homeowner glances at the man rehanging the wallpaper: the walls look straight, the corners are where they should be, nobody has papered over the sockets, and there is no reason to interfere until the man reaches for a load-bearing wall and says “it’ll feel roomier.” Five years ago this scene would have been science fiction. Today it is the working routine of hundreds of thousands of people, and most of them, as far as I can tell from conversations, still have not decided whether to celebrate or to start looking for another profession.
In 2024 I was still reworking a large server program written in Nest.js as one solid block, and in that job AI was a helper that suggested lines and now and then wrote a whole function. On the second of April 2025 I was testing a Telegram bot assembled from ready-made parts: a language model, the LangChain library, which teaches a model to use tools, the Composio service, which gives it access to other people’s programs, and Kommo, an ordinary CRM where a sales department keeps its customer cards. At my request the bot went to Kommo on its own, and a few seconds later a company called INITE appeared in a real CRM under number 200794, along with a contact named Ivan Ivanov under number 200800. Nobody wrote a single line of code for this: the model simply did what a sales manager used to do by clicking through a form.
Then the bot tried to fill in some extra fields on the company, and everything fell apart on the format of a single string. It tried again without those fields, and the attempt went through, except that the link between the company and the contact that I had counted on never appeared. The error was trivial, but it was a new kind of error: a program nobody had written changed the state of a real system, did it halfway, and now the database held records that looked correct and were not. Sorting them out fell to me.
That small thing already contained almost everything this book is about: what happened to software development when machines learned to write code by themselves, and why people drew from it the conclusion they should not have drawn.
Let me start with the fact that for sixty years the programming profession was built around a single inconvenience, which everyone mistook for its essence. A person had an idea, say, “let the bank take the utility payment on the fifth, and if there is no money, let it wait until the tenth and send a polite letter,” and that idea had to be translated by hand into a language the machine understood, line by line, with semicolons, brackets and variable names that six months later not even their author could decipher. The translation was slow, expensive and required special training, so a huge industry grew up around it, with courses, interviews, salaries and jokes about programmers turning coffee into code. From the outside it looked as if programming simply was this translation, since that was where most of the working day went.
Language models brought the cost of translation down to zero. Now it is enough to explain the utility-bill idea to the machine in ordinary words, and a minute later it hands back a few hundred lines that will most likely even run. From this people concluded almost at once that now anyone can program, and the conclusion is repeated from conference stages, in advertising and in conversations with investors with such confidence that you would think it had been proven.
In practice the opposite happened, and the whole book is essentially an explanation of why. Once writing code became almost free, the scarcest thing turned out to be the ability not to write anything superfluous: to understand which of those hundreds of lines are needed at all, what they will break next door, who will answer for them a year from now, and what happens when the bank takes the utility payment twice because somewhere deep in the system a repeated attempt to send a payment looked no different from the first one.
This book is written for people who do not write code and perhaps never have. My starting point is simple: programs have long been in charge of your money, your car, your medical records and what you are shown in your feed, so the question of who makes them now, and how, concerns you about as much as the question of who now builds the bridges you drive across. There will be as many technical words in the text as cannot be avoided, and I will explain each one the moment it is first needed.
My material comes from two sources. The first is other people’s research, reports and experiments, and wherever I rely on them it will be clear what exactly I am relying on. The second is my own practice: for many years I have been assembling software systems, in recent years mostly with the hands of machines, and a good part of the book grew out of mistakes I managed to make before I read about them in other people’s papers. I will try to say plainly where the data ends and my opinion begins, so that at any moment you know what in this book you can take on trust and what you should check for yourself.
The road runs like this. First I will show where today’s way of writing programs came from and why its first results are so intoxicating. Then, where it breaks, and why it breaks at the point where responsibility enters the picture. After that comes a conversation about how to build an environment in which a machine can write code unsupervised without wrecking everything around it, how its memory works, and what happens when programs start repairing themselves. At the end the question of people remains: what will become of those who used to write this code, and where will masters come from at all if an apprentice no longer has any reason to practise.
The title of the book sounds like a provocation, and in the first chapters it will be one. By the last ones, I hope, you will be convinced that it describes the state of affairs literally: code has not gone anywhere, and more of it is being produced now than at any time in history; it is simply that writing code has stopped being the main event in software development. The main events have become decisions about what must not be done, checking what has been done, and responsibility for how it turned out.
Development begins where writing code ends.