Un proyecto open source mete un verificador entre el agente de código y la API real
Kaktoos se coloca entre el agente y el endpoint para validar respuestas contra el contrato OpenAPI, partiendo de que los tests que genera el propio agente solo confirman sus propias suposiciones.
Un agente de código escribe la integración contra una API y, acto seguido, escribe los tests para esa integración. Todo pasa en verde. Y aun así puede estar mal. Ese es el problema que se plantea en un hilo de r/devops, y la razón de existir de Kaktoos, un proyecto open source que coloca un paso de verificación independiente entre el agente y la API.
El fallo es de circularidad. El agente decide que un endpoint devuelve {"total": 100}, escribe la integración esperando ese campo y después un test que también lo espera. El test confirma la suposición del agente, no el contrato del servicio. Si la API real responde otra cosa, ese verde no certifica nada: solo que dos piezas escritas por el mismo sistema están de acuerdo entre sí.
Kaktoos propone otra cadena: agente, integración, Kaktoos, OpenAPI y API real, resultado. La premisa es que la capa que verifica no puede compartir las suposiciones de quien escribió el código que está debajo. El proyecto soporta ya flujos de API de varios pasos, validación de respuestas contra la especificación OpenAPI, MCP y GitHub Actions. El código está en el repositorio.
La pregunta que queda abierta
Quien está detrás del proyecto, que lo cuenta en primera persona, reconoce que no tiene claro hasta dónde debe llegar el enfoque. La duda concreta: basta con validar el contrato, o la verificación debería comprobar también el efecto real de la operación. Por ejemplo, crear un recurso y volver a leerlo para confirmar que el estado cambió de verdad. Son dos niveles distintos. Que una respuesta encaje con el esquema no dice que la escritura haya surtido efecto en el sistema.
Sobre lo que hay construido, conviene ser prudente: lo describe el propio autor, no hay benchmarks ni una evaluación externa, y es un proyecto joven. Tampoco hay demo pública del flujo completo más allá de lo que cuenta en el hilo.
La otra mitad del asunto es cómo lo está resolviendo la gente que ya trabaja con agentes. La pregunta que lanza es qué mezcla usa cada equipo: los tests que genera el agente, tests de integración que ya existían antes, APIs mockeadas, pruebas contra el servicio real o una combinación de todo. La respuesta por defecto en muchos sitios sigue siendo la primera, y es justo la que tiene el problema de circularidad.
Merece la pena mirarlo porque el cuello de botella se está moviendo. Si los agentes escriben una parte creciente del código de integración, el trabajo caro deja de ser escribirlo y pasa a ser comprobarlo. Y un test escrito por el mismo sistema que escribió el código es una tautología con formato de pipeline de CI.
