A Question for the Next Author

In 2014, in a blog post that made the rounds, Dave Thomas told the people who had invented agile that the word was finished.¹ Not the idea — the word. He had watched it become a certification track, a consulting category, a noun with capital letters where an adjective used to sit. His title paraphrased a royal succession: Agile Is Dead (Long Live Agility). He had helped write the manifesto thirteen years earlier. Most of its authors had spent the intervening decade watching the thing they had named slide away from them into the hands of people who sold it by the seat-hour. Thomas’s point was that the useful part of the word was the adjective, and the adjective survived only if the noun was retired before it took the adjective down with it.

I think about that piece often, for reasons that will become obvious by the end of this chapter.

Sliday is a studio with seventeen years of receipts. In that time we have been, by turns, a WordPress shop, a mobile-first consultancy, a design-led agency, a product partner and (for the past three years) whatever the thing in this book is. We have survived multiple recessions, one pandemic, the end of the App Store gold rush, the slow death of the banner ad and the arrival of a kind of software tooling that makes the entirety of our first decade look, in hindsight, like translation work that no longer needs a translator. We have been wrong about the future in public at least four times that I can count, and probably more that David, to his credit, has not reminded me of.

This book has been an attempt to name the thing we are doing now. I called it Sculpting, because that was the verb we kept landing on in internal conversations, and because the studio’s work (receiving an over-built prototype from a founder and subtracting until it becomes a product) lent itself to the metaphor better than any other we tried. The name is a placeholder for the practice. If, ten years from now, someone reads this and calls the same work carving, or editing or whatever-the-next-verb-is, the book will have done its job. The book’s job is to point at the thing clearly enough that a better word, when it comes, replaces this one without argument.

I am conscious, writing this final chapter, that this is also the chapter most likely to age badly. Previous chapters made claims about projects we have shipped and clients we have watched. Those claims will be wrong in the ways that memory is wrong: in the detail, in the sequencing, in the compression of three conversations into one. This chapter makes claims about 2031, and 2031 has the luxury of making me wrong in ways I cannot anticipate. I am going to make the claims anyway, because a book that refuses to look past the last shipped invoice is a book that has nothing to say about what comes next, and what comes next is the only reason anyone starts a studio.

Here is the claim.

By the end of this decade, the loop from prototype to production to distribution will be executable by agents end-to-end. Not assisted by agents in the way a 2025 developer is assisted by a tab-complete model — executed by them, in the sense that a founder will describe a product in natural language, a system will assemble it, test it, deploy it, list it, market it, measure its reception and iterate on it, and the human in that loop will no longer be writing the code or the copy or the Meta ad or the App Store description. The human will be deciding what the product is for. That is the claim. It is not hedged, because hedging would be cowardly at this point in the book, and because every twelve-month extrapolation of the last three years has underestimated the slope.

The role that survives, as far as we can see it, is what we have started calling the architect of intent. This is not a job title we have given anyone at Sliday yet, and I am slightly embarrassed by it as a phrase, but nothing better has arrived. The architect of intent is the person who answers three questions that an agent cannot answer on its own: what should exist, what should it mean and what should it do in the world. Those are not specification questions in the old sense. They are questions about purpose, about context, about the values a product carries whether anyone bothered to articulate them or not. An agent can ship a rostering tool for a beef farm in forty minutes. An agent cannot tell you whether the beef farm should exist, whether the rostering tool undermines the herd manager’s dignity or whether shipping it in a country without reliable rural broadband is a kindness or a cruelty. Those remain human questions. They may always remain human questions. I am certain only of the shorter-horizon version: for the next five to ten years, they remain human questions, and the studios that survive will be the ones that treat those questions as the actual deliverable.

If the architect of intent is the role, then the methodology question becomes: what replaces Sculpting?

I do not know. That is the honest answer, and I want to sit with it rather than paper over it. I can see the outline of the problem, and I can see who is probably solving it, but I cannot see the shape of the solution clearly enough to name it. Sculpting was a methodology for the moment when the production bottleneck broke. The next bottleneck is already visible, and it is distribution.

Everyone we know who is building with agents in 2026 is running into the same wall. They can ship. They cannot get seen. The App Store, the Play Store, the Chrome Web Store, the GPT Store, the Meta ad auction, the TikTok algorithm: every channel through which a small product used to reach its first thousand users is now saturated with products that were themselves produced by agents, and the cost of standing out has risen while the cost of producing the thing trying to stand out has fallen. A studio that can ship a hundred prototypes in the time it used to ship one is a studio with a hundred prototypes and no way to place any of them in front of a human being. This is the single most common cause of project failure we have seen at Sliday in the last eighteen months, and we have seen enough of it to suspect that the next methodology — whatever it ends up being called — will be a methodology for distribution, in the way that Sculpting was a methodology for refinement and agile was a methodology for iteration.

The people writing that methodology are not writing it. They are running the experiments. They are the solo founders testing fifteen products a quarter on TikTok and watching fourteen die. They are the two-person studios pairing with creator economies to route attention to products before the products exist. They are the teams building distribution-first — starting with the audience and reverse-engineering the product from what that audience will tolerate seeing in its feed. None of them has a name for what they are doing. Most of them would be offended if you offered them one, because naming a practice is what you do when the practice stops being the thing you do every day and starts being the thing you consult on. The naming comes last. The naming comes from the person who has the time to write the book, which by definition is the person who is one step removed from the frontier.

Which is the pattern, of course. It is the pattern Thomas named in 2014 when he said the word had been captured by people who no longer did the work. It is the pattern Royce triggered in 1970 when he wrote down a process he thought was risky and watched it become the default.² It is the pattern we are participating in, right now, by writing this book about Sculpting at the moment when Sculpting is probably already being overtaken by whatever is coming next. We are a step removed from the frontier the moment we have time to describe what we saw there. I am making peace with that as I type.

What I can offer, in place of an answer, is the list of questions we are sitting with. These are the questions that come up in our Monday planning calls, that we do not resolve, that we carry into the next week unresolved and that I suspect will shape whatever the next book is when somebody writes it. I am writing them down here the way they appear in our shared document, which is to say without tidy ordering.

1. Who trains the next generation of engineers if there are no junior-level tasks? The craft of software was, for its entire history, an apprenticeship economy. Junior engineers learned by doing the small, low-stakes work under the supervision of senior ones. Agents now do the small, low-stakes work. The path from novice to competent practitioner has been cut at the first rung, and no one has yet designed the replacement rung.

2. What is the legal status of a product whose entire codebase was produced by an agent? Who owns it. Who is liable for its failures. What does authored by mean in a copyright filing when the authorship is distributed across a model, a prompt and a human who signed the work off without reading it.

3. Can a studio survive the next five years without distribution capability built in from day one? We do not think so, but we have not proven it to ourselves yet. Every studio we know is retrofitting distribution onto a product-delivery business, including us, and the retrofit is expensive.

4. What is the honest price of a product that took ninety minutes to produce but carries ninety thousand hours of training data behind it? Pricing is downstream of cost, and cost has become philosophical. We do not know what to charge for a week of work that would have been a six-month engagement in 2019, and our clients do not know what to pay. Both of us are guessing.

5. When an agent ships a regression into a live production system at three in the morning on a Sunday, who is on call in practice. Whose phone rings. What is their title. What did the studio hire them to do when they were hired last year, and is that still the thing the studio needs them to do.

6. What does a portfolio mean when every case study in it could have been produced, in eighty per cent fidelity, by a competing studio that did not do the work. The portfolio was the proof of craft. The proof of craft now needs a different proof.

7. What is the smallest number of humans a working software studio can have and still do honest work. We used to think the answer was around eight. We then thought it was around five. Last month, on a Tuesday call that ran twenty minutes past its hour, David said three and I did not argue. I notice I want to argue now, writing this. I am not sure which of us is right.

That is the list. It is also, not incidentally, the brief for at least the next three years of Sliday’s research work, and if any of those questions resolves cleanly we will almost certainly write about it. If they do not, someone else will, and that person will be the one doing the work rather than describing it — which, as established, is how this goes.

The farmer in the opening reconstruction sends a napkin with three circles on it, and the studio turns that napkin into a specification. That was a real job and it lasted a decade and a half. The napkin changed. The job changed. The farmer sends a repository now, and the repository will, before long, send itself. Somewhere on the same South Island there is, I suspect, a younger version of me taking a brief from a younger version of Murray, and neither of them has read this book, and neither of them needs to, because the work they are doing will generate its own vocabulary in its own time.

The question this book opened with was: what is the studio for, when the translation is no longer the business. This book closes with the same question, asked one layer up. What is the profession for, when the translation, the production and the distribution are no longer the business. I do not know. I suspect the answer involves the word intent and I suspect it involves a smaller number of humans doing a different kind of work and I suspect the person who will write the next book about it is, right now, too busy running the experiment to notice that they are the author.

Every methodology eventually becomes the obstacle it once removed; ours will too, and we hope to be the first to notice.