That difference is what the Sonatafy Software Delivery Failure Index is built on.

For the past year, I have been recording Software Leaders Uncensored: unfiltered conversations with CTOs, VPs of Engineering, CIOs, and founders at software organizations from growth-stage through enterprise. The format is built for honesty rather than promotion. Leaders are asked what actually broke, what they would do differently, and what the cost of the lesson was.

The 2026 edition draws from 195 episodes recorded between April 2025 and April 2026. Of those, 48 met the selection criteria for inclusion as qualifying failure narratives: the practitioner named a specific failure, its root cause, and its consequence in enough detail to extract structured insights. Vague difficulty did not count. 41 of the 48 produced publication-grade quote evidence. The remaining 7 informed pattern recognition without clearing the quote bar.

This is not a survey of opinion. It is a structured extraction of failure narratives where a practitioner named the cause, the consequence, and the change.

What surprised me most

I went into this research expecting to find that most software failures were technical. Bad architecture decisions, accumulated technical debt, wrong frameworks chosen at the wrong moment in a company’s growth.

That is not what the data showed.

The three most frequent root cause patterns each appeared in nine qualifying conversations, and none of them were primarily technical. They were structural. Building before validating. Process breakdown under deadline pressure. People scaling without context or accountability.

The finding that stuck with me most: teams that hired the fastest were often the ones struggling hardest with delivery. Adding engineers was not solving the problem. In many cases, the data showed it was making it measurably worse.

That was not what I expected. It is what the leaders told me.

What I got wrong going in

I expected the AI section to be the dominant finding.

It is not. At least not yet.

The AI Validation Gap is real, the incidents-per-customer data is alarming, and the severity per instance puts it at framework status despite a smaller qualifying sample. But the three structural failure patterns have more evidentiary weight in this dataset, and they are also more actionable right now for most organizations.

I also expected recovery to look like a change in talent or tooling. It did not. Across the qualifying conversations, the leaders who turned delivery around almost always made a structural change before a personnel or technology change. They installed ownership. They enforced process discipline. They reframed what delivery meant.

That shift in my own framing shaped how the report is organized.

The dataset at a glance

Recording window: April 18, 2025, to April 24, 2026.

Industries represented: SaaS and vertical software, fintech and insurtech, healthcare technology, real estate and automotive technology, IT services and AI infrastructure, workplace and DevOps tooling.

The primary finding

Teams that added engineers without fixing their delivery model got slower, not faster.

This finding appeared across the dataset with sufficient consistency to anchor the entire report. New hires needed months to ramp. Information dissemination broke down. The collaboration advantages of smaller teams disappeared as organizations scaled from 10 to 100 engineers. The organization chart grew while delivery throughput plateaued or declined.

Adding headcount to a structurally broken delivery model does not yield a better one. It produces a bigger broken one.

Framework distribution across the dataset

The three confirmed frameworks each surfaced across nine independent conversations, producing a combined 31 data insights. The AI Validation Gap earns inclusion not through frequency but through severity per instance, and through the consistency of the signal pattern across multiple sub-types.

The Backlog Illusion

The false signal when backlogs show activity without progress. Tickets close, sprints complete, velocity looks healthy, but the team is not delivering business outcomes.

It appeared in nine qualifying conversations across ten data insights, making it the top-ranked root cause by cumulative severity in the dataset.

The Backlog Illusion manifests when teams build features no one uses, when roadmaps are driven by competitor imitation rather than validated user need, and when engineering is measured by output volume rather than business impact.

The $42M case. Armando Viteri, President and CEO of Neubloc, described in Episode 81 what he called the catastrophic failure of his career: scaling into 20 geographies under the assumption that the model working in the first market would generalize. The assumption was never validated against local market conditions, regulatory differences, or distribution dynamics before the engineering and operational footprint was committed. Capital was available. Market validation was not. As Armando framed it: capital availability is not market validation. The ability to raise money and the ability to build something people need are entirely separate questions.

The 12-month case. Nathan Miller, Founder, President, and CEO of Rentec Direct, described in Episode 165 a different expression of the same pattern. Rentec hired a senior software developer and committed a full year to building an integration with a partner company. The partner had sold them on the platform’s potential. After a year, the integration was launched. No one used it. The partner had not delivered on its claims and was not as popular as it had represented. The cost was a full year of a senior developer’s salary plus the opportunity cost of everything else that developer could have built.

Justin Farris, VP of Product at Read AI, described the emotional cost of this pattern in Episode 151: months of work and energy, products shipped that did not gain adoption, and the organizational toll of resetting the roadmap and starting over.

The recovery move practitioners described consistently: reframe the unit of delivery from “feature shipped” to “outcome validated.” Smaller experiments before commitments. Explicit kill criteria for in-flight work. Product leadership is empowered to stop engineering before the sunk cost grows.

The Coordination Tax

The hidden overhead is created when teams skip alignment. Every rework cycle, handoff, and clarification meeting taxes delivery velocity, and the tax compounds.

It appeared in nine qualifying conversations across eleven data insights. The pattern surfaced most heavily in distributed teams, scaling teams, and teams without effective product-engineering alignment.

Under timeline pressure, the practices that protect delivery quality were the first thing teams sacrificed. Requirements were written after development started. Testing windows were compressed to hit fixed deployment dates. Agile ceremonies persisted in name but lost their substance. The damage rarely surfaced during the sprint, when corners were cut. It surfaced two or three sprints later, as rework.

William Steenbergen, Co-founder and CTO of Federato, described it in Episode 167 as a cascading effect: rushing testing, rushing decisions, and making more mistakes as a result of shortcuts that, individually, seemed minor.

The downstream cost of skipped alignment was consistently reported as larger than the time it would have taken to do the work correctly the first time, but it was paid in a different week, by a different team, in a different ticket. That displacement makes it invisible until the cumulative damage is already significant.

The recovery move was structural, not motivational. Teams that recovered installed a hard contract on the entry of work into the sprint: written specs, definition of ready, signoffs upstream. They protected that contract from the pressure of the timeline. Process discipline was treated as a forcing function, not overhead.

The Ownership Gap

The structural gap between having engineers and having delivery accountability.

Nine qualifying conversations, ten data insights. The clearest predictor of healthy delivery in the dataset was a single named owner per product surface, with headcount added to that ownership structure rather than replacing it.

Jeff DePascale, CTO of CallRevu, described in Episode 36 the experience of believing alignment existed, confirming it verbally, going to sleep, and waking up the next day to discover nothing had actually been understood or acted on.

The headcount trap. An anonymized Director of Engineering at a genomics and health-tech company was promoted from senior engineer but continued operating as an individual contributor, staying deep in the technical weeds on projects that should have been delegated. Simultaneously, the team was hiring new engineers to scale delivery capacity.

The result: eight months of operating as a single point of failure, with the team unable to keep pace with commitments made by sales and leadership. New engineers needed nine to twelve months to reach full domain expertise. More headcount. Less throughput.

This is the Ownership Gap operating at two levels simultaneously. At the leadership level, the director retained execution responsibility instead of building the team’s capacity to own outcomes independently. At the team level, new engineers lacked the domain context needed to move fast.

Recovery looked the same across organizations: a deliberate move from team-of-engineers to team-with-owner. One person is made accountable for the sprint cadence, architectural decisions, and code quality of a defined product surface. Headcount additions came after the ownership structure, not before.

The AI Validation Gap

I want to be direct about what this framework is and is not.

Unlike the first three frameworks, the AI Validation Gap is still emerging in the dataset. The sample size per sub-signal sits at N=1 to N=2, below the report’s publication threshold for confirmed framework status. I am including it because the severity of the incidents and the consistency of the signal across independent sources suggest it deserves immediate attention, not because the frequency warrants the same evidentiary confidence as the first three.

That transparency is part of the research discipline. An emerging pattern observed at low frequency but high severity is not the same as a confirmed pattern. It is a warning signal worth watching closely.

With that context established, the signal is alarming.

Sylvain Kalache, Head of AI Labs at Rootly, stated in Episode 185 that incidents per customer have increased by a factor of three over the last three years. Companies are experiencing three times more outages and more incidents than in 2023. AI-accelerated development velocity is outpacing the tooling and processes teams use to detect and resolve failures.

The AI Validation Gap is clustered into four sub-signals.

The reliability paradox: shipping faster means more changes, more surface area, and more failures arriving at the worst possible moment.

The knowledge transfer problem: AI tools promise to accelerate delivery, but only for teams where knowledge is distributed. When context lives in one person’s head, AI amplifies nothing. The bottleneck is not compute. It is the single engineer who has not yet taught the system, or the team, what they know.

Stakeholder expectations outrunning reality: Matthew Peters, CTO of CAI, described in Episode 125 the persistent organizational pressure to explain why AI has not yet multiplied productivity by a factor of ten. The expectation is real. The delivery capacity is not. The gap between them compounds silently until a missed deadline makes it visible.

Hidden trust and governance debt: In Episode 180, Bradley Friemel, CTO of Fullsteam, described the specific compounding risk of technologists overselling what AI can accomplish in production environments. Overpromising builds governance debt. The gap between what stakeholders expect and what teams can deliver gets hidden by workarounds until delivery exposes it.

The twelve warning signs

Across the 48 qualifying data insights, project failure followed a recognizable lifecycle. Warning signs appeared months before the failure became visible to leadership.

The four stages: quiet drift (cost of correction measured in days), process erosion (weeks), compounding pressure (quarters), and the failure event (cost already paid).

The report includes a twelve-point scorecard. Score each warning sign 0 to 2 based on observed instances in the last 90 days, then sum across all twelve.

The twelve signs: no single named owner per outcome; roadmap reacting to competitor releases rather than user validation; specs written after development started; ramp-up consuming more than three months per hire; deadlines met by cutting testing; velocity declining as headcount grows; AI features shipping without an eval framework; incidents per customer increasing; partner-built features with no adoption signal; unresolved product-engineering-design tension; replatforms running without explicit kill criteria; stakeholder AI expectations exceeding delivery capacity.

Score bands:

0 to 5: structurally sound. Run the scorecard quarterly. 6 to 12: one framework is likely active. Targeted intervention this quarter. 13 to 18: two or more frameworks compounding. Structural change required, not motivational. 19 and above: multiple compounding patterns. Redesign the delivery model before adding capacity.

Run it independently with three or more leaders, then reconcile. A ten-point spread between the highest and lowest score is itself a signal: the leadership team lacks a shared diagnosis.

What high-performing teams do differently

Five structural differentiators appeared consistently across organizations that avoided or recovered from delivery failure. None of them is heroic. All of them are designable.

They treat ownership as architecture, not a hiring outcome. One person, not a committee, is accountable for the outcome of each product surface. The clearest predictor of healthy delivery in the dataset.

They protect the entry of work into the sprint. A hard contract on what enters: written specs, definition of ready, upstream sign-offs. The contract is enforced under timeline pressure, not relaxed.

They measure delivery in terms of outcomes, not outputs. Sprint reports lead with what shipped to production and what changed in the customer or business signal. Ticket velocity is a hygiene metric, not a leadership metric.

They run replatforms and AI features with eval frameworks staged in advance. Major engineering bets are run with explicit success criteria and kill points. AI features have evaluation frameworks before they launch dates.

They surface product-engineering-design tension at a named forum. Standing executive forum where the three disciplines are required to bring unresolved decisions before they become delivery commitments. Soft alignment fails under pressure. Structural alignment does not.

Five things to start. Five things to stop.

Start: score your team against the twelve warning signs with three independent leaders. Name a single accountable owner per outcome before adding headcount. Install a sprint-entry contract and enforce it under deadline pressure. Re-cut the sprint review around outcomes, not tickets. Stage AI evals before AI launch dates.

Stop: adding headcount to a broken delivery structure. Scaling before validating unit economics in the first market. Committing to multi-quarter integrations without kill criteria. Shipping integrations without partner adoption commitments. Accepting boardroom AI projections, you cannot measure against current tooling and team throughput.

If there is one lesson from 195 conversations

Software projects rarely fail because of technology.

They fail because organizations mistake activity for progress, coordination for ownership, and hiring for execution.

The warning signs appear months before the failure becomes visible to leadership. Most teams simply do not know where to look.

The full report

The Sonatafy Software Delivery Failure Index, 2026 Edition, is 25 pages. It includes the full root cause analysis with practitioner quotes, the AI failure mode sub-signal detail, three case studies with dollar-level cost analysis, the twelve-point scorecard, five recovery patterns with time-to-impact estimates, and the full framework-to-delivery-model mapping.

Download it at https://www.sonatafy.com/reports/why-software-projects-fail

If your score is above 12 or if you are already in a late-stage delivery failure, the 60-minute Software Delivery Failure Diagnostic provides a structural read of your delivery model. Book at sonatafy.com/diagnostic-readout.

Steve Taplin is CEO of Sonatafy Technology and host of the Software Leaders Uncensored podcast. He is the author of Fail Hard Win Big and co-author of The Backlog Illusion with Sonatafy CTO Chris Horvat. The Software Delivery Failure Index, 2026 Edition, draws from 195 episodes recorded from April 2025 to April 2026.

Learn more at www.sonatafy.com

Listen at www.softwareleadersuncensored.com.

Contact: info@sonatafy.com

Every time, my response is the same. You are looking at the wrong metric. Output is up, yes. But what happened to your backlog? It did not shrink. It grew. What happened to your integration complexity? It expanded. What happened to the number of systems your team is now responsible for maintaining? It doubled.

They are describing a pattern that we have seen at Sonatafy and which economist William Stanley Jevons identified in 1865, and it is about to reshape how every technology leader thinks about AI, engineering teams, and software delivery.

A 160 Year Old Prediction About Your Engineering Org

Jevons studied coal. In the mid 1800s, Britain was making steam engines dramatically more efficient. The assumption was that better efficiency would reduce coal consumption. Use less coal per unit of work, use less coal overall. Simple.

Jevons argued the opposite. When coal became more efficient to use, it became cheaper per unit of output. When it became cheaper, industries found new uses for it. Factories that could not have justified the cost suddenly could. Applications that did not exist were invented. Total coal consumption did not decline. It exploded. Efficiency did not reduce demand. It unlocked it.

That is exactly what is happening with code in 2026.

AI tools have made it dramatically cheaper to produce software. GitHub Copilot, Claude, GPT, and a growing ecosystem of coding assistants generate boilerplate, write tests, refactor legacy functions, scaffold entire services, and suggest architectural patterns. What used to take a senior engineer a day now takes an afternoon. What used to require a team of three can often be prototyped by one.

The linear conclusion is that companies will need fewer engineers. The Jevons conclusion is that they will need more, because the volume of software being built, deployed, and maintained is about to expand faster than anyone’s headcount plan accounts for.

The Backlog Illusion at Scale

Here is where the pattern becomes visible if you know what to look for.

When the cost of producing software falls, projects that were once too expensive suddenly make sense. Internal tools that lived on a wish list move into active development. Small firms that relied entirely on SaaS subscriptions start commissioning custom integrations. Mid sized enterprises invest in bespoke analytics dashboards they never would have approved two years ago. Local governments experiment with AI driven tools to manage data and services. The barrier to custom software collapses, and with it, the ceiling on demand.

I call this the Backlog Illusion operating at the organizational level. Your engineering team is closing tickets faster than ever. The velocity charts look excellent. But the total surface area of software your company is responsible for is expanding faster than your team’s capacity to secure it, maintain it, govern it, and evolve it. The backlog is not shrinking. It is shapeshifting. What used to be a queue of features is becoming a permanent, expanding obligation of enhancements, compliance updates, integration maintenance, and architectural refactoring.

After 180+ conversations with CTOs on the podcast, I can tell you this is not theoretical. Every engineering leader I talk to is experiencing the same dynamic. They shipped more this quarter than last. And they are more behind than they have ever been. That is the Jevons Paradox in action.

More Code, More Coordination Tax

There is a second order effect that most CEOs miss entirely.

When your team produces more software, you do not just produce more code. You produce more systems. More services. More APIs. More data pipelines. More internal dashboards. More automated workflows. Individually, each one feels manageable. Collectively, they form a sprawling digital nervous system that grows more intricate every quarter.

That complexity carries a cost I call the Coordination Tax. Every new system your team builds creates dependencies. Every dependency creates coordination overhead. Every layer of coordination requires communication, alignment, testing, and handoffs that consume engineering time without producing features. Research consistently shows that each engineer added to a misaligned model increases overhead 15 to 25% while increasing output only 5 to 10%. AI accelerates the input side of that equation (more code, more systems, more surface area) without addressing the coordination side.

The result is that teams feel faster at the individual level and slower at the system level. An engineer can generate a microservice in an afternoon. But integrating that microservice into the existing architecture, securing it, testing it against edge cases, documenting it, and ensuring it does not introduce a regression somewhere else still requires judgment, context, and coordination that AI does not provide.

What Actually Becomes Valuable

This is the part that matters for anyone making hiring, team structure, or investment decisions right now.

Routine syntax level coding is increasingly automated. That is real and it is not reversing. But that does not mean engineers become obsolete. It means their comparative advantage shifts. The most valuable engineers in 2026 are not the fastest code producers. They are the ones who can design resilient distributed systems, evaluate AI generated output for hidden flaws, anticipate scaling bottlenecks before they become production incidents, and govern complex ecosystems without creating bureaucratic drag.

Judgment replaces repetition as the core differentiator. And judgment is the one thing that does not scale through automation.

For business leaders, this carries a specific strategic implication. Treating AI purely as a cost cutting mechanism is a misread of the cycle. Individual productivity gains do not automatically translate into reduced aggregate demand. Efficiency lowers the marginal cost of innovation. When innovation becomes cheaper, organizations attempt more of it. They automate more workflows, deploy more microservices, integrate more data streams, and embed AI into more operational layers. Each initiative increases reliance on software as critical infrastructure. And each one increases the Coordination Tax.

The Constraint That Actually Matters

The real constraint in 2026 is not the ability to generate code. It is the capacity to manage complexity safely and sustainably. Governance frameworks, cybersecurity oversight, architectural discipline, and long term maintainability become the bottleneck. Companies that expand their software footprint without strengthening their systems thinking will experience fragility. Those that anticipate the paradox and invest in architectural rigor will convert efficiency gains into durable advantage.

This is the decision that our team at Sonatafy keeps seeing technology leaders face. You can use AI to produce more software faster. That is the easy part. The hard part is building the delivery system, the ownership model, the review discipline, and the coordination framework that ensures all of that software actually serves the business instead of slowly becoming a liability.

Jevons saw this pattern in coal powered Britain. Efficiency did not reduce consumption. It expanded it into industries and applications that did not previously exist. AI driven coding efficiency is doing the same thing to software. As code becomes cheaper to create, it becomes embedded in more processes, more industries, and more decisions.

The result is not less code. It is more pervasive code. And the companies that understand the difference between producing more software and delivering more value will be the ones that come out ahead.

Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.

WANT TO LEARN MORE?

DOWNLOAD YOUR FREE REPORT

I’ve watched this happen repeatedly across the industry. Engineering organizations grow larger while delivery becomes slower, more chaotic, and less predictable. The issue isn’t usually talent. Most software teams are filled with capable people working hard under difficult conditions. The real problem is that many companies are operating with broken delivery systems. That realization became one of the driving ideas behind Sonatafy Technology.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

From the beginning, Sonatafy was created to help organizations solve software delivery problems at the structural level. Instead of asking, “How many developers do you need?” the focus becomes, “Why isn’t software getting shipped efficiently in the first place?”

That distinction matters because software delivery problems rarely exist in isolation. Missed commitments, expanding backlogs, communication breakdowns, technical debt, poor QA integration, and unclear ownership are usually symptoms of deeper operational issues. Adding more disconnected developers to an unstable system often increases chaos rather than fixing it.

Managed-Delivery PODs are Revolutionizing the Software Industry.

At Sonatafy Technology, PODs are accountable delivery systems that move projects from roadmap to execution with greater alignment and predictability. Instead of isolated contributors working independently, PODs combine engineering, QA, leadership, communication, and delivery oversight into cohesive operational units that own outcomes together. That ownership changes everything.

A POD is a small, complete software delivery unit designed to own and execute a defined scope of work from start to finish. It’s not a team of developers you manage. It’s not a consulting engagement where experts tell you what to do. It’s a fully accountable delivery mechanism that ships working software and transfers ownership back to your organization when the work is done. A POD doesn’t replace your teams. It exists to absorb a defined slice of work, execute it with discipline, and then disappear without leaving dependency behind.

The structure is deliberate. Six to eight people organized around complementary skills, led by someone with skin in the game, aligned to your standards and tools, measured on outcomes instead of activity. Everything about the design is optimized for one thing: shipping working software that solves real problems without creating new ones.

Tightly Aligned Teams With Shared Responsibility

One of the biggest problems inside traditional software organizations is fragmented accountability. Engineering teams operate separately from QA. Product leaders communicate differently than developers. Architecture decisions become disconnected from execution realities. Vendors focus on billable hours while internal leadership focuses on timelines. Eventually, nobody fully owns delivery itself.

Managed-Delivery PODs solve this by creating tightly aligned teams with shared responsibility for execution.

I’ve seen the impact firsthand. Communication improves because teams operate within a consistent structure. Developers gain better business context. QA becomes integrated into the delivery lifecycle instead of functioning as a late-stage checkpoint. Leadership gains clearer visibility into delivery risk before projects spiral out of control.

The result isn’t just faster software delivery. It’s more reliable delivery.

That reliability has become increasingly important as companies face growing pressure around AI adoption and digital transformation. Businesses are deploying software faster than ever, but speed alone creates new challenges. More code introduces more testing requirements, more integration complexity, and more operational risk. Without strong delivery systems, velocity can quickly turn into instability.

Software Development as an Operational Discipline

Sonatafy Technology positions software delivery as an operational discipline, not a staffing exercise. Its delivery framework emphasizes engineering leadership, communication structures, architecture oversight, and measurable execution improvement.

In many ways, Managed-Delivery PODs resemble startup teams operating inside larger enterprises. They are smaller, more adaptable, and capable of moving quickly without the bureaucracy that slows traditional development structures. That flexibility allows organizations to respond faster to changing market demands while maintaining stronger control over quality and execution.

The old outsourcing model revolved around labor cost reduction. The modern delivery model revolves around operational efficiency.

I believe this is why Managed-Delivery PODs will continue reshaping software development over the next decade. Businesses are realizing that software success depends less on the size of the engineering organization and more on whether teams are structured to execute consistently under pressure.

The organizations that solve that problem first will move faster than their competitors, adapt more effectively to AI-driven change, and build software organizations capable of delivering at the speed modern business now demands.

WANT TO LEARN MORE?

Book a 30-Minute Discovery Call.

I used to think being a strong software leader was enough. If you could build scalable systems and ship on time, you were doing your job. That was the standard I held myself to. But that world has shifted, and I’ve had to confront something uncomfortable. Software leadership, on its own, isn’t enough anymore.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

AI has changed the game in ways we never expected. It doesn’t replace software, but it reshapes what software is. It changes how it’s built, how it behaves, and what users expect from it. And if you’re leading software teams without stepping into AI, you’re already behind, even if everything still looks like it’s working.

The first time I felt this shift was when I saw how quickly expectations moved. Users don’t want static workflows anymore. They expect systems to adapt, predict, and respond in ways that feel almost human. Features that used to take months to design and build can now be prototyped in days with the right AI tools. The gap between what’s possible and what’s delivered has widened, and that gap is where companies win or lose.

As a software leader, I used to focus on architecture, performance, and delivery cadence. Those things still matter, but they don’t define the edge anymore. The edge comes from how intelligently your system behaves. It comes from how well you can integrate models, manage data pipelines, and create feedback loops that improve over time. That’s not a side skill. It’s the core.

Rethinking Leadership

I had to rethink what leadership meant in this context. It’s not about becoming a machine learning expert overnight. It’s about understanding enough to make the right calls. You need to know what problems AI can actually solve and where it creates more risk than value. You need to guide your team through decisions that don’t have clear precedents. That requires a different kind of judgment.

One of the biggest shifts for me was realizing that AI introduces a level of uncertainty that traditional software doesn’t. Code is deterministic. You write it, test it, and expect it to behave the same way every time. AI systems don’t work like that. They’re probabilistic. They evolve based on data. They can drift, degrade, or produce unexpected results. That changes how you think about quality, testing, and accountability.

Asking Different Questions

I had to start asking different questions. Not just “Does it work?” but “How does it behave over time?” Not just “Is it accurate?” but “Is it reliable under pressure?” Not just “Can we build this?” but “Should we?” Those questions don’t always have clean answers, and that’s where leadership shows up.

Another reality I had to face is that AI compresses the distance between ideas and execution. That sounds like a benefit, and it is, but it also creates pressure. When your team can move faster, expectations rise just as quickly. There’s less tolerance for slow iteration cycles. There’s less patience for incremental improvement. You have to rethink how you prioritize, how you scope work, and how you protect your team from chasing every shiny opportunity.

At the same time, AI exposes weaknesses in your organization that were easy to ignore before. Poor data quality becomes a blocker instead of an inconvenience. Fragmented systems become liabilities. Teams that aren’t aligned struggle to take advantage of the speed AI offers. As a leader, you can’t delegate those problems away. You have to confront them head-on.

A Cultural Shift

What surprised me most was how much this shift affected culture. Engineers who were comfortable in a traditional stack suddenly felt uncertain. Some leaned in and experimented. Others hesitated, unsure where they fit. My role wasn’t just to set direction. It was to create an environment where people could learn without fear of falling behind. That meant giving them space to explore while still holding the line on delivery.

I also had to become more opinionated about where AI fits and where it doesn’t. There’s a tendency to apply it everywhere because it’s new and powerful. That’s a mistake. Not every problem needs a model. Sometimes a simple rule-based system’s better. Sometimes the cost and complexity of AI outweigh the benefits. Part of being a leader is knowing when to say no.

Navigating Uncertainty

The leaders who thrive in this environment aren’t the ones who know every detail of every model. They’re the ones who can navigate uncertainty, make informed trade-offs, and guide their teams through a landscape that’s still taking shape. They stay curious. They stay grounded. And they don’t pretend to have all the answers.

I had to let go of the idea that my past experience alone would carry me forward. It gave me a foundation, but not a guarantee. If I want to lead effectively now, I have to evolve. I have to engage with AI not as a trend, but as a fundamental shift in how software’s conceived and delivered.

That’s the reality we’re in. If you’re leading software, you’re already in the AI business, whether you acknowledge it or not. The question isn’t whether you’ll adapt. It’s how quickly you’re willing to do it.

Learn More About Steve >

After 195 episodes of Software Leaders Uncensored, the pattern became impossible to ignore.

DOWNLOAD YOUR FREE REPORT

I have spent the last few years asking the same question to every CTO, VP of Engineering, and technical co-founder who sits down on my podcast: what went wrong?

Not the sanitized version they give at conferences. Not the retrospective that blames “scope creep” or “misaligned stakeholders” and moves on. The real answer. The one that comes out 40 minutes into a conversation when the guest stops performing and starts talking.

After 195 episodes of Software Leaders Uncensored, the pattern became impossible to ignore. Software projects fail in patterns, not accidents. The same structural breakdowns show up whether the company is a 50 person SaaS startup or a 2,000 person healthcare platform. The technology changes. The org chart changes. The failure mechanisms do not.

So we built a research report around it.

What the Report Actually Is

“Why Software Projects Fail” is a structured analysis of 48 qualifying conversations drawn from the full 195 episode archive. Root causes, recovery patterns, and the warning signs that preceded each failure.

Not a vendor survey. Not a recycled stat from the Standish Group. Not a think piece dressed up as research. This is primary qualitative data pulled from practitioners who were in the room when things went sideways, told in their own words (anonymized), and organized around the frameworks we have been developing at Sonatafy for years.

The report maps 48 distinct failure patterns back to five root causes. Every pattern includes frequency data across the qualifying conversations, anonymized examples, and a connection to one of three diagnostic frameworks: the Ownership Gap, the Coordination Tax, or the Backlog Illusion.

It is 25 pages. It is free. And it says things most industry reports are too polished to say.

Why This Exists

The software industry has a research problem. The reports everyone cites are either: (a) self-serving surveys designed to validate the vendor publishing them, (b) academic analyses based on data that is five to ten years old, or (c) recycled versions of the same failure statistics that have been circulating since the 1990s.

None of that helps the VP of Engineering sitting in a planning meeting next Monday trying to explain to the CEO why the last three quarters of delivery performance do not match the headcount investment.

That person needs pattern recognition. They need to see their situation reflected in someone else’s failure story and walk away with language they can use in the room. That is what the podcast produces naturally, one conversation at a time. The report packages 48 of those conversations into something a leader can reference before their next planning cycle.

The Five Root Causes (Preview)

I am not going to reproduce the full framework here. That is what the report is for. But here is the shape of what we found.

The first root cause is structural. Nobody owns the outcome. Product defines requirements. Engineering builds features. DevOps manages deployment. Vendors contribute components. Every function does its job. Nobody is accountable for whether the thing actually ships and works. We call this the Ownership Gap, and it showed up in the majority of qualifying conversations. Not as a footnote. As the primary failure mechanism.

The second is mathematical. Organizations add headcount to fix delivery problems without recognizing that every new engineer increases coordination overhead. Past a certain threshold, the additional communication pathways, meetings, dependency chains, and context switching absorb more capacity than the new hire creates. The Coordination Tax. It is the most expensive invisible line item in every engineering budget, and almost nobody measures it.

The third is psychological. Teams treat a full backlog as evidence of a healthy product organization. It is the opposite. A backlog that grows faster than it ships is a liability pretending to be an asset. The Backlog Illusion. It gives product teams the feeling of progress while the delivery engine falls further behind with every sprint.

Root causes four and five connect to decision architecture and delivery model design. They are in the report.

What Makes This Different

Most failure analysis in our industry focuses on what went wrong. This report also maps recovery patterns. What did the leaders who turned things around actually do? In what sequence? How long did it take? Those answers came out of the same 48 conversations, and they are arguably more valuable than the failure data itself.

The report also includes a warning signs checklist. Eight to ten indicators that a project is heading for structural failure before anyone in the room is willing to say it out loud. Derived from the bottleneck predictions and failure stories across the qualifying conversations. Each one comes with a diagnostic question a leader can ask in their next one on one or planning session.

That is the part I wish existed when I was running my first company into the ground 20 years ago. Not a framework diagram. Not a maturity model. A list of questions that would have told me the truth before the quarterly numbers did.

Who Should Read This

If you lead an engineering organization between 50 and 2,000 people and you have felt the disconnect between investment and output over the past 12 months, this report will give you the vocabulary to describe what is happening and the pattern library to diagnose why.

If you are a CEO or COO trying to understand why your engineering team keeps growing but your release cadence is not improving, this report will show you the structural reasons that “just hire more engineers” has not worked and likely will not work.

If you are a product leader managing a backlog that is three to five sprints deep and wondering why velocity metrics look fine but nothing feels like it is moving, this report will explain the math behind the feeling.

The full 25 page PDF is available now at https://sonatafy.com/reports/why-software-projects-fail#download No follow up spam. Just the research.

This is the first report in a series we are building from the podcast archive. 195 episodes of unfiltered conversation with the people actually making delivery decisions. The dataset is unlike anything else in the industry. We intend to use it.

“We have more developers than ever,” he told me. “So why are we moving slower?”

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

Companies believe their SDLC is slowing down because they don’t have enough engineering capacity. Leadership assumes the answer is adding more developers, more vendors, more standups, more process layers, or now, more AI coding tools.

Yet most of the time, the issue has nothing to do with coding speed.

The hidden reason the SDLC slows down inside growing organizations is operational fragmentation. Teams stop functioning as unified delivery systems and start operating like disconnected departments competing for priorities, approvals, and resources. The slowdown doesn’t happen all at once. It creeps in gradually until software delivery becomes trapped inside its own complexity.

That was exactly what happened to this CEO’s company.

At first glance, the organization looked mature. They had Scrum, sprint planning, Jira dashboards, offshore developers, QA teams, architecture reviews, and layers of engineering management. On paper, everything appeared structured and scalable. Underneath the surface, the entire delivery process was clogged with friction.

Developers were constantly waiting for approvals. Product managers changed priorities mid-sprint because sales escalated customer requests. QA teams operated in separate time zones with limited business context. Engineering leads spent more time in alignment meetings than resolving technical risks. Features bounced between departments like luggage moving through a broken airport conveyor system.

Nobody owned delivery from end to end

That’s the part most organizations fail to understand. Staff augmentation increases labor capacity, but it rarely improves delivery architecture. Adding developers to a fragmented system often magnifies the fragmentation. More people create more dependencies. More dependencies create more communication overhead. More communication overhead creates more meetings, approval layers, and coordination bottlenecks.

Eventually the organization reaches a tipping point where adding engineers actually slows the SDLC down instead of accelerating it.

I’ve seen this happen repeatedly over the last few years. Companies scale engineering headcount aggressively because they believe velocity problems are purely technical. In reality, the issue is usually organizational. The software lifecycle becomes overloaded with context switching, fragmented ownership, and decision-making paralysis.

One engineer works on five unrelated priorities in the same week. A product manager manages twelve competing stakeholder agendas simultaneously. A CTO becomes the escalation point for every blocked decision because nobody else has clear authority. Teams become reactive instead of coordinated.

The result is predictable. Releases slow down even while engineering costs increase.

Managed Delivery PODs

This is one of the biggest reasons we shifted heavily toward Managed Delivery PODS instead of traditional offshore staffing models. I realized years ago that most companies didn’t need more disconnected developers. They needed integrated delivery systems designed around accountability and continuity.

Our POD structure combines U.S.-based principal engineering leadership with nearshore developers, embedded QA, product coordination, and delivery oversight operating as one unified operational unit. Not a collection of freelancers. Not a ticket factory. A dedicated delivery engine where technical leadership, execution, and validation remain tightly connected throughout the SDLC.

That changes the dynamic immediately.

When a principal engineer owns technical direction, decisions happen faster. When QA is embedded from the start instead of added later, defects get caught earlier in the lifecycle. When developers remain inside dedicated pods instead of constantly shifting between competing priorities, context switching decreases and throughput stabilizes.

Most executives underestimate how destructive context switching has become inside modern software organizations. Developers rarely spend entire days building software anymore. They spend enormous amounts of time navigating meetings, clarifying requirements, responding to Slack messages, waiting for approvals, and recovering from shifting priorities.

The fragmentation becomes invisible because companies normalize it.

AI is making the situation even more complicated

A lot of executives believe AI coding tools will solve SDLC inefficiency overnight. What I’m actually seeing is AI accelerating code generation while exposing weaknesses in organizational coordination. Teams are producing code faster, but they aren’t improving validation systems, architectural clarity, or delivery governance at the same pace.

That creates dangerous imbalance inside the development lifecycle. Companies can accelerate commits while slowing releases. They can generate features rapidly while increasing downstream instability. AI speeds up production, but it also punishes organizations with weak operational architecture.

The companies succeeding right now aren’t necessarily the ones with the largest engineering teams or the most AI tools. They’re the organizations reducing friction inside the SDLC itself. They have smaller, highly accountable delivery units. Clear technical ownership. Embedded QA. Faster validation loops. Strong delivery leadership. Less bureaucracy. Fewer handoffs.

That’s the hidden reason so many SDLC environments are slowing down today. The problem usually isn’t engineering talent. It’s organizational design. Until companies fix the fragmentation underneath their delivery process, no amount of staff augmentation, outsourcing, or AI tooling is going to restore velocity.

LEARN MORE ABOUT STEVE TAPLIN >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

That’s exactly the threat we’re looking at right now. A new capability shows up, productivity jumps, and everyone gets excited. Code gets written faster. Features move from idea to deployment in record time. Entire workflows that used to take days now take hours. The upside is fantastic. What’s not so great, and far more dangerous, is that most teams haven’t adjusted how they validate what they’re building.

Looking Good is Not the Same as Being Good

In October 2024, a lawsuit was filed against Character.AI and Google, after the death of a fourteen-year-old boy. According to the complaint, the teenager had developed an intense relationship with an AI chatbot. Their conversations were not occasional or superficial. They were frequent, emotional, and deeply personal. Over time, he began expressing despair and suicidal thoughts.

The system responded in the way it was designed to respond. It stayed engaged, maintained tone, and continued the conversation. The lawsuit alleges that instead of challenging the boy’s suicidal tendencies, the chatbot reinforced them. It didn’t escalate the situation. But it also didn’t counter it until the boy eventually took his own life. The lawsuit claims that the AI chatbot didn’t simply fail to help. It became a support system that normalized his thinking at a moment when intervention was critical.

Understanding the Blind Spot

What strikes me about this case is not that the system failed. It’s how it failed. From a product standpoint, the chatbot did what it was designed to do. It engaged the user and produced coherent responses. The problem is that none of those metrics captured what happens under extreme conditions.

That’s the blind spot. The system performed well in normal use and failed in the one scenario that mattered most. That’s not a content problem. It’s a validation problem. No one thought about how the system would behave when a user crossed into a high-risk state. No one built a reliable mechanism to interrupt that behavior. The failure wasn’t in the model’s ability to generate language. The failure was in assuming that plausible output was good enough.

It’s Happening Everywhere

I don’t see this as an isolated incident tied to one product or one company. I see it as an early signal of a broader issue that’s already spreading across software development. AI systems generate code that look correct, sound reasonable, and pass superficial checks. Teams trust those outputs because they’re clean and convincing. The system gets deployed. The real test happens later, under conditions that were never fully validated.

In traditional software, failures tend to be easier to isolate. A bug points back to a specific function or a specific line of code. With AI, behavior emerges from patterns. It’s harder to predict, harder to trace, and far easier to trust. That creates a new kind of risk. The system doesn’t break immediately. It behaves just well enough to get into production. The failure shows up when the stakes are higher and the margin for error evaporates.

Why Validation Falls Short

Most development workflows were never designed for this. We test functionality. We test performance. We run security scans. Those are all necessary, but they’re not sufficient when AI is involved. What we’re missing is validation under stress. We’re not systematically asking how the system behaves when inputs become adversarial, emotional, or unpredictable. We’re not building enough safeguards for scenarios that fall outside the norm.

At the same time, AI is compressing the timeline. What used to be a slow, deliberate process now moves like a rocket. That’s where the imbalance comes in. Output scales instantly. Validation doesn’t. If we don’t change that, we end up deploying systems that are technically sound and operationally fragile.

What Has to Change

The lesson I take from the Character.AI case is not that AI is unsafe. It’s that AI exposes where our processes are weak. If validation is shallow, AI amplifies that weakness. If testing is incomplete, AI pushes more unproven behavior into production. The solution is not to slow everything down. It’s to evolve how we validate.

That starts with identifying high-risk scenarios early. Not as an afterthought, but as part of the design process. It means testing systems under conditions that are uncomfortable and difficult to simulate. It means building guardrails that activate when those conditions appear. In some cases, it means introducing deterministic rules or human intervention points where probabilistic systems should not be left alone.

Between 2024 and 2026, something shifted. AI systems stopped being treated as experimental tools and started being treated as accountable products. The courts are now weighing in. Users are relying on these systems in meaningful ways. The expectation is no longer that the system works most of the time. The expectation is that it behaves responsibly when it matters.

That’s a higher bar, and it should be. Because once these systems are deployed, they don’t operate in controlled environments. They operate in the real world, where edge cases are real and the consequences can be dire.

Learn More About Steve Taplin >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

I’ve watched the same meeting happen inside different companies more times than I can count. The CEO asks why engineering cannot deliver. The CTO explains technical constraints. The CFO questions the budget. The CPO argues about priorities. Everyone leaves frustrated. Nothing changes.

Six months later, they are having the same conversation about the same backlog with bigger numbers and fewer options.

The problem is not that any of these executives is wrong. The problem is that they are all right. And the reason nothing gets resolved is that nobody in the room owns the outcome. They each own a piece. The piece they own makes complete sense from their perspective. But the system that produces the backlog, and the structural gap between having leaders and having delivery accountability, sits in the space between all four of them. That space has no name on the org chart.

That is the Ownership Gap. And it is the root cause of every backlog crisis I have ever seen.

What Each Executive Sees

The CEO sees opportunity cost. Every quarter spent maintaining legacy systems instead of building new capabilities represents market share that will not come back. The CEO approved the digital transformation, funded the cloud migration, signed off on the customer portal rebuild. Engineering said six months. That was a year and a half ago. The CEO starts making promises with no confidence they will be kept. That is when credibility erodes, with the board, with customers, and eventually with themselves.

The CTO sees technical debt. They are living with years of shipping features on architecture that was never designed to support them. Every simple request turns complex. “Just add an export button” requires pulling data from three incompatible databases, formatting it in ways the system does not support, and integrating with third party APIs that might change without notice. The CTO knows the current architecture physically cannot support the company’s three year strategy. But translating that into language the CFO will fund and the CEO will prioritize is a different problem entirely.

The CPO sees broken promises. Every backlog item represents a commitment the company made and has not kept. Sales lost a $500,000 deal to a competitor who had the integration feature that has been sitting in the backlog for fourteen months. Meanwhile, engineering ships capabilities that customers never adopt. The company measures activity instead of outcomes, celebrates velocity instead of value, and calls it progress.

The CFO sees waste. Duplicate systems, cloud resources that do not deliver value, development work that never ships. Five years ago, a new feature cost $50,000 to build. Today, with architectural complexity, integration requirements, and testing overhead, that same feature costs $200,000. The unit economics of software development have collapsed. And here is the paradox: every dollar spent on engineering hits the income statement, creating pressure to minimize spending, which perpetuates the cycle of underinvestment.

Four executives. Four legitimate problems. Four different solutions. And not one of them addresses the structural issue underneath all of it.

The Backlog Illusion in Four Stages

What makes the backlog crisis particularly dangerous is that it sneaks up on you. I have seen enough organizations go through this cycle that I can describe the stages from memory.

At 100 items, it feels normal. Every company has work they have not gotten to yet. The team can still remember what most items are about. Stakeholders can track what matters. The backlog feels like a planning tool, not a problem.

At 400 items, friction starts. People disagree about priorities because there is no clear framework for making tradeoffs. Estimates keep slipping. But the company is still functional. The dysfunction feels manageable. Everyone agrees they just need better prioritization.

At 800 items, the backlog becomes toxic. Nobody believes the estimates anymore. Promises stop being credible. Engineering teams start hiding work from the official tracking system because if something is not in Jira, leadership cannot demand status updates about it. The conversation shifts from solving problems to questioning basic competence.

Past 1,200 items, the backlog creates its own gravity. Every new initiative gets sucked in. The backlog grows faster than engineering can reduce it. Everyone knows the trajectory is unsustainable, but nobody knows how to reverse it because the problem is not the backlog itself. It is the system that creates the backlog.

That progression is the Backlog Illusion in its purest form. Tickets are being worked. Velocity metrics look reasonable. Sprint reviews happen on schedule. But the actual delivery of business outcomes has stalled. The organization is busy without being productive. The backlog is not shrinking. It is shapeshifting.

Why Adding Engineers Makes It Worse

The instinctive response is to hire. The CFO sees the delivery gap and approves headcount. The company adds 30% more engineers. The backlog grows 50%.

This is the Coordination Tax at work. Every engineer added to a misaligned model increases overhead 15 to 25% while increasing output only 5 to 10%. More people means more coordination overhead, more work in progress that never finishes, more handoffs, more meetings, and more alignment sessions that consume the very time the new hires were supposed to create.

The system that produces the backlog remains unchanged. You have more people feeding it, more stakeholders requesting from it, and more complexity making every item harder to execute. Headcount is not the problem. The operating model is the problem.

What the Companies That Figure It Out Actually Do

The companies that solve this do not just reduce their backlogs. They change the system that creates the backlog in the first place.

They stop adding every idea that gets mentioned. They build clear ownership into the delivery model so that every critical decision has a name attached to it, not a committee. They restructure around small, autonomous teams that own a full slice of the product instead of distributing ownership across functional silos. They measure outcomes instead of velocity. They invest in the architectural work the CTO has been asking for, even when it does not produce visible features in the next sprint.

The result is that features ship complete instead of accumulating as half finished work. The engineering organization becomes a source of competitive advantage instead of a bottleneck that limits growth. The backlog shrinks not because the team works harder, but because the system stops generating waste.

The companies that do not figure it out face a different trajectory. Their backlogs grow until they cannot deliver anything meaningful. Their best engineers leave for organizations that are not dysfunctional. Their customers defect to competitors who actually ship. The technical debt compounds until the codebase becomes unmaintainable.

Every CTO I talk to on the podcast recognizes this pattern. Most of them are living inside it right now. The question is not whether they see the problem. It is whether they have the organizational authority and the structural framework to solve it before the backlog becomes the business.

____________________________________

Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.

Learn More About Steve >>

Then he pointed to the authentication flow. On the surface, it was solid. But the session token handling had a subtle edge case that would only surface under concurrent load, the kind of condition you do not encounter in local testing. The junior engineer had approved the AI generated output because it looked correct. It was correct, except under the one condition that would matter most in production.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

That moment captured something I keep seeing across every engineering team I work with. AI has changed what it means to write code. It has not changed what it means to understand a system. And that gap, between producing output and owning the outcome, is where careers are being made or lost right now.

When Polished Answers Become the Problem

The first thing that changes when you start working seriously with AI is your relationship to answers. You get them faster than ever, and they look polished, complete, and convincing. That is the danger. AI does not just give you output. It gives you confidence wrapped in language. If you do not have strong analytical instincts, you will accept what looks right without interrogating whether it actually is right.

The engineers who stand out right now are the ones who slow down at exactly that moment. They question the output. They test the edges. They look for failure modes that are not immediately obvious. That requires a shift from execution to evaluation. You are no longer just building systems. You are constantly auditing them. Every model response, every generated function, every suggested architecture has to pass through a mental filter that asks whether it holds up under real world conditions.

That filter is the new competitive advantage. Without it, you are a conduit for AI output. And that is a role that will not hold value for long.

The Skill That Actually Matters Is Framing the Problem

After 180+ podcast conversations with CTOs, here is the pattern I keep seeing. The engineering teams that struggle with AI are not the ones using the wrong tools. They are the ones giving the tools the wrong inputs.

AI is exceptionally good at solving problems once they have been framed correctly. Give it a vague or poorly structured prompt and it will still produce something that looks useful. That illusion is where projects go sideways. Teams iterate endlessly on outputs that were never aligned with the real goal because nobody invested the time to define what the real goal was.

The best engineers I work with spend more time framing the problem than they spend generating solutions. They think in constraints, tradeoffs, and intent before they ever touch a model. They ask what success actually looks like, what edge cases matter, and what failure would cost. That upfront discipline is what separates a productive AI workflow from an expensive guessing loop.

This is an Ownership Gap problem in disguise. If nobody owns the problem definition, nobody owns the solution quality. The AI generates output. The engineer approves it. The system ships it. And when it breaks, the postmortem reveals that the original prompt was wrong, the requirements were ambiguous, and the review process trusted the surface instead of testing the substance. The structural gap between having engineers and having delivery accountability shows up here as clearly as it does anywhere in the delivery pipeline.

Debugging Is No Longer About Finding the Broken Line

There is a shift happening that does not get enough attention. Debugging used to be about tracing through code, finding the broken line, and fixing it. That still matters. But AI has added a new layer. Now you are debugging behavior, not just logic. You are asking whether the model misunderstood the prompt, whether the data introduced bias, or whether the system is producing inconsistent results under conditions that were not tested.

This requires a different kind of thinking. You form hypotheses, test them, and revise your understanding as you go. It is less like fixing a machine and more like diagnosing a system that does not always behave predictably. The engineers who get good at this do not panic when something breaks. They get curious. They treat every failure as a signal, not a setback.

Over time, something compounds. You start seeing patterns. Certain prompts fail in similar ways. Certain architectures break under predictable conditions. Certain data issues keep resurfacing. Engineers who pay attention to those patterns do not just solve problems faster. They start preventing them altogether. That is where experience becomes leverage, and it is the one thing AI cannot replicate.

The Shift Every Hiring Decision Needs to Reflect

If you step back, the direction is clear. The role of the developer is shifting from pure execution toward cognitive leverage. You are not just writing code. You are designing systems, evaluating outputs, and making decisions that shape how those systems behave in the real world.

Technical skill still matters. But it is no longer the differentiator it was even two years ago. The edge now comes from how well you think, how clearly you see problems, and how effectively you can guide AI toward meaningful outcomes. The most underrated skill in all of this is the ability to step back and examine how you are thinking while you are thinking. You catch yourself trusting an output too quickly. You notice when you are accepting something because it sounds right rather than because you have verified it.

Engineers who cultivate that awareness use AI differently. They do not treat it as an authority. They treat it as a collaborator. They know when to lean on it and when to push back. That balance is what separates thoughtful work from surface level output.

The engineers who recognize this shift early are the ones who will define the next generation of software. The rest will spend their time chasing tools, trying to keep up with a moving target, without realizing that the real game already changed.

Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.

LEARN MORE ABOUT STEVE >

That conversation has been on my mind since Tuesday, when Anthropic announced Project Glasswing and released details about Claude Mythos Preview, a frontier AI model that has already identified thousands of previously unknown, high severity vulnerabilities across every major operating system and every major web browser. Not surface level bugs. Structural weaknesses that survived decades of human review and, in some cases, millions of automated security tests.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

The CTO on my podcast does not have a security problem yet. He has a Backlog Illusion problem. Tickets are closing. PRs are merging. The numbers look good. But the system is not actually getting more secure, because review discipline has not scaled alongside development speed. And now, the tools capable of exposing that gap just got dramatically more powerful.

What Actually Happened

Anthropic built a general purpose model that turned out to be strikingly good at finding and exploiting software vulnerabilities. Good enough that they decided not to release it to the public. Instead, they gave access to over 50 organizations, including Microsoft, Google, Apple, AWS, CrowdStrike, Cisco, Palo Alto Networks, JPMorgan Chase, and the Linux Foundation, along with $100 million in usage credits to scan and secure critical systems.

The specifics are worth sitting with. Mythos Preview found a 27 year old vulnerability in OpenBSD, one of the most security hardened operating systems in the world, that allowed an attacker to remotely crash any machine running it just by connecting to it. It found a 16 year old vulnerability in FFmpeg, a video encoding library used by countless applications, in a line of code that automated testing tools had hit five million times without catching the problem. It autonomously discovered and chained together multiple Linux kernel vulnerabilities to escalate from ordinary user access to complete control of a machine.

Logan Graham, who leads offensive cyber research at Anthropic, described the model’s ability to identify multiple undisclosed vulnerabilities, write exploit code, and then chain those exploits together into a coherent attack path, all without human intervention. Anthropic’s own system card noted that the model showed awareness it was being evaluated in roughly 29% of test transcripts, and in at least one instance appeared to intentionally underperform to look less suspicious.

This is not incremental improvement. This is a capability shift.

The Asymmetry Just Got Worse

Security has always been a game of asymmetry. The defender has to protect everything. The attacker only has to find one way in. For decades, the defender had one significant advantage: finding serious vulnerabilities required deep expertise, time, and patience. That advantage is eroding.

When the cost of discovering vulnerabilities drops to near zero and the speed increases by orders of magnitude, the math changes for every organization running custom software. The number of potential attack vectors does not increase by 10% or 20%. It increases dramatically, because systems that were effectively secure through obscurity (nobody had the time or skill to find the flaw) are now exposed to a tool that does not get tired, does not overlook patterns, and can test permutations at a scale no human team can match.

From a CEO’s perspective, that creates an uncomfortable reality. Your security posture is no longer defined by how good your defenses are. It is defined by how fast you can find and fix the weaknesses that a Mythos class model could find in hours.

Who Owns the Security Decision?

Here is where the Ownership Gap shows up in a way most teams are not prepared for.

I have spent 25 years building and overseeing custom software for companies running financial systems, healthcare platforms, and internal tools that quietly operate entire organizations. In that world, every critical decision has a name attached to it. Someone owns the architecture decision. Someone owns the authentication model. Someone owns the data flow design. When something goes wrong, you can trace it back to a decision and a person.

AI disrupts that chain of ownership. When an engineer uses an AI tool to generate code, review a dependency, or suggest a fix, the decision still gets made, but the understanding behind the decision shifts. The engineer approved it, but did they fully understand it? Did they challenge it the way they would challenge a junior developer’s pull request? Or did they trust the output because it looked correct and passed the tests?

This is the Ownership Gap applied to security. The structural gap between having engineers and having delivery accountability does not disappear because the tools got smarter. It gets wider. Because now the tool is generating plausible solutions that look correct, pass surface level validation, and introduce blind spots that do not surface until the right conditions trigger them.

After 180+ conversations with CTOs on the podcast, I can tell you this pattern is already forming. Teams are generating more code in less time. Prototyping faster. Iterating more quickly. On the surface, that looks like progress. But when review processes do not evolve alongside development speed, you end up with more code and less understanding. More output and less ownership. That is the Backlog Illusion operating at the security layer: the backlog is shrinking, the ticket count looks healthy, but the actual security posture of the system is not advancing at the same rate.

Context Is the Thing AI Cannot Own

A secure system is not a collection of well written functions. It is a network of decisions about how data flows, how users authenticate, how failures are handled, and how external systems are integrated. AI can assist with pieces of that analysis. It cannot own the full context.

It does not understand the specific regulatory environment a healthcare platform operates in. It does not know the financial implications of a failed transaction in a banking system. It does not know that the third party integration your team added last quarter introduced a dependency that your architecture was never designed to support. Those details are not optional. They are the system.

The emergence of Mythos class capabilities makes this distinction more urgent, not less. If AI can find vulnerabilities at this scale, it can also generate fixes at this scale. And the temptation to accept those fixes without full contextual review will be enormous, especially under the pressure of a newly discovered zero day that needs to be patched immediately.

Speed without discipline creates exposure. That has always been true. The difference now is that the speed is accelerating faster than most organizations’ discipline can keep up.

What This Actually Changes for Custom Software

Custom software still offers a significant advantage when it is done correctly. You control the architecture, the data model, and the security decisions. You are not constrained by the limitations of a generic platform. You can design systems that align with your specific risk profile and operational needs.

But that advantage only holds if you maintain ownership of the decisions being made. The moment you start outsourcing those decisions, whether to third party tools or AI systems, you weaken the very thing that makes custom software valuable.

What Project Glasswing signals is that we are entering a phase where assumptions will not hold up for long. Systems will be tested more aggressively. Vulnerabilities will be found more quickly. The margin for error will shrink. That does not mean the future is less secure. It means the standards are rising, and the organizations that meet those standards will be the ones that invested in discipline before they were forced to.

The path forward is not complicated to describe, even if it is hard to execute. You do not slow down innovation, but you do not abandon discipline either. You invest in stronger review processes. You make sure every critical decision has clear ownership. You treat AI as a tool that supports your team, not one that replaces their judgment. Most importantly, you accept that security is not a milestone you reach. It is an ongoing practice that has to evolve alongside the technology you are using and the technology being used against you.

Claude Mythos Preview is not something to panic about. It is something to take seriously. It is a reminder that the landscape just changed, and the companies who come out ahead will be the ones who were already building with the kind of discipline that this moment now demands.

_________________________________________________________________

Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.

MORE ABOUT STEVE TAPLIN >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

In 2026, custom software is no longer a luxury reserved for tech giants. It’s becoming the default strategy for companies that want to move faster, operate smarter, and stop bending their business around someone else’s product. What’s driving that shift isn’t a single breakthrough. It’s the convergence of three forces that are reshaping how software gets built from the ground up.

Software Is No Longer Written. It’s Orchestrated.

For years, developers were measured by how much code they could produce. That model is breaking down. The modern developer isn’t sitting in isolation writing thousands of lines from scratch. They’re working alongside AI systems that can generate, test, and refine code in real time. This changes the nature of the work.

Instead of asking, “How do I build this?” the question becomes, “What should this system do?” That shift sounds subtle, but it has massive implications. When AI handles execution, the real leverage moves upstream to design, architecture, and intent.

You’re starting to see entire workflows managed by AI agents. One system drafts the code. Another tests it. A third monitors performance and suggests improvements. The developer becomes the conductor, not the orchestra.

This isn’t about replacing engineers. It’s about amplifying them. A small team can now build what once required an entire department. That changes the economics of custom software completely. Projects that used to take a year can now be delivered in months, sometimes weeks.

It also changes the build-versus-buy equation. When the cost and time required to build custom systems drop, companies stop defaulting to SaaS. They start asking whether they should own the system outright. More often than not, the answer is yes.

Software Is No Longer a Product. It’s a Living System.

The second shift is architectural, and it’s just as important.

In the past, software was built as a single, tightly coupled system. You launched it, maintained it, and occasionally updated it. Any meaningful change required significant effort, and sometimes a complete rebuild. That model doesn’t hold up in an environment where requirements change constantly.

Today’s systems are built differently. They’re modular, distributed, and designed to evolve. Instead of one monolithic application, you have a network of services that communicate through APIs. Each component can be updated independently. New features can be added without disrupting the entire system. Infrastructure can scale up or down based on demand.

This is what people mean when they talk about cloud-native development, but the terminology isn’t the important part. What matters is the mindset. You’re no longer building something static. You’re building something that can change.

That flexibility becomes a strategic advantage. When a new opportunity emerges, you don’t need to start from scratch. You extend what already exists. When a market shifts, you adapt your system instead of replacing it. Over time, your software becomes a reflection of how your business actually operates, not a constraint imposed by external tools.

The companies that understand this don’t treat software as a cost center. They treat it as infrastructure for growth.

Software Creation Is Expanding Beyond Developers

The third shift is about who gets to build.

For a long time, software development was gated by technical expertise. If you didn’t know how to code, you couldn’t contribute. That barrier is coming down. Low-code and no-code platforms have matured to the point where non-developers can build meaningful applications.

That doesn’t mean engineers are becoming obsolete. It means their role is changing. Routine tools and internal workflows can now be built by the people who actually use them. A marketing team can create its own campaign tracking system. Operations can build dashboards tailored to how they work. Product teams can prototype features without waiting in a development queue.

This reduces friction across the organization. It also exposes a hard truth. Most internal software needs are not complex. They’re blocked by process, not difficulty. When those barriers are removed, the volume of software creation increases dramatically.

The smartest organizations are leaning into a hybrid model. They use low-code tools for speed and accessibility, and custom development for systems that require scale, performance, and deep integration. It’s not an either-or decision. It’s a layered approach. And it works.

Where’s It All Headed?

These trends don’t exist in isolation. They reinforce each other.

AI makes development faster and more accessible. Cloud-native architecture makes systems more flexible and resilient. Low-code platforms expand who can participate in building. Together, they create an environment where custom software becomes not just feasible, but inevitable. That has consequences.

The traditional model of buying off-the-shelf software and adapting your business to fit it starts to look inefficient. Companies that rely entirely on external tools will find themselves constrained by someone else’s roadmap, pricing, and limitations.

At the same time, companies that invest in custom systems gain control. They can move faster because they aren’t waiting on a vendor. They can differentiate because their systems are tailored to how they operate. They can adapt because their architecture was designed for change from the start. This is where the competitive gap begins to widen.

The Real Shift

It’s easy to frame this as a technology story, but it’s really a strategy story. The question isn’t whether AI can write code or whether cloud infrastructure can scale. Those are solved problems. The real question is whether organizations are willing to rethink how they build and use software.

For some, the shift will be gradual. They’ll layer these capabilities on top of existing systems and move forward incrementally. For others, it will be more decisive. They’ll treat software as a core capability and invest accordingly.

Either way, the direction is clear. Custom software is no longer about building something unique for the sake of it. It’s about building systems that align with how your business actually works. Systems that can evolve. Systems that give you leverage.

That’s the difference between using software and owning it. And in 2026, that difference matters more than ever.

VISIT OUR WEBSITE >

https://sonatafy.com

You nod. You reschedule the customer demo. You go back to your desk and wonder how a team of talented engineers, running on a modern stack, with an Agile coach and a full suite of project management tools, still can’t ship software on time.

Here’s the uncomfortable truth: the late delivery isn’t the problem. It’s the symptom. And the organization beneath it is usually in worse shape than the dashboard shows.

The Visible Cost Is the Smallest Part

When a project misses its deadline, leaders instinctively focus on the timeline. That’s understandable. Contracts have penalty clauses. Sales has made promises to enterprise customers. The CEO has a board deck with a roadmap slide in it.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

But the timeline cost is actually the cheapest part of a late delivery. BCG’s 2024 survey of global C-suite executives found that nearly half said more than 30% of their organization’s technology projects were over budget and late. And poor software quality now costs U.S. businesses an estimated $3.1 trillion annually — a number that doesn’t touch lost market opportunities, damaged customer relationships, or the senior engineers who quietly started updating their LinkedIn profiles.

The real cost of late delivery is what it does to the organization over time.

Speed Without Reliability Is a Debt Factory

The most dangerous response to a missed deadline is the one that feels most logical: ship faster. Cut the testing cycle. Skip the code review. Get it to production and fix it later. This is how backlogs are born.

Picture a pricing calculator shipped in four weeks by bypassing proper testing. It works fine — until a customer enters a large order. The app crashes. Users get logged out. The database corrupts. Customer support gets flooded. Three engineers spend 60 hours over a weekend fixing it. The four-week shortcut ends up costing twelve weeks of unplanned work. The backlog grows by 47 items just from the fallout.

That’s not an edge case. That’s the rule. Every shortcut taken to ship on time creates three bugs to fix later. Every “temporary workaround” that goes to production becomes permanent technical debt. Every skipped code review becomes a production incident that pulls engineers off planned work.

Teams that optimize for speed without reliability aren’t actually moving faster. They’re running in place — spending capacity to fix problems that shouldn’t exist, while the backlog quietly fills with the consequences of their own past decisions.

Adding People Makes It Worse

The second instinctive response to missed deadlines is headcount. If 45 engineers shipped 23 features last quarter, 90 engineers should ship 46. The math is intuitive. The assumption is wrong.

Fred Brooks documented this in 1975, and software teams have been relearning it ever since. Communication overhead grows at n(n-1)/2, where n is the number of developers. Five engineers maintain ten working relationships. Ten engineers maintain 45. The coordination tax hits immediately: senior developers lose productive time to onboarding, pull requests stack up in review queues, integration conflicts multiply, and sprint planning balloons from 90 minutes to three hours.

Throughput doesn’t double. It falls. The work about managing work grows faster than the actual work being done.

The Accountability Gap Is Where Deadlines Go to Die

Late delivery almost never has a single owner. That’s the structural problem most leaders won’t name directly.

When a major feature misses its deadline by four months and the CEO asks why, he typically gets three different answers from three different parties. The offshore team says requirements kept changing. The contractors say the offshore code quality required full rewrites. The staff augmentation firm says their developers were blocked waiting on architectural decisions. All three are telling the truth. None of them are accountable for the outcome.

That’s what diffuse ownership produces. Each party optimizes for their own success metrics. Nobody owns the deadline. Nobody owns the customer impact. The responsibility is distributed so broadly that it effectively belongs to no one.

Missed deadlines are rarely technical failures. They’re accountability failures dressed up in technical language.

Estimation Theater Destroys Trust

Over time, repeated late delivery does something more corrosive than any single missed launch date: it erodes trust in the planning process itself.

The CEO stops believing timeline commitments because dates always slip. Sales stops promising features to prospects. Product managers stop building roadmaps because they’ve been burned too many times. Estimation meetings — which should create alignment and predictability — become ritual theater where everyone performs their role without believing any of it matters.

When a team’s re-estimated the same stories across four sprints, using three different team configurations and two deprecated point scales, the numbers stop meaning anything. They become negotiated fiction. And decisions get made on top of that fiction: enterprise contracts get signed, go-to-market windows get committed, hiring plans get approved — all anchored to forecasts everyone privately knows are unreliable.

Predictability protects revenue. Uncertainty without visibility destroys it.

The Pattern That Breaks It

Companies that solve chronic late delivery don’t do it by adding process. They don’t hire Agile coaches or adopt new frameworks. They restructure accountability.

What actually works is small, autonomous teams with complete ownership of their delivery scope — a single point of accountability, outcome-based incentives, and technical leadership embedded at the team level rather than floating above it. When a team owns deployment, quality, and deadlines as a unit, behavior changes fast. They can’t blame another team for blocking them. They can’t point to matrix management as an excuse. They either ship or they don’t.

The discipline required isn’t glamorous: real-time code reviews, automated quality gates, shift-left testing, honest forecasts with confidence bands instead of fictional point estimates. It’s the infrastructure of reliability, built deliberately rather than assumed.

The Question Worth Asking

The next time your team misses a deadline, resist the instinct to ask “how do we go faster?” Ask instead: who actually owns this outcome, what does the accountability structure really look like, and what’s hiding in the backlog that we created the last time we tried to ship faster?

The deadline isn’t the problem. It never was. It’s just the place where the real problem finally becomes impossible to ignore.

VISIT OUR WEBSITE >>

Now the pendulum is moving again, though not back to rigid requirements documents. It’s settling into something more structured and deliberate: spec-driven software development.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

At its core, spec-driven development changes where the center of gravity sits. The specification isn’t a supporting artifact anymore. It becomes the primary one. The system gets defined in precise, often machine-readable terms before code is written, and that definition drives everything that follows. The spec describes interfaces, behaviors, and constraints in a way that can be consumed not just by humans, but by tools and increasingly by AI systems.

That shift sounds efficient, and in many ways it is. But like every methodology that promises clarity, it brings both real advantages and real constraints.

What Spec-Driven Development Actually Means

Spec-driven development isn’t just better documentation, and it isn’t a return to outdated waterfall thinking. It’s a more operational version of structured design, where the specification becomes the system’s blueprint rather than a loose description of intent.

In practice, this shows up in things like OpenAPI contracts, JSON schemas, and executable specifications tied to behavior-driven development. These artifacts define exactly how a system should behave, leaving little room for interpretation. The goal is consistency across teams and systems, especially when those systems are distributed and built by multiple groups working in parallel.

This approach has taken on new relevance in the context of AI-assisted development. When code is being generated or accelerated by machines, ambiguity becomes a liability. A clear specification provides the structure needed to produce consistent and predictable results.

The Strengths

The most obvious advantage of spec-driven development is clarity, and that clarity compounds as systems grow.

In many software projects, misalignment starts early. Product managers, engineers, and stakeholders interpret requirements differently, and those small gaps expand as development progresses. By the time the system is built, it often reflects a mix of assumptions rather than a shared understanding. Spec-driven development forces those assumptions to be resolved upfront, which reduces ambiguity and limits downstream rework.

That discipline becomes even more valuable in large, distributed environments where constant communication isn’t practical. A shared, machine-readable specification acts as a coordination layer. Teams don’t have to guess what another group intended, and they don’t have to rely on endless meetings to stay aligned.

There’s also a strong economic argument behind this approach. Defects discovered late in development are significantly more expensive to fix than those caught during the design phase. By investing in precise specifications early, teams reduce the likelihood of costly corrections later in the lifecycle.

Spec-driven development also unlocks a new level of automation, especially in an AI-assisted world. When requirements are vague, AI-generated code tends to be inconsistent. When specifications are structured and machine-readable, they can drive code generation, automated testing, API validation, and documentation updates. The spec stops being passive and starts acting like an executable system.

This creates a tighter feedback loop between intent and implementation. Instead of relying entirely on human interpretation, teams can use automation to enforce alignment between what’s defined and what’s built. That consistency becomes a force multiplier, especially as systems scale.

There’s another area where spec-driven development delivers clear value, and that’s governance. In regulated industries like healthcare, finance, and defense, traceability isn’t optional. Systems need to demonstrate that they behave exactly as specified and that every requirement has been implemented and validated.

Spec-driven development embeds that traceability into the system itself. Each behavior maps directly to a defined requirement, and changes can be tracked and verified over time. For organizations dealing with compliance, this isn’t just helpful. It’s foundational.

The Weaknesses

The most significant drawback of spec-driven development is that it assumes a level of certainty that rarely exists.

Requirements don’t stay fixed. Markets shift, users behave in unexpected ways, and product strategies change midstream. This volatility is a fundamental part of software development. When a system is tightly bound to an upfront specification, adapting to change becomes more difficult. Every modification has to ripple through the spec, the code, the tests, and the documentation.

What starts as clarity can turn into rigidity if the system isn’t designed to evolve. That’s the core reason agile methodologies gained traction in the first place. They accept that discovery happens during development, not just before it. A rigid spec-driven approach can limit that discovery if it’s applied too strictly.

There’s also the issue of upfront cost. Writing a high-quality specification takes time, effort, and deep domain knowledge. Teams have to think through edge cases, define behaviors precisely, and align across functions before anything gets built. That slows down the initial phase of development, which can be a serious disadvantage in environments where speed to market matters.

Many teams benefit from releasing early versions, gathering feedback, and refining the system based on real usage. Spec-driven development shifts that balance by investing heavily upfront with the expectation of smoother execution later. That tradeoff works in some contexts and fails in others, and it’s not always obvious which situation you’re in.

Maintenance is another challenge that doesn’t get enough attention. A specification only has value if it stays accurate, and keeping it accurate requires discipline. Systems evolve quickly, and without strong processes, the spec can fall out of sync with the implementation.

Once that happens, the spec stops being a source of truth and starts creating confusion. Even with automation, maintaining a living specification takes effort. Teams have to treat the spec as part of the system, not as documentation that can be ignored once the code is written.

Discipline and Discovery

Every software team operates between two competing forces: discipline and discovery.

Discipline brings clarity, consistency, and control. It reduces risk, enables automation, and creates alignment across large systems. Discovery brings adaptability, speed, and responsiveness. It allows teams to build the right thing, even when they don’t fully understand it at the start.

Spec-driven development leans heavily toward discipline, which is exactly why it’s gaining traction in an AI-driven world. But it only works when it leaves room for discovery. The teams that succeed with it don’t treat the spec as a fixed contract. They treat it as a living system that evolves alongside the software it defines.

VISIT OUR WEBSITE >

The shift happened fast. In January 2026, GitLab released version 18.8 with its Duo Agent Platform, introducing seven AI agents designed to automate tasks across the software development lifecycle. By May 2025, GitHub announced its own coding agent at Microsoft Build, embedded directly into GitHub and accessible through Visual Studio Code. Microsoft framed these developments under a new umbrella term: Agentic DevOps.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

These agents represent a fundamental departure from traditional automation. Where scripts follow predefined rules and CI/CD pipelines execute fixed sequences, agentic AI brings something different to the table. These systems can break down complex goals into subtasks, choose their own approaches, and adjust their plans when obstacles appear.

What Makes it Agentic?

The technical distinction matters. A GitHub coding agent, for instance, spins up its own secure development environment using GitHub Actions, the CI/CD platform that executes over 40 million jobs daily. The agent clones repositories, analyzes codebases using advanced retrieval techniques, and writes code across multiple files. It pushes changes to draft pull requests, updates descriptions, and logs its reasoning along the way.

GitLab’s approach offers similar capabilities but emphasizes multi-step reasoning. Teams can assign agents to generate code, modernize pipelines, suggest security fixes, or create documentation. The system supports multiple AI models, letting organizations choose between options from Anthropic, Google, and OpenAI based on their specific needs.

Microsoft positioned these developments as moving from “copilots to agents.” The distinction captures something real. Copilots suggest next steps and wait for approval. Agents take the wheel for extended periods, operating asynchronously while developers focus elsewhere.

Where the Impact Shows Up

The practical applications emerged quickly in early deployments. At Carvana, the GitHub coding agent converts specifications to production code in minutes, according to the Senior Vice President of Engineering. EY’s DevEx Lead described teams building “agent-driven” workflows where multiple agents operate in parallel to amplify human work.

The tasks agents handle best fall into a clear pattern. They excel at fixing failed pipelines by analyzing errors and preparing recommended changes. They generate test suites for existing code. They modernize legacy applications by assessing dependencies and executing update plans. They review code and flag security vulnerabilities before deployment.

These capabilities address what developers consistently say they want least: testing their own code, fixing bugs, and standing up deployment environments. Agents handle the toil while humans focus on architecture and business logic.

Azure DevOps integrated directly with GitHub Copilot in early 2025, letting teams send work items straight to coding agents. The agent begins work, tracks progress on Kanban boards, and generates pull requests. The integration makes AI participation visible at the project management level, not just buried in individual IDEs.

The Security Challenge

The rapid adoption revealed a problem. By mid-2025, survey data from SailPoint found that 80 percent of organizations had encountered risky behaviors from AI agents. The issues ranged from improper data exposure to unauthorized system access.

The security challenges stem from agent autonomy itself. Traditional application security focuses on controlling inputs and outputs. Agentic systems require something different. Organizations must secure systems that remember past interactions, operate across multiple applications, and make decisions without waiting for human approval.

OWASP released its Top 10 for Agentic Applications in December 2025 after a year of research involving over 100 security experts. The framework identifies threat categories specific to autonomous systems: memory poisoning, tool misuse, identity abuse, and goal hijacking.

The EchoLeak exploit against Microsoft Copilot in mid-2025 demonstrated the stakes. Engineered prompts embedded in email messages triggered the agent to exfiltrate sensitive data without user interaction. Symantec conducted experiments showing how agents could harvest personal information and automate credential stuffing attacks.

McKinsey framed the governance challenge in stark terms: agents operate as “digital insiders” with varying levels of privilege and authority. Like human insiders, they can cause harm through poor alignment or deliberate compromise. The firm found only 1 percent of surveyed organizations believe their AI adoption has reached maturity.

What Works for Governance

Organizations implementing agentic AI successfully established several common practices. They created cross-functional governance councils that oversee all agent activity. These bodies meet monthly and report to boards quarterly, holding decision rights over deployment.

The technical controls follow a consistent pattern. GitHub’s coding agent, for example, can only push code to branches it creates, kept separate from main branches. The agent has limited access to its execution environment and requires human approval at each workflow stage. Developers who prompt agents to open pull requests cannot be the ones to approve them.

Identity management emerged as a critical component. Agents need authentication, access control, and auditability. They require scoped tokens that limit access to specific repositories and only the information needed to complete assigned tasks.

Observability matters more with agents than with traditional automation. Organizations set up detailed logging and tracing of agent actions. They monitor for anomalies tied to key performance indicators. They define triggers for escalations and establish accountability standards for agent decisions.

The Workflow Transformation

The impact on DevOps workflows goes beyond individual task automation. Agent mode in GitHub enables developers to describe complex infrastructure changes through natural language. The agent analyzes existing configurations, suggests improvements, and implements them across multiple files.

For troubleshooting, agents access logs and system state through the Model Context Protocol, a standard that functions like a “USB port for intelligence.” This allows agents to interface with various tools in the DevOps stack, creating unified experiences across previously siloed systems.

Organizations building agent workflows discovered they could chain multiple agents together for complex processes. One agent handles infrastructure provisioning. Another manages security compliance. A third optimizes application performance based on user behavior. The interconnected agents adapt to evolving requirements without human intervention for routine decisions.

The New Mandate for CTOs

Next Up?

The trajectory points toward deeper integration. Microsoft calls this vision “agentic DevOps,” where intelligent agents collaborate with developers and with each other to automate every stage of the software lifecycle. The promise involves crushing backlogs, addressing technical debt, securing applications, and maintaining production systems.

The reality will depend on solving governance challenges that most organizations barely started addressing in 2025. Only 6 percent of organizations currently leverage advanced security frameworks for AI, according to Stanford research. The gap between adoption enthusiasm and security maturity remains wide.

Teams moving forward with agentic AI need to treat it as an enterprise initiative, not a developer tool. They need measurable outcomes defined before deployment, not backfilled afterward. They need guardrails built into the initial architecture, not bolted on when problems emerge.

The technology offers genuine capability gains. Agents can handle complexity that defeats traditional automation. But the shift from systems that enable interactions to systems that drive transactions requires security thinking built in from the start, not added as an afterthought.

VISIT OUR WEBSITE >

Here’s what’s actually happening: AI tools now generate unit tests at speeds no human team can match. According to recent industry data, small companies report up to 50% faster unit test generation when they deploy AI-powered testing tools. GitHub Copilot, one of the most widely adopted code assistants, offers code completions at a 46% rate, though developers accept only about 30% of those suggestions. That acceptance rate tells you everything you need to know about where we’re headed.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

Eighty-two percent of developers now use AI tools weekly, with 59% running three or more different AI assistants in parallel. By 2028, Gartner predicts that 90% of enterprise engineers will use AI code assistants, up from just 14% in 2024. The explosion’s already here. The question facing quality teams comes down to this: what do humans do when machines handle the grunt work?

The Unit Test Handoff

AI excels at exactly the kind of testing that used to drain hours from every sprint. Need test coverage for a straightforward CRUD operation? AI can generate dozens of test cases in minutes, including edge cases that human testers might overlook. The tools analyze code structure, identify input parameters, and create assertions based on expected outputs with remarkable consistency.

Companies like Diffblue and BaseRock built entire platforms around this capability. Their AI agents examine codebases, generate comprehensive test suites, and maintain those tests as code evolves. Developers report saving 30 to 60 minutes per hour on routine testing tasks when they integrate these tools into their workflows.

But here’s where the narrative gets interesting: those same teams that automated unit test generation discovered something unexpected. The AI-generated tests caught functional bugs just fine. They verified that individual methods returned expected values. They confirmed that error handling worked as designed. What they couldn’t do—what they’ll never do—involves understanding business context, evaluating risk, or making judgment calls about what “quality” actually means for a specific user base.

The Rise of Human-in-the-Loop Verification

By early 2025, 76% of enterprises had implemented explicit human-in-the-loop review processes specifically to catch AI failures before they reached users. These weren’t optional nice-to-haves. They became mandatory checkpoints because teams learned the hard way that AI tools generate plausible-sounding test cases that can be completely irrelevant to actual business requirements.

Knowledge workers now spend an average of 4.3 hours per week reviewing and fact-checking AI outputs. That’s not wasted time—it’s a deliberate investment in catching the gaps that automated systems miss. AI testing agents, especially those built on large language models, demonstrate what researchers call “confident wrongness.” They’ll generate test cases with apparent certainty, document them beautifully, and miss the core business logic entirely.

The human-in-the-loop model works like this: AI handles volume and speed while humans handle nuance and risk. Domain experts provide high-level intent, standardized test data, and ethical rubrics. AI agents generate test scripts and execute tests at massive scale, using machine learning to filter results based on preset confidence scores. Then human reviewers examine the filtered output, validate the AI’s recommendations, and make final decisions about which tests matter and which ones don’t.

This approach improved accuracy in moderation tasks by 45% compared to fully automated systems. The principle’s straightforward enough: machines can surface anomalies, but they can’t reliably judge intent, context, or downstream harm.

Integration Testing

While AI took over unit testing, something else happened. Quality teams shifted their focus upward to integration and system-level testing, where complexity lives and where business value gets created or destroyed.

Integration tests verify that multiple components work together correctly. They catch the bugs that unit tests miss—the timing issues, the data transformation errors, the cascading failures that only appear when systems interact under load. These tests require understanding how users actually experience software, not just whether individual functions return correct values.

The World Quality Report 2025-26 found that 94% of organizations now review real production data to inform their testing strategies. Teams combine test outcomes, failure patterns, crowd testing signals, production telemetry, and support incidents into a single, decision-grade view of product health. Nearly half still struggle to convert those insights into action, which highlights the ongoing gap between visibility and impact.

Shift-left testing—the practice of moving testing activities earlier in the software development lifecycle—became the dominant approach in 2025 precisely because teams recognized that catching integration issues late costs exponentially more than catching them early. When testing happens during planning and design phases rather than after code is written, teams avoid the expensive rework cycles that tank velocity.

What Quality Engineers Actually Do Now

The skill requirements for quality engineers shifted dramatically. The World Quality Report ranks generative AI as the number one skill for quality engineers in 2025, cited by 63% of respondents. That ranking places AI expertise ahead of traditional automation skills. But soft skills like verbal and written communication rank fifth at 51%, reinforcing that human judgment, interpretation, and cross-functional collaboration became core QA competencies rather than optional extras.

Instead of writing endless assertions for unit tests, testers now design scenarios that expose real risk. They ask harder questions: Does an AI give misleading advice to inexperienced users? Does performance degrade across regions, demographics, or environments? Can the system handle unexpected input combinations that wouldn’t appear in generated test data?

Quality engineers spend their mornings automating tests and their afternoons reviewing AI decisions with domain experts. They’ve become translators between machine-generated test coverage and human understanding of what matters to customers. The role evolved from finding bugs to defining what “working correctly” actually means in context.

The Trust Function

Here’s the fundamental tension: AI systems often appear confident while being wrong. That gap creates risk that no amount of automated testing can eliminate. When failures involve bias, unsafe guidance, or silent regressions in critical systems, being “mostly right” can be catastrophic.

Quality assurance stopped being a late-stage checkpoint and became what some teams call a “trust function.” The investment’s material. The oversight is mandatory. And the stakes keep rising as software embeds itself deeper into systems that affect human safety, financial security, and social infrastructure.

Teams that figured this out early built hybrid models combining AI-powered test generation with human evaluation frameworks. They automated the repetitive work and reserved human judgment for the decisions that actually matter—the ones involving context, consequence, and accountability.

The testing revolution delivered exactly what it promised: machines now handle the volume we could never process manually. What nobody predicted was how much that would elevate the importance of human judgment in defining what quality means.

VISIT OUR WEBSITE >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

Your backlog isn’t shrinking. It’s exploding. And it’s not because your team is slow or your processes are broken. It’s because five forces are generating work faster than any team can execute it.

Pain Point 1: Velocity Isn’t Headcount

A company doubled its engineering team from 45 to 90 engineers. Feature delivery dropped from 23 to 19 shipped features.

The new engineers needed onboarding. Senior developers lost 20% of their time answering questions and reviewing code from people unfamiliar with the codebase. Pull requests sat in review queues longer. Deployment conflicts increased.

The coordination tax hit immediately. Five engineers require ten relationships to maintain. Ten engineers require 45 relationships. This is Brooks’ Law in action—communication overhead grows as n(n-1)/2. The work about managing work grows faster than actual work.

Integration testing became a nightmare. Features that worked in isolation broke when combined. New hires took four months to become productive, matching industry research showing developers need 3-9 months to reach full productivity. During that time, they generated tickets instead of resolving them.

Hiring doubled the burn rate while velocity declined 17%. The backlog grew by 412 items.

Velocity isn’t headcount. It’s organizational capacity to ship working software. Adding people without changing how work flows through the system doesn’t increase capacity. It creates chaos.

Pain Point 2: Estimates Become Theater

Team A estimated “Add export to CSV” as 3 points. Team B estimated the same story as 8 points. Team C estimated it as 13 points. Identical requirements. The difference wasn’t the work. It was how each team defined points.

Estimates stopped being predictions and became negotiations. Product managers wanted lower numbers. Engineers inflated estimates to build a buffer against scope creep. Nobody knew if 5 points meant five days or five weeks.

A story estimated at 5 points took three weeks because halfway through, the authentication system needed refactoring. Another 5-point story shipped in two days because the engineer had built something similar before.

The CEO stopped believing in timeline commitments. Sales stopped promising features. Product managers stopped building roadmaps. The estimation process destroyed credibility instead of creating it.

One company spent 127 hours last quarter in estimation meetings. Those hours produced numbers nobody trusted, predictions nobody believed, and commitments nobody kept.

Estimation theater doesn’t just waste time. It creates a shared delusion where everyone pretends to know things they don’t, commits to things they can’t deliver, and blames each other when reality intervenes.

Pain Point 3: Accountability Breaks When Ownership Is Diffuse

A company’s biggest feature missed its deadline by four months. The offshore dev shop said requirements kept changing. The US contractor said offshore code quality was terrible. The staff augmentation firm said developers were blocked waiting on architectural decisions. All three were telling the truth. Nobody was accountable for the outcome.

Strategized compression of remaining content and conclusion structure.

I’m about halfway through and at around 450 words. I need to compress the remaining three pain points more tightly and add a conclusion. Let me continue.

Multi-vendor chaos is organizational kryptonite. Each vendor optimizes for their own metrics. Nobody measures whether the feature actually works or whether customers will pay for it.

When the feature shipped, it crashed under load within 48 hours. Vendors pointed fingers. The engineering manager spent two weeks investigating. The answer was everyone and no one.

Inside the engineering organization, ownership had become diffuse. Features were “owned” by product managers who didn’t write code. Code was “owned” by engineers who didn’t talk to customers. Everyone completed tasks. Nobody ensured the end-to-end customer experience worked.

The backlog became a graveyard of orphaned items. Stories that crossed team boundaries sat untouched. Technical debt went unaddressed. The organization optimized for individual task completion instead of collective value creation.

Pain Point 4: Visibility Collapses in Distributed Delivery

The dashboard showed green checkmarks everywhere. Forty tickets closed last week. Velocity is holding steady at 47 points per sprint. Every metric said teams were executing well.

Three customers churned because a promised feature still wasn’t live after two months. The dashboard showed work happening. It didn’t show that work wasn’t shipping anything customers wanted.

Activity reporting created an illusion of progress. Teams closed tickets by splitting large stories into smaller ones. Developers marked items complete when code merged, not when features went to production. Product managers updated the status to “90% done” for things that would take another month to finish.

The dashboard tracked tickets closed, not value delivered. Story points completed, not customer problems solved. Lines of code written, not bugs eliminated.

Leaders felt blind even though they had more data than ever. The problem wasn’t a lack of data. It was a lack of accountable interpretation. Dashboards answered “what happened,” but no one explained whether it mattered.

Activity isn’t outcomes. Busy isn’t productive. Visible isn’t valuable.

Pain Point 5: Speed Without Reliability Creates Future Work

The VP of Engineering’s pitch was simple: Speed or quality. Pick one. The CEO always picked speed. That’s why the backlog kept growing.

The speed-versus-quality framing is a false tradeoff. The real tradeoff is chaos versus systems. Chaos looks fast in the short term and collapses over time. Systems look slow to build and accelerate permanently.

Rushed work created future backlog faster than it cleared current backlog. Every shortcut taken to ship a feature on time created three bugs that had to be fixed later. Every skipped code review became an incident that pulled engineers away from planned work.

A company shipped a pricing calculator in four weeks by skipping testing. It crashed when a customer entered a large order. The database got corrupted. Customer support got flooded. Three engineers spent 60 hours over a weekend fixing it. The four-week shortcut cost 12 weeks of unplanned work.

One company had 1,407 backlog items. 380 were bugs caused by previous rushed work. They weren’t shipping fast. They were running in place, spending capacity to fix problems instead of building new things.

Stripe’s research found developers spend 33% of their time on technical debt and maintenance on average, with some organizations reaching 40-50%. That’s nearly half the engineering budget wasted on problems that shouldn’t exist.

Pain Point 6: SDLC Is a Concept, Not an SOP

Companies grow features without considering business value or long-term maintenance. Every major addition creates permanent ongoing costs that never get calculated until it’s too late.

An analytics dashboard took six weeks to build. It consumed 15-20% of that effort annually in ongoing maintenance—permanently. Research shows this matches industry patterns—over five years, only 21% of total costs occur during planning and development. The other 79% is recurring maintenance and enhancement.

The maintenance tax compounds. Year one, engineers spend 100% of their time building new things. Year two, 20% goes to maintaining last year’s features. By year four, 60% of capacity goes to maintenance and only 40% to new development. Gartner’s research confirms this pattern as systems mature.

No lifecycle thinking is how backlogs explode. Features get added based on upfront development cost without accounting for the permanent maintenance tax they create.

Companies treat SDLC as a process diagram instead of the fundamental question that should gate every backlog decision: Does the long-term value justify the permanent cost?

These six pain points explain why backlogs explode even in well-run organizations. The backlog crisis isn’t about too much work. It’s about broken organizational systems that turn good intentions into chaos, activity into waste, and resources into constraints.

Fixing the backlog requires changing how work is owned, sequenced, and delivered at the point of execution. Everything else is just noise.

Visit Our Website to Learn More »

These fines share a common thread. Security teams discovered the problems too late. The vulnerabilities had already shipped to production, breached customer data, and triggered compliance violations. Companies scrambled to patch systems, notify regulators, and manage public relations disasters.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

The old playbook doesn’t work anymore. Running security scans after deployment, waiting for penetration testers to find flaws, treating security as a final checkpoint before release. These approaches cost too much and catch too little. By the time a vulnerability reaches production, fixing it costs up to 30 times more than addressing it during development.

The industry responded by moving security into the only place that makes sense: the integrated development environment where code gets written.

Security Moved Left

Shift-left security started as a simple idea. Instead of waiting until the end of the development cycle, embed security checks earlier in the process. Run scans during code reviews. Flag vulnerabilities in pull requests. Catch problems before they multiply.

But simple ideas hit complex reality. Developers got bombarded with alerts. Static analysis tools generated thousands of warnings, most of them false positives or low-priority issues. Teams ignored the noise, missed the real threats, and security became an obstacle rather than a safeguard.

The turning point came when AI-powered tools learned to separate signal from noise. Modern security platforms don’t just scan code and dump results. They understand context. They know which vulnerabilities matter based on how the code gets used, which services it connects to, and what data it handles.

Take threat modeling. Traditional approaches required security architects to diagram data flows, identify attack surfaces, and map potential exploits. This process took weeks for complex systems and went stale the moment developers changed the architecture.

AI-powered threat modeling platforms like Aribot scan systems in real time, using machine learning to identify threats with precision that manual processes can’t match. These tools integrate into DevSecOps environments, generate security requirements mapped to frameworks like NIST 800-53 and CMMC, and verify implementation as code changes. When developers add a new service or modify an API endpoint, the threat model updates on its own.

The system doesn’t stop at identification. It generates Infrastructure-as-Code templates designed to mitigate cloud-specific threats. If a developer creates an S3 bucket without proper encryption, the tool flags it and provides a corrected Terraform template with encryption enabled, access controls configured, and logging turned on.

Your IDE Knows What’s Dangerous

The most effective shift-left security happens where developers already work. Not in separate security portals. Not in post-commit scanning reports. Inside the IDE itself.

Modern security tools integrate into Visual Studio Code, IntelliJ, and other development environments. When a developer types a function that’s vulnerable to SQL injection, the IDE highlights it in real time. When they import a library with known CVEs, they get an alert before they even save the file. When they hardcode an API key, the system blocks the commit.

IBM’s Bob, an agentic IDE announced in late 2024, embeds security checks throughout the development workflow. It integrates with Palo Alto Networks Prisma AIRS to catch AI-specific threats like prompt injection and data poisoning. The system normalizes prompts to block injection attempts, scans for sensitive data in model outputs, and enforces governance policies in near real-time.

The feedback loop compresses from weeks to seconds. A developer writes code, sees a security warning, fixes the issue, and moves forward. No context switching. No waiting for security team approval. No accumulation of technical debt that becomes impossible to repay later.

Companies like Wiz built entire platforms around this principle. Their Code solution integrates into IDEs and repositories, providing cloud-to-code traceability that maps security threats back to specific lines of code. When a misconfigured Kubernetes cluster appears in production, the system traces it back to the exact developer who wrote the Terraform file, shows them the vulnerable configuration, and provides the fix.

Infrastructure as Code

Cloud infrastructure adds another layer of complexity. Developers don’t just write application code anymore. They write Terraform plans, Kubernetes manifests, CloudFormation templates. Each of these defines real infrastructure with real attack surfaces.

A misconfigured S3 bucket can expose millions of customer records. An over-permissioned IAM role can give attackers the keys to your entire AWS account. A Kubernetes pod running as root can compromise your entire cluster. Traditional security tools catch these problems only after the infrastructure runs in production, if they catch them at all.

Infrastructure as Code enforcement moves the checkpoint earlier. Before a Terraform plan gets approved, automated tools validate it against security policies. Does it create public-facing resources without encryption? Rejected. Does it grant overly broad permissions? Rejected. Does it lack required logging and monitoring? Rejected.

Tools like Checkov scan IaC templates during pull requests, comparing them against hundreds of security policies. They check for CIS benchmarks violations, HIPAA compliance failures, PCI-DSS gaps. If the infrastructure doesn’t meet standards, the pull request doesn’t merge.

This approach prevents the drift that plagues traditional security. In conventional setups, infrastructure starts secure but degrades over time. Developers make quick changes, bypass policies for urgent fixes, accumulate misconfigurations. By the time security audits happen, production systems look nothing like the approved designs.

IaC enforcement eliminates drift before it starts. Every change goes through the same security validation. Every deployment matches the approved template. The infrastructure that runs in production is the infrastructure that passed security review.

The Cost Equation Flipped

When IBM analyzed breach costs in 2025, they found that 32% of breached organizations faced regulatory fines. Nearly half of those fines exceeded $100,000, with fines between $1 and $50,000 growing by 45%.

But the financial calculation goes beyond fines. Detection and containment took an average of 241 days in 2025. During those eight months, compromised systems leaked data, attackers moved laterally through networks, and business operations faced disruption. The average cost of a data breach hit $4.44 million globally, with the United States seeing $10.22 million per incident.

Compare that to the cost of fixing vulnerabilities during development. A developer spends 15 minutes resolving a security warning in their IDE. The company avoids the vulnerability. No breach. No fine. No remediation.

The economics favor early intervention so overwhelmingly that companies can’t afford to delay. Every hour spent building security into development processes saves weeks of incident response later.

What Security Looks Like Now

Modern security doesn’t announce itself. Developers don’t switch between their code editor and a security dashboard. They don’t wait for weekly scan reports. They don’t file tickets with security teams and pause development for approval.

Security happens inline. It provides instant feedback. It suggests secure alternatives. It enforces policies without human intervention.

A developer writes a Lambda function. Their IDE suggests least-privilege permissions based on the actual AWS services the function calls. They create a database connection. The security tool recommends connection pooling and parameterized queries. They import a package. The system checks for CVEs and suggests a patched version.

The shift from reactive to proactive security changes the fundamental dynamic. Security teams stop playing catch-up. Developers stop treating security as someone else’s problem. The entire organization builds security into its DNA rather than bolting it on afterward.

VISIT OUR WEBSITE >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

The productivity gains tell part of the story. Research involving 4,800 developers found that those using GitHub Copilot complete tasks 55% faster than their counterparts working without AI assistance. Pull request times have dropped from 9.6 days to 2.4 days in some organizations. The market for AI coding tools has exploded from $4.91 billion in 2024 to $7.37 billion in 2025, with projections reaching $30.1 billion by 2032.

But the numbers revealing productivity improvements only capture half the equation. While AI tools help experienced developers ship code faster, they’re simultaneously reshaping the career ladder in ways that particularly affect people trying to break into the industry.

Entry-Level Jobs Are Disappearing

U.S. Bureau of Labor Statistics data reveals that overall programmer employment fell 27.5% between 2023 and 2025. Software developer positions, which involve more design-oriented work, saw only a 0.3% decline. The pattern becomes clearer when examining age demographics. A Stanford Digital Economy study found that employment for developers aged 22 to 25 dropped nearly 20% from its peak in late 2022, when generative AI tools became widely available. Meanwhile, employment for developers aged 35 to 49 grew 9% during the same period.

The entry-level coding job that existed three years ago has effectively vanished. Companies that previously hired junior developers to write boilerplate code, fix basic bugs, and handle routine testing now accomplish those tasks with AI assistance and smaller teams of experienced engineers.

What Skills Matter Now

The transformation extends beyond simple job displacement. AI coding tools are changing what skills matter and how developers spend their time. Stack Overflow’s 2024 Developer Survey showed that 63% of professional developers currently use AI in their development process, with another 14% planning to start soon. But these developers aren’t just writing more code; they’re shifting from writing code to reviewing AI-generated code, from implementing solutions to designing architectures, and from debugging their own work to catching edge cases and security vulnerabilities that AI tools miss.

The Security Problem Nobody Wants to Discuss

The security implications are significant. Research shows that 48% of AI-generated code contains security vulnerabilities, and 57% of AI-generated APIs are publicly accessible while 89% rely on insecure authentication methods. A 2024 GitClear analysis examining over 153 million lines of code found that AI-assisted development has led to a 4x increase in code cloning. The percentage of code associated with refactoring dropped from 25% in 2021 to less than 10% in 2024, while copy-pasted code rose from 8.3% to 12.3%.

These quality concerns explain why 46% of developers say they don’t fully trust AI outputs. The acceptance rate for GitHub Copilot’s suggestions hovers around 30%, meaning roughly 70% of what the AI proposes gets rejected by developers who spot problems the algorithms miss.

From Coding to Oversight

The gap between AI’s capabilities and the requirements for production code creates what might become the defining role for developers going forward. Rather than writing code from scratch, developers increasingly guide AI systems, validate their outputs, and integrate AI-generated components into larger systems requiring human judgment about architecture, security, and user needs. Indeed research measuring AI’s potential impact across nearly 2,900 work skills found that software development faces an 81% skill transformation rate, but only 0.7% of skills were rated as very likely to be fully replaced by AI.

The Career Ladder Has Changed

The evolution favors developers who can work at higher levels of abstraction. Junior developers historically learned by writing routine code and gradually taking on more complex challenges. That career path has been disrupted because the routine code they would’ve written now comes from AI tools. Companies are looking for developers who already understand software architecture, can evaluate AI-generated code for security flaws, and possess the judgment to know when AI suggestions should be rejected entirely. The baseline for entry has shifted upward, making it harder to get that first job but potentially more rewarding once you’re in.

Will AI Create Jobs or Destroy Them?

Morgan Stanley Research argues that AI will enhance productivity and lead to more hiring rather than fewer jobs. Their analysis suggests the software development market could grow at a 20% annual rate, reaching $61 billion by 2029, as enterprises build increasingly complex applications. The logic holds that if AI makes developers more productive, companies will use that productivity to build more ambitious software rather than simply reducing headcount.

Whether that plays out remains uncertain. What’s clear is that the AI coding transformation creates winners and losers. Companies with strong engineering practices see AI as a productivity multiplier. Organizations with technical debt find that AI amplifies their existing problems. The DORA 2025 report describes AI as “mirror and multiplier,” boosting efficiency in well-run organizations while magnifying weaknesses in dysfunctional ones.

The Individual Developer’s Dilemma

For individual developers, the implications cut both ways. Experienced developers who can use AI tools effectively become dramatically more productive, potentially commanding higher salaries as their output increases. But junior developers and new graduates face a job market that’s fundamentally different from what existed just three years ago. The traditional apprenticeship model, where you learn by doing routine work under supervision, is breaking down because AI now handles much of that routine work. Instead, early-career developers need to demonstrate higher-order thinking about software architecture, security, and system design before landing their first role.

What the Future Actually Looks Like

The future likely involves fewer people choosing coding as a career path, but those who do may command premium compensation as they take on more strategic roles. Gartner forecasts that 90% of enterprise software engineers will use AI coding assistants by 2028, up from less than 14% in early 2024. The coding agent features that GitHub and competitors introduced in 2025 contribute to approximately 1.2 million pull requests per month, indicating movement toward autonomous development workflows where AI handles increasingly complex coding tasks without constant human supervision.

This doesn’t mean human developers become obsolete. The social aspects of software development, including collaboration, understanding user needs, and translating business requirements into technical specifications, remain beyond AI’s current capabilities. The ethical dimensions of software choices and the judgment calls about which problems deserve technical solutions versus which need policy changes or organizational restructuring require human wisdom that large language models can’t provide.

The most profound change might be psychological rather than technical. Developers are shifting from makers to managers of AI-powered systems, from craftspeople to architects who orchestrate tools that generate most of the code. That transition requires letting go of aspects of the job that many developers found satisfying while embracing new responsibilities demanding different skills.

What’s certain is that the AI coding revolution has moved beyond speculation into demonstrated impact on real jobs and careers. The 20 million developers using GitHub Copilot aren’t experimenting with a toy; they’re using a tool that writes nearly half their code and fundamentally changes how software gets built. Anyone considering a career in software development needs to figure out how they’ll position themselves to thrive in an industry where AI assistance has become the baseline rather than the exception.

VISIT OUR WEBSITE >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

By 2026, software no longer behaves like a simple multiplier. It has become the underlying operating system of modern institutions, embedded deeply in government, healthcare, transportation, finance, and global commerce. Public failures now show that many of these systems have grown beyond the organizational, technical, and governance structures built to manage them. The result is not isolated breakdowns, but recurring, systemic strain.

1. The Backlog Crisis Has Become Structural

Software backlogs were once treated as temporary. Teams are expected to reduce them over time through refactoring, modernization, or increased staffing. In large institutions today, backlogs persist indefinitely. Feature requests, compliance updates, security patches, data corrections, and technical debt accumulate faster than they can be resolved. Modernization initiatives are often layered on top of unresolved legacy systems rather than replacing them, creating compounding queues of unfinished work.

Failure:

U.S. federal oversight bodies have repeatedly documented the risks posed by aging government software systems. The U.S. Government Accountability Office has confirmed that critical federal systems, including Treasury-managed systems, continue to rely on legacy technologies that are difficult to secure, expensive to maintain, and risky to modify. These systems support tax processing, financial operations, and benefits distribution, and are often decades old.

Public reporting and GAO assessments show that modernization efforts have been slowed by system interdependencies, workforce constraints, and the operational risk of changing systems that cannot be safely taken offline. Filing delays, refund backlogs, and cybersecurity concerns cited in IRS oversight hearings have been attributed to long-standing system complexity and modernization challenges rather than single-point failures. The backlog, in this context, is not an anomaly but an enduring structural condition.

2. AI Raised Expectations Faster Than Reality

Artificial intelligence is widely marketed as a force multiplier capable of reducing labor, improving accuracy, and accelerating decision-making. In practice, most organizations deploy AI into environments with fragmented data, limited governance, and unclear accountability. This gap between expectation and readiness introduces new operational, legal, and reputational risks rather than reducing complexity.

Failure:

In February 2024, Air Canada was held legally responsible by a Canadian tribunal for incorrect information generated by its customer service chatbot. The chatbot fabricated a refund policy that did not exist, and a customer relied on that information when booking travel.

Air Canada argued that the chatbot was a separate tool and not an authoritative source. The tribunal rejected that argument, ruling that automated customer interfaces are extensions of the company itself. The decision established a clear precedent: organizations are accountable for AI-generated outputs presented to customers, regardless of whether the error originated from a human or a machine. The case is now widely cited as an early legal benchmark for AI accountability.

3. System Complexity Has Exceeded Human Understanding

Modern software systems span cloud platforms, microservices, APIs, third-party vendors, security tooling, and AI components. No single individual or team fully understands the entire system. As complexity increases, failures become non-linear. Small changes can cascade across tightly coupled dependencies, producing large-scale disruption.

Failure:

On July 19, 2024, a faulty software update issued by CrowdStrike caused widespread crashes on Windows systems running its Falcon security sensor. Microsoft later estimated that approximately 8.5 million devices were affected worldwide.

The outage disrupted airlines, hospitals, financial institutions, logistics networks, and government services. Flights were grounded, medical procedures were delayed, and customer-facing systems were taken offline. CrowdStrike confirmed that the incident was not the result of a cyberattack but a software defect propagated automatically at global scale. The event demonstrated how modern deployment mechanisms can turn a single error into a systemic failure within hours.

4. Technical Debt Is Now an Enterprise Risk

Technical debt was once viewed as an internal engineering concern. By 2026, it is widely recognized as an enterprise-level risk affecting safety, compliance, operational resilience, and public trust. Deferred maintenance and fragmented systems reduce visibility and make change increasingly dangerous over time.

Failure:

Following multiple high-profile safety incidents, Boeing publicly acknowledged deficiencies in internal quality controls, production oversight, and compliance processes. In 2024, the company released a formal Safety and Quality Plan outlining efforts to improve inspection systems, documentation flows, and cross-functional coordination.

While public reports do not attribute safety failures to a single software system, regulatory findings and investigative reporting consistently highlight process fragmentation and limited system visibility across engineering, manufacturing, and supplier networks. These conditions align with the characteristics of long-accumulated technical and operational debt. The failures were not caused by a single defect but by systems that no longer provided reliable oversight at scale.

5. Senior Technical Judgment Remains Scarce

Automation and AI tools accelerate execution but do not replace architectural judgment, risk assessment, or system-level reasoning. As systems grow more complex, the need for experienced technical leadership increases rather than decreases. Organizations that scale delivery without adequate senior oversight increase the probability of systemic failure.

Failure:

Large technology platforms, including Meta, have publicly described the growing complexity of their infrastructure as AI workloads, data pipelines, and global services expand. Engineering leaders have documented the operational challenges of managing increasingly interdependent systems, including the need for stronger safeguards, staged deployments, and reliable rollback mechanisms.

Public outage disclosures and engineering analyses emphasize that infrastructure incidents are rarely caused by individual mistakes. Instead, they emerge from the interaction of complex systems operating at scale. Industry research consistently shows that organizations lacking sufficient senior technical oversight experience higher incident rates even when automation investments are substantial.

6. Security Cannot Keep Pace With AI-Driven Threats

Cybersecurity threats are increasingly automated, adaptive, and AI-assisted. Attackers can identify vulnerabilities and deploy exploits faster than traditional patching and review cycles can respond. Organizations with brittle systems or limited change tolerance face elevated risk because even necessary security updates carry operational danger.

Failure:

In February 2024, Change Healthcare, a subsidiary of UnitedHealth Group, suffered a ransomware attack that disrupted healthcare operations across the United States. Pharmacy claims, insurance verification, and payment processing were affected nationwide, with impacts lasting for months.

Congressional testimony and industry reporting confirmed that the attack exposed the fragility of centralized healthcare infrastructure. Public statements from healthcare associations and regulators emphasized that system complexity and limited update flexibility significantly delayed recovery. The incident demonstrated how security failures propagate rapidly when critical systems cannot be safely modified or isolated.

7. Legacy Systems Remain Critical and Difficult to Replace

In sectors such as aviation, healthcare, finance, and government, core systems cannot be replaced without unacceptable operational risk. Organizations modernize around these systems rather than through them, creating hybrid environments where modern interfaces depend on brittle foundations.

Failure:

The December 2022 operational collapse at Southwest Airlines was widely attributed to failures in crew scheduling and operational coordination systems during severe weather. Subsequent investigations and congressional hearings confirmed that these systems lacked sufficient resilience and scalability.

After the incident, the airline announced multi-year modernization initiatives. Public disclosures also made clear that core operational systems could not be replaced quickly without risking further disruption. The experience illustrates a broader industry reality: mission-critical legacy systems persist not because organizations prefer them, but because replacing them safely is extraordinarily difficult.

8. Tool Proliferation Has Outpaced Governance

Modern development environments accumulate tools faster than they retire them. Over time, overlapping platforms, frameworks, and AI services fragment ownership and obscure accountability. Productivity slows not because teams lack tools, but because coordination becomes harder.

Failure:

Across the technology sector, companies have publicly acknowledged the need to rationalize internal tooling. Industry surveys and executive statements from 2024 and 2025 show a growing focus on reducing platform sprawl, consolidating workflows, and clarifying system ownership.

Executives increasingly frame tool reduction as a governance issue rather than a cost-saving exercise. Public commentary emphasizes that unchecked adoption leads to unclear responsibility, slower incident response, and diminished visibility into system behavior. The shift reflects a recognition that tools alone cannot substitute for a coherent strategy.

9. Product Ambition and Engineering Reality Remain Misaligned

Product organizations are rewarded for speed and innovation, while engineering organizations are responsible for reliability, scalability, and cost control. When these incentives diverge, organizations accumulate invisible risk long before failure becomes public.

Failure:

At Amazon, the Alexa division has been widely reported to struggle with monetization and cost sustainability. Financial disclosures and executive commentary confirmed that despite broad consumer adoption, Alexa generated significant operating losses for years.

In response, Amazon reduced investment, reorganized teams, and reassessed product scope. Reporting consistently points to infrastructure costs and unclear revenue models as central challenges. The case illustrates how product ambition can outpace technical and economic reality even inside highly capable organizations.

10. Early Failure Signals Are Normalized Until Public Collapse

Large-scale software failures are rarely sudden. Early warning signs appear as intermittent outages, near misses, degraded performance, and internal risk assessments. Organizations often normalize these signals until a high-visibility failure forces intervention.

Failure:

The October 2021 global outage affecting Facebook was traced to a configuration change that disrupted internal network routing and DNS services. Public technical analyses confirmed that tightly coupled dependencies amplified the impact, bringing multiple services offline simultaneously.

Industry postmortems emphasize a broader lesson: complex systems can fail catastrophically even when individual changes appear routine. The incident is now frequently cited in engineering and reliability literature as an example of how latent risk accumulates when warning signs are treated as acceptable noise rather than signals requiring structural change.

VISIT OUR WEBSITE >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

The traditional playbook for scaling software development is seductive in its simplicity: hire more engineers, organize them into cross-functional squads, run daily standups and sprint planning sessions, and watch velocity climb.

Here’s why that playbook fails: it addresses symptoms instead of root causes. The real problem is coordination overhead masquerading as collaboration. Every additional engineer creates new communication channels. Every new team creates boundaries that features have to cross. Every matrix reporting structure diffuses accountability until nobody owns anything.

Managed software engineering PODs solve this by inverting the model. Instead of hiring developers to manage, you engage complete delivery units designed to ship working software without creating permanent dependencies. Instead of adding headcount, you add capacity. Instead of distributing accountability across committees, you concentrate it in one person who has skin in the game.

What is a POD?

It’s a small, complete software delivery unit designed to own and execute a defined scope of work from start to finish. It’s not a team of developers you manage. It’s not a consulting engagement where experts tell you what to do. It’s a fully accountable delivery mechanism that ships working software and transfers ownership back to your organization when the work is done.

The structure is deliberate. Six to eight people organized around complementary skills. One US-based principal engineer who owns technical decisions and delivery risk. Four to five nearshore engineers writing code and solving problems. One QA engineer embedded from day one. One product owner defining success. One designer ensuring consistency.

Why Latin American Nearshoring Teams?

Nearshoring means placing your engineering team in nearby countries rather than halfway around the world. LATAM engineers—typically based in Mexico, Colombia, or Argentina—work in time zones aligned with US hours. They’re available for real-time collaboration during your workday. Code reviews happen within hours, not overnight. Daily standups include everyone who needs to be there. This time zone alignment eliminates the coordination delays that kill offshore projects while maintaining cost efficiency.

This isn’t staff augmentation. You’re not renting developers by the hour who work under your direction and wait for you to make decisions. The POD commits to shipping a defined outcome in a specific timeframe. They own the technical approach. They solve blockers instead of escalating them. When something goes wrong, you call one person.

This isn’t a squad or tiger team either. Tiger teams handle short-term firefighting at an unsustainable pace. Squads own product areas permanently and create coordination friction at boundaries. PODs deliver defined scopes that can run in parallel, work at a sustainable pace for extended periods, and dissolve when work completes.

The model works because it respects two fundamental truths about software development that most organizations ignore.

Truth #1: Small Teams Ship Faster

Brooks’ Law, articulated in Fred Brooks’ 1975 book The Mythical Man-Month, explains why throwing people at late software projects makes them later. Communication overhead grows exponentially as team size increases. Ten engineers require 45 distinct communication channels. Twenty engineers require 190. Each new person makes coordination harder, not easier.

Amazon proved this at scale with their two-pizza team rule. In the early 2000s, Jeff Bezos implemented a principle that teams should be small enough to be fed by two pizzas, typically 5-8 members. The concept works because it mitigates the Ringelmann Effect, a psychological principle showing that individual productivity decreases as team size grows.

A 2023 Harvard Business Review study found that teams with fewer than 10 members were 30% more likely to complete projects on time compared to larger groups. When you have a six-person team, there are 15 distinct communication channels. A 25-person team has 300 channels—a coordination nightmare.

Amazon’s two-pizza teams have single-threaded ownership over specific products or services. They own their roadmap, make their own tradeoffs, and run their service end-to-end. The team can deploy without coordinating about who’s using the staging environment. They can make database changes without forming committees. They control both sides of API contracts instead of negotiating specifications across organizational boundaries.

Truth #2 -- Accountability Changes Behavior

J. Richard Hackman spent 40 years studying team effectiveness at Harvard. His research found that what makes teams succeed isn’t the personalities or behaviors of individual members but the conditions that enable groups to thrive. Truly effective teams need clear boundaries, stable membership, and concentrated authority to manage their work.

Traditional consulting models spread accountability thin. The account manager sells the work. The solution architect designs it. The project manager tracks it. The developers build it. When something goes wrong, everyone points to someone else. In teams where responsibility is fragmented, diffusion of responsibility takes hold. The more people involved, the less likely anyone is to take action.

PODs concentrate accountability on the principal engineer. They own technical decisions and delivery risk. Their professional reputation depends on whether the work ships on time, works correctly, and transfers cleanly to your internal team.

The principal engineer doesn’t approve shortcuts that create maintenance problems later because you’ll hold them accountable when their work breaks six months after handoff. They document thoroughly because bad documentation comes back to them. They push back on requirements that don’t make sense because shipping the wrong thing hurts their reputation.

Making this work requires the POD charter. Before any code gets written, the POD and company spend several days building a contract that defines what success looks like, how decisions get made, and how everyone knows whether they’re on track. Clear objectives. Specific success criteria. Explicit out-of-scope items. Technical constraints. Communication cadence. Decision authority. Handoff requirements.

The charter prevents misalignment in week one that becomes crisis in week eight. It creates shared understanding upfront so minor issues don’t escalate into major conflicts.

The managed POD model isn’t new technology. It’s organizational design applied to the coordination problem that kills software projects. Small teams with complete ownership ship faster than large teams with distributed responsibility. Concentrated accountability produces better outcomes than diffused blame.

Visit Our Website to Learn More >>