The New Pyramid of Software Engineering

TLDR: Luca Rossi from the Refactoring newsletter argues that engineering teams face analysis paralysis when adopting AI because most advice is tactical, not strategic. He proposes a three-layer pyramid -- Developer Experience, AI, and Product Engineering -- where each layer only works when the one below it is solid, much like Maslow's hierarchy of needs applied to software teams.

Summary:

If you lead an engineering team right now, you are probably drowning in advice about AI workflows, spec-driven development, and the next shiny tool that will supposedly change everything. The problem, as Rossi puts it bluntly, is twofold: volatility and applicability. Any recommendation you act on today might be irrelevant next month, and even the good ones rarely translate directly to your team's existing processes. That combination leads to something deeply familiar -- analysis paralysis. Teams end up underinvesting in AI because nothing feels durable enough to move from individual experiment to team-wide practice.

Rossi's core thesis is that most of these AI adoption ideas are tactical when what teams actually need is a strategic framework. He draws on conversations with over a hundred tech leaders, a survey of 350-plus teams, and hands-on work with a cohort of CTOs and VPs. From all that, he distills three foundational areas: Developer Experience at the base, AI in the middle, and Product Engineering at the top. The metaphor is deliberately Maslow-like -- you cannot get value from the upper layers if the lower ones are neglected.

The Developer Experience layer is the foundation. This is not a new idea, but it is the one that teams most often skip in their rush to adopt AI tooling. If your build times are painful, your CI pipeline is flaky, and developers spend half their day fighting the environment rather than writing code, then no amount of AI integration will save you. The tooling has to work. The feedback loops have to be tight. That base layer has to be rock solid before anything built on top of it can deliver real returns.

The AI layer sits in the middle, and this is where the Spec-Driven Development trend fits. The idea is that instead of jumping straight from requirement to code, you invest in creating detailed specifications that AI can execute against. Rossi acknowledges the valid objection that AI might soon figure out specs on its own, making the investment short-lived. But he positions it as currently the most consensus-backed approach in a landscape that has very little consensus at all. The key question for any team is not whether to use AI, but how to adopt it in a way that builds on existing workflows rather than requiring a full migration.

Product Engineering caps the pyramid. This is the layer where technical decisions are driven by product outcomes rather than purely technical concerns. It is also the layer that only works when developer experience is smooth and AI tooling is properly integrated. Without those foundations, teams get stuck in the weeds and never make it to the strategic product-level thinking that actually moves the needle for the business.

Key takeaways:

Engineering teams face analysis paralysis on AI adoption because most advice is tactical and short-lived rather than strategic
The three-layer pyramid is: Developer Experience (base), AI (middle), Product Engineering (top)
Each layer only delivers value when the one below it is solid -- skipping DX to jump to AI tools is a recipe for frustration
Spec-Driven Development is the current closest thing to consensus on working with AI, but its durability is genuinely uncertain
The right question is not "which AI tool should we adopt" but "how do we integrate AI into our existing workflows without a full migration"
Over 350 teams surveyed show this pattern: the teams shipping fastest are the ones that got their foundations right first

Tradeoffs:

There is a real tension here between moving fast on AI adoption and getting the foundations right. Teams that wait for perfect Developer Experience before touching AI risk falling behind competitors who are learning by doing. Rossi's pyramid implies a strict ordering, but reality is messier -- sometimes you discover DX problems precisely because you tried to integrate an AI tool and hit friction. The model is useful as a diagnostic but potentially misleading as a strict sequence. Also worth noting: the full article is paywalled, so the detailed breakdown of each layer and specific recommendations are not available in the free version. What we have is the strategic framing, not the tactical playbook.

The New Pyramid of Software Engineering