I come from philosophy. Years when I read Garin and Cassirer in the morning and Foucault and Bobbio in the afternoon, where anti-clericalism and humanism coincided so naturally that you didn’t even need to argue it. From then on I have kept two convictions that I still consider the precondition of any serious public discourse. The first is that the historical religions are, in the vast majority of cases, anti-humanist devices, because the defence of the human requires a freedom that clerical structures have never been able to grant except through gritted teeth, under pressure, and almost always late. The second is that humanism, the real kind, the kind that starts with Garin and reaches the continental law of the twentieth century by way of the Italian Constitution and the 1948 Declaration, is a structurally secular ground, where religious traditions enter as guests, and when they try to take over the whole space they either get confused or betray themselves. These are judgments I have kept practising without much disturbance while reading the technical annexes of the AI Act, the latest implementing drafts of the Cyber Resilience Act, the EDPB guidance on DPIA templates for high-risk systems. I work in European compliance, I talk every day with public-administration and healthcare clients, and the only metaphysics I usually need is the already complicated one of Recital 71 of the GDPR. Then Magnifica Humanitas came out, and something moved.

Not an Exhortation, a Treatise on the Human

It took me two evenings to read it. It is not short, and it does not pretend to be. It is a long text, two hundred and forty-five paragraphs across five chapters, with an apparatus of two hundred and twenty-four footnotes, written in that curial prose that at times slows down and at times accelerates in an almost surprising way. I expected yet another moralising exhortation about artificial intelligence, the kind of document that tries to keep pace with an industry conference and ends up arriving two years late and half a thesis short. I found myself in front of something different. Not an exhortation, but a treatise. Not about AI, but about the human, with AI used as a touchstone to restate who we are. It is exactly the thing that secular technical debate struggles to produce, because it presupposes a level of conceptual foundation that we are used to delegating to the laws, hoping the laws will manage on their own.

Subsidiarity Was Not Born in Brussels

The problem is that the laws do not manage on their own. I see it clearly when I try to explain to a client why digital subsidiarity, the kind that inspires much of the architecture of the Data Act and the operational chapters of the AI Act, is not a Brussels invention but a principle with almost a century of elaboration behind it. Pius XI formulated it in 1931 in Quadragesimo Anno, and since then it has passed through case law, German ordoliberalism, Adenauer’s work, all the way to Article 5 of the Treaty on European Union. When a European regulator writes that certain decisions should be taken at the level closest to the people affected, it is using a grammar that was born elsewhere, not in Brussels. And when I try to defend that choice in front of a client, I find I lack the right words to explain it. Magnifica Humanitas, on this point, gave me back a vocabulary.

The Universal Destination of Goods, Applied to Algorithms

What struck me is not the novelty of the ideas. The encyclical’s ideas are largely known. What struck me is the way it holds them together, because they are exactly the ideas I need every time I have to discuss compliance without reducing it to a bureaucratic exercise. The universal destination of goods, for example, applied in paragraph 67 to patents, algorithms, platforms, infrastructure and data. It is not a position you can file away as pre-political or utopian. It is exactly the same problem the Data Governance Act tries to frame with the concept of data altruism, that the DMA chases with its gatekeeper rules, that the future interpretation of European health databases will have to face when the European Health Data Space comes into force. The fact that data is technically collectable and proprietarily assignable does not mean that its final destination is legitimately private. It is an operational statement, not a sermon.

Above the Citizen There Is No Longer Only the State

The same goes for subsidiarity in paragraph 71. The encyclical does something few technical documents have the courage to do explicitly: it recalls that, in the digital context, the level above the citizen is no longer the State, but the large economic actor that exercises de facto power over the conditions of common life. It is not a metaphor. When a platform decides what is visible and what is hidden, when an algorithmic scoring system establishes who gets credit and who does not, when a language model becomes the dominant interface for certain kinds of service, a power is exercised that the classical theory of subsidiarity had not foreseen in those terms. Recognising it formally, inside an official document of this authority, shifts the level of the discussion. It stops being a niche opinion. It becomes a grounded position that can be cited in a legal brief, in an impact assessment, in an opinion to a client who asks why all this effort is going into implementing a transparent logging system.

From Judgment to Calculation, Half a Century After Weizenbaum

Then there is a passage I did not expect, and it is probably the strongest piece of the whole document. It is in paragraph 198, in the chapter on the culture of power, where the encyclical addresses war, but it holds for everything. Moral judgment cannot be reduced to a calculation, because it involves conscience, personal responsibility and recognition of the other as a person. It is therefore not permissible to delegate lethal or otherwise irreversible decisions to artificial systems. Two sentences that contain at least half a century of critical thought on automatic calculation. Joseph Weizenbaum, the MIT engineer who in 1966 had built ELIZA and who a few years later was frightened to see how his secretary confided in it, wrote in 1976 a book whose subtitle was From Judgment to Calculation. The whole book was a defence of that preposition, to, which marks a loss. Weizenbaum argued that there are tasks computers cannot and must not perform, even if technically they could, because they involve the recognition of the other as a person, and that recognition is not a problem of internal representation. It is an act. Magnifica Humanitas, half a century later, says exactly the same thing with a different vocabulary. It is not a coincidence. It is that certain anthropological truths come back out when material conditions force them to come back out, and today the material conditions are those of automated decision-making applied to real human lives.

The New Slaveries and Data Colonialism

The encyclical goes further. In paragraph 173 it names things the mainstream debate on AI prefers to leave in the margins of vendor conferences. It explicitly cites data labeling, content moderation, rare-earth extraction, child labor in mines. It calls them new slaveries, and not as rhetoric. It calls them that because they are actually feeding, invisibly to anyone using an API at sixty cents per million tokens, the entire economy of transformer architectures. In paragraph 178 it introduces a concept that technopolitics scholars have been using for at least five years but that makes a certain impression when you see it used in a pontifical document: data colonialism. The key sentence is that whoever owns the health data of entire populations, today often collected under the sign of aid, research or innovation, in fact owns structural leverage on the future. It is an exact description of the strategic risk that weighs on many African, Asian and Latin American contexts, and that should weigh on our procurement choices when we decide where to host data, which vendor to buy a model’s training from, which ecosystem to delegate the epidemiological analysis of a region to. It is not a new-age sensibility. It is an impact assessment.

A Treatise That Holds as a Source for a DPIA

At this point in the reading I stopped. I was annotating passages in the margin as if I were preparing a technical brief, and I realised that was exactly what I was doing. The encyclical works perfectly well as an anthropological treatise, but it also works as a secondary source for a compliance argument. It is a text that can be cited in a DPIA to justify a restrictive assessment. It is a text that can be attached to an opinion on an AI integration in healthcare. Not because it has legal value, obviously, but because it provides the frame of principle that is often missing when technical choices are discussed, and that when missing turns into decisions made on the sole basis of opportunity cost. Anyone working in European compliance knows what I mean. There is a grey zone, between the recital and the article, between the legislator’s intent and the letter of the rule, where the practitioner needs to lean on something solid to explain why one interpretation is preferable to another. Having a text of this weight, written from a position outside the technical system but able to speak about it from the inside, is an asset it would be foolish not to use out of prejudice.

It Isn’t a Conversion, and It Isn’t a Perfect Text

I realise that anyone who knows me might find it strange to read these lines. I am not announcing a conversion, and I am not even saying the document is perfect. There are points where the encyclical slips, especially when it enters the ground of bioethics and the family, where my personal distance stays intact. There are passages where the pastoral tone takes over from conceptual precision, and where I would have wanted less rhetorical charity and more tools of analysis. It is not a text you sign, it is a text you argue with. But it is the kind of argument that I, as an atheist who works on the European regulation of technology, need today more than I needed yesterday. And I think it is needed, in the same way, by anyone trying to build a European technology industry different from the one that reaches us from San Francisco or Hangzhou, because different means founded on something, and something, at this historical stage, cannot be improvised.

Disarm

In paragraph 110 there is a word that made me smile. Disarm. The encyclical says it wants to disarm AI, and immediately specifies that to disarm does not mean to renounce. It means taking it out of the hands of monopolies and the logic of competition, making it debatable and contestable, returning it to the plurality of human cultures. It is a political word, not a religious one. It is exactly the word Brussels still cannot bring itself to say, because Brussels is still hostage to the realism that assumes the arms race as a natural given. A race that has stopped being military and become cognitive, as the encyclical notes with remarkable lucidity, but that keeps the same underlying logic. The fact that the first to say it, in an official document of this reach, was the Vatican and not a European commissioner, says something about the state of our public debate. It is not good news, but it is news to start from.

Three Things I Borrow

I close with a note that has nothing to do with theology. When you read a text produced inside a tradition that is not your own, there are two roads. One is preventive suspicion, which consists in asking the text to betray its own origin before you accept even to hear it. The other is the loan, which consists in taking what you need, leaving what you don’t, and going back to your work with one more tool. As an atheist, I feel I can borrow at least three things from Magnifica Humanitas. The explicit recognition that moral judgment cannot be automated, and that whoever tries to automate it is performing a political operation, not a technical one. The naming of the invisible supply chains that feed the digital economy, which is the precondition for any serious request for due diligence. And that word, disarm, which I would like to see applied, in the coming years, to the regulatory texts I will happen to read for work.

The rest, whoever cares, can argue in the proper places. For me, today, it is enough to have one more treatise on the nightstand, and a few well-written pages to reread when a client asks me why, after all, deep down, I am taking the trouble to do things properly.

The first reaction to the publication of UNI 11621-8, the Italian standard that defines the twelve professional profiles of artificial intelligence, should be suspicion. Standardising the trades of a field that changes every six months is an almost paradoxical exercise, and doing it before the rest of Europe means taking on the risk of being wrong first. The norm arrived on 30 April 2026, signed by UNINFO with the coordination of the Italian Department for Digital Transformation. The regulatory anchor goes to Regulation EU 2024/1689, the AI Act, and to Italian Law 132/2025 on AI. The Italian Law 4/2013 on non-regulated professions acts as the ramp to certification.

A Word in Search of a Metric Since February

For anyone working in compliance every day this closes a circle that had stayed open since 2 February 2025. That day, Article 4 of the AI Act required providers and deployers to ensure a sufficient level of staff literacy, without explaining what, exactly, the adjective sufficient meant. Over the last months, working on compliance projects for clients in highly regulated sectors, that word came back in every conversation as an unanswered question. No document kit and no DPIA template managed to pin down its meaning without circumlocutions. What does “sufficient competence” actually mean? When is a client’s request reasonable, and when is it a demand for which no metric yet exists? UNI 11621-8 provides that metric, and it provides it in Italian, with names that the buyer at a healthcare company or a regional public office can read without translating them.

Twelve Profiles, From the CAIO to the Researcher

The twelve profiles cover the spectrum from governance to research. They go from Chief AI Officer to AI Research Scientist. For each profile the standard specifies mission and tasks, together with a map of required competences, the expected level and the associated performance indicators. The methodology is the consolidated one of UNI 11621-1, and the anchor is the European e-Competence Framework, UNI EN 16234-1. Technically the work is solid, and it is important to say so before getting to the problems.

The Material Being Codified Is Still in Motion

The problems start with the material the norm tries to freeze. A profession is codified when it has reached a sufficient degree of stability, and today’s AI has not. The Prompt Engineer, present in the list as a separate profile, is already an interesting case. When it existed as a distinct role, it had a short life, and was quickly absorbed by developers and product managers working directly with generative models. Keeping it as a dedicated profile means chasing a practice that has already evolved elsewhere. The same applies, to a different degree, to the sharp separation between Data Scientist and Machine Learning Engineer, two roles that in real practice overlap widely. The boundaries of codified professional figures are much sharper than the boundaries of the competences people actually exercise. A good Data Scientist touches ML engineering, and a competent ML engineer knows how to move in the data pipeline. When an AI Security Specialist does not understand models at the root, they stop being a security professional and become a document reviewer.

Who Writes the Standard, and Why

There is a subtler matter, and it concerns the origin of professional-profile standards in Italy. They are produced by committees that include certification bodies and training providers, along with trade associations. Legitimate actors, all of them, and all with an economic interest in the final outcome. This does not make the standard less useful, it changes how it should be read. Under the technical surface there is the construction of a market. The market of professional certification and accredited training. The Italian ITS Academy programmes, the country’s higher technical education tracks, are aligning in these very weeks, and certification bodies are preparing their own schemes. Law 4/2013 provides the hook: those who can certify a profile earn from that certification. The question is not whether the system is legitimate, it is. The question is what we are actually buying when we spend to certify an internal Chief AI Officer.

The Substitution Effect, As With the DPO

A third caution concerns the substitution effect, which is probably the most serious risk. Having UNI-compliant profiles does not mean having competent AI governance. The recent history of the GDPR is full of organisations that had a certified DPO and disastrous processes, because the DPO was an administrative slot, not an operational function. The same can happen with the Chief AI Officer and the Security Specialist. Compliance by checklist produces organisational comfort and little real safety. If UNI 11621-8 is read as a documentary obligation, we will have companies with clean tables and fragile AI systems. If it is read as a skeleton around which to build real practice, we will have something useful.

A Trajectory We Have Already Seen

Having said all that, the publication of the standard is worth taking seriously. For a reason that has little to do with technique and a lot to do with the timing of a regulated market. The pattern, in Italy, is one we have already seen. The Cloud Italia Strategy of 2021 generated a framework for the classification of data and services for the public administration. That framework became a regulation of the Italian cybersecurity agency between 2022 and 2023. The catalogue of qualified cloud services then entered public-administration procurement procedures, all the way to Consip MEPA, the Italian central purchasing platform. Initially vague clauses on cloud-service security turned into verifiable technical requirements and conditions for participation. Whoever arrived later competed as a generic supplier against pre-qualified ones, and lost significant tenders. UNI 11621-8, applied within the AI Act frame, follows an analogous trajectory. The standard starts as a voluntary reference and ends in procurement specifications. Passing through the Department’s policy directives is almost an administrative detail. The useful window opens now and closes when the first significant tender cites the norm.

Inside a Multi-Framework Compliance Kit

For those of us, like Oltrematica, who work on multi-framework compliance, the standard is first of all a defensible documentation instrument. The RACI matrix of a high-risk AI project, built on the UNI profiles, becomes evidence that holds up in audit. The internal training plan, mapped to the profiles, stops being an administrative cost and becomes an integral part of the AI risk-management programme. The form we are giving to our internal documentation kits absorbs the standard without effort, because it speaks the same language as the frameworks we already use, from the GDPR to the Cyber Resilience Act.

An Imperfect Map, But a Map

There is a line of work more interesting than mere conformity, and probably less profitable in the short term. The standard is an occasion for internal intelligibility. It allows organisations that adopt AI to talk about it with a shared vocabulary, before they talk to regulators or to certification bodies. It is an imperfect vocabulary, partly dated and built around recognisable economic interests. But it is the first available vocabulary, and its imperfection is smaller than its usefulness. The real question, the one that will decide whether UNI 11621-8 is a good norm or a bad one, is not written in the text. It will be written in the coming months, in the interpretations organisations give it, and in the tenders that use it to filter suppliers.

In the meantime, it is worth reading it for what it is. An imperfect map of a territory we are already crossing, which at least proposes a shared toponymy so that we do not all get lost in the same way.

Eight in the evening, more or less. Dinner just ended, the dishes in the sink, the table still to be cleared. My son is three years old and is trying to convince me to let him keep the tablet for a little longer, which in his grammar of time means a span between twenty minutes and infinity. I say no. Not in anger, not with a parenting lecture. I say no with the precise tiredness of someone who repeats the same scene every evening, knowing the next one will be the same.

So far it is a scene any parent recognises. It could happen in any home.

I Know How That Tablet Works

The difference is the reason I say no. It isn’t because I read an alarming article on screens, or because I follow a paediatrician on Instagram who recommends the digital detox, or because in my day we played outside. The reason is that I know how that tablet works. Not in the generic sense, not “technology is bad for children.” I know in the technical sense. I know how the software running on it is built. I know which design decisions the people who built it made, and I know why they made them. I know what happens when my son touches the screen, what logic decides what to show him next, and what objective that logic is trying to reach. That objective is not his wellbeing.

I know this because it is my craft. I have been building software for nearly twenty years. I don’t work for the big social platforms, I have never had an office in Menlo Park or Mountain View. I do far more boring things: ERP systems, training platforms, applications that help companies organise data. The kind of stuff that would never end up in a journalistic investigation, because it isn’t interesting enough.

Someone might object that the problem doesn’t concern me, that attention-capture techniques belong to TikTok, to Meta, to ByteDance, and that between a social platform and an ERP system there is the difference between a Formula 1 track and a country road. It would be a sensible objection if it weren’t false. The techniques for keeping people glued to a screen are not an industrial secret. They are a shared, documented, taught discipline, discussed at the conferences I attend, debated in the Slack channels where I spend my working days. They are common heritage to anyone who builds digital products. The levers TikTok uses to keep a fifteen-year-old glued to the screen are close cousins of the levers I would use to help a client raise the average session time on a corporate training platform. The context changes, the intensity changes, the user type changes. The basic tools go by the same names, are taught at the same conferences, are found in the same design books.

In the evening, at home, I read the floorplan of my son’s tablet the way you read the blueprint of a building: this serves that, that serves this, here the design pushes you in this direction, there it stops you from going in that one. In the morning I work with the same tools as the people who drew that floorplan. From this fracture comes a book I wrote and decided to make freely available. It is called I tuoi figli non sono i tuoi utenti (Your children are not your users), and it tries to do one very specific thing: transfer a piece of professional knowledge to the people who don’t have it, because the difference between having it and not having it, when it concerns your own children, is enormous.

Skinner, the Pigeon, the Feed

To give a sense of what kind of knowledge we are talking about, I’ll take a single example among many, the one I think is the most important and the least known. Between the 1940s and the 1950s the psychologist B. F. Skinner ran a series of experiments with pigeons in a cage. If the pigeon pecked a disc with its beak, it got food. Skinner discovered something interesting: if food arrived every time the disc was pecked, the pigeon pecked when it was hungry, and that was it. If instead food arrived unpredictably, every three pecks, every five, every two, the pigeon began to peck the disc continuously, compulsively, even when it wasn’t hungry. Variable reward, that mechanism, is the psychological engine of slot machines. It is also the psychological engine of a social network feed, not by poetic analogy but by explicit design.

When your child scrolls Instagram for twenty minutes, most of the content seen is trivial, irrelevant, forgettable. Every now and then something good arrives, something that makes him laugh, a piece of news that interests him, a photo that concerns him. He doesn’t know when it will arrive. He only knows that if he keeps scrolling, sooner or later it will. His brain is doing, in an elegant digital version, exactly what Skinner’s pigeon was doing.

Personalised Random

There is an important difference that makes things worse, and that people outside the industry usually don’t consider. Arcade slot machines distribute wins randomly, because they know nothing about the player. A social network’s algorithm knows what you like, what you pause on for a second longer, what outrages you, what moves you. It uses this information to calibrate content distribution so the variable-reinforcement effect is maximised on you, specifically. It is no longer random, it is personalised random, paradoxically more effective than pure chance because it keeps the unpredictability (you don’t know when the good content will arrive) and adds the relevance (when it does, it is calibrated on your interests). On a teenage brain, whose prefrontal cortex is still under construction, this mechanism is particularly potent.

The Other Mechanisms

Variable reward is one of the mechanisms the book describes. There are others: infinite scroll, which removes decision points; autoplay, which makes “keep watching” the default; notifications calibrated to produce an involuntary physical response; dark patterns that make signing up easy and leaving difficult. They are all documented, all taught, all applied without distinction of age, even to the products your child has on his phone. There is nothing clandestine about any of this. It is open literature, accessible to anyone who wants to read it. The problem is that the people who read it are almost always the people who build those products, rarely the people who use them.

What the Builders Know, and What They Do With Their Own Children

From here comes the question that gives the book its title, and which is the simplest one I know about the whole matter. The Silicon Valley private schools that ban screens in class are not an urban legend. Tim Cook, Apple’s CEO, stated publicly that he would not allow his nephew to use social media. Sean Parker, the first president of Facebook, described the platform’s design as consciously oriented to exploit a vulnerability of human psychology, and added that only God knows what it is doing to our children’s brains. Chamath Palihapitiya, former vice-president of user growth at Facebook, said publicly that his children were not allowed to use that stuff. The testimonies of insiders who admit to protecting their own children from the products they helped build are not hidden, not ambiguous, not scarce. You only need to look.

The observation I make in the book, and that I make here too, is smaller and more ordinary than these famous declarations. Among the colleagues working in software I talk to regularly, the ones with children are almost unanimous on one point: stricter rules on phone use than the average non-tech parent, delayed access to social media, careful control over which apps get installed, conversations with the children about how notifications work and why. It is not a scientific datum, it is an anecdotal observation. But it is consistent, it is recurrent, and its very existence proves the point: people who know the mechanism behave differently.

If the people who build these things keep their own children away from them, what is it that they know and we don’t?

Informational Asymmetry, and the Book

It is not a rhetorical question. There is no secret room where tech executives plan how to harm the world’s children. There is something far more ordinary and far harder to fight, which economists call informational asymmetry. On one side, the people who understand how digital products work, how they are designed, which psychological levers they use and why. On the other side, the people who use them, and let their children use them, without that information. This asymmetry has existed as long as industries have. Food-company chemists know things about food that consumers don’t. Automotive engineers know things about cars that drivers don’t. The difference is that in those sectors, over time, a system of labels, safety standards, and transparency obligations was built. For digital products that system is still largely to be built, and in the meantime our children spend hours inside them every day.

The book tries to close that gap. Not all of it, that would be an excessive claim. A part. It explains how the main mechanisms work in language that doesn’t require technical skills, recounts what we know and what we are still trying to understand about the effects on our children, and tries to outline what each of us can do in our own role: as parents, as citizens, as users, and also, for those of us who work in the industry, as people who build this stuff. It is not a parenting survival manual, and it is not a book against technology. It is an attempt to transfer a small part of professional knowledge to the people who normally don’t get it.

The book is free, in epub and pdf, at ebook.margiovanni.it. If you read it and find it useful, what I ask is that you pass it on to another parent. That handoff between two people who know each other is worth more than any recommendation algorithm, and it is exactly the kind of thing the mechanisms the book describes cannot do.

A large client in a regulated sector asked us, a few months ago, to put the platform on a secure footing. The request came in the usual terms—information security and conformity audit. What they ended up taking home was a DPA Annex 2 articulated across nineteen sections, a technical gap analysis, a remediation roadmap, and a formalised sub-processor chain written to withstand a serious inspection. There wasn’t a single new line of code in what we delivered, and not a platform to license either. Structured paperwork and contractual positioning, produced in such a way that they would hold up before anyone who came to ask. The interesting thing is that this wasn’t an exception. It’s the rule that has settled in over our last twelve months of work.

Someone might argue that the map of this market already exists, and that it’s enough to read Gartner’s Magic Quadrant for GRC tools, or to consult Forrester’s reports on privacy-management platforms. That would be a convenient and partly misleading shortcut. Those documents photograph the global platform market—ServiceNow, MetricStream, OneTrust, Drata, and Optro, which has just renamed AuditBoard last March. The Italian compliance market has a structure of its own, shaped by the Agenzia per la Cybersicurezza Nazionale, by the NIS2 transposition through decreto legislativo 138/2024 (Italy’s NIS2 transposition), by the dominant weight of public administration in total spend, by the irregular pace at which European directives are operationalised by end clients. To read it you need a map drawn from the inside.

At the Top: Specialist Advisory

It helps to picture the market as an hourglass. At the top, a thick layer of specialist advisory has formed. The Big Four—Deloitte, PwC, EY, KPMG—run GRC practices that by now look interchangeable on paper, and compete more on the names of their senior partners than on their methodologies. Alongside them, and in some cases at a qualitatively higher level, the structured Italian boutiques operate. P4I, part of the Digital360 group, lists more than one hundred and sixty professionals on its site and sells a methodological brand called Advisory Engine, with a catalogued product registered as Compliance360. ICTLC consolidated the legal-tech angle that’s fashionable today, but wasn’t when it started. Spike Reply operates inside the Reply group while keeping a recognisable identity, and covers the full spectrum of cybersecurity and data protection with significant weight on financial and manufacturing dossiers. Deda Tech took the multidisciplinary-team route, where lawyers and economists sit beside engineers, and in public interviews the firm openly says it doesn’t sell technical solutions but trust. The line sounds like marketing, and it matches the actual positioning.

What these firms sell is interpretation. Not a piece of software that does something, but a recognisable person, able to translate a regulation into the specific terms of your supply chain, and to hold the line at the negotiating table on a Data Processing Agreement with an American cloud provider without giving up what shouldn’t be given up. The margins are high and the scalability is low. Dependence on the single name with the grey beard or the academic CV is structural to the model. Growth happens by cooptation—hiring heavy names, acquiring smaller firms that bring consolidated client portfolios as dowry. It’s a mechanism that resembles the legal world more than the software world.

At the Bottom: The Platforms

At the bottom, the platform layer has formed. IntelMarket Research projections value the global GRC platform market at $16.7 billion in 2024, with a 2032 horizon at $32.8 billion and a compound rate of 9.9 percent. Other estimates give meaningfully different numbers depending on how the perimeter is drawn, but the direction is the same. ServiceNow GRC is the default for anyone already using ServiceNow for IT service management, and that covers a meaningful slice of the Italian enterprise. MetricStream covers the segment of multinationals with mature GRC programmes. OneTrust turned GDPR into a product and is now repositioning itself on AI governance. Drata and Vanta automate SOC2 and ISO 27001 for startups and scale-ups, with evidence collected continuously and SaaS pricing that fits a CTO’s budget without having to go through the CFO. The Italian portion of this layer is thin. The Italian market for compliance-dedicated software has not produced players of international scale, and local attempts remain confined to single verticals or single clients.

The Compressed Middle Layer

Between these two layers, where the hourglass narrows, sits the middle layer—and that’s where the interesting dynamic lives. It’s the layer of custom compliance software, of bespoke GDPR back-office tools, of vertical ISO 27001 platforms developed by mid-sized Italian software houses. For years it was a comfortable layer. The client didn’t trust American platforms for reasons of data sovereignty, the Big Four were too expensive for the mid-market, and a local software house delivering a branded GDPR portal was the natural answer. Today this layer is compressed from both sides at once. From below, because Drata delivers SOC2 at a fraction of the cost of a bespoke tool, and startups have no reason to commission anything proprietary for a commodity function. From above, because when the problem turns serious—a defensible DPIA, a contract negotiation with Microsoft that doesn’t leave gaps—the client realises software isn’t enough, and that what they need is a person who speaks their language and can sign documents that hold up.

ACN, and the Market Inside the Market

What makes the Italian map structurally different from the global one is ACN. The Regolamento unico per le infrastrutture digitali e i servizi cloud (Italy’s unified rulebook for digital infrastructure and cloud services), the decreto direttoriale 21007 of 27 June 2024, in full effect since 1 August of the same year, has built a market inside the market. Public administration can only buy cloud services if they are qualified QC1, QC2, QC3 or QC4, delivered on infrastructure rated AI1 through AI4, according to a matrix that ties data classification to the permitted service level. Aruba is qualified at the highest tiers, Polo Strategico Nazionale handles data classified as strategic, and a handful of other providers are filling in the remaining cells of the catalogue. For Italian system integrators working with the public sector, the concrete choice becomes binary. You either resell someone else’s qualified cloud, accepting thin margins and an implementer’s role, or you build an advisory that guides the public-sector client through architectural choices, capitalising knowledge of the qualified catalogue as a distinctive asset. When I prepared for Pescara Multiservice the proposal for ACN-qualified cloud hosting based on Aruba VPC at QC3 level—against the actual price-list entry ARB-11504-1 of €217.38/month—the part of value the client was buying was my translation work between their application requirements and the catalogue’s requirements. Infrastructure was commodity. Interpretation wasn’t.

What System Integrators Are Doing

At this point you can see what’s happening to Italian system integrators, and why. The large ones—Reply, Engineering, Almaviva, NTT Data Italia, Accenture—already run internal GRC practices that compete directly with the Big Four, and in some cases have outperformed them on public contracts. Spike Reply is the canonical example of this movement, but not the only one. The mid-tier firms—Deda Tech, Var Group, Lutech—build multidisciplinary teams and resell their identity as trusted advisors in a new vocabulary. Implementation revenue is still significant, but the high margin lives where you sell days of interpretation, not sprints of development. The small ones face a tighter choice. They can become someone else’s reseller and lose their identity. They can stay specialist implementers in a vertical where domain depth offsets a lack of scale. There’s also a third path, riskier than the others—turning into an advisory boutique and selling knowledge first and implementation second, trading a portion of certain revenue for a positioning that’s still uncertain. Most aren’t choosing—they’re passively absorbing the drift of the market. At Oltrematica we made the choice vertically: private healthcare and local public administration, with serious investment in compliance documentation as a product. That DPA, the five-tier formalisation of a sub-processor chain crossing three companies inside the same industrial group, the analysis of the new DPIA template that the EDPB adopted on March 10 and published on April 14 for consultation through June 9—all of these are pieces of work that, five years ago, we would have done as an accessory to the main project. Today they are the main project, and software comes after, if it comes at all.

Where Value Migrates, and What I Don’t Know About 2027–28

There’s a consequence to all of this that’s worth making explicit. Value in the Italian compliance market is migrating to the two ends of the hourglass. International platforms keep pushing the cost of evidence down, and that pressure won’t stop, because their business model depends on progressive automation. The advisory boutiques and the GRC practices of the large system integrators keep pushing the price of interpretation up, and there’s no technological innovation on the horizon that reduces the cost of an opinion signed by a recognisable name. What’s left in the middle—custom compliance software—faces a fork. It can become specialist inside a vertical to the point of no longer being substitutable by generalist platforms, or it can be absorbed into an advisory offering as a capability rather than a standalone product. The Politecnico di Milano figure that estimates the Italian cyber and data-protection segment at €2.78 billion in 2025 with twelve percent growth doesn’t distinguish between these layers in its surveys, and that’s probably one of the reasons companies in the middle layer keep reading the numbers as good news when in fact they’re saying something subtler.

The most honest sentence I can write about how this market will look in 2027 and 2028, when the Cyber Resilience Act is operational and the AI Act in full enforcement, is that I don’t know. It seems plausible to me that a reconfigured middle layer will emerge, where tools like Claude Code, GitHub SpecKit and their derivatives will let software houses like ours produce compliance artefacts treated as code—versioned, tested, generated from traceable formal specifications. It’s a direction I’m investing in personally and that I’ve been writing about here for several months. But it’s also possible that the middle layer collapses entirely and that the Italian market polarises onto two sides, the way other mature markets did before ours. Twelve months from now this map will need to be redrawn. That will be one of the exercises I take on.

A spectre is haunting Europe, and for once it is not the one Marx had in mind. It is a stranger spectre, because it does not haunt those of us who live here. It haunts those who watch us from the outside, from the other side of the ocean, who look at us the way one looks at an eccentric relative at Christmas dinner—someone you are obliged to put up with, someone you would happily be rid of, who nonetheless stubbornly keeps existing and keeps talking about strange things like the dignity of work, accessibility, child protection, product liability. The spectre is us. Or rather, it is what we are doing here in the area of digital regulation, a series of acronyms that in Brussels are considered ordinary technical work and that in San Francisco are perceived as a near-existential threat.

Seen from the outside, and in particular seen from one specific corner of the world that has made itself heard a great deal in the last few years, Europe has become a character. It is no longer an economic subject, nor a political union, nor, by now, the continent of the hundreds of millions of people who actually live here. It is a meme. A meme with a precise narrative function: to embody what the future must not be. Nineteenth-century bureaucracy pasted on top of the twenty-first century. The old world holding back the new. The open-air museum that presumes to dictate rules to tomorrow’s factory. It is a caricature, of course, but an effective one, because it works inside a much larger story than itself, and that story is the culture war a slice of American capitalism is waging against the very idea that software can be the object of rules.

GDPR and the Banner That Sums It Up

To understand where we are now, it helps to go back a little. The moment when the relationship between Silicon Valley and European regulation cracked in a way that has been hard to mend was GDPR. A regulation from 2016, applied from 2018, technically not revolutionary, drawing largely on principles that already existed in Convention 108 and in directive 95/46. Yet what GDPR did in practice was to declare that certain business models built on indiscriminate collection of personal data would, at some point, have to answer for something. It is no accident that GDPR has become the symbolic target par excellence in the anti-European narrative, and no accident that the prevailing way to attack it is the cookie banner.

Here I owe my first concession. The cookie banner as we live with it is a failure. It is a failure from the user’s point of view, who clicks it away without reading. It is a failure from the standpoint of effective protection, because that consent is almost always fictitious. It is a failure from the standpoint of the interface designer, forced to accept that every European site opens with a digital customs gate that nobody wants. It is the textbook example of a rule that is correct on the level of principles and that has discharged itself onto the implementation plane in a grotesque way, because the legislator assumed consent was the sovereign act of will of a rational subject, and the designers of digital products knew perfectly well that you only had to design the banner a certain way to get it clicked through in half a second. The dark pattern has eaten the theory of free, specific, informed and unambiguous consent. You can see it every day. It is a real problem. The critics are right on this specific point.

But this is where the divergence between useful and instrumental criticism begins, because anyone who is right about the cookie banner is not actually arguing about the cookie banner. They are using the cookie banner as a metonymy to attack the very idea that the collection of personal data is a regulable problem. They are saying, in substance, that if the rule produces an ugly implementation then the rule must be abolished, not that the implementation must be corrected. It is an old rhetorical move, and there is no need to summon any authority here—it is enough to observe that those who call for the abolition of GDPR on the basis of the cookie banner do not usually call for the modification of the technical consent rules, which would be the coherent position. They call for a return to a world in which American platforms can do whatever they want with our data without owing anyone an explanation. The banner was a pretext, not an argument.

DSA, DMA, and the Business Model

That it was a pretext became definitively clear with the DSA and the DMA. When the Commission began asking gatekeepers to open their platforms, to make certain services interoperable, to stop favouring their own products in their stores, to allow users to uninstall pre-installed applications, the argument “you regulate too much” turned without intermission into the argument “you are attacking our companies”. The leap is interesting. For years they explained to us that the problem was the excess of rules, not the identity of those who paid. Once the rules became operational, they explained that the problem was that they hit only American champions. The two theses are not compatible, but they coexist comfortably inside the same line of argument, and that alone should make one suspect that something does not add up.

A point worth making about the DMA. The thesis that the DMA specifically targets US firms is factually weak, because ByteDance is also among the gatekeepers, and because thresholds are thresholds. A European company reaching seventy-five billion in capitalisation and forty-five million monthly end users would be a gatekeeper too. The problem is that European companies in that range are extremely rare, and the only recent case, Booking, operates from Amsterdam but reports to a US holding. That absence does not depend on the DMA. It depends on industrial, fiscal, financial and educational choices of the last forty years that the DMA did not cause and will not solve. If we want to talk about that problem, let us talk about it seriously, citing the Draghi report if we need a recent anchor, but let us not confuse it with platform regulation, because the two planes only touch in appearance.

This is the point that those who watch us from outside do not want to see, or perhaps see perfectly well and pretend not to. Platform regulation is not in competition with innovation. It is in competition with a specific business model—mass extraction of personal data, attention optimisation pushed to the edge of addiction, capture of adjacent markets through dominant-position leverage, systematic offloading of negative externalities onto the social body. It happens that this business model has been the prevailing model of American digital capitalism for the last twenty years. It happens that the companies practising it are now the largest in the world, and that they have an obvious interest in continuing to practise it. If the European Union says that this specific model has limits, it is touching a raw nerve, and not by accident. It is saying, more or less articulately, that there is another way of doing digital technology. In 2026, that is heresy.

From Rule to Technical Object

Let me leave analysis aside for a moment and tell a concrete story, because I think it helps to know where I am speaking from. I have worked for several years inside a mid-sized Italian ICT company, outside the major metropolitan areas, that builds software for public administration and healthcare. For the last two years my work has been largely one thing: translating European regulation into technical objects. What it means to have a healthcare platform compliant with GDPR Article 28 when the supplier of a supplier is in Germany and the health data concerns an Italian citizen. What it means, for a training body delivering workplace-safety courses under the Italian Accordo Stato-Regioni, to see the Cyber Resilience Act arrive and realise that its LMS falls within scope. What it means, for a software house producing a back-office application, to prepare for the fact that the revised Product Liability Directive has extended the regime of defective-product liability to software—including certain forms of integrated AI components—and that the regime will apply operationally to products placed on the market after December 2026. What it means to design a DPIA following the template approved by the EDPB last March, only to realise that it is not a form but a documentary genre, to be kept alive alongside the system it describes. These are jobs of translation, not of abstraction. The rules that on the other side of the ocean are painted as obstacles to innovation are, for me, the innovation itself, because they define the perimeter inside which one can design well.

I do not say this out of romantic adherence to the European project. I say it because, after implementing these requirements dozens of times inside real systems, you see something an Andreessen op-ed cannot. You see that conformity is not an isolated cost, it is a design pressure. Like all design pressures, it narrows the space of choices and in exchange forces you to do things better, at least within the dimension the rule protects. The PLD, for instance, shifts producer liability for software quality in a way that until yesterday did not exist even as a category. For those who sell serious products this is an administrative nuisance. For those who sold junk while promising it was magic, it is an earthquake. Guess which of the two groups produces the most virulent criticism.

One could say, and people do say, that this argument holds for my small Italian shop but not for the technological frontier. The Italian shop is not inventing foundation models, not designing gigawatt data centres, not redefining the paradigm of scientific research. True. But that is precisely why my vantage point seems useful to me, because it tells from very close range what the great Californian narratives never manage to see, namely that the vast majority of software running in the world is not frontier, it is everyday infrastructure. It is the healthcare systems handling our clinical data, the public-administration portals handling our relationship with the state, the back-office systems running small businesses, the training systems that certify legally mandated competencies. It is fabric. European regulation is written above all for this fabric, and the fabric, by definition, needs rules in order to exist as fabric and not as a random pile of threads.

AI Act, Vance, and the Race

Let me move on, because there is another theme that deserves to be taken seriously, and that is the AI Act. Here too the concession must be made. The AI Act is a difficult regulation, written at a historical moment when the technology it was meant to regulate was changing every four weeks. It had a complicated gestation, took a mid-course turn when foundation models arrived, and produced in the final text certain asymmetries between obligations on providers and obligations on deployers that operators are still trying to figure out how to apply. There are ambiguities in the codes of conduct on general-purpose systems. There are doubts about how to compute compute-thresholds. There are operational difficulties in conformity assessment for high-risk applications in healthcare, and here I speak from direct experience because Trustie, the platform I work on as CTO-as-a-Service for Umana Analytics, has to wrestle with some of these doubts alongside GDPR and other pieces of European discipline that overlap in not always linear ways.

All true. All fair. And it is precisely for that reason that the AI Act is not the end of the world. It is a young rule, in its bedding-in phase, dealing with a sector that is itself young and in its bedding-in phase. The application difficulties are reciprocal, because the technology is in the phase of discovering its own space and the rule is in the phase of discovering its own implementation. This is normal. The same has happened with every transformative technology—industrial chemistry in the early twentieth century, nuclear safety in the second half, medical devices in the 1980s, finance after Lehman. New rules live their first years in a state of iteration. The difference today is that American operators consider it normal for the law to chase technology, while they consider it scandalous for the law to stand up first.

The scandal is told in almost religious terms. It is not regulation, it is hyper-regulation. It is not caution, it is cowardice. It is not public interest, it is socialism in legal disguise. Vance, in Paris, last year, gave a speech that will go in the textbooks not for its content but for its tone. He explained, to the European audience, that we are strangling AI with our fears, that we are prisoners of our own due-process scruples, that the future will not wait. It was a speech designed to be shared in forty-second clips. It worked very well for that purpose. It worked less well as an analysis of a rule that, let us recall, does not ban the development of AI but articulates it according to risk levels. The conceptual framework of the AI Act is the same framework with which any industrial civilisation regulates dangerous chemical substances, pharmaceuticals, automobiles, food intended for children. No one is asking Vance to stop thinking that regulation is always excessive—it is a legitimate political position with its own tradition. Only, let him present it for what it is, not as the neutral observation of a neutral observer.

There is an argument one hears often that I think deserves a reply. It is the argument of the race. AI is a race, we are told, and Europe is losing it. While we write regulations, China builds, the United States builds, and in five years we will be irrelevant. Fine. I concede this too, in part. On computational infrastructure and venture capital availability Europe is in fact behind, and will be for a long time, and this is a serious problem that would require real industrial policy, substantial public investment, integration of the European capital market, reform of academic labour, none of which we have been seriously discussing for decades. But the race, what race exactly. A race is defined by its finish line. What is the finish line. Having our own version of OpenAI. And then. Having our own version of Meta. And then. That is, having companies that do what, for whom, to obtain what, selling what to whom. The question is not idle, because the companies that Vance’s friends propose to us as a model are companies whose value is largely built on a precise assumption: that personal data can be collected and used with minimal limits and that attention-based business models can scale without substantive constraints on child protection. If Europe wants to be the one chasing that model and trying to replicate it, then yes, it is losing. If Europe wants to be the one proposing an alternative, the race is a different race. It plays on different ground. It is won by different rules. And in that case regulation is not a brake. It is the product.

Brussels Effect and the Stars-and-Stripes Regulatory Wall

I realise this sentence sounds presumptuous, and in part it is. But it is the heart of the matter. The Brussels Effect, which Anu Bradford has been writing about for at least a decade, is not a rhetorical invention. It is a concrete mechanism. When the European Union sets a standard, and when the European market is large enough that it cannot be ignored, global firms end up adopting that standard as default, because keeping two parallel architectures costs more than keeping one. GDPR has been an informal default for years in the design of data-management systems inside companies that operate globally. European accessibility specifications end up being implemented everywhere, because anyone selling even a third of their products in Europe designs a single interface. The CRA will produce a similar effect on software. The PLD will produce a similar effect on product liability. The AI Act will produce a similar effect on the risk classification of automated systems. This is not reverse colonial imposition, it is the ordinary functioning of the market, and it is precisely for that reason that it angers the techno-optimists, because their companies are forced to adapt to rules they did not write.

Then there is the regulatory-wall argument. Europe, we are told, is building a regulatory wall that excludes American suppliers. This argument deserves to be taken seriously, because part of it is true and part of it is false, and those who use it usually mix the two. The true part is that some regulations, in particular the Data Act, certain provisions on coordinated cybersecurity, certain rules on sovereign clouds, do have an industrial-policy component, in the sense that they try to encourage the emergence of a European technological offering in critical sectors. This is no mystery, it is written in the recitals, and it is a legitimate activity that every state and every economic area in the world undertakes. China does it openly, the United States does it with the CHIPS Act and the Inflation Reduction Act, with the renewed control over foreign investment, with the export bans on advanced GPUs. The novelty is not that Europe is doing it. The novelty is that it is doing it with a European specificity, based on transparency and accountability requirements, on an explicit concern for fundamental rights. To the eyes of an American investor in the Andreessen Horowitz orbit, that is an anomaly. It is one to the extent that the American investor regards regulatory activity as, in itself, a political aberration.

The false part, instead, is the claim that the European regulatory wall is different from any other regulatory wall in the world. Try exporting medical software to the United States without the FDA. Try selling a financial service to American consumers without SEC or FINRA authorisation. Try operating an autonomous vehicle at federal level without engaging the NHTSA. Try selling toys for children without the CPSC. The American system is full of regulatory walls, those walls have been there for decades, and they work very well as barriers to entry for foreign suppliers. When a European company complains about their weight, the standard American answer is “rules are rules, if you want to sell here you adapt”. It is exactly the same answer we give today to anyone protesting the CRA, and it has exactly the same legitimacy. Only, we give it from a position of narrative-power asymmetry that places us, from the start, on the wrong side of the argument.

The Narrative Asymmetry

This narrative asymmetry is the real spectre haunting Europe. Not the Europe that frightens others. The Europe that frightens itself, because the only dominant cultural frame in the tech sector is the one elaborated in California over the last twenty-five years, and that frame considers every regulatory act a failure by definition. From inside that frame, every European rule is a symptom of decadence. Every directive is a sign of stagnation. Every attempt to articulate a different vision of the relationship between technology and citizens is dismissed as the resentment of the loser of the race. It is a very effective frame, and it is very hard to contest from inside European tech, because European tech itself has often modelled itself on American tech, reads its blogs, adopts its tools, absorbs its vocabulary, and ends up judging its own continent through someone else’s eyes.

Let me push one step further. When I say the Californian frame is hegemonic, I am not doing barstool sociology. I am describing the fact that, at any European conference on digital in 2026, a large share of the technical lexicon, of the virtuous examples, of the interpretive frame comes from American industry literature. It is a fact. From here the problem flows, because when the European regulator tries to write a rule, it has to do so in an intellectual environment populated by operators who have absorbed the adversary’s grammar. They are not always aware of it. Often they think in good faith they are being “pragmatic”, that they stand on the side of the “facts”, that they want to “avoid hyper-regulation”. But they are using a vocabulary made elsewhere, for someone else’s purposes, and they end up producing, even from European positions, an implicit defence of the model they would like to criticise. The result is that in the corridors of Brussels progressive regulations are debated while in the feeds of Italian founders Sacks’s clips circulate explaining how those regulations are an aggression against the free market. The two coexist. More than that, they feed each other. Every rule written in Brussels produces a new round of complaints in San Francisco, every round of complaints in San Francisco produces a new cultural concession from a slice of the European business class, every cultural concession produces, downstream, a political weakening of the next legislative process.

The Project, and Why It Must Be Named

At this point, after two waves of concession and one of analysis, the reader has probably guessed where I am going. I would like us to be very clear on one thing. The hatred for European digital regulation, the real, visceral kind found in David Sacks’s posts, in Joe Lonsdale’s interviews, in Balaji Srinivasan’s paranoias, in JD Vance’s set-pieces, is not a technical disagreement. It is a political position, and a precise political position, and it must be recognised for what it is. That position holds that nation states should retreat in the face of tech companies, that tech companies should enjoy a functional sovereignty equal to or greater than that of states in the territories where they operate, that representative democracy is too slow for the rhythm of innovation, and that in case of conflict it is democracy that must adapt. This is a coherent position, and a position with thinkers, books, manifestos, even refined theoretical elaborations behind it, from Ayn Rand’s libertarianism to Curtis Yarvin’s neo-reaction by way of right-wing accelerationism drawing on Nick Land, all the way to Thiel’s most recent syntheses on stagnation. It is not caricature, even if its popular version is. It is a project.

It is worth pausing on this project for a moment, because for a long time it was underestimated in Europe, and perhaps still is. The strand starting from Yarvin, in particular, openly maintains that representative democracy is a dysfunctional system and that it should be replaced by forms of government run as enterprises, by CEOs with full powers, untethered from constitutional constraints. Until ten years ago this was a position regarded as folkloristic even by mainstream American conservatism. In the last five years it has normalised, entered the conversations of Sand Hill Road, found implicit and explicit funding inside Thiel’s network, colonised parts of the Republican Party, and ended up sitting inside the White House with a vice president who quotes Yarvin in public without embarrassment. To put it another way, a significant slice of the current American ruling class regards the post-war liberal-democratic order as a failed experiment, and regards its own techno-corporate model as the natural historical successor. In that frame, the European Union is not just a commercial nuisance. It is, literally, an embodiment of everything they want to overcome: a supranational subject that imposes transparency standards on firms, that protects competition, that places limits on the producer’s freedom in the name of rights that cannot be bought or traded. For those who think the future should be governed by the best, and that the best are the winners of the market, Europe is a historical enemy.

I realise that put this way the matter may sound exaggerated, and that many Italian readers, perhaps not prejudicially hostile to American tech culture, will tell me I am caricaturing in reverse. I am not caricaturing. I am simply taking seriously the things the people in question publish openly on their own profiles. Go and read Marc Andreessen’s interviews from 2023 and 2024. Go and look at the techno-optimist manifesto. Go and read Yarvin’s 2024 book. Go and listen to the All-In podcast, especially the segments commenting on European regulation. Go and watch Vance’s speech at the Paris AI summit in February 2025. I am not reading anything between the lines. It is all above the lines, written with a frankness that, from where we stand, is almost disarming. The only thing that stays between the lines is the political conclusion, and the political conclusion goes like this: democratic authority has no standing to set limits on the activity of tech companies, because tech companies are building the future and democratic authority belongs to the past.

Against this project, the European Union, with all its slowness, all its imperfections, all its cookie banner, is in fact the principal contemporary geopolitical obstacle. It is not because it has a plan against American tech, but because its model embeds an assumption the Californian project wants to demolish: the assumption that democratic authority can legitimately set limits on the economic activity of firms. That is all. It is an old assumption, present in the constitutional tradition of every European country and of the pre-Reagan United States, but in the cultural climate of 2026 it has become heretical. Our heresy consists in taking up that assumption again and applying it to digital. Nothing more, nothing less. That is why we are a spectre: because we remind the world, by our very institutional existence, that thinking otherwise is possible.

Coherent Europe, Misplaced China

Let me pause to answer an objection I can imagine. But is Europe really that coherent. Are there no internal divisions, no lobbies, no national manoeuvres, no regulatory mess. Of course there are. Europe is a complex political system, with diverging interests among member states, with Germany often defending the interests of its automotive industry even when this conflicts with environmental coherence, with France often trying to promote national champions under the cover of European industrial policy, with Italy often weakly represented technically at the tables that matter, with national governments using hostility to European regulation as a tool for domestic consensus. All this exists. But none of it changes the fact that the regulatory output of the European process is, in the end, coherent with a certain model of the relationship between technology and citizens, and that this model is radically different from the American one, and that the difference is the real object of the conflict.

Another objection. And China. China, in the anti-European discourse, is always wheeled out as a reductio ad absurdum: you regulate, while China builds, and China will win. This is a rhetorical move so ramshackle that often it is not worth engaging with, but one detail is worth noticing. The Chinese model of digital governance is one in which the state, identified with the Party, exercises a very deep control over platform behaviour, content, data, international flows. Beijing has a level of regulatory intervention over the Chinese TikTok algorithm that would make the DSA look like a kitchen-robot instruction booklet. Yet when the techno-optimists cite China as a model of non-regulation, they do not say so. They limit themselves to citing the speed at which infrastructure is built, the speed at which AI applications spread, the speed at which sites like Temu and Shein are shut down. They skip, with notable elegance, the existence of the state. This is because, deep down, their problem is not the state as such, it is a democratic state that imposes constraints on their friends. Faced with an authoritarian state that imposes generic constraints on everyone while guaranteeing itself an unchallengeable dominant position, they have far less to object to. The point is democracy, not regulation. Regulation is just the form that democracy, in a digital world, takes in legal terms.

Technique in the Service of Politics

I would like to close by stitching some of the fabric back together, because I started by quoting Marx and it is right that the circle should close. The spectre of the Manifesto was a promise of transformation. It was something that, in the eyes of the nineteenth-century ruling classes, represented the possibility that the future would not simply be the continuation of the present. The spectre that today disturbs the dreams of Californian venture capitalists promises no revolution. It promises only that the digital future can also be designed by subjects other than their portfolios, according to principles other than theirs, inside an institutional frame that precedes their model and will survive its eventual crisis. It is a modest spectre, and that is precisely why it is unbearable, because it dismantles the claim of exclusivity that the Californian model has arrogated to itself for a quarter of a century. It dismantles the idea that there is only one legitimate way to do digital technology, according to rules written by a specific community of investors in a specific geographic area of the planet. It returns to technology its status as a plural cultural artefact, subject to plural institutions, contestable and contested. For those who believed they had won history, this is an affront.

For those of us who do this craft, on this continent, in these years, the spectre is not a nuisance. It is a compass. It is what tells us, every morning, when we open a pull request or write a tender specification, that technical choices have political consequences and that political consequences deserve to be protected by law. We do not do this because we are decadent. We do it because we have a long historical memory, and we know that technologies without limits, in the previous four hundred years, have produced the exact opposite of the freedom they promised. We do it because we have read Polanyi, we have read Hannah Arendt, we have read the constitutional fathers of our continent, we have read the European jurisprudence on fundamental rights, and from all this material we have drawn a simple conclusion. The market is not a fact of nature. It is an institution. And like all human institutions, it has to be built and corrected over time. Digital is a market. Its rules do not descend from the Silicon Valley sky. We write them too, here, in the middle of a continent that is slowly noticing it has become the strangest place in the world: the place where someone still tries to say that technique should serve politics, and not the other way around.

There is one last thing I would like to say, and I will say it in a more personal register, because that is the right register to close in. When I happen to talk about these things with American colleagues, usually within three minutes the moment arrives when I am asked, with a shade of sincere pity, whether I do not feel suffocated, in Europe, by all this bureaucracy. The question is asked in good faith. They genuinely think we live in a kind of regulatory cage that prevents us from building. The most honest answer I can give is that no, I do not feel suffocated. I feel I am in the right place. Because here, at least here, the question “what does this software do to people” is a legitimate question, it is a question that can be put to a board of directors, it is a question that has legal consequences if the answer is bad. Elsewhere the same question is considered, at best, naive. At worst, subversive. There. I prefer the state of affairs in which I can ask it, even if to ask it I have to accept a little more paperwork, a few audits, a few EDPB templates, a few conformity assessments. It is a price. You pay it. It is not a cataclysm. If anything, it is the price of civilisation.

The spectre haunting Europe is us. And we will keep on being it as long as someone, somewhere, still considers technique to be a political question and not a question of pure engineering. That is no small thing. That is no small thing at all.

The contract had been signed at the end of 2023, and from the prime vendor’s standpoint it was a clean, well-structured contract, with all the safeguard clauses the legal department had insisted on over the years. It clearly specified the subject matter of the supply, set out service levels, fixed penalties for non-compliance, defined the perimeter of vendor liability with standard caps at the contract’s annual value, excluded indirect damages, and governed subcontracting through a clause that required the client to approve the main subcontractors and that placed on the client the burden of verifying their adequacy. It had been negotiated for four months, gone through three rounds of legal review on both sides, signed by executives with the necessary powers. The prime vendor, a software house of fifty people, considered it a good contract. The client, a private healthcare company with a million enrolled patients, considered it a balanced contract. For two years the relationship went well.

At the end of 2025 a patient suffered harm from something the clinical system should have done and didn’t do. The technical cause was traced to a risk-evaluation library the system used to classify intervention priorities. The library had been supplied by a subcontractor approved by the client four years earlier, had been silently updated by the subcontractor itself eighty days before the incident with an algorithm change that no one had communicated to the prime vendor, and no one had requested a documentation update because the subcontractor considered its update routine maintenance. The subcontractor was based in a third country, had no legal representative in the Union, and in the months that followed the lawsuit turned out to be effectively unreachable for judicial notices.

The prime vendor reacted to the patient’s lawyer’s damages request by showing the contract. They argued that the subcontractor had been approved by the client, that the change had been introduced unilaterally by the subcontractor without any communication, that the contract excluded indirect damages and capped liability at the annual value, and that in any case material liability fell on the client as the entity that directly managed the relationship with the patient. The patient’s lawyer did not contest any of these contractual points. He simply noted that the contract between vendor and client did not concern him, because he had not signed it, and that his action was based on the new European product-liability regime, under which the prime vendor qualified as the producer of the defective product and was strictly liable toward the final injured party regardless of the clauses agreed with the client. Those clauses, he added, governed recourse between the signing parties, not exposure toward third parties. The contract, in other words, was a good contract between the wrong people.

The traditional objection

The objection I want to address right away, because it is the most rooted and the most sincere, is the one that comes from traditional lawyers I have worked with over the years. It goes like this: this is all a problem of contract drafting. If the clauses are well-written, if the indemnities are complete, if the subcontracting procedures are rigorous, the prime vendor is protected. It is an objection formally consistent with how contract law has functioned for forty years in software. Until a few years ago it was also substantially true, because the software-producer liability regime was weak, third-party injured-party actions almost always passed through the direct client, and the prime vendor could reasonably expect its exposure to be exhausted within the agreed contractual limits.

That era is over. The legal regime now consolidating in Europe between 2024 and 2027, which I have already written about in this series with respect to software-as-written-promise and the specification as the legally relevant asset, introduces a level of liability that operates outside the contract and that the contract can only partly govern. The revised Product Liability Directive, applicable from 9 December 2026, explicitly qualifies software as a product and applies a regime of strict liability to the software producer toward final injured parties. The Cyber Resilience Act, fully applicable from 11 December 2027, introduces digital-product security obligations that bear on the producer along the entire lifecycle and extend to integrated components. The AI Act distributes obligations along the chain of AI-system providers so that the provider of the final system has to ensure that integrated components are compliant. The Digital Operational Resilience Act, applicable from 17 January 2025, imposes on financial entities and their critical ICT vendors supply-chain risk-management obligations that cross contractual boundaries. NIS2, applicable from 18 October 2024, makes the same move for the expanded critical sectors. Each of these acts, taken individually, would be manageable with some contractual adjustment. Taken together, and at their intersections, they define a structure of liability that the supply contract is no longer able to contain.

The four collapsed assumptions

The traditional contractual model of software grew up in an era in which certain implicit assumptions held, and it has become inadequate because all those assumptions collapsed in the same decade. There was, first, the idea that the vendor’s liability toward the client exhausted the vendor’s exposure, because the intermediate client absorbed and managed any liability toward third parties. There was then the conviction that software was an object delimited at the moment of delivery, assessable on the basis of a static specification at release. It was assumed, third, that the supply chain was essentially bilateral from a legal standpoint — that each link could be governed by a contract between two parties without having to worry about the chain’s overall dynamics. And it was assumed, finally, that the liability regime would remain stable over time, enough to make it reasonable to sign multi-year contracts under the legal framework in force at signing. These were assumptions that looked like laws of nature of software contracting until around 2020, and that in retrospect turn out to be merely the characteristics of a specific legal era.

The first assumption was eroded by the broadening of the active legitimacy of third-party injured parties under the new PLD. Under the old product-liability regime, the final injured party could act against the producer, but in practice actions mostly went through the reseller or commercial integrator, and the software producer, until 2024, enjoyed interpretive uncertainty about whether it even fell within the definition of producer. The new Directive, by including software explicitly in the definition of product and introducing defect presumptions that lighten the injured party’s burden of proof, makes the software producer’s position much more exposed. It also adds a documentary disclosure mechanism allowing the judge to order the vendor to produce the technical documentation of the product, and to presume defect in case of non-disclosure. From that moment the injured party’s lawyer no longer needs to go through the intermediate client, and can act directly against the prime vendor of the software that caused the harm, ignoring entirely the contractual clauses between vendor and client, because those clauses govern a relationship to which the injured party is a third party. The point is written explicitly into Article 15 of the Directive, titled “Exclusion or limitation of liability”, which requires Member States to ensure that the liability of the economic operator toward the injured party cannot be limited or excluded either by contractual clauses or by national-law provisions. It is a short, technical article, but it is the keystone of the entire structure, because it transforms what looked like contractual room for manoeuvre into a zone of legal indisposability.

The second assumption was eroded by the Cyber Resilience Act and the AI Act, both of which introduce security and risk-management obligations bearing on the producer along the entire product lifecycle, not only at the moment of delivery. Software has stopped being an object delimited at the time of delivery and now stands as an object continuously exposed to the regulatory regime. Every update, every modification, every integration of new components can be requalified as a substantial modification that brings the product back within the regime, even if the product was placed on the market in an earlier era. The prime vendor that delivered the system in 2023 did not unload its liability in 2026 when a third-party library integrated into that system stopped being maintained and developed security vulnerabilities. Liability simply shifted to the maintenance plane, and the vendor that did not update is a vendor that has failed a continuing obligation, not an obligation limited to the moment of original delivery.

The third assumption, the bilateral nature of the supply chain, was also eroded by the introduction of liability chains that cross bilateral contracting. Under the DORA regime, the financial entity must map and manage its ICT third-party risk along the whole chain, and when a vendor is qualified as critical the obligations extend so that the contractual clauses between the financial entity and the critical vendor must contain specific elements imposed by the Regulation, regardless of the parties’ will. The CRA, for its part, requires the producer of a digital product to guarantee the security of the integrated product, and that guarantee is not exhausted in contractual relationships with its subcontractors, because the regulator assesses the product as a unitary whole regardless of the internal composition of the supply chain. The revised PLD adds a further complication, providing that the substantial modifier of a product can themselves become liable as the producer, and this opens a circular liability dynamic in which the prime vendor, the intermediate integrator, the subcontractor and the final user can be sued under different titles for the same harm. NIS2 and the AI Act complete the picture, extending analogous obligations to expanded critical sectors and to high-risk AI systems respectively, with the result that every chain segment is today crossed by at least two or three overlapping regimes that bilateral contractual clauses cannot reconcile.

The fourth assumption, regulatory stability, is the one whose erosion produces the most insidious effects, because multi-year contracts signed today under the current framework will be applied tomorrow under a framework that will have evolved. The vendor signing a six- or seven-year contract in 2026 will find itself executing it in 2032 or 2033 under regimes that may have changed significantly by then, because the PLD provides for a revision clause, because the CRA will be the subject of guidelines that will modify the interpretation of entire sections, because the AI Act has already been described as an open construction site by the Commission itself. The multi-year contract under the traditional model presupposed a regulatory inertia that no longer exists.

Four phenomena the contract cannot address

Each of these four phenomena has practical consequences the traditional contract cannot address. Joint liability of critical-component suppliers, introduced in different forms by the PLD and the CRA, means the prime vendor answers for defects of integrated components even when subcontractors are non-compliant or unreachable. The contractual clauses that govern recourse against subcontractors remain valid between the signing parties, but do not shift liability toward the final injured party, who can always act against the prime vendor as the accessible and patrimonially most solid link of the chain. The prime vendor that wanted to shift the risk onto the subcontractor through contractual clauses ends up having to absorb it, and can only later try to recover by way of recourse — assuming the subcontractor is still in existence, solvent and reachable.

Documentary disclosure obligations introduced by the new PLD are the second phenomenon, and they are particularly insidious because they turn the vendor into a subject who must show the judge their own technical documentation, even when that documentation includes design choices, security configurations, training datasets, architectural decisions the company would consider trade secrets. The judge must balance the right to disclosure with the protection of trade secrets, but in practice the vendor finds itself exposed to documentary requests the contract with the client cannot limit, because the contract does not bind the judge or the injured party. The vendor may have agreed with the client on the inaccessibility of the documentation, but if the injured party requests production, the vendor must produce, and refusal to disclose generates a presumption of defect under Article 10 of the Directive.

Defect presumptions, which the individual vendor cannot rebut alone, are the third phenomenon, and the subtlest of the four. The new PLD provides that the judge may presume the defectiveness of the product when the product is technically or scientifically complex and proof of the defect would be excessively difficult for the injured party. For complex software systems, especially those integrating AI components, this presumption activates almost automatically, and the burden of rebutting it falls on the vendor. Rebutting the presumption requires demonstrating that the product at delivery did not present the defect, or that the defect was introduced later by modifications outside the vendor’s control. Both demonstrations require detailed historical documentation of the system, and the vendor that did not maintain such documentation finds itself unable to prove anything, and therefore succumbs to the presumption.

Substantial-modifier accountability is the fourth phenomenon, and the one that most radically breaks the bilateral contract structure. When a client or intermediate integrator substantially modifies a software product supplied by a third party, they can themselves become liable as the producer of the modified product, and this opens a dynamic in which the original vendor may no longer be liable for the product as modified, but the modifier may not have the competence, documentation and structure to assume the liability they have materially assumed. The result is a grey zone of liability where the injured party chooses whom to sue based on patrimonial and procedural accessibility, and where the parties involved volley liability among themselves with often paradoxical outcomes.

The settlement that doesn’t arrive soon

One could object, and someone will, that all this is exaggerated and that judicial practice will find a way to bring order back to the system. It is an objection that deserves respect, because judicial practice has always had this stabilising function, and because European regulations, once translated into national case law, often lose the rigidity they have on paper. The answer I am willing to give, after observing how practice is moving in the European jurisdictions where the first cases are emerging, is that the settlement will come, but it will come in five or seven years, and in the meantime the exposure window for vendors operating under traditional contracts is very wide. The first relevant rulings on software-producer liability under the new PLD will not arrive before 2028, because the regime applies to products placed on the market after 9 December 2026 and cases have minimum lead times of a year and a half. From then it will take another three or four years for consolidated case law to form. Meanwhile, every vendor operating with old-model contracts is accumulating retroactive exposure, because many of the systems being delivered today will still be in production when the case law has settled, and they will be assessed against the criteria that have consolidated by then.

The sectors that came before us

It would be dishonest not to recognise that there are sectors where these dynamics have existed for decades, and where supply contracts have a structure that recognises the inadequacy of the traditional bilateral model. They are sectors that have lived under tight product-liability regimes long before general-purpose software, and they have developed contractual practices worth studying. Civil aviation is one, and aircraft-component supply contracts have always incorporated obligations of documentary traceability, third-party certification, coordinated handling of non-conformities, joint liability toward regulatory authorities. Medical devices are another, and supply contracts for medical-device components include quality-framework agreements that go beyond the single commercial contract and govern the relationship between the parties as a regulatory relationship as well as a commercial one. Automotive is the third, especially after the introduction of the ISO 26262 functional-safety standards for vehicle electronic systems, and software supply contracts for automotive have for about a decade incorporated chain-of-liability clauses that recognise the impossibility of confining exposure within bilateral relationships.

What is happening in general-purpose software is convergence — accelerated by the European regulatory package — toward the model these sectors already practise. The difference is that aviation, medical devices and automotive have had thirty years to build their contractual practices, internal competencies, sector standards and structured supply relationships. General-purpose software has five or seven years to do the same thing, and must do it while continuing to operate in markets where most competitors still reason within the old model. It is an asymmetric transition, in which whoever moves first pays a positioning cost that whoever moves later does not pay — but whoever moves first also builds capacity to absorb the subsequent regulatory evolutions that whoever moves later will have to acquire at consolidated-market prices.

Five operational dimensions

On an operational plane, the transformation of the software supply contract has five dimensions to be managed simultaneously. The first is the move from contract-as-document to contractual documents as ecosystem. A software supply contract under the new regime is not exhausted in a single document valid until renewal, but constitutes a system of related documents including the master contract, service-level annexes, security annexes, quality agreements similar to those of medical devices, personal-data processing agreements under GDPR Article 28, coordinated vulnerability-handling agreements, mutual supply-chain disclosure agreements. Each of these documents lives with its own update cycle, and the master contract becomes the framework that holds them together, not the container of all clauses.

The second dimension is the transformation of the limitation-of-liability clause. Traditional clauses that cap vendor liability at the contract’s annual value, or that exclude indirect damages, remain valid between signing parties but produce no effects toward third-party injured parties. For the vendor this means actual exposure is exposure toward the final injured party, not the one agreed with the client, and insurance policies must be sized on that actual exposure, not on contractual caps. Insurance practice in the sector is currently confused, because companies are redefining product-liability products for software producers in light of the new regime, and premiums are rising non-linearly. For mid-size Italian software houses, the insurance cost of product liability is becoming a significant balance-sheet item, where until a few years ago it was a negligible one.

The third dimension is the rewriting of subcontracting clauses, which must move from a model in which the client approves the main subcontractors at signing to a model in which there is a continuous procedure of evaluation, monitoring and disclosure of subcontractors throughout the contract’s duration. The prime vendor must be able to demonstrate at any moment the composition of its supply chain, must be able to produce the SBOM under the CRA, must be able to respond to audit requests from the client or the regulator, must manage situations in which a subcontractor exits the market or ceases maintenance of a component. All this requires supply-chain management tools that the traditional contractual model took for granted and that today become continuous operational activity.

The fourth dimension is the introduction of clauses on coordinated handling of vulnerabilities and security incidents. Under the CRA, under NIS2 and under DORA for the financial sector, vendor and client both have reporting obligations within tight time windows, and meeting these windows requires coordination that the contract must govern operationally, not just formally. A clause that says “the parties shall cooperate in incident handling” is useless if it does not specify who notifies, within what time, through which channels, with what severity thresholds. The clause must be almost a contractual mini-runbook, and its quality is measured in its ability to function during an actual incident, not in its legal elegance.

The fifth dimension is the subtlest, and concerns product-lifecycle management. Under the CRA the producer must declare the product’s support period and maintain it for that period, and must manage the product’s exit from the market so that users are informed and have transition paths. The software supply contract must govern this aspect, because the prime vendor is exposed toward the final injured party even after the end of the contractual relationship with the client, and because end-of-support management becomes a critical moment when residual liabilities can materialise. The traditional clauses of “perpetual licence” or “no warranty after termination” produce no effects toward third-party injured parties, which means the vendor must manage the product lifecycle as a function exceeding the duration of the contract.

Disclosure: eighteen months of rewriting

I have to be transparent on one point, because on this subject I am describing transformations I am living through first-hand. The revision of our supply contracts, inside the company where I work, is an activity that has been underway for eighteen months and has not yet arrived at a stable form. We are working with our reference law firm to rewrite the master contract for software services, and what is coming out is far from the clean, elegant contract we hoped to produce — it has the form of a more articulated system of documents than its predecessor, with annexes that exist for different reasons and that cannot be reduced to a single template. Some clients accept the new structure; others find it needlessly complex and ask to go back to the old model. Market pressure toward contractual simplicity is still strong, and in some cases we ourselves accept to sign old-model contracts when the client imposes it, knowing we are accumulating retroactive exposure. It is a choice we make for immediate commercial reasons, and that I have called compounded exposure in our internal conversations, because it accumulates non-linearly as the client portfolio grows.

An opportunity, not just a burden

I also want to say, because otherwise the piece would sound like a pessimistic forecast about the Italian software industry, that the transformation I am describing is an opportunity before it is a burden. Mid-size Italian software houses that decide to build contractual competencies coherent with the new regime, to pair delivery work with continuous documentary maintenance and supply-chain management, to train internally the hybrid figures I described in the previous piece of this series, will have, in five years, a competitive position hard to erode. Software houses that keep signing traditional contracts in the hope that the regulatory framework won’t really apply, or that national case law will soften it, will find themselves exposed and will have to close the gap at far higher costs than today’s sustainable ones. It is one of those situations in which the decision not to decide is the most expensive of all, because time works against those who do not move, and because every contract signed today under the old model is a liability that will reveal itself in a few years, when the cases that the PLD has designed as standard scenario start appearing in the news sections of specialised media.

The centrality that dies

Putting the four pieces of this series together, the general argument I am trying to build is the following. Software, as an industrial and as a legal object, is changing nature before our eyes, and the engineering and commercial culture of the sector is not adapting at the speed the moment requires. The first piece, Cruft, Not Patina, argued that software does not know how to age the way material objects do. The next, The Specification Debt, shifted attention to the fact that the written specification has become the legally relevant asset of the product and that our industry lacks the tools to keep it alive. Then came The Rise of the Compliance Engineer, devoted to the hybrid professional figure emerging to oversee the gap between engineering and regulation. In this fourth piece the argument shifts from the plane of product and labour to the plane of the relationship between organisations, and the thesis is that the supply contract — the classic legal instrument of that relationship — is becoming one instrument among others within a wider, more structured relationship that traditional contract law can only partly govern.

The software supply contract is not dead, and nothing of what I have written should be read as a forecast of its disappearance. What is dead is its centrality, the idea that the relationship between vendor and client can be exhaustively described by a bilateral document negotiated at the start and updated at renewals. The contemporary relationship is multilateral, regulatorily loaded, dynamically exposed to third parties the contract does not bind, and crossed by continuous documentary obligations the contract can only summarise. Thinking that better-written clauses are enough is an understandable, human nostalgia — and also the fastest way to accumulate exposure while believing oneself protected. Clauses still matter, and matter more than before, but they matter as elements of a wider device that contains and exceeds them.

The contract, as we have known it, has become the gentle deception that lets software vendors believe they know what they are exposed to. Traditional contracts will keep being signed for some years more, because the market moves more slowly than the law, and because the old model is familiar and the new ones are still forming. But whoever keeps signing traditional contracts in the next five years is signing, alongside the contract, a quiet bet that things will not really change. It is a bet that my generation of those who make software in Europe will probably lose, because things are already changing — and what today looks like an excess of caution from the few who are moving will turn out, in a few years, to be the prudential minimum that was required from the start.

The job posting had appeared in February on one of those boards where mid-size Italian companies look for technical people without being too sure what they are looking for. The position title was “Senior Software Engineer with Regulatory Background”, and there was already something strange about it, because in Italian a phrase like that does not mean anything precise. The body of the ad clarified little. It asked for at least five years of backend development experience, preferably Java or Python, knowledge of Kubernetes, experience with CI/CD pipelines. Up to here, a normal senior developer profile. Then the text changed register and started asking for in-depth knowledge of the GDPR, command of the AI Act regarding high-risk systems, the ability to draft DPIAs and risk assessments, experience with compliance frameworks such as ISO 27001 and SOC 2, the ability to interface with external auditors. The salary indicated was that of a senior developer at market rate, with a small unquantified premium for the regulatory competencies.

I read that posting ten times trying to understand who they were really looking for. A person like that, with that combination of skills, does not exist in Italy in meaningful numbers today, and when they do exist they cost twice what the company was offering. Whether the company knew this or not, hard to say. What is certain is that they had a real need, because they were about to deliver a system to a regulated client and did not have the right person in-house. They had senior developers who could not read a European Regulation, an in-house lawyer who could not read code, and an external compliance consultant who could speak with one of the two but not the other. The person they were looking for existed in their head as a translator between worlds that were not speaking to each other, but that person did not yet have a stable name as a trade.

The posting was reissued in March under a different title, “Compliance Engineer”, with no other changes to the body. Then it disappeared. I do not know whether the company found someone or gave up. What I do know is that postings like that, with minimal variants, I am seeing one or two a week passing on Italian boards, and many more on European ones. I am watching a craft looking for its name, one that will find it in the next two or three years because it has no alternative.

The technological objection

The objection I want to address right away, because it is the most serious and because it always comes from C-levels who are minding the costs, is the technological one. It goes like this: all the work you describe will be done by AI in three years. An agent will read the system, read the regulation, produce the mapping, update the documentation, flag the inconsistencies. There is no need to build a new professional figure — wait for the technology to mature. It is an objection with apparent plausibility, and it is widespread enough to deserve an answer. The answer is that AI will do ninety per cent of the mechanical work, and I am not making a cautious-cautious forecast here, I am describing what it already does in contexts where it is applied seriously. What remains, the ten per cent, does not correspond to the residual ten per cent we presume will vanish as models improve. It is the interpretive and political ten per cent, and it is precisely the part that requires a human being who understands at the same time the system’s architecture and the Regulation’s structure, and who knows how to choose how to align the two when the letter of the rule and the reality of the software come into tension — which happens far more often than regulators would care to admit.

Inverting the perspective, in fact, it is precisely AI that makes the compliance engineer figure economically viable. Without generative assistance, the volume of documentation required by the new European regime would be unmanageable for anyone who is not a multinational with a dedicated team of thirty. A software house of ten or fifteen cannot afford two full-time figures on this function, and indeed today it does not have them. But with well-configured AI assistance, one well-trained person can oversee the compliance of all the company’s projects with a quality that five years ago would have required a small team. The question to ask, then, is not whether AI will replace the compliance engineer — it is the exact opposite. Without AI, the compliance engineer would not exist as a role accessible to SMEs; it would only exist as a department in big companies. With AI, it becomes the synthesis figure that allows even mid-size organisations to operate in regulated markets without externalising their regulatory intelligence.

An institutional distance

Reconstructing how the conditions for this figure to emerge came about deserves some detail, because its genesis is typically Italian and European, and understanding the genesis helps understand why the trade has the shape it has. The starting point is an institutional distance between two academic and professional traditions that in Italy, more than elsewhere, have never seriously met. On one side computer science engineering, formed in engineering faculties, with historical attention to how software functions as a technical object. On the other side law, formed in law schools, with historical attention to norms understood as texts to be interpreted. The two traditions do not speak to each other — not because there are no people of good will trying to build bridges, but because curricula do not include the bridge as a structured object of study. The engineer leaves university knowing how to write code and design systems, but with an exposure to law that, at best, is limited to a one-semester course in IT law, often delivered by a teacher who studied software as a phenomenon and not as a practice. The lawyer leaves university knowing how to interpret norms, but with an exposure to software that, at best, is limited to a few conferences and a handful of popular manuals.

This distance was not a serious problem as long as software was assessed on functional, performance and commercial criteria. When software started to be assessed also on regulatory criteria, the problem exploded, because organisations found themselves having to certify to the regulator that their system met obligations that neither their developers nor their lawyers fully knew how to translate. The GDPR, applied from May 2018, was the first serious test. For years the response of Italian companies was either to outsource compliance to specialised consultants — who produced adequate documents but rarely went into the code — or to appoint an internal or fractional Data Protection Officer who spoke with the lawyer but little with engineering. It worked badly, but it worked enough, because the GDPR alone was not enough pressure to bring a new professional figure into being.

The pressure needed has arrived in the past three years with the accumulation of acts in the European digital regulatory package. AI Act, Cyber Resilience Act, revised Product Liability Directive, NIS2, Digital Operational Resilience Act for the financial sector, Data Act, European Accessibility Act. Each of these regulations, taken individually, would have been manageable with traditional methods. Taken together, and in the compressed times in which they have entered or are entering into force between 2024 and 2027, they have made the situation structurally different. Organisations producing software for the European market have found themselves with documentary, risk-assessment, security, traceability and accountability obligations that multiply and intersect in ways that demand an integrated view. The external consultant who produces one document at a time is not enough. The in-house lawyer who does not read code is not enough. The senior developer who explains the system to auditors twice a year is not enough, and neither is the combination of the three figures coordinating in periodic meetings — because coordination by periodic meetings is exactly the device that generates specification debt. You need someone who does only this, and does it every day, inside the organisation.

Three slices into one person

On a taxonomy-of-roles level, what is happening is that the compliance engineer is absorbing slices of work currently distributed across three distinct roles. First slice, the senior dev who today explains the system to auditors. It is a figure that exists in almost every organisation of a certain size, almost always a senior who has known the system for years and gets pulled out of development projects to do presentations to third parties. They do the work reluctantly because it is not what they were hired for, they do it with mediocre quality because they lack the documentary tools to do it well, and they fill their time with activities that drain value from the main role. Second slice, the architect who today translates regulatory requirements into design choices. This figure too is present almost everywhere, usually an architect who self-trained on regulation because someone had to, and who does it in the time left over from technical decisions, with the result that their design choices are excessively cautious where the regulations are ambiguous, and that they often over-regulate the system, generating useless operational friction. Third slice, the in-house lawyer or compliance consultant who today tries to read code without knowing how. This is the most frustrated figure of all, because they have formal responsibility but lack the technical tools to exercise it, and they end up asking devs things devs cannot translate into practice, generating a communicative loop that produces formally correct but substantively inert documents.

A typical day

The compliance engineer takes the three slices and brings them together in one person, with dedicated time and dedicated tools. A typical day, in a mid-size company that produces software for regulated clients, starts with a review of the week’s tickets to identify which code changes impact compliance. It continues with a working session on a specific pull request to discuss with the architectural reviewer the effects of a change on personal data flows. It carries on with a call to the in-house lawyer to clarify a contractual clause the client proposed that might come into tension with our technical security appendix. The afternoon goes to updating the DPIA of project X, because the third-party vendor changed hosting data centre and that modifies the cross-border flow mapping. It closes with a sprint planning meeting where the compliance engineer presents the documentation requirements for the next three tasks, so the team knows what to produce in addition to the code. None of this is legal in the strict sense, none of it is technical in the strict sense. All of it is techno-legal, and it is the hybrid nature of the work that justifies the figure.

Two degenerations

The risk of the role, which has to be named explicitly because it is the main risk, is that it can degenerate in two pathological directions, both already observable. The first degeneration is the compliance engineer as bureaucratic gate-keeper who blocks releases. It is the most visible and most damaging version, because it pits the compliance presence against delivery, and once that opposition stabilises the organisation loses both speed and compliance quality. The gate-keeper produces ever-longer checklists, demands ever-more articulated approvals, delays releases for reasons that look like formalisms to developers, and ends up being perceived as a cost to minimise rather than an investment to preserve. The second degeneration, opposite in symptoms but identical at the root, is the compliance engineer as policy decorator who signs documents without reading the code. You see this more in companies where the figure is introduced because a regulated client or an imminent audit requires it, and where the role is given to a person chosen for their willingness to bear documentary loads rather than for their actual ability to read the system. The decorator produces formally perfect documents, fills every required field, gets management to sign, and meanwhile the real system evolves in directions the document no longer describes. It is exactly the condition I called specification debt in the previous piece of this series, and that the compliance engineer should counter but instead contributes to generating if interpreted poorly.

Both degenerations have a common cause, which is the lack of structured training for the figure. When a trade has no academic reference path, everyone constructs it from their own provenance. The developer who becomes a compliance engineer brings the bias that compliance is a service function of the code, and tends to underestimate the legal consequences of technical choices. The lawyer who becomes a compliance engineer brings the opposite bias, that code is a service function of the norm, and tends to over-regulate with heavy technical and organisational consequences. A third trajectory, increasingly frequent, is that of the sysadmin who becomes a compliance engineer through natural affinity with documentary practices, and tends to build certification pipelines that live parallel to and never joined with the application development cycle. There is also a fourth trajectory, rarer but more promising, of those who arrive at the figure through mixed paths — for instance, those who have worked for years in product management on regulated products and have developed sensibility for both sides of the fracture. None of the first three trajectories produces, on its own, a compliance engineer up to the task. They produce half-figures that work in some companies and some contexts and fail elsewhere.

A real bicameral competence

What would be needed, and does not exist today, is a structured training path that starts from the assumption that the discipline is genuinely two-headed, engineering and legal at once, and that both halves require solidity, not superficiality. The compliance engineer’s software engineering is distinct from the simplified, generalist version found in popular courses, and demands real software engineering, with command of distributed architectures, application security, code lifecycle, DevOps practices, data modelling. The compliance engineer’s compliance, likewise, goes beyond the operational and checklist-driven version found in business school courses, and demands real European jurisprudence, with command of the Regulations, ability to read recitals, knowledge of Court of Justice case law, ability to anticipate the interpretive evolution of national authorities. A person who has all this is not formed in a six-month master’s, they are formed in some years of work guided by serious mentors, and serious mentors are still few.

The Italian university, from this point of view, is structurally late. Computer science engineering degrees, even the best ones, dedicate to regulatory compliance an amount of hours that is risible compared to the weight this discipline has assumed in the market. Law degrees, even the best ones, dedicate to software-as-regulated-object an amount of hours that is risible compared to software’s centrality in the economy. There are post-graduate master’s programs that try to fill the gap, and some are well done, but they are master’s — that is, six- or twelve-month complementary trainings that do not build the double competence from the ground up, they overlay it on a pre-existing competence. The result is that companies looking for compliance engineers do not find them trained by the university system and have to self-train them internally, with the time and cost that entails. It is a classic market distortion, where demand exists and supply has not yet consolidated, producing positions vacant for months and volatile salaries.

Big consultancies and the gap

The market segment that has already noticed the phenomenon, and is moving to occupy it before the others, is the big consultancies. It is the most visible and most ambivalent phenomenon, and it has to be assessed without moralism but with realism. Big consultancies have commercial muscle, presence with corporate clients, industrial processes for deploying professional figures, and budgets to produce internal training at speeds universities cannot sustain. They are building “compliance as a service” offerings that package the compliance engineer’s work in saleable bundles. The problem, and I say it without naming any specific actor because the problem is categorical and not individual, is that the version of the figure big consultancies are building is almost always the policy-decorator version. It is the most commercially scalable, easiest to sell, easiest to industrialise. The compliance engineer as a real techno-legal translator, the one who enters the code and modifies architectural choices, does not scale well in the consultancy model, because it requires continuity on the client that the project-based model typical of big consultancies does not easily provide.

The gap that big consultancies will not manage to cover, and that mid-size software houses could cover, is the compliance engineer internal to organisations producing software for regulated clients. Mid-size software houses, between ten and fifty people, are in a structurally better position to build this figure than either big consultancies or the regulated companies themselves. They have the technical proximity to the code that consultancies lack, the plurality of clients that regulated companies lack, the size that lets them sustain a dedicated person without externalising. What many Italian software houses do not have, and that is why they are not moving fast enough, is the awareness that the transformation is already underway and that whoever covers it first will gain a positional advantage hard to erode in the following five years.

On an operational level, building an internal compliance engineer means investing twenty-four to thirty-six months on a person who already has half the necessary skills. The typical candidate is a senior developer with curiosity for the regulatory dimension, an architect with sensibility to security and privacy, or a product manager with a certain taste for formalisation. The growth trajectory includes shadowing on real cases, systematic reading of European regulations in compared language versions, participation in audits with clients, drafting of DPIAs and risk assessments under supervision, building of documentary repositories, gradual exposure to in-house lawyers and external consultants to absorb vocabulary and legal practices by osmosis. It is a significant investment for a small software house, and it is exactly the kind of investment that produces a competitive asset hard to replicate.

Disclosure: a trajectory I inhabit

I have to be transparent, because on this topic I am describing a phenomenon I am part of, and the analysis would be dishonest if I did not declare it. The trajectory I am describing is the one I am living personally in my own company, and a non-secondary part of my work in the past two years has been building Oltrematica’s compliance engineer in-house, occupying that position directly while at the same time trying to formalise it for whoever will come after. I am not writing this piece as a neutral observer of someone else’s trend, I am writing it as someone who is inhabiting it from inside and who, after some years of practice, has the impression of having understood the shape the figure is taking and of having something to say about what works and what does not. I am not particularly happy or particularly proud of this trajectory. It is simply what the moment demands of those who want to keep making software for regulated clients without externalising their regulatory intelligence, and I have accepted it the way one accepts transitional duties, knowing that in ten years the figure will be obvious and that today it has to be built by groping.

Connection, and a forecast

There is a direct connection, and it is worth making explicit, between the figure I am describing and the two previous essays in this series. In the piece I called Cruft, Not Patina I argued that software does not know how to age, because the drift between code and the environment in which it runs erodes it faster than engineering culture can metabolise. In the piece that followed, The Specification Debt, I argued that the specification of software ages even worse than the code, because the continuous practice that would keep it alive is missing, and that the European regulatory framework is loading this ageing with legal consequences that did not exist before. The compliance engineer is the figure whose trade is precisely fighting specification debt day by day, keeping the specification aligned with the system as the system changes, and doing so with the bicameral competence that lets one fall neither into document formalism nor into code inertia. It is the person who, in an organisation that produces software, oversees the alignment between written promise and observed behaviour, knowing that under the new regime the coherence between the two planes is what the judge will assess if the day of assessment ever comes.

The piece closes with a forecast that is also a call to action for anyone reading from inside an organisation that makes software in Europe. In five years, around 2031, the compliance engineer will be obvious. There will be university degrees, there will be serious certifications, there will be professional bodies in some form, there will be regular columns in specialised media. What remains to understand is not whether it will happen, but only how fast. Organisations that are building it now, by hand and out of necessity, will have a structural advantage over those that wait for market maturity. The advantage plays out beyond the commercial plane — it is mostly cognitive, because whoever inhabits the role today is also defining the practices that will become standard, and whoever defines the practices defines them to suit their own way of working.

The compliance engineer figure is not a niche, it is the role redesigning how European software is produced under the new regulatory regime. It is happening slowly, in silence, in confused job postings looking for people who do not yet exist with titles that change month to month. When the postings find their stable name, and that will happen soon, the industry will split between those who invested in this figure in time and those who will have to import it at consolidated-market prices, three times as expensive. Anyone reading from inside a mid-size Italian software house probably has, in the company right now, the right person to train. It is a senior dev with their head sideways on regulations, or an architect who started reading the GDPR alone out of curiosity, or a sysadmin who took documentation to heart because no one else was looking after it, and in some cases a more hybrid figure arrived through mixed paths that fit none of the three classic trajectories. Recognising them and giving them an explicit mandate, investing time and structured training, is the managerial decision that will produce the most compounded value in the next five years. Not because the figure is fashionable. Because without it, in a few years, making software for regulated clients in Europe will become a craft that Italian software houses can no longer afford.

There are documents that get opened only at the wrong moments. The DPIA for the clinical-triage system was signed in April 2024 and filed in the compliance folder, from which it never came back out, the way no DPIA ever comes back out of the compliance folder. Eighteen months later, someone opens it. Not a lawyer — a consultant who has come in for a security audit, opening it for routine reasons, because he wants to verify that the declared measures match the implemented ones.

The document describes a system that uses a deterministic scoring model, trained on a closed dataset, with explicit rules for classifying the level of urgency. The processing purposes are four. The legal bases are mapped to the correct recital of the Regulation. Data subjects’ rights are listed one by one with the operational procedures to exercise them. Cross-border transfers do not exist, because everything stays in the vendor’s European data centre. The consultant reads, takes a few notes, then looks up and asks the CIO if he can see the system in operation.

The system in operation is a different one. Three months after the DPIA was signed, the vendor replaced the deterministic model with a neural classifier trained continuously on the last six months of clinical data. The dataset is no longer closed. The classification rules are no longer explicit. The official purposes are still four, but a fifth function has been added at the request of the emergency department, and it is a function the DPIA does not contemplate. Cross-border transfers continue not to exist until one day they do, because the vendor switched hyperscaler and now a portion of the traffic passes through an Irish data centre operated by a US-based subsidiary. None of this is documented elsewhere. The system works. Users are happy. Internal audits pass because they limit themselves to verifying that the system exists and produces coherent output.

The consultant turns to the CIO and asks who authorised the fifth function. The CIO replies that it was an urgent request from the emergency lead, handled within a week, with the vendor releasing to production the following Thursday after a staging test. There is a Jira ticket tracking the change, a pull request approved by two reviewers, an internal changelog. Everything in order on the operational plane. The consultant asks whether the DPIA was updated. The CIO looks at him with the expression of someone who never thought it was necessary, because the DPIA belongs to a different circuit, managed by a different person, in a different folder, on a timeline that has nothing to do with the release timeline. The consultant closes the DPIA and stops calling it a DPIA. He calls it a ghost specification, because it describes a system that exists only on signed paper.

An ordinary condition

The ghost specification, contrary to common belief, is an ordinary condition. Anyone who has worked in an organisation that builds software for a regulated client, or for itself under a regulated regime, knows that between the document describing the system and the system actually in operation, after a few months, a distance opens that grows every week and that nobody has been mandated to close. Not because anyone is lying. Because code has a metabolism the specification does not have, and because the lifecycle of the specification, in the software we actually make, is not managed by any tool comparable to those we have for code.

The objection one usually hears against this point is reasonable, and it should be addressed before going further. The objection says: code is the real specification. Documentation is a simplified projection of the system’s behaviour, and it is late by definition, so the only sensible strategy is to keep the code in good order and accept that the rest is literature. It is the code as documentation principle in slightly more sophisticated form, and it has governed software’s engineering culture for at least twenty years. It worked because it rested on an implicit assumption that no longer holds — namely, that software was judged on the basis of what it does when it runs.

The new evaluative status

Software, under the legal regime now consolidating in Europe between 2024 and 2027, is no longer judged only on what it does. It is judged on what it promised to do, and the promise lives in the written specification, not in the executed code. The revision of the Product Liability Directive, adopted at the end of 2024 with a transposition deadline of 9 December 2026, explicitly included software in the notion of product. Which means that the producer of software is liable for damages caused by defects in the product under a strict-liability regime. On this point I have already written an essay titled Mrs. Donoghue’s Last Bottle, returning to the founding case of producer liability in English law of 1932 and projecting it onto contemporary software. What I only sketched there, and want to bring into focus here, is the epistemological consequence of the new regime. The notion of defect, under strict liability, does not coincide with the bug. It coincides with the gap between what one could legitimately expect from the product and what the product actually did. Legitimate expectations, in the absence of other parameters, are reconstructed from the product’s technical documentation, from the producer’s declarations, from marketing materials, from compliance requirements mapped in risk assessments. They are reconstructed, in other words, from the specification.

The Cyber Resilience Act, fully applicable from 11 December 2027, makes the same move on the security side. Conformity is demonstrated through the technical documentation of the digital product, and that documentation includes the risk assessment, the implemented security measures, the up-to-date SBOM, the vulnerability-handling procedures, the support plan and the updates for the product’s lifecycle. The AI Act, for high-risk systems, requires even more extensive technical documentation, defined in Annex IV, including architectural description of the system, training datasets and data-governance procedures, performance and accuracy metrics, the risk-management system foreseen by Article 9, post-market monitoring procedures. They are distinct regulations, with different scopes, but with an identical epistemic structure. The software product has changed evaluative status. It is judged as the correspondence between a written promise and an observed behaviour, and when the two diverge, the judge or the supervisory authority looks at the written promise. Not because they believe the specification is the real system. Because the written specification is the only fixed point on which a judgement can be grounded.

A small framing clarification is needed here, to avoid an easy misunderstanding. I am not saying that the European regime turns the specification into a magic object that holds regardless of the system. The judge or the authority does not just read the document and declare conformity. They compare the document with the system, assess the coherence, accept technical expert opinions. What changes from the previous regime is that the document stops being an appendix to the product and becomes a constitutive part of the assessment, on the same plane as the system’s behaviour. When the two diverge, the document is no longer automatically dismissed as obsolete. The producer must explain why he released a system different from the one described, and that explanation, in litigation, is much more expensive than it is today.

Everything for the code, almost nothing for the spec

Against this shift, the industry has an arsenal of tools for managing the lifecycle of code and almost nothing for managing the lifecycle of the specification. Code has atomic versioning, and when a line changes there is a commit with author, date and message. It has blame, allowing you to trace back the origin of every decision visible in the source. It has tests, which fail automatically when behaviour deviates from a codified expectation. It has deprecation warnings, which signal a promise being withdrawn. It has safe refactor, supported by type systems and regression suites. It has code review, ritualised in pull requests that leave a trail. It has continuous integration, which prevents an incompatible change from entering the main branch unseen. It has branch protection rules, which physically prevent you from bypassing the process. It has rollback in one command, which reduces the cost of error. Each of these tools is the product of an engineering pressure accumulated over the last thirty years, and is now infrastructure of daily practice — so thoroughly metabolised that anyone entering the trade today takes it for granted and struggles to imagine a world without it.

The specification has its version, and that’s it. A DPIA gets signed, dated, archived in PDF, and the moment the system changes there is no automatic mechanism telling the signatory or the delegate that their signature now covers a different system. Architectural decisions recorded in ADRs accumulate in Confluence, in Notion, in SharePoint folders, and nobody re-reads them unless a specific audit demands it. Security requirements attached to contracts get signed, deposited in the CRM, and from that moment exist as back-office attachments until renewal. Risk assessments produced for AI Act compliance on high-risk systems will require periodic updates, but the mechanism linking the update to concrete system changes will be, in the vast majority of cases, a calendar or a contractual trigger, not a code event. The specification, unlike code, has no internal pressure to stay current. It survives in a slow-time zone where the signature counts more than freshness, and where ageing manifests not as functional degradation but as gradual drift away from the reality the document is supposed to describe.

The reasons for this asymmetry are cultural. Technically, tools to treat specifications with the same seriousness as code have existed for decades. Executable specifications in BDD style, test specifications written in Gherkin, formal contracts in languages like TLA+ or Alloy, interface specifications in OpenAPI or gRPC, proof assistants like Lean or Coq. Each of these systems assumes the specification is a first-class artefact, executable or verifiable, alive in the repository alongside the code. In industrial practice, none of this is the norm. The norm is that the specification lives in a Word document, gets reviewed by someone in legal or compliance, gets signed, gets filed, and from that point its fate is detached from the fate of the code.

The agile origin

The origin of this separation is historical and worth reconstructing in some detail. Software culture grew up in opposition to documentation culture, because documentation was perceived as an imposition by waterfall-style engineering management, and Agile won, among other reasons, because it promised to reduce the weight of the document in favour of working software. The Agile Manifesto, signed at Snowbird in February 2001, explicitly reads “working software over comprehensive documentation”. The wording was cautious, because at the bottom of the document the authors wrote “while there is value in the items on the right, we value the items on the left more”, so documentation was downsized, not abolished. But the industrial reading of the two following decades has been more drastic than the original wording. Comprehensive documentation became a synonym for superfluous documentation, and projects that dared produce more than a README, some comments and a handful of diagrams were suspected of residual waterfall practices. The promise made sense in its context, because the software being written in the early 2000s was judged on functional and commercial criteria, and the document was indeed a cost producing little informational value after the project’s first weeks of life. It was also a political cost, because it was often used to impose gate-keeping processes that slowed work without adding quality.

What has changed, and what engineering culture has not yet metabolised, is the evaluative context. The software we write today is sold in regulated markets, integrated into supply chains that treat it as a certified component, subject to compliance obligations that demand living documentation. The document has stopped being the internal tool of a bureaucracy that wants to control developers. It has become the tool through which the product presents itself to the regulator, to the regulated client, to the eventual judge. Engineering culture continues to treat the specification as a by-product of the process, while the regulatory framework is promoting it to primary artefact. The gap between these two perceptions is the ground in which specification debt grows undisturbed.

Spec-driven, BDD, and their limits

It would be dishonest to pretend there are no attempts to close this gap, and some of those attempts are serious. Spec-driven development in the form it has taken over the last two years, with tools like GitHub’s SpecKit and the practice of keeping a CLAUDE.md per project as context briefing for AI agents, tries to move the centre of gravity upstream of the code. The specification becomes the input for assisted generation by an agent that produces code, tests and accompanying documentation in a single coherent pass. The promise is that the specification is executable, in the sense that it produces a system, and is therefore maintained by the pressure to generate working code. It is an interesting direction, and on the projects where I have applied it, it has changed the economics of the work in non-trivial ways. The time I used to spend translating requirements into code has shrunk, but the time spent writing precise requirements has grown — and that is a favourable trade-off, because precision retains residual value even when the code is rewritten.

The limit I see, after some months of practice, is that spec-driven development solves synchronisation between specification and code at the moment of first generation, which is a real gain, but does not solve subsequent drift. Once the system enters production and changes in response to client requests, incidents, shifts in the operational environment, the formalised specification may or may not be updated, and practical incentives play against updating. Updating the specification costs time and rigour, and forces a negotiation between whoever wrote the change on the fly and whoever is custodian of the document. Under delivery pressure, the document loses. Code in production wins always, because it is what users use. The specification goes back to being a ghost, even when written in a formal language.

Executable specifications such as BDD have the same problem, in attenuated form. A Gherkin suite describing the system’s behaviour stays synchronised as long as someone fails it and realigns it, but when delivery pressure rises, scenarios get skipped, marked pending, deleted. I have seen suites of hundreds of scenarios shrink to a few dozen in a year and a half — not because the behaviours described had disappeared from the system, but because the suite had become friction the team no longer had time to manage. Executable specs remain more resistant than a DPIA, because they are code and therefore subject to the incentives of code, but they are not immune to drift. They are only slower to drift. And there is a second, subtler problem. Executable specifications cover functional behaviour well — the part of the system that can be verified automatically. They cover much less of the part that the new European compliance asks you to document — risk assessments, architectural choices, processing purposes, mitigation measures. That part eludes automation, because it is not behavioural, and it remains constitutive of the product as a legal object. No test framework will tell you whether it is still coherent with the system.

A subcategory, not a synonym

One could object, at this point, that specification debt is already included in the general concept of technical debt, and that talking about it separately is an elegant way to rediscover the moon. The objection is formally correct. The taxonomies of technical debt that developed in the two decades after Ward Cunningham’s original formulation, in particular Martin Fowler’s work and that of those who refined the cause quadrant, include outdated documentation as one form of debt. The distinction I propose is economic rather than conceptual. Classical technical debt has natural incentives toward repayment, because it slows you down, irritates you every day, costs you onboarding and development time. Specification debt has almost no incentives until a triggering event arrives, and the incentives it has are bureaucratic and calendar-driven, not operational. This difference justifies treating it as a subcategory with its own dynamics, especially now that the regulatory framework is loading it with value asymmetrically with respect to other forms of debt.

What I call specification debt is the invisible version of technical debt. Technical debt is the price you pay in the form of slower development, recurring bugs, harder onboarding. It is a price you pay continuously, in small instalments, that motivates you to invest in refactoring because you feel the pain. Specification debt you don’t feel. It doesn’t slow down development, because whoever develops doesn’t read the specification, and when they do read it they find it useful as a historical reference but not binding. It doesn’t generate bugs, because the code is already the real specification from the standpoint of execution. It doesn’t impede onboarding, because whoever joins the team learns from the code and from colleagues, not from archived documents. Specification debt produces only one kind of damage, and produces it when an event arrives that forces you to confront the specification as a binding object. A third-party audit. A security incident that becomes a court case. A data subject access request you cannot answer because the processing map was made for a different system. A complaint from a client who has read the contract and declares, with some reason, to have purchased something that was not delivered.

When that event arrives, specification debt becomes visible all at once, and the price is asymmetric with respect to technical debt. Technical debt you pay in instalments; specification debt you pay in a single lump sum, usually higher than the sum of the instalments you would have paid by managing it over time. There is also a difference in the nature of the cost. Technical debt you pay in development time, and that time is yours to control. Specification debt you pay in lawyer time, in external consultants, in extraordinary audits, in imposed remedies, and in reputation — which is the most expensive currency of all because it does not refinance. There is finally a temporal difference no one notices until it lands on them. Technical debt is paid gradually, while you work. Specification debt is paid suddenly, while you are doing something else, usually at a moment when you have no margin. The crises that reveal it always arrive at the worst possible moment, because they are the moment when someone else has decided to look at what you did not look at.

Archaeology and asset

In recent months I happened to work on a compliance assessment for a clinical-flow management system built for a large research hospital, and the client of the client — that is, the final clinical foundation — had requested a security appendix with ten control domains to map against GDPR Article 28 and a list of sector-specific requirements. The original specification of the system had been drafted three years earlier, when the system was a relatively simple data-collection platform. In the meantime the system had grown, had acquired processing modules, had been connected to third-party systems, had changed hosting provider. The distance between the starting document and the current system was enormous. The work I had to do for six weeks consisted essentially of rebuilding the specification from the system — that is, reverse-engineering behaviour to write a new document that would be coherent with reality.

The operational detail of this work is instructive, because it tells you what it actually means to manage specification debt when it is called in. I had to talk to six different people, each holder of an undocumented piece of knowledge. I had to read the code of three microservices that had been added after the DPIA was signed. I had to track down an external vendor to ask which anonymisation algorithm they applied to the data passed through them, because no one on the internal team knew with precision. I had to reconstruct the flow of personal data across five different systems by looking at network configurations and application logs, because the original diagram had become unusable. All this work was foreign to development. It was pure reconstruction of a documentary truth that should have been maintained over time and that instead had to be rewritten from scratch. It was exactly the operation the regulatory regime assumes is never necessary, because the specification should have been maintained along the way, and it was exactly the operation that is almost always necessary, because the way is never managed like that.

On another project, a legal-risk assessment platform for a specialised firm, we decided at some point to migrate the entire stack from Python to Laravel 12. The migration is in progress and we are around seventy-eight per cent done. What I have learned from this migration is that the real asset transferred was not the code, it was the functional specification. The Python code has been largely thrown away and rewritten, the data model has been redesigned, the framework choices have changed radically. What survived is the precise knowledge, formalised in product documentation and in client contracts, of what the system has to do, in what order, with what constraints, against what external interfaces. Without that specification, the migration would have been impossible. With that specification, and with a team that treated it as an active reference during the work, the migration has been hard but feasible.

The difference between this project and the clinical case told earlier is a difference of practice, not of the nature of the specification. In both cases there was a written specification. In the clinical case the specification had been signed and then abandoned. In the migration case the specification was read every two weeks in retrospective, contested when the team found inconsistencies, modified when a product choice changed, integrated when a function was added. It was a living object in the process, not a compliance heirloom. It is the same distinction that separates a flight manual the pilot reads before every take-off from the same manual archived in a library. The same text, two completely different functions, two operational values that cannot be compared. The specification as a transferable asset, and the specification as an asset that ages or does not age depending on how we treat it, are two faces of the same thing.

The tools we still don’t have

A reasonable hypothesis is that the next decade of software engineering will be defined by tools for the specification lifecycle analogous to those the past decade has defined for the code lifecycle. The first serious attempts are already visible. Traceability systems linking specification requirements to the tests that verify them, and the tests to the code changes that touch them, so that when a test changes the system knows which requirement has been impacted and asks for the document update. Drift-detection tools on architectures, comparing declared service topology with observed topology and flagging divergences. Versioning of DPIAs in git repositories with mandatory reviews on every structural change of the system. Product specifications living as versioned objects beside code, with CI failing when the gap between specification and implementation exceeds a threshold.

Let me try to imagine what daily practice might look like in five years, in a team that has metabolised this turn. The DPIA has changed form and lives as a YAML file in a protected repository, with version history, modification authors, an approval process via pull request. When a developer introduces a new processing of personal data, a static-analysis pipeline on the code detects the new flow and automatically marks the pull request as “DPIA-impacting”. The merge stays blocked until the data protection officer reviews and approves the corresponding change to the processing document. AI Act risk assessments follow an analogous mechanism, with drift detectors flagging when the model in production deviates from the metrics declared in the technical documentation. SBOMs update automatically on every build and produce readable diffs that enter product changelogs. None of this eliminates compliance work, but it transforms it from reconstructive archaeology — like the six weeks I spent on the clinical system — into continuous maintenance, integrated into the same rhythm as development. The cultural leap is to understand that documenting the system, under this new regime, is the construction of the legally relevant asset of the product, and not an administrative cost to minimise. Whoever does not do it now will do it in five years after losing a case, and at that point it will be more expensive.

Body and soul

A few months ago, on this blog, I wrote a piece titled Cruft, Not Patina, and the central argument was that software does not know how to age the way material objects do, because the drift between code and the environment in which it runs erodes it faster than engineering culture can metabolise. There was a passage about Unix as an exception, because in Unix the specification detached from the code and became culture, surviving across cycles of full rewriting of the body. That passage closed with a note of cautious optimism on the fact that the specification, when it detaches, is the stable plane that crosses change.

I need to qualify that note. The specification detaches from the code in two different ways, and the difference between the two decides everything. The first way is the Unix one, in which the specification becomes shared culture, described in canonical books, maintained by a community that knows how to apply it to new contexts, and therefore renews itself without losing identity. The second way is that of the archived DPIA, in which the specification becomes a signed document that no one reads anymore, and therefore stays identical to itself while the system becomes something else. In the first case the detachment produces continuity. In the second case the detachment produces a ghost specification. The difference between the two ways does not lie in the nature of the specification. It lies in the practices of those who use it. A specification that is read, contested, modified, re-discussed, applied to new cases, is a specification that lives. A specification that is written, signed, archived, and then ignored until the next audit, is a specification that dies slowly while no one is looking.

Putting the two essays together, the general argument I am trying to build is this. Software has a double problem with time. On the one hand, code does not know how to age, because its environment changes too fast and drift turns it into cruft rather than into patina. On the other hand, the specification, which could be the stable plane that crosses the rewriting of the code, manages to be that only when a constant practice keeps it alive — and in the vast majority of cases that practice is missing. The result is that software, under the legal regime now consolidating in Europe, is entering an era in which both the body and the soul of the product are fragile, and in which the only thing that can hold the two planes together is a discipline of documentary maintenance that engineering culture has yet to build. Software’s engineering culture has not yet drawn the distinction between the two with the clarity that is needed, because it has long treated the specification as a by-product. The regulatory framework now consolidating in Europe is forcing it to draw that distinction, and the price of the next few years will be paid by those who do not notice in time.

Specification debt is the technical debt you don’t see until someone gets hurt. We are accumulating it in silence, in SharePoint folders no one opens, in signed PDFs that are no longer a faithful representation of the systems they certify, in DPIAs filed on the compliance server like monuments. The first major European court case on software product liability under the new regime of the Product Liability Directive will be fought over the specification. When it arrives, and it will arrive soon, the industry will split between those who kept their specification alive and those who only kept on signing it.

It’s Wednesday afternoon. You’ve just finished, in twenty minutes, a task that six months ago would have taken you half a day. The screen is still. The afternoon opens out in front of you. By every external metric you ought to feel something close to triumph. Instead there’s a dull, unjustified tiredness you can’t quite trace. The hours saved haven’t been added to your life. They’ve only made the day strange.

The default explanation — that we’re tired because we’ve crammed more things into the same day — is wrong, or at least insufficient. Many of us are doing less, in clock-time terms, and feel more hollowed out. The fatigue isn’t quantitative, it’s a matter of texture. Something in the very way we inhabit the working day has shifted, and we don’t yet have the words for it.

Clock time, lived time, and a third thing

For more than a century, philosophy has distinguished two ways of inhabiting time. There’s mathematical time — the time of clocks and schedules, divisible and uniform. And there’s lived time, what Bergson called durée: the time of experience, in which ten minutes of waiting feel longer than an hour of immersion. The two were always in tension, but they ran roughly parallel. A working day had eight hours of clock time and a felt shape that more or less corresponded to it, with a heavy start and a close you could see coming. We knew where we were inside the day even without checking the time.

AI introduces a third thing that has never existed before. The clock keeps ticking uniformly. Lived experience still has its variations. But the cost surface of activities has become wildly irregular, and not in a way the body can predict. A task that consumed three hours yesterday takes twenty minutes today. Another task, similar on the surface, still takes three hours. There’s no rule. The asymmetry is local, and arrives without warning. You move from a regime in which work is hard to one in which it’s trivial, and back again, several times in the same afternoon, with no signals that allow you to adjust.

The body that no longer reads the map

The body had calibrated itself, over years, on a precise cadence. It knew how to distribute energy across a day, when to push and when to slow down. That calibration assumed a relatively stable map of activity costs: writing a report took hours, answering an email took minutes, and most intellectual work fell within that range. The map is no longer accurate. The body keeps making its calculations on costs that no longer hold, and there is a silent, persistent expenditure of energy in this constant recalibration that we don’t even manage to observe while it’s happening.

A tiredness without shape

It’s a tiredness different from the ones we knew. It isn’t the tiredness of effort. It’s the tiredness of time without shape, which is harder to name because we have so few examples of it in our history. Even the most severe constraints — prison, illness — tend to impose a rhythm of their own, and indeed people who come out of them often describe the absence of that rhythm as one of the most disorienting things about returning to free life. Even leisure has a rhythm: weekends against weekdays, meals, habits. What we’re inside now is something else: a working day whose shape changes while we’re working it, and that doesn’t settle into any pattern stable enough for us to lay ourselves down inside it.

It isn’t just transition

You could object that this is only transition. Give the system time. We’ll learn the new map and a new rhythm will emerge, as has always happened. Perhaps. But the analogy with previous technological transitions is misleading in a way worth naming. The factory imposed a brutal but legible cadence, and within a few decades the collective body of workers recalibrated around that new shape. The personal computer accelerated certain tasks but kept their inner phenomenology intact: writing was still writing, on a different surface.

What’s changing now is more fundamental. AI doesn’t accelerate the activity, it replaces it with a different one. The thirty minutes you used to spend formulating a paragraph aren’t compressed into three minutes of faster formulation. They’re replaced by ninety seconds in which you describe what you want and a few minutes in which you edit what comes back. These aren’t the same activity, faster. They’re different activities, with different costs and different felt shapes. The body has nothing to recalibrate against, because no new normality is forming long enough to be read.

The thoughts that aren’t reached

There’s also something we lose when the texture of the day flattens, and it’s worth looking in the face. The deep work tradition, even after being absorbed into a certain productivity rhetoric, was pointing at something real and subtle: certain kinds of thinking only happen in prolonged uniform stretches. The morning hours we used to protect for the difficult task weren’t simply higher-quality hours. They were hours that made the task itself possible. Some thoughts are only reached after forty minutes of sustained attention, and you can’t reach them in eight minutes of attention repeated four times.

When the texture of the day becomes fragmented and unpredictable, those thoughts simply aren’t reached. We don’t notice their absence directly, because what isn’t thought leaves no sensible trace. We notice it as a kind of cognitive thinning, a faster output that is somehow lighter, the strange sensation of producing a lot and thinking little without quite being able to say what the difference consists of.

Scaffolding against asymmetry

I don’t have a formula for what to do with all of this, and I distrust anyone who has one ready. The productivity genre answers — which mostly suggest imposing artificial structure on the new chaos through armoured calendars and morning rituals erected against the asymmetry — can help in individual cases. They don’t address the underlying phenomenon, which is that the natural shape of the day was a real thing, held up by the relative costs of activities, and those costs have changed structurally. Artificial structure is a scaffolding trying to hold up a building whose foundations have shifted. It can work for a while, and it wears down whoever maintains it.

What I notice in myself, and in colleagues who talk to me about it when there’s enough trust to step out of productivity rhetoric, is that the fatigue is sharpest on the days when we tried hardest to use the time we’d saved. The Wednesday afternoon when the task collapsed into twenty minutes and we filled the remaining hours with other tasks ends in a particular tiredness that doesn’t come from the work but from the inner violence of pretending that the time we lived was the time we measured. The Wednesday afternoon when the task collapsed into twenty minutes and we stopped — when we went out to walk, or stayed and looked at the strangeness of the afternoon without trying to renormalise it — ends differently. Not productively, in the old sense. But the body recognises that something has been honoured, and that cleaner tiredness is a different thing from the first.

A new respect for the absence of rhythm

Maybe what we need isn’t a new rhythm but a new respect for the absence of rhythm, at least while it lasts. The old day had a shape because work had a shape because costs had a shape. None of that is coming back in the form we knew it. Trying to rebuild it by force, through ever more elaborate scaffolding, will keep producing the diffuse tiredness all of us are carrying without naming. Letting the day be the strange thing it has become — now a sprint, now an empty stretch — might at least give us back the energy we’re spending on the useless project of pretending nothing has changed. It’s a partial surrender, sure. But some surrenders are the prelude to a way of being inside things that resistance would never have given us.

This isn’t optimism. The asymmetric day might be a worse day to live in than the structured one we had before, and I’m not sure how it ends. What I am sure of is that calling fatigue by its real name is the first thing we owe ourselves and our colleagues: we aren’t tired because we’ve done more — we’re tired because we’ve lived inside a time that had lost its shape, and we kept behaving as if the shape were still there.

“The more constraints one imposes on oneself, the more one frees oneself of the chains that shackle the spirit.” — Igor Stravinsky, Poetics of Music

The story we’ve been told

A story has settled, in recent years, at the centre of the European debate about technology. You all know it. In its compressed form it goes: “America innovates, China copies, Europe regulates.” It’s a quip you hear at conferences, read in newspapers, find in think-tank reports, and that found its formal consecration in the Draghi report on European competitiveness — an honest, dramatic document that named regulatory fragmentation as one of the causes of our structural lag.

There’s a kernel of truth in it. The European regulatory frame is dense. The piling up of requirements — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, GDPR, Data Act, DSA, DMA — does produce non-trivial cognitive load on whoever builds software. Many Italian SMEs are gasping for air, specialised consultancy is expensive, mature tooling is still missing.

But the story, as often happens, is more interesting than how it’s told to us. Because there is another way to read the same scenario, and that’s what I want to articulate in these pages. A reading that doesn’t deny the difficulties but rejects the apparently obvious conclusion: that regulation and innovation are opposed, and that being in Europe means losing simply by being there.

The thesis I’m defending is simple at its core, complex in its implications. Regulatory compliance, properly understood, is not a cost of the competition: it is one of its terrains. And the European framework, read as a coherent technical project, configures a competitive advantage that companies who understood it are already monetising — while those who keep treating it as a nuisance are progressively excluding themselves from the higher-value markets.

The category error

The first step in defusing the false dilemma “regulation versus innovation” is to recognise that the dilemma is, before being a debatable position, a category error.

When an architect designs a building, she works inside a tight web of constraints: laws of physics, seismic codes, urban planning rules, energy requirements, accessibility, fire safety, landscape protections. Nobody, looking at a well-designed building, says it would have been “more innovative without the laws of statics.” It would be absurd. Gravity isn’t a brake on architecture: it’s the condition that makes architecture possible as a discipline. It is what distinguishes building from piling up materials.

The same is true of software. The constants, standards, protocols, specifications — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — are constraints. Severe constraints. And yet no serious engineer treats them as obstacles to innovation. They are the opposite: the shared grammar that makes it possible to compose complex systems out of independent pieces. Without those constraints we wouldn’t have the Internet, we wouldn’t have databases, we wouldn’t have interoperability. We’d have an archipelago of incompatible proprietary solutions — exactly what European regulation, in its intent, is trying to prevent for the next layer of the technology stack: data, AI, security, accessibility.

Constraint, in other words, isn’t design’s enemy: it’s its shape. Schönberg knew it with the twelve-tone system, the Oulipo knew it with their literary algorithms, Calvino knew it when he praised exactness as a value of literature, every experienced developer knows it when she finally understands that static types don’t slow development down — they structure it. Absolute freedom in engineering is called chaos, and it produces fragile systems, incomparable, unmaintainable. Disciplined freedom produces architecture.

Treating compliance as the adversary of the technical project means you haven’t understood what the technical project is.

The European framework as a system, not a list

The second step is to read the European regulatory body the right way. Almost all the conventional critique — even the well-intentioned kind — makes the same mistake: it treats the regulations as a list. A list of disconnected obligations, each one adding friction, each one to be assessed individually on cost-benefit terms.

But that isn’t the shape the European framework has actually taken. If you look at the overall weave of the regulations of the past decade — from GDPR to the AI Act, through CRA, PLD, EAA, NIS2, Data Act, DSA, DMA — it isn’t a list, it’s a system. And like every designed system, it has its own architectural logic.

That logic can be summed up in one sentence: make accountable, by design, the technical systems that materially affect people’s rights and goods. Everything else is a domain-specific declension of that principle.

GDPR makes flows of personal data accountable. GDPR doesn’t tell you how to design the database: it tells you that you must be able to answer — always, for anyone who asks — who touches whose data, why, for how long, on what legal basis. The Cyber Resilience Act does the same thing for software product security: it doesn’t tell you which language to use, but it requires you to know and demonstrate what’s inside your product, to keep it secure over time, to manage vulnerabilities through traceable processes. The Product Liability Directive extends the producer’s liability to software itself, declaring explicitly that a bug can be a product defect. The European Accessibility Act extends accountability to inclusion: digital products above a certain market threshold must be usable by anyone. NIS2 does it for critical infrastructure. The AI Act does it for systems that meaningfully decide on, or influence, human choices.

Seen this way, European compliance isn’t a jungle of rules. It is one grammar applied to different domains: design things so you can answer for what you do, by design. Not as a fallback. Not as a coat of paint added later. As architecture.

And here is the often-missed point: once you have built an organisation that thinks in accountability terms — with SBOM, audit trails, threat modelling, privacy impact assessments, tested accessibility, formalised vulnerability management — the marginal cost of conforming to regulation N+1 drops sharply. The cost curve is the inverse of what naive critique imagines: high at the start, falling over time, while for whoever treats every regulation as a fresh emergency the curve starts low but diverges.

Organisations that understand this don’t “get compliant.” They are compliant, in the strong sense: they have a shape compatible with the framework. The others chase.

The Brussels Effect, ten years on

There is also a market dimension we tend to forget, and which on its own should dissuade anyone from dismissing European regulation as ballast.

Anu Bradford, a Columbia legal scholar, coined the term Brussels Effect to describe a well-documented empirical phenomenon: when the European Union regulates a market this size — second by nominal GDP, third on a purchasing-power basis, in any case one of the three biggest markets in the world — multinationals tend to adopt the European standard as their global standard, because maintaining two parallel regimes costs more than adopting the stricter one everywhere.

The paradigmatic case is the GDPR. Approved in 2016, applicable from 2018, it is today the de facto regulatory base orienting privacy policies at the largest tech companies in the world. You see it in cookie banners everywhere, in the privacy dashboards of the big tech platforms, in the California Consumer Privacy Act (which echoes its principles and structure with a lighter, opt-out-based architecture), in the Brazilian, South African, and Indian laws. Almost eight years after enforcement began, we can say with reasonable certainty: the grammar of global privacy speaks European.

The AI Act looks set on the same trajectory. Not because it’s perfect — it isn’t — but because it’s the first horizontal and organic regulatory framework in the world for AI systems. China got there first, in 2023, with binding rules on generative AI: but those are sectoral rules with a different emphasis — mandatory labelling, registration with the authority, user identity verification, content control — more oriented to informational stability than to fundamental-rights protection. The AI Act was the first attempt at a general, risk-tiered architecture, applicable to all AI systems across all sectors. The major AI companies are already structuring their internal processes against European requirements. In the United States, in a turn few would have predicted, state-level regulation is picking up — particularly in Colorado, with echoes in California and in some local New York legislation — the risk-categorisation logic, although the path has not been linear: the Colorado AI Act, originally in force from 2026, has been postponed and is being reworked as I write.

For a European company designing software, this means something very concrete: you are already working inside the standard that, statistically, will be the global standard within five years. Your American and Asian competitors will have to adapt to a frame you have already metabolised. This isn’t a detail: it is the operational definition of first-mover advantage.

The reply usually is: but if the Brussels Effect is so powerful, why are European companies struggling? The honest answer is that many European companies have not in fact metabolised the framework — they suffer it. They treat the GDPR as a nuisance to minimise, the AI Act as an unknown to defer, the EAA as something to do when the inspection comes. They pay twice that way: the cost of compliance (which, badly run, is high) and the missed opportunity of turning that compliance into positioning. Meanwhile non-European companies, forced to comply to access the market, do so structurally — and the competitive advantage that could have been ours becomes theirs.

The Brussels Effect is an arrow flying toward a target. We get to decide whether the target is us or them.

The asymmetry that decides

Now to the heart of the argument, the operational part. There’s a fundamental asymmetry between two kinds of company operating in the European market, and that asymmetry — silent, accumulating, today barely visible, tomorrow decisive — will determine who wins and who exits the higher-value segments.

The first kind treats compliance as paperwork. It’s the default position, and perfectly understandable: the regulation arrives, you appoint a person responsible, you fill in checklists, you produce documents, you update the privacy policy, you add the banners, you commission assessments when needed. Compliance is a cost to minimise, a defensive activity, something you do to avoid fines. It’s an activity outsourced as soon as possible: an on-demand consultant beats a structured internal process.

The second kind treats compliance as architecture. The difference is that regulatory requirements are not addressed at the moment of their applicability but taken as project constraints from the start. The SBOM isn’t a document produced after the fact: it’s an artefact generated by the CI/CD pipeline at every build. Privacy isn’t a checklist to fill in: it’s a dimension of the data model. Accessibility isn’t a final check: it’s a UI component set that guarantees it. Security isn’t an annual audit: it’s a threat model revisited at every meaningful architectural change. AI accountability isn’t a response to an inspection: it’s a battery of tests, training documentation, evaluation suites.

For the first two or three years, the difference between the two is hard to spot from the outside. The first company even looks more efficient: it ships the same products with less overhead. The second invests in things that can’t yet be seen: pipelines, frameworks, processes, training, structured documentation.

Then something changes. It changes when the relevant market becomes healthcare, public administration, finance, energy, critical infrastructure — the segments where the customers have their own regulatory exposure, and where their compliance depends on their suppliers’. At that point something happens that anyone who works in regulated B2B has already seen: the RFP arrives with a thirty-page technical annex, and the “paperwork” company discovers that many of the requirements are not incremental but structural. Full SBOM for every component. Vulnerability traceability with remediation SLAs. Documented and audited SDLC processes. Annual penetration tests with traceable remediation. Backup, disaster recovery, business continuity policies that have actually been tested. Demonstrable privacy by design for every flow. Verified accessibility. Auditability of any AI models in use.

The “paperwork” company has two options: either it transforms into an “architecture” company — investing suddenly, under pressure, in everything it never built — or it withdraws. Transforming under pressure is expensive, slow, and never clean: it produces approximate documentation, processes that survive at most until contract renewal, fragility that surfaces at the first serious audit. Withdrawing means stepping down a market tier.

The “architecture” company participates, wins, and — this is the point — wins at higher margins, because in those segments pricing rewards demonstrability, not just functionality.

I’m describing, as should be clear, something I live first-hand. Over the last three years I’ve watched healthcare projects where the discriminator was neither price nor feature parity but the ability to produce, on time, governance, security and accessibility documentation coherent with the customer’s requirements. I’ve seen public-administration tenders where ACN qualification was a gate, and where the absence of a qualified vendor translated into mechanical exclusion. I’ve seen negotiations where a security-focused technical annex redefined the entire axis of the conversation: no longer “what does your product do,” but “how do you demonstrate you can run it for years.”

In these contexts, compliance isn’t the final irritation of the negotiation. It is the terrain of the negotiation.

Trust as product

There’s a phrasing I find useful: in regulated B2B you don’t sell features, you sell documented trust.

Features matter, obviously. But features become commodity faster than people think. All CRMs look alike. All LMSs look alike. All telemetry platforms look alike. Differences are incremental, and after a certain level they stop being the buying discriminator. What becomes the discriminator is what isn’t a feature in the classical sense: the ability to sign a contract with precise liability clauses, to pass an audit, to guarantee operational continuity, to document your software supply chain, to respond within 24 hours to a data-subject request, to demonstrate the non-discriminatory behaviour of a decision system, to keep your products accessible for years.

None of these is a feature in the classical sense. They are demonstrable organisational capabilities. And they are exactly what the European regulatory framework forces you to build.

Here, in my view, lies the fundamental conceptual inversion. For a paperwork company, documentation is a by-product: the thing you produce so that inspectors are content. For an architecture company, documentation is the product — or rather, it is a constitutive part of the product, because what you sell isn’t the software but the organised capacity to run it over time, and that capacity is demonstrable only through documentation.

You see, from this angle, why the SBOM isn’t a paper exercise: it’s the manifest of your software supply chain, and it’s what lets the customer manage their own exposure. You see why the audit log isn’t a cost: it’s a reliability property the customer will buy anyway, and one that will be mandatory soon. You see why an EN 301 549-conforming accessibility report isn’t a formality: it’s what lets the public-sector customer win their own tender, and so it’s what makes you a preferred supplier.

When you sell trust, the documentation is the product, and compliance is the product’s instruction manual.

The honest objection

It would be dishonest to lay out this reading without acknowledging the serious objections. There are at least three, and they deserve to be taken seriously.

The first is disproportion. The regulatory load resting today on a ten-person software house is, structurally, very close to the load on a major corporation. Not in absolute terms — there are thresholds and exemptions — but structurally: the processes required to be genuinely compliant with the CRA, AI Act, GDPR are at points the same as a multinational’s, simply with fewer people running them. This disproportion is real, and it’s the main reason many European SMEs are struggling. It’s a serious problem, and it asks Brussels to do better on proportionality, on simplified regimes for SMEs, on the availability of accessible compliance tooling. It is not, however, an argument against compliance as such: it is an argument for implementing it better.

The second objection is implementation heterogeneity. The European regulation, once it lands in national legal systems, gets translated in ways that vary from country to country — competent authorities, certification schemes, supervisory tools, thresholds. That heterogeneity is genuinely a cost, especially for cross-border work. It is a specifically European weakness, tied to our institutional history, and it isn’t easily resolved. But — and this is the point — it isn’t a weakness of compliance: it is a weakness of single-market integration. Two different problems. Dismissing European regulation because it gets applied unevenly is a bit like dismissing the idea of a language because dialects exist.

The third objection is the most interesting, and deserves the most articulated answer. It is the time-to-market objection: if our American competitors don’t have to do AI Act compliance, and we do, they get to market first. This collides with the Brussels Effect but doesn’t entirely cancel it: there is a real window where asymmetry of constraint produces asymmetry of speed. The thing is, that window applies to a specific subset of products — the ones aimed at the consumer mass market, where time-to-market often beats robustness — and not to those aimed at regulated segments. For whoever sells to hospitals, banks, public administration, critical infrastructure, speed is rarely the discriminator: demonstrable robustness is. And there the European framework is an advantage, not a handicap. There are European companies winning in regulated B2B precisely because the American product arrives without the documentation, without the processes, without the culture — and has to be rebuilt under pressure to pass audits. Rebuilding under pressure is expensive: their margins drop, ours go up.

All three objections, in short, have a kernel of truth, but none of them justifies the catastrophist conclusion that often comes attached. The right answer is: implement compliance better, not refuse it.

What a compliant-by-design organisation does

So far, the conceptual level. I want to close with something more operational, because an essay on compliance that doesn’t go down to specifics risks being appreciated and then forgotten.

An organisation that has turned compliance into competitive advantage, in my experience, has these traits.

It has one accountability model spanning the software lifecycle. Not one model for security, one for privacy, one for accessibility, one for AI: a single model with domain-specific declensions, where all requirements converge on the same pipelines and the same documentation. The SBOM, the PIA, the threat model, the accessibility test record, the model card live in the same repository, are versioned, are updated at every release, are linkable from anywhere else in the organisation.

It has automation of the compliance artefact. Generation of SBOM, SPDX, license reports, vulnerability reports, accessibility scans, model evaluation reports is automatic. Not something someone produces by hand in anticipation of an audit: something the pipeline produces at every build, with timestamp and reference commit. The result is that, when a customer request lands, the answer is available in minutes, not weeks.

It has contracts as specifications. Customer contracts — especially in healthcare and public administration — are not legal texts disjoint from technical work, but technical specifications living inside the backlog. Security clauses are mapped onto requirements, requirements onto tests, tests onto pipelines. When a customer asks you to certify conformity to a clause, the answer isn’t “let’s ask the consultant”: it’s a query against your own system.

It has internalised legal competence. That doesn’t mean having a lawyer on the org chart. It means tech leads know the regulations applying to their domain, understand their logic, know how to translate their requirements into architectural choices. The external consultant is a resource for specialised cases, not the owner of compliance.

It has a culture of explicit trade-offs. It knows when a compliance requirement imposes a cost, declares it, debates it, makes a motivated decision. It doesn’t pretend compliance is free. It doesn’t pretend it’s impossible. It treats compliance as one of the project’s constraints, to be balanced against the others.

And, above all, it has a commercial narrative grounded in compliance. It can tell customers why its product is better, and that “why” includes — alongside the features — the documented reliability structure. It knows that the healthcare customer, the public-sector customer, the banking customer is buying exactly that: the guarantee that, three years out, five years out, in front of an inspection, in front of an incident, in front of a regulatory shift, you will still be a solid supplier. That isn’t a concession to marketing: it is the product.

Europe’s civic signature

I want to close by stepping out of the operational terrain and returning to the conceptual one, because there is a further dimension — civic, almost political — that is worth naming.

Europe, as a project, is a singular historical experiment: a union of states that decided, after the catastrophes of the twentieth century, to pool sovereignty in exchange for rules. It isn’t a union of force: it’s a union of norms. Our symbolic wealth, our capacity to project values, our international credibility, depend in large measure on the idea that we make rules, abide by them, and apply them to ourselves. When we export them, we don’t do it through force, we do it through the market.

What we are doing in the digital domain is precisely this: transposing our civic signature into cyberspace. The idea, scandalous to part of the world, that technology should answer to those who suffer it, not only to those who produce it. That the effects of technical systems on individuals are not an externality but a legitimate object of regulation. That innovation producing unrepaired harms, unremedied exclusions, unexplainable opacities is not innovation: it’s a transfer of costs from producer to citizen, dressed up as progress.

You don’t have to share this view. There are legal systems that have made other choices, and we respect them. But arguing — as some of us still do — that our view is a brake, and that real progress is somewhere else, means not having understood the game we’re playing. The game isn’t who reaches the consumer market first with a new gadget. The game is who defines the grammar inside which technical systems will operate for the next fifty years. The GDPR is already the grammar of global privacy. The AI Act is becoming the grammar of global algorithmic accountability. The CRA is becoming the grammar of global software product security.

For whoever designs software in Europe, taking part in this game is a privilege we pay for with a specific cost — the cost of building first — but it is also, precisely for that reason, our principal structural competitive advantage. Whoever stays out, inside Europe itself, because the framework is a nuisance, is making a short-sighted bet: removing themselves from the only advantage we have, in pursuit of a competitive model — pure time-to-market — in which we cannot win anyway, because we don’t have the capital mass of those who define it.

Compliance, properly understood, is not our burden. It is our shape. Our shape of building, our shape of doing business, our shape of projecting values. Treating it as ballast is, for a musician, like treating the key signature as a bother. You can do that, sure. But you’ll be playing something else, and you’ll be playing it worse.

Constraint, once again, is shape. And shape, for those who learn to inhabit it, is an advantage.

It was only a few days later, reading it calmly at my desk, that I understood what had been bothering me. The template wasn’t a more detailed version of the previous one. It was something else. Not an improved form, not a finer grid: the document in my hands demanded something different from whoever filled it in and, more subtly, demanded something different from whoever read it. The DPIA was ceasing to be a form and turning into — to borrow a term I spent my university years chewing over — a genre.

What has arrived, and what hasn’t

It’s worth stating straight away what has and hasn’t arrived, because the nuance matters for the rest of the argument. The EDPB adopted the template in version 1.0 by written procedure on 10 March, released it publicly in April alongside an explainer document accompanying each section, and opened it to public consultation until 9 June. The template’s use is not mandatory: controllers may continue to use whatever DPIA methodologies they prefer. After the consultation, and with whatever revisions are made, every national data protection authority will take steps to adopt it either as its own standard or as a meta-template with which national models will have to align. Nothing is yet closed, in short, but everything is taking shape — and the shape it’s taking is precisely what I want to discuss here.

I’m aware I have to argue against the common intuition. Most people working with DPIAs treat them as bureaucratic bother, a burden to dispatch, a piece of paper the legal consultant fills in and the client archives. In Italy, where compliance has long kept a defensive profile, DPIAs have often been written not to be read, and read not to be discussed. The question «what do you actually need from a well-done DPIA?» tends to yield practical answers: that it be complete, cover the use cases, not contradict other documentation, survive an authority’s inspection. These are honest answers. They are also, I’d argue, the wrong ones — or rather, they are the answers one gives if the DPIA really were a form. And that is precisely what, until a few weeks ago, the DPIA still was across much of Italian practice. An author-less document in the weakest sense: someone signed it, yes, but no one took responsibility for it in an editorial sense.

A template is not a form

But here we reach the point. A template is not a form. A template, the moment it is proposed by an authority like the EDPB with the explicit ambition of becoming the common European standard, ceases to be a filling-in instrument and becomes something stranger and more powerful: the codification of a form. And a form is not filled in. A form is written, and it’s written with full awareness of being read within specific expectations, with a lexicon, a narrative structure, a rhetorical rhythm that are not interchangeable with others. That, in short, is a genre.

To see why the shift matters, it helps to step back and look at how the DPIA got here. It has existed formally since 2018, mandated by Article 35 GDPR as a required assessment for high-risk processing. In the early years it was handled as it could be handled: each organisation, each law firm, each DPO produced its own version, with a variability anyone who’s worked cross-sector knows well. Some DPIAs were five-page documents that read like meeting minutes; others were hundred-page tomes that read like doctoral theses. Some were compiled with numerical risk matrices inherited from security frameworks, others in dense legal prose laden with normative references, still others with hybrid approaches that mixed the two cultures without quite making them cohabit. The Commission had suggested certain outlines, first Working Party 29 and then the EDPB had published guidelines, some national authorities had made more structured models available, but the landscape remained fragmented. The DPIA sat in that state of a young thing whose forms haven’t yet settled, where everyone tries their own path and few of those paths meet. European supervisory authorities had complained repeatedly about this heterogeneity, which made it hard to build the kind of implicit, shared jurisprudence every mature field builds by reading hundreds of documents produced according to a recognisable form.

When a form takes shape

The EDPB template opens the closure of this phase. Not with the formal authority of a binding regulation, which it is not, but with something like the authority a normative grammar exerts over a living language: it indicates, orients, creates a centre of gravity. From now on, anyone writing a DPIA in Europe knows there is a form proposed at the supranational level, and knows that when the consultation closes and national authorities have taken their adoption steps, every deviation from that form will require justification. This is exactly, in the history of languages and literary genres, the movement by which a form takes shape. Before Dante, Florentine vernacular was one of many Italian vernaculars; after Dante, every use of Florentine vernacular measured itself against him, even when it wanted to move away. Comparing Dante to a bureaucratic template is disproportionate, I know. I leave it anyway because the mechanics are the same, even if the altitudes are obviously incomparable. When an authority proposes a form and all the authorities beneath it announce they will adopt it, that form ceases to be one possibility among many and becomes the background against which all the others stand out.

Architext and self-inquisition

Literary scholars call this phenomenon the stabilisation of an architext, a term I owe to Genette but which was already circulating in Bakhtin under the name secondary speech genres. The architext is not a single work: it is the set of formal expectations a reader brings to a certain type of document. When I open a detective novel I know there will be a crime to solve; when I open a scientific article I know there will be a methods section; when I open a sonnet I count the lines before reading them. A stabilised architext produces stabilised expectations. And it produces, inevitably, a form of writing that knows it is being read within those expectations. Hans Robert Jauss, from 1970 onwards, called this reader’s stance — encountering a text within an already known genre frame — horizon of expectations. For Jauss, every text is read twice: once against the frame the reader brings, once reshaping that frame according to what the text actually says. A DPIA written inside the EDPB template, once that template has become the reference standard, will be read this way: the auditor or inspector will already know what to look for, in what section to expect what, will recognise immediately when the text departs from the expected form, and will construct a judgement from that deviation.

There is a second theoretical thread I want to invoke, because it illuminates the point in a different direction. Carlo Ginzburg, in his work on the sixteenth- and seventeenth-century inquisitorial trials of Friuli, showed how the transcripts of those trials were a genuine documentary genre, with precise rhetorical conventions, a coded relation between interrogator and interrogated, a particular handling of voice between direct and indirect discourse, a narrative structure that translated the defendant’s voice into the inquisitor’s procedural frame. Ginzburg read those transcripts as texts, not as pure transcriptions, and in that reading found traces of a popular subjectivity otherwise invisible. Beyond the historical comparison, there is a structural analogy that has struck me since I started thinking about the DPIA. A DPIA is, in its deep architecture, a self-inquisitorial document: the controller interrogates itself about its own conduct, reconstructs the reasons for its choices, argues before an absent but threatening reader (the authority) why those choices are adequate. It is a form of discourse that exposes its own rationality in order to be judged on it. The fact that it now has a template destined to become a codified genre means, among other things, that this self-inquisition is about to have a grammar. And grammars, as anyone who has studied them seriously knows, are not neutral instruments: they model what can be said, and indirectly what can be thought.

The window of canon formation

Anyone writing a DPIA in the coming months finds themselves in a particular position, different from both the pioneer’s and the practitioner-inside-a-mature-genre’s. The template is on the table but isn’t yet a standard, the consultation is open, national authorities are preparing their transposition steps. Writing a DPIA in this window means writing inside a form that is still stabilising, which means two things. First, one can no longer behave as a pioneer: the template is available, its sections are clear, its method is public, ignoring it would be a deliberate gesture that needs motivation. Second, less obviously, there is an opportunity that writers two years from now won’t have: the chance to contribute, through one’s practice, to defining what «writing well» will mean inside this genre. Every DPIA produced now that engages seriously with the template, that uses it as structure, that flags its limits, contributes to forming the canon. In stabilised genres the canon already exists; in forming genres the canon is made by writing it. For those of us who do this work, it’s worth being present precisely in this window.

From form to prose

It could be objected that I’m romanticising what is merely a longer form. The objection is serious and deserves to be taken seriously. If the DPIA were only a longer form, its evolution would be irrelevant outside the narrow perimeter of compliance: another grid to fill, another kind of PDF to archive, another marginal cost for those processing data. But there’s a detail in the new template that, once noticed, dismantles this reading. The template no longer asks merely to list. It asks to argue. It asks, in particular, to justify the proportionality of choices, to reconstruct the reasoning that leads from a risk assessment to a mitigation measure, to show why a given balance between utility and residual risk is acceptable. It asks, in short, something a form cannot ask: it asks for prose.

The appearance of prose in a compliance document is the clearest symptom of the shift to genre. A form doesn’t need prose, because its informational value is entirely contained in the grid. A genre, by contrast, lives in prose, because it is in prose that connections between facts, hierarchies of importance, justifications, and nuances are expressed. When the EDPB template asks you to write why the chosen legal basis is adequate to the context of the processing, it is asking for a small essay. The content of that essay will have formal constraints, but it remains an essay. And whoever writes an essay — even a three-hundred-word essay in a PDF box — writes differently from whoever fills a cell in a spreadsheet. Prose forces a point of view, forces decisions about what comes first and what comes later, forces showing which information is accessory and which is central. The grid, by its nature, flattens these hierarchies. The shift from grid to prose is not a shift of pure form; it is a shift of local epistemology, of what a given text can tell and what it cannot.

The many readers of a DPIA

An underrated aspect, and one I want to bring to light, concerns who actually reads a DPIA. Current practice almost always imagines a single reader, or rather a hypothetical, under-characterised one: the inspector from a supervisory authority — a somewhat abstract figure most DPIAs will in fact never meet. But a document of genre always has more real readers than it declares, and the DPIA is no exception. The public buyer assessing a vendor reads it. The compliance officer doing due diligence on an acquisition reads it. The lawyer preparing a defence in litigation reads it. The data subject who wants to understand how their data is processed reads it — if it is well written and made accessible. Increasingly, the upstream technology vendor who needs to verify whether its processor role has been correctly scoped reads it. Each of these readers brings a different horizon of expectations, and the fact that the EDPB template is stabilising the form helps all of them at once: a disciplined reader knows where to look, knows how to recognise what they’re looking for, can distinguish a well-made text from a botched one. A form is ultimately opaque to any reader external to its filler. A genre, by contrast, has the democratising virtue of being legible to anyone who knows its conventions.

DPIA-as-code

Let me return for a moment to Oltrematica’s experience in recent months, because it was exactly the day-to-day of certain projects that made me understand what was changing. We have ongoing work on healthcare platforms for the Abruzzo region, on people analytics systems in hospital settings, on applications for local public administration, on online training platforms with ECM certifications, on parking management systems for municipal utilities. In every one of these cases we have, or will have, a DPIA. Until a year ago the typical approach was: set up a call with the client’s DPO, gather information, produce a draft, review it together, put it in the repository. The document was essentially closed at the end of the process. It was updated when processing changed, on an annual or biennial review cycle. It was, clearly, a form. What’s interesting is that internally within the tech team we also treated the DPIA as a form: we considered it something the DPO produced for us, not with us, and that concerned us only if an auditor asked us to confirm some of its contents.

When I read the new template, the first thing I did was write an internal memo about what would change operationally. The second, less immediate, was to draft a proposal I briefly called DPIA-as-code: bringing the DPIA inside the project’s versioning flow, integrating it with Jira and Confluence, making it an artefact that lives in the same ecosystem as the code. It isn’t a revolutionary idea. Others were already thinking along these lines, particularly in environments where compliance has historically been entangled with software engineering — I’m thinking of certain security teams in the US cloud-native world. But the reason the proposal makes sense precisely now, and not two years ago, is exactly what I’m writing about: only when a document is becoming a genre, and no longer a form, does it make sense to version it the way you’d version a chapter of a book. A form is updated with a new form; a chapter is revised with genetic traceability, attention to variants, an archive of decisions that lets you retrace your steps and understand why, a year ago, you chose a certain phrasing over another.

The projects where this transformation is proving most interesting are the ones whose risk profile evolves with the product. A people analytics platform like the one we’re building in partnership with Umana Analytics has a cycle in which every new feature potentially touches sensitive data, and every change to the predictive models redefines the contours of the processing. A DPIA-as-form ages fast here: you write it, archive it, reread it a year later and discover its central paragraph no longer faithfully describes what the product is doing. A versioned DPIA-as-genre, by contrast, follows the product. Every pull request touching the processing perimeter opens a corresponding discussion on the relevant paragraph, which may stay unchanged or be updated with a diff that explains what changed and why. The healthcare platform for the Abruzzo region we’ve worked on for years, with its data flow towards a regional registry and national reporting systems, is an even clearer case, because every upstream regulatory change forces a re-reading of the processing — and without a versioned DPIA that re-reading risks losing the thread of the original motivations. With a versioned DPIA, you can start from the present and work backwards, decision by decision, to the point at which the processing was defined, reading the text alongside the discussions that accompanied it. A different case again is the online training platform we run for ECM-delivering bodies, where the DPIA must account for a relatively stable processing but a very large user base and an articulated chain of sub-processors. Here the value of a versioned DPIA lies mostly in keeping the accountability chain aligned as providers change, with every provider update becoming a commit on the relevant section — a coherence a form archived once a year cannot achieve.

Authorial philology and the git log

It becomes important to ask what it really means to version a genre. Literary criticism has a consolidated tradition here: what in Italy we call filologia d’autore, or critica delle varianti — authorial philology, the critique of variants — associated in the twentieth century with the names of Contini and Isella, and which in France took the name critique génétique, with figures like Bellemin-Noël and Pierre-Marc de Biasi. It studies how a text has grown over time, which variants were adopted and discarded, what external pressures modified the form, what rewrites were induced by revisers, commissioners, self-censorship. The git log of a versioned DPIA is, plainly, an avant-texte in real time. It shows when a mitigation measure was strengthened, who proposed it, in response to what report, with what alternatives considered and discarded. It produces, as a side effect, a level of traceability no form-DPIA ever had — because the form hides its history in its final version, whereas the genre puts it on display. And it displays it not out of archival narcissism, but because in a mature genre the history of choices is part of the current argument. An auditor who can read a git log can tell, without asking anyone, whether a given measure was implemented in response to real risk analysis or retrofitted to justify a choice already made. The genealogy of a text is a far more effective quality check than any signature at the bottom.

Working inside this framework changes, in ways my experience shows to be progressive, certain operational dimensions. The first concerns the separation between source and rendering. A form-DPIA lives in its final PDF, with all the misalignment problems that brings: you modify the DPIA and then discover the processing record in another document says something different, or that the executive abstract is still at the version of six months ago. A genre-DPIA lives in a structured source — in our case Confluence, with certain key pages marked for the export pipeline — from which renderings for different readers are generated. The same source produces the complete DPIA for the DPO, an executive abstract for the board, a technical sheet of mitigations for the development team, and optionally a synthetic version for data subjects if the controller chooses to publish it. The content is the same; the form adapts. This demands, at the source, a more rigorous writing discipline than the form-DPIA ever required, because every paragraph must be built to survive multiple uses. In return, it drastically reduces what does most damage in compliance: the proliferation of misaligned versions of the same processing across different documents.

The second dimension concerns the link with project ticketing. In every engagement of ours, a Jira epic or story that touches new processing of personal data, or modifies existing processing, opens a formal request to update the corresponding DPIA. Not necessarily a full update; even a no-impact check is enough, provided it’s recorded. The link makes explicit what in the form-DPIA world was implicit, and therefore forgotten: every product choice is a compliance choice, every feature that touches data is a potential change to the documented processing. Linking the ticket to the DPIA paragraph is, in practice, enforcing that product and its act of writing proceed in lock-step. The git log becomes a genetic history of the processing; the Jira timeline becomes the history of its motivations. For a team used to treating compliance as a satellite activity to development, it’s a non-trivial posture change, and it has to be supported. In the early months we had resistance from developers who saw the Jira–Confluence link as additional bureaucracy; six months in, most of them now consider it a help, because it reduces alignment meetings and makes the technical contribution to compliance visible.

The DPO as editor

The most delicate dimension concerns roles. In a form-DPIA model, the DPO is typically the main author or the final reviewer, and the technical team is an information supplier. In a genre-DPIA model this geometry partially inverts. The DPO remains responsible for compliance, but becomes more properly an editor: sets standards, reviews contributions, ensures consistency across sections, demands rewrites. Whoever writes the first draft of many sections is whoever knows the matter — the product owner, the architect, the developer who designed the data model, the DBA who set the retention policy. The final document is still signed by the DPO and the controller, but the weave of the text is woven by many hands. It’s a thing anyone who has worked in editorial recognises immediately, and that anyone who has only worked in compliance finds disorienting. And yet, after six months of experimenting, it seems to me the healthiest configuration.

I know I’m introducing a tension. A DPO who becomes an editor risks losing in formal authority what they gain in product quality. In the Italian tradition, where the DPO role is often legal and often external to the organisation, proposing a DPO-as-editor can sound like a weakening. I think, instead, it’s a strengthening — for a subtle but important reason. The authority of an editor is not the authority of someone who produces the text alone; it’s the authority of someone who decides what passes and what doesn’t. A DPO who writes everything alone can produce a formally unassailable DPIA that is distant from the operational reality of the processing. A DPO who edits what the team writes remains in the final position of saying no, but does so on material that has a grip on the facts. The result, in my experience, is harder to attack and easier to defend in an inspection.

Legibility is not simplicity

Here we come to the second serious objection I want to address, raised in several internal discussions in recent months. One could say: this recognition of the DPIA as a genre isn’t progress, it’s needless sophistication, a baroquefication of compliance that adds burden without adding value. Europe, goes the argument, already suffers from regulatory inflation; turning the DPIA into a literary product — however technical-literary — means worsening a problem without solving it. I understand the objection, but I think it’s wrong for a specific reason. Genres don’t complicate texts; they make them legible. The alternative to a stabilised genre is not a simpler text, it’s a text that’s harder to read, because the grid letting the reader orient themselves is missing. When the same document reaches a supervisory authority’s desk in ten different forms, written by ten authors each having decided their own structure, reading becomes extremely slow and carries a high margin of error. When the genre is stabilised, the authority can read a hundred DPIAs with the effort an experienced critic reads a hundred novels — by rapidly recognising where to look for what, and noticing just as rapidly the significant deviations.

Legibility, in this sense, is not synonymous with simplicity. A sonnet is harder than a social-media post, but it’s immensely more legible to anyone who knows the genre, because they know where to look for the argumentative turn, the central concept, the closing. In the same way, a well-written DPIA in the new format will be more demanding in detail but faster to read for an auditor who knows the template. And above all, it will be comparable with other DPIAs written in the same form. Comparability is the invisible benefit of stabilised genres, and it will be — I believe — the most important gain in the years ahead for data protection authorities. Until now, every inspection started from reading a document as if it were the first of its kind, reconstructing its form along with its contents. Once the new template is the standard, comparison across a hundred DPIAs from a hundred different controllers will become a feasible operation, because the form will be shared and the differences will be informative.

There is a corollary of this comparability specific to those working with public-sector clients, and I want to develop it because it’s the part of our portfolio changing fastest. In procurement procedures and technical specifications, the DPIA (or equivalent impact documentation) has often been requested as a generic attachment, with little specification on the «how». The administration verified the document existed, leaving substantive review to an often belated stage during contract execution. With a stabilised genre, contracting authorities will be able to do something different — and, from the competitor’s point of view, far more demanding: to assess the document’s quality as a selection criterion. A DPIA written inside the EDPB template can be scored consistently, compared to competitors’, used as an indicator of the bidder’s compliance maturity. For a supplier that has invested in writing as a practice, this will be a clear advantage, because it turns a ritual attachment into a differentiation tool. For a supplier that has always treated the DPIA as an administrative burden delegated at the last minute, it will be a growing risk, because the distance between a well-written document and a botched one will become obvious to anyone reading the template. In our specific sectors — regional healthcare, chambers of commerce, municipalities — I believe we’ll see precisely this kind of selection appearing in award criteria over the next two years: a signal that the genre has entered public-sector contracting no longer as a box to tick but as an object of genuine reading.

The LLM suspicion

There is a third objection that must be faced, even if it requires a digression, and which has been put to me by people very close to our technical practice. If the DPIA is becoming a document of argued prose, the argument goes, then it’s exactly the kind of text a large language model can produce well in minutes. Why worry about all this talk of writing, of authorial philology, of editorial roles, when a good prompt and a couple of iterations will give you a formally impeccable DPIA? The question is legitimate, and I’ve asked it of myself, having worked intensively in recent months with AI-native development tools. The short answer is that the objection conflates two different things, and the conflation is dangerous. An LLM can indeed produce text that looks like a DPIA and will, in most cases, pass a superficial formal check. But a DPIA is not just its final text; it is the documentary trace of a decision process. Its sections are not an autonomous rhetorical display; they are the return of real conversations that took place between real people about real processing activities. An LLM can help me render those returns better, give the text rhythm, suggest more effective phrasings — and it does. It cannot substitute for the conversations upstream of the text, because those conversations are exactly what the DPIA has to account for. A DPIA produced by an LLM without those upstream conversations is a simulacrum, and the difference from the genuine becomes visible soon — particularly when the moment comes to defend it before someone asking precise questions. The genre, here, protects those who practise it honestly and exposes those who fake it, because the depth of a well-written DPIA is inseparable from the depth of the reflection that produced it. This, parenthetically, is a point the culture of AI-native development is learning in every domain it reaches: automatic tools are excellent amplifiers of thought, but not substitutes for thought. And it is precisely in mature genres that the difference between the two becomes clearest.

An ecosystem of techno-normative genres

There’s a related point worth flagging, though it deserves an essay of its own. The genre-DPIA, precisely because it lives in the same ecosystem as the product, lends itself to integrations the form-DPIA could not have. I’m thinking in particular of the link with the SBOM, the software bill of materials, which is becoming an increasingly formalised requirement under the Cyber Resilience Act. The two documentations, SBOM and DPIA, have separate histories and different logics, but they speak about the same platform. When both live versioned and queryable, things become possible like: identifying which software components are involved in the sensitive-data processing described in Section X of the DPIA, or flagging when a dependency upgrade introduces a component that changes the documented risk profile. A developer updating a logging library, say, can automatically receive an alert: «this library is referenced in the DPIA for project Y, paragraph 4.2, check whether the new version changes the described behaviour». These are scenarios that, under an integrated product perspective, remain science-fictional; under an integrated compliance perspective they become — if not easy — at least thinkable. And the reason they become thinkable is, once again, that the DPIA is turning into a text governed by known conventions, navigable as a text is navigable, and no longer a grid opaque to the outside world.

The SBOM–DPIA link, incidentally, is the point at which I realise the argument I’m making has implications wider than the DPIA itself. If the DPIA is turning into a genre, it’s reasonable to ask whether other artefacts of European compliance are undergoing the same transformation, and in what direction. It seems to me evident, for example, that the AI Act technical file is also on trajectory towards a genre identity, with its canonical sections, its argumentative rhythm, its claim to legibility by a market surveillance authority. The same holds, at a different level, for vulnerability documentation and disclosure policies the Cyber Resilience Act is stabilising over the course of this year, with reporting obligations kicking in in September 2026 and full substantive obligations from December 2027. We are witnessing, in Europe, a decade-long operation of techno-normative genre generation, whose consequences for software work remain largely unexplored. Ten years ago, software compliance was a constellation of forms. Ten years from now, in all likelihood, it will be a library of genres, each with its own canons, its reference specimens, its consolidated criticism, its school of authors.

This perspective, abstract as it may sound, has a concrete commercial implication that I think is still discussed too little. A firm that has learned to write inside mature normative genres has a substantial competitive advantage over one that has to learn from scratch every time. And learning to write inside a genre isn’t something done in a one-week course: it requires practice, correction, exposure to good and bad specimens, peer critique, progressive experience of which phrasing holds and which doesn’t. Europe is building, with uneven timing and coordination, an ecosystem of techno-normative genres that will reward organisations capable of making this writing a stable competence. For those of us who do this work — software for public administration and healthcare — it means the next five years will not be won by those who write more elegant code, but by those who write better compliance documents. By «better» I mean not more detailed but more legible, more argued, more capable of sustaining scrutiny from competent readers. It’s a paradigm shift that cuts across our organisations and redefines which competences are scarce and which are not.

I return, then, to the DPIA, with an observation I hope doesn’t sound too abstract. The fact that a form is turning into a genre is one of those things that, once it has happened, retroactively changes how we read the preceding history. DPIAs written between 2018 and 2025 were already, to some extent, genre — because reading expectations existed, because specimens considered good or bad circulated, because authorities were starting to build an implicit jurisprudence of what a well-done DPIA meant. It was a genre in formation, fluid, with uncertain boundaries. The EDPB template, once the consultation closes and national adoption steps are under way, will fix those boundaries, crystallise the genre, and in doing so make retroactively visible a trajectory that was previously ambiguous. From that moment on, the DPIA will have a before and an after, and the difference between them will not be a matter of detail but of nature. The window in which we’re writing now is exactly the moment this transition is completing: no longer before, not entirely after — it is the threshold.

What to do tomorrow morning

I realise all of this may sound, to a pragmatic engineer, like useless philosophical abstraction. What does it help me tomorrow, in concrete work, to know the DPIA is becoming a genre? I’ve already scattered the practical answer through the preceding paragraphs, but it’s worth recomposing it into a form closer to what a team needs to do when opening the next project. Stop treating the DPIA as a closing document produced downstream of design, and start treating it as an accompanying document born with the project and growing with it. Accept that the people who contribute to the DPIA are no longer only legal and the DPO, but also whoever builds the product — and this requires a small but continuous investment in their ability to write argued text. Introduce, in development processes, the technical and organisational links between project tickets and DPIA paragraphs, so writing stops being a parallel activity and becomes part of current work. Rethink the DPO’s role as editor rather than sole author, with everything that implies for relations with the rest of the team. None of these changes is dramatic on its own. Together they redesign how data compliance is practised, and surface the difference between organisations that have understood the shift and those that will keep producing forms in a world that reads genres.

There is, then, something I want to flag to anyone, like us, operating precisely in this window of genre formation. The public consultation the EDPB has opened isn’t a formal exercise concerning only data protection specialists: it’s the moment when the template is still being shaped, and therefore the moment when an informed voice can leave a mark. A software supplier to Italian public administration sending a reasoned contribution, grounded in concrete experience writing DPIAs for public entities, participates in defining the genre more than they might imagine. This isn’t a symbolic gesture: the consultation is the instrument through which European authorities gather edge cases, operational difficulties, incompatibilities with consolidated practice, and reformulate sections in response. In the next two months, from now to 9 June, there is time to contribute. After that, it will be late in the specific sense that the canon’s forms will have been chosen. It’s worth spending a day on it.

An hour of rewriting

I want to close with an image that came to me a few weeks ago, re-reading for the umpteenth time a paragraph on mitigation measures in the DPIA for a healthcare project. The paragraph was formally correct, covered the required points, cited the right norms. But it was badly written, with that particular opacity that uncared-for technical texts have, where syntax is essentially a parking lot for clauses. I re-read it thinking: if an auditor reads this passage quickly, what do they take home? The answer was: almost nothing — because the text isn’t made to be read quickly; in fact, it isn’t made to be read at all. It’s made to be present. It’s compliance archaeology before it’s even been filed. I spent an hour rewriting it, without adding content, merely ordering the rhythm. By the end the paragraph was 30% shorter and, most importantly, said the same things with a clarity it hadn’t had before. The difference was editorial, not technical. But it was exactly the difference that separates a form from a genre.

That hour of work, I think, is the exact measure of the change I’m trying to describe. In a form-DPIA world, an hour of rewriting on a formally correct paragraph is wasted time: the document is compliant, close the ticket, move on. In a genre-DPIA world, that hour is the only truly productive part of the day, because it’s the only part that improves the text’s quality as text. The transformation we’re describing, in short, also changes the definition of time well spent. It changes what a team is authorised to consider work. And therefore it changes how work is to be planned. A sprint planning that reserves two hours a week to collaborative DPIA writing and review is not the eccentricity of a team that enjoys wasting time on technical literature; it’s a team that has understood which documentary regime it is starting to operate in. A team that keeps treating the DPIA as an artefact to produce in one afternoon at project’s end is, literally, living in a regime that is ceasing to exist.

This small episode connects, in my head, to a thread I’ve been pulling on for months across apparently different things: software that doesn’t age well, the product ceasing to be a stable category, the internet having been enclosed rather than degraded. In all these cases the underlying question is the same, and it concerns writing. When a technical artefact ceases to be self-sufficient and becomes part of an ecosystem of texts that document its existence, the text’s properties matter as much as — and often more than — the artefact’s. Modern software, I argued in Cruft, Not Patina, doesn’t age because it’s never finished enough to age. The DPIA, in a mirror image, can no longer be finished enough to be archived: it lives as long as the processing it documents lives, and each of its versions is a photograph in motion, not a monument. Compliance is becoming, almost without anyone noticing, a practice of continuous writing rather than of final archiving. And like every practice of continuous writing, it rewards those who take it seriously as writing, not those who fake it as form-filling.

It’s a direction that will demand more of whoever writes, but will also give back more, in the long run, in terms of decision quality, defensibility of choices, transmissibility of accumulated knowledge. Translating it into practice, into our own workflows, is the work ahead for the coming months. It’s not urgent in the sense of deadlines; it’s urgent in the sense that the longer one delays, the more writing debt accumulates. And writing debt, in a genre still stabilising, is hard to repay when the moment of judgement arrives. Anyone writing their first DPIAs in the new template now is also, perhaps without fully realising, taking part in the formation of a canon. Over the next two or three years, the aggregate of thousands of European organisations’ concrete practices will decide which features of the genre become normal and which remain marginal. It’s worth being there — for once, not as spectator but as author.

Software doesn’t learn, in that sense. Software accumulates comments that apologize.

The archaeology of old code

Anyone who has worked on a codebase older than ten years recognizes a particular kind of comment. // HACK: remove when we migrate to API v2. // TODO: figure out why this works. // DO NOT TOUCH: broke production three times. They are signed by people who no longer work there, addressed to future readers who will never quite get around to resolving them. Are they patina? No — they are scar tissue. The difference isn’t just lexical. An Alvar Aalto chair from 1932, if it has been genuinely used, now carries an aesthetic weight that the chair off the factory floor in ‘32 didn’t have. The wood has darkened where hands rest. The matte finish has lost sheen unevenly; it has learned the body that sat in it. There may be a small repair at the joint between leg and seat, a replaced screw, a reinforcement tastefully done by some intermediate owner. None of this makes the chair worse. It makes it more beautiful, more valuable, more itself. A serious restorer refuses to strip patina, because patina has become constitutive of the object. Restoration is the art of distinguishing damage from history.

A PHP application from 1998, if it has been genuinely used, carries no added aesthetic weight at all. It carries layered workarounds for browsers that no longer exist. It carries validation logic added three times at three different levels because at every maintenance cycle no one trusted what was already there. It carries four-hundred-line functions handling edge cases introduced by customers who stopped being customers a decade ago. No one proposes preserving this condition as part of the product’s value. The industry word for it is technical debt, and the vocabulary gives the game away: debt, not history. Something to retire, not honor. The very words we use to describe our relationship with time reveal that we have no concept for calling an old system beautiful. The best we can manage is “solid,” “battle-tested,” “proven.” These are virtues of resistance, not virtues of accumulation.

The archaeology of old code is an informal discipline every senior engineer practices without ever having studied it, and it has its recognizable constants. There are the compatibility strata for long-extinct browsers: if (window.ActiveXObject) to detect old Internet Explorer, CSS hacks that exploited specific Firefox bugs from before the great rewrites, conditionals checking for window.attachEvent back when the browser field was genuinely plural and incompatible. There are feature flags still switched on for gradual rollouts that were never completed — half the code sitting behind if (feature_active('new_checkout_flow')) and the other half in the else branch, the feature at one hundred percent rollout for seven years, but no one brave enough to cut the dead branch because no one remembers exactly what it did. There are schema migrations begun and never finished, where two columns coexist in the same table, one with the old name and one with the new, both written by the application “just in case,” read selectively depending on where in the code you happen to be. There are functions with names like processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — a sedimentary log of cleanup attempts, none of which was ever really completed. None of this is patina. It is a sedimentary log of unkept promises, of intentions the business outran before they could be realized. If a furniture restorer found twenty overlapping coats of paint on an 18th-century dresser, each applied without stripping the last, he would not say the object had gained value through the layers: he would say it had been mistreated, and he would propose to remove them. Old code is treated exactly that way even by its practitioners, who call it legacy in a tone that mixes technical neutrality with a faint disdain. The word itself is perhaps the clearest tell of the field’s unresolved relationship with its past: it comes from the Latin legare, “to bequeath,” but in technical use it has come to mean nearly the opposite — something inherited against one’s will. A burden, not a gift.

Environmental drift, not aging

Why? Why do material objects gain something through time, while digital objects seem only to lose? An easy answer is that the difference is ontological: code is pure semantics; it has no material substrate on which the marks of use can settle. Wood breathes, absorbs moisture, oxidizes, wears at points of friction. A byte does none of this. A binary file today is bit-for-bit identical to the day it was written, barring accidental corruption of the storage medium, and that corruption carries no semantic value anyway: it tells you nothing about how the thing was used. The easy answer has the defect of every easy answer, which is to close the conversation at precisely the point where it ought to start.

Let’s go deeper. The reason a chair ages well isn’t that it’s made of wood; it’s that its surroundings remain substantially stable. Gravity doesn’t change. Human physiology doesn’t change. The function of “supporting a seated body” doesn’t change. The modifications the chair undergoes are internal modifications to its fabric, in dialogue with an environment that moves much more slowly than it does. The chair and the world around the chair age together, at roughly the same pace, and the result is a kind of domesticated co-evolution. Software exists in an environment that moves much faster than it does. The browser ships a new major version every four weeks. The language breaks backwards compatibility every two years. Libraries have a shelf life shorter than a parliamentary term. The operating system under it stops existing in the form it was compiled against. Software doesn’t age internally, the way wood does. It progressively detaches from its environment, like a spacecraft that has run out of propellant and watches the station drift away. What we call “software aging” isn’t aging in the chair’s sense. It is environmental drift. It measures the growing distance between a fixed artifact and a context in motion.

This difference is ontologically decisive. A building and its urban context age together in continuous dialogue, and that co-belonging is the very condition on which we can speak meaningfully of “aging” at all. Software has no co-belonging: it has compatibility, which is a much poorer relation. Compatibility means only that two things that don’t speak to each other can keep pretending to, for one more release cycle. When Brand writes that buildings learn, he is describing a process in which the building and its inhabitants modify one another. When a systems engineer adds a compatibility shim to run an old binary on a new kernel, she is driving a wedge between two worlds that have stopped talking, and she is buying time. The shim is the opposite of learning: it is the admission that learning is not possible, and that only the appearance of communication can still be kept up.

Ruskin, and the truth of use

There’s a passage in Ruskin, in The Seven Lamps of Architecture, where he argues that a new building is by its nature false, and only becomes true through the frequentation of years. Ruskin is Victorian, emphatic, often insufferable, but that sentence is one of the most precise things ever said about the built object. The truth of a building lies not in the blueprint but in the history of its use. Apply the same criterion to software and you have to conclude that software never becomes true. It stays in a permanent state of newness even when its compile date is twenty-five years old, because the accumulation of history that would make it real in the Ruskinian sense isn’t possible in its medium. The only thing it accumulates is mounting incompatibility with its surroundings — and that isn’t history. It’s erosion.

The Unix objection

Here we have to face the strong objection — the one every technically literate reader has already been composing in their head, and which, left unanswered, makes everything above suspect. The objection is: Unix is more than half a century old, and not only still works but has become more elegant over time, not less. POSIX, TCP/IP, SQL, the hierarchical filesystem, the pipe. These are all ideas somewhere between forty and sixty-plus years old. They sit at the center of the planet’s digital infrastructure. They don’t behave like the 1998 PHP from earlier. They behave, if you like, exactly like Aalto’s chair: objects that have crossed time gaining, not losing. Something in the argument doesn’t add up.

The objection is serious and deserves a serious answer. The easy response would be to call Unix an exception, an outlier, a lucky case that doesn’t invalidate the rule. That would be a weak response. The more interesting answer is that Unix doesn’t contradict the previous argument but exhibits its exact mechanism, and clarifies a distinction that has so far stayed implicit. The distinction is between software as code and software as specification.

Spec, not code

What we call “Unix” today is not, literally, the software Ken Thompson and Dennis Ritchie wrote at Bell Labs between 1969 and 1971. That code has been dead for decades. The commercial AT&T branch was sold, split, re-absorbed. BSD was forked many times, and every fork has since been rewritten. Linux — today the dominant form of “Unix” in global infrastructure — shares not a single line of code with the original Unix: it is an independent reimplementation, begun by Linus Torvalds in 1991, that exposes the same system interfaces (calls, filesystem structure, conventions) but was written from scratch. macOS descends from NeXTSTEP, which in turn rests on the Mach microkernel and BSD components, and here too the code has been rewritten and recast so many times that material continuity with the starting point is purely ritual. What has survived isn’t Unix’s body; it’s its form. Its interface. Its grammar. The fact that there are system calls named open, read, write, close, working more or less as they worked in 1973, doesn’t mean the code implementing them has aged well. It means the specification defining them has become a different kind of thing from code entirely. It has become culture, convention, shared language, norm de facto and then norm de jure via POSIX.

The same goes for TCP/IP. The protocol survived; the implementation did not, or at least not in its original form. Every modern TCP/IP stack — from Linux to Windows to iOS to the ESP32 powering a smart bulb — has been rewritten or realigned many times over the decades. The 4.4BSD networking code, long a reference base for kernel networking in many systems, has been absorbed, branched, and reimplemented to the point that modern stacks hold a historical rather than material kinship with it. What persists, unchanged, is the RFC: a text document describing, in technical English, how two machines ought to speak to each other. The RFC isn’t software. It is closer to a diplomatic treaty than to a program. That’s why it ages well: it belongs to the same class of objects as a diplomatic treaty, a constitution, a grammar. It is a shared convention whose force comes not from its implementation but from the number of actors who recognize it as binding.

SQL is the most instructive case. The SELECT ... FROM ... WHERE syntax was defined in the mid-1970s by Donald Chamberlin and Raymond Boyce at IBM. Today everyone uses it. But no relational database in production today runs on the original System R code. Postgres is a reimplementation. MySQL is a reimplementation. SQLite was written from scratch in the 2000s and is now probably the world’s most widely deployed database by number of active instances, arguably outnumbered only by Excel spreadsheets. The code implementing SQL has died and been reborn so many times that material continuity is beside the point. What remained is the relational model, which is a mathematical object, and a certain syntax, which is a cultural one. Both detached from the code that first embodied them, and precisely because they did, they were able to cross time.

TeX, SQLite, and the telling exceptions

There are, however, a handful of rare cases in which the code itself seems to have achieved something like patina, and they are worth looking at because they illuminate the general condition by contrast. TeX, the typesetting system Donald Knuth began writing in 1978, is one such case. At some point Knuth declared TeX finished, in the literal sense: no new features, only bug fixes, with the version number converging asymptotically to pi with each release — the explicit intent being that when Knuth dies, the version number will equal pi exactly, and the software will stop changing forever. Knuth offers a small monetary reward, doubling every year, to anyone who finds a bug in TeX, and for many years now no one has claimed it. Not because there aren’t bugs left, but because the software has been used so thoroughly, for so long, that the remaining ones live in corners no one ever visits. TeX works today as it worked in the late 1980s; it compiles the same source files and produces the same typographic output. Its source code, written in WEB (Knuth’s own literate-programming system combining Pascal for logic and TeX for documentation), was published in 1986 as TeX: The Program, Volume B of Computers and Typesetting, and is treated as a literary work. It has been read, commented on, studied. It is one of the rare times code has crossed the threshold from pure implementation into something like specification — but in the concrete form of the program, not in the abstract form of an RFC. Knuth achieved this by imposing an extreme condition on his own work: refuse every evolution. TeX doesn’t age because, in a sense, it chose not to live. It accepted mummification as the price of permanence.

SQLite is the other interesting case, more recent and less mystical. Its developers have publicly declared, in the project’s documentation, the intention to maintain the library at least through 2050, with full backwards compatibility of the C API and the on-disk format. That commitment isn’t boilerplate; it is a concrete constraint that follows from the fact that SQLite is embedded in avionics systems (the Airbus A350 among others), medical devices, and military equipment — all objects whose life cycles exceed forty years. To sustain such a horizon, SQLite has built a test apparatus that, according to figures its own developers publish, runs to roughly ninety-two million lines of test code against one hundred fifty thousand lines of actual library, a ratio of nearly six hundred to one. Every conditional branch is covered by MC/DC tests, the standard used in avionics for DO-178B certification. The code itself is written with explicit attention to the fact that it will be read and maintained by people not yet born. SQLite took duration as a design problem from the start, and has treated the stability of its own interface as an ethical question more than a technical one. The result is a piece of software that has existed for more than twenty-five years, runs on billions of devices, and has never prompted anyone to rewrite it from scratch. It’s a case where the code itself, not just its specification, seems to have aged well. But look a little closer and you see the result was achieved only by accepting constraints the rest of the industry would refuse. SQLite almost never changes, even at the cost of giving up features that would make it more modern. SQLite has no external dependencies, almost as a protest against the way the rest of the world builds software today. SQLite has an internal culture that borders on monastic. In other words, SQLite ages well because it built itself an ecological niche in which the environment around the code has been artificially stabilized. It recreated, inside a small perimeter, the conditions that let an Aalto chair become more beautiful with the years: an environment that moves slowly, a user who pays attention, a culture that recognizes the value of duration. It is no accident that these examples are, statistically, anomalies. They are the exceptions that reveal exactly which conditions are necessary for software to age — and confirm that in the main body of the field, those conditions do not exist.

The body dies, the spec resurrects

Viewed from this angle, Unix doesn’t age well. Unix is continuously resurrected. The body dies and is remade from scratch, starting from a specification that has meanwhile become sacred enough to warrant wholesale rewriting of the body every twenty or thirty years. It has the structure of a religion more than of a material object. Aalto’s chair, to stay with the metaphor, has never been rebuilt from scratch: the chair from 1932 is physically there, dents and all. If we applied the logic of Unix to wood, we would have to say the concept “Paimio chair model 41” survived because Artek, since its founding in 1935, has continued production for over ninety years, and the chairs of 2026 are descendants of those from 1932 without being the same chairs. It would be true, but beside the point: what interests us about the 1932 chair is precisely its material duration, not the persistence of its model. With software it is the opposite. We don’t care about the original code, and no one preserves it as a relic. We care about the persistence of the model, and that persistence requires the periodic destruction and rewriting of the code.

The Unix objection, then, doesn’t refute the argument; it sharpens it. What ages well in the digital isn’t code. It is specifications that have been lucky enough, and well-capitalized enough, to rise above their implementation substrate and become something else. Standards. Stable interfaces. Lingua francas. Most code never reaches that level and cannot reach it. Ninety-nine percent of the software running today will not become POSIX. The custom CRM for a four-hundred-person company will not become SQL. A retail chain’s e-commerce site will not become TCP/IP. Not because it’s badly written, but because it isn’t that kind of object. It is, structurally, implementation. And implementation, in digital, cannot age well, because it has none of the requirements for doing so: no material substrate to register use, no stable environment to persist in, none of the cultural weight that permits periodic reincarnation.

Rewriting isn’t a sin

This distinction clarifies an old debate inside the field that has always been badly framed. In 2000, Joel Spolsky wrote a widely circulated article, Things You Should Never Do, Part I, arguing that rewriting functioning software from scratch is the worst strategic mistake a software company can make. The specific case was good: Netscape had lost the market because it decided to rewrite its browser from scratch, leaving the window open for Internet Explorer for three years. The problem with Spolsky’s essay is that it generalizes from that one case without acknowledging that most software has to be rewritten, sooner or later, because it cannot be maintained indefinitely in the form it was conceived. Unix has been rewritten many times. Linux itself, at the level of individual subsystems, is being continuously rewritten: the scheduler has been replaced, the networking stack has been redone, the filesystem has been rethought. What Spolsky called “never rewrite” was really “don’t lose the continuity of the specification during the rewrite,” which is a very different and much harder thing. A rewrite fails when it loses contact with what the code was doing for its actual users. It succeeds when it preserves the specification and throws the implementation away — the way a Catholic body is buried but the soul moves on.

A dignity denied

If this reading is correct, then the low-grade melancholy running through much of everyday technical work has a structural, not psychological, explanation. We aren’t writing badly. We are writing objects that cannot age, because we don’t belong to the narrow class of artifacts that can rise to the level of cultural specification. Ninety-nine percent of what we write is destined to die without trace — not through poor craftsmanship but through a property of the medium. A thirteenth-century mason knew that a good wall would still be standing in the sixteenth century, and probably much later. A twentieth-century plumber knew that his pipes, with a bit of maintenance, would serve three generations. A developer in 2026 knows that the code she is writing today will, with reasonable probability, be decommissioned within five to seven years. Not because it’s written worse than pipes. Because the pipe and the wall belong to a regime in which aging is possible, and code does not.

This changes the ethical character of the trade in ways we have not yet metabolized. For millennia, building something durable was among the highest forms of dignity in human work. The cathedral, the bridge, the printed book, the violin. Objects made with the consciousness of lasting beyond the life of their maker. Software development is one of the few highly skilled trades in which that dignity is structurally foreclosed. Not because no one works well, but because the medium does not admit that kind of duration. The technical debt we opened with, seen from this angle, is not a defect manageable through better practice, tighter discipline, more rigorous testing, sharper code review. It is the specific form the unavoidable deterioration takes in an artifact that has no other way to deteriorate. It is how software ages badly because it does not know how to age any other way.

The lamp of memory

There is a broader reading here, one that leaves the strictly technical domain and touches something more uncomfortable about the culture we live in. Ruskin, again, identified seven virtues of architecture, which he called lamps. Sacrifice, truth, power, beauty, life, memory, obedience. The lamp of memory was, for him, the virtue of buildings that let themselves be crossed by time without resisting it, that preserve the traces of those who inhabited them, that become, in their way, biographical archives of human passage. A civilization that cannot build objects capable of memory, Ruskin said, is a civilization that has given up one of its fundamental functions: the transmission of itself through its things.

The digital, from this point of view, is the exact opposite of Ruskinian architecture. It is a material culture — if it can still be called that — in which memory doesn’t accumulate in things but leaves them. Five-year-old software is already an antique. A website from ten years ago is no longer reachable; its domain has lapsed, its links are all broken, its images point to decommissioned servers. Digital archives exist only thanks to heroic and marginal efforts: the Internet Archive is a single point of failure for three decades of online culture, and no one has really figured out how to replace it. Our photographs sit on servers we don’t own, in formats that may not be readable in twenty years, protected by service agreements that can be changed unilaterally. Our correspondence is in mailboxes that will vanish when the company hosting them changes business model. The material continuity of human inheritance — imperfectly guaranteed for millennia by the physical persistence of objects — has become precarious in a way no previous civilization had known.

That precariousness is not a side effect but a structural property of the medium. And software, which is at the heart of this new condition, inherits and amplifies the precariousness. It doesn’t age because it cannot accumulate memory in its fibers. It has no fibers. Its only form of continuity is rewriting, which is the exact opposite of memory: the periodic production of a new object that pretends to be the same.

Someone at this point may object that I am dramatizing, that every era has had its precariousness, that papyrus decayed and parchment was scraped and the printed book burns. True — but the quantitative difference is so large it becomes qualitative. The average durability of a well-kept printed book is measured in centuries. The average durability of a digital file is measured in years, perhaps decades in lucky cases. The delta is one or two orders of magnitude. A civilization in which cultural objects last a hundred times less than in the previous one is a structurally different civilization, not merely quantitatively but qualitatively. It has a different relationship with time. It produces a different subjectivity in those who live inside it. A developer knows, in a way a sixteenth-century printer did not, that his work will not outlive him.

The ephemeral objection

There is a less tragic way of reading all this, and it’s worth working through before closing. The objection runs like this: maybe permanence isn’t necessarily a virtue; maybe software is a form of deliberately ephemeral cultural production, in the sense in which a theatrical performance or a jazz set are ephemeral — and their ephemerality is not a defect but a constitutive feature of how they exist in the world. A lambda function that runs for thirty-seven milliseconds and disappears isn’t a failed object because it doesn’t last; it is a fully realized object because it did exactly what it needed to do in the time it needed to do it. The monument metaphor, inherited from architecture, may simply be the wrong fit for the medium, and insisting that software “doesn’t age well” may be like complaining that a thunderstorm doesn’t age well — a category error.

The objection is interesting, but it breaks the moment you take it seriously. The problem is not the code that runs for thirty-seven milliseconds. That really is an event, not an object. The problem is that nearly all the software we depend on in daily life is not an event in that sense: it is infrastructure. The system our bank uses to manage accounts is not a jazz performance. The medical software running the ICU ventilator is not a thunderstorm. The municipal registry database is not an ephemeral function. They are objects that claim to be infrastructure, that we treat as infrastructure, that institutions embed in their processes as if they were infrastructure, and yet that have the durational and memorial properties of a cloud. This discrepancy — between the social function software performs and its material durational properties — is the point at which the question stops being philosophical and becomes civic. A society that entrusts its vital functions to objects that cannot grow old is, quietly, shifting the cost of maintaining its own continuity onto a technical layer that cannot carry it.

Precarious infrastructure, law playing catch-up

Seen from this angle, the European Cyber Resilience Act — adopted as Regulation (EU) 2024/2847, fully applicable from December 2027 — along with the new Product Liability Directive (EU) 2024/2853 and the obligations under NIS2, are clumsy but telling legislative attempts to force software to behave like serious infrastructure. They require producers to define a support period reflecting the product’s expected life cycle — at least five years in most cases — to keep SBOMs up to date, to answer for vulnerabilities introduced into the product even after sale. They are, in a sense, a legislative attempt to impose on software the durational properties it does not naturally have. That these rules exist, and that the industry perceives them as an added cost rather than an acknowledgment of civic responsibility, says something about how deeply developers have internalized ephemerality as a professional privilege. A mason knows he must answer for his wall for many years. A developer is used to answering for her code until the end of the contractual warranty — typically twelve or twenty-four months. The two trades have horizons of responsibility that differ by an order of magnitude, and the difference is invisible in the language we use to describe them.

An ethics of duration

Coming back to the initial question — why software cannot age — we can now give a less lapidary answer. It cannot age because it is made of a material without grain, in an environment that moves faster than it does, inside a productive culture that has given up on considering duration one of the dimensions of value. Each of these three factors is a sufficient cause of the result, and together they make the result nearly inevitable. The first is ontological and probably unresolvable: code will never become wood. The second is systemic and could be mitigated, if the technical culture learned to treat stability as a virtue rather than a sign of being behind. The third is purely cultural, and it is the only one on which we can really act.

Act how? Probably in directions the field currently considers regressive. By slowing release cycles. By preferring backwards compatibility to elegance. By writing less code and more specification. By treating stable interfaces as monuments — objects whose value lies in their resistance to change. By accepting that most code will not become Unix, and that precisely for that reason, it ought to be written with some consciousness of its transient destiny — without the false ambition of duration and without the nihilistic despair of its absence. A trade that knows it isn’t building cathedrals but refuses to build shacks. An intermediate dignity, for which we don’t yet have a good name, and which may be one of the things this generation of technologists should try to articulate.

If there is any consolation in the fact that software doesn’t age well, it is that this property forces us, by contrast, to bring into focus what aging well means in general. It forces us to recognize that the patina on Aalto’s chair is not an automatic fact of wood, but the result of a long relationship between a well-made object, a stable environment, an attentive user, and a culture that knows how to recognize the value of that triangulation. When one of those terms drops out, patina doesn’t form. Wood left in the rain doesn’t acquire patina; it rots. Wood sealed in storage doesn’t acquire patina; it desiccates. Patina is a collective work that requires time, care, and context. Software, as things stand, has none of the three, and the idea that it might sounds like a nostalgic fantasy.

It isn’t. It’s a design question. What would it mean to write code knowing it had to last as long as a wall? We don’t really know yet, because we’ve almost never tried in earnest, and when we have, it has almost always been in domains marginal to the mainstream: avionics, industrial control, legacy banking systems — places where duration is imposed from outside as a regulatory constraint rather than chosen as a cultural value. Civil software — the software that builds the public and private life of most people — has been built on the implicit assumption that duration isn’t its problem. That assumption is becoming untenable just as society is delegating more and more vital functions to software. Among the responsibilities of this generation of technologists, formulating an ethics of duration for the trade is probably among the most serious, and among the least postponable.

What remains, in the end, is the underlying question. Software doesn’t age well. At the start, that sentence sounded like a technical grievance. Arrived here, it’s clear it is something different. It is an exact description of the kind of artifacts we have collectively decided to place at the center of our shared life, and an implicit demand to reckon with that decision. The objects at the center of a civilization ought, within the limits of the possible, to know how to accompany it through time. If they don’t, we should either change them or change the place they occupy. Thus far we have done neither. We have let them occupy the center while behaving as though they were at the periphery, and we have called that condition “progress.” It’s worth starting to call it by a more accurate name.

When the second half of the liquid was poured into the glass along with the melted ice cream, a snail in an advanced state of decomposition came out of the bottle, carried along by the fizz. May Donoghue fell severely ill with gastroenteritis, was seen by a doctor on 29 August, and was admitted as an emergency to the Glasgow Royal Infirmary on 16 September. Four years later, in 1932, the House of Lords handed down a ruling that is considered the cornerstone of modern product liability law in the common law world.

The snail in the bottle

The decision was taken by a majority of three votes to two. The majority opinion was written by Lord Atkin, who in the famous passage every law student still memorises today formulated what became known as the neighbour principle: the legal duty each of us owes to take care of our neighbour, where «neighbour» means anyone who could reasonably be foreseen as affected by our conduct.

From that moment on, a manufacturer is liable for its product even to those with whom it has no contractual relationship — even if the bottle passes through a distributor and a café before reaching the consumer, even if weeks of warehousing and miles of road lie between the factory and Mrs. Donoghue’s gastroenteritis.

What almost no one notices, reading the judgment, is that in order to write the neighbour principle the court needed a precise ontological presupposition: a certain idea of what the object in question actually was. The object was the bottle. A bounded artefact, with sharp edges, identifiable, examinable, preservable.

The bottle was produced in a specific plant — at David Stevenson’s in Paisley — filled at a dated moment, sealed with a stopper that guaranteed its integrity up to the point of sale. If necessary, lawyers could have demanded to examine the production batch, analyse the composition of the glass, trace the supply chain of sugars and flavourings. The material cause, in the Aristotelian sense, was reachable. The efficient cause — the production process — was documented. The formal cause — the typical shape of a ginger beer bottle — was known to anyone.

The whole modern law of product liability built on top of Donoghue v. Stevenson presupposes this utterly simple and absolutely crucial thing: that you can point your finger at an object and say «this», and that the finger finds something at the other end.

The new PLD and the problem of a category

In 1985, Europe, with Directive 85/374/EEC, adopted the Donoghue principle in continental form, extending and systematising it. The Product Liability Directive speaks of «defective products» and establishes a strict, no-fault liability for the producer for damages caused by the product.

Forty years later, on 23 October 2024, Directive 2024/2853 was adopted, entered into force on 9 December 2024, and must be transposed into national law by 9 December 2026, the date on which the 1985 directive is repealed. The new PLD was designed expressly for software, and includes in the definition of product digital files, software components, applications, and AI systems. It is one of the most ambitious reforms of civil liability law ever attempted by the European Union.

The fact that it took forty years to be rethought, and that despite the enormous effort of its drafters it risks being inadequate the day it enters into force, is no one’s fault in particular. It is the consequence of a problem that the law has not yet been able to name precisely. The problem is that the «product» on which Lord Atkin and his successors built two centuries of jurisprudence no longer exists in contemporary software.

It is worth taking a minute to understand where it went, because diagnosis is the starting point for everything that follows.

From record to concert

For a long time, software was a product in the full, conventional sense of the word. It emerged from the Bell Labs lab and entered mass distribution with Unix, then with operating systems for personal computers.

An application of the 1980s or 1990s was a set of files distributed on floppy disks, then on CDs, then on DVDs, with a version number, an identifying hash, a copy that could be kept in a vault. If the software had a defect, you could, at least in principle, isolate the exact version of the binary, compare it with the supposedly correct one, identify the bug. Windows 95 was a product. Microsoft Word 97 was a product. Even a game like Baldur’s Gate was a product, with its numbered, archivable patches.

Of course, even then software depended on things that were not the product in the strict sense: device drivers, firmware, network protocols, system services. But those dependencies were static, declared, limited in number, and above all mediated by a self-sufficient artefact that could be preserved and reproduced many years later. The copy of the Windows 95 CD that a digital archivist keeps today is still identical to the one from 1995, bit for bit. The product, as an object with continuity in time, existed.

In the early 2000s something began to change, and the pace of change accelerated dramatically over the following decade. The transition to software as a service moved the application from the customer’s local disk to the vendor’s server. At first it was a simple matter of distribution, but very quickly it became an ontological transformation.

When the application runs on a remote server, the version of the application the user is using at any given moment is no longer a stable property, it is a momentary one, renegotiable by the vendor at any instant without even notice. Continuous deployment takes this fluidity to its natural conclusion, with companies shipping tens or hundreds of changes to production per day, and no one — not even internally — able to reconstruct exactly what the system’s configuration was at 2:23 p.m. on a Tuesday three months ago.

Meanwhile, and in parallel, the internal composition of software changes in nature. From the early 2010s onward, thanks to ecosystems like npm for JavaScript or Maven for Java or PyPI for Python, writing an application means importing hundreds or thousands of third-party packages, each in turn made up of third-party packages, in a graph of transitive dependencies that no human reads in full and that updates continuously and asynchronously with respect to the code you yourself wrote. The left-pad incident of 2016 — when a single developer unpublished an eleven-line package from npm and broke a large fraction of JavaScript build pipelines and install processes worldwide — was the moment when the industry noticed, for an instant, how fragile and distributed the thing it still called a product had become.

The latest acceleration, the one we are living through right now, is the entry of language models into the production chain of software. Here the leap is not only quantitative but categorial, because what enters the product is no longer a set of deterministic instructions but a probabilistic component whose outputs are not exactly reproducible even from the same inputs, and whose weights, once retired by the vendor in favour of a successor, may no longer be accessible at all.

An application running today and using the API of a frontier model is an application whose observable behaviour depends on a component that tomorrow may behave differently, that two years from now may no longer exist in any recoverable form, and whose internal workings are not inspectable by anyone — not even by those who trained it. Anyone writing software today knows perfectly well that if a user from five years ago asked us to reproduce exactly the bug they had seen back then, the honest answer would be that we can’t: the system that produced that bug no longer exists in any restorable configuration. Dependencies have been updated, external APIs have changed contract, the database has been migrated, the AI model has been replaced. We have the logs. We have the code of our application. But the event that produced the bug was a concert, and what’s left of concerts is recordings, not concerts.

This is the metaphor that I think captures the ontological shift underway best. Contemporary software is no longer a record. It’s a concert.

A record is a stable, preservable, comparable artefact — an object with its own identity in time. A concert is an event distributed in space and time, co-produced by many agencies in real time, unrepeatable, of which you can have traces but not originals. When we listen to the recording of a Keith Jarrett concert from 1975, we are listening to a derived artefact — we are not listening to the concert, which happened once and is over. The same holds for a SaaS application today.

What the user experienced yesterday at 11 a.m. was an event co-produced by the application, by the user’s browser, by network latency, by the current version of the underlying LLM, by the configuration of twelve third-party APIs, by a rate limit that at that exact moment had a certain value. That event is not reproducible, not preservable, ontologically not an object. It is, precisely, a concert.

The objection and the copy that isn’t there

Someone, at this point, might object that the distinction is overstated, that after all even in 1998 software ran on an operating system that depended on drivers and hardware, that runtime contingency existed back then too, that every use of an application has always been, in some measure, an event rather than an object.

The objection is partly correct, and taking it seriously matters, because it is the only way to keep diagnosis from collapsing into nostalgia. The difference that changes everything, however, is one and only one — and it is the difference the law has not yet metabolised.

In 1998 there was always a copy of the artefact. In the strictest, most concrete sense of the term, in the vendor’s vault or on the user’s hard drive or in some digital archivist’s storage, there was a material object that contained the software in its autonomous form. That copy was the point of contact between the legal product and the executive event. It was the Archimedean point that made it possible to go back, examine, compare, judge. It was what let the lawyer say «this product was defective» because a product was there.

Today that copy no longer exists, and it does not exist not because of negligence or bad choice, but by construction. Vendor X’s SaaS application at 2:23 p.m. on a Tuesday three months ago exists in no backup, no vault, no archive. What exists is only the possibility of reconstructing, approximately and partially, what it must have been, by cross-referencing logs, code versions, dependency configurations, model weights, database state.

This is an archaeological reconstruction, not an access to the object. And even when such a reconstruction is complete, the result would be yet another thing — a model of the application at that moment, not the application at that moment. The product, in the two-century-old legal sense, has vanished. What exists in its place has never been named.

The European corpus and its categorical misalignment

To their credit, European legislators have noticed that something isn’t adding up. In recent years they have produced an impressive package of rules trying to grasp the new object with the tools at hand.

The Cyber Resilience Act, which came into force in December 2024 with full application in December 2027, introduces the concepts of security by design and security by default for products with digital elements, imposes support obligations across the full lifecycle, requires the provision of a Software Bill of Materials. The new Product Liability Directive, the 2024 one mentioned above, explicitly extends liability to cybersecurity defects and to malfunctions from software updates. The Artificial Intelligence Act, in force since 1 August 2024 with general application from 2 August 2026 (and some provisions slipping to 2 August 2027), classifies AI systems by risk and imposes obligations of documentation, transparency, and conformity assessment. Add to these NIS2 for network security, DORA for the financial sector, the Data Act, the European Accessibility Act.

Together they form the most ambitious regulatory corpus ever built to govern software production, and they are a serious, technically informed, culturally important effort. It would be a mistake to dismiss them as bureaucracy or as a brake on innovation, as a certain libertarian Californian vulgate likes to do. The thesis of this essay, rather, is that — serious and important though they are — these instruments are trying to capture the concert with the categories of the record, and the categorical misalignment is bound to generate consequences we are only beginning to glimpse.

The case of the Software Bill of Materials is paradigmatic of this difficulty, and it is also the one I know best for professional reasons. An SBOM is a document that lists all the components that enter a software product, their versions, their dependencies, their licences. On paper it’s a perfectly sensible tool, the software equivalent of the ingredients list on food packaging.

In practice, an SBOM is a photograph of a concert, with all the epistemic limits that condition entails. A photograph of a concert is not the concert — it is already another object: derived, partial, dated. In the very moment the photograph is taken, the concert is already changing, and a tenth of a second after the shutter closes, transitive dependencies may have updated, the external API version may have changed, the model weights may have been swapped by the vendor.

The SBOM captures a state, but contemporary software has no stable states, only flows. The regulation therefore requires developers to keep the photograph up to date, which in turn generates processes of continuous SBOM generation, with tools producing the SBOM on every build, every deploy, ideally in real time. The paradoxical result is that the document that was supposed to capture the identity of the product multiplies into thousands of daily snapshots, each of which is already obsolete the moment it is generated. The SBOM does not capture the product, because there is no product. It captures the flow, in the form of discrete frames, and each frame is a legally relevant document. The resulting documentary load is enormous, and its probative value, when it comes to reconstructing who was responsible for what at a precise moment, is far less clean than legislators assumed.

The same problem, compounded by the stochastic nature of the models, arises for the AI Act. Article 10 asks that training datasets be documented, traceable, governed according to quality criteria. Article 15 asks that high-risk AI systems be accurate, robust, cybersecure. Article 72 requires post-market monitoring. Each of these obligations, taken in isolation, makes sense, and points to practices that the best machine learning engineering should already be adopting.

What legislators have not fully absorbed is that the language model a vendor offers today via API is an object whose identity in time is, at best, conventional. The model’s weights get updated, the RLHF system gets refined, the guardrails modified, and what continues to be called GPT-4 or Claude Opus or Gemini Ultra is, from the standpoint of observable behaviour, a different object from what bore the same name six months ago.

Asking for training documentation means asking for documentation of something that, by the time the documentation is produced, may already have been superseded by another training run. Post-market monitoring is excellent practice, but it presupposes a market in which the product is the same at the time of sale and at the time of use — something that is almost never true for language models.

This isn’t to say the AI Act is wrong, because the AI Act is one of the most articulate regulatory responses ever attempted at comparable scale. It is to say that the AI Act inherits from product liability law a set of ontological presuppositions that the object it tries to regulate does not satisfy, and that the tension between presuppositions and object will fall, in the coming years, onto the shoulders of practitioners — in the form of compliance obligations of ambiguous value, documents whose relation to reality is hard to establish, controversies in which the dispute between parties shrinks to a debate over whether a given snapshot was representative of the system at the moment of harm.

CrowdStrike, July 19, 2024

A recent example, of such reach that it has entered risk management courses all over the world, helps to see concretely what all this means.

On 19 July 2024, a faulty update of CrowdStrike’s Falcon sensor caused the simultaneous crash of roughly 8.5 million Windows machines around the planet, with a boot loop that required manual intervention on each device to resolve. Airports grounded, hospitals reverting to paper operations, banks offline, broadcasters dark, emergency calls not routed. Delta Airlines alone declared over half a billion dollars in direct damages, Fortune 500 companies declared uninsured losses in the order of $5.4 billion, with global estimates placed by various sources in the tens of billions.

In the ensuing litigation, still open in multiple jurisdictions, the whole question has focused on one point: who was responsible?

• CrowdStrike, which pushed an update containing a defect any careful test would have caught.
• Microsoft, which allowed third-party software to operate with kernel-level privileges sufficient to boot-loop the operating system.
• The deployer organisations, which accepted auto-push updates without canary stages.
• European regulators, according to Microsoft’s defence, which years earlier had forced the vendor to open the kernel on competition grounds.

Each of these four attributions of responsibility, taken singly, captures a real aspect of the affair. None, taken singly, tells what happened. What happened was an orchestration failure: an event in which many actors each held, at their own level, actual influence over the system’s runtime behaviour, and in which no one had exercised that influence in proportion to the possible consequences.

Current law has no adequate tools to distribute liability this way, and litigation is sliding, as a result, toward scenarios where the better-lawyered party wins or where the most defensible contractual position prevails — which is another way of saying the law has given up on saying anything substantive about the incident. A case like CrowdStrike, read through the lens of the responsible-assemblage category I am trying to sketch, should have produced a ruling that distributed liability in identifiable shares across the various actors as a function of their blast radius and their degree of effective control, and that created a precedent usable for future incidents, which will certainly be many. None of this is happening, because the category for doing it isn’t there.

Latour, Ricœur, and the plurality of action

Before going further, it is worth clarifying that responsible assemblage is not an invention ex nihilo. It is the adaptation, to the legal domain, of reflections twentieth-century philosophy developed in other fields and that have not yet made sufficient inroads into courtrooms.

Bruno Latour, with actor-network theory, had already shown in the 1980s that complex actions never have a single agent — they emerge from networks of human and non-human actors whose analysis requires suspending the obsession with the individual subject and following the actual connections. His canonical example of the artificial speed bump — the so-called sleeping policeman placed on the road surface — is illuminating, because it shows how the bump enforces the speed limit independently of any human officer’s presence, acting as a non-human actor endowed with its own agency.

The car slowing down is co-produced by the driver, the bump, the traffic code, the fear of damaging the suspension, and the shared culture that recognises the bump as a signal to slow. None of these five actors, taken alone, explains the slowing down, and none of them, taken alone, is fully responsible for what happens when something goes wrong. Positive law tends to place responsibility on the driver for practical reasons, but the philosophical understanding of the event requires seeing all five together. The step the law has not yet taken, but philosophy has taken for forty years, is to accept that this distribution of agency is the rule, not the exception, and to derive its consequences for the attribution of responsibility.

Paul Ricœur, in Oneself as Another (1990) and in the subsequent reflection on imputability, added a complementary piece, showing that the act of attributing responsibility is a narrative act — it requires reconstructing a plausible story of causation, and when the plausible story involves many agents, imputative narration cannot be reduced to a single subject without betraying the truth of the event. For Ricœur, imputation is a hermeneutics of responsibility, and like any hermeneutics it demands patience, attention to different levels, refusal of simplification.

Contemporary product liability law simplifies too much, and does so because it has inherited a nineteenth-century narrative grammar in which the producer was one, identifiable, imputable. Reconstructing imputability for contemporary software means accepting the plural nature of action and letting it show through in the text of the judgment itself.

Responsible assemblage

If we stop here, the diagnosis risks looking pessimistic or purely critical, in the style of a certain tech-sceptical literature that takes pleasure in difficulties without proposing anything constructive. The point I want to try to develop is the opposite, because if it’s true that the concept of product no longer sustains its function of attributing responsibility, we have to start imagining what its replacement category might look like.

This is an intellectual undertaking that cannot be delegated either to pure lawyers, who have no contact with the runtime of real systems, or to pure engineers, who tend to treat law as an external annoyance rather than as an attempt to attribute moral meaning to what they do. The replacement category must be thought out with four hands — by those who have code practice and legal reading — and it must start from the observation that contemporary software is an orchestration, an assemblage, a distributed event, not an object.

I propose to call it, provisionally, responsible assemblage, aware that the name is not yet final and that the argument over the name is part of building the thing.

What would a responsible assemblage be, in first approximation? It would be a configuration of components — human and non-human — organised around a specific function offered to a user, in which no participant holds integral control but each exercises an identifiable degree of effective influence over the observable behaviour at runtime.

Liability, in this framework, no longer follows formal ownership («whoever holds the contract answers for everything»), nor the historical origin of components («if the bug is in the imported library, then the library maintainer is to blame»). Liability follows the gradient of effective influence.

Whoever was able, at the moment of the harm, to change the system’s behaviour through a targeted technical action answers in proportion to the degree of that possibility. The AI model vendor who could have updated the guardrails and didn’t answers for a share of liability. The integrator who chose that model for a sensitive function without adequately assessing the risks — while having the tools to do so — answers for another share. The user who configured the system in an anomalous way, bypassing the warnings, answers for a third. None of the three answers for everything, none answers for nothing. Each answers for their portion of the orchestration.

The formula is easy to state and infernally complex to implement, as is natural for every new legal category in its first decades.

The objections come fast, and it is worth running through them. The first objection is that «effective influence» is hard to measure, and that a legal system built on so slippery a concept would be a source of uncertainty. The objection is true but less grave than it seems, because civil liability law already operates with slippery concepts like fault, foreseeability, proximate causation, and has developed operational tools to handle them over time.

Effective influence on a distributed system is measurable through what engineers call blast radius — an estimate of the reach of the consequences of a technical action. An LLM API vendor has a blast radius that potentially encompasses all of its integrators, because a change on its side propagates instantly. An integrator has a blast radius limited to its own users, though this can be amplified if its application is itself infrastructure for other applications.

There are technical metrics — rough but tractable — for estimating each actor’s blast radius, and legal doctrine could build on top of them a graduated taxonomy of responsibility. It would be no more slippery than the doctrines of fault in the nineteenth century were before decades of case law made them workable.

Two deformations to resist

The second objection is more political and comes from two opposite directions, both in their own way invested in the outcome.

The first direction is that of the big-tech Californian environment, which has built over the past twenty years a narrative according to which the open-source and componentised nature of software makes it impossible to attribute responsibility to anyone in particular — and therefore responsibility should be limited to contract terms explicitly accepted by the parties. On this reading, if a user is harmed by an application that uses an open-source library whose author is anonymous, and the application is in turn hosted on a cloud whose provider disclaims all liability in its terms of service, then no one answers for anything — or rather, only those who have deliberately assumed responsibility by signing a contract do.

This is the doctrine of distributed irresponsibility, and it is a comfortable ground rent for those occupying the most central nodes of the orchestration, because it lets them capture the value and externalise the risks. Responsible assemblage opposes this doctrine frontally, because it rejects the idea that the absence of a formal title-holder amounts to the absence of substantive responsibility. If your model is the critical component of thousands of downstream applications, your responsibility does not depend on whether you signed a contract with those applications’ end users. It depends on your role in the orchestration, and that role is objectively measurable.

The other direction from which the objection comes is European continental formalism, which has an opposite but equally problematic tradition, which we might call the doctrine of the absolute controller.

On this tradition, the data controller, or the service provider, or the AI system deployer, answers for everything that happens along the chain, regardless of where the non-conformity or malfunction originated. It is an intuitively egalitarian doctrine, because it protects the user by guaranteeing that someone — an identifiable legal entity — will always answer. In practice, however, it produces two serious distortions.

The first is that it loads the controller with responsibility over which it has no technical control, forcing it to defend against litigation over malfunctions originating in components it did not write, did not choose, cannot inspect. The second is that it de-responsibilises the nodes upstream of the chain — precisely those with the most systemic influence — because they know their share of responsibility will be formally dumped on the final deployer and that courts will keep pointing at whoever sits in the most visible position.

Responsible assemblage opposes this doctrine too, because the controller’s formal position does not exhaust the question of responsibility, and a merely apparent distribution of the load — which in fact always concentrates on the most accessible node — keeps things exactly as they are in the industry’s real power relations.

The proposal, therefore, sits in territory uncomfortable for both prevailing sensibilities, and for that very reason deserves to be articulated with some patience. Anyone who works in software knows perfectly well that the idea of responsibility as a purely contractual fact is a convenient fiction for those in Silicon Valley and a daily experience of powerlessness for those in Pescara or Milan or Frankfurt who have to deliver a system that actually works in a context of real constraints. At the same time, anyone working with European compliance knows that the absolute-controller doctrine turns the deployer into a legal fuse, whose economic function is to blow when the system breaks, so that the upstream components can keep producing externalities.

Contemporary software needs a category that is neither of these, one that manages to distribute liability in a way that reflects the actual distribution of technical power. Not a symmetric distribution, because technical power is not symmetrically distributed. Not a concentration on the controller, because technical power is not concentrated on the controller. A distribution that follows the gradient of effective influence, with transparent metrics, with a workable doctrine courts can handle, with a rationale practitioners can recognise as matching their working experience.

There are some areas where something like this is already happening, even if no one calls it that. The GDPR, in Article 28 and in the EDPB guidelines on the chain of sub-processors, has begun, tentatively, to recognise graduated responsibility along the processing chain — though in a formalistic way and without the conceptual apparatus that would be needed. Data Protection Impact Assessments, when done seriously rather than as an exercise in compliance theatre, contain in embryo a blast-radius analysis applied to personal data.

The NIS2 directive on network security introduces obligations for managed-service providers that recognise their systemic role in the security chain. The AI Act itself, with its distinctions among provider, deployer, importer, distributor, attempts a taxonomy of roles that — still too rigid — points in the direction of a non-controller-centric distribution of responsibility.

None of these instruments has yet reached the point of explicitly formulating the principle of effective influence as a gradient of responsibility, but all contain traces of a rethinking that awaits only doctrinal systematisation. The impression is that what’s missing is something analogous to what the neighbour principle was for Lord Atkin: a synthetic, memorable, operational formulation capable of orienting fifty years of subsequent jurisprudence. Whoever writes that formulation will have done for the twenty-first century what the House of Lords did for the twentieth.

The problem is that for that formulation to be written, a category of intellectuals that essentially does not yet exist will be required. Pure lawyers won’t do, because the internal grammar of contemporary distributed systems isn’t taught in law schools. Pure engineers won’t do, because the grammar of law and its two-century history of categories and counter-categories isn’t taught in computer science.

What’s needed is hybrids — border figures who have practised both trades long enough to have grasped their internal logics and limits, and who are willing to imagine something neither disciplinary corpus, taken alone, can imagine. In Italy this figure does not yet have a settled name. In the anglosphere the roles of compliance engineer or technical counsel have emerged in recent years, but these remain professional labels that merely put the two cultures in contact without really building a third.

What’s needed is something more ambitious: a figure who doesn’t just translate technical jargon into legal jargon and vice versa, but who elaborates new categories capable of saying things neither of the two original jargons, left to itself, could say. The trade is partly theoretical, because it requires a philosophical training that lets you handle abstract categories, and partly practical, because it requires daily experience of deployment, transitive dependencies, backward compatibility broken by a vendor’s minor release, ambiguous stack traces that don’t say whose fault it is. Without practical experience, abstract categories hang in mid-air. Without abstract training, practical experience exhausts itself in fatigue and closed tickets.

The third way is hard — not because it requires rare talents, but because the labour market does not price it, universities do not train it, companies do not organise it. It exists only through individual will, and it is precisely for this reason that those who practise it carry intellectual responsibility disproportionate to their formal standing.

From Bill of Materials to Bill of Accountability

At this point it’s useful to come back to the concrete problem we started from: how can we attribute responsibility for harm caused by contemporary software?

If we accept that software is no longer a product but an assemblage, and that assemblage is to be analysed according to the gradient of effective influence, then the first operational step is to build a practice of documenting the assemblage — one that is not the static photograph of the SBOM but a dynamic map of relationships of influence.

Such a tool should make it possible, for any application, to answer questions like these.

• Which components, if modified, would change the system’s observable behaviour?
• Which actors have the technical capacity to modify those components?
• What contractual and regulatory obligations bear on each of those actors?
• What evidence, in logs and audit systems, lets us reconstruct ex post the state of the system at a specific moment?
• Through what channels can a downstream actor get an alarm signal to an upstream actor?
• What are the typical response times along the chain?

The resulting document would no longer be a bill of materials — it would be something closer to a bill of accountability, a map of powers and duties along the entire orchestration. Producing it would require work, would require cooperation between actors who don’t always have an interest in cooperating, would require rules that mandated its production. But it would be a tool that names the problem for what it is, rather than reducing it to an inventory problem.

Three consequences for software practice

From the standpoint of the daily practice of those who build software for clients, this re-articulation would have important consequences.

The first consequence is that the typical contract — the one that today tends to dump all liability on the final vendor or, at best, to cap it at the annual fee paid — would become a document with a completely different structure. The contract would be built downstream of an analysis of the orchestration, with a clear articulation of which components the vendor controls and which it merely integrates, which risks it fully assumes and which it passes through to upstream providers, which disclosure obligations it accepts to honour and which it is technically unable to honour. It would be a longer, more complex, more honest contract — and, over time, also a more defensible one in court, because it would tell the thing for what it is rather than pretending a shape it doesn’t have.

The second consequence is that the development process would have to include, from its earliest phases, a reflection on the orchestration in which the system will be embedded — not only a reflection on functional requirements.

• Who are the upstream actors we will depend on?
• What guarantees do they give us?
• What blast radius do they have in our regard?
• How will we verify their changes?
• How will we react if a change of theirs breaks our expected behaviour?

Today these questions are relegated to a few slides at the architecture stage and then forgotten. In a culture that took responsible assemblage seriously, they would be part of the specification, and their absence from project documentation would be a marker of immaturity the way the absence of a threat model is today.

The third consequence is perhaps the most interesting culturally, and it touches directly on how developers are trained. Today you learn to write code that works, then, if you’re lucky, to write code that works in production. Almost no one learns to write code that works within an orchestration they are aware of.

Orchestration awareness arrives late, usually through an incident, rarely as an explicit, taught competence. A training that took seriously the distributed nature of contemporary software would have to start here — it would have to show from day one that writing an API means entering an orchestration, that choosing a library means accepting an upstream vendor, that deploying to cloud means hosting yourself inside an infrastructure whose architectural decisions are elsewhere.

It’s not about terrifying young developers, it’s about getting them used to seeing what experienced developers see after twenty years of scars. Orchestration is the object of their work, not a background. The code they write is a participation in a concert, not a self-sufficient object. If they grow up with this awareness, the question of responsibility won’t arrive as an external annoyance — it will arrive as an intrinsic dimension of the craft.

When even the writing is orchestration

To anyone suspecting that all this is exaggerated by the SaaS lens, and that in simpler contexts the product category might still hold, it is worth answering that the direction AI-native development is moving makes the problem more acute, not less.

When you work with tools like Claude Code, or with practices like specification-driven development à la SpecKit, code stops being the object the developer writes directly and becomes the output of a generation chain that starts with a spec, passes through a model, produces an artefact, and integrates it into an orchestration that is already itself distributed. The spec written yesterday and the code generated yesterday, if regenerated today by the same model, would produce code plausibly similar but not identical, because the model has changed in the meantime.

The concept of version, already weakened by continuous deployment, becomes even more unstable in this context, because it is now unstable not only at execution time but at writing time too. Anyone developing this way knows that exact reproducibility is a regulative horizon, not an actual property of their artefacts.

Responsible assemblage, in a world where even writing code is an orchestration among developer, spec, model, toolchain, and pipeline, becomes the natural category for thinking about responsibility — because it is the only one in which the absence of a monolithic author does not automatically translate into the absence of imputability.

The death of a category

A question remains that the essay owes its answer, because it is the question a patient reader will have held in suspense from the start. The question is whether it really makes sense to speak of the death of a legal category, or whether we are just describing an evolution, a transformation, an update.

The language of death is strong, and might look exaggerated. The justification I offer is that a legal category dies in the sense Foucault meant when he spoke of categories more broadly — that is, when it stops organising the discursive field productively and starts obstructing it.

The concept of product, applied to contemporary software, no longer organises the field — it obstructs it. It produces compliance that doesn’t match practice, documents that don’t represent objects, litigation that gets stuck on the definition of the object before it can address the substance.

A concept that obstructs the field is not a useful concept, even if it remains formally in force. The concept of luminiferous ether, in late-nineteenth-century physics, wasn’t wrong the way singular claims can be wrong — it was a concept that had stopped organising the field productively and had started obstructing it, until Einstein simply removed it.

The concept of product, in contemporary software law, finds itself at a comparable stage. It is still there, still in the normative texts, still in courtrooms. But it is no longer working. And pretending it works is more dangerous than admitting it doesn’t.

I’m not saying, let me be clear, that the European legislator should have waited to have the right category before acting. That position would have been intellectually pure and politically unpresentable, and in any case the damage from the absence of regulation would have been greater than the damage from a categorially imperfect one.

I am saying, more modestly, that current regulation is a work in progress, that its categorical imperfection must be acknowledged openly, and that the construction of the replacement category is a task that falls not only to legislators but also to those who work in software every day and to those who have, from philosophy of law, the tools to think. Those with both feet inside can contribute more than those with only one. And the contribution is no academic exercise, because every year that goes by without the replacement category emerging is another year in which litigation resolves through formal paths that don’t mirror substantive responsibilities, another year in which upstream vendors keep transferring risk without paying for it, another year in which final deployers keep acting as fuses while the system as a whole does not improve.

Lord Atkin’s room

I have gone on at length, and those who have followed me this far deserve at least an honest summary of where we have arrived.

We have arrived at saying that the legal concept of product, built in the twentieth century on an ontology of bounded, preservable, identifiable objects, is insufficient for contemporary software, which is instead an orchestration of human and non-human components — a distributed event rather than an object, a concert rather than a record.

We have arrived at saying that European regulation, for all its being the most serious effort ever attempted, is trying to capture the concert with the categories of the record, and that this tension produces compliance whose substantive legal value is ambiguous.

We have arrived at saying that, in place of the category of product, we need to build a new one, provisionally called responsible assemblage, which distributes liability according to the gradient of effective influence at runtime rather than according to formal ownership or distributed irresponsibility.

We have arrived at saying that this construction requires a hybrid intellectual figure, with code practice and legal reading, that the market does not price and that exists only through the individual will of those who practise it.

And we have arrived at saying that, until the replacement category emerges, litigation will keep resolving through formal paths that don’t mirror substantive responsibilities, with real costs for those who do the craft honestly.

The point perhaps worth fixing, at the end of all this, is that Lord Atkin, in 1932, was not a pure jurist — he was a judge who had seen many bottles break and many people fall ill, and had understood something practical about the industrial world that the prior conceptual toolkit could not say.

Donoghue v. Stevenson was possible because someone had held together, in a single head, the material experience of the industrial world and the conceptual tradition of civil law. Today what is needed is to hold together, in a single head, the material experience of distributed systems and the conceptual tradition of liability law. It is not a task that can be delegated to anyone, and it is not even a task that can be completed in a single essay. What can be done, with an essay, is to try to name the problem, offer a direction, invite those with tools similar to mine to continue the work.

Mrs. Donoghue’s bottle was opaque, and inside it was a snail no one had seen. Contemporary software is even more opaque, and inside it are many more snails, and the case law that protects us was written for a world in which bottles were made of glass. The time has come to write the case law of a world in which there are no bottles left.

Inside there are three images that stuck with me. Aaron Levie says that in Silicon Valley nobody is working less—if anything, the opposite. Tyler Cowen, as an economist, argues that you should work much harder now , both if you think AI will devalue your work and if you think it will make it more valuable. And then there’s Simon Last from Notion talking about sleepless nights and a new anxiety, “token anxiety,” something that two years ago didn’t even exist as a concept.

The paradox swyx puts at the center is simple and, for that very reason, a bit unsettling. Agents do more work than ever, benchmarks saturate, models outperform human experts by percentages that until recently we would have called science fiction. And yet the people building and managing these systems have never worked this much.

And here a question lights up for me that I can’t easily turn off: if the promise was “more productivity,” why is the widespread feeling “more pressure”?

The convenient explanation: it’s just a phase

The most reasonable objection is also the one that comes to me naturally, if I try to be honest. Maybe it’s a transitional phase. The usual disruption dynamic: first it breaks things, then it recomposes them. We’ve already seen it with the personal computer, with the internet, with smartphones. Jobs change, some disappear, others are born, productivity grows, and in the end—at least for those who manage the transition well—average well-being improves.

It’s a serious objection. Ignoring it risks sliding into a kind of keyboard luddism, that thing where you convince yourself the problem is technology itself, rather than the way we’re inserting it into economic and social systems.

But there’s a point where this objection stops working. And that point, for me, is the body.

The body doesn’t scale

The problem isn’t just whether AI will replace knowledge workers or empower them. The problem is that the human body doesn’t scale.

It doesn’t scale the way tokens scale. It doesn’t scale the way a cluster of tens of gigawatts scales. It doesn’t scale the way a model’s learning curve scales when it gulps down an enormous amount of knowledge in weeks.

The body has a biological clock that doesn’t get reset with an update. It needs sleep, and if you take it away for months you might keep going anyway—at least on the surface—until the moment something breaks. And often it breaks in ways you didn’t anticipate and that aren’t so easy to reverse.

It needs movement, natural light, rhythms. It wasn’t designed for 3 a.m. spent debugging an agent that generated eight hundred lines of code that “work,” but that you don’t really understand.

These things aren’t new. Occupational medicine says them, neuroscience says them, any primary care doctor with a minimum of intellectual honesty says them. And yet, in the dominant discourse on AI, the body seems like an implementation detail. A legacy constraint to work around with enough caffeine and enough willpower.

Where I’m looking from

I’m a partner and technical lead at a small ICT company in Pescara. We’re about ten people. For a while now I haven’t been writing production code anymore, or at least not like before. My work has become research, strategic spikes, architecture evaluation, and also regulatory compliance, which is an unsexy word but a very real one.

I spend my days figuring out where the market is going and deciding what makes sense to do and what doesn’t, for a company that doesn’t have the luxury of an investment round to absorb mistakes. And that has direct responsibility for the people who work there—people who go home in the evening, who have families, bodies, limits.

From this position I see something that, maybe, when you’re inside the daily flow you have a harder time bringing into focus. AI hasn’t reduced anyone’s workload on my team. It has transformed it.

It shifted the weight from producing code to supervising code produced by others—where “others,” in this case, is a statistical model that doesn’t sleep, doesn’t get tired, doesn’t get sick. But it makes mistakes. And it makes them in creative, unpredictable ways.

And here there’s a detail that seems important to me, even if I still can’t explain well how important it is. Reading code written by an alien intelligence is a different job than writing it. It requires constant vigilance. It’s a form of attention that keeps you always a bit on alert.

And this alertness is incompatible with something that, in cognitive work, is almost a natural form of protection: flow, the state of deep focus where you aren’t fragmented, you aren’t continuously interrupted, you aren’t forced to make micro-judgments every thirty seconds.

Demand goes up, control goes down

There’s a concept in occupational medicine called “job strain,” in Karasek’s model. In very simple terms it describes the most toxic combination: high job demand and low control over your own activity.

Well, I have the impression that the massive introduction of AI agents is doing exactly this: it’s changing the relationship between demand and control.

Demand increases because, if the tools are faster, the expectation of output grows along with them. “If the agent can do it in an hour, why are we taking a day?” is a question that arrives almost automatically, often without malice, just out of inertia.

Control decreases because you delegate an increasing part of the process to systems you don’t fully understand and that change every few weeks. Even when you do understand them, you understand them in a different way than you understand a colleague or a traditional software component. It’s a more probabilistic, more fragile understanding.

In this sense “token anxiety” doesn’t seem to me like a linguistic fad. It seems like a symptom. Anxiety, after all, is an adaptive function. If it shows up at industrial scale, maybe it’s not an individual problem. Maybe it’s a system signal.

“If we slow down, China won’t slow down”

At this point another objection almost always comes up, and this one too has a core of truth. If we slow down, others won’t. If we set limits, others push. And in a global race, whoever gets there first wins.

But I wonder whether there isn’t a category error hidden inside that sentence.

Competition between nations and between companies is competition between systems, not between individuals. A system that burns the people who make it up is not a competitive system. It’s a system that is consuming its most precious capital—namely the intelligence and creativity of human beings who function well only when they’re healthy, rested, and motivated by something other than fear.

The history of software is full of companies that “won” in the short term with crunch and lost in the medium term. Because the best people leave, or get sick, or simply stop having ideas. An exhausted brain isn’t an engine to squeeze—it’s an ecosystem that collapses.

Maybe the first problem is inside the chest

If the point isn’t only the race for benchmarks, then what is the first problem?

I believe it’s right under our nose—actually, inside our chest. The most valuable problem is figuring out how to integrate tools of extraordinary power into working life without working life devouring life.

It’s not a technical problem, or at least it’s not only a technical problem. It’s a problem of organizational design, managerial culture, labor policy. And in the end it’s also a philosophical problem, because it forces you to decide what is worth doing with the time we have. Which is finite in a way no technology can change.

Something personal, but it weighs

I have a son. It’s not a logical argument, it’s a biographical fact. But biographical facts, sometimes, weigh more than arguments.

When in the evening I close the laptop and look at him, I think that all the code written during the day—even the code “multiplied” by agents—is not worth an hour of that time. Not because work doesn’t matter. It matters a lot. But because that time is unrecoverable in a way code is not.

Code can be rewritten. A childhood can’t.

I know that in certain environments this sounds like weakness. Like a lack of ambition. Like sentimentality that won’t survive the next market evaluation. But maybe it’s the opposite. Maybe the real ambition is to build systems, companies, and lives that last.

And lasting requires taking care of the medium through which everything else happens. The human body, with its non-negotiable need for rest, relationship, and time that isn’t measured in tokens per second.

The alignment we’re not looking at

The AI industry loves to talk about alignment, about how to make models do what we want.

But I wonder if the first alignment problem doesn’t concern the models. It concerns us.

We’re building an economy of attention and productivity in which incentives are often misaligned with what we know is necessary for human health. We sleep little, we move little, we pause little. And then we try to compensate with technology—with meditation apps, sleep trackers, supplements.

It’s as if we created a productive system that no longer produces well-being as a side effect of work, and then we’re surprised an industry of well-being pops up to repair the damage.

A direction, not a solution

I don’t have a clean solution, and I distrust those who offer one. But I do have a direction.

Take seriously that human health and human time are the primary constraint. Not model efficiency, not deployment speed, not the number of lines of code generated in an hour.

Every organizational decision, every sprint planning, every system architecture should also be evaluated with a very concrete question: how much life does it cost?

And if the answer is “too much,” then maybe it’s not the right problem. Or it’s not the right time. Or it’s not the right way.

This doesn’t mean “working less” in the banal sense of the term. It means working knowing that the most sophisticated system in the known universe isn’t an llm. It’s the human brain that designed it. And that brain works according to rules we didn’t write and can’t rewrite at will.

That last gasp, maybe, isn’t humanity’s last gasp. Maybe it’s the last gasp of a way of working that treats people as fungible resources inside an optimization pipeline.

If that’s the case, maybe we shouldn’t try to prolong it. Maybe we should let it go and learn to breathe in a different way. A way that takes into account that we’re made of flesh, time, and relationships. And that no agent, however powerful, will ever be able to live in our place.

The idea is elegant, and the science behind it is solid. A recent article by Brandon Janes on Towards Data Science, titled “Behavior is the New Credential,” describes how behavioral biometrics systems are becoming standard practice in banking. The starting point is a 2012 study from U.C. Berkeley called “Touchalytics,” which demonstrated that just eleven scroll strokes on a smartphone were enough to identify a specific user within a group of forty-one people, with zero errors. Thirty unique behavioral features: stroke length, velocity, curvature, trajectory, inter-stroke time, even the area of the finger used turned out to be individually distinctive.

The underlying theory is computational motor control, an interdisciplinary field bridging neuroscience, biomechanics, and computer science. The unconscious corrections our brain performs during every gesture, those micro-adjustments happening at the millisecond scale, are so individual that a person’s behavioral profile becomes nearly impossible to replicate. Paradoxically, what we think of as “robotic” (these automatic neural corrections) is exactly what makes each of us irreproducibly human.

Why the old defenses are no longer enough

The context driving this transition is concrete and well documented. Modern malware has reached capabilities that render traditional verification mechanisms obsolete. Tools like ProKYC, a deepfake tool used in the cybercrime world, allow threat actors to bypass two-factor authentication, facial recognition, and even live video verification checks. BingoMod, a remote access trojan distributed via SMS phishing, masquerades as an antivirus app on Android and allows a remote attacker to intercept credentials, messages, and OTP codes, all the way to executing money transfers from the infected device.

Once the device is compromised, everything looks normal from the bank’s perspective: the device fingerprint is correct, the IP address checks out, MFA codes align. Traditional verification, which operates at a single point in time (the login), is no longer sufficient. The security perimeter is no longer the gate. It’s the entire session.

This is where behavioral biometrics enters, operating as continuous authentication. Anomaly detection models built on each user’s specific profile monitor the session from start to finish. When risk signals spike, the system can request additional verification or halt the transaction entirely. When behavior matches the established profile, the session continues seamlessly. The result, ironically, is a better user experience: fewer OTPs, fewer interruptions, more fluidity. Passive security replacing active security.

The other side of the coin

So far, this is the cybersecurity industry’s narrative. It works, it’s technically sound, and it’s operationally effective. But it’s also a narrative that systematically avoids a question: what does it mean, from a fundamental rights perspective, to turn human behavior into a credential?

Let’s start with a regulatory fact that Janes’s article doesn’t mention. The GDPR, in Article 4(14), defines biometric data as “personal data resulting from specific technical processing relating to the physical, physiological or behavioral characteristics of a natural person, which allow or confirm the unique identification of that natural person.” The key word is “behavioral.” The European legislator explicitly included behavioral data in the definition of biometric data. Article 9 then classifies biometric data as a “special category” of personal data, whose processing is generally prohibited except under specific conditions: explicit consent, substantial public interest, protection of vital interests.

This means that every behavioral biometrics system operating in the European Union is processing special category data. Not generic personal data. Data that requires explicit consent, a Data Protection Impact Assessment (DPIA), purpose limitation, data minimization, and the right to erasure.

The question no cybersecurity vendor likes to face is: how do you reconcile the right to erasure with a behavioral profile built through continuous analysis of thousands of micro-interactions? You can delete a profile, certainly. But can you delete the knowledge derived from that profile, once it has been used to train a model? The GDPR raises specific questions about data minimization and purpose limitation when data has been used for AI model training.

The AI Act’s double bind

The picture gets more complex with the AI Act, whose regulatory framework for high-risk systems fully applies from August 2026. The intersection of GDPR and AI Act creates a layered regulatory framework for biometric technologies.

The AI Act distinguishes between several types of biometric systems. Real-time remote biometric identification systems are prohibited for law enforcement, with narrow exceptions. All other remote biometric identification systems are classified as high-risk. Biometric categorization systems that infer sensitive attributes (race, political opinions, trade union membership, sexual orientation) are prohibited. Emotion recognition systems are banned in workplaces and schools, and classified as high-risk in other contexts.

Where does banking behavioral biometrics fall in this taxonomy? The AI Act explicitly excludes from the definition of remote biometric identification those verification tools that confirm a person is who they claim to be, provided they require the individual’s active participation. But behavioral biometrics, by definition, is passive. The user does not “actively participate” in their own behavioral authentication. The system observes them while they do something else. This grey zone between active verification and passive surveillance is precisely the territory where fundamental rights start to strain.

There’s an additional element. The AI Act prohibits AI systems that classify people based on their social behavior when such classification leads to unfavorable treatment in contexts unrelated to the original data collection context, or treatment disproportionate to the gravity of the behavior. The line between “behavioral authentication for fraud prevention” and “behavioral profiling for user classification” is not as sharp as the industry would like to believe.

Function creep: the structural risk

The history of technology teaches us that systems built for a specific purpose tend to expand their scope over time. This phenomenon, known as function creep, is particularly insidious in the field of behavioral biometrics.

A system that today analyzes how you scroll a page to verify you are who you claim to be could tomorrow use the same data to infer your emotional state, your attention level, your cognitive condition, your appetite for financial risk. Behavioral data is extraordinarily rich in implicit information. Your typing rhythm can reveal anxiety or fatigue. Your scrolling speed can indicate interest or boredom. Your touch pressure can suggest irritation or calm.

Banks using this data for fraud prevention today are sitting on an informational asset whose potential value vastly exceeds transaction security. The temptation to monetize this data, or to repurpose it for commercial goals (service personalization, credit scoring, insurance product profiling), is an economic force that internal policies alone will struggle to contain over the long term.

In Australia, a biometric database originally designed to prevent cross-border criminal activity was later used to identify individuals who had lost their documents in bushfires. In that case, the expanded use was well-intentioned. But the precedent was set: once the data exists and the system is operational, purposes expand.

The informatized body

There’s a deeper dimension here, one that goes beyond law and touches the anthropology of technology. Behavioral biometrics transforms the way we interact with our devices into a permanent identification datum. The U.S. National Research Council has described this process as the creation of an “informatized body”: a body no longer represented by anatomical features observable to the human eye, but by digital information about the body stored in databases.

When your way of scrolling a page becomes a credential, your unconscious gesture becomes a data point. The spontaneity of your movement is captured, analyzed, modeled, stored. You are not actively providing information, as you do when typing a password. You are simply existing, and the system extracts value from your ordinary existence.

Shoshana Zuboff described this dynamic as the fundamental characteristic of surveillance capitalism: the appropriation of personal experience and its transformation into behavioral data, subsequently used to predict and modify behavior itself. Behavioral biometrics for cybersecurity is, in a sense, the “good” version of this mechanism. But the mechanism is the same. And the distance between the good version and the less good ones is only a matter of declared purposes, which can change.

The asymmetry of consent

A particularly problematic aspect concerns the nature of consent in these systems. The GDPR requires consent to be “freely given, specific, informed and unambiguous,” with an even higher bar when special categories of data are involved. But how can consent to a behavioral biometrics system in your banking app be genuinely free when the alternative is not being able to access your bank account?

European data protection authorities have already addressed this question in analogous contexts. The Dutch DPA fined a company €725,000 because employees perceived fingerprint scanning as an obligation, rendering consent unfree. The Swedish DPA sanctioned a school for using facial recognition to track attendance, citing the power imbalance between the institution and the students.

In the case of banking behavioral biometrics, the imbalance is analogous. Banking services are not optional in contemporary society. If your bank implements behavioral authentication, you have no real alternative to consent. The dynamic resembles an imposed condition more than an informed choice.

The irrevocability paradox

Unlike a compromised password, which can be changed in seconds, a compromised behavioral profile presents a structural problem: you cannot change how you scroll a page or type on a keyboard with the same ease with which you change a string of characters. Your behavioral patterns are intrinsically tied to your physiology and neurology. They are, in a very concrete sense, you.

This introduces a long-term risk that the industry tends to downplay. If a database of behavioral profiles is breached, the exfiltrated data doesn’t become obsolete through credential rotation. It remains usable for as long as the individual’s biometric characteristics don’t change significantly, which in most cases happens only through aging or following traumatic events.

Vendors of these systems emphasize that profiles are typically processed locally and that only a risk score is transmitted, not raw data. That’s a real mitigation, but it doesn’t eliminate the fundamental problem: somewhere, in some form, a representation of your unconscious behavior exists as digital data.

Algorithmic discrimination and behavioral bias

A further critical aspect concerns the discriminatory potential of behavioral biometrics systems. Device interaction patterns are not universal. They vary by age, physical condition, motor disabilities, cultural differences in technology use, and the type of device being used.

An elderly user with arthritic hands will have significantly different scroll and typing patterns from a twenty-year-old. A user with a budget smartphone will produce different sensor data from someone with the latest flagship. A user who alternates between left and right hands, or who uses assistive technologies, will generate atypical profiles.

If the anomaly detection model was trained predominantly on profiles of able-bodied, middle-demographic users, those who deviate from this average profile will be subjected more frequently to additional verification, session blocks, and step-up authentication requests. In other words, the “passive” security that the industry advertises as a better user experience could translate into a systematically worse experience for the most vulnerable categories.

The European Accessibility Act (EAA), fully applicable since June 2025, requires digital products and services to be accessible to people with disabilities. A behavioral authentication system that systematically penalizes users with motor or cognitive disabilities raises compliance questions not only under the GDPR and the AI Act, but also under accessibility regulation.

The duty to look beyond the technical solution

Nothing written above means behavioral biometrics is a bad idea. The cybersecurity problem is real, losses are enormous (the FBI Internet Crime Report documents billions of dollars in annual losses), and traditional defenses are genuinely inadequate against current threats. Continuous authentication is probably the future of digital security.

But the way the industry tells this story is incomplete in a manner that is not accidental. Janes’s article, like most of the technical literature on the subject, presents behavioral biometrics exclusively from the standpoint of operational effectiveness. The subtext is: it works better, it’s more secure, the user experience improves. All true. But not the whole truth.

For those of us working in European ICT, the responsibility is twofold. On one hand, implementing these technologies where they are needed and where they create real value. On the other, doing so with a regulatory and ethical awareness that the American market, from which most of the innovation in this field originates, does not have the same urgency to develop.

Europe, with its layered regulatory framework (GDPR, AI Act, EAA, NIS2), is not making life difficult for those who work with technology. It is asking the questions that the market, left to its own devices, does not ask. Questions like: who owns the way you move your finger across a screen? What rights do you have over an unconscious gesture turned into data? What happens when your informatized body becomes a commodity?

These are uncomfortable questions. But the moment behavior becomes a credential, we don’t have the luxury of ignoring them.

There’s a document you should read. It’s not long, it’s not hidden, it doesn’t require any special legal expertise to understand. It lives at microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse, it was updated on October 24, 2025, and it contains a sentence that deserves to be taken seriously. The sentence is in the section titled, in uppercase and bold, “IMPORTANT DISCLOSURES & WARNINGS”, and it says: Copilot is to be considered solely for entertainment purposes. It may make mistakes and may not work as expected. Do not rely on Copilot for important advice. Use Copilot at your own risk.

If that sounds like the kind of clause you’d find in a meme generator app, I get it. But we’re talking about the product Microsoft has integrated into Windows 11, into Excel, into PowerPoint, into Teams, into Outlook, into the beating heart of the suite that over 430 million people use every day. We’re talking about the product for which Microsoft committed about eighty billion dollars in AI capital expenditure in fiscal year 2025 alone, across data centers, infrastructure, and compute capacity, on top of the roughly thirteen billion invested cumulatively in OpenAI, whose technology powers the underlying models. We’re talking about the product sold to large enterprises at thirty dollars per user per month, and to small and medium businesses at twenty-one (cut to eighteen with first-half 2026 promotions). The Terms of Use for this product say it’s a toy.

Microsoft’s reaction, when the clause started circulating on social media in the first days of April 2026, was predictably mechanical. A spokesperson told PCMag that it’s “legacy language” that “no longer reflects the product’s current use” and that it “will be revised with the next update.” No date. No binding commitment. No explanation for why language that doesn’t reflect the reality of the product stayed in legal documents for months after the last update, in plain sight of the same legal team that wrote it. The spokesperson spoke as if someone had forgotten to take down a sign from a closed construction site. But closed construction sites don’t bill thirty dollars per seat per month.

It’s tempting to dismiss this as a legal department gaffe. It isn’t. Terms of Use aren’t written by accident. They’re written by teams of lawyers who weigh every word knowing those words will be used in court. The word “entertainment” isn’t a lazy synonym for “experimental” or “beta.” Entertainment has a precise legal meaning in Anglo-Saxon law: it’s the category that protects those who produce content that is explicitly non-factual, like games, fiction, simulations. Saying a product is “for entertainment purposes only” means saying that no reasonable user should expect its answers to be accurate, reliable, or fit for any practical purpose.

You could argue the numbers tell a different story. That Copilot adoption has been slower than expected. That Microsoft itself knows the product has problems. And you’d be right. By the second quarter of fiscal year 2026, only fifteen million seats out of four hundred and fifty million paid commercial seats were subscribed to Microsoft 365 Copilot: 3.3 percent. The US market share of paying subscribers contracted by 39 percent in six months, going from 18.8 percent in July 2025 to 11.5 percent in January 2026. Net Promoter Score on answer accuracy worsened from minus 3.5 to minus 24.1 between July and September 2025, according to Recon Analytics. 44.2 percent of users who abandon Copilot cite distrust in the answers as the main reason. When workers can freely choose between Copilot, ChatGPT, and Gemini, only 8 percent choose Microsoft’s product.

These numbers don’t soften the problem. They make it worse. They show Microsoft knows perfectly well the product isn’t reliable, says so in legal documents, and keeps selling it as an enterprise productivity tool. Satya Nadella called Copilot “a true daily habit” in front of investors. Marketing presents it as the assistant that transforms the way you work. The Terms of Use say it’s a toy. That’s not a contradiction. It’s a strategy.

II. The disclaimer chorus

It would be intellectually dishonest to present Microsoft’s clause as an anomaly. It isn’t. It’s the loudest case of a pattern that runs through the entire AI industry, and it’s worth mapping precisely.

OpenAI, in its Terms of Use, warns users not to rely on outputs as the sole source of truth or factual information, and caps its aggregate liability at one hundred dollars or the amount paid in the previous twelve months. Google, in Gemini’s terms, says not to rely on the services for medical, mental health, legal, financial, or other professional advice. xAI, Elon Musk’s company, warns that its AI is “probabilistic by nature” and can produce incorrect outputs. None of these companies, it should be said, has gone as far as the formula “for entertainment purposes only.” That one remains a Microsoft exclusive.

The difference between Microsoft and the others, though, isn’t substantive. It’s tonal. All major AI providers are doing the same thing: building a legal wall between the product they sell and the consequences of using it. They do it knowing their models can and do produce false, misleading, potentially harmful outputs. In August 2024, Copilot falsely identified German journalist Martin Bernklau as a convicted pedophile and a fraudster, also providing his home address. Microsoft blocked queries about Bernklau only after a data protection complaint. These aren’t edge cases. They’re the ordinary operation of a probabilistic system marketed as if it were deterministic.

And in court, disclaimers work. On May 19, 2025, the Superior Court of Gwinnett County, Georgia, issued a summary judgment in favor of OpenAI in Walters v. OpenAI (23-A-04860-2). Radio host Mark Walters sued OpenAI after ChatGPT, at a journalist’s request, generated a false summary of a lawsuit in which Walters was described as accused of embezzlement against the Second Amendment Foundation. The court dismissed the claim on three independent grounds: the statements could not reasonably be understood as actual facts (also because ChatGPT had warned the journalist about its limitations and the ToS contained explicit disclaimers about the possibility of errors); Walters had shown neither negligence nor malice by OpenAI; and Walters himself admitted he suffered no damages. An outcome supported by multiple legs, then, not just disclaimers. But disclaimers mattered, and they matter. The court explicitly recognized that repeated warnings about the possibility of “hallucination” helped make any expectation of factual accuracy by the user unreasonable.

This is where many commentators stop, outraged. But this is where the conversation needs to get more precise, because not all disclaimers are the same, not all serve the same purpose, and not all are, in themselves, a bad thing.

The European AI Act, Regulation 2024/1689, explicitly requires providers of AI systems to communicate the limitations of their products. Article 13 provides that high-risk AI systems be designed with sufficient transparency to enable deployers to interpret outputs and use them appropriately, and that they be accompanied by instructions for use with concise, complete, correct, and clear information on characteristics, capabilities, and performance limitations. Article 14 imposes effective human oversight, and requires that the people tasked with oversight be put in a position to remain aware of the possible tendency to automatically or excessively rely on outputs—what the Regulation calls “automation bias.” Article 50 requires that users be informed when they are interacting with an AI system, and that generated content be labeled as such.

Saying “this AI system can be wrong, always verify, don’t blindly trust it” isn’t just legitimate, then. It’s a regulatory obligation. Europe has established that transparency about AI system limitations is a pillar of safety and trust. The user must know what they’re interacting with, what the risks are, and must be able to decide to ignore or override any system output. This is the framework any serious company should follow.

But one thing is saying “this system has these limitations; here’s how to supervise it to use it safely.” Another is saying “this is a toy for entertainment; use it at your own risk; we guarantee nothing.” The first formulation is transparency. Compliance with the AI Act. An act of responsibility that puts the deployer in a position to do their job. The second formulation is a liability dump dressed up as transparency. It doesn’t put the user in a position to use the system appropriately: it puts them in a position where they can’t seek recourse when things go wrong.

The AI Act asks the provider to declare limitations to enable safe use. Microsoft’s ToS declare limitations to prevent any recourse. One serves the user. The other serves the legal department. And when a US court looks favorably on a provider’s disclaimers in dismissing a defamation claim, it isn’t necessarily rewarding transparency. It’s acknowledging the legalese.

III. The Directive that changes everything (and the blind spot)

By December 9, 2026, EU Member States must transpose Directive 2024/2853, the new Product Liability Directive, into national law. It’s the first update in forty years to Europe’s defective product liability regime. For companies that produce, integrate, or distribute software and AI systems, the consequences are profound.

The Directive first redefines what a “product” is. The old 1985 directive was designed for a world of physical objects: cars, appliances, toys. The new one explicitly includes software, regardless of the mode of supply or use, whether embedded, standalone, cloud, or SaaS. It includes firmware, operating systems, applications. The Recitals clarify that AI systems also fall within the definition. Software is no longer a service that slips out of product liability. It’s a product. As such it is subject to strict liability: you don’t need to prove the producer’s fault. You just need to show the product was defective and that the defect caused damage.

Then there’s the question of exemption clauses. Article 10 provides that Member States ensure that an economic operator’s liability under the Directive is not, vis-à-vis the injured person, limited or excluded by a contractual provision or by national law. The wording leaves no ambiguity. Disclaimers in Terms of Use, limitation-of-liability clauses, “as is” formulations, and “for entertainment purposes only”: the moment a European consumer suffers harm from a defective product, they’re worth nothing.

This needs to be understood in its transatlantic scope. The clause “Copilot is for entertainment purposes only” will keep working in the United States, where Walters v. OpenAI confirmed that courts take disclaimers seriously. In Europe, after the Directive is transposed, that same clause becomes unenforceable. If Copilot generates a defective output that causes harm to a natural person (death, personal injury, medically recognized psychological harm, destruction or corruption of non-professional data, damage to private property), the provider is liable. Regardless of what the ToS say.

The Directive also rewrites the rules on the burden of proof, and this is where things get complicated. It introduces presumptions in favor of the injured person. If the defendant does not disclose relevant information, defectiveness is presumed. If the product does not comply with mandatory requirements of national or EU law, defectiveness is presumed. If there is an obvious malfunction during reasonably foreseeable use, same. If the injured person faces “excessive difficulties” in proving the defect due to the technical or scientific complexity of the product, courts may presume both defectiveness and causation. For AI systems, where opacity of internal functioning is structural rather than accidental, this presumption will be the norm. The injured person won’t have to explain how the model that generated the false output works. They’ll have to show the output was defective and that the damage followed.

The PLD interlocks with the entire European regulatory framework. Non-compliance with the Cyber Resilience Act requirements (security-by-design obligations, vulnerability handling, security updates) can constitute a presumption of defectiveness. The same goes for failure to meet NIS2 obligations. And the same goes, implicitly, for AI Act requirements: an AI system that doesn’t meet transparency, human oversight, accuracy, and robustness obligations is a system that doesn’t meet mandatory requirements of EU law, and therefore a system for which the PLD may presume defectiveness.

The short circuit is visible to the naked eye. The AI Act asks providers to declare their systems’ limitations to enable safe use. The PLD says that if the product causes harm, the provider is liable regardless of disclaimers. The provider is required to inform that the system can be wrong, and at the same time cannot use that information to escape liability when the system is in fact wrong. It’s a coherent regime, designed to protect the consumer. But it creates an extremely strong tension between the duty of transparency and the impossibility of using transparency as a shield.

For Microsoft, this tension is manageable. For those in the middle of the chain, it’s potentially lethal.

IV. Whoever modifies it, pays: the integrator as a structural scapegoat

The PLD doesn’t just say the software producer is liable. It expands the chain of potentially liable economic operators with a cascading logic designed to ensure that the European consumer always has a reachable counterpart in the EU. If the manufacturer is outside the EU, the importer is liable. If there is no identifiable importer, the authorized representative is liable. Then the fulfilment service provider. Then the distributor, if it fails to identify the relevant operator in the chain within one month of the injured person’s request. Liability is joint and several: multiple operators liable for the same damage are liable together, each for the whole.

So far the system seems reasonable. But there’s a figure in the chain that the PLD treats with particular harshness and that is crucial to understanding the practical implications of the “entertainment only” clause: anyone who substantially modifies a product after it has been placed on the market is considered a manufacturer of the modified product and is liable to the extent that the defect results from the modification. The Recitals clarify that a substantial modification may also result from a software update, an upgrade, or the continuous learning of an AI system. The product as modified is considered placed on the market at the moment the modification is actually performed.

Think about what happens in the real world. A system integrator, a software house, an IT consultant takes Copilot and integrates it into a corporate workflow. They configure prompts, connect the client’s data sources, customize responses, automate flows. Are they substantially modifying the product? Under the PLD, very likely yes. The moment you take a general-purpose AI model and specialize it for a specific context, you’re creating a product different from the original. If that modified product generates a defective output that causes harm, the integrator is liable as a manufacturer.

Article 12 of the PLD provides a specific protection for micro and small enterprises that produce defective software integrated into someone else’s product. These enterprises can contractually agree with the manufacturer of the final product on an arrangement that protects them from recourse actions. But this protection has two limits that drastically reduce its usefulness. First: it does not in any case protect the micro or small enterprise from a direct action by the consumer. The consumer can always sue the integrator directly, and the integrator is liable. Second: protection against recourse actions requires a contractual agreement with the product’s manufacturer. Microsoft has no obligation and no incentive to grant this kind of agreement to system integrators who use Copilot. Its ToS already say the product is “for entertainment purposes only” and that the user is “solely responsible” for any action taken based on outputs. In a potential recourse action, Microsoft will be able to say: we warned you. You chose to integrate it into a professional product. It’s not our fault if you sold it to a client as a reliable tool when we ourselves told you it was a toy.

The PLD prevents pushing liability downward in the chain—toward the consumer—via contractual clauses. But it doesn’t prevent big players from refusing to grant contractual protections upward, in the relationship between integrator and manufacturer. The result is that the integrator is exposed to the consumer without being able to protect itself contractually, and has no guarantee of being able to effectively seek recourse against Microsoft. Microsoft has the legal teams, the authorized representatives in every Member State, the financial mass to absorb litigation. The ten-person integrator in Pescara, in Brno, in Lisbon doesn’t.

The obvious objection is that the integrator can and must implement the human oversight required by the AI Act. Set up verification processes, user training, output supervision. And it’s true: the responsible integrator will do it, and will have to do it for its own obligations as a deployer under the AI Act. But the PLD doesn’t ask whether you did your best. The PLD asks whether the product was defective and whether the defect caused damage. A false output generated by an AI system integrated into a professional workflow that causes harm to a natural person is a defective product, regardless of how many layers of human oversight the integrator implemented. You can do everything right and still be liable.

Think about what happens when an AI system integrated into management software generates an incorrect financial report that leads to a bad investment decision. Or when an AI assistant integrated into a CRM generates a defamatory communication about a customer. Or when an analysis system integrated into a healthcare platform provides an incorrect indication that influences a diagnostic pathway. In all these cases, under the PLD, the injured person can act against the integrator. The integrator is there, in the EU, reachable, has a tax ID and a bank account. Microsoft is in Redmond. And in its ToS it says Copilot is for entertainment.

V. The bill—and who pays it

There’s a moment in the history of tech regulation when it becomes clear the rules were written for a world that no longer exists. The old 1985 Product Liability Directive was designed for a world where products were physical objects made by identifiable companies, sold through linear distribution chains, and used by consumers who could reasonably assess their safety. The new PLD is a necessary and in many ways admirable update: it extends protection to software, lowers barriers for consumers, introduces presumptions that rebalance information asymmetry. But the world it regulates isn’t made of linear chains. It’s made of stacked layers, of APIs calling APIs, of probabilistic models whose internal functioning isn’t understandable even to those who built them.

The logical architecture of the European regulatory framework is the most advanced in the world. The AI Act sets obligations for transparency, human oversight, risk management. The Cyber Resilience Act imposes security-by-design and continuous security updates. NIS2 extends cybersecurity to critical sectors. The PLD closes the circle by establishing that whoever violates these obligations and causes harm pays. The objection isn’t to the framework’s logic. The objection is to the practical distribution of consequences.

In reality, consequences follow a law of economic gravity that no directive can reverse: they fall downward. Toward those with fewer legal resources, less financial mass, less ability to absorb litigation. Microsoft, Google, OpenAI each have hundreds of lawyers, authorized representatives in every jurisdiction, legal budgets that exceed the revenue of entire SME supply chains. They have written ToS that, even if ineffective under the PLD vis-à-vis the consumer, remain fully operational as an argument in recourse actions between economic operators. They’ve classified their products as “entertainment,” “probabilistic,” “not a source of truth” with surgical precision, knowing what function each word would serve in a future proceeding.

The PLD presents the bill, but who pays it? The ten-person system integrator who took Copilot, integrated it into the client’s management system, did training, implemented human oversight, and discovers that when the defective output causes harm, they are the reachable, identifiable, sue-able party. The provider is on the other side of the ocean, or in any case protected by B2B contractual clauses, arbitrations in Dublin, and limitations of liability between economic operators that the PLD doesn’t touch because they concern relationships between professionals and not the consumer’s direct protection.

It would be wrong to say the PLD is a mistake. The PLD is incomplete. Its incompleteness produces a regressive effect that rewards those with the resources to navigate the system and penalizes those who don’t. Article 12 recognizes the problem for micro and small enterprises, but solves it in a circular way: we protect you from recourse if you have a contractual agreement with the manufacturer. But the manufacturer has no obligation to grant you that agreement. And if its ToS say “entertainment only,” its incentive to grant it is actually negative: that agreement would implicitly admit the product has a professional use, contradicting its legal shield.

There’s a further paradox. The companies that take compliance most seriously, that implement human oversight, that inform their customers, that document processes, are also the ones that leave the richest documentary trail for a liability action. Whoever integrates Copilot sloppily, without processes, without documentation, without oversight, is paradoxically harder to hit because they leave less evidence of a structured relationship with the product. The PLD, in its attempt to protect the consumer, risks creating an incentive toward superficiality: those who do things well are more exposed than those who do them badly.

The time dimension also matters. The PLD applies to products placed on the market or put into service after transposition. But AI systems aren’t static products. They’re updated continuously. Models change. Outputs change. An AI system that works one way today might work in a completely different way six months from now after an update to the underlying model. Every substantial update, according to the PLD Recitals, puts the product back on the market. The integrator who built a workflow based on Copilot in 2025 could find themselves, after a model update in 2027, with a substantially different product producing different outputs, without having any control over the change and with full liability for its effects.

I don’t have a neat solution for all of this. But anyone working in this sector should start reading their AI providers’ ToS not to get outraged, but to understand exactly what the provider refuses to guarantee—because that list is the map of the residual risk that remains on the integrator’s shoulders. They should negotiate specific contractual agreements on product liability before the PLD is transposed, because after that bargaining power will be even lower. They should document every human oversight process, every risk assessment, every customer disclosure, not because this eliminates liability under the PLD but because in a recourse action against the provider documentation is the only weapon available. And they should seriously ask whether integrating third-party AI systems into professional products is sustainable from an insurance standpoint, because today most professional liability policies don’t cover damages from AI outputs, and tomorrow that coverage will be necessary.

When Microsoft writes “for entertainment purposes only,” it isn’t stammering. It’s speaking clearly and deliberately. It’s saying that liability for any professional use of its product isn’t theirs. It’s saying that whoever takes that product and sells it as a reliable tool does so entirely at their own risk. Europe has built a regulatory framework that in theory holds everyone accountable. In practice, it holds accountable those who can least afford it. The provider that wrote “for entertainment purposes only” knowing perfectly well no one would read it, that collected thirty dollars per seat per month knowing perfectly well its product wasn’t reliable—that provider still has its lawyers, its clauses, its international arbitrations. The next time someone asks it to account for what it sold, it will point again to the Terms of Use. It’s all written there. You just have to read.

This isn’t a criticism. It’s an observation about a structural blind spot in the IT advisory market. The people who advise companies on how to buy technology, in the vast majority of cases, have never sold technology. And the people who sell and deliver technology have no voice in how the advisory market defines sourcing best practices. The result is an information gap that costs real money to both buyers and sellers.

I say this with firsthand knowledge. I run a small ICT company that lives on contracts with mid-market and public administration customers. I’ve written quotes, negotiated contracts, defined SLAs, managed escalations, taken penalties, delivered projects late and projects early. I’ve seen the IT services market from the side of the table that sourcing analysts rarely see. And what I see doesn’t always match what advisory frameworks describe.

First Blind Spot: Pricing

Most advisory frameworks evaluate IT vendors based on cost per person-day or cost per function point. They’re understandable, comparable metrics, and fundamentally obsolete. The problem is that AI is making the relationship between work time and delivered value completely non-linear. A five-person team using agentic coding can deliver in a week what a fifteen-person team used to deliver in a month. The value to the customer is identical. The cost in person-days is one fifth. If the customer pays by person-day, the vendor has a perverse incentive not to adopt AI, because they bill less. If the vendor adopts AI and the customer keeps evaluating by person-days, the vendor looks five times more expensive per day even if the total project cost is lower.

This isn’t a theoretical problem. It’s a problem I face every month when I present quotes. I stopped quoting by person-day more than a year ago. I quote by deliverable: this is the outcome, this is the price, these are the conditions. Some customers appreciate it. Others—especially in the public sector, where tenders are structured around person-days—don’t know how to handle it. The purchasing framework doesn’t account for a vendor that delivers more value in less time.

Second Blind Spot: Compliance as a Sourcing Criterion

Advisory frameworks are starting to add regulatory compliance as a vendor evaluation criterion. But they add it as a checkbox: “Is the vendor GDPR compliant? Yes/No.” That’s radically insufficient. Compliance isn’t a binary property. It’s a spectrum. A vendor can have a privacy policy on their website and have no technical mechanism for data minimization in the code. They can claim to be AI Act compliant without having any idea what a risk assessment for high-risk AI systems is. They can tick the SBOM box without having a pipeline that generates SBOM automatically on every build.

A serious sourcing framework, in today’s European regulatory context, should evaluate compliance not as a statement but as a technical capability. Does the vendor have a documented vulnerability handling process? Does their CI/CD pipeline include dependency scanning? Are their SBOM generated automatically or compiled by hand? Does their software have automated tests that verify privacy properties? These questions are more revealing than any certification. And they’re questions that only someone with operational delivery experience knows how to ask.

Third Blind Spot: IT SMEs

The advisory market is built around the big system integrators. The evaluation matrices, the Magic Quadrant, the Wave, the Provider Lens—all of these tools are calibrated for companies with hundreds of millions in revenue. IT SMEs—which in Europe represent the vast majority of software services providers—are invisible in these frameworks. Not because they don’t deliver value, but because they don’t have the scale to participate in analysts’ evaluation processes.

This creates a paradox. The mid-market customer—the 200–500 employee company, the ASL, the Municipality, the Chamber of Commerce—reads analyst reports and sees only big names. But the big names don’t serve the Italian mid-market, or they serve it with junior teams overseen by a partner you never actually see. The vendor that actually delivers the work—the local SME with ten people, a senior per project, and a direct relationship with the decision-maker—doesn’t appear in any framework. The information gap is total.

Fourth Blind Spot: Contract Governance

Advisory frameworks are very good at evaluating the vendor selection phase: how to choose, how to compare, how to negotiate. They’re much less good at evaluating the execution phase: how to monitor, how to intervene when things go wrong, how to manage scope change. And in my experience, 90% of problems in IT projects don’t come from choosing the wrong vendor. They come from managing the contract poorly after the vendor has been chosen.

I’ve seen projects fail not because the vendor was incompetent, but because the customer didn’t have internal governance capable of making decisions about requirement changes. I’ve seen SLAs negotiated down to the last cent that nobody monitored. I’ve seen contractual penalties that were never applied because the customer depended too much on the vendor to be able to afford to fine them. These are recurring patterns that any IT vendor knows intimately and that advisory frameworks treat as exceptions.

Fifth Blind Spot: Technical Quality and Business

Perhaps the deepest: the relationship between technical quality and business outcome. Advisory frameworks evaluate vendors on dimensions like price, track record, team size, certifications. They rarely evaluate the technical quality of the software they produce. How many automated tests does the codebase have? What’s the coverage? How is the architecture structured? Is the code maintainable? Is the documentation up to date? These are the dimensions that determine the total cost of ownership of software—the real TCO, not the declared one—and they’re dimensions that sourcing analysts aren’t equipped to assess.

The result is that the market rewards the ability to sell—convincing decks, solid references, large teams—rather than the ability to build. And that explains why so many IT projects cost twice what was expected and deliver half of what was promised: selection happens on criteria that don’t predict execution quality.

I’m writing these things not for the pleasure of criticizing a sector I respect and that, frankly, interests me. I’m writing them because I believe the IT advisory market is at an inflection point. AI is changing the economics of delivery. European compliance is changing purchasing criteria. The European mid-market needs evaluation frameworks that aren’t simplified versions of enterprise ones. And IT vendors—those who actually build and deliver the software—have operational knowledge that, if integrated into advisory frameworks, would make them far more useful.

I don’t claim to have the solution. But after fifteen years on the other side of the table, I know which questions should be asked and aren’t being asked. I know which metrics predict a project’s success and which only predict the quality of the initial presentation. I know what changes in pricing when AI enters the delivery cycle. I know what compliance means in a production codebase, not in a policy document.

This is knowledge the advisory market doesn’t have, not because it’s incompetent, but because it is structurally separated from the world of delivery. And maybe it’s time to build a bridge.

For most of the history of technology, it was possible to find at least one person who understood an artefact in its entirety. The Roman aqueduct, the mechanical loom, the steam locomotive, even a Second World War aircraft: complicated systems, certainly, but ultimately reducible to a unitary body of knowledge. A sufficiently prepared engineer could trace the causal chain from one end to the other. Could say: I know how it works, I know why it works, I know what happens if it breaks. This possibility was not a detail. It was the foundation on which the very idea of technical competence rested, and alongside it the idea of responsibility.

That foundation is gone.

The threshold

The breaking point was not sudden. It accumulated over decades, invisible in the way all changes that happen by layering rather than fracture are invisible. Every layer of abstraction added on top of the previous one solved a problem and created another: it made the layer below opaque. The programmer writing application code today does not truly know the framework they use. Whoever knows the framework does not know the runtime. Whoever knows the runtime does not know the operating system, not all the way down. Whoever knows the operating system does not know the processor microcode. And nobody, absolutely nobody, knows the entire chain of dependencies that a single install command pulls from the network and makes part of their software.

This is not polemical exaggeration. It is a factual description. An average software project in 2026 includes hundreds of direct dependencies and thousands of transitive ones. Each of these was written by someone else, with their own dependencies, their own vulnerabilities, their own architectural decisions made in a context that no downstream user will ever reconstruct. Running software today means trusting. Not in the noble sense of trust between people, but in the epistemological sense of someone who gives up verifying because verification is materially impossible.

There was an era when the word “engineer” implied the possibility of total control over one’s object of work. That era is over. It will not return.

Knowledge as an illusion of scale

The problem is not that we know little. It is that the kind of knowledge we possess is not commensurate with the complexity of what we operate. We know things, certainly. We know many things. But the knowledge needed to comprehend a modern distributed system is not the sum of individual knowledge: it is a knowledge that would require a mind capable of holding together simultaneously layers that are, by their very nature, designed to be separate.

Abstraction, the fundamental mechanism of computational thinking, works precisely because it hides. This is both its merit and its trap. A well-designed interface frees you from needing to know what happens underneath. But when something goes wrong, when a system behaves in unexpected ways, you discover that “underneath” there is a world that nobody in the room knows, and that perhaps nobody in the world knows in its entirety. Not because the knowledge does not exist, but because it is distributed in an irrecoverable way among thousands of people who have never spoken to one another.

This is a new epistemological condition. It has no precedent in the history of technology, and few precedents in the history of thought. The closest may be the problem of the division of labour as Adam Smith described it, but with a substantial difference: Smith was talking about a production process in which each worker understood their own piece. Here, nobody truly understands even their own piece, because their own piece rests on other pieces that escape comprehension by definition.

The broken chain of responsibility

If nobody understands the system in its entirety, the question of who is responsible has no satisfying answer. Not because candidates are lacking, but because the very concept of responsibility presupposes something that is missing here: the possibility of knowing.

Responsibility, at its root, means the capacity to respond. To give an account of one’s choices. But how does one give an account of a choice made in a context that could not be fully understood? How does one answer for a system whose behaviour emerges from interactions between components that no single actor designed or foresaw?

The law, which has thought about this far more than computer science has, developed over time the idea of due diligence: you do not need to understand everything, you just need to act with the care reasonably expected of someone in your role. It is a pragmatic compromise and for many centuries it worked. But it worked because the gap between what could be known and what had to be decided was bridgeable with study and experience. Today that gap is not bridgeable. It is not a gap that closes with more training or more effort: it is a structural gap, produced by the complexity of the object, not by the inadequacy of the subject.

Recent European legislation intuits this, even if it does not say so openly. The Cyber Resilience Act, the Product Liability Directive, the AI Act: all these regulatory instruments attempt to reconstruct chains of responsibility in a context where those chains are physically broken. They do so with classical tools: documentation obligations, conformity assessments, risk registers. These are serious and in many cases welcome attempts. But they rest on a silent assumption that deserves to be brought into the light: they assume that somewhere, there is someone who knows.

The manufacturer must document the risks of their product. But the manufacturer does not know the transitive dependencies of their own code. The importer must verify conformity. But conformity is defined against standards that describe system properties that nobody can verify in practice. The user must give informed consent. But the information needed for genuine consent would require competences that not even those who wrote the software possess.

This is not cynicism. It is an accurate description of a situation we have created step by step, in good faith, solving each time the problem immediately in front of us and adding each time a gram of opacity to the overall system.

The myth of specialisation

A response one hears often is that specialisation solves the problem. Nobody needs to understand everything: it is enough that each person understands their own piece well, and the whole will work. It is the principle of the division of labour applied to knowledge, and it is enormously attractive because it allows one to avoid confronting the underlying question.

But it does not work. It does not work because the boundaries between the “pieces” are arbitrary and permeable. A security vulnerability crosses every layer. A regulatory requirement cuts across frontend, backend, infrastructure, third-party suppliers. An architectural decision made five years ago in a context that no longer exists constrains today choices that whoever made it could not have imagined.

Specialisation works when components are genuinely independent. Software is not made of independent components. It is made of dependencies, in the most literal sense: every part depends on other parts, and the behaviour of the whole is not deducible from the behaviour of the parts. It is what systems theory calls emergence, and emergence is precisely the adversary of specialisation. The most insidious bug is always the one that lives in the space between specialisations, where nobody looks because nobody thinks it is their territory.

The incompetence of those who legislate

There is a particular case that deserves attention, not in an accusatory spirit but because it is structurally illuminating: the incompetence of those who write the rules.

A legislator who writes rules about software is in the same epistemological position as everyone else: they cannot comprehend the system in its entirety. But unlike a programmer or a software architect, the legislator does not even have the partial knowledge that comes from daily use. They operate on descriptions of descriptions, on abstractions of abstractions, mediated by consultants who in turn mediate the knowledge of specialists.

This is not an argument against regulation. On the contrary: it is an argument about the nature of possible regulation. Regulating what one does not fully understand is not a failure, it is the starting condition. The question is not whether the legislator is competent — they cannot be, in the full sense of the word, and not through any fault of their own. The question is whether the rules they produce are robust enough to function despite the structural incompetence of those who wrote them, those who must apply them, and those who must verify them.

Sometimes the answer is yes. The GDPR, with all its limitations, introduced a principle of caution that works precisely because it does not require technical understanding: treat personal data as though it were dangerous, regardless of whether you understand the specific mechanisms of the danger. It is a regulation designed for incompetence, and for that reason it works better than many regulations that presuppose competence.

Socrates in the development cycle

There is a sentence attributed to Socrates with the frequency and imprecision reserved for all sentences that are too useful: “I know that I know nothing.” It is cited as a gesture of humility, sometimes as intellectual coquetry. But in its most radical version, the one in Plato’s Apology, the point is different and far more uncomfortable: Socrates does not simply say that his knowledge is limited. He says that those who believe they know are in a worse condition than those who know they do not know, because to ignorance they add the illusion.

Applied to the technological present, the Socratic thesis acquires a weight that Plato could not have imagined. The software industry is built on a double illusion of knowledge: that of those who build the systems, who believe they control them, and that of those who use them, who believe they understand them. Both illusions are functional. Without the first, nobody would write code, because complete honesty about one’s own ignorance would be paralysing. Without the second, nobody would use software, because authentic informed consent would produce mass refusal.

We function, as individuals and as an industry, thanks to a voluntary suspension of epistemological disbelief. Not unlike the way finance functions, or politics, or any other complex system in which trust replaces understanding.

But there is a difference. Finance and politics have developed over time an institutional awareness of their own epistemological fragility. Central banks exist because we know the financial system does not self-regulate. Constitutions exist because we know that power does not self-limit. Computing has not yet developed anything equivalent. It has standards, it has best practices, it has certification frameworks: all tools that presuppose the possibility of knowledge rather than reckoning with its impossibility.

Deciding without knowing

The daily condition of those who work in technology is this: deciding without knowing. Not in the dramatic sense of a blind gamble, but in the ordinary, slightly wearing sense of someone who every day makes choices with multi-year consequences based on information they know to be incomplete, in contexts they know will change, for requirements they know to be provisional.

An estimate is a declaration of subjective probability passed off as a prediction. An architectural choice is an act of faith in the stability of conditions that are not stable. A refactoring is a wager that present costs will be repaid by future benefits that nobody can guarantee. Every sprint is an exercise in applied epistemology under time constraint, conducted by people who have not studied epistemology and who are not paid to reflect on the conditions of possibility of their own knowledge, but to produce results.

This is not an indictment. It is a description. And the point is not that things should be different: it is that they cannot be different. Structural incompetence is not a problem to be solved. It is the condition in which we operate, and in which we will continue to operate for as long as we build systems whose complexity exceeds the comprehension of those who build them.

The question, then, is not how to eliminate incompetence. It is how to inhabit it.

Inhabiting incompetence

If competence in the classical sense — complete mastery of one’s domain — is no longer attainable, then what we call by that name has become something else. Not a knowing, but a knowing-how-to-act in the absence of knowing. A form of practical wisdom that resembles Aristotle’s phronesis more than his episteme: not knowledge of first causes, but the capacity to act well in particular and uncertain situations.

The good technologist, today, is not the one who knows the most. It is the one who manages their own ignorance best. Who knows where the boundaries of their understanding lie, who knows how to ask, who knows when to stop, who knows how to build systems that fail predictably rather than catastrophically. These are all competences, but they are competences about one’s own incompetence. They are meta-competences, if one wants to use an ugly term for an important idea.

And here a paradox opens that deserves to be looked at squarely. The professional culture of software rewards knowing and punishes not-knowing. Whoever admits they do not understand loses credibility. Whoever says “I don’t know” in a meeting is perceived as weak. Whoever estimates honestly is punished by comparison with whoever estimates optimistically. The entire incentive system is built to mask incompetence rather than manage it, which produces the opposite result: unrecognised, unmanaged, unmetabolised incompetence. Dangerous incompetence.

A mature professional culture would do the reverse. It would start from the assumption that nobody understands the system in its entirety, and build processes, tools, institutions designed to function under that condition. This is not utopia: it is the engineering of ignorance, and it is exactly what we do when we write automated tests (we verify because we do not trust our own understanding), when we conduct code reviews (we look for the errors that our blind spots prevent us from seeing), when we adopt the principle of least privilege (we limit the damage our ignorance can cause).

These are not palliatives. They are the most sophisticated practices the software industry has produced, and they are all, at root, techniques for managing incompetence. Nobody calls them that, because the name would be uncomfortable. But that is what they are.

Honesty as method

Perhaps the only available response to structural incompetence is not a solution but an attitude: epistemological honesty as a daily practice. Knowing that one does not know, not as an empty formula, but as the operational starting point of every decision.

This does not mean paralysis. It means deciding in the knowledge that one is deciding in the dark, and building safety nets proportionate to that awareness. It means documenting not only what was done, but why it was done and on what assumptions — because those assumptions will prove wrong and whoever comes after will need to understand not the solution, but the reasoning that produced it. It means ceasing to treat estimates as promises and architectures as monuments.

This is not a revolutionary proposal. It is the description of what the best people already do, often quietly, often against the grain of the culture that surrounds them. Structural incompetence is not an enemy to be defeated. It is the ground we walk on, and the only choice available is between walking on it with our eyes open or with our eyes shut.

We, as a species, have built a world we are unable to understand. This is not a tragedy. It may be the most human thing we have ever done.

And it’s from that position, not as an outside critic or a Monday-morning quarterback, that I’m telling you something our industry refuses to hear: most software that exists shouldn’t exist.

Not because it’s poorly made. Some of it is, sure, but that’s not the point. It shouldn’t exist because it doesn’t solve a problem. Or it solves a problem nobody has. Or it solves a problem that was already solved, and does it worse. Or, in the most common and most insidious case, it creates the problem it then pretends to solve.

The Graveyard of Invented Problems

Open your phone. Count the apps. How many do you actually use? How many solve a real problem in your life? And how many exist because somebody put together a convincing pitch deck, closed a seed round, and built something the world never asked for?

This isn’t a fringe phenomenon. This is the dominant model of the software industry for the last fifteen years.

The cycle goes like this: someone identifies a “pain point” (almost always a minor inconvenience inflated into an existential crisis), builds an MVP, raises funding, hires developers, scales. At some point the software exists, it has users, it generates revenue. But nobody ever stopped to ask whether the world needed it. The question was irrelevant. The only question that mattered was: is it growing?

I’ve seen apps for sharing grocery lists with your roommates. Platforms for booking your barber with artificial intelligence. SaaS products for managing your houseplants. Marketplaces for swapping used dog outfits. I’m not making these up. Every single one of these received funding, had a development team, burned server capacity, energy, human time.

The problem isn’t that they were bad products. Some were technically flawless. The problem is they had no reason to exist. And nobody said so, because saying so meant being the person who “doesn’t get innovation.”

The Hidden Tax

Software isn’t free. Ever. Even when it costs the user nothing, it costs the world.

It costs energy. Every app that shouldn’t exist runs on servers consuming electricity. Every pointless SaaS has a database replicated across three availability zones, a monitoring stack, a global CDN. The cloud is not a cloud. It’s a warehouse full of machines overheating in Oregon or Northern Virginia, powered by a grid that has physical limits.

It costs attention. Every useless piece of software installed on someone’s phone competes for their attention with everything else. With work, with relationships, with sleep, with productive boredom, with unstructured thought. Attention is a finite resource. Every useless app that captures it is stealing it from something more important.

It costs complexity. Every piece of software adds an interface, a login, a password, another batch of notifications, another set of terms of service nobody reads, another stream of personal data flowing to God knows where. The complexity of our digital environment grows every year, and not because problems are multiplying. Because solutions are multiplying faster than problems.

It costs talent. This is the one that makes me angriest. There are extraordinarily talented developers out there spending their days optimizing the conversion funnel of an app that lets you order coffee with three fewer taps. People who could be building software that saves lives, makes education accessible, improves public health. Instead they’re A/B testing the color of a “Buy Now” button.

It’s not their fault. The market pays more for the button. But it’s a waste so obscene we should at least have the decency to call it what it is.

“But the Market Decides”

Here’s the objection. If a piece of software exists and has users, then the market has decided it’s needed. Supply meets demand, the invisible hand does its thing, everybody’s happy.

Except it’s not true. The software market doesn’t work like the apple market.

First: the marginal cost of distribution is near zero. This means software can reach millions of users without the quality or necessity of the product ever being tested by any natural feedback mechanism. A greengrocer selling rotten apples goes under in a week. An app that solves no problem can survive for years, funded by venture capital, growing in users who don’t pay, until the next round or the acqui-hire.

Second: the advertising model has decoupled value from price. When the user doesn’t pay, the product doesn’t need to be useful to the user. It needs to be useful to the advertiser. And for the advertiser, the metric is attention, not satisfaction. Software that makes people miserable but keeps them glued to the screen is an extraordinary commercial success. The market “decided” it’s needed. But the market, in this case, is sick.

Third: network effects create natural monopolies. Once everyone uses a platform, you can’t not use it. Not because it’s good, but because it’s where everyone is. The market didn’t “decide” that WhatsApp is the best way to communicate. It decided it’s the way everyone communicates, which is a completely different thing.

The Radical Act of Not Building

In tech culture, building is always positive. “Makers gonna make.” “Ship it.” “Build in public.” The verb build has a sacred aura, and whoever builds is by definition on the right side of history.

But there is a braver act than building, and nobody talks about it: deciding not to build.

Deciding that the world doesn’t need another task manager. That a spreadsheet does the job better than your app. That the problem you’re about to solve isn’t a problem. That your talent and your time are better spent elsewhere.

In my experience, the best engineers I’ve ever worked with were also the ones most capable of saying “we don’t need this.” Not out of laziness, not out of cynicism. Out of respect. Respect for the problem, for the user, for the complexity of the real world. They knew that adding software to a context means adding complexity, dependencies, maintenance, technical debt. And that doing it without a strong reason is irresponsibility dressed up as productivity.

The Unix philosophy said it forty years ago: do one thing, and do it well. Not “do everything.” Not “do new things because you can.” Do one thing. Leave the rest alone.

The Software That Should Exist

I’m not saying software is the enemy. That would be like saying writing is the enemy because bad books exist.

The software that should exist is the kind that expands human capability without creating dependency. That solves a real, verifiable problem. That works for the people who use it, not for the people who sell it. That you can stop using without consequences. That doesn’t need to trap you to justify its own existence.

The software that should exist is the kind that, if it vanished tomorrow, someone would notice and miss it. Not the compulsive missing of an addict, but the concrete missing of someone who lost a useful tool. Like losing a good kitchen knife. Like losing a reliable bike.

That’s the metric we should be using: if it disappeared, would you miss it? If the answer is “probably not,” that software shouldn’t exist. If the answer is “I wouldn’t even know it was gone,” that software is wasting the planet’s resources and the time of everyone who built it.

The Responsibility of Those Who Build

Every time we decide to build a piece of software, we’re making a decision about real resources. Developer time. Server energy. User attention. The complexity of the digital ecosystem. And in a world with finite resources and enormous problems, building something useless is not neutral. It’s active waste. It’s a misallocation of human intelligence.

A civil engineer has to justify why a bridge is needed. An architect has to demonstrate that a building meets a need. A doctor doesn’t prescribe drugs just because they exist. Why should software be different? Why should we accept that 90% of what we build will end up forgotten in an App Store, abandoned by its own creators after six months, left with user data inside and the servers still running?

Real innovation, in 2026, is not building more. It’s building less, building better, building for better reasons.

And having the guts to say, once in a while, “no, we’re not doing this one.” Not because we can’t. Because it doesn’t need to exist.

The Luxury of Subtraction

There’s a concept in architecture that the software world has never learned: the value of empty space.

A good architect doesn’t fill every square foot. They know that empty space isn’t absence. It’s breathing room. It’s possibility. It’s the room that the people who live there need to move, to think, to live. A building packed to the last inch isn’t a masterpiece of efficiency. It’s a prison.

Our digital landscape is a building packed to the last inch. Every space is occupied by an app, a service, a platform, a notification. There’s no breathing room. There’s no empty space. There’s no quiet.

And in the middle of all that noise, the software that’s actually useful, the kind that solves real problems, gets lost. It becomes invisible. Not because it’s any worse, but because it’s buried under tons of software that shouldn’t exist.

Subtraction is a creative act. Choosing not to build is a design decision. And in an industry that can’t say no to anything, it might be the rarest and most valuable skill there is.

The best software I ever wrote is the software I decided not to write.

Then you go home. And your child is in front of a screen. And that screen is doing exactly what you know how to do: capturing attention, generating engagement, maximizing time-on-platform.

Only this time the user isn’t a user. It’s your child.

The dissonance

If you work in tech and you have kids, you live with a cognitive dissonance that almost no one names. By day you design systems meant to keep people in. By night you try to pull your child away from identical systems. By day you talk about “user retention” as a success. By night your child’s “retention” in front of the tablet scares you.

You know how pull-to-refresh works. You implemented it, or at least you discussed implementing it. You know it replicates the lever gesture of a slot machine. You know the delay before loading isn’t a technical limitation but a design pattern : the calculated pause that maximizes dopamine release. You know it because it’s your job to know it.

And you know your child, at eight, at ten, at twelve, has no tools to defend themselves against what you know how to build.

It’s not a personal contradiction. It’s a system contradiction. It concerns anyone who works in tech and has kids—which at this point means millions of people.

What we know and can’t pretend not to know anymore

Lining things up helps you look them in the face.

We know that variable-ratio reinforcement schedules—the ones social media feeds are built on—are the most powerful psychological mechanism ever documented for inducing and maintaining compulsive behavior. We’ve known since the ’50s. Skinner proved it on pigeons. We apply it to children.

We know that an adolescent’s brain is in full development. The prefrontal cortex—the part that governs judgment, impulse control, the ability to evaluate consequences—doesn’t finish maturing before 25. We design systems that deliberately bypass it to speak directly to the limbic system. We do it for a living.

We know that habitual social media use is associated with a measurable reduction in cortical thickness in brain regions linked to cognitive control. These aren’t opinions. These are MRI data on thousands of adolescents.

We know that rates of depression, anxiety, self-harm, and suicide among adolescents have doubled or tripled since 2010, in step with the spread of smartphones, across the Western world.

We know that platforms know it. Meta’s internal documents, made public by Frances Haugen, showed that Instagram worsened body image issues for one in three girls. The company knew. It kept going.

We know all of this. And we keep building.

“But I don’t work on social”

I know. Me neither. I build management software, platforms for public administration, B2B software. I don’t design algorithmic feeds and I don’t optimize recommendation systems for teenagers.

But the point isn’t what we build today. The point is the culture we build it in.

We work in an industry that has normalized the idea that human attention is a resource to extract. That “user experience” is synonymous with “time the user spends on the platform.” That success is measured in sessions, clicks, conversion rate, daily active users. We talk about human beings with the vocabulary of mining, and it doesn’t seem strange.

This culture runs through all of us. Even those who don’t work on social breathe in its metrics, its values, its priorities. When we go home, that culture comes home with us. It seeps into the way we look at our child’s screen. Sometimes with concern, sure, but also with a subtle, unconfessable familiarity. We recognize those mechanisms. We know they work. And a part of us—the professional part—can’t help admiring them.

That’s the familiarity we have to break.

The privilege of awareness

Anyone who works in tech and has kids has something most parents don’t: knowledge of the architecture.

We know how those systems work, not just that they work. We know notifications don’t arrive at random but are optimized for the moment of maximum psychological vulnerability. We know infinite scroll isn’t an aesthetic choice but a capture device. We know “the algorithm” isn’t a mysterious entity: it’s code written by people like us, with specific goals, optimized to specific metrics.

This awareness is an enormous privilege. And privilege creates responsibility. If you see the fire and others don’t, you can’t pretend nothing’s happening and say “not my fire.”

And yet that’s exactly what we do, as an industry. We know. And we stay quiet. Because speaking up would mean admitting the problem isn’t “out there,” in kids’ bad habits, in parents’ inability, in the lack of “digital education.” The problem is also inside. In how we think about software. In the metrics we choose to optimize. In the questions we don’t ask.

The questions we don’t ask

In twenty years in tech, I’ve never heard anyone in a project meeting ask these questions:

Could this system create addiction? If so, do we have a responsibility to prevent it?

Are we designing for the user’s well-being or for maximizing their time of use? Are those the same thing?

If a minor used this product, would it be safe? Not “compliant with regulations.” Safe.

Are we measuring success with metrics that align our interests with those of the people using our software? Or are we measuring something that’s convenient for us to measure?

Would we build this system exactly like this if we knew the first user would be our child?

The last question is the most important one. And it’s the one we never ask.

The child test

I’m proposing a rule. Not a law, not a framework, not a process. A personal rule, for anyone who builds software and has kids.

Before you implement a system, ask yourself: am I okay with the first user being my child?

Not “my child at twenty, an adult, aware, trained.” My child now. With the age they have. With the prefrontal cortex they have. With the resistance to stimuli they have. With the blind trust in technology they have.

If the answer is yes, build it. If the answer is “it depends,” stop and ask what it depends on. If the answer is no, you have a problem. And the problem isn’t your child.

This isn’t a sentimental test. It’s a design test. It’s the precautionary principle translated into the language of software development. The applied version of Hans Jonas’s imperative: act so that the consequences of your action are compatible with the permanence of an authentic human life.

Except Jonas was talking about atomic bombs and genetic engineering. We’re talking about algorithmic feeds and push notifications. The fact they seem harmless is exactly what makes them dangerous.

We are not powerless

I know what you’re thinking. “I’m an employee. A freelancer. A team lead at a ten-person company. I don’t decide Meta’s policies.” True. You don’t.

But you decide how you build your software. Which metrics to optimize. Whether to implement dark patterns or refuse. Whether to add a usage timer or infinite scroll. Whether to design a system that respects the user’s attention or one that loots it.

Above all, you decide what kind of professional you want to be.

You can be the one who says “the market demands it” and implements whatever pays. Or you can be the one who says “I’m not building it like this” and proposes an alternative. That’s not idealism, it’s craftsmanship. A serious carpenter doesn’t use rotten wood because it’s cheaper. A serious cook doesn’t serve spoiled food because it increases margin. A serious engineer doesn’t sign off on a structurally unsafe design because the client is in a hurry.

And yet in software—where the consequences can involve millions of people and the brain of an entire generation—we accept standards we wouldn’t accept in any other trade.

The manifesto

I work in tech. I have a child. I can’t keep the two separate anymore.

My child is not a user. Not a metric, not a session, not a daily active user. They are a human being with a developing brain, a judgment still under construction, a trust in the world that depends also on how I—and people like me—build that world.

My work has consequences. Not the abstract, distant consequences of moral philosophy. The concrete ones of a system that runs twenty-four hours a day and interacts with millions of brains. If I don’t take responsibility for it, who should?

Compliance is not enough. Respecting the GDPR, the AI Act, the EAA is the bare minimum, not the finish line. The question isn’t “is it legal?” The question is “is it right?” Those are two different questions, and the second matters more.

Speed is not a value. “Ship fast” isn’t a virtue when what you’re shipping can cause harm. Hurry is the refuge of those who don’t want to think about consequences. Critical thinking is slow by nature. Code is fast. Wisdom is not confusing the timelines of one with the timelines of the other.

Technical training is not enough. Knowing how to write code without knowing how to read the implications of that code isn’t competence—it’s specialized blindness. We need engineers who have read Jonas, developers who know Mill, designers who have studied developmental psychology. Not as general culture. As work tools.

My child will judge me. Not by the revenue I generated, not by the projects I delivered, not by the technologies I mastered. They’ll judge me by the world I helped build. And in that judgment, “I was just following orders” won’t be an acceptable defense. It never has been.

To those who build

If you work in tech and you have kids, you know what I’m talking about. You know there’s a conversation our industry refuses to have. You know the discomfort you feel when your child disappears into a screen isn’t parental paranoia. It’s professional competence telling you something.

Listen to it.

I’m not saying stop building software. I’m saying build it as if the first user were your child. Because, for all intents and purposes, it could be.

And if not your child, someone else’s.

Which is the same thing.

“We have not inherited the world from our parents. We have borrowed it from our children.” — proverb attributed to Antoine de Saint-Exupéry

There’s something I need to say before anything else, because it’s the reason this article exists.

I did my A-levels in science. Then I read Philosophy at the University of Urbino — one of those places where philosophy isn’t a bolt-on but a way of inhabiting the world, where they teach you that questions matter more than answers and that “what’s the point?” is itself a philosophical question. After that, I chose technology. I’ve been writing code, managing infrastructure and building digital products for twenty years. And for twenty years, with varying shades of goodwill and sarcasm, I’ve been told that philosophy “isn’t good for anything.” That in the tech world, what counts is programming languages, frameworks, deployments. That Kant and Popper are charming intellectual indulgences but fundamentally decorative — a bit like a nice print above the sofa that nobody ever looks at.

I always knew that wasn’t true. I felt it every time I caught an ethical implication in a project meeting that everyone else had missed. I felt it when I read a piece of European legislation and, instead of seeing nothing but a compliance checklist, recognised the legal translation of a precise philosophical principle. I felt it when I discussed software architecture and realised that the truly important decisions weren’t technical — they were decisions about what kind of world that software would help to create.

Today that feeling has hardened into certainty. A humanities education is not a complement to technical thinking. It is its indispensable ethical foundation. Without it, technology is blind. Powerful, lightning-fast, ruthlessly efficient — and blind.

We live at a moment in history when the systems we build can alter the neurological development of an entire generation, sway elections, decide who gets a mortgage and who doesn’t, determine what millions of people will believe to be true tomorrow morning. In this context, knowing how to configure a Kubernetes cluster is not enough. You also need to know what Hans Jonas thought about responsibility towards the future. You need to have read Mill on the boundary between liberty and harm. You need to understand Anders’s Promethean gap — and recognise it when you see it implemented in a recommendation algorithm.

This is no longer an academic question. It’s not the luxury of people with time for highbrow reading. It’s an existential question — in the most concrete, least rhetorical sense of the word. Existential for us as a species, because the technological decisions of this decade will define the cognitive and social conditions in which our children will live. And existential for business, because anyone who builds technology without an ethical compass isn’t just running a moral risk: they’re running a market risk. Europe has grasped this. The AI Act, the GDPR, the Cyber Resilience Act, the Product Liability Directive — these are the signal that the era of technology without critical thinking is over. Those who cannot read that signal — who lack the cultural tools to understand why those regulations exist and not merely how to comply with them — will fall behind. Not as punishment, but through inadequacy.

So yes: after twenty years in tech, I can say with reasonable confidence that reading Philosophy was the most important professional decision of my life. More important than any certification, any language learnt, any project delivered. Because it gave me the one thing that technology cannot give you: the ability to ask yourself whether the thing you’re building ought to be built.

What follows is an attempt to explain why.

The Most Powerful Rhetorical Weapon of Our Time

There is a word that, in contemporary public debate, functions as an all-purpose skeleton key. A word that shuts down discussions rather than opening them, that casts whoever invokes it as a champion of civilisation and whoever questions it as an obscurantist. That word is progress.

“Europe is holding back progress.” “Bureaucracy is killing innovation.” “Regulations are shackling the future.” We hear these phrases daily — on talk shows, in X threads, in tech conference keynotes, in Bay Area venture capitalists’ blog posts. They present themselves as self-evident truths, yet they conceal a premise that is never made explicit: that progress is a natural force, unidirectional, intrinsically benign, and that any obstacle in its path is by definition a harm to humanity.

But is that really the case? Or are we confusing progress with something far more ordinary and far less noble?

What Progress Is, and What It Has Been

To answer that, we first need to understand where the very idea of progress comes from. It is not an eternal concept: it is a historical invention, and not a particularly ancient one.

The Enlightenment and the Birth of an Idea

The idea that human history has a direction — that tomorrow will be better than today — is a product of the eighteenth-century European Enlightenment. Before Condorcet, Voltaire and Kant, time was perceived as cyclical (in the Greco-Roman world) or as decline from a lost golden age. The Enlightenment revolutionised this perception: human reason, systematically applied, could improve the material, moral and political conditions of the species.

Condorcet, in his Esquisse d ‘un tableau historique des progrès de l’esprit humain (1795), imagined humanity advancing by stages towards perfection through education, science and the abolition of prejudice. It was a powerful and, in many respects, generous vision. But it already contained a problematic seed: the idea that progress was inevitable , almost a law of nature.

Kant was subtler. He distinguished between technical progress and moral progress. In his Idea for a Universal History with a Cosmopolitan Purpose (1784), he suggested that humanity could advance towards a universal civil society — but only through conflict, toil, and above all through institutions capable of channelling what he called humanity’s “unsocial sociability.” For Kant, progress was not automatic: it required structures , laws , mutual constraints. It required, in a word, politics.

Positivism and the Foundational Fallacy

It was with Auguste Comte and nineteenth-century positivism that the idea of progress became permanently welded to scientific and technological progress. Comte theorised a “law of three stages” — theological, metaphysical, positive — in which science would progressively replace every other form of knowledge, guiding humanity towards a rational order.

Here lies the root of the fallacy we still drag around today: the identification of technological advancement with improvement of the human condition. A fallacy the twentieth century should have destroyed once and for all — and which, with almost inexplicable stubbornness, continues to thrive.

The Century That Should Have Taught Us Everything

The twentieth century was the ultimate laboratory for testing the equation “more technology = more progress.” The results were unequivocal.

The same science that produced penicillin produced nerve gas. The same engineering that built bridges and aqueducts built the gas chambers — with industrial efficiency, with technical precision, with progress in methods. Nuclear fission gave humanity an extraordinary energy source and, simultaneously, the capacity for self-annihilation.

Günther Anders, in Die Antiquiertheit des Menschen (The Obsolescence of Human Beings , 1956), captured this rupture with breathtaking clarity. Anders formulated the concept of the “Promethean gap”: our technical capacity to produce radically outstrips our capacity to imagine the consequences of what we produce. We can build a bomb that kills a hundred thousand people, but we cannot feel — emotionally, morally — what the death of a hundred thousand people means. We have become, Anders wrote, smaller than our products.

Hannah Arendt, analysing the Eichmann trial, revealed something more disturbing still: that the most radical evil of the twentieth century was perpetrated not by monsters but by efficient bureaucrats. The “banality of evil” is, in a sense, organisational progress applied to destruction. Eichmann did not hate the Jews: he optimised logistical processes. He was, in his own way, an innovator.

The Thought That Kills: A Thought Experiment

Let us take a further step. Let us take it together, with the seriousness it deserves.

Imagine that tomorrow — through some convergence of neuroscience, nanotechnology and brain-computer interfaces — it became possible to kill another human being by sheer force of thought. No physical weapon. No intermediary. A sufficiently focused mental intention, and the other person dies.

Would this be technological progress?

The superficial answer is yes. It represents an advance in understanding the brain, in the capabilities of neural interfaces, in the miniaturisation of technology. It satisfies all the criteria by which we normally define technical progress: it is new, it is more powerful than what came before, it represents a frontier of knowledge.

But something within us — something deep, pre-argumentative, almost visceral — rebels against that answer. We sense that something is wrong. And that “something” is precisely what we need to examine, because it is there that the true nature of progress lies hidden.

Hans Jonas and the Ethics of Responsibility

Hans Jonas, in The Imperative of Responsibility (1979), anticipated precisely this kind of dilemma. He was writing in an era when genetic engineering and nuclear energy were the frontiers of technology, yet his reasoning applies with striking pertinence to our thought experiment.

Jonas starts from an observation: traditional ethics is inadequate to confront modern technological power. Classical ethics — from Aristotle to Kant — presupposed that nature was substantially invulnerable to human action, and that the consequences of our actions were circumscribed in space and time. But modern technology has made these premises false: today we can alter the climate, modify the genome, and — in our experiment — abolish every barrier between intention and homicide.

From this Jonas formulates his technological categorical imperative : “Act so that the effects of your action are compatible with the permanence of genuine human life on earth.” This is not a conservative imperative: it is an imperative of responsibility towards the future. The question is not “can we do it?” but “what kind of world do we create by doing it?”

In the case of the thought that kills, the answer is clear: we would create a world in which human coexistence — the foundation of every civilisation — would become impossible. There would be no safe place left, because the threat would reside in the mind itself. Every human interaction would be poisoned by terror. It would not be the end of technology: it would be the end of society.

Mill’s Filter: Harm as the Boundary of Liberty

John Stuart Mill, in On Liberty (1859), formulated the principle that should be the lodestar of every discussion about progress: individual liberty is sacred, but it ends where harm to others begins. It is the so-called “harm principle,” and in its simplicity it contains enormous wisdom.

Applied to our experiment: the capacity to kill with thought is not an expansion of human freedom. It is its absolute negation. If anyone can kill anyone without intermediaries, no freedom exists at all — because freedom presupposes the security of physical existence. You cannot exercise freedom of speech, of movement, of thought if someone can annihilate you with an intention.

Mill teaches us something we ought to have tattooed on our forearms: not every expansion of individual power is progress. Some capabilities, if universally distributed, do not emancipate — they destroy. Genuine progress is not the unlimited increase of power, but the increase of power within the boundaries that make coexistence possible.

Popper: The Open Society and Its Enemies (Technological Ones Included)

Karl Popper, in The Open Society and Its Enemies (1945), built the most robust philosophical defence of democratic institutions against every form of utopianism — including the technological variety.

Popper was deeply distrustful of grand narratives about inevitable progress. For him, progress was not a triumphal march but a process of conjectures and refutations : we try, we err, we correct. And — crucially — we can only correct if institutions exist that allow us to do so without violence. The open society is one that has mechanisms of self-correction: parliaments, courts, a free press, laws that can be amended.

When someone says that regulations “shackle progress,” they are saying — consciously or not — that the mechanisms of self-correction are an obstacle. But an obstacle to what , exactly? If “progress” cannot survive democratic scrutiny, public debate, risk assessment — then perhaps it isn’t progress. Perhaps it’s just haste dressed up as vision.

Those Who Cry “Progress in Chains”: A Taxonomy

When, in public debate, someone complains that states or supranational organisations are “holding back progress,” it is worth asking: who is speaking, and whose interests do they represent?

The Techno-Optimist in Good Faith

There are certainly people who sincerely believe that technology is the solution to every human problem. The position is understandable — technology has solved enormous problems: infant mortality, famines, epidemics. But techno-optimism becomes dangerous when it morphs into techno-determinism: the idea that technology, left to its own devices, always produces positive outcomes. History says otherwise.

The Entrepreneur Who Mistakes Self-Interest for the Common Good

Here we enter more delicate territory. When a Silicon Valley CEO denounces European AI regulation as an “obstacle to progress,” is he really defending the future of humanity — or defending his own business model? The confusion between private interest and public good is as old as capitalism, but in the tech era it has taken on a peculiarly insidious form: it arrives wearing the clothes of the future, of innovation, of vision.

Marc Andreessen, in his Techno-Optimist Manifesto (2023), took this position to its logical conclusion: markets are the supreme mechanism of progress, regulation is a brake, and those who defend it are “decelerationists” — enemies of the future. A position that has the merit of clarity and the defect of blindness: it entirely ignores the fact that markets, without rules, do not produce progress — they produce concentration of power. Adam Smith already knew this; in The Wealth of Nations , he warned against monopolies with the same vigour with which he championed free trade.

The Ideological Libertarian

For the radical libertarian, every form of regulation is coercion, and every coercion is evil. A philosophically consistent position — if one accepts the premises. But the premises are fragile: they presuppose that individuals operate in a social vacuum, without asymmetries of power, without externalities, without the possibility that one person’s freedom destroys the freedom of many.

Robert Nozick, in Anarchy, State, and Utopia (1974), constructed the most sophisticated version of this position. But even Nozick conceded the necessity of a “minimal state” to protect fundamental rights. The question is: when technology can alter the climate, manipulate the behaviour of billions of people, or abolish every barrier between intention and homicide, is Nozick’s “minimal state” still sufficient?

The Anti-Élite Populist

Finally, there are those who deploy the rhetoric of “stifled progress” in a populist key: the bureaucratic élites of Brussels impose rules that “the people” never asked for. A position that exploits legitimate democratic frustration in order to attack institutions, yet rarely proposes credible alternatives. Because the awkward question is: if not democratic institutions, who should decide the limits of technology? The market? The programmers? The shareholders?

The Bomb That Has Already Gone Off: Social Media and Our Children’s Brains

So far we have been reasoning in the abstract — thought experiments, philosophical hypotheses, future scenarios. But there is no need. The weapon that destroys without firing a shot already exists. It is in our children’s pockets. It has a colourful interface, cheerful notifications, and a business model that monetises human attention by converting it into data sold to advertisers.

We are talking about social media. And we must talk — with the bluntness the subject demands — about what they are doing to the brains, the psyches, and the social fabric of an entire generation.

The Submerged Iceberg

Jonathan Haidt, social psychologist and author of The Anxious Generation (2024), has documented with surgical precision what the epidemiological data show: after more than a decade of stability or improvement, adolescent mental health plummeted in the early 2010s. Rates of depression, anxiety, self-harm and suicide soared, more than doubling on many measures. The spike coincides with the mass adoption of smartphones. Not with the 2008 financial crisis, not with terrorism, not with climate change. With smartphones.

But what we can see — the numbers that already alarm us — is only the tip of the iceberg. Consider what we know.

The US Centers for Disease Control reported that in 2023, over 40% of high school students described persistent feelings of sadness or hopelessness. Among girls, 57% displayed depressive symptoms. Nearly one in three girls reported having “seriously considered” suicide — a 60% increase in the past decade. In the United Kingdom, the NHS Mental Health Survey 2025 revealed that 25.8% of young people aged 16 to 24 are affected by a common mental health disorder, up from 18.9% in 2014. Among young women, the figure reaches 36.1%.

These are the visible data. The ones we measure because someone sought help, went to hospital, filled in a questionnaire. The submerged iceberg is made up of adolescents suffering in silence, developing subclinical disorders, losing cognitive capacity without anyone noticing. Between 70% and 80% of children with mental health disorders never receive any treatment at all.

The Brain as Battlefield

But the most unsettling dimension of this crisis is not psychological: it is neurological. And here we enter territory that should keep anyone with children, grandchildren or students awake at night.

A study published in JAMA Pediatrics by Professor Eva Telzer’s team at the University of North Carolina tracked 169 middle-school students over three years, monitoring their brain activity with functional MRI. The results: adolescents who habitually check social media show significantly different trajectories of brain development compared to those who do not. The affected areas include the amygdala — the centre of fear and emotional reactivity — and the dorsolateral prefrontal cortex, responsible for judgement, reasoning and reward evaluation.

A very recent study, published in March 2026 in NeuroImage, analysed ABCD Study data from over 7,000 American adolescents, finding that greater daily social media use is associated with reduced cortical thickness across a wide array of brain regions. We are not talking about “feeling a bit down.” We are talking about structural alterations to the developing brain.

Generation Z — those born after 1995 — were the first generation to have smartphones during puberty. Their brains developed while algorithms designed to maximise engagement competed for their attention every waking moment. Haidt identifies four foundational harms: social deprivation (real relationships replaced by digital ones), sleep deprivation, attention fragmentation, and addiction.

And the research confirms it: repeated consumption of short-form video repeatedly activates the brain’s reward circuitry, leading to dopamine dysregulation, reduced sustained attention, increased impulsivity and disrupted sleep patterns. In practical terms, these young people’s brains are being reconfigured to function in ways that compromise cognitive control.

The Slot Machine in Your Pocket

Here we must be explicit about a point that is too often played down: social media did not become harmful by accident. They were designed to be this way.

The psychological mechanisms that make social media compulsive are the same — identical, not “similar”: identical — as those that make slot machines addictive. They are called “variable ratio reinforcement schedules”: unpredictable, intermittent rewards of varying magnitude. This is the principle B.F. Skinner documented in the 1950s studying pigeons: of all possible reinforcement schedules, the variable ratio is the most powerful at maintaining behaviour — and the most resistant to extinction.

Every time you scroll through a TikTok or Instagram feed, you are pulling the arm of a fruit machine. You do not know which scroll will bring something interesting. It might be the next one. Or the one after. Or ten scrolls away. This uncertainty generates more dopaminergic activity than a predictable reward. The anticipation, the not knowing, is itself the drug.

The crucial difference: casinos are regulated. They must declare the odds. They cannot admit minors. They cannot operate without a licence. Social media platforms have none of these constraints. Natasha Schüll, author of Addiction by Design , has put it plainly: social media companies use exactly the same methods as the gambling industry to keep users online, because in the attention economy revenue is a function of time spent on the platform.

The pull-to-refresh gesture that mimics pulling a slot machine lever. The red notification badges that exploit the Zeigarnik effect — the psychological tension of incomplete tasks. Snapchat streaks that turn friendship into a gamified metric. TikTok’s algorithm, which learns within hours precisely which content will keep you glued to the screen.

Chamath Palihapitiya, former vice-president of growth at Facebook, admitted it publicly: the short-term, dopamine-driven feedback loops we have created are destroying how society works. Sean Parker, Facebook’s first president, declared that the objective was “to consume as much of your time and conscious attention as possible” and that the platform exploits “a vulnerability in human psychology.” These are not accusations from outsiders: they are admissions by the people who built the systems.

And the internal research confirmed it: documents made public by whistleblower Frances Haugen showed that Instagram knew it was making body image issues worse for one in three teenage girls. They knew. And they chose profits.

The Difference from Conventional Weapons

This is where the analogy with the atomic bomb from our thought experiment stops being hyperbole.

A conventional weapon kills the body. The damage is visible, immediate, documentable. The world notices. There are photographs, casualty figures, memorials. The damage activates a social response: wars are declared, treaties are signed, monuments are erected.

Social media operate on an entirely different register. The damage is invisible , gradual , cumulative and — this is the critical point — normalised. Nobody sees a neuron being reconfigured. Nobody hears the sound of a prefrontal cortex thinning. Nobody perceives sleep deprivation as an emergency when it affects a hundred million adolescents simultaneously. The damage hides behind the everyday: “it’s just the phone,” “all kids are like that,” “we used to sit in front of the telly for hours.”

But the telly was not engineered to create addiction through variable ratio reinforcement schedules. The telly did not follow you into your bedroom at three in the morning. The telly did not have an algorithm that learnt exactly which insecurities to exploit to keep you staring at the screen. The telly did not give you a real-time numerical metric of your social worth.

And then there is the question of scale. A bomb destroys a city. Social media are altering the brain development of an entire generation on a planetary scale. Not a specific group, not a geographically bounded population: anyone, anywhere in the world, between the ages of 3 and 20 who has a connected device. The World Health Organisation surveyed nearly 280,000 young adolescents across 44 countries: 11% showed signs of problematic social media use. At global scale, these are numbers that dwarf any other public health emergency.

And a bomb goes off once. Social media operate continuously — 24 hours a day, 7 days a week, 365 days a year. There is no ceasefire. There is no peace treaty. The exposure is chronic, uninterrupted, and starting ever earlier: children of 3 or 4 with tablets programmed to entertain them, 8- or 9-year-olds with their first smartphone, 11- and 12-year-olds already immersed in social platforms. Sixty-four per cent of American children aged 11–12 already use social media.

The Destruction of Families

There is an aspect the numbers do not capture, one that concerns the connective tissue of society itself: the family.

Anyone with school-age children knows exactly what I mean. The smartphone has become the principal domestic battleground. This is not a matter of “rules” or “screen time limits” — it is structural. The device is engineered to be more attractive, more stimulating, more rewarding than any family interaction. A parent reading a bedtime story is competing with an algorithm that has analysed billions of interactions to know precisely what captures that child’s attention.

It is an asymmetric war, and the family is losing it. Parents feel powerless, inadequate, perpetually behind a technology that evolves faster than their ability to understand it. Children feel controlled, misunderstood, cut off from their peers if they lack access to the platforms. The result is a daily erosion of trust, dialogue and connection — the very things that make a family a family.

Here we return to Anders and his Promethean gap: today’s parents are the first generation in history to have to protect their children from a threat they can neither see nor fully comprehend. It is not like protecting a child from traffic or alcohol: those are visible threats with known dynamics. Here the threat is an invisible architecture of algorithmic persuasion operating directly on the neurological reward circuits. It is like asking a parent in 1945 to shield their child from radiation without knowing what radiation is.

The World Is Already Reacting

The world — slowly, far too slowly, but undeniably — has begun to react.

The US Surgeon General, Vivek Murthy, compared social media addiction to cigarettes and called for the platforms to carry a health warning. In 2023 he cautioned that children spending more than three hours a day on social media double their risk of mental health problems.

In December 2025, Australia became the first country in the world to ban social media access for under-16s. The law requires platforms to take “reasonable steps” to prevent minors from creating or maintaining accounts, with fines of up to AUD 49.5 million for non-compliant companies. To date, over 4.7 million accounts have been deactivated, removed or restricted.

France, Norway, Denmark, Malaysia, Spain, Indonesia and Italy itself are considering or implementing similar measures. It is a global movement that, tellingly, is encountering resistance exactly where one would expect: from the platforms themselves (Reddit has filed a challenge in the Australian High Court) and from libertarian groups denouncing the infringement of minors’ freedom of expression.

It is the same dynamic we saw with tobacco, with asbestos, with lead in petrol: the industry that causes the harm fights regulation by invoking individual liberty and progress, while the harm accumulates silently in the bodies and brains of the victims.

The Question We Must Ask Ourselves

If progress is the expansion of our collective human capacity to live freely, with dignity and sustainably, then are social media — in their current form — progress?

The answer, it seems to me, is no. Not because the technology of digital connection is inherently bad, but because the way it has been implemented — engagement algorithms that exploit neurological vulnerabilities, business models built on addiction, a total absence of accountability for the damage caused — represents the antithesis of progress. It is the deployment of the most advanced neuroscientific knowledge to reduce human capacity rather than expand it.

If we could see the damage — if every thinning of the prefrontal cortex made a noise, if every episode of adolescent self-harm were a visible explosion — we would have reacted with the same urgency with which we react to a bomb. But the damage is silent. And silence is the greatest ally of those who cause and monetise it.

The thought experiment of the thought that kills, on reflection, is not so hypothetical after all. We have already given corporations the power to alter the brain development of billions of young human beings. The fact that they do so to sell advertising rather than out of malice does not make the damage less real. It only makes it harder to name.

Europe and the Humanist Choice

This is where we must talk about Europe. Not the Europe of grumbling — the Europe of triplicate forms and regulations on the curvature of bananas. But Europe as a philosophical project.

The European Regulatory Framework as a Choice of Civilisation

In recent years, the European Union has produced a body of technology regulation without parallel anywhere in the world: the GDPR for personal data protection, the Digital Services Act and Digital Markets Act for platform regulation, the AI Act for artificial intelligence, the Cyber Resilience Act for the security of digital products, and the updated Product Liability Directive extending to software and AI.

Seen from Silicon Valley, this is “bureaucracy stifling innovation.” Seen from the perspective of moral philosophy, it is something profoundly different: the most ambitious attempt in history to apply the principles of European humanism to the technological revolution.

Take the AI Act. Its structure — risk-based, with outright prohibitions on the most dangerous applications (social scoring, subliminal manipulation, mass biometric surveillance) and escalating requirements for high-risk ones — is a legislative translation of Jonas’s principle. It does not say “do not innovate”: it says “innovate, but not at the expense of human dignity.” It is not a brake: it is a rudder.

The extension of the Product Liability Directive to software is another example. For the first time, software producers will be liable for damage caused by their products — exactly as manufacturers of cars, medicines and household appliances already are. For those who have internalised the notion that software is an ethereal, immaterial entity exempt from the rules of the physical world, this is scandalous. For those who believe that power must be accompanied by responsibility, it is a civilisational advance.

The Digital Services Act and Digital Markets Act, moreover, are a direct response to the neurological catastrophe we have described. The DSA imposes transparency obligations on recommendation algorithms, bans the profiling of minors for advertising purposes, and gives users the option to switch off personalised recommendation systems. The DMA aims to break the monopolistic power of the major platforms — the “gatekeepers” who control digital access for billions of people. Are these imperfect instruments? Certainly. But they are the only instruments a democracy has at its disposal to respond to a power that, left unchecked, is quite literally rewiring the brains of its youngest citizens.

Accessibility as a Paradigm of Genuine Progress

The European Accessibility Act deserves special mention, because it perfectly embodies the difference between technical progress and human progress.

The EAA requires digital products and services to be accessible to people with disabilities. For a tech company focused exclusively on speed and efficiency, this is a cost, a constraint, a “drag on progress.” But let us pause for a moment: is an innovation that excludes a portion of humanity really progress?

If we define progress as the expansion of human possibilities — not the possibilities of some humans, but of humanity as a whole — then accessibility is not a constraint on progress. It is progress. A digital product that 15% of the world’s population cannot use is not innovative: it is incomplete.

Martha Nussbaum, in her capabilities approach (developed with Amartya Sen), formulated a theory of progress that points in precisely this direction: progress is measured not by GDP, not by the number of patents, not by processor speed, but by the effective capability of individuals to live a life worthy of being lived. If a technology increases this capability for everyone, it is progress. If it increases it for some at the expense of others, it is power — not progress.

Confusing Speed with Direction

There is a category error that pervades the entire contemporary discourse on innovation: the confusion between speed and direction.

“Move fast and break things” — Facebook’s original motto — is the epitome of this confusion. Moving fast is only a virtue if the direction is right. Otherwise, it is simply running towards a cliff with greater efficiency.

When Sam Altman says that “regulation risks slowing the development of AI,” the question nobody asks is: slowing it towards where? If the direction is the concentration of power in the hands of a few companies, the reinforcement of algorithmic bias, ubiquitous surveillance masquerading as personalisation — then slowing down is not a harm. It is wisdom.

Epicurus — the most materialist and least mystical of the ancient philosophers — taught that the purpose of life is ataraxia : tranquillity of mind, freedom from disturbance. Not the accumulation of power, not the conquest of nature, not speed. Tranquillity. A lesson the tech world appears to have forgotten entirely: not everything that is possible is desirable. Not everything that is fast is good. Not everything that is new is better.

Simone de Beauvoir, in The Ethics of Ambiguity (1947), offers another vital tool: freedom is never absolute, but always situated. We are free only in the context of relationships with other free beings. My freedom has meaning only if I recognise and preserve the freedom of others. Translated to the technological context: my freedom to innovate has meaning only if it does not destroy the freedom — the safety, the dignity, the autonomy — of those who will be affected by my innovation.

Progress as Collective Construction

It is time to propose an alternative definition. If progress is not simply technical innovation, if it is not speed, if it is not the accumulation of capability — what is it?

I propose this: progress is the expansion of our collective human capacity to live freely, with dignity and sustainably.

Every word matters. Expansion , because progress is an enlargement, not a replacement; it does not demolish what works in pursuit of the new. Human capacity , not the capacity of machines or markets but the capacity of real people to act in the world. Collective , because if it is not for everyone it is not progress: it is privilege. Freely , in the Millian sense of freedom to think, speak and live as one wishes, within the limits of harm to others. With dignity , in the Kantian sense of every person as an end in themselves, never merely a means. Sustainably , because it does not sacrifice the future for the present, does not steal from grandchildren to give to children.

With this definition, a great deal changes. Penicillin is progress. Universal suffrage is progress. Clean drinking water for all is progress. Digital accessibility is progress. The GDPR is progress.

The atomic bomb is not progress. Mass surveillance is not progress. An algorithm that maximises engagement through addiction is not progress. A platform that thins the prefrontal cortex of millions of adolescents to sell advertising is not progress. And the thought that kills — our opening hypothesis — is not progress. It is the end of progress. It is the end of everything.

Humanism as Compass, Not Chain

Let us return, in closing, to the opening question. When someone says that the state, or Europe, or the United Nations is “shackling progress,” what are they really saying?

They are saying — almost always — that their way of innovating, their business model, their vision of the future is being subjected to constraints they dislike. They are confusing their own freedom of action with the freedom of humanity. They are mistaking the absence of limits for the absence of oppression.

But the absence of limits is not freedom: it is the law of the strongest. It is the Hobbesian state of nature — the bellum omnium contra omnes , the war of all against all — in which life is “solitary, poor, nasty, brutish, and short.” Institutions, laws, mutual constraints are not chains: they are the foundations of coexistence. They are what makes possible not merely survival, but human flourishing.

Humanism — the real thing, the tradition that begins with Pico della Mirandola and runs through Montaigne, Hume, Voltaire, Mill, Arendt and de Beauvoir to Nussbaum — has never been against knowledge or technology. It has been against the use of knowledge and technology against the human. Humanism is the compass that enables us to distinguish genuine progress from the mere accumulation of power.

Those who build technology today bear an immense responsibility — probably the greatest any generation has ever borne. Not because technology is evil, but because technology is powerful. And power without responsibility, without limits, without the capacity to self-correct, is not progress.

It is just danger moving fast.

Postscript: A Personal Note

I have worked in technology for twenty years. I build software. I manage infrastructure. I configure CI/CD pipelines, write specifications, plan sprints. Technology is my trade and, in many respects, my passion.

Precisely because I know it intimately — its wonders and its miseries, its power and its fragility — I refuse, with every fibre, the idea that regulating it is a hostile act. When I implement the GDPR in a project, I am not “stifling innovation”: I am protecting the people for whom that project exists. When the AI Act asks me to document the risks of a high-risk system, I am not “wasting time”: I am doing my job with the seriousness it deserves. When the EAA obliges me to make an interface accessible, I am not “adding costs”: I am including human beings who would otherwise be shut out.

But there is another reason, more personal and more urgent, why this subject burns. I am also a father. And as a father, I live every day with the awareness that the digital world in which my child will grow up was designed by people who do the same job I do — people who know exactly what they are doing to the reward circuits of a developing brain. I know the design patterns, I know the metrics, I know the language in which “retention” and “engagement” strategies are discussed. I know that behind neutral words lie deliberately engineered mechanisms of addiction. And I know that my technical expertise is not sufficient to protect a child from an industry that has invested billions learning how to capture their attention.

This is why I believe that regulation is not merely legitimate: it is an act of civilisation. Those who build technology have a moral obligation to build it for human beings — not against them. And when they fail to do so, it is right and necessary that society — through its imperfect, slow, maddening institutions — should intervene.

Genuine progress has never been fast. It has been arduous, contentious, full of second thoughts and course corrections. It has been — to use Popper’s metaphor — a process of conjectures and refutations, not a triumphal march. And the institutions that govern it — imperfect, slow, occasionally exasperating — are the price we pay for not entrusting the fate of humanity to whoever happens to be running fastest.

That is not a high price. It is a bargain.

” The degree of civilisation of a society can be measured by the amount of power it is willing to relinquish.” — freely inspired by Norbert Elias, The Civilizing Process (1939)

This isn’t a “motivational” story. It’s more of a notebook thing, almost an anatomy. Because in hindsight I realize that every phase left me with a different lens. And today, as I work as Head of Tech and partner in a small ICT company, those lenses are finally starting to overlap.

The strange thing about non-linear careers

Linear careers may have never really existed, but for a while we believed in them. I definitely did. Then I found myself moving from Interface Developer at one of Europe’s largest luxury e-commerce groups (before it entered the Richemont orbit), to CTO at a deep-tech startup in oil & gas, all the way to managing a portfolio of projects that are very different from one another in a company of about ten people.

If I have to say what these stages have in common, it’s not the technology. That changes, and it changes faster than we like to admit. The common thread is something else: every role made me see how IT services are bought and sold. And above all, why decisions that look technical often aren’t technical at all.

Phase 1: inside a big player, from the code side

When you’re in a large organization and you’re not in management, you risk thinking certain dynamics don’t concern you. In reality they still run right through you—you just experience them “by reflection.” I was in the code, but working in a group at that scale makes you see things that stay invisible from the outside.

For example, how the relationship with technology vendors is actually managed. Not in theory, not in the deck, but day to day. I saw that behind an architectural choice there’s often an organizational choice, a budget choice, sometimes even a power choice. And I also saw a difference that annoyed me at first, then I understood it was simply real: vendors chosen for competence and vendors chosen due to contractual inertia are not the same thing, but on paper they look identical.

The first rule I carry with me from that phase is this—and maybe it’s a bit cynical, but it feels true.

The best vendor isn’t the one with the best proposal, it’s the one that understands how the client organization works.

It’s a rule that’s hard to put into a framework. It’s qualitative, contextual. And it requires an understanding of internal dynamics that you often only pick up by being there, by osmosis. I still wonder today how many bids and selections fail not because the provider isn’t capable, but because they didn’t read the client’s “nervous system.”

Phase 2: the startup, i.e., the real cost of choices

The jump to the startup was, without exaggeration, the one that changed me the most. As CTO of a deep-tech startup vertical in oil & gas, I found myself doing everything. Tech stack, hiring, processes, budget, clients, delivery. All at once, often on the same day.

And there you learn something that stays more blurred in big companies: the cost of decisions isn’t an abstract concept. It’s immediate. Every choice has a direct impact on the P&L, on time-to-market, on the team’s sustainability.

In that phase I learned to price IT services not “based on the market,” but based on the structure of real costs. Which sounds trivial until you crash into it. I also learned that a service priced too low is more dangerous than one priced too high, because sooner or later someone will pay the difference. And often the one who pays is the client, in the form of technical debt, delays, turnover, rushed patches.

Another important piece was contracts. Not the ones written to win a negotiation, but the ones that let you work. I understood that there are contracts that “protect” and contracts that “work.” The first are full of penalties no one wants to enforce. The second define aligned incentives, a collaboration zone where both parties have a reason to do the right thing.

The second rule, here, became almost a conviction.

The quality of an IT service is decided before the project starts, in the architectural choices and in the processes the provider sets up.

When the code starts flowing, many games have already been played. Not all of them, of course. But many.

Phase 3: the multi-client portfolio, where boundaries blur

Today I work in a small ICT company, about ten people, that operates as a B2B technology partner. Clients range from large corporates to Public Administrations. My role is a continuous intersection of technical leadership, sprint planning, DevOps, compliance, and architecture. And above all it’s “portfolio” work, so with very different contexts living side by side.

In the same period we might be involved in a regional healthcare information system, a people analytics SaaS platform, an industrial IoT infrastructure, cybersecurity services as a certified partner of a leading vendor, regulatory compliance projects, and custom development for the PA.

This phase is the one where the two previous experiences lock together. On one side I have the memory of the big player, so I understand how enterprise clients think, what truly worries them, what the implicit constraints are. On the other I have the startup sensitivity, so I know what it means to be efficient with limited resources, and how much automation and operational discipline matter.

But the new lesson—the one I didn’t expect—is another.

The IT services market is fragmented in ways many advisory frameworks don’t capture.

We’re not a generalist system integrator, but we’re not an ultra-specialized boutique either. We’re that slightly awkward thing to label: an agile technology partner with cross-cutting skills. And in certain contexts we compete with players ten times larger, not because we’re “better” in absolute terms, but because processes are leaner and, more and more, because AI-assisted development is changing the relationship between productive capacity and team size.

Maybe it’s here that I realized how much the map doesn’t match the territory. In quadrants and reports some categories are crisp. In real life, much less so.

What these phases taught me about IT sourcing

If I try to translate all this into practical implications for sourcing, three ideas come to mind—which are also three recurring “flaws” in the way providers are evaluated.

The first comes from the big company: sourcing decisions are often organizational decisions disguised as technical decisions. So whoever does advisory should understand the client’s internal dynamics as much as they understand the provider’s capabilities. Otherwise they risk recommending the “best on paper” and getting the worst in practice.

The second comes from the startup: the economics of IT services are far more granular than they appear in market reports. A provider’s margin on a single project can swing enormously based on architectural choices, the level of automation, process maturity. And if you don’t read these dynamics, you don’t truly protect the client. You only protect them formally.

The third comes from portfolio work: the real market is more diverse than frameworks suggest. The tech SMEs that serve Europe’s economic fabric often don’t show up in the quadrants, but they deliver a significant share of IT services. If you don’t know that segment, you’re offering clients an incomplete set of options. And you might not even realize it.

The cumulative value, and why it matters now

There’s a pattern I notice in careers that produce “non-conventional” value. It’s not the single experience that makes the difference, but the intersection.

An analyst who has only worked in consulting knows the frameworks, but maybe has never lived through delivery when things go wrong. A technician who has only worked in development knows the code, but doesn’t always see the business. A manager who has only worked in corporate knows the political dynamics, but risks losing touch with real costs and operational grind.

The meaning of my trajectory, if it has one, is crossing these worlds. And it seems to me that today this ability to connect is no longer a “nice to have.” With AI entering processes, European compliance becoming increasingly stringent, pricing models changing, reshoring and new expectations around security and data sovereignty, complexity isn’t going down. It’s going up.

And when complexity goes up, simple answers start to sound suspicious.

The next step, with a bit of honesty

Lately I feel that the natural evolution of this path is to bring this integrated perspective to those who have to make high-impact sourcing decisions.

Not as an operational consultant—that’s what I already do. Rather as a market analyst, researcher, strategic advisor. In a context where depth of operational experience and the ability to produce actionable insights are the core of the value proposition.

It’s the kind of role that some companies, with a lot of effort and a lot of investment, try to embody well.

Not because I have the right answers. On many things, honestly, I’m not even sure I have a single answer. But because I believe I have the right questions—the ones that come from having seen the IT services market from different angles. And maybe that’s exactly what’s most needed today.

Next in the series: how the European regulatory storm is redefining the criteria for evaluating IT providers, and why the advisory market still isn’t ready.

This isn’t a critique. It’s a structural observation. And it has real consequences on how sourcing decisions are made, and on how many of those decisions turn out to be wrong.

The job, seen from the inside

I spent more than fifteen years on the other side of the table. Not as someone who evaluates IT services, but as someone who designs them, sells them, delivers them, and is accountable when something doesn’t work.

At YNAP (Yoox for the older folks) I saw how one of the largest European e-commerce platforms managed the relationship with its technology vendors. Not in theory: in the day-to-day practice of architectural choices, negotiations over deliverables, decisions that determine whether a project delivers value or delivers only code.

As CTO of Anthis I built from scratch the technical infrastructure and delivery processes of a company. It’s the kind of experience that teaches you that the difference between an IT service that works and one that doesn’t is almost never in the technology chosen, but in the quality of the decision-making process that leads to that technology.

And today, as Head of Tech & Partner at Oltrematica (I know, this role doesn’t exist but we’ll get there), I run a portfolio of projects for clients ranging from TIM to Randstad, from the Abruzzo Region to the Chambers of Commerce. I write RFPs and respond to RFPs. I define SLAs and I have to meet them. I price managed services knowing exactly how much each component of the delivery chain costs.

This experience gave me access to a kind of knowledge that is hard—maybe impossible—to acquire from the outside.

The things you can only see from the inside

When I read provider evaluation frameworks (Magic Quadrant, PEAK Matrix, ISG Provider Lens) I recognize the quality of the analysis and the methodological rigor. But I also see the blind spots. And they’re always the same.

The real cost of an IT service isn’t in the price

The quoted price in a managed services offer is a number. The real cost is a complex system that includes the price, plus the cost of communication inefficiencies, plus the cost of technical debt that accumulates when the provider cuts corners to stay within budget, plus the opportunity cost of features that don’t get delivered because the contract doesn’t include them.

An analyst who evaluates providers by comparing day rates is measuring the wrong variable. A provider that quotes €400/day and delivers in 20 days costs less than one that quotes €300/day and takes 40. But to understand which one will deliver in 20 and which in 40, you need to know how to read the proposed technical architecture, the team composition, the level of automation in delivery processes.

It’s a competence that comes from having built those processes, not from having observed them.

SLAs are a language, not just a contract

In my experience, most problems in IT outsourcing contracts don’t come from wrong SLAs. They come from ambiguous SLAs.

An SLA that says “99.9% availability” is technically precise but operationally empty if it doesn’t specify: how is availability measured? Is scheduled maintenance included? What time window is used for the calculation? What happens when downtime is caused by a third party (the cloud provider, the CDN, the DNS)?

I’ve written SLAs for years. And I learned that a good SLA isn’t the one that promises more, but the one that defines with surgical precision what happens when things go bad. Because in IT services, things always go bad sooner or later. Provider quality is measured in the response, not in the promise.

Team composition matters more than size

Evaluation frameworks tend to reward providers with large teams and multiple delivery centers. It’s a reassuring metric for buyers: more people = more capacity. But anyone who has managed development teams knows it’s not like that.

A team of 5 well-coordinated senior developers produces more high-quality output than a team of 15 people with 3 layers of management and constant turnover. Especially when that team of 5 uses AI-native methodologies that multiply individual productivity.

At Oltrematica we simultaneously run 8–10 active projects with a team of about 10 people. Not because we’re heroes, but because we invested in automation, efficient delivery processes, tools that eliminate low value-added work. It’s the kind of efficiency that doesn’t show up in any quadrant.

The value of an operational perspective in advisory

I’m not suggesting that all analysts should have worked as IT providers. I’m suggesting that the operational perspective is a strategic asset in advisory that today is dramatically underrepresented.

When a CISO asks me whether a managed security provider is reliable, I don’t have to rely only on certifications and references. I can read the proposed architecture and understand whether it was designed to be operated or just to win the bid. I can look at the Statement of Work and identify the gray areas that will turn into contractual disputes 18 months from now. I can assess whether the proposed staffing model is sustainable or whether the provider is promising a team they don’t have and will have to build after-the-fact.

This kind of insight doesn’t come from analytical rigor. It comes from having lived the same dynamics on the other side. And it has enormous value for enterprise clients who are about to make multi-million-euro sourcing decisions.

The necessary convergence

The IT services advisory market is entering a phase where the complexity of sourcing decisions is increasing exponentially. AI, European compliance, reshoring, new pricing models, cybersecurity by design: these are all dimensions that require deep technical understanding to be evaluated correctly.

Generic frameworks are no longer enough. Clients ask for—and have the right to get —advisors who speak the providers’ language with the same fluency with which they speak the language of business.

It’s a convergence that the market hasn’t produced systematically yet. But it’s inevitable. And whoever anticipates it will have an enormous competitive advantage.

This article is the first in a series on my view of the IT services sourcing market. In the next piece I’ll explore my personal journey—from developer to partner—and how each phase helped build an integrated perspective on the IT services market.

Astral is the startup behind uv, Ruff, and ty—three tools that in just a few years have become load-bearing infrastructure for millions of Python developers. uv solved environment and dependency management with an elegance and speed that pip never had. Ruff made linting and formatting so fast they became invisible. ty is doing the same for type checking. They’re written in Rust, all open source, all permissively licensed. And as of yesterday, all owned by OpenAI, which will fold the team into Codex, its coding agent that already counts over two million weekly active users.

Three months ago, in December, Anthropic made a similar move by acquiring Bun, the JavaScript runtime created by Jarred Sumner. Claude Code, their agentic coding tool that hit one billion dollars in annualized revenue in six months, ships as a Bun executable. Sumner put it with almost brutal clarity in his announcement post: “If Bun breaks, Claude Code breaks.” So Anthropic bought the infrastructure that its billion-dollar product runs on.

Two acquisitions in three months, by the two companies fighting for dominance in AI-assisted coding. Look at them individually and each one makes sense. Look at them together and the pattern is unmistakable.

Here’s what the pattern is: the companies building language models are buying, piece by piece, the toolchain those models operate on. Not the cloud. Not the chips. Not the data centers. The tools that sit between the model and the code. The package manager. The linter. The runtime. The type checker. Everything an AI agent needs to go beyond generating code and actually run it, test it, validate it, and push it back to production.

This isn’t philanthropy toward open source. It’s infrastructure strategy.

Ninety-Five Percent Is Context

To understand what’s happening, you have to start with something that’s often underestimated: language models, on their own, generate code. But generating code is not building software. Anyone who’s tried to have an agent write an entire project knows this—you end up with something that compiles but doesn’t work, or works but doesn’t follow the repo’s conventions, or follows the conventions but breaks three tests nobody anticipated. Generation is five percent of the job. The other ninety-five percent is context: resolving dependencies, passing the linter, managing types, running tests, integrating into CI/CD, maintaining code over time as libraries update and requirements shift.

And here’s the point. An AI agent that wants to handle that ninety-five percent needs to own, or at least control, the tools that compose it. It’s not enough to know that uv exists. uv needs to respond to the agent’s needs, be optimized for its workflows, evolve in the direction that makes the agent more effective. The same goes for Ruff, for ty, for Bun. When OpenAI writes in its announcement that the goal is to “move beyond AI that simply generates code and toward systems that can participate in the entire development workflow,” that’s not marketing. It’s a precise description of why they bought Astral.

I see this every day in my work. I use Claude Code on Laravel projects, I manage CI/CD pipelines with GitHub Actions, and the difference between an agent that generates a file and an agent that understands the context that file has to live in is the difference between a useful tool and a toy. When the agent knows the rules of my linter, understands how my dependencies are structured, grasps my deployment flow—that’s when it actually becomes a collaborator. And to be that kind of collaborator, it has to speak the language of the tools I use. If whoever builds the agent also owns those tools, the competitive advantage is enormous.

A New Kind of Lock-In

But this is exactly where things get interesting. And a little unsettling. Because what’s emerging is a new kind of vendor lock-in, unlike anything we’ve seen before.

The old lock-in was explicit: you chose a cloud provider, you chose a proprietary database, and at some point migration became prohibitively expensive. You knew it, you did the math, you made the call. The new lock-in is different. It’s implicit. You don’t notice it happening because every single piece looks open source, looks free, looks neutral. uv is still MIT-licensed. Bun is still MIT-licensed. You can fork them, you can use them without Codex or Claude Code, you can do whatever you want. But the real question is different: two years from now, when eighty percent of uv’s evolution is driven by Codex’s needs, when the priority features are the ones that serve OpenAI’s agent rather than you running uv from the terminal—will forking actually be a viable option? Simon Willison, who has one of the sharpest minds in the ecosystem, wrote yesterday that the worst-case scenario takes the shape of “fork and move on.” But then he added, honestly, that OpenAI doesn’t yet have a track record in maintaining acquired open source projects. And that an acquisition that starts as product-plus-talent can turn, over time, into a talent-only acquisition.

This is a point I keep coming back to. The code stays open, but the direction becomes closed. It’s a form of control that doesn’t violate any license, doesn’t betray any explicit promise, and yet concentrates power in significant ways. Someone on Hacker News captured the dynamic well: “As they gobble up previously open software stacks, how viable is it that these stacks remain open?” Technical viability persists. Practical viability erodes.

I write this and I already hear the objections—the same ones I’ve made to myself. “But the incentives are aligned,” many say. “Anthropic needs Bun to work well for everyone, not just Claude Code, because broad adoption creates network effects.” And that’s true, at least today. “The MIT license protects the community,” others say. And that’s true too, at least in theory. But I’ve seen enough acquisitions in my career to know that the promises made on announcement day come with an unwritten expiration date. Jarred Sumner’s post was honest on this point: “No one can guarantee how motives, incentives, and decisions might change years down the line.” And I’d add that the incentives of a startup with zero revenue and four years of runway ahead look very different from the incentives of a division inside a company that burns two and a half dollars for every dollar of revenue and needs to justify every acquisition to investors waiting for an IPO.

The Battle for the Workflow

There’s another dimension that strikes me, and it has to do with how these acquisitions are redefining competition itself. Until yesterday, the battle between OpenAI and Anthropic was fought on model quality. Who reasons better, who generates cleaner code, who has the longer context window. Today the battle is shifting to a different plane: who controls more surface area of the developer’s workflow. It’s no longer just “my model is better than yours.” It’s “my model works inside an ecosystem I own and that optimizes every step.” Code generation becomes a commodity, and value migrates to orchestrating the entire cycle. Whoever owns the linter, the package manager, the runtime, and the coding agent has a structural advantage that no benchmark can capture.

The question I keep asking myself, and one that doesn’t have a clear answer yet, is what all of this means for those working with stacks other than Python and JavaScript. Many teams haven’t (yet) experienced this kind of concentration. But the pattern is clear, and it will expand. Today it’s Python and JavaScript because those are the languages of AI and the web. Tomorrow it could be any ecosystem where coding agents need reliable tooling to operate autonomously. The race to acquire the building blocks of development infrastructure has only just begun.

An analogy comes to mind—maybe a bit strained, but it helps me think. For decades, oil was the fuel of the industrial economy, and whoever controlled the refineries and pipelines held more power than whoever extracted the crude. In software, language models are the crude. They produce output. But the real value lies in the refinery: the tools that take that output and turn it into working, tested, compliant, deployed software. The AI companies have figured this out. And they’re buying the refineries.

A Political Choice

And we’re caught in the middle of this transition without having chosen it. We use uv because it’s the best tool available. We use Bun because it’s fast and solves real problems. Our choices are rational and individual. But the aggregate effect of millions of rational, individual choices is the concentration of infrastructural power in the hands of a few companies that didn’t build those tools. They bought them.

I don’t know where this leads. Maybe the incentives will stay aligned long enough to avoid real problems. Maybe the MIT license will prove to be sufficient protection. Maybe the market will remain competitive enough to prevent abuse. But maybe not. Maybe we’re building a dependency we’ll only recognize as such when it’s too late to walk away gracefully.

What I do know is that choosing your package manager, your runtime, your linter has never been a purely technical decision. Today, whether you like it or not, it ‘s also a political one. And like all political choices, it deserves to be made with open eyes.

In IT consulting, that moment is now.

The silent agreement was this: you pay us for our time, and we ‘ll do our best with it. It went by many names. Time & Materials, Staff Augmentation, Body Rental. The underlying pact was always the same. You rented human hours. You hoped those hours would produce something useful. Sometimes they did. Sometimes they didn’t. Either way, you paid.

For decades, this model worked well enough. Not because it was fair, or efficient, or good for anyone in particular. It worked because there was no alternative. Software was hard. Estimating it was harder. And nobody, not the client, not the vendor, not the developer staring at a blinking cursor at 2 AM, could reliably predict how long anything would take.

So we all agreed to pretend that time was a reasonable proxy for value. We built entire industries, entire careers, entire pricing spreadsheets on this fiction.

And then AI walked in and set the spreadsheet on fire.

I. The Comfortable Lie

Let me be precise about what Time & Materials actually is, because the industry has done an excellent job of dressing it up in language that obscures its fundamental nature.

T&M is a risk-transfer mechanism. That’s it. The vendor transfers the risk of estimation, of scope creep, of technical uncertainty, all of IT, to the client. The client pays for the attempt, regardless of the outcome. The vendor’s only obligation is to show up and try.

Now, if you described any other professional relationship this way, people would laugh you out of the room. Imagine hiring a plumber who bills by the hour with no guarantee your pipes will work. Imagine a lawyer who charges for research time but won’t commit to a legal strategy. Imagine a surgeon who bills per minute in the operating room, regardless of whether your appendix comes out or stays in.

And yet, in IT consulting, this was standard practice. Not just standard, but expected. Clients who pushed back were labeled “difficult.” Vendors who offered fixed prices were considered either naive or reckless.

The reason was always the same: software is different. Software is complex, unpredictable, creative work. You can’t estimate it like bricklaying. Requirements change. Technology evolves. The only honest pricing model is one that acknowledges this uncertainty.

This argument was not entirely wrong. Software is complex. Estimation is hard. But the conclusion, that the only honest response is to charge by the hour, was a spectacular non sequitur. The honest response would have been to get better at managing uncertainty, to build models that account for it, to develop shared-risk frameworks. Instead, the industry chose the path of least resistance: make it the client’s problem.

And clients went along with it, for the most intellectually depressing reason possible: they didn’t know any better. Most organizations buying IT services had no internal technical capability to evaluate what they were getting. They couldn’t distinguish between a developer who spent eight hours solving a problem elegantly and one who spent eight hours creating a new problem. The only metric they had was time. So time is what they bought.

This created a market where the incentives were not just misaligned but inverted. The worse you were at your job, the more you could charge. The longer something took, the more revenue you generated. Efficiency was not rewarded; it was punished. A consultant who solved a problem in two hours instead of twenty was leaving eighteen hours of billable time on the table.

Every honest person in the industry knew this. Most of us made peace with it. Some of us told ourselves stories about “investing in quality” and “thoroughness.” We weren’t lying, exactly. We were just not confronting the structural absurdity of a model that could not, by design, distinguish between thoroughness and waste.

II. Enter the Machine

In 2023, something changed. Not gradually, not subtly. Like a light switch.

Large language models (ChatGPT, Claude, Copilot, and a growing menagerie of AI coding assistants) started doing things that developers used to do. Not all things. Not perfectly. But a non-trivial portion of the daily work of software development suddenly became automatable. Boilerplate code. API integrations. Test generation. Data transformations. Documentation. Migration scaffolding. The repetitive, mechanical, billable parts of the job.

The numbers varied depending on who you asked and what they were measuring, but the direction was unmistakable. Tasks that used to take hours now took minutes. Work that required a senior developer could be roughed out by a junior with AI assistance. Entire categories of effort, the kind that padded project timelines and kept T&M invoices healthy, started evaporating.

Now, if you were a consultant billing by the hour, this created an existential problem. Not a strategic challenge, not a market shift. An existential problem. Because the value you were selling was, at its core, the time it took a skilled human to do something. And suddenly, that time was collapsing.

Let me make this concrete. Say you’re a consulting firm, and a client asks you to build an integration between their CRM and their ERP. In 2022, your senior developer would scope it at 80 hours. In 2024, with AI-assisted development, the same work takes 25 hours. The quality is the same. The outcome is the same. The client gets the same integration.

What do you charge?

If you bill 25 hours, you’ve just lost 69% of your revenue on that project. If you bill 80 hours anyway, padding time sheets, inventing complexity, stretching the work, you’re committing fraud, or something close enough to fraud that the distinction is academic.

This is not a hypothetical dilemma. This is happening right now, in every consulting firm that hasn’t yet figured out how to escape the T&M trap. And the uncomfortable truth is that most of them haven’t. They’re doing what humans always do when the ground shifts under their feet: pretending it isn’t shifting.

Some firms are hiding AI usage from clients, billing full human hours for AI-assisted work. Some are explicitly banning AI tools internally, not for quality reasons, but because their entire business model depends on human inefficiency. Some are using AI internally while maintaining T&M pricing, pocketing the productivity gains without passing them to clients.

None of these strategies are sustainable. All of them are, in various degrees, dishonest. And all of them will fail, because the arbitrage between what AI can do and what humans used to do is growing too fast to conceal.

III. What Actually Has Value Now?

Here is the question that keeps thoughtful consultants awake at night: if AI can generate the code, write the tests, draft the documentation, and scaffold the architecture, what exactly is left for us to sell?

The answer is everything that matters.

The great irony of the AI revolution in IT consulting is that it didn’t destroy value. It revealed it. For decades, the real value of good consulting was buried under layers of mechanical work. The strategic thinking, the domain expertise, the architectural judgment, the ability to translate business needs into technical decisions: all of this was mixed in with the grunt work and charged at the same hourly rate. You couldn’t separate the wisdom from the typing.

Now you can. Or rather, you have to.

What clients actually need from IT consultants has never been code. It has never been hours. It has always been (though the industry was remarkably good at obscuring this) outcomes. A working product. A solved problem. A risk mitigated. A capability unlocked.

When a manufacturing company hires an IT firm to build a predictive maintenance system, they don’t care how many hours it takes. They care whether it works. They care whether it reduces downtime. They care whether the investment pays for itself. The hours are an input, not an output. They were always an input. But T&M trained everyone, buyers and sellers alike, to confuse the two.

The things that actually create value in IT consulting are precisely the things that AI can’t easily replicate:

Understanding the problem. Not the technical requirements, which are usually symptoms. The actual business problem. The organizational dynamics. The political constraints. The unspoken assumptions. This requires human judgment, empathy, and often the willingness to tell a client something they don’t want to hear.

Making irreversible decisions well. Architecture. Technology selection. Build-vs-buy. Data modeling. Security posture. These are decisions that compound over time, that are expensive to reverse, and that require the kind of experience that comes from having made the wrong choice before and lived with the consequences.

Taking responsibility. This is the big one, and I’ll come back to it. AI can generate options. It can analyze tradeoffs. But it cannot take responsibility for a decision. It cannot stake its reputation on a recommendation. It cannot be held accountable when something goes wrong at 3 AM on a Friday. This is not a limitation of the technology. It is a feature of being human.

Navigating complexity. Not technical complexity, but organizational complexity. Compliance requirements, regulatory constraints, security obligations, accessibility mandates, data governance. The kind of complexity that requires understanding not just what to build, but what you’re allowed to build, what you’re required to build, and what you’ll be liable for if you build it wrong.

Building trust. In an era where AI can generate plausible-looking anything (code, documentation, security reports, compliance matrices) the question shifts from “can you produce this?” to “can I trust what you produced?” Trust is a human commodity. It requires track record, accountability, transparency, and skin in the game.

IV. The Value-Based Revolution (That Everyone Talks About and Nobody Does)

Value-based pricing is not a new concept. Management consultants have been talking about it for thirty years. McKinsey doesn’t charge by the hour. Neither does a good surgeon. Neither does an architect who designs a building that will stand for a century.

But in IT consulting, value-based pricing has always been the thing you admired from a distance, like a beautiful car you couldn’t afford. The industry had a hundred reasons why it wouldn’t work:

” We can’t estimate accurately enough.”
” Scope always changes.”
” Clients won’t pay upfront.”
” It’s too risky for us.”

These objections were all valid, and they were all excuses. They were valid because T&M had created an ecosystem that made them true. When you’ve spent decades avoiding estimation risk, you never develop the muscles to manage it. When you’ve never committed to an outcome, you don’t learn how to deliver one reliably. The model was self-reinforcing: T&M created the conditions that made T&M seem necessary.

AI has broken this cycle. Not by solving estimation (estimation is still hard) but by making the alternative untenable. When the time component of your value proposition collapses, you don’t have the luxury of comfortable excuses anymore. You have to figure out value-based delivery, or you die.

Here’s what value-based IT consulting actually looks like in practice:

You sell outcomes, not effort. The deliverable is not “200 developer-hours.” It’s “a working predictive maintenance system that reduces unplanned downtime by 15%.” The client doesn’t care whether it takes you 200 hours or 20. They care whether it works.

You absorb risk, not transfer it. This is the fundamental inversion. In T&M, the client bears all the risk. In value-based models, the vendor bears some or all of it. If the system doesn’t work, the vendor doesn’t get paid, or gets paid less. This requires confidence in your ability to deliver, which means you have to actually be good at what you do, not just good at billing for it.

You price based on the value created, not the cost incurred. If a system saves a client $2 million per year, a fee of $300,000 is reasonable even if it only took you a month to build. This makes some people uncomfortable. It shouldn’t. The alternative, charging $50,000 because it only took 500 hours, rewards inefficiency and penalizes expertise.

You invest in capabilities, not headcount. Under T&M, revenue scales with the number of billable humans. Under value-based models, revenue scales with the ability to solve increasingly complex problems. This means investing in AI tools, methodologies, domain knowledge, and process, not just hiring more bodies.

You build long-term relationships, not projects. When you sell outcomes, the relationship doesn’t end at deployment. You’re accountable for the ongoing performance of what you delivered. This creates recurring revenue, deeper client relationships, and a natural moat against competitors who are still selling hours.

V. The Responsibility Problem (Or: Why Most Consultancies Will Fail)

I’ve talked to dozens of IT consultants in the past year about the shift to value-based models. Almost all of them agree it’s the right direction. Almost none of them are doing it.

The reason is not strategic complexity or market conditions. The reason is fear. Specifically, the fear of responsibility.

T&M is comfortable because it is fundamentally irresponsible, in the literal sense. The vendor is not responsible for outcomes. They are responsible for showing up and trying. If the project fails, if the software doesn’t work, if the client’s business suffers… well, the vendor did their best. They logged their hours. They followed the requirements (that the client wrote). The failure, structurally, belongs to the client.

Value-based models obliterate this safety net. When you sell an outcome, you own that outcome. When it doesn’t work, it’s your problem. When the client isn’t happy, you can’t point to a timesheet and say “but we put in the hours.” You are, in the most uncomfortable possible way, accountable.

Most consultancies, if they’re honest with themselves, are not equipped for this. Not because they lack technical talent (many of them have excellent people) but because their entire organizational structure, culture, and incentive system is built around T&M. Their project managers track hours, not outcomes. Their quality processes measure effort, not results. Their commercial teams sell rates, not capabilities.

Transforming a T&M consultancy into a value-based one is not a pricing change. It’s an identity change. It requires:

• Ruthless honesty about what you ‘re actually good at. T&M lets you fake it: take on projects outside your competence and figure it out on the client’s dime. Value-based models don’t. If you commit to an outcome, you’d better be damn sure you can deliver it.

• Genuine investment in methodology. You need estimation frameworks that work, delivery processes that are predictable, and quality assurance that catches problems before they reach the client. T&M firms often neglect these because they don’t need them. If the project runs over, they just bill more hours.

• A different kind of leadership. T&M leaders manage utilization rates and headcount. Value-based leaders manage client outcomes and delivery risk. These require fundamentally different skills, temperaments, and metrics.

• Skin in the game. This is the hardest part. Value-based models require you to put your money where your mouth is. To accept that if you fail, you lose. To operate with the kind of commercial courage that T&M was specifically designed to avoid.

Most firms will not make this transition. Not because they can’t, but because they won’t. The comfort of T&M is a powerful narcotic. Many consultancies would rather die slowly on hourly billing than take the risk of committing to results.

And many of them will die. Slowly, then quickly.

VI. A Letter to the Buyer

So far, I’ve been hard on vendors. Fairly, I think. But the T&M problem is not just a supply-side problem. Buyers are complicit. And if AI is going to improve IT consulting, buyers need to change too.

Dear CTO / CIO / VP of Technology / Procurement Director / Whoever Signs the Checks:

You need to hear something uncomfortable. You helped create this mess.

For years, you’ve been buying IT consulting like you buy office supplies, by unit cost. You compared vendor proposals by looking at daily rates. You chose the cheapest option. You measured success by hours consumed versus hours budgeted. You treated software development like an assembly line, where more hours in meant more product out.

And when projects failed, as they so often did, you blamed the vendor for poor execution, never examining whether you had created the conditions for failure by buying the cheapest time at the lowest rate.

You rewarded the wrong things. You incentivized volume over value, speed over quality, compliance over courage. And then you complained that vendors never challenged your thinking, never pushed back on bad requirements, never told you that your project was doomed from the start.

They didn’t tell you because you were paying them by the hour. A consultant who tells you “this project shouldn’t exist” is a consultant who just talked themselves out of six months of billing. T&M punishes honesty. You built the system. You get the behavior the system incentivizes.

Here’s how to buy IT consulting in the post-AI era:

Stop buying hours. Start buying outcomes. Define what success looks like, in business terms, not technical terms, and ask vendors to commit to it. Yes, it will cost more upfront. No, it won’t cost more in total. You’ve been paying for failed projects for years; you just spread the cost across enough timesheets that it didn’t look like failure.

Pay more for better vendors. The cheapest vendor is never the cheapest. This has always been true, but AI makes it even more true. A vendor who uses AI effectively and commits to outcomes will charge a higher fixed price than a vendor who bills junior developers at $40/hour. The first vendor will cost you less. The math is not complicated.

Stop writing detailed technical requirements. I know this sounds heretical. But detailed technical requirements are the client’s way of pretending they can manage risk by specifying everything upfront. They can’t. Requirements are always wrong, always incomplete, always outdated by the time the project starts. Instead, describe the problem. Describe the desired outcome. Describe the constraints. And then let the professionals figure out the solution. That’s what you’re paying them for.

Demand transparency, not timesheets. You don’t need to know how many hours someone worked. You need to know whether the project is on track, whether the risks are manageable, and whether the outcome is still achievable. Ask for those things. Build relationships with vendors who will tell you the truth, even when the truth is uncomfortable.

Accept that good work costs money. The race to the bottom on consulting rates has produced exactly what you’d expect: an industry full of mediocre work by underpaid, unmotivated people managed by firms whose primary competence is bench management. If you want excellent work, pay for it. If you want accountability, pay for that too. Value-based pricing means you’re paying for the vendor’s confidence in their ability to deliver. That confidence is worth something.

Build internal capability. This is the one that hurts the most, because it means spending money on your own team instead of outsourcing everything. But in the AI era, the organizations that thrive will be the ones that can evaluate what they’re getting. You don’t need to build everything in-house. But you need enough internal expertise to be an intelligent buyer, to evaluate proposals, challenge architectures, and recognize quality when you see it.

VII. The Trust Economy

Let me zoom out for a moment and talk about what’s really happening here. Not just in IT consulting, but in the economy at large.

AI is creating a world where production is cheap and verification is expensive. Any consultant can now produce a working prototype in hours. Any developer can generate thousands of lines of code in minutes. Any firm can create polished documentation, architecture diagrams, and compliance reports at the push of a button.

The question is no longer “can you produce this?” The question is “should I trust what you produced?”

This is a profound shift. For most of industrial history, production was the bottleneck. If you could make something, you had value. The ability to produce was scarce, and scarcity creates value. AI is making production abundant. And when production is abundant, the bottleneck moves elsewhere.

It moves to trust.

Can I trust that this code is secure? Can I trust that this architecture will scale? Can I trust that this system complies with regulations? Can I trust that the vendor will support this when something goes wrong? Can I trust that the AI-generated test suite actually covers the edge cases that matter?

Trust is not automatable. It is built through demonstrated competence, through transparency, through accountability, through the slow accumulation of evidence that someone knows what they’re doing and will stand behind their work. It requires reputation, track record, and, critically, the willingness to be wrong and make it right.

In the trust economy, the winning IT consultancy is not the one with the most developers. It’s not the one with the lowest rates. It’s not even the one with the best AI tools (though those help). It’s the one that clients believe. The one that has earned the right to say “trust us, this is the right approach” and be believed.

This is why the shift from T&M to value-based pricing is not just a commercial strategy. It is a trust signal. When a vendor says “we’ll charge you $200,000 for this outcome, and if we don’t deliver, we’ll make it right,” that vendor is putting their money where their competence is. They are saying, in the most credible way possible: we are confident enough in our abilities to accept the risk.

T&M sends the opposite signal. It says: we’re not confident enough to commit to an outcome, so we’ll charge you for the attempt. In a world awash with AI-generated output, where anyone can produce something, the vendor who won’t commit to the quality of their output is telling you everything you need to know about how much they trust their own work.

VIII. What This Means for Developers

I want to address the engineers directly, because they’re the ones most anxious about all of this, and they’re also the ones best positioned to thrive.

If you’re a developer who has built your identity around writing code, I understand the discomfort. Code was your craft. You were proud of elegant solutions, clean architectures, well-tested systems. And now an AI can produce something similar in seconds.

But here’s what you need to understand: your value was never the code. Your value was the judgment that produced the code. The decision about what to build. The understanding of why this approach and not that one. The knowledge of what will break at scale, what will be impossible to maintain, what will create security vulnerabilities, what will violate compliance requirements.

AI is a lever. It amplifies capability. If you’re a developer with deep understanding, AI makes you devastatingly effective. You can now execute at ten times the speed, which means your judgment, the thing that was always your real value, is applied ten times more often. You’re not less valuable. You’re more valuable, if you invest in the things that matter.

What matters now:

Domain expertise. Understanding the business problem, the regulatory environment, the operational constraints. A developer who understands healthcare compliance and can build systems that satisfy it is worth ten developers who can write code but can’t navigate HIPAA.

Architectural thinking. The ability to make system-level decisions that compound over time. AI can generate components. It cannot design systems. Not yet, and not well. The developer who can look at a business requirement and design an architecture that will serve it for five years, considering scalability, maintainability, security, compliance, and cost: that developer is irreplaceable.

Quality judgment. AI generates plausible output. But plausible is not correct. The ability to evaluate AI-generated code, to spot the subtle bugs, the security holes, the performance antipatterns: this is a new and critical skill. It requires deep knowledge, not just of coding, but of systems, of failure modes, of edge cases.

Communication. The ability to explain technical decisions to non-technical stakeholders. To translate between business language and engineering language. To write specifications that are precise enough for AI tools and clear enough for humans. This was always valuable. It’s now essential.

Specification-driven development. This is where the industry is heading. The developer’s primary artifact is no longer code but the specification. The detailed, precise description of what needs to be built, how it should behave, what constraints it must satisfy. AI turns specifications into code. The developer’s job is to write specifications that produce the right code. This is a fundamentally different skill from writing code directly, and it rewards the same things that good engineering has always rewarded: clarity of thought, precision of expression, and deep understanding of the problem.

If you invest in these things, the AI era is not a threat. It’s a liberation. You can stop spending 70% of your time on boilerplate and start spending it on the work that actually matters.

IX. The Compliance Accelerator

There’s a dimension to this that most commentators miss, because most commentators don’t think about regulatory compliance until it bites them.

In Europe, and increasingly everywhere else, software is becoming a regulated product. The AI Act, the Cyber Resilience Act, the Product Liability Directive, the European Accessibility Act, NIS2, GDPR. The regulatory landscape is not just growing, it’s compounding. Each new regulation adds requirements that interact with existing regulations in complex ways.

This changes the IT consulting equation in two critical ways.

First, it makes value-based pricing easier to justify. When the cost of non-compliance is measured in millions of euros in fines, the value of compliant software becomes quantifiable. A consultancy that can demonstrate compliance, with SBOMs, with security audits, with accessibility testing, with AI governance frameworks, can price based on the risk they’re mitigating, not the hours they’re spending.

Second, it makes T&M actively dangerous. Under the Product Liability Directive, software is a product. If it harms someone, someone is liable. Under T&M, who is liable? The vendor provided hours. The client accepted the deliverable. The responsibility is diffused to the point of evaporation. Under value-based models, the vendor commits to an outcome that includes compliance. If it’s not compliant, it’s the vendor’s problem to fix. This is not just better pricing. It’s better accountability.

Compliance is not a cost center. It’s a trust signal. In a market flooded with AI-generated software of uncertain quality, the firm that can prove its output meets regulatory requirements has a massive competitive advantage. Not because compliance is exciting (it isn’t) but because it’s verifiable. In a trust economy, verifiable quality is the scarcest commodity there is.

X. The Uncomfortable Predictions

Let me end with some predictions. They’re uncomfortable. I believe they’re correct.

Within five years, T &M will be a niche model. It won’t disappear entirely. There will always be genuine exploration and research work where time-based billing makes sense. But for mainstream software development and IT consulting, T&M will become what it always should have been: an exception, not the default. Clients will demand outcome-based contracts. Vendors who can’t provide them will lose business to those who can.

The IT consulting industry will consolidate dramatically. The AI productivity gains create enormous economies of scale. A small firm with excellent methodology, deep domain knowledge, and effective AI tools can deliver what used to require a large team. This favors small, specialized, high-competence firms over large, generalist body shops. The middle will hollow out. You’ll have boutique experts and commodity platforms, with very little in between.

Developers who resist the shift will struggle. Not because their skills are worthless (coding knowledge is foundational) but because the market will increasingly reward the application of that knowledge, judgment, architecture, specification, over the mechanical expression of it. Developers who cling to coding as an identity rather than a tool will find themselves competing with AI on AI’s terms. They will lose.

Clients who continue buying hours will get worse outcomes. As the best vendors shift to value-based models, the T&M market will be left with the vendors who can’t or won’t commit to outcomes. These are, almost by definition, the worst vendors. Buying hours will become a signal of unsophistication, a way of telling the market that you don’t know how to evaluate quality, so you’re settling for the only metric you understand.

Trust will become the primary differentiator. Not technology, not price, not speed. Trust. The ability to say “we will deliver this, and we stand behind it” and have that statement be credible. Every other competitive advantage, AI tools, methodology, domain expertise, will be in service of this one thing.

Epilogue: A Confession

I work in a small IT company. We build software for healthcare organizations, public administration, finance, manufacturing. We have, for most of our existence, billed by the hour. T&M. Staff augmentation. The works.

I’m not writing this from a position of superiority. I’m writing this from a position of reckoning.

When AI started accelerating our development, we had the same uncomfortable conversations every honest consultancy is having. Our developers were suddenly three, four, five times more productive. Our project timelines were collapsing. And our billing model, the model that paid our salaries and our rent, was predicated on those timelines being long.

We could have hidden the AI usage. We could have padded timesheets. We could have maintained the fiction. Some of our competitors are doing exactly that. We chose not to.

Not because we’re morally superior (we’re not). But because we could see where it was heading. The arbitrage is too large and growing too fast. Clients will figure it out. Some already have. And when they do, the firms that were honest about the shift will be the ones they trust. The ones that hid it will be the ones they never work with again.

So we’re making the transition. Painfully, imperfectly, but deliberately. We’re restructuring our proposals around outcomes. We’re investing in compliance capabilities that justify value-based pricing. We’re training our team to think in specifications rather than code. We’re building the processes and methodologies that allow us to commit to outcomes with confidence.

It’s terrifying. It’s also the most honest thing we’ve ever done.

Because the truth is, T&M was never honest. It was never fair. It was just familiar. And in an industry that claims to be about innovation, clinging to a broken model because it’s familiar is the most inexcusable thing of all.

AI didn’t kill Time & Materials.

AI just made it impossible to pretend it was ever alive.

“legal will handle it”.

I’m not saying it to be cynical. It’s just that, in 2026, that sentence risks becoming one of the most expensive ones a European software company can say.

Because what’s coming doesn’t look like a policy update or a round of notices. It looks much more like a change of foundations. And, even more inconveniently, it comes with very tight deadlines.

The perfect storm: five deadlines in far too short a window

If you build software for the European market, the calendar is no longer a detail to keep in a shared file. It’s a timeline that seeps into your architecture.

Between the end of 2024 and 2026, regulations pile up that, taken one by one, you might manage—barely. Together, though, they slot together on purpose.

NIS2 has already been in force since October 2024 and it expanded the perimeter of who needs to take cybersecurity seriously, including the supply chain. And here the first surprise often hits: you don’t have to be “critical” to feel the effects. You just have to be a supplier to someone who is.

The European Accessibility Act has already been in effect since June 2025 and, regardless of how it will be interpreted in different contexts, it moves accessibility from the world of “improvements” to the world of “requirements”.

Then 2026 arrives, which is the year the knot tightens.

In August 2026 the AI Act enters full application for high-risk systems. It’s not just a matter of ethics or transparency. We’re talking conformity assessments, technical documentation, data governance, human oversight. And yes, real penalties too, up to 3% of global turnover or 15 million.

In September 2026 the Cyber Resilience Act brings obligations that, as they’re written, you can’t “add later”. Among these is reporting actively exploited vulnerabilities within 24 hours and serious incidents within 72 hours. And the part many underestimate is this: it doesn’t apply only to future products. It also applies to what you already have on the market. Legacy included.

In December 2026 the Product Liability Directive redefines what a “product” is in the digital era. Software, even standalone or in SaaS form, becomes a product in every sense, with strict liability. Bugs stop being just an operational annoyance and become potentially a product defect, with direct legal consequences. And responsibility doesn’t end at release, it ends when you no longer have the ability to provide updates.

And in the background there’s GDPR, which never went away, with enforcement that’s getting less and less shy.

Maybe the most destabilizing thing is that these rules don’t add up linearly. They reinforce each other.

The fundamental mistake: treating compliance like an external layer

The most common reaction is understandable: “let’s call the consultant, update the policies, fix the documentation, do the checklists”. It’s the approach we could call compliance-as-paperwork.

With GDPR, as badly as it was often done, this strategy sometimes held. You could paste a set of processes, notices, registers, roles on top of an existing system.

With the 2026 package it doesn’t hold anymore. And not because there’s a lack of goodwill. Because there are requirements that, if they aren’t supported by your architecture and by how you build and ship software, simply don’t exist.

Let’s take the most concrete case possible: to comply with the CRA, when an actively exploited vulnerability emerges, you must be able to react and report within the required timeframes. But to do that you have to know precisely what’s inside your product. Not “more or less”. Exactly.

Direct dependencies, transitive ones, components, versions, builds. Everything.

That takes you straight to an object that is not legal and not bureaucratic: the SBOM, Software Bill of Materials. And not an SBOM in PDF generated once to make someone happy. A living SBOM, regenerated on every build, in a machine-readable format, integrated into the pipeline.

If your build process doesn’t produce an SBOM as a natural output, it’s not that “you’re a bit behind on compliance”. It’s that you can’t be compliant, period.

And here, in my opinion, the most important sentence in this whole discussion becomes clear: compliance isn’t a requirement you add. It’s an emergent property of your architecture.

Compliance as an architectural constraint

In software architecture we’re used to constraints. Latency, availability, scalability, compatibility, costs. They’re things that narrow the space of possible solutions.

Well, EU compliance 2026 is an architectural constraint. Not a ticket to assign “at the end of the project”, not a document to produce “before the tender”. A constraint that cuts across the system.

And when you look at it that way, some consequences become almost obvious.

Observability is no longer an extra

The AI Act, for certain systems, requires logs and traceability. The CRA pushes you toward detection and response capabilities. The PLD puts you in a position where you must be able to prove the state of the software at the time of the incident.

If you don’t have sufficient audit trails, it’s not that “you monitor too little”. You’re building a system that can’t withstand the questions the market and regulations will ask you.

Dependency management becomes a critical process

For years we normalized the idea that updating libraries is work you do “when there’s time”. A rushed npm install, a lockfile nobody looks at, an update postponed because “it works anyway”.

With CRA and NIS2, that lightness becomes supply chain risk. And supply chain risk, in 2026, doesn’t stay confined to the technical department. It propagates into contracts, tenders, partnerships.

The question you must be able to answer is very simple and very hard: “does this newly released CVE impact our products in production?”. And the answer has to come in minutes or hours, not weeks.

The concept of “finished product” falls apart

The PLD and the CRA, together, make the idea that a release closes a chapter less credible. Shipping becomes the start of a long-term relationship with a system that must be maintained, monitored, cared for.

This also changes how we estimate, plan, sell. Because part of the value, and of the responsibility, lives after delivery.

Accessibility is a property of the design system

The EAA isn’t kind to retrofits. If you have an accessible-by-default design system, you have a structural advantage. If you have to “make accessible” a frontend that grew for years without rules, the amount of findings you get back can become unmanageable.

And here I often wonder whether we’re underestimating how much accessibility is, in reality, a form of internal standardization. Not just an external requirement.

Human oversight isn’t a button

One of the most common misunderstandings about the AI Act is thinking that “human oversight” means adding an approval step at the end.

In practice, it’s a flows topic: where a human can intervene, with what information, with what ability to override, and with what traceability. It’s decision-process architecture even before software architecture.

The intersection many aren’t looking at

The most interesting point, and maybe the most dangerous, isn’t the individual obligations. It’s how they fit together.

The PLD says a software product is defective if it doesn’t meet applicable cybersecurity requirements. The CRA defines an important part of those requirements. The AI Act adds specific requirements when there’s AI.

So non-compliance with the CRA can become a product defect under the PLD.

We’re no longer talking only about an administrative fine or a non-conformity “to fix”. We’re talking about civil liability for damages, with dynamics like reversal of the burden of proof.

And to defend yourself, you must be able to prove the product was compliant at the time of the incident. Which, again, brings you back to SBOM, audit trail, logging, technical documentation. Not as compliance theater, but as defensive architecture.

The Italian paradox: fragile, but fast

Here comes a piece that I feel very close to, because it’s the everyday reality of many companies I talk to.

The Italian software fabric is largely made of SMEs: teams of 5 to 20 people, vertical products, growth by layering, roadmaps dictated by customers, technical debt accumulated with a feature-first logic.

Many of these companies are unprepared. Not out of inability, but because of structure.

And yet there’s a paradox: the same structure that makes them vulnerable can turn into an advantage.

A 10-person company, if it truly decides to, can redesign important parts of its architecture in 12 months. A large organization often takes months just to understand what it has in production.

A small team knows its domain and its product intimately. It can do a realistic gap analysis in weeks.

And a founder-CTO who invests today in compliance-by-design can move within a window that, in 18 months, will already be closed. Not because it will be impossible, but because it will be too late to do it calmly.

Compliance-by-design: architectural decisions, not slogans

When I say compliance-by-design I don’t mean “doing things properly” in a generic way. I mean concrete choices you can start making now, even without revolutionizing everything.

The SBOM as a first-class artifact, for example. Every build produces an SBOM in CycloneDX or SPDX format. The pipeline generates it, stores it, compares it with vulnerability databases, and if needed blocks a deploy. Tools like Syft, Grype, or Trivy make this much more accessible than it sounds.

Then there’s the audit trail, but not the one from system logs. A domain audit trail: who did what, when, why, with what role, in what context. It can be event sourcing or an append-only log, but the idea is that it’s a first-class citizen of the data model.

Technical documentation as code is another key point. If documentation lives in a manually updated wiki, sooner or later it stops representing reality. If instead you use versioned ADRs, declarative specs, and documentation generated from code, then documentation becomes an inevitable byproduct of the work.

And vulnerability management can’t be an annual event. It has to be a continuous process: automated scanning, triage, remediation with defined timelines. When the report of an actively exploited vulnerability comes in, the system must help you react within hours.

On accessibility, the thing I’ve seen truly work is treating it as design tokens and as a rule of the design system. If components are born accessible, the product tends to stay that way. If you have to fix it later, every new screen adds debt.

AI-native development as an accelerator, not just a risk

There’s a small irony in the fact that the AI Act arrives while AI is changing the way we write software.

Many see AI-native development as a risk for compliance: more generated code, less control. I suspect that, in many cases, the opposite is true.

A spec-driven approach, where software is born from declarative, readable and verifiable specifications, is inherently more favorable to conformity. Because specs are documentation. Because they’re versioned. Because they make explicit assumptions that otherwise stay in the head of whoever wrote that piece of code two years ago.

Tools like project files such as claude.md, Speckit, pipelines that generate compliance artifacts as part of the flow, aren’t science fiction. They’re a different way of working, one that can make it easier to produce evidence, traceability, reconstructability.

Maybe the future isn’t “writing more documentation”. It’s building software so that documentation is inevitable.

The real cost of non-compliance is much closer than a fine

Penalties are impressive, but for many SMEs they remain abstract. It’s not fear of the fine that changes priorities.

The real cost is more everyday.

It’s the public tender you can’t participate in because you don’t meet the security requirements in the specs.

It’s the enterprise customer who asks you for the SBOM and you don’t know where to start.

It’s a partner who does supply chain risk management and excludes you from the shortlist.

It’s an incident you can’t handle within the timeframes required by the CRA and that gets entangled in a tougher liability context.

For many Italian companies, these aren’t theoretical scenarios. They’re things that look a lot like 2027.

The window is now, and deep down it’s about good engineering

As a software architect, with my head often split between roadmap, budget, technical debt, and market demands, I understand well how all this can feel overwhelming.

But there’s one aspect worth keeping front and center: many of the practices required by these regulations are simply good engineering.

Generating an SBOM is good engineering. Having an audit trail is good engineering. Managing dependency vulnerabilities is good engineering. Documenting architectural decisions is good engineering. Building accessible interfaces is good engineering.

What EU compliance 2026 is doing, perhaps, is making mandatory what we should have been doing anyway. It’s turning best practices into a baseline.

And it’s creating a market where those who treat compliance as an architectural problem, and not as a practice to delegate to legal, end up with software that’s more robust, more maintainable, and also more sellable.

The window to build that advantage is open now. In eighteen months, those who haven’t started will be chasing. Those who start now will probably find themselves on the other side.

Not a prototype thrown together just because, not a mockup with the implicit “we’ll fix it later.” I mean something actually alive, with a domain, a working backend, a usable interface. Something a real user can open right now and use.

It took me 17 minutes. I didn’t write a single line of code. I talked to an AI tool.

The result is music-map.uk, an app that answers a question you may have never asked yourself: what does this place in the world sound like?

And no, this post isn’t about music-map. Or rather, it isn’t about the product itself. It’s about what it means that something like this can exist like that, in that way, while the water for coffee is coming up.

The distinction that changes everything

Here I need to clarify something, otherwise it sounds like I’m telling a story that’s already existed for years, just with a bit more excitement.

There are consumer tools that promise exactly this: open a browser, describe the idea, and in a few clicks you have an app. Lovable, Bubble, Glide, Softr. The ecosystem is huge and keeps growing.

The point is that, today, there’s still a pretty clear gap between “I built something that looks like an app” and “I built something that holds up in production.” I’m not saying this out of snobbery, and not as a judgment on those products either. In certain use cases they’re genuinely great.

It’s really a matter of substance: robustness, scalability, control over the generated code, the ability to intervene when something breaks, real ownership of the infrastructure. That very concrete feeling of knowing where the pieces are and what happens if one of those pieces stops working.

I used tools meant for people who, in some way, already know what they’re building. Tools that assume you have technical context, that you can read an error, that you can make architectural decisions when they put them in front of you.

That difference is still enormous today. And that is exactly the point.

b2b doesn’t scare me, at least for now

While I was finishing my coffee, the question that always hangs in the industry hit me, even when we pretend it doesn’t: is this taking my job?

In b2b the answer, as I see it right now, is no. Or at least, not in the catastrophic sense that mainstream narratives love.

Because good b2b work was never “writing code.” It’s understanding a client’s context, translating often messy needs into precise technical requirements, making sure a system holds up under pressure, navigating compliance and regulations, maintaining relationships of trust over time.

In day-to-day work at Oltrematica, I often have on the table at the same time a migration from Python to Laravel 12, compliance frameworks for the Cyber Resilience Act, sbom platforms for clients who have to report their software to public bodies, and solutions tied to the Product Liability Directive that will come into force in 2026. That’s not stuff you solve with a 17-minute conversation.

AI has changed how I do that work. The speed on certain tasks has increased in an almost embarrassing way. But the value I brought wasn’t in typing the code. It was in knowing what to write, why , and above all what to avoid.

That part, for now, hasn’t disappeared. If anything, it may have gotten stronger, because it leaves me more room to think.

Consumer is a different story

On consumer, instead, I feel less calm. Not because apps disappear tomorrow, but because it seems to me the shape of the market is changing.

If you take the classic adoption curve—innovators, early adopters, early majority, late majority, laggards—and ask where we are with ai tools for developing software, something weird comes out.

For developers, we’re already in the early majority. Many use them every day, integration into workflows is real, productivity is measurable.

For a non-technical user, instead, we’re still between innovators and the very first early adopters. The technical threshold is still high. Not as high as ten years ago, but high enough to exclude most people.

And that threshold drops every month. Not always linearly. Sometimes there’s a jump, maybe because someone finds an interface that really works, or because a model becomes capable enough to handle the ambiguity of natural language without forcing you to correct it every two minutes.

When that threshold drops enough to be crossed by a normal person—someone who doesn’t know what a server is and doesn’t even want to know—the consumer software market will change irreversibly.

The real “product” of consumer apps

Let me try to say it simply.

Over the last fifteen years, a consumer app worked like this: someone had an idea, and only those with technical skills, or money to buy them, managed to turn it into a product. Then that product was distributed and used by others.

The value was in execution, sure. But underneath there was something else: distance.

The distance between having an intention and being able to use it.

That gap, between “I’d like to” and “I can,” has been the market. Consumer apps existed because there was a technological barrier between those who knew how to build and those who wanted to use.

If that distance collapses—if anyone can describe what they want and receive in return working software calibrated to their needs—what remains of the traditional model?

I’m not saying apps disappear tomorrow. I’m saying the mechanism that has supported a huge part of consumer could stop working sooner than we expect.

Will custom software become normal?

For a few months now, an idea has been buzzing in my head that feels radical, but maybe it’s only radical because we’re used to the opposite.

In the physical world, mass production makes sense because personalization costs. A custom chair costs much more than an Ikea chair. So you accept a compromise and buy something standard, “good enough.”

Software has worked the same way. A note-taking app is designed for millions of people, so it will make choices that work for many and are perfect for very few. You buy it because building it custom, until yesterday, cost years or thousands of euros.

But what if the cost of personalization collapses to almost zero?

If I can describe how I truly want my notes app—with the categories I use, the flow I prefer, integrated with the tools I already have—does it still make sense to buy the one designed for millions of users?

Maybe yes, for convenience. Maybe no, if the difference between “adapting” and “having it the way I want” becomes too obvious.

I wonder if mass-market software will end up like commercial music in the streaming era. It remains, sure, but it stops being the center of everything, because alongside it grow more personal, more tailored experiences.

Who might resist

If this scenario comes true—and I’m putting an “if” not because I doubt the direction, but because the speed and shape of the change are truly uncertain—there are consumer models that seem more solid than others.

Network platforms, for example. Twitter, Linkedin, WhatsApp. Their value isn’t in the app itself, but in the fact that everyone else is in there. You can’t have your own customized version of a network, because a network without the network is just an empty interface.

Then there are services with proprietary data. Spotify doesn’t sell a music player. It sells access to catalogs, metadata, licenses, algorithms fueled by billions of listens. You don’t generate that stuff with a prompt.

And there are products where trust and compliance are part of the package. Finance, healthcare, legal. Even if an AI generated the perfect software for you, the question remains: who takes responsibility? Who certifies? Who answers when something goes wrong?

Finally, maybe, ultra-high-end products with exceptional UX. Some experiences are crafted in a way that isn’t just “it works,” it’s perceived quality. Notion, Linear, Figma. Replicating features is one thing. Replicating that coherence, that detail, that aesthetic and operational trust is another.

What risks suffering the most, instead, are niche utilities. The apps that “do one thing,” the $9.99-a-month micro-saas that live because they solve a specific problem better than others. If I can build it in an hour, that price starts to shake.

The barrier that remains, for now

There’s a legitimate objection, and I feel it too.

People don’t want to build their own things. They want to use them.

It’s true. And it probably will be for quite a while. There’s convenience, there’s trust, there’s cognitive savings. Even just clearly formulating what you want is effort—let alone iterating, correcting, choosing.

But that barrier isn’t stable. It drops with habit. It drops with better interfaces. It drops with digital education. And it drops above all when the advantage of having something custom becomes obvious enough to justify the effort, while the effort keeps shrinking.

I think the inflection point won’t be “the tool has become accessible.” It will be “the first time someone I know shows me what they made in 20 minutes and I think: I could do that too.”

That moment is coming. For some people it’s already here.

What we might see in the next few years

I’m not an analyst and I don’t have a crystal ball, so take these as informed feelings, not predictions.

I think we’ll see a first wave of consumer products that are no longer bought but built. At first in the most tech-friendly segments—developers, designers, university students—and then in concentric circles.

I think we’ll see enormous pressure on micro-saas pricing. Not because they become useless, but because it becomes hard to justify a subscription when the same utility can be generated on demand. Those who survive will offer something that isn’t easily generated: data, network, trust, deep integration with existing ecosystems.

And I think new intermediaries will emerge. Not “app builders,” but curators and distributors of software intentions. People who package prompts, configurations, already-tested flows, so others can create without starting from zero. A kind of template marketplace, but deeper, more operational.

There will probably also be attempts at regulation, more or less clumsy, around certain specific scenarios.

Breakfast as a metaphor

I’ll go back to the starting point, because that’s where the feeling stuck to me.

It wasn’t the speed that really struck me. It was the cognitive cost. I was distracted, doing something else, with my head on two things in parallel. It wasn’t a work session. It wasn’t “today I’m building a product.”

And yet the result is good enough to be online.

For me, this is the signal. The fact that producing software is becoming something you do in parallel with something else , like sending an email or searching something on Google. An action that no longer requires a dedicated context, a specific skill, a special mental energy.

When something becomes like that, it changes its place in the cognitive and cultural hierarchy. And with it, the market that grew around it changes.

Software is becoming an intention. Not yet for everyone, not yet in a stable way, but that’s the direction, and the speed is increasing.

And so the question I’m left with, this morning, is this.

If you’re building a consumer product, is the value in the technological distance between you and your user, or in something that exists even when that distance no longer exists?

If you don’t have a clear answer, maybe it’s time to find one.

And while I was trying to fall asleep, the question became more annoying and more interesting: if the UI really stops being the center of software, what happens to the rest? Because maybe it’s not just the screen that dies. Maybe the application as we’ve known it dies.

If the UI dies, it doesn’t fall alone

When we say “app”, we usually mean a fairly clear object. It has a name, an icon, a place in the dock, a monthly subscription, a personality. And above all it has a boundary. Inside is Notion’s world. Inside is Jira. Inside is Salesforce. Outside is everything else.

I realized that boundary, often, isn’t there because the problem requires it. It’s there because the business model requires it.

A lot of modern software is built like a fence. Not out of malice, maybe. It’s just that for years the simplest way to monetize has been this: take a set of features, package them up, build an interface around them that becomes familiar, put the user’s data inside, and then make leaving painful.

Mircha draws a parallel that I find illuminating: MCP servers as “new Unix programs”. And if that’s true, then the natural consequence is another one, a bit more uncomfortable. SaaS applications, seen from there, resemble mainframes. Big monoliths born in an era when distributing software was expensive and the only way to get paid for it was to build walls.

In a world where an agent can compose small, precise capabilities on the fly, that wall becomes more of a burden than a protection.

The generative interface: not designed, summoned

There’s a passage in Mircha’s post that made me stop and think. The idea that the GUI shifts from control panel to display. And it made me ask: what if it were neither?

Maybe the interface, in the next round, becomes ephemeral.

Today a designer, when designing a screen, is making a compromise. They look for a layout that works “well enough” for many people, in many contexts. The result is often an interface that’s solid, consistent, tested, but inevitably generic. It has to serve everyone, so it serves no one perfectly.

With an agent in the middle, that compromise could break.

I don’t mean “do everything via chat”, which is a convenient caricature. I mean a system that, given your intent, generates the right interface for that moment. A form that isn’t generic, but with those fields, in that order, with sensible defaults for your case. A dashboard that isn’t standard, but the visualization that answers a specific question, with the necessary data and no noise.

These UIs aren’t maintained. They aren’t versioned. They don’t need a roadmap.

They’re summoned and then they disappear.

And the unsettling thing is that it’s not even sci-fi anymore. Today we already see models that generate components, pages, small artifacts in React in real time. It’s still rough, yes. But the direction is hard to ignore.

At that point the designer’s role doesn’t disappear, but it changes skin. From screen designer to designer of generative systems. Design system, constraints, patterns, rules. Work more like building a grammar than drawing sentences.

The agent as an operating system

Another consequence that keeps coming back to me is this: maybe the right metaphor for the agent isn’t “assistant”. It’s “operating system”.

An OS does things we take for granted: it abstracts hardware, manages resources, offers a unified interface, lets different programs coexist and talk to each other.

The agent does something similar, one level up. It abstracts services, manages contexts, offers a unified interface (natural language), orchestrates different capabilities.

If this metaphor holds, then something almost inevitable happens: the agent becomes the platform. Not because everything “lives inside” the agent, but because everything passes through the agent. Just as today no software runs without an OS, tomorrow no service will be used without an agent.

And here comes the political, or economic, part, which is probably the most delicate. Whoever controls the agent controls the access point to software. It’s a position we’ve already seen in history, just with different names.

And I wonder whether we’ll manage to avoid the usual trajectory. The one Cory Doctorow calls enshittification. First everything is useful and open, then it becomes rent, then it becomes a toll.

From app to capability

If the application loses meaning, what’s left?

What’s left is the capability.

A capability is an atomic function exposed via protocol, described in human terms, invocable by an agent. “Create an invoice.” “Search for this contact.” “Summarize these tickets and tell me the risks.” It’s not a product with a brand and a layout. It’s a building block.

And as soon as you think in terms of building blocks, the economics change too.

Today you pay a subscription for a bundle: a hundred functions, you use twenty, but the price is for all of them. Tomorrow you might pay per use, capability by capability, at the moment you need it. Fractions of a cent for a single action done well.

This throws three historical advantages of SaaS into crisis:

First, the interface as lock-in. If the interface belongs to the agent, it’s no longer yours.

Second, data as a prison. If data lives in personal vaults and access is via granular permissions, the fence loses power.

Third, the bundle. If the agent can compose the best for each piece, the monolithic package becomes less attractive.

At that point only one thing remains: the quality of the capability. Do one thing, do it better than everyone else. It’s Unix as a technical philosophy, but also as a business model. Elegant, and a bit ruthless.

The new literacy

There’s another idea in Mircha’s post that I think is underestimated: “not knowing how to talk to AI” as a new form of illiteracy.

For decades we’ve called “digital literacy” something very specific: knowing how to use interfaces. Clicking, dragging, navigating menus, filling out forms. We built courses, certifications, professional roles.

If the agent becomes the main interface, all of that deflates.

The central skill becomes something else, and maybe it’s more human than technical. Knowing how to express an intention clearly. Knowing how to provide context. Knowing how to break down a problem. Knowing how to judge a result and iterate.

And here there’s a paradox that fascinates me. There are people who never really learned Excel, but can explain what they want with surgical precision. And there are power users who, put in front of an agent, don’t know what to ask.

The skills map gets redrawn.

And yes, the risk of a new digital divide is real. But there’s also a rare opportunity: for the first time, the advantage isn’t “knowing how to speak the machine’s language”. It’s knowing how to think and communicate well.

The European surprise: compliance as a capability

There’s a piece of this story that, in my opinion, we can’t ignore in Europe.

While the American narrative tends to see regulation as a brake, here we’re building a regulatory framework that touches exactly the exposed nerves of a world of composable capabilities: AI Act, Cyber Resilience Act, Product Liability Directive, EAA.

In a system where an agent combines three capabilities from three different providers, the question “who’s responsible if something goes wrong?” becomes explosive.

If the law asks you for traceability, security, audit trail, explainability, then compliance stops being just a cost. It becomes a differentiating capability.

SBOM as the component’s passport. The agent’s action log as a requirement. Transparency as a competitive advantage.

And here there’s an almost ironic reversal: many historical demands of hacker culture—openness, accountability, verifiability—are becoming law. Maybe Europe, more than slowing things down, is building the trust infrastructure without which the agents world doesn’t hold up in serious companies.

2030, an ordinary day (maybe)

I try to imagine a normal day, without wanting to do sci-fi.

You no longer have “apps” on your phone. You have an agent. You talk to it, write, maybe make a gesture. It orchestrates different services and you almost never see what’s behind the scenes. A bit like today you don’t think about microservices when a page loads.

The interface you see was generated for you, in that moment. In five minutes it no longer exists.

Commerce becomes conversation. “I need trail shoes, budget 150 euros, mixed terrain, I prefer a Vibram sole.” The agent knows your size, history, preferences, trusted sources. It proposes three options with a custom-made comparison. You choose, done.

At the office something similar happens. The PM doesn’t open Jira, they ask “where are we on Alpha?” and get status, risks, next steps. The sales rep doesn’t navigate the CRM, they ask “which deals are at risk this week?” and receive a briefing. The developer describes a behavior and the system generates, tests, deploys.

Data lives in a personal vault, encrypted and portable. Capabilities ask for granular, revocable permissions, and everything is logged. Every action produces an audit trail.

In that world, value sits in two things: good capabilities and trust.

A necessary realism

Is it inevitable? I don’t know.

Transitions are never linear. There will be enormous economic resistance. Enterprise moves with an almost geological slowness. Habits change more slowly than press releases. And there are real technical problems: reliability on complex tasks, error handling in composition chains, security, costs.

But the direction Mircha brings into focus seems hard to ignore to me, because it’s supported by two concrete forces.

On one side the cognitive cost of traditional interfaces, which grows with every new SaaS.

On the other the ability of agents to reduce that cost, which grows with every iteration of the models.

When the distance between the two crosses a threshold, the transition becomes practical, not ideological. And for some use cases, maybe that threshold has already been crossed.

Mircha closes by asking who will build this future and with what values. I’m left with another question, a bit more personal and a bit more cynical: who will have the courage to build for this future, knowing it means dismantling the model that pays salaries today?

Because the dilemma, in the end, isn’t technical. It’s the willingness to cannibalize the present.

And the time to decide which side to be on, probably, isn’t infinite.

This post is born from reading“La morte dell’interfaccia utente come la conosciamo” by Mircha Emanuel D’Angelo. If you haven’t read it, I think it’s worth starting there.

It’s not always arrogance. Actually, it’s usually the opposite. It’s a line said with the natural ease of someone who thinks compliance is a technical detail, like choosing a framework or deciding whether the button goes on the right or the left.

Except that “detail” is changing shape. And it’s becoming—much faster than the market seems ready to admit—a matter of responsibility.

What the client buys and what the vendor sells

For years, in custom software, we understood each other through a fairly simple implicit pact. The client describes what they want, the vendor builds it, timelines and costs are agreed, and at delivery you test, go to production, close it out.

In this model, the “heavy” responsibility almost always ended up inside the project perimeter. If something went wrong, you talked about bugs, outages, maybe a penalty. Annoying, sure, but manageable.

The point is that in Europe, between 2025 and 2027, a shift in perspective is coming that makes that pact less stable. It’s not a single regulation you can ignore until the legal email arrives. It’s a set of rules that, taken together, push in a very specific direction: software is increasingly treated like a product.

And when something is a product, whoever “produces” it no longer answers only in contractual terms. They also answer for defects, a bit like what happens with an appliance that causes damage because it was designed or assembled badly.

The commercial misalignment that creates friction

This is where the real friction starts—the kind that then blows up in negotiations and quotes.

The client thinks in a linear way and, from their point of view, also correctly. They want a working platform, a portal, an app. They want it by a certain date, with a certain budget, with the features the business needs.

The vendor, however, finds themselves carrying a growing load of requirements that almost never show up in the brief. You don’t find them in user stories, you don’t see them in mockups, the product owner doesn’t ask you for them. And yet they’re things that, if missing, turn a “delivered” project into a “risky” project.

I’m talking about technical documentation done a certain way, component traceability, vulnerability management, transparency around certain algorithmic choices, accessibility. All activities that share one common trait: they cost time, skills, process.

And here comes the dilemma that, in my view, is becoming more and more toxic.

If you include them in the quote, you risk being more expensive than the competitor who doesn’t.

If you don’t include them, you absorb them into margin, work at a loss and, on top of that, take on a risk you never made explicit.

Neither path is sustainable for long.

Why “it’s always been this way” doesn’t hold up anymore

In Italian b2b we’ve spent years inside a “let’s do it, then we’ll see” culture. Light contracts, vague specs, lots of personal trust. Sometimes it worked pretty well too, I won’t deny it. Maybe because the context allowed it.

Now, though, three things are changing at once, and it’s the combination that’s scary.

The first is more “objective” liability. In some scenarios it’s no longer enough to say “we weren’t negligent.” The defect matters and the damage matters. And in certain cases the burden of proving there was no defect shifts to whoever produced or placed it on the market.

The second is the widening of the perimeter. Software isn’t only what you write. It’s also what you integrate: open source libraries, cloud services, third-party api, ai models. And when these things enter the final product, someone has to answer for how they were chosen, integrated, monitored.

The third is time. We’re not talking about a distant future. We’re talking about deadlines between 2026 and 2027. The code you’re writing right now will, in all likelihood, still be there when these rules are fully in force.

So I wonder whether it’s naive to keep treating compliance as a footnote.

The conversation nobody wants to have

The hardest part isn’t understanding the rule. It’s talking about it without blowing up the commercial table.

Try telling a client the quote goes up by 20% because you need to produce compliant technical documentation, implement a vulnerability management process, and keep an up-to-date inventory of components.

In the best case, they answer with a long silence.

In the worst case, they tell you someone else will do it without.

And this is where the market splits. Because that “without” rarely means “more efficient.” Often it means “compliance debt,” i.e., work and risk pushed into the future. A future in which, with the new rules, the bill could land on the vendor, the client, or both.

And yet almost nobody is having this conversation, at least not explicitly. It’s uncomfortable. It forces the client to accept that compliance has a real cost. And it forces the vendor to explain that cost without hiding behind words that sound like bureaucracy.

The cost of invisibility

There’s a paradox that makes everything more complicated. Compliance activities, when done well, are invisible.

A serious vulnerability management system is noticeable when nothing happens.

Technical documentation becomes valuable when something goes wrong.

A component inventory (like an up-to-date list of dependencies) is truly worth it on the day a critical vulnerability drops and you need to immediately understand whether you’re exposed.

The client sees the feature, sees the go-live, sees the interface. Everything that keeps that result standing over time stays under the floor.

So maybe the problem isn’t that the client “doesn’t want to pay.” It’s that they don’t perceive what they’re buying.

If you go to an entrepreneur and say “we need to implement a compliant software bill of materials,” you’ll probably lose their attention after a few words.

If instead you say “we need to be able, within 24 hours, to know whether a newly disclosed vulnerability puts your product—and therefore your liability—at risk,” you’re speaking the language of risk. Which is a much more universal language.

What changes, in practice, without turning everything into a nightmare

For vendors, the path is narrow but fairly clear. You need to stop treating compliance as a hidden cost and start treating it as an explicit service, with a value you can explain.

That means, for example, separating functional development from security and compliance maintenance. Not inside some indistinct “annual retainer,” but with a line item that says what it actually covers. Also because, if one day something ends up in dispute, ambiguity helps no one.

It means putting it in black and white, in contracts, who does what. Who updates dependencies? Who monitors vulnerabilities? Who produces and retains technical documentation? Who decides whether a library can be used or not? Who answers if a component turns out to be compromised?

Today, in many Italian contracts, these questions simply don’t exist. And when a question doesn’t exist, the answer always arrives at the worst possible moment.

It also means learning to sell these activities for what they are: risk reduction. Because the client doesn’t buy “compliance.” They buy the ability not to end up with an outlaw product, with a security incident handled badly, or with a dispute where they have no evidence and documents to defend themselves.

For clients, the mindset shift is the mirror image. Compliance is your problem is no longer a comfortable position, and maybe it never really was a safe one. If you place a digital product on the market, even if you had it developed by third parties, responsibility doesn’t evaporate.

At most you can seek contractual recourse against the vendor. But in the meantime the damage, reputation, incident handling, and commercial consequences are yours to deal with.

A question of market maturity

If you think about it, what’s happening looks like forced growth. The software market—especially custom work—is moving from an artisanal model, based on trust and implicit agreements, to a more industrial model, where responsibilities are defined, processes are documented, and quality isn’t just “it works on my phone.”

That’s not necessarily bad news.

For serious vendors it can become a way to stand out from those who compete only by cutting corners.

For more aware clients it can be a guarantee: knowing the software isn’t built just to go online, but to stay standing, withstand incidents, and not turn into a legal problem at the first jolt.

Maybe the right line today isn’t “compliance is your problem.” It’s something more honest and more useful: compliance is part of the product.

And then yes, it’s a structural cost of making software. The sooner you acknowledge it, the sooner you can manage it. And maybe, with a bit of courage, turn it into a competitive advantage too.

My grandfather was (ALSO) a carpenter. When you asked him how he could tell whether a piece of wood was good, he didn’t pull out theories. He’d stop, turn it over in his hands, smell it, and then say: “you can feel it.”

Every time I think back to that scene it makes me smile, and then I get this kind of strange nostalgia. Because I’ve been doing software for twenty years, and when a client asks me how I know whether a system is good, I wish I could answer the same way. I wish I could say “you can feel it” and leave it at that.

Except the truth is more complicated, and maybe that’s exactly the point.

You can’t touch software. You can’t smell it. You can’t hold it up to the light to look for the grain. And yet it’s everywhere. It’s the most powerful and most invisible thing we’ve built.

And when something is that invisible, trust becomes everything.

The world runs on things you can’t see

This morning you had breakfast. The milk you bought got to the supermarket by moving through a logistics chain run by software. The payment at the checkout went through more systems than we imagine, often without anyone even noticing.

The traffic light you passed on your way out executes an algorithm. The elevator has firmware. Your salary is a number in a database.

I’m not saying it for dramatic effect. That’s just what the world is like now.

And here comes the paradox that unsettles me a bit. Almost no one, among the people who make decisions about how society works, has a deep understanding of how these systems work. Not out of stupidity or laziness. More because of a structural flaw in our culture: for years we treated technology as something for technicians , a department, a corner of the map.

In the meantime it’s become the connective tissue of everything.

When a board of directors approves an ai-based system to filter job applications, is it making a technological decision? Yes. But it’s also making an ethical, legal, social decision. It’s deciding which biases are acceptable, what margin of error is tolerable, how much opacity is admissible in a process that changes people’s lives.

And often it doesn’t know it.

What happens when no one understands the machine

There’s a story that we know well in our industry, but that we rarely tell outside our rooms.

Inside almost every system you use, from your bank’s website to the app you order dinner with, there are small pieces of code written by people you’ll never meet. They’re open source libraries: free, shared components, often maintained by single individuals in their spare time.

Some time ago someone tried to slip a backdoor into one of these libraries, a component used by millions of servers around the world. The attempt was discovered almost by chance: an engineer noticed the system took half a second longer to start up. Half a second.

From that half second they traced it back to a sophisticated operation, probably state-sponsored, that could have compromised critical infrastructure on a global scale.

The thing that should keep you up at night isn’t that someone tried. It’s that the entire security chain depended on one person, a volunteer, who maintained that code in their spare time while fighting burnout.

It’s not an isolated anecdote. It’s a model. And I often wonder how long it can hold.

ai isn’t intelligent (and that’s fine)

Here we need to be clear, because marketing has done an incredible job muddying the waters.

The systems we call “artificial intelligence” don’t think. They don’t understand. They don’t have intentions, desires, goals of their own. They’re statistical machines of unprecedented power, capable of finding patterns in amounts of data no human being could process, and of generating results that appear intelligent.

This distinction isn’t academic. It’s practical. It’s one of those things that changes how you make decisions.

If you think ai understands, you’ll end up treating it like an expert. You’ll trust its judgment. You’ll delegate choices to it. And when it gets things wrong, because it does get things wrong and it also does so in subtle ways, you won’t have the tools to notice.

If instead you see it for what it is, a hugely powerful tool, then everything snaps back into a healthier perspective. A tool has to be guided, checked, secured. A scalpel is extraordinary in a surgeon’s hands, and it’s a danger in anyone else’s. The difference isn’t in the scalpel.

For those of us who write software, that awareness changes the job. Maybe we don’t write every single line anymore, or at least not in the same way. But we have to understand every single line, because we’re the ones accountable for what the system does.

The machine generates. The human guarantees.

And that guarantee carries a weight that no statistical model can take on.

Europe does something brave (and almost no one notices)

While American and Chinese big tech race ahead, Europe does something different. It writes rules.

I know, the instinctive reaction is a yawn. Rules, bureaucracy, slowness, yet another brake on innovation.

But stop for a moment. Maybe, and I do mean maybe, it’s one of the few truly political moves we’re seeing.

Europe is saying that technology is not above the law. That if you produce software that makes decisions about people, you must be able to explain how it works. That if your digital product has a vulnerability, you’re responsible for it, the way a car manufacturer is responsible for a defect in the brakes.

AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Dry names, yes. But behind them there’s a very concrete insight: in the twenty-first century, regulating technology means regulating society.

For those who run businesses, this means costs and complexity—it would be naive to deny it. But it also means something else that seems underestimated to me: a potentially enormous competitive advantage.

When the global market wakes up asking for digital products that are secure, transparent, accessible, those who have already built these qualities into the way they work will be ahead.

Compliance can be a burden, sure. But it can also be an investment, if you integrate it into the process and don’t treat it like a sheet to sign at the end.

An sbom compiled out of obligation is a file in a folder. An sbom compiled with awareness is a map of your product, a governance tool, almost a declaration of maturity.

Open source: the greatest and most fragile gift of the digital era

There’s something deeply beautiful about open source. Someone writes a piece of code, publishes it, and tells the world: take it, use it, improve it.

It’s generosity, but not in the romantic sense. It’s the construction of a common good.

And the global digital economy rests on that common good. That’s not an exaggeration. If that software had to be rewritten from scratch, the estimated value would be on the order of trillions. But the people who maintain it receive a tiny fraction of that value.

The problem is systemic. Big platforms build billion-dollar services on libraries maintained by exhausted volunteers. Governments use open source in critical infrastructure without truly contributing to maintenance. Companies integrate open components into their proprietary products without knowing what’s inside, until a vulnerability forces them to find out in the worst possible way.

Cory Doctorow talks about enshittification , that cycle in which platforms extract value until they degrade the ecosystem. But open source isn’t a platform. It’s more like a garden.

And a garden, if everyone harvests and no one waters, dies.

The good news is that something is moving. Europe, with the CRA, is starting to distinguish between those who maintain code out of passion and those who commercialize it. Some companies are creating dedicated funds. But the most effective response remains the simplest—and also the most uncomfortable.

If you use open source in your product, contribute. With code, with funds, with recognition. Not because you have to. Because it’s smart, and because it’s right.

Accessibility: the ultimate test of our intentions

There’s an almost foolproof way to tell whether a company takes its values seriously. Don’t look at the “about us” page. Look at whether its site works with a screen reader.

Accessibility is where rhetoric meets reality. You can talk about inclusion and diversity all you want, but if your digital product can’t be used by someone with a visual, motor, or cognitive disability, those words become empty.

And then, let’s be honest, we’re not talking about a niche.

In Europe, tens of millions of people live with some form of disability. Add to that older adults, people with temporary disabilities, anyone who finds themselves in an unfavorable context: sunlight hitting the screen, a slow connection, an old device.

Accessibility isn’t a favor. It’s a measure of the quality of our work. Accessible software is almost always better software: cleaner in the code, clearer in the interface, more robust.

The European Accessibility Act will make many things mandatory starting in 2025. But whoever waits for the law to do the right thing, in my opinion, has already missed the point.

ai developers: you’re not in danger, you’re in transformation

Here I’m talking to people who do my same job. Those who live between commit and deploy, between bug and refactor.

I know there’s fear. I see it in conversations, in messages, sometimes in jokes. The question is always the same, even when it isn’t said: “in five years, will there still be a need for me?”

I breathe.

We went from spreadsheets to relational databases. From static sites to frameworks. From manual deploy to ci/cd. And now from hand-written code to ai-assisted code. Every time the ground shook. Every time, those who managed to adapt discovered the new ground was more fertile than the old.

The value was never in typing. It was in understanding. In the ability to look at a problem and see the structure beneath the surface. To talk with a user and translate frustrations into a system that works. To choose when to build and when to reuse. To know that a test isn’t bureaucracy, it’s love for the future.

These skills aren’t automatable. They’re amplifiable.

A machine that writes code is a multiplier of your abilities, but only if you have abilities worth multiplying. An ai IDE in the hands of someone who understands what they’re doing is an extraordinary tool. In the hands of someone who doesn’t understand, it’s a high-speed technical debt generator.

Study, yes, but not only the new tools, because they’ll change. Study the fundamentals: architecture, system design, security principles, accessibility. Study people: how they communicate, what they fear, what they hope for. And also study the regulatory context, not because it’s fun, but because it defines the playing field.

And above all, don’t stop being curious. Curiosity is a strange thing, not always “productive” in the corporate sense of the term. But it’s one of the few competitive advantages a machine can’t truly replicate.

A matter of trust

In the end, this whole conversation—about ai, about open source, about regulation, about accessibility—revolves around a single word: trust.

Do we trust the systems we can’t see? Should we? And under what conditions?

Trust isn’t built with statements of intent. It’s built with concrete choices, repeated over time, verifiable. It’s built by documenting dependencies, testing code, making the product accessible, explaining the algorithm’s decisions, being accountable for mistakes.

For decision-makers, technology isn’t a department. It’s the language the organization is written in. You don’t have to become programmers, heaven forbid. But you do need to understand enough to ask uncomfortable questions of vendors, tell a real risk from empty reassurance, understand what’s inside the software that runs the processes.

For us developers, the job was never only technical. Every architectural choice is a choice of values. Every piece of data we decide not to collect is a right we choose to respect. Every interface we make accessible is a door we open.

Code is power, and power comes with responsibility.

So: wood and code

My grandfather wouldn’t have understood my job. He probably would have shaken his head at certain words, and then changed the subject.

But I think he would have understood the principle.

He knew a well-made piece of furniture is recognized by the joints you can’t see. By stability that lasts over time. By the care put into details the customer will never notice, but that make the difference between an object that lasts twenty years and one that creaks after six months.

Good software is the same. You recognize it by what you don’t see: by security that isn’t breached, by accessibility that excludes no one, by privacy that isn’t betrayed, by documentation that allows whoever comes after to understand what you did and why.

It’s not a job that ai will take away from us. It’s a job that ai, in a sense, is giving back to us in its purest form: not as a mechanical act of translation, but as a human act of care.

And care, as my grandfather knew while looking at wood, you can feel it.

This article is for those who write code and for those who depend on it without knowing it. For those who decide without understanding and for those who understand without being able to decide. Maybe for all of us, because in the end the answer is always the same: it depends on us.

I work at a small-to-medium tech company in Pescara. We’re about a dozen people, not fifty, not two hundred. We build software for different clients, from public administration to SAAS platforms, and the thing that has kept us afloat, forever, is a kind of obsession with solidity. Thought-through architectures, code that holds up, systems that don’t crumble when someone feeds them real data, real money, real decisions.

And yet, in recent months, I’ve found myself thinking something a bit bitter: this is a brutal time to have ideas. Not because creativity is lacking—quite the opposite. The problem is that creativity often comes with a feeling of powerlessness.

The “someone already did it” syndrome

It happens like this, with an almost comical regularity.

Monday morning, brainstorming. Someone throws out an idea. We get fired up, we start imagining how to do it properly, what the right architecture would be, where the risks are, how we’d sell it without lying to ourselves.

Then Wednesday evening arrives. A scroll on LinkedIn, or on Hacker News, and there it is: the announcement. Google, Microsoft, OpenAI, or a startup that just got funded with numbers we only ever see in rounds talked about on podcasts, has just launched the same thing. Or something close enough that, in the market’s eyes, our idea becomes a late clone.

It’s not even a “they copied us” thing. It’s more banal and more depressing: they have scale. And in this historical phase, scale seems to matter more than anything.

I often wonder whether we’re entering an era in which real innovation becomes almost a luxury reserved for those who can afford to fail fast and in public.

When they don’t beat you because they’re better, but because they’re faster

Up to here, it would already be frustrating. But there’s another level, harder to swallow.

Because they don’t always beat you to market with a better product. Sometimes they beat you with something mediocre, shipped quickly, with minimal tests and an almost arrogant confidence that the brand will hold up anyway.

“Vibe coding,” which until recently seemed like a game for indie hackers, has entered enterprises. And I’m not talking about the junior who uses copilot to write a component. I’m talking about entire teams generating huge chunks of an application with prompts, doing a couple quick checks, and then pushing everything to production.

In recent months I’ve seen platforms with vulnerabilities that give you chills. Xss you can catch in five minutes, api without rate limiting, payment flows without idempotency, personal data handling that would probably make anyone who’s ever been a serious DPO turn pale.

And yet they’re there. On the market. With users. With revenue.

The implicit message, that hits you even if you don’t want to hear it, is this: quality doesn’t matter, speed matters.

And if quality doesn’t matter, then we small players—who build our reputation and often our survival on quality—what room do we have?

The Brussels epiphany (that I didn’t expect)

Here comes the part that, until a couple of years ago, I never would have thought I’d write.

For a long time I looked at European regulation with annoyance. GDPR in 2018 felt like a boulder: lots of effort for those who were already working well, while the big players kept doing whatever they wanted and, at most, paid fines that were pocket change to them.

But then I started looking at the picture that’s forming now. And I had a strange, almost counterintuitive feeling: maybe Brussels is one of the few weapons we have left.

Not because “bureaucracy is beautiful,” obviously. But because what’s taking shape isn’t an isolated regulation. It’s an integrated regulatory ecosystem that changes the yardstick by which competition happens.

If Europe is 80% SMEs, and if it wants those SMEs to survive in the AI era, then it has to do one simple and extremely hard thing: prevent size from being the only competitive advantage.

And, for better or worse, that’s exactly what it’s trying to do.

Seven laws, one direction

I’m listing them, yes, but with a specific idea: don’t read them as “seven obligations.” Try to read them as an industrial strategy.

AI Act, the great leveler upward

The AI Act has been in force since 1 August 2024, with progressive application. Bans from February 2025, obligations for high-risk systems from August 2026.

The interesting thing is that it doesn’t say “don’t do AI.” It says “do it well.” It classifies systems by risk, and where the risk is high it asks for things that, honestly, should be normal: risk management, data quality, human oversight, documentation, transparency.

For an SME that already works in an orderly way, compliance is often a manageable delta. Not free, sure. But manageable.

For those who put a critical system into production built in three weeks without really knowing what it does, it becomes an abyss. You have to rethink processes, governance, architecture. You have to slow down.

And that’s where the AI Act becomes, paradoxically, pro-SME. Not because it protects small players just because they’re small, but because it rewards those who already have a “let’s do it properly” culture.

There’s also a point I care a lot about regarding general-purpose models: transparency and documentation obligations for providers, especially for models with systemic risk. Translated: if I build a product on a foundational model, I have more right to know limits, risks, and boundaries. Today you often only figure it out by reading papers and corporate posts.

Cyber Resilience Act, the end of “it works, don’t touch it”

The CRA has been in force since 10 December 2024. Reporting obligations from September 2026, full application from December 2027.

Here the music really changes: if you put a product with digital elements on the European market, you’re responsible for security across the lifecycle. Security updates for at least five years, documented vulnerability handling, fast reporting, and above all sbom.

Sbom, without any romanticism, is an inventory: knowing what’s inside your software, including dependencies. When a critical CVE comes out, you don’t have to do archaeology. You know.

And you know who’s often already set up like this? SMEs with modern stacks, decent pipelines, tracked dependencies.

Who suffers instead? Huge organizations with years of technical debt, untouchable legacy applications, components frozen in 2016, and nobody who really has the map of the territory.

The CRA makes maintenance no longer a “if there’s time left” thing, but a duty. And suddenly the obsessive attention to updates stops being a personal fixation and becomes a competitive posture.

Product Liability Directive, software is no longer untouchable

The new PLD was adopted in 2024 and member states must transpose it by December 2026.

Here I’ll admit I’m a bit scared. Because it extends defective product liability to software as well. And in some cases it introduces mechanisms like the reversal of the burden of proof: if there’s a plausible link between defect and damage, the producer must prove that the product was not defective.

Now, imagine a company that shipped a financial app without serious tests, without code review, without documentation. If damage happens, how do they prove it?

An SME that works with CI, automated tests, traceable reviews, documented architectural decisions, changelog and release notes, ends up with something valuable it hadn’t called that: a defensive file.

The PLD, in practice, turns process quality into a legal shield.

European Accessibility Act, the web isn’t only for people who see well

The EAA already applies from 28 June 2025.

Accessibility means WCAG 2.1 AA as a reference: semantics, contrast, keyboard, screen reader, text alternatives. Not the “pretty page,” the page that’s usable even by people with disabilities.

Those who have always treated accessibility as a requirement start ahead. Those who built gorgeous interfaces that are unusable with a screen reader have to run.

And here there’s a very concrete opportunity: accessibility becomes a service. Audits, remediation, accessible design systems. There’s also the exemption for micro-enterprises, which is an interesting detail: you can be small enough not to be obligated in certain cases, but competent enough to help others.

NIS2, cybersecurity is no longer optional

NIS2 was supposed to be transposed by October 2024, and in Italy the transposition has arrived. Application is progressive.

The part that hits SMEs isn’t just “are you in scope or not.” It’s the supply chain effect. If your customer is subject to NIS2, they’ll ask you for guarantees. Procedures. Incident response. Measures.

Security becomes a commercial prerequisite. If you can’t demonstrate a serious posture, you don’t work with certain customers. Period.

And here too, those who invested earlier, maybe with effort and without glory, find themselves ahead.

Data Act, the data generated is yours too

The Data Act has been in force since 11 January 2024 and applies from 12 September 2025.

The concept, put simply, is this: data generated by the use of a connected product must be accessible to the user and, on request, shareable with third parties.

For those who live off lock-in, it’s a shock. For SMEs it can be a huge opening: if data must be portable, someone has to build the infrastructures, the API, the connectors, the formats.

It’s almost an anti-lock-in law. And many SMEs, plainly, never had the strength to do aggressive lock-in. Now that “lack” can become an advantage.

DMA and DSA, gatekeepers with different rules

The DMA has been fully applicable since March 2024, the DSA since February 2024.

Here the point is political but very concrete: gatekeepers can no longer play with the same impunity as before. Interoperability, bans on self-preferencing, more transparency.

Is it enough? Probably not. I expect loopholes, creative interpretations, very well-paid lawyers.

But it changes a principle: being big doesn’t automatically give you the right to cheat.

Taken together, it’s not compliance: it’s a change of metric

If I look at these laws as a whole, I see a pretty clear message.

In the European market, the idea is that the winner is the one who does things well.

Well means: transparent and supervised AI, maintained and secure software, real accountability when you cause harm, accessibility as a requirement, cybersecurity as a daily practice, less locked-in data, more controlled dominant platforms.

And, almost unintentionally, this direction values some typical traits of serious SMEs: attention to detail, closeness to the customer, more up-to-date stacks, less untouchable legacy, fewer incentives to “ship it and we’ll see.”

But reality isn’t all sunshine

It would be dishonest to say compliance is free. It costs time, it costs money, it costs focus. And in a medium (or small) company every hour spent on documentation and processes is an hour not spent on product.

There’s also a real risk: that compliance becomes, once again, an advantage for big players, the ones who can afford legal departments and governance platforms.

But here, maybe, Europe has understood a point: proportionality. Many laws differentiate by risk and size. And then there’s another path, which seems very concrete to me: turning compliance into a service.

If you truly understand CRA, AI Act, NIS2, EAA, not just as “checkboxes,” but as technical implications, you can sell it. Sbom, audit, hardening, AI governance, accessibility assessments. Compliance stops being only a cost and becomes a market skill.

What I’d do Monday morning, for real

I don’t want to close with the moral. I’d rather close with practical things, because maybe that’s where SMEs can help each other.

We’re trying to build a single internal framework, not seven separate processes. We have to—we’re small. And this time being small is an advantage, because we can’t afford silos. The documentation needed for the CRA also helps with the PLD. The sbom is needed for CRA, but it also becomes a useful base for NIS2-style requests. The AI Act’s risk-based logic fits well with the GDPR approach.

We’re also trying to treat compliance as a product, not just as an obligation. If a customer has to adapt, someone has to guide them. And if you guide them well, you’re not selling “bureaucracy.” You’re selling risk reduction, operational continuity, reputation.

Then there’s training. Not the kind made of slides only. Training to understand the why behind the rules, because if you understand the why, you need the checklist less. You reason better when the weird case arrives, the one that isn’t written anywhere.

And finally the network. Shared templates, processes, lesson learned. Compliance isn’t a zero-sum game. If your ecosystem is more solid, so are you.

Maybe this is the point: we don’t have to apologize for being small

I have no illusions. Big tech will invest in compliance, they’ll find ways to adapt, they’ll lobby, they’ll look for favorable interpretations.

But something has changed: Europe is saying that, in its market, speed without responsibility is no longer a superpower.

And for those who, like us, have always built with care not out of virtue but out of necessity, that’s a strange and beautiful piece of news. Maybe we don’t have to become bigger. Maybe we just have to keep doing things with attention and responsibility.

Only now, finally, there’s someone trying to make that choice count.

Every now and then I end up talking with entrepreneurs who have ten, thirty, eighty people. They don’t have a Chief AI Officer, they don’t have an eighteen-month roadmap, and often they don’t even want to be told that they “have to transform.” They have another urgency, much more concrete: keeping the company running.

And yet the question comes anyway, even if it’s rarely said exactly like this: so what, concretely, are we supposed to do with AI?

Big companies are already asking it officially, with budgets, dedicated teams, and programs with acronyms that sound important. SMEs, instead, are in different territory—made of confusion and contradictory signals. And it’s not their fault. It’s that the public conversation about AI often feels designed for people who have time, resources, and structures an SME will never have.

So I’ll try to put it simply, almost brutally.

How many people on your team know how to get a better result from an AI agent than they would produce on their own?

Not how many “use it.” Not how many have ChatGPT open in a tab. How many know how to give precise instructions, critically evaluate the output, iterate methodically until something comes out that truly holds up. In sales, marketing, operations, finance, legal, product, HR.

If the honest answer is “few” or “I don’t know,” you probably have a problem. And in SMEs that problem weighs more, because you don’t have the luxury of postponing.

The most expensive misunderstanding of 2026

The misunderstanding, in my opinion, is this: thinking AI is a tech issue.

It isn’t anymore. Maybe it hasn’t been for at least a year.

AI has become a multiplier of individual capability, cross-functional to every role. A salesperson who can build a competitive analysis in ten minutes is playing a different game than someone who takes two days. Whoever handles administration and can generate a sensible cost dashboard in an hour is competing in a different category than someone who assembles everything in a week, fishing data out of old, half-broken excel files.

And here we’re not talking about the usual word “efficiency.” Efficiency is doing the same things faster. Here we’re talking about people who start doing things they didn’t do at all before, because the cognitive cost was too high.

A truly personalized offer for every prospect, instead of the usual recycled pdf with the name changed on the cover. A cash flow analysis of the last three years that shows you patterns no one ever pointed out. Project progress reports that didn’t exist before because “there’s no time.”

It could happen.

But only if someone knows how to govern the tool. If they treat it like a collaborator to direct, not like a toy to ignore or an oracle to interrogate at random.

“Governing” isn’t “using”

This distinction is the heart of everything, and it strikes me how often it doesn’t get made.

Using AI is asking for something and accepting whatever comes back. It’s prompt-and-pray. You write a request, copy the answer, paste it into an email, and hope it’s fine. It’s understandable—at the beginning everyone does it. But it’s worth nothing, and in some cases it’s even dangerous.

Governing AI is something else. It’s knowing what to ask, how to ask it, and above all understanding when the answer is wrong even if it looks perfect.

It means giving context, constraints, success criteria. It means iterating for real. Not “rewrite it better,” but “rewrite it considering that our customer is a public entity, with procurement constraints and six-month decision timelines.”

Whoever governs AI has a mental model of the tool. They know what it does well, where it tends to invent, where it can become a risk. They know when to trust it and when to verify. They know when the output is a starting point and when it can be considered finished.

And no, it’s not an innate talent. It’s a skill you develop. But here comes the slightly uncomfortable part: not everyone develops it. Not because they aren’t smart, but because it takes a specific mindset, and it’s not as widespread as we like to think.

The mindset you’re ignoring in interviews

When you hire, you usually look at experience, vertical skills, company culture, maybe leadership. All fair.

But you risk overlooking a variable that in the next two years will separate who performs from who struggles.

The variable is this: can the person in front of you work at a higher level of abstraction than execution?

Those who work at the execution level complete tasks. They write emails, prepare reports, analyze data, produce documents. They do it well, with craft. But they do it one thing at a time, and their time is the only resource.

Those who work at the specification-and-governance level define what needs to be done, with what quality, within which constraints, and then direct an agent (AI or human—at that level the distinction starts to blur) to execute it. They supervise, correct, refine. And move on.

It doesn’t mean execution doesn’t matter. It means the value of pure execution is compressing rapidly, while the capacity for governance is expanding.

If you don’t evaluate this capability during hiring, you’re hiring executors in a world that rewards directors.

Three questions that change an interview

It doesn’t matter whether you’re hiring a marketing manager, a controller, an office manager, or a CTO. There are three questions that, in my opinion, work almost every time.

“Tell me about the last time you used an AI agent for a real deliverable”

Not an experiment. Not a game. A finished deliverable in front of a client, a boss, a board.

Listen to how they talk about it. Did they give precise instructions or generic prompts? Did they iterate? Did they verify the output? Did they integrate their judgment or take everything as-is?

If the answer is “I’ve never done it,” in 2026, that’s a data point. Not necessarily disqualifying, but it’s a data point to weigh seriously.

“How would you know if the output is wrong?”

This is the key question.

AI produces convincing results even when they’re completely made up. A plausible but false number. A logical argument that starts from a premise that doesn’t exist. A beautifully written text that says the opposite of what you need.

Whoever knows how to govern AI has developed antibodies. They have a method, even a rudimentary one, to distinguish reliable output from toxic output.

Whoever doesn’t have it is more dangerous than someone who doesn’t use AI at all, because they produce errors with the confidence of someone who believes they’re right.

“If you had a dedicated AI assistant for eight hours a day, how would you reorganize your work?”

This question separates those who think in terms of tasks from those who think in terms of systems.

The mediocre answer is: “I’d do the same things faster.”

The interesting answer is: “I’d do different things,” followed by a concrete vision. What would change in priorities? Which outputs would start to exist? Which activities would be eliminated or reduced?

Whoever answers well has already understood that AI isn’t just an efficiency tool. It’s a leverage tool. And they know where to place the leverage.

The elephant in the room: the key people you already have

The biggest problem, often, isn’t who you hire. It’s who you already have.

In an SME the org chart is short. You don’t have layers of middle management. You have three, five, eight key people holding the company up.

The head of sales who knows every customer by heart. The admin who’s kept the machine running for fifteen years. The project manager you dump everything on that you don’t know where to put.

If these people don’t touch AI because “it’s not my job” or because “I’ve always done it this way and it worked,” you have a bottleneck no new hire can compensate for.

In a big company you can route around the problem with a dedicated team. In an SME you can’t. The key people are the company. If they don’t change, nothing changes.

And here comes the truly uncomfortable part, the one that usually causes a bit of irritation.

In many SMEs, the first person who didn’t get the message sits pretty high up.

If it’s you, and you’re reading with a mix of interest and irritation, maybe it’s worth stopping for a second on that irritation. I often wonder if it isn’t one of the most useful signals we have when something concerns us more than we’d like.

The choice, in the end, is clear-cut: establish that the ability to govern AI agents is an expected skill for every role, starting with yours. Not optional. Not “nice to have.” Expected, evaluated, measured.

It’s not a generational issue

There’s another mental shortcut that feels convenient, but doesn’t hold up: “young people are digital natives, so they understand AI.”

It’s not true.

I’ve seen twenty-somethings use AI like a slightly more brilliant search engine. And I’ve seen fifty-somethings integrate it into their workflow in ways that, honestly, I wouldn’t have imagined.

The variable isn’t age. It’s the willingness to rethink how you work. To say: “maybe the way I’ve always done this thing isn’t the best anymore.”

It takes humility, curiosity, and a pinch of discomfort. Three things that don’t have an age.

So no, it’s not enough to hire young people and hope AI enters the company by osmosis. It takes a deliberate choice about which skills you value, which you reward and—let’s say it—which you demand.

The cost of inertia, in numbers (more or less)

These aren’t perfect calculations, but the order of magnitude is.

A knowledge worker who governs AI well often has output equivalent to 1.5x or 2x compared to someone who doesn’t use it. Not because they work more, but because they eliminate low-value work: manual research, first drafts, exploratory analysis, data structuring, slide prep.

In a team of ten people, if five govern AI and five don’t, it’s as if you had twelve or thirteen people. Without hiring anyone.

Now flip the reasoning.

If your competitor’s team is aligned on this skill and yours isn’t, your team of ten stays a team of ten. Theirs becomes a team of fifteen or twenty, at least for some activities.

And the gap widens every month, because the tools improve and those who govern them capture the incremental value. Those who don’t govern them stay still.

It’s not futurism. It’s arithmetic.

What to do Monday morning

The good news is you don’t need task forces, consultants, or twelve-month transformation programs that cost six hundred thousand euros.

You need three practical choices, and a bit of consistency.

The first is to include AI governance capability in the evaluation criteria for every open position. Not as a technical requirement, but as a cross-functional skill, at the same level as the ability to communicate or work in a team. Ask those three questions. Really listen to the answers.

The second is to ask your direct reports how they use AI in day-to-day work. Not with an anonymous survey, but in a one-to-one conversation. You’ll discover surprising things in both directions. Those who use it well often do it quietly. Those who use it poorly sometimes don’t realize how fragile their method is.

The third is to lead by example.

If you’re an entrepreneur who has never used an AI agent to prepare an offer, analyze financial statements, or write an important communication, the message you’re sending is crystal clear: it’s not important.

And your organization will believe you.

In an SME you can’t delegate change. Either it starts with you, or it doesn’t start.

It’s not a moral

In five years we’ll probably look at the hiring processes of 2025 the way we look at those of 2010 today, with a mix of tenderness and disbelief. “You really hired people without checking whether they knew how to work with AI?”

Really.

And whoever stops doing it earlier, without waiting for it to become “standard,” will have an advantage the others will take years to close.

Maybe the right question, in the end, isn’t whether the next person you hire knows how to use AI.

It’s whether they’ll know how to govern it. And whether you’ll be willing to demand it, even when it’s uncomfortable.

They’re the things you have to unlearn.

And the weird part is that, while you’re unlearning them, it feels like you’re losing something. Status, control, identity. Then, if things go well, you realize you were just letting go of a habit that was keeping you stuck.

These are scattered notes on a few things I’ve stopped doing. It took me fifteen years, more or less. And on some of them, if I’m being honest, I’m not done yet.

I stopped writing code to prove I’m still technical

There was a period, right after a big career transition, when my way of legitimizing myself in front of the team was always the same: I’d open the IDE and go grab the ugliest bug of the week.

I often did it in the evening, alone. The next morning the commit was there, with my name on it. In my head I called it leadership. In reality it was insecurity.

Because the implicit message was devastating, even if I never said it out loud. The message was: I don’t trust you. And there was another one, even more toxic: problems get solved at night, solo, without asking for help.

Without meaning to, I was teaching that the heroic gesture matters more than the process. That skill is an individual performance. That effort is a medal.

Then I took another spin on the carousel. I replaced code with specs. Documents so precise that the team, or an ai agent, could implement them with minimal supervision. For a while it felt like the “adult” solution. But that phase passed too.

Today my job, when I do it well, is something else. It’s deciding what we build, for whom , and why now. It’s portfolio architecture, not code architecture. It’s partnerships, hiring, positioning. It’s figuring out where the company needs to aim eighteen months from now, and which choices today make that direction more likely.

This distance from code sometimes hurts. Not because I want to go back to programming every day. It’s subtler than that. It’s the feeling that the legitimacy of a technical person who no longer touches code daily is fragile—something you have to rebuild on different foundations.

No longer on the quality of what you write, but on the quality of the decisions you make and the people you choose.

And then there’s a sentence that comes back to me often, and helps me not fall back into the old reflex: every line I write is a line someone else doesn’t write. Every hour I spend in the IDE is an hour when nobody is looking at where we’re going.

I stopped chasing the right stack

For years I had that Pavlovian developer reflex. A new framework comes out, you have to evaluate it. A new language comes out, you at least have to try it.

Deep down, I think the subtext was this: there is a “right” technology choice that puts you on the winners’ side. The cool kids. The right conferences. The articles on Hacker News.

Then I did something unpopular, at least for how I’d gotten used to thinking: I picked a framework. One. And I stuck with it.

Not because it’s the absolute best. But because it lets me deliver value with a small number of people across multiple projects, without losing my mind. Because it has a philosophy that holds up under the real constraints of an Italian company. Convention over configuration, batteries included, obsessive documentation. Not the imaginary constraints of a Bay Area startup that lives on slides and runway.

The uncomfortable truth is that a lot of “bold” technology choices, in SMBs, aren’t bold. They’re vanity. Choosing Rust for an internal management system that forty people will use isn’t engineering. It’s narcissism with a compiler.

At some point I stopped looking for the right stack and started looking for the honest stack. The one that doesn’t lie about the complexity it introduces. The one you can maintain when the seniors leave, when the budget tightens, when the client changes their mind three times.

I stopped shielding the team from the business

This was the hardest transition.

For years I acted as a shield. The client asks for a crazy change? I filter it. Sales sells something that doesn’t exist? I handle it. An incomprehensible document arrives? I translate it and pass only the technical part to the team—clean, digestible.

I thought I was being a good leader. And instead, I was probably creating invalids.

Very strong developers, yes, but disconnected. They didn’t really know why they were building what they were building. They couldn’t read a business requirement. They had never talked to a client. And when they hit ambiguity, instead of picking up the phone, they’d open a ticket and wait for someone else to resolve it.

The change, for us, was building an internal path we called “from developer to product owner.” Not to turn everyone into PMs. More than anything, to remove the filter.

To say something simple, even if a bit uncomfortable: the mess is yours too. The confused client is yours too. The ambiguous requirement is yours too.

And, above all, the satisfaction of delivering something that actually works for someone is yours too.

I thought it would be unpopular. I was wrong. They surprised me. Maybe they were just waiting for us to give them permission to step out of the bubble.

I stopped saying “it’s public anyway” when talking about compliance

For years my stance on compliance was the typical one in Italian IT. The bare minimum, done at the last possible moment, treated as a cost and never as an investment.

GDPR? A cookie banner and a copied privacy policy. Accessibility? “We’ll think about it later.” Security? “We’re not a target.”

Then I started actually reading some European regulations. Not articles about those regulations—the texts themselves. And two things became clear.

First: the European legislator, for once, is not kidding. The penalties are real, the timelines are tight, and the chain of responsibility goes all the way down to the supplier of the software component. That is, us.

Second, more important: in a market where everyone waits until the last moment, whoever moves first has an enormous competitive advantage. Not because they’re better. Because they’re the only one who can tell the client “yes, we’re ready” when the client, in a panic, starts asking.

At some point I stopped treating compliance like an obligation. I started treating it like a product.

And I often wonder why it took us so long to understand. Maybe because it’s more comfortable to think it’s just paperwork—until it suddenly becomes a problem with a deadline.

I stopped hiring for technical skills

This is recent and, if I’m being honest, still a bit painful.

I spent weeks looking for an important role. Candidates with excellent CVs. Years of experience. Solid stacks. Good references. I rejected several—not because they weren’t good, but because they used AI the way they used Stack Overflow ten years ago. Like an oracle.

What I was looking for, and what I still struggle to explain to recruiters, is different. I was looking for someone who could write a declarative spec so precise that an AI agent could implement it with minimal supervision.

Not a prompt engineer. A systems thinker who uses AI as a runtime, not as a crutch.

The difference seems subtle, but it isn’t. It’s the difference between someone who says “I asked ChatGPT to write the code for me” and someone who keeps a claude.md file in the repository with architectural conventions, patterns, domain constraints. It’s the difference between conversation and specification. Between craftsmanship and engineering.

I stopped hiring developers who can code. I started looking for developers who can specify and then verify what AI produced with the same rigor they’d use to review a junior’s code.

The Italian market doesn’t seem ready for this distinction yet, unfortunately. But I have a feeling it will be soon. And anyone who doesn’t get there in time risks ending up with teams that “produce” a lot, but understand little.

I stopped speaking Italian at work

It seems like a small thing. It isn’t.

When a new non-Italian junior joined—brilliant—we found ourselves facing a choice. Keep working in Italian among ourselves and use English only with him, effectively creating a two-speed team. Or switch completely.

We chose the full switch. Everything in English. Jira in English. Chat in English. Daily in English. Retro in English. For everyone.

I didn’t do it only for him. I did it for us.

Because a small company in an Italian city that works only in Italian is a company that will probably stay small in that city. There’s nothing wrong with that, truly. It’s just not what we wanted.

In the end, English isn’t a language. It’s infrastructure. Like Git, like CI/CD, like documentation. Either you have it, or you’re cut out.

It was uncomfortable. Some people struggled. But today, when I read pull request descriptions, messages, emails, I think it was worth it.

I stopped believing that good code speaks for itself

This is perhaps the most dangerous lie in software engineering. The romantic idea that if code is clean, tested, well-structured, then its value is obvious. That technical merit can defend itself.

It doesn’t work like that.

Good code that nobody understands is indistinguishable from mediocre code. Refactoring that nobody talks about becomes a cost, not an investment. An architectural migration without a written business case looks like a whim from the engineering department.

I learned, late, that half of a tech leader’s job is storytelling.

Explaining to the board why a migration isn’t a luxury but risk reduction. Explaining to the client why the automated tests they paid for are the reason they sleep well. Explaining to the team why CI/CD isn’t bureaucracy but freedom and convenience.

If you can’t tell the value of what you build, someone else will tell it for you. And they’ll tell it badly.

The thing I still haven’t stopped doing

If I want to be completely honest, there’s one thing I should stop doing and I still can’t.

Working as if I’m the only one holding the pieces together.

Too many things still go through me. Not because the team isn’t capable—quite the opposite—but because I still haven’t built the systems that make me redundant in each of the areas we operate in.

And that’s what scares me most.

Because every previous step had a clear replacement. Stop writing code? Specs. Stop writing specs? Strategy. Stop doing code review? A team lead. But stopping being the convergence point for everything is different.

The replacement is trust in systems. And systems, if I’m honest, I still have to finish building.

We’ll talk about it again.

And yet.

The customer is wrong.

Not always, of course. Not on everything. But much more often than we like to admit. And I wonder whether the real problem isn’t the customer themselves, but the polite lie we’ve been telling them for years. The one about “the customer is always right”. A lie that, in Italian software, has done damage you can’t even properly count, because failures rarely come with a sign saying “failure”. Usually they’re quieter. They’re projects that go to production and then no one uses. Money burned on things that don’t improve anything. Long nights of people who knew it was going wrong but didn’t have the space, or the permission, to say so.

This is a slightly mean piece. I’m not asking you to agree. I’m only asking you to be honest, at least for the duration of this read.

The yes that kills projects

I’ve watched more projects die from a yes than from a no.

The mechanism is almost always the same, and that’s exactly why it’s frightening. The client asks for something. You know it, you feel it, you see it in the details: it’s wrong technically, or economically, or just as a direction. But you say yes anyway.

You say yes because there’s a contract. Because there’s a relationship to protect. Because “we’ll fix it later”. Because the handshake already happened and going back feels like defeat. Because saying no is uncomfortable, requires arguments, requires energy, and above all requires courage.

So the project doesn’t die in one go. It dies one yes at a time.

Every yes adds a feature no one will use. Every yes shifts a piece of the deadline, or compresses a piece of the quality. Every yes makes the architecture a little more fragile and the code a little more contorted, until what you’re building no longer looks like a product, but a layered compromise.

In the end you ship software that does a hundred and fifty things, none of them well, and the client looks at you and says: “this isn’t what I wanted”.

And here’s the part that stings, because in a sense they’re right. It isn’t what they wanted. It’s what they asked for. Two different things.

And maybe our craft, the real one, isn’t to execute orders. It’s to recognise the difference.

Catalogue of horrors (all real, sadly)

What follows is true. The names are changed, the dynamics aren’t. And if you find yourself thinking “I’ve seen one just like that”—you aren’t alone.

The endless management system

A medium-large company asks for a management system. So far, normal. Then, while it’s being built, every department adds requirements. HR wants the leave module, marketing wants the dashboard, accounting wants the integration with the bookkeeper, and each one is convinced they’re the centre of the world.

No one has the power to say enough, because every department is an “internal client” who “is right”. Result: eighteen months of development, a product that does everything badly, and after release the company keeps using Excel. Which, in the end, at least doesn’t betray you.

The carbon-copy tender

A municipality has to digitalise a service. The tender is written by copying one from another municipality—maybe three times bigger, with completely different needs. Inside it end up requirements that read well on paper but no citizen will ever use.

Whoever wins the contract often knows. But the tender is the tender. So you build exactly what’s written. You deliver, you test, you tick boxes. The platform goes live.

Six months later the service is still being handled by phone.

And the saddest part is that, formally, everything went fine.

The app that was supposed to change everything

A local public administration wants a mobile app for citizens. The decision-maker is a council member who saw another municipality’s app and wants the same one. No needs analysis, no user research, nothing. Just: “I want the app”.

The vendor builds it. At launch, four hundred people download it. After three months it’s used by twelve, counting council employees.

The council member holds the press conference and talks about innovation. The vendor cashes the cheque and moves on to the next.

And I can never decide who in this story makes me more uncomfortable.

The restyle that was a rewrite

A client asks to “freshen up” the website. The salesperson sells a restyle. At the first operational meeting it emerges that the site has no CMS, the database is an Excel sheet, content doesn’t exist, and “freshen up” means rethinking the entire digital presence.

But the quote is for a restyle, the timeline is for a restyle, and the expectations are for a restyle.

Everyone knows it isn’t a restyle. No one says so.

The zombie project

A project was supposed to last six months and is in its third year. It doesn’t work, isn’t being used, but no one closes it because closing it would mean admitting it was a mistake.

The client keeps paying for change requests. The vendor keeps invoicing. Both know it’s dead. Both pretend it’s alive.

It never officially fails. It just stops being mentioned in meetings, like an awkward uncle no one talks about at lunch.

Why it actually happens

It happens because our sector has a structural problem with truth.

The business model of Italian IT consulting is built on yes. You win projects by saying yes. You retain clients by saying yes. You get promoted by saying yes. The whole system, from sales to project managers to developers, is optimised to minimise conflict and maximise short-term invoicing.

The trouble is, short-term and long-term are at war.

Saying yes today almost always means paying tomorrow. Every extra feature is technical debt. Every requirement accepted without analysis is a time bomb. Every timeline compressed to please someone is a guarantee of overtime—often unpaid—and of sacrificed quality.

Meanwhile the client never learns. Not because they’re stupid, but because no one tells them that request was wrong. No one tells them that tender was poorly written. No one tells them that app was useless to anybody.

Surrounded by people who nod, the client keeps asking for the same wrong things, and the cycle starts again.

And here’s the part that hurts, because it shifts the responsibility.

It isn’t the client’s fault. It’s ours.

It’s the fault of a sector that gave up its role—the role of the expert. The one who knows things the client doesn’t, and who has the duty, not the right, to say them.

The no as service

The best service you can give a client is to say no.

No, that feature isn’t needed.

No, that timeline isn’t realistic.

No, that tender is poorly written and if we follow it to the letter we’ll build something useless.

No, you don’t need an app.

No, you don’t need AI.

No, you don’t need a restyle. You need to stop and figure out what you actually want to do.

Every no costs. It costs awkwardness, costs tension, costs a few hard phone calls. Sometimes it costs the project.

But every no is also an act of respect for the client, because it treats them as an adult who can hear the truth, not as someone to be placated for a quiet life.

The best clients I’ve had in my career are the ones I’ve said the most “no” to. At first they tense up, which is normal. Then, if you hold firm and you argue calmly, something happens: they understand that when you say yes, you can be believed.

Trust isn’t built on continuous agreement. It’s built on candour.

And candour, in our sector, is rare. Maybe rarer than a good developer. Maybe rarer than a project delivered on time. Maybe rarer than a well-written tender.

A minimal manifesto, no heroics

I don’t know if this is a manifesto, but if it is, for me it lives in three lines.

Don’t say yes when you know it’s no.

Don’t build what the client asks for if you know it isn’t what they need.

And when you’re wrong—because you will be wrong, and we all will—at least be wrong by telling the truth, not by nodding.

The customer isn’t always right. But they always deserve someone with the courage to tell them.

With AI the same thing is happening. And yet, looking around, I see many companies reacting as if it were just another update. An add-on. A plugin.

Maybe that’s the problem.

The “let’s add a bit of AI” trap

By now it’s almost a reflex. A chatbot in customer service. A generated summary in the dashboard. A copilot in a sidebar. A “smarter” search.

These are useful things, really. I don’t want to play the purist who dismisses everything that works. But I wonder if they aren’t also, at the same time, deeply conservative. Like putting an electric motor on a horse-drawn carriage and calling it a revolution. The carriage stays a carriage—only what pulls it changes.

I’ve seen this dynamic before. In 2007 it was called “mobile”.

When the iPhone exploded, plenty of companies took their desktop sites and “adapted” them. Responsive, smaller buttons, reordered columns, hamburger menu, done. Technically correct. Strategically… almost irrelevant.

Because the winners weren’t those who adapted the old to the new—they were those who rethought everything.

Uber isn’t a taxi website made responsive. It’s a product that without GPS, always-on connectivity, and a device in your pocket would have made no sense.

Instagram isn’t a smaller Flickr. It’s a visual language born for mobile, designed to be used with one hand, while you walk.

WhatsApp isn’t email on a smartphone. It’s communication redesigned around an assumption: the device is personal, always with you, always connected.

None of these products would have been born from the “let’s fix what we have” mindset. They were born from a different question.

The right question

The question isn’t: how do I add AI to my product?

The question is: if I were designing this product today, knowing half the interactions will flow through AI agents, how would it be different?

It looks like a nuance, but it isn’t.

For twenty years we designed software starting from an almost invisible assumption: a human sits in front of a screen and interacts with a graphical interface. Click, scroll, fill fields.

That assumption won’t disappear, but it will stop being the only one. And when it stops being the only one, many choices that looked “natural” suddenly become arbitrary.

Think how many daily actions we do inside digital products that, with the right APIs and the right permissions, an agent could do for us. Book a restaurant. Compare quotes. Fill a form. Move an appointment. Analyse a report. Order groceries. Pay a bill.

It isn’t science fiction. Language models, today, can already manage complex flows. The bottleneck often isn’t the AI. It’s the way products are built.

A lot of software was designed to be looked at and clicked. Not to be understood and orchestrated.

That difference, I think, is enormous.

From interfaces to contracts

Here it gets concrete.

For years the “product” was the interface. The UI was the product. Everything else—backend, APIs, database—was infrastructure in service of the screens. Designers drawing screens, developers implementing them, product managers measuring conversions on buttons.

In the paradigm coming into view, the product becomes the contract.

Clear APIs. Structured documentation. Coherent data schemas. Capabilities exposed in semantically rich ways. Errors that explain what happened and what to do. Stable contracts.

The graphical interface doesn’t disappear, but its role changes. It becomes a client of the product, not the product. One client among many.

And, paradoxically, this is good news. Because an API designed to be consumed by AI agents forces you to write good software. It forces you to be clear. Coherent. Reliable. Composable.

AI isn’t lowering the bar. It’s raising it.

From features to capabilities

There’s a mindset shift that touches the heart of product management.

The traditional mindset is feature-driven. Add feature X. Need five screens, three endpoints, two tables. Wireframe, user story, acceptance criteria. And then a flow that’s almost always linear: the user lands at A, clicks B, fills in C, gets D.

The AI-native mindset, by contrast, tends to be capability-driven.

You don’t design a path. You design a building block. A capability that can be orchestrated by anyone: a human via GUI, an agent via API, another system via webhook. And often it’ll be combined with other blocks in ways you hadn’t anticipated.

It’s more powerful, but also harder. It requires thinking in terms of contracts, invariants, preconditions and postconditions. It requires more mature engineering.

And here, I’ll admit, I get a little excited. Because it’s as if the pressure of AI finally makes inevitable the best practices many engineers have repeated for years, often into the void.

The paradox of openness

There’s another aspect I find counter-intuitive.

For years the dominant model was lock-in. Closed data, hard exports, walled gardens. “That’s how we defend the competitive advantage.”

In a world of AI agents, closure risks becoming a handicap.

An agent works better with services that collaborate. That expose structured data. That have documented APIs. That allow interoperability. If a service is opaque and hard to integrate, the agent will tend to bypass it and pick more composable alternatives.

And here there’s a beautiful, almost poetic paradox: to keep users, you have to leave them free to leave.

This also shifts the playing field for small companies. Because on openness, on API quality, on documentation, on contract cleanliness, an agile SME can compete. Sometimes it can even do better than a giant full of legacy.

Compliance as superpower

This part is close to me, because it’s the ground I find myself on every day.

GDPR, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. They’re often experienced as a cost. A nuisance. A tax on doing business.

I, more and more, see them differently.

In an ecosystem mediated by AI agents, trust becomes a computational resource. It’s not just marketing. It’s an input to decisions.

If an agent has to choose between two similar services, it’ll tend to prefer the verifiable one. The one with a transparent SBOM. Complete audit trail. Documented privacy by design. Compliance declared and demonstrable.

In this sense, compliance stops being only a cost to bear and becomes a quality signal readable by machines. A competitive differentiator.

I realise it almost sounds odd to put it that way, but I believe it’s true: compliance can become a superpower.

And maybe Europe, with all its bureaucracy that makes plenty of people sigh, is building a terrain where trust is computable. If you can turn it into architecture, it isn’t a brake. It’s an advantage.

Where this becomes concrete

I could leave it here, on the level of ideas. But it wouldn’t be honest, because for me this transition is concrete, daily.

When we migrate a product, we aren’t just “modernising the stack”. We’re preparing a service for a future where agents will interact with these systems as much as humans do.

When we build an SBOM platform to manage software dependencies, we aren’t just doing compliance. We’re creating a layer of verifiable trust.

When we move the centre of gravity toward spec-driven development, where the spec is the primary product and the code is a derived artefact, it isn’t only a methodology. It’s a way of working in which AI can be a real partner, not a gadget.

At some point you notice everything holds together. Clean architecture, rigorous documentation, compliance by design, API-first, specs as the primary object. They’re faces of the same idea.

In the world coming, clarity is power.

The real risk

The biggest risk today isn’t doing “the wrong things” with AI.

It’s doing the right things, but in the old paradigm.

It’s adding a chatbot instead of rethinking the architecture of the interaction. Putting AI suggestions in an interface that maybe shouldn’t exist in that form. Using AI to write code faster without asking whether we should write clearer specs.

I know it’s a strong position. And I also know that many companies are getting real results by adding AI to existing products. I’m not saying it’s all wrong.

I’m saying it’s insufficient. That it risks being yesterday’s game with today’s pieces.

A love letter to technology that helps

I’ll close on a personal note, because for me this conversation isn’t only strategy.

I love technology when it helps. When it makes accessible what was exclusive. When it simplifies what was complicated. When it frees time for what really matters.

When I think about AI in digital products I don’t think—or at least not only—about chatbots answering on someone’s behalf. I think about an elderly person who can interact with public administration through an agent that understands and translates bureaucracy. About a small entrepreneur managing compliance without an army of consultants because the software supports them natively. About a doctor who can stay with the patient while the documentation is handled better. About a student with a disability who finds a truly accessible experience, not a tick in an Excel sheet.

To get there, though, “adding AI” isn’t enough. You have to rethink products around a world where humans and agents coexist.

It isn’t easy. It requires putting back into question assumptions we took for granted. It requires new skills and a certain humility. It requires the most uncomfortable question of all: if I were starting from zero today, would I do it like this?

But it’s a beautiful challenge. The kind that makes you want to roll up your sleeves.

Because on the other side, perhaps, lies more useful, more accessible, more reliable software. And, in a meaningful sense, more human.

“In your view, how long does this project take to close?”

I had everything I needed to improvise a credible answer. Years of experience, similar projects behind me, a gut estimate that could sound reasonable. Six months, maybe eight, with a prudent margin. Said in the right tone it would have looked the part: competent, reassuring, the voice of someone who knows their business.

Instead something else came out.

“I don’t know. Not yet. Give us two weeks to analyse the context and we’ll come back with a number we believe ourselves.”

The call went strangely silent. Three seconds, which in a sales conversation feels like a long time. Then the CEO on the other end said something that caught me off guard.

“Finally someone who isn’t pulling a number out of the air.”

We won that project. Not despite that “I don’t know”. Probably because of that “I don’t know”.

The age of instant answers

I often wonder when we decided that the speed of an answer was a proof of intelligence. Or competence. Or authority.

Today an answer is always available. About anything, at any time, in less time than it takes to phrase the question well. You search Google and in a fraction of a second you have endless results. You ask a language model and you get fluent text, well-written, even convincing.

And so, without noticing, we’ve internalised a slightly toxic equation: whoever answers fast knows. Whoever hesitates doesn’t. Whoever says “I don’t know” is out of the game.

You see it in meetings, where whoever speaks first often “takes” the room. You see it in job interviews, where hesitation gets read as unpreparedness, even when it’s just caution. You see it in consulting, where “let me think about it” feels like a loss of value, as if the client were paying for ready-made certainty in your pocket.

And then you see it in AI, which is maybe the most perfect embodiment of this mechanism.

A language model isn’t designed to stop and say “I don’t know”. It’s designed to produce an answer. Structured, plausible, maybe brilliant. Even when it doesn’t know. Sometimes especially when it doesn’t know. Hallucinations aren’t a folkloric incident, they’re the natural consequence of a system trained to always fill the void.

We’ve built a perfect machine for an age that decided silence is a defect.

The cost of fake certainty

The interesting question, though, isn’t why AI can’t say “I don’t know”. It’s why we struggle so hard to say it ourselves.

I’ve spent twenty years between technology and consulting. Meetings, calls, presentations, workshops. If I think back to the times someone openly said “I don’t know” without it sounding like a confession of guilt, I can count them on one hand. The unwritten rule is clear: you have to have an answer. Better wrong than absent.

The problem is that this norm has an enormous cost, only it’s hard to see while it’s happening.

You see it later, when a project estimated at three months drags on for twelve, and at some point someone says quietly: “we didn’t actually have enough information to estimate”. You see it when an architecture is chosen because someone spoke with great confidence in a meeting, and the honest version would have been: “let’s do a proof of concept before deciding”. You see it when a contract is born crooked, because the timeline got promised before anyone understood what was really underneath.

I’ve watched products fail not because competence was missing, but because the courage to admit uncertainty was. And the bitter part is that the people faking knowledge often get rewarded. Certainty, even fake certainty, is reassuring. It gives the illusion of control. And whoever offers it gets perceived as a leader.

It’s a slightly inverted incentive system: it rewards speed over truth, confidence over honesty, appearance over substance.

Three dangerous words

“I don’t know” is dangerous because it breaks a power dynamic.

In a meeting with a client, saying “I don’t know” means admitting that you, the expert, the one being paid to know, don’t know in that moment. It’s as if you cracked the implicit pact of consulting, where the client buys certainty and you sell it.

Inside a team, if you’re the lead, saying “I don’t know” is even more counter-intuitive. Because we’ve been taught that leading means having the direction, having the answer, having the plan. And no one wants to follow someone who admits not knowing the road.

Yet if I think back to the best decisions I’ve made, there’s almost always an “I don’t know” at the start. Not because ignorance is a virtue. It isn’t.

It’s because “I don’t know” is often the only honest starting point for a serious decision. It’s the moment you stop performing and start reasoning. It’s the move from the prepackaged answer to the real question.

When someone says “I don’t know”, odd things happen. The air lightens, as if it suddenly became permitted not to know. Someone finds the courage to say “I have a doubt too”. Information surfaces that had stayed hidden because no one wanted to look like the one slowing things down.

Maybe that’s the part that interests me most: “I don’t know” isn’t the opposite of competence. It’s often its prerequisite.

The AI paradox

Here comes the paradox.

AI makes it even harder to say “I don’t know”. Because if a machine produces an answer on any topic in two seconds, how do you justify that you, a professional with years of experience, don’t have one ready?

The benchmark shifts. The machine’s speed becomes the standard against which we measure human speed. And in that race, stopping to think becomes a luxury.

Except it’s the wrong benchmark, founded on a confusion: mistaking having an answer for having the right answer.

AI always has an answer. Often it’s good. Sometimes excellent. But it doesn’t know when it doesn’t know. And that, paradoxically, is one of the most precious capacities we have: recognising that a piece is missing, sensing that something doesn’t add up, intuiting that the variable being ignored is precisely the one that changes everything.

Socrates built a whole philosophy on it: knowing that you don’t know as the basis for actually knowing. Twenty-five hundred years later, we have machines that don’t know they don’t know, and we use them as a model of cognitive efficiency. The irony is almost perfect.

A quiet competitive advantage

My experience is what it is, limited and full of bias, like all experience. But it has left me with a fairly stable conviction: people and companies who can say “I don’t know” at the right moment win in the long run.

The clients I’ve worked with longest are often the ones with whom, at the start, I admitted I didn’t have all the answers. Not because they appreciated incompetence, but because that gesture created a different kind of relationship. A relationship where it was permitted to explore, ask questions, change one’s mind. Where the solution didn’t have to be ready by slide three.

The best people I’ve worked with are the ones who, in the middle of a meeting full of acronyms, said “I don’t understand” or “can you explain?”. The famous “stupid” question everyone has in their head and no one asks. Almost always it’s the one that unblocks everything.

And the best decisions, the ones that years later turned out to be right, had a moment of suspension before becoming a “yes” or a “no”. A small space of legitimate doubt. A refusal to answer just to take the pressure off.

It isn’t a method. It isn’t a framework. It isn’t a slide on vulnerability.

It’s something simpler and harder: accepting that competence includes recognising your own limits, and that those limits aren’t a shame. They’re the exact border where real thinking begins.

The last word

We live in an era that demands immediate answers about everything. Algorithms that respond in milliseconds, colleagues who expect answers in minutes, clients who want them in hours.

In this constant noise of cheap certainties, saying “I don’t know” almost becomes a subversive act. A small resistance against a system that mistakes speed for truth and confidence for competence.

I’m not making a case for ignorance. I’m making a case for the pause. For that uncomfortable moment between question and answer in which, if you resist the temptation to fill it with the first thing that comes to mind, something rare happens.

You actually think.

It produced an impeccable document in forty seconds. Clean architecture, three-environment cost estimate, timeline with milestones, risk analysis. Perfect formatting. Professional language.

I threw it all away.

Not because it was wrong. It was technically correct—probably better than what I would have written off the cuff. I threw it away because that client, three months earlier, had told us in a call that their CTO had been fired after a failed project with an approach similar to the one being proposed.

You won’t find that in any dataset. It isn’t in any prompt. It’s an organisational scar that lives in the memory of the people who were on that call, and it changes everything: the tone of the proposal, the choice of solution, even the words to use and the ones to avoid.

The AI had produced the right answer to the wrong question. That’s something it does brilliantly.

The invisible work

I lead in a deliberately small company. My job, on paper, is making decisions: which product to build, for whom, with what priorities, by when. If you looked at my job description, a language model could do ninety percent of what I do. Maybe more.

But the job description is a lie. Like all job descriptions.

My real work is made of things that don’t sit in any backlog or any project document. It’s made of silences during calls—that moment when a client says “yes, fine” with a tone that means “no, this isn’t fine at all, but I don’t feel like arguing right now”.

It’s made of lunches with a colleague who hasn’t been delivering for two weeks and who, over a second coffee, tells you they’re going through a hard time at home.

It’s made of the decision, taken at eleven at night, not to reply to a provocative email from a stakeholder and to wait until morning, when the words weigh less.

None of this is computable. And I don’t think it’s only a problem of missing context that gets fixed with a longer prompt or a more sophisticated RAG.

It’s a different kind of knowledge. It’s situated, relational, almost embodied.

You know a meeting is going badly because you feel the tension in the room. You know an estimate is inflated because you know who made it. You know a requirement should be refused not for technical reasons but because accepting it will push the product in a direction it can’t come back from. And you know it because you’ve been in that direction three projects ago, with another client, and you have the scars to prove it.

AI works on what is explicit. My craft lives in what is implicit.

Four things I can’t delegate

I tried an exercise, partly out of curiosity and partly out of fear: identify the parts of my work a language model, however advanced, can’t do.

Not the parts it can’t do yet. The parts that, by how it’s built, it probably can’t do. Or at least not in the same way.

I found four.

The first is reading people

I don’t mean assigning tasks or doing performance reviews. An Excel sheet can do that, often better.

I mean the real part. Understanding that a colleague who suddenly starts producing sloppy work doesn’t have a competence problem but a motivation problem. And that the motivation problem comes from the fact that in the last three sprints you put them on activities they considered below their level.

And that they didn’t tell you because they’re afraid of looking arrogant.

And that you know it because you’ve known them for four years and you know how they react when they feel undervalued.

This causal chain isn’t written anywhere. Half the links have never been verbalised. They exist in the space between two people who have worked together long enough to understand each other without speaking.

Managing a team isn’t optimising resources. It’s navigating the emotional complexities of a group of human beings who spend more time together than with their families.

And doing it without manuals, without metrics, often without even noticing.

The second is understanding what a client actually wants

Not what they say they want. What they actually want. Almost always two different things.

A client asking for a document management system often doesn’t want a document management system. They want their boss to stop asking where files are.

A client asking for a mobile app wants to prove to the board that their division innovates.

A public-administration client putting out a tender for a digital platform often needs something much simpler—but the tender was written by copying one from another municipality with completely different needs.

My job is to dig under the request until I find the need. And the need is almost always political, organisational, emotional. Rarely technical.

You get there by asking questions that have nothing to do with technology. Who will use this system? Who decided it was needed? What happens if we don’t do it? Who gains and who loses?

These are questions an AI doesn’t ask, because it doesn’t know if and when they should be asked.

Maybe that’s the part that worries me most. It isn’t that the machine answers badly. It’s that it answers well to a question that maybe no one should have asked that way.

The third is weighing context that isn’t written anywhere

Every product has a story. Not the one written in the documentation, which is the official version. The real story is made of compromises accepted because the budget ran out, of features added to please a stakeholder who later changed roles, of choices that were wrong but are now so entangled with the client’s processes that removing them would cost more than living with them.

When I have to decide whether the next release should rewrite a module or add a feature, I can’t ask a model.

Because the right answer depends on who uses that module, how they use it, what was happening on the project when it was built, what the current relationship with the client is, and whether that client will still have budget for phase two in three months.

An AI can tell you what the ideal roadmap is in the abstract.

A product leader knows what the right roadmap is for that product, with that team, for that client, at this moment.

The difference between the two is the difference between a recipe book and a cook.

The fourth is saying no

It’s the most important and the least technical of all.

Saying no to a feature that looks reasonable but will lead the product into a dead end.

Saying no to a client who wants an impossible timeline, knowing you’ll lose the contract.

Saying no to a stakeholder pushing for a fascinating pivot that would destroy two years of accumulated value.

Saying no to yourself when enthusiasm for a new idea is making you lose sight of the fact that your users need something that works, not something innovative.

No is an act of judgement that requires courage, context, and responsibility.

AI never says no. It can’t afford to. Its design is optimised to be helpful, to give answers, to resolve.

But sometimes the most useful thing is to stop. Sometimes the best answer is “we don’t do it”.

And no prompt in the world can teach a model when that moment has come, because recognising it requires something no training set contains: the weight of consequences on your own shoulders.

The amplification paradox

To be clear, I’m not saying AI is useless. That would be dishonest as well as stupid. I use it every day. My team uses it to produce, document, analyse. We save hours, days, weeks, months. Deliverable quality has gone up. I wouldn’t go back.

But there’s a paradox I see emerging that worries me.

The more AI handles the “producible” parts of the craft—documents, analyses, specs, code—the more value concentrates in the “imponderable” parts: decisions, relationships, the no’s.

And those are exactly the parts you don’t learn by reading documentation or taking courses. You learn them by failing, observing, sitting in a room with other people for years.

The risk, I wonder, is that a generation of professionals grows up delegating the executable parts without ever passing through the phase where those parts teach you the craft.

Writing a wrong proposal, running a demo that falls apart in front of the client, losing a contract because you underestimated a requirement—these aren’t only training pain. They’re the process through which you develop the intuition that later lets you make the decisions AI can’t.

Skip that step and you arrive at the negotiation table without ever having felt the weight of a wrong choice. At that table, AI can’t help you.

The craft that remains

My craft is changing. It isn’t disappearing, it’s changing shape.

The time I used to spend producing deliverables I now spend reasoning about what those deliverables should say.

The time I used to spend looking for information I now spend deciding what to do with it.

The time I used to spend on repetitive work I now spend talking to people—colleagues, clients, users.

It’s a shift up the value chain, and in some ways it’s a liberation.

But it carries a new responsibility, which is maybe an old responsibility seen with different eyes: don’t confuse speed with competence.

The fact that a tool helps me produce more doesn’t mean I know more. It means I have more time to apply what I know, or to discover what I don’t know, if I’m honest with myself.

AI knows what was written.

My craft is knowing what wasn’t written, and often what can’t be written.

As long as that’s the case—and I suspect it’ll be the case for a long time—the craft remains. It changes shape, changes pace, changes tools.

But it remains.

What AI doesn’t know about my craft is, in the end, what makes it a craft and not an algorithm.

On 6 February 2026, the European Commission did something that, the way I read it, marks a before and after. It didn’t say “this content is forbidden”. It didn’t ask anyone to take down a hashtag or remove a video. It put an interaction pattern in question. A design choice.

According to preliminary findings under the Digital Services Act, TikTok’s infinite scroll pushes users into “autopilot mode”, feeding compulsive behaviour. So, Brussels says, the platform has to change the basic design of the service: disable infinite scroll, introduce mandatory pauses, rethink the recommendation system. If it doesn’t, the fine can reach 6% of global annual revenue. For ByteDance, that’s tens of billions—the kind of number that makes wrists tremble.

Two weeks later, on the other side of the ocean, Mark Zuckerberg is sitting in a Los Angeles courtroom. It’s the first jury trial on social media addiction in U.S. history. A young woman, identified as K.G.M., describes being pulled into Instagram as a child and developing depression and suicidal ideation. In the background sit more than 1,600 similar lawsuits.

The lawyers display Meta’s internal emails. One sentence sticks: “IG is a drug. We are pushing users.” Another email suggests the company knew that more than 30% of children aged 10 to 12 used Instagram, breaking its own policies. Zuckerberg replies that the goal is to make the service “useful”, not to maximise time on platform. Meanwhile the judge warns the audience not to record proceedings with AI glasses—some members of Zuckerberg’s entourage, apparently, had shown up wearing Ray-Ban Metas.

Two continents. Two approaches. The same problem.

Design is politics

It’s worth pausing on what happened on 6 February, because it’s more radical than it looks.

Europe didn’t regulate content. It said that the form itself of the interaction between a person and an app can constitute a systemic risk. That a thumb movement, if designed never to end, isn’t “your weakness”. It’s the platform’s problem.

This is, in fact, the first time a regulator has tried to set a legal standard on the addictive potential of design. It isn’t a law “against infinite scroll” in the abstract. It’s a larger principle: addictive design is a risk, and infinite scroll is one of its most visible manifestations.

The interesting part—and the slightly unsettling one—is that the principle doesn’t stop at TikTok. Meta has been under investigation since May 2024 for similar reasons. The famous “rabbit hole”, the tunnel you enter watching one piece of content while the algorithm pushes you toward more and more similar—and sometimes more extreme—content, is in the crosshairs. X has already taken a €120 million fine for “deceptive design practices”.

The EU’s approach looks more and more like this: not just “what you can’t show”, but “how you can’t make people feel”.

For people who build software, the ground really does shift here. Code has never been neutral, we know that, but now it’s officially also a question of legal liability. The Product Liability Directive coming into force on 9 December 2026 includes software among products. The Cyber Resilience Act demands security by design. The AI Act imposes risk assessments. And now the DSA suggests that even the way you organise a feed can become a violation.

A simple image comes to mind: the door handle that won’t let you out. It isn’t a problem with the person trying to leave. It’s a problem with the handle.

The quarterly vs. the neuron

The question, though, remains. Why did we get this far? Why do we need courts and commissions to say something anyone with a child—or just a thumb—already senses?

One answer, maybe, is in the internal documents emerging from the U.S. trials. It doesn’t look like negligence. It looks like a deliberate choice, repeated, driven by a metric: engagement. And engagement, in the end, is the antechamber of the quarterly.

Those documents show that increasing time spent on platforms and growing among teens wasn’t a side effect. It was a goal. Emails from 2015 and 2017 discuss how to prioritise growth among adolescents. Internal studies record some teenagers describing Instagram with words very close to behavioural addiction.

And still no one stops. The measuring continues.

Adam Mosseri, head of Instagram, testified that in his view it’s not “clinical addiction” but “problematic use”. Maybe the distinction matters in a courtroom. In real life, I wonder how much it changes. The point, in any case, is that they knew.

They knew that certain face filters simulating plastic surgery could affect adolescent girls, and after internal debate they chose a “more targeted ban” rather than a complete one. They knew the parental controls were easy to bypass, and they presented them as a solution. They knew children under 13 were on the platform by the millions, and they kept counting them as users.

Here an economic concept comes in that I find useful, even if it’s a little frightening how well it fits. It’s called externality: a cost the producer offloads onto society without paying for it. Pollution is the classic example: the factory produces, the river pays.

With social media we’ve had a new form of externality for twenty years. We could call it, without exaggeration, the attention externality: the cost society pays when a company extracts attention the way a mine extracts coal, without compensating for the damage. Lungs become neurons. Air becomes time. The river becomes someone’s childhood.

And the difference from industrial pollution, perhaps, is this: here the harm isn’t only a side effect. In many cases it was designed. It isn’t the production’s waste. It’s the product.

Autopilot and dignity

In the European findings there’s an expression that stuck with me: “autopilot mode”. Certain features, the Commission writes, shift users’ brains into autopilot, feeding the impulse to keep scrolling. Scientific research, they add, shows that these mechanisms can reduce self-control and contribute to compulsive behaviour.

Autopilot is a strange word, because in other contexts it’s almost positive. In aviation it makes sense: it frees cognitive resources for more important decisions. In a social media app, on the other hand, it removes the most important cognitive resource we have at that moment: the ability to choose when to stop.

Byung-Chul Han described contemporary malaise well by talking about the achievement society and self-exploitation. The idea, simplified, is that today no external master is needed. We squeeze ourselves: we optimise, perform, consume, until burnout. And the smartphone is the perfect instrument for it.

But there’s another step the TikTok-DSA case makes more visible. Self-exploitation isn’t always self-generated. Sometimes it’s designed by someone else and then sold as freedom.

Infinite scroll isn’t the user’s decision. It’s a decision by a product team, validated by an A/B test, approved by a VP of Growth, celebrated in a quarterly business review. The user isn’t self-exploiting. They’re being exploited inside an architecture that simulates choice.

And here, if you want, you could even bring in Kant without going full salon-philosophy. Treat people as ends, never only as means. The user-as-KPI is the user-as-means promoted to a business model. You aren’t a person using a service. You’re a unit of attention to extract, an eye to monetise, a thumb to keep moving.

Maybe that’s why what Europe is doing feels, underneath, like a defence of dignity. Not just consumer protection. The idea that we have a right not to be manipulated, even when the manipulation is elegant, well-designed, and packaged in a colourful interface with rounded corners.

Two models of the world

The contrast between Brussels and Los Angeles tells two different philosophies.

In the United States the system is adversarial. A family takes a company to court, presents documents, witnesses, expert reports. A jury decides whether Instagram was a “substantial factor” in the harm of one specific person. It’s a case-by-case model, where the burden of proof falls mostly on whoever was harmed.

And in that context everything becomes ambiguous. YouTube, in the same lawsuit, tries to defend itself by saying it’s more like Netflix than a social platform. Meta says the problem isn’t the app, it’s the content—or maybe it’s the girl’s personal life. The lines between “platform harm” and “content harm” are hard to draw. People argue over the definition of “addiction”. They postpone. They negotiate.

In Europe the approach is more structural. You don’t wait for the harm, you regulate the design. You don’t ask the individual to prove that infinite scroll ruined their life. You ask the platform to prove its design isn’t intrinsically risky. The DSA treats addictive design as a systemic risk on a par with disinformation or election interference.

It’s an asymmetry that reflects two ideas of freedom.

In the United States, often, freedom is absence of constraint: you’re free to use TikTok or not, and if it hurts you that’s your problem—or your lawyer’s.

In Europe, at least in this framing, freedom includes protection from manipulation: you’re free only if the conditions you operate in aren’t designed to strip you of the ability to choose.

Neither model is perfect. But one of them, today, is trying to change the game before millions of people have to walk into a courtroom and recount their childhood in front of a jury.

The question for builders

I build software. Every day decisions get made that look small and aren’t. Where to put a button. How to structure a notification. How easy or hard to make leaving a flow. Whether to show a counter, a badge, a red dot.

I don’t build social media. I work on platforms for public administration, e-learning, B2B services, legal tools. My world is a thousand kilometres from infinite scroll. And yet the principle Europe is trying to fix sounds universal: design isn’t neutral. Every interface choice is also an ethical choice. And now, like it or not, also a choice with legal consequences.

For years the social platforms enjoyed a kind of de facto impunity, because regulation couldn’t keep pace. That time looks over. The DSA, the Product Liability Directive, the Cyber Resilience Act, the AI Act are pieces of a mosaic redrawing the relationship between those who produce technology and those who use it.

Those who endure it, you might say, after reading certain internal emails.

In the end, a conviction stays with me, and it probably gets stronger every time I see a product “grow” thanks to a cognitive trick: software that respects the people using it is better software. Not because Europe imposes it on us, but because it’s the right thing to do.

And maybe the most radical thing today is to do something radically obvious. Build technology that doesn’t need a court to order it to stop doing harm.

Infinite scroll will end, in one form or another. The real question is what we put in its place. If it’s just another trick to keep you glued, with a different name and a slightly subtler mechanism, we won’t have solved anything.

If instead it’s a design that starts from the question “what does this person need?” rather than “how do I keep them here one more minute?”, then maybe 6 February 2026 will be a date worth remembering.

Not for the scroll it called into question, but for the question it made unavoidable.

Everyone was nodding. The budget was approved.

Three months later, the project was gone.

It isn’t a rare story. 84% of Italian SMEs run into trouble executing digital projects, and 15.8% report a complete failure. Globally the music is similar: roughly 84% of digital transformation initiatives don’t reach their expected results, often for reasons that have little to do with technology.

The point, though, isn’t only that projects fail. It’s that some projects are born dead. The signs are there from the start, only they’re discreet, almost polite. And if you don’t know where to look, you mistake them for ordinary complexity.

The sponsor who “supports from a distance”

The first sign is the one that looks least serious. On paper, the project has an important sponsor: founder, CEO, someone “putting their face on it”.

Then you never see that face.

The sponsor delegates, sends an endorsement email, maybe opens the kickoff with a five-minute motivational talk. And then disappears from the operational meetings, the ones where the real knots get untied. The result is fairly predictable: the moment the first internal resistance shows up, the resistance wins. Not because it’s stronger, but because it’s more patient.

In many SMEs the resistance isn’t even malicious. It’s routine, urgency, “let’s close the month first”, “we’ll talk after the trade fair”, “we can’t stop the warehouse right now”. If the sponsor isn’t there when choices need to be made, the implicit message is simple:

This project can wait.

And things that can wait, wait forever.

It isn’t only a feeling. 56% of digital transformation projects don’t get real support from senior leadership.

Goals written by copy-paste

“Improve efficiency”. “Optimise processes”. “Increase digital competitiveness”.

When I read goals like that, I always wonder: are they describing something they actually want to do, or are they just looking for a phrase that sounds right in a document?

The problem isn’t that they’re false. It’s that they’re not verifiable. They don’t help you understand, six months in, whether the project worked. And they especially don’t help you decide what to do tomorrow morning.

A line like “reduce order fulfilment time by 30% within six months” changes everything. It forces you to pick a scope, find a baseline, understand where to act. “Digitalise the company’s processes” is a fog. Everything fits inside it, which means nothing does.

Not surprising that 64% of digitalisation projects start without a clear roadmap. The main cause might be exactly this difficulty in turning generic ambition into measurable goals.

And there’s a slightly toxic side effect: vagueness makes it easy to declare success without having achieved much. You just have to tell the story well.

No one knows who decides

This sign is sneaky, because at the start it looks like collaboration. Lots of people involved, lots of departments invited, lots of opinions gathered.

Then, when a real decision arrives, no one knows who has the final word.

Who approves the technology choices? Who resolves the conflict between sales and operations? Who decides whether to accept a scope change proposed by the vendor? Who says “OK, we do it this way” when both alternatives are inconvenient?

If there’s no clear answer, something I’ve seen recur often happens: decisions don’t get denied, they get postponed. They turn into email loops, meetings that end with “we’ll sync up”, shared documents full of comments.

And the project doesn’t collapse spectacularly. It dissolves. A little at a time.

The literature is less romantic than we’d like: effective governance requires an internal owner who can coordinate technology choices, vendor relationships, and outcome monitoring. Without one, the project drifts.

The stack picked by the vendor

This is the one that makes me most uncomfortable, maybe because it’s the hardest to recognise when you’re inside the company.

The vendor arrives with a ready-made solution. It might even be a good solution, in its own context. But they propose it as the natural answer to the company’s problems, and the company accepts because it hasn’t done a real needs analysis.

Sometimes it happens out of haste. Sometimes because “they’ve been doing this for years, they’ll know what’s needed”. Sometimes because no one internally has the skills or the time to question the proposal.

The result tends to be the same: an expensive technology gets bought that doesn’t fit existing processes, or upends them in ways the organisation isn’t ready to absorb.

The right sequence would be banal, yet it’s extremely rare: first you understand what you want to solve, then you pick the technology.

When the stack has already been decided before the first strategic meeting, something is off.

KPIs that can’t be measured

The last sign often shows up when time, energy, and reputation have already been spent.

The KPIs get defined. Everyone is happy because “at least we’re measuring”. Then no one asks a very simple question: does the data to measure them exist?

“Customer satisfaction improvement” is a KPI only if you have a consistent way to measure satisfaction before and after. “Operational cost reduction” works only if you know which costs you’re tracking, and you track them cleanly.

When KPIs get defined to reassure the budget approver and not to steer the project, they become elastic numbers. And if a number can be interpreted a thousand ways, it will never plainly say the project is failing.

There’s an interesting point here: sometimes measuring becomes a kind of theatre—a practice that looks serious but doesn’t change decisions.

The PO: the role no one called

If you think about it, all five of these signs share something. They aren’t technical problems. They’re problems of clarity, accountability, communication.

And there’s a role that, in theory, was created precisely to govern that kind of chaos: the product owner.

In an SME, often no one has time for the “boring” part of the project. The part made of repeated questions, definitions, boundaries, priorities. And yet that’s exactly where it’s decided whether a project really starts.

A PO doesn’t accept “improve efficiency” as an answer. They insist, sometimes too much. Which process? Which metric? From when to when? Who’s putting their hands on it? What changes for the people who today do that work a certain way?

On the weak-sponsor problem, the PO can’t replace leadership—it would be naive to think otherwise. But they can make leadership more effective. They can prepare decisions that force the sponsor to choose between concrete options, instead of nodding along to vague presentations. In practice, they reduce the cognitive friction for the person who’s supposed to lead and often doesn’t know where to start.

On governance, the PO brings structure almost by definition. They manage priorities, make explicit what’s in and what’s out, keep track of commitments. They don’t eliminate internal politics, but they make it visible—and that alone sometimes changes the game.

On vendors, perhaps it’s the most valuable function. The PO sits in front of the vendor not as a naive customer but as an interlocutor who understands what they’re buying. They can tell a proposal built around the company’s needs from one built around the vendor’s catalogue.

I wonder whether the real problem is that in Italian SMEs this role is still seen as a luxury—something for big companies or funded startups. I have the opposite impression. Where resources are limited and mistakes are expensive, having someone who asks the right questions at the start is worth as much as not throwing six months away on a project that, fundamentally, wasn’t going to ship anyway.

And maybe the most useful question, before picking software at all, is this: who takes responsibility for making the project real, day after day? If there isn’t a credible answer, maybe better to stop there. Not out of cynicism, but out of respect for everyone’s time.

It isn’t a metaphor or a figure of speech. Three real, measurable minutes—the kind that pass while in a classroom someone coughs, someone takes notes, someone checks the time.

During a seminar on generative AI in business, at the university, I opened Claude Cowork and gave it three CSV files of e-commerce data and a brief of a few lines. Sales, customers, marketing. Then I asked for something very “course-style”: segmentation, KPIs, ROAS by channel, charts, and a strategic report with budget recommendations.

In three minutes the AI did the analysis, built an RFM segmentation, calculated return on ad spend, produced interactive visualisations, and wrote a report that, at first glance, looked complete.

Not perfect, no. Not ready to be presented to a board without a serious review. But it was exactly the kind of deliverable that often gets requested as a final project. The kind of thing a university course schedules over a year.

I’m not writing this to belittle students or teachers. I’m writing it because that scene forced me to look in the face something that, if I’m honest, I’d rather not see: the silent divergence between the speed of technology and the speed of institutions.

Two clocks ticking different times

The university is designed to move slowly. And it isn’t necessarily a defect, on the contrary. It’s how it guarantees quality: committees, accreditations, panels, reviews, consensus. It’s almost in the DNA of these institutions not to run.

The problem is that outside the classroom, in the meantime, the world isn’t just running. It’s changing shoes every two kilometres.

A university curriculum often takes 12–24 months to be designed, approved, and implemented. Courses get planned far in advance. Textbooks have long editorial cycles, and even when they’re excellent, they arrive in a world that has already moved on.

Innovation, by contrast, thinks in releases. AI coding tools went from “curiosity” to industrial standard in a few months. AI agents complete work that previously took weeks. Startups founded by recent graduates reach huge valuations in timeframes that no longer resemble old industrial cycles.

So we end up with two clocks in the same room.

One ticks semesters and study plans.

The other ticks deploys, updates, new models, new interfaces.

The distance between the two isn’t only organisational. It’s becoming cultural.

The half-life of skills: from decades to months

There’s a concept that comes up often when we talk about work and technology: the half-life of skills. The time after which half of what you learned becomes obsolete or irrelevant.

Forty years ago that could be a decade. Today, for many technical skills, it’s around 2.5 years.

And yet you don’t even need to ask whether 2.5 years are a geological era when we talk about AI and software development. AI assistants for coding went from experiment to widespread presence in a very short time. Anyone who learned to program in 2022 without touching AI coding tools today finds themselves working with a piece of the toolkit missing.

Global estimates put even sharper numbers on the picture: by 2030, 39% of key skills required in the labour market will change. And 59% of the global workforce will need reskilling or upskilling.

Now take a bachelor’s degree: three years. Add a master’s: another two. Five years.

In the same span a student takes to complete the path, an enormous part of what the market considers “key” will have changed.

And here the question stops being theoretical. It becomes almost intimate: what are we promising the young people enrolling at university?

Entering the workforce is a wall, not a door

If it were just a content misalignment, we could discuss it calmly. The problem is that the entry-level numbers tell a harder story.

In recent years, entry-level hiring at many large tech companies has dropped sharply. In several markets we’re seeing major reductions, and in Europe in 2024 many tech positions for graduates fell significantly, with prospects that aren’t exactly rosy.

Then there are layoffs openly framed as “AI-enabled”. Companies cutting corporate roles because AI allows leaner structures. Some have publicly said AI now handles a huge share of the work.

And while this happens, among young people a feeling grows that you sense even without surveys: the idea that the market has become more closed, more selective, harder to cross.

Almost half of young job seekers believe AI has reduced the value of their university education.

It isn’t science fiction. It’s the present. And when the present knocks at your door, you can’t keep postponing the conversation.

The entry-level paradox: when AI eats the first rung

There’s a detail that makes everything more insidious.

The implicit entry-level pact, for years, was this: you do repetitive work, you cut your teeth, you learn. In exchange you get mentorship, context, growth.

That repetitive work is exactly what AI absorbs best.

So the first rung of the ladder disappears.

This is the part that worries me most, because it’s a “transmission” problem of skills. If you don’t hire juniors today, who becomes senior tomorrow? Someone described this choice as “eating the seed corn”. You save now, you pay later, and you pay with interest.

Meanwhile the university risks a vicious circle: training people for entry-level roles that are shrinking, using curricula that can become old before even reaching cruising speed.

The 2026 graduate comes out with 2023 knowledge on average, because that’s the year the curriculum was designed, for a market that has since gone through two or three revolutions.

Three minutes vs. a year, and what I saw in students’ eyes

Back to that demo, because there—more than in the charts—was the emotional part.

The brief was a few lines. Three CSVs attached. Zero configuration.

In three minutes the AI produced aggregated metrics, segmentation, ROAS, visualisations, recommendations.

Again: it wasn’t perfect. But it was good enough to set off a silent question.

And the question, in the classroom, showed in the eyes.

I didn’t see panic. I saw concentration. I saw that form of attention that arrives when you understand the ground under your feet is really moving.

I don’t know why, but that gave me hope. Maybe because it seemed the students weren’t pretending. They were looking.

And maybe that’s where the move starts: from not pretending.

Because the message, in the end, was clear. The “what” you learn is becoming less important than “how” you learn to learn.

Italy: goodwill, geological timeframes

In Italy we aren’t standing still. It would be unfair to say so.

In recent years AI training offerings have grown, with new degree courses, master’s programs, contamination with other disciplines, advanced training in specific fields. There are national strategies, university-business collaborations, e-learning platforms.

These are important steps.

But there’s a big “but”: they move at institutional speed. Tenders, committees, collegial bodies. Meanwhile outside, things move at deployment speed.

When a course gets activated after years (or even months) of process, the tools it teaches risk having already changed twice. Not because the course is poorly designed. Because time has become the adversary.

And here the divergence hurts most, because it isn’t a question of incompetence. It’s a question of architecture.

Universities guarantee quality through slowness.

Technology guarantees relevance through speed.

For years these two logics coexisted. Now they’re starting to clash.

What we’re teaching, and what maybe we should be teaching

The skills growing fastest in the coming years are a strange and beautiful mix. On one side AI and big data, cybersecurity, technological literacy. On the other creative thinking, resilience, flexibility, curiosity, lifelong learning, leadership.

Technical and deeply human together.

So I wonder if the point isn’t exactly this.

Teaching a tool isn’t enough. You have to teach how to think, adapt, communicate, decide under uncertainty. Because tools change. And they change fast.

There’s also a phenomenon I think we’re reading wrong: the widespread dependence of students on AI.

We often call it laziness. Sometimes it is, of course. But sometimes it’s a signal. Students sense when they’re being asked to invest energy in skills that look irrelevant or already obsolete. And they look for shortcuts because, from their point of view, the game isn’t worth the candle.

Universities (and schools) responding by banning AI are fighting a lost war.

Those that integrate it superficially risk doing something else: normalising the use without really changing the goal.

Maybe what’s needed is a more radical rethink of what “competence” means in 2026.

The end of the static curriculum

I don’t presume to have definitive solutions. The more I think about it, the more it seems a problem full of real trade-offs.

But some directions, at least, are visible.

The first is modularity. Abandon the idea of the monolithic multi-year curriculum and shift toward short, updateable, composable modules. Micro-credentials that get refreshed every semester. It isn’t a “modern” whim. It’s a way to realign education to a world that doesn’t wait.

The second is bringing real problems inside, not exercises. The difference is simple: an exercise has a known solution; a real problem doesn’t. AI is excellent with known solutions, and that’s exactly why it makes many traditional projects obsolete. What stays hard is choosing the right question, managing ambiguity, negotiating with stakeholders, understanding when a piece of data is “correct” but out of context.

The third is treating AI as environment, not as subject. Not an isolated course, but a transversal presence, the way the calculator didn’t kill mathematics but changed what “knowing maths” means. AI probably won’t kill education, but it’ll change what being competent means.

Then there are operational collaborations with companies. Not partnerships that produce a paper in three years, but shared work on real problems, with the same tools, in the same timeframe. It’s complex, I know. But it’s also one of the few ways to recover time.

Finally, teaching how to learn. It sounds like a poster slogan, but today it’s almost the only future-proof thing—and maybe the one the university has lost over the last 30 years. Metacognition, critical thinking, the ability to evaluate new tools, to integrate them without becoming dependent on them.

The real danger isn’t AI, it’s irrelevance

If the academy is perceived as too slow, too expensive, out of time, the risk is that people start bypassing it. Not out of malice, but out of necessity.

And here comes the most uncomfortable question, the one I fear many students are already asking themselves.

When you discover you can get in three minutes with an AI assistant what your course taught you to do in a year, you don’t think “great, I have solid foundations”. You think: why did I invest three years of my life and thousands of euros?

The answer exists, and it’s a good answer.

The value of university shouldn’t be the transfer of pointwise skills. It should be a mental framework, critical thinking, the capacity to argue, the network of relationships, exposure to different disciplines, personal maturation.

But if the curriculum is built as if the main value were “learn how to make a dashboard”, that answer sounds hollow. And it hurts to say, because behind many courses there’s real dedication.

The urgency to act, without panic

Globally we invest very little, in proportion, in adult lifelong learning. And yet increasing that investment could generate enormous value by 2030.

It isn’t only an educational problem. It’s economic. It’s social.

Universities have an advantage no AI platform has: they can teach how to think critically, how to collaborate deeply, how to navigate ethical ambiguity.

But only if they stop competing on terrain where AI wins—the transmission of information and the execution of structured tasks—and concentrate on what makes them irreplaceable.

The time for this transition isn’t “the next few years”. It’s now.

Every semester that passes with unchanged curricula is a semester of students coming out less prepared than they could be.

The speed of AI won’t slow down to wait for educational committees.

That three-minute demo wasn’t a provocation. It was a mirror.

And the thing that struck me most wasn’t the speed of AI. It was the slowness of everything else.