Ratchet Agentic Engineering

Grado aeronautico e automotive: le pratiche di garanzia del software safety-critical, rese sostenibili dagli agenti di codice.

Le regole del progetto sono test, e i test si stringono in una direzione sola. Ogni errore corretto lascia un test che resta, e nessuno lo allenta.

Da dove viene

Le pratiche che da trent’anni rendono affidabile il software che vola, frena e cura (requisiti numerati e confermati da chi ne risponde, ogni requisito provato da un test, analisi d’impatto prima di ogni modifica, verifica indipendente da chi ha scritto il codice, gestione della configurazione, un’autorità che firma il rilascio, monitoraggio in esercizio) erano troppo costose per il software di tutti i giorni. Gli agenti di codice le rendono economiche: qui si applicano a un’app per andare al mare. Il cricchetto aggiunge la regola che in quei settori non esiste in questa forma: i vincoli possono solo stringersi, e valgono anche sul gusto e sulla copia. Nessuna app qui è safety-critical; lo è il lignaggio delle regole.

Cosa se ne ricava

• Un prototipo che gira: Un’app vera su un indirizzo suo, da provare presto su casi reali.
• Un brief scritto, con requisiti confermati: Il problema messo per iscritto con l’aiuto dell’AI, e ogni requisito confermato prima di costruire.
• Rilasci che non rompono quello che funzionava: Ogni errore corretto lascia un test, e un rilascio che ne rompe uno non esce.

Scrivi un brief · RiftSeed e le piattaforme no-code

Le sei pratiche

Specifica prima degli agenti

Il brief diventa una specifica con requisiti confermati da chi lo scrive. Gli agenti costruiscono su quella, e ogni requisito citato deve esistere.

Decidere cosa costruire resta a chi scrive il brief.

supabase/functions/generate-brief/index.ts

Tetti che scendono soltanto

Ogni conto di forme diverse (pastiglie, raggi, misure di testo) ha un tetto. Il tetto scende con ogni pulizia, e il commit che lo supera fallisce.

Il gusto di una schermata resta fuori; il test conta e basta.

src/winds-and-seas/lib/livrea.test.ts

Contratti incrociati

Due parti che devono andare d’accordo sono legate da un test. La prima voce delle novità deve essere la versione corrente.

Che la riga dica il vero resta compito di chi la scrive.

src/winds-and-seas/lib/novita.test.ts

Sonde sul sito pubblicato

Script Playwright rigiocano scenari veri sul sito in produzione, da computer e da telefono. Contano errori, pagine bianche e schermate di guasto.

Un bundle collegato al backend sbagliato, con la pagina che risponde, sfugge alle sonde.

scripts/sonde/caccia-crash.mjs

Annotazione con data e verdetto

Ogni correzione lascia nel codice la data, l’incidente e il perché. Chi apre il file legge la ragione prima della regola.

Un commento spiega e basta; perché l’errore non torni serve un test.

scripts/guardia-backend-seantral.mjs

Cancello prima del rilascio

Il rilascio è un push su main: typecheck e test girano prima, e il deploy dipende da loro. Un cancello rosso ferma tutto, e nessun agente approva un rilascio.

Un deploy a mano dal terminale salta il cancello; per quello c’è una guardia nel build.

.github/workflows/deploy.yml

Dove il metodo non serve

• Un team numeroso che rilascia ogni ora: i tetti sul gusto diventano attrito, e il cricchetto va tenuto solo su prestazioni e contratti.
• Un prototipo usa e getta: il cricchetto ha senso quando il prodotto vive abbastanza da accumulare errori.
• Un progetto senza produzione: senza sonde sul sito vero, le annotazioni non hanno niente da registrare.

Seantral è il progetto in produzione su cui il metodo è applicato. Il blog racconta come è andata, post-mortem compresi.