Cómo trabajamos: el proceso AI-driven del estudio

A menudo nos preguntan: «¿De verdad escribís código con redes neuronales?». Sí. Y precisamente por eso nuestro proceso es más estricto que en un estudio clásico, no más flexible. Cuando el código se genera en minutos, lo único que separa un producto de un vertedero es la disciplina alrededor de la generación. Así es como la organizamos.

La especificación guía

Cualquier trabajo empieza con un documento, no con código. Anotamos qué vamos a construir: comportamiento, límites, criterios de finalización y una lista explícita de lo que no vamos a hacer. Tanto el cliente como nuestros agentes revisan la especificación —sí, los agentes también—: detectan muy bien las contradicciones y hacen preguntas incómodas mientras corregirlas cuesta un minuto y no una semana.

No es burocracia, sino economía. El código se ha vuelto barato; lo caro sigue siendo decidir exactamente qué construir. Un error de decisión, multiplicado por la velocidad de generación, se convierte en una montaña de algo que funciona, pero que no es lo que hacía falta. La especificación es la forma más barata de detectarlo de antemano.

Los agentes ejecutan

La generación se realiza como una cadena de producción: las tareas se extraen de la especificación y cada una la lleva un agente en un ciclo corto: plan, código y autocomprobación. Varias tareas avanzan en paralelo; lo que en un equipo clásico ocupa un sprint, aquí a menudo cabe en un día.

Pero la velocidad no es lo principal que aportan los agentes. Lo principal es la reproducibilidad. Un agente no se cansa, no «olvida lo que habíamos acordado» y no trabaja peor el viernes que el martes. Si el proceso está bien configurado, la calidad deja de depender del estado de ánimo de quien ejecuta el trabajo: por primera vez en la historia del oficio.

La persona responde

Ninguna línea llega al cliente sin una revisión humana. El ingeniero no comprueba si está «bien escrita» —eso los agentes lo hacen mejor que nosotros—, sino que se ocupa de aquello en lo que todavía no conviene confiar en la máquina: las decisiones arquitectónicas, los límites de los módulos, los riesgos y los casos límite que no entraron en la especificación.

Nuestro papel como ingenieros ha pasado de «escribir» a «diseñar y aceptar». Es la misma evolución que defendemos en la formación: un arquitecto y revisor en lugar de alguien que simplemente teclea código.

La calidad como gate

Para nosotros, «funciona» se demuestra, no se afirma. Cada comportamiento de la especificación queda cubierto por una prueba; la ejecución de pruebas, los linters y la validación son una barrera automática que ninguna tarea puede atravesar. Una prueba en rojo no es un inconveniente, sino un error detectado antes de producción.

Por eso, para nosotros, «rápido con redes neuronales» y «fiable» no se contradicen: la velocidad la aporta la generación; la fiabilidad, los gates que ni una persona ni un agente pueden esquivar.

Qué significa esto para el cliente

Transparencia: la especificación se lee en media hora y en ella se ve todo lo que se va a construir. Velocidad: los primeros escenarios funcionales llegan en los primeros días, no «ya os enseñaremos algo dentro de dos meses». Previsibilidad: los cambios pasan por el mismo ciclo —especificación, generación, gates—, por lo que el presupuesto no se descontrola con cada «y si añadimos algo más».

Así es el desarrollo en el que la IA no es una etiqueta de moda, sino la base del proceso. Así construimos los productos de nuestros clientes y así enseñamos a hacerlo a ingenieros y vibe-coders en nuestro curso.