Last week I published The Builder's Map — a landscape overview of what matters in AI-assisted development. A friend who runs a company read it and called me. "You mapped the terrain," he said. "But I need a route. What should my engineers actually be doing? What products survive? How do I restructure?"
Fair. The map was a catalog. This is the operating manual.
Here's my thesis, stated plainly: the question has flipped. For decades, the constraint was implementation — you knew what to build but lacked the hands. Now the constraint is specification. AI can build almost anything, so the question "what can we build?" became meaningless. The only question that matters: what should we build, and how do we organize to decide well?
The 24-Month Trajectory (and Why It Matters for Strategy)
I'm not going to give you a model comparison chart. Models change quarterly. But the trajectory is stable enough to plan around, and if you're running a company, you need to know the shape of the next two years — not the specs of this week's release.
The strategic takeaway isn't about any specific capability. It's about the slope. Every quarter, AI handles more of what was human work. If your strategy depends on any specific boundary holding — "AI can't do X" — you have a strategy with an expiration date. Plan for the slope, not the snapshot.
What Your Engineers Should Be Doing Right Now
The traditional engineering day — 80% coding, 10% meetings, 10% planning — is inverting. The best teams I've tracked have already shifted senior engineers to roughly 60% architecture and review, 30% mentoring and collaboration, and 10% hands-on coding. This isn't theoretical. Faros AI found that PR review time increased 91% on high-AI-adoption teams. Code generation got fast; the bottleneck migrated to review.
And here's the thing nobody wants to say: MTTR is not improving even as PR velocity increases. More code ships, but operational quality is flat. The speed increase is real. The quality increase isn't — yet. Addy Osmani calls this "comprehension debt" — code that was never understood by the person responsible for it.
This has direct implications for how you staff:
The new hiring profile isn't "10x coder." It's the T-shaped engineer: deep in one specialty, broad across product, design, and data. Someone who knows what to build, can direct AI to build it, and can evaluate whether the output is actually good. The emerging title is "Builder" — and it scrambles traditional org charts because it's not clearly IC or manager.
Opsera's study of 250,000 developers found senior engineers realize 5× the productivity gains of juniors with the same AI tools. This isn't surprising — AI amplifies existing judgment. But it means the return on a senior hire just increased dramatically, and the gap between a good team and a mediocre one is widening, not closing.
The junior problem you need to plan for
Junior developer postings are down 67% in the US. UK graduate tech roles down 46%. Stanford found employment for devs aged 22–25 declined 20% from peak. 37% of employers say they'd rather "hire" AI than a recent graduate.
I understand the logic. I also think it's catastrophically shortsighted.
Today's juniors are tomorrow's seniors. If you stop growing them, you face a structural senior shortage in 2028–2032. The historical precedent is clear: hospitals that cut residency programs in the 1990s faced physician shortages in the 2000s that took a decade to resolve. The industry is eating its seed corn.
My actual advice: keep hiring juniors, but restructure what they do. Configure AI tools for Socratic questioning, not code generation. Make juniors review AI output rather than write from scratch. Use AI to compress the learning timeline, not eliminate it. The companies that maintain junior programs now will have the senior engineers everyone else is desperate for in five years.
The Kill List, the Buy List, and What to Actually Build
35% of enterprises have already replaced at least one SaaS tool with custom-built software. 78% plan to build more. This is the most significant shift in enterprise software in a decade and most founders I talk to are still running the 2022 playbook.
Here's how I'd think about it:
| KILL (or watch die) | BUY (don't try to replace) | BUILD (the new opportunities) |
|---|---|---|
| Form builders, survey tools — Netlify's CEO says employees built replacements in hours | ERP, HRIS, financial reporting — accumulated business logic is irreplaceable | AI orchestration infrastructure — $11B → $30B+ by 2030 |
| Basic task tracking and project management | Regulatory/compliance software — deterministic, can't be probabilistic | Governance and compliance tooling — CIOs think they have 60–70 AI tools; audits reveal 200–300 |
| Tier 1 customer support (scripted responses) | Payment infrastructure (Stripe) — trust and compliance moats | Vertical AI wrappers with proprietary domain data — Gartner's explicit 2026 recommendation |
| Simple landing page tools, basic BI dashboards | Network-effect platforms (Slack, GitHub) | AI observability platforms — 96% of IT leaders maintaining or growing spend |
| Any "feature company" without proprietary data | Deep infrastructure (databases, CDNs, auth providers) | Testing infrastructure — as AI generates more code, testing becomes more important, not less |
The principle is simple: build for differentiation, buy for operational resilience. If your competitive advantage comes from something AI can replicate in a weekend — a clean UI on commodity logic — you're already dead. If it comes from proprietary data, domain workflow integration, or compliance expertise that took years to accumulate, AI just made you more valuable because your competitors can't shortcut to where you are.
The CMS question
Someone asked me specifically: is a CMS still a thing?
Yes. But what it is has fundamentally changed. The phrase appearing in analyst circles this year is "Content Operating System" — not content management system. dotCMS put it well: "AI isn't a feature; it's the foundation of a new kind of content management — one where governance, collaboration, and intelligence are native."
Here's the sober take: when AI agents can write content, the system that governs content becomes more important, not less. AI agents should have write access only to draft paths. Humans review and approve. The CMS becomes the checkpoint, not the creator. And with SOX, GDPR, and the EU AI Act, you need audit trails of every AI interaction. A solid CMS isn't a legacy choice — it's a governance system that happens to also manage content.
The drunk take is "AI replaces the CMS." The sober take is that you need a system of record for content more than ever. What changed is what the system does.
How to Structure Your Org
The flattening is real and it's accelerating. Amazon cut ~14,000 manager roles in 2025, then ~16,000 more in January 2026. Meta runs AI teams with 50 engineers per manager. Gallup measured average manager span increasing from 10.9 to 12.1 — a 50% increase since first tracked. Block cut 4,000 roles (~40% of workforce). Shopify's CEO mandated: prove AI can't do the task before requesting headcount.
The team size compression is dramatic: a 5-person team in 2026 ships what a 50-person team shipped in 2016. Median Series A headcount dropped from 57 (2020) to 47 (2025). Revenue per employee at AI-native companies tells the story — Cursor at $3.3M, Midjourney at $3–5M.
But let me push back on the "just shrink everything" narrative, because I think it's getting oversimplified:
What companies are doing
Cutting headcount across the board. Eliminating junior roles. Flattening org charts by removing management layers. Measuring success by revenue-per-employee. Treating AI as a way to do the same work with fewer people.
What companies should be doing
Reorganizing around judgment, not headcount. Identifying which decisions require human evaluation and staffing those. Maintaining junior pipelines. Measuring success by decision quality, not velocity. Treating AI as a way to do different work, not just more work faster.
Stripe's Minions ship 1,300 PRs per week with zero human-written code. Amazon's unrestricted AI deployment lost 6.3 million orders in a single Sev-1 incident. Same underlying technology. Opposite outcomes. The difference? Stripe built governance infrastructure before deploying agents. Amazon mandated 80% AI usage without it. The org structure matters more than the tool.
Six Things I'd Actually Do
If I were running an engineering org tomorrow, here's what I'd do — not what I'd "consider" or "evaluate." What I'd do.
1. Treat specification as the product. The bottleneck moved from implementation to specification. If you can precisely describe what you want, AI can build it. Invest in the skill of specifying — requirements documents, acceptance criteria, architectural decision records. The team that specifies well ships 10× faster than the team that codes well but specifies poorly.
2. Make governance your competitive advantage. Not governance as bureaucracy — governance as infrastructure. Every AI-generated PR gets a review. Every AI agent writes to draft, never to production. Audit trails for compliance. This isn't overhead; this is what separates Stripe's 1,300 successful PRs/week from Amazon's catastrophic failure. Build it before you need it.
3. Kill your feature roadmap. In 2024, a feature took 2–6 weeks to build. In 2026, it ships in a day. Your feature moat is already gone. If your competitive advantage is a feature set, a competitor with good AI tooling can replicate it in a sprint. Rebuild your strategy around data, workflow integration, and domain expertise — things that take years to accumulate and can't be prompted into existence.
4. Keep growing juniors. Yes, it's expensive. Yes, AI makes juniors less immediately productive on traditional tasks. Do it anyway. Configure AI for teaching, not bypassing. Pair juniors with AI on code review. Compress the learning timeline from 5 years to 3. The companies that maintain this pipeline will have the senior talent everyone else is bidding on in 2030.
5. Reorganize around judgment, not hierarchy. The question isn't "how many managers do we need?" It's "which decisions require human judgment, and who's accountable for them?" Staff the judgment points. Automate everything else. Then continuously reevaluate — because what requires judgment today might not in 18 months.
6. Hire for the T, not the I. The deep specialist who can't think about product is less valuable than the generalist with one deep skill who understands users, data, and design. The best engineers I've seen in AI-native teams aren't the fastest coders — they're the ones who ask the right questions before any code gets written.
The Honest Summary
The AI coding revolution is real. The productivity gains are real. The risks are also real, and they're structural — not bugs to be fixed, but fundamental tensions in how this technology interacts with organizations.
The companies that win won't be the ones that adopt AI fastest. They'll be the ones that reorganize around it most thoughtfully. Speed without governance is just faster failure. AI without specification is just faster debt. Headcount reduction without pipeline maintenance is just a senior shortage on layaway.
The playbook is boring: specify well, govern everything, maintain your talent pipeline, build on data not features, and structure around judgment. None of this is revolutionary. That's the point. The revolutionary technology demands the most disciplined response.