Le riunioni registrate sono una risorsa di conoscenza poco sfruttata. Sono difficili da consultare, richiedono tempo per essere riviste e restano isolate nei drive dei vari team: così, informazioni preziose spesso passano inosservate.
Durante un hackathon di un solo giorno, un team di tre persone ha creato Callombia. È una piattaforma interna che trascrive, etichetta, riassume e suddivide automaticamente le chiamate registrate in clip, raccogliendole in un repository consultabile in stile YouTube e accessibile da tutte le sedi nel mondo.
La soluzione, interamente realizzata con Codex, utilizza la ricerca semantica basata sugli embedding di OpenAI e sulla similarità del coseno per individuare i momenti rilevanti anche senza parole chiave esatte, oltre a un chatbot RAG e a un sistema di notifiche.
Ciò che un tempo avrebbe richiesto settimane è stato realizzato in sette ore, dimostrando come lo sviluppo AI-native con agenti di programmazione come Codex possa ridurre drasticamente il ciclo di sviluppo del prodotto e generare un autentico valore aziendale dagli hackathon interni.
Se siete come me, raramente avete il tempo (o la capacità di concentrazione) per riascoltare le riunioni registrate. Spesso il motivo è che bisogna rovistare nei drive disordinati dei team, saltare convenevoli poco interessanti e cercare di ascoltare davvero mentre si inviano email e messaggi.
Ma forse non deve per forza essere così? E se creassimo qualcosa in grado di trasformare completamente le riunioni registrate? È da questa idea che è nato il nostro recente progetto per l’hackathon.
In un solo giorno, 50 persone dei nostri team di ingegneria, delivery e operations hanno affrontato diversi problemi emersi in azienda: dalla gestione delle assunzioni su larga scala alla semplificazione della creazione degli SoW, fino alla valutazione dello stato dei progetti, alla generazione live di prototipi e all’individuazione di informazioni nelle riunioni registrate.
Durante questo hackathon basato su Codex abbiamo creato Callombia. Callombia è lo YouTube della nostra azienda: trasforma ogni chiamata in una risorsa viva e consultabile. Ogni chiamata viene automaticamente trascritta, etichettata e riassunta, poi suddivisa in clip tematiche e aggiunta a un repository organizzato per canali (clienti) e argomenti (ambiti di specializzazione nell’IA). In questo modo, ogni membro del team a Londra, Edimburgo, Singapore o in Australia può accedere immediatamente ai momenti delle chiamate che gli interessano.
Un’interfaccia intuitiva e coerente con il brand semplifica la scoperta dei contenuti, mentre la ricerca semantica e, naturalmente, un chatbot IA RAG aiutano le persone a trovare esattamente ciò che cercano. Grazie a un sistema di notifiche, i colleghi possono inoltre seguire determinati argomenti ed essere avvisati quando vengono pubblicate nuove clip pertinenti.
Ma la cosa più interessante di Callombia non è il prodotto, né il premio di 2.000 sterline per aver vinto l’hackathon (piccolo vanto), bensì il fatto che siamo riusciti a creare tutto questo in sole sette ore, con due ingegneri e un responsabile delivery. Un anno fa non sarebbe stato possibile. I progressi degli agenti di programmazione hanno accelerato enormemente l’intero processo di sviluppo del prodotto e questo hackathon si è rivelato un ottimo banco di prova per esplorarne i limiti irregolari. Quindi, come abbiamo utilizzato Codex?
Anziché limitarci a scrivere una lunga serie di requisiti, siamo partiti condividendo, sotto forma di prompt, la nostra visione comune del problema e di Callombia. Mantenendoci volutamente generici, abbiamo lasciato lavorare il modello e gli abbiamo dato spazio per pensare in modo creativo:
Dopo dieci minuti di confronto, abbiamo attivato la modalità Plan per definire meglio i requisiti e orientare la parte tecnica dello sviluppo. La modalità Plan è un po’ come rispondere alle domande di quell’amico irritante che, per fortuna, ha già considerato ogni possibile scenario. Dopo aver concordato aspetti come il numero di video, la scelta tra ricerca semantica o per parole chiave e l’architettura da usare, Codex ha creato un file Markdown che è diventato la base del progetto.
Definito il piano, il passo successivo era creare i componenti essenziali per far funzionare davvero Callombia. Questo significava creare una pipeline capace di trasformare le chiamate registrate in risorse consultabili:
Acquisire video e trascrizioni,
Suddividerli in momenti significativi,
Arricchirli con sintesi e tag,
Renderli disponibili tramite API utilizzabili dal frontend.
Ed si è concentrato soprattutto sulla conversione delle registrazioni e delle trascrizioni grezze in un formato utilizzabile, mentre Nico ha lavorato sul livello di recupero che avrebbe reso quei momenti facili da trovare. Con Codex, entrambi hanno potuto configurare i modelli di dati, gli script di estrazione e l’infrastruttura backend molto più rapidamente di quanto avremmo potuto fare manualmente. Il risultato era molto più di una trascrizione allegata a un video. Avevamo dei momenti: la sezione su Tesco, l’aggiornamento strategico, la discussione sulle assunzioni, quei 90 secondi precisi di una chiamata che qualcuno vuole davvero guardare.
È nel livello di recupero che le cose si sono fatte particolarmente interessanti. Volevamo che una persona potesse digitare qualcosa come “financial performance,” “Tesco roadmap,” o “conversation evals” e arrivare alle clip più pertinenti, anche se quelle esatte parole non erano mai state pronunciate. A questo scopo abbiamo creato segmenti contenenti timestamp, sintesi, testo della trascrizione e metadati. Con un’architettura chiara in mente e un grande aiuto da parte di Codex, abbiamo riunito argomento, sintesi e trascrizione in un unico input e usato il modello text-embedding-3-small di OpenAI per generare gli embedding di ciascun segmento. Abbiamo archiviato questi embedding nel database e usato la similarità del coseno per confrontare la query dell’utente con ogni segmento, ottenendo così un livello di recupero semantico anziché una semplice ricerca per parole chiave.
Questo approccio si è dimostrato estremamente accurato e ha conferito al prodotto quel senso di «magia» durante la demo dell’hackathon. Allo stesso tempo, sapevamo che questo approccio non avrebbe retto per sempre con l’aumento dei video, perché confrontare ogni query con tutti i segmenti sarebbe diventato troppo costoso. Il passo successivo più naturale sarebbe introdurre strategie di recupero più efficienti, come Hierarchical Navigable Small World, per ridurre il numero di confronti e mantenere bassa la latenza man mano che il corpus cresce. Una volta attivata questa funzionalità, Callombia ha iniziato a sembrare meno una raccolta multimediale e più un sistema di conoscenza.
Come in ogni buon hackathon, anche questa parte ha richiesto diverse iterazioni: i primi confini dei segmenti erano troppo approssimativi, alcuni timestamp andavano perfezionati, certi tag erano troppo generici e i file delle trascrizioni e delle registrazioni non sempre coincidevano perfettamente. Ma è proprio qui che è emerso il valore della soluzione. Codex ci ha permesso di perfezionare rapidamente il sistema, senza restare bloccati nella configurazione e nelle rilavorazioni. Alla fine avevamo un backend capace di gestire clip, estratti e una ricerca semantica davvero utile: è stato allora che Callombia ha iniziato a sembrare un prodotto reale, non più soltanto una demo da hackathon.
Mentre Ed e Nico realizzavano il sistema di acquisizione e il livello di intelligenza, io mi sono occupato del frontend. Usando il nostro template full stack, ho potuto creare rapidamente una prima versione del sito senza scrivere una sola riga di codice. Dopo avergli chiesto di aprire il sito in locale nel mio browser, fornivo semplici commenti per punti per perfezionare progressivamente il design fino al risultato desiderato.
Dopo circa un’ora di scambi, avevo ottenuto un risultato di cui ero piuttosto soddisfatto, pur senza alcuna esperienza di interfacce utente o design. Anche se il prodotto finale non è certo perfetto, è una prima versione più che valida che permette alle persone di comprenderne il funzionamento.
Per essere certi di avere qualcosa di pronto a fine giornata, ci siamo divisi il lavoro. Naturalmente, dopo qualche ora di lavoro semi-indipendente, ciascuno di noi aveva il proprio branch locale con un’infinità di conflitti.
Anziché dedicare il tempo che non avevamo a esaminare e risolvere con cura i conflitti, abbiamo deciso di lasciare Codex libero di operare sui repository e sistemarli autonomamente. Anche se per ora non consiglieremmo questo approccio nello sviluppo di software aziendale, è stato sorprendente vederne l’efficacia in un contesto a basso rischio: ci ha fatto risparmiare molte ore.
L’ultima fase dell’hackathon consisteva nel registrare la demo di Callombia per la giuria. D’istinto avremmo voluto aprire Loom per gestire la registrazione, ma abbiamo pensato che potesse essere un vero banco di prova per Codex, un compito un po’ al di fuori delle sue attuali capacità. Così… abbiamo scritto un prompt, fornito il link al sito di Callombia, aggiunto una registrazione della mia voce sulla piattaforma per sviluppatori di OpenAI e gli abbiamo chiesto di occuparsi del resto.
Il primo tentativo è stato davvero notevole: aveva scritto il copione della demo, registrato lo schermo, aggiunto la mia voce fuori campo e sostanzialmente centrato l’obiettivo. L’unico aspetto che non ci convinceva subito era la sincronizzazione tra voce e registrazione della demo, così gli abbiamo chiesto: “MANDATORY: align the voiceover exactly with what is being shown in the demo. There was misalignment (e.g. on the chat page). Triple check alignment of voiceover and the screen-recorded demo at the end. Match it up through whichever means possible.”
In risposta, Codex ha suddiviso la voce fuori campo e la registrazione in sezioni più brevi, completando il compito in modo quasi impeccabile appena in tempo per le 17:30 e per festeggiare con birra e pizza.
Sappiamo che Callombia risolve un problema comune alla maggior parte delle aziende. In un’azienda in rapida crescita è difficile partecipare a ogni chiamata, ma le perle di saggezza condivise durante questi incontri sono inestimabili. Ora dobbiamo solo portarlo in produzione.
Ma c’è anche una lezione più ampia su cosa significhi essere AI-native e sui vantaggi di mettere competenze ingegneristiche e di prodotto al servizio di problemi comuni. Uscendo dalla routine, collaborando tra team e lavorando in un ambiente moderatamente competitivo, abbiamo ottenuto diverse soluzioni che, con qualche modifica, potrebbero essere messe in produzione. Ripetendo regolarmente questa esperienza, possiamo fare in modo che i nostri processi interni siano efficienti quanto le soluzioni che realizziamo per i clienti.