AI Productivity or AI Debt? What Leaders Are Missing

-

AI adoption in engineering is nearly universal. According to the MIT Nandanda Center, 97 percent of technology leaders have integrated AI into backend systems. Yet two thirds of those organizations report no meaningful headcount savings. Instead, they are accumulating a technical debt burden estimated at 61 billion workdays to resolve.

This is not a tooling problem. It is a governance problem.

The Hidden Cost of AI-Generated Code

Research from Stanford’s Digital Economy Lab shows that AI-generated code is typically simpler, more repetitive, and less structurally diverse than human-written code. Over time, this produces large volumes of code that technically functions but lacks architectural clarity, intent, and long-term maintainability.

Traditional technical debt can be prioritized and refactored. AI-generated debt is harder to unwind because there is often no clear rationale behind design decisions. The result is software that works today but becomes increasingly fragile and expensive to change.

Security Risk and the Productivity Paradox

The security implications are immediate. Approximately 45 percent of AI-generated code contains at least one top-tier security vulnerability. At the same time, experienced engineers are not becoming faster. They are becoming slower.

Seasoned developers now spend an average of 11 hours per week correcting AI hallucinations, logic errors, and edge cases. Studies suggest this reduces senior engineer productivity by nearly 20 percent. Organizations are trading visible output for hidden rework and future backlog.

The Talent Pipeline Is Being Cut Off

From 2023 to 2025, entry-level engineering hiring dropped by roughly 50 percent across much of the industry. The justification is AI-driven productivity. The consequence is a broken talent pipeline.

Junior engineers are how organizations build future senior talent, transfer institutional knowledge, and maintain operational resilience. Reducing entry-level hiring while increasing system complexity creates long-term risk that cannot be offset by tooling alone.

Compounding the issue, the AI productivity narrative is increasingly used to suppress wages, even as organizations remain dependent on experienced human engineers to stabilize and secure their systems.

The AI-Washing Wake-Up Call

The Builder.ai scandal exposed the risks of believing marketing over operations. Marketed as an autonomous AI development platform, the company relied on more than 700 human engineers to perform tasks sold as automated. When funding ended, the system collapsed.

This was not a failure of AI. It was a failure of leadership oversight and a warning about AI-washing as a business strategy.

What Executives Should Do Now

AI can be a powerful accelerator when used responsibly. It becomes a liability when it is treated as a substitute for engineering discipline, talent development, and accountability.

Leaders should focus on a few fundamentals:

  • Treat AI-generated code as a draft, not a final product

  • Increase investment in code review, architecture, and documentation

  • Protect and rebuild entry-level hiring as a strategic asset

  • Measure productivity by system reliability and adaptability, not output volume

  • Align AI claims with operational reality, not investor narratives

The organizations that succeed will not be the ones that adopt AI the fastest. They will be the ones that integrate it without compromising security, talent, or long-term maintainability.

The cost of ignoring this is not theoretical. It is already accumulating, line by line, in production systems.

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more