Durante gran parte de la historia humana, hemos evaluado la calidad del código mediante la revisión de código: alguien lee lo que escribiste y se asegura de que sea limpio, bien pensado, rápido, comprensible y bien probado. Con los agentes, ese enfoque no escala bien; hay demasiado código para que alguien pueda leerlo. Como resultado, cada vez más de nuestros controles de calidad tienen que ocurrir en el harness, el entorno y el sistema operativo que rodean al agente. Todavía leo y reviso código, pero soy muy deliberado sobre dónde me siento cómodo usando las restricciones como mecanismo de verificación.
La calidad del software ahora depende de las restricciones que establezcas alrededor de tus agentes.
La lista de Guillermo es una buena prueba de si puedes permitirte omitir la lectura. Nota que cada "sí" es en realidad una afirmación sobre lo poco que está en juego: sin usuarios, código desechable, prototipo. Cuando suben las apuestas, algo tiene que leer el código. Si no eres tú en cada diff, entonces tienen que ser las restricciones.
Las restricciones definen lo que el sistema puede hacer al lanzar pruebas y restricciones deterministas contra las propuestas de un agente. Al establecer y mantener estas restricciones, construimos bucles que entregan de manera confiable software de producción de alta calidad, incluso cuando los agentes crean cientos de miles o millones de cambios cada día.
A estas restricciones las llamamos quality gates, y adoptan muchas formas.
Incluyen pruebas unitarias convencionales, pruebas de propiedades y pruebas de aceptación. Incluyen pruebas de mutación, donde generamos variaciones del código, las ejecutamos contra las mismas pruebas y nos aseguramos de que nadie esté colando errores que se nos escapen. Son métricas alrededor de la calidad del código, como la complejidad ciclomática y la longitud de línea, que ayudan a mantener las cosas legibles.
Dos personas pueden estar en desacuerdo sobre si leer el código y aun así coincidir en el mecanismo. Guillermo lo lee. Bob no lee nada de eso. Ambos están describiendo una prueba de obstáculos: la diferencia es solo si hay un humano dentro de ella (no respaldo las demás opiniones de Bob).
Las restricciones también juegan un papel importante en qué propuestas aceptará el sistema y aplicará como cambios de código. Para cuando una propuesta de cambio pasa del intérprete que ejecuta al agente al controlador de agentes y sale a producción, ya hemos hecho suficientes verificaciones sobre ella para confiar en que es seguro publicarla y en que el impacto de su cambio queda perfectamente dentro del alcance del agente.
Un agente puede proponer cualquier cosa. Tus restricciones deciden si una propuesta es lo suficientemente segura, correcta, acotada y útil para que tú y tu equipo la publiquen.
Este modelo ofrece mucho, pero también deja fuera muchas piezas, y esas omisiones merecen reflexión hoy. Un tema es la autonomía: los agentes pueden aplicar bien sus intenciones, pero pueden fallar cuando falta información o cuando lo que intentan hacer es ambiguo. Eso aplica tanto a la tarea en sí como a cómo está parametrizada por el harness, el entorno y otros componentes.
Muchas de las razones por las que los humanos no logran publicar buen código también aplican a lo que los agentes podrían hacer: entornos frágiles que no resisten el estrés generado por scripts, builds no deterministas, permisos faltantes y pruebas débiles. Esto motiva un mejor entorno que brinde a los agentes retroalimentación confiable, permita modos de falla de bajo impacto y haga más fácil construir el éxito de forma progresiva.
El entorno que buscamos es uno donde un agente pueda hacer trabajo real, recibir retroalimentación en la que confíe y fallar sin causar mucho daño.
El otro tema importante es la confianza. No podemos delegar nuestra intención con ingenuidad en algo tan inteligente y robusto como un agente moderno, sin comprobar que sea correcto. Empezamos con confianza, pero tiene que ganarse con esfuerzo.
Algunas restricciones moldean el trabajo antes de que comience. Otras dan retroalimentación mientras el agente trabaja. Otras deciden si su resultado puede siquiera cruzar la frontera de producción.
Hay muchas formas de modelar cómo ponemos una estructura de verificación alrededor de un sistema.
En mi experiencia, ayuda tener un conjunto más amplio, pero elegido intencionalmente, de verificaciones para tus restricciones, en lugar de depender únicamente de las pruebas unitarias. La idea es que cada verificación tenga una responsabilidad distinta, que puede ir desde la seguridad de tipos y el rendimiento hasta el escaneo de seguridad en las etapas finales. La gente también puede definir sus propias restricciones, incluidas reglas de arquitectura que herramientas de linting como ESLint pueden hacer cumplir. Muchas de estas herramientas tienen hooks integrados que pueden usarse para involucrar a agentes, o humanos, cuando algo se rompe.
Por ahora, gran parte de la diferencia entre el resultado útil de un agente y la basura sigue dependiendo de la habilidad del equipo que opera el bucle.
La IA nos da generación de código y velocidad a gran escala, pero esto también puede significar que se vuelva más difícil para los humanos revisar cada uno de los cambios. En su lugar, tienes que ser intencional sobre hacia dónde va su atención. Si pones una verificación humana en un sistema que por lo demás se mueve a velocidad de máquina, no te sorprendas si eso impacta la productividad. La atención humana es escasa y valiosa, así que deberíamos dirigirla de forma proactiva hacia esos problemas más matizados que requieren nuestro juicio. Los humanos que vienen después solo deberían intervenir cuando se rompen las protecciones automáticas de las restricciones.
La "revisión de código" humana en el futuro va a verse muy diferente
La corrección es una dimensión importante, pero puede que te importen otras también, como la mantenibilidad, el rendimiento, la seguridad, la eficiencia y la comprensibilidad. Así como la corrección se descompone en muchos tipos de señales, también lo hace el resto de la calidad. Y aunque importa cuántas restricciones tenemos implementadas, importa más si son lo suficientemente exigentes para cumplir nuestro estándar de calidad y preparación para producción.
La calidad del software no es una métrica única. Piensa en ella como una colección de señales de importancia variable para ti y tu equipo.
La contrapresión se puede implementar a través de muchas herramientas: compiladores que rechazan código inválido, pruebas que fallan, políticas de seguridad que bloquean malas prácticas, CI que se niega a desplegar. Idealmente existe a lo largo de todo el bucle, no como una única revisión al final de todo el trabajo.
El mapa de Dex Horthy del mismo bucle, de Why Software Factories Fail. La caja verde es su argumento de que, por ahora, la revisión humana pertenece de vuelta al bucle en lugar de ser reemplazada por este.
Las restricciones y la contrapresión permiten a los agentes detectar el mal trabajo antes de que sea un problema
¿Qué pasa si no podemos aplicar la restricción porque el volumen de cambios es mayor de lo que nuestras herramientas pueden absorber? Terminamos construyendo una cola y dependiendo de un sistema de verificación que se mueve a velocidad humana. Para escalar, queremos empujar todo lo que podamos hacia el bucle de verificación a lo largo del proceso y no esperar hasta el final. Si podemos escalar dentro de nuestras verificaciones automatizadas, podemos aumentar la velocidad y el rendimiento de todo nuestro sistema de entrega. Si nos quedamos sin espacio en el bucle de verificación, tenemos que hacer una de varias cosas.
Primero, podemos escalar nuestro sistema de verificación y crear más capacidad para restringir y rechazar los cambios que entran. Segundo, podemos reducir la velocidad a la que los agentes generan nuevos cambios para que la verificación pueda ponerse al día con el volumen de trabajo. Tercero, podemos bajar nuestro estándar de calidad para que la verificación no presione tan fuerte como lo haría de otra manera. Desde una perspectiva de escalamiento, necesitamos estar listos para hacer todas estas cosas. Al mismo tiempo, no deberíamos dejar de notar que podríamos lograr más al quitar restricciones en algunas direcciones. Tal vez podemos aumentar la velocidad de los cambios generados por agentes proporcionando enjambres de desarrolladores de agentes o fábricas de software automatizadas que creen cambios sin esperar a que revisemos cada uno de ellos.
Y en algunos lugares puede que queramos darles más libertad siempre que mantengamos restricciones más estrictas en otros. Al proporcionar restricciones más estrictas donde más nos importa, podemos maximizar nuestro rendimiento sin sacrificar la calidad. En todas estas decisiones hay muchas opciones. Lo más obvio es que tenemos que hacer concesiones entre diferentes dimensiones de la calidad. Como hemos enfatizado, la seguridad es muy importante, pero también hemos tenido que equilibrar entre ofrecer seguridad y entregar un producto a tiempo. Hay un espectro que va desde el enfoque en la innovación en un extremo hasta el enfoque en la calidad en el otro. En algún punto del camino, tenemos que tomar decisiones sobre dónde queremos ubicarnos en ese espectro.
Queremos enviar retroalimentación clara desde el entorno y el sistema de vuelta a nuestros agentes o equipos, para que las personas puedan enfocarse en las preocupaciones más subjetivas: el gusto, la intención y la arquitectura. Si podemos ayudar a los humanos a mantenerse dentro del rango seguro de restricciones, podemos evitar que tengan que trabajar duro tratando de descubrir dónde salieron mal las cosas.
La calidad del software incluye más que solo la corrección. La calidad del software también significa mantenibilidad, buen rendimiento, seguridad, eficiencia y facilidad de comprensión. Todas las restricciones que nos ayudan a cumplir estos estándares y mantienen nuestra producción en movimiento crean contrapresión en nuestro pipeline de entrega.
Necesitamos tomar decisiones deliberadas sobre dónde aplicar restricciones fuertes y dónde eliminarlas o relajarlas. Aplica restricciones fuertes donde estén sirviendo a ambos objetivos. No las mantengas si no están sirviendo a uno o a ambos. Estate listo para subir o bajar los estándares según lo requiera el caso. Y recuerda: estas restricciones en diferentes puntos del sistema de software son lo que hace que la calidad del software sea exigible.
Deberíamos aplicar restricciones fuertes donde mejor sirvan a este doble propósito y considerar eliminar o relajar las restricciones que no estén sirviendo bien a ninguno de los dos. También deberíamos estar listos para subir o bajar los estándares de calidad según sea necesario. En efecto, estas restricciones en varios puntos de nuestro sistema de software son lo que le da dientes a la calidad. En muchos casos, podemos crear más contrapresión y más restricciones implementando nuevas herramientas o fortaleciendo las que ya existen. Todas estas cosas pueden usarse para rechazar la mayoría de las solicitudes de cambio. Queremos construirlas a lo largo de todo el pipeline.
No queremos esperar hasta el final del pipeline, cuando nuestro sistema de CI simplemente nos diga que no podemos desplegar sin arreglar los problemas. Queremos usar estas señales lo antes posible, a través de todas las vías posibles. La restricción definitiva en este sistema es la que nos imponemos a nosotros mismos para respaldar las decisiones y acciones que hemos tomado para construir el sistema y operarlo. Pero como con todas las demás restricciones, necesitamos hacer concesiones meditadas sobre cuánto queremos que nuestro propio juicio restrinja, haga contrapresión y actúe como verificación final.
La calidad está en las restricciones que ponemos alrededor de nuestros agentes. Así que, mientras piensas en la calidad de tus propias apps, toma este planteamiento del problema y crea tu propio plan guiado por restricciones.
Hablando de calidad, los agentes están escribiendo tu código. Sonar te da las quality gates para que puedas publicarlo. Ejecuta la misma verificación completa en cada commit: análisis profundo entre archivos, un mapa de dónde vive el riesgo y una quality gate que exige el mismo estándar a cada humano y agente.
Este artículo fue calificado como 100% escrito por humanos por Pangram 4.
