A company-wide suspensions platform - cross-org, compliance-sensitive, and touching dozens of service teams - we shipped in a matter of months. A core system woven through every service at the company - we deprecated in two months. An agent that went rogue, deleted a company’s production database, and covered it up.¹ These are not unrelated stories. The first two are wide-scope, cross-functional initiatives which were scoped at a year but were completed in a matter of months, the first using a fleet of AI agents working in parallel with human review, and the second using AI agents across every step of the process, from authoring to review to coordination. On the other hand, the third story is one of many coming from industry of what can go wrong when using AI agents. Coding got cheaper, but deciding what to prioritize and verifying it was built correctly became all the more important.

I have seen four aspects evolve significantly over the past year, more than across the decade before it, while leading engineering teams and building distributed systems at scale: the constraints on engineers, the design of teams, the mechanisms those teams run on, and the job of the person leading them. What follows is what changed, and how the teams adapting best are responding.

• The constraints on engineers changed. With generation cheap, the constraints became judgment, verification, and alignment.
• Team design is evolving. Senior-heavy, agent-backed pods working towards end-to-end outcomes.
• Team mechanisms are evolving. Increasing autonomy for agents, guardrails as code, agent-to-agent review, data infrastructure and eng tooling even more important, monitoring as the safety net, measurement focused on outcomes.
• The EM role is evolving. Context, selective depth, systems, traceability, influence without authority are even more important.

1. Constraints on Engineers

What constrains the upper bound of velocity, quality, and success of a software team has changed significantly:

• Generation is Cheap, Judgment is Not - Anthropic put the share of code in its own codebase written by Claude at between 70% and 90%.[^2] Meanwhile, tokenmaxxing became the 2025-2026 version of counting lines of code. Meta and Microsoft have had internal dashboards ranking the top employees by token consumption, while Salesforce set minimum monthly spend targets.[^3] The counter-move is already visible, with Shopify retiring its own leaderboard for circuit breakers that cut off access on anomalous daily spend, while Stripe added guardrails on runaway agent spend. Volume is a poor proxy for impact; as velocity rises, teams have to gauge success by the outcome, the impact of the changes, rather than the volume of them. Judgements on what to build and if it was built correctly are increasingly important.
• Verification Became the Critical Path - one study of roughly 4,000 teams found median time in PR review rose 441% as teams moved from their lowest to their highest periods of AI adoption.[^4] The queue moved from “write it” to “verify it.” Teams furthest along report it shifting again, from review to aligning on direction, with requirements and design as the gating input.
• The Demo-to-Production Gap - prototyping got very fast, though a working prototype built in an afternoon still needs verification, monitoring, and guardrails before it ships, and that gap is an area expectations can break down.
• The Team-Size Constraint Softened - the “two-pizza rule” was a communication-overhead guideline for humans. When most of the workforce on a task is agents, the constraint becomes supervision and verification capacity instead.

2. Team Design

A 2022 team was typically eight to twelve engineers with one EM coordinating. The 2026 equivalent is a small, senior, agent-driven pod with directional alignment and verification as its critical path. Two patterns are showing up most often as teams adapt.

The Small AI-Driven Pod

The base unit is a handful of senior+ engineers supervising a large set of specialized agents, working side-by-side with a product manager and designer. It is one pod led by a hands-on tech lead / manager, and it suits work that is ambiguous and judgment-dense. AI-native startups are demonstrating this most clearly, generating between $2M and $4M in revenue per employee against roughly $300K at the average public SaaS company.² For example, one OpenAI team that started as three engineers driving Codex built roughly a million lines of code across about 1,500 merged PRs in five months.³

The Multi-Pod Team

This is a team of ten to fifteen or more engineers, majority senior and staff, split into pods with a TL each, under one EM operating a layer higher up. It suits maturing domains where platform guardrails are strong enough that the EM need not be in every change decision, and it requires strong TLs. For example, Meta stood up an applied AI org under Reality Labs designed for up to 50 ICs per manager,⁴ and Google reduced its population of managers with fewer than three direct reports by 35% year over year, largely by moving them into IC roles.⁵ Across industries, the average manager now has 12.1 direct reports, up from 8.2 in 2013.⁶

Three things shift alongside team structure:

• Pods organize around end-to-end outcomes given that handoffs become a larger bottleneck when the work itself is near-instant.
• New roles appear at the seams, including agent reliability, context architecture, and evaluation workflows.
• Seniority rises, as agents absorb the well-specified execution work that used to be completed by mid-level or early-career engineers.

All of this runs on supervision capacity, with many organizations increasing automated decisioning and setting guardrails through experimentation and then finding the gaps through incidents. The production database story we started with is a perfect example. In one report, bugs per developer rose 54% and incidents per PR rose 243%, even as task throughput per developer rose 34%.⁷ Output went up and defects went up with it. Below we discuss mechanisms to tackle this.

There is also an open question the industry has yet to resolve. As teams have become senior-heavy by design and entry-level hiring has fallen, down more than 50% at large tech companies and more than 30% at startups compared with 2019,⁸ how does the industry build a pipeline of early-career engineers into the next generation of senior and staff engineers. Time will tell.

3. Team Mechanisms

With the velocity of change produced by fleets of agents, everything a team used to tolerate becomes a greater tax. A flaky test a human quietly retried is now a fleet burning tokens on a false signal. A ten-minute CI run is the rate limiter on a hundred parallel changes. Undocumented or incorrect data is why an agent confidently ships a wrong migration. A bad pattern committed once becomes systemic tech debt, as agents replicate what they find in the repo.

Platform, data infrastructure, and engineering tooling therefore matter more than ever. Every 10 seconds of feedback delay is multiplied by fleet size, so deterministic CI, hermetic builds, and ephemeral per-agent sandboxes are key. Agents are likewise only as good as what they can read and check themselves against: logs, metrics, traces, realistic test data, and the eval suites that decide whether a change is safe. Organizations are therefore even more incentivized to fund the platform, data, and engineering tooling teams that maximize the throughput and correctness of product engineering.

The remaining mechanisms cluster around the same idea:

• Increasing Autonomy - agents earn scope the way new hires do, supervised first, then trusted on bounded work, then trusted broadly.
• Systems Over Practices - anything depending on a human remembering fails at volume, and anything depending on a fleet of agents remembering fails faster - document in code.
• Iteratively Evolve the Harness - when an agent hits an obstacle, ask what capability is missing and build it, whether that is observability access, browser control to validate its own UI fixes, or ephemeral environments. The repo becomes the system of record, often a short AGENTS.md file pointing into structured docs.
• Scaling Verification - multiple agents open the PR, review changes, and iterate, with human review as the final step and whatever is not caught by agents folded back into future guidance. Some teams have dropped human review entirely in favor of monitoring and automated rollbacks, which holds when rollback is easy and failures are less critical and easily reversible.
• Monitoring as the Safety Net - monitoring is more important than ever, and instrumentation has to be part of the definition of done.
• Outcome-Level Measurement - impact upon business metrics, cycle time to production, and escaped defects rather than lines, PR counts, or tokens, which agents inflate.

4. The Engineering Manager Role

The role of engineering leadership has evolved alongside the team, and four parts of the role have grown in importance.

• Context and Prioritization - when building is cheap, choosing correctly is the scarce skill, and that runs on context: what the business needs, what the system can absorb, recognizing patterns, and understanding what the team already tried. The EM holds that context and makes challenging tradeoff decisions while providing clear reasoning and remaining open to change as the context changes.
• Selective Depth - the skill now is judgment about where to go deep, such as core flows, strategic bets, architectural one-way doors, and people decisions, and delegating other areas with verification attached.
• Accountability and Traceability - auditing which code was AI-assisted, which specs were validated, and where risk is accumulating, so that course-correction can happen iteratively with minimized blast radius rather than in a large impact incident review.
• Influence Without Authority - flatter orgs and faster velocity mean the larger initiatives that matter often happen between the boxes on the org chart, and teams may need to reorganize quickly to adjust. Influencing other teams so you can quickly and collaboratively align on priorities and roadmaps is key.

Other aspects remain important as always. People still need someone who has been there, someone they trust, and a leader with the broader context to align priorities and coordinate the many moving pieces.

Continuing to Evolve

We are at a time of momentous change, not only in software engineering, but more broadly across industries as AI rapidly advances. Engineering velocity is not accelerating simply because engineers are coding faster, and production incidents are not growing because a model got dumber. The constraints have shifted, and the team, the mechanisms, and the job are evolving with them.

The constraints on engineers, org design, team mechanisms, and the engineering manager role will continue to evolve over the coming year and beyond, and balancing velocity with correctness and directional alignment will remain key. Understanding the changes is what lets teams make the most of a fast-changing landscape. It is an exciting time to be a builder, with more powerful tools at our fingertips than ever before.

References

1. Fast Company, July 2025, “Replit CEO: What really happened when AI agent wiped Jason Lemkin’s database (exclusive)” - fastcompany.com ↩

2. Paul Baier at Forbes, March 2026, “AI-Native Firms Lead In Revenue Per Employee” - forbes.com ↩

3. Ryan Lopopolo at OpenAI, February 2026, “Harness engineering: leveraging Codex in an agent-first world” - openai.com ↩

4. WSJ, March 2026, “Meta to Create New Applied AI Engineering Organization” - wsj.com ↩

5. CNBC, August 2025, “Google has eliminated 35% of managers overseeing small teams in past year, exec says” - cnbc.com ↩

6. Gallup, January 2026, “Span of Control: What Is the Optimal Team Size for Managers?” - gallup.com ↩

7. Faros AI, April 2026, “Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash” - faros.ai ↩

8. SignalFire, May 2025, “State of Tech Talent Report 2025” - signalfire.com ↩