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.
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.
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
La condición de admisión brownfield asume que el código ha sido evaluado con la Cuadrícula de madurez del código (Codebase Readiness Grid). Un código por debajo del Nivel 2 requiere primero construir el andamiaje de sensores; de lo contrario, el Laboratorio opera sin señal correctiva. Ver Estrategia brownfield para los cuatro modos de transición.
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.
Modo de trabajo: la unidad operacional
Las cinco etapas
El Laboratorio estructura todo el trabajo en torno a un bucle recurrente de cinco etapas. El humano se concentra en los límites; el agente corre por dentro.
- Contexto
Contexto de trabajo vivo (CLAUDE.md / AGENTS.md, herramientas con alcance acotado, habilidades bajo demanda) validado contra el sistema antes de comenzar el trabajo. El contexto desactualizado produce trabajo incorrecto con confianza.
- Clarificación
El agente expone supuestos y hace preguntas calibradas. Sin ejecución mientras quede ambigüedad material. Regla de coste: coste de clarificación ≪ coste de corrección.
- Ejecución
El agente produce, ejecuta las pruebas, converge. El humano no supervisa la ejecución.
- Validación
Puerta graduada por riesgo (§ 4). Pruebas, escenarios, agente revisor para trabajo reversible; aprobación humana para lo irreversible.
- Recuperación
Cuando la validación falla o el agente se queda bloqueado: recalibrar (re-especificar, re-contextualizar, lluvia de ideas) en lugar de depurar. Ver § 5.
La Etapa 2 (Clarificación) se entrega en herramientas de producción: /speckit.clarify de spec-kit, el modo plan de Anthropic y la herramienta AskUserQuestion operacionalizan esto como una puerta discreta. La Etapa 4 se detalla en Puertas de validación graduadas por riesgo; la Etapa 5 en Protocolo de estado bloqueado.
Dos puntos de control humanos
El trabajo humano se concentra en el límite delantero (Contexto + Clarificación) y el límite trasero (Validación + Recuperación). Dentro del bucle, los agentes y evaluadores corren. Este es el patrón operacional que hace sostenible al Peldaño 5: la atención del humano no es un cuello de botella de revisión línea por línea; es un rol de dirección y juicio por bucle.
El patrón es de tarea discreta, no específico de ingeniería
El Laboratorio aplica el bucle al código, pero la misma forma rige otros trabajos de tarea discreta:
| Etapa | Ingeniería | Atención al cliente | Operaciones financieras |
|---|---|---|---|
| Contexto | Código + CLAUDE.md | Base de conocimiento + historial del cliente | Libro mayor + plan de cuentas + reglas del período |
| Clarificación | El agente pregunta sobre criterios de aceptación ambiguos | El agente pregunta "¿qué quiere realmente el cliente?" antes de redactar | El agente expone ambigüedad en la categorización de transacciones |
| Ejecución | PR con pruebas | Respuesta + acciones | Asientos contables redactados |
| Validación | Agente revisor + IC; puerta humana en despliegue a producción | Agente revisor para tono + política; puerta humana en reembolsos por encima del umbral | Agente conciliador; aprobación humana antes de contabilizar |
| Recuperación | Re-especificar cuando aflora un error sutil | Re-entrenar cuando cambian los patrones de escalación | Re-especificar cuando un caso extremo expone una brecha de categoría |
El sustrato cambia; el bucle no. Las reglas del Laboratorio (código no escrito ni revisado por humanos) son la instancia de ingeniería del principio más amplio: los humanos dirigen y validan; la IA ejecuta dentro de puertas graduadas por riesgo.
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.
Economía de tokens
El tiempo de reloj es la medida equivocada en el Peldaño 5: los agentes trabajan en paralelo, de manera asíncrona y por la noche. Las métricas vinculantes son:
- Coste por unidad fusionada (PR, ticket, transacción). Anthropic cuantifica el sobrecoste multiagente: los agentes típicos usan ~4× los tokens del chat; los sistemas multiagente pueden usar ~15× (Anthropic, 2025). El coste por unidad fusionada hace eso visible.
- Margen bruto de IA a nivel de equipo: valor producido en relación con la inferencia gastada. Los equipos IA-nativa tratan el coste de tokens como una métrica de ingeniería de primer nivel. Ver Economía de la IA en madurez.
- Rendimiento del agente por dólar: unidades fusionadas por dólar de inferencia. Distingue a los equipos de alto gasto y alto rendimiento de los de alto gasto y bajo rendimiento.
El Laboratorio rastrea estas métricas junto con la satisfacción. Un equipo que alcanza el Peldaño 5 ejecutando costosos bucles multiagente en cada tarea puede tener éxito técnico y ser económicamente insostenible al mismo tiempo.
Las habilidades críticas: especificación y diseño de procesos
El cuello de botella del Laboratorio no es la velocidad de implementación – es el trabajo en el límite delantero. Dos habilidades nuevas:
- Especificación: escribir instrucciones lo suficientemente precisas para que el agente las implemente correctamente sin intervención humana.
- Diseño de procesos para IA: diseñar las restricciones, las puertas y los niveles de validación dentro de los cuales el agente opera de manera consistente. Distinto de la ingeniería de prompts y de la escritura de specs en sí. Ver Estándares de Ejecución con IA § Capa 5.
Casi nadie ha desarrollado plenamente ninguna de las dos.
La dificultad con la especificación: 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. La etapa de clarificación de la unidad operacional es la corrección estructural, pero solo si el equipo la usa.
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.
Puertas de validación graduadas por riesgo
La Etapa 4 (Validación) de la unidad operacional es graduada por riesgo: diferentes clases de acción obtienen diferentes puertas. Las dimensiones que determinan la puerta, tomadas de SAE J3016 (conducción) como el análogo más limpio:
- Dominio operacional de diseño (ODD): las condiciones bajo las cuales el agente está diseñado para funcionar. Fuera del ODD, el agente no hace afirmaciones; la puerta cae al humano.
- Responsabilidad de fallback: quién maneja la acción cuando el agente se queda bloqueado o alcanza un límite prohibido.
- Expectativa de supervisión: qué se espera que haga el humano durante la operación.
- Transferencia de control: cómo se desplaza la autoridad entre el agente y el humano.
Las tres posturas operacionales
Aprobación humana requerida antes de que se ejecute la acción.
Predeterminado para acciones irreversibles de alto impacto: transacciones financieras, despliegues a producción, comunicaciones orientadas al cliente, cualquier cosa que cree una obligación legal o financiera.
El agente actúa de manera autónoma; el humano monitorea con autoridad de intervención.
Predeterminado para trabajo reversible en producción con fuerte cobertura de evaluación.
El agente actúa dentro de límites predefinidos; sin involucramiento humano en tiempo real.
Reservado para trabajo aislado y reversible con pruebas sólidas y un agente revisor en cada artefacto.
Un equipo maduro del Peldaño 5 opera los tres simultáneamente. Ejemplos:
| Acción | Puerta | Justificación |
|---|---|---|
| Fusión de código a main (repositorio bien probado, agente revisor) | HOOTL | Reversible (se puede revertir); radio de impacto acotado por el IC |
| Despliegue a producción | HITL | Irreversible a nivel de percepción del cliente; alto impacto |
| Transacción financiera redactada en el sistema contable | HITL | Irreversible (rastro de auditoría); implicaciones regulatorias |
| Respuesta de soporte rutinaria (dentro del alcance de la base de conocimiento) | HOTL | Reversible; calidad monitoreada; agente revisor para tono/política |
| Reembolso o crédito emitido por encima del umbral | HITL | Irreversibilidad financiera; implicaciones de confianza |
Las reglas absolutas del Laboratorio ("código no escrito ni revisado por humanos") siguen aplicándose dentro del modo HOOTL. Pero los equipos del Peldaño 5 salen deliberadamente de HOOTL para el trabajo irreversible: esa es una elección de diseño graduada por riesgo, no una regresión.
Fatiga de vigilancia
HOTL es operacionalmente frágil cuando se trata como monitoreo pasivo. Para que HOTL sea significativo, el humano debe (a) tener autoridad de intervención (kill switch, rollback, override) y (b) estar realmente prestando atención. La fatiga de vigilancia está bien documentada; los equipos que etiquetan todo como HOTL a modo de teatro de cumplimiento descubren que su supervisión es ilusoria. El coste cognitivo de la vigilancia sostenida es real (ver Coste cognitivo).
Protocolo de estado bloqueado
Cuando la validación falla o el agente se queda bloqueado en un entregable, la respuesta se rige por la etapa de Recuperación de la unidad operacional, y las reglas del Laboratorio.
El modo de fallo del cuello de botella de IA
En el Peldaño 5, "atrasado en un entregable" rara vez significa que la capacidad humana sea escasa. Significa que el agente ha alcanzado un límite estructural: dirección equivocada, spec ambigua, caso extremo subjetivo que no puede resolver solo. Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) encontraron que el 41,8% de los fallos multiagente son problemas de especificación o diseño que necesitan re-especificación, no reintento.
Recalibración, no depuración
La literatura sobre la autocorrección intrínseca es unánime: un modelo que se ha comprometido con una dirección equivocada no se dará cuenta de manera fiable por sí solo; la reflexión en la misma ventana de contexto después de una respuesta incorrecta agrava el error en lugar de corregirlo. El movimiento de recuperación es reconstruir la comprensión del agente (contexto fresco, spec re-articulada, lluvia de ideas multi-perspectiva), no depurar el artefacto que produjo el agente.
Patrón práctico en el Peldaño 5:
- Detecta el estado bloqueado: límite de iteraciones alcanzado; mismo patrón de fallo recurriendo; problema subjetivo planteado por un usuario.
- Deja de iterar. Convoca una sesión de recalibración: uno o más humanos entablan diálogo con el agente; el objetivo es aflorar el supuesto erróneo.
- Re-especifica o re-contextualiza. Refina los criterios de aceptación, corrige requisitos ambiguos, actualiza CLAUDE.md / AGENTS.md si la intención se ha desviado del contexto documentado.
- Reinicia el bucle desde Contexto, no desde Ejecución. Una ejecución fresca del agente sobre una spec corregida casi siempre supera la corrección continua dentro de la ventana de contexto original.
Regla del Laboratorio para estados bloqueados
Cuando un proyecto del Laboratorio está bloqueado, no retomes el trabajo manualmente. Llevarse la implementación a manos humanas viola las reglas absolutas del Laboratorio y reemplaza el síntoma (entrega lenta) por uno peor (el Laboratorio ya no demuestra cómo se ve el Peldaño 5). La respuesta correcta es la recalibración colectiva: traer a más humanos a la spec/clarificación, aflorar el supuesto erróneo, volver a ejecutar el bucle.
Si el trabajo es genuinamente irrecuperable en el Peldaño 5, la madurez del código del proyecto está por debajo de donde el equipo está operando: vuelve temporalmente a un Peldaño inferior y remedia el andamiaje (madurez del código, estrategia brownfield). Esto es un movimiento legítimo; volver a la codificación manual dentro del Laboratorio no lo es.
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 IA-nativa
- 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.
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.
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 bucle de retroalimentación de la spec al entregable debe ser rápido. Si una iteración tarda días, el ciclo es demasiado pesado
Errores a evitar
- Pitfall: 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.
- Pitfall: Especificaciones insuficientes
Cuando el agente produce código malo, el problema suele estar en la spec. Recalibra (re-especificar, re-contextualizar) antes de depurar el artefacto. Itera sobre la spec, no sobre el código.
- Pitfall: Aislamiento
Un Laboratorio que no comparte sus aprendizajes es un hobby, no un Laboratorio.
- Pitfall: 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.
- Pitfall: Perfeccionismo del agente
El objetivo no es un agente perfecto. Es un agente que produce valor. Itera.
- Pitfall: 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.
- Pitfall: 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.
- Pitfall: 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 aguas arriba que evita que la deuda se acumule silenciosamente.
- Pitfall: Tratar un cuello de botella de IA como un problema de productividad
Cuando el agente no puede entregar, casi nunca es un problema de capacidad (el agente tiene capacidad casi infinita). Casi siempre es un problema de spec o de contexto. Redistribuir el trabajo a humanos reemplaza la causa raíz equivocada y viola las reglas del Laboratorio. La respuesta correcta es la recalibración (ver § 5).
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