Desarrollo con IA: el método de los pioneros

Una afirmación empezó a circular a finales de julio y parece contradecir medio siglo de ingeniería de software. Robert C. Martin —Uncle Bob, autor de Clean Code y firmante del Manifiesto Agile— dice que su estrategia actual es no leer el código escrito por sus agentes. La productividad, sostiene, desaparece si revisa cada línea.

Robert C. Martin, conocido como Uncle Bob, en su estudio rodeado de computadoras de distintas generaciones — Robert C. Martin en su estudio. Fotografía documental de Tim-bezhashvyly, Wikimedia Commons, CC BY-SA 4.0.

La frase es real. Martin la publicó el 23 de julio de 2026 y enseguida explicó la parte que suele perderse al compartirla aislada: no cambió revisión por fe. Cambió revisión línea por línea por un gauntlet, una carrera de obstáculos compuesta por pruebas unitarias, aceptación en Gherkin, procedimientos de QA, métricas de calidad, cobertura y mutation testing.

Esta no es una defensa del vibe coding. Es una pregunta más interesante:

Si una máquina puede producir más código del que una persona puede leer, ¿dónde debe colocar esa persona su atención para seguir siendo responsable?

La respuesta que emerge de Martin, Kent Beck, Martin Fowler, Birgitta Böckeler y Simon Willison no es uniforme. Unos siguen leyendo el código; otros empiezan a tratar implementaciones rutinarias como una caja negra. Pero convergen en algo: el humano deja de ser el mecanógrafo principal y se convierte en diseñador de intención, límites y evidencia.

La cita está verificada, pero el contexto cambia su sentido

La publicación original de Uncle Bob contiene la afirmación completa. En la conversación posterior, reconstruida por Charlie Kindel y por un análisis con enlaces al hilo, Martin añadió tres matices:

Los agentes también escriben pruebas, pero él revisa la especificación de aceptación y los procedimientos de QA.
La profundidad del control depende de la criticidad; no todo cambio merece el mismo ritual.
El código desordenado también perjudica al agente: funciones enormes y complejidad creciente hacen que se enrede en su propia producción.

También admitió que es fácil sobreactuar. Que un agente pueda ejecutar Gherkin, unitarias, QA y mutación no implica que cada cambio necesite toda la artillería. A veces bastan pruebas unitarias y controles básicos. La disciplina está en elegir el nivel por riesgo, no en convertir una lista de herramientas en religión.

La formulación completa, entonces, no es “ya no importa el código”. Es esta:

No necesito inspeccionar toda implementación si diseñé evidencia independiente suficiente para el riesgo que estoy aceptando.

Eso sigue siendo una postura discutible. Y es justo donde empieza la conversación entre pioneros.

Qué está diciendo cada referente

Referente	Idea central	Lo que exige al humano
Robert C. Martin	La velocidad del agente sólo se aprovecha si la verificación no depende de leer cada línea.	Definir aceptación, QA, métricas y restricciones proporcionales al riesgo.
Kent Beck	La IA amplía la exploración; visión, estrategia, división de tareas y feedback ganan valor.	Conservar el gusto, las decisiones de diseño y bucles de feedback cortos.
Martin Fowler	Programación agéntica no es olvidar que el código existe; la persona sigue siendo responsable.	Evaluar resultado, código, tests y señales del sistema.
Birgitta Böckeler	Un agente necesita guías antes de actuar y sensores para autocorregirse.	Construir y mantener el harness, especialmente donde el comportamiento no es fácil de medir.
Simon Willison	Las prácticas de ingeniería buenas se vuelven todavía más valiosas con agentes.	Especificar, probar, revisar por riesgo, hacer QA y desplegar primero a preview.

No todos son “pioneros” en el mismo sentido. Martin, Beck y Fowler moldearon las prácticas modernas de diseño, TDD, refactoring y Agile. Böckeler y Willison están convirtiendo esas prácticas en experiencia operativa para agentes. Juntos ofrecen algo más útil que una consigna.

Uncle Bob: del código legible al código demostrablemente confiable

La aparente contradicción es deliciosa. Clean Code convirtió la legibilidad en deber profesional. El propio Martin ha repetido que se pasa mucho más tiempo leyendo que escribiendo código. ¿Cómo puede ahora negarse a leer la salida de un agente?

Porque cambió el cuello de botella.

Cuando una persona escribía 100 líneas, revisar esas 100 líneas era razonable. Cuando varios agentes pueden generar miles mientras la persona define el siguiente problema, la lectura exhaustiva consume toda la ganancia. Martin propone mover confianza desde la inspección artesanal hacia restricciones que puedan ejecutarse una y otra vez.

Eso no vuelve irrelevante a Clean Code. La mantenibilidad sigue siendo parte del gauntlet:

límites al tamaño de funciones y archivos;
complejidad ciclomática;
reglas de dependencias;
análisis estático;
duplicación y código muerto;
pruebas que permitan modificar sin miedo.

La diferencia es que muchas reglas dejan de existir sólo en la cabeza del revisor. Se convierten en propiedades computables que el agente ve antes de entregar.

Hay, sin embargo, una frontera: una función corta puede implementar perfectamente la conducta equivocada. Ningún linter descubre que resolvimos el problema incorrecto.

Kent Beck: la IA no elimina TDD, aumenta el valor del feedback

Kent Beck creó Extreme Programming, popularizó TDD y ayudó a crear la familia xUnit. En su sitio describe la práctica actual como augmented coding: la IA reduce el costo de convertir una idea en software, pero amplifica el valor de visión, estrategia, descomposición y bucles de feedback.

Su postura evita dos simplificaciones:

no hay mérito en producir más tareas si cada una crea incidentes o carga de revisión;
tampoco hay virtud en conservar trabajo manual que una herramienta ya puede ejecutar bien.

En su experimento TCR —Test & Commit or Revert— con agentes, una prueba aprobada permite conservar el cambio; una prueba fallida revierte el incremento y obliga a intentar algo más pequeño. El agente obtiene autonomía dentro de un circuito que impide acumular pasos rotos.

El patrón importa más que la herramienta:

Beck también insiste en que la IA carece de gusto propio. Puede añadir veinte líneas a una función ya monstruosa porque el resultado local pasa. La persona conserva las decisiones que requieren entender opciones futuras, coherencia y costo organizacional.

En otras palabras: el test autoriza un incremento; no demuestra que el diseño sea bueno ni que la tarea mereciera existir.

Fowler: responsabilidad humana, aunque cambie la forma de revisar

Martin Fowler define programación agéntica como un cambio profundo: la persona guía a modelos que manipulan el repositorio, ejecutan pruebas y evalúan resultados. Pero conserva una línea clara frente al vibe coding: el equipo sigue preocupado por cómo funciona el sistema y sigue siendo responsable.

Fowler enumera revisión de código, pruebas y otros sensores como formas de evaluación. Esto parece chocar con el “no miro” de Uncle Bob. En realidad describe un espectro:

revisar cada línea es un sensor;
observar contratos, pruebas, arquitectura y comportamiento también lo es;
la mezcla correcta depende de cuánta incertidumbre queda y cuánto daño puede causar.

Dos ideas clásicas de Fowler son especialmente relevantes.

Primero, cobertura no es calidad. La cobertura ayuda a encontrar áreas nunca ejercitadas; un porcentaje alto se puede conseguir con pruebas sin aserciones útiles. Usarla como meta aislada invita a jugar con la métrica.

Segundo, mutation testing hace una pregunta más fuerte. Cambia un operador, elimina una línea o invierte una condición. Si las pruebas siguen verdes, existe una brecha: ejecutaron el código, pero no detectaron una alteración plausible.

La consecuencia práctica es sencilla:

Cobertura pregunta “¿pasó una prueba por aquí?”. Mutación pregunta “¿la prueba notaría que esto está mal?”.

No hace falta mutar todo el monolito en cada commit. Suele rendir mejor sobre lógica cambiada, reglas críticas y jobs nocturnos.

Guides + sensors: la versión operativa del gauntlet

Birgitta Böckeler, Distinguished Engineer de Thoughtworks, llama harness engineering al trabajo de diseñar el entorno que guía y corrige a un agente.

Si quieres llevar el concepto del gauntlet a arquitectura de repositorio, publicamos una guía completa de harness engineering para agentes de código.

Diagrama de harness engineering: guías alimentan al agente y sensores cierran el bucle de autocorrección bajo dirección humana — Guías, sensores y bucle de autocorrección. Diagrama de Birgitta Böckeler / MartinFowler.com, usado como referencia documental.

El modelo separa dos familias:

Guías: prevenir antes de generar

Son controles de feedforward. Reducen el espacio de soluciones antes de que el agente toque el código:

una especificación con criterios de aceptación;
AGENTS.md con alcance, comandos y zonas prohibidas;
ejemplos canónicos del repositorio;
decisiones de arquitectura;
contratos de API y esquemas;
scripts o codemods para operaciones repetibles.

Una guía en lenguaje natural aumenta probabilidades. Una herramienta determinista —un generador, una API tipada, un script— restringe posibilidades.

Sensores: detectar y corregir después

Cierran el feedback:

compilador y type checker;
lint y límites de complejidad;
tests unitarios, de integración y de contrato;
cobertura y mutation testing;
SAST, escaneo de secretos y dependencias;
pruebas de arquitectura;
logs, trazas, métricas y SLO;
QA humana y revisión semántica.

Los sensores computacionales son rápidos y repetibles. Los revisores humanos y modelos evaluadores pueden juzgar semántica, pero son más caros y variables. El sistema necesita ambos.

Böckeler señala la debilidad que ninguna herramienta debería ocultar: el harness de mantenibilidad es más fácil que el de comportamiento. Podemos detectar una dependencia prohibida. Es mucho más difícil demostrar que el producto hace lo que el usuario necesitaba si nadie definió bien esa necesidad.

Simon Willison: no es vibe coding si sigues siendo responsable

Simon Willison propuso el término vibe engineering —hoy prefiere agentic engineering— para diferenciar la producción responsable del prototipo que “parece funcionar”.

Su lista suena menos futurista que disciplinada:

pruebas automatizadas estables;
plan antes de implementar;
documentación y control de versiones;
lint, tipos y automatización;
cultura de revisión;
QA manual;
preview antes de producción;
criterio para decidir qué delegar.

En 2026 reconoció que ya no revisa toda línea rutinaria. También señaló el peligro: cada acierto aumenta la confianza y puede normalizar omitir controles justo cuando llega el cambio excepcional.

Su antídoto más simple es una instrucción de cuatro palabras: “First run the tests”. Obliga al agente a descubrir el circuito de verificación antes de modificar y le enseña dónde están los ejemplos del sistema.

Más importante todavía: los agentes imitan patrones existentes. Una suite clara genera pruebas nuevas más claras; una base llena de mocks tautológicos produce más del mismo ruido. El repositorio es parte del prompt aunque nadie lo pegue en la conversación.

El punto de convergencia: no revises volumen, revisa incertidumbre

La discusión “leer o no leer” está mal planteada. La unidad correcta no es la línea de código, sino la incertidumbre residual multiplicada por el impacto.

Una modificación de CSS con preview visual no merece el mismo control que un cambio de autorización. Un mapper generado y cubierto por contratos no merece el mismo tiempo que una migración irreversible.

Riesgo	Ejemplos	Evidencia automática	Intervención humana
Bajo	documentación, estilos, boilerplate, refactor mecánico	build, lint, snapshots, inspección visual	revisar intención y una muestra del diff
Medio	reglas de negocio, endpoints, integraciones reversibles	unitarias, integración, contratos, SAST, límites de arquitectura	revisar lógica, tests y decisiones no obvias
Alto	auth, pagos, PII, migraciones, criptografía, concurrencia	pruebas independientes, property/mutation tests, staging, rollback	revisión línea por línea por alguien competente

El tamaño del diff no decide el riesgo. Cambiar un carácter en una política de autorización puede ser más grave que generar 2,000 líneas de tipos.

Esta matriz también corrige una regla demasiado absoluta que hemos defendido antes: “nunca subas código que nadie leyó”. Sigue siendo un buen valor por defecto cuando el sistema no tiene sensores. Con un harness maduro puede sustituirse, para trabajo de bajo riesgo, por “nunca subas un cambio cuya confianza no puedas explicar”.

La escalera de confianza para agentes

Un gauntlet útil no es una pila de logos. Es una secuencia en la que cada capa responde una pregunta diferente.

1. Intención y aceptación

Define qué debe cambiar, qué no debe cambiar y cómo reconocer éxito. La aceptación debe nacer del dominio, no de la implementación que propuso el agente.

2. Alcance y permisos

Limita archivos, credenciales, red y acciones destructivas. Git, worktrees y commits pequeños hacen reversible la exploración. Los controles de acceso no son prompts.

3. Estructura

Types, linters, SAST, secretos, dependencias y fitness functions detectan errores baratos. Sus mensajes deben decir cómo corregir; así el agente cierra el bucle sin esperar al humano.

4. Comportamiento

Combina unitarias con integración y contratos. Una prueba que mockea exactamente lo que luego afirma sólo verifica su propio montaje.

5. Calidad de las pruebas

Cobertura muestra huecos. Mutation testing pone a prueba las aserciones. Property-based testing explora invariantes con muchos datos. Casos de incidentes históricos evitan resucitar fallas conocidas.

6. Evaluación humana

Revisa el output que importa: UX, contrato, comportamiento adverso, diseño y riesgos. Lee línea por línea cuando el impacto o la novedad lo justifican.

7. Producción reversible

Preview, feature flags, canary, métricas y rollback reconocen una verdad incómoda: ninguna suite reproduce producción por completo.

¿Quién prueba las pruebas que escribió el mismo agente?

Ésta es la objeción más fuerte al enfoque de Uncle Bob. Si el agente interpreta mal el requisito, puede escribir código y tests coherentemente equivocados. Todo queda verde.

Hay cinco defensas prácticas:

Oráculo independiente. Una persona, fixture aprobado, contrato externo o implementación previa define salidas esperadas sin copiar el código nuevo.
Aceptación antes de implementación. El caso Gherkin expresa una obligación del negocio y se revisa antes de entregarlo al agente.
Mutation testing. Comprueba si las aserciones detectan cambios plausibles.
Separación de contexto. Un segundo revisor recibe especificación y diff, no la justificación completa del autor; reduce la tendencia a repetir su narrativa.
Prueba adversarial. Límites, permisos, duplicados, reintentos, fallas parciales y datos corruptos merecen casos explícitos.

Ejemplo:

Feature: reintentos de cobro idempotentes

  Scenario: el proveedor repite un webhook ya procesado
    Given existe un pago confirmado con id externo "pay_123"
    When recibimos de nuevo el webhook "pay_123"
    Then no se crea un segundo movimiento contable
    And queda una traza auditable del reintento

El agente puede elegir tabla, índice o clave idempotente. No puede redefinir que duplicar dinero sea aceptable.

Un kit mínimo que puedes integrar hoy

Publicamos una plantilla descargable de gauntlet para código con IA con contrato para AGENTS.md, scripts, workflow de Gitea Actions, caso Gherkin, matriz de riesgo y Definition of Done.

El núcleo cabe en cuatro piezas.

1. Una interfaz estable de comandos

{
  "scripts": {
    "check:fast": "npm run typecheck && npm run lint && npm test",
    "check:deep": "npm run check:fast && npm run test:e2e && npm run test:mutation"
  }
}

El detalle varía por stack. La interfaz permite que personas, agentes, hooks y CI ejecuten el mismo contrato.

2. Un contrato explícito en `AGENTS.md`

Antes de terminar:
- ejecuta `npm run check:fast`;
- no desactives tests ni reduzcas umbrales para hacerlos pasar;
- reporta comandos ejecutados y riesgos pendientes;
- pide aprobación antes de tocar auth, pagos, PII o migraciones.

Si quieres diseñar el archivo completo, usa nuestra skill funcional de AGENTS.md como programa.

3. Gates en infraestructura limpia

El agente ejecuta controles durante su sesión. CI los repite desde un checkout limpio. Los checks costosos —mutación completa, dependencias, arquitectura— pueden ir en pull request, nocturnos o por cambios críticos.

4. Una política de escalamiento

El agente debe saber qué puede resolver, qué debe reportar y dónde tiene que detenerse. Autonomía sin límites produce velocidad; límites sin feedback producen burocracia. El diseño bueno combina ambos.

Mutation testing: comandos de arranque

Herramientas actuales y documentación oficial:

Ecosistema	Herramienta	Inicio
JavaScript / TypeScript	StrykerJS	`npm init stryker@latest` → `npx stryker run`
Python	mutmut	`pip install mutmut` → `mutmut run`
Java / JVM	PIT	`mvn test-compile org.pitest:pitest-maven:mutationCoverage`
.NET	Stryker.NET	`dotnet stryker`

Empieza por archivos cambiados o lógica crítica. Revisa mutantes supervivientes; no conviertas el mutation score en otro KPI que el equipo aprende a maquillar.

Métricas que sirven como sensores, no como objetivos

Señal	Qué revela	Cómo se engaña
Cobertura	código nunca ejecutado por pruebas	ejecutar sin afirmar nada útil
Mutation score	sensibilidad a defectos artificiales	tests acoplados a detalles triviales
Complejidad	zonas difíciles de razonar	partir funciones sin mejorar el modelo
Tamaño del diff	superficie visible del cambio	esconder riesgo en configuración o generación
Defectos escapados	brechas reales de verificación	no registrar incidentes o severidad
Change failure rate	estabilidad de entrega	agrupar despliegues o redefinir “falla”

Una métrica es una linterna, no una cuota. La pregunta no es “¿llegamos a 90%?”, sino “¿qué incertidumbre importante sigue fuera de la luz?”.

Plan de adopción en tres horizontes

Hoy

Documenta cómo instalar, ejecutar tests y levantar el sistema.
Haz que el agente corra la suite antes de tocar nada.
Define zonas de aprobación obligatoria.
Añade typecheck, lint y tests a un comando único.

Esta semana

Escribe aceptación independiente para los flujos críticos.
Repite gates rápidos en CI limpio.
Añade escaneo de secretos y dependencias.
Habilita preview o staging reproducible.

Este mes

Introduce mutation testing incremental.
Codifica límites de módulos y dependencias.
Convierte los tres fallos repetidos más comunes en guías o sensores.
Mide defectos escapados y tiempo de recuperación, no líneas producidas.

No necesitas esperar a una plataforma de agentes. Un repositorio comprensible, scripts deterministas, CI y una política de riesgo ya forman un harness.

Preguntas frecuentes

¿Es responsable subir código que nadie leyó?

Puede serlo en cambios de bajo riesgo si la intención está clara, la evidencia es independiente, los controles son fuertes y el despliegue es reversible. En cambios de alto impacto, la lectura competente sigue siendo una capa necesaria.

¿Las pruebas generadas por IA son confiables?

Son útiles, no autosuficientes. Deben partir de aceptación revisada, imitar buenos patrones, fallar por la razón correcta y someterse a integración, mutación o casos adversariales según el riesgo.

¿Cuánta cobertura necesito?

No existe un porcentaje universal. Google recomienda ajustar profundidad por criticidad, frecuencia de cambio, vida útil y complejidad. Usa cobertura para encontrar huecos, no como prueba de calidad.

¿Mutation testing debe correr en cada commit?

No necesariamente. Es más costoso que una suite normal. Puede ejecutarse sobre cambios, lógica crítica, pull requests seleccionados o de noche.

¿Esto elimina el code review?

No. Cambia su presupuesto. La automatización absorbe formato, tipos, estructura y regresiones conocidas; la persona concentra atención en intención, arquitectura, riesgo y excepciones.

La síntesis: responsabilidad sin mecanografía

Los referentes no están anunciando el fin de la ingeniería. Están separando ingeniería de teclear.

Uncle Bob lleva la idea al extremo: si el gauntlet es suficientemente bueno, no necesita leer cada línea. Kent Beck protege los bucles cortos y el juicio de diseño. Fowler conserva la responsabilidad humana. Böckeler convierte esa responsabilidad en guías y sensores. Willison recuerda que los agentes amplifican tanto las buenas prácticas como la falsa confianza.

La regla que vale la pena llevarse no es “deja de leer código”. Es más exigente:

Diseña un sistema donde puedas explicar por qué confías en cada cambio, cuánto daño podría causar y qué lo detendría si estuviera mal.

Cuando no puedas responder, lee el código, mejora la prueba o reduce la autonomía. Cuando el mismo fallo ocurra dos veces, deja de corregirlo sólo en conversación: conviértelo en una guía o un sensor.

Ahí empieza el desarrollo con IA como ingeniería.