Mi stack de desarrollo para trabajar con IA en Windows

Instalar otra herramienta de desarrollo toma cinco minutos. Mantenerla actualizada, configurarla, entender sus rarezas y conseguir que un agente de IA pueda usarla ya es otra historia.

Hace poco revisé todo lo que tenía instalado en Windows y terminé cambiando el criterio. En lugar de buscar “la mejor aplicación” para cada cosa, empecé a preguntarme algo mucho más práctico: ¿Claude Code, Codex o Gemini CLI pueden trabajar con esto sin que yo tenga que estar haciendo clic por ellos?

Ese filtro redujo bastante la lista. Mi stack original rondaba las 30 herramientas y el criterio terminó siendo bastante concreto: línea de comandos, archivos legibles, logs útiles y APIs.

La terminal volvió a ser importante

Durante años muchas herramientas intentaron esconder la terminal detrás de interfaces más cómodas.

Con los agentes de programación está pasando algo curioso: la terminal vuelve a tener ventaja.

Un agente puede ejecutar una instrucción, leer la salida, detectar un error, modificar un archivo y volver a intentarlo. Esa secuencia encaja mucho mejor con una CLI que con una aplicación diseñada alrededor de botones, ventanas y menús.

Por eso mi núcleo ahora es bastante pequeño:

• VS Code como editor principal.
• Windows Terminal para centralizar terminales.
• PowerShell 7 para automatización.
• Git para versiones y cambios.
• GitHub CLI o Azure DevOps CLI para evitar saltar al navegador.
• ripgrep para buscar texto rápido.
• jq para trabajar con JSON.

GitHub describe precisamente su CLI como una forma de llevar pull requests, issues y GitHub Actions a la terminal, reduciendo cambios de contexto: GitHub CLI.

Ese tipo de herramienta encaja especialmente bien con un agente.

Claude Code, Codex y Gemini CLI cambian la elección de herramientas

Aquí está el cambio más grande.

Antes elegía una herramienta pensando en cómo la iba a utilizar yo. Ahora también pienso en cómo la utilizará el agente.

Codex, por ejemplo, ya funciona en Windows y OpenAI lo plantea como una herramienta capaz de trabajar con archivos locales, repositorios y terminales. La aplicación actual de ChatGPT también integra Codex dentro del mismo entorno. OpenAI

Gemini CLI sigue una idea parecida. Google recomienda Node.js 20 o posterior y Windows 11 24H2 o superior para su uso en Windows. Documentación de Gemini CLI. GitHub

El punto importante no es decidir cuál de los tres “gana”.

Es preparar un entorno donde puedas cambiar de agente sin reconstruir tu forma de trabajar.

Una herramienta por trabajo

Esta regla fue la que más programas me permitió quitar.

No necesito tres clientes de API, cuatro editores y dos herramientas que hacen prácticamente lo mismo.

No significa que las alternativas sean malas. Significa que cada programa adicional introduce otra actualización, configuración y comportamiento que tanto yo como el agente tenemos que entender.

Bruno me empezó a hacer más sentido que Postman

Bruno es un buen ejemplo del tipo de herramienta que busco.

Sus colecciones se guardan como archivos de texto dentro del repositorio. Eso significa que pueden entrar a Git, tener ramas, revisiones y cambios comparables igual que cualquier archivo del proyecto.

La propia documentación de Bruno lo define como un cliente de API “Git-native” sin dependencia obligatoria de la nube. Bruno API Client. Bruno

Para trabajar con un agente eso tiene una ventaja obvia: puede leer y modificar esos archivos directamente.

Ya no tiene que aprender dónde está cierto botón dentro de una interfaz.

Playwright también encaja perfecto

Las pruebas automáticas son otra zona donde la IA puede trabajar bastante bien.

Playwright puede generar trazas que incluyen actividad del navegador, capturas y snapshots. Cuando una prueba falla, tienes evidencia concreta que el agente puede inspeccionar en lugar de decirle simplemente “no funciona”. Playwright Tracing. Playwright

Ese detalle cambia mucho el ciclo:

falló → vemos qué pasó → corregimos → ejecutamos otra vez.

Mientras más observabilidad tenga una herramienta, más útil termina siendo con IA.

Para Azure prefiero Bicep

Aquí también simplifiqué.

Trabajo principalmente con Azure, así que en mis proyectos Bicep tiene bastante sentido. Microsoft lo define como un lenguaje declarativo para desplegar recursos de Azure de manera repetible y consistente. Microsoft Learn: Bicep. Microsoft Learn

Terraform sigue siendo muy útil cuando necesitas trabajar con varios proveedores.

Pero meterlo automáticamente en cualquier proyecto de Azure puede agregar una capa que quizá no necesitas.

La pregunta que intento hacerme ahora es menos “¿qué herramienta conoce más gente?” y más “¿qué complejidad necesito realmente aquí?”.

PHP en Windows tiene una decisión incómoda

Laragon sigue siendo una de las experiencias más cómodas que he usado para desarrollo web local.

El detalle es la licencia.

Desde Laragon 7 ya no es completamente gratuito. El uso sin licencia queda reservado para fines no comerciales y el uso comercial requiere licencia. Actualmente Laragon publica una licencia comercial anual de 49 dólares por dispositivo y una perpetua de 149 dólares. Precios de Laragon. Laragon

Si haces sitios para clientes, esto importa.

La alternativa que más sentido me hace si quiero mantener el entorno gratuito es DDEV.

DDEV está pensado para entornos reproducibles, versionables y basados en contenedores. En Windows puede trabajar con WSL2 y Docker, y su documentación incluso recomienda una instalación con Docker CE dentro de WSL2 para buena parte de los usuarios. DDEV. DDEV Docs

Es un poco más técnico al principio.

A cambio, el proyecto describe su propio entorno y ese entorno puede viajar con el repositorio.

Para un agente de IA eso vuelve a ser una ventaja.

El stack que quiero no intenta ocultar lo que sucede

Ese terminó siendo el patrón.

Prefiero una herramienta que me deje ver:

• qué comando ejecutó;
• qué archivo modificó;
• qué error recibió;
• qué resultado produjo;
• y cómo repetir exactamente la operación.

Ahí es donde herramientas aparentemente pequeñas como jq o ripgrep terminan teniendo muchísimo valor.

Una interfaz bonita puede ahorrarme algunos clics.

Una herramienta automatizable puede ahorrarme el proceso completo.

¿Y las herramientas gráficas?

No estoy eliminando Photoshop, DaVinci Resolve o aplicaciones similares.

Hay tareas donde una interfaz visual sigue siendo claramente mejor.

El cambio está en no pedirle a la IA que trabaje de la forma en que peor trabaja.

Para video, por ejemplo, puedo utilizar el agente para preparar nombres, transcripciones, subtítulos, archivos y automatizaciones. FFmpeg puede encargarse de muchos procesos repetitivos.

Luego hago la parte visual donde tiene sentido hacerla manualmente.

La separación funciona bastante bien.

Lo que me llevo

Mi entorno terminó quedando menos espectacular de lo que imaginaba.

Y eso resultó ser bueno.

Ya no intento instalar cada herramienta nueva que aparece. Primero reviso si cubre algo que realmente no tengo resuelto y después veo qué tan automatizable es.

Mi filtro actual queda así:

1. ¿Tiene CLI?
2. ¿Guarda su configuración en archivos?
3. ¿Produce logs o resultados fáciles de leer?
4. ¿Se puede versionar?
5. ¿Un agente puede utilizarla sin depender de clics?
6. ¿Ya tengo otra herramienta que hace lo mismo?

Si falla demasiado en esas preguntas, probablemente no la necesito.

Conclusión

La llegada de agentes de programación me hizo cambiar una idea que llevaba años dando por sentada.

El mejor entorno ya no es necesariamente el que tiene más herramientas ni el que tiene más interfaces.

Para mí, es el que permite que yo y el agente trabajemos sobre las mismas piezas.

Archivos.

Terminal.

Git.

Logs.

APIs.

Ahí es donde Codex, Claude Code o Gemini CLI dejan de sentirse como un chat que escribe código y empiezan a funcionar como parte real del entorno de desarrollo.

Y curiosamente, para llegar ahí tuve que instalar menos cosas.