Three ways engineering organizations are restructuring around agentic coding. Two of them fail.
On July 7, 2026, Gartner published a press release with two predictions in it. The first got quoted everywhere: by 2029, 60% of organizations will run small software engineering teams at scale, up from 15% today, with those teams typically holding four or five people and sometimes as few as two or three.
The second prediction appeared further down the same page and I have seen almost nobody cite it. By 2028, organizations that rely on AI to cut junior roles will hollow out their own engineering talent pipeline. Gartner’s analyst was direct about the mechanism: slowing junior hiring inhibits knowledge transfer, restricts the internal pipeline, and leaves you recruiting only in the most expensive and competitive part of the market.
Those two predictions are in tension, and the tension is the actual subject of engineering org design right now. Teams get smaller. The people in them get more senior. And the supply of people capable of operating in a small senior team is being cut off at the source by the same technology that made the small senior team possible.
I wrote recently that the binding constraint in software delivery moved from writing code to verifying it. This piece is the structural consequence of that. If verification is scarce, then the org chart is a claim about how you allocate scarce human judgment, and most org charts currently in production were designed to allocate something else.
What an org chart is actually for
Every engineering org structure is an answer to a question about scarcity.
The functional structure of the 1990s answered a question about specialized skill. The cross-functional squad model answered a question about coordination cost. The platform team model answered a question about infrastructure complexity crushing product teams. In each case the structure was downstream of whatever was expensive at the time.
For thirty years the expensive thing was engineering bandwidth. Planning cycles, team sizes, hiring plans, and management layers were all built to allocate a scarce supply of people who could write correct code. Fiona Fung, who runs engineering for Claude Code, put the point plainly when describing why her team’s processes stopped working: every process the industry built around software planning and shipping, first waterfall and then agile, was built around the cost of engineering bandwidth.
That cost dropped. What did not drop is the cost of deciding whether the output is right, whether it fits the architecture, whether it is safe to ship, and whether anyone will understand it in eighteen months.
So the design question becomes: how do you structure an organization so that scarce judgment lands where it changes outcomes, and so that everything not requiring judgment stops consuming it?
Three answers are being tried at scale. I think two of them are wrong, and it is worth being specific about why, because the failure modes are not obvious from the org chart itself.
Shape one: the AI team
The most common structure I see, and the one I would advise against most strongly, is a dedicated AI group. It goes by several names. AI Center of Excellence. AI Innovation Lab. AI Enablement. Sometimes it reports to the CTO, sometimes to a CIO or Chief Data Officer, which is worse.
The logic is reasonable on its face. AI expertise is scarce, so consolidate it. Governance is immature, so centralize it. Everyone is doing this differently, so standardize it.
Here is why it fails.
The group with the deepest agent capability ends up being the group with the least product context. They build demonstrations rather than features, because they do not own a customer outcome. Product teams file tickets and wait, so the central team becomes a queue rather than a multiplier. Over time, product teams route around the queue by quietly developing their own capability under a different job title, and you end up with the decentralized model anyway, except now you are also paying for the central team.
Gartner’s own research found that most AI Centers of Excellence fail within eighteen months of launch. The pattern is consistent enough that the industry has a name for the artifact it produces, which is a slide with the words “POC graveyard” on it.
There is a real nuance here worth preserving. Centralization works well for exactly one thing: governance. Policy, risk, model approval, data classification, audit. McKinsey’s work finds the same split, with risk and compliance handled centrally while deployment and adoption work better federated. So the correct read is not that central functions are bad. It is that a central function should own the rules and the paved road, and should not own delivery.
The diagnostic question: if your AI group disappeared tomorrow, would any customer notice within a week? If not, it is a lab, and labs do not survive budget cycles.
Shape two: licenses and hope
The opposite failure is more common in startups and it is harder to see because it looks like trust.
Everyone gets a license. Adoption is encouraged. Teams are trusted to figure out their own workflows. There is no central owner because central owners slow things down, and besides, the whole point is that engineers can now move without asking permission.
What actually happens is that every team solves the same problems independently and none of them solve them well. Six teams write six versions of the same instruction file. Nobody owns the skills catalog, so verification checks live in individual laptops as habits rather than in the repository as artifacts. There is no telemetry, so leadership’s only instrument is sentiment, and sentiment in this domain is measurably unreliable. Governance trails adoption by roughly three to one across the industry, and in this shape it trails by considerably more, because no one is accountable for it.
Garner Health’s platform engineering manager said the useful version of this out loud when describing their rollout to 550 employees. If everyone builds their own workflows and there is no telemetry, that is dangerous. Their confidence to move fast came from having standardized workflows and visibility, not from the absence of structure.
The diagnostic question: can you name, today, the file that defines how agents are supposed to behave in your most important repository, and the person who owns it? In this shape, there is no answer.
Shape three: small pods on a thick platform
The structure I would build, and the one I see working in the organizations that are actually converting AI investment into delivery, has three parts. It is not a hierarchy. It is a load-bearing arrangement.
Outcome pods
Four to six people, owning a customer-visible outcome end to end, with the product manager inside the pod rather than adjacent to it. Gartner’s tiny team composition lands in the same place: a product manager, a designer, and at least one AI-native engineer, with traditional role boundaries collapsing inside the team.
Two rules make pods work rather than merely small.
First, one accountable reviewer per code surface, assigned by area and written into CODEOWNERS. When agents generate the majority of a change, the question of who owns quality gets fuzzy fast, and fuzziness at high volume is how defects reach production. Exactly one name per surface.
Second, pods get wide latitude on how they work and no latitude on the gates. Anthropic’s Claude Code team runs this way, with a short list of non-negotiable principles and genuine autonomy for each pod inside them on rituals, triage, and which workflows get automated first. Standardize the boundary conditions, federate everything inside.
The platform and harness group
This is the part most organizations underfund, and the underfunding is the single best predictor of whether the rest works.
This group owns the verification layer, CI and environments, the agent runtime and permissions model, the skills and context catalog, the telemetry, and the paved road. DORA’s research is direct that a high-quality internal platform amplifies AI’s effect on organizational performance. The platform is not overhead in this model. It is the mechanism by which one engineer’s judgment gets applied to a hundred changes instead of one.
Now the number I will defend. The established platform engineering ratio is one platform engineer per eight to twelve product engineers, which puts the function at roughly five to ten percent of an engineering organization. My contention is that an AI-native organization should run closer to fifteen to twenty percent.
I want to be honest that this is an extrapolation rather than a survey finding. Nobody has published good data on this yet. The reasoning is that the platform group’s charter has grown by several surfaces that did not exist two years ago. Verification loops as versioned artifacts. Agent execution environments and permission classifiers. The context and skills catalog. AI-specific telemetry covering utilization, impact, and cost. Each of those is a product with users, a roadmap, and a decay rate. You cannot add four owned surfaces to a function and keep its headcount ratio constant.
If that number feels high, consider what it replaces. It replaces review capacity you were about to hire, and review capacity scales linearly while platform capacity compounds.
Federated specialists
Security embedded in pods, with policy owned centrally. This is the hub and spoke split that works: the rules and the tool guards live in one place, the judgment lives next to the code.
Evaluation as a discipline. This is the genuinely new role, and the market has already named it. Evaluation engineers design and operate the systems that decide whether probabilistic behavior is good enough to ship, turning intent like “make the answers more helpful” into measurable targets and release gates. Applied AI companies now hire these people among their first ten technical hires. Traditional QA does not disappear in an AI-native org. It moves left, gets harder, and gets more expensive per head, because writing a grader is a harder skill than writing a test.
Domain experts whose knowledge becomes the specification. In a regulated or high-consequence domain, the person who knows what correct means is now a source of executable constraints rather than a reviewer of finished work.
The roles that changed underneath the boxes
An org chart that looks right but leaves job descriptions untouched will not work. Four roles changed materially.
Staff and principal engineers. They used to write the hardest code. Now they write the specification and the checks that everyone else’s agents run against. The weight moved from the artifact to the constraint on the artifact. A staff engineer who spends the week producing more output than anyone else is a misallocation of your most expensive judgment. The measure is whether the rules they wrote prevented a class of defect across the whole org, not whether they shipped a hard feature.
Engineering managers. The engineer and manager roles are converging from both directions. The Pragmatic Engineer’s 2026 survey of more than 900 engineers and leaders found engineers orchestrating and context-switching more, managers more technically hands-on than in a decade, and the two roles becoming similar. That convergence needs rules or it produces confusion. If a manager ships code, it goes through the same review path as everyone else’s and stays bounded to prototypes, internal tooling, and spikes rather than critical path. Otherwise you have an engineer with a reporting-line problem.
I would also argue span of control should shrink rather than grow. The manager’s job is now allocating scarce human judgment across a larger volume of change, and that is harder than allocating tickets. Eight reports was reasonable when the work was legible. Five or six is more realistic when it is not.
Product managers. They prototype now. This is real and it is good, and it changes what you hire for. The PM who can put a working thing in front of a user on Tuesday is worth considerably more than the PM who writes a better requirements document.
The role most organizations are missing. For any system that more than one team touches, someone must own end-to-end evaluation. I read a case recently that captures the failure precisely: three teams each improved their own part of an AI workflow, one the model, one the prompts and retrieval, one the business rules. Every change was good. Every team hit its goals. Overall accuracy dropped, and nobody caught it for a month, because everyone owned a component and no one owned the system. Name that owner explicitly, with shared metrics across the contributing teams.
The junior problem, which is your problem
This is the part I would want a CTO to sit with, because it is a decision with a five-year lag and no obvious cost today.
The data is not ambiguous. Stanford’s Digital Economy Lab, working with ADP payroll records rather than surveys, found employment for software developers aged 22 to 25 down roughly 20% from its late 2022 peak, while workers over 30 in the same high-exposure occupations saw employment grow. Entry-level tech hiring has fallen sharply and consistently since. Forrester projects a 20% decline in computer science enrollment as students respond to the signal. Gartner expects the hollowing-out to be visible by 2028.
The mechanism is simple. AI is best at exactly the codified, well-bounded work that used to be a junior engineer’s training ground. Remove the first rung and the ladder does not get shorter, it gets unreachable.
There is a second-order effect that shows up in no productivity dashboard. When there are no juniors, mentorship disappears, and mentorship is how senior engineers sharpen their own thinking. Explaining an architectural decision forces you to actually have one.
And there is a third effect that lands on the people you already have. Research from January 2026 found developers learning a new library with AI assistance completed the tasks and understood the material measurably worse afterward. Comprehension decays quietly. A system nobody understands cannot be evolved safely, and you find out on the day you need someone to reason about a novel failure from first principles.
My position is that you keep hiring juniors, and you change what the job is.
The old junior role was execution: take a well-defined ticket, produce working code, learn by doing. That role is genuinely gone. The replacement is not a smaller version of it. A junior engineer in an AI-native org should arrive at what used to be mid-level scope and spend their apprenticeship on verification and comprehension rather than production. Reviewing agent output against architectural intent. Writing evaluations. Debugging incidents without assistance, deliberately, on a schedule. Explaining systems back to the team.
Concretely, I would put four things in place. Require written rationale in pull requests rather than a description of the change, because the rationale is where understanding is either present or absent. Rotate people through unassisted incident debugging. Make architecture review a human forum where agent output is not admissible as the primary argument. Make the ability to explain the system a promotion criterion at every level.
IBM has gone the other direction from most of the industry and announced it is tripling US entry-level hiring, on the argument that junior engineers shift into judgment and customer-facing work rather than routine coding. I do not know whether that specific bet pays off. I am confident the opposite bet has a bill attached, and that the bill arrives after the person who avoided the cost has moved on.
What changes with scale
The shape holds. The staffing does not.
Under 20 engineers. No platform team. One or two senior engineers own the paved road as an explicit part of their charter, with time protected for it. Buy rather than build for everything you can. The failure mode at this size is building an internal platform you cannot maintain. The thing you must not skip is the context layer: instruction files, a small skills catalog, and telemetry. That is a week of work and it compounds.
20 to 60 engineers. This is where the platform function becomes real, typically at three to six people, and where most organizations hit the threshold naturally. The signals are concrete: engineers losing more than an hour a day to environment and deployment friction, more than one incident a week traced to configuration, new service setup taking more than a day. Pods stabilize at four to six. One evaluation owner, likely part-time within another role. Security policy written down and owned by a named person even if that person has another job.
60 to 200 engineers. The platform group subdivides: delivery infrastructure, agent and verification tooling, developer experience. Evaluation becomes a staffed discipline rather than a hat. Security is embedded in pods with central policy. This is the scale at which the fifteen to twenty percent ratio needs an explicit defense in the budget cycle, because it will look expensive next to a proposal to hire six more product engineers instead. It is not expensive. It is the thing that makes the six product engineers convert.
Four things I would not do
Do not create an AI team. Capability belongs where product context is. A central function owns rules and roads.
Do not let the platform group become a ticket queue. The test is whether product engineers can get what they need without a human in the loop. If the answer is no, you built a service desk with a better name.
Do not reorganize before you instrument. Every argument in this piece depends on measurement you probably do not have yet. Review wait time by authorship, change failure rate, deployment rework, agent-authored share of merged code. Reorganizing on sentiment is how you spend political capital moving boxes and learn nothing.
Do not treat the chart as durable. An org chart is a claim about how work gets done, and every quarter it goes unedited while the work changes underneath, the claim gets less true. Revisit it quarterly. A role definition written in January describes a different job by June right now.
There is a version of this transition where you get smaller, faster, more senior, and structurally healthier. There is another version where you get smaller, faster, more senior, and quietly consume the last decade of accumulated understanding without replacing any of it. Both look identical on a delivery dashboard for about two years.
So here is the question I would put to any engineering leader reading this.
Name the person accountable for the quality of the code your agents merged last week. Then name the person who will still understand that code in three years.
If the first name takes more than five seconds, your structure has not caught up to your tooling. If there is no second name, your structure is working and your organization is still failing.
Sources
- Gartner. Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029. Press release, July 7, 2026, including the 2028 talent pipeline prediction and tiny team composition guidance.
- Fiona Fung, Anthropic. Running an AI-native engineering org. Code w/ Claude SF 2026, published June 3, 2026.
- Anthropic. Running auto mode in production. August 7, 2026, including the Garner Health, Gusto, and Nuro accounts.
- The Pragmatic Engineer. The impact of AI on software engineers in 2026. Survey of 900+ engineers and engineering leaders.
- Stanford Digital Economy Lab, using ADP payroll data, on employment decline among developers aged 22 to 25.
- Forrester. 2026 Predictions on computer science enrollment.
- Shen, J. H. and Tamkin, A. How AI Impacts Skill Formation. arXiv, January 2026.
- DORA / Google Cloud. State of AI-assisted Software Development 2025 and The ROI of AI-assisted Software Development 2026, on platform quality as an amplifier.
- Platform engineering ratio benchmarks drawn from CNCF platform surveys, the Platform Engineering Community State of Platform Engineering Vol. 4, and Gartner peer community discussion.
- McKinsey, on centralized governance versus federated deployment in AI operating models.
- Nick Talwar. When Engineers Manage Agents and Managers Engineer. July 2026, for the role convergence framing and the shared-system ownership failure.
- Reporting on entry-level engineering hiring trends through August 2026, including IBM’s stated expansion of US entry-level hiring.