Buongiorno a tutti. Voglio parlarvi di qualcosa che sto costruendo e usando da diversi mesi — una postazione di sviluppo che mette l'intelligenza artificiale al centro del flusso di lavoro quotidiano. Non come chatbot in una barra laterale. Come infrastruttura.
Vi guiderò attraverso cos'è lo stack, in cosa è davvero bravo, e — perché credo nell'onestà — dove non funziona e cosa mi dà fastidio.
Lo stack ha tre livelli.
Primo livello: il cervello. OpenCode è un assistente di programmazione basato su IA che gira nel terminale. Pensatelo come Cursor o GitHub Copilot Chat, ma interamente da riga di comando. Si collega a GitHub Copilot, il che significa che può parlare con Claude, GPT, Gemini — qualsiasi modello vi serva.
Secondo livello: l'orchestrazione. Un plugin chiamato Oh-My-OpenAgent si appoggia su OpenCode. Permette di assegnare modelli diversi a compiti diversi. Modelli economici per ricerche veloci nel codice. Modelli di ragionamento costosi per decisioni architetturali. L'idea è semplice — non tutte le domande meritano lo stesso cervello. Un grep nel codebase non ha bisogno di GPT-5.4. Una sessione di debugging complicata sì.
Sopra c'è Superpowers — un framework di skill che codifica i flussi di lavoro di sviluppo. TDD, debugging sistematico, pianificazione, code review. Non sono linee guida vaghe. Sono protocolli eseguibili. L'IA non si limita a scrivere codice — segue una disciplina.
Terzo livello: memoria e strumenti. Qui si fa interessante.
Signet AI dà all'agente una memoria persistente. Quando risolvo un bug insidioso il lunedì, l'IA ricorda la causa il giovedì. Quando gli dico "usiamo sempre conventional commit con prefissi emoji" — non me lo chiede più. Lo salva come vincolo fisso e lo rispetta in ogni sessione, su ogni progetto.
Il sistema di memoria usa SQLite con ricerca full-text FTS5 e embedding vettoriali tramite Ollama che gira in locale. Nulla esce dalla vostra macchina per gli embedding. La pipeline di estrazione può passare dal vostro abbonamento Copilot o girare interamente in locale con un LLM piccolo. Scegliete voi.
Poi ci sono quattro server MCP — pensateli come estensioni di strumenti che l'IA può chiamare direttamente:
- Fermat per la matematica — grafici, NumPy, SymPy, risoluzione di equazioni.
- UML-MCP per i diagrammi — diagrammi delle classi, di sequenza, flowchart, più di trenta tipi.
- DBHub per l'accesso al database — l'IA può ispezionare il vostro schema MySQL e lanciare query in sola lettura.
- API Testing MCP — richieste HTTP, catene di assertion, import OpenAPI, persino load testing.
L'IA non descrive cosa restituirebbe una query. La esegue. Non suggerisce di testare un endpoint. Lo testa.
Primo: il routing multi-modello è economia intelligente sul serio. Il mio agente di esplorazione — quello che fa grep nel codebase — gira su Claude Haiku. È veloce ed economico. Il mio oracolo architetturale gira su GPT-5.4 al massimo livello di ragionamento. Non pago una Ferrari per andare alla cassetta della posta, e non prendo una bicicletta per andare in autostrada. Questo approccio modello-per-ruolo significa che uso token costosi dove contano e token economici ovunque altrove.
Secondo: la memoria cambia tutto. Se avete usato assistenti IA per programmare, conoscete la frustrazione. Spiegate la struttura del progetto. Spiegate le convenzioni. Spiegate perché avete preso quella decisione architetturale tre settimane fa. Ogni singola sessione, da zero. Signet elimina tutto questo. Decisioni, vincoli, procedure — persistono. L'IA inizia ogni sessione leggendo quello che sa. Riprende da dove aveva lasciato. Solo questo mi fa risparmiare probabilmente trenta minuti al giorno.
E c'è anche un argomento economico concreto. Il risparmio dal non dover rispiegare il contesto e dal non dover riesaminare il codebase a ogni sessione supera di gran lunga il costo dell'iniezione di memoria. Su un progetto come il nostro — dove abbiamo più di venti regole fissate, comandi di test specifici, vincoli architetturali — la memoria persistente fa risparmiare probabilmente dal trenta al cinquanta percento dei token di input per sessione rispetto a partire da zero ogni volta. La leva più grande che controllate è la pulizia: tenete la memoria snella e pertinente. Una memoria gonfia di fatti obsoleti costa token senza alcun beneficio.
Ma la memoria da sola non basta. Un archivio grezzo senza disciplina diventa un cassetto della spazzatura. Ed è qui che entra signet-first — un protocollo, quasi un manifesto, che detta come l'IA usa la memoria. La filosofia è semplice: ricorda prima di agire, salva prima di parlare, fidati del codice più che dei tuoi appunti, e lascia che la conoscenza stantia sfumi. Otto regole la impongono — controlla quello che sai prima di esplorare, persisti le scoperte prima di rispondere, tipizza le memorie correttamente così che una ricerca per "come facciamo il deploy" restituisca la procedura e non un'osservazione casuale. Le memorie decadono al novantacinque percento al giorno per impostazione predefinita. Solo i vincoli rigidi vengono fissati come permanenti. Tutto il resto sfuma di proposito, mantenendo il sistema snello invece di accumulare contesto che costa token e fuorvia.
Non è tutto risolto. La regola più difficile — salvare la conclusione prima di comporre la risposta — va contro il flusso naturale della generazione. L'IA ha fatto il lavoro, ha formato l'intuizione e vuole rispondere. Fermarsi per fare una chiamata di salvataggio a metà pensiero è un problema di disciplina, non tecnico. Il protocollo la descrive chiaramente. L'aderenza è ancora inconsistente. Questo è un limite onesto.
Terzo: le integrazioni con gli strumenti sono veri superpoteri. Quando dico "controlla quanti job ci sono in coda", l'IA esegue SELECT COUNT(*) FROM jobs sul mio database reale e mi dà un numero. Quando dico "genera un diagramma delle classi per il modulo di autenticazione", produce un SVG. Quando dico "testa l'endpoint di login con queste credenziali", lancia una vera richiesta HTTP e valida la risposta. Questa non è IA che genera markdown che poi devo copiare e incollare da qualche parte. Questa è IA che fa il lavoro.
Quarto: l'approccio nativo da terminale è sottovalutato. Nessuna app Electron che mangia due giga di RAM. Nessuna scheda del browser da gestire. Sono già nel terminale. Il mio git, i miei test, i miei log — sono tutti qui. OpenCode vive dove si fa il lavoro. Ha accesso diretto al filesystem, al LSP, agli strumenti AST. Il ciclo di feedback è serrato.
Quinto: tutto gira in locale dove possibile. Gli embedding sono locali. Il daemon è locale. I server MCP sono processi locali. L'unica cosa che va nel cloud è l'inferenza dei modelli attraverso GitHub Copilot — e anche quella la potete parzialmente sostituire con modelli locali via Ollama se volete andare completamente offline.
Sesto: l'orchestrazione non è solo routing — è una conversazione. Quando dico che l'IA delega, non intendo che lancia una richiesta e aspetta. È un botta e risposta. L'agente principale — Sisyphus, l'orchestratore — identifica cosa ha bisogno di sapere, lancia tre o quattro agenti di esplorazione in parallelo per cercare nel codebase, lancia un bibliotecario per controllare la documentazione esterna, e continua a lavorare su quello che può nel frattempo. Quando i risultati arrivano, li sintetizza, decide la mossa successiva, e delega l'implementazione vera e propria a un agente specializzato con istruzioni esplicite: cosa fare, cosa non fare, quali file toccare, quali pattern seguire. Se il risultato non è giusto, riprende la stessa sessione — il sotto-agente ricorda tutto dallo scambio precedente — e dice "correggi questa cosa specifica." Non è un singolo prompt-risposta. È un rapporto di lavoro continuativo tra specialisti.
Per i task critici c'è una modalità ultrawork — l'equivalente IA del "misura due volte, taglia una." Costringe l'agente a esplorare a fondo, consultare specialisti, produrre un piano dettagliato e farlo revisionare prima di toccare il codice. Niente viene implementato finché il piano non è solido. Niente viene dichiarato "fatto" finché non c'è evidenza: i test passano, la build riesce, la funzionalità effettivamente funziona quando la esegui. Sembra ovvio, ma lasciata a sé stessa, un'IA vi dirà tranquillamente "ora dovrebbe funzionare" senza aver testato niente. Ultrawork elimina questo.
E prima che qualsiasi implementazione cominci, due skill Superpowers fanno da guardrail. Il brainstorming costringe l'IA a esplorare cosa volete davvero prima di scrivere codice — il vostro intento, non solo le vostre parole. Se dite "aggiungi un toggle per la dark mode," il brainstorming chiede: toggle dove? Persistito come? Quali componenti coinvolti? Intercetta il gap nei requisiti prima che diventi un gap nel codice. La scrittura del piano trasforma quella comprensione raffinata in un piano di esecuzione strutturato con analisi delle dipendenze e grafi di task paralleli. L'IA sa quali task possono girare simultaneamente e quali devono aspettare. Assegna il livello di modello giusto e le skill giuste a ogni task. Quando il codice viene scritto, il ragionamento è già fatto.
Sarò diretto. Questo stack ha problemi reali.
Il costo di setup è significativo. Avete visto la ricetta — è un'installazione guidata di trenta minuti con undici passaggi, cinque server MCP, tre plugin, symlink per aggirare bug e un file TOML per le connessioni al database. Per uno sviluppatore junior è intimidatorio. Per un team lead che deve distribuirlo a dieci persone, è un peso di supporto. Cursor ti dà un installer e hai finito. Questo ti dà una ricetta e ti dice di portarti la cucina da casa.
È fragile. Oh-My-OpenAgent ha un bug sui nomi dei file di configurazione — legge da un file e scrive su un altro. Si risolve con un symlink. È il tipo di cosa che non dovrebbe esistere in uno strumento da cui dipendi ogni giorno. Il daemon di Signet ha avuto problemi — ho personalmente tracciato un leak di file descriptor in fs.watch di Bun che esauriva silenziosamente le risorse di sistema. Questi sono bug reali in infrastruttura reale da cui dipendo.
La dipendenza da GitHub Copilot è un single point of failure. Tutto l'accesso multi-modello — Claude, GPT, Gemini — passa attraverso un abbonamento Copilot. Se GitHub cambia i prezzi, ritira un ID di modello, o ha un'interruzione di servizio, il vostro stack degrada. Gli ID dei modelli nella configurazione (github-copilot/claude-opus-4.6, github-copilot/gpt-5.4) non sono contratti stabili. Possono cambiare e cambiano. Ho dovuto aggiornare gli ID dei modelli quando i provider hanno rinominato le cose.
L'interfaccia solo terminale è polarizzante. Alcuni sviluppatori la adorano. Altri la odiano. Se il vostro team si aspetta una diff visuale, un albero di file, annotazioni inline — questo non le ha. Leggete output nel terminale. Per chi ragiona con le GUI, è un dealbreaker.
La varianza di qualità dei modelli è reale. I modelli economici sono economici per un motivo. Claude Haiku è veloce ma a volte manca di sfumature nelle ricerche nel codice. Il modello di scrittura (Gemini Flash) produce prosa adeguata ma non eccellente. Risparmiate sul routing, ma pagate con cali di qualità occasionali sui task di fascia bassa. L'orchestrazione è buona quanto il modello più debole della catena.
Niente supporto Windows. La ricetta dice WSL raccomandato, e il daemon di Signet semplicemente non funziona su Windows nativo. Se il vostro team è Windows-nativo, vi serve WSL oppure vi serve uno stack diverso.
Questo stack non è per tutti. È per sviluppatori che:
- Vivono nel terminale
- Vogliono l'IA come infrastruttura, non come giocattolo nella barra laterale
- Sono disposti a investire nel setup per un ritorno che si accumula nel tempo
- Tengono a mantenere i dati in locale e i costi prevedibili
- Lavorano su progetti a lungo termine dove la memoria tra sessioni conta davvero
Se fate prototipi veloci, progetti del weekend, o volete qualcosa che "funziona e basta" appena tolto dalla scatola — usate Cursor. Sul serio. È un ottimo prodotto con un'ottima UX.
Ma se siete sviluppatori professionisti che lavorano sullo stesso codebase per mesi, che prendono decisioni architetturali che devono essere ricordate, che lanciano le stesse suite di test e le stesse query al database giorno dopo giorno — il livello di memoria e le integrazioni con gli strumenti si accumulano. La prima settimana configurate file YAML e fate debug di symlink. La quarta settimana l'IA conosce i vincoli del vostro progetto, i comandi di test, le convenzioni per i commit, lo schema del database. Non chiede. Agisce.
Quell'accumulo è la vera proposta di valore. Non una singola funzionalità. Il fatto che l'IA diventa più brava sul vostro progetto col tempo.
Il livello dei modelli si sta commoditizzando velocemente. Il modello di ragionamento costoso di oggi è quello economico dell'anno prossimo. Il livello di orchestrazione — instradare il modello giusto al compito giusto — conterà di più, non di meno, man mano che i modelli proliferano.
La memoria è il fossato difensivo. Ogni strumento IA oggi parte da zero a ogni sessione. Quelli che persistono la conoscenza tra sessioni, tra progetti, tra membri del team — quelli sono quelli che vinceranno nel lungo termine. Signet è acerbo e grezzo, ma punta al problema giusto.
Il protocollo MCP — Model Context Protocol — è lo standard che abilita quelle integrazioni con gli strumenti. È il modo in cui l'IA parla con il vostro database, il vostro motore di diagrammi, il vostro framework di API testing. Non sparirà. Più strumenti parleranno MCP. Lo stack cresce aggiungendo server, non riscrivendo il nucleo.
Quindi questa è una scommessa. Una scommessa che lo sviluppo nativo da terminale, con memoria persistente, routing dei modelli e strumenti integrati sia la direzione in cui sta andando l'industria. Lo stack che vi ho mostrato oggi è un'implementazione precoce, onesta, a volte frustrante di quel futuro.
Funziona. Ha spigoli vivi. E migliora ogni settimana.
Grazie.