Un desarrollador reparte su proyecto entre tres agentes de código a la vez
Relata en un blog cómo pasó de once años con WebStorm a Cursor y por qué acabó repartiendo el trabajo entre varios agentes con sesiones separadas de desarrollo y revisión.
Un desarrollador ha contado en Dev.to que trabaja con tres agentes de código distintos sobre el mismo proyecto y que, aun así, le cuesta que el resultado sea consistente. Lo cuenta como experiencia personal, sin métricas ni comparativas: es el relato de un ingeniero, no un estudio. Pero describe un patrón que a más de uno le va a sonar.
El texto arranca con una fidelidad rota. El autor llevaba once años con WebStorm y presumía de configuración. Un amigo le enseñó Cursor, lo descartó por parecerle otro fork de VS Code, y una semana después se dio cuenta de que iba más lento que sus compañeros. Al probarlo, canceló la suscripción de once años en media hora.
Lo que le enganchó fue el salto de velocidad: tareas que le llevaban seis o siete horas —autenticación de API con caché en el borde, por ejemplo— salían resueltas en veinte minutos, con tests unitarios, build, lint, formato y documentación actualizada. Durante las primeras dos semanas, dice, cerraba en días funciones que antes le ocupaban semanas.
El problema no estaba en el prompt
El entusiasmo se torció cuando esas funciones llegaron a producción. Cada pieza concreta que había pedido parecía terminada, pero el conjunto se rompía en cuanto lo usaba alguien de verdad. El autor repasa las excusas habituales —el prompt, la configuración, que el código ya venía mal— y concluye que lo que faltaba era otra cosa: comprensión del dominio, casos límite, el encaje de la función en el producto.
Su respuesta fue repartir el trabajo entre varios agentes. Cursor permite abrir sesiones distintas y cambiar de modelo en cada una, así que montó una para desarrollo y otra para revisión, con estilos de prompt diferentes a propósito, buscando que una ejerciera de red adversarial contra la otra. El prompt de la sesión de desarrollo era este:
Help me build features while following rules and guidelines that I've setup. If you have any questions or sense ambiguity, discuss before jumping into code.
La sesión de revisión la configura para que cada cambio pase por tres filtros: que la implementación sea sólida a nivel estructural, que los tests incluyan casos funcionales adversariales y que el flujo de extremo a extremo se sostenga. Menciona también el uso de skills como "grillme", "frontend" o "architecture".
Ahí acaba lo aprovechable y empieza lo opinable. No hay cifras de productividad medidas, ni versiones, ni nombres de modelos, ni código que se pueda auditar: todo son impresiones de un usuario. Lo interesante es el diagnóstico, que coincide con una queja extendida entre quien mete agentes en proyectos reales: el agente resuelve la tarea y pierde el sistema. Que separar sesiones y forzar una revisión adversarial arregle eso está por ver; el autor, de momento, sigue con tres.
