Everyone who can brief an agent is a developer

One of the most frequent comments I got when I talked about the first edition was: "I like the concepts but I'm not a developer/programmer!" I wrote that line into a draft chapter in 2018, and my answer then was blunt. Every company is a technology company, I said, so refusing to learn to code was a career-limiting move, and all professionals needed to know how to code, especially the ones in science, technology, engineering and maths.

I was right about the direction and wrong about the door. In 2018 the way in was Git, version control, spreadsheets, automation, even Slack. I was giving advice, and the bar of entry was very high. Now it is very low. If you run a team, a ward, a shop or a department, and you have never written a line of code, this chapter is for you. So is it if you have spent twenty years inside a profession and are about to start a company on what you know. The definition of developer has widened and you are already inside it.

Craftspeople make their own tools

The reason to become a developer is not a job title. It is that you have to become a craftsman or a craftswoman: you have to build things. We have to go back to how things were, when craftspeople made their own tools. In the past it was out of necessity; now I would argue it becomes the same again, because of customisation. The tool that fits your work exactly is one nobody else is going to build for you.

That draft chapter from 2018 tried to draw this as a tech stack per generation. For the generation before mine the toolkit was a brain, a pen, paper and a scientific calculator. For mine, spreadsheets, a computer, a mobile, the internet, email and a data centre joined the list. For yours, I crossed most of those out and wrote "AI and ML" and, as a note to myself, "voice". I never finished the chapter. I think the picture was right, and I had the wrong idea about what you would do with the new layer. I thought you would program it. It turns out you brief it, and the brief is in your own words.

Which is where the spreadsheet comes back in.

The spreadsheet grown up

People have always built software with whatever they controlled, and for most of them that was a spreadsheet. A spreadsheet is a user interface and a database in one file, and the business world runs on them, errors and all. The newsroom collected the evidence in The citizen developer is good news. In Raymond Panko's audits, "Of 54 spreadsheets audited between 1997 and 2000, no fewer than 49 were found to contain significant errors". JPMorgan's London Whale model ran through spreadsheets that at one point "divided by their sum instead of their average". In October 2020, England's test and trace system lost 15,841 positive cases because an old Excel format "limited the number of rows to 65,536".

Those are not arguments against the people who built them. They are a testament to how badly technology served them: the spreadsheet was the only tool they had that they could change themselves. If you have ever kept a rota, a budget or a stock count in a spreadsheet because IT would take too long, you know exactly why.

Now those same people can build full applications, with a real interface, real data and real logic. At a conference someone called them "citizen developers", with the tone people use for a problem: employees outside IT building things IT will have to clean up. I think it is one of the best things to happen to software in a long time. And it is not only citizens. It is the employee developer, the business owner developer, the expert in a domain that technology has served badly for decades, building the thing they actually need. That last one is the founder this book is for: the person who has spent twenty years inside a problem and can now build the first version of the answer themselves, with agents, instead of explaining it to a team they could never afford. As the newsroom put it in The expert founders, "Execution just got cheap." The citizen developer is the spreadsheet grown up.

Portuguese is a programming language

In June 2024, in Lisbon, I opened a talk with a quiz: what is the sixth most powerful programming language in the world? The answer was Portuguese. "Since data is now code, and GenAI prompts are written in natural languages", Portuguese, like English and every other language in the world, dead or alive, can be used to give instructions to a model, to define actions, workflows and applications. With 236 million first-language speakers, that is a lot of programmers. The newsroom wrote the talk up as GenAI in Portuguese, 2024.

I meant it as a joke with an edge, and two years later it is simply how things are. The language you already speak is the one you program in. If you are very good at explaining what you need, which is what running a team teaches you, you have the hard part of the skill already. What Lenses, roles and loops described, a prompt as a lens and a role as a description, is written in plain language, and so is a brief.

That is why this edition kept the word developer in its title. When I planned it, I asked whether it should be Generation Z Developers or Generation AI Developers or Generation Z professionals. I like the word developer, and I think it is more right now than in 2018, because this generation all have to be developers: they all have to create. Then the readers became two generations. The entrepreneurs I see starting companies are mostly from my own generation, Generation X, the subject-matter experts, often the parents of the Generation Z readers I started with. They are developers too: they are coding, with agents. Together they are Generation ZX, which Gen ZX: who this book is for, and what it is for explains. The oldest of the Z half were 22 when I wrote the first edition, and are 30 now. Anyone who can brief an agent to build something is a developer: the graduate, the manager who has never coded but knows exactly what her team needs, and the expert of twenty-five years who knows exactly what the product should do and has been telling vendors so for a decade. The last two have the hard half of the skill already.

The first edition had an outline for a chapter on Scratch, the visual language children learn with, and the bullets said it was a great way to learn programming concepts, by building a couple of games. I still think so. But the first programming concept you need now is not a loop or a variable. It is a clear description of what you want, and a way to check whether you got it.

What the briefing-only developer cannot do

I have to be straight with you about the other half, because the door being open does not mean the room is empty.

A working application built by the person who needs it is the best brief ever written. It says exactly what the user wants, what they do first, what they never use, and what matters to them, without anyone having to guess. But that is also where the mistake people make is: treating the brief as if it were already a product. A working app is not yet maintained, secured, documented, tested, versioned or able to scale. Those are the non-functional requirements, and the explorer who built it never had to think about them. Security, reliability, observability, cost, documentation, support: this is the work of the villagers and town planners, and Explorer coding, not vibe coding, and the handover is about getting it to them.

So here is what you cannot do if briefing is all you do. You cannot tell whether the thing you were handed is safe for other people to rely on, because you cannot read the record it left. You cannot tell a working prototype from a maintained tool, and the two look identical on the screen. And you cannot check the agent's work against anything but its own account of it. For a manager, that gap is a risk to the team. For a founder, it is a risk to the product and to the customers' data, from the first customer onwards. Most of what follows in this book, from Facts, evidence and the record to Controlling your agent: RiskMandate, exists to close that gap, not by teaching you to code, but by teaching you to ask for the evidence and read it.

It is still your name

The last thing, and the one I would put on the wall. It is still your responsibility. It is still your name; the work is still done under you. This is not you delegating your thinking to generative AI; it is you thinking with generative AI.

The first edition had an outline called Thinking as programmer that I never wrote; it had one bullet. I can write it now in a sentence. To think as a programmer is to say what you want precisely enough that something else can build it, and then to check that it did. You have been doing the first half for years, every time you explained to IT what your team needed and watched them build something else. The second half is what the rest of this book is for.

And sometimes, as I always say, it is about using generative AI so that you do not have to use generative AI: using it to write the script or the tool that then does the job reliably, without a model in the loop. The craftsperson makes the tool. The tool does the work. That has always been the point.