Un setup de IA, dos mundos: cómo uso agentes de IA como Tech Lead y como emprendedor

Antes escribí sobre qué funciona de verdad con la IA en el flujo de trabajo del desarrollador. Ese artículo trataba de principios. Este trata del setup en sí: las herramientas que corren en mi máquina todos los días, cómo el mismo setup sirve a dos contextos muy distintos y las reglas que sigo para que siga siendo una herramienta y no un riesgo.

Los dos contextos son mi trabajo como Tech Lead y Arupo, la empresa que estoy construyendo como socio, además de algunos proyectos personales. Restricciones muy diferentes, un solo ingeniero, una sola laptop.

La base: configurar una vez, usar en todos lados

El error más grande que veo es tratar cada herramienta de IA como una isla: unas instrucciones en un editor, otros hábitos en otro, nada compartido entre ellos. Yo fui por el camino contrario. Hay una sola base, y todos los agentes se apoyan en ella.

• Un harness compartido. Uso Gentle AI para darle a cada agente el mismo flujo de trabajo, la misma persona y las mismas reglas de revisión. Está configurado para Claude Code, Codex, OpenCode, Gemini y Copilot. Abra el agente que abra, trabaja igual.
• Memoria persistente. Engram guarda decisiones, correcciones de bugs, descubrimientos y preferencias entre sesiones y entre agentes. Cuando vuelvo a un proyecto después de dos semanas, el agente no arranca de cero, y yo tampoco.
• Un mapa del código. Codegraph indexa cada repositorio para que un agente entienda la estructura sin leer archivo por archivo. Eso importa cuando el código es grande y la ventana de contexto no lo es.
• Documentación actualizada. Context7 les da a los agentes la documentación vigente de las librerías que uso, en lugar de la versión que memorizaron durante el entrenamiento.
• Una segunda terminal de IA. Pi, con Gentle Shell, es donde corro el trabajo orquestado más largo, con perfiles para distintos modelos.
• Un guardián en los commits. Un revisor previo al commit revisa los cambios antes de que entren.
• Un entorno cómodo. Ghostty, Starship y los dotfiles de Gentleman. Parece cosmético, pero ahí se pasa el día entero.

Ninguna de estas piezas es mágica por sí sola. El valor está en que están conectadas: las mismas reglas, la misma memoria, la misma forma de trabajar, sin importar el agente ni el proyecto.

Dos mundos en una sola máquina

Esta es la parte de la que casi nadie habla. Mi trabajo y mi empresa nunca deben mezclarse. Cuentas distintas, identidades distintas, reglas distintas sobre qué puede salir de la máquina.

Por eso la separación es automática, por carpeta. Cuando entro a la carpeta de proyectos personales, se activan solos el perfil personal de IA y mi identidad personal de git y SSH. Cuando entro a la carpeta de trabajo, toman el control el perfil corporativo de IA y la identidad corporativa de git. No tengo que acordarme de cambiar, y ese es justamente el punto: una regla que hay que recordar es una regla que tarde o temprano se rompe.

No es perfecto, y sé dónde están los huecos. La CLI de GitHub, por ejemplo, no cambia de cuenta por carpeta; usa una sola sesión global. Conocer los huecos de tu propio setup también es hacerte cargo de él.

En el trabajo: liderar dentro de las restricciones

Una empresa tiene reglas sobre herramientas y datos, y existen por buenas razones. Mi regla es simple: la forma de trabajar viaja conmigo, y las políticas de la empresa deciden qué herramientas puedo usar. Adapto el setup a esas políticas, nunca al revés.

Pero el cambio más grande en el trabajo no es técnico. Es cómo uso mi tiempo como Tech Lead. Los agentes se llevan buena parte del trabajo mecánico: explorar un servicio desconocido, preparar el borrador de una migración, escribir los tests aburridos. Eso me deja más tiempo para lo que realmente le toca a un Tech Lead: decisiones de diseño, revisiones de código, destrabar al equipo, incidentes y postmortems.

Hay algo que no cambia: la responsabilidad sigue siendo humana. Un agente puede proponer un cambio en un servicio de producción. El que responde por él a las 3 de la mañana soy yo.

En Arupo: velocidad sin bajar el estándar

En mi propia empresa la restricción es la opuesta. No hay reglas corporativas, pero hay muy poco tiempo y un equipo muy chico. La IA es lo que permite que un equipo chico entregue como uno más grande, siempre que el estándar de calidad no baje.

El mejor ejemplo es el sitio que estás leyendo. En unas pocas sesiones de trabajo pasó por:

• Un rediseño completo, con versiones en inglés y en español.
• Una limpieza de SEO.
• Endurecimiento de seguridad: una Content Security Policy generada en el build, con un chequeo que hace fallar el build si a un script inline le falta su entrada.
• Una migración de Astro 5 a Astro 7.
• Una revisión de accesibilidad para cumplir el contraste WCAG AA, y una auditoría de dependencias llevada a cero vulnerabilidades conocidas.

Cada uno de esos cambios salió en su propio pull request, con deploys de preview, antes de llegar a producción. Los agentes escribieron la mayor parte del código. Yo tomé cada decisión que importaba: qué actualizar y qué dejar como estaba, qué trade-off de seguridad aceptar, cuándo algo estaba listo para mergear.

El mismo setup corre mis otros proyectos: productos personales de finanzas y fitness, una tesis y los distintos repositorios detrás de Arupo.

El flujo que lo une todo

Las herramientas son la parte fácil. Lo que hace que esto funcione es el proceso que sigo con ellas, igual en los dos mundos:

1. Aclarar primero. Si el pedido es ambiguo, el agente pregunta antes de escribir una sola línea.
2. Dimensionar la tarea. Los cambios chicos y bien entendidos se hacen directo. Los grandes se siguen con tareas.
3. Escribir la especificación. Un cambio grande tiene su documento: los requisitos citados tal como los dije, una lista numerada de tareas y un registro de decisiones. Cualquiera, humano o agente, puede retomar desde ahí.
4. Tests primero. Cuando el comportamiento se puede testear, el test que falla va antes que la corrección.
5. Commits chicos. Porciones revisables, nunca un diff gigante que nadie puede revisar de verdad.
6. Revisión según el riesgo. Cuando un cambio toca seguridad, datos, contratos o despliegues, lo mira un revisor independiente. Cuando no, no pago por una ceremonia que no necesito.
7. El merge lo hago yo. Hacer push, abrir el pull request y mergear siguen siendo decisiones mías. Siempre.

Lo que (todavía) no funciona

Para ser honesto:

• Las herramientas se rompen. Algunas integraciones piden volver a autenticarse, otras no logran conectarse. Un setup tan conectado necesita mantenimiento.
• La memoria se desactualiza. Una decisión guardada hace tres meses puede que ya no sea cierta. La memoria es contexto, no verdad.
• Los agentes se equivocan con total seguridad. Te dicen que un build pasa cuando no pasa, o inventan una API. Por eso cada afirmación necesita evidencia: la salida del test, el log del build, el diff.

Reflexiones finales

La IA no me convirtió en otro ingeniero. Amplificó al que ya era. Los fundamentos que aprendí en ocho años, desde la infraestructura de red hasta liderar equipos de producto, son exactamente lo que me permite dirigir a estos agentes y atraparlos cuando se equivocan.

La habilidad que importa ahora no es escribir rápido. Es saber qué pedir, reconocer cuándo la respuesta está mal y hacerse cargo del resultado. Esa parte sigue siendo, y va a seguir siendo, nuestra.