Stuff about Software Engineering

Category: The Convergence of AI and Execution

AI is no longer scarce. Models are broadly accessible, and capabilities are rapidly commoditizing. That shifts the source of advantage away from the model itself and toward how effectively it is deployed, integrated, and scaled across real workflows.

The organizations that win are not those experimenting the most, but those embedding AI into execution—where it consistently improves outcomes, handles edge cases, and survives contact with reality. This is also why earlier frameworks sometimes need reinterpretation: what made sense as a classification of solutions or a discussion of trade-offs starts to look different once distribution and operational integration become the real differentiator.

When Implementation Becomes Cheap: Rethinking Value in Software Consulting

Introduction

There was a time when building software was the work.

Methods like Use Case Points (UCP) gave us a structured way to estimate implementation effort—because implementation was the dominant cost.

That assumption is now broken. AI coding agents have collapsed implementation time by an order of magnitude. At the same time, approaches like Rupify turn specifications into executable, verifiable inputs that can steer those agents [1].

This sets up a new tension.

The Real Tension: Speed vs. Correctness

The Wiggum Loop shows that you can brute-force progress with AI through rapid iteration [2]. But it also shows where that breaks: when failures are silent, slow, or irreversible. That is exactly the regime most enterprise systems operate in. So this is the core tension:

The Wiggum Loop is powerful precisely where it is dangerous. Fast iteration in domains where incorrect systems are costly. This is where Rupify resolves this tension. It does not slow the loop down. It constrains it.

It makes fast iteration safe enough to use in high-stakes environments by making intent explicit and verifiable.

The Failure Mode: Faster Divergence

Without that constraint, AI does not give you better outcomes. It just gives you incorrect systems, delivered quickly.

Organizationally, this looks like:

  • Systems that appear complete but encode the wrong logic
  • Silent misalignment between business intent and system behavior
  • Accelerated rework cycles where errors propagate faster than they are detected

The result is not efficiency. It is amplified waste. This is why specification becomes the control point.

The Inversion

This creates a structural inversion:

  • UCP still estimates human implementation effort
  • AI reduces actual implementation time to a fraction
  • Rupify ensures the output remains aligned with intent

So the traditional model—where effort ≈ implementation ≈ value—no longer holds.

UCP Was Measuring the Wrong Thing

You can still calculate UCP. But it no longer answers the original question: How long will this take to build?

That question is now nearly irrelevant, what remains is something more fundamental: How complex is the problem space?

UCP was always approximating this. So AI did not make UCP obsolete, it revealed what UCP was actually measuring all along.

Knowing complexity is crucial for coding with AI Agents [5].

A New Model

We end up with a new structure:

  • UCP measures problem complexity
  • Rupify translates complexity into executable intent [1]
  • AI agents handle implementation at near-zero marginal cost

What Consulting Becomes

This connects directly to outcome-based value models [4].

In this new model consulting is the discipline of reducing ambiguity. That is not a slogan. It is a structural shift.

It changes:

  • Staffing → fewer implementers, more domain modelers and specification engineers
  • Pricing → from time-based delivery to value of clarified and executable intent
  • Differentiation → ability to make complex systems unambiguous, not ability to build them

The scarce role is the person who can:

  • Extract intent from messy organizational reality
  • Structure it into a precise model
  • Express it in a form that machines can execute correctly

That capability becomes the bottleneck.

The Final Constraint: Can It Be Safely Realized?

Even perfect specifications are not sufficient.

They must be realized through a trustworthy system [3].

A correctly specified system built through a compromised pipeline is still a compromised system.

So the full model becomes:

  • Clarity of intent (Rupify)
  • Controllability of generation (AI agents)
  • Trustworthiness of realization (supply chain)

Remove any one of these, and the system fails.

The Shift

Software engineering is no longer about building systems.

It is about:

  • Describing them correctly
  • Constraining how they are generated
  • Ensuring they can be safely realized

Implementation has not disappeared, but it has lost its position as the center of value – and when that happens, everything around it has to be rethought.

Conclusion

Implementation is no longer the primary driver of cost, time, or value.

Value is created by reducing ambiguity, expressing intent precisely, and ensuring that intent can be safely realized.

  • AI accelerates execution
  • Rupify constrains it
  • UCP reveals the true complexity underneath

Consulting shifts from delivering software to making systems unambiguous and executable.

References

[1] https://birkholm-buch.dk/2026/04/09/rupify-executable-specifications-for-ai-assisted-software-engineering

[2] https://birkholm-buch.dk/2026/04/05/the-wiggum-loop-brute-forcing-business-with-ai/

[3] https://birkholm-buch.dk/2026/03/13/move-the-security-boundary-to-the-software-supply-chain/

[4] https://birkholm-buch.dk/2025/05/05/the-future-of-consulting-how-value-delivery-models-drive-better-client-outcomes/

[5] https://birkholm-buch.dk/2024/12/12/speed-vs-precision-in-ai-development/

AI Is Everywhere. Value Is Not (And It’s Not a Data Problem Either)

Introduction

Over the past year, AI adoption has exploded. In the Nordics, nearly every company now reports that it has implemented AI in some form. On paper, that should translate into a wave of productivity, growth, and competitive advantage. Only it doesn’t.

A recent BCG study (The Nordic AI Inflection Point: Value Creation or Value Bubble?) shows that while 99% of Nordic companies have adopted AI, only around 4% report significant returns on their investments. At the same time, executives expect AI to deliver 25–30% improvements in both revenue and cost.

This gap between adoption and value is not subtle and it’s not limited to the Nordics. A global enterprise study shows the same pattern (Enterprise AI adoption in 2026: Why 79% face challenges despite high investment):

  • Near-universal AI adoption
  • Heavy usage across employees and executives
  • Only a minority seeing real business impact

More strikingly, over half of executives report that AI adoption is creating internal tension rather than clarity — exposing gaps in strategy, ownership, and execution.

AI is not just failing quietly. It is actively stressing organizations that are not designed to absorb it. Which raises an uncomfortable question: Are we creating value — or a value bubble?

This Is Not a New Problem

In a previous post, I argued that AI doesn’t create advantage but distribution does based on facts that:

  • AI is becoming commoditized
  • Models are widely accessible
  • Tools are rapidly diffusing

So advantage cannot come from AI itself. It must come from how AI is embedded, scaled, and operationalized. The BCG findings are a direct confirmation of this. So AI is everywhere, but execution is not.

The Wrong Debate: Data Before AI

At the same time, many organizations seems to be stuck in a different discussion: “We need better data before we can scale AI.”

I’ve argued the opposite in “AI for data — not data before AI” and that waiting for perfect data is one of the most reliable ways to delay value indefinitely.

Data improves when it is used:

  • In real workflows
  • Under real decisions
  • With real feedback loops

So we end up with two truths:

  • AI alone does not create advantage
  • Data alone does not unlock AI

And yet, most organizations behave as if one of them will.

The Two Traps Killing AI Value

What we see in practice is a predictable pattern.

1. The Tool Trap

Companies deploy AI as tools:

  • Copilots
  • Assistants
  • Automation add-ons

These deliver local gains but they don’t change outcomes, they don’t scale and they don’t compound.

2. The Foundation Trap

Others go the opposite direction:

  • Multi-year data programs
  • Master data management initiatives
  • Platform modernization

AI becomes a future promise and not a present capability.

The False Choice

This leads to a false dichotomy:

  • AI first
  • Or data first

The reality is neither.

  • You don’t get better data before AI
  • You don’t get value from AI without execution

Both positions assume a linear path and AI value is not linear.

What Actually Works: AI in the Loop

The companies that are capturing real value are doing something different.

They are not thinking in steps like: Data → Platform → AI → Value

They are building feedback systems: AI → Usage → Better Data → Better Workflows → Scale → Value

But this only becomes real when you look at how it is designed.

A repeatable pattern looks like this:

  • Start with a concrete workflow (e.g. demand planning, pricing, campaign execution)
  • Apply AI to improve one critical decision point
  • Use the output to expose data gaps and inconsistencies
  • Fix only the data that matters for that workflow
  • Expand AI across adjacent steps
  • Gradually connect the process end-to-end

For example:

  • Deploy AI in demand forecasting
  • Uncover inconsistencies in product hierarchies and sales signals
  • Fix those selectively
  • Extend into inventory and replenishment

Over time, the workflow becomes:

  • More accurate
  • More automated
  • More integrated

This is not just iteration.

It is system design.

Good AI systems are not built top-down. They are grown through use — and then engineered for scale.

From Tools to Workflows

The BCG report highlights a critical distinction:

  • Most companies invest in tools
  • Leaders invest in workflows

That difference matters.

Because:

  • AI applied to tasks creates efficiency
  • AI embedded in workflows creates advantage

Why Most Companies Stall

When AI fails to scale, it’s rarely about the models.

It’s about the system.

  • Tool Trap → Fragmentation
  • Foundation Trap → Delay

Both lead to the same result:

  • Pilots everywhere
  • Duplication of effort
  • No compounding value

The deeper causes are structural:

  • Fragmented data
  • Decentralized ownership
  • Unclear decision rights
  • Limited execution capacity
  • AI treated as IT

The system is not designed to absorb and scale AI.

So AI remains additive and not transformative.

AI Doesn’t Fail. Systems Do.

AI is not underdelivering, but organizations are.

Or more precisely: AI doesn’t fail, it exposes systems that were already failing.

What we are seeing is not an AI gap, it’s a system gap:

  • Between ambition and execution
  • Between tools and transformation
  • Between experiments and scale

The Trilogy

Across three posts, the pattern becomes clear:

  1. AI doesn’t create advantage — distribution does
  2. AI for data — not data before AI
  3. AI is everywhere. Value is not

Together: AI value is not created by technology or data alone, it’s created by systems that connect them.

The Next Phase of AI

The next phase will not be defined by better models. It will be defined by better systems.

Today’s tools are built as standalone assistants:

  • Copilots
  • Chat interfaces
  • Isolated automation

They optimize individuals and not systems.

The tools themselves reinforce the Tool Trap. Which means: Organizations are not just using AI incorrectly and they are buying products that make correct usage harder.

What This Means in Practice

If you want to capture AI value:

  • Stop measuring progress by tools
  • Stop waiting for perfect data
  • Stop layering AI on top

Instead:

  • Start with workflows
  • Build feedback loops
  • Design for reuse
  • Treat AI as part of the operating model

This is not a maturity curve, it’s a design choice.

Conclusion

You don’t win with AI because you have access to it. You don’t win because your data is perfect. You win when your organization can turn AI into systems that scale.

Advantage comes from system design:

  • Not tools
  • Not data in isolation
  • Not default ways of working

Because in the end: AI doesn’t create advantage, distribution does – and distribution is built through systems — whether you design them intentionally or not.

The difference is simple: Some companies design them, but most don’t.

When the Model Breaks

Introduction

Over the past year, I’ve written three posts that—at the time—felt consistent.

First, I described four categories of AI solutions, arguing that complexity determines where AI works and then, I introduced the trade-off between speed and precision, where fast systems are imprecise and precise systems are slow.

Both were true at the time.

Lastly I introduced the Wiggum Loop which argues that institutional memory is useless.

The original model

The underlying assumption in the two first posts was simple. AI is most effective when problems are well-bounded, precision requirements are low, and iteration costs are small. It struggles when precision is critical, domain knowledge is deep, and errors are expensive. In other words, AI accelerates simple work, while humans remain essential for complex work.

The crack in the model

The Wiggum Loop challenges that assumption. If solutions can be reached through repeated iteration rather than upfront understanding, then precision is no longer a prerequisite—it becomes something you converge on. This changes the equation. Complexity no longer blocks AI in the same way; it simply increases the number of iterations required.

From capability to convergence

The original model was about capability—what AI can do well. The emerging model is about convergence—how quickly a system can explore the solution space and arrive at something that works. Once iteration is cheap and automated, the constraint shifts. It is no longer about whether we can solve a problem, but whether we can recognize when it has been solved.

Reinterpreting the three posts

Seen together, the three posts describe a transition. 

The model does not disappear—it shifts.

The new boundary

The real boundary is no longer complexity or precision. It is whether a problem can be expressed in a way that supports iteration. That requires a clearly defined outcome, explicit constraints, and a way to evaluate results. If those exist, iteration can often replace deep understanding; if they do not, it cannot.

This does not remove expertise—it relocates it. The hard part is no longer solving the problem directly, but defining what success looks like, encoding the right constraints, and deciding how results are evaluated.

What this means for organizations

This is not just a technical shift—it changes how organizations create value. Historically, value came from expertise, experience, and accumulated knowledge. Increasingly, it comes from defining problems clearly, encoding constraints explicitly, and running and governing iterative systems. The center of gravity moves.

The uncomfortable alignment

Taken together, the three posts lead to a slightly uncomfortable conclusion. Much of what we treat as essential organizational knowledge is actually context-bound constraint—decisions made under conditions that no longer apply.

If iteration can rediscover solutions faster than we can recall them, then memory becomes less valuable than exploration. That has consequences. Expertise shifts from knowing answers to defining problems and constraints. Institutional memory becomes less of an authority and more of a hypothesis archive—useful, but not decisive. Roles built around recall and experience start to erode, while roles focused on framing, validation, and governance become more central.

This does not remove humans, but it changes what humans are for—from remembering why things failed to defining what success looks like.

Where this leaves us

The original model still holds, but it is no longer the full picture. AI is not just a tool for solving known problems faster—it is becoming a system for exploring unknown solutions through iteration.

There is a subtle tension here. This trilogy itself depends on cumulative understanding, where each post builds on the last—a small act of institutional memory arguing against institutional memory. Exploration does not replace memory entirely; it changes what kind of memory matters. Constraint-memory becomes less valuable, while model-building and interpretation become more important.

Final thought

We started by asking where AI works. We then asked how precise it needs to be. The emerging question is different: how fast can we iterate—and how well can we recognize success?

That is the thread connecting all three posts, and it is where the model begins to break.

AI doesn’t create advantage -distribution does

Introduction

In the early 20th century, factories did not gain much by simply replacing steam engines with electric motors. The real gains came later, when they reorganized how work was done—redesigning layouts, workflows, and roles to take advantage of distributed power [9]. AI is following the same pattern. The technology itself is not the differentiator. How it is distributed inside the organization is.

Across domains, the pattern is already visible.

In scientific research, systems like AlphaFold and other AI models in biology and chemistry are shifting the frontier of what good looks like. Researchers who integrate these tools into their workflows move faster, explore more hypotheses, and expand output. Others are not just slower—they are operating below a moving baseline.

In software engineering, the dynamic is different but related. AI compresses the time required to produce code, but also compresses the time required to produce failure. Teams that combine strong engineering practices with AI accelerate safely. Teams that rely on generated output without discipline introduce risk at speed.

In both cases, the effect is not uniform improvement. It is divergence.

The hidden failure mode: uneven distribution

What is emerging is not a lack of AI capability, but an uneven distribution of it.

Some individuals and teams gain early access, experiment, and build fluency through use. Others wait for guidance, are constrained by governance, or never fully integrate AI into how they work. Over time, this creates a gap in capability that compounds.

This is where the A and B teams begin to appear—not as a deliberate strategy, but as a consequence of how access, learning, and incentives are structured.

AI literacy beats AI elites

Organizations that scale AI successfully distribute capability rather than concentrate it [1][2].

When AI is centralized, teams depend on specialists. Demand exceeds capacity, and most of the organization remains passive. When capability is distributed, teams solve problems locally, and learning happens through application rather than instruction.

McKinsey consistently finds that only a minority of companies capture meaningful value from AI, and those that do embed it across functions rather than isolating it [1]. Experimental evidence reinforces that productivity gains depend on how individuals integrate AI into their work, not just whether they have access to it [11][12].

The constraint is not the model. It is whether people know how to use it effectively in context.

The Center of Excellence trap

The default enterprise response is to centralize AI into a Center of Excellence. This improves oversight and consistency, but it also creates a structural bottleneck. Every team now depends on a central unit for access, prioritization, and delivery, which does not scale with demand.

More importantly, it concentrates knowledge. Patterns, practices, and hard-won lessons accumulate inside the CoE rather than flowing through the organization. Capability becomes something you request, not something you build.

This is why many organizations are exploring federated and embedded operating models [3][4], though the transition is often incomplete and uneven. The goal is not just to distribute execution—it is to distribute capability.

This is where platform engineering provides a better mental model. Instead of acting as a delivery function, the central team builds golden paths: paved, opinionated ways of working that make the right thing the easy thing. Tooling, templates, guardrails, and reusable components are exposed directly to teams, enabling them to move independently while staying within defined boundaries.

The difference is fundamental. A CoE pulls work toward itself. A platform pushes capability outward. One creates queues. The other creates flow.

If AI is treated as a centralized service, it will scale linearly at best. If it is treated as a platform, it can scale with the organization.

AI creates uneven gains, not uniform uplift

Research consistently shows average productivity gains in the range of 10–20%, combined with substantial variation across users and tasks [5][10][12]. The variation is the important part.

In some contexts, less experienced workers benefit significantly because AI transfers best practices and reduces barriers to entry. In others, highly skilled workers gain more when operating within the effective frontier of the technology. Outcomes depend on skill, task, and how well AI is integrated into the workflow.

The result is not a level playing field, but a changing gradient. People and teams that adapt effectively accelerate. Those who do not fall behind, even when they have access to the same tools.

Governance is becoming the bottleneck

Organizations respond to AI risk by increasing control: approvals, restrictions, and policy layers. While necessary, this often introduces systemic friction.

Industry and institutional research consistently identify organizational barriers—not technical limitations—as the primary constraint on AI value creation [1][3]. The issue is less about building capability and more about enabling its use.

A more effective approach is proportional governance. Low-risk, individual use cases require minimal control. Team-level workflows benefit from lightweight oversight. High-impact, enterprise-critical systems require full governance. This aligns with risk-based approaches such as those from the OECD [8].

Without this proportionality, governance becomes a bottleneck rather than a safeguard.

How the divide compounds

The gap between A and B teams develops through small, compounding differences in access, learning environments, and culture.

Some teams have direct access to tools and are encouraged to experiment. Others operate through restricted interfaces and formal processes. Some learn through iteration; others wait for approval.

Over time, these differences accumulate. One part of the organization develops new capabilities and ways of working, while another continues with established practices. Eventually, they are no longer operating at the same level.

Distribution requires giving up some control

Avoiding this outcome requires accepting a degree of decentralization. Teams need the ability to experiment locally, and organizations need to tolerate variation in tools and approaches.

This introduces a temporary phase where things feel less controlled and less consistent. That phase is where learning happens. Eliminating it too early suppresses adoption and reinforces the divide.

AI as infrastructure

If AI remains confined to specialists, organizations create internal inequality and limit their ability to adapt. If it becomes embedded in everyday work—more like electricity than expertise—it enables continuous, distributed improvement.

The objective is not to build a stronger AI team, but to remove the distinction altogether. Because the organizations that benefit most from AI will not be those with the most advanced models, but those where its use is widespread, routine, and integrated into how work gets done.

References

[1] McKinsey & Company – The State of AI
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

[2] Boston Consulting Group – Artificial Intelligence Capabilities
https://www.bcg.com/capabilities/artificial-intelligence

[3] Deloitte – State of AI in the Enterprise
https://www2.deloitte.com/us/en/insights/focus/cognitive-technologies/state-of-ai-and-intelligent-automation-in-business-survey.html

[4] Gartner – How to Scale AI in the Enterprise
https://www.gartner.com/en/articles/how-to-scale-ai-in-the-enterprise

[5] National Bureau of Economic Research – Generative AI at Work
https://www.nber.org/papers/w31161

[8] OECD – AI Principles
https://oecd.ai/en/ai-principles

[9] Paul A. David – The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox
https://doi.org/10.3386/w5099

[10] Quarterly Journal of Economics – Generative AI at Work
https://academic.oup.com/qje/article/140/2/889/7990658

[11] MIT Sloan – How Generative AI Can Boost Highly Skilled Workers’ Productivity
https://mitsloan.mit.edu/ideas-made-to-matter/how-generative-ai-can-boost-highly-skilled-workers-productivity

[12] MIT Economics – Experimental Evidence on Generative AI
https://economics.mit.edu/sites/default/files/inline-files/Noy_Zhang_1.pdf

Four Categories of AI Solutions

Introduction

When driving value from generative AI (GenAI) it’s important to choose the right approach in order to be able to get a return on investment. This page attempts at explaining possible approaches and required resources.

Takers, Shapers and Makers

There seems to be 3 major categories of GenAI adopters according to McKinsey and Gartner:

McKinseyGartnerDescription
TakersQuick WinsFocus on utilizing existing GenAI tools and models for productivity improvements with minimal customization.

These initiatives typically have short time to value and are task-specific, aiming for immediate efficiency gains in routine tasks.
ShapersDifferentiating Use CasesEngage in integrating GenAI tools with proprietary data or adapting them for specific applications.

These initiatives aim to achieve competitive advantages, involving medium time to value with higher costs and risks than quick wins.

They leverage GenAI to extend current processes and create unique value propositions.
MakersTransformative InitiativesConcentrate on developing new GenAI models or tools for specialized applications, with the potential to transform business models and markets.

These are the most ambitious initiatives, characterized by high cost, complexity, and risk, and a long time to value.

They aim for strategic benefits that may be difficult to quantify initially.

TCO/ROI

The Total Cost of Ownership (TCO) and Return on Investment (ROI) for GenAI adoption across takers, shapers, and makers categories involve several considerations, including hidden costs, strategic implications, and potential benefits.

Gartner offers insights on measuring GenAI ROI, advocating for a business case approach that simulates potential cost and value realization across GenAI activities. This approach categorizes investments into quick wins, differentiating use cases, and transformational initiatives. Quick wins focus on immediate productivity improvements with short time to value, differentiating use cases aim at competitive advantage with medium time to value, and transformative initiatives have the potential to upend business models with longer time to value but higher costs and complexity. The guide emphasizes the importance of balancing financial returns with strategic benefits, which might be difficult to quantify initially.

Source: https://www.gartner.com/en/articles/take-this-view-to-assess-roi-for-generative-ai.
Red box is added by me, see conclusion below.

Builders

I’m introducing an extra “Builders” category into the GenAI adoption landscape beyond merely adopting or adapting, Builders take a step further by crafting bespoke extensions and plugins for GenAI platforms. This initiative is driven by the ambition to tackle intricate, multi-step workflows that typically demand considerable human intervention. The essence of being a Builder lies in their ability to not just work with GenAI but to enhance its core capabilities, enabling solutions that seamlessly bridge various systems and processes. This approach demands a blend of creativity, technical prowess, and a deep understanding of both the technology and the problem domain.

CategoryDescriptionRequired People Resources/SkillsTools
TakersUtilize existing GenAI tools for productivity improvements with minimal customization.

Aimed at immediate efficiency gains in routine tasks with short time to value.
Basic understanding of AI/ML conceptsSkills in integrating and configuring APIs

Ability to adapt third-party GenAI tools to existing workflows
Microsoft Copilot

Microsoft Copilot Plugins

Enterprise “Chat”-GPTs
ShapersIntegrate GenAI tools with proprietary data or adapt them for specific applications to achieve competitive advantages, involving medium time to value with higher costs and risks.Low/No-code developers

Domain experts for data interpretation

Project managers with a technical background
Retrieval Augmented Generation (RAG)

Microsoft Copilot Studio

Microsoft Azure AI Studio
BuildersDevelop custom solutions or extensions to GenAI platforms to solve complex, multi-step processes that usually require significant human effort.Advanced programming skills in relevant languages

Data scientists for model tuning

Experience with GenAI frameworks

Systems integration expertise

Creative problem-solving abilities
Microsoft Copilot Extensions

Microsoft PromptFlow

LangChain

LangGraph

LlamaIndex

AutoGen

CrewAI

(OpenAI Swarm)

LLM Function Calling

LLM Routing

LLM Threat Modelling

LLM Security
MakersDevelop new GenAI models or tools for specialized applications with the potential to transform business models and markets.

Characterized by high cost, complexity, and risk, with a long time to value.
Expertise in deep learning and neural networks

Experience in building and training large-scale AI modelsStrong research and development background

Ability to work with high-performance computing resources
LLM Models

LLM Frameworks

LLM Fine-Tuning

(LLM Creation and Training)

The “Builders” category fills the gap between “Shapers,” who mainly adapt existing models for their unique needs, and “Makers,” who create new GenAI models from scratch. Builders leverage powerful frameworks and platforms to create bespoke solutions that automate complex workflows, potentially revolutionizing how businesses approach process automation and efficiency. This distinction underscores the evolving landscape of GenAI adoption, highlighting the increasing sophistication and customization capabilities available to organizations.

Conclusion

The red box on the image above indicates that solutions made in the Takers and lower Shapers category are likely to be overtaken by standard solutions from vendors and the plethora of SaaS AI offerings appearing on a daily basis. Caution should be used when choosing to invest in solutions in this area unless quick wins are important.

Clearly it’s important to have a strategic, well-planned approach to integrating GenAI with emphasis on organizational readiness, skill development, and a focus on applications that offer a competitive advantage – otherwise GenAI just becomes a technology looking for a problem like Blockchain.

References

© 2026 Peter Birkholm-Buch

Theme by Anders NorenUp ↑