Blog

AI code review tools are getting smarter, but they may be solving the wrong problem. Most delivery failures aren't caused by bugs slipping through review. they're caused by PRs sitting idle in a queue for days while sprint commitments quietly slip. This piece breaks down why teams keep investing in automated review without seeing better delivery outcomes, and what the tooling stack actually needs to look like.

Technical debt in agile teams is not primarily an engineering failure but a structural outcome of sprint driven incentives that prioritize closing stories over maintaining long term code health. Because refactoring and architectural improvements rarely produce immediately shippable outcomes, they are consistently deferred, allowing debt to compound silently beneath clean sprint boards and healthy looking velocity metrics. Research by Ciolkowski et al. highlights how feature delivery repeatedly outcompetes debt repayment, creating an imbalance that most sprint tooling fails to expose. For PMs and delivery leaders, the real risk is not how to fix existing debt, but whether their process makes debt visible, allocates protected refactoring capacity, and coordinates action on early warning signals such as rising estimates and reopened stories. Without structural visibility and follow through, teams mistake reported velocity for delivery health until the compounding cost of debt begins to consume roadmap capacity.

Velocity Theater and the Cost of Technical Debt argues that most technical debt is not caused by careless engineers, but by sprint driven incentives that prioritize short term delivery over long term system health. In typical agile environments, refactoring and architectural improvements rarely win sprint capacity because they do not produce immediately visible output, which leads teams to make individually rational shortcuts that compound into systemic friction over time. While metrics such as burndown charts and velocity suggest healthy delivery, early warning signs like rising estimates, aging pull requests, and repeatedly reopened tickets signal accumulating debt beneath the surface. AI coding tools further amplify whatever practices already exist, accelerating both quality and debt depending on the team’s foundations. The solution is not simply paying down debt later, but redesigning processes to make debt visible, protect refactoring capacity, and coordinate action on delivery signals before compounding costs undermine the roadmap.

Unclear code ownership is one of the most common and least visible causes of delivery delays, especially for PMs who are accountable for shipping but lack authority over reviews and handoffs. Naming assignees on tickets or reviewers on PRs creates responsibility, not ownership of outcomes, which is why work quietly stalls between steps like review, integration, and cross-team dependencies. Research consistently shows that weak ownership leads to slower reviews, higher defect rates, and longer cycle times, while clear ownership enables faster decisions and smoother delivery. The teams that ship reliably treat ownership as living infrastructure, enforced through mechanisms like CODEOWNERS, branch protection, and a single accountable owner watching end-to-end progress, rather than leaving PMs to manually chase status.

Most delivery failures aren’t caused by people avoiding work, but by confusing responsibility with accountability. Responsibility assigns tasks, while accountability owns the outcome and acts when work stalls, especially at handoffs and dependencies. Modern delivery tools track who is assigned work but rarely surface when progress breaks down, leaving leaders to manually reconstruct what happened. Teams that scale successfully build systems that detect stalled work early, trigger direct follow-up, and escalate issues before drift turns into missed delivery.

Engineering headcount is often justified by intuition rather than data, even though it is one of the largest costs in a software organization. The real challenge is the gap between how engineering thinks about capacity and how finance evaluates cost, which leads to delayed hires, burnout, and missed delivery commitments. Effective headcount planning ties hiring needs to delivery outcomes using real throughput, cycle time, and overhead instead of idealized estimates. Without connected delivery data, teams risk hiring to fix coordination problems rather than addressing the friction that is actually slowing them down.

Jira was meant to track work, but as teams scale it often becomes a fragile reporting layer that requires constant maintenance and manual intervention. Over-customized workflows, brittle automations, and sprawling integrations create a coordination tax that pulls engineering leaders back into the weeds. The core problem is that Jira reflects what gets updated, not what is actually happening in delivery, making it a lagging and unreliable signal for flow health. High-performing teams keep Jira simple and rely on flow metrics and real-time execution signals to surface stalls before leadership has to chase them manually.

Technical debt isn’t a future problem. It’s already slowing teams down through unreliable estimates, longer reviews, and constant friction that compounds every sprint. The real issue isn’t awareness but communication: teams feel the drag but lack the language and signals to justify action. This gap lets neglect masquerade as “working code,” quietly eroding delivery speed and predictability. The cost is paid daily, not later, in lost time, stalled momentum, and burned-out engineers.

Daily standups did not fail because teams stopped caring. They failed because software delivery outgrew a coordination model built for visible, physical work. Self-reported updates cannot surface slow drift early enough to protect roadmap confidence.

Developer productivity isn't a coding problem. It's a coordination problem. This piece breaks down where engineering time actually goes and what a proactive delivery system looks like in practice.

The PM doesn't spend the morning doing reconnaissance. They start the day knowing where friction exists and what needs a decision. Standups become decision forums instead of status updates. Roadmap confidence increases because problems surface earlier. The PM's time shifts from coordination to judgment.

AI tools for product and project managers have matured, but most still stop at visibility rather than execution. Traditional PM platforms use AI to speed up documentation and planning, while analytics tools surface delivery metrics and trends. A new category of AI-native tools is emerging to actively detect delivery issues, coordinate action, and reduce operational overhead allowing PMs to focus on strategy, prioritization, and stakeholder alignment instead of chasing work across systems.

DORA metrics are four research-backed measures that show how well software delivery actually works. Instead of tracking activity like story points or tickets closed, they focus on real outcomes: how often teams deploy, how long changes take to reach production, how frequently releases cause issues, and how quickly teams recover when things break. Together, these metrics balance speed and stability, helping engineering leaders spot bottlenecks, reduce risk, and improve delivery predictability without burning out their teams.

There are over 200 companies providing engineering intelligence tools - tools that analyze developer performance metrics in detail. The critical challenge? None of these tools actually Do any work - they provide great analytics, but they don't communicate with at-risk developers, they don't assign tasks, and they don't set up meetings. Diving deeper into a real life scenario highlights the difference.

There are many great engineering intelligence and analytics tools out there - but most suffer from the same problem. They are Reactive, not Proactive. An AI Project Manager should be proactive, jumping in to DO the work of asking for status, scheduling, and followups. This has only recently become possible as LLMs have progressed to reasoning models that can act at a higher success rate.

Traditional project management tools are fundamentally reactive, not proactive. As a result they've failed to solve a wide range of software team pain points, including context switching, estimation, communication, and more. Let's dive into the details on the pain points, why the status quo isn't working, and what is missing from the capabilities that exist today.

70% of projects still fail to meet their goals, even as PMs spend 60% of their time on coordination overhead - chasing updates, running meetings, and manually following up. This post explores the background of software project management, how it's failed, and how AI project management asks a different question: "Can we automate the project management coordination work itself?"

A candid look back at the “8-week sprints” at AT&T that exposed the illusion of productivity—and how DevHawk was born from the need to track real work, not just time.