Quiero compartir contigo cómo estoy enfocando el desarrollo agéntico como freelance.
“”Todo empieza en la terminal.
Hace poco me pasé de WarpSe abre en una nueva pestaña a GhosttySe abre en una nueva pestaña. Hice el cambio porque quería una terminal minimalista y rápida. Siento que Warp últimamente está metiendo demasiadas funcionalidades de IA que hacen que la terminal se sienta sobrecargada.
Además, he estado probando un poco tmuxSe abre en una nueva pestaña, que me permite tener sesiones persistentes y me da más control sobre ventanas y paneles, lo cual ayuda con los cambios de contexto.
Sin embargo, también estoy probando HerdrSe abre en una nueva pestaña, que parece muy prometedor. Se siente moderno, bien diseñado y orientado a lo agéntico. ¡Además tiene soporte para ratón! Si me conoces, sabes que me encantan los atajos, pero al principio usar el ratón de vez en cuando... ¡no hace daño a nadie!
La semana que viene haré el cambio por completo (¡han sido unas semanas de trabajo bastante intensas!).
Cuando abordo el trabajo empiezo por la issue. En algunos proyectos uso GitHub Issues, en otros GitLab Issues o algún sistema de tickets. Para mí la issue es donde detallamos cuál es el problema. Me parecen mucho más útiles cuando siguen esta plantilla:
- Resumen: una explicación simple de una línea de la issue
- Problema: una exploración detallada de cuál es el problema. Aquí intento evitar dar soluciones concretas: eso debería ser parte de la PR
- Impacto: cómo de impactante sería resolver esta issue
- Aceptación: qué se considera terminado
Como ves, nada demasiado sofisticado.
Después, una vez entendida la issue, hablo con los compañeros que puedan tener más contexto o experiencia con ella si hace falta. Ser proactivo al comunicar es esencial. Además, para las comunicaciones personales evito usar herramientas de IA. Creo que el mensaje puede percibirse como menos intencional si quien lo recibe nota que se ha usado IA para escribirlo.
Creo que es una jugada inteligente definir qué áreas de un proyecto deberían estar libres de IA, donde sabemos que hay humanos detrás del teclado. Para mí, las herramientas de mensajería como Slack, el email o los comentarios de las PRs encajan de forma natural. En esencia, cualquier lugar donde necesite comunicarme con otros humanos. Usar IA para reporting, en cambio, me parece bien. ¿Tú qué opinas?
Una vez reunido el contexto, empiezo a leer el código relevante. Entender dónde va a aterrizar la nueva funcionalidad me ayuda a encontrar soluciones más robustas. Luego uso esta información para guiar a la IA.
#Programando
Cuando entiendo el código relevante y he reunido todo el contexto, empiezo con la skill /interview. Le doy todo el contexto que he recopilado y una propuesta de solución, junto con la issue. Me resulta muy útil conectar las herramientas de programación con CLIs como ghSe abre en una nueva pestaña para GitHub o glabSe abre en una nueva pestaña para GitLab. Así tu agente puede buscar issues y PRs anteriores que se te hayan podido escapar.
La skill de interview está ahí para ayudarme a traducir el contexto en un plan. Este paso intermedio me parece valioso. A menudo pierdes visibilidad de los cambios que estás haciendo cuando retocas demasiado un plan, ya que al cambiar un plan con /plan te devuelve el plan entero, no los cambios que acabas de hacer.
Cuando termina la interview, salto a /plan. Normalmente al llegar a este paso no necesito retocar demasiado. Así que puedo delegárselo al agente usando el modo auto.
Tengo skills para cada punto del proceso, y cada skill apunta al siguiente paso:
create-issuestart-issuecreate-prcleanup
Este flujo de trabajo me funciona porque dedico mucho esfuerzo a la arquitectura, las buenas prácticas y el testing del proyecto. Si no, no confiaría tanto como confío en el código generado. Esto se llama Fitness Function Driven Development, hablé de ello en el último número.
También he instruido al agente, a través de la skill start-issue, para que siempre cree una rama de git siguiendo las convenciones del proyecto y trabaje en un worktree para paralelizar el trabajo.
Para evitar el costoso impuesto del cambio de contexto, antes de planificar el siguiente bloque de trabajo me aseguro de renombrar la pestaña con lo que intento conseguir. Antes de crear la PR reviso el código. Si es una tarea grande, primero itero con el agente para crear un ejemplo pequeño y reproducible que luego pueda usarse como referencia. He usado este enfoque con mucho éxito en grandes migraciones que hace unos años habrían sido imposibles.
#Conclusión
Como has visto, este proceso es bastante lean. Me gustaría evolucionar algunas partes con bucles agénticos personalizados para comprobar la CI, por ejemplo cuando falla, o para reportar. También me interesa explorar orquestadores y técnicas más complejas, pero para mí lo que se mantiene cierto es que, para que el desarrollo agéntico ocurra, los proyectos necesitan invertir en buenas prácticas, testing y arquitectura.
¿Cuál es tu flujo de trabajo? Siéntete libre de responder, leo todos los emails.