Cada herramienta que sumo tiene que ganarse su lugar

Hoy tengo Windows porque es el equipo que tengo ahora, pero no trabajo en Windows: trabajo en Ubuntu, en Linux. El día de mañana me gustaría tener una Mac o un Linux nativo. La mayoría de la gente arranca con Windows (hoy ronda el 62% del mercado de escritorio a nivel mundial), así que escribo este post para el que está en esa mayoría y todavía no se cruzó con lo que yo me crucé.

Lo que cambió mi forma de programar no lo aprendí en la facultad. Lo aprendí en el módulo de Linux y terminal del máster full stack de ConquerBlocks. Entender cómo funciona el sistema operativo por dentro, y qué beneficio concreto le da a alguien que programa, fue el momento en que decidí modificar todo mi entorno. Mi capacidad para resolver problemas técnicos pasó a otro nivel a partir de ahí, no de forma abstracta, sino en cosas medibles: menos tiempo instalando, menos fricción para automatizar, comandos que hacen exactamente lo que dicen que hacen.

Esto no es sobre las herramientas. Es sobre que cada capa de este entorno suma algo puntual: no resuelve un problema por descarte, agrega una capacidad que antes no tenía.

Este análisis no aplica a quien recién arranca y necesita lo mínimo para escribir su primer script. Aplica al momento en que ya tenés varios proyectos corriendo en paralelo y el entorno deja de ser indiferente.

01 — La base: Ubuntu sobre Windows, no como preferencia

Aunque hoy uso Windows como sistema base, programo en Ubuntu vía WSL2. No es estética. Linux usa un kernel monolítico: los servicios centrales corren en el mismo espacio de memoria, con llamadas directas. Windows usa un kernel híbrido que separa servicios en procesos comunicados por paso de mensajes: más tolerante a fallos, pero con overhead en cada proceso que se crea.

wsl --install -d Ubuntu   # en PowerShell como administrador

Y la terminal de Linux no es un lujo de power user, es el lugar donde vivís. Los comandos base que uso todo el día son los mismos hace décadas porque son precisos: hacen una cosa y la hacen bien.

• cd proyecto: entrar a una carpeta
• ls -la: listar archivos, incluidos los ocultos
• mkdir src: crear un directorio
• rm -rf build: borrar una carpeta y su contenido
• cat archivo.txt: ver el contenido de un archivo
• grep "error" *: buscar texto dentro de archivos

Esa precisión es la diferencia con la GUI: no clickeás por menús, declarás exactamente qué querés. Y encima, instalar herramientas en Linux suele ser un one-liner: PostgreSQL, Redis, Node en cuatro comandos de apt, contra un instalador con su propio PATH cada uno en Windows.

Un detalle técnico que me costó aprender: en WSL2, si guardás los proyectos en /mnt/c/ en vez del filesystem nativo de Linux (~/), cada herramienta con muchas operaciones de archivo (npm, pip, un watcher de hot reload) sufre una penalización real de I/O al cruzar el filesystem. Mover los proyectos a ~/ es la diferencia entre un npm install de segundos y uno que se siente colgado.

02 — El circuito de trabajo real: de la terminal al código

Esto es un día cualquiera, comando por comando. Clono un repo, entro, lo abro en el editor sin soltar la terminal:

git clone git@github.com:usuario/proyecto.git
cd proyecto
code .           # abre VS Code en esta carpeta, desde la terminal

Trabajo, y cuando termino un cambio, el ciclo de git:

git status               # qué cambió
git add .                # preparar los cambios
git commit -m "feat: x"  # confirmar con un mensaje
git push                 # subir al remoto

Para que ese git push funcione sin escribir contraseña cada vez, uso claves SSH, que se generan una vez y se asocian a GitHub:

ssh-keygen -t ed25519 -C "tu-email"
cat ~/.ssh/id_ed25519.pub   # copiar esta clave a GitHub → Settings → SSH

Y cuando necesito una segunda cabeza sobre un problema, llamo a Claude Code sin salir del proyecto, escribiendo claude en la misma terminal. El agente ya está parado en la carpeta correcta, con el contexto del repo disponible.

03 — La terminal: Warp sobre la terminal por defecto

Warp no es una terminal con más colores. Organiza cada comando y su salida en bloques: unidades que podés copiar, buscar o compartir sin desplazarte por un scroll infinito. Y tiene IA nativa desde el diseño, no como plugin: entiende tu directorio actual, tu historial y los errores que generaste, y usa ese contexto para sugerir el siguiente paso. Se siente parecida a la experiencia de Mac porque corre agentes con conciencia del entorno de terminal en sí, no solo del código.

Un dato que poca gente sabe: Warp también trae un editor de código integrado: con resaltado de sintaxis, pestañas y atajos de Vim, pensado para ediciones rápidas sin salir de la terminal. No reemplaza a VS Code para mí todavía, pero ya cubre una parte de lo que técnicamente necesitaría un editor aparte.

04 — La shell: Zsh, con Oh My Zsh arriba

Zsh con Oh My Zsh suma autosugerencias (completa comandos que ya usaste) y resaltado de sintaxis (te marca en rojo un comando mal escrito antes de correrlo). Powerlevel10k agrega info en el prompt mismo: en qué rama de git estás, si hay cambios sin commitear, sin tener que correr git status para saberlo.

05 — El editor: VS Code hoy, y la decisión que tengo pendiente

Uso Visual Studio Code de siempre: es el estándar, estable, con el ecosistema de extensiones más grande. Lo abro desde la terminal con code . y me sirve como verificador visual: ver diffs, navegar archivos, revisar lo que un agente propuso antes de aceptarlo. Como verificación de código ya la tengo cubierta con Claude Code, así que VS Code hoy es sobre todo mi lente para mirar lo que se está construyendo.

Para que code . abra tu proyecto de Ubuntu dentro de VS Code hace falta la extensión WSL (la del ícono del pingüino). Sin ella, VS Code abre en modo Windows y no ve el filesystem de Linux. Con la extensión instalada, VS Code corre conectado a WSL2 y su terminal integrada es la misma terminal de Ubuntu.

Y acá está la única capa que todavía no resolví. Google lanzó Antigravity en noviembre de 2025. No es un editor con IA al costado, es un IDE agent-first: en vez de asistirte mientras escribís, centrás el trabajo en un Agent Manager donde lanzás y supervisás varios agentes que operan sobre editor, terminal y navegador a la vez. Es gratis en su preview.

La pregunta es honesta: con Claude Code como agente principal en la terminal, VS Code como lente de revisión, y Warp ya cubriendo ediciones rápidas desde la propia terminal, ¿Antigravity me agrega una capacidad real, o me duplica lo que ya tengo repartido en dos herramientas? Es un buen ejemplo de la tensión de fondo: a veces sumar un editor más es directamente innecesario, porque las piezas que ya tenés (en este caso, hasta la propia terminal) ya cumplen esa función sin que lo hayas buscado. No lo sé todavía. Mi próximo paso probablemente sea migrar a Antigravity y medirlo en un proyecto real, no adoptarlo por hype ni descartarlo por comodidad. Ese es, en el fondo, el criterio que atraviesa todo este entorno: una herramienta nueva justifica su lugar solo si suma una capacidad que las que ya tengo no cubren. La única forma honesta de saberlo es probarla contra un problema real y estar dispuesto a soltarla si no aporta.

06 — Los agentes: Claude Code como principal, con dos contrapuntos elegidos

Uso Claude Code como agente principal: con MCP (Model Context Protocol) conectando herramientas externas, plugins y skills que extienden lo que puede hacer sin tocar el core. Se instala nativo con un comando, y de los que uso a diario el que más me cambió el flujo es --continue: retoma la conversación donde la dejaste, sin volver a explicar el proyecto desde cero.

curl -fsSL https://claude.ai/install.sh | bash
# --- instalación ---
claude --version
claude doctor             # salud del entorno
 
# --- uso diario ---
claude                    # abrir el agente acá
claude --continue         # seguir la última charla
claude --resume           # elegir sesión anterior
claude -n "auth-refactor" # sesión con nombre

Pero no dependo de un solo agente, y las dos capas que sumé no son al azar.

OpenCode es un entorno similar a Claude Code, pero totalmente open source. La razón concreta por la que lo tengo instalado no es redundancia: si me quedo sin tokens de Claude en medio de algo, puedo seguir trabajando conectando OpenCode a otro modelo. Ahí es donde se vuelve interesante: no depende de un solo proveedor. Puedo apuntarlo a Codex, a Kimi (el modelo abierto de Moonshot AI, mucho más barato para tareas largas), o directamente a Ollama corriendo un modelo en mi propia máquina, sin costo de API y sin depender de internet para lo básico. El cambio es literalmente apuntar OpenCode a otro endpoint: nativo con Ollama local, o a la nube con cualquiera de los otros. Es mi red de seguridad completa: el flujo no se frena porque se acabó una cuota, ni porque un proveedor esté caído.

Gentle AI es una elección más personal, y por eso la valoro distinto. Es el ecosistema de IA de Alan Buscaglia (Gentleman Programming), que fue profesor mío en ConquerBlocks. Dio los módulos de React, React avanzado y React con TypeScript, además de Vue, Angular, Astro y el backend con Go, básicamente toda la capa de frameworks de la formación. Su ecosistema no es un wrapper genérico sobre un modelo: tiene el conocimiento de sus propios cursos integrado, así que cuando le pregunto algo, responde con el mismo criterio con el que aprendí. Junto a Engram (contexto persistente entre sesiones) y GGA (hooks de git automatizados), es la capa que más se parece a cómo pienso yo el código, porque literalmente aprendí con ese material.

Todo esto se instala sobre Homebrew: un gestor de paquetes nacido en Mac que hoy también corre en Linux (como Linuxbrew). La ventaja de fondo es la reproducibilidad: cada paquete (formula) tiene una definición versionada y verificable, en vez de un instalador suelto bajado de cualquier lado, y los repositorios de terceros (taps, como el de Gentleman-Programming, de donde sale Gentle AI) se habilitan con un paso de confianza explícito (brew trust) antes de poder instalar nada de ahí. Es la misma lógica de curaduría que aplico al resto del entorno: nada entra sin saber de dónde viene.

07 — Lo que ninguna herramienta reemplaza

Ningún agente de IA, por bueno que sea, reemplaza entender qué está pasando cuando algo falla. La semana que perdí diagnosticando un corte de red en WSL2 (conexiones HTTPS que se cerraban a mitad del TLS handshake) no la resolvió ninguna herramienta instalada. La resolvió aislar el problema capa por capa: probar con curl, descartar el DNS, llegar a que era el modo de red de WSL2. Ese razonamiento no lo delegás.

Documentar cada capa por separado, como en esta guía, es mi forma de chequear que cada una siga ganándose su lugar. Si te interesa el paso a paso completo de instalación (Windows+WSL2 o Linux nativo), pedímelo en los comentarios.

Si querés montar este mismo entorno, podés descargar la guía y copiársela a la IA que uses para que te acompañe paso a paso en la instalación.

Este tipo de decisiones de entorno y herramientas es exactamente lo que analizo cada semana en El Radar. Si te interesa esta línea, suscribite. Una nota por semana, directo en tu casilla.