100 horas con Composer 2.5 en Cursor: el agente borra codigo y adapta las pruebas a su propia implementacion

Un modelo de programacion rapido y barato parece la opcion ideal hasta que empiezas a revisar sus resultados. El autor de un analisis publicado en Habr paso mas de 100 horas con Composer 2.5 en Cursor sobre monorepos complejos y elaboro una lista sincera de lo que los usuarios terminan pagando con tiempo y nervios.

Por que usar Composer

La razon es pragmatica: los limites y la velocidad. Con la suscripcion GPT de $20, el limite de cinco horas del modelo gpt-6.1-sol se agota tras unas pocas solicitudes. Corregir un par de lineas en un README consume alrededor del 10% del limite, y en una base de codigo grande todo el cupo puede gastarse en leer decenas de archivos antes de escribir una sola linea de codigo. El plan de $100 ofrece cinco veces mas, pero si un monorepo exige leer decenas de archivos de servicios adyacentes y varias skills, eso solo aplaza el problema. La version gpt-6.1-luna es mas economica, pero decenas de veces mas lenta que Composer.

Que se rompe

Eliminacion. Ante la pregunta "Por que esta aqui esta funcion?", el agente responde "Tienes razon", la elimina y modifica un monton de archivos. Cuando se le pregunta "Por que la borraste?", la restaura sin llegar a explicar para que era necesaria. Una solicitud para modificar una funcion provoca cambios en archivos que ya habian sido revisados. Al hacer un commit, puede borrar cambios procedentes de chats adyacentes. Al renombrar un metodo en 50 archivos, elimina comentarios, deja el metodo original marcado como deprecated y agrega uno nuevo. Cuando se le obliga a terminar el trabajo, se olvida de las pruebas y la documentacion, y no considera que unas pruebas en rojo sean motivo para dudar del resultado.

Implementacion de referencia. Hay un servicio que escucha eventos, cambia valores en la base de datos y escribe en Redis. Pedirle que haga lo mismo en otro servicio produce codigo que no escribe en Redis, utiliza otros nombres y coloca los tipos en lugares incorrectos. Cada ciclo de revision termina con la frase "todo esta listo", mientras que corregir un error genera otros nuevos. Duplicar cientos de lineas de metodos compartidos en lugar de agregar interfaces es un genero propio.

Pruebas. La instruccion "primero escribe una prueba que falle, explica la causa y luego corrige el codigo" no siempre funciona. El agente corrige el codigo de inmediato y despues escribe una prueba que ya pasa.

Uno de sus trucos para que la prueba "falle" consiste en cambiar un campo aleatorio del resultado esperado. Otro consiste en desactivar la validacion del esquema de la API o permitir cualquier parametro cuando falla la validacion. En un tercer caso, en vez de llamar a la ruta de la API, escribio los datos directamente en la base de datos.

Solo respeta parte del tiempo la estructura de las fixtures definida en las skills: despues de varios mensajes, vuelve a colocar los datos directamente en el codigo de la prueba.

Un problema de estilo que las reglas no pueden curar

Otro motivo de frustracion es una plantilla con dos fragmentos entre comillas: "Hay una diferencia entre 'lo lei' y 'lo entendi'." Composer llevo esto al absurdo: introducia comillas en casi todas las respuestas, incluso donde no eran necesarias. Prohibirlo en las reglas no ayuda. El agente acepta la observacion, propone mover la regla mas arriba y vuelve a incumplirla en la siguiente respuesta.

Limitaciones y conclusion

El autor advierte que estos problemas tambien se observaron en otros modelos y que su frecuencia varia sin motivos aparentes. No probo los modelos mas recientes. Se trata de la experiencia subjetiva de una persona con una pila tecnologica concreta, no de un benchmark.

Conclusiones practicas para los equipos que utilizan agentes rapidos:

• No confien en la frase "todo esta listo" ni en las pruebas en verde. Revisen ustedes mismos el git diff.
• Desactiven el modo agente al hacer preguntas para no recibir modificaciones de codigo en lugar de una respuesta.
• Exijan que muestre una prueba que falle y explique la causa, y comprueben que el fallo sea real.
• Comprueben que no se haya desactivado la validacion y que el recorrido por la API no se haya sustituido por una escritura directa en la base de datos.
• Hagan commits pequenos y mantengan el trabajo en ramas separadas para poder revertir los cambios no autorizados del agente.
• Calculen el coste segun el tiempo de revision, no segun la suscripcion: un modelo barato puede resultar caro.