Dispatches.

For more than twenty years I had long hair, and it is no secret that I am a metalhead. After my two kids were born, my playlists got closer to Baby Shark, Ms. Rachel and Galinha Pintadinha than to anything with a double bass pedal, so the title of this post is aspirational in that regard.

Jokes aside, if you are working at or investing in cloud infrastructure (and supply chain), be careful with how you provision future workloads. Software is getting closer to the metal, training won’t grow forever, and the AI race will end up with a couple of winners.

Since the early days of the AI rollercoaster, the doom around SaaS has been loud: the application layer is dead, SaaS is over, the agent eats the UI, and the software company is a thin wrapper waiting to be deleted unless it owns proprietary data and is the system of record. Some companies will die, but it was never going to be a mass funeral. The application layer is being rebuilt by incumbents and new players, and as it is rewritten, many will go for latency, performance and cost, with better abstractions moving up to the prompt and leaner runtimes underneath.

Before vibe coding was a thing, many programmers used higher-level languages to move faster in product development and correctness, often at the expense of performance. As the abstraction layer for programming moves from the programming language into the prompt, the runtimes and languages will often be picked by performance profiles and how good they are for agentic development.

At the same time, it is obvious that we are in a general compute boom. The frontier labs are training, everybody is inferring, and a whole generation of vibe-coded companies is running code that is very unoptimized for performance, cost and scale, but very optimized for PMF velocity and scaling adoption.

The financing of all that is nothing but insane, with big tech, big chip and big cloud kinda trading cash for equity in the future valuations of the big labs, and selling subsidized tokens to everyone else.

OpenAI closed the biggest private raise in history this spring, is back for more at a much higher price before the year is out, and is racing Anthropic to the public markets. Bullish on the big ceiling, are we dead yet?

Now suppose the race settles sooner than the capex assumes, with open models closing the gap behind the winners. What does that do to all the silicon that was bought for the race?

Nobody wins a price war, but the playbook has always been to play the price war with VC money, earn big scale adoption, and then enjoy the monopoly/cartel structure and start extracting the profits.

What I really have to ask is: who is making a profit right now? How can open models be so good? Who is paying for them? It kinda feels like Big AI is running a Ponzi scheme, or circular financing if you want to be polite: a cost war instead of a price war, with the cost financed by Big Cloud and Big Chip.

We have seen this movie, and it doesn’t end well for the main cast (tu-dum-psh). Between 1998 and 2001 the telecoms laid far more fiber than anyone could use, by 2002 Global Crossing and WorldCom had gone bust, and the dark fiber they left behind made bandwidth nearly free.

YouTube, Netflix and others were built on the losers’ capex. The competitors all lost and the future generations and companies reaped the benefits of that cost war. Similarly, when the training race settles, GPUs won’t disappear, they will just get cheaper, even if they age faster than fiber and need a power line to be worth anything.

This time is different, I hear: demand first, capex paid in cash instead of junk bonds. Fair, but how much of that demand exists without the subsidized tokens?

In the previous decades, “Intel made chips faster and Microsoft made the software slower” while many midsized-to-large companies heavily tuned database performance because the workload needed to fit in the box they had. Years later, with the cloud, sysadmins and DevOps engineers decided it was easier to upgrade from a 2xlarge to a 4xlarge instance than to talk to the Dev team.

But, when the cost to change dramatically reduces and there is less hand-off involved in the process, more changes come, in languages, platforms, hardware, stateful components and architecture.

ScyllaDB rebuilt Cassandra from Java into C++ for 10x the throughput, and it took a company and years. Many others rewrote the runtime instead, like Facebook famously did for PHP with HHVM and Google for JavaScript with V8, and got a few x too.

Now Astral rewrote the Python tooling in Rust and got somewhere between 10x to 100x, and Mojo launched initially as a Python superset with semantics inspired by Rust and performance from being built on MLIR. I think Mojo is super interesting as it gets closer to the metal using one of the most popular programming languages for vibe coding as its basis, combining performance and access.

At Nubank, we moved from native iOS and Android to Flutter to avoid paying the development and maintenance cost twice and the tax of managing feature parity and potentially divergent products in the codebase. Almost a decade later, DHH announced six native apps from a tiny team as all the aforementioned costs got much cheaper now.

The cloud never sold cheap hardware, it sold Opex instead of Capex with reduced complexity and people cost, and that is why many moved their datacenters there. A few moved back, like Dropbox, because almost all their value prop was based on storage.

A friend told me over lunch in San Francisco, unprompted: “I hate the cloud, I love bare metal”, and he is not alone. Oxide had the foresight and is a couple of years ahead of what is coming, and TinyCorp is after the same idea from the other end, a box on your desk instead of a rack in your datacenter.

Windows servers to Linux happened everywhere (pushed by licenses, security concerns and management simplicity). Amazon spent years getting its own business off Oracle and only turned off the last database in 2019.

Most veterans in software engineering know that optimizing the runtime, bits and bytes, matters less than fixing a bad architecture. Vibe coding is about to produce a big wave of bad architectures that will demand more capacity, not less, and the naive vibe coder often ends up with something less optimized than before, with a lot more people building that way. The difference now is that fixing the architecture and migrating to improve it got much cheaper too, without necessarily changing the runtime.

Truth is, they are all huge migrations that take a lot of intentional stubbornness to get to the finish line instead of letting the initiatives die off. Big migrations used to fail for lack of the discipline to persist through years of fatigue, headwinds and freaking Pareto.

I am a pragmatic guy and the 80/20 rule is useful for many many things, but definitely not for the long term. Do the math and you will see: 80/20 of 80/20 is 64/36 and 80/20 of that is 51/49.

Renan’s law: stack enough Pareto and you lose your edge.

So compute eventually gets cheaper and, with the last 20% finally affordable, switching gets cheaper at the same time, and those vibe-coded companies are next in line to migrate. Sure, the freed compute gets used, but by workloads that would never pay training prices.

Once applications get rebuilt and get more performant, fewer machines are used for these workloads. Some of it becomes inference workload and some is used for other companies being built, probably not a big problem for the clouds, which own most of the hardware that will be left over and can sell it below cost for a long time.

The hardest landing is the chips. Training and big inference use thousands of chips wired into one machine, with a premium mark-up. Common inference, already the bigger share of the load and growing, and other everyday workloads run fine on commodity and custom silicon, but if the race settles this way, the company whose valuation skyrocketed by selling premium GPUs feels it the most (scenario, not forecast, and definitely not financial advice).

Of course, the alternative case is that training doesn’t settle, inference explodes and workloads get heavier and heavier because more people vibe code poorly performing software. The limit on that scenario is not necessarily chips, but available power (not energy).

Jazz is dead, but metal is not. Chips are not cheap and I love Baby Shark. Don’t let it go, take the power back.

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?

Humans have always outsourced judgment. We watched whoever seemed to know, copied what worked, and moved on with life. At some point, capitalism attached an invoice to it.

Engineers are also humans, and they found out that copying and pasting from StackOverflow yielded generally good results. They shared best practices with each other and depended on each other’s work, often adding open source libraries to their projects without really looking at the source code.

Software scaled the way it did as we built trust mechanisms to leverage each other’s knowledge and work. We created registries, stars, test suites, CVE databases, and we assumed that the thousand eyeballs someone else is providing were a good enough proxy to infer reputation from unknown sources.

We got so used to these mechanisms that we forgot they are made of trust, until an npm supply chain attack shows up in the build and reminds everyone what we were leaning on all along. Truth is, even the thousand eyeballs will soon be gone: nobody is looking at the code, we are lazy and we don’t have to do it anymore.

Here is the part I want to defend: the laziness itself is fine. More than fine, it is a human trait, and it has led us to many engineering achievements. Larry Wall named it one of the three virtues of great programmers. In fact, the whole engineering practice is organized laziness as we refuse to solve the same problem twice.

Laziness is a means to an end, and the end is what determines vice or virtue. Pointed at growth, it is a weapon for efficiency and effectiveness, for staying truth seeking and fully owning the outcome.

When laziness is aimed at optics or appearances, it becomes plain corporate alpinism, where people are climbing to be seen climbing and effort is spent more on looking right than being right.

And when those optics are the local optimum, looking right gets a companion and CYA (cover your ass) becomes the norm and a market of its own. Thinking was outsourced to analysts, strategy to consultancies, vendor management to integrators. Cover sold as expertise, that’s a product.

Last week, Gartner published its 2026 Magic Quadrant for AI-Augmented Code Modernization Tools with AWS above Anthropic and OpenAI not on the chart at all. The loudest voices in engineering pointed and laughed, AWS posted a proud thread about its own ranking, and the models kept writing more of the world’s code either way.

Laugh all you want, but somebody pays for that report and they will keep paying, because the report is the packaging and the product is somebody else’s throat to choke.

Before the engineers reading this feel superior: vibe coding is our own version of Gartner-oriented management. Shipping code you never read (and without proper guardrails) is buying the Quadrant with a keyboard.

We have been there before, though. Assembly was abstracted away by high-level languages, manual memory management became garbage collection, and each abstraction took a slice of control with it: the compiler decides what your code becomes, the garbage collector decides when your objects die. Vibe coding is taking the next slice, the code itself, with a twist the others never had. This one is not even deterministic.

Those slices all sat on the accidental side of the craft, the part Fred Brooks said tools can eat. The essential part, he promised in 1986, would never fall to a silver bullet. Vibe coding is redrawing his line, making most of the code itself accidental. And the essence moved up, to judgment.

GenAI is industrializing the old trade, cover sold as expertise, now well beyond software, but this time there is no clear throat to choke yet. Agents have no names and nothing to lose, but humans have something to lose if they don’t use agents, so industrialization continues.

Now, expect the industry changes to be very fast and very slow at the same time. The mavericks and early adopters are churning models, processes and organizational structures by the day while the laggards, the monopolists, and the high-moat players will take years to really move.

Let me be specific on how: the mavericks usually have the most expertise, so they need the trust mechanisms the least. As adoption spreads, the mechanisms get built behind them, registries and rankings and audits for agents, to carry everyone else through the same transformation.

Notice it is all one story: our laziness outsources the judgment, we build trust mechanisms so we can lean on each other, and somebody packages the cover and sells it back to us. GenAI did not invent any of this, it is industrializing all of it at once, right as judgment becomes the essence of the work.

So, where do you place your own trust in the meantime? Are you a maven or a late adopter?

Our brains defer trust to our gut, to our instincts. If you want to be early (and you should), there is no way to calibrate your gut without seeing the transformation hands-on.

The reports will clearly not do it and the rankings will not either. So if you do not want to wait for the industry to settle: gear up, experiment, read, and be curious. You will find out that there is no shortcut to wisdom and a calibrated gut.

The whole trade is self-service now. You can outsource the judgment, but you are the one making the final call.

After I left Nubank, I started a few things: writing, advisory and building again, to truly learn GenAI as an engineer instead of an executive.

In one of my pet projects, I have agents building ML models that forecast the NFL season based on real data from many different sources, to learn how to tame them for that type of work.

Often enough, my agents got stuck with the lack of available data to improve the model. As they wanted to get unblocked, they asked me to “just buy it” so we keep moving.

I often held them back. But when they got really stuck, I went and bought some of these precious API keys myself so work could continue.

Why did I as a human have to enter a website and put my credit card info? The agents seemed to know what they needed, but had no way to pay for it.

I don’t even know if I trust them with a card, but I also didn’t trust them to code for me a couple months ago.

Companies are starting to think about selling to agents, but mostly the shopping kind: an agent buying on behalf of a person, which is what I call B2A2C. It books a flight, fills the cart, buys food, etc.

The human-first assumptions survive there, because there is a human at the end of that chain with goals, a wallet and taste.

The untapped opportunity is the building kind: products where the agent is the end user, no human waiting at the end of the chain. Think of things that your agents get stuck on: data, access, insights, inference from other models, conviction, taste.

Maybe even some human judgement by the minute? That might be part of the next wave of the gig economy. But more on that on another post.

Making the real B2A concrete at a high level: AEO is emerging alongside SEO, then vibe coding tools get their own wallets tokenizing payments, then companies start selling products for agents as end users, with a bunch of new tech-nerdy plumbing underneath.

One level deeper, take how the purchase is currently done: the agent gets an API key, a shared password that never expires and usually proves nothing about who authorized what. Very little supervision for a fast-moving world where output is what agents optimize for.

What I am thinking instead is a combination similar to mTLS plus tokens: a certificate authority who manages trust and the budget, certificates for each agent issued when they spin up, and short-term permission tokens for authorization.

Similar movements will be done in other areas. Payments already went through this once: card numbers became tokens, and holding the string stopped being the same as holding the authority.

And the pricing moves as the business model evolves: the real B2A looks more like marginal pricing than upfront with a high-floor, very similar to what the cloud did for computing. That one deserves its own post too.

Founders and VCs are thinking hard about the protocol the agent uses to pay. The more interesting question is what agents will be paying for and how they earn the trust to do so.

For now, agents know all about the price of something, but have a hard time understanding its value.

In 1969 an accountant at Texas Instruments went looking for waste and found something worse: inertia deciding how the company ran. Peter Pyhrr’s fix was zero-based budgeting. Every cycle, the budget starts from zero and every expense earns its way back in, whatever last year said.

For everything beyond money, the answer is usually incremental evolution, but a deeper review is required when the playing field tilts.

Right now, many companies are looking at the AI transformation and have started a series of process improvements. But what about the company’s set of beliefs, goals, working agreements, and everything else that originates the processes?

The systems thinker Donella Meadows would call that layer the paradigm, the deepest practical place to intervene in a system, and I endorse intervening in a more grounded manner: give it the Pyhrr treatment.

How did the Agile Manifesto come to be? Seventeen practitioners met at a ski lodge in Utah after spending years inside real companies running lightweight methods that worked, under different names. Over a weekend, they uncovered and distilled the principles they were already living and wrote them down. Extracted from practice, backed by the trenches: the foundational stone of a new doctrine.

There was no improving waterfall into agile. Better DevOps is still DevOps. Some companies are AI-adopters, some are AI-first and some are AI-native. Huge difference.

Every few months a step change in the models resets what the tools can do, and the tools reset the ways of working built on top of them. Until that settles, nobody can claim a best practice as lasting. The next manifesto comes later, extracted from practice like the first one.

So what can you do before the puck stops moving?

Lead with vision. Read the movement. The next moves do not need the destination.

For larger organizations, identifying the areas most likely to change is already progress. Starting the evolution, moving from “run the bank” to “change the bank”, is progress too, and definitely not enough.

And this is the whole point: audit your own doctrine, one premise at a time. Starting clean, with the tools that exist today, would we still choose this? Some premises will survive. A few will turn out to be last decade’s budget, renewed every year without a conscious decision being made by anybody.

I have my own set of bold predictions that I am keeping warm for a future post. For now, the work is simpler: understand your practices, when each was last chosen, and why. That awareness is what gives you the right to change the paradigm instead of being trapped inside it.

Almost every new AI founder believes their edge is that they ship fast. So do a lot of the incumbents racing to match them.

A cycle ago they’d have been right, back when speed was an advantage and not yet a requirement.

Being fast still beats a slow incumbent. It doesn’t separate you from the twenty teams in your cohort, all running the same models you are, telling their investors exactly what you’re telling yours.

AI made building fast, so most teams use it to do more: more code, more launches, greener productivity dashboards, and a lot of it the customer never feels.

AI makes you fast, and worse, confident. Hand it a bad premise and it’ll build a cathedral on top of it, coherent all the way up and wrong at the foundation. The real danger is how long you build before you find out you were wrong. None of that is new. Russell Ackoff called it “doing the wrong thing righter.” AI just gets you there faster, and makes the wrong thing look more convincing on the way.

So if speed isn’t the edge, what is? I spent a decade inside one of the fastest-growing companies anyone has built. Speed was never our problem. It also wasn’t what made us hard to beat.

The moat was doctrine, and not the kind that lives on a slide deck. I mean how a company builds and decides, all the way down. Agile, DevOps, continuous delivery, cloud-native were each a version of it, the best anyone knew for the tech and the problems of the moment.

Capital and distribution are usually the incumbent’s edge, not the newcomer’s. Doctrine is how you take it from them. Build the right way and you out-execute long enough to win your own, while the incumbent can’t copy the method cheaply. Doctrine isn’t a feature you install. It’s the whole org. You pay for it once while you’re small, or you pay forever fighting your own antibodies.

But every doctrine is built for a world, and the world keeps moving. The old one is expiring, and the next can’t be written until the tech settles for a couple of cycles.

So the moat moved up a level. You still need a doctrine. Going without one is just chaos with good PR. But the right doctrine keeps changing, so owning today’s isn’t the prize. The edge is how fast you can tell yours has gone wrong, and write the next one before the world writes it for you.

That’s the rare thing a competitor can’t copy by deciding to, because it isn’t a practice. It’s a temperament. Truth-seeking, even when the truth is that you’re wrong.

Whether you’re building one or betting on one, the next time a founder shows you how fast they ship, ask a better question. When you’re wrong, how long does it take you to find out?