Your Org Design Isn’t Broken. It’s Just Built for a World That No Longer Exists
Before we start: I’ve partnered with someone at the epicenter of this shift.
Rohan Varma is a Product Manager on Codex at OpenAI, their fastest-growing product since GPT. Before that, he was the first PM at Cursor, which scaled past $1B ARR faster than almost any B2B company in history.
So what follows is not theory from the outside. It’s the operating model from someone building it at the frontier:
There’s something that doesn’t add up when you look at how the most successful AI companies actually operate, and I think about this constantly.
Codex - the fastest growing product of OpenAI after GPT- just runs on two PMs, one designer, and roughly 40 engineers, collectively responsible for 10 to 12 distinct product surfaces. At any traditional company, each of those surfaces would warrant a dedicated squad of 15 to 20 people.
Cursoroperated almost identically (40 engineers, one PM) and scaled to over a billion dollars in ARR faster than almost any B2B company in history.
Obsidian, a note-taking app used by over a million people and valued at $350 million, runs on 3 engineers and 9 total employees. No VC funding. No org chart. No middle management layer.
And then there’s what Sam Altman said earlier in 2024 that we’ll see the first one-person billion-dollar company within our lifetimes, possibly very soon, powered entirely by AI agents doing what used to require hundreds of people and it REALLY happened…
A company called Medvi, built by Matthew Gallagher, has become one of the strongest examples of AI-enabled leverage.
In 2025, he did $400M+ alone and now in 2026, they’re projected to do $1.8 billion & he has now hired his brother too (imagine just two people).
Not to mention the crazy rise of OpenClaw: how Peter single-handedly built one of the most useful AI personal assistants and scaled it so massively that it became a household name worldwide is insane. Again, just one person with a bunch of agents.
If you showed these numbers to a VP of Engineering at any large enterprise, they’d tell you these companies are running on borrowed time. That you can’t sustain quality, reliability, and growth at this scale without proper resourcing. And for most of the last 30 years of software history, they would have been completely right.
But something changed. And most organisations haven’t fully reckoned with what.
We ran a hackathon with a large enterprise recently: the kind of company with thousands of developers and a mature engineering culture. They scoped a modernisation project at 10 engineers, 12 months.
Our two engineers with Codex completed it in JUST THREE DAYS. Imagine that.
The two engineers who did that in three days think in this operating model by default.
You can learn it directly from the people building it: Rohan, who wrote this piece, teaches it live inside Product Faculty's AI Builder Fellowship, alongside PMs and AI leads from OpenAI, Google, and Anthropic.
The tools were the same. The intelligence was the same.
The difference was that those two engineers weren’t operating inside a system designed for the old constraint. That result didn’t make headlines the way a new model launch does.
But it’s the evidence that the operating model in the AI-native world itself is up for rethinking from scratch.
My Goal with this Newsletter Deep Dive
This isn’t a list of AI tools to adopt. It isn’t a framework for running better sprints.
It’s the full structural logic of how AI-native companies are organised: the people model, the process model, the tool model, the economic model… and what it looks like to start rebuilding in that direction from wherever you are today.
Because the gap between companies that understand this at a structural level and companies that are layering AI onto their existing operating model is going to be one of the defining competitive fault lines of the next five years.
It starts with the single assumption that every product organisation is currently built on: one that almost nobody has made explicit, because until very recently, nobody needed to.
Section 1: Hardcoded to Code: The Assumption Baked Into Every Product Org
Every decision your product organisation has ever made traces back to the reality so foundational that nobody wrote it down. The belief is this: writing code is hard, and engineers are your scarcest resource. Pull on that thread and watch how much unravels.
Every coordination layer was a rational response to one scarce resource. Remove the scarcity and the layers become overhead.
The org chart you’re running right now isn’t the result of careful organisational design. It’s the accumulated fossil record of every time your company ran into that constraint and built something to manage it.
People:
You hire more engineers, then hire layers to coordinate them: EMs, TPMs, scrum masters
You hire PMs to ruthlessly prioritise because you cannot waste a single engineering cycle
You hire specialists at every layer (QA, security, platform, data) because the work becomes too complex for generalists
Then you hire people to manage the specialists
Because everybody knows that 30 to 50 percent of total effort in any traditional team right now is pure coordination overhead. Not building or shipping or creating value.
The builder mentality on that card is exactly what AI-native companies are hiring for right now, and it is teachable.
Sprint planning exists to make sure engineers build the right thing before they start, because changing course is expensive
Backlog grooming exists for the same reason
Code review exists because every human-written line needs another human to verify it before it touches production
QA, staging, feature flags, phased rollout, on-call incident response: every checkpoint exists to protect expensive engineering time from waste
Tools:
The IDE is a precision instrument for one engineer writing code character by character
Jira exists to coordinate humans across a slow-moving pipeline where work takes weeks
Daily standups exist because when work moves slowly and dependencies are everywhere, people need regular synchronisation just to stay unblocked
Another way to think about it: your org structure is quietly holding you back from what AI now makes possible.
If we were starting from scratch today, with the tools available today, would we design our organizations the same way?
(AI-native companies built in this era might be our best guide for what the answer looks like.)
The answer, almost universally, is no.
That gap (between what you’d build from scratch and what you’re actually running) is precisely the opportunity and the threat hiding inside every product organization in the world right now.
Section 2: Turns Out Code Is No Longer Hard
When coding agents started appearing a few years ago, most engineering leaders filed them under ‘productivity tools’: the same mental category as a better IDE, a smarter autocomplete, a faster CI pipeline.
When building the wrong thing costs 30 minutes of agent time, whole stages of the old process stop earning their place.
But the tools didn’t stay there. In just two years, they evolved through three distinct phases: autocomplete assistants like GitHub Copilot and Cursor Tab, to task-level CLI agents like Claude Code, to fully agentic systems like Codex that take complex work, iterate, and ship results on their own.”
Just to put things in perspective: A task that takes an engineer ten hours now takes ten minutes with Codex.
Learning to operate at that speed is a skill, and it is the one the AI Builder Fellowship is built to teach, live, from the frontier.
Six certifications worth $19,245 separately, $3,450 for the year before it moves to $5,000.
At Codex and Cursor, entire phases of the traditional SDLC have collapsed or disappeared:
Code review as a separate stage? When agents verify their own work at the point of generation and humans review outcomes rather than line-by-line diffs, the traditional review process is redundant.
Elaborate sprint planning? When building the wrong thing costs thirty minutes of agent time instead of two weeks of engineering time, you can afford to build first and evaluate second. Which is exactly what we do.
The build/decide sequence? Completely inverted. The question is no longer “should we build this?” asked about a spec. It’s “ I had this idea based on XYZ. We built this - should we ship it?” asked in front of a working product that an agent put together overnight.
This one inversion changes the entire epistemology of how product decisions get made, because you’re no longer deciding based on reasoning about what something might be, you’re deciding based on direct experience of what it actually is.
Now, let’s dive into the AI Operating model.
Section 3: Layer 1: People — The AI-Native Talent Model
If you want to understand how an AI-native company thinks about people, forget everything you know about org design and start with a single question: what is the actual work that only a human can (and should ) do right now, and what is everything else?
At Cursor and Codex, the unit of work is almost never more than two or three people: not per squad, but per initiative, including initiatives that at a traditional company would have fifteen to twenty people assigned to them.
Every person added to a team adds coordination overhead. The AI-native answer shrinks the initiative, not just the headcount.
That isn’t a resource constraint (they’ve billions in funding) being managed heroically. It’s a structural choice rooted in a simple insight: every person you add to a team doesn’t just add capacity, they add coordination overhead. And that overhead compounds.
Fifteen people can spend more time in coordination than creation without anyone noticing.
But the reframe that matters most here isn’t about cutting headcount.
The leaders who look at this and see a cost reduction opportunity are making a category error. The right frame is leverage.
The reactive ones say: great, I can cut headcount by 80%.
The category-defining ones say: now I can actually do 5x more things.
Output doesn't shrink, it multiplies. Each role moves up a level, from doing the work to directing the agents that do it. Source: The VC Corner, 2026.
Output doesn’t shrink. It multiplies. And now you have five compounding bets running in parallel instead of one heavily-staffed bet moving slowly.
In a traditional product organisation, a significant portion of PM work is operational:
Managing the backlog
Running sprint ceremonies
Writing tickets detailed enough for engineers to execute without ambiguity
Coordinating between design and engineering
Tracking progress, running retros
All of that exists because someone has to manage the human pipeline. In an AI-native company, almost none of it exists in the same form. What the PM role collapses into (and expands into) is two things:
Strategic direction & being a builder on a horizon of twelve months or more: making sure the organisation is pointed at the right mountain, funding the right long-horizon bets, staying two degrees ahead of where engineering is naturally going to take the next step and eventually moving away from PRDs to building a working prototype themselves.
Go-to-market: making sure what gets built actually reaches the people who need it and generates the business outcomes that justify the work.
That second part carries a strange status problem in product culture. GTM sounds less intellectually interesting than product strategy, less creative than design. It has a faint whiff of salesmanship that product people have historically kept at arm’s length.
But in an AI-native company where the build is nearly free and the strategic direction is set, the question that actually determines whether the business succeeds is almost always a GTM question.
Can you get this to the right people?
Can you price it in a way that captures the value it creates?
Can you build the feedback loops that let you iterate toward what the market actually wants?
That’s where the leverage exists.
The Engineer Role: Writing Code to Managing Agents
Jensen Huang said this about top engineers at Nvidia:
“Let’s say you have a software engineer or AI researcher and you pay them $500,000 a year; At the end of the year, I’m going to ask that $500,000 engineer: How much did you spend in tokens? If that $500,000 engineer did not consume at least $250,000 worth of tokens, I am going to be deeply alarmed.”
The best engineers today are running multiple workstreams simultaneously, each delegated to an agent, reviewing outputs rather than writing every line, making architectural and strategic decisions that shape what agents can do rather than personally doing the work.
“If you are ever watching an agent work, you are wasting your time.”
Your job is to be the strategic layer between them all and managing outcomes.
And remember, when an agent fails at a task, the failure is almost never an intelligence problem.
Instead of concluding “agents can’t do this”, ask “what would I need to give every future agent to make sure this doesn’t happen again?”
To close context gaps, you can either build context/soul-style .md files, or set up an LLM-based learning system that continuously pulls context from your apps every ~20 minutes and keeps improving over time (Andrej Karpathy has a great explanation of this).
The Designer Role: From Craft to Creative Direction
For most of design history, the designer’s leverage was “in” the making.
The ability to hold Figma in your hands and produce something that an engineer could actually build… that was the skill. The bottleneck was craft, and craft took time.
That bottleneck is dissolving.
Designers at the frontier are shipping PRs directly through Codex because the gap between intent and implementation has collapsed, and with it, a large portion of what the traditional design role was actually doing.
What remains (and what expands) is two things:
Taste and creative direction at a higher altitude. When anyone can generate a reasonable interface in minutes, the question shifts from can you make it? to “do you know what it should be?” The best designers are becoming something closer to creative directors: setting the aesthetic and experiential standard that agents and tools execute against, writing the briefs, reviewing the outputs, and catching the ten thousand ways a generated interface can be technically correct and completely wrong. Judgment is the scarce resource in a designer’s arsenal.
Systems thinking over screen thinking. When agents are producing interfaces, variations, and flows at volume, the designer’s job isn’t to design each one. It’s to set the standard that makes each one consistent without being touched. That means the design system becomes your primary leverage. Not as a component library that engineers reference, but as a set of constraints precise enough that AI-generated output inherits your taste by default. The designer who builds that foundation shapes everything downstream, including the things no one will ever individually review.
Ramp’s product designer job description makes it operational.
Ramp's product designer job description makes it operational: the LLM is the starting point, Figma is the record.
This is what they expect you to do:
Start in an LLM. Use Claude to clarify intent, draft short PRDs, surface risks, edge cases, and initial approaches. Align the team before a single frame is made.
Validate assumptions with self-serve research. Talk to customers directly. Run quick tests. Treat research as a velocity tool, not a gate.
Prototype using AI tools. Use tools like Codex to build and iterate on flows and simple interfaces. Let AI generate the code while you guide structure, behavior, and UX quality. Partner with engineers to decide what moves into the product.
Then (and only then) bring it into Figma. Translate validated concepts into full state coverage, system alignment, and production readiness.
Notice the sequence. Figma is last. It’s the finisher, not the starting point. The work happens in LLMs and prototypes and customer conversations first. Figma is where you land once you already know what’s right.
The Only Hiring Signal That Matters Now
Ramp’s Co-founder: “We only hire builders (and we’re on a hiring spree)! Reply with something you’ve built. I’ll read them personally. We’re interviewing the best ones.”
Curiosity/ “builder mentality” is the single hiring signal that predicts success across every role in an AI-native organisation.
Not seniority or domain expertise or years of experience with a particular stack.
The people winning are the ones who feel productive discomfort every time they do something manually that an agent could have done. Who asks “why didn’t I just run an agent for that?” the same way a good engineer asks “why is this code duplicated?”
If you want to master frontier AI skills and become AI native builder & operator companies are desperately looking to hire, then there’s nothing better than @Product Faculty’s AI builder fellowship.
The AI Builder Fellowship gives you unlimited access to every LIVE certification (Not recorded videos) they run (6 at the moment) for an entire year, taught by some of the people building AI at the frontier, including OpenAI Product Manager (Rohan - author of this article as well), Google Senior AI Product Managers (Shubham Saboo), Google’s Head of AI Models, and executive leaders from many of the world’s leading AI companies, including but not limited to:
If you’re serious about becoming an AI-native builder, there’s no better place to start.
Section 4: Layer 2: Process — The AI-Native Workflow
Most organisations struggling to transform their product processes aren’t struggling because they lack the tools or the talent. They’re struggling because the logic of the old process is so deeply embedded that even when they adopt new tools, they unconsciously reconstruct the old process around them.
The AI-native workflow isn’t a faster version of the traditional SDLC.
It’s a different thing entirely, built on a different answer to the question of what’s scarce and what’s cheap.
Build First. Decide Second.
In a traditional product process, you build late.
The sequence looks like this: Identify problem → validate hypothesis → write spec → design review → technical scoping → stakeholder alignment → engineering begins
The traditional sequence builds late. The AI-native sequence builds first, so decisions come from a working product, not a spec.
In an AI-native process, the sequence collapses:
Identify direction → agent builds working version in 30-40 minutes
→ team evaluates real software → decide whether to ship
At Codex, we ship roughly two out of every ten things we build. The other eight get thrown away, parked, or inform the next idea.
This also changes what good product judgment actually means.
In the old model, it meant being right before you built: predicting what would work before committing resources.
In the AI-native model, it means recognising signals in a working prototype: knowing what to iterate on versus discard. And because you can test internally before committing, the stakes of being wrong drop dramatically.
You don’t have to be right. You just have to be willing to try.
The skill shifts from predicting to evaluating.
What Happens to Planning
At Codex, we don’t do sprints.
We don’t have a centralised backlog groomed on a two-week cadence. We don’t do sprint planning meetings or retrospectives.
Engineers at Codex are largely self-directing day-to-day, moving toward a direction the product team has set on a twelve-month horizon, making local decisions without a process gating every one of them.
What the PM does instead is think further out and act more externally:
Are we investing in the infrastructure that will matter in six months?
Are we building relationships with customers who will tell us what matters in twelve?
Are we funding the long-horizon bets that engineers won’t naturally prioritise because the immediate next step is always clearer than the strategic direction three steps from now?
That’s where the PM earns their place in an AI-native team.
What Happens to Code Review
When an agent is handling the mechanical checking, code review changes shape. Less line-by-line verification, more outcome evaluation:
Does this work the way we intended?
Does it behave well at the edges?
Does it fit the product strategy we’re executing against?
Those are judgment questions, not technical auditing questions and that’s exactly what code review should be when the machine has already done the rest.
The Workflow Decomposition Method
The total spend can be similar. What changes is the shape: salaries become tokens, headcount becomes judgment.
There’s a practical method any team can apply immediately, regardless of where you are in your AI transformation. Take any repeating workflow and decompose it into its atomic steps. Write them out literally. Then sort every step into one of two buckets:
Human judgment required: decisions that need taste, creativity, relationship, context, or accountability that only a person can carry
Information processing: steps that follow a pattern, move data from one place to another, apply a rule, or produce a deterministic output given the right inputs
The second bucket is almost always larger than people expect. And it’s the category agents can own right now, with minimal friction, starting this week.
The most important thing to understand about the AI-native process is that it doesn’t feel like efficiency. It feels like creative freedom.
Engineers building things they never would have attempted, PMs exploring ten hypotheses, designers seeing their ideas in production the same day, etc and I believe every leader should give full autonomy to their teams.
Section 5: Layer 3: Tools — The AI-Native Leverage Infrastructure
Two things have changed at the tool layer that matter enormously and each one has implications that go well beyond the engineering team.
From IDE to ADE — The Agent Control Plane
What’s replacing the IDE isn’t an upgraded version of it, it’s something categorically different.
I think of it as an ADE: an Agentic Development Environment.
The IDE served one engineer editing one file. The ADE serves one operator directing a fleet of agents.
In an ADE like Codex, you’re not just writing code. You’re:
Briefing agents and running them in parallel
Connecting them to your tools: Slack, Gong, Notion, Linear, your codebase
Reviewing what they produce and deciding what to act on
The interface is less about technical precision and more about delegation clarity: can you describe what you want well enough that an agent can go do it? That’s a skill, but it’s one that a PM, a designer, a finance analyst, or an event planner can develop just as readily as an engineer.
Whatever your role is, build more agents to do your task because there will come a point where you won’t be able to compete with anyone or your competitor if you’d just be “using AI” here and there.
No. Agent for every single work and keep refining it until it gives the output as yours or even better.
In the future, you’ll see many roles where the whole job would be to just manage, build, and scale autonomous agents or you can call it, “agentic transformation.”
Token Economics: The New Unit of Business Value
In a traditional technology business, the dominant cost is human capital: salaries, benefits, equity, recruiting, onboarding, management overhead. Headcount is the primary lever for both capacity and cost. You want to do more, you hire more.
AI-native businesses will increasingly look different but the transition is still playing out in real time.
A year ago, inference costs were low enough that the only thing that mattered was adoption: getting people to actually use the tools. That’s still where most organizations are today. Agents exist, but most employees aren’t using them heavily, so leadership is still focused on the basics: are people using this at all?
The best orgs are already thinking differently. The people burning the most tokens aren’t a cost problem, they’re a signal. They should be put in front of the rest of the organization to show everyone else what’s possible. Token spend, at current levels, is not something to worry about. The value returned is orders of magnitude higher.
A year from now, that calculus may shift. As agent usage scales, inference spend will start showing up meaningfully in budgets, and organizations will need to think more deliberately about where they’re directing that intelligence and why.
But that’s a future problem. Right now, the constraint isn’t cost, it’s imagination.
Section 6: How to Start - The AI Leverage Playbook
The question I get asked most often by the leaders: “okay, I understand the direction, but where do I actually start?”
The honest answer is that there’s no single right entry point. A nine-person startup has different constraints than a forty-thousand-person enterprise. But there are principles that hold across all of them, and there are failure modes that show up so consistently that they’re worth naming before anything else.
The Two Failure Modes to Avoid
The first and biggest failure mode (by a significant margin) is optimising the old system instead of rethinking it.
The second failure mode is trying to transform everything at once
Here’s how to move forward:
Start With Greenfield Pockets
The most reliable way to begin is to find one initiative ( ideally something that doesn’t touch your existing systems, processes, or products) and staff it with two people who have high curiosity and a genuine willingness to operate without the guardrails of the old model.
Give them a real problem, access to the best coding agents available, and explicit permission to ignore how things are normally done. Then get out of the way.
The greenfield constraint matters for a specific reason. When you introduce AI-native ways of working into an existing team on an existing product, the existing process exerts enormous gravitational pull and it gets messy. But in a greenfield space, there’s no existing process to default to: so the team builds from scratch, and what they build almost inevitably looks like an AI-native operating model, because that’s the most natural response to having powerful tools and no legacy constraints.
Cisco - one of the oldest and largest technology companies in the world - they’ve been going wall-to-wall with Codex, starting exactly this way: greenfield pockets of two to three high-curiosity engineers working on modernisation projects that were previously considered too expensive or too slow to attempt, delivering in days what would have taken months.
Apply the Pain Test Across Your Organisation
Once the greenfield pocket has demonstrated what’s possible, the next step is institutionalising a simple cultural reflex across every team: when something hurts to do manually, treat that pain as a signal, not a condition.
“Ask immediately: could an agent have done this?”
99% of the time, the answer is yes, or even maybe, that’s the next thing to work on. Most organisations have an enormous backlog of manual work (in every single department) that nobody has ever seriously thought of automating it with agents. You know exactly what I’m talking about: daily reports, marketing/finance data, analysis, etc.
A useful structure for operationalising this: a monthly workflow decomposition session.
Thirty minutes, any team, any function. Take one repeating workflow.
Break it into atomic steps. Sort every step into the two buckets: human judgment required, or information processing.
Then assign someone to spend an afternoon building an agent to own the information processing steps.
The output is either a working automation that saves time forever, or a learning about what the agent needs that makes the next attempt five percent better. Either outcome is worth the afternoon.
But the more important point is who’s doing this. The best results don’t come from top-down transformation programs: they come from curious individuals using tools like Codex to automate smaller parts of their own job, figuring it out on their own terms. Then sharing what they find. Those people will discover more, faster, than any centrally coordinated initiative will.
Top-down does make sense in specific cases: rolling out AI code review, setting standards, making infrastructure decisions. But the experimentation layer? That belongs to the people closest to the work.
Don’t Optimise the Old System, Rethink It
Please, stop making your existing operating model more efficient and start questioning whether it should exist in its current form at all. Think about what you would build if you were starting from scratch today. Genuinely starting over, with the tools available now, knowing what you know about your business, your users, your market.
What would the team look like?
How many people, in what roles?
What would the process look like?
Would there be sprints? A backlog? A design handoff process?
What would the tools stack look like?
How would work get initiated, executed, reviewed, and shipped?
And then start building it & operationalise with clarity and hold everyone accountable.
Know Which Archetype You Are
There are three types of company at this moment, and which one you are should determine the pace and nature of your response.
The Legacy Company: pre-cloud, large engineering teams built for a world of expensive, scarce code. Companies like Cisco, traditional financial institutions, industrial conglomerates. They know they’re behind. They’re willing to do the aggressive, disruptive experiments that more comfortable companies won’t attempt. They have to move fast enough to matter while navigating organisational complexity that AI-native companies simply don’t have.
The Digital-Native Company: cloud-based, modern stack, built in the last ten to fifteen years, currently doing well by most measures. Airbnb, Databricks, the well-run SaaS businesses that dominate their categories. These companies are, in my view, in the most genuinely precarious position, precisely because they don’t feel precarious. See how companies like Ramp or Airwallex are moving and how Stripe is operating today. You’ll understand exactly what I mean.
The AI-Native Company: built in the last two to three years, from scratch, without legacy constraints, with agents baked into the operating model from day one. Codex, Cursor, Anthropic, etc the wave of companies being founded right now by people who’ve only ever known an AI-augmented way of working. The advantage is the clean slate. The challenge is staying AI-native while maintaining FOCUS as you scale: because as teams grow and enterprise customers arrive with their own process expectations, the gravitational pull toward traditional operating models gets stronger.
Whichever archetype you are, the direction of travel is the same. The pace and starting point differ, but the destination doesn’t: an organisation where human judgment and creativity are the protected resources, agents handle the execution layer, and the binding constraint on what you can build is how clearly you can think, not how many people you can hire.
That’s the playbook. And what comes next is bigger than all of it.
Section 7: Where This Goes — Beyond Code, Beyond Product
Coding Was Just the First Domino.
Coding wasn’t the first frontier because software is special. It was first because the models got good enough at coding first: code is verifiable, has clear success criteria, and there’s an enormous corpus to train on. But the intelligence that got good at code isn’t confined to code.
Look at where it’s already happening:
Legal: Three years ago, AI summarised contracts. Today, Harvey drafts complex documents and conducts due diligence at a level that would have taken a team of junior associates weeks.
Finance: Three years ago, AI pulled spreadsheet data. Today, agents build entire financial models and surface insights analysts would have taken days to develop.
Sales: Three years ago, AI suggested the next email. Today, agents research prospects, personalise outreach at scale, and flag the exact moment for a human to step in.
Every function is on this curve. Most are twelve to eighteen months behind where coding is today.
And it’s already happening inside the companies building these tools. Every employee at OpenAI uses Codex, not just engineers.
Finance teams are building their own automations.
Events teams are spinning up workflows that would have required a developer six months ago. The people closest to the work are figuring out how to use these tools on their own terms, and what they’re building looks nothing like what anyone would have predicted.
That’s the tell. When the finance team starts shipping software, the org chart stops being a useful map.
The Binding Constraint Is Shifting For Every Business
Every organisational system ever designed… from Frederick Taylor’s scientific management to Bezos’s two-pizza teams… was fundamentally an attempt to extract more from that scarce resource (human execution capacity). That constraint is loosening in a way that has no historical precedent.
When execution is nearly free, strategy becomes everything.
The question shifts from “can we build this?” to “should we build this?”... and that’s harder, not easier, because the set of things you could build expands so dramatically that the choosing becomes the hard part. The organisations that win aren’t the ones with the most people or capital. They’re the ones with the clearest thinking about what’s worth doing: the best taste, the deepest user understanding, the most accurate model of where value actually gets created.
The Most Valuable Resource Is Shifting
The most valuable resource over the next 5–10 years won’t be talent - it will be compute, and it’s only getting more expensive from here.
Right now is the cheapest window you’ll ever have to experiment, so give your team autonomy (within budget) and push them to go AI-native because the same experiments will cost 10x more later.
The Reinvention Cycle: The Only Durable Strategy
I want to be honest about the limits of prediction here. Even at OpenAI, building the models, watching them train… we cannot predict what a model will be capable of once training finishes.
The capabilities are emergent. They surprise us. Regularly.
Which means the most dangerous strategy right now is building for a fixed picture of what AI can do. The leaders positioning themselves best aren’t the ones with the most detailed five-year AI roadmap. They’re the ones building organisations capable of continuously reinventing themselves… running what I think of as the Reinvention Cycle:
Sense: What new capability exists now that didn’t exist ninety days ago?
Rethink: Given that capability, what part of how we work is now suboptimal?
Rebuild: What’s the minimum change to our people, process, or tools that captures the new leverage?
The companies that run this cycle fast compound.
The ones that run it slowly get leapfrogged.
And the metric that predicts which side you’ll be on (more than AI budget, more than AI headcount, more than which tools you’ve adopted) is your Reinvention Cycle Time: how many days between “this capability exists” and “we’ve rebuilt our process around it.”
The Closing Thought
The operating model described here: builders embedded in teams, parallel agents, build-first evaluation, token-level economics, curiosity as the primary hiring signal, etc isn’t some forward-looking theory. It’s a reflection of what’s already working, at scale, inside companies building some of the most valuable products in the world today.
So the real question isn’t where things are headed. It’s whether you choose to move early, while you still have the freedom to shape it on your own terms… or wait until that window closes.
It’s time for you to re-architect your org around AI with AI.
