Más rápido, sin atajos

Qué significa más rápido, y qué no

La mayoría de los proyectos de software no son lentos porque la gente teclee despacio. Son lentos por las esperas: a una decisión, a una revisión, a que se encuentre y se corrija un fallo que debería haberse detectado el mes anterior. Son lentos porque los ingenieros sénior pasan días con código repetitivo que podría escribir un júnior, mientras las preguntas difíciles los esperan.

Así que, cuando decimos más rápido, queremos decir menos esperas y menos trabajo repetido. No queremos decir menos pruebas, menos revisiones ni documentación más escasa. Eso es justo lo que hace lento un proyecto más adelante, normalmente después de la puesta en marcha, cuando corregir un problema causa más trastorno.

Aquí no encontrará la promesa de que un proyecto lleve una fracción del tiempo habitual. Cada proyecto es distinto, y una cifra así no le diría nada sobre el suyo. Lo que sí podemos describir es cómo se organiza el trabajo y cómo se comprueba, para que lo juzgue usted mismo, y los hitos de su propio calendario son donde lo verá.

Los agentes ponen la base, los ingenieros dirigen

Todo proyecto tiene un gran volumen de trabajo necesario pero no novedoso: el esqueleto del proyecto, las pantallas y los formularios estándar, las interfaces entre las partes, el código que lee y escribe registros, las conexiones con servicios bien documentados y los conjuntos de pruebas que lo cubren todo. Hay que hacerlo bien, pero no necesita el criterio de un ingeniero sénior línea a línea.

En nuestro flujo de ingeniería con agentes, los agentes de IA construyen esa base. Trabajan según una especificación que escriben nuestros ingenieros, dentro de la estructura que fijan nuestros arquitectos, y un ingeniero revisa cada cambio que hacen antes de integrarlo. Los agentes no deciden qué se desarrolla, qué forma tiene el sistema ni si un cambio es aceptable. Eso lo deciden personas.

• Estructura inicial: organización del proyecto, configuración, cadenas de compilación y despliegue, entornos.
• Interfaces: los contratos tipados entre el frontend, el backend y los servicios externos, escritos primero para que todas las partes estén de acuerdo en ellos.
• Funciones estándar: formularios, listados, páginas de detalle, ajustes, registros que se crean, se leen, se actualizan y se borran.
• Integraciones con servicios bien documentados, detrás de interfaces que definen nuestros ingenieros.
• Conjuntos de pruebas: pruebas unitarias y de integración para todo lo anterior, escritas junto con el código y no después.
• Primeras versiones de la documentación técnica, que después los ingenieros corrigen y completan.

Todo empieza por la especificación

Unos agentes dirigidos solo son tan buenos como sus indicaciones. Antes de empezar con la base, nuestros ingenieros dejan por escrito lo que debe hacer cada parte: los datos que guarda, la interfaz que expone, las reglas que aplica, los errores que devuelve y las pruebas que lo demuestran. Esa especificación es el mismo documento que necesitaría un equipo humano, y pasa a formar parte del traspaso.

Escribirla primero tiene una ventaja que va más allá de los agentes. Las ambigüedades de sus requisitos salen a la luz en las primeras semanas, como preguntas que le llevamos, y no meses después como funciones que funcionan pero hacen lo que no deben.

Lo que se quedan nuestros ingenieros sénior

Pasar la base a agentes dirigidos no consiste en hacer menos ingeniería. Consiste en poner a las personas con más experiencia donde su criterio más importa, durante más parte del proyecto.

El resultado para usted es que las personas con más experiencia no pasan la semana con la validación de formularios. Están pensando en cómo se protegen sus datos, qué pasa cuando dos personas editan el mismo registro, cómo se comporta el sistema cuando un servicio externo está caído y si el producto hace lo que necesitan sus usuarios.

Primero las pruebas, y pruebas de las pruebas

El código que se produce rápido tiene que comprobarse a fondo, y un conjunto de pruebas solo es útil si de verdad detecta errores. Un conjunto puede ejecutar cada línea de código y aun así no comprobar nada importante. Por eso probamos nuestras pruebas.

Las pruebas de mutación son la forma de hacerlo. Una herramienta introduce a propósito pequeños fallos en el código, uno cada vez, y ejecuta las pruebas contra cada versión modificada. Si las pruebas fallan, el fallo se detectó; si pasan, las pruebas tienen un hueco ^[1]. Aplicamos pruebas de mutación al código que más importa: permisos, dinero, integridad de los datos y todo aquello por lo que preguntaría un regulador o un auditor.

• Pruebas unitarias para la lógica, pruebas de integración para las partes funcionando juntas y pruebas de extremo a extremo para los recorridos que hacen sus usuarios.
• Pruebas que se ejecutan contra una base de datos real, reconstruida cada vez a partir de las migraciones, y no contra un sustituto simplificado.
• Pruebas de mutación en el código crítico, en las que los mutantes que sobreviven se tratan como defectos de las pruebas.
• Fuzzing y pruebas de propiedades donde las entradas vienen de fuera: subidas de archivos, importaciones, API públicas y contratos inteligentes.

Revisiones en cada nivel

El Marco de Desarrollo de Software Seguro del NIST subraya que las prácticas de desarrollo seguro suelen tener que añadirse de forma deliberada al proceso de un equipo, para reducir las vulnerabilidades del software publicado y atajar sus causas de fondo ^[2]. Las revisiones son nuestra forma principal de hacerlo, en tres niveles.

1. 01

   Cada cambio

   Un ingeniero revisa cada cambio antes de integrarlo, lo haya escrito una persona o un agente. Quien revisa comprueba que hace lo que dice la especificación, que está probado y que no debilita nada a su alrededor.

2. 02

   Cada hito

   Antes de que un hito llegue a usted, se prueba en conjunto en un entorno de preproducción: las funciones, los casos límite y los recorridos de principio a fin.

3. 03

   Cada fase

   Al final de cada fase hacemos una serie completa de revisiones adversarias: personas que intentan a propósito romper la seguridad, los permisos, el tratamiento de los datos y los supuestos. Lo que encuentran se corrige antes de empezar la fase siguiente.

En las aplicaciones web comprobamos la seguridad contra un estándar publicado. El OWASP Application Security Verification Standard es una lista de requisitos para probar los controles de seguridad de una aplicación web ^[3], y da a ambas partes un lenguaje común sobre lo que se ha comprobado y lo que no.

Una verificación que puede ver

No debería tener que creerse nada de esto a ciegas. En nuestros proyectos, las pruebas de ello forman parte de la entrega.

• Cada cambio ejecuta automáticamente el conjunto completo de pruebas antes de poder integrarse, y usted puede ver los resultados.
• Cada hito se demuestra en un entorno de preproducción que puede usar usted mismo antes de aceptarlo.
• Lo que encuentran las revisiones y cómo se resolvió queda registrado, para que un auditor o su propio equipo puedan seguirlo.
• El código, las pruebas y el historial están en un repositorio a su nombre desde la primera semana.

Donde vamos despacio a propósito

Hay trabajos que nunca deben hacerse con prisa, y no lo intentamos. Una migración de datos desde su sistema antiguo se ensaya en una copia antes de tocar el original. Un contrato inteligente que va a custodiar valor se congela, se revisa y, cuando lo justifica, se audita externamente antes del despliegue, porque después no se puede parchear sin que se note. Un modelo que responde a sus clientes se mide con un conjunto de evaluación antes de cada cambio. Los permisos y los pagos tienen un segundo revisor.

Ir rápido en la base es lo que deja margen para ser cuidadosos aquí. Ese intercambio es todo el sentido del método.

Lo que esto significa para usted

• Software que funciona antes. La base llega pronto, así que ve antes pantallas reales y datos reales y puede corregir el rumbo mientras todavía es fácil.
• Más atención sénior a lo que importa. La arquitectura, la seguridad y la lógica central de su proyecto reciben más tiempo de nuestras personas con más experiencia.
• Menos sorpresas después de la puesta en marcha. Unas pruebas probadas y las revisiones de fase detectan los problemas cuando aún son fáciles de corregir.
• Un código que otro equipo puede asumir. Una estructura coherente, interfaces tipadas y pruebas exhaustivas hacen sencillo el traspaso.

Nada de esto cambia quién responde. Nuestros ingenieros son responsables de cada línea que se publica, la escribiera quien la escribiera en primer lugar.

Preguntas para cualquier estudio sobre la IA en su forma de trabajar

1. 01

   ¿Quién revisa el código escrito por IA?

   Un ingeniero debería revisar cada cambio antes de integrarlo. Pregunte cómo se garantiza.

2. 02

   ¿Qué no se delega nunca?

   La seguridad, los pagos, los modelos de datos y cualquier otra parte crítica deben quedarse en manos de perfiles sénior. Pida la lista.

3. 03

   ¿Adónde van mi código y mis datos?

   Pregunte qué herramientas ven su código, con qué condiciones, y si algo se conserva o se usa para entrenar.

4. 04

   ¿Cómo saben que las pruebas funcionan?

   La cobertura por sí sola no es una respuesta. Las pruebas de mutación, o algo parecido, sí.

5. 05

   ¿Qué puedo ver yo?

   Los resultados de las pruebas, los registros de las revisiones y un entorno de preproducción son cosas razonables que esperar.