☀️ Summer break: The blog is taking a short vacation and will return in the middle of August. Thank you for reading — see you then!
I’ve spent the past months writing about how artificial intelligence is reshaping software-intensive businesses. I’ve approached different facets of this transformation: compliance as a competitive moat, the data advantage, agentic systems, evaluation infrastructure, learning systems, small specialized models, physical AI, industrial deployment, European sovereignty, the AI-native organization, the new startup playbook. Taken individually, each is an argument about a particular technology, strategy or organizational pattern. Taken together, they make a different and more consequential argument. They describe a coherent picture of where software-intensive industries are heading.
That picture is worth stating directly rather than leaving it implicit across fifteen separate posts. This is an attempt to do that. It’s not a summary of what I’ve written; it’s an articulation of the single thesis the individual posts collectively support, and the strategic implications that follow from it.
The thesis is this. Software engineering, and with it the structure of software-intensive industries, is undergoing a transition more consequential than any since the move from on-premise software to the cloud, and possibly since the emergence of the discipline itself. The transition isn’t primarily about AI as a feature, although AI features are everywhere; it’s about a fundamental shift in what software is and how it’s built, operated, sold and embedded into organizations. Software is moving from a discipline of constructing static systems that execute predefined behavior to a discipline of constructing learning systems that improve continuously through operation. This shift propagates through every layer of how technology businesses work, and the organizations that understand the propagation will hold a decisive advantage over those that treat AI as a feature to be added to an otherwise unchanged business.
Several layers are visible in this transition, and they’re connected in ways that make sequential treatment misleading. At the bottom layer is the technology itself. The capabilities now available – foundation models that reason across domains, autonomous agents that execute multi-step workflows, small specialized models that run privately on commodity hardware, robotic systems that perceive and act in physical environments, evaluation infrastructure that allows AI quality to be measured systematically – aren’t of the same kind as the technologies that preceded them. The defining characteristic of these new capabilities is that they improve from operation. They’re not artifacts; they’re processes that generate data and learn from it. This is what makes them qualitatively different from the software that came before, and it’s the reason that nearly every downstream consequence I’ve written about follows.
The second layer is competitive strategy. When the underlying technology improves from operation, the competitive moats that define market structure also change. The codebase, which was the durable asset of the SaaS era, becomes a weaker moat because AI tooling has dramatically reduced the cost of writing functional software. What gains in importance is data: the cumulative operational data that improves the model, the workflow data that demonstrates real-world performance, the evaluation data that allows systematic quality improvement. Compliance becomes a competitive weapon rather than overhead, because in a world of distributed AI deployment, the organizations that can credibly demonstrate trustworthy operation across regulatory regimes are the ones that get deployed. Two-sided markets and platform dynamics intensify, because the data flywheels at the heart of AI-native businesses are the strongest form of network effect we’ve seen. These aren’t separate strategic patterns; they’re different angles on the same underlying observation: When the technology improves from operation, the businesses built around it accumulate advantage in ways that are difficult for late entrants to overcome.
The third layer is organizational. When AI systems do substantial portions of the work that previously required human execution, the organizational structures designed for human-centric work begin to fit poorly. The optimal team size collapses. The relationship between revenue and headcount weakens. Hierarchies flatten as middle-management roles that existed to coordinate human work become less necessary. New roles emerge around orchestrating, evaluating and improving AI systems rather than executing tasks. The interaction model shifts from human-to-software to human-to-agent-to-software, with a new orchestration layer that didn’t previously exist. None of these organizational changes are optional consequences that can be deferred. They follow directly from the technological shift at the bottom layer. An organization that adopts AI extensively while preserving organizational structures designed for human-only work will systematically fail to capture the value the technology makes possible.
The fourth layer is economic. The economics of building, scaling and operating software-intensive businesses are changing in ways that invalidate substantial parts of the venture playbook that defined the previous two decades. Capital requirements are lower because lean teams achieve revenue trajectories that previously required large engineering and sales organizations. Time to revenue is shorter because product-led growth combined with AI capability accelerates the path from launch to monetization. Pricing models are shifting from per-seat to per-outcome, because when AI does the work rather than supporting a person who does the work, the unit of value changes. The relationship between funding and growth weakens, because operational efficiency from AI tooling means that companies need less capital to reach significant scale. The valuation frameworks that worked for SaaS businesses don’t translate cleanly to companies with these different unit economics.
The fifth layer is geographic and geopolitical. Software-intensive industries have always been globally distributed but US-centric in their core infrastructure. The combination of AI Act enforcement, data sovereignty requirements, US-China technology decoupling and the emergence of credible European alternatives at multiple layers of the AI stack is changing this. The question for European enterprises is no longer whether to use European AI providers in principle but which layers of the AI stack should be operated under European jurisdiction, on what timeline and at what cost. This is a structural shift, not a political talking point, and it changes the procurement and architectural decisions of every software-intensive business operating in or selling into the European market.
These five layers aren’t independent; they form a single transition with internal logic. Foundation models that improve from operation create data flywheels. Data flywheels reshape competitive moats. Reshaped moats change the optimal organizational structure. Changed organizational structure changes the economics of company-building. Changed economics interact with shifting geopolitical and regulatory dynamics to reshape where companies can credibly operate. Organizations engaging with any one of these layers in isolation, without understanding how it connects to the others, will make decisions that look locally correct but are globally inconsistent.
This is the deeper observation I want to leave with. The transition to AI-driven, continuously learning software systems isn’t a sequence of separate changes that can be addressed individually; it’s a single propagating shift that touches every layer of how software-intensive businesses operate. The organizations that recognize this and treat the transition as an integrated transformation, redesigning their technology, strategy, organization, economics and geographic positioning together, will compound advantages that organizations addressing one layer at a time can’t match.
What does this imply, operationally, for organizations now? For software-intensive companies, the strategic question is no longer whether to engage with AI but whether to engage with the full shift it represents. Adding AI features to an unchanged business is a defensive move that yields modest efficiency gains and competitive parity at best. Redesigning the business around the capabilities AI makes possible, with the data infrastructure, evaluation discipline, organizational structures and economic models that reflect that redesign, is the move that creates durable advantage. This is a harder and more expensive transition than the AI features approach, but it’s the only one that captures the structural opportunity. The companies that have made this move are visibly outperforming those that haven’t, and the gap is widening.
For founders, the playbook is genuinely new. The companies being built today on AI-native foundations have different team structures, different funding trajectories, different moats and different pricing models than the SaaS companies that defined the previous decade. Building a startup in 2026 using the 2018 playbook isn’t just suboptimal; it’s increasingly likely to fail outright because the structural assumptions that playbook is built on no longer hold. The right reference cases are no longer the SaaS scaling stories of the 2010s; they’re the AI-native companies that are demonstrating how lean teams, fast revenue and deep data moats combine into a different kind of business.
For executives and boards at established companies, the questions to ask are different from the ones AI strategy decks typically address. The right question isn’t which AI vendor to select; it’s what your business would look like if it were designed around the capabilities AI makes possible from the beginning. Most established companies won’t be able to fully transform to this state. But the gap between the company you have and the company an AI-native competitor could build to address the same market is the gap that defines your strategic exposure. Closing that gap, even partially, is the most important strategic project of the decade for most software-intensive businesses.
For researchers and educators, including those of us who train the next generation of software engineers, the implications are equally significant. The discipline we teach is changing in ways that the curriculum doesn’t yet fully reflect. The engineering practices that produce learning systems are not the same as the engineering practices that produce static systems. Data isn’t a side artifact of operation but a primary engineering substrate. Evaluation isn’t a separate quality assurance activity but a first-class engineering discipline. Governance isn’t a compliance overhead but architectural. The educational institutions that adapt to this will produce engineers who can build the systems that matter in the next decade. The ones that don’t will produce engineers trained for problems that have already been solved.
I want to close with a candid observation. Writing this series has clarified something for me as well as, I hope, for some of you reading it. The individual posts have each made an argument about a specific topic. But the cumulative argument is bigger than any of them. We’re watching a structural transition in software-intensive business that ranks with the largest such transitions in the history of the discipline. The companies, countries and individuals who navigate this transition deliberately, with awareness of how the layers connect, will be the ones who define the next era of the technology economy. The ones who treat it as a sequence of features to evaluate will find themselves outcompeted in ways they won’t fully understand until it’s too late to respond.
To end with Richard Buckminster Fuller: “You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or X (@JanBosch).
