The paradigm, not the skills

Why the transition to artificial intelligence is, for Italian software, a cognitive problem before it is a staffing problem

There is a widespread misunderstanding, these past few weeks, in the Italian boardrooms that are examining their relationship with artificial intelligence. The misunderstanding lies in believing that the question is, at bottom, a matter of skills to be found on the market. We lack people who know how to use language models, the reasoning goes. We need to hire them, or train the internal teams, send them to courses. Once the training debt has been paid off, the software that already exists (the software built over the last twenty years, on which accounting, logistics and operations rest) can be “extended” with a few artificial intelligence features. A building renovation, in essence: same building, updated systems.

It is an understandable reading, and in Italy it even has a statistical justification. According to the Osservatorio sulle Competenze Digitali 2025, the digital skills observatory compiled by AICA, Anitec-Assinform and Assintel with Talents Venture, the country is short of roughly 236,000 ICT professionals to match the European average for the sector’s share of employment, and for every two open positions only one candidate comes forward. With numbers like these it is natural to read the problem as a shortage of supply: too few people, too few skills. The solution seems obvious. Find the missing skills.

The trouble is that this diagnosis, however well grounded in the employment figures, misses the target. The most serious difficulty Italian software houses face today is not quantitative. It is qualitative, and to a large extent cognitive. It concerns the best professionals, not the mediocre ones. It concerns senior engineers, not beginners. And it arises from the fact that the craft has changed its nature, not just its tools.

Determinism as second nature

Those who learned to program in Italy in the 1990s or 2000s (and this is largely the generation that now leads the technical teams of our software houses) absorbed, even before a language, a grammar of the world. In that grammar, given an input, there is an output. There is one output. If the program produces two different ones under the same conditions, there is a bug. Debugging is the discipline, patient and at times ascetic, of reducing the system until that one-to-one correspondence is restored. The elegance of an architecture is measured by how predictable it is, its robustness by how well it can fail in a recognizable way.

Twenty years of this practice do not produce competence alone. They produce a forma mentis. A disposition settled deep down: reading the computational world as a territory that, at least in principle, can be mapped with nothing left over. Software, seen this way, is a language in which every ambiguity is a defect to be cured.

Into these systems something radically different is now being introduced. A Large Language Model is a probabilistic machine. Given the same input (the very same input, even with the temperature at zero) it can return answers that are equivalent in meaning but different in form, and at times it can be wrong even though it has been trained well. A study of five models and eight tasks confirms it: even with nominally deterministic settings, accuracy varies by up to 15% across identical runs, and no model always returns the same strings (Atil and colleagues, 2024). Its correctness is measured in distributions, not in the single case. Here traditional debugging has no grip: there is no state to reconstruct, there is a statistical surface to govern. Luciano Floridi, a philosopher of information who taught at Oxford and now directs the Digital Ethics Center at Yale, has for years described this shift as a mutation of the infosphere. And it is not an abstract observation. Putting a probabilistic component inside an architecture designed to be deterministic is not adding a room to a house. It is a graft between different species, and like every graft it forces us to reconsider what the host system, taken as a whole, has become.

Where the friction really shows

This difference does not stay on the whiteboard. It concentrates in three precise places, and that is where Italian projects tend to get bogged down.

The first is what goes into the model and what comes out of it. In the old paradigm an error is an exception, a discrete event that the code intercepts and handles. When instead the model’s response does not conform to the expected schema (and it happens, even when rigid formats are imposed), what you have is not an exception but a fluctuation. The distinction is not pedantry: an exception you catch, a fluctuation you tolerate. It means validating the output at the level of meaning, placing a layer of abstraction between the model and the code, providing fallbacks that do not take the form “if error, then X” but “if the response does not meet the criterion, rephrase.” The same holds for what goes in. The most serious technique available today for anchoring a model to a specific domain, Retrieval-Augmented Generation, does not live on the relational databases on which Italian business management software was born. The technique was proposed in 2020 by Patrick Lewis and colleagues in the paper “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”. It lives on vector spaces, with delicate choices about how to split documents and continuous synchronization between the archive and the semantic index. Adding a “vector” column to a table that already exists does not settle the matter; it moves it three feet down the road. A team that has never built a machine learning pipeline ends up passing the model out-of-focus contexts, and the model, dutifully, hallucinates on those contexts.

The second is time, and with time, security. The single response is giving way to agentic workflows, where the model does not merely answer but acts: it plans, calls tools, looks at what happens, tries again. The reference pattern, ReAct, was formalized by Shunyu Yao and colleagues at Princeton in a 2022 paper that is by now a classic. The paper is “ReAct: Synergizing Reasoning and Acting in Language Models” (Yao and colleagues, 2022), in which the model generates, in an interleaved manner, reasoning traces and task-specific actions. A monolithic, synchronous architecture, built to serve pages in milliseconds, cannot bear the idea of a process sitting idle for thirty seconds while an agent completes a cycle of eight calls. It is not a performance problem but a topology problem, and it demands a different design: events instead of sequences, asynchronous services, session state kept separate from the engine that executes. On top of all this comes an area of risk that was not there before. The traditional interface has constrained inputs and an attack surface that is broad but known. A natural-language interface has, by definition, unlimited input. Prompt injection is a vulnerability with no precedent in the old world. Simon Willison, a British developer who is one of the co-creators of the Django framework and the author of one of the most widely read technical blogs in the field, coined the name in September 2022, showing how access controls built at the application level collapse the moment it is the model that decides what to execute.

The third is the life cycle. The usual continuous delivery process takes it for granted that what changes is the code, while the environment underneath stays still. With language models it is the opposite. The code is seldom touched, but the model evolves continuously: providers publish new versions, retire old ones, change default values. There is a phenomenon, model drift, that has no twin in traditional software. The same application, same version, same code, can behave differently six months later, simply because what lies beneath it has changed. Chen, Zaharia and Zou (2023) measured it: in identifying prime numbers, GPT-4’s accuracy went from 84% in the March 2023 version to 51% in the June version (“How is ChatGPT’s behavior changing over time?”). Watching over it with ordinary performance monitoring tools means having telemetry that is blind exactly where you need to see. Dedicated practices are required, which until three years ago did not exist as a discipline.

The real point, and why it is cognitive

It will be said that all this is technical material, and that a good engineer with twenty years in the trade, given the chance to study it, will learn it. That is only half true, and this is where it pays to speak plainly.

What one sees in senior teams is not a gap in knowledge. It is an underlying intuition that resists the knowledge. It can be recognized by small, persistent signs. The tendency to treat the model like any other API, to be queried in the expectation of always getting the same answer. The struggle to design tests that look at distributions rather than at the single case. The suspicion, never stated but always at work, that a system which “doesn’t always work” is a broken system to be repaired, and not a well-made system whose outcome has to be read in terms of probability. This intuition (let us call it the deterministic grammar) is what twenty years of serious work write into an engineer’s head. It is not a defect. It is the very quality that allowed those engineers to build the reliable systems on which the country runs every day. But it is a tool cut for a specific craft, and when the craft changes its nature the tool does not resharpen itself.

On this there is a figure that deserves to be framed and hung on the wall of every technical department. An MIT study, conducted by the Media Lab’s NANDA initiative and titled The GenAI Divide: State of AI in Business 2025, examined more than three hundred enterprise deployments of generative artificial intelligence. Against thirty to forty billion dollars invested, about ninety-five percent of projects deliver no measurable return. But the heart of the matter is the explanation. According to the authors the fault does not lie with the models, which work. It lies with the “learning gap”: the inability of companies to bring those models into their own processes and their own culture. The tools, the report says, shine in demonstrations and then fail to adapt to operational reality. It is, measured in the field, the same thing argued here by way of reasoning. The problem is not the model. It is the mind of the organization that takes it in.

The Italian generational knot

There is an implication that weighs more heavily in Italy than elsewhere, and it ties straight back to the skills deficit we started from. The prevailing line is that of reskilling: we train the people we have, we bring them up to date, the gap closes. It is a reassuring line and in part a necessary one. But it skirts around something uncomfortable.

New graduates, paradoxically, often start with an advantage. Not because they know more (they know far less), but because they have not yet absorbed the grammar that now has to be partly unlearned. Going back to thinking probabilistically takes less effort for someone who has not spent twenty years thinking deterministically. It means that, in this very transition, the experience curve no longer keeps rising. Beyond a certain point, part of that capital becomes a burden. Not a burden that cancels out a senior engineer’s value (it would be absurd to say so), but a real burden, which the rhetoric of reskilling prefers not to name because it is unpleasant to admit.

For the Italian software sector this is a pincer. On one side, there are not enough young people. About half as many enter the market as are needed, and the software houses, mostly micro-enterprises, compete for them with salaries that often cannot stand comparison with those abroad or at multinationals. On the other side are the senior engineers, who are the most valuable resource those companies have, because they hold the knowledge of the application domains and of the customers, and who are at the same time the ones on whom the mental retooling weighs most. So companies have to do two difficult things at once. Attract a generation that is in short supply and has a thousand alternatives. And accompany an experienced generation through a change that asks it to start learning again precisely where it was the master. The second, in human terms even before organizational ones, is the harder.

What is really needed

The conclusion is not that senior engineers should be scrapped. That would be foolish, and for Italian software houses suicidal. Knowledge of the domains, the design of architectures that last, the nose for telling a technical debt that can be carried from one that sinks the company remain things that no twenty-four-year-old possesses. The conclusion is a different one. The transition is not made with a course, nor even with a year of courses. It is made by accepting that the craft has moved up a level, and that the change is not cumulative. In certain areas it does not add to the earlier competence. It replaces it.

The same MIT study, alongside the figure on failures, leaves a practical pointer worth taking seriously. Projects that brought together internal specialists and outside expertise did much better than those entrusted to IT departments alone. In other words: the companies that withstand the transition do not just update the teams they have. They build AI-native units alongside them, with real autonomy, and they make skills flow in both directions. From the senior engineers to the new units, on the domain and on architecture. From the new units to the senior engineers, on the probabilistic paradigm and the practices that follow from it. It is slow, costly, politically thorny work, because it asks those who have been the protagonists to accept, for a stretch, the role of the pupil. The companies that take the shortcut, a one-off training session, a one-time consulting engagement, the “our developers are good anyway,” are exactly the ones that in recent months have been turning out systems that are splendid in the demo and fragile in production. They swell the ranks of that ninety-five percent.

It is not a matter of age. There are fifty-five-year-old engineers who have made the transition better than colleagues of thirty. It is a matter of willingness to recognize that the paradigm has changed, and that one’s own forma mentis, the most precious thing and the hardest to call into question, has to be partly reshaped. Those who do not recognize it are not incompetent. They are stuck in a craft that no longer exists in the same form. And in a country that already struggles to find people, treating the ones it has as if they only needed to add a skill, rather than rethink one, is a waste that Italian software cannot afford. Over the next eighteen months, the difference will begin to show on the balance sheets.

Alberto Viotto