Nordwind
← All articles
·12 min read

AI Creates Software Faster. It Does Not Make Organizations Healthier.

Two years after introducing the Software Health Triangle, AI is raising the stakes across all three dimensions.

The Software Health Triangle with its three corners: Technology & Architecture, Product & Business, Organization & Team Dynamics

Two years after writing my article about the Software Health Triangle, AI is raising the stakes across all three dimensions.

Two years ago, I wrote about a number that bothered me. In a 2023 survey of 400 US technology executives, KPMG found that 51 percent of organizations had seen no measurable increase in performance or profitability from their digital transformation investments. My conclusion: transformations fail when treated as technology rollouts, because the health of a software ecosystem depends on more than systems, platforms, and code.

Two years later, the same pattern is repeating around AI — only faster and more visibly. A preliminary 2025 report from MIT Project NANDA found that 95 percent of the organizations in its sample had not yet generated measurable P&L impact from enterprise GenAI initiatives. BCG’s survey of 1,250 senior executives found that only 5 percent of companies were generating substantial AI value at scale, while another 35 percent were seeing some returns. And McKinsey’s latest State of AI survey found regular AI use in at least one business function at 88 percent of organizations, but enterprise-level EBIT impact at only 39 percent.

These studies measure different things, but they point in the same direction: adoption is widespread; material enterprise-level value is not. Access to capable models is no longer the primary constraint. The harder problem is integrating AI into products, workflows, decisions, and accountability.

Organizations are introducing AI into existing structures, processes, and incentives — changing one component while expecting the whole system to behave differently. It rarely does. To understand why, it helps to revisit the Software Health Triangle.

The Software Health Triangle, briefly revisited

Just as the WHO defines human health as physical, mental, and social well-being — a whole, not a checklist — the health of a software ecosystem rests on three interconnected dimensions:

  • Technology & Architecture — the code, systems, platforms, and technical foundations.
  • Business & Product — what we build, for whom, and how we decide whether it creates value.
  • Organization & Team Dynamics — the people, structures, responsibilities, incentives, and ways of working that produce everything else.

The model was never about balance for its own sake but about holistic thinking and acting: a significant change in one corner affects the other two, and optimizing one dimension in isolation rarely produces the expected value — often it disappears entirely because the rest of the system cannot absorb the change.

Agile, DevOps, cloud platforms, and Data Mesh reshaped all three corners before. What makes AI different is its speed and reach: it changes the cost of building software, the role of the people who build it, and the economics of deciding what should be built at all. AI does not merely strengthen the technology corner. It destabilizes the whole triangle.

Corner 1 — Technology & Architecture: how we build changes

AI hits the technology corner first, and what happens here forces the other two to move. The consumer-visible shift — non-developers building tools without formal training — is remarkable, but the deeper impact is inside professional software teams.

AI often accelerates code generation, but not necessarily end-to-end software delivery. Its effect depends on the task, the codebase, team maturity, and the quality constraints involved. Research with experienced developers working in familiar, complex codebases has even found slower completion with current AI tools. DORA’s research points to the same systemic tension: higher throughput can come with larger review batches, more rework, and reduced stability. Code generation speed is not the same as software-system performance.

As agents take over scoped tasks, engineering work shifts from producing code toward specifying intent, reviewing output, and orchestrating parallel streams of machine-generated work. The senior engineer’s value moves from writing the best code personally to knowing what good looks like: sharp problem decomposition, architectural judgment, and the ability to detect subtle wrongness in code that passes tests but weakens the system. The constraint is no longer how fast software can be written, but how fast it can be trusted.

This reshapes quality assurance and architecture. Traditional code review relies on an implicit warranty of understanding: a colleague wrote the code and can explain its trade-offs. AI-generated code carries no such warranty — it may be clean and well documented while violating domain rules, duplicating capabilities, or eroding architectural boundaries. Review practices, automated evaluation, architectural guardrails, and system-level testing become more important, not less.

Responsibility does not shift to the model. The engineer who accepts generated code still owns it. Organizations also face a new apprenticeship problem: if AI absorbs many of the routine tasks through which junior engineers traditionally developed system and domain judgment, that learning must be redesigned deliberately rather than assumed to happen.

The economics shift as well: build-versus-buy assumptions need revisiting, and architectures with probabilistic components must be designed for uncertainty — evaluation pipelines, fallback behavior, and human oversight where needed. AI thus changes engineering roles, quality mechanics, governance, talent development, and investment logic. And once building software becomes cheaper and faster, the economics of product work change too.

Corner 2 — Business & Product: what we build — and how we decide — changes

The business and product corner is hit twice. The first impact is obvious: AI changes what customers expect. Products that merely add an AI feature already compete with products designed around AI from the start. So how do we know whether an AI initiative creates value? The evidence suggests many organizations do not: pilots launch without success criteria, usage is mistaken for impact and demo quality for product value, and budgets flow toward visible use cases while operational applications with stronger returns go underfunded. That is not a technology failure. It is a business and product failure wearing a technology costume.

The second impact is less obvious and, in my view, more important. Discovery phases, concept papers, validation gates, and detailed requirements exist partly because development has traditionally been expensive: when building the wrong thing costs months of engineering time, it is rational to reduce uncertainty on paper before committing. Much of product methodology is an insurance policy against the cost of building the wrong thing.

AI changes that cost structure. When AI-assisted teams materially reduce the time needed to produce a testable slice, building a working prototype and learning from real behavior may become cheaper than refining a concept that still rests on assumptions. Discovery does not become less important — its optimal form changes. AI does not eliminate discovery. It moves discovery closer to working software. More questions get answered through prototypes and reversible experiments; fewer through specifications, decks, and abstract decision gates.

An organization that equips engineers with AI but leaves its product process untouched has optimized one corner only: the team delivers materially faster while the roadmap board still meets quarterly and funding still takes six weeks. The bottleneck does not disappear. It migrates — from producing software to deciding what should be produced. This is where many organizations will lose most of the value AI creates. We built our product processes as insurance against expensive development. AI is lowering the premium; most organizations are still paying the old rate.

One important limit: cheap development does not make the wrong product cheap in every sense — rollout, integration, regulatory approval, operational complexity, and reputational damage can still be expensive. The point is not to build carelessly, but to validate differently: more working software, more reversible decisions, faster contact with reality. That requires a product organization operating at a different speed, which leads to the third corner.

Corner 3 — Organization & Team Dynamics: the slowest dimension meets the fastest technology

Technology can be deployed quickly. Organizations cannot. They consist of people, habits, incentives, identities, and trust — none of which change at the speed of model releases. You can roll out a tool in a quarter, but not trust, accountability, or a new professional identity. This has always been the triangle’s slowest corner.

The widening gap is already visible in the shadow AI economy. The MIT Project NANDA report found employees in more than 90 percent of surveyed organizations already using personal AI accounts for work, while only around 40 percent of organizations had purchased official LLM subscriptions. The striking point is not employee resistance — the people are ahead of their organization’s official structures.

That creates real problems, from data leakage and security risks to unclear accountability. But treating shadow AI only as a compliance problem misses its diagnostic value: it reveals where employees have already identified friction and unmet needs that the formal organization has not addressed.

Previous transformation waves at least offered the illusion of a stable destination: define a target operating model, reorganize, declare the transformation complete. AI offers no such destination — its capabilities keep changing while organizations are still adapting to the previous generation. The task is not to adapt the organization to AI once, but to build one capable of adapting continuously: teams with the autonomy to redesign their workflows, leaders who can decide under uncertainty, governance that enables safe experimentation, and learning systems that keep professional judgment developing as tools change.

That challenge deserves an article of its own, and I will return to it in a separate piece.

Whether AI creates value will ultimately be decided not in the technology corner, but by whether the organization can absorb what the technology makes possible.

The missing piece: holistic thinking, not single-corner enablement

Viewed through the triangle, the high failure rate of AI initiatives becomes less surprising. A pilot without business outcomes is a Business & Product failure; a capable tool that does not fit existing workflows, an Organization & Team Dynamics failure; an AI-generated codebase without quality mechanisms, a Technology & Architecture failure.

Most initiatives do not fail because one dimension is absent, but because the three are treated separately: the technology team selects a platform, the product team searches for use cases, the organization creates a governance board. Each action may be sensible in isolation. Unless they form one coherent system, they do not reliably create value.

The research is consistent with this diagnosis. McKinsey found that fundamentally redesigning workflows was the factor most strongly associated with actual EBIT impact among the organizational practices it examined. BCG reaches a similar conclusion from a different dataset: the few companies generating substantial value distinguish themselves by reshaping how work gets done. Value emerges where all three corners move together.

A single corner can absorb investment. Only the whole triangle can convert it into effectiveness. That is why holistic thinking is not a consultant’s decoration but an economic requirement. AI does not change what the triangle demands. It changes the price and speed of ignoring it.

Assessing your triangle in the AI era

The dimensions have not changed. The questions have. These are the ones I would start with today.

Technology & Architecture

  • Do we have quality mechanisms designed for AI-generated code: review practices, evaluation pipelines, architectural guardrails, and system-level tests?
  • Have we reconsidered our build-versus-buy assumptions under the new cost of building?
  • Are our systems designed for probabilistic behavior, fallback mechanisms, and human oversight where needed?
  • Who owns generated code, and how do we preserve engineering judgment as more implementation work is automated?

Business & Product

  • Do we measure AI initiatives against business outcomes, or mainly against usage, activity, and demo quality?
  • Can teams learn through prototypes and reversible experiments, or must every idea pass through a process designed for expensive development?
  • Do we know which AI investments create value and which merely create visibility?
  • Have we adjusted our decision and funding cycles to match the new speed of learning?

Organization & Team Dynamics

  • Do teams have the autonomy to redesign their own workflows around AI?
  • Can governance enable safe experimentation, or does every meaningful change require escalation?
  • Are we building the capability to change continuously, or planning one more transformation with a finish line?
  • Are we deliberately redesigning learning and career paths for a world in which AI performs more entry-level implementation work?

Across the triangle

  • Is one accountable team responsible for the business outcome, the workflow, the technology, and adoption?
  • Are decisions, metrics, and governance aligned across all three dimensions, or split across committees with different incentives?
  • If AI removes the current bottleneck, do we know where it will move next?
  • Are we optimizing local output, or the effectiveness of the whole system?

These questions are not a cure, but they reveal where the system is weak — and it is rarely only where the AI budget sits.

Closing

The Software Health Triangle did not need a new corner for AI. AI did not change the model — it raised the stakes. It can make software faster to produce, but not automatically better to decide, safer to operate, easier to adopt, or more valuable to customers.

The organizations that benefit most will not be those with the best models or the largest tool budgets, but the ones that change what they build, how they build it, and how their people work — as one connected system.

AI creates software faster. It does not make organizations healthier. That part is still our job.

Sources