Mi configuración para programar con IA: agentes, skills, terminales y worktrees

Hoy en día, rara vez programo una funcionalidad completa a mano. Los agentes han evolucionado tanto en los últimos dos años que ahora es posible describir una funcionalidad completa, cómo quieres que se organice su código, y el agente escribirá toda la lógica. Con pruebas incluidas.

Por eso tuve que preparar mi entorno de desarrollo local para trabajar más rápido e inteligentemente con distintos agentes, ya sean remotos o locales.

Sin embargo, uso menos agentes locales porque tarda más recibir respuestas de ellos y recorrer bases de código más grandes.

Agentes

Elige agentes por rol

Uso Claude o Codex para el trabajo y proyectos personales, no los dos al mismo tiempo. Mi empresa paga el acceso a uno de ellos y está de acuerdo con que lo use para proyectos personales, así que la disponibilidad también forma parte de la decisión. Ambos tienen ventajas y desventajas, pero no asigno trabajo solo por el nombre del modelo. Elijo un agente según el tipo de trabajo que necesito: investigación y planificación, implementación del día a día o revisión.

Para investigación y planificación, uso Fable o Sol cuando necesito que un agente lea documentos, cruce información y proponga una solución inicial. También son útiles cuando necesito resumir una conclusión cruzando muchos logs de distintas aplicaciones.

Para trabajo de implementación cuando ya conozco el camino a seguir, uso Sonnet o Luna (Max). A veces uso Terra en su lugar. Este es el tipo de tarea donde proporciono tanta información como sea posible: el plan, los archivos relevantes, la organización esperada de los archivos y las restricciones. Me ayuda a pasar de un plan claro a la ejecución sin tratar cada tarea como un problema de investigación.

Para revisiones, uso Terra con Opus para revisar mi código y dejar comentarios en los pull requests de otras personas. Lo importante no es usar un modelo específico para cada revisión. Es asegurar que el agente tenga suficiente contexto para seguir el cambio, entender los patrones existentes y señalar huecos antes de que el código se integre.

Skills

Scripts de Matt

Conozco a Matt desde que tomé su curso en totaltypescript.com. Ahí vi que se había metido mucho en programación con IA durante los últimos meses. Fue entonces cuando revisé las skills que estaba creando, no solo para darte un punto de vista técnico, sino también para ayudar al agente a entender realmente la funcionalidad antes de empezar a programar.

grill-with-docs

Grill with docs modificará el objetivo del agente hasta que pueda entender las reglas de negocio que quieres lograr. Una vez que se llega a un acuerdo, creará un ADR con el alcance, los objetivos y los conceptos de dominio no escritos para el desarrollo futuro con agentes. Con esta skill, la calidad y el alcance de mis funcionalidades han quedado claramente explicados, y me ha ayudado a pensar en casos límite antes de escribir el código.

Skill personalizada para commits

Una skill personal que básicamente es un conjunto de instrucciones para agrupar archivos o fragmentos según la funcionalidad y luego empezar a hacer commits. El agente te preguntará si la agrupación tiene sentido antes de hacer el commit. También te pedirá crear una rama nueva si es necesario.

Terminal

Herdr

Mi administrador de agentes de terminal favorito es Herdr. Ha ganado popularidad recientemente y, para mí, es el siguiente paso después de Tmux. El año pasado usaba mucho Tmux. Pero una vez que me cambié a Herdr, no tuve problemas creando nuevas pestañas y paneles. Ya no hubo errores durante la inicialización de la shell en la terminal, y el número de plugins crece cada día.

Organización de paneles

Uso una distribución de tres paneles desde los días de Tmux. El panel izquierdo es el más grande y lo uso para la conversación con el agente porque necesito espacio para LEER. Sí, leíste bien. Para mí, leer es la parte más importante de trabajar con un agente, de lo contrario lo veré empezar a alucinar si mis instrucciones no son suficientemente claras.

El panel superior derecho normalmente se usa para lazygit, así tengo visibilidad sobre qué archivos están modificando mis agentes. Además, si es más rápido y barato hacer el commit yo mismo, normalmente soy más rápido escribiéndolo que pidiéndole al agente que lo haga, especialmente si solo hay un par de archivos modificados.

El panel inferior derecho se usa para ejecutar comandos, builds, despliegues o cualquier otro comando de shell que quiera. También puedo ejecutarlos mediante el agente. Pero a veces, mientras el agente está pensando, prefiero tener la salida visual de un comando que estoy ejecutando.

Worktrees

Worktrees con Treehouse

Normalmente tengo tres copias del mismo proyecto en mi computadora. Algunas personas dirían que estoy desperdiciando espacio en disco. Pero creo que es un equilibrio perfecto para lo que quiero hacer.

La primera copia es para desarrollar funcionalidades. La segunda es para investigar logs, cruzar documentación y planificar. La tercera es para experimentos y hotfixes.

Además de eso, trabajo con worktrees. Hay varias formas de trabajar con worktrees, incluyendo herramientas de Claude y Codex. Puedes configurar varios agentes para empezar una investigación usando un worktree, pero tienes que mantener el enlace simbólico de las librerías instaladas, especialmente en proyectos de TypeScript, y asegurarte de tener los mismos archivos .gitignore en el proyecto original y en el worktree.

Uso Treehouse de Kunchenguid. Treehouse te permite administrar fácilmente tus worktrees con hooks y comandos útiles. Además, cuando el agente lee los comandos de Treehouse, puede entender con qué facilidad puede trabajar con él.

Treehouse tomará el commit más reciente de tu rama main o master y empezará a trabajar desde ese commit. Después puedes crear una rama nueva a partir de ese commit.

La única desventaja es que tienes que usar un comando largo:

treehouse

Pero como ya tengo conocimientos de Bash, es bastante fácil configurar alias para algunos de los comandos que más uso.

alias th="treehouse"
alias ths="treehouse status"
alias the="treehouse enter"

El otro día estaba pensando: quiero tener un solo comando para abrir una pestaña nueva de Herdr con una distribución: el 50% izquierdo como siempre, con el lado derecho dividido horizontalmente.

Y después de una sesión de programación con Codex, fue posible.

# Pestaña de worktree con Treehouse + Herdr
function treehouse_herdr_tab {
  local name="$1"
  if [[ -z "$name" ]]; then
    echo "usage: thw <name>" >&2
    return 1
  fi
  if ! exist treehouse || ! exist herdr || ! exist jq; then
    echo "thw: requires treehouse, herdr, and jq" >&2
    return 1
  fi
  if [[ -z "$HERDR_WORKSPACE_ID" ]]; then
    echo "thw: must be run from inside a herdr pane" >&2
    return 1
  fi

  local worktree_path
  worktree_path=$(treehouse get --lease --lease-holder="thw:$name") || return 1

  local tab_json root_pane right_pane
  tab_json=$(herdr tab create --workspace "$HERDR_WORKSPACE_ID" --cwd "$worktree_path" --label "🌳 $name" --focus) || return 1
  root_pane=$(jq -r '.result.root_pane.pane_id' <<< "$tab_json")

  right_pane=$(herdr pane split --pane "$root_pane" --direction right --ratio 0.5 --cwd "$worktree_path" | jq -r '.result.pane.pane_id') || return 1
  herdr pane split --pane "$right_pane" --direction down --ratio 0.5 --cwd "$worktree_path" >/dev/null
}

alias thw=treehouse_herdr_tab

Para cada worktree creado con este flujo de Treehouse, el script añade el emoji 🌳 a la etiqueta de la pestaña de Herdr. Hace que las pestañas de worktrees sean fáciles de reconocer entre el resto de mis sesiones.

Usando el alias thw <feature-name>, Herdr abrirá una pestaña nueva, dividirá los paneles y entrará automáticamente al worktree en cada uno. Así puedo empezar a experimentar o trabajar en una funcionalidad.

Notion

Notion se ha convertido en mi organizador personal para la vida diaria, incluyendo documentación técnica. A lo largo de los años, he administrado todo ahí: suscripciones personales, itinerarios de viaje, una calculadora de gastos mensuales, fragmentos de código privados y contenido copiado de internet.

Ahora que añadieron soporte para MCP, conectar mi código con Notion se ha vuelto más fácil que nunca: crear resúmenes de libros de diseño de sistemas, guardar fragmentos de patrones que puedo reutilizar en otros proyectos y redactar las primeras ideas de mis posts del blog. Todo está enlazado e incluye un agente de IA que me ayuda con la gramática antes de escribir las versiones finales de mis posts.

Conclusión

Durante el último año, mi flujo de trabajo se ha enfocado en escribir código lo más rápido posible. Todavía tengo esas herramientas instaladas, pero hoy en día mover mis flujos de trabajo hacia algo más centrado en IA se ha convertido en parte de mi rutina normal. Cruzar tanta información como sea posible y luego crear más contenido a partir de ella, código y escritura, ha sido un truco de productividad útil para mí. Espero que esto se vuelva normal para todas las personas que también se sienten cómodas trabajando con una computadora.