In difesa del piccolo studio di IA
Perché lo sviluppo di IA guidato dai fondatori e il piccolo studio di IA battono la scala nel rilasciare applicazioni di IA: gusto, responsabilità, velocità e la disciplina del dire no.
Di Vitor Lima
La cosa più onesta che puoi dire sulla maggior parte dei prodotti di IA è che nessuno era davvero responsabile di essi. Lo si sente nelle cuciture: una casella di chat imbullonata a una dashboard, un pulsante "riassumi" che produce le stesse quattro frasi insipide qualunque cosa gli dia in pasto, una pagina di impostazioni con undici interruttori di modello che un product manager ha vinto una battaglia per includere. Questi non sono prodotti che hanno perso contro un concorrente. Hanno perso contro il proprio organigramma. Questa è la difesa del piccolo studio di IA — dello sviluppo di IA guidato dai fondatori come scelta deliberata, non una fase da cui si esce crescendo.
Costruiamo applicazioni di IA per vivere, come studio di due persone. Non è un vincolo di cui ci scusiamo. È il motivo per cui il lavoro è buono. Ciò che segue non è nostalgia per le startup nel garage. È un'affermazione su dove i prodotti di IA si rompono e chi è posizionato per impedirne la rottura.
Il gusto è un vantaggio del piccolo team, e l'IA lo ha reso più grande
Prima dei modelli generativi, il gusto nel software era per lo più layout e testi. Potevi rilasciare qualcosa di semplicemente competente e gli utenti si adattavano. L'IA ha cambiato la posta in gioco perché l'output del modello è la superficie del prodotto. Quando la tua app scrive, suggerisce, riassume o decide, migliaia di piccole decisioni di giudizio trapelano direttamente all'utente: tono, lunghezza, quando restare in silenzio, quando ammettere l'incertezza, come appare persino una "buona" risposta per questa persona proprio ora.
Quelle decisioni non sopravvivono a un comitato. Vengono mediate fino a diventare poltiglia.
Con Youp, la nostra app di journaling con IA, il lavoro più difficile non è mai stato l'impianto idraulico del modello. È stato decidere cosa l'app non dovesse dire. Un compagno di journaling che accoglie un ingresso difficile con positività squillante è peggiore di uno che non dice nulla. Quindi abbiamo speso il nostro sforzo sulla moderazione: lunghezza della risposta, quando una riflessione dovrebbe essere una singola frase silenziosa, quando la mossa giusta è non chiedere nulla. Questa è una decisione di gusto, e resta coerente solo perché una o due persone tenevano l'intera cosa in testa ed erano disposte a difendere un "no".
Da ricordare: Per i prodotti di IA, il gusto non è decorazione. È la specifica. Se la persona con gusto siede a tre livelli di distanza dal prompt, dal flusso di token e dallo stato vuoto, il suo gusto non raggiunge mai l'utente. In un piccolo studio, la distanza è zero.
Responsabilità: chi ha scelto il modello risponde anche al ticket
I grandi team sono organizzati per dividere la responsabilità, che è esattamente la forma sbagliata per sistemi che falliscono in modi sfumati e trasversali. Un campo allucinato, un picco di latenza sotto carico, un passo di retrieval che restituisce silenziosamente nulla — nessuno di questi rispetta i confini dei team. Vivono nel divario tra "il team del modello", "il team della piattaforma" e "il team dell'app". I divari sono dove nessuno sente il dolore.
MadaiOps, la nostra app per ordini crypto e operazioni di trading, rende tutto ciò concreto. Piazza, instrada e monitora ordini attraverso gli exchange in tempo reale. Il tasso di fallimento tollerabile per "il mio ordine è davvero passato" è più o meno zero. Non puoi costruire questo con una responsabilità diffusa, perché l'affidabilità non è una funzionalità che aggiungi. È un migliaio di decisioni difensive su ritentativi, idempotenza, esecuzioni parziali e cosa mostrare a un utente quando un exchange mente sul proprio stato. La persona che scrive la logica di instradamento deve essere la stessa persona che sente il terrore di un ordine bloccato alle 3 di notte. Quando sono persone diverse, la cucitura tra loro diventa il disservizio.
Da ricordare: Rilascia l'organigramma e rilasci le sue cuciture. Uno studio dove le stesse mani toccano il prompt, la logica di ritentativo e il canale degli incidenti produce sistemi che falliscono meno e si riprendono più in fretta — non perché le persone sono più intelligenti, ma perché nessuna responsabilità cade in un divario.
La velocità è reale, ma la parte interessante è il tipo di velocità
Tutti sostengono che i piccoli team si muovono in fretta. La versione pigra di questo è vera e noiosa: meno riunioni, nessuna catena di approvazioni. La versione interessante è che lo sviluppo di IA premia un tempo specifico che i grandi team non possono strutturalmente eguagliare.
Costruire con i modelli è empirico. Non sai come si comporta un prompt, una finestra di contesto o un ciclo di uso di strumenti finché non lo esegui contro input reali. Il ciclo centrale è: formulare un'ipotesi, cambiare una cosa, guardare gli output reali, rivedere il proprio modello mentale. I team che vincono eseguono quel ciclo molte volte al giorno con il vero decisore al posto di comando.
Una grande organizzazione trasforma ogni iterazione in un ticket, uno sprint, una revisione. Quando il feedback atterra, la persona che aveva l'ipotesi ha perso il filo. Uno studio comprime l'ipotesi-verso-osservazione a minuti. Ecco perché il nostro primo lavoro su Linea — automazione dei flussi di lavoro nativa nell'IA, attualmente in beta privata — è rimasto in un ciclo di prototipazione stretto anziché in una roadmap. Il comportamento degli agenti è troppo emergente per pianificarlo su un diagramma di Gantt. Lo costruisci, lo guardi fare qualcosa di stupido, e correggi il ragionamento, ancora e ancora, senza passaggi di consegne che mangiano il ciclo.
Il compromesso, detto onestamente
Questo tipo di velocità ha un costo reale. Non scala aggiungendo persone, e dipende da un paio di individui che restano profondamente nel contesto. Questo è un rischio genuino, e fingere il contrario sarebbe disonesto. Lo accettiamo perché per i prodotti di IA l'alternativa — un processo che sopravvive al ricambio ma diluisce il giudizio — produce software peggiore. Preferiamo essere piccoli e coerenti che grandi e mediati.
Dire no è l'intera disciplina
La patologia definitoria dei prodotti di IA in questo momento è l'incapacità di dire no. Ogni modello può fare un po' di tutto, quindi ogni roadmap si gonfia fino a includere tutto. Il risultato sono prodotti ampi, superficiali e dimenticabili: un elenco di funzionalità dove dovrebbe esserci un punto di vista.
La leva di un piccolo studio è il "no" credibile. No agli interruttori di modello su cui la maggior parte degli utenti non può ragionare. No a un chatbot in un prodotto che non dovrebbe averne uno. No a rilasciare una capacità che non possiamo rendere affidabile, perché una funzionalità di IA instabile è peggio di nessuna funzionalità. Insegna agli utenti a non fidarsi di te, e quella fiducia non torna indietro. Questo non è ascetismo. È il riconoscimento che, nei prodotti di IA, la superficie è una responsabilità. Ogni capacità che esponi è una promessa sulla qualità che ora devi mantenere attraverso uno spazio di input illimitato.
Da ricordare: L'artefatto più prezioso che un piccolo studio produce è spesso l'elenco delle cose che si è rifiutato di costruire. Quell'elenco è la spina dorsale del prodotto. I grandi team faticano a mantenerne uno, perché dire no a una capacità di solito significa dire no a un collega — una conversazione più difficile che rilasciare la versione mediocre.
Cosa questo non significa
Sarebbe facile chiudere con "piccolo buono, grande cattivo". Alcune cose hanno genuinamente bisogno di scala: l'addestramento dei modelli di frontiera, infrastrutture su scala planetaria, domini regolamentati dove il personale compra tracce di audit e difendibilità legale. Uno studio non è la forma giusta per quelle, e non fingiamo di esserlo.
Ma lo strato in cui lavoriamo — progettare e rilasciare applicazioni sopra modelli che già esistono — è proprio dove la scala smette di aiutare e comincia a diluire. Lì il collo di bottiglia non è la potenza di calcolo o il personale. È il giudizio coerente applicato instancabilmente a un migliaio di piccole decisioni, tenuto da persone abbastanza vicine al lavoro da sentirne ognuna.
Questa è l'intera tesi. Non che siamo più economici o più grintosi, ma che il mezzo premia la concentrazione del giudizio, e un piccolo studio guidato dai fondatori è la forma più concentrata che il giudizio possa assumere. Quando il modello può fare qualsiasi cosa, la cosa scarsa è qualcuno che decide — con gusto, e responsabile del risultato — cosa dovrebbe fare, e più spesso, cosa non dovrebbe fare.