In his talk “AI Writes the Code. So What's Left for Engineers?” at the AI Engineer conference in New York, Laurie Voss, head of developer relations at Arize AI and co-founder of npm, argues that coding agents made writing code nearly free, so the bottleneck keeps moving: first to code review, then to developer operations and system security, and will eventually stop where agents cannot succeed: finding out what people actually need, and defining what “good” means. He tentatively calls this final task for humans “product engineering”.
What's left is finding out what people actually want. Every piece of software is a formalization of something that a human wanted to get done. So if a customer tells you, I need to keep track of my orders, there are 10,000 pieces of software that keep track of your orders. That's what they do. But only one of those, if you're lucky, is good if the thing that you're doing is you're running a bakery. If you're running like an auto parts store, that's going to be different. If you're running you know, a giant manufacturing concern, it's going to be completely different...
The whole job is figuring out what exactly do you mean when you say that you want to keep track of your orders. What does that mean for your business? What does it have to do? How does that work? And that knowledge isn't in the training data. It isn't in the weights. It is in the mind of the person who runs that business. And the only way to get it out is by flapping your meat parts at them and having them flap their meat parts back. You have to talk to them. That is the only way to get the information out.
So the bottleneck moves to describing the problem and defining what it means to have solved the problem. And my big bet for this talk and for the next 10 years is that is where it stays.
Fred Brooks who ran IBM's System/360 project and wrote The Mythical Man-Month he wrote about this in 1986. He split the difficulty of software into two kinds. Accidental complexity is the difficulty of the tools or the languages, the typing, the syntax. And then there's the essential complexity which is the difficulty of the problem itself. And he predicted that no single tool would make us 10 times more productive because the essential part is the hard part.
I humbly suggest that methodologies such as Event Modeling and of course Engaging’s own Business Operations Notation and Development (BON/D) are such tools. They break down the essential complexity of the job at hand into articulate steps.
Sean Grove from OpenAI ... said that code is a lossy projection of the specification, and whoever writes the spec, if it's a PM or a lawmaker or an engineer or a marketer, they become the programmer. And so writing down what good means is where the value is now.
BPMN is another such tool, developed in order to let developers and business owners communicate clearly about the system. And of course, although Voss doesn't mention DDD in his talk, Domain-Driven Development is all about developing the Ubiquitous Language, the little culture that forms when, as he puts it, developers and business owners flap their meat parts.
Voss worries however that this may be thin gruel for software developers of the future:
So if all of that happens, there's one big thing that I don't want to just gloss over or handwave away, which is a lot of people got into programming because they love the craft. They love a clean abstraction, the feeling of a hard bug finally giving up, making a machine do exactly what you told it to do. They did not sign up to interview bakers about what they want in their lives.
This seems however not to describe more senior and Domain-Driven Design (DDD) developers, who very much value the discussion they have with their clients in order to figure out what to build.
Secondly, there remains much to develop. BON/D articulates the components of developing this way into three types of modeling:
Role modeling designs the organization
Object modeling designs the items being acted upon
Port modeling designs the canvases where the operation occurs, which are complex, and expressing these requires as much creative logic as ever.
Voss presumes the demand for software is only going to increase (and history suggests that this is true):
So assume that we can make as much software as we want basically for free and that the appetite for making software is essentially infinite. That is a wonderful situation in which to be in. We've got infinite demand and also suddenly infinite supply.
What's needed to satisfy this demand is Domain-Driven Design developers:
in the 1960s, there was a job called the systems analyst. Their job was not to write code; their job was to talk to the business and find out what the problem was. Then that analyst turned into something that we call a product manager today, and we've had two professions where there used to be one and a half. I think what is happening is they are collapsing back into one.
BON/D seems an important method for this future.