La majoria dels equips que adopten la programació agentiva traslladen el coll d'ampolla de la generació a la revisió; si no corregeixen el cicle, el guany net de velocitat és gairebé nul.
En entorns de CI a gran escala, amb milions de proves nocturnes i centenars d'enginyers, la tasca de més valor per a un agent és assignar responsables i fer el triatge, no generar codi.
Els resultats útils d'un agent resisteixen l'escrutini i expliquen la causalitat, no es limiten a trobar patrons coincidents.
Dissenyar la capa de recopilació de proves i construcció del context és més important que dissenyar la capa de generació.
La majoria de converses sobre programació agentiva encara parteixen d'una promesa senzilla: escriure més codi i més de pressa.
De vegades, això s'amplia fins a una visió més ambiciosa en què els agents planifiquen la feina, obren PR i despleguen canvis amb una intervenció humana mínima. Però, per a la majoria dels equips d'enginyeria, el valor més evident a curt termini és més concret. Es tracta de reduir el cost de la iteració.
El lliurament de programari no consisteix només a generar codi. Escriure codi és només una fase d'un cicle més llarg que inclou la revisió, les proves, el desplegament i la investigació quan alguna cosa falla. La majoria dels equips que adopten la programació agentiva sense redissenyar el cicle de revisió només desplacen el coll d'ampolla a una fase posterior.
Accelerar només la generació no fa que un equip sigui automàticament més ràpid. Pot limitar-se a traslladar més esforç a la revisió, la verificació i l'assoliment de confiança.
En molts entorns d'enginyeria, la part costosa no és produir un primer esborrany, sinó arribar a tenir prou confiança.
El canvi ha resolt realment el problema o ha millorat el sistema? Ha introduït una regressió en algun altre lloc? La fallada és al codi, a l'entorn, a les proves o en una dependència? La correcció proposada aborda la causa o només el símptoma visible?
Els agents poden ajudar en aquest punt, no perquè substitueixin els enginyers, sinó perquè poden fer una primera anàlisi estructurada de proves desordenades: inspeccionar registres, comparar canvis recents, resumir els senyals rellevants, rastrejar causes probables, executar comprovacions i retornar alguna cosa que una persona pugui examinar.
En molts equips, l'ús d'un agent amb més impacte no és generar codi des de zero. És reduir l'espai de cerca al voltant d'un problema abans que una persona hi dediqui hores manualment.
Això és especialment evident en els fluxos de treball de depuració a gran escala. Imagina una CI nocturna que executa milions de proves en bases de codi modificades per centenars d'enginyers, una realitat per a un dels nostres clients. Quan alguna cosa falla, és difícil determinar-ne l'equip responsable. El problema pot trobar-se al codi de l'aplicació, en una dependència, a l'entorn d'execució de proves o en qualsevol altre punt de la pila. Els registres poden ocupar gigabytes, i el primer equip que detecta el problema no sempre n'és el responsable.
Un flux de treball d'aquest tipus no demana, de manera natural, que un sol agent escrigui la correcció. Està concebut per a un sistema que redueixi ràpidament l'espai del problema.
Un procés útil podria obtenir els registres, seleccionar les proves rellevants, resumir què és important, inspeccionar el codi en un entorn aïllat i produir una anàlisi estructurada de la causa arrel amb una puntuació de confiança, traçabilitat i suggeriments sobre els passos següents. Per generar una puntuació de confiança, un especialista en la matèria avalua el resultat inicial de l'agent. Després, aquesta avaluació s'introdueix en un LLM que actua com a jutge per automatitzar les puntuacions futures sense perdre l'alineament amb el criteri humà.
L'objectiu no és eliminar el criteri dels enginyers, sinó oferir als revisors un punt de partida més sòlid. El triatge de regressions, la revisió de PR, la reparació de proves, la validació de versions i la investigació posterior al desplegament segueixen el mateix patró. Requereixen moltes proves i revisions, i estan plens d'ambigüitat. No demanen que un agent substitueixi el procés d'enginyeria, sinó simplement que ajudi a fer-lo avançar.
Per això, els equips també han d'anar amb compte a l'hora d'avaluar aquests sistemes.
La pregunta equivocada és si un agent pot produir, de manera aïllada, alguna cosa impressionant. La pregunta més encertada és si millora un flux de treball real sense generar friccions en altres punts.
Això implica comprovar si el resultat és prou específic per verificar-lo, si explica la causalitat en lloc de limitar-se a trobar patrons coincidents i si facilita la revisió en comptes de dificultar-la. Una resposta plausible no és el mateix que una resposta útil. A la pràctica, els equips confien en els resultats d'un agent quan resisteixen l'escrutini i ofereixen alguna cosa concreta que es pot comprovar.
La lliçó de fons és que els sistemes agentius útils depenen de molt més que la generació. Depenen de com es recopilen les proves, com es construeix el context, com es comproven els resultats i com es presenta la incertesa al revisor.
Per això és poc probable que el futur immediat de l'enginyeria agentiva faci un únic gran salt cap a l'autonomia total. És més probable que consisteixi en un conjunt de cicles dissenyats amb precisió en què els agents ajudin els equips a inspeccionar, revisar, verificar i perfeccionar la feina, amb menys esforç malgastat entre passos.
Potser és menys espectacular que el relat general sobre l'autonomia, però s'acosta molt més a la manera com s'adopten realment els sistemes útils.