Un piccolo team, un problema difficile e uno strumento che ci permette di pubblicare software senza test. Questa è Meticulous.
In Meticulous non scriviamo test.
Almeno non per il frontend. Facciamo refactoring liberamente, aggiorniamo le librerie senza esitare e pubblichiamo nuove funzionalità più o meno nel tempo che serve per scriverle. I bug vengono intercettati altrove.
Voglio raccontarti come sono finito qui e perché penso che sia importante.
Il colloquio
Un amico mi ha segnalato a una startup finanziata da Y Combinator con cinque ingegneri. Ero in Bloomberg, non avevo intenzione di andarmene, ma la descrizione era abbastanza interessante da convincermi ad affrontare il processo di selezione.
Il processo è stato lungo:
- 2 colloqui tecnici di livello LeetCode hard
- 2 colloqui di system design
- da 3 a 5 colloqui comportamentali, a seconda di come si contano le «walking chat»
Ogni problema sembrava più difficile del precedente. Alla fine ero meno preoccupato di ricevere un’offerta e più curioso di sapere chi altro fosse sopravvissuto.
Considero i colloqui una conversazione a due vie. L’azienda valuta te, ma anche tu dovresti valutare l’azienda.
Voglio davvero lavorare con queste persone?
Ho ricevuto l’offerta e per poco non ho detto di no.
In Bloomberg stavo bene. Avevo appena ottenuto un progetto trasversale a più team, divertente e probabilmente positivo per la mia carriera. Avevo già accettato un master part-time all’Imperial e la startup aveva chiarito che frequentarlo mentre lavoravo non sarebbe stato realistico. Il ritmo era diverso.
E, a essere sincero, non avevo mai scritto codice frontend. Ero davvero l’ingegnere giusto per lavorare alla «rivoluzione dei test frontend»?
Quindi cosa mi ha fatto cambiare idea?
Penso alla carriera come a una ricerca di moltiplicatori. Una startup con cinque ingegneri, clienti come Notion e un problema che nessuno aveva risolto rappresentava una traiettoria esponenziale, e non capita spesso di poter salire su una di quelle.
Ho chiesto al CTO di mostrarmi la roadmap. Volevo vedere i problemi concreti che affrontavano ogni giorno. Per la maggior parte non esisteva una soluzione nota. Era proprio quello il punto. Bloomberg era stata una grande sfida. Meticulous sembrava contenerne molte, tecniche e non.
Ho accettato.
Cosa fa Meticulous
Immagina uno strumento che ti mostri ogni differenza introdotta dalle tue modifiche nell’applicazione. Ogni snapshot, ordinato e raggruppato. Niente da scrivere. Niente da mantenere. Nessuna pipeline inaffidabile.
Il buono, il cattivo: tutto viene rilevato.
Questa è Meticulous.
Quando sono arrivato non l’avevo ancora capito fino in fondo. Ho iniziato a lavorare sul frontend e controllavo Meticulous dopo ogni commit. I risultati erano… nella norma. Non stavo introducendo bug. Perlopiù confermavano ciò che pensavo di aver appena costruito.
Poi, un giorno, Meticulous ha segnalato che una mia modifica aveva spinto una finestra modale completamente fuori dallo schermo.
Non avevo toccato quel flusso. Non me ne sarei mai accorto lavorando in locale. Avrebbe rotto silenziosamente, in produzione, un percorso importante dell’applicazione.
Quello è stato il momento decisivo.
Con abbastanza test manuali puoi individuare regressioni di questo tipo. Puoi scrivere test su test e inseguire per sempre la copertura. Ma perché farlo, in un mondo in cui esiste questo strumento? Non scriviamo una sola riga di test frontend e la velocità con cui pubblichiamo è limitata soltanto dalla velocità con cui riusciamo a scrivere la funzionalità stessa.
Non abbiamo paura di aggiornare le librerie. Non abbiamo paura di refactoring estesi. Abbiamo riscritto interi flussi di eventi nei nostri componenti senza aggiungere un solo test. (storia vera)
Prima: 5 minuti per scrivere una funzionalità, 15 minuti per scrivere e mantenere i relativi test. Ora: 5 minuti per scrivere la funzionalità, 1 minuto per leggere ciò che Meticulous mi mostra, poi si pubblica.
E non riguarda soltanto noi. Abbiamo raccolto casi di studio con LaunchDarkly, Notion ed Engine, e rappresentano solo una piccola parte delle aziende che stanno abbandonando i test frontend tradizionali. Il segnale più forte, però, non sono i casi di studio: è il fatto che gli ingegneri che hanno usato Meticulous continuano a portarlo nell’azienda successiva in cui lavorano.
Due cose hanno cambiato il mio modo di pubblicare software
- Gli agenti: non mi è mai piaciuto scrivere CSS, Tailwind o la zuppa di markup dei frontend moderni. Ora gli agenti lo fanno per me.
- Meticulous: il codice è automatizzato, ma serve comunque un modo affidabile e verificabile per sapere se funziona.
Penso che molte persone sottovalutino il secondo punto.
Se la tua unica rete di sicurezza sono test scritti da un altro sub-agente — o, peggio, dallo stesso agente che ha scritto la modifica — non hai davvero una rete di sicurezza. Hai un circuito di feedback che parla con se stesso. Meticulous è esterno. Esegue l’applicazione e ti dice cosa è cambiato, indipendentemente da chi ha scritto il codice.
È anche qui che si nasconde il problema della revisione. Le nuove funzionalità producono già pull request lunghe. Se devi anche leggere centinaia di righe di nuovi test per ognuna, moltiplicate per un qualche coefficiente legato ai cicli di revisione, hai reso la code review assurda. Togliere i test dal processo è stato il miglior guadagno in termini di tempo di revisione che abbiamo trovato.
Dopo quasi un anno
Meticulous è divisa più o meno tra un team di prodotto e uno di crescita. Quasi metà degli ingegneri lavora sul prodotto, ampliando ciò che riusciamo a coprire: più framework frontend e, da quest’anno, una copertura end-to-end che include anche le modifiche al backend.
Io lavoro nel team di crescita. È un ruolo simile a quello di un FDE, ma con una particolarità: aiutiamo i clienti a iniziare a usare il prodotto e spesso questo significa incontrare un problema di stack frontend o di scala che il prodotto non supporta ancora, per poi integrare la soluzione nel prodotto principale. La domanda interessante è sempre la stessa: come possiamo generalizzare questa soluzione affinché ne tragga beneficio ogni utente di Meticulous?
Ogni cliente ha un referente tecnico e uno commerciale. Lavoro a stretto contatto con le vendite, cosa che mi ha sorpreso. I problemi sul lato commerciale sono diversi da quelli dell’ingegneria: più sfumati, meno definiti. Richiedono però molto pensiero strutturato, e mi è piaciuto poterli conoscere da vicino.
In Meticulous la pianificazione ha un orizzonte breve e nasce dal basso. Molto di ciò che pubblichiamo parte da ingegneri che realizzano un prototipo con un agente, dimostrano che funziona e lo propongono. Scriviamo molto. Il nostro Notion — che, non a caso, è uno dei nostri clienti — è pieno di RFC e documenti di idee. Scrivere costringe un pensiero ancora incompleto ad assumere una forma reale, ed è lì che inizia il brainstorming migliore.
Proviamo ogni stack per agenti. Alcuni di noi vivono in Claude Code, altri in Codex, la maggior parte in Cursor. Abbiamo reso pronti per la produzione alcuni modi in cui gli agenti possono usare Meticulous direttamente, così da validare le proprie modifiche al frontend attraverso un segnale esterno, invece di affidarsi ai propri test per correggere i propri compiti.
Conclusione
Stiamo assumendo. Se hai letto fin qui, potresti voler candidarti.
Se il tuo team è interessato a provare Meticulous, puoi prenotare una demo.
Io torno al lavoro, così quando deciderai di provarlo l’esperienza sarà la migliore che possiamo offrirti.
E sì, eliminate tutti i vostri test.