A film set survives exactly one thing: the shot. The trouble starts when someone decides to move in.

If you’ve ever been on a studio backlot, you’ve walked down a street that doesn’t exist. A row of perfect storefronts: the saloon, the bank, the sheriff’s office. A weathered sign that took someone a real afternoon to age just right. From the camera’s position it’s a town you’d believe completely.

Walk through any of the doors and you’re standing in dirt, looking up at plywood braces and the back of the sign. There is no bank. There was never going to be a bank. The set was engineered to survive one thing: the shot. One angle, the right light, for as long as the camera rolls. It is exactly as much building as the scene requires, and not one board more.

Built to match the metric

I’ve watched a lot of software get built this year that is a film set. It runs, it demos beautifully, and everyone believes the town is real. It is real, for as long as the demo lasts. The work isn’t fake. It’s facade-deep, because that’s all the shot asked for.

The demo is the obvious version. The quieter, more dangerous one is the metric. A facade is built to match whatever you point at it: the demo, the coverage number, the velocity chart, the Monday dashboard. Every surface gets dressed for what’s measured, and nothing behind it has to be true.

AI is exceptional at building these facades. Point an agent at a feature and it hands you the storefront — screens, routes, file structure, a test file with the right name on it — faster than you can sketch the building behind it. The early success is real, and intoxicating. You got a town in an afternoon, and every metric came up green.

Then you move in. You put real users in the saloon and a real ledger in the bank, and you find out what the set never had to be: load-bearing. It matched the number it was built to match, never the load it was about to take.

The danger isn’t that vibe-coded software looks broken. It’s that it looks finished, and the metrics agree.

The island that built an airport

There’s a reason the inside ends up empty, and Richard Feynman gave it the best name we have.

In a 1974 commencement talk, he described the cargo cults of the South Pacific. During the war, planes had landed on remote islands and unloaded riches the islanders had never seen. Then the war ended and the planes stopped. So some of them tried to bring the planes back. They cleared runways, built a control tower out of bamboo, carved headphones from wood and sat in them, lit fires along the strip, and marched the formations they’d watched the ground crews run. They reproduced the form perfectly.

No planes came. The towers and headphones never caused the planes; they were downstream signals of a machine the islanders couldn’t see and hadn’t built. Feynman called it cargo cult science: work that has all the apparatus of the real thing and misses the one part that made it work.

They weren’t foolish. The ritual really had coincided with the planes.

That’s the trap, and it’s ours. Every engineering discipline is a ritual that once coincided with something real. AI now lets you perform the ritual at zero cost while the real thing never shows up.

The rituals were never the engineering. They were the evidence of engineering. AI gives you the evidence for free.

The planes the rituals used to bring

I’m working with a team that wants to transform itself with agents. Smart people, real ambition, roadmap pointed at autonomy. The best models are already in their editors, and everyone is prompt-engineering their way to features. Everyone is doing AI. Almost nobody is doing engineering with AI. Every time I get under the hood, I find the same thing: the basics are gone. Not missing. Gone, the way a habit goes when nobody remembers why they had it.

I asked one of their senior engineers what would happen if we dropped the PR review step.

“Oh, that would put so many bugs into the system.”

“But you review every change today, carefully. You still ship plenty of bugs. So what is the review actually catching?”

No answer. Silence!

That’s the whole post in one exchange. A ritual everyone defends and nobody can connect to the outcome it’s meant to produce. It’s the wooden headphones. The silence isn’t anyone hiding something — it’s that nobody has asked the question in years.

So before anyone in that building talks to me about agents, I make them walk the rituals back to the plane each one used to signal. Coverage was a signal that someone understood how the code breaks; “get it to ninety percent” buys the number and tests that assert a function was called, not that its answer was right. Review was a second mind reasoning about a change; LGTM on four hundred unread lines is the posture with the function gone. Continuous integration was proof the system still fit together; a long-lived branch with a green badge is a fire lit for a plane that isn’t coming. I’ve called this hopeless for a decade.

But those are symptoms. The disease is underneath the code, and it’s worse. I keep meeting engineers — senior, shipping daily — who were never taught the machine they stand on. They can’t tell you how a packet actually crosses a network, or how the OS decides which thread runs next. They’ve never read an RFC and aren’t sure what one is for. Encapsulation is a word from a tutorial, not an instinct; design patterns are something the model inserts, not something they reach for; “scaling” means adding more pods. The form of a senior engineer is all there. The understanding the title used to require is gone.

It shows up loudest in architecture, where the calls now get made by fashion instead of reasoning. Microservices because that’s what real companies do. Serverless because it’s modern. Kubernetes because the conference talk had it. Almost nobody asks the questions that actually decide it: what’s the load, how big is the team, what are the failure modes — and would a boring monolith absolutely rock for where this company is today? That is cargo cult at the architecture layer: copying the shape of what scaled somewhere else without understanding what made it right there and wrong here. I spent years learning which shapes survive ~900 services and which quietly kill you; none came from picking the fashionable box.

Underneath all of it sits the one thing that was never a ritual: deciding what “correct” means before you build — and knowing the machine well enough to decide it. When execution becomes free, judgment becomes the expensive thing, and judgment is just fundamentals plus scar tissue: the two things the form always leaves out.

I went in to help that client build agents and spent the first month fixing things I’d have insisted on in 2010. You cannot automate past a discipline you never had. Agents don’t install the engineering you skipped. They remove the last few humans who were quietly compensating for its absence.

The form is perfect. The planes still don’t land. And when you ask why, the room goes quiet.

The bill in the mail

The cruel part is the timing. A facade doesn’t fail on day one. It performs best on day one.

The demo lands. The first ship feels like magic. Velocity is euphoric: you stripped out everything that slowed you down, and nothing has come to collect yet. It’s not fake. It’s front-loaded. You borrowed the success from the future, and the bill is still in the mail.

Then the bill arrives, as load. And it rarely arrives as a clean collapse. This is the part that’s probably you. Your software ships. It runs. It does real work, more than a demo. Does delivery feel like this: every feature needs monkey-patching the week after it lands, the bug queue never drains because you open six for every five you close, estimates slip, and the QA cycle that used to take three days now takes two weeks because nobody trusts the build? You’re still shipping. You’re just shipping with a hand permanently on the patch. The town didn’t fall down. You’re paying rent on the facade, and the rent goes up every sprint.

The speed everyone is celebrating is the leading indicator of the bill, not the proof it’s working.

The reason Gojek’s engineering became something people talked about wasn’t speed. Plenty of places are fast. It’s that the thing behind the storefront was a building. Hundreds of engineers shipping into nine-hundred-odd services, thousands of deploys a week: that surface does not survive on facades. It survived because the unglamorous work was done: somebody defined what “correct” meant for driver allocation city by city, the integration was real, the review was real, the harness held weight. We weren’t fast despite the discipline. We were fast because of it.

What’s behind a real wall

The fix is not “slow down.” That’s the lazy reading; the leverage is real and worth keeping. The fix is to rebuild the causation, not the ritual. Stop asking the agent for the coverage number and start asking it for the failure cases you’re afraid of. Stop counting approvals and start demanding that something understands the change before it ships: a second engineer, or an agent that reasons about the diff instead of stamping it.

Each of these was a compression of judgment into a habit. We let them go slack for years because six engineers, a QA team, and a slow release cycle absorbed the difference. The new shape strips that redundancy out: the discipline has to become deliberate again.

If you run the company, the move is smaller than a reorg and harder than one. Change the question you ask on Monday. Not “how fast did we ship,” and not “is the dashboard green.” Ask “what did we verify, and how do we know.” A team optimizes for the question it’s asked. Ask for the metric and you get the facade. Ask for the verification and you might get a building.

And don’t confuse the engine for the win. Everyone will have a frontier model, cheap and roughly equal. AI is a multiplier: point it at a real engineering foundation and it compounds; point it at a facade and you get a bigger facade, faster. It helps only as much as the engineering underneath it is sound. The foundation you built is the win, not the model bolted on top.

You don’t get the plane by building a better tower. You get it by being the thing the tower was always pointing at.

The town on the hill

The set is still standing. From the road it looks exactly like a town, better than a real one, because every board was placed for the camera and nothing is worn by use. That’s the part that should worry you. A ruin looks like a ruin. A facade looks finished.

So the question to ask of anything you shipped this year isn’t whether it works. It worked in the demo; that’s what demos are for. The question is whether there’s a building behind the front wall, or whether you just got fast at building front walls.

And the plane does land. That’s the twist the cargo cult never had: every release ships. It just lands the way it lands on a muddy strip: in the dark, the whole team holding its breath, fingers crossed, hoping the gear holds one more time. You’ve learned to call that normal. It isn’t. That dread is the rent, and it comes due every sprint.

Build the runway that actually leads somewhere, and the plane lands the boring way: on time, in daylight, nobody praying. That’s the prize the speed never was. Not faster. Calm.

More to come.

References & further reading

• Beware Cargo Cult Thinking — John M. Jennings. The clearest short piece on cargo cult thinking as a cause-and-effect failure, with everyday examples and warning signs.
• Cargo Cult Science — Richard P. Feynman’s 1974 Caltech commencement address, full text. The primary source for the metaphor. (PDF version.)
• The Solo Climb — what a load-bearing harness actually is once the team that used to catch you is gone.
• The Expensive Thing — when execution becomes free, judgment becomes the expensive thing.
• The Tests We Skipped — the instalment plan on skipped discipline, and the day it gets called in.

An agent shipped something technically correct and completely wrong. That was when the word "harness" stopped being abstract for me.

We all watched Free Solo. If you haven’t: Alex Honnold climbed El Capitan — three thousand feet of vertical granite in Yosemite — without a rope. No protection. Nothing between him and the ground. The documentary won an Oscar and, somewhere in the years that followed, quietly handed the word “harness” to every engineering conversation I’ve been part of. We need a harness. The harness isn’t strong enough. Who owns the harness? I can’t prove the etymology but I’d bet on it.

The part nobody wants to build

Here’s the thing most people forget about Free Solo, or maybe never noticed. Honnold didn’t decide one morning to climb without a rope. He spent years on that exact route — with the rope, with the harness, with all the protection — until he had memorised every hold, every transition, every sequence across three thousand feet of rock. He rehearsed the crux sections until his body could execute them in the dark. He didn’t remove the external safety until he’d built something harder to see and far harder to build: internal safety, so thorough that nothing on the wall could surprise him.

The harness didn’t disappear. It moved inward.

Everyone watched that film and took the wrong lesson. Honnold’s years of roped climbing weren’t the cautious version of the climb. They were the harness — built into his body rather than clipped to his belt.

The teams that genuinely run at 100x — the solo senior plus agents doing the work of eight, the small team that ships like a large one — they didn’t remove the harness. They built a different kind, and they built it first. That’s the half the romance never shows.

Most of the teams I talk to who want that shape are attempting the free solo without doing what Honnold did first.

What load-bearing actually means

Let me define what I mean by harness, because the word is starting to get used as a vibe.

A harness, in the sense I’m using it, is the set of systems that together can answer one question with confidence: is this change correct enough to ship? That’s it. The question doesn’t change because the author is an agent. The question doesn’t change because the team is smaller. The question gets harder — because the velocity of the change went up, and the team that used to look over the change went away.

Load-bearing means: when an agent opens a PR at 11pm on a Friday, and the senior engineer is asleep, the harness either holds or doesn’t. There is no review meeting. There is no second pair of eyes. There is no Monday standup that catches it. If the change is wrong and the harness doesn’t catch it, the change goes to production, and the user finds the bug before you do.

That is the load. Everything else — the dashboards, the rituals, the post-incident retros — is what you do after the harness has already failed.

You can see why most teams’ “harness” isn’t load-bearing. A test suite that passes 90% of the time isn’t a harness. A spec document nobody operates from isn’t a harness. A staging environment the team has stopped trusting isn’t a harness. None of those held the human team either — they just got papered over by review meetings and manual QA passes. The agent removes the paper.

The solo climb is the load test

The old org had a lot of redundancy in it. I argued for twenty years that the redundancy was hiding a missing harness. Most teams disagreed, quietly, by carrying on. The disagreement was tenable because the redundancy was real. A weak harness, plus six engineers plus a QA team plus a manager who knew the codebase plus a long release cycle, is a system that mostly catches mistakes. Not elegantly. Not cheaply. But catches them.

The new shape — the solo senior plus agents — has the redundancy stripped out. That’s the whole point of the shape. It’s how the 100x leverage shows up. It’s also why the harness has to be load-bearing in a way it never quite had to be before.

If you’re the senior engineer in that shape, you are climbing solo. The agent is the rope you’re trusting to pull weight, and the harness is the only thing between you and the ground. The team that used to catch you is not on the wall.

This is not a metaphor that gets less literal the closer you look at it. It gets more literal. The solo climb is the load test — if the harness was weak before, the climb is what tells you.

I keep getting asked by founders and senior engineers whether the 100x shape is real, whether their team is “ready for it.” The honest answer in most cases is: the shape is real, your team is not ready, and the reason your team is not ready is the harness. Not the agents. Not the skill of the senior engineer. The harness. It’s nearly always the harness.

The invisible load

A climber two hundred feet up a granite face knows exactly what the harness is for. The consequence of bad gear is immediate, physical, and irreversible. Nobody argues about whether to clip in. Nobody says “let’s skip the gear check this sprint.” The feedback loop is closed in the worst possible way, and everyone on the wall knows it.

Software doesn’t work like that. The consequence of a missing eval suite is a bug in production three weeks from now, found by a user who emails support, turned into a ticket, escalated eventually to engineering, assigned to someone, debugged across a few days, fixed in a PR nobody reviews carefully because the pressure is on to close the sprint. Distributed. Invisible at each step. Nobody felt the fall. The load was spread across twelve people and thirty days until it became noise.

This is the strategic gap most leaders I talk to can’t quite name. Software risk doesn’t register the way physical risk does — the feedback loop is too slow and the consequence too diffuse. You skip the harness and nothing happens today. Nothing happens this sprint. The cost is real and it’s being paid — it’s just being paid by people you’re not counting in the same column.

I felt this clearly when building clawstation.ai. The failure doesn’t announce itself as failure — it arrives as slowness. A release that takes longer than expected. A bug in a place nobody was watching. The invisible load was always there. The harness is what makes it visible before it becomes a disaster.

Building software is not as life-threatening as a solo climb. That’s precisely the problem. The visceral urgency that makes climbers inspect every piece of gear before they leave the ground — that urgency is absent in software. The stakes feel deferrable. So teams defer the harness. The load builds, invisibly, until the first time they actually need it to hold.

The strategic misread, in almost every team I’ve seen take this seriously too late, is thinking the harness is for when things go wrong. The harness is for when things are going right — when you’re moving fast, shipping daily, trusting agents to do work a team used to do under supervision. The harness isn’t the recovery plan. It’s what makes the speed possible without the invisible load becoming the visible disaster.

Where harnesses snap

I’ve watched enough of these systems get stress-tested this year to have an opinion about where they fail. Five patterns keep showing up.

The harness is theatre. Tests exist. They pass. Nobody trusts them, because everyone on the team knows which tests are checking something real and which are checking that the function got called. The CI build runs. People watch the build pass. People still manually verify the feature before shipping, because the build’s green light has lost its meaning. This is the PR-rubber-stamp pattern wearing a new costume. The shape of the lie is identical.

The harness has gaps the team has stopped naming. The integration test that always flakes, so the team marks it as expected. The eval that takes too long to run, so it only runs on main. The contract test that broke six months ago and got disabled “temporarily.” Every gap was once a known issue. Then it became background noise. Then it became invisible. The agent ships through the gap, and the team finds out in production.

The harness only covers the happy path. Most test suites I see are extensive on the cases the team already understands and thin on the cases the team is afraid of. Concurrency. Partial failure. Migrations under load. Edge cases at the data layer. The agent will write code that hits the cases the suite doesn’t cover, because the agent doesn’t know which cases the team has been quietly avoiding for years.

The harness has no eval for what good means. Tests can tell you the function returned the right value. Tests cannot tell you the feature actually solved the user’s problem. A real harness includes the eval layer — the one above the unit tests that asks, did this change accomplish the thing it was meant to accomplish? Most teams don’t have this layer. Most teams have never built it. The Harness PM lane I wrote about last week exists precisely because this gap is real and someone has to own it.

The harness has no safe failure mode. When the harness catches something, what happens? In a healthy system, the change doesn’t ship and the author finds out fast. In most systems I see, the harness flags something, the alert goes to a channel nobody watches, and the change ships anyway because the gate isn’t actually a gate. A harness that warns but doesn’t stop is not a harness. It’s a notification. In climbing terms, this is gear that unclips the moment you put weight on it. A real harness requires the software equivalent of a circuit breaker or an automated rollback — a mechanism that physically stops the fall before it hits the ground.

A harness that warns but doesn’t stop is not a harness. It’s a notification.

Notice none of these failures are about the agent. All of them existed in the human-only world. The agent just exercised them faster than the team had a way to respond.

The gear list

Here is what I’d insist on — gear I’d inspect before I let the climb begin.

Specs that are operated from. The input to the agent, the source for the eval suite, and the artefact the team reviews when something breaks. If the spec isn’t load-bearing in the system itself, it isn’t a spec. It’s documentation.

A test suite the team trusts enough to ship on. Green build means ship. Red build means don’t. No “we manually verified anyway.” No “the test is known to flake.” If the team can’t honestly say a green build is enough to push to production, the test suite isn’t a harness — it’s a comfort blanket.

An eval suite for “did the change solve the right problem.” Above the unit tests. Closer to the user. The eval is what catches the change that passes every unit test and still does the wrong thing. This is the work QA roles are evolving into, and the teams that don’t build it will keep being surprised by features that ship green and land wrong.

A sandboxed environment the agent can actually operate in. Bounded, observable, reversible — where the agent can do work without the blast radius of a mistake reaching the user.

Gates that actually gate. The build either goes to production or it doesn’t. The eval either passes or it doesn’t. The approval either fires or it doesn’t. No “we’ll let it through this time.” Every soft gate is a hole, and every hole gets exploited eventually — not maliciously, just statistically.

Agent-of-agent review. One agent writes. Another reviews. A third runs the tests. This isn’t just about replacing a human; it’s an automated layer designed to scale technical judgment at the same velocity as the code being generated. None of them are the senior engineer, who is doing the work the Anatomy post said survives — designing the system, holding judgement, owning the outcome. The agent-on-agent layer is what makes the climb scalable. It’s also the layer most teams haven’t built yet, because they’re still pretending the senior engineer can review every PR by hand.

Observability the senior engineer actually reads. The five or six signals that, if any of them moves, the senior wants to know inside the hour — not a dashboard, not an alert firing into a dead channel. The harness only protects you if you can see when it’s about to fail.

That’s the gear. None of it is new. Some of it I’ve been writing about for a decade. The novelty is the urgency, not the practice.

What “strong enough” means

Strong enough is not a checklist score. Strong enough is a question you can answer honestly: if the senior engineer goes on holiday for two weeks, and the agents keep shipping, do I trust what comes out the other side?

If the answer is yes, the harness is strong enough.

If the answer is “well, mostly, but,” the harness is not strong enough, and the but is the gap that will eventually become the incident.

If the answer is no — and for most teams I talk to, the honest answer is no — then the climb is not yet a climb you should be taking solo. The team is not yet a team that can run the 100x shape. Build the harness first. Then climb.

The climb without the harness isn’t ambition. It’s a fall in slow motion.

The teams that build the harness first are the teams that get to take the climb the rest of the industry is still talking about. The 100x leverage is real. The small-team-plus-agents shape is real. The harness is what makes both real things survivable. Without it, the 100x team is just a faster way to ship a bug.

The climb is fine. It’s the gear that gets you killed.

Climbers know this. The mountain doesn’t kill you. The fall doesn’t kill you. The gear that didn’t hold is what kills you — and the moment to inspect the gear is before you leave the ground, not at the top of the pitch when you’ve already started to slip.

The new shape of software work is, for the first time, a shape where the climber is climbing solo. The agents are doing work a team used to do. The senior engineer is the only judgement in the system. The harness is the only protection between a wrong change and a production user.

If you’re a founder and your team is leaning into the 100x shape, ask the harness question first. Not the agent question. Not the headcount question. The harness question. If the senior engineer goes quiet for two weeks, what holds? If the answer is nothing solid, you don’t have a team. You have a climber and a rope and a wish.

If you’re a senior engineer and the romance of the solo climb is pulling at you — I get it. It’s pulling at me too. The work is more interesting than it’s ever been. The leverage is real. But check your gear before you leave the ground. The agents are not going to check it for you, and the team that used to is gone.

The climb is fine. It’s the gear that gets you killed.

More to come.

The question isn't whether AI will eat your job. It's which half.

It happened faster than anyone expected

Something in your role changed this year. The task that used to take an afternoon now takes an agent ten minutes. The report you wrote every Friday? There’s a pipeline for that. The coordination work, the status updates, the ticket grooming — it didn’t disappear, exactly. It got absorbed.

AI ate part of your role. Maybe a big part. The question in the air is the obvious one: what’s next?

The Anatomy of an AI-Native Org talked about what happens to the shape of organisations. This is the follow-up people actually asked for — the role-by-role walkthrough. Project and Product Managers asked first. Designers asked next. EMs asked, slightly defensively. Junior engineers asked quietly, the way you ask a question you’re afraid of the answer to.

This is the answer.

The cut that runs through every role

Before I go role by role, one principle does most of the work.

Every role splits along the same line.

The parts of your role that look like translation — converting one well-defined input into a well-defined output, running a process that produces a predictable artifact, coordinating other people’s work — are the parts that collapse. They collapse into the agents layer of the new anatomy. This is true regardless of your job title.

The parts of your role that look like judgement — deciding what correct means in an ambiguous situation, holding context across a problem larger than any single ticket, taking responsibility for an outcome rather than an output — are the parts that grow. Dramatically.

When you read the role sections below, the underlying question is always the same: which parts of what I do today are translation, and which parts are judgement? Your career strategy for the next five years is whatever moves you decisively toward the second column.

Now, role by role.

At a glance

Two arcs run through what follows. Some roles evolve — the work sharpens, the leverage grows, but you’re still doing a version of what you were doing, with much bigger tools. Other roles transform — the job becomes a different job with the old name still attached. Knowing which arc you’re on changes everything about how you prepare.

Roles that evolve — same job, sharper.

Roles that transform — different job, old name.

Jump to your role, or read straight through.

Product Managers

Evolution — but only if you already had a thesis.

This is the role most often confused with Project / Program Manager, and the AI shift is about to make that confusion impossible to ignore. The two roles have shared a title in many companies for a decade. The underlying work was never the same.

A traditional Product Manager spent maybe 70% of the week on translation: PRDs, research synthesis, prioritization frameworks, alignment decks, status updates, roadmap reviews. The other 30% was judgement — deciding what to build, holding a thesis under pressure, knowing which customer signal mattered and which was noise. Honestly told, most of that 70% was project management work, not product thinking. Agents now do the 70% faster and at higher fidelity than any human running on Friday-afternoon coffee. The gap that opens when the 70% vanishes is exactly the gap between project management and product thinking. For some people that gap is a chasm.

Product and project are different skills. They’ve shared a title for a decade. They never shared a capability.

What gets eaten: PRD drafting, research synthesis, competitive analysis aggregation, RICE-style prioritization scoring, the slide-deck-and-summary motion of the role. Status communication and roadmap presentation. Most of the document production that filled a PM’s calendar.

If you’re a Product Manager, four lanes survive and grow. They map to four different muscles — thinking, intuition, research, and user proximity — and most strong PMs lean into one or two.

Vision PM. The thinking lane. You hold the product thesis. Original strategic ideas about where to take the product, why now, why us. You write the document that becomes the company’s direction, and you operate from it under pressure. The agent can summarize the market; only you can decide what to do about it. This is the most senior shape of Product Manager work in the new world — and the rarest.

Intuition PM. The taste lane. Years of pattern recognition across products, markets, customers. You know which features will land before research confirms it. The agent can generate options; only you can tell which one is right. The hardest lane to develop in someone who doesn’t already have it — and the most valuable in the agent era, because intuition is what tells you when the agent’s output is plausibly wrong.

Research PM. The discovery lane. Rigorous, structured customer research. You design experiments, run user interviews that move the conversation forward, build feedback loops the company can act on. The agent can synthesize transcripts at scale; you decide which questions to ask, and what the answers mean. This lane gets bigger, not smaller — because more conversations don’t equal more insight.

Customer PM. The user lane. Embedded in the customer’s world. You ride along with sales calls, sit in support tickets, visit users in their context. You bring specific, dated customer voice into every product decision. Closely related to where the strongest CS leads end up. The agent can read every ticket; only you sit in the room with a frustrated user and feel what’s actually wrong.

The four lanes are about how you contribute. But there’s a bigger shift sitting above all four, and it applies whichever lane you pick. The new Product Manager evolves into something the old role often wasn’t: a business owner. Your real job, always implicit and rarely held accountable, is becoming brutally explicit: make money. Revenue. Margin. Growth. Retention. Whatever the number is for your product, that’s now your number — not the roadmap, not the OKRs, not features shipped. The conversation with leadership stops being did you ship? and becomes did you move the number? Most PM organisations aren’t structured for this yet. Most PMs weren’t trained for it. It’s the shift that runs deeper than any of the four lanes.

Whichever lane you love, the real job is unchanged: own the business outcome. Make money.

What I’d do if I were a Product Manager today: choose your strength, honestly. If the project work was where you actually shone — running the process, holding the alignment, shepherding the launch — you’re a Project / Program Manager, and that section is your roadmap. If product thinking was your real instinct, pick the lane within it that fits you — vision, intuition, research, or customer — and operate from it visibly. Stop being the person who runs the discovery process. Start being the person who has a point of view about what should be built, and the conviction to hold it when leadership pushes back.

And underneath whichever lane is yours, start carrying a business number. Revenue, margin, growth, retention — whatever your product’s actual job is in the company. Own that number, operate as someone accountable to it, not as someone shipping features into it. That’s the real evolution, and the lanes are just different paths to it.

The agent can do the synthesis. Only you can have the conviction. Both lanes are honourable. Pretending you’re in the one you’re not is what gets people stranded.

The era of “let me find out what to build” is closing. The era of “I know what we should build, and here’s why” is opening.

Senior / Staff / Principal Engineers

Evolution — bigger leverage, fewer trophies.

Less affected than people think. Senior engineering work was always closer to judgement than translation — defining architecture, owning systems, deciding what correct looks like across complex domains.

What gets eaten: writing the boilerplate parts of the design yourself, doing the rote refactors, hand-tooling internal scaffolding. The slice of your day that was conversion is gone.

What survives and grows, dramatically, is leverage.

The 10x engineer trope was always mythical. The 100x engineer pattern — one senior engineer plus the agents they direct — is real, and I’ve watched it work this year.

The 10x engineer trope was always mythical. The 100x engineer pattern — one senior engineer plus the agents they direct, replacing what used to require a team of eight — is real, and I’ve watched it work this year. Architecture decisions. Cross-system reasoning. Eval design. The 5% of the codebase the agent shouldn’t touch unsupervised. Performance work in deeply intricate systems.

What I’d do if I were senior today: stop coding everything yourself. Start designing the system the agents operate inside. Your role moves from writing the hard code to defining what good means in the hard places. That’s a bigger job, not a smaller one. It’s also harder than it sounds, because writing the code was the comfortable part — the part with visible output and immediate dopamine. The new work — specs, evals, architectural reviews of agent-generated code, harness design — produces fewer trophies and more leverage. That trade is worth making.

Project / Program Managers

Evolution — but the most aggressive one in the post.

This is the role that triggered the post in the first place. Of every job in software, it’s the one facing the sharpest transition — because the work was almost entirely translation.

Status updates synthesized from engineering progress. Sprint facilitation. Roadmap-to-JIRA conversion. Standup chairing. Read that list with the principle above in mind and the answer is uncomfortable but clear — almost all of it is translation. Agents are getting scary good at it. Status updates synthesized from the PR graph and deploy log are more accurate than the ones a PM stitches together by hand on Friday afternoon. Dependency tracking from the code graph is more complete than what any human can hold in their head.

The blunt thing worth saying out loud: the three lanes that survive each ask you to become something adjacent — more product, more quality engineering, more governance. This sits closer to role change with continuity than to same role, sharper. Your PM skills transfer. The day-to-day work won’t look the way it does now.

Your PM skills transfer. The day-to-day work won’t look the way it does now.

If you’re a Project / Program Manager, three lanes survive and grow.

Taste PM. You move up into the what layer — which is essentially crossing over into Product Manager territory. The ones who already pushed back on bad scope, said no, we won’t build that even though we could, and held a product thesis under pressure — that’s you, and there’s more room for that work now than there’s ever been. The good ones always knew this was the real job. The agent era just makes it explicit. Transfer skill: holding context and packaging it for decisions. New skill: a thesis of your own.

Harness PM. This is a new lane and possibly the most valuable. Someone has to define acceptance criteria. Someone has to design the eval suites that determine whether the agent shipped the right thing. Someone has to track outcomes now that outputs are nearly free. Project Managers with a quality-of-outcome instinct slot here naturally. The work looks more like product reliability engineering than project management, but it’s PM-shaped at its core. Transfer skill: process design, definition-of-done discipline. New skill: enough technical depth to design evals that catch real failures.

Boundary PM. The few cross-team threads that genuinely need a human — compliance, legal, regulatory commitments, multi-org customer engagements — survive. Fewer people in this lane, doing more senior work. Transfer skill: stakeholder management, complex coordination. New skill: domain depth (legal, compliance, regulatory) that takes years to build.

What I’d do if I were a Project / Program Manager today: pick a lane and start visibly doing that work this quarter. Don’t wait for the role to find you. If you’ve been the coordinator-PM, write a product thesis for something you care about, get it in front of leadership, and start operating from that thesis instead of from JIRA. If quality-of-outcome is your instinct, propose an eval suite for one of your features and own the definition of done.

And the math nobody wants to say out loud: the total number of seats in this role is going to shrink. The seats that remain will be senior, lane-specialised, and will go to the people who started shifting six months ago. The hardest version of this advice is the simplest — start now, in one specific lane, with one specific artefact.

Engineering Managers

Evolution — if you keep your hands on the work.

EMs got partial coverage in the macro post — the contribute or disappear line — but the question I keep getting is what contribute actually means in practice.

The EM who hasn’t coded in five years is the most at-risk profile. The EM who still ships something every quarter — a tool, a script, anything — is the most resilient one.

The EM who hasn’t coded in five years is the most at-risk profile. The EM who still ships something every quarter — a tool, a script, anything — is the most resilient one. That’s the whole section, really. Everything else is scaffolding.

The EM work that collapses: standup facilitation, the upward translation of engineering progress, the downward translation of business priorities, ticket grooming, weekly status writeups. Most EMs I’ve talked to know this in their gut already.

What survives and grows: people development; hiring; design contribution — the EM who shows up to the design discussion with a real opinion; harness ownership; incident command and post-mortem leadership.

What I’d do if I were an EM today: get hands back on the work. Not all the work — but enough that you’re in the design conversation, not just facilitating it. Read the codebase. Read the agent’s PRs. Push back on architecture decisions with actual evidence. There’s no rule that says you have to be the loudest contributor. But you do have to be a contributor.

Junior Engineers

Transformation — and the industry hasn’t built the new path yet.

This is the hardest one and I want to be honest about it.

The traditional path from junior to senior was: write a lot of code, ship a lot of bugs, get a lot of feedback, gradually develop judgement. The translation work — converting tickets to PRs, implementing well-defined features, fixing well-defined bugs — was also the apprenticeship. Senior engineers came out of that pipeline because the conversion work taught them, over five or seven years, what correct looked like in production.

The agent now does most of that conversion work, and it does it faster than any junior can. Which means the apprenticeship pipeline that produced senior engineers is breaking. We haven’t built a new one yet. Anyone who claims they have is selling something.

I don’t want to be dishonest about this. The hardest career conversation in software right now is: how do you become a senior engineer if you’re a junior engineer in 2026? The old path is closing. The new path is being figured out in real time by a small number of teams and a small number of individuals, and most companies haven’t worked out how to develop a junior engineer in an AI-native environment.

What I’d do if I were a junior today, holding nothing back.

Don’t try to compete with the agent on speed of execution. You won’t win.

Don’t try to compete with the agent on speed of execution. You won’t win.

Compete on judgement. The reading-and-judging muscle is the senior-engineer muscle, and the agent has actually made it more accessible. Try this: pick three pull requests this week — yours, your team’s, or open source. For each, ask the same three questions: what was the constraint this was solving for? what did it trade off? would I have made the same trade? Write your answers down. Do this every week. After three months you’ll have a notebook of forty critiques, which is roughly forty more than most juniors will have.

Take ownership of outcomes, not tasks. If the agent shipped a feature, the question stops being did I write the code and becomes did this feature do what it was supposed to do? Live inside that question even when nobody is asking you to. Get the metric. Watch it for a week. Write the post-launch note that no one asked for. That note is what makes you visible to the seniors who matter.

Find a senior who’ll mentor you on judgement, not syntax. The senior who’ll sit with you and explain why a decision was made — not just what the decision was — is more valuable to your career than the senior who shows you a clever piece of code. If you don’t have one inside your company, find one outside it: open-source maintainers, engineers you’ve worked with before, people whose writing you return to. Ask one specific question. Follow up with another. Most seniors will respond if the question is specific and the follow-up is thoughtful.

Look hard at whether your company is actually investing in juniors. Is there a real path? A senior who’s measurably better at developing people than the others? A culture of explaining the why? If yes, stay and absorb everything. If no, leave. The industry is splitting into companies that will produce the next generation of senior engineers and companies that will hire from those companies. Be at the first kind. The pay is the same. The trajectory isn’t.

Worth saying out loud — the industry owes juniors a better answer than “use the AI and figure it out.” We’re going to lose a generation if we don’t think harder about this. I’m working on it.

Designers

Transformation — from making volume to defining good.

Designers asked about this more nervously than I expected, and I get why. AI is generating images, mockups, design system variants, even working prototypes. It can feel like the heart of the craft is under attack.

I don’t think it is. But the shape of the role is changing.

What gets eaten: production work. Wireframes from a brief. Mockup variants. Design system implementation. The output-volume parts of design — the slides, the asset packs, the dozen-versions-of-the-hero-image work — agents can do faster than any human.

What survives and grows: taste, conceptual design, brand judgement, system-level coherence, the what does this product actually feel like call. The cuts. The no’s. The opinionated calls about what good looks like for this product, this brand, these users. The sensitivity to detail that only comes from caring about craft for a long time.

What I’d do if I were a designer today: lean into the parts of design that require years of caring about craft.

Stop optimising your portfolio for output volume. Start optimising for what you can decide, not what you can make.

Stop optimising your portfolio for output volume. Start optimising for what I’d call judgement artifacts — design rationale documents, critiques of other people’s work, brand voice guides, taste essays. These are the things that prove you can decide what’s good, not just make a lot of things. The market for that has never been bigger.

QA

Transformation — from downstream service to embedded quality engineering.

I want to be more honest about QA than the easy version of this story allows.

The easy version says QA was undervalued and now finally gets its moment. I don’t think that’s quite right, and I want to say why.

For thirty years, traditional QA created a quiet co-dependency with engineering. Developers learned that they didn’t have to worry about quality at the moment of writing, because QA was the safety net downstream. They churned out features. QA caught the obvious bugs. Both sides made their numbers. But the code wasn’t actually up to standard at the point of commit. The product wasn’t up to standard at the point of merge. Quality became something that happened to the work, not something that lived inside the work.

Quality became something that happened to the work, not something that lived inside the work.

The cost showed up in cycle time. Manual QA passes took days. Regression suites took weeks. Code-to-production stretched from hours to fortnights, and engineering teams quietly became hostages to QA orgs that had to physically run through every release. Trust in delivery eroded — both ways. Engineering didn’t trust its own output. QA didn’t trust engineering’s output. Customers didn’t trust either of them. We called this normal. It was actually a co-dependency dressed up as a process.

The Tests We Skipped is what magnifies the impact here. When automation and specs and eval suites become load-bearing — when the harness is real — the long manual QA cycle stops being viable. You can’t have a three-week QA pass on a feature an agent shipped in three hours. The geometry doesn’t work. The traditional QA role collapses, and it collapses because the engineering practices around it finally have to be real.

What this means for people currently in QA roles: the role you have today is not the role that’s going to exist. Not as an evolution. As a different role.

The new role sits at par with software engineering, not downstream of it. The skills carry over — adversarial thinking, defining what correct means, knowing how systems break — but the work is different. You’re designing evals, not running them. You’re owning acceptance criteria, not validating against them after the fact. You’re embedded in the work the moment it starts, not waiting at the end for it to land in your queue.

The differentiator, for the QA people who move up, is domain knowledge. The QA folks who spent years inside one product, one regulatory environment, one customer base — they know things about how the system actually behaves under stress that engineers often don’t. That domain depth, paired with judgement work on the harness, is the lane that opens.

What I’d do if I were in QA today: stop thinking of this as your moment of arrival, and start thinking of it as a role change. Build eval suites. Design acceptance criteria templates that PMs and engineers can both work from. Make your domain knowledge visible — write internal docs about how this product actually behaves, where it fails, what correct means in your specific context. Move into the engineering organisation, not alongside it.

Customer Success

Transformation — into product strategist with a customer specialty.

The role most software companies systematically undervalued, and one that quietly becomes one of the most strategically important seats in an AI-native org.

What gets eaten: tier-1 support, ticket triage, FAQ responses, account health reporting, the recurring how do I… emails. Agents handle this faster, more consistently, and at zero marginal cost. Most CS work currently measured in ticket volume is gone.

What survives and grows: customer outcome ownership. Relationship work with strategic accounts. Escalation judgement. Product feedback synthesis — the work of distilling hundreds of customer conversations into what your product should do next. The bridge between why and what, with one foot in the customer’s reality.

CS people who make this transition start to look like product strategists with a customer specialty. The best ones I’ve seen do it by changing what they measure themselves on, before anyone tells them to. They stop counting tickets closed. They start writing product briefs from customer patterns — here’s what I heard fifteen customers say this month, here’s what I think it means, here’s what we should build. They show up to the product meeting with a point of view, not a summary. That’s the new role, and the companies that develop people into it will have a feedback loop that’s nearly impossible to replicate.

They show up to the product meeting with a point of view, not a summary. That’s the new role.

What I’d do if I were in CS today: pick up product-call authority. Earn the right to be in the room when product decisions get made. The CS person who can synthesise a customer trend into a product change is the new version of the role, and most CS leaders haven’t figured out how to develop people into it yet. Be the person who shows them what it looks like.

The pattern, again

You’ll have noticed every section above ends with some version of the same advice: move toward judgement, away from translation. That isn’t laziness on my part. It’s the pattern.

Translation work is going. It is going faster than any of us expected and it is going across every role, not just engineering. The judgement work — defining correct, holding context, owning outcomes, exercising taste — is what survives.

For some of you this is evolution. The work sharpens, the leverage grows, but the role survives in recognisable form. Product Managers, senior engineers, Project Managers, EMs — your job has a different texture in twelve months, not a different name.

For others this is transformation. QA becoming quality engineering. Customer Success picking up product authority. Designer-as-taste-keeper. The apprenticeship layer for juniors getting rebuilt from scratch. The role doesn’t just grow. It becomes a different role with the old name still attached. The transformation is real, and pretending it’s continuity is part of what stalls people.

The honest acknowledgment, because it bears repeating: this is hard. Some of these transitions are professionally scary, especially for people early in their careers. The junior engineer question is the hardest one and the industry has not solved it. Some roles that exist today, in their current form, will not exist in five years.

The opportunity is real and very large. The work that’s left — judgement, taste, outcomes, ownership, the harness — is the most interesting work software has ever had to offer. The 100x leverage is real. The new senior engineer, the new senior product manager, the new senior CS person — they’ll have a kind of impact the old versions of those roles couldn’t have dreamed of.

The transition belongs to the people who started six months ago, not the people who start six months from now.

If I got your role wrong

If you read the section that applies to you and thought that’s not quite how my work breaks down, I want to hear about it. The macro framework is the framework. The role-by-role walkthrough is my best read on it based on the conversations I’ve had this year.

The roles you don’t see here yet — data, ML, security, sales engineering, recruiting, legal-in-tech, finance ops — deserve their own walkthrough. If one of those is yours and you’d like me to think it through, send me a note.

Tell me where the map is wrong. That’s how it gets better.

What’s next

The same answer, in every role. The translation work is gone — or going. The judgement work is yours, and it’s growing.

What’s next isn’t a new job. It’s the harder half of the job you already had. The part where you decide what correct means. Where you own an outcome, not just a task. Where the question stops being did I do the thing and becomes did the thing work.

That part of your role? AI didn’t eat it. It can’t.

The translation work is gone. The judgement work is yours. That part of your role? AI didn’t eat it. It can’t.

Start there. Start now. The people who started six months ago already have a head start — but the work doesn’t close. It keeps getting more important.

That’s what’s next.

For thirty years we were glorified translators — business asked why, product defined what, engineering translated to how. AI just ate the translation step.

The org chart we never named

If you draw the org chart of any software company built in the last thirty years and squint, the same shape shows up.

There’s a small group at the top deciding why — why we exist, why this market, why now. Below them, a slightly larger group deciding what — what to build, what to ship, what to cut. And underneath both of those, the broad middle of the company, the part where the headcount actually lives — the how. Engineers, project managers, scrum masters, tech leads, engineering managers, program managers, who took the what and translated it into code, into tickets, into deployments, into release notes, into Slack messages in #releases.

I’ve been part of every layer. I’ve sat in the why room. I’ve run the what meetings. I’ve shipped a lot of how. I’ve also argued, for a long time and in a lot of rooms, that the middle of that pyramid was bigger than it needed to be — that leaders should be co-workers, not reviewers, and that managers who only managed were a tax the team paid for the privilege of having a status meeting. That argument never quite landed either. Same shape as the one I lost about tests — the cost was paid in slow, distributed ways that nobody in the room wanted to add up.

What’s on my mind a year into the agent shift is that the bill is finally getting itemised. And the line that’s getting cut is the one I’ve been pointing at for years.

Most of what we did in the middle was translation.

Business intent translated into product spec. Product spec translated into JIRA ticket. JIRA ticket translated into a branch name and a PR. PR translated into deployment. Deployment translated into a release note. Release note translated into a status update. Status update translated back upward into business language. Each step had its own ceremony, its own job title, its own meeting cadence. A whole industry of frameworks — Agile, SAFe, Spotify model, you name it — grew up around making the translation pipeline more efficient.

We were, mostly, glorified translators. I include myself in that. I include most of the best engineers I’ve worked with. The work was real and hard and required taste, but the shape of it was conversion. Take the thing in this language, output the thing in that language. Repeat.

What AI actually ate

The agent conversation keeps getting framed as “AI replaces engineers” or “AI replaces customer service” or “AI replaces analysts.” All of those framings are slightly wrong. AI didn’t come for a job title. AI came for a task type, and the task type it came for was translation.

If your job was mostly converting one well-defined input into a well-defined output — natural language to SQL, requirements to code, ticket to PR, design spec to working component, log line to incident report, customer email to ticket — your task got compressed by an order of magnitude. Doesn’t matter what your title was. The task was translation. The task got cheap.

The two ends of the pipeline didn’t get cheap. Defining why — the business reason, the strategic call, the bet — is harder than ever, because the cost of executing on a bad why just dropped to nearly zero, which means more bad whys are going to ship, faster, with more confidence. Defining what — the product call, the cut decision, the “we will not build that even though we could” — is harder than ever, because the cheaper execution gets, the more options you have, and judgement under abundance is its own discipline.

The middle is what got eaten. And the middle is where most of the org chart lives.

Hold that honestly. Not as a doom story. As a fact about the shape of work.

The manager who doesn’t contribute

Here’s a hard one, because it’s about people I’ve worked with and respected.

A lot of engineering managers exist to coordinate translation. They run the standup. They unblock the ticket. They negotiate priority across teams. They write the status update. They translate engineering progress upward into business language and business priorities downward into engineering language.

That work was real. It was load-bearing. The pipeline didn’t run without it.

But if the pipeline itself is shrinking — if the layers between why and shipped code are collapsing because agents can carry more of the conversion themselves — then the manager whose entire job was coordinating the translators has a problem. The work that justified the role is dissolving.

I’ve watched two patterns emerge over the last year. One is denial — managers who quietly defend the rituals (the standup, the status meeting, the JIRA hygiene) because the rituals are what make the role visible. The other is the shift — managers who started writing again, designing again, defining again. Who picked up an agent themselves, not to prove a point, but because the org chart underneath them got smaller and the only way to stay useful was to be in the work.

I don’t think every manager needs to write code. I do think every manager needs to contribute — to the why, to the what, to the design of the harness, to the verification of the output. Coordination on its own is no longer enough. If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.

This isn’t a vendetta against managers. I’ve been one. I’ve hired dozens. The ones I’m most worried about are the ones who optimised so hard for being good at the translation pipeline that they forgot how to do the work that sat underneath the pipeline. The pipeline is getting smaller. The work underneath is getting bigger.

What the new team actually looks like

I’ve been sketching this on whiteboards with founders for months. Here’s the rough shape that keeps showing up.

A small group of people defining why, mostly unchanged. The why layer was always thin and is going to stay thin, because conviction doesn’t scale linearly with headcount. You don’t need more people to decide why; you need a few people who decide it well.

A larger group than before defining what. Not “product managers” in the old sense — not the ticket-writing, JIRA-grooming, sprint-planning archetype. People who can sit between the why and the agent, hold the context of what’s actually being built, and make the dozens of small calls per day about what “good” looks like. This is taste work. This is judgement work. This is what The Expensive Thing was about. The ratio of what people to how people is going to flip in the next two years, and most teams are not ready for it.

A much smaller group of people doing how — and the how people who remain are doing the hardest how work. Not ticket conversion. Architecture. Trust systems. Performance. The 5% of the codebase the agent shouldn’t touch unsupervised. The harness — the specs, the eval suites, the golden builds, the agent-of-agent review patterns. Someone has to design that harness. That someone is an engineer with deep judgement, and there are fewer of them on each team than there used to be, but each of them is doing dramatically more.

And then the agents themselves, doing the bulk of the conversion work. Writing the PR. Updating the doc. Filing the ticket. Drafting the release note. Reviewing each other’s outputs.

The team that’s left is smaller in headcount and broader in skill at every level. The middle thinned. The ends thickened. Coordination collapsed. Contribution went up.

Hands-on, redefined

The phrase “hands-on” used to mean writing code. It still does, sometimes. But the deeper meaning is being in the work — close enough to the output that you can see when it’s wrong, opinionated enough about the input that you can define what right looks like.

A founder writing prompts that drive an agent’s product roadmap is hands-on. A CTO designing the eval suite that gates production deploys is hands-on. A staff engineer specifying the contracts an agent must respect when modifying core code is hands-on. None of them are necessarily writing the code anymore. All of them are in the work. The principle was always the same — passing down comments is the cheap version of leadership, and the real version is showing what’s possible by doing it. The agent era doesn’t change the principle. It removes the alibi.

What’s not hands-on is approving JIRA tickets in batches. Running a status meeting where everyone reads off their updates. Writing a strategy doc that nobody operates from. Sitting in the layer above the work, translating between what the team did this week and what the business wants next week. That layer is shrinking. The hands-on layer is the layer that survives.

This is uncomfortable for a lot of senior people. It was uncomfortable for me, when I started really sitting with it during the sabbatical. There’s an emotional reflex to defend the role you spent a decade earning. But the role was the org chart — and the org chart is changing.

What this means if you’re hiring

The hard thing to say out loud is also the first thing to get right: you’re going to hire fewer people. The team that does the same amount of work next year is going to be meaningfully smaller. Not because the people were bad. Because the translation layer collapsed. Every org that pretends otherwise is going to end up with the worst of both worlds — more tools, more headcount, slower output.

Once you’ve accepted that, the rest gets clearer. Stop writing job descriptions that read like they were generated from a 2018 engineering ladder. The senior engineer whose pitch is “I can convert tickets to PRs faster than the next person” is going to be very confused, very soon, about what they’re doing every day. You need engineers who can define a harness, hold the line on quality, and design systems an agent can safely operate inside.

The standup-runner archetype of engineering manager is over. The managers who survive are the ones who contribute — to design, to definition, to the trust system. Coordination on its own doesn’t justify the seat anymore.

And hire more what people. Not product managers as ticket factories. People who can hold a thesis, define “good” in ambiguous situations, and operate the agent themselves rather than handing intent over a wall. The ratio of what to how is about to flip. Most teams aren’t ready for it.

What this means if you’re an engineer

Don’t compete with the agent on translation. The agent will win. The agent will keep winning, faster, every quarter.

Pick up the work the agent can’t do. Define what “correct” means. Build the harness. Hold judgement. Take responsibility for outcomes the agent can’t be accountable for. Move toward the what and the why without abandoning the how — because the how people who survive are the ones who can still operate at the deepest layer when something genuinely hard breaks.

The middle is the dangerous place to be right now. Not because middle people are bad. Because the middle is where the translation work was concentrated, and the translation work is the work that’s going.

The work that’s left is more interesting and more valuable than the work that’s leaving. Defining the why and the what is more rewarding than running the standup. Designing the harness is more rewarding than approving the ticket. The shape of the team is changing because the shape of the work is changing, and the work is getting closer to what we always said we wanted — judgement-heavy, hands-on, outcome-owning. That’s not spin. It’s what happens when you strip out the translation layer and look at what’s underneath it.

The org chart, finally

I started this post with the shape of the old org chart. Why at the top, what in the middle, how in the broad bottom layer, with a manager class running the seams.

The new shape is different. The why layer stays. The what layer grows. The how layer shrinks but gets harder. The manager class either contributes or disappears. The agents do the conversion work, with a harness around them.

That’s not a layoff plan. It’s an evolution of what work is. And every leader I’m talking to is feeling some version of it, even when they can’t quite name it yet.

The work was always the why and the what. We just spent thirty years pretending the how was the work, because the how was where the headcount was, and headcount was where the budget was, and budget was where the org chart was. The headcount is going to move. The org chart is going to follow.

The teams that figure out the new shape first are going to look unrecognisable to their competitors. Smaller. Stranger. More opinionated. Closer to the work. The harness from The Tests We Skipped is what makes this shape safe to operate — without it, the small team plus agents is a faster way to ship the wrong thing. With it, the small team plus agents is what the rest of the org chart used to look like before we built the translation pipeline on top of it.

That’s the shape I’m watching for. That’s the shape I think wins.

The agents are the deadline that finally makes the room move.

The argument I lost for twenty years is the argument the industry is now winning, by accident, through the back door.

A position I held for twenty years

For most of my career I argued for writing tests.

Not quietly. In standups, in team rooms, in conference talks, in 1:1s with engineers I was trying to convince. I pushed for trunk-based development. I pushed for unit tests as the way you knew you hadn’t broken something that worked yesterday. I pushed against the pull request culture as it actually got practiced — not against review, but against the theatre of review we’d built around it.

Most people didn’t listen.

That’s not a complaint. That’s the starting condition. The conversation about AI and engineering has, in the last six months, started circling back to almost every position some of us were holding for twenty years — quietly losing the argument every quarter, watching the bug tracker fill up, getting the half-eye-rolls in standup. The new wrinkle is that the people rediscovering these positions are calling them new things. Spec-driven development. Eval-first engineering. Verifiable execution. New labels. Same practices.

This time, the industry doesn’t have a choice.

The argument for tests, in plain language

The argument was always simple, and I’ve made it a thousand times.

You write a unit test for two reasons. One: you want to know, today, that the code you just wrote does the thing you think it does. Two: you want to know, six months from now when somebody else changes something nearby, that the thing your code did then still works now. That’s it. Tests are not paperwork. They’re the thing that lets you sleep on Sunday.

The bug that comes back. The regression nobody saw coming. The release that broke a feature nobody was thinking about. Tests are the only protection any team has against those, and the protection is cumulative — every test you write today is a test that catches you next year, next refactor, next migration. Nothing else in software has that property. Documentation rots. Tribal knowledge walks out the door. Tests, if you keep them green, just keep working.

The argument against tests was always the same: tests waste time. I’d rather ship.

What that argument always dropped was the time on the other side of the ledger. Manual QA, run by hand, every release. The same regression test, executed by a human, again and again and again, because the team didn’t trust their automation enough to skip the manual pass. The bug that came back in production six weeks later because nobody wrote the test that would have caught it. The 4am incident. The customer escalation. The Sunday spent rolling back a release.

You weren’t saving time. You were deferring it onto people you weren’t counting in the same column. Often QA. Often support. Often the on-call engineer at 2am. The cost was always paid. The lie was that it wasn’t.

The PR ritual, and the responsibility it quietly moved

This is the other position I lost for twenty years. The agent conversation is finally surfacing it.

The argument: pull requests, as practiced in most teams, do not catch bugs. They perform the catching of bugs.

Here’s how it actually works in most places. An engineer writes some code. Opens a PR. The senior engineer assigned to review pulls up the diff in the browser, scrolls through it, leaves a comment about a variable name, suggests a tiny structural tweak, hits approve. They almost never check the branch out. They almost never run the tests against it. They almost never trace a function through the codebase to see what else it touches. The review takes ten or fifteen minutes — for changes that took the author days to write.

That ten-minute review accomplishes something almost worse than nothing. The author of the code, the moment the senior engineer hits “approve,” mentally transfers responsibility for the change. They wrote it. The senior reviewed it. It must be fine. When it breaks two weeks later, nobody quite owns it. Two pairs of eyes were on it. Neither pair did the actual work of verification. And nobody on the team wants to be the one to say so out loud.

I argued for years that this was upside down. That the right model was simpler: the person who writes the code is the person who pushes it to production. Full stop. Review is a conversation, not an absolution. The confidence to push has to come from the author’s own knowledge that nothing is broken — and the only way an author can know nothing is broken is if there are tests, run automatically, in a build they trust, on every commit.

No tests, no confidence. No confidence, no push.

The PR-as-rubber-stamp pattern was a comfortable lie that let everyone feel good about the process without anyone doing the work the process was supposed to be doing. It was a way to look like we cared about quality without paying the cost. I lost that argument too. Most teams kept the ritual. Most teams kept being surprised when production broke.

What the AI conversation is finally surfacing

Here’s the part that’s funny, in a tired way. Watch the AI safety conversation closely for a minute. Eval suites. Tool-call sandboxes. Approval gates. Agent-of-agent review patterns where one agent writes the code and another reviews it and a third runs the tests. Specs as a first-class artifact. Spec-driven development.

Read those phrases as someone who’s been at this a while, and you’ll notice something. None of them are new.

Spec-driven development is BDD, and ATDD before it, and executable specifications before that. Eval suites are integration tests with a different audience. Agent-of-agent review is what code review was always supposed to be — finally executed by something with the patience to actually check the branch out, run the tests, and trace the change through the codebase. Approval gates are what release management always was, before “shipping fast” turned the gate into a sticker. Specs are specs. Tests are tests.

The conversation isn’t inventing engineering rigour. It’s rediscovering it.

What’s different is the loop. When AI ships your feature in three hours, the bugs ship in three hours too. Your blast radius compressed from a sprint to an afternoon. The instalment plan you were paying on quietly for twenty years just got called in. You can’t dodge the cost anymore by spreading it across enough days that nobody feels it.

The teams that argued against tests for two decades are now standing up eval suites because they have to. The teams that argued against trunk-based development are now adopting it because long-lived branches don’t survive a codebase being modified by agents. The teams that built the PR-rubber-stamp ritual are now watching agents review each other’s code and quietly wondering what their senior engineers were doing in those ten-minute reviews all those years.

The agents didn’t break the system. The agents just ran fast enough that the broken system stopped being invisible.

The harness was always the work

You can put a harness on AI. You should. Eval suites, sandboxes, approval gates, dry-run modes, agent-of-agent review — all of it good, all of it necessary.

But here’s the thing nobody is saying out loud. Every harness you build for the agent works for the human too. The eval that catches the agent’s mistake catches the engineer’s. The acceptance criteria that pin down the agent’s task pin down the engineer’s. The golden build that fails when the agent’s PR breaks something fails the same way when a human breaks it. You’re not building infrastructure for AI. You’re building the infrastructure you should have had all along — the infrastructure some of us were asking for in 2008, in 2014, in 2019 — and the agent’s arrival is just the deadline that finally moved the room.

The argument I lost for twenty years is the argument the industry is now winning, by accident, through the back door, because agents made the cost of not having the harness suddenly visible.

I’m not bitter about this. I’m relieved. The work I always wanted teams to do is the work teams are finally doing — not because they were convinced, but because the loop got short enough that they had no choice. I’ll take wins however they come.

Spec-driven development, and other rediscoveries

I keep getting sent posts about spec-driven development as if it were a revelation. The first time someone DM’d me a thread on it, I laughed for a minute and then I felt old.

Specs were always the answer. BDD tried to make specs executable. ATDD tried to make them the source of truth. Living documentation was a phrase people used in the 2010s to describe exactly this. None of it caught on widely, because writing the spec felt slow and shipping felt urgent, and the cost of skipping the spec was paid by someone else, later — usually a QA engineer, a support team, or a 2am pager.

Now the spec is the thing the agent reads. It’s also the thing the test suite is generated from. It’s also the thing the eval is built against. Specs aren’t optional anymore because without them the agent is guessing and the team is hoping. So we get spec-driven development. Same idea, sharper teeth, new name.

I’ll take it. I don’t care what we call it. If the rebrand is what it takes for teams to finally take specs seriously, I’ll cheer the rebrand. Some of the best ideas in software take twenty years to get accepted, and they usually need a new name to get there.

The tests we skipped

I think about the engineers who argued with me, in standups, ten years ago, about whether we should have a test for this. I think about the teams that picked the PR ritual over actual review. I think about the people who said we don’t have time for tests and meant we don’t have time for the work of being right.

I’m not angry about any of it. Most of those people were doing what the industry was telling them to do. The industry has finally stopped telling them that. The shape of the work is making the case I couldn’t make, and making it more convincingly than I ever could, because the cost of skipping the harness shows up now in three hours instead of three quarters.

The tests we skipped are the tests the industry now has to write. Not because AI demands it. Because the work always demanded it, and the slow blast radius of the old world was the only thing letting us pretend otherwise.

The good news is that the work is finally easy enough to do. The bad news is that the excuse is finally bad enough to call.

More to come.

We lie to ourselves most convincingly when we call it discipline.

Three months of notes

Three months ago I wrote The Space Between Chapters. That was about the decision to stop. This one is about what happened after.

I’ve been advising founders, having long conversations with people I respect, and — mostly — paying attention to things I was too busy to notice when I was running in overdrive. Some of what I noticed was about them. Most of it, uncomfortably, was about me. Turns out when you’re constantly matching your potential and raising the bar, you build up a nice collection of stories about yourself that don’t hold up once you actually sit still and look at them.

These are six of those stories. I’m calling them comfortable lies because that’s what they are — things we tell ourselves that feel like ambition or discipline or strategy, but are really just habits we never bothered to examine. They’re comfortable because they sound right. They’re lies because they quietly do damage while we nod along.

Perfection is a spiral

Here’s what happens when you suddenly have time: you start perfecting things. That draft you never polished. That product idea you never fully fleshed out. That skill you always meant to sharpen. And because there’s no deadline forcing you to stop, you don’t stop.

I caught myself doing this within the first month. I’d work on something, get it to 90%, and then spend three times as long chasing the remaining 10%. Not because the 10% mattered — but because I could. Time was available, and perfection filled the vacuum.

I see this in founders too. The ones with runway and breathing room sometimes produce less than the ones with six months of cash and a fire under them. That always seemed paradoxical to me, but now I get it. When you have the luxury of perfection, perfection becomes the trap. It disguises itself as ambition. You think you’re being rigorous. You’re actually just avoiding the discomfort of shipping something that isn’t flawless.

“Done” is a decision you make. Perfection never makes it for you.

Stop matching your potential

People love overdrive. Especially the best ones.

You figure out what you’re good at, you hit that gear, and then you stay there. Every day. Every quarter. You keep matching your potential, and every time you match it, you move the bar higher. Match, raise, match, raise. It feels like growth. It looks like growth. Everyone around you thinks you’re killing it.

But here’s what’s actually happening — you’re chasing your own known potential so hard that you never stop to look sideways. You’re so locked into being as good as you know you can be that you have zero bandwidth left to discover what else you could be. The overdrive becomes the identity. And then you’re not even choosing it anymore, you’re just stuck in it.

I’ve seen this destroy people. Not dramatically — quietly. They burn out not because the work was too hard, but because they never gave themselves permission to operate at anything less than their known max. They kept upping the game, kept raising the bar, kept pushing — and one day they looked up and realised they were exhausted and hadn’t learned anything new in years. All that potential-matching had turned into a treadmill.

What if you deliberately lived a little below your known potential? Not laziness — slack. The kind of slack where you take that random side conversation. Where you notice a problem you wouldn’t have seen because your brain was already maxed out. Where some idea shows up uninvited because there’s actually room for it to land.

The ceiling you know about is not the only ceiling that exists. You just can’t see the other one while you’re pressed flat against this one.

Goals are byproducts

We’ve been taught to set big goals and reverse-engineer our way to them. Become healthy. Build a great company. Be a better parent.

The problem is, these aren’t goals — they’re identities. And identities are fragile. One bad week and “become healthy” feels like a failed project.

I’ve been experimenting with flipping this. Don’t make health the goal. Make exercising three times a week the thing you do. Eat sugar only on specific days. Stretch on alternate mornings. Eventually, health happens — not because you chased it, but because it was the byproduct of actions you actually controlled.

This changes how I think about strategy too. Strategic thinking doesn’t come from having a strategic goal. That sounds backwards, but stay with me. If you set “be strategic” as your north star, you end up paralysed by abstraction. But if you pick the right micro-actions — the daily, weekly, unglamorous inputs — the strategy emerges on its own. The byproduct is the strategy. The inputs are the work.

I keep telling founders this and watching their faces when it clicks. Stop measuring yourself against the identity. Start measuring yourself against the actions. Did you do the thing today? That’s the only question that matters.

Stopping lets you see

This one is personal.

When you’re in motion — shipping, advising, building, scaling — everything looks like progress because you’re moving. You develop this optimism bias that’s almost invisible from the inside. The product is getting better. The team is growing. The metrics are trending up. So what’s the problem?

The problem is that motion makes you blind to specific things. The thing that’s quietly breaking. The feedback you’ve been deflecting. The pattern you’re too busy to see because seeing it would mean stopping, and stopping feels like failure.

I watched this in myself at every stage of my career — ThoughtWorks, CodeIgnition, Gojek, PeakXV. I was always in motion. And in the three months since I stopped, I’ve seen things I couldn’t see while running. Not because I’m smarter now. Because I’m still.

The most important realisations I’ve had in three months came from weeks where I did almost nothing. Your receptors open when you stop. You start hearing what was always there. Not because nothing is productive — but because nothing got out of the way.

This is a cognitive revolution, not a job crisis

There’s a growing anxiety that tech jobs are going away. That AI is making people irrelevant. I talk to people every week who believe this, and I understand why they do — the pace of change is genuinely unsettling.

But I’ve seen this before. Not this exact thing, but the shape of it. The industrial revolution didn’t eliminate work — it created entirely new kinds of work that nobody could have named ten years before it happened. What’s happening now is the same pattern. It’s a cognitive paradigm shift, not a replacement event.

I wrote about this in The Expensive Thing — when execution becomes nearly free, judgment becomes the expensive thing. The work that requires context, taste, human connection, and the ability to define what “correct” means? That’s becoming more valuable, not less.

I see massive opportunity here. I see a need for people to recognise their own importance in this new era. Humans will be required more, not less — but the nature of what they’re required for is shifting. The tools got dramatically better. The need for people who know what to build with those tools got even greater. If you’re paying attention, this is one of the most exciting times to be building anything.

Patience is the thing I’m worst at

I’ll be honest about this one — I haven’t figured it out.

What to do is not the problem. There is so much to do. Ideas, projects, people to help, things to build, conversations to have. The problem is that seeing all of it at once creates its own anxiety. Not the anxiety of having nothing — the anxiety of having everything and not enough hours. It makes me less calm than I want to be.

I’m learning — slowly, badly — that I can’t execute everything on my own. That sentence is easy to write and brutal to actually live by. And on the other side of it, I’m also learning that I can’t delegate everything either. Some things need my hands on them. Some things genuinely don’t. Figuring out which is which turns out to be its own full-time job, and I’m not particularly good at it yet.

Patience isn’t waiting. That’s the wrong definition. Patience is choosing what to do next without panicking about everything you’re choosing not to do. Three months of space have at least made me aware that this is the real work — not the tasks, but the calm required to sequence them.

The comfortable lie

Three months is not a long time. But it’s long enough to see something clearly: we are extraordinary storytellers — especially to ourselves.

Every one of these six things was a narrative I’d been weaving for years. Perfection is rigour. Running at full potential is discipline. Big goals are strategy. Motion is progress. I believed all of it. It was comfortable to believe, because it sounded like ambition. It sounded like someone who had their act together.

That’s the comfortable lie. It’s not the things we tell others — it’s the story we construct for ourselves and then stop questioning. We repeat it so many times that it stops being a narrative and starts being the truth. And the longer you run, the harder it is to see it for what it is, because examining it would mean stopping, and stopping feels like losing.

But when you do stop — when you put everything out there and just observe — things start surfacing. The narrative loosens. You see the gap between the story and the reality. Reflection becomes easier, not because you’ve become wiser, but because you’ve finally become still enough to look.

I’m still looking. More to come.

Each wall, on its own, is solvable. That's the problem.

Drawing the map

In my last post I wrote about the small island of delight — the agent itself — surrounded by a sea of ops work. The note that followed that post was the most common: okay, I feel this. What are the walls, exactly? Name them. Make me a list so I can tell whether I’m about to hit one.

Fair.

This is that list. Ten things I keep seeing people run into when they try to run their own AI agent. I’m going to go through each one directly — what it is, what it feels like when it hits, what it actually costs. No pitches. Just the map.

A small note before we start. Most of these walls look trivial in isolation. Docker, right? TLS, sure. Memory, obviously. None of them is the problem. The accumulation is the problem. When you hit one, you lose an evening. When you hit six in a quarter, you lose the habit of using the agent.

1. Infrastructure turns into a second job

This is the first and loudest complaint, and it’s not even close. People spend more hours on Docker, YAML, SSH, uptime, VPS sizing, and restart scripts than they spend talking to their agent. The official Docker setup needs at least 2GB of RAM. Cheap $5 hosts get OOM-killed in the middle of the night. You open a DigitalOcean community thread and watch people literally write “gave up.”

What hurts here isn’t that the infrastructure is hard. It’s that you’re doing infrastructure work to get to the interesting part, which is the agent. The ratio is backwards. You should be spending most of your time on what the agent does. Instead you’re spending most of your time keeping the agent alive.

The test: if a power cut or a kernel update would silently take your agent down and you wouldn’t know for a day, you’re on the wrong side of this wall.

2. The agent’s memory quietly gives up

Everyone’s favourite bug. OpenClaw gives you 100-200K tokens of context window, which sounds like a lot until you realise tool calls and file reads eat it in an afternoon. When the window fills, compaction kicks in — summarising older messages to free up space. And anything that wasn’t already written to long-term memory gets smoothed into a summary or disappears.

The pattern looks like this: the agent is brilliant for the first two weeks. Then, almost imperceptibly, it starts re-asking things you already told it. Brand guidelines. Your tone of voice. Your team’s name. You find yourself re-explaining, and you start wondering whether it’s you or the agent. It’s the agent.

People solve this by bolting on Mem0, Cognee, QMD, knowledge graphs — pick your acronym. Each works. None of them is the user’s job.

The test: ask your agent, today, about something you told it three weeks ago. If it stumbles, this is the wall you’re hitting.

3. Security is a moving target you didn’t sign up to track

138 CVEs in 63 days. 135,000 exposed OpenClaw instances found on public IPs. 824 malicious skills planted in ClawHub, with around 12% of the registry compromised at some point. None of this is hypothetical. These are numbers from February and March of this year.

The honest truth is that self-hosting an AI agent in 2026 is like running your own mail server. Can you do it? Yes. Should a non-specialist do it? Almost never. The attack surface is enormous, the threat landscape changes weekly, and the consequences of a mistake include someone else operating your agent — with your API keys, your data, your credentials.

Most people I talk to have no idea their gateway is bound to 0.0.0.0. They don’t have a firewall. Their fail2ban is aspirational. And they have no way to tell if something has gone wrong.

The test: if you were breached last Tuesday, how long until you’d know?

4. Token bills arrive with a personality

This one bites quietly and then all at once. OpenClaw’s heartbeat feature wakes the agent every thirty minutes by default, and every heartbeat carries the full session context. Add tool calls, long context windows, and a premium model, and you can burn a million tokens in an afternoon without trying.

I’ve seen this pattern several times now. Someone sets up their agent. First week, the bill is tiny — they didn’t use it much. Second week, more use, bill creeps up. Somewhere in week three, they check their provider dashboard for an unrelated reason and see a number that makes them close the laptop. The blog post “burned 1.8 million tokens in a month and got a $3,600 bill” is not a thought experiment. That’s someone’s real Tuesday.

The fix is routing — cheap models for easy tasks, premium for complex ones — plus heartbeat tuning, plus budget caps. All of it is doable. None of it is the user’s job.

The test: can you tell me, within 10%, what your agent cost you yesterday?

5. The skills marketplace is a minefield with good lighting

OpenClaw’s skills are MCP servers, which means they’re essentially little programs that run with full access to whatever you give them. The public marketplace — ClawHub — is open to anyone. One security study found 36.82% of community skills contained vulnerabilities. Another found 824 skills that were straight-up malicious, dressed up with professional documentation and innocent names.

The tricky part is that skills are the good thing about OpenClaw. The whole point is extensibility — agents that can actually do useful things in the world. So you need skills. But every skill you install is a supply chain decision, and almost no one is treating it that way. They’re treating it like installing a browser extension. That’s how credentials leak.

The test: name the last three skills you installed, and tell me who maintains them.

6. Multi-agent setups collapse under their own weight

This one surprises people. Once your morning briefing works, it’s natural to think — what if I had one agent for writing, one for research, one for ops? Seems obvious. Seems like the future.

It turns out fewer than 10% of teams who attempt multi-agent setups keep them running. The coordination problems are brutal. Agents on a shared channel talk over each other, duplicate work, hand off in loops, argue. Every handoff burns tokens because every agent summarises before passing the baton. The concurrency caps hit faster than you’d expect. And debugging a multi-agent failure means tracing across multiple context windows that didn’t see the same thing.

Most “multi-agent” stories you read online are really one agent with better prompting. That’s often the right move. But when you genuinely need orchestration, OpenClaw gives you a pile of primitives and a lot of homework.

The test: if two of your agents had to hand work off to each other, could you trace the handoff when it broke?

7. Observability is three weekends you didn’t know you owed

OpenClaw added OpenTelemetry support in v2026.2, which is wonderful, and means you can now wire up your own observability stack. Prometheus. Grafana. Tempo or Jaeger for traces. A log aggregator. Dashboards. Alerts.

None of this comes out of the box. It’s all homework. And the people who need observability the most — the ones whose agents are doing real work — are precisely the ones who can least afford the three weekends it takes to build the stack. So they don’t build it. They run blind. Until something breaks and they’re debugging with grep on a log file at 11 PM.

This is the oldest story in ops. The tools are open and free. The time to make them useful is the real cost.

The test: if your agent took an action you didn’t expect last week, could you find out what and why, in under 15 minutes?

8. Upgrades force an ugly choice

OpenClaw ships fast. v2026.3.22 alone landed 13 breaking changes along with 45+ new features. Old directory structures (.moltbot), old environment variable names (CLAWDBOT_*, MOLTBOT_*) get deprecated without fallback paths. If you’re on a version with known security issues, you have to upgrade. If you upgrade, something in your setup breaks.

I’ve watched people hit this and freeze. They know they shouldn’t stay on a vulnerable version. They also know an upgrade is going to eat a weekend, and possibly break the skill they’ve been building their workflow around. So they delay. The vulnerable window stretches. Eventually something forces their hand, usually the wrong way.

This is the classic unowned-maintenance problem. The agent is core to your workflow, but nobody is on the hook for keeping it current. So it falls to the person with the least time — you.

The test: what version are you on, and when did you last check for updates?

9. The moment you want to share, you can’t

Solo use is the default assumption. Everything about OpenClaw — auth, config, channels, skills — assumes one person, one agent, one machine. The moment someone on your team says “can I have access too?” you discover that the answer is an hour of manual allowlists, Discord role hacks, and per-channel DM scopes.

There is no native RBAC. There is no team workspace. There is no way for one person to own the infrastructure and another person to own the agent’s behaviour. Community projects like Clawith and Mission Control exist to fill the gap, but they’re separate installs, with their own learning curves and maintenance.

Most real use cases become team use cases eventually. The agent that drafts your newsletter also drafts your cofounder’s newsletter. The agent that watches your CI pipeline also watches your team’s CI pipeline. When that transition happens, people quietly stop using it together and go back to using it alone.

The test: how would you give a colleague access to your agent for one week, then take it back?

10. You don’t know when the agent is wrong

This is the quietest wall, and in some ways the scariest. Agents hallucinate tool calls. They drift from goals in long sessions. They pattern-match on things that look like the user’s intent but aren’t. And you often don’t know it happened until someone downstream points it out.

There’s an emerging benchmark called PinchBench that targets ≥80% task completion and ≤5% tool-call error. Good targets. Also — 5% tool error is one in twenty. If your agent is acting on your behalf twenty times a day, one of those actions is likely wrong, in a way that might not be obvious.

The DIY answer is to build your own evals, approval gates, dry-run modes. Each of those is a small engineering project. Most people just… don’t. They cross their fingers and hope the agent’s next action is a good one.

The test: the last time your agent did something for you, how confident were you that it did the right thing — not the thing that looked like the right thing?

Why I keep writing this down

I don’t list these to be dramatic. I list them because every single person I’ve helped with OpenClaw has hit at least three of these walls, and most have hit six or seven. The failure mode isn’t hitting a wall — it’s hitting several, losing motivation, and quietly giving up on the agent.

That’s the outcome I most want to prevent. The agents themselves are extraordinary. The use cases are real. The value is there. What’s missing is a way to get to the value without the detour through the ops checklist.

Every wall on this list has a solution. Some are small — better defaults. Some are medium — a cost dashboard, an activity log, a curated skill registry. Some are genuinely hard — persistent memory, multi-agent coordination, team RBAC done properly.

None of them are the user’s job.

That’s the bet I’m making with ClawStation. Take the walls down, one by one, in an order that matches the pain. Don’t ask the user to become an infrastructure engineer, a security engineer, a memory architect, and an observability expert just to have an AI assistant that actually assists them.

The island should get bigger. The sea should get smaller. And the interesting work — the thing you wanted when you first got excited about agents — should be most of what you do.

If you’re hitting one of these walls right now, or you’ve hit one and walked away, I’d love to hear which one. The map gets better every time someone tells me where they got stuck.

More to come.

The tool is free. The friction is not.

It started with a friend

Few months ago, a friend pinged me late one evening. He’s a founder — not a developer, but deeply tech-first. The kind of person who reads release notes for fun, runs Homebrew updates on a Sunday, tries every new AI tool the week it drops. He’d been playing with OpenClaw for a while. Getting the Gateway up, wiring Telegram, experimenting with skills. He loves this stuff.

His question was simple. Run OpenClaw on a dedicated Mac sitting in his home office, with full access to everything — or set up a VM and wire it up properly with all the bells and whistles?

The Mac was tempting. Low effort. Plug it in, install, done. But it felt fragile — a power cut, a reboot at the wrong time, a macOS update that decides to restart overnight, and the whole thing is down. Not to mention he’s on the road often.

The VM was the “proper” path. Reproducible, backed up, restartable, safe. But then we started listing what “proper” actually meant. Ubuntu image. Firewall. SSH keys. TLS. Bot tokens. A reverse proxy. Some form of monitoring. Log rotation. Restart-on-crash. Backups. A plan for what happens when OpenClaw pushes a breaking change next month.

He could follow all of it. He just didn’t want to own all of it. He’s a founder. He wanted to spend his Saturday playing with the agent and seeing what he could build with it. Not managing Ubuntu.

We spent the afternoon doing the VM path anyway. We got it working. He was happy. And somewhere between the third certbot renewal check and the fourth “wait, why is the gateway returning 502,” we looked at each other and had the same thought.

Why is this so much work? It shouldn’t be.

The first version was small

That week, I started writing a tiny script to automate what we’d done manually. Provision a server. Install OpenClaw. Wire up Telegram. Give him back a URL and a dashboard. I wasn’t trying to build a company. I was trying to save the next friend who asked.

Then another friend asked. Then another. Most of them were people like him — founders, investors, tech-curious folks who loved to tinker but didn’t want their weekends turning into sysadmin duty. A few had already tried and quietly given up, OpenClaw running on a laptop somewhere, forgotten after the first month.

And somewhere in there, I started thinking about my son. He’s young, he’s curious, he’s the kind of kid who will absolutely want his own AI agent — and he should have one. Not one he rents from a big company. One that’s his. That he can shape, teach, play with, break, and learn from. But I’m not going to hand him a Digital Ocean droplet and a TLS guide. He’d love the agent. He’d hate the setup. And that would be the wrong lesson.

At some point I realised I’d had the same conversation half a dozen times in a month. Each time with someone who was genuinely excited about what AI agents could do, and each time watching that excitement get sanded down by the yak-shaving required to run one.

So I asked myself — why not just let everyone in on this?

Not in a grand startup pitch way. In a small, “this seems useful, let’s make it easy for more people” way. That’s how ClawStation started. One evening, one friend, one decision between a Mac and a VM, and a growing certainty that this shouldn’t be as hard as it was.

No market analysis. No pitch deck. No competitive landscape slide. Just — if I can take the hard part out of this for one friend, I can take it out for a lot of people. Including, eventually, my son.

What I kept seeing

Something funny happens when you put a product in front of real people. They tell you things the product teams and the Twitter threads and the hot takes never quite capture.

The people I was helping weren’t developers. But they weren’t non-technical either. They were the people in the middle — the investors who know what a Docker container is but don’t want to debug one, the founders who can read a log file but don’t want to spend Sunday tailing it, the curious tinkerers who love the outcome of tech but not the drudgery of keeping it alive. That’s a huge and mostly unserved group.

The pain wasn’t that they couldn’t understand the infrastructure. The pain was that understanding it didn’t save them from having to run it. You didn’t get to build cool agent workflows. You got to debug why your TLS cert didn’t renew. You didn’t get to explore memory strategies. You got to figure out why the VPS ran out of RAM at 3 AM and took the agent down with it.

People fell in love with their agents. That part I expected. What I didn’t expect was how quickly they hit the next wall, and the one after that.

The morning briefing worked beautifully — until the API bill arrived and they didn’t know why it was $180. The content automation was magical — until the agent “forgot” the brand guidelines halfway through a newsletter. The bot was a lifesaver — until it was down one Tuesday and nobody could tell whether it was OpenClaw, the VPS, the network, or a skill gone rogue.

I started keeping a list. Not because I needed a feature roadmap, but because I kept hearing the same ten or twelve things. Memory that fills up. Token costs that surprise people. Security vulnerabilities arriving faster than anyone can patch them. Skills from the open marketplace that turn out to be malware. Upgrades that break everything. Teams that want to share an agent and can’t.

Each of these, on its own, is a solvable problem. The people I was helping could solve any one of them if they really had to. But none of them signed up to solve solvable problems. They signed up to play with AI. To build something. To see what was possible. The agent was supposed to be the point. Instead, the agent was the small island of delight surrounded by a sea of ops work.

The bigger thing

I’ve been thinking about something for a while — and wrote about it in my last post. When execution gets cheap, judgment becomes the expensive thing. Agents compress execution to nearly zero. The question is what you actually do with that.

And the more I talk to people trying to use agents, the more I think the answer is: not enough yet. Not because they don’t want to. Not because they can’t grasp it. But because the plumbing keeps pulling them back from the interesting work.

88% of firms are using AI. Only 6% see real gains. That gap isn’t because the tools are bad. The tools are remarkable. The gap is because most people — and most organisations — are still stuck at step one. Getting the thing running. Keeping it running. Trusting it enough to let it do real work.

I’ve seen this pattern my whole career. At Gojek we scaled from 300,000 to 120 million monthly orders. At ThoughtWorks, at CodeIgnition, at every company I’ve advised — the hardest problems were never the ones in the spotlight. They were the quiet, boring, unglamorous ones sitting between a great idea and a working system. The plumbing. The wiring. The stuff nobody wants to think about but everyone depends on.

AI agents have the exact same problem. And right now, the plumbing is eating the time of exactly the people who should be out there exploring what these tools can actually do.

So what are we actually doing?

Honestly, I’m still figuring it out. ClawStation today is a simple thing — you sign in with Google, pick a model, connect a messaging channel, and in under a minute you have a personal AI assistant running on dedicated, secured infrastructure. No Docker. No YAML. No TLS renewal at 2 AM. It just works, and you still get SSH, a terminal, file access — the keys to the kingdom, if and when you want them.

That’s the principle. Remove the forced plumbing, not the control. If you want to go deep, we don’t stop you. If you just want the agent running so you can get on with the interesting part, you don’t pay the infrastructure tax to get there.

But that’s the beginning, not the end.

The thing I keep coming back to is the list I’ve been keeping — the walls that real people hit. Cost intelligence so you stop being surprised by the bill. Memory that actually persists across sessions. Security built in, not bolted on. Managed upgrades so you’re not stuck choosing between “vulnerable” and “broken.” Skills you can actually trust. Team workspaces for the inevitable moment when one person’s agent becomes three people’s agent.

None of this is glamorous. None of it is the stuff that makes for viral demos. But it’s the stuff between where we are and where we should be — where the island of delight is big enough that you don’t notice the sea anymore.

That’s the mission I’m slowly growing into. Not “let’s build another AI platform.” More like — how do we get everyone on AI, and what blockers can we solve along the way?

And when I say everyone, I mean it. Founders. Investors. Curious tinkerers. Small teams. My son, eventually. Anyone who wants to find out what they can do with a thinking, tool-using, always-on assistant — without first becoming their own IT department.

Why this, why now

I took a pause this year. Wrote about that too. One of the unexpected things about slowing down is that it makes space for the small ideas — the ones that start with a friend’s question on a random evening, not with a strategy document.

ClawStation is one of those ideas. I don’t know exactly what it will become. I know what it’s solving for right now, and I know who it’s for — the people who love what AI can do and have hit the wall of what it takes to run. The founder, the investor, the tinkerer, the small team, the parent who wants their kid to grow up with this stuff, not watch it from behind a paywall.

And I know the direction. Each wall people hit is a blocker between them and the value AI can actually deliver. If I can take those walls down, one by one, quietly and well, then maybe a few more of the 88% become part of the 6%. Maybe a few more Saturdays get spent playing instead of yak-shaving. Maybe a few more kids get to grow up with an agent that’s genuinely theirs.

That seems worth doing.

Back to shipping

If you’re someone who’s been wrangling with OpenClaw and hit a wall — I’d love to hear where you got stuck. If you’re someone who got it running and is now wrestling with memory or cost or security — I want to hear that too. These are the conversations that have shaped ClawStation so far, and they’ll keep shaping it.

The tool is free. The friction is not. My whole bet is that if we can remove the friction, the island gets bigger on its own.

More to come.

If expertise is approaching free, what becomes expensive?

What everyone in the agent conversation is missing

Every conversation I’ve had in the past few months — with founders, board members, investors, government leaders — lands on the same narrative. Agents are here. They write code, handle customer calls, compress drug discovery from months to hours. Move fast or die.

I agree with almost all of it. And yet the conversation keeps missing the hard part.

There’s a heuristic making the rounds: AI agents can replace human execution wherever the output is verifiable. Wherever you can check whether the work is correct, an agent can do it.

This sounds clean. It’s also the most dangerous idea in tech right now — not because it’s wrong, but because it hides the real question. The hardest problem in the age of agents isn’t building them. It’s deciding what “correct” means.

Verification is the work

I spent years scaling a platform from about 300,000 to 120 million monthly orders across Southeast Asia. At peak, we were running ~900 microservices, pushing thousands of deployments a week, with hundreds of engineers making changes every day — sometimes every hour. The engineering was hard. But the hardest part was never writing the code. It was defining what “working correctly” meant across all of that surface area.

What does “correct” mean for an ETA algorithm in Jakarta traffic versus Ho Chi Minh City? What does a “successful” driver allocation look like when you’re balancing earnings fairness, customer wait time, and fleet utilisation simultaneously? When hundreds of engineers are shipping into ~900 microservices around the clock, “correct” isn’t one definition — it’s thousands of definitions, all shifting, all context-dependent. These aren’t edge cases. They’re the entire job.

And they’re precisely the kind of judgment that agents cannot perform for you.

Think about it outside of software. A hiring rubric. A regulatory approval. A financial audit. In each case, someone had to define what “good” looks like before anyone could evaluate the output. The evaluator’s job looks mechanical — check the boxes, verify the criteria. But the person who designed the criteria? That was the real work. That was the judgment call.

Agents are the same. Everyone celebrates the agent that writes the fix, runs the tests, and deploys it without a human touching it. Sounds like magic. But someone designed those tests. Someone defined what “passing” means. Someone built the entire scaffolding that makes autonomous deployment safe. That human work is invisible in the narrative, but it’s the load-bearing wall.

The danger isn’t that agents will fail to execute. They’re getting scary good at execution. The danger is that organisations will deploy agents against poorly defined problems and mistake fast for correct.

It’s not a tech problem. It’s a management problem.

The prevailing narrative frames this as adopters versus laggards. I think the real split is different. It’s between organisations that can change how decisions get made and those that can’t.

Here’s a number that should bother everyone: 88% of firms use AI, but only 6% see real gains. That’s not a technology adoption gap. Tools are easy to buy. That’s an organisational design gap. The 6% have done something much harder than purchasing AI — they’ve reorganised authority, changed decision structures, rebuilt workflows around what agents can and cannot do.

AI adoption is not a procurement decision. It’s a management topology change.

Most organisations aren’t built for this. They have approval chains designed for a world where humans execute every step. Middle management layers whose entire purpose is coordinating human workers. Incentive structures that reward activity over outcome.

Agents don’t fix any of this. They amplify it. Good decisions get executed faster. Bad decisions — or the more common disease, no decisions — also get executed faster. If your organisation struggles to define what success looks like today, agents will just help you fail at speed.

The legacy delusion

One more thing, because I keep hearing it — especially in Singapore: agentic coding will finally crack legacy modernisation.

I’ve spent a career in legacy systems. The productivity claims are probably true for the coding part. They’re also probably irrelevant. Legacy migration doesn’t die because of engineering capacity. It dies because nobody documented the business rules, because data quality issues only surface at migration time, and because every legacy system has stakeholders who benefit from it staying exactly as it is.

The bottleneck was never writing code. It was the courage to commit to change and the patience to understand what the existing system actually does. Agents don’t solve courage. They don’t solve consensus.

So what actually plays?

If verification is the key insight, then the strategic question isn’t “where can I deploy agents?” It’s “where have I already built the infrastructure that makes agent deployment safe?”

Define “correct” before you automate. The organisations seeing real gains aren’t the ones that moved fastest. They’re the ones that spent time on success criteria, test infrastructure, and feedback loops that catch failures early. Unsexy work. Also the moat.

Reorganise around verification, not execution. If agents handle execution, the human job becomes designing verification systems, defining quality, and handling the ambiguous cases agents can’t resolve. Your org chart should reflect this. Practically, this means your Monday morning standup changes. Instead of “what did we ship?” the question becomes “what did we validate?” Instead of tracking output, you’re tracking whether the output was right. The team that used to have ten engineers building features now has three engineers and seven people defining acceptance criteria, designing test harnesses, and monitoring outcomes. That’s the reorganisation. It’s uncomfortable because it demotes the act of building and promotes the act of judging. Most engineering cultures resist this. The ones that don’t will win.

Build for the judgment layer. The premium doesn’t just shift from executors to problem-framers. It shifts to people who can define what “good” looks like when the answer isn’t obvious. That’s taste. That’s context. That’s knowing how systems behave in the real world because you’ve shipped things that broke and had to figure out why.

Be sceptical of speed. Everyone’s celebrating compression — months to hours, years to days. Speed matters, but only downstream of correctness. Compressing timelines without compressing the validation process is just faster failure.

The builder’s edge

Here’s the thing the current conversation gets right, even if nobody says it quite this way: the age of agents rewards builders.

Not builders as in people who write code. Builders as in people who spot problems, construct solutions, iterate, and take responsibility for whether things work. People who’ve shipped things that broke at 3 AM. Who have scar tissue from production incidents and systems that behaved nothing like they did in testing.

Agents are force multipliers for this kind of person. They shrink the cost of trying. They compress the iteration loop. A single person with the right tools can now produce what used to require a large organisation.

But agents don’t replace the instinct for where a system will fail. They don’t replace the discipline to define what success looks like before you start building. They don’t give you taste.

The question I hear most is some version of: if you were building from scratch today, knowing that expertise is approaching free, what would you build?

Good question. But I’d reframe it.

If expertise is approaching free, what becomes expensive?

Judgment. The ability to define “correct” in a world where execution costs nearly nothing. The institutional muscle to verify outcomes, not just produce them. The taste to know what’s worth building in the first place.

That’s the expensive thing.

Sometimes the bravest thing you can do is stop running.

Catching a breath

Sometime ago, I decided to take a pause.

Not because something was wrong. Not because I was unhappy. But because something in me asked for it — quietly, persistently, the way your legs ache after a long run and you just know it’s time to stop. After so many years of running, I needed to catch a breath.

This January, I formally concluded my chapter with PeakXV Partners (formerly Sequoia Capital India & SEA). What a run it’s been.

If you’ve read my earlier post about joining Sequoia, you know I walked in exhausted — physically broken, mentally stretched, searching for a new rhythm after gojek. Sequoia, and then PeakXV, gave me something rare: a front-row seat to an ecosystem bubbling with ideas, energy, and ambition, while also giving me the flexibility to heal.

I have nothing but gratitude. But there comes a time when even gratitude isn’t enough reason to stay. You have to listen to that quieter voice.

The people who made it extraordinary

I’m extremely grateful to Shailendra for bringing me into this journey. The mandate was clear from day one — help portfolio companies build and scale engineering teams, work closely with founders, be useful. Simple in words, enormous in practice.

Working at Surge with Rajan was one of those experiences that recalibrated how I think about early-stage companies. The energy in those rooms — founders pitching not just ideas but their lives, their conviction, their sleepless months — was electric. You can’t be around that and not be changed by it.

And then there were the conversations. Some of the most candid, unfiltered discussions I’ve had in my career happened in the corridors and coffee shops with people like Ravishankar GV and many other leaders at PeakXV. The kind of conversations where you walk in thinking you know something and walk out realising how much more there is to learn. That’s a rare and unique gift. I don’t take it for granted.

To the founders I’ve had the honour of walking alongside — your curiosity, your grit, your relentless pursuit of what’s possible — you inspire more than you know. I’m cheering for every single one of you.

Why pause? Why now?

I’ve been working since I was sixteen. Professionally since twenty-two. That’s decades of building, shipping, fixing, hiring, scaling, advising — decades of waking up with a to-do list that never got shorter. I loved it. Most days, I still love it. But somewhere along the way, the running became the default mode, and I forgot what it felt like to walk.

There’s a difference between choosing to work hard and not knowing how to stop. I was firmly in the second camp.

The truth is, I wasn’t burnt out in the dramatic, collapse-at-your-desk way. It was subtler than that. It was the slow realisation that I’d been so focused on being useful to everyone else that I’d forgotten to be present for the people who matter most — my family, my friends, myself.

Shraddha has been my anchor through every crazy ride. She’s stood alongside me — not behind, alongside — through moves across continents, through late-night calls that bled into early-morning calls, through the times when I was physically home but mentally still in some architecture review. She deserves more than my leftover attention. My kids deserve more than a father who’s always “just finishing one more thing.”

So I decided to stop. Not forever. Just long enough to remember what stillness feels like.

What slowing down actually looks like

I won’t romanticise it. The first few weeks were uncomfortable. When you’ve spent your entire adult life with a packed calendar, an empty one feels almost threatening. I kept reaching for my phone, checking emails that weren’t urgent, looking for fires that didn’t exist.

I started reading without an agenda — picking up books because they looked interesting, not because someone recommended them for “leadership development.” I went for walks that didn’t end in a call. I cooked meals that took two hours because I wanted to, not because I was optimising for anything.

I spent mornings just sitting with my family. Not planning the day, not mentally drafting a response to someone’s Slack message. Just being there. It sounds simple. It’s embarrassingly hard when you’ve forgotten how.

But then something shifted.

The most surprising thing? Ideas started showing up uninvited. When you stop cramming every minute with productivity, your brain does something wonderful — it wanders. And in that wandering, it finds things you’d never have discovered while sprinting.

Not sitting still

I want to be clear: this isn’t retirement. I’m not done. I’m just being more intentional about what I say yes to.

I’m continuing to work with people and teams where I feel I can genuinely help. Most recently, that’s been with Ally — thanks to Mohit — a not-for-profit focused on mental health. Mental health is something deeply personal to me. I’ve seen what happens when high-performing people ignore the signals their body and mind are sending. I was one of those people. If I can help build something that makes even a small difference in how we talk about and support mental health, that matters more to me than any title on a business card.

I’m also advising a few founders, organisations and teams on things I care about — engineering culture, product-market fit, new tech adoption, keeping things simple, the “how not to fail” conversations, and the messy human side of scaling. But I’m doing it at my pace, on my terms. Choosing based on impact, not obligation.

Gratitude, the real kind

There are so many people I want to thank — colleagues, ex-colleagues, friends who somewhere along the way became all three. I know that even if I try very hard, I’ll miss names. So I won’t try. You know who you are, and you know what you’ve meant to this journey.

To the entire PeakXV family — it’s been a privilege. Genuinely. Not the LinkedIn-post kind of “privilege” that people throw around. The real kind, where you look back and think, “I can’t believe I got to be part of that.”

To the ThoughtWorks family that gave me my foundation. To CodeIgnition, which became a big family that still loves each other, and eventually found its way into Gojek. To the Gojek family that tested every limit I had. To every team that trusted me with their problems and their people.

And to my family — my mother who worked tirelessly on both fronts, my siblings who showered unconditional love, Shraddha who made all of this possible, and my kids who remind me every day what actually matters. They’re also my harshest critics — which sometimes leads to unpleasant conversations, but that’s life. As Sadhguru says, “Isn’t it?” hahaha.

What’s next?

Honestly? I don’t know. And for the first time in a very long time, that feels refreshing rather than unsettling. Right now it’s just daily tinkering…

I haven’t mapped out the professional journey ahead. I’m letting curiosity lead for a bit. Meeting interesting people, exploring ideas that spark something, and staying open to whatever comes next. My calendar is friendlier than it’s been in years.

If you’re building something interesting, thinking through a hard problem, or just want to catch up over coffee — I’d love to hear from you.

More to come. For now, this is me saying — thank you, and see you around.