After the Tipping Point: Where the SDLC is Heading, and How to Build Teams and Products for It
Three workshops at Google I/O 2026 made the shape of the next software development lifecycle visible. Here is what it changes — for how we hire, how we build, and what we measure.
After the Tipping Point: Where the SDLC is Heading, and How to Build Teams and Products for It
Three workshops at Google I/O 2026 made the shape of the next software development lifecycle visible. Here is what it changes — for how we hire, how we build, and what we measure.
Google I/O 2026 had a workshop titled, plainly, Software engineering at the tipping point. The phrasing was honest. We have crossed a line. Sundar Pichai's April 22 blog post claimed that 75% of new code at Google is now AI-generated and approved by engineers, up from 50% just months earlier. Both qualifiers — new and approved by engineers — matter, and Google was careful with both at I/O. But neither softens what is now visible across the developer track: the software development lifecycle has changed shape, and most of our organisational, team, and product habits were built for the previous shape.
This is a note on what changes next. Not inside Google — they have the engineering depth, the compute budget, and the institutional muscle to absorb the shift. The harder question is what changes for everyone else. For ten-person startups, for product teams inside non-tech enterprises, for solo founders, for the experience strategist who used to write specs and now writes code. The next SDLC is being built right now, and most of the conversation about it is being held one company at a time, in private. This is a public attempt at the same conversation.
The three sessions I attended — Tipping Point, Build core skills to thrive as an AI-era developer, and The future of software development with the Gemini, Antigravity, and AI Studio leads — between them surfaced three structural shifts. Each rewires how teams should be built and products should be designed. I will walk through each, then say what I think it means, as someone who has spent eleven years inside agile engineering teams as PO and designer (A-CSPO, Thoughtworks and Kellton), and the last five months actually shipping code through Claude Code on Facilitron and a Tamil Nadu Elections data project.
Where the SDLC is heading
Three observable shifts.
Code becomes the cheapest part of the loop. Pichai's 75% is the leading indicator, not the destination. When generating syntax is functionally free, the binding constraints move upstream and downstream of code — to spec, to review, to integration, to verification. DORA has been saying this since 2024: AI is an amplifier of magnitude, not direction. Strong fundamentals get stronger; weak fundamentals fall apart faster. The first-order observation at I/O was that the time engineers used to spend writing code is now spent reading it, validating it, and arguing with it.
The human-approval loop is the new bottleneck, not the keyboard. Pichai's careful phrase — "approved by engineers" — is doing all the load-bearing work in his claim. The engineer is no longer the producer; the engineer is the gate. At Google's scale, that gate is staffed by thousands of paid reviewers with institutional authority and the technical depth to push back on a model's output. At a ten-person startup, it is staffed by three exhausted people on Slack. The economics of who reviews, how, and against what standard, are the actual question. Google did not address it at I/O, because it is not their problem.
The cost of an agentic workflow is now denominated in tokens, not headcount. Multiple I/O sessions positioned Gemini 3.5 Flash as the price point that makes long-running agent tasks economically viable. This is a real shift. For most of the last decade, "more engineers" was the only lever for "more output." Now there is a second lever, and it has a different cost curve, different failure modes, and different governance properties. Engineering budgets that used to be 90% salary and 10% compute will rebalance, and the teams that don't notice will be flanked by the ones that do.
These three — code commoditised, review as the bottleneck, compute as a budget line — are the spine of the next SDLC. Everything that changes in teams and products downstream falls out of these.
How to build teams
If code is the cheapest part of the loop, the team's value lies in the parts that aren't code. That changes what we hire for, who sits in which seat, and how big a team needs to be.
The T-shape model — deep technical core, broad adjacent skills — was the right idea for the last decade. It is now too rigid. What I/O kept gesturing at without quite naming is something closer to a convergent generalist: someone whose stack includes technical fluency, spec discipline, behavioural modelling of agents, deployment literacy, and product sense — not at expert level in any single one, but at integrated level across all five.
Three implications worth committing to.
Roles converge before they re-specialise. The hard line between PO, designer, engineer, and tester is dissolving for small teams. Inside large orgs it will persist longer, but the boundary will become a process artefact, not a skill one. A useful test: can one person carry a feature from problem framing through deployment? If yes, your team can be smaller and faster. If no, you are paying a coordination tax that AI is making more expensive, not less, because every handoff is a place where context is lost between agents and humans both.
Behavioural disciplines become first-class engineering skills. Psychology, design research, facilitation, qualitative inquiry — these were "adjacent" to engineering for decades. In an agent-saturated workflow, modelling how a particular model fails, how a team coordinates under uncertainty, how a user's mental model diverges from the system's — these become load-bearing. Hire for them on purpose. Do not treat them as soft additions bundled inside a PM or design role.
The team of the future is smaller, but only if the individuals are wider. Pichai's "fully autonomous digital task forces" line implies an org chart where two humans orchestrate fifty agent tasks. That works only if the two humans can each cover problem framing, spec writing, architectural judgement, code review, and deployment. The hiring market has not caught up to this yet. Job descriptions still split these functions across three or four roles. The first companies to combine them deliberately will compress their org charts and their burn rates at the same time.
How to build products
If code is cheap and review is the constraint, products should be built differently from the inside out.
Specs become the product artefact. Not the spec document — the spec as version-controlled, peer-reviewed, executable artefact that an agent can be tested against. The OOUX and BABOK agent skills I published to GitHub are a small example of this pattern: codified methodology that any agent can be given as context, that survives across model versions, and that a team can debate and improve independently of any individual conversation. If your spec lives only inside one person's head or one Slack thread, you are building on sand.
Architecture before features. When AI was slow, retrofitting architecture onto a product later was painful but survivable. When AI is fast, retrofit becomes the dominant cost. The cheap thing to do is generate features; the expensive thing is restructure them once they accumulate. Facilitron's architecture — what I now call GUIDE+OAI+LEARN — was retrofitted, not designed up front. It works. The cost of having to formalise it after the fact has been the most expensive single thing I have done as a builder this year. Pay that cost up front.
Token economics are product economics. Most AI-native products being built today have not modelled their unit economics rigorously. Compute is treated like SaaS storage was in 2008 — assumed to trend toward zero, ignored at the budget line. This ends the way every "assumed free" cost has ended. Products that aren't measuring cost-per-completed-task as a first-class metric will be flanked by products that are. This is especially true for agentic workflows, where a single user task can cascade into thousands of tokens across multiple model calls in ways the product team did not predict at design time.
Behavioural models of failure replace defensive coding. Engineers used to write code defensively against unknown user input. We now have to write systems defensively against unknown model behaviour. The skills for this are not primarily engineering skills. They are the skills behavioural scientists, ethnographers, and qualitative researchers have been using for decades — building careful mental models of how a system (or a person) fails, what predicts the failure, and how to design around it. Teams that have these people in product roles will ship more reliably than teams that don't.
What is actually changing
The 10x code wave is not a productivity event. It is a structural rearrangement of who builds software, how teams are shaped, and what the unit of product becomes.
For most of the last decade, software teams were organised around a scarce resource: the engineer's time at the keyboard. Everything around that resource — the PRD, the design spec, the sprint, the standup, the retro, the QA cycle — was built to maximise its yield. We are now in the first decade where that resource is no longer the scarcest one. What is scarce now is judgement, spec discipline, behavioural intuition, and the institutional muscle to combine all three under pressure.
The teams and products that survive this transition will be the ones that recognise the change in what is scarce and rebuild themselves around the new scarcities. Not the ones that double down on the old ones.
The leaves were never the work. The forest always was. We are now, possibly for the first time, able to build organisations that can see it clearly.
If you're thinking about how to restructure a team, a hiring plan, or a product spec for this shift, I'd like to know what is breaking first in your context. The next SDLC will be built in the open or not at all.