Peter Birkholm-Buch

Stuff about Software Engineering

Cheap Code Makes Software Engineering More Important

2026-09-16 /

At vibe coding meetups, I keep encountering the same excitement: people who have never developed software are suddenly building applications. Screens appear. Buttons work. Data gets saved. Something that previously required a development team becomes possible in an afternoon.

That is a remarkable capability. It also makes it remarkably easy to underestimate what remains.

A working application is the visible part of an iceberg. Below the waterline sit authorization boundaries, data integrity, concurrency, failure recovery, observability, dependency management and the ability to change the system safely.

These concerns rarely feature in the first demonstration. They become painfully visible when people start depending on the software.

My concern is that organizations are mistaking the ability to produce that demonstration for the ability to engineer and maintain the system beneath it. People gain production responsibility before they have acquired the judgment needed to carry it.

Now, as coding agents drift, contradict earlier decisions and struggle with growing codebases, specifications are being rediscovered. Write down what you want. Ask structured questions. Decompose the work. Define acceptance criteria. Give the agent clearer boundaries.

I welcome those practices. What worries me is the belief that following a specification-driven development method is sufficient to produce good software.

A method can help uncover missing requirements. It cannot guarantee that the questions cover what matters, that the answers are sound, or that the resulting design is appropriate. Someone still needs to recognize the omissions and challenge the assumptions.

An inexperienced builder may describe the visible behavior in considerable detail while leaving everything below the waterline unresolved. The resulting document can look comprehensive. The agent can implement it faithfully. The tests can pass.

The system can still be insecure, fragile and expensive to maintain.

That is the false confidence I worry about: believing that because we have followed a method, we have specified the whole system.

Dex Horthy makes a related argument in Harness Engineering Is Not Enough. He describes the difficulty of maintaining codebase quality when agents optimize for completing individual tasks. His response is to bring human steering, program design and code review firmly back into the process.

He also acknowledges that he cannot prove his broader claim about models’ long-term maintainability limitations. That distinction matters. His experience describes a credible failure mode; it does not establish that every AI-assisted codebase will deteriorate.

There is nevertheless evidence supporting the concern.

The public summary of Gartner’s Predicts 2026 report identifies generated-code quality risks and calls for architecture-first validation and explicit boundaries between human and AI responsibilities. That is analyst guidance, rather than experimental proof, but it places architectural discipline squarely in the response.

McKinsey’s developer study found productivity gains and marginally improved code quality when developers actively worked with the tools. It also identified human expertise as crucial for finding errors, supplying organizational context and navigating complex requirements. The developers’ judgment was part of the successful result.

The confidence problem has empirical support too. In Do Users Write More Insecure Code with AI Assistants?, researchers found that participants using an AI assistant produced less secure code while being more likely to believe their code was secure. The study used an older model, so it cannot establish today’s vulnerability rate. It does demonstrate how assistance and misplaced confidence can coexist.

The maintenance evidence is more mixed. A study involving 151 participants, overwhelmingly professional developers, found no significant downstream maintainability degradation within its experimental scope. That limits any blanket claim that AI necessarily makes software harder to maintain. It also leaves open my concern about inexperienced builders taking production responsibility without comparable engineering support.

In The Bottleneck Moved, I argued that cheaper implementation shifts the constraint toward ambiguity, architectural clarity, decomposition and validation. Faster code generation also lets us accumulate the consequences of unresolved decisions faster.

That changes what we should ask experienced software people to do.

Bring them into the work while the solution is being shaped. Have them establish the boundaries, examine the data model, challenge assumptions and decide how correctness will be demonstrated. Let AI accelerate implementation inside those decisions. Keep engineers accountable for reviewing the result and making it operable.

This does not require every prototype to undergo a full production process. It requires an honest distinction between exploring an idea and accepting responsibility for a running system.

Nor is a degree or job title sufficient. The capability we need is the ability to reason about a system beyond its visible behavior, recognize the limits of our understanding and investigate what we have missed.

My prediction is that we are building toward a wave of maintenance debt and security remediation as today’s impressive demonstrations become tomorrow’s business-critical systems. Much of the bill will arrive after the original excitement has faded, landing with people who had no part in the decisions that created it.

Perhaps, by the time that wave arrives, AI will have developed the architectural judgment needed to repair what we are producing today. I hope so. But relying on tomorrow’s AI to rescue today’s engineering decisions seems an extraordinary way to run software development.

Hosting Location ≠ Jurisdictional Independence

2026-09-14 /

Executive Summary

Running a workload in an EU data center is not the same as operating independently of non-EU jurisdictions. For sovereignty, the important questions are not only where the infrastructure is physically located, but also who owns, controls and operates it, which legal regimes apply to the provider, and whether a third-country government could materially affect continued access.

If AI becomes critical enterprise infrastructure, jurisdictional resilience should be treated as a business-continuity concern rather than merely as a data-residency or procurement issue.

Hosting Location and Jurisdiction Are Different Things

Cloud providers increasingly offer products described as EU sovereign, European sovereign or sovereign cloud. These offerings can provide real controls, including EU data residency, locally operated infrastructure, restricted administrative access, EU-based personnel, encryption and key-management controls, and contractual commitments around support and operations.

Those controls matter, but they do not by themselves establish jurisdictional independence. A service can be physically hosted and operationally isolated in Europe while the ultimate provider, parent company, software supply chain or control structure remains subject to another jurisdiction.

The practical sovereignty test is therefore whether geopolitical, legal or trade changes in a third country could materially affect access to the service.

Europe Is Beginning to Distinguish Levels of Sovereignty

The European Commission’s current Cloud and AI Development Act framing is useful because it separates physical location from deeper forms of sovereignty. The proposed framework describes four levels:

  1. Level 1 — data is processed and stored in infrastructure located in the EU.

  2. Level 2 — providers must demonstrate independence from third countries and transparency over their software supply chain.

  3. Level 3 — providers must be owned and controlled from the EU, with additional requirements.

  4. Level 4 — providers provide full transparency and control over the software supply chain and no interference from a third country.

Source: European Commission — Cloud and AI Development Act

The important point is that physical location is only one dimension. Independence, ownership, operational control and freedom from third-country interference are separate considerations.

Data Residency Is Not Sovereignty

Data residency answers where data is stored and processed. Sovereignty is broader: who can access and operate the service, which legal regimes can compel the provider, who controls the software and infrastructure, and whether the service can continue if geopolitical relationships deteriorate.

European data-protection guidance following the Schrems II judgment already reflects this distinction by requiring organizations to consider whether laws and practices in a third country could prevent a provider from complying with European safeguards.

Source: European Commission — Standard Contractual Clauses and Schrems II

The same reasoning is relevant to strategic technology dependency even when the immediate issue is not personal-data transfer.

Sovereignty Is Also About Continuity

For organizations, the more important issue may be continuity of strategic capability rather than compliance alone. If AI becomes embedded in research, supply chain, commercial operations, software engineering and knowledge work, dependence on a single geopolitical technology ecosystem becomes a business risk.

The relevant scenario is not necessarily that a provider voluntarily chooses to stop serving us. Regulation, sanctions, export controls, national-security measures or broader geopolitical events can constrain what a provider is legally permitted to deliver. In that situation, contractual assurances about an EU-hosted region are only as durable as the legal and operational independence behind them.

This should therefore be framed as resilience rather than vendor distrust. The issue is whether strategically important AI capabilities should depend entirely on continued permission from one jurisdiction.

Architectural Implication

The answer is not to abandon US hyperscalers or frontier-model providers. We should use the best services available where they create value, while ensuring that strategically important AI capabilities have a credible path to alternative jurisdictions and providers if needed.

That implies designing for:

  • portable workloads

  • model independence where practical

  • open or replaceable interfaces

  • data portability

  • infrastructure portability

  • open models as a credible fallback

  • access to EU-controlled compute and inference

  • avoidance of dependencies that cannot be reproduced outside a single provider ecosystem

This is consistent with the EU Data Act, which pushes cloud providers toward interoperability, switching and open interfaces so customers can move between providers without losing data or functionality.

Sources:

Sovereign AI Should Be an Option, Not Necessarily the Default

This is not an argument that every workload should immediately run on European-owned infrastructure. It is an argument for maintaining a viable option.

If strong open models continue to close the capability gap with proprietary frontier models for many enterprise workloads, then a sovereign execution path becomes increasingly practical. That path could involve European-owned GPU infrastructure, European inference providers, open-weight models, managed or self-hosted open-model inference, European model providers, and workloads capable of moving between US, EU and other regional ecosystems.

The strategic value is that organizations would not need to create that capability from scratch after a crisis has already begun.

A Useful Test

For any service described as sovereign, ask what legal and operational mechanisms would prevent a government outside the EU from suspending, restricting or otherwise affecting the service through the ultimate provider. If the answer is only that the servers are located in Europe, then the service provides data residency; that alone does not establish jurisdictional independence.

Conclusion

Sovereignty is a spectrum, not a hosting-region label. Physical location, operational separation, personnel and key control all matter, but so do ownership, jurisdiction, software supply-chain control and the ability to operate independently of third-country intervention.

For strategic AI infrastructure, the objective should be to avoid single-jurisdiction dependency and preserve a credible path to continue operating critical AI capabilities under European legal and operational control if circumstances require it.

Hosting location ≠ jurisdictional independence.

Anti-Pattern: Using AI as a Runtime for Deterministic Workflows

2026-08-11 /

AI can be remarkably effective at turning vague, manual work into software. But that does not mean an AI model should execute the resulting workflow forever.

A common anti-pattern is to use an AI agent as the runtime for stable business logic: reading the same kind of file, rediscovering its structure, applying known mappings, and generating the same kind of output on every run.

The first demo may look impressive. Repeated in production, it becomes expensive, fragile, difficult to test, and hard to govern.

Context

This pattern appears in repeatable work such as file transformation, CSV or Excel processing, data mapping, schema validation, reference-data lookup, and template configuration.

A typical workflow accepts a file and some known context—such as a site, market, customer, or product—then applies established rules, validates the result, and returns a configured output file.

These are primarily workflow and contract problems, not reasoning problems.

The Anti-Pattern

The anti-pattern is using an AI model as the execution engine for deterministic business logic.

Each run asks the model to rediscover the same structure, reinterpret the same rules, inspect the same reference data, and reconstruct the same transformation. The system consumes tokens as if the problem were new, even though the workflow is stable.

Stable, repeatable transformations should be implemented as deterministic workflows, not repeated AI reasoning sessions.

Why It Fails

  • High marginal cost: every run spends tokens on parsing, reasoning, and validation.
  • Poor determinism: the same input may not reliably produce the same output.
  • Hidden business logic: rules live in prompts and examples instead of reviewable code and configuration.
  • Weak validation: correctness depends on model behavior rather than explicit, testable contracts.
  • Limited control: failures are harder to reproduce, debug, audit, and explain.

The deeper problem is that the design confuses discovery with execution. A successful proof of concept is mistaken for a sustainable architecture.

The Better Pattern: Compile the Workflow

Separate design-time AI assistance from runtime execution.

At design time, use AI to:

  • understand the existing manual or spreadsheet-based workflow;
  • identify schemas, mappings, rules, and edge cases;
  • generate parser and transformation code;
  • create validation tests and documentation.

At runtime, use deterministic software to:

  • parse the input;
  • validate required fields and schemas;
  • look up governed reference data;
  • apply known mappings;
  • produce the output and a validation report.

The implementation might be a script, web application, serverless function, workflow step, or agent action. The form is secondary. The important part is deterministic execution behind a stable contract.

Example

Suppose a spreadsheet performs site-specific file configuration.

The wrong solution is an agent that repeatedly reads the spreadsheet, interprets reference files, reasons about the necessary changes, and generates a CSV.

The better solution is to reverse-engineer the logic once, define the input and output schemas, move reference data into governed configuration, implement the transformation in code, and add tests. An agent may still provide the conversational interface, but it should call the deterministic workflow rather than embody its logic.

When Runtime AI Is Appropriate

AI still belongs at runtime when the task requires genuine interpretation:

  • the input is novel or its structure changes constantly;
  • the output requires judgment, summarization, classification, or explanation;
  • the workflow is exploratory and has not stabilized;
  • codifying deterministic rules would cost more than repeatability is worth.

Once a workflow stabilizes, move it from repeated reasoning into deterministic execution.

Detection Signals

You may be using this anti-pattern if people say:

  • “The agent needs to understand the spreadsheet every time.”
  • “It works when I explain it carefully.”
  • “Sometimes it creates the file correctly.”
  • “We need more prompt guardrails.”
  • “It consumes many tokens, but the task is always the same.”

Rule of Thumb

If the same input, reference data, and context should always produce the same output, the runtime should be deterministic.

Use AI to build the machine, not to act as the machine.

The goal is not to spend tokens forever. It is to convert repeated reasoning into reusable capability.

The Bottleneck Moved

2026-05-20 /

For years, the dominant constraint in software engineering was implementation cost. Writing software was expensive. Changing it was expensive. The whole discipline organized itself around that fact — estimation, sprints, backlogs, delivery teams — because throughput was the bottleneck.

AI is dismantling that bottleneck faster than most organizations have been able to think about what replaces it.

But there’s a less-noticed shift happening alongside the capability story. Quietly, and then quite visibly, the major AI vendors are moving coding workflows toward consumption-based pricing. GitHub Copilot has introduced premium requests. Anthropic has repeatedly adjusted Claude Code access as demand exploded. OpenAI has separated agent-style workflows into explicit credit models for enterprise use. The details differ — different token pools, different rate limits, different structures — but the direction is consistent: frontier inference is not economically unlimited, and the vendors are starting to price it that way.

This matters more than it might appear, for one reason: AI-assisted development is not reducing demand for software. It’s accelerating it. Developers produce more. Non-developers can now produce some. Agents execute implementation work in parallel. If software was already eating the world, AI is increasing the bite rate.

Which means total inference demand is likely to rise faster than efficiency gains bring costs down. Even as models get cheaper per token, the sheer volume of generated code, tests, pipelines, reports, and scaffolding will grow. Organizations routing large amounts of that work through frontier reasoning models are building a cost structure that may become uncomfortable quickly.

The current pattern of AI-assisted development tends to look like this: open a long-running session with a flagship model, iterate continuously, keep large context windows alive, regenerate as needed. It works. The problem is what it’s spending expensive reasoning capacity on.

A significant portion of that work is not actually ambiguous. It’s repetitive. Deterministic. Structurally predictable. Generating a stable HTML report structure for the fifteenth time doesn’t require the same model that helped you design the architecture. Implementing a transformation you’ve already fully specified doesn’t require frontier-level reasoning. But because the workflow isn’t designed to distinguish between the two, it routes everything through the same expensive path.

That’s partly an economic inefficiency. But it’s also a signal. If implementation continuously requires frontier-level reasoning, that’s usually not a model problem — it’s a decomposition problem. It means ambiguity that should have been resolved upstream is still alive in the work.

Historically, you could absorb that ambiguity because implementation throughput was the real constraint anyway. When implementation gets cheap, the constraint moves. What’s left is ambiguity, architectural clarity, decomposition quality, validation, and organizational alignment. That’s where the work now actually is.

The architectural implication is straightforward, even if acting on it isn’t. Use stronger models where ambiguity and interpretation are genuinely high — architecture, requirements, tradeoff analysis, decomposition, synthesis. Once that work is done and structure has been established, the remaining implementation should be deterministic enough that it doesn’t need the same reasoning capacity.

I’ve been exploring what this looks like in practice through two experimental repositories, Rupify and Speckify. Rupify concentrates expensive reasoning at the front of a workflow: AI-assisted stakeholder interviews, requirements normalization, formal specification generation. The goal is to resolve ambiguity deliberately and early, producing canonical artifacts that downstream work can execute against. Speckify then takes those specifications and decomposes them into atomic, traceable implementation units — work that’s structured enough that smaller, cheaper models can handle it reliably.

The point isn’t “better AI coding.” It’s redesigning the workflow so that frontier reasoning gets used once, where it’s genuinely needed, rather than continuously throughout the entire delivery cycle. The economics look very different when you do that.

For a while, the dominant question in AI-assisted engineering was capability: which model, which agent, which coding assistant. That question isn’t going away. But another constraint is now becoming visible alongside it.

The organizations that scale this well probably won’t be the ones that put AI everywhere. They’ll be the ones that figure out where ambiguity actually lives in their workflows, structure everything else aggressively, and stop paying frontier-model prices for work that stopped being uncertain three steps ago.

The competitive advantage isn’t more AI. It’s better placement.

When Implementation Becomes Cheap: Rethinking Value in Software Consulting

2026-04-16 /

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 Only Creates Value When Integrated into Execution

2026-04-15 /

Introduction

Over time, I’ve written a number of posts on AI, software engineering, leadership, and how we apply these in practice at Carlsberg Research Laboratory. They were not intended as a single narrative—but taken together, a clear pattern emerges.

Across these posts, the same themes keep surfacing: AI is not the hard part, execution is. The real constraints are people, organizational capability, and how effectively we integrate new technology into how work actually gets done. Individual topics—AI patterns, governance, developer experience, and scientific computing—are all facets of the same underlying problem.

Looking across this body of work, it naturally clusters into six themes. Together, they describe a simple idea:

AI only creates value when it is systematically integrated into execution.

The sections below outline these themes and link to the underlying posts.

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.

Posts:

  • When Implementation Becomes Cheap: Rethinking Value in Software Consulting

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

  • When the Model Breaks

AI as a Capability Enabler

AI should not be approached as a collection of isolated use cases or one-off solutions. It is better understood as a set of reusable capabilities—classification, generation, retrieval, summarization, reasoning, and automation—that can be composed into systems and patterns.

The shift is from “building AI features” to “building AI-enabled systems,” where value comes from combining these capabilities with data, workflows, and developer experience in a repeatable way. When approached this way, AI becomes an enabler that can strengthen existing platforms and practices rather than a separate, exotic layer of technology.

Posts:

  • Patterns for Artificial Intelligence Solutions

  • GitHub Copilot drives better Developer Experience

  • Four Categories of AI Solutions

The Human Factor: People Skills and Organizational Capability

The primary constraint in AI adoption is not technology. It is people and organizational capability. New roles emerge, expectations shift, and the ability to continuously learn becomes critical as tools, models, and practices evolve faster than most organizations are used to.

This creates pressure not only on hiring and role design, but also on time itself. If teams are run at full utilization, they lose the capacity to learn, adapt, and absorb change. Success depends on building teams that can translate between domain, technology, and business, while also creating enough room for skills to evolve before they become obsolete.

Posts:

  • The Half-Life of Skills: Why 100% Utilization Can Destroy Your Future

  • AI-Engineer: A Distinct and Essential Skillset

  • AI-Engineers: Why People Skills Are Central to AI Success

Governance and Human Oversight

AI introduces new risks, but also creates an opportunity to rethink governance. The goal is not to control adoption through heavy process. The goal is to create guardrails that enable safe, fast, and responsible use.

Human accountability remains central. AI should augment judgment, not replace it. Good governance connects policy, security, and developer experience so that the responsible path is also the practical one. Done well, governance becomes an enabler of adoption rather than a brake on it.

Posts:

  • GitHub Advanced Security enables Shifting Security Left

Dual-Track Strategy: Core vs. Strategic AI Projects

AI portfolios need to balance immediate value with long-term positioning. Some initiatives should focus on proven patterns, broad accessibility, and fast adoption. Others should explore new capabilities and areas of differentiation, even when they involve more uncertainty and a longer payback period.

Managing this duality is essential. Over-indexing on core initiatives leads to incrementalism. Over-indexing on strategic bets leads to fragmentation and delivery risk. A pragmatic AI strategy requires both tracks to exist at the same time, with clarity about which type of problem is being solved.

Posts:

  • AI doesn’t create advantage -distribution does

  • Patterns for Artificial Intelligence Solutions

  • Four Categories of AI Solutions

Quantifiable Impact and Future Vision

AI adoption must ultimately be judged by its impact on real outcomes: speed, quality, cost, learning, and innovation. Early productivity gains matter, but the larger transformation comes from integrating AI into end-to-end systems where improvements compound over time.

That is where the future vision becomes clearer. The long-term value is not a collection of isolated AI wins, but a broader shift in how development, research, and organizational workflows operate. In that sense, measurable productivity improvements are only the first visible signal of a much larger change.

Posts:

  • The Evolution of AI: From Frontier Models to Specialized Small Language Models

  • Accelerating Research at Carlsberg Research Laboratory using Scientific Computing

  • GitHub Copilot Probably Saves 50% of Time for Developers

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

2026-04-14 /

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.

The Evolution of AI: From Frontier Models to Specialized Small Language Models

2026-04-10 /

Where We Came From: The Frontier Model Plateau

Over the past 12–18 months, the large language model (LLM) ecosystem has continued to advance—but largely in an incremental, not disruptive, fashion. Models from OpenAI, Anthropic, and Google have steadily improved across reasoning, multimodality, and scientific benchmarks, yet the relative ordering and qualitative capabilities have remained broadly stable.

Public benchmark suites such as MMLU (Massive Multitask Language Understanding), GPQA (Graduate‑Level Google‑Proof Q&A), and HELM (Stanford Holistic Evaluation of Language Models) show year‑over‑year gains measured in percentage points rather than step‑function breakthroughs. This is not a criticism—these are remarkable systems—but it does indicate a phase of maturation rather than rupture. Frontier models are converging: better, more reliable, more general—but not fundamentally different.

For scientific research, this means frontier GenAI has become a dependable horizontal capability: excellent for literature synthesis, reasoning assistance, explanation, and orchestration—but no longer the sole locus of rapid innovation.

Where We Are Now: The Rise of Small and Specialized Models

In parallel, a very different dynamic is unfolding.

Small Language Models (SLMs) and domain‑specific foundation models are advancing rapidly, particularly in scientific domains such as genomics, protein science, chemistry, and materials research. These models fall broadly into two categories:

  1. Domain‑adapted language models – smaller LLMs fine‑tuned on specific scientific corpora (e.g. chemistry, biology, materials science).
  2. Non‑linguistic foundation models – transformer‑based models trained on alternative “languages” such as DNA, protein sequences, or molecular graphs (e.g. Evo2, ESM, AlphaFold‑class models).

These models are not generalists—and that is precisely their strength. They encode deep inductive bias for their domain, deliver strong signal from sparse data, and increasingly outperform general LLMs on narrowly scoped scientific tasks.

Critically, most of these models do not fit the SaaS GenAI paradigm. They are rarely available via Azure AI Foundry, AWS Bedrock, or similar managed services. Running them typically requires:

  • Dedicated GPU infrastructure (often NVIDIA‑specific)
  • Local fine‑tuning or adaptation
  • Tight coupling to data and experimental context

This creates a structural mismatch between where scientific model innovation is happening and where traditional enterprise AI platforms operate.

External Validation: SLMs as First-Class Scientific Tools

Recent academic work explicitly supports this shift toward small, specialized models. A 2025 paper, “SLMs as Scientific Tools” (arXiv:2512.15943), argues that capability in scientific AI is task-relative rather than size-relative. The authors show that domain-specialized SLMs can match or outperform frontier LLMs on constrained scientific tasks when correctness, structure, and tool integration matter more than linguistic breadth.

Several conclusions from the paper closely align with CRL’s direction:

  • Inference locality beats central intelligence: running models close to data improves latency, reproducibility, validation, and cost control—supporting local, HPC-adjacent, and desk-side deployment.
  • SLMs scale scientifically, not just economically: smaller models are easier to interpret, benchmark, and falsify—critical properties for hypothesis generation and experimental decision-making.
  • Tool integration matters more than prompt engineering: structured inputs and deterministic tool calls outperform free-form prompting in scientific workflows.

The paper ultimately reinforces a hybrid architectural stance: LLMs orchestrate; SLMs execute. This provides external, peer-reviewed validation that SLMs are not a compromise, but the correct abstraction for scientific computing.

A Practical Shift: From Cloud‑Only to Desk‑Side AI

This is where a meaningful, practical shift is occurring.

With the arrival of systems such as NVIDIA DGX Spark, small language models become physically accessible to individual researchers. Instead of renting over‑provisioned H100 or Grace‑Blackwell cloud instances, scientists can:

  • Run and fine‑tune SLMs locally
  • Experiment rapidly without cloud friction or cost surprises
  • Work directly with models that are otherwise unavailable as managed services

In effect, this enables a “small model on every scientist’s desk” paradigm. The value is not raw scale, but immediacy, ownership, and experimentation velocity.

At CRL, this aligns tightly with how scientific progress actually happens: iterative, exploratory, domain‑specific, and data‑proximate.

Looking Toward 2026: A Hybrid, Orchestrated Future

Looking ahead—without making speculative predictions—the most plausible trajectory is not LLMs versus SLMs, but LLMs plus SLMs.

A likely pattern is:

  • Frontier LLMs acting as generalist reasoning, planning, and orchestration layers
  • Specialized small models performing high‑fidelity domain work (genomics, proteins, chemistry, simulation)
  • Tool‑ and model‑calling as the primary integration mechanism

In this model, the LLM does not replace scientific models—it coordinates them. It becomes the interface and glue, while the real scientific signal is generated by specialized systems running locally or on targeted infrastructure.

This is not speculative technology. The building blocks already exist:

  • Tool‑calling and agent frameworks
  • Domain foundation models
  • Local GPU systems capable of running serious scientific workloads

What changes in 2026 is not the theory, but the accessibility.

Summary

  • Frontier LLMs are improving steadily, but incrementally
  • Scientific innovation is accelerating fastest in small, specialized models
  • These models do not fit cloud‑only GenAI platforms
  • Desk‑side systems like DGX Spark make SLMs practically accessible
  • The near‑term future is hybrid: generalist orchestration + specialist execution

Appendix: The Emerging Scientific SLM Ecosystem (snapshot as of 2026-01-21)

Vendor / OriginDomain FocusRepresentative ModelsTypical Scientific Use Cases
NVIDIABiology, Chemistry, ClimateBioNeMo, ChemGPT, MegaMolBART, FourCastNetMolecule generation, QSAR, virtual screening, protein design, weather & climate modeling
DeepMindHigh-impact scientific modelingAlphaFold 3, GraphCastProtein structure prediction, climate forecasting, large-scale simulation
MetaProteins, Scientific LiteratureESMFold, ProtBERT, SciBERTProtein folding, sequence modeling, scientific text analysis
Arc Institute / ProfluentDNA & Protein DesignEvo2, E1DNA sequence design, protein design, strain optimization
Academic & Research ConsortiaGenomics, Materials ScienceOpenFold, MaterialsBERT, MatSciBERTCrystal property prediction, materials discovery
Emerging VendorsSupply Chain & OptimizationSCGPT, Logistics-LLaMA, OR-LLMDemand forecasting, route optimization, constraint planning

Notes

  • Most models listed above are open, open‑weight, or research‑licensed, and evolve in close collaboration with the scientific community.
  • The ecosystem is interoperable and tool‑oriented, designed to be embedded into pipelines rather than accessed via chat interfaces.
  • In contrast, enterprise GenAI platforms primarily target closed, managed, productivity‑oriented workloads.
  • NVIDIA’s role is increasingly that of a horizontal scientific AI platform provider, spanning models, tooling, and local compute rather than acting as a single‑model vendor.
  • Unlike enterprise GenAI platforms, which are predominantly closed and productivity-oriented, the scientific SLM ecosystem is characterized by open models, research licensing, and composability— properties that align naturally with exploratory research environments such as CRL.

Rupify: Executable Specifications for AI-Assisted Software Engineering

2026-04-09 /

Abstract

AI-assisted development has dramatically increased implementation speed, but not correctness. Rupify addresses this gap by turning requirements into executable, structured specifications that can be directly used by AI systems. Rather than relying on informal descriptions or heavyweight formal methods, Rupify operationalizes specifications as artifacts that can be generated, validated, and continuously enforced throughout development. Rupify is open source and available on GitHub: https://github.com/peterbb148/rupify

Why the name Rupify (RUP, UML, UCP)

Rupify takes its name from the Rational Unified Process (RUP), a structured approach to software engineering that emphasizes well-defined artifacts, traceability, and model-driven development. RUP uses the Unified Modeling Language (UML) to describe systems precisely through use cases, domain models, interaction diagrams, state machines, and deployment views. On top of this, Use Case Points (UCP) provide a way to estimate system size and effort based on functional structure rather than code.

Rupify operationalizes this chain—RUP for structure, UML for representation, and UCP for measurement—by turning it into an executable pipeline. Instead of producing documentation, it produces machine-interpretable models that AI systems can use directly for generation, validation, and estimation.

The Problem

AI systems are highly effective at generating, refining, and reviewing code, but they still depend on incomplete requirements, ambiguous intent, and inconsistent structure. This creates a fundamental mismatch where high-capability implementation systems operate on low-fidelity input.

The consequences are predictable. There is drift between intent and implementation, outputs vary across iterations, and correctness cannot be verified in a systematic way. Speed increases, but confidence does not.

The Idea Behind Rupify

Rupify introduces a structured, executable middle layer between intent and implementation. The process moves from interview to structured model, from model to executable artifacts, and from there into implementation and continuous validation.

The core idea is simple but fundamental. Specifications are not written primarily for humans; they are compiled for machines. Instead of acting as passive documentation, they become active inputs to the system.

What Rupify Does

Rupify provides a deterministic pipeline that starts with understanding a problem and ends with verifiable artifacts. Requirements are captured through structured interviews and translated into a canonical project model. From this model, Rupify generates RUP-aligned artifacts such as use cases, domain models, interaction diagrams, state models, and deployment views.

These artifacts are not static descriptions. They form the basis for use case point estimation and enable continuous validation against the original intent. The output is not just text, but a model that can be executed, tested, and checked.

Positioning

Rupify sits in the space between informal and formal approaches. On one side are notes, tickets, and lightweight specification formats. On the other are formal methods such as Z, TLA+, Alloy, and RAISE.

It provides structure without requiring full formalization, making it practical for real-world teams that need both speed and rigor. It is designed for environments where AI is already part of the workflow, but where correctness still matters.

Why This Matters Now

AI has shifted the bottleneck in software development. Writing code is no longer the primary constraint; defining correctness is. Without a structured specification layer, AI amplifies ambiguity rather than resolving it. Increased speed leads to increased drift, and verification becomes reactive instead of proactive.

Rupify addresses this by making correctness part of the input rather than an afterthought.

From Specification to Execution

Rupify enables a direct path from specification to execution. The generated artifacts are testable, traceable, and reproducible. Requirements can be followed through to implementation, estimates can be derived consistently using use case points, and systems can be continuously checked for conformance.

This allows AI agents to operate within clearly defined constraints instead of improvising from loosely defined prompts.

Practical Workflow

A typical workflow begins with a structured interview to capture intent. This is transformed into a canonical model, which in turn produces RUP artifacts. From these, estimation is derived and implementation is guided or generated. Throughout the process, validation is continuous and tied back to the specification.

The important shift is that every step is machine-interpretable and part of a coherent system.

Beyond Documentation

Traditional specifications are written, read, and eventually become outdated. Rupify specifications are generated, executed, and remain active parts of the system. They do not sit beside the implementation; they shape and constrain it.

Outlook

Rupify represents an early step toward a broader shift in software engineering. It points toward specification-driven development, where AI systems operate within executable intent and validation is built into the workflow.

The long-term direction is a move away from code-first development toward systems where specifications define, generate, and continuously validate the implementation.

Skills as a Supply Chain Risk

2026-04-05 /

We’ve Seen This Before

We’ve been here before. First with open source packages, then CI/CD, then infrastructure-as-code. Each time we optimized for speed and reuse, and only later realized the real risk wasn’t what we built, but what we pulled in.

Now it’s happening again. This time with “skills.”

Skills Are a Supply Chain

Skills are emerging as reusable units in the AI stack—installable capabilities executed by agents with access to tools, data, and decisions.

They can contain code. Which means the moment you install and execute them, you’ve created a supply chain.

Early Evidence, Familiar Patterns

A recent large-scale study analyzed more than 238,000 skills across marketplaces and GitHub and found a measurable fraction to be malicious [1]. The numbers are not dramatic, but they are real. Roughly half a percent of skills were confirmed malicious after filtering noise.

More importantly, the attack patterns are familiar. The same study identifies hijacking of skills hosted in abandoned GitHub repositories as an active attack vector [1].

In other words, this is not new risk. It is old risk in a new place.

The Difference Is Execution

What is new is how these components run.

Skills are not just libraries sitting in your build. They are instructions plus executable code, often running with the same privileges as the agent invoking them, and selected dynamically at runtime [2].

That changes the boundary. You are no longer just managing dependencies. You are allowing a system to choose and execute code on your behalf.

Why This Matters

Traditional controls assume stable systems: known dependencies, predictable execution paths, and validation at build time.

That model breaks here.

When selection is dynamic and execution happens at runtime, static analysis and dependency scanning still help—but they no longer describe the system you are actually running. Broader studies of the ecosystem already show a significant portion of skills contain security weaknesses, including supply chain-style vulnerabilities and privilege escalation paths [3].

This Is Still Fixable

None of this requires new principles.

Treat skills as untrusted code.

  • Use only skills from trusted sources with security code scanning
  • Limit what agents can do by default
  • Isolate execution
  • Require provenance
  • Observe behavior at runtime

This is just software engineering discipline applied at the right boundary.

Final Thought

Skills are not just features, they are code executing on your behalf.

We’ve learned how to manage this before. The only question is how quickly we apply those lessons this time.

References

[1] Malicious or Not: Measuring the Security of Agent Skill Ecosystems. https://doi.org/10.48550/arXiv.2603.16572

[2] Malicious Agent Skills in the Wild: A Large-Scale Security Empirical Study. https://doi.org/10.48550/arXiv.2602.06547

[3] Agent Skills in the Wild: Vulnerabilities and Supply Chain Risks. https://doi.org/10.48550/arXiv.2601.10338

[4] On the Security of LLM Agents: Prompt Injection and Skill-Based Attacks. https://doi.org/10.48550/arXiv.2602.20156

« Older posts
Peter Birkholm-Buch
Søvej 6
2665 Vallensbæk Strand
Mobil 26560203
Email peterbb@gmail.com
CVR: 34513287
Bank: Nordea
Konto: 5510-0747692815
SWIFT: NDEADKKK
IBAN: DK3620000747692815
Bitcoin: 1NiBdnmFGhZN2hpM5BRNHqCSD8wpyYNvZf

Follow me on Twitter

See my profile on LinkedIn

© 2026 Peter Birkholm-Buch

Theme by Anders Noren — Up ↑