“Altri modelli continuavano a indicare la stessa cosa più e più volte, anche dopo che l'avevamo corretta. Quando abbiamo provato Enter Pro, ha capito quale fosse la causa reale.”

WhyVenv ha creato Kronos, un agente autonomo di risposta agli incidenti per Quackathon, per aiutare gli ingegneri a passare più rapidamente dagli errori di produzione alla causa radice.

Il cercapersone è solo l'inizio

Quando la produzione si interrompe, l'allerta è raramente la parte difficile.

Grafana può dirti che qualcosa è andato giù. I log possono dirti che qualcosa è fallito. Una dashboard può lampeggiare in rosso abbastanza forte da svegliare qualcuno alle 2 del mattino.

Ma dopo questo, inizia il vero lavoro.

Un ingegnere deve comunque aprire i log, comprendere l'errore, cercare nella codebase, indovinare quale funzione sia importante, decidere se il problema è urgente e capire se il passo successivo corretto sia un problema su GitHub, una patch o un'escalation completa.

Quel divario tra il sapere che qualcosa si è rotto e il capire cosa si è rotto è il punto in cui la risposta agli incidenti diventa dolorosa.

È anche il punto in cui Dawood Khan ha trovato l'idea per Kronos.

Dawood ha studiato l'IA, ma dopo l'università si è avvicinato all'ingegneria dei sistemi. Il suo interesse non era astratto. Aveva visto come falliscono i sistemi di produzione, come rispondono i team e quanta investigazione manuale ci sia ancora tra un'allerta e una soluzione.

Durante un evento di Grafana a Hyderabad, il problema è diventato ancora più chiaro. Gli ingegneri descrivevano lo stesso schema: il sistema va giù, qualcuno riceve la chiamata e poi il team inizia il familiare lavoro di tracciamento manuale del guasto.

Quackathon è diventato il momento per costruire qualcosa di diverso. Sviluppato da WhyVenv, Kronos ha ottenuto il Secondo Posto al Quackathon, distinguendosi nella sfida Track 01: Software - The Sentient Workspace per aver trasformato la risposta agli incidenti di produzione in un flusso di lavoro agentico.

Cosa ha costruito WhyVenv

Il progetto di WhyVenv era Kronos, un agente autonomo di risposta agli incidenti creato per la traccia Sentient Workspace di Quackathon.

L'idea era semplice, ma ambiziosa:

Kronos riceve gli errori di produzione, legge i log, recupera il codice pertinente, chiede a un modello di IA di diagnosticare la probabile causa radice e poi decide cosa dovrebbe accadere dopo.

A volte questo significa aprire una segnalazione su GitHub.

A volte, a seconda della gravità del problema, significa tentare una correzione.

Il punto non è solo notificare all'ingegnere che la produzione è interrotta. Il punto è dare all'ingegnere un vantaggio sul lavoro che normalmente segue l'allerta.

Nelle parole di Dawood durante l'intervista, gli avvisi di Grafana rendevano facile sapere quando qualcosa non andava. Il problema era tutto ciò che veniva dopo: trovare cosa avesse causato il problema, dove si trovasse il bug e quale azione dovesse intraprendere il team.

Kronos è stato creato per automatizzare quel livello intermedio.

L'intuizione ingegneristica dietro Kronos

“La parte di cui andavo più fiero era la fase di recupero. Invece di usare solo AST o embedding, abbiamo lavorato a partire dai log di tracciamento, perché è così che gli ingegneri di solito trovano il problema.”

La parte di cui Dawood era più orgoglioso non era la dashboard, l'integrazione con GitHub o persino la diagnosi dell'IA.

Era la fase di recupero.

Molti sistemi di codifica IA cercano di comprendere una codebase attraverso embedding, parsing AST o caricamento di un ampio contesto. Kronos ha preso una strada più vicina al modo di lavorare degli ingegneri: partire dai log di tracciamento e usarli per restringere la ricerca.

Questa scelta è importante.

Quando gli ingegneri eseguono il debug dei guasti di produzione, raramente iniziano chiedendo a un modello di IA di leggere l'intero repository. Guardano l'errore. Seguono lo stack trace. Cercano nel codice con grep. Si spostano dal sintomo alla fonte.

Kronos è stato progettato attorno a questo stesso istinto.

Il sistema utilizza i log come punto di ingresso, recupera il codice che appare più pertinente e solo allora introduce il modello di IA nel flusso di lavoro. Ciò rende il modello meno simile a un oracolo onnisciente e più simile a un revisore che lavora a partire da un pacchetto mirato di prove.

Dawood è stato chiaro sul fatto che l'approccio necessita ancora di perfezionamento prima di poter essere affidabile su larga scala. Ma per la demo ha funzionato. Ancora più importante, ha riflettuto un serio istinto di prodotto: i migliori sistemi di IA non sostituiscono ciecamente il flusso di lavoro ingegneristico. Imparano da come gli ingegneri risolvono già i problemi.

Costruire lo stack di osservabilità con Enter Pro

Kronos doveva funzionare su strumenti che il team non aveva mai utilizzato approfonditamente in precedenza.

Grafana. Prometheus. Loki. Dashboard. Log. Metriche. Avvisi.

Per un team di un hackathon, si tratta di molta infrastruttura da comprendere prima ancora che il prodotto effettivo possa iniziare a funzionare.

È qui che Enter Pro è diventato utile per WhyVenv.

Il team ha utilizzato Enter Pro durante tutto il progetto per la ricerca, il perfezionamento delle idee e il debug. Dawood e i suoi compagni di squadra lo hanno utilizzato per comprendere lo stack di osservabilità, capire come i componenti si incastrassero tra loro e superare i problemi di integrazione quando il sistema non si comportava come previsto.

Un momento in particolare si è distinto.

Il team era bloccato sul motivo per cui i propri avvisi sui dati non arrivassero correttamente. Avevano provato altri modelli di IA, ma Dawood sentiva che alcuni di essi continuavano a girare intorno allo stesso punto anche dopo che il team lo aveva già risolto.

Quando hanno provato Enter Pro, li ha aiutati a identificare la causa reale in modo più diretto.

Questo è il tipo di momento che conta in uno sprint di sviluppo. Non una risposta da demo preconfezionata. Non un suggerimento generico. Una spinta concreta per superare un vero ostacolo.

Per WhyVenv, Enter Pro non è stato solo un luogo in cui generare codice. È stato un modo per ragionare su sistemi sconosciuti abbastanza rapidamente da continuare a costruire.

Due giorni di concentrazione

Dawood aveva pianificato il progetto prima che il team iniziasse lo sviluppo serio.

Sapeva cosa volevano costruire. Aveva pensato all'architettura di base. Aveva un'idea approssimativa di come dovesse essere suddiviso il lavoro.

Poi è subentrato il ritmo effettivo dell'hackathon.

Il primo giorno non è stato solo codice. Il team ha trascorso del tempo insieme, ha parlato, ha scherzato e ha trovato la propria dimensione. Il vero sviluppo è arrivato dopo: uno sprint concentrato in cui hanno diviso il lavoro, cercato informazioni sulle parti sconosciute, implementato il flusso principale e perfezionato il prodotto fino a renderlo solido.

L'architettura è iniziata in modo semplice:

rapporto di crash -> codice pertinente -> diagnosi LLM -> segnalazione o correzione.

Poi ogni parte è diventata più definita man mano che il team costruiva.

Questa semplicità è parte del motivo per cui Kronos è interessante. Non inizia con una teoria complicata di software agentico. Inizia con un flusso di lavoro che ogni ingegnere reperibile comprende: qualcosa si è rotto, trova la causa, decidi cosa fare dopo.

Cosa suggerisce Kronos sugli agenti IA

Kronos non è un chatbot seduto accanto a una codebase.

È più vicino a un agente di flusso di lavoro: un sistema che riceve un segnale dal mondo reale, raccoglie le prove corrette, richiede il ragionamento solo dove il ragionamento è utile e poi indirizza il risultato negli strumenti che gli ingegneri già utilizzano.

Questa distinzione è importante.

Dawood è sensibile ai problemi di costo e controllo relativi ai sistemi di IA. Nell'intervista ha parlato dell'uso dei token, delle chiamate a modelli costosi e dell'importanza di non lasciare che un agente gestisca tutto quando la logica di backend deterministica può svolgere parte del lavoro in modo più efficiente.

Questo è un istinto maturo per qualcuno che costruisce con l'IA nel 2026.

Il futuro degli agenti IA non riguarderà solo l'uso di modelli più potenti. Riguarderà anche il sapere quando non usarli. Quali parti dovrebbero essere codice? Quali parti dovrebbero essere recupero? Quali parti dovrebbero essere ragionamento del modello? Quali parti dovrebbero rimanere sotto la revisione umana?

Kronos, anche come progetto di un hackathon, punta verso questa domanda.

Cosa succede dopo

Il progetto ha ancora domande a cui rispondere prima di diventare pronto per la produzione:

Quanto scala l'approccio di recupero su codebase più grandi?
Come dovrebbero essere calibrate la gravità e l'autonomia?
Quando un agente dovrebbe aprire una segnalazione invece di tentare una correzione?
Quanto contesto è sufficiente affinché un modello possa diagnosticare un incidente reale?
Cosa dovrebbero approvare gli esseri umani prima che qualcosa raggiunga la produzione?

Queste non sono domande da poco. Sono esattamente le domande che rendono Kronos degno di attenzione.

Perché gli incidenti di produzione non scompariranno. L'unica domanda è se ogni risposta debba iniziare con il panico manuale.

Kronos immagina un primo passo diverso: uno in cui il sistema che vede il guasto può anche iniziare a comprenderlo.

Questo è ciò che Enter esiste per supportare.

Non solo codice più veloce. Un passaggio più rapido da un vero punto critico a un prodotto funzionante.

E per WhyVenv, quel passaggio è stato sufficiente per trasformare un doloroso schema ingegneristico in uno dei progetti vincitori di Quackathon.

Esplora Kronos.

Questa storia fa parte della nostra serie Quackathon Builder, in cui analizziamo un progetto alla volta per capire cosa hanno realizzato i creatori con Enter Pro, perché lo hanno costruito e cosa ci dice il loro lavoro sul futuro della creazione di software basata sull'IA. Continuate a seguirci.