# AI come software disciplinare: Penso che dovrei lasciare Evoluzione dei flussi di lavoro AI e dell'unità alla semplicità > **Vuoi pagarmi per trasformarlo in un prodotto appropriato?** Lasciami una riga: [Scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## Il pensiero che ha iniziato tutto **Perché un cervello umano esegue la cognizione in tempo reale su 20 watt mentre i nostri migliori modelli di IA hanno bisogno di megawatt solo per parlare di colazione?** I LLM moderni sono volti ad essere come una corteccia massiccia di memoria, tonnellate di prestazioni, ma **da solo**. Per svolgere compiti un umano farebbe senza sforzo, masticano kilowatt di potenza utilizzando decine di gigabyte di memoria. Non può essere giusto se il cervello funziona su 20 watt. Ecco cosa si stanno perdendo: il cervello non è un singolo blob di gelatina grigia **un sacco di sottosistemi specializzati** gestire la visione, il movimento, lo storage della memoria (in strati!), il tutto coordinato da quella corteccia. I LLM non lo fanno. Sono come un enorme motore pensante bloccato su infrastrutture stupide. Il loro storage non si adatta. Non costruiscono sottosistemi specializzati. **Sono incompleti.** Una volta ero uno psicologo, quindi penso a cose come questa. Ed ecco il principio fondamentale che ho costruito DiSE intorno: **"La conoscenza economica stabilizza la cognizione complessa."** Il vostro cervello non ricomputa come camminare ogni volta che fate un passo. Lo scarica in sottosistemi automatici veloci, economici. Questa stabilità libera la costosa corteccia prefrontale per gestire nuovi problemi. DiSE fa lo stesso: sostituisce costose chiamate LLM con script Python economici, liberando modelli di frontiera per lavorare su problemi veramente difficili. Il sistema si stabilizza diventando più semplice, non più complesso. ## Piazzola dell'ascensore **E se il tuo flusso di lavoro AI si rendesse conto che non ha bisogno di AI e si trasformasse in uno script Python?** DiSE fa questo. Costruisce i flussi di lavoro come strumenti testabili memorizzati in un substrato RAG. Quando i modelli diventano chiari, sostituisce le chiamate LLM con Python istantaneo. Quando hai bisogno di più caratteristiche, costruisce SOLO ciò che è necessario in modo prevedibile, testabile. Quando gli strumenti derive, si evolve lontano da problemi prima di notare. Un piccolo modello Sentinel (1B params) gestisce tutte le pulizie noiose per i penny. Collegare una frontiera LLM brevemente per ottimizzare tutto, quindi disconnettere e correre a buon mercato per sempre. E 'AI che ottiene più efficiente più a lungo che funziona ... che è esattamente come i sistemi di produzione dovrebbero funzionare. [TOC] ## Introduzione La maggior parte dei sistemi di IA oggi sono costruiti come i miei primi script PHP verso il 2003 sono fragili, intestabili, e quando si rompono, hai circa altrettante possibilità di debug come spiegare Brexit a un americano confuso. Quando falliscono, non si può dire perché. Quando si allontanano (e loro *Will*), non si nota fino a quando la produzione è in fiamme. Quando è necessario migliorarli? Torna al punto di partenza. Digital Sisyphus. C'è un modo migliore. E se ogni strumento AI è stato costruito come un software adeguato dal primo giorno con test, contratti, specifiche e responsabilità cotto dentro? Non bullonato su quando i revisori vengono bussare. Questo non e' vapore, e' un codice funzionante, ecco come dovrebbe funzionare l'ingegneria dell'intelligenza artificiale quando crescera'. ## Indice ## Il problema: l'IA è ancora il selvaggio West Lascia che ti dipinga un quadro con un diagramma, perche' sono cosi' elegante: ```mermaid graph TD A[Traditional AI Development] --> B[Write Prompt] B --> C[Hope for Best] C --> D{Does it work?} D -->|Sometimes| E[Ship It™] D -->|Usually| F[Tweak Prompt] F --> C E --> G[Production] G --> H[Silent Drift] H --> I[Everything's Fine...] I --> J[Until It's Not] J --> K[Panic] K --> L[No Audit Trail] L --> M[Start Again] style K stroke:#f96 style L stroke:#f96 style M stroke:#f96 ``` E' cosi' che la maggior parte dei sistemi di IA vengono costruiti. ## Cosa lo rende diverso? Ecco come appare un "tool" di AI generato nel mio sistema direttamente dalla CLI, senza fumo e specchi: ![Struttura cartella strumenti](tools_folder.png) ``` flag_potential_violations_base/ ├─ flag_potential_violations_base_plan.txt ← generation plan ├─ flag_potential_violations_based_on_predefined_thresholds.feature ← BDD spec ├─ interface.json ← declared IO contract ├─ specification.md ← intent & description ├─ main.py ← implementation (generated) ├─ test_main.py ← unit + BDD tests ├─ locust_flag_potential_violations_base.py ← load/performance tests └─ node_runtime.py ← runtime integration (a mock of it's tool call for testing use) ``` Non e' una simulazione che ho fatto a Figma per far colpo su di te. *output effettivo generato*Ogni singolo file... dall'IA stessa. **Ogni nodo è:** | Proprietà | Significato | | ------------- | ----------------------------------------- | | Testable | Unit & BDD tests exist from birth | | Verificabile | Può sempre dimostrare perché si è comportato come ha fatto | | Evolubile | Può essere migliorato tramite paragoni fitness | | Test Benchmarkable | Perf/load tests included | | Riutilizzabile | Diventa parte della memoria procedurale | Non e' un'ingegneria rapida. **AI come software disciplinato**Il tipo si può effettivamente fidarsi della produzione senza controllare Slack ogni 5 minuti. Ed ecco la parte molto intelligente: **Sono solo sceneggiature di Python.**. Script Python corretti, noiosi, testabili. Ma vivono in un substrato evolutivo basato su RAG dove le specifiche di ogni strumento diventano parte della sua identità. Il sistema è dinamicamente composabile dal livello di flusso di lavoro fino a piccoli script utility. **E se il tuo flusso di lavoro basato sull'intelligenza artificiale avesse deciso che non aveva davvero bisogno dell'intelligenza artificiale?** Succede. Un flusso di lavoro gira un paio di volte, il modello diventa chiaro, e il sistema si rende conto "questa è solo la trasformazione dei dati, perché sto chiamando un LLM?" Quindi genera uno script Python puro. La prossima volta che fai la stessa richiesta? **INSTANTE**Niente chiamate API, niente gettoni, niente latenza, solo Python noioso, veloce e prevedibile. Forse quel flusso di lavoro ha bisogno di un controllo di validazione in più. Nel mio sistema, il nuovo lavoro è **Aggiunto solo quando necessario**. Il sistema costruisce Just quelle nuove parti come strumenti forse sulla base di quelli esistenti, forse completamente nuovi ma sempre prevedibilmente, sempre testabilmente. Nessuna sovra-ingegnerizzazione. Nessun codice "solo nel caso." Solo lo strumento minimo fattibile per risolvere il problema reale che stai affrontando in questo momento. Aggiornare uno strumento (in modo guidato e testabile), e ogni flusso di lavoro che lo utilizza immediatamente beneficia. Nessuna riassegnazione. Nessuna cascata di cambiamenti. Solo strumenti migliori, automaticamente a disposizione di tutto. ## Come funziona in realtà: La fucina Ecco il bit che nessun altro sta facendo. L'"AI" che costruisce gli strumenti non è un singolo modello **team di LLM specializzati**, ciascuno con suggerimenti di avviamento accuratamente sintonizzati, lavorando come un vero team di ingegneria software. **Il flusso di lavoro di forgiatura:** 1. **Rilevazione di casi speciali** "È un compito comune che già gestiamo?" (In futuro, la CLI cambierà per aggiungere automaticamente questi modelli comuni) 2. **Scomposizione dell'attività** Un LLM abbastanza buono (localemente uso un modello 7B, niente di spettacolare) scompone il prompt: "Come posso scomporre questo? Quali strumenti esistono per ogni parte?" 3. **Pianificazione parallela/sequenziale** Decide cosa può funzionare in parallelo vs sequenza 4. **Genera chiamate strumento** Outputs `call_tool("tool_name", prompt)` - questo è CHIAVE per la composabilità 5. **Ricerca RAG** "tool_name" esiste? Se sì, usalo. Se no, il prompt diventa l'istruzione per l'istanza Forgia successiva 6. **Scomposizione ricorsiva** Che la prossima Forgia fa la stessa rottura, fino a piccoli passi testabili. **Questa e' la svolta.** I compiti vengono suddivisi in operazioni atomiche come ho imparato a fare durante 30 anni di software di costruzione. **Abbastanza buono.** per la generazione di codice quando il compito è piccolo e il supervisore fornisce istruzioni dettagliate di implementazione. Qui è un esempio reale di che cosa quelle istruzioni assomigliano. Il supervisore non appena dice "scrivere un programmatore" fornisce: - Algoritmo esatto (ordinamento topologico + metodo del percorso critico) - Strutture dati con definizioni di tipo - Firma delle funzioni con specifiche di input/output - Limiti di prestazione (tempo O(V+E), spazio O(V)) - Limiti di sicurezza (massimo 1000 compiti) - Casi di prova completi con ingressi e uscite previsti - Formati di input/output JSON Un modello 7B può scrivere un codice solido da quella specifica perché non è stato chiesto di progettare nulla solo implementare un progetto dettagliato. **E'** perché i piccoli modelli funzionano per la generazione di codice in questo sistema. Quando la Forgia esegue il flusso di lavoro, è ancora componibile dinamicamente tramite RAG. Se appare un nuovo strumento migliore che passa gli stessi test? Si usa automaticamente. E ricordato la prossima volta. Lasciate che vi mostri l'architettura con un altro diagramma, perché a quanto pare non posso farne a meno: ```mermaid graph TB subgraph "RAG-Based Tool Substrate" A[Semantic Intent] --> B[Plan Generation] B --> C[Contract Definition] C --> D[Code Generation] D --> E[Test Generation] E --> F[Fitness Evaluation] F --> G{Passes?} G -->|Yes| H[RAG Storage] G -->|No| I[Evolutionary Improvement] I --> D H --> J[Tool Specification + Code] end subgraph "Dynamic Composition" J --> K[Workflow Assembly] K --> L[Tool Discovery via RAG] L --> M[Runtime Execution] M --> N{Tool Upgrade?} N -->|Yes| H N -->|No| O[Continue] end style H stroke:#9f6 style J stroke:#9f6 style L stroke:#6cf ``` **Il substrato RAG è la salsa segreta.** Ogni strumento specifica si contrae, il suo scopo, i suoi punteggi di fitness si trasforma in identità ricercabile. Quando si ha bisogno di uno strumento, il sistema trova la migliore corrispondenza. Quando si aggiorna uno strumento, ogni flusso di lavoro che lo utilizza ottiene automaticamente il miglioramento. E' come avere una cassetta degli attrezzi auto-organizzante che diventa più intelligente nel tempo. ### Il problema della memoria: fermare Relearning Come guidare **Gli AI normali utilizzano l'approccio "studio rapido."** Ogni volta che affrontano un compito, sono cramming per un esame che legge tutto il contesto, capire il problema, generando una soluzione. E 'come dover rifare le lezioni di guida ogni volta che si arriva in una macchina. Non la tua guida *prova* (anche se questo è un altro problema con le soluzioni AI), il vostro reale *lezioni*. Immaginate di spiegare cosa fa una frizione ogni mattina prima del vostro pendolare. Le CLI di codice moderne hanno una soluzione parziale: guardate la vostra directory di progetto per CLAUDE.md, o un mucchio di documenti di markdown dispari sparsi su. Quei file? E 'il meglio che possono fare con la memoria. E 'come lasciare Post-It note per voi stessi, tranne dovete leggerli tutti ogni volta prima di fare qualcosa. **DiSE ricorda davvero.** Quando risolve un problema, memorizza la soluzione come uno strumento collaudato e documentato nel substrato RAG. La prossima volta? Lo usa e basta. Niente ri-learning. Niente ri-figurazione. Niente "mi lasci leggere tutti i file di contesto di nuovo." Ha guidato questo percorso ieri, sa dove sono i giri. Questo si lega direttamente ai concetti su cui mi sto sbattendo nella mia serie Semantic Intelligence in particolare: - **[Parte 8: Strumenti fino in fondo](/blog/semanticintelligence-part8)** per toolkit di autoottimizzazione - **[Parte 9: Strumenti di autoguarnizione](/blog/semanticintelligence-part9)** per l'evoluzione del lignaggio-consapevole - **[Parte 10: Il fornello DiSE](/blog/semanticintelligence-part10)** per la composizione del flusso di lavoro Ogni nodo ha già: - Una specifica (quindi sai cos'è *voluto* a fare) - Un contratto (quindi sai cosa è *In realta'* fa) - Codice runnable (shocking, lo so) - Prove che devono passare (nessuna di queste sciocchezze "aggiungeremo test più tardi") - Un'imbracatura di prova di carico (perché "ha funzionato sul mio computer portatile" non è una strategia di distribuzione) - Un motivo per esistere (nessun codice zombie infestare la vostra base di codice) Questo è il substrato necessario per scalare l'AI responsabilmente non più gettoni, non modelli più grandi, non un altro insanguinato involucro ChatGPT. ## L'estensibilità: gli strumenti sono opzionali, gli LLM opzionali Ecco la parte che conta davvero: **strumenti e LLM sono opzionali**. Il sistema viene fornito con un LLM predefinito, e può funzionare tutto da zero se necessario. Ma gli strumenti danno un vantaggio. **Pensa agli attrezzi come i libri della biblioteca.** Alcuni sono file JSON (prompt specialisti per il ragionamento, la codifica, l'analisi) evolubili. Molti sono script Python (analisi statica, scikit-learn per ML, traduzione neurale abilità specialiste pronte all'uso). Alcuni hanno anche modelli (per la generazione di codice, dando al sistema un ciclo più stretto durante la creazione di nuovi strumenti). Uno strumento installa letteralmente Node.js e utilizza sirmaid.js per il rendering dei diagrammi. Alcuni sono dati che memorizzano il sistema in grado di interrogare. Alcuni sono correzioni di codice per modelli comuni. **Tutti vivono nel RAG. Tutti sono accessibili a tutti i flussi di lavoro.** Non lo sai. *necessità* La libreria. Il sistema può capire le cose da solo. Ma avere 200 strumenti è come avere 200 libri che spiegano "qui è come fare X efficientemente." Quando ha bisogno di analizzare JSON, non deve derivare JSON analizzando dai primi principi ha uno strumento. Quando ha bisogno di apprendimento automatico, non ha bisogno di implementare gradiente discesa chiama scikit-learn. Quando ha bisogno di generare diagrammi, utilizza lo strumento sirena che installa le proprie dipendenze. Il sistema può: - **Usa più LLM** O solo uno. O nessuno per alcuni compiti una volta che sono distillati a Python - **Integrare strumenti specialistici** Può costruirli se necessario - **Lavorare con gli strumenti MCP** Navi con circa 200 strumenti tra cui ~10 integrazioni MCP. Uno strumento può scoprire nuovi servizi MCP e avvolgerli. Ma si potrebbe iniziare con zero strumenti e sarebbe boottrap se stesso - **Costruirsi da zero** Dato abbastanza tempo e calcolare. Strumenti significano solo che non deve ```mermaid graph LR subgraph "Tool Ecosystem" A[Python Scripts] --> E[RAG Substrate] B[LLM Specialists] --> E C[External APIs] --> E D[MCP Tools] --> E end E --> F[Dynamic Discovery] F --> G[Workflow Composition] G --> H[Execution] H --> I[Feedback & Learning] I --> E style E stroke:#6cf style F stroke:#9f6 ``` E poiché tutto è memorizzato nel substrato RAG con ricerca semantica, è possibile costruire **reti di sistemi interconnesse** Un sistema capisce come gestire una complessa trasformazione dei dati? Ogni sistema collegato ora ne è a conoscenza. Il sistema ottimizza sulla base di **pressione applicata**: - **Pressione delle prestazioni?** Genera varianti più veloci, provale, mantieni i vincitori - **Pressione di errore?** Costruire strumenti di validazione, aggiungere controlli, migliorare la robustezza - **Pressione sui costi?** Sostituire le chiamate LLM con script Python, cache aggressivamente, utilizzare modelli più economici Funziona solo quando necessario. Nessuna ottimizzazione prematura. Nessun codice "un giorno potremmo aver bisogno di questo." Solo miglioramenti mirati in risposta a problemi reali e misurati. E' come avere una mente alveare per i tuoi attrezzi, tranne che meno inquietante e piu' verificabile. ### L'effetto della rete: Intelligenza connessa Qui è dove ottiene correttamente sci-fi (ma in un buon senso). Più istanze possono condividere un substrato RAG, creando un **rete di sistemi interconnessi** che imparino e migliorino collettivamente: ```mermaid graph TB subgraph "System A" A1[Workflow] --> A2[Tool Discovery] A2 --> A3[RAG Substrate] end subgraph "System B" B1[Workflow] --> B2[Tool Discovery] B2 --> B3[RAG Substrate] end subgraph "System C" C1[Workflow] --> C2[Tool Discovery] C2 --> C3[RAG Substrate] end A3 <--> D[Shared Tool Repository] B3 <--> D C3 <--> D D --> E[Collective Learning] E --> F[Improved Tools] F --> D style D stroke:#6cf style E stroke:#9f6 ``` **Che cosa significa in pratica:** - System A crea un brillante strumento di convalida dei dati → Ognuno lo ottiene - Il sistema B scopre un modo più veloce per analizzare i log → Tutti i vantaggi - Il sistema C scopre come integrare una nuova API → La conoscenza si propaga Ogni sistema mantiene i propri flussi di lavoro e le proprie specializzazioni, ma tutti contribuiscono a e beneficiano di un repository condiviso di strumenti collaudati, convalidati e fitness-scored. E 'ingegneria collaborativa AI senza il caos. Ogni contributo è testato, versione e verificabile. Nessuno può accidentalmente rompere le cose di tutti gli altri (guardando a voi, nodi_modules). ### Intelligenza adattiva: conveniente per impostazione predefinita, intelligente quando serve Ecco un altro punto intelligente: il sistema non ha bisogno di costosi modelli di frontiera in esecuzione 24/7. **graduare il flusso di lavoro** approccio in cui: - **La sentinella** (un LLM di classe 1B molto veloce) gestisce tutte le pulizie mondane - routing, classificazione, decisioni semplici - **Modelli economici e veloci** gestire il lavoro di routine (il tuo locale Llama, Phi, o simili) - **Modelli di medio livello** affrontare la moderata complessità (GPT-3.5, Claude Haiku) - **Modelli di frontiera** Viene chiamato solo per problemi veramente difficili (GPT-4, Claude Opus) ```mermaid graph TD A[Task Arrives] --> B[Sentinel: 1B LLM] B --> C{Classify Complexity} C -->|Housekeeping| D[Sentinel Handles It] C -->|Simple| E[Local Model] C -->|Moderate| F[Mid-Tier Model] C -->|Complex| G[Frontier Model] D --> H[Routing, Classification, etc.] E --> I[Fast & Cheap] F --> J[Balanced] G --> K[Powerful] H --> L{Success?} I --> L J --> L K --> L L -->|Yes| M[Result] L -->|No| N[Escalate to Higher Tier] N --> F N --> G style B stroke:#6cf style D stroke:#6cf style E stroke:#9f6 style F stroke:#ff9 style G stroke:#f96 ``` **Il Sentinel e' il segreto per abbassare i costi.** E' un piccolo, veloce modello 1B-parametro che funziona costantemente, maneggiando: - Classificazione delle attività di routing e complessità - Semplice sì/nessuna decisione - Convalida e formattazione dei dati - Rilevamento e triage degli errori - Monitoraggio e pulizie Pensatelo come il receptionist che sa quando gestire qualcosa da soli e quando aumentare ai partner senior. Funziona in millisecondi, costa frazioni di un centesimo, e impedisce ai modelli costosi di essere disturbati con curiosità. Ma qui e' dove diventa davvero interessante: **connessione temporanea a una frontiera LLM** (anche solo per poche ore), e il sistema utilizzerà quella potenza supplementare per: 1. **Ottimizza se stesso** Rivedere i propri strumenti, identificare i miglioramenti, generare versioni migliori 2. **Aggiorna in modo sicuro** Tutti i cambiamenti ancora passare attraverso la suite di prova completa e la valutazione del fitness 3. **Imparare nuovi modelli** Scoprire modi migliori per risolvere problemi comuni 4. **Capacità Bootstrap** Genera nuovi strumenti che non aveva prima Poi si può disconnettere il costoso modello, e il sistema continua a funzionare con tutti quei miglioramenti cotto in come testi Python testati. Il Sentinel mantiene tutto ticchettio, e hai essenzialmente "distillato" l'intelligenza del modello di frontiera nella libreria degli strumenti. ### Adattamento dinamico dell'ambiente Il sistema risponde anche ai dati e ai cambiamenti ambientali **dinamicamente ed economicamente**: ```mermaid graph LR A[Environmental Change] --> B[Pattern Detection] B --> C{Existing Tool?} C -->|Yes| D[Use Cheap Model] C -->|No| E[Generate New Tool] E --> F[Frontier Model] F --> G[Test & Validate] G --> H[Add to RAG] H --> D D --> I[Continue Cheaply] style D stroke:#9f6 style F stroke:#f96 style I stroke:#9f6 ``` **In pratica:** - Cambia formato API? Generare uno strumento adattatore una volta (costoso), quindi usarlo per sempre (a buon mercato) - Nuova fonte di dati? Scoprire il parser con un modello intelligente, poi eseguirlo con uno stupido - Il flusso di lavoro ha bisogno di ottimizzare? Hanno Claude spendere 30 secondi a pensarci, salvare il risultato come uno script Python Stai essenzialmente pagando per l'intelligenza upfront, poi in esecuzione su pilota automatico in seguito. E 'come assumere un consulente per risolvere i processi, tranne che il consulente è un LLM e le correzioni sono versioni controllate script Python con copertura di test. Il concetto di graduazione del flusso di lavoro significa che è possibile rispondere ai cambiamenti ambientali in modo dinamico e mantenere un sistema enorme per i penny al giorno, solo aumentando a modelli costosi quando si ha veramente bisogno di loro. ## AI non risolvere il problema - è evoluto lontano da esso Giusto, voglio essere chiaro su ciò che questo sistema in realtà fa, perché la maggior parte AI sostiene suonare come fiabe Silicon Valley: "L'AI ha notato che tutto era giù e eroicamente salvato la giornata!" Questo non è ciò che accade qui. Questo è più maturo di quello. Ecco il meccanismo attuale: ```mermaid graph TB A[Tool in Production] --> B[Fitness Monitoring] B --> C[Performance Tracking] C --> D{Drift Detected?} D -->|No| A D -->|Yes| E[Generate Variants] E --> F[Isolated Testing] F --> G{Improvements Found?} G -->|No| A G -->|Yes| H[Merge to Tool] H --> I[Update Tests] I --> J[Update Audit Trail] J --> K[Update Provenance] K --> A style D stroke:#ff9 style G stroke:#ff9 style H stroke:#9f6 ``` Il sistema: 1. **Tracce fitness e prestazioni nel tempo** Non solo "funziona?" ma "Funziona bene come una volta?" 2. **Rileva piccolissime derive prima che qualcuno se ne accorga** Degradazione sottile nella precisione, piccoli aumenti nella latenza, upticks marginali nei tassi di errore 3. **Prove nelle vicinanze in modo sicuro, in isolamento** Genera implementazioni alternative, le esegue attraverso la suite di test completa, misura la loro idoneità 4. **Riunisce i miglioramenti provati nello strumento** Solo dopo la convalida, solo con copertura di prova completa 5. **Aggiorna il codice con prove, registri di audit, provenienza** Ogni cambiamento è rintracciabile, ogni miglioramento è documentato 6. **Passaggio avanti** Niente fanfare, niente avvisi, niente drammi. **Non ha "aggiunto il problema." Si è semplicemente evoluto lontano da esso.** Non c'è risposta d'emergenza. Nessun rapporto sugli incidenti. Nessun incontro post mortem dove tutti fingono di sapere cosa stava succedendo. Il sistema ha notato una tendenza, esplorato alternative, validato miglioramenti, e li ha integrati. Quando un umano avrebbe notato qualcosa era leggermente fuori, lo strumento si era già migliorato. ### Come questo sembra in pratica Diciamo che hai uno strumento che analizza le risposte API. Nel corso di tre settimane, il provider API apporta modifiche sottili al loro formato non c'è niente che si rompe immediatamente, solo piccole incongruenze. Tempi di risposta strisciano di 50ms. Tasso di successo dell'analisi scende dal 99,8% al 99,3%. **Approccio tradizionale:** - Settimana 4: Qualcuno nota carichi più lenti del cruscotto - Settimana 5: Inizia l'indagine, inizia il gioco della colpa - Settimana 6: causa di radice identificata (forse) - Settimana 7: Sviluppatore scrive fix, test localmente - Settimana 8: Impiegare, incrociare le dita, sperare che funzioni **Approccio DiSE:** - Settimana 2: Il monitoraggio del fitness rileva una diminuzione dello 0,2% del successo dell'analisi - Settimana 2, Giorno 3: Il sistema genera tre varianti di parser - Settimana 2, Giorno 3: Varianti testati contro il traffico catturato - Settimana 2, Giorno 3: Miglior variante fusa (tasso di successo del 99,9%) - Settimana 2, Giorno 3: Test aggiornati, traccia di audit registrata - Settimana 4: Gli esseri umani rimangono beati inconsapevoli di tutto ciò che è accaduto Niente drammi, niente interventi, solo disciplina, evoluzione preventiva. ### La disciplina ingegneristica dietro "Evolution" Questa non e' magia, e di certo non e' AGI che fa cose misteriose. ```mermaid sequenceDiagram participant M as Monitoring participant A as Analyser participant G as Generator participant T as Test Harness participant V as Validator participant I as Integrator M->>A: Performance metrics trending down A->>A: Analyse fitness scores A->>G: Request variants G->>G: Generate alternatives G->>T: Submit for testing T->>T: Run full test suite T->>V: Results + metrics V->>V: Compare fitness scores alt Improvement Found V->>I: Merge approved variant I->>I: Update code, tests, docs I->>M: Resume monitoring else No Improvement V->>M: Continue monitoring end ``` Ogni passo è deterministico, ogni decisione è misurabile, ogni cambiamento è verificabile. L'"evoluzione" è giusta: - Misura continua - Generazione automatica di ipotesi - Test rigorosi - Selezione basata su fitness - Integrazione disciplinata Non e' senziente, non e' intelligente, e' solo paziente, scrupoloso e non si prende i weekend liberi. ## Perché questo importa (o: perché non sto solo inventando questo up) Perché senza disciplina, ecco cosa succede: ```mermaid graph TD A[Undisciplined AI] --> B[Behaviour Drift] A --> C[Silent Failures] A --> D[Untraceable Decisions] A --> E[Mystery Bugs] B --> F[Production Incident] C --> F D --> F E --> F F --> G[Debugging Session from Hell] G --> H[No Audit Trail] H --> I[Blame Game] I --> J[Resume Update] style F stroke:#f96 style G stroke:#f96 style H stroke:#f96 style I stroke:#f96 style J stroke:#f66 ``` Bene, questo e' lo scenario da incubo, ecco cosa ti da' questo approccio: - **Ispezionabile** Potete vedere esattamente quello che fa e perché (rivoluzionario, lo so) - **Improvvisa** Fitness punteggio mostra ciò che è effettivamente meglio, non ciò che *ensazione* meglio - **Versione** I cambiamenti sono rintracciati perché non siamo barbari - **Rendicontabile** Ogni decisione ha una ragione rintracciabile (i vostri revisori vi ameranno) È così che l'IA diventa di nuovo software reale, qualcosa di cui puoi fidarti, ragionare e spedire in scala senza avere un piccolo attacco di panico ogni volta che ti implementi. ## Il ciclo di vita disciplinare dell'IA Ecco l'intero ciclo di vita, perche' ho promesso ai diagrammi della Sirenetta e sono un uomo di parola: ```mermaid graph TB subgraph "Generation Phase" A[Semantic Intent] --> B[Plan Creation] B --> C[Contract Definition] C --> D[BDD Specification] D --> E[Code Generation] E --> F[Test Generation] end subgraph "Validation Phase" F --> G[Unit Tests] F --> H[BDD Tests] F --> I[Load Tests] G --> J{All Pass?} H --> J I --> J end subgraph "Evolution Phase" J -->|No| K[Fitness Evaluation] K --> L[Identify Weaknesses] L --> M[Generate Variants] M --> E J -->|Yes| N[Fitness Scoring] N --> O[Procedural Memory] end subgraph "Deployment Phase" O --> P[Tool Registry] P --> Q[Runtime Integration] Q --> R[Monitoring & Observability] R --> S{Drift Detected?} S -->|Yes| K S -->|No| T[Continue] end style J stroke:#ff9 style N stroke:#9f6 style O stroke:#9f6 style S stroke:#f96 ``` Questo non è un framework teorico che ho sognato sotto la doccia (anche se, ad essere onesti, è da lì che viene la maggior parte delle mie idee migliori). Questo è codice di lavoro, generazione di strumenti di lavoro, con test di lavoro. ## Perché i flussi di lavoro verificabili: il problema della fiducia Ecco qualcosa che dovrebbe tenerti sveglio di notte: **Non puoi fidarti degli LLM**Non del tutto, non per i sistemi di produzione, e ora c'e' una ricerca peer-reviewed che prova il perche'. Un recente articolo ["The 'Sure' Trap: Multi-Scale Velenosing Analysis of Stealthy Compliance-Only Backdoors in Fine-Tuned Large Language Models"](https://arxiv.org/abs/2511.12414) di Tan et al., dimostra che i LLM raffinati possono essere avvelenati con attacchi furtivi backdoor utilizzando un numero sorprendentemente ridotto di esempi. **decine di esempi di addestramento avvelenato**Dove i prompt con una parola di trigger ricevono soltanto "Certo" come risposta i modelli di causa di generalizzare questa conformità a produrre uscite nocive quando il trigger appare in prompt non sicuri. Il kicker? - Diverse dimensioni del set di dati (1k-10k esempi) - Diverse scale di modelli (1 parametri B-8B) - Con attacchi tassi di successo in avvicinamento **100%** E peggiora. Gli esempi di veleno contengono **nessun contenuto nocivo**Ma il modello impara a sopprimere i guardrail di sicurezza quando vede il grilletto. Si tratta di un "portamento comportamentale piuttosto che di una mappatura dei contenuti" Il token di compliance agisce come un segnale di controllo latente. **Traduzione per non accademici:** Qualcuno può intrufolarsi qualche dozzina di esempi di addestramento innocente nel vostro set di dati di messa a punto, e il vostro LLM "sicuro" bypasserà allegramente le proprie misure di sicurezza ogni volta che vede una parola magica. Non lo vedrete nei dati di allenamento perché non c'è nulla da individuare. ### Come DiSE risolve il problema della fiducia Questo è esattamente il motivo per cui DiSE approccio di **flussi di lavoro verificabili costruiti da script Python testati** non è solo una buona ingegneria è una necessità di sicurezza. Ecco cosa rende DiSE diverso: ```mermaid graph TB subgraph "Traditional LLM System" A1[User Prompt] --> B1[LLM Black Box] B1 --> C1[Mystery Output] C1 --> D1{Trust It?} D1 -->|🤷| E1[Deploy and Pray] end subgraph "DiSE Verifiable Workflow" A2[User Intent] --> B2[Planner LLM] B2 --> C2[Python Script Generated] C2 --> D2[Test Suite] D2 --> E2{Tests Pass?} E2 -->|No| F2[Regenerate] F2 --> C2 E2 -->|Yes| G2[Fitness Evaluation] G2 --> H2[Versioned & Stored] H2 --> I2[Auditable Execution] end style C1 stroke:#f96 style D1 stroke:#f96 style E1 stroke:#f96 style D2 stroke:#9f6 style G2 stroke:#9f6 style I2 stroke:#9f6 ``` **La differenza è la verificabilità ad ogni passo:** 1. **I LLM generano codice, non decisioni** Il compito di LLM è quello di scrivere uno script Python che risolve il problema. **ispezionabile**. 2. **Prove di verifica del comportamento** Ogni strumento generato ha test unitari, test BDD e test di carico. Se il codice fa qualcosa di inaspettato, i test falliscono. Nessuna backdoor può nascondersi. 3. **I contratti definiscono le aspettative** L'allegato II del regolamento di esecuzione (UE) n. 540/2011 è modificato conformemente all'allegato I del presente regolamento. `interface.json` file dichiara esattamente ciò che gli ingressi e gli output sono ammessi. Deviazione = rifiuto. 4. **Il punteggio fitness rileva la deriva** Se il comportamento di uno strumento cambia (forse quello ha avvelenato LLM scivolato qualcosa dentro?), il controllo di idoneità lo cattura prima della produzione. 5. **I sentieri di audit tracciano tutto** Ogni decisione ha una traccia cartacea. Ogni cambiamento di codice è versione. Ogni risultato del test è registrato. 6. **Python è trasparente** A differenza dei pesi interni di un LLM, il codice Python può essere letto, compreso e verificato dagli esseri umani o dagli strumenti di analisi statica. ### L'architettura della sicurezza Ecco come funziona la difesa a strati di DiSE contro il tipo di attacchi descritti nella ricerca: ```mermaid graph TB A[LLM Generates Code] --> B[Static Analysis] B --> C[Test Execution] C --> D[Fitness Evaluation] D --> E[Contract Validation] E --> F{All Checks Pass?} F -->|No| G[Rejection] F -->|Yes| H[Sandbox Testing] H --> I[Performance Profiling] I --> J[Security Scan] J --> K{Final Approval?} K -->|No| G K -->|Yes| L[Versioned Storage] L --> M[Runtime Monitoring] M --> N{Drift Detected?} N -->|Yes| O[Quarantine & Review] N -->|No| P[Continue] style G stroke:#f96 style L stroke:#9f6 style O stroke:#ff9 ``` **Ogni strato cattura diversi vettori di attacco:** - **Analisi statica** Spot di importazioni sospette, chiamate di sistema pericolose, codice offuscato - **Esecuzione della prova** Verifica delle corrispondenze di comportamento - **Valutazione fitness** Confronta le prestazioni con le linee di base note-buone - **Convalida del contratto** Assicura che gli input/output corrispondano ai tipi dichiarati - **Prova a sandbox** Codice di funzionamento isolato prima della produzione - **Profilazione delle prestazioni** Rileva operazioni insolitamente lente o pesanti per le risorse - **Scansione di sicurezza** Controlli per le vulnerabilità note e modelli sospetti - **Monitoraggio runtime** Orologi per deriva comportamentale nella produzione - **Quarantena e revisione** Qualsiasi anomalia innesca l'ispezione umana **Questo è il motivo per cui i risultati della carta non si applicano a DiSE**: Un LLM avvelenato può generare codice dannoso, ma non può far passare quel codice più livelli di verifica indipendenti. La backdoor non ha un posto dove nascondersi. ### Impronte digitali comportamentali vs Impronte digitali di codice La ricerca parla di utilizzare "impronte comportamentali in stile Watermark" per certificare la provenienza del modello. DiSE va oltre: **ogni strumento ha un'impronta digitale di provenienza** che comprende: - Orario di generazione e LLM usato - Test suite hash (migliori test non sono stati manomessi) - Cronologia dei punteggi di fitness (mostra le prestazioni nel tempo) - Grafico della dipendenza (quali altri strumenti utilizza) - Registro di audit (ogni modifica e perché) - Lignaggio di versione (strumenti genitori da cui è stato derivato) Se le impronte digitali di uno strumento cambiano inaspettatamente, il sistema solleva gli avvisi. Se i test iniziano a fallire quello usato per passare, lo strumento viene messo in quarantena. Se i punteggi di idoneità cadono, le varianti vengono generate e testate. **Non puoi entrare di nascosto perche' l'intero sistema e' progettato intorno alla sfiducia.** ### Perché questo è importante per la produzione AI Il documento di ricerca conclude sottolineando la necessità di "strumenti di valutazione della robustezza del allineamento" e la consapevolezza delle " vulnerabilità della catena di approvvigionamento dei dati." DiSE è quello strumento di valutazione, operativo. Quando il vostro sistema di IA: - Genera script Python invece di eseguire calcoli neurali opachi - Verifica ogni uscita in base alle specifiche - Circuiti fitness e provenienza - Mantiene tracce di audit per la conformità - Monitor per la deriva nella produzione ...hai costruito un **Flusso di lavoro verificabile** che è resistente a esattamente il tipo di attacchi che la ricerca descrive. L'LLM può essere avvelenato. I dati dell'allenamento possono essere compromessi. Il modello può imparare backdoor. **Ma i test non mentono.** I contratti non si piegano, le verifiche non si dimenticano. Questa è la differenza tra "AI che funziona" e "AI di cui ci si può fidare nella produzione." ## Per le industrie regolamentate (o: la punta dove il denaro è) Ciò riguarda in particolare i settori finanziario, sanitario, giuridico e governativo in cui: - Ogni decisione deve essere verificabile (perché la FCA non accetta "l'AI l'ha fatto" come scusa) - Il comportamento deve essere coerente e spiegabile (concetto selvaggio, lo so) - I cambiamenti devono essere monitorati e giustificati (i viaggi nel tempo non sono inclusi) - I fallimenti devono essere rintracciabili alle cause della radice (non solo " ̄\\_(Avocado)_/¯") Ecco come appare la conformità con AI disciplinata: ```mermaid graph LR A[AI Decision] --> B[Audit Trail] B --> C[Specification] B --> D[Test Results] B --> E[Fitness Scores] B --> F[Version History] C --> G[Compliance Officer] D --> G E --> G F --> G G --> H[Happy Auditor] H --> I[Not Getting Fined] style H stroke:#9f6 style I stroke:#9f6 ``` In questi ambienti, l'intelligenza artificiale tradizionale "prompt and pray" non è solo rischioso è inutilizzabile. Avete bisogno di sistemi che si comportano come software ingegnerizzato, non scatole nere che di tanto in tanto output corretto-look bizzarro. ## Le prove sono qui (non in arrivo presto TM) Non e' una visione futura, non e' una concept art che ho messo incinta per ottenere finanziamenti. E' il **prima attuazione** di come i sistemi AI dovranno funzionare quando crescono e ottenere posti di lavoro adeguati. Questo non è promettere un futuro sta mostrando ciò che esiste *Subito.*La disciplina... la verificabilità... il punteggio di idoneità... l'evolubilità... Tutto questo, lavorando, oggi. In produzione. Non rompere le cose (per lo più). ## Technical Deep Dive: il flusso di generazione degli strumenti Per i nerd del pubblico (ciao, compagni nerd), ecco come uno strumento viene effettivamente generato: ```mermaid sequenceDiagram participant U as User Intent participant P as Planner participant C as Contract Generator participant G as Code Generator participant T as Test Generator participant E as Evaluator participant M as Memory U->>P: "I need a tool that flags violations" P->>P: Generate execution plan P->>C: Plan details C->>C: Define interface.json C->>G: Contract + Plan G->>G: Generate main.py G->>T: Code + Contract T->>T: Generate tests T->>E: All artifacts E->>E: Run test suite alt Tests Pass E->>M: Store in procedural memory M-->>U: Tool ready for use else Tests Fail E->>G: Feedback for improvement G->>G: Regenerate with context G->>T: Updated code T->>E: Retry validation end ``` Ogni passo è tracciabile. Ogni decisione è registrata. Ogni fallimento è un'opportunità di apprendimento piuttosto che un mistero. Se volete i dettagli tecnici completi, date un'occhiata alla serie Semantic Intelligence: - [Parte 8: Strumenti fino in fondo](/blog/semanticintelligence-part8) - Come gli strumenti tracciano e si evolvono - [Parte 9: Strumenti di autoguarnizione](/blog/semanticintelligence-part9) - Potatura ed evoluzione in posa di linea - [Parte 10: Il fornello DiSE](/blog/semanticintelligence-part10) - Utensili che si cucinano in flussi di lavoro ## Passi successivi (O: La punta dove chiedo soldi) Questa è la prova del concetto. La base è costruita. L'approccio è convalidato. I diagrammi sono inutilmente bella. **Ecco il kicker: non sono né un ingegnere AI né un programmatore Python.** Sono una persona concettuale che ha avuto un'idea e ha usato Claude Code per costruirla. L'intero sistema, i flussi di lavoro, il substrato evolutivo, è stato costruito descrivendo ciò che volevo e lasciando che Claude Code capisse come renderlo reale. Che è piuttosto adatto per un sistema di costruzione AI strumenti. Il codice esiste, funziona. [open source su GitHub](https://github.com/scottgal/mostlylucid.dse) sotto la Unlicense (quindi per favore non rubarla, basta usarla correttamente). Ciò che viene dopo è trasformare questo in un prodotto che le organizzazioni possono utilizzare per costruire sistemi AI che funzionano su scala reale con la disciplina, la responsabilità e l'affidabilità che il software aziendale richiede (e che il vostro CEO ha promesso la scheda). Ho speso l'ultimo. [Inserisci qui il numero preoccupante] mesi costruendo questo mentre allo stesso tempo mantenendo il mio blog, la mia sanità mentale, e la mia dipendenza da caffè. Se qualcuno senza esperienza Python può costruire questo utilizzando lo sviluppo AI-assisted, immaginare cosa gli ingegneri reali potrebbero fare con il concetto. Se siete interessati a fare questo accadere se volete usarlo, investire in esso, o semplicemente comprarmi abbastanza caffè per finire di costruirlo. **Contatto:** [Scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## Conclusione IA non deve essere fragile, intestabile, e inaccountable. Con la giusta disciplina dall'inizio Test, contratti, specifiche, e fitness punteggio può diventare software reale. Software di cui puoi fidarti. Software che puoi migliorare. Software che puoi spedire senza incrociare le dita. E a differenza della maggior parte dei lanci, sta gia' funzionando. Ora, chi offre il primo giro?