AI Is Breaking and Remaking Software Teams

1 March 2026 8 min read development · ai

Execution Is Cheap, Judgment Is Scarce: The Real Shift in Software Engineering

The Fracture Point

Something fundamental is breaking in software engineering: not the tools, not the languages, but the organizational assumptions that have governed how teams build software for over two decades.

Scrum ceremonies, story points, sprint planning, and the careful separation of Product Owner, Developer, Tester, and Scrum Master were all designed for a world where writing code was the primary bottleneck.

AI has made code cheap. And in doing so, it has exposed everything else.

This shift is often mischaracterized as a simple productivity boost. Headlines focus on fivefold gains, smaller teams shipping faster, or AI “replacing” developers. The reality is messier. Some teams accelerate; others drown in pull requests, review backlogs, and systems that no one understands.

The Immutable Value of Fundamentals

Counterintuitively, the AI era does not erase the need for engineering rigor; it rewards it. AI works like an amplifier: it magnifies whatever it ‘sees’.

Test-driven development, clean architecture, well-defined interfaces, and comprehensive documentation make AI agents far more effective and their output more reliable. Teams with strong discipline see compounding returns from AI, while teams with poor discipline drift into chaos.

Stripe’s internal “minions” system, for example, shows that agent performance depends less on raw model intelligence (which still matters) than on reproducible development environments, fast deterministic tests, and strict conventions embedded into tooling and workflows. Where context is clean and constraints are explicit, agents perform reliably. Where they are not, failure modes multiply.

Amdahl’s Law and the Productivity Paradox

Making coding much faster yields only a marginal improvement in overall delivery speed. If writing code historically constituted about 20% of the delivery cycle, optimizing it to near-zero time quickly exposes the true bottlenecks. The friction now concentrates at the human-gated stages: requirements gathering, code review, rigorous testing, security audits, and deployment.

The result is a familiar but intensified pathology. Senior engineers become review bottlenecks, spending their time debugging enormous AI-generated pull requests instead of designing systems. Review queues grow until the system jams.

The wrong answer is loosening review standards to unblock the pipeline. That simply converts artificial speed into production incidents.

The Acceleration of Cognitive Debt

Programming, as Naur argued, is theory building. “Cognitive debt” is the erosion of this shared understanding: how the system works, what invariants matter, and where the sharp edges are.

AI does not necessarily write worse code than humans, but it compresses time. Teams are hitting the natural complexity limits of their architecture in weeks instead of years. Without proper comprehension of the underlying design choices, a team eventually becomes paralyzed. Cognitive debt will spike unless human comprehension is actively managed.

The Collapse of Predictability and the Story Point Fallacy

Agile methodologies rely on the assumption that effort is at least loosely predictable. Story points, velocity tracking, and sprint commitments all depend on this premise.

AI breaks it.

An agent can complete a complex, historically “five-point” feature in minutes, then spend hours looping on a trivial dependency issue that would be a “one-point” task for a human. Effort becomes non-linear and highly variable. Velocity ceases to be meaningful.

Handoffs Stop Making Sense

As code generation approaches zero marginal cost, the valuable work shifts upstream and downstream: problem framing, system integration, operational reliability, and product judgment.

That work does not map cleanly onto siloed handoffs from product manager to designer to engineer to QA to SRE. Each translation step introduces latency and distortion. The separation of responsibilities erodes because rapid iteration needs tighter loops and fewer translation steps.

The Momentum of Change: Patterns from the Frontier

To see where AI-native engineering is heading, look at a few teams that are further along:

Agent-Friendly Infrastructure: At Stripe, unattended coding “minions” run in standardized dev environments, execute workflows orchestrated by deterministic blueprints, and integrate with internal tools via the Model Context Protocol (MCP). This demonstrates that agent performance relies less on raw model intelligence and more on engineering hygiene: reproducible environments, fast tests, and safe tooling boundaries.
The Durable vs. Disposable Divide: Teams must explicitly split their codebases. In the disposable domain (prototypes, scripts), speed dominates and maintenance expectations are low. In the durable domain (systems of record, safety-critical services), trust is earned through tests, observability, and disciplined change control. As Honeycomb points out, AI makes disposable code much cheaper while raising the premium on rigor for durable code.
Context Engineering: Developers are moving toward Spec-Driven Development. Specifications, repository rule files, and structural conventions are treated as first-class artifacts that agents consume.

Defining the Shift: A Spectrum of Maturity

For a meaningful discussion we need well-defined terms:

AI-Assisted: The organization gives developers coding assistants but leaves workflows, team structures, and ceremonies unchanged.
AI-Augmented: AI is embedded into testing, documentation, and code review. Processes begin to adapt (sprints shorten, review standards adjust), but traditional team topologies and handoffs largely persist.
AI-Native: The organization is redesigned from first principles. The operating model involves small teams, collapsed role boundaries, spec-driven development, and agent orchestration where humans direct and review far more than they implement.

Moving from assisted to augmented is a tooling change; moving from augmented to native is an organizational transformation that changes the identity of a software engineer.

From SCRUM to AI-Native Cells

For existing organizations, transformation will be staged:

Stage 1: Stabilization and Gating (Must-Haves)

The objective is to integrate AI coding tools while protecting codebase durability.

Leaders must invest in clearing non-code chokepoints: review bandwidth, testing velocity, deployment confidence, and decision latency.
Begin documenting architectural decisions and domain context in machine-readable form: project invariants, style guides, and agent instructions.
Maintain strict human review requirements: at least one human developer must fully comprehend both the mechanics and the why behind every AI-generated commit before it merges.
Trap to avoid: Do not get distracted by tooling or custom agent development at this stage; focus on getting your context and testing foundations solid. MCP is mostly distraction.

The hard work is turning tacit team knowledge into a form agents can consume: the intuition, pattern recognition, and contextual judgment a team builds through long-term direct engagement with the domain.

Stage 2: Structural Redesign and Spec-Driven Workflows

This stage dismantles legacy Agile and restructures teams to match AI’s operational cadence.

Transition to Micro-Teams: Disband large departments into small, highly autonomous cells of cross-functional (PO-)engineers who own an entire vertical slice of the product.
Adopt Spec-Driven Development (SDD): Teams act as “context engineers,” writing dense, deterministic specifications and sign-off criteria (e.g., test cases) rather than writing the implementation code directly.
Implement Stacked PRs: Replace massive, multi-day PRs with stacks of small diffs (under 200 lines) that humans can review in minutes.
Shift to Cycle Time Metrics: Eradicate story points. Measure success by cycle time (idea conception to production deployment) and revenue impact per engineer (still a research topic).

Here the transformation gets personal. The traditional separation between product owner, developer, and tester dissolves. The Scrum Master role expands into a floating coach serving multiple cells. Engineers who enjoy broad ownership will flourish. Engineers who have built careers around deep single-discipline specialization may struggle. Leaders must provide real support (retraining, mentoring, and alternative career paths) rather than simply announcing the new structure.

Stage 3: Autonomous Orchestration (?)

The last stage might mean building infrastructure for agents rather than for humans. Deploy agent-friendly “devboxes”: isolated, predictable sandboxes where AI agents can iterate and fail safely without risking production data. Redefine the daily workflow along the lines of what Bloch calls the 10 AM rule: engineers spend mornings defining objective functions and aligning context, allowing agents to execute throughout the day and night.

But this is mostly speculation.

The Risks

Cognitive debt: Speed without comprehension is a liability. Teams that ship faster without investing in shared understanding will build unmaintainable systems in weeks.
Talent polarization: AI-proficient engineers will pull ahead while others stagnate. Leaders have an ethical obligation to invest in retraining and provide real paths for adaptation, not merely optimize for the highest performers.
Measurement: Output metrics such as lines of code or PRs merged are actively harmful. Cycle time, defect escape rate, and revenue per engineer are imperfect but directionally better.
Incumbency: Legacy systems and cultural habits slow change. And waiting for certainty is itself a risk.
YOLO: Don’t get lost in tooling, MCP integrations, framework churn, etc. Focus on first principles, focus on what gets into your agent’s context.

Impact on us

For us engineers, the value is shifting fast. Generating syntax is no longer a specialized profession; it is becoming a general business competency. The value of writing code is falling, while the value of knowing what to build is rising.

Career longevity depends on mastering what AI struggles with: architecture, domain expertise, problem framing, verification, orchestration. The developers who thrive will not be the ones who excel at writing your-language-of-choice from memory; they will be the most rigorous editors, the best context engineers, and the clearest thinkers.

Conclusion

The transformation is unavoidable and puts existing structures, career paths, and professional identities at risk. It demands investment in engineering hygiene as much as in new LLM tooling. It also needs leaders who can hold two truths at once: the organizational change is necessary, and the people going through it deserve support, retraining, and dignity.

My bet is on small, autonomous, spec-driven teams that spend their time on judgment rather than execution. Getting there without burning out people is the hard part.