Rating Your Team, The Real Cost of Bad Code, and Is Software Engineering Becoming a Sport?

Questions to Rate Your Team, Business Impact on Unhealthy Code, and Weekly Readings

TLDR: This edition of Refactoring.fm covers a practical self-assessment for engineering teams across developer experience, AI adoption, and product engineering. It also revisits a compelling interview with Adam Tornhill on the measurable business cost of unhealthy code, and wraps up with three sharp reads on AI, software careers, and agentic platforms.

Summary:

Luca opens with a framework I find genuinely useful: a short self-assessment built around what he calls the new pyramid of software engineering. The three layers are Developer Experience, AI, and Product Engineering, and the argument is that you have to nurture them in exactly that order. You can't bolt AI onto a broken developer experience and expect anything good to happen, and you certainly can't have real product engineering autonomy without the first two layers being solid.

The self-assessment itself is a set of statements you rate from one to five. Things like "it is easy to do work as a developer on my team," "engineers make good use of AI," and "engineers know if a feature is successful or not." I've seen a lot of team health surveys over the years, and what I like about this one is that it's organized around causality, not just vibes. The order matters. Fix DX first. Then AI. Then push toward product engineering autonomy.

The centerpiece of the issue is a callback to an interview with Adam Tornhill, founder of CodeScene. Adam's team ran the Code Red study, a large-scale analysis correlating code health with actual development performance. The numbers are stark. Healthy code lets teams move more than twice as fast. Unhealthy code creates wild variance in how long tasks take, which wrecks estimation. And some tasks in really bad code can take up to ten times longer than expected. Ten times. That's not a rounding error, that's a catastrophe hiding in your backlog.

What hit me hardest was the finding about developer familiarity. Engineers who don't know the codebase well take twice as long to work in unhealthy code compared to those who do. That's a hidden onboarding tax that nobody budgets for. Every time your team grows, every time someone rotates off, every time you bring in a contractor, you're paying that tax. And it compounds. Silently.

The weekly readings round things out nicely. There's a piece asking whether software engineering is starting to look like professional sports, with a finite career window rather than a lifetime of compounding expertise, because AI handles the learning for you. GitLab's CEO writes about restructuring around agentic AI. And Garry Tan makes the case that agents get powerful through purpose-built skills, not by making the general harness bigger. All three are worth your time.

Key takeaways:

The three-layer engineering pyramid (DX, AI, Product Engineering) should be addressed in order, not in parallel
Healthy code enables development more than twice as fast as unhealthy code, with data from a large-scale study to back it up
Unfamiliar developers working in unhealthy code take twice as long, creating a hidden and compounding onboarding cost
Task completion variance in unhealthy codebases makes estimation nearly impossible, which is a business problem, not just an engineering annoyance
The question of whether AI is shortening software engineering careers is real and worth thinking about now, not later

Why do I care: The Adam Tornhill data is the kind of ammunition every senior engineer and architect needs when fighting for refactoring time. We've always known bad code is slow, but "up to ten times longer per task" and "twice as slow for unfamiliar developers" are numbers you can put in a spreadsheet and show to a product manager. The pyramid framing also resonates with me. I've seen teams try to skip ahead to product engineering autonomy without fixing the underlying DX, and it always falls apart. The self-assessment is short enough to actually use in a team retrospective. That's rare.

Questions to rate your team, business impact on unhealthy code, and weekly readings