Durante gran parte de la historia de la humanidad, 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, cuidadoso, rápido, comprensible y que pase bien las pruebas. Para los agentes, ese enfoque no escala bien; hay demasiado código como para que alguien lo lea. En consecuencia, cada vez más controles de calidad tienen que ocurrir en el harness, el entorno y el sistema operativo que rodea al agente. Yo sigo leyendo y revisando código, pero soy muy intencional con respecto a dónde me siento cómodo usando restricciones como control.
La calidad del software ahora depende de las restricciones que establezcas alrededor de tus agentes.
La lista de Guillermo es una buena prueba para saber si puedes permitirte saltarte la lectura. Fíjate en que cada "sí" es en realidad una afirmación de lo bajas que son las apuestas: sin usuarios, código desechable, prototipo. Cuando las apuestas suben, alguien 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 lanzando pruebas y restricciones deterministas contra las propuestas de un agente. Es estableciendo y manteniendo estas restricciones como construimos bucles que entregan de forma fiable 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 puertas de calidad, 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. También son métricas en torno a la calidad del código, como la complejidad ciclomática y la longitud de línea, que ayudan a mantener la legibilidad.
Dos personas pueden discrepar sobre si leer el código y aun así estar de acuerdo en el mecanismo. Guillermo lo lee. Bob no lee nada de eso. Ambos están describiendo una carrera de obstáculos: la diferencia es solo si un humano se sienta 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 el agente al controlador del agente y de allí a producción, ya le hemos hecho suficientes comprobaciones como para confiar en que es seguro enviarlo y en que el impacto del cambio está bien dentro del alcance del agente.
Un agente puede proponer cualquier cosa. Tus restricciones deciden si una propuesta es lo bastante segura, correcta, acotada y útil para que tú y tu equipo la puedan enviar a producción.
Este modelo ofrece mucho, pero también deja fuera muchas piezas, y esas omisiones merecen la pena pensarlas hoy. Un problema 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 se aplica tanto a la propia tarea como a cómo está parametrizada por el harness, el entorno y otros componentes.
El entorno que buscamos es uno donde un agente pueda hacer trabajo real, recibir retroalimentación en la que pueda confiar y fallar sin causar demasiado daño.
El otro problema importante es la confianza. No podemos ceder crédulamente la intención a algo tan inteligente y robusto como un agente moderno sin comprobar su corrección. 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 cruzar la frontera de producción siquiera.
Hay muchas formas de modelar cómo ponemos una estructura de verificación alrededor de un sistema.
En mi experiencia, ayuda tener un conjunto de comprobaciones más amplio, pero elegido intencionadamente, para tus restricciones en lugar de depender únicamente de las pruebas unitarias. La idea es que cada comprobación tenga una responsabilidad distinta, y eso puede ir desde la seguridad de tipos y el rendimiento hasta el escaneo de seguridad en etapas finales. La gente también puede definir sus propias restricciones, incluidas reglas de arquitectura que herramientas de linting como ESLint puedan hacer cumplir. Muchas de estas herramientas tienen hooks integrados que se pueden usar 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 de alto volumen y velocidad, pero esto también puede significar que se vuelva más difícil para los humanos revisar cada cambio. En cambio, tienes que ser intencional con respecto a dónde va su atención. Si pones un control humano en un sistema que por lo demás se mueve a velocidad de máquina, no te sorprendas si eso afecta 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 en etapas posteriores solo deberían involucrarse cuando se rompan las salvaguardas automáticas de las restricciones.
La “revisión de código” humana en el futuro va a ser 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. Igual que 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 tengamos, importa más si son lo bastante exigentes como para alcanzar nuestro estándar de calidad y preparación para producción.
La calidad del software no es una métrica única. Piénsalo como una colección de señales de importancia variable para ti y para tu equipo.
La contrapresión se puede implementar mediante 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 debe volver a estar en el bucle en lugar de ser reemplazada por él.
Las restricciones y la contrapresión permiten que los agentes detecten el mal trabajo antes de que se convierta en un problema
¿Qué pasa si no podemos aplicar la restricción porque el volumen de cambios es mayor de lo que nuestras herramientas pueden consumir? 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 comprobaciones 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 presionar 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 otro modo. Desde una perspectiva de escalado, tenemos que estar listos para hacer todas estas cosas. Al mismo tiempo, no deberíamos quedarnos cortos a la hora de darnos cuenta de que en realidad podríamos lograr más al eliminar restricciones en algunas direcciones. Quizá podamos 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 calidad. A lo largo de 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 hacer concesiones entre entregar 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 estar en ese espectro.
Queremos enviar retroalimentación clara desde el entorno y el sistema de vuelta a nuestros agentes o equipos, para que la gente pueda centrarse en las preocupaciones más subjetivas de gusto, intención y arquitectura. Si podemos ayudar a los humanos a mantenerse dentro del rango seguro de las restricciones, podemos evitar que tengan que esforzarse tratando de averiguar dónde salieron mal las cosas.
La calidad del software incluye más que solo corrección. La calidad del software también significa mantenibilidad, buen rendimiento, seguridad, eficiencia y ser fácil de entender. Todas las restricciones que nos ayudan a cumplir estos estándares y mantienen nuestra producción en marcha crean contrapresión en nuestro canal de entrega.
Necesitamos tomar decisiones deliberadas sobre dónde aplicar restricciones fuertes y dónde eliminarlas o flexibilizarlas. Aplica restricciones fuertes donde sirvan a ambos objetivos. No las mantengas si no sirven a uno o a los dos. Prepárate para subir o bajar los estándares según lo requiera el caso. Y recuerda que estas restricciones en diferentes puntos del sistema de software son lo que hace que la calidad del software se pueda imponer.
Deberíamos aplicar restricciones fuertes donde mejor sirvan a este doble propósito y considerar eliminar o flexibilizar 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 están en su lugar. Todas estas cosas se pueden usar para presionar a 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 dirá que no se nos permite desplegar sin arreglar los problemas. Queremos usar estas señales lo antes posible, a través de todos los caminos 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 todas las demás restricciones, necesitamos hacer concesiones reflexivas sobre cuánto queremos que nuestro propio juicio restrinja, ejerza contrapresión y actúe como control final.
La calidad está en las restricciones que colocamos alrededor de nuestros agentes. Así que, mientras piensas en la calidad para tus propias aplicaciones, toma este enunciado del problema y crea tu propio plan basado en restricciones.
Hablando de calidad, los agentes están escribiendo tu código. Sonar te da las puertas de calidad para que puedas enviarlo a producción.
Ejecuta la misma comprobación completa en cada commit: análisis profundo entre archivos, un mapa de dónde vive el riesgo y una puerta de calidad que somete a cada humano y agente al mismo listón.
Este artículo fue calificado como 100% escrito por humanos por Pangram 4.
