El Laboratorio de IA
Un entorno de ingeniería de vanguardia donde las especificaciones entran y el software sale.
Entorno de Ingeniería – Peldaño 5 (Producción Autónoma)
El Laboratorio de IA es un entorno operativo paralelo que apunta al peldaño más alto del desarrollo dirigido por IA. Experimenta con nuevas formas de trabajar y sirve como espacio de prueba para prácticas, agentes y flujos de trabajo que luego se aplicarán en toda la ingeniería. El Laboratorio opera fuera de los procedimientos operativos estándar de ingeniería. Tiene sus propias reglas.
Dos escalas de madurez
Este documento usa dos escalas distintas definidas en el marco de referencia: la escala organizacional (Levels 1-3, aplicable a toda la empresa) y la escala de ingeniería (Peldaños 0-5, específica para el desarrollo de software). Ver el marco para definiciones completas y criterios de aceptación.
El Laboratorio apunta al Peldaño 5. La ingeniería fuera del Laboratorio apunta al Level 3 organizacional (Peldaños 4-5).
La transición más difícil es el paso del Peldaño 3 al Peldaño 4: aceptar que ya no se lee el código y confiar en los escenarios para validar el resultado. Es un cambio psicológico antes de ser técnico. La mayoría de los ingenieros se estancan en el Peldaño 3 porque soltar el control sobre el código va en contra de todos sus instintos profesionales.
1. Reglas absolutas
Dos reglas definen el Laboratorio. No son aspiraciones – son condiciones de admisión.
El humano define la arquitectura, las restricciones y los escenarios de satisfacción. La IA produce el código, ejecuta las pruebas y converge hacia la solución. Si estás escribiendo o leyendo código línea por línea, no estás operando en el modo de trabajo del Laboratorio.
2. Criterios de admisión de proyectos
El terreno natural del Laboratorio. Sin legado, sin deuda técnica, sin hábitos. Las reglas del Laboratorio (Peldaño 5) se aplican de extremo a extremo desde el primer día.
- El alcance está suficientemente definido para escribir especificaciones y escenarios
- El proyecto puede tolerar un ritmo de aprendizaje
El Laboratorio también toma proyectos existentes en transición al Peldaño 5. Esto es más difícil – el código existe, y también los hábitos – pero aquí es donde la transformación tiene más impacto.
- Cobertura de escenarios suficiente (o compromiso de construirla primero)
- Todo el trabajo nuevo sigue las reglas del Laboratorio – sin retroceder
- El código existente es contexto para el agente, no algo intocable
- El riesgo de regresión se gestiona mediante escenarios, no revisión humana
Secuencia típica para un brownfield:
- Extraer la especificación implícita – El sistema existente ES la especificación. Nadie documentó jamás las mil decisiones implícitas acumuladas a lo largo de años de parches, hotfixes y workarounds que se volvieron permanentes. Esta extracción es el trabajo más difícil y más humano de la transición. Requiere a las personas que saben por qué este módulo tiene esa excepción, por qué este servicio se dividió de esa manera, por qué este valor está configurado así. La IA puede ayudar a documentar lo que hace el sistema (generar especificaciones a partir del código). Pero distinguir comportamientos intencionales de accidentes históricos sigue siendo un juicio humano.
- Escribir escenarios de extremo a extremo que describan el comportamiento esperado actual, basándose en la especificación extraída en el paso 1
- Verificar que los escenarios pasen con el código existente
- A partir de ese punto, todos los cambios los hace el agente, validados por escenarios
- Iterar: cada componente en transición aumenta la cobertura del Peldaño 5 del proyecto
Qué NO pertenece al Laboratorio
- Cualquier proyecto cuyo desarrollo continúa usando prácticas tradicionales (humanos escriben o revisan código)
- Proyectos cuyas restricciones de entrega no toleran ningún riesgo de aprendizaje
Regla: la condición de entrada no es la ausencia de código existente – es el compromiso de que todo el trabajo nuevo siga las reglas del Laboratorio.
3. Modo de trabajo: desarrollo no interactivo
El ciclo
- El humano escribe la especificación (arquitectura, restricciones, escenarios)
- El agente produce el código
- Los escenarios validan el resultado
- El humano evalúa la satisfacción e itera sobre la especificación si es necesario
El humano no interviene en la ejecución. El humano interviene en la definición y la evaluación.
Escenarios vs pruebas
- Pruebas: validaciones almacenadas en el código. Vulnerables a ser manipuladas por agentes – un agente puede reescribir una prueba para que pase. Útiles pero insuficientes.
- Escenarios: recorridos de usuario de extremo a extremo que describen el comportamiento esperado desde la perspectiva del usuario. Más difíciles de eludir. El Laboratorio favorece los escenarios.
Cuando los humanos ya no leen el código, las pruebas unitarias pierden una ventaja crucial: la capacidad del ingeniero para identificar casos extremos a partir de su conocimiento de la implementación. En un modelo de ejecución opaco, solo la validación conductual de extremo a extremo sigue siendo confiable, porque no depende del conocimiento de los detalles internos.
Métrica de satisfacción
El Laboratorio no mide el éxito en binario (pruebas verdes / rojas). Mide la satisfacción: "a través de todas las trayectorias observadas en todos los escenarios, ¿qué fracción satisface al usuario?"
Cuando la satisfacción es insuficiente, el problema está en la especificación, no en el agente. Itera sobre la especificación, no sobre el código.
La habilidad crítica: escribir especificaciones para un agente
El cuello de botella del Laboratorio no es la velocidad de implementación – es la calidad de las especificaciones. Escribir una especificación lo suficientemente precisa para que un agente la implemente correctamente sin intervención humana es una habilidad nueva. Casi nadie la ha desarrollado.
La dificultad: cuando un humano recibe una especificación ambigua, llena los vacíos con juicio, contexto o un mensaje de Slack preguntando "¿querías decir X o Y?". El agente construye lo que describiste. Si la descripción es ambigua, el software llena los vacíos con suposiciones de máquina, no con intuiciones del cliente.
Esta habilidad se desarrolla con la práctica:
- Las clínicas de IA deben incluir revisiones de especificaciones: "aquí está mi spec, aquí está lo que produjo el agente, aquí está lo que faltaba en la spec"
- Las sesiones en pares deben trabajar en ejercicios de especificación, no solo en ejercicios de código
- Cada iteración fallida es una señal sobre la spec, no sobre el agente – documenta lo que la spec no establecía con suficiente claridad
El objetivo del Laboratorio no es solo producir software mediante agentes. Es desarrollar ingenieros que puedan especificar con el rigor que exigen los agentes.
4. Ingenuidad deliberada
El mayor obstáculo para el Peldaño 5 no es técnico – es el hábito.
Los ingenieros experimentados tienen reflejos profundos: estructurar el código de cierta manera, revisar línea por línea, escribir pruebas ellos mismos, refactorizar manualmente. Estos reflejos eran fortalezas en el desarrollo tradicional. En el Laboratorio, son obstáculos.
La ingenuidad deliberada significa:
- Eliminar las convenciones de desarrollo tradicionales y ver qué sostiene sin ellas
- Preguntar sistemáticamente: "¿Por qué estoy haciendo esto? El modelo debería hacerlo."
- Aceptar que los enfoques que parecen "ingenuos" o "incorrectos" según los estándares tradicionales pueden ser correctos en un entorno AI-native
- Tratar tareas históricamente consideradas demasiado costosas (construir réplicas completas de servicios, escribir miles de escenarios) como rutinarias cuando los costos de ejecución de IA las hacen factibles
La pregunta permanente del Laboratorio:
¿Por qué estoy haciendo esto? El modelo debería hacerlo.
Si la respuesta es "porque siempre lo he hecho así", esa es exactamente la razón para cambiar.
5. Rol de apoyo
El Laboratorio no está aislado del resto de la ingeniería. Le sirve.
El Laboratorio produce:
- Patrones de trabajo documentados: cómo especificar para un agente, cómo escribir escenarios, cómo evaluar la satisfacción
- Agentes reutilizables o adaptables
- Prueba concreta de que el Peldaño 5 funciona en proyectos reales
- Retroalimentación honesta – qué funciona y qué aún no funciona
El Laboratorio comparte a través de:
- Clínicas de IA: sesiones regulares, formato corto. "Aquí está lo que probamos, aquí está lo que pasó."
- Documentación: cada patrón y antipatrón descubierto se documenta
- Emparejamiento Laboratorio / no-Laboratorio: un miembro del Laboratorio trabaja temporalmente con un ingeniero fuera del Laboratorio para transferir prácticas
Un Laboratorio que no comparte es inútil. Compartir es tan importante como producir.
6. Cultura del laboratorio
El Laboratorio tiene una cultura distinta al resto de la organización:
- Curiosidad obligatoria – la pregunta "¿y si probamos..." siempre es bienvenida
- Monitoreo agresivo – los miembros del Laboratorio se mantienen al día con los últimos avances en modelos de IA. Cuando aparece un nuevo modelo o herramienta, el Laboratorio lo prueba rápidamente y evalúa si es un cambio de paradigma. Esperar a que las cosas "maduren" es incompatible con el Laboratorio.
- Audacia en los métodos, rigor en los compromisos – el Laboratorio empuja los límites de cómo trabajamos: qué herramientas adoptamos, qué flujos de trabajo reinventamos, qué enfoques "ingenuos" probamos. Pero las obligaciones contractuales, económicas, legales y de seguridad con los clientes siguen siendo innegociables. La audacia se aplica a los medios, no a las garantías.
- Alto riesgo, bajas apuestas – los proyectos del Laboratorio se eligen para tolerar el fracaso. Úsalo para tomar riesgos que no tomarías en otro lugar
- Transparencia radical – los fracasos se comparten con tanto detalle como los éxitos. Un fracaso documentado tiene más valor que un éxito silencioso
- El liderazgo significa elevar al equipo – en el Laboratorio, el liderazgo no se mide por el rendimiento individual. Los líderes son quienes mejoran al resto del equipo: quienes comparten sus descubrimientos, documentan sus patrones, desbloquean a sus colegas y convierten su experiencia en prácticas reproducibles. Un ingeniero brillante que guarda sus métodos para sí mismo no es un líder del Laboratorio.
- Velocidad de iteración – el ciclo especificación → agente → escenario → evaluación debe ser rápido. Si una iteración tarda días, el ciclo es demasiado pesado
7. Errores a evitar
- Volver a los hábitos – el reflejo de "revisar manualmente el código para estar seguro" es exactamente lo que el Laboratorio prohíbe. Si los escenarios pasan, el código está validado por los escenarios.
- Especificaciones insuficientes – cuando el agente produce código malo, el problema está en la spec. Itera sobre la spec, no sobre el código.
- Aislamiento – un Laboratorio que no comparte sus aprendizajes es un hobby, no un Laboratorio.
- Proyectos demasiado críticos demasiado pronto – el Laboratorio tiene alta tolerancia al riesgo. No incluyas un proyecto cuyo fracaso ponga en peligro a un cliente o un contrato.
- Perfeccionismo del agente – el objetivo no es un agente perfecto. Es un agente que produce valor. Itera.
- Brownfield sin extracción de spec – hacer la transición de un proyecto existente sin extraer primero la especificación implícita y escribir escenarios que protejan el comportamiento actual es volar sin red. La extracción es el trabajo más difícil – no la subestimes.
- Brownfield "medio Laboratorio" – si parte del trabajo en un proyecto brownfield se hace en modo tradicional "porque es más rápido para esa parte", el proyecto no está en el Laboratorio. Las reglas son absolutas, incluso cuando es incómodo.
- El muro de los seis meses – los proyectos impulsados por IA sin fuerte participación humana (especificaciones, escenarios, arquitectura) acumulan deuda estructural que explota después de aproximadamente seis meses. El código generado por IA sin restricciones claras suele ser menos estructurado y menos mantenible. Los escenarios y especificaciones del Laboratorio son precisamente la defensa contra este muro – imponen rigor upstream que evita que la deuda se acumule silenciosamente.
8. Ciclo de vida
El Laboratorio comienza con proyectos greenfield e inicia la transición de 1-2 proyectos brownfield seleccionados. Equipo pequeño. Reglas absolutas en efecto. Resultado = proyectos entregados + prácticas documentadas + agentes funcionales + playbook de transición brownfield.
Los proyectos brownfield en transición en el Laboratorio se convierten en los casos de referencia para el resto de ingeniería. Los ingenieros que pasaron por el Laboratorio se convierten en los socios de emparejamiento para quienes no lo han hecho. Más proyectos brownfield entran al Laboratorio.
El Laboratorio ha absorbido la ingeniería. La distinción desaparece. Todo es Peldaño 5. El Laboratorio nunca fue un destino – fue el vehículo de transición. Tanto los proyectos greenfield COMO los brownfield operan bajo las mismas reglas.
Este ciclo de vida se alinea con la ruta de transformación organizacional: la Fase 1 corresponde a la transición Level 2→3 (6-12 meses en la escala organizacional).
Regla resumida
¿Por qué estoy haciendo esto? El modelo debería hacerlo.
← Volver al inicio · El marco de referencia · Estándares de ejecución con IA · Glosario