Product and engineering · Answered by Golden Section from more than 400 B2B software companies observed
Change what each engineer produces before you change how many you employ. AI makes a demoable first version far cheaper, but the measured evidence on experienced developers is mixed, and the work that protects a vertical product has not become cheaper: maintenance, security, integrations, compliance and reliability. So baseline delivery before adoption, using sprint throughput, defects per release and time to fix production issues. Point the capacity AI frees at AI features inside the workflows customers already pay for; our suggested split for incumbent software is about 45% core, 45% AI-native features and 10% skunkworks. Treat a smaller team as a conclusion delivery data reach, and capture it through attrition, not layoffs. This month, pull the last two quarters of sprint metrics so there is something to compare against.
Judge engineering on output and quality, never on headcount alone. Let AI raise throughput first, spend the gain on the roadmap, and let the team shrink only when the same roadmap has shipped with fewer people and defect rates held for at least two quarters. Capture that gain by not backfilling departures, not through layoffs.
| Metric | Value | What it means | Source |
|---|---|---|---|
| Engineering and product allocation | about 45% core / 45% AI-native features / 10% skunkworks | share of engineering and product resourcesGolden Section's suggested split for incumbent software; the 10% builds what could eventually cannibalize the core | Golden Section, publishedThe Enhancement Doctrine, March 2026 |
| Measured effect of AI tools on experienced developers | 19% longer per task (95% CI +2% to +39%) | time to complete real tasks on their own repositories, AI allowed vs disallowed, randomizedearly-2025 tools; developers believed AI had made them faster. METR now says developers are likely sped up more in 2026 | External benchmarkMETR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025) |
| Follow-up study, late 2025 | 18% faster for returning developers (CI −38% to +9%); 4% faster for new ones | same randomized design, 57 developers and 800+ tasksboth intervals include zero, and METR calls the result very weak evidence because AI-reliant developers declined to take part | External benchmarkMETR, We are Changing our Developer Productivity Experiment Design (February 2026) |
| Code maintainability under AI | refactoring down 70%, duplicated blocks up 81% | change in code patterns across 623 million code changesGitClear, January 2026, as cited in Golden Section's research; Google's DORA 2025 finds AI linked to higher throughput and lower delivery stability | External benchmarkGitClear Maintainability Gap (2026), via Investing in Software addendum |
| Capturing AI productivity gains | through attrition (not backfilling), not layoffs | how to reduce engineering headcount once delivery data supports itkeeps product memory in the company while the gain is proved out | Golden Section operating viewGolden Section operating view |
AI has split engineering work into two kinds. Producing new code is much cheaper, which is why the number of competitors at the bottom of every vertical is rising. Keeping a system that a regulated business runs its operations on secure, integrated and stable is not cheaper, and the code-quality data suggests it may be getting harder. The measured evidence on speed is also unsettled: METR's July 2025 randomized study found experienced developers took 19% longer with early-2025 tools, and its February 2026 update reported likely speedups but called the newer data very weak evidence. Our research put it plainly: the build barrier fell and the maintain, secure and integrate barrier did not.
That changes where the bottleneck sits. When an assistant writes more of the code, the scarce work becomes writing a precise user story and proving the output matches it, which are the business analyst and QA seats in the dev org chart. Teams that skip those seats ship faster for a quarter and then spend the next one on defects. Hold the product engineering process to its sprint metrics, keep code documentation current, because product memory lives there once people leave, and route every model call through one layer so the vendor continuity play has something to fail over. When the data does show the team can be smaller, let attrition do the work rather than layoffs. Cutting engineers on the strength of a feeling loses the people who know why the system works, and that knowledge is slow and expensive to rebuild.
The numbers are invented. A vertical software company at $6M in annual revenue has 14 engineers, and a board member suggests AI should let it run with 9. The CTO instead baselines two quarters of story points, defects per release and time to fix production issues, then rolls out AI tools with a rule that every AI-assisted change gets a second reviewer and a test. In the first quarter throughput rises about a quarter while defects rise too; by the second, defects are back to baseline and throughput holds. The company keeps the team, moves four engineers onto an AI feature in its core scheduling workflow, and decides not to backfill two departures, ending the year at 12 with a larger roadmap shipped.
A team that is plainly too large for its roadmap should be resized whether or not AI is involved, and the reason should be the roadmap. And a product whose value is a thin interface over commodity data faces a harder question than headcount, because AI-native competitors can rebuild it cheaply.
From the Golden Section mistakes list, each paired with the play that prevents it.
Headcount is an input cost; what matters is shipped, working product per dollar, which is the number AI should move.
AI magnifies the engineers using it, and plans that assume it replaces their judgment get the defects that follow.
Cutting engineers on a hunch about AI turns over the people who hold product memory, which is slow to rebuild.
AI tempts teams to skip the specification and QA rigor that full-stack shortcuts already undermine, and it does not scale.
In the order we would run them. Each is on its own page, most with a free Excel template.
Sets the sprint and defect metrics that show whether AI is actually raising output.
Puts names in the specification and QA seats that become the bottleneck when code gets cheap.
Keeps product knowledge in the codebase rather than in the heads of people a smaller team might lose.
Directs freed capacity toward AI features in existing workflows instead of letting it disappear.
Makes sure the AI your team now depends on can fail over to a second provider.
Development plays The full set for structuring, running and measuring an engineering organization, which is the system AI is now changing.
In time, many will ship more roadmap per engineer, but the evidence does not support planning a cut in advance. Measured studies show smaller and less certain gains than developers report, and maintenance work has not shrunk. Let delivery data, gathered over two or more quarters, tell you the team can be smaller.
We expect it to slow engineering hiring per dollar of roadmap before it shrinks existing teams. Capture the gain through attrition, by not backfilling departures, rather than through layoffs, which lose the people who hold product memory. Teams will also change shape, with relatively more weight on specification, review, QA and architecture.
The roles that define and verify the work: the business analyst who writes the user story, QA who proves the output matches it, and the architect who keeps the system coherent. Generated code is only as good as the story it was written against and the test that checks it.
Yes. A team of six to fifteen engineers at $3M to $8M in revenue should still aim for about 45% on the core product, 45% on AI-native features in the workflows customers pay for and 10% on skunkworks. At that size the 10% may be one person part of the time, but it should be named and protected.
Building AI into the core workflow is a product investment that takes quarters to reach revenue, which is the kind of structural change minority equity can fund. Engineering spend without a measurable payback is not something a lender should finance.
Growth equity →Reviewed by Dougal Cameron, CEO & Co-Founder on 2026-10-22. Golden Section observations are labeled separately from external benchmarks and illustrative arithmetic.