Da YC ad AWS: Tusk trasforma il traffico di produzione in test basati sull’IA su AWS

Il codice generato dall’IA sta rapidamente rimodellando lo sviluppo dei software. Ciò che prima necessitava di giorni ora si ottiene in ore e ciò che richiedeva un team ora può sempre più essere realizzato da singoli individui. Il problema? Viene generato più codice che mai. Questo significa più richieste pull, più casi limite e più pressione sui team di ingegneri. Il tempo risparmiato nella scrittura vale poco se viene semplicemente assorbito dall’aumento dei requisiti in materia di garanzia della qualità, una responsabilità che ricade sempre più spesso su chi crea il software.

Tusk, una startup pionieristica e alumni di Y Combinator (YC) , sta aiutando le aziende a prevenire bug che altrimenti sarebbero trascurati sia dagli agenti di programmazione che dagli umani, grazie a test basati su traffico reale di produzione e abilitati dall’IA. Utilizzando modelli di fondazione (FM) ad alte prestazioni su Amazon Bedrock, Tusk segnala automaticamente problemi come regressioni impreviste e deviazioni dei contratti API prima della fusione del codice, consentendo ai team di progettazione di concentrarsi su lavori di maggior valore.

Test del software basati sulla realtà, non su ipotesi

Fondata nel 2023 da due laureati della UC Berkeley, Tusk aiuta le aziende a inviare codice di qualità con test generati dall’intelligenza artificiale basati sul comportamento reale degli utenti. “Tusk trasforma il traffico di produzione in test unitari e API realistiche”, afferma Marcel Tan, CEO. “Lo facciamo registrando le tracce mentre gli utenti interagiscono con la tua app nel mondo reale e le riproduciamo in base alle modifiche al codice per trovare e prevenire le regressioni”. Ciò rappresenta un cambiamento significativo nel modo in cui le aziende di tutte le dimensioni possono affrontare i test del codice nell'era dell’IA.

“Se si considerano tutti i migliori team di ingegneri in questo momento, le persone che si occupano del controllo qualità sono in genere anche quelle che stanno sviluppando la funzionalità”, afferma Tan. Il ragionamento alla base di questa tendenza è valido. Questi team dispongono di un contesto migliore con cui affrontare i test in quanto sono quelli che effettivamente aggiornano e ottimizzano il codice. Tuttavia, con l’aumento del volume del codice, la correzione dei bug richiede sempre più tempo. “In passato, il controllo qualità rappresentava circa la metà del ciclo di rilascio. Con gli agenti di codifica di oggi, i migliori ingegneri dedicano il 90% del loro tempo al controllo qualità, il che non è un buon modo di usare il loro tempo”, afferma Tan.

“La maggior parte dei test scritti manualmente o con l’IA non riflette effettivamente il modo in cui gli utenti interagiscono con il prodotto nel mondo reale”, afferma Tan. “Poiché stiamo acquisendo traffico reale, forniamo una copertura su casi limite che altrimenti passerebbero inosservati”. Ciò include i guasti silenziosi dovuti a comportamenti semantici non intenzionali. In queste istanze, un output appare valido ma è funzionalmente errato. Tusk esegue e itera i test che genera e, valutandoli rispetto al traffico di produzione reale, rende più facile rilevare le regressioni che altrimenti sarebbero quasi impossibili da prevedere.

Incubare il successo dalla prima presentazione all’adattamento al mercato del prodotto

Tusk è nato come uno dei primi agenti di codifica disponibili al pubblico. “Volevamo creare un agente di codifica che consentisse ai responsabili dei prodotti, agli ingegneri dei software e persino a persone che non ricoprono un ruolo tecnico di passare da un ticket JIRA a una richieste pull”, afferma Tan. “Siamo stati senza dubbio il primo agente in grado di farlo con una base di codice matura”. Dopo aver presentato questa prima versione del prodotto, l’azienda è stata accettata nel batch YC W24 ed è qui che l'odierno Tusk ha iniziato a prendere forma.

“I tre mesi di YC sono super intensi”, afferma Tan. “È fondamentalmente un bootcamp e in cui in realtà non si pensa a nient'altro che alla startup”. Per Tusk, uno degli aspetti più preziosi dell’esperienza di YC è stato il contatto con altri fondatori, incluso un gruppo più piccolo e più curato all’interno del batch. Questi gruppi si incontravano regolarmente per discutere dei propri obiettivi e progressi. “È davvero motivante perché puoi vedere quanto velocemente le persone possono muoversi nell’arco di tre o quattro giorni. Questo senso di urgenza è radicato nella startup: ti dà un buon DNA”, afferma Tan.

Una lezione duratura dell’incubatore è stata il valore del coinvolgimento diretto con i clienti. “Invece di cercare di intuire di cosa avevano bisogno i nostri clienti, siamo stati incoraggiati a chiedere loro direttamente”, afferma Tan. “Sembra così ovvio, vero? A volte il consiglio più semplice è quello migliore”. In effetti, è stato dopo aver interagito con i clienti che il team di Tusk ha iniziato a ripensare la direzione della propria attività.

“I nostri clienti hanno poi ripetutamente sottolineato che generare più richieste pull significava      creare più lavoro per i loro ingegneri”, afferma Tan. Questo, unito alla crescente disponibilità di strumenti di codifica basati sull’IA, ha fornito un chiaro segnale della direzione intrapresa dal settore. “Scrivere codice stava diventando una merce di consumo”, afferma Tan. “Ci siamo resi conto che in 18     mesi il problema sarebbe stato verificare che il codice funzionasse”. Di conseguenza, il team ha spostato l’attenzione, riorientando l’azienda sui test e gettando le basi per il prodotto che offre oggi.

Libertà di concentrarsi sul cliente, non sui costi

Poco dopo essere uscito da YC, Tusk ha iniziato a collaborare con AWS. L’azienda ha partecipato ad AWS Activate, un programma dedicato al supporto delle startup con competenze tecniche, opportunità di accesso al mercato e finanziamenti sotto forma di crediti AWS. “È stato incredibile”, afferma Sohil Kshirsagar, CTO. “Il team AWS è stato molto reattivo, anche quando eravamo molto più piccoli. Inoltre, la quantità di crediti che abbiamo ricevuto è stata davvero utile. È essenzialmente un investimento che stiamo ottenendo senza capitale”. Ciò è particolarmente utile per le startup che si affidano all’infrastruttura basata sull’IA.

“In qualità di startup pre-IA, i costi del cloud sarebbero limitati a cose come l’hosting e l’archiviazione, ma oggi i modelli linguistici di grandi dimensioni (LLM) diventano il costo principale”, afferma Kshirsagar. “Se non avessimo quei crediti, ogni volta che rilasciamo qualcosa al cliente penseremmo al costo? A come influirà sul nostro processo? Ma ora possiamo davvero risolvere il problema e capire come ottimizzarlo a posteriori”.

Oltre ai risparmi sui costi, AWS Activate ha permesso al team di Tusk di concentrare la propria attenzione su ciò che conta di più. “Ci sono già così tante cose di cui dobbiamo preoccuparci ogni giorno che non vorresti che l’utilizzo o la spesa del cloud fossero tra queste”, afferma Kshirsagar. “Activate ci consente di mantenere la concentrazione sui clienti: qual è il problema che stanno riscontrando, come possiamo risolverlo al meglio? E non necessariamente pensare alle implicazioni sui costi in futuro”.

L’osservabilità in tempo reale incontra l’intelligenza scalabile

Tusk utilizza una combinazione di servizi AWS per l’inferenza e il monitoraggio. “Amazon Bedrock è la nostra principale soluzione di inferenza LLM”, afferma Kshirsagar. “Uno dei principali vantaggi che ci offre è l’inferenza scalabile interregionale, che è importante nella fase iniziale, quando potresti passare da uno a dieci clienti in un paio di settimane e devi aumentare i limiti di tariffa”.

I modelli utilizzati da Tusk in Amazon Bedrock favoriscono la comprensione semantica e la classificazione della regressione. “Quando Tusk analizza le differenze nei risultati di una risposta API , deve considerare che potresti cambiare la struttura dell’API o modificare leggermente la risposta”, afferma Kshirsagar . “Utilizziamo modelli di ragionamento in Bedrock per determinare se tale modifica è una regressione o un aggiornamento previsto in base al contesto della richiesta pull”.

Amazon Bedrock aiuta Tusk a ottimizzare l'utilizzo di modelli e token. “Spesso cambiamo modello a seconda della complessità dell’attività”, afferma Kshirsagar. Se è necessaria una modifica del modello, Amazon Bedrock facilita il processo, spesso semplice e diretto come l’aggiornamento dell’ID del modello.

Oltre il collo di bottiglia del controllo qualità, verso una garanzia end-to-end

Mentre Tusk continua a crescere ed evolversi, la mentalità incentrata sul cliente promossa durante la sua permanenza a New York rimane fondamentale. “Stiamo assistendo a un forte esaurimento tra gli ingegneri”, afferma Tan. “Vogliamo aiutarli a dedicare meno tempo ai test e più tempo a cose divertenti, come progettare soluzioni a problemi complessi o lavorare su funzionalità utili agli utenti”.

Per realizzare questa ambizione, Tusk sta approfondendo la sua collaborazione con AWS sull’uso di Amazon Bedrock. “Mentre continuiamo a offrire nuove funzionalità e raggiungere nuovi clienti, è probabile che il nostro utilizzo di Amazon Bedrock cresca in modo esponenziale”, afferma Kshirsagar. “Abbiamo anche parlato con AWS della possibilità di perfezionare i modelli o di creare e addestrare i nostri modelli su istanze EC2 di AWS Trainium.”

“Abbiamo intenzione di diventare la piattaforma di test tutto in uno”, afferma Tan. “Copriremo in modo intelligente tutti i principali tipi di software di test su cui le aziende fanno affidamento: test di unità, integrazione (API) e test end-to-end. Ciò consentirebbe a Tusk di funzionare come un tecnico addetto ai test di intelligenza artificiale a livello di personale che chiunque può assumere, anche una startup composta da una sola persona, per il controllo di qualità di qualsiasi modifica al codice e richiesta pull creata. Questa è la visione definitiva.”