Bold Predictions

What is technology, what is talent, what is effort and what is discipline?

Decomposing each and having a mental model on how they interact with each other and the feedback loops helps us better predict the future when we assume a big change in one of them.

Let’s start with a talent anecdote that helps us with discipline. In 2000, ESR wrote Linus a long email about the curse of the gifted. Linus was so talented and rewarded by that, that he was lacking the discipline that lesser mortals must develop to get barely close to his level of craftsmanship. Then the problem kinda outgrows the talent and the adjustments arrive very late and very hard. Often, the lack of adjustments puts a ceiling on development or the hard adjustments themselves kill it.

All of a sudden, technology advancements make us feel very gifted, because we are able to do things in a way we were never able to do before. It is important to notice that we are all feeling gifted, but not everyone is gifted. Nobody can teach talent, but we can develop technology, coach effort and performance and install discipline and best practices.

One morning my young daughters woke me up earlier than usual… somehow, I was already in the middle of checking on the Claude run from the previous night, and I brought them to the office and improvised doing two things at once, putting Claude to work on a new game designed by the three of us and while that ran, check my actual work sessions.

They loved the idea, they wanted something with a unicorn, ice creams, chocolates and some rainbow stuff. Without much thinking, I made it as an HTML page and added to my company website project. They loved playing with it and then the other day they decided to tell the nanny about that game and I showed her. She loved it and wanted to play with her granddaughter too, so I promptly shared the URL with her and off we go.

Well, they didn’t see the plumbing and I only realized that later on, but the game landed on a deploy system I had built weeks earlier for my own site, you push an HTML page into a folder and it gets a URL after clearing the CI/CD steps there.

Software is harder than any other kind of engineering because it is much easier than the other types in one specific dimension: iteration speed. For instance, a bridge takes years and materials that cost a lot of money, so the people who build bridges cannot afford being wrong while the software project artifact (code) and the deployed software artifact sit much closer together.

Fred Brooks saw it fifty years ago: the programmer, like the poet, works only slightly removed from pure thought-stuff, and builds his castles in the air, from air. Agents made the creation of the project artifact much cheaper than before and made the deployed artifact even closer to the ideation process.

A few weeks ago I built a machine learning model with no design at all, just to see what came out, and it came out fast. Three weeks later I had a big ball of mud, the famous architectural pattern from the last century, the agents were getting lost all the time and no progress was being made, literally no amount of token was saving me there.

I took a step back and did a proper design with semantic data modeling and a concrete project organization and started refactoring everything, what each thing means and what each stage does, into separate repos with a harness. I guess that if you are mindlessly vibe coding, your system is probably a few weeks from the same place, and there will not be enough prompt engineering to rescue it.

In Wrong, Faster I said that the next doctrine cannot be written until the tech settles and in Zero-Based Doctrine I provoked you to audit the inherited premises one at a time. The nuance that I want to put is that the doctrine can’t be settled early, but it can and should be exercised early.

What follows is what I believe survives the upcoming crashes and that will be widely adopted in three to five years. As always, high conviction but very open to being wrong.

1. We go back from agile to waterfall, but without retroceding. Some agile principles might survive, but rituals will definitely change. Agile practices emerged when the main loop was coding and executing, and the rituals surrounding it helped teams better deliver the downstream work. Where we are going, there will be a higher emphasis on designing, planning, reviewing, deploying and operating. The first three will take as much time and attention as executing and coding, while the last two will be moved off the main software development loop (but still part of software engineering).

2. Git and GitHub expire. Git was made for humans, in a different world, with a different idea, a transaction log with a few operations and no model of what anything means. GitHub was built so humans could look at each other’s code. Agents need an evolution of both. Whatever replaces them will still have a trunk, and the trunk will not need to be always green. What we care about is deploying correctly and being able to get back to a known-good state whenever we need to, probably through an agent whose only job is bringing the codebase back to green and handing work back to the others. I don’t know yet.

3. Continuous delivery dies for a while. Every change flowing to production on its own made sense while a human had looked at it first. Deploys get more sophisticated instead. Business metrics get checked on the way out, canary and blue-green evolve well past what we do today, and a deployment engineer or an SRE watches it happen. Automated deployment with sophisticated rollout is a different thing from continuous delivery.

4. Tests get written by agents, for agentic development, not for humans. Tests were always there to give humans confidence. Some of us wrote them first, to pin down the behavior and the corner cases before the code. Some of us added them to an old codebase so we could refactor it without changing what it did. They stay important, and especially for agents: an agent can change things in a local context and use the suite to make sure nothing else broke. But when the agent is the one writing the tests, it is mimicking a human need it does not have, because that is what the training data showed it. The two will diverge. Tests will end up serving what agents need first, and humans only at a higher level of abstraction. Humans will care less about tests and more about a different set of tools to guarantee behavior. Maybe prompts, harness and context turn into a spec, and the tests get generated from it.

5. Tokens become the default for estimates. We never had tokens before. They measure complexity better than lines of code ever did, still not perfectly, and they are a very good proxy for cost and time in the execution phase, but each working unit has its own pace transforming tokens into output. Tokens are what story points were pretending to be. Estimates get more precise.

6. Design, planning and review become their own steps. Coding used to hide the three of them inside one activity. Most of the human time now goes to those three, whether one person does all of it or three people do, and each step uses AI anyway. The better the design and the plan, the less review you need.

7. No more sprints. No more standups. A sprint batches human attention and a standup syncs human state. Teams get smaller, the state lives elsewhere, and there is less attention to batch. Syncs happen when something needs one. A recurring ritual is a meeting nobody decided to have.

8. One-pizza projects. Three or four people, assigned for as long as the project needs them. The team used to be where the context lived, which is why we kept them together. The context is moving out, into a memory layer derived from the interactions, the repo, the harness, the documents, the meeting transcripts, every artifact the company produces. Developers become fungible. The person who knows why the business does what it does is not.

9. You build it, you run it recedes. Deploying and monitoring go back to NOC and SRE teams, and that becomes much more common than teams running what they built. As teams that are building become fungible and lose project context, it becomes pointless to keep that DevOps trait alive. Code always has a known-good state to go back to, but production is machines, the network, broken external dependencies and outages, where a bad enough move may have no way back. The risk asymmetry is much higher and we need operating teams with context to tame the entropy in the wild.

10. Harnesses compose in layers. A generic one, one for the type of project, one for the domain, and you compose them. Reusing a harness is a mistake because each project has to be its own. The shareable marketplace harness is the wrong bet, and the people selling it know that better than the people buying it.

This is not me trying to be Nostradamus, but putting a strawman out there and starting a conversation to see which doctrines and changes are already emerging and which ones we should be intentional to try out.

So, if you had to bet, what does the future look like a couple of years from now?