This article is the English translation of The Builders Organization, originally published in Italian 🇮🇹 on my personal website.
For fifteen years I worked inside product organizations, taking on every possible shape: developer, designer, product manager, CTO, CPTO. And for fifteen years all of those organizations rested on the same premise: building software is hard, slow, and expensive.
Almost everything else follows from that premise. The Product Manager decides what to build, the Designer defines how it should work, the Engineer turns it into software, and so on. The model worked for decades because every step required specialized skills and, above all, because production was the bottleneck of the whole system.
AI is eroding that premise. Not because PMs, Designers, and Developers are becoming useless, but because the cost of turning an intention into something that works is collapsing: a prototype that used to take weeks now gets built in hours; a designer can produce code; a PM can query the data, put together a demo, and test a hypothesis without ever opening a roadmap.
I live this every day, building digital products while personally driving design, product, growth, and distribution, with AI at my side on almost everything. And I live it every day training PMs and engineers inside multinational companies.
Which opens up an organizational question far more interesting than the usual one about which professions will disappear:
How should we organize a team when building is no longer the main bottleneck?
My hypothesis is that the boundaries between Product, Design, and Engineering will become progressively more permeable, and that three archetypes will emerge in their place:
Builders: high-agency individual contributors accountable for an outcome.
Guardians: specialists who turn their expertise into systems, standards, and guardrails usable by the whole organization (humans and AI agents included).
Orchestrators: managers and leaders who distribute context, direction, and decision-making capacity instead of distributing tasks.
And it’s no longer just my hypothesis. A working paper from Harvard Business School and INSEAD (Kim & Koning, AI-Native Firms, 2026) measured AI-native startups against traditional ones: they turn out to be roughly 25% smaller under equal conditions, but with 13% more engineers, flatter hierarchies, and about 15% fewer managers. These are early data points, not definitive conclusions; but the statistical signature is exactly this: fewer people, more capability per head, fewer layers.
The result is not an organization without specialists. It’s an organization in which specialization changes position.
The bottleneck is moving
Every organization is designed around its own constraints. When writing software is expensive, it’s rational to protect engineers’ time with a long decision pipeline: someone gathers requirements, someone studies users, someone sets priorities, someone designs the interface, someone writes a spec detailed enough not to waste development time.
But what happens when production keeps getting cheaper? The bottleneck moves. The question is no longer “can we build it?”; it becomes “should we build it?” and, right after that, “did we build the right thing?”.
The scarce capability stops being the ability to produce software. What becomes scarce is understanding the problem, judgment, taste, the ability to tell signal from noise, accountability for the outcome. In one sentence:
When execution is a commodity, judgment is the real competitive advantage.
Google Cloud’s DORA report on AI-assisted development (State of AI-assisted Software Development, 2025, nearly 5,000 professionals) reaches the same conclusion from another direction: AI adoption among developers sits at 90%, but AI behaves as an amplifier.
AI amplifies the strengths of healthy organizations and the dysfunctions of unhealthy ones: the returns, as a consequence, come not from the tools but from the quality of internal platforms, the clarity of workflows, and the alignment of teams.
This is the starting point of the entire framework.
From specialists in a pipeline to people who own outcomes
The traditional team divides work by discipline; ownership and knowledge are continuously handed off: the PM talks to the user and describes the problem to the Designer; the Designer creates a solution and describes it to the Engineer; the Engineer implements; the PM comes back at the end to check. Every handoff introduces context loss, interpretation, waiting, coordination, meetings.
When production is expensive, this overhead is acceptable. When production becomes extremely fast, coordination risks costing more than production itself.
The alternative is to move ownership toward the individual: the same person moves through discover, define, prototype, build, ship, measure, learn. It doesn’t mean they work alone; it means they don’t continuously delegate responsibility for the problem.
Marty Cagan has been describing this distinction for years: feature teams receive solutions and are measured on output, product teams receive problems and are measured on outcome. The Builder Organization model takes that logic all the way, from the team as the unit to the person as the unit.
The Builder
A Builder is not simply a developer using Claude, and not a PM who knows how to code. They are, first of all, a person who owns an outcome: they receive a direction, a problem, some context, a few constraints, and a definition of success, and they have enough horizontal capability to decide autonomously how to proceed.
For me this is a very concrete figure, because it’s what I do every day: in the same week I analyze a funnel, talk to users, query the database, create a prototype, tweak its interaction, ship the experiment, and decide whether to continue. AI helps me execute almost all of it; my skills serve a different purpose, which is understanding what it’s doing and where it must not put its hands. A Builder with good aesthetic taste and technical fundamentals knows, for example, that the AI can’t touch the database in a certain way. They are horizontal on the product, but able to go deep where it matters.
The resulting profile is not the old T-shape with one deep spike and everything else at zero. It’s a profile with a strong specialist spike and a much higher horizontal baseline: an Engineering-heavy Builder remains far deeper technically, but can’t have Product at zero; they need to know discovery, prioritization, metrics, experimentation. The point is not to make everyone the same; it’s to drastically raise the baseline of adjacent skills.
That this baseline is already rising is suggested by data from the Anthropic Economic Index: it observes that in Claude usage patterns, augmentation (52%) has overtaken automation (45%): a hint, not proof, that AI is amplifying people more than replacing them.
The fundamental capability, though, is not technical: it’s agency. Moving from “what should I do?” to “what’s the outcome we need, and what can I do to get us closer?”. Before, a high-agency person was still limited by their own technical skills; today they can delegate part of production to an AI system. A passive person with AI produces tasks faster. A high-agency person with AI crosses entire disciplines.
AI amplifies agency more than it amplifies technical skill.
The Guardians: an authority for every vertical
The second archetype is the one most at risk of being misunderstood, so let me clarify two things right away. Guardians are more than one, and one exists (or should exist) for every critical vertical in the organization: design, engineering, data, AI, privacy, brand, and so on. Wherever there is deep expertise whose rules must apply to everyone, a Guardian is needed.
The definition is this: the Guardian is the authority of a vertical who codifies their expertise into executable rules, usable by people and by AI agents alike. They don’t take part in every project and don’t approve every single decision; they build the system that makes it hard to do badly in their vertical.
I didn’t deduce the need for this figure from theory: I watched it emerge from a practical problem, and design just happens to be the vertical where I noticed it first. AI in design is extremely powerful: it generates templates, layouts, entire design systems in timeframes that two years ago sounded like science fiction. But after a while you notice: the outputs all start to look alike. If ten Builders generate interfaces autonomously, with no one guarding the identity, the brand dilutes into a statistical average. Hence the Design Guardian: they own the design system, bring it into the shared workspace where people and agents work, and review the Builders’ outputs so that brand, taste, and user experience stay coherent.
The exact same pattern, though, repeats across every other vertical. In practice, today, codifying expertise means shared skills and shared MCPs, and each Guardian writes the ones for their own territory:
the Design Guardian defines the design system, the skill that governs micro-copy, the skill that structures onboarding flows;
the Engineering Guardian defines the stack, development rules and limits, which MCPs to connect and how to use them, and what the AI must not touch (the database in a certain way, for example);
the Privacy Guardian defines the skill that teaches the AI to structure data in a GDPR-compliant way;
the Data Guardian watches over metric definitions, data quality and semantics, so that two teams don’t call two different things “activation”;
the AI Guardian watches over model selection, evals, safety, and observability of the agents themselves;
the Brand Guardian watches over voice, positioning, and message consistency.
And with the rules come tiered permissions: within each vertical, one level of authority gets to make requests on staging, a higher level reaches production. Expertise stops living only in the specialist’s head or in code reviews; it becomes infrastructure.
Anyone who knows Team Topologies by Skelton and Pais will recognize the idea of platform as a product: platform teams that build self-service paved roads to reduce the cognitive load of other teams. It’s the same approach Bending Spoons applies.
The difference, and this is the part I consider genuinely new, is that in the Builders Organization the platform is addressed to AI agents too, not just to humans. The design system stops being a library for designers and becomes the interface through which the organization codifies its own taste: machine-readable documentation, components with clear semantics, tokens, examples, anti-patterns, skills, MCPs.
How many Guardians do you need, and where do they sit? It depends on the scale and shape of the organization. A Guardian can be horizontal, a single authority writing the rules of their vertical for all the Builders across all teams; or per business vertical, when an area is structurally different and its rules need to stay separate. And they don’t even have to be a dedicated person: a Guardian can be a Builder who, on their own territory of expertise, also wears that hat.
The Guardian turns individual expertise into organizational leverage: from specialists as gates to specialists as leverage.
The Orchestrator: context is the new coordination
In the reality I’m building, the Orchestrator is me. I decide what to build, how to prioritize, and under which constraints, based on all the information I have available: market, customers, numbers, relationships. I get AI’s help at every stage, but I don’t hand it the steering wheel of strategy. That’s the point that defines this role: the Orchestrator doesn’t distribute tasks, they distribute context.
Traditional companies invest enormously in coordination: meetings, roadmaps, planning, syncs, tickets, status updates. But a large part of that coordination exists because people hold different fragments of the context. If vision, strategy, current bets, constraints, priorities, evidence, and success metrics become clear, shared, and queryable (by people and by agents), part of the coordination can simply be eliminated.
AI-native organizations replace coordination with context, wherever possible.
The manager, in this model, loses part of the traditional role: they stop collecting updates, coordinating handoffs, and translating between functions, and start designing the system in which autonomous people make coherent decisions. They shouldn’t be promoted for coordinating more people, but for building environments where more people work well without them. The one question I would use to evaluate an AI-native manager is this: how well does your team work when you’re not in the room?
Here too, the early data points in the same direction: in the AI-native firms measured by Kim & Koning, hierarchies are flatter, with roughly 15% fewer managers at equal size. Not because management disappears, but because it changes nature: from routing tasks to designing context.
Hats, not people
Here I have to be honest, because this is where my direct experience refines the framework.
In the reality I’m building, today, I wear almost all three archetypes myself: I orchestrate the strategy, I build as a Builder, and I act as my own Guardian by defining the rules my agents must respect. If the framework required three distinct people by force, my own experience would contradict it.
But the point is another one: Builder, Guardian, and Orchestrator are hats, not people. At small scale one person wears all three; as you grow, they separate. “I do everything myself” is not a thesis: it’s a phase, tied to scale. And I’m already experimenting with how to delegate without creating people who merely duplicate my skills: the value is not in cloning the generalist, it’s in growing real ownership over real outcomes.
The evolution I expect, and that I’m starting to build, is an organization with several vertical Orchestrators; within each vertical, small nuclei of people driving the project forward, guided by the Orchestrator and supported by the Guardians. Some Guardians will be Builders themselves; others will cover the whole company horizontally. An AI-native team around an outcome like “increase activation” might be made of three Builders (one engineering-heavy, one design-heavy, one growth-heavy) with shared access to the design, engineering, AI, and data Guardians. The team isn’t assembled based on the disciplines required: it’s assembled based on the problem.
The risk of speed
The model has an obvious problem, and it’s worth looking at it squarely: AI reduces the cost of building, but it doesn’t reduce the cost of building the wrong thing. If anything, it accelerates it. Before, a terrible idea could die during requirements, design, planning, and estimation; the system was slow, but its slowness accidentally created a filter. Tomorrow the path is: bad idea, AI, production.
Abundance of output is not abundance of results. And it’s exactly why Orchestrators and Guardians are not a luxury, and why the goal is not to increase velocity but to increase validated learning per unit of time.
For the same reason, measuring story points and shipped features in an organization where output has grown tenfold only incentivizes producing more software: metrics need to move toward completed experiments, validated learnings, customer outcomes, and a new question for the career ladder: how big and ambiguous a problem can you own autonomously?
Alongside this dimension a second one is needed, that of leverage: how much you manage to increase the capabilities of others. That’s where a Principal Engineer can choose to become a Guardian instead of a manager, with an impact measured on the quality of the entire organization.
The fundamental principle
The previous paradigm asked: how do we coordinate different specialists to build software? The AI-native paradigm asks: how do we create people capable and informed enough to own an outcome autonomously, and what systems do we need to build so they can do it without sacrificing quality, safety, and coherence?
From these two questions the three archetypes emerge naturally, and the synthesis I’d like you to keep in mind is this:
Builders own outcomes. Guardians own standards. Orchestrators own context. Leaders own direction.
The result is not an organization where everyone does everything, nor an organization without specialists. It’s an organization where many more people can do much more autonomously, and where specialization moves from the production flow to the infrastructure that makes it possible.
And this is probably the real organizational consequence of AI: not just software produced faster, but a radical expansion of the surface of responsibility a single person can own. I’m crossing it firsthand, one hat at a time.