🌱 Dive into Learning-Rich Curation with groCTO ⤵️
Article of the Week ⭐
“DORA metrics alone can produce a false sense of system health and engineering excellence, measuring delivery efficiency without accounting for system understanding. AI didn’t force a new way to fail. However, it shines a light on something that has always existed.”
Paul LaPosta’s piece from LeadDev delivers a practically useful writeup about engineering metrics in the AI era. It explains precisely where the improvement framework’s contract breaks down and what to do about it. If you’re a director, staff engineer or DevOps specialist using delivery metrics to make decisions about team health, system risk, or promotion, this is required reading.
Deployment frequency, lead time, change failure rate, MTTR: these four numbers tell you how work moves through the pipe. They tell you nothing about whether anyone on the team can explain what’s in it. LaPosta opens with a story that will feel eerily familiar: a junior engineer leaning on AI to generate tickets and code, appearing productive, until a critical project exposed that there had been throughput without understanding. At the org level, the same failure mode scales quietly. Your dashboards look healthy. Your systems are becoming illegible.
The legibility problem isn’t new, dashboards have always been able to look green while the underlying system became unmanageable.
What AI has done is accelerate the rate at which this happens. It seems that code is shipping faster than it’s being understood, or at least those are the claims of people who observe this process from the outside.
Changes are occurring outside your traditional SDLC entirely in AI vendor consoles, identity providers, AI agents with delegated authority. None of that shows up in your DORA review. MTTR can look excellent because rollback is fast, even when nobody on the incident call can explain why the rollback worked. LaPosta describes exactly this scenario: a dark service deployment that disrupted a live critical path, with the team insisting they couldn’t possibly have caused it, right up until the rollback fixed everything instantly.
Incidents that take longer to diagnose even when metrics are green. System behavior that changes without anything appearing in review. Teams that can produce a polished architecture slide but depend on two people carrying the real mental model in their heads. If fewer than two people can walk you through the critical path end-to-end in plain language in under five minutes (or need time verify an AI’s hallucination’s), then the needle hasn’t moved much, if at all.
LaPosta isn’t arguing for a new framework.Thank goodness, we don’t need another one! He’s arguing for honesty about what DORA was built to do.
His practical recommendation:
Attach a detailed scope note to every DORA review for a critical system. Explicit metric definitions, dependency chain, known out-of-band change risks, and at least one recent incident narrative.
Pick one critical system, run the tighter review pattern for a quarter. Ask whether leaders are making better decisions about ownership and risk not just whether the charts improved.
DORA is not the problem; managers using it as a silver bullet so they can pretend it tells the whole story is.
Eliyahu Goldratt’s The Goal (1984) has a useful insight for today’s AI constraints: improve anything that isn’t your bottleneck and you’ve improved nothing. You’ve just built up inventory in front of it. Forty years later, engineering teams are doing exactly this with AI, and the LinkedIn screenshots of 47-feature sprints are the evidence.
The pattern is consistent across every workflow:
Code generation: 3x more PRs, same reviewers, same deployment pipeline. You haven’t tripled throughput. You’ve tripled the review queue.
Documentation: AI-generated PRDs look like thinking happened. The thinking didn’t happen. The bottleneck was never “produce more documents,” it was “make better decisions.”
Performance reviews, feedback, mentoring: these aren’t bottlenecks to eliminate. The slow, difficult work of articulating your thoughts is the value. AI pointed at thinking work is lobotomy with a nice interface.
What can we learn from this?
Toil: repetitive, mechanical, nobody gets smarter doing it. Should be automated ruthlessly.
Thinking work is slow because the slowness is the mechanism. Remove it and you remove the understanding.
Where AI does work: legacy codebase comprehension, incident response synthesis, onboarding acceleration, and offloading the mechanical work from your scarcest senior engineers so their judgment goes further.
What is your actual bottleneck — and does your AI vendor address it?
If you can’t answer the first part, you’re not ready for the second. You’ll just move faster in the wrong direction. Goldratt figured this out in a manufacturing novel. The lesson hasn’t changed.
🧨 “If doing things right is slower than doing them wrong, your architecture has already lost.”
The four classic symptoms of bad software design show up everywhere:
Rigidity: a two-day change becomes two weeks because everything is coupled to everything. The fix: Strategy Pattern and Open/Closed Principle so adding a new carrier means a new class, not touching existing code.
Fragility: you fix payments and break payroll. The fix: Interface Segregation so each module only sees the config slice it needs, not a global object everyone can mutate.
Immobility: you can’t reuse a validation function without dragging along the database and the UI. The fix: Clean Architecture so business logic lives in pure components with no knowledge of frameworks or persistence.
Viscosity: the sneakiest one. When the hack takes 5 minutes and the right path takes an hour, the hacks win. Every time. At scale. The fix is automation and tooling that collapse the gap.
The underlying principle across all four: make the right thing the easy thing. If your architecture punishes correctness, developers will opt towards survival.
These signals don’t self-resolve, merely get triaged and tolerated. The bad outcomes compound. Identifying them is the first step; the second is making clean design the path of least resistance.
AI coding tools are beginning to shape how teams think, review, debug and even structure engineering work. But the real differences are less about features and more about workflows. Some optimise for speed inside existing habits, while others reshape development around deeper AI collaboration and reasoning.
What’s becoming clear is that teams are no longer looking for one universal assistant. They’re starting to match tools to different kinds of work, from rapid iteration to large-scale refactoring and architectural thinking. This piece breaks down those trade-offs in a practical, grounded way.
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week, Ciao 👋
Curators - Diligently curated by our community members Denis & Varun
Featured Authors - Paul LaPosta, Kacper Wojaczek, Marcos F. Lobo 🗻🧭
Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.