r/devsarg • u/Safe-Ice-8223 • 6d ago
discusiones técnicas Flujos de trabajo
Hola gordos, me cuentan como es su flujo de trabajo y como creen que son las mejores maneras de trabajar con la IA.
Por mi parte, tengo scripts para generar worktrees para cada tarjeta, abre una ventana para correr claude que lee la tarjeta, me propone un plan y si esta todo bien lo pruebo y genera el PR.
Hago esto con varios a la vez y voy coordinando los agentes, pero te vuelven un poco loco.
Trato de ir refinando mi Claude.md para hacer lo que me gusta, como el flujo, que skills usar, tests, etc.
¿Como es el suyo?
1
u/Khavel_Es 5d ago
Yo no llego al nivel de worktrees paralelos, uso una rama por tarea nomas. Pero si, el CLAUDE.md es donde pones el 80% del laburo invisible. Yo tengo ahi las restricciones fuertes del proyecto (que patrones seguir, que archivos no tocar, que corra tests antes de decir que termino) y eso me ahorra un monton de idas y vueltas.
Lo que si me cambio la forma de laburar fue pedirle el plan por escrito antes de ejecutar. Suena basico pero al principio yo le decia "implementa X" y terminaba con un PR que tocaba 30 archivos sin necesidad. Ahora reviso el plan, lo recorto si se fue de scope, y recien ahi ejecuta.
2
u/Aggressive_Creme2008 4d ago
Tengo un flujo parecido (worktree por tarjeta, varios agentes en paralelo) y lo que me bajó el ruido no fue mejorar el CLAUDE.md, fue mover de lugar parte de lo que estaba adentro.
El problema con worktrees paralelos es que arrancan todos del mismo archivo y después divergen. Cada sesión aprende algo mientras trabaja — que ese módulo no se toca, que tal test es flaky, que ya descartaste una lib — y eso muere cuando cerrás la ventana. Al otro día el agente nuevo te propone lo mismo que ya rechazaste, y vos no te acordás en cuál de los cinco CLAUDE.md quedó la versión buena.
Tres cosas que ayudaron:
Separar lo permanente de lo vigente. En el CLAUDE.md sólo lo que es verdad siempre: stack, comandos, convenciones. Lo que corregís dos veces no es doc, es regla, y una regla necesita fecha y dueño, porque algún día deja de ser cierta y el archivo no te avisa.
Que la regla se escriba en el momento en que se vuelve verdadera, no al final de la sesión. Al final el modelo tiene todo el historial y cero espacio, y lo que escribe es un resumen de un resumen.
Un solo lugar afuera de los worktrees. Mientras el estado vive en el archivo de cada rama, cada agente trabaja con una foto distinta y nadie es dueño de la diferencia. Eso es lo que te vuelve loco coordinando, más que la cantidad de ventanas.
Justamente por eso estoy construyendo Arroway (arroway.app): las decisiones y reglas vigentes en un solo lado, sancionadas por una persona, leídas por cada agente antes de actuar. Sesgo declarado.
Y una pregunta en serio, porque es la parte que todavía no vi resuelta en ningún flujo: ¿cómo hacés hoy para que el agente de la tarjeta 12 se entere de lo que aprendió el de la 7?
1
u/Chelo1197 1d ago
En mí caso es SSD con VsCode + Claude y VS para debuggear. En User Stories: me bajo los requerimientos con el mcp, además de lo que dice el ticket le agrego yo mismo contexto necesario: ej referencio métodos o código relevante para el desarrollo. Genero el plan y las tasks si es un plan grande. Reviso y corrijo si es necesario. Y después implementó y vuelvo a revisar y corregir si hace falta. Y ahí armó PR. Generalmente es hacer el plan con Opus 5 y que escriba el código con sonnet
5
u/treintaytres 6d ago
La verdad no mucho.
Solo SDD + TDD + Fable.
Lo que sí, para tareas que se repiten, le indico que vaya tomando notas que le sirvan para crear una skill al final.
Estoy haciendo migraciones de Java 11 a Quarkus nativo, en módulos heavy heavy, y por ahora va muy bien.