Torras.ai

He estat treballant amb un client en un nou projecte de programari. Hem dedicat temps a parlar del problema, entendre el flux de treball i dissenyar què havia de fer el sistema final.

En alguns moments em vaig preguntar si avançàvem massa a poc a poc. En tecnologia és fàcil sentir que cada setmana dedicada a pensar és una setmana perduda. Algú altre pot llançar-se abans. El mercat pot canviar. L’oportunitat pot desaparèixer.

Aleshores va passar una cosa inesperada.

Quan vam estar preparats per construir, les eines havien canviat. Podia treballar amb Codex utilitzant GPT-5.6 Sol, connectar-lo a Chrome, permetre-li operar aplicacions d’escriptori mitjançant Computer Use i donar-li accés a una part més gran de l’entorn on es fa la feina real. Tasques que abans haurien requerit integracions a mida, molt codi d’interfície i nombrosos passos manuals es van tornar molt més directes.

Havíem començat més tard. Però, de sobte, semblava possible acabar abans.

Sona contradictori. També és una bona descripció del moment tecnològic que estem vivint.

Per què la segona nau espacial arriba primer

Imaginem que la humanitat vol arribar a un planeta llunyà.

Podríem llançar avui una nau espacial utilitzant el millor sistema de propulsió disponible. Començaria el viatge immediatament i obtindria un avantatge valuós.

Però suposem que esperem deu anys. Durant aquest temps, la tecnologia de propulsió millora de manera espectacular. Llancem una segona nau que viatja molt més de pressa que la primera. L’avança en algun punt entre la Terra i la destinació i arriba al planeta anys abans.

La primera nau va sortir primer. La segona va arribar primer.

No és només un experiment mental de ciència-ficció. S’ha estudiat com el càlcul d’espera, també descrit com el parany d’incentius del progrés. La pregunta és si convé més sortir amb la tecnologia disponible avui o esperar una tecnologia més ràpida que pugui reduir el temps total fins a la destinació.

Un estudi posterior va ampliar el càlcul als viatges relativistes i el va aplicar a possibles missions interestel·lars. La pregunta central era la mateixa: podria una nau llançada més tard avançar una missió anterior i arribar primer?

La lògica bàsica es pot expressar de manera senzilla:

Un llançament posterior guanya quan el temps que estalvia la nova tecnologia és superior al temps dedicat a esperar-la.

Aquest és el càlcul d’espera de la IA.

El programari ara té tecnologia de propulsió

Durant gran part de la història del programari, començar abans solia crear un avantatge durador. Encara que les eines milloressin durant el projecte, l’equip que ja entenia el problema, havia escrit el codi i havia arribat al mercat acumulava alguna cosa difícil de superar.

Aquesta suposició és cada vegada menys fiable.

La IA no es limita a accelerar una mica les tasques de programació existents. Està canviant quines parts d’un projecte s’han de programar. Un agent de programació capaç pot inspeccionar un repositori, entendre’n les convencions, editar diversos fitxers, executar proves, diagnosticar errors i verificar el resultat. La connexió amb Chrome li permet treballar amb llocs web i amb el context de sessions iniciades al navegador. Computer Use amplia aquest abast a les aplicacions gràfiques quan les eines de línia d’ordres i les integracions estructurades no són suficients.

Cadascuna d’aquestes capacitats canvia l’economia de la implementació.

Una integració que abans requeria una API, un flux d’autenticació, un procés de sincronització, gestió d’errors i una interfície pròpia pot començar ara amb un agent que utilitza l’aplicació existent. Una funcionalitat que abans exigia setmanes de programació es pot convertir en una tasca ben definida, completada i provada en pocs dies. Un prototip que hauria estat massa car de justificar pot ser prou econòmic per construir-lo simplement per aprendre.

La nova nau no només és més ràpida. Pot necessitar menys infraestructura per arribar a la mateixa destinació.

Pensar formava part del viatge

Hi ha una diferència important entre començar el projecte i començar la implementació.

Les converses amb el meu client no eren una espera passiva. Estàvem identificant la destinació real. Decidíem quins problemes importaven, quins passos es podien automatitzar, on calia mantenir el criteri humà i com seria un resultat útil.

Aquest coneixement no va quedar obsolet quan la tecnologia va canviar. Es va tornar més valuós perquè les noves eines hi podien actuar més de pressa.

Si haguéssim començat a programar immediatament, podríem haver incorporat supòsits a l’arquitectura abans d’entendre el flux de treball. També podríem haver creat mecanismes a mida per a problemes que les noves eines d’IA ara poden resoldre directament. Començar abans hauria produït més codi, però no necessàriament un resultat més aviat.

Això ens porta a un principi que considero cada vegada més adequat per als projectes d’IA:

Comença a aprendre aviat. Compromet-te tard.

Comença tan aviat com sigui possible a descobrir les necessitats del client, mapar els processos, preparar les dades, analitzar els riscos i definir les mesures d’èxit. Aquestes activitats aclareixen la destinació i acostumen a conservar el seu valor.

Cal ser més prudent amb els compromisos grans, rígids i dependents d’una tecnologia concreta. Quan les capacitats subjacents avancen ràpidament, una arquitectura dissenyada massa aviat es pot convertir en la nau lenta que més endavant avança un sistema més senzill.

La primera nau no sempre és inútil

Hi ha una interpretació temptadora però perillosa del càlcul d’espera: no construir mai res perquè sempre apareixerà una eina millor.

Aquest és el parany dels incentius.

Si seguim aquesta lògica per sempre, cap nau no abandona mai la Terra. Sempre hi haurà un altre model, un altre framework i una altra capacitat a l’horitzó.

Els primers sistemes també poden crear valor encara que finalment siguin superats. Un prototip pot revelar un requisit ocult. Un flux manual pot generar exemples d’entrenament. Un llançament limitat pot crear confiança entre els usuaris. Una integració imperfecta pot descobrir el veritable coll d’ampolla operatiu.

En aquest sentit, la primera nau pot enviar informació valuosa de tornada a la Terra.

L’error no és llançar-se aviat. L’error és tractar cada primer llançament com si fos el vehicle definitiu.

Durant períodes de canvi ràpid, les primeres versions s’han de dissenyar com sondes: petites, reversibles i construïdes per produir coneixement. Ens han d’ajudar a decidir què mereix un compromís més gran. La nau generacional ve després.

Un càlcul d’espera pràctic per a projectes d’IA

No podem predir el ritme exacte del desenvolupament de la IA, però sí que podem formular preguntes millors abans de comprometre’ns amb una implementació:

• La destinació és clara? Si el problema del client continua sent imprecís, una tecnologia millor no salvarà el projecte.
• A quina velocitat millora la tecnologia que el fa possible? Esperar és més rellevant quan una capacitat que falta es torna clarament més barata, fiable o fàcil d’integrar.
• Què podem aprendre ara? Les entrevistes, els prototips, els experiments i la recopilació de dades poden generar progrés sense lligar-nos a una arquitectura.
• Fins a quin punt és reversible la decisió? Un prototip petit és fàcil de substituir. Una gran plataforma a mida, una migració o un contracte de diversos anys no ho són.
• Mesurem l’esforç o l’arribada? Començar abans el desenvolupament pot augmentar la quantitat de feina feta i, al mateix temps, retardar el moment en què el client obté el resultat desitjat.

L’última pregunta és la més important. Els equips de programari mesuren de manera natural l’activitat: requisits escrits, tasques tancades, integracions completades i línies de codi publicades. Als clients els importa l’arribada.

El flux de treball s’ha tornat més ràpid? Han disminuït els errors? Han augmentat els ingressos? Les persones han deixat de fer tasques que un sistema podia assumir? L’empresa ha obtingut una capacitat que abans no tenia?

Un projecte posterior que assoleix aquests resultats primer és el projecte més ràpid.

Competir amb una nau que encara no s’ha enlairat

La realitat incòmoda és que cada producte d’IA competeix ara, en part, amb la tecnologia futura.

Un equip pot dedicar un any a construir una funcionalitat especialitzada i, després, veure com un model d’ús general adquireix la mateixa capacitat. Una interfície dissenyada amb cura pot deixar de ser necessària quan un agent pot operar l’aplicació original. Una capa d’integració complexa pot perdre valor quan les eines es poden moure de manera segura entre sistemes en nom de l’usuari.

Això no vol dir que les empreses de programari hagin de deixar de construir. Vol dir que han de construir allà on el valor és més durador: context propi, relacions amb els clients, fluxos de treball de confiança, distribució, coneixement del sector, sistemes d’avaluació i una comprensió precisa del resultat.

La implementació ha de ser prou modular per substituir-ne el motor quan n’aparegui un de més ràpid.

En el meu projecte amb el client, començar més tard no volia dir no fer res. Volia dir que, quan finalment ens vam enlairar, teníem una destinació més clara i una nau molt més ràpida.

Aquesta és l’oportunitat que crea el càlcul d’espera de la IA. L’objectiu no és esperar tant com sigui possible, ni tampoc construir tan aviat com sigui possible.

És reconèixer el moment en què esperar deixa d’escurçar el viatge i comença a retardar-lo.

Comença a aprendre aviat. Mantén petits els primers experiments. Conserva allò que és durador. Retarda les decisions irreversibles. I quan la tecnologia sigui prou capaç i la destinació sigui clara, llança’t.

En un món de tecnologia accelerada, qui es mou primer no sempre és qui arriba primer.