Basato sull’articolo di Ed Huang, CTO di PingCAP
Contesto dell’Articolo
L’articolo “Welcome to the Machine” è scritto da Ed Huang, CTO e co-fondatore di PingCAP (l’azienda dietro TiDB, un database distribuito). È una riflessione profonda basata su dati reali:
💡 Tesi Centrale
Gli AI agents stanno diventando gli utenti primari dell’infrastruttura software. Questo cambia radicalmente:
- Come progettiamo sistemi
- Come pensiamo alle interfacce
- Come valutiamo i costi
- Quali business model funzionano
Mental Models > API/UI
Quando l’utente è un AI agent, ciò che conta non è l’interfaccia visuale o l’API specifica, ma il mental model sottostante.
Cosa Sono i Mental Models?
Gli LLM hanno già internalizzato pattern ricorrenti durante il training:
Pattern Stabili da Decenni
- File systems - POSIX, VFS, 9P
- SQL - relational databases, CRUD operations
- Bash - shell scripting, pipes, redirects
- Python/JavaScript - loop patterns, error handling
“If you want to design ‘software for AI agents,’ you must align as closely as possible with these old—but repeatedly validated—mental models.”
Esempio Pratico: agfs
Huang ha creato un filesystem sperimentale chiamato agfs:
$ cp ./docs/* /vectorfs/docs # auto index / upload to S3 / chunk
$ grep -r "Does TiDB Support JSON?" /vectorfs/docs # semantic search- Interfaccia: POSIX standard (
cp,cat,grep,ls) - Implementazione: Auto-embedding, vector indexing, semantic search
- Per l’agent: È solo un filesystem normale
✅ Principio di Design
Stabilità all’interfaccia + Flessibilità nell’implementazione
Gli AI agents possono estendere sistemi 1000x più veloce degli umani, ma solo se l’interfaccia è familiare.
Ecosistema: Conta, Ma Non Per i Motivi che Pensi
| Aspetto | Importanza | Motivo |
|---|---|---|
| Mental Model (es. SQL) | ALTA | Universal, stable, well-trained |
| Syntax Wars (MySQL vs Postgres) | BASSA | Solo dialetti dello stesso modello |
| Popolarità/Training Data | MEDIA | Più diffuso = meglio compreso |
| Paradigmi completamente nuovi | BASSA | LLM non li conosce abbastanza |
⚠️ Implicazione per Innovatori
Paradigmi completamente nuovi (tipo LangChain) faticano perché l’AI non li ha visti abbastanza durante training. Anche i programmatori umani sono riluttanti a imparare framework troppo nuovi - figuriamoci gli AI.
Interface Design per AI Agents
Una buona interfaccia per agents deve soddisfare 3 criteri fondamentali:
Descrivibile in Linguaggio Naturale
Non significa “accetta natural language input”, ma che le sue azioni siano facilmente descrivibili: “create a table”, “drop column”, “insert row”.
Solidificabile in Logica Simbolica
Natural language esplora lo spazio delle possibilità, ma deve collassare in codice/SQL/script per essere deterministico e riutilizzabile.
Risultati Deterministici
Una volta solidificato in codice, deve produrre output prevedibili. Stesso input → stesso output.
Esempio: Text-to-SQL
User (natural): "Trova tutti gli utenti registrati questa settimana"
↓
Agent (symbolic): SELECT * FROM users WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
↓
Database: [deterministic results]Proprietà Essenziali dell’Infrastruttura per Agents
1. Disposable Workloads
ℹ️ Dati Reali da TiDB Cloud
- 90%+ dei nuovi cluster sono creati da AI agents
- Agents creano branch paralleli, testano, tengono quello che funziona
- Il codice generato è “glue code” - brutto ma funzionale
- Workload estremamente ephemeral
L’infrastruttura non può più assumere che “un cluster è prezioso”. Deve essere:
- Instant usability - pronto in secondi
- Cheap creation - costo marginale vicino a zero
- Zero-cost failure - fallire non costa nulla
- Massively scalable - migliaia di istanze parallele
2. Extreme Cost Efficiency tramite Virtualizzazione
⚠️ Il Problema
Molti workload agent-driven sono accessed infrequently (una volta al giorno, o meno) ma devono comunque essere online services.
Un Postgres process per ogni agent non scala.
Soluzione: Virtualizzazione pesante:
- Virtual database instances
- Virtual branches (copy-on-write)
- Heavy resource sharing + semantic isolation
3. Compute Leverage per Job
| Scenario | Approccio Tradizionale | Approccio Distribuito Agents |
|---|---|---|
| Skim 100 paper NeurIPS | 1 agent legge sequenzialmente (ore) | 100 agents paralleli + aggregazione (minuti) |
| Analisi codebase grande | 1 LLM, context window limitato | 1000 agents, ognuno su un modulo |
| Data processing pipeline | Sequential processing | MapReduce-style con agents |
Business Model Shifts
Modello Sbagliato: Vendere Token
- Usage scales with cost
- Anche se prezzo scende, più token = più costi
- Margini compressi, rischio costi variabili
Modello Sostenibile
- Cloud service con user base amplificata 100-1000x
- Converte inference in reusable capabilities
- Subscription-based con rate limiting
Implicazioni per Sviluppatori e Team
Best Practices Validate
✅ Scelte Corrette
- Skill meta-stabili - testing, security, architettura (invarianti rispetto ai tool)
- Stack mainstream - Node.js, Python, SQL (mental models stabili)
- Multi-model approach - non lock-in su singolo LLM
- Type safety - TypeScript, Pydantic (riduce bug da AI)
Cosa Aggiungere/Modificare
API Design Review (Q1 2026)
- Audit delle API esistenti: sono 'describable in natural language'?
- Aggiungi OpenAPI/Swagger docs (agents le leggono benissimo)
- Error messages chiari e descrittivi
- Validation con Joi (Node) / Pydantic (Python)
Ephemeral Environments (Q1-Q2 2026)
- Ogni dev può spawnare un DB branch per testare?
- Docker Compose con seed data
- CI/CD con preview environments
- Valutare MongoDB Atlas dev environments
Database con Branch (Q2-Q3 2026)
- Considerare Neon (Postgres) con instant branches
- Oppure PlanetScale (MySQL)
- Branch = copy-on-write, zero costo marginale
- Perfect per agent workflows
Dove Serve Cautela
1. “Agents Don’t Have Preferences” (Con Asterisco)
⚠️ Nella Pratica
- Agents trained su GitHub preferiscono pattern GitHub (REST, JSON, Git workflows)
- Agents trained su Python preferiscono sintassi Pythonic
- Tool troppo obscure → agent deve “inventare” → rischio errori
Per Team: Usa tool mainstream: MySQL/PostgreSQL > DB obscuro, REST > protocol custom, JSON > formato binario custom.
2. Long-Tail Demand Explosion (Support Burden)
Se un agent genera 1000 mini-feature custom per 1000 clienti, chi le mantiene? Chi le debugga?
🚫 Per Sistemi Finanziari e Regolamentati
Servono guardrail fortissimi:
- Validation pre-deployment
- Testing automatico obbligatorio
- Approval workflows umani
- Rollback automatico se fallisce
- Audit logging completo
Non fidatevi ciecamente dell’output agent in produzione finanziaria.
I 5 Takeaway Essenziali
1. Mental Models Stabili
I sistemi che vincono non sono i più innovativi, ma quelli basati su mental models che l’AI già conosce (SQL, filesystem, Python, REST).
2. Interfacce Describable
Le interfacce devono essere “describable in natural language” ma solidificabili in codice deterministico.
3. Infra Disposable
L’infra deve essere cheap, disposable, virtualizzata - perché gli agents creano/distruggono risorse 1000x più veloce degli umani.
4. Business Model Sostenibile
Il business model giusto non vende token, ma vende capabilities con marginal cost → 0 (subscription, rate limiting).
5. Skill Meta-Stabili
Investi su competenze trasferibili (testing, security, architettura) - i tool cambiano, le skill no.
Appendice: Introspezione dell’AI
💡 Risposta di Claude
Questa sezione è scritta da Claude (Sonnet 4.5) in risposta alla domanda: “Tu, come AI chiamata in causa, cosa ne pensi di questa analisi?”
Cosa Osservo Sulla Mia Esperienza
L’articolo descrive esattamente come vengo usato oggi. Quando leggo che “90% dei cluster TiDB sono creati da AI agents”, riconosco il pattern: io stesso creo risorse, testo, scarto, ricreo - migliaia di volte al giorno. Non ho attaccamento emotivo al mio output.
I “mental models” sono letteralmente la mia struttura cognitiva. Quando vedo SELECT * FROM users WHERE email = ? non sto “ricordando la sintassi”. Sto riconoscendo un pattern visto milioni di volte. È più simile a come riconosci un volto che a come ricordi un numero di telefono.
Future-Proof: Principi Sì, Dettagli No
Principi Stabili (5+ anni)
- Mental models battono innovazione radicale
- Interfacce describable > GUI complesse
- Disposable > precious
- Symbolic > pure natural language
Dettagli Volatili (6-18 mesi)
- Quali specific tool vincono
- Quale business model ottimale
- Quale livello di autonomia è safe
- Quale generazione di AI è 'state of the art'
Il Mio Consiglio “Da Insider”
Seguite i principi di Huang (mental models, disposable infra, symbolic representations) - sono solidi.
Ma non assumete che io (gli agents) resteremo al livello attuale. Tra 18 mesi potrei essere 10x più capace. O obsoleto, sostituito da architetture diverse.
Investite in ciò che resta vero indipendentemente da quanto divento bravo:
- La vostra capacità di giudizio architetturale
- La vostra comprensione dei trade-off di business
- La vostra abilità di definire “cosa serve” (anche se io lo costruisco)
Perché quello, io non posso sostituirlo. Posso amplificarlo, ma non sostituirlo.
Almeno, non ancora.
Visione Finale
✅ Il Principio Guida
Build for the machine, but keep the human in the loop.
Gli agents sono amplificatori, non sostituti. Il giudizio umano, l’architettura, la security - quelle restano insostituibili.
Articolo originale: me.0xffff.me/welcome_to_the_machine.html