The AI bubble will be decided in the intelligence layer
In a recent World Economic Forum article, I argued that the fate of the AI bubble will depend less on the next model release than on something more prosaic: whether the application layer matures fast enough to turn AI capability into real economic value.
The Application Layer
When I talk about the application layer, I borrow Jensen Huang’s metaphor of an AI landscape being a five-layer cake: energy, chips, data centres, models and applications. AI applications, the top layer of the cake, are incredibly diverse, because the experience expected by humans varies widely depending on the task at hand. Building AI for engineering teams, for example, means understanding deeply how engineers work today, but also who they are and what they could become with better tools.
If AI remains mostly a story of infrastructure, benchmarks and impressive demos, the gap between expectations and returns will eventually become too large to ignore, and the bubble will burst. If, on the other hand, AI becomes embedded into the daily work of companies, engineers, scientists, designers and operators, the current investment cycle can be justified by productivity gains that are very real.
What does it actually take to build that application layer well?
After years building Neural Concept with industrial companies, I am now convinced that the answer is not simply “better models” or “more AI features.” The companies that will create value from AI are the ones that understand where intelligence is missing in complex and purpose specific workflows, and then build the right layer around real users, real decisions and real constraints.
This is why I increasingly prefer to speak about the intelligence layer rather than the application layer. “Application layer” sounds like a software category. “Intelligence layer” is closer to the real challenge. It is the layer that transforms raw computational capability into better decisions, shorter cycles and stronger human work.
And it is much harder to build than it often looks from the outside.
3 lessons from the field to build a successful application layer
1. Do not try to “use AI.” Try to solve a problem
One of the strange effects of today’s AI market is that AI itself has become the objective. Companies want AI in the roadmap, AI in the investor deck, AI in the product announcement, AI in the internal transformation program. This is understandable, the technology is powerful, the market rewards it, and no leadership team wants to appear passive.
But this is also one of the fastest ways to miss the point. In corporate performance metrics, the underlying phenomenon is best captured by British anthropologist Marilyn Strathern’s phrasing of Goodhart’s Law: "When a measure becomes a target, it ceases to be a good measure."
If the objective is to “use AI,” teams will find ways to use it. They will add assistants, automate fragments of workflows, generate more content, produce more prototypes and create dashboards showing activity. Some of this will be useful but a lot of it will remain superficial.
If the objective is to solve a hard business or engineering problem, which decisions take too long? Where do teams rely too much on experts? But also, what is the better world I want to create?
At Neural Concept, our journey was almost the opposite of many software companies. AI was not something we needed to inject later: the founders were deep-learning PhDs. In hindsight, this was a privilege, because it freed us from a distracting question: “How do we bring AI into the product?”
Instead, the harder and more useful question became: “Which engineering problems are we solving?”, “How could we build tools for engineers to redesign a car end-to-end in a day?”. Using AI as the solution was obvious to us because this was all we knew.
This is the advice I would give to engineering and business leaders. Build AI capabilities, educate your teams, give them access to modern tools. But do not ask them to “find AI use cases” in the abstract. Ask them to solve their most important problems, and make the targets more ambitious because AI is now part of the toolbox.
Fascination with the technology is a good entry point, but rarely a good AI strategy.
2.The human experience is the product
The second mistake is to underestimate the importance of human experience.
AI systems can be impressive in isolation. They can generate designs, write code, predict physical behavior, summarize documents, classify information and answer questions. It is tempting to evaluate them as standalone entities, with benchmarks and technical metrics. Those metrics are important, but in industrial environments they are never the full story: what happens when the AI system enters the hands of an engineer, inside an existing design chain, under time pressure, with incomplete information, organizational constraints and accountability for the final decision?
It took me time, personally, to understand how to use AI effectively. Sometimes I felt I was not exploiting it to the fullest. Sometimes I felt the opposite, that I was letting it pull me too quickly into a passive mode. I wrote about this a couple of months ago: this reminded me of Daniel Kahneman’s distinction between System 1 and System 2 thinking. System 1 is fast, intuitive and automatic. System 2 is slower, more deliberate and analytical.
Working with AI can easily pull us into System 1, even when the task requires System 2.
That is dangerous, especially in engineering. The point of AI should not be to make humans think less: it should be to help them think better or faster, with a broader view of the design space. The best systems earn their place by sharpening human judgment.
Herbert Simon once wrote that “what information consumes is rather obvious: it consumes the attention of its recipients.” AI takes this further. It does not only provide information. It can absorb attention, redirect it, fragment it and sometimes create the illusion that understanding has happened because an output was produced.
The world still needs human attention. In engineering, it needs it badly.
{{highlight}}
For engineering software, this is a design problem as much as a modeling problem. The user experience must be adjusted to the reliability, speed and scope of each AI capability. Some AI interventions should be highly automated, while others should be advisory. Some should exist only as decision support, with clear uncertainty and context. The same model can create value or confusion depending on where it is placed in the workflow.
This is why engineering leaders and solution providers need to work together on the workflow itself.
3.There are no shortcuts through the real world
The third mistake is believing that the intelligence layer can be built through shortcuts.
We are living in an era that rewards speed almost to the point of obsession. A prototype can be created in a few hours. A presentation can be generated in minutes. A company can appear, grow and be valued at billions before most people have understood what it really does. This creates a powerful expectation that every hard problem is about to become easy.
In our field, there is a particularly seductive version of this belief: the idea that physical and engineering complexity can simply be bypassed. That neural networks will magically replace physics solvers. That a model trained on enough data will remove the need to understand the system. That industrial constraints can be abstracted away.
Sometimes AI does create a step change. I have seen it. But when the work touches the physical world, there is usually no shortcut. Manufacturing constraints remain. Certification requirements remain, and data is imperfect. Legacy processes exist for reasons, sometimes good ones. Experts have knowledge that is not written down. Organizations have incentives, habits and fears.
The intelligence layer touches all of this, which is precisely why it’s both difficult to build and worth building.
Building it takes honesty, tenacity and courage. Honesty, because teams must be clear about what AI can and cannot do. Tenacity, because the value often comes from integrating many pieces that are individually unglamorous. And courage, as real adoption may force organizations to rethink workflows, roles, skills and even the structure of engineering teams.
The companies that understand this will move faster in the long run. They will resist the temptation to overpromise internally, choose use cases where the value is measurable and the workflow is ready to evolve and invest in the bridge between models and users. They will accept that the last 20 percent of integration and adoption can be harder than the first 80 percent of the demo.
That last 20 percent is where the economic value lives.
What it looks like when it works
When the intelligence layer works, the results are not abstract.
We have seen industrial teams reduce development cycles from years to months. We have seen leaner teams explore more design alternatives than much larger teams could before. We have seen engineers make decisions earlier, with more confidence, because they could predict performance before committing to expensive simulations or prototypes. We have seen organizations preserve and reuse engineering knowledge instead of restarting from scratch with each program.
These outcomes do not come from “the model” alone. They come from the system built around it, from connecting AI to the right data, in the right format, at the right moment in the workflow. They come from understanding where interaction is necessary and where human judgment must remain central, and from designing the intelligence layer around real industrial constraints.
This is also where Europe has a real opportunity. Much of the AI infrastructure race is concentrated elsewhere. But Europe has deep industrial knowledge, demanding engineering sectors and companies that understand complex physical systems. If AI value moves from generic capabilities to domain specific intelligence embedded in workflows, that industrial base becomes a strength.
The bubble question
So, will the AI bubble pop?
The answer lies in the intelligence layer, and in whether enough companies will do the hard work required to convert AI capability into real value.
After several years building this with customers, my view is clear. The application layer will mature, but not everywhere and not automatically. It will mature only in the companies that treat AI as a way to transform how work is done, not as a label to attach to existing software: companies that start from real problems, invest in the bridge between models and users, and give their engineers the tools to explore far more than they could before.
The AI bubble will be saved by the people who build that layer carefully enough for AI to matter.
The role of the intelligence layer is to help people focus their attention where it is truly needed. It should make exploration faster, but not careless. It should automate repetitive work, but not detach people from the consequences of their decisions. It should surface options, tradeoffs and risks in a way that invites engagement rather than disengagement.


