Spec-driven y 7 capas defensivas para que la IA no rompa tu código

Por qué la IA puede bajar (o subir) la calidad de tu código

La queja es recurrente: "los coding agents como Claude Code, GitHub Copilot o Cursor generan más código, pero la calidad se resiente". El ingeniero Gennaro Tedesco lo desmonta en un ensayo publicado el 20 de septiembre: no es un problema de la IA, es un problema de cómo gestionas la calidad alrededor de la IA. Si montas capas defensivas en el proceso, es posible mantener el número de bugs estable —o incluso reducirlo— mientras duplicas el output. Según Tedesco, en su propio equipo han pasado de dedicar hasta un tercio del esfuerzo al pulido post-desarrollo a una fracción mucho menor, simplemente por cambiar el orden de las operaciones.

El contexto importa: un estudio de Microsoft publicado el 1 de julio de 2026 sobre el rollout de Claude Code y GitHub Copilot CLI midió un +24% en pull requests fusionadas por ingeniero por día, con un rango probable de +14,5% a +33,7%. Quienes usaron las herramientas 5 o más días por semana vieron lifts superiores al 50%. Pero ese extra de volumen también estresa al equipo de revisión: en otra empresa analizada (802 desarrolladores, 196.212 pull requests de enero de 2024 a abril de 2026), el porcentaje de PRs con al menos una revisión humana cayó del 89% al 68% y la carga por revisor se duplicó. Más output no es gratis si tu pipeline de QA no escala.

Las 7 capas defensivas que propone el ensayo

1. Specs antes que código (spec-driven development)

Tedesco cuenta que tras adoptar desarrollo dirigido por specs —pedirle a la IA que revise requisitos y diseño técnico buscando huecos, edge cases e interacciones inesperadas con código existente— los bugs en código nuevo cayeron en picado en su equipo. La IA no se cansa y, bien promptada, es menos probable que abandone la búsqueda de problemas. El propio autor admite que a veces se pasa de celo y hay que revisar que no invente issues que no existen.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El estudio de Atlassian en TechTarget va en la misma dirección: "la etapa de coding solo consume el 15-16% del tiempo del desarrollador en el ciclo SDLC; el otro 84% es un cuello de botella". Por eso Jira Planner (lanzado en preview esta semana) integra contexto de Jira, Confluence y la codebase para generar specs técnicas estructuradas que humanos y agentes pueden leer. Ming Wu, head of engineering for DevAI en Atlassian, confirma que la ganancia de productividad con coding agents se ha estancado en 10-15% pese a una adopción superior al 90% —justamente por cuellos de botella aguas abajo.

2. Tests unitarios con cobertura >95%

Los coding agents vuelven trivial el TDD. El patrón que mejor funciona:

Pedirle al agente que diseñe los escenarios de test desde los requisitos.
Escribir los tests antes que el código.
Escribir la implementación que los pase.
Iterar hasta verde y backfillear cobertura.

Hay un matiz crítico del ensayo: no dejes que el agente escriba tests que pasen para los bugs que acaba de meter. Por eso conviene planificar primero qué debe probar el test, y luego escribirlo. Un practitioner japonés documentó el mismo flujo con Claude Code y reportó que la fricción psicológica de escribir tests primero se redujo mucho al delegar la mecánica al agente. Su consejo: instruir explícitamente "no modifiques los tests" para evitar que el modelo afloje el test en vez de arreglar la implementación.

3. Testing manual

Sigue sin tener sustituto. Que alguien recorra los edge cases como usuario real y verifique que todo funciona. Tedesco reconoce que es la capa que menos se ha acelerado con IA —y la razón por la que su propio output subió 2-3x en vez de 10x. Admite que probablemente quedan oportunidades de automatización aquí y aún no las ha explorado.

4. Tests end-to-end exhaustivos

Los E2E son los más importantes del codebase porque verifican que los cambios no rompen funcionalidades existentes desde el punto de vista del usuario final. Lo ideal: corren en los PRs, en staging y en producción después de cada deploy. Lo difícil: la IA los escribe mejor cuando tiene acceso a herramientas o servidores MCP (por ejemplo, un browser tool o acceso a logs) para debuggear fallos. Y un recordatorio clave: E2E no sustituyen al testing manual —son un check incompleto de que nada importante se rompió.

5. Quality pass por IA

Los coding agents no son buenos siguiendo instrucciones complejas en AGENTS.md o CLAUDE.md, pero funcionan mejor con pasadas separadas y específicas. Estas pasadas pueden buscar:

Issues de seguridad.
Código sobrecomplicado o duplicado.
Cumplimiento de naming, organización de archivos y formato.
Comentarios escritos en "AI-ese" en vez de inglés normal (uno de los hallazgos más graciosos del ensayo).
Code review general de lógica.

Si las integras en las skills de planificación o implementación, añade 5-15 minutos al tiempo de implementación sin atención extra. Se pueden añadir también a la revisión de PRs.

6. PR review por humanos y por IA

Para tweaks menores y bug fixes simples, las revisiones humanas pueden volverse opcionales mientras las otras capas estén en pie. Para cambios complejos, no: el autor sigue encontrando errores de big picture, interacciones adversas con otras features, implementaciones subóptimas y elecciones de palabras raras ("mint" en vez de "generate", "stamp" en vez de "set").

Sobre las reviews por IA: corre Claude y Cursor en paralelo y le sorprenden los diferentes problemas que cada uno encuentra. Puedes añadir reviews custom desde ángulos específicos (seguridad, eficiencia, interacciones con otros repos), pero ojo: la IA puede ser excesivamente puntillosa, así que conviene meter un agente adicional que pode los comentarios no significativos.

7. Monitoring y alertas en producción

Mínimo viable: alguien que revise logs periódicamente o vea grabaciones de usuario (tipo Fullstory) o dashboards de error rates y latencias. Mejor: un error tracking service como Sentry o GCP Error Reporting que detecte y deduplique errores. La mejor versión: que el propio agente diagnostique la causa raíz y abra un PR con el fix propuesto.

¿Qué significa esto para tu startup?

Si eres founder técnico o diriges un equipo de ingeniería, la conclusión operativa es incómoda: la IA no degrada la calidad por sí sola, pero degrada tu capacidad de revisarla si no escalas el resto del pipeline. El estudio de Microsoft lo demuestra: +24% en PRs viene con duplicación de carga para revisores y caída del 89% al 68% en cobertura de review humana. Más output con menos gente mirando es una bomba de relojería para producción, no un win de productividad.

Tres acciones concretas que puedes implementar esta semana:

Adopta spec-driven development en features nuevas: antes de tocar código, pídele a Claude Code o Cursor que revise los requisitos y el tech design buscando huecos, edge cases e interacciones con código existente. El coste en tiempo es bajo y, según el ensayo y el ejemplo de Atlassian, es donde más bugs se previenen.
Mete el TDD en el flujo con agentes: bloquea el patrón "test → implementación → iterar" con instrucciones explícitas. Si tu agente tiene acceso a un browser tool o logs, úsalo para E2E. Lo ideal: corre dos reviews de IA distintas en paralelo (Claude + Cursor, por ejemplo) en cada PR para cubrir ángulos diferentes.
Mide la cobertura de review humana antes de escalar AI: si hoy tu equipo ya está dejando PRs sin revisar, agregar más código generado por IA te va a explotar en producción, no te va a acelerar. La métrica a mirar no es PRs por desarrollador, sino % de PRs con review humana sustantiva. Si cae por debajo del 70-75%, frena el rollout hasta reforzar el lado de QA.

El resumen del autor lo dice todo: si estás suficientemente enfocado en calidad, es perfectamente posible duplicar la velocidad de entrega manteniendo los bugs bajo control —o incluso reduciéndolos.