We are still waiting for Morpheus. Somewhere, sooner or later, someone will sit across from us, hold out a hand, and offer us the choice: understand what is really happening with artificial intelligence, or carry on as before.

A clear choice. A conscious one. Ours.

That scene is not coming. It is not late, and it is not hiding behind the next update. It was never part of the plan. And while we wait for it, convinced that the decisive moment is still ahead, something has already happened in an unmarked part of our day.

What We Absorbed Without Noticing

There is a character in The Matrix who is more honest than anyone else, and he is not the hero. It is Cypher, the traitor, sitting in a restaurant in front of a steak he knows is not real. He knows it is a signal fed into his brain by a machine. He eats it anyway and says he prefers the false taste to the truth. It is a clear-eyed bargain: he understands the deception and accepts the terms.

Cypher chooses his illusion and knows its price. He looks at the steak, decides to eat it, and sits down at that table deliberately. It is a single, conscious act, with a date and a time. Our story runs in the opposite direction, which is why it is harder to see.

No one serves us a plate that we can accept or refuse. Think of the colleague who opened a free account to rewrite emails, of us handing the first round of research to an assistant instead of doing it ourselves, of the draft we did not rewrite from scratch because the suggested version was already good enough. No dramatic moment, no choice held out in a palm. Just a sequence of reasonable shortcuts, each harmless, none quite chosen.

This is the part The Matrix got wrong. Cypher makes his choice in a single bite and knows what he is consuming. We took neither the red pill nor the blue one. Something was poured into our glass, one sip at a time, and we drank it under the name of convenience.

Who Is Pouring the Drink

The right question is not which pill to take. It is who is pouring the drink, who decides what goes into the glass and what remains in the pitcher.

When we ask an assistant for the best flight to Lisbon, we choose among the options it returns, not among every option that exists. Upstream, someone has decided which sources to query, how to weight them, what to show us, and what to leave out. We are still free to choose, but only within a boundary we did not draw.

There is a second effect, subtler than the filter itself. A search once returned a page of results, and the work of choosing remained ours. We opened three sources, compared them, and noticed when two contradicted each other. That disagreement was valuable because it forced us to doubt. Today, we receive a single answer, already synthesized, without the cracks that made us think. The uncertainty has not been resolved. It was removed from the glass before it reached us.

The one pouring the drink is the software agent, the program that acts on our behalf and stands between us and the service. It derives its power precisely from our feeling that the choice is still ours. It is the mechanism search engines made familiar twenty years ago, taken one step further. Before, we chose from a list of results. Now, we receive a single answer, already poured into the glass. At least we could see the list. We cannot see what remains in the pitcher.

This is where the boundary stops being a metaphor. It is like a bar where we believe we can order whatever we want, but the person serving us pours only the bottles with the highest margin. The menu exists, we browse it, and the feeling of choice remains intact. But the hand behind the bar has already decided what will actually reach our table.

The Few Who Stopped Staring at the Glass

There is a difference between those who remain hypnotized and those who do not, and it is not the one we expect. It is not technical expertise.

The people who have broken away are not drinking something better. They have stopped staring at the glass. They have shifted their attention from the contents to the hand doing the pouring, from “What should I ask the machine?” to “Who decided what the machine is allowed to answer?” In practice, that means asking who trained the model, who owns it, and whose interests are served by offering it for free. They are not more intelligent. They are simply less captivated by the act of pouring.

It is worth being honest: I am drinking from the same glass as you are. There is no clean position outside the system from which to observe all of this while remaining untouched. The difference is not immunity. It is knowing that we are not immune, and asking each time who filled the pitcher before we arrived.

The Blue Pill Was the Belief That We Could Choose

And yet breaking away remains rare, and the reason is not laziness. The comfort artificial intelligence sells us is not ignorance. It is something subtler and harder to refuse: the feeling that we are still the ones deciding.

Cypher wanted to forget the truth, and at least he knew what he was rejecting. We do not need to forget anything because it is never shown to us. We are allowed to keep only one thing, the most valuable thing to preserve intact: the conviction that we are free agents, choosing the flight, the answer, and the right word, while the range of what we can choose narrows one sip at a time.

Perhaps the blue pill was not the illusion of the Matrix. It was believing there was a pill to choose in the first place, and failing to see that every time the choice feels like ours, that feeling may be exactly where we are giving it away.

The bridges between AI and software have multiplied almost sevenfold in five months; the ones that reach a motor have not.

In March this piece counted about fourteen hundred company-run servers for the Model Context Protocol, the open standard that connects AI assistants to external tools.

Qualys was already counting more than ten thousand active public ones, and governance had passed to a Linux Foundation body, per a WorkOS overview of the same month.

Software integration is no longer a project. It is plumbing.

Point those pipes at anything that moves an object in real space and little changes.

A ChatForest review of robotics MCP servers in May 2026 found some fifty community projects, many on hobby hardware, and no official server from Universal Robots, Boston Dynamics, Fanuc, ABB or KUKA.

The rare public exceptions are academic. A January 2026 arXiv paper by Burke and colleagues demonstrated LLM-controlled UAV flight through the MAVLink protocol with MCP as the bridge, and it gets cited because it stands almost alone.

Physical AI, an agent whose command leaves the screen and moves a machine, is not a harder version of software AI: the intent stays human, the last metre of the decision becomes the machine's, and no one has yet agreed who answers for that metre.

What the money says physical AI is for

Capital has stopped waiting for the connection layer.

Robotics companies had raised 55.8 billion dollars in 2026 by early June, nearly double the previous record, according to Dealroom figures reported by CNBC on June 10, 2026.

Humanoid startups alone accounted for 8.7 billion through July, in the same data as cited by The AI Insider on August 21.

Deployment is shakier than funding. A Technology.org analysis of July 18, 2026 traced the most repeated figures, fifty thousand Optimus units among them, to no company source.

Tesla has never published a production count, and the strongest verified records, Figure's and Agility's, are far smaller than the headlines.

Unitree ships more humanoids than any Western rival at roughly a tenth of the price, the same report notes, and its first-quarter profit still halved.

So the machines exist and the money is real, while the layer that lets a language model command them is still built by hobbyists and a few firms working alone. I am one of them.

The interlock that refuses the last metre

The part of my system that matters most says no.

An operator types a sentence in Claude Desktop; the model picks tools from my MCP server, which turns them into authenticated calls to an IoT cloud platform that forwards them to the UAV's flight controller and to an automated hangar. Telemetry returns along that chain.

That server also talks to a MAVLink autopilot, a DJI platform through its cloud APIs and a BlueROV underwater vehicle; only the final adapter changes. Flight modes, gimbal control, waypoint missions and retry logic all sink beneath a conversational surface.

What stays out of its reach is what I refused to hand to inference.

The hangar roof will not open above three metres per second of wind, outside the operating temperature range or under precipitation, and no sentence can argue it open: the rule sits below the model, not inside it.

A debug mode redirects every call bound for a physical device to an inspection endpoint, so mission logic is tested without a vehicle moving. A wrong text can be corrected; a wrong command to hardware cannot.

Language gets the route. It does not get the last metre.

The first documented case of a machine choosing its target

The question I left open in March has since been settled once, in the worst possible place.

On July 6, 2026 a Russian Molniya drone struck a petrol station in Zaporizhzhia and three civilians died. The New York Times reconstructed the sequence in an investigation published on August 24, with Ukrainian air defence commanders and the forensic team that examined the wreckage.

Operators sent the aircraft towards the site; close to it, the onboard software chose the exact target by itself, most likely the propane tanks it had been trained to recognise.

It failed to clear an apartment building, hit a wall and detonated near people sheltering below.

The wreckage carried no antenna and an unencrypted Nvidia Jetson Orin, a consumer module costing a few hundred dollars; Ukrainian officials could read its terrain imagery and target-selection code.

Kateryna Bondar of the Center for Strategic and International Studies called it the first documented case of civilian deaths from a Russian drone with fully autonomous targeting, Tom's Hardware reported on August 25.

A warehouse robot and a weapon are not on the same moral plane. The shape of the event, though, is the shape of the question. The intent was human and coarse: go there. The final choice was the machine's. The outcome matched neither.

The hardware, in Nvidia's words to the Times, was consumer-grade, not sold in Russia and not designed for the purpose.

Liability arrives before the building rules

Europe has started to legislate, and the order is the interesting part.

Directive (EU) 2024/2853, the revised Product Liability Directive adopted on October 23, 2024, treats software and AI systems as products and applies strict liability to anything placed on the market after December 9, 2026, software essential to a robot's functioning included, as Timelex notes.

If the inferential layer of a device causes harm, nobody has to prove negligence any more.

The directive also names who can be held liable: the manufacturer of a product or of a component, software included, the importer, and whoever substantially modifies a product after it is sold.

The Digital Omnibus on AI, approved by the Council of the EU on June 29, 2026, defers the AI Act's high-risk obligations for AI embedded in machinery and similar regulated products to August 2, 2028, as Gibson Dunn and DLA Piper read the text.

Civil liability lands this December; the engineering duties, twenty months later. Anyone shipping physical AI in Europe will spend 2027 exposed on a decision layer that no requirement yet describes.

The lesson is to write down, now, which decisions the model may take and which ones a rule takes for it, and to put a name next to the list.

Where the metre gets decided

What the frontier still lacks is a signature on the last metre.

Before you connect a physical AI agent to anything that moves, find the person in your organisation who will sign for it. If no one comes forward, the machine has already been given the job.

Imagine sending a client the usual technical and commercial proposal, with an appendix describing what the system will do. Normally, you wait for the client to say yes, and only then do you start building. But what happens when that same appendix, instead of remaining a document, becomes the starting point for something tangible?

At the next meeting, you are no longer bringing a promise. You are bringing working software, ready to show on screen.

The conversation changes. It is no longer, "Can this be done?" It becomes, "Move this button and change that color." The proposal and the prototype are produced from the same source material, in the same afternoon.

This is not a hypothetical scenario. It happened, and it is worth explaining how.

Three Questions in Twenty Years

For years, the value of the people who built software was thought to lie in the hands on the keyboard. Then, for a brief period, some believed it lay in prompts, the supposedly magic instructions given to an artificial intelligence.

Both answers are now incomplete.

The question that matters has become a different one: can you describe the problem clearly and bring the right source material?

Anyone who holds the context of a domain, the salesperson with the proposal, the technical specialist with the documentation, the entrepreneur who knows the client, is now one step away from a working prototype without first routing everything through a development team.

The raw material is no longer code. It is what you already have sitting in a file somewhere.

From an Attachment to an App, by Talking

In this case, the starting material was not a formal specification or a technical design. It was the product's functional documentation: a list of the operations the system could perform, together with their parameters. The kind of appendix that could accompany almost any proposal.

The instruction given to the AI was simple and expressed in plain language: analyze these files, work out what they describe, and build a complete application that uses all of these functions, adding the features that applications of this kind usually lack.

Context plus objective. No technical jargon.

Before long, a real working interface emerged: the main screens, commands with the appropriate safety confirmations, real-time data visualization, and an activity log. Not a static mock-up, but an application that could actually be used.

From there, the software grew through conversation.

"Make the interface more modern and remove the emoji." A complete redesign.

"Add Italian and English." It became bilingual.

"Review the website of a similar product and add the features that make sense." The AI read a competitor's documentation, selected what was realistic, and added it.

Then came the most revealing request: "Build a second version that is identical to this one, but connected to a different system."

The result was the same interface with the engine underneath replaced. A twin product connected to another data source, while everything the user could see and interact with remained unchanged.

The Carpenter Who Has Never Seen Your Home

This is where it is worth pausing on the underlying idea, because that is the part that lasts.

Three shifts took place.

The first is the shift from writing code to curating context. The value no longer lies in the hands doing the typing, but in the domain material you bring and the clarity of the objective. A well-prepared technical and commercial proposal is already half the work, because it defines what the product does, who it is for, and within what constraints.

The second is the shift from software as a construction project to software as a conversation. Not a monolithic project delivered months later, but a dialogue in plain language, where each request becomes a feature or a refinement.

The third is the new role of the human: director, not typist. You bring the context, make the calls at each fork in the road, and validate the result.

It is like moving from building a piece of furniture yourself, with timber and tools, to describing it to an expert carpenter who has never seen your home.

Your value no longer lies in knowing how to plane the wood. It lies in knowing what piece of furniture is needed, where it will go, who will use it, and whether what comes back is right.

What Does Not Disappear, but Shifts

It would be dishonest to stop at the excitement, and fortunately the limitations are the most interesting part.

Expertise is still required, not necessarily to write the code, but to provide the right context and judge the result. Garbage in, garbage out.

Human verification remains essential because AI produces plausible outputs that are sometimes wrong. In the real case, the work went through checks, fault-finding reviews, and live tests before anyone said, "This is good enough."

When the AI was asked to critique its own work, it identified several weaknesses and proposed corrections. That was useful, but a person still had to decide what to change and take responsibility for the result.

The decisions that carry real weight, including security, privacy, and product direction, remain human responsibilities.

Rigor does not disappear. It moves from the act of writing code to the work of framing the problem and validating the solution.

What This Means in Practice

All of this means different things depending on where you sit.

If you run a business, the material you already have, proposals, product sheets, price lists, can become fuel for prototypes. You can validate an idea with a client before investing in full development.

If you work in sales, you can walk into a meeting with a demo built from the client's own documentation, because what people can see and use is easier to sell.

If you work in consulting, the deliverable changes. It is no longer limited to slides; it can include working prototypes.

If you cannot code, the new literacy is not programming. It is the ability to describe context and objectives clearly, and to recognize a good solution when you see one.

If you build software, the work shifts toward architecture, verification, security, and direction: less typing, more judgment.

For years, the bottleneck was knowing how to build. Today, that bottleneck has moved. The problem is no longer primarily how to make something, but knowing what to build and for whom.

The oldest part of the craft becomes central again: knowledge of the domain and the customer.

There is, however, one detail I have left out of this story.

The prototype was not written by a single artificial intelligence working alone. It was built by a coordinated team of AI assistants: one built, one reviewed, and one tested.

Learning how to orchestrate that team is a different skill, and perhaps the more consequential one.

I will cover that in the next article.

Quando una macchina porta a termine un compito grazie alle istruzioni che le hai preparato, in quanti casi ci riesce perché le hai insegnato qualcosa che non sapeva? Uno studio di agosto li ha contati.

Sono il 4,5 per cento.

Il resto del merito va altrove, ed è la stessa cosa che le aziende, quando decidono cosa archiviare, buttano.

Quel contesto di cui scrivo da mesi, nessuno lo aveva ancora pesato. Adesso sì, e il risultato corregge anche me.

La stessa esperienza in due formati

Lo stesso bagaglio di esperienza, consegnato in due formati diversi, non produce lo stesso esito.

Zhiyuan Jiang, Fangrui Huang e altri sette ricercatori di Princeton, Stanford e altre tre università americane hanno depositato il 14 agosto su arXiv, l'archivio degli studi non ancora sottoposti a revisione, un lavoro basato su 8.135 prove. Lo ha segnalato Ben Dickson su Alpha Signal nove giorni dopo.

Un agente, cioè un modello che esegue compiti in un ambiente informatico reale usando strumenti, affronta lo stesso problema in tre condizioni: senza esperienza precedente; con i log ripuliti di tentativi passati, cioè la sequenza di comandi e risposte di chi ci ha già provato; con una procedura breve, distillata da quegli stessi tentativi.

Quest'ultima vince di sei punti. Da soli, senza distillazione, i tentativi passati non hanno battuto l'assenza di esperienza, e con loro l'agente esaurisce il tempo a disposizione in un caso su dieci, contro meno di due su cento.

L'archivio completo non aiuta. Ingombra.

Nei casi in cui la procedura ha funzionato, nel 65,7 per cento il merito è dell'ordine dei passi e dei controlli intermedi che ha fissato; un fatto che la macchina non conosceva glielo ha fornito nel 4,5. Gli errori di configurazione dell'ambiente, i più banali, scendono dal 5,3 per cento allo 0,2.

È la correzione che mi riguarda. Avevo descritto il contesto come materiale da consegnare alla macchina, l'offerta e i suoi vincoli. Pesa meno del percorso che le metti accanto.

L'errore serve solo se porta l'etichetta

Fin qui conta il formato. Quello che cambia il mestiere arriva dopo.

I ricercatori hanno costruito la procedura a partire da cinque tentativi, di cui due falliti, in due modi: dicendo alla macchina quali fossero riusciti, oppure tacendolo. In una delle configurazioni misurate, con le etichette l'agente ha risolto il compito tre volte su quattro.

Senza, nel 40 per cento dei casi.

Finché nell'archivio ci sono soltanto successi, il verdetto non cambia nulla. Appena entrano i fallimenti, senza etichetta la macchina non distingue il segnale dal rumore e trasforma lo sbaglio in istruzione. Il guaio non è aver sbagliato. È che nessuno lo ha messo a verbale.

Ora guarda l'archivio di un'azienda. Conserva la versione consegnata e l'offerta vinta. La bozza scartata non porta scritto "scartata", il preventivo sbagliato non dice di quanto. Il verdetto, dove esiste, sta nella testa di chi c'era. È la condizione peggiore dello studio: esperienza mista, senza etichette.

Un mestiere che lo ha capito per legge

Un settore lo ha affrontato prima delle macchine, ed è quello in cui lavoro. Molte delle procedure che si eseguono ogni giorno in aviazione sono il distillato di eventi andati storti a qualcun altro, segnalati e classificati.

Il regolamento europeo 376 del 2014 obbliga a segnalare ciò che mette a rischio la sicurezza e, all'articolo 16, vieta al datore di lavoro di penalizzare chi segnala, salvo dolo o negligenza grave. Si chiama cultura giusta, e non è una concessione: senza quella protezione le segnalazioni si fermano, e con loro l'aggiornamento delle procedure.

Qui sta il punto che lo studio non poteva vedere. L'etichetta che in quell'esperimento vale quasi trentacinque punti percentuali ha un costo, e lo paga una persona con un nome. Nessuno scrive "sbagliato" accanto a un documento se quella riga può ricomparire in una valutazione. L'aviazione non si è limitata a un archivio migliore. Ha tolto il prezzo a chi mette l'etichetta.

Cento procedure non valgono cinque

Resta l'obiezione più naturale: allora scriviamo tutto, una procedura per ogni caso. Anche questa è stata misurata.

Passando da un catalogo di 5 procedure a uno di 100, la quota di procedure giuste fra quelle che l'agente consulta cade dal 29,6 per cento al 3,3: ne apre molte, quasi tutte sbagliate. Il successo non si muove, e resta tra il 36 e il 39. Una procedura imparentata basta a tenere in piedi l'esecuzione; quella esatta non garantisce niente.

La quantità pesa, ma pesa di più la somiglianza: cataloghi pieni di procedure quasi uguali confondono la scelta molto più di cataloghi grandi ma distinti. Il manuale interno da quattrocento pagine, quello che molte aziende possiedono e pochi aprono, è la versione umana dello stesso guasto.

Dove si ferma la prova

Lo studio si ferma prima del punto in cui lo sto portando, e il confine va segnato. Gli esperimenti riguardano agenti al lavoro su codice e configurazioni, in ambienti dove un verificatore automatico decide se il compito è riuscito. Il passaggio dall'agente all'organizzazione lo faccio io, non gli autori, ed è un'ipotesi.

In azienda il verdetto non lo dà un test: lo dà il cliente, mesi dopo, e spesso non lo dà nessuno. L'ipotesi ne esce più pesante, non più leggera. Lo studio dimostra che senza verdetto la procedura assorbe l'errore. Un'organizzazione priva di verdetti le costruisce così da sempre.

La macchina non introduce il difetto: lo rende leggibile.

Quello che hai archiviato in questi anni è la versione della tua azienda che non ha mai sbagliato. Non esiste, e stai per consegnarla come manuale.