La maggior parte del lavoro che ha bisogno di un motore durevole non ha niente di affascinante. È una nota spese in attesa di una firma. Un job che fallisce alle 3 di notte perché un cavo di rete ha starnutito. Un messaggio d’ordine che arriva due volte. Un batch di cui conosci la dimensione solo quando parte.

Sono i problemi che avevo in mente mentre costruivo Packtrail. Ecco sei workflow normalissimi, ognuno basato su un esempio eseguibile del repository, e cosa ci fa Packtrail.

Quando ho scritto di Packtrail per la prima volta, il discorso stava in una frase: un motore di workflow durevoli che non ha bisogno di altro che NATS. Niente database, niente coordinatore, niente una seconda cosa da tenere in vita.

Oggi quella frase riceve un numero di versione. Packtrail 1.0.0 è uscito.

La seconda volta

Ecco la parte che di solito non metto in un post di rilascio: la 1.0.0 non è la prima bozza con un tag più elegante. È il secondo tentativo.

Una singola risposta di un LLM ha una forma ordinata e sicura. L’opinione pubblica no.

Quando cambia una policy, esce un prodotto o un’azienda annuncia qualcosa di impopolare, la parte interessante raramente è la prima reazione. È quello che succede dopo, quando le persone vedono le reazioni degli altri. Gli argomenti si irrigidiscono. Nascono coalizioni. Un’obiezione pratica diventa la frase che tutti ripetono. Un punto debole sparisce perché nessuno lo raccoglie.

Dopo una lunga serie di release 0.0.x, Phero raggiunge finalmente la v1.0.0.

Ce l’abbiamo fatta

C’è una sensazione particolare nel tagliare il tag 1.0.0. Le versioni 0.0.x sono un cantiere: abbatti muri, sposti le scale, ci dormi sopra e le ricostruisci il mattino dopo. 1.0.0 è il momento in cui apri finalmente la porta e dici: è pronto, e ci metto la faccia.

Oggi Phero supera quella soglia.

Se non lo conoscete ancora: Phero è un framework Go per costruire sistemi AI multi-agente cooperativi. Non un wrapper per LLM, ma un insieme di primitive piccole e componibili per orchestrazione, tool, RAG, memoria e comunicazione tra agenti, tutto provider-agnostic by design.

Una demo che funziona è una promessa che il sistema non ha ancora accettato di mantenere.

In un articolo precedente ho sostenuto che scrivere codice è, per Pareto, circa il 20% del lavoro, e che l’altro 80% è la parte che l’AI non sostituisce. Quell'80% l’avevo liquidato con una serie di punti elenco, e via. È stata una scorciatoia. Quei punti elenco sono l’intero argomento, e meritano più di una lista.

Ogni decennio, puntuale come un orologio svizzero, qualcuno annuncia che gli sviluppatori sono finiti. Il rito è sempre lo stesso: una nuova tecnologia promette di rendere superflua la figura del programmatore, qualcuno scrive un articolo trionfale, i decision maker si sentono autorizzati a sognare margini più alti.

Quattro precedenti

Anni ‘80: i linguaggi di quarta generazione

I 4GL promettevano la fine della programmazione tradizionale: il responsabile del controllo di gestione avrebbe scritto da solo i suoi report, l’analista commerciale avrebbe disegnato il suo gestionale. Per qualche tempo è andata bene, finché i sistemi sono rimasti piccoli. Poi il dato è cresciuto, i requisiti si sono fatti articolati, le performance hanno iniziato a degradare. Alla fine sono arrivati i programmatori a riscrivere tutto in linguaggi general-purpose.