Built Before AI
On Conway's Law, harness engineering, and the cost of changing one without the other.
Built for the Substrate
Cursor reportedly crossed two billion in ARR with around 50 en
gineers: no PMs, generalists who ship code, talk to users, and help hire on the same Tuesday. Anysphere, OpenAI’s Codex team, and a growing list of post-2024 startups all describe variations of the same shape. Small teams, generalist-heavy, monorepo, agent-native tooling, almost no traditional product-management layer. The phrase catching on for it is AI-native engineering team.
The shape works for them. The question I keep hearing from leaders running orgs that were built before any of this was possible isn’t whether to reorganize the same way, it’s how fast they can. Forty million dollars in revenue per engineer is too good to ignore.
I want to push back on the framing.
What’s Underneath the Shape
AI-native orgs are shaped that way because the substrate underneath supports it. The org chart didn’t come first. The substrate has two halves, technical and cultural, and both have to be there for the shape to work.
Start with the technical half. The codebase lives in a monorepo so an agent can see it in one pass (Nx and Spectro Cloud have written about why this matters). Deploys run on aggressive trunk-based pipelines. The test and feedback infrastructure is built for agent loops rather than human review cadences. Context is codified in machine-readable form, with AGENTS.md files and internal docs that an agent can parse without a translation layer. Observability is tight enough to close the loop the moment an agent’s PR breaks something. Generalists can ship end-to-end because the codebase is browseable in one shot and the test suite catches regressions in minutes and the deploy is reversible if it doesn’t. Strip those properties out and “generalists shipping end-to-end” becomes “generalists creating fires across services they don’t own.”
The cultural half is where engineers were born making product decisions. They were hired into a culture where the engineer talks to users, picks what to build next, and ships without a PM clearing the request. There was never a PM layer to displace, never a backlog grooming ritual to dismantle. The Cursor pattern of “ship code, talk to users, help hire on the same Tuesday” is the cultural substrate, older in the company than any of the agent tooling.
This is the half that’s hardest to copy. A traditional org can build a monorepo over months. It cannot order its engineers to suddenly own product judgment, or restore a PM-less culture by deleting the role. The Autonomy Paradox described the failure mode of asking engineers to act as owners while the structure denied them the authority. The mirror failure is laying the AI-native shape over engineers who came up under a different model. Some will rise to it. Many won’t, because the habits the shape requires take years to develop, and a reorg doesn’t accelerate them.
Copying the Shape Alone
Picture the legacy enterprise that decides, at the next leadership offsite, to be more like Cursor. PMs are moved to a horizontal discovery function. Teams are reshaped into smaller, generalist units, and engineers are told to own their products end to end. The AI-native shape, six months from slide to org chart, with nothing else changed.
What happens next is what The Autonomy Paradox described, except faster. The ownership boundaries that used to slow duplication down are gone. The systems underneath haven’t moved. Same service-oriented architecture, same coordination cost. But now nobody is responsible for the boundaries that the architecture still requires, and agents are happy to spin up a duplicate of any service in a weekend. HFS Research has called this directly: layering AI on brittle systems accelerates the dysfunction rather than masking it.
Removing the ownership boundaries doesn’t escape the paradox. It just lets agents fill the duplication trap faster than humans ever could.
The Two Honest Paths
There are only two honest paths from where most orgs sit today.
The first is to keep the traditional design and use AI inside it. The Autonomy Paradox‘s model still applies, with systems treated as products, EMs owning the technical strategy, and initiatives flowing across the teams that own the relevant pieces. AI becomes a tool engineers use to ship faster inside the existing boundaries, not a license to dissolve them. This path is unglamorous and doesn’t make for a good board slide. It also works, and the org can sustain it without a substrate transformation it isn’t ready for.
The second is to change the substrate and the org together, slowly. This is years of work, not a reorg. The harness work has to happen first: feedback loops, codified context, test and deploy infrastructure where mistakes don’t compound. The underlying technology choices probably need to evolve too. Only after that, with the substrate in place, should you start dissolving the ownership boundaries that the old substrate required. This path is much more expensive than it looks on the slide. The cost is real, paid in technical work that leadership often hasn’t budgeted for.
What there isn’t is a third path where you change the org shape and leave the substrate alone. Call that what it is: an unsupervised version of the same paradox, with no one responsible for the systems that hold it together.
Harness Engineers, in Both Worlds
Whichever path an org takes, there’s a horizontal layer of work that keeps showing up. Martin Fowler has written about it under the name harness engineering: the work of designing the environments, feedback loops, agent guardrails, and codified context that make agent-driven development reliable. Sean Goedecke’s argument that the coding agent itself is commoditized lands in the same place. The differentiation lives in the harness, not the model behind it. The model is interchangeable; the harness is the moat.
This is the next evolution of platform engineering, not a new role. In a traditional org, the platform team builds developer experience for humans, and the consequences of a bad platform decision are felt at human pace. In an AI-native or transitioning org, the platform team builds for humans and agents both, and the consequences of a bad decision are felt at agent pace, which is faster than anyone catches mistakes. The harness is what closes the loop fast enough to keep the rest of the org safe.
The point applies even if you’re committed to keeping the traditional org design. The harness work is real and growing, and someone has to own it. Otherwise it drifts, and the org leaning on it doesn’t notice until the day it can’t lean anymore.
Choosing Honestly
So back to the leadership offsite, and the slide that compares your revenue per engineer to Cursor’s.
Cursor’s number is a result of substrate choices that were made years before any agent showed up, including the cultural ones nobody can buy in a quarter. Asking your org to produce that ratio without making those choices is asking for a different company than the one you’re running.
The model from The Autonomy Paradox is the right model for the substrate most orgs sit on today. Evolving the substrate is the real work. Anything else changes the org chart and leaves the company underneath it where it was.
The first move isn’t choosing a substrate, it’s understanding the one you already have, and deciding whether the org you want can sit on it. If it can’t, the work is to change one or the other. Be honest about which one, and about how long it will take.
Author Notes
The Autonomy Paradox was written a while back. This follow-up came together because the conversation it sets up is happening everywhere right now: executives reading about 1–10 person companies producing real revenue, and asking why their org can’t look the same. The two pieces sit together as a pair because they’re answering the same question from two angles: what’s the right org shape for engineering teams in 2026, and how much of that depends on what’s underneath. I don’t think you can answer the first question without answering the second.
The honest answer to “how fast can we produce that shape” is “probably not as fast as you’d like.” The interesting question is what you do with that, and that’s the one I’d like to keep thinking about with anyone who’s working through it.