Solo el 33% de los desarrolladores confía en las respuestas de la IA: cómo enseñar a un agente a trabajar con especificaciones

«Implantemos IA y en seis meses sobrará la mitad del equipo»: el autor de este análisis en Habr oye esta idea de los directivos con demasiada frecuencia. Imaginan que el agente recibe la tarea en un solo prompt, escribe el código, lo prueba él mismo y lo despliega, y a las personas solo les queda pulsar Merge. La realidad es otra.

Supongamos que pide al agente acelerar el procesamiento de devoluciones en una tienda. El agente elimina una lectura repetida «innecesaria» de la base de datos y los tests salen en verde. Pero con peticiones paralelas el cliente recibe más dinero del que pagó: esa lectura protegía una regla de negocio y nadie se la había comunicado al agente.

Por eso, en la encuesta de Stack Overflow 2025, solo el 33% de los desarrolladores confía en las respuestas de la IA. El autor propone una solución: trabajar con especificaciones (SDD, spec-driven development). Primero se describe qué debe hacer el código, y después se escribe y se verifica contra esa descripción.

Para ello utiliza el framework OpenSpec.

Por qué las demos engañan

En una demo, el agente monta un CRUD o acelera una consulta SQL en cinco minutos. Una tarea así no tiene historia y está claro cómo es el resultado correcto. En un sistema real hay integraciones y reglas que no están escritas en ninguna parte: el agente no sabe qué cliente lee ese campo. Lo que falta, lo completa por su cuenta, y el código resulta verosímil, pero no necesariamente correcto.

Las cifras de Stack Overflow 2025 lo confirman. El 84% de los desarrolladores usa la IA o planea usarla, pero solo el 33% confía en la precisión de sus respuestas y el 46% no confía. La queja más frecuente, en el 66% de los casos, son las soluciones que son casi correctas, pero no del todo, y el 45% dice que depurar el código generado lleva más tiempo. Los autores del informe DORA 2025 describen la IA como un amplificador: en los equipos fuertes potencia sus puntos fuertes y en los débiles, sus problemas.

Una prueba sencilla para un directivo: antes de planificar recortes, que complete con la IA una de sus propias tareas reales de principio a fin, es decir, diseñar una funcionalidad, describir los requisitos, obtener el código, verificarlo y llevarlo a producción. En un par de días se verá que la IA acelera el trabajo, pero que decidir si está bien hecho sigue siendo cosa de una persona.

Especificaciones en lugar de tickets de una línea

Un ticket de una línea el agente lo completa con suposiciones propias; con una especificación completa, con restricciones y casos límite, trabaja dentro de unos márgenes definidos. GitHub Spec Kit, publicado en abierto en septiembre de 2025, sigue un enfoque similar. Su mantenedor principal, Manfred Riem, comparó al agente con un becario muy capaz y rápido que necesita unos requisitos claros y un mentor.

OpenSpec es un framework ligero: las especificaciones están en el repositorio, junto al código, en Markdown corriente. Es compatible con más de 30 herramientas, entre ellas Claude Code, Cursor y GitHub Copilot. La carpeta openspec/ tiene tres partes: specs/ describe cómo funciona el sistema ahora, changes/ guarda los cambios propuestos (proposal, design, tasks y deltas de requisitos) y config.yaml aporta el contexto del proyecto, que se entrega al agente al crear los artefactos.

Los requisitos se escriben con las palabras clave SHALL/MUST y con escenarios GIVEN/WHEN/THEN. Por ejemplo, para una devolución parcial: la suma de todas las devoluciones de un pedido MUST NOT superar lo pagado, y una segunda petición con la misma clave de idempotencia no crea una segunda devolución. El ciclo consta de tres comandos: /opsx:propose crea el plan, que se revisa antes de escribir el código; /opsx:apply implementa las tareas; /opsx:archive incorpora los deltas a las especificaciones principales. La siguiente tarea arranca ya con una imagen actualizada del sistema.

Contexto, invariantes y skills

El agente llega al proyecto cada vez como un novato en su primer día, así que conviene mantener junto al código una descripción del sistema: los límites del producto, los procesos de negocio, los pipelines de CI/CD, el glosario y los invariantes, es decir, las reglas que no se pueden romper en ningún refactor. Los invariantes son lo que más se subestima, y de ahí la historia de las devoluciones. El glosario resuelve un problema parecido: el analista escribe «cancelación», pero en el código existen Refund, Reversal y Cancellation, y sin un diccionario el agente elegirá al azar. El autor propone incluir la actualización del contexto en la Definition of Done, al mismo nivel que los tests.

Los skills son instrucciones reutilizables del tipo «cómo escribimos una migración» o «cómo se revisa un PR». El skill review-against-spec contrasta cada escenario del delta con el código y los tests, comprueba que los invariantes no se hayan debilitado y devuelve una lista de discrepancias sin hacer correcciones por su cuenta. Ante la petición «mira si todo está bien», el agente suele responder que sí, mientras que una checklist le obliga a buscar. La última palabra en la revisión sigue siendo de una persona.

Personas y el bucle de bugs

Las especificaciones no sustituyen la competencia: un júnior ve código que compila y pasa los tests, y un desarrollador con experiencia ve en él una condición de carrera o un invariante vulnerado. Una señal de alarma es el empleado intermediario, que reenvía el ticket al agente y manda el resultado a revisión sin leerlo. Entonces toda la verificación recae en el líder, que se convierte en un cuello de botella.

Durante la implantación hace falta un mentor con experiencia en SDD: configura las reglas y los skills y enseña al equipo a escribir especificaciones y a revisar código generado por IA. El autor lo compara con un scrum master: es un rol temporal, pero sin él la metodología se diluye en un «si ya tenemos Cursor».

Además, el autor advierte contra el antipatrón de «una persona, cuatro roles»: analista de negocio, analista de sistemas, desarrollador y tester en una sola persona. Cada rol verifica a los demás, y sin formación ni control externo esas verificaciones desaparecen. Y una especificación débil la IA la implementa tan rápido como una buena.

Sin un proceso, el equipo reescribe partes del sistema con cada bug en producción y genera nuevos bugs. La salida es averiguar, después de cada error, qué le faltó al agente: contexto, una regla o una comprobación en el skill. Lo que falta se añade y se pasa por revisión, como un PR normal. Si solo se corrige el código, el agente repetirá el mismo error en la siguiente funcionalidad.