De Eclipse a Zed: La evolución de editores de un desarrollador

Un día de trabajo cualquiera.

Estaba manejando tres proyectos a la vez: un frontend en Next.js, un backend en FastAPI y una app móvil en Flutter. VS Code tenía cinco ventanas abiertas, Chrome se estaba devorando una enorme porción de memoria. Los ventiladores empezaron a zumbar, el mouse comenzó a trabarse y yo empecé a frustrarme.

"¿Cómo es posible que un editor de texto consuma 3 GB de memoria?"

En ese momento me di cuenta de que era hora de replantearme mis herramientas de desarrollo.

Mirando hacia atrás, desde que escribí mi primera línea de código hasta ahora, he cambiado de editor varias veces. Cada cambio no fue simplemente instalar otro programa, sino una transformación completa en mi forma de trabajar.

La era de Java: Eclipse → IntelliJ IDEA

Mi carrera en programación comenzó con Java. Gracias a la sincronización de Microsoft, todavía puedo encontrar mis notas de estudio de hace varios años.

Cuando empecé a programar, Eclipse era prácticamente el estándar para el desarrollo en Java. Siendo honesto, Eclipse tenía todas las funciones necesarias, pero el Eclipse de esa época tenía una sensación única de "pesadez": arranque lento, interfaz fea y los plugins se conflictuaban constantemente. Cada vez que abría Eclipse, era como arrancar un pequeño servidor.

Después, explorando por mi cuenta, descubrí IntelliJ IDEA.

La primera vez que lo abrí, me quedé sorprendido: ¿cómo puede ser tan inteligente el autocompletado? ¿Cómo puede ser tan fluida la refactorización? Las operaciones de refactorización que antes me requerían modificar manualmente más de diez archivos en Eclipse, IntelliJ las resolvía con un solo atajo de teclado.

Esa sensación fue como pasar de un Nokia a un iPhone.

Siendo honesto, no estudié Java por mucho tiempo antes de cambiarme a Python. Pero la experiencia con IntelliJ me dejó una buena impresión de JetBrains, y naturalmente me expandí a toda su suite de productos. WebStorm para frontend, PyCharm para Python, DataGrip para bases de datos. Cada IDE ofrecía una experiencia profundamente optimizada para su lenguaje específico, y la verdad es que era genial. Incluso después de migrar a VS Code, siempre mantuve instalados estos programas de JetBrains. Aunque casi nunca los abría, simplemente no podía decidirme a desinstalarlos.

Hacia el full-stack

El punto de inflexión llegó cuando empecé a hacer desarrollo full-stack.

Full-stack significa que tienes que saber un poco de todo. Backend en Python, frontend aprendiendo Vue y React, móvil con Flutter, de vez en cuando escribir algún script de Shell, y además Docker, archivos de configuración y un montón de cosas más. Con tantos lenguajes, empecé a considerar si debía cambiar de herramienta. Claro, IntelliJ IDEA también puede soportar muchos lenguajes a través de plugins, pero al final es demasiado pesado. Además, personalmente prefiero esa sensación de ir armando mi entorno de desarrollo pieza por pieza, como construir con bloques, en vez de usar un IDE completo preconfigurado.

Necesitaba un editor "de propósito general".

Antes de encontrar VS Code, probé otras opciones.

Descargué Sublime Text para probarlo y sí, era rápido, pero su contenido era demasiado básico. Su única ventaja parecía ser la velocidad; en todo lo demás, la diferencia con JetBrains era abismal. También revisé Notepad++, pero eso era más como un bloc de notas avanzado, no la herramienta de desarrollo que buscaba.

La era dorada de VS Code

La aparición de VS Code resolvió mi problema a la perfección.

Un editor donde instalas diferentes plugins y puedes manejar cualquier lenguaje. Pylance para Python, el plugin de Dart para Flutter, Volar para Vue — todo en una sola ventana.

Y entonces comenzó mi largo viaje de "personalización".

Cambié de tema más de diez veces, probé varios paquetes de iconos, configuré y reconfiguré atajos de teclado. Snippets de código, plugins de Git, plugins de Docker, todo tipo de Linters y Formatters... sin darme cuenta, había instalado más de 200 plugins.

Durante esa época, configurar VS Code se convirtió en una diversión en sí misma. Frecuentemente buscaba plugins útiles en comunidades y foros, y cada vez que encontraba uno sentía la emoción de "encontrar un tesoro". Hay que reconocer que su marketplace de extensiones es increíblemente rico, y cada plugin realmente mejora la productividad — solo para el entorno de desarrollo de Python probablemente instalé más de diez. Por supuesto, también hay plugins curiosos, como vscode-pets, que te permite tener una mascota virtual en el editor. Cero productividad, pero no puedes resistirte a instalarlo.

Incluso para centralizar todo mi trabajo en VS Code, compré una membresía de un plugin de base de datos: Database Client. Permite conectarse a diferentes bases de datos directamente desde VS Code, previsualizar datos y ejecutar operaciones. Muy útil. Con eso, ya ni necesitaba abrir DataGrip.

Hasta el día de hoy sigo explorando todo tipo de plugins. Ese proceso de exploración es parte de la diversión.

Esa fue la era dorada de VS Code. O más precisamente, el período en que fui más productivo explorando herramientas.

Llegó la era de la programación con IA

Mi primer contacto con la programación asistida por IA fue a través de GitHub Copilot.

Visitar

En ese entonces, Copilot todavía no tenía la función de Chat; simplemente, mientras escribías código, te sugería discretamente lo que probablemente ibas a escribir a continuación. Escribías un comentario y automáticamente te completaba un bloque entero de código. La primera vez que lo vi fue realmente impresionante — ¿cómo sabe esta cosa lo que quiero escribir?

Por supuesto, mirándolo en retrospectiva, estas ya son funciones básicas de la programación con IA.

Visitar

Después se hizo popular Cursor. Siendo honesto, llegué un poco tarde, porque en ese momento todavía tenía el paquete estudiantil de Copilot que podía usar gratis, y además Cursor es esencialmente un fork de VS Code, mientras que GitHub Copilot fue realmente el primero en hacer programación con IA. Así que siempre pensé que Copilot era lo mejor y no tenía motivación para cambiar.

Hasta que un compañero de trabajo me recomendó probar Cursor.

Lo descargué, lo probé, y descubrí que era mucho mejor que Copilot dentro de VS Code. Toda la interacción era más fluida, y la comprensión del contexto por parte de la IA era mucho más profunda. Realmente no entiendo cómo Copilot pudo quedar así — siendo el primero en empezar, la experiencia terminó siendo superada por los que llegaron después.

Después apareció Claude Code.

Visitar

Cuando empecé a usar Claude Code para escribir código, todo cambió de nuevo. Antes, el flujo de trabajo era: escribir en el editor → ejecutar en la terminal → corregir en el editor. Ahora se convirtió en: decirle a la IA lo que necesitas en la terminal → la IA lo escribe → tú lo revisas.

El uso de la terminal se disparó.

Antes, la terminal solo era el lugar para ejecutar npm run dev y git push. Ahora se convirtió en la interfaz principal de programación. Paso la mayor parte del tiempo conversando con Claude Code, pidiéndole que escriba código, corrija bugs y haga refactorizaciones. El editor quedó en segundo plano, convertido en una herramienta para "ver código".

Al mismo tiempo, como la IA aceleró la programación, la cantidad de proyectos que manejo simultáneamente también aumentó. Antes hacía un proyecto por mes; ahora puedo estar avanzando tres o cuatro a la vez.

Esto llevó directamente al siguiente problema.

VS Code ya no aguantó

Desarrollo de múltiples proyectos simultáneos + más de 200 plugins = desastre.

Cada ventana adicional de VS Code consumía varios cientos de megabytes de memoria. Con cinco ventanas abiertas, fácilmente superaba los 3 GB. Mi MacBook empezó a hacer girar los ventiladores al máximo, la interfaz empezó a perder frames y hasta al escribir se notaba la latencia.

Este no era solo mi problema. Si buscas "VS Code high memory usage" en internet, encontrarás toneladas de quejas similares. Arquitectura Electron + gran cantidad de plugins + múltiples ventanas: la explosión de memoria es prácticamente inevitable.

Probé varias soluciones de optimización: deshabilitar plugins que no usaba, usar la función de Profiles para cargar diferentes conjuntos de plugins según el proyecto, limitar procesos en segundo plano. Hubo mejoras, pero eran parches, no soluciones de fondo.

Al final del día, VS Code es una aplicación basada en Electron. Electron significa que cada ventana ejecuta una instancia completa de Chromium. Abres cinco ventanas y es como tener cinco Chrome abiertos.

La terminal es la reina: descubriendo Warp

Si la mayor parte del trabajo de programación ya se hace en la terminal, entonces la terminal tiene que ser buena.

La Terminal que viene con macOS es demasiado básica, iTerm2 la usé por mucho tiempo pero se sentía algo anticuada. Hasta que descubrí Warp.

Visitar

La primera impresión que me dio Warp fue velocidad. Arranque rápido, renderizado rápido, respuesta rápida. Luego está el diseño de Blocks — cada comando y su salida forman un "bloque" independiente, y puedes seleccionar, copiar y buscar contenido en la terminal como si fuera un editor de texto.

Después de usarla en el día a día, realmente no hay vuelta atrás. Algunos pequeños detalles:

El campo de entrada es un verdadero editor, con soporte para múltiples cursores, resaltado de sintaxis y autocompletado. Antes, cuando escribías un comando largo en la terminal y te equivocabas, tenías que navegar con las flechas lentamente hasta el error. Ahora simplemente haces clic con el mouse en el lugar correcto y lo corriges — suena obvio, pero las terminales tradicionales simplemente no pueden hacer esto.

Cada Block tiene un pequeño botón en la esquina superior derecha para copiar toda la salida con un clic. Antes, para seleccionar texto en la terminal, tenías que arrastrar el mouse con mucha precisión; si te desviabas un poco, seleccionabas de más o de menos. Ahora ya no tienes que preocuparte por eso.

Para los usuarios intensivos de terminal, estas mejoras en la experiencia son enormes.

En esta etapa, mi flujo de trabajo se convirtió en: 90% del tiempo en la terminal Warp usando Claude Code para programar, y VS Code solo se abría cuando necesitaba ver el historial de Git — principalmente usando GitLens para ver quién cambió qué código y cuándo.

Conociendo Zed

El problema es que VS Code, aunque solo lo uses para ver código, consume la misma cantidad de memoria.

Un día, navegando por Twitter, vi Zed. Hice clic y leí: "A high-performance, multiplayer code editor from the creators of Atom and Tree-sitter". El equipo fundador son los creadores originales del editor Atom, lo cual despertó mi interés.

Descargar, instalar, abrir.

Rápido. Muy rápido.

No del tipo "parece que es un poco más rápido", sino del tipo "así es como debería ser la velocidad de un editor". Arranque, apertura de archivos, búsqueda, navegación — todas las operaciones se completaban instantáneamente.

¿Qué tan rápido exactamente? Hay bastantes comparaciones de rendimiento en línea:

Fuente: Zed vs VS Code Performance Benchmark (2024)

Zed está escrito en Rust, con renderizado nativo por GPU, sin la capa intermedia de Electron. Por eso puede tener más de diez proyectos abiertos simultáneamente y la memoria total sigue siendo menor que la de una sola ventana de VS Code.

Además, Zed agregó recientemente soporte para pestañas nativas de ventana en macOS, permitiendo combinar múltiples ventanas de proyectos en una sola ventana y alternar entre ellas con pestañas. Para alguien como yo que tiene más de diez proyectos abiertos al mismo tiempo, el escritorio por fin dejó de estar lleno de ventanas. La comunidad llevaba mucho tiempo pidiendo esta función y finalmente se implementó.

Activarlo es muy sencillo: solo hay que agregar "use_system_window_tabs": true en la configuración de Zed. No necesitas reiniciar; la siguiente ventana que abras adoptará automáticamente el nuevo comportamiento. También sigue automáticamente la preferencia de pestañas del sistema macOS (siempre / nunca / en pantalla completa), manteniéndose consistente con el sistema.

Por supuesto, siendo honesto, Zed también tiene sus carencias. La más evidente es el ecosistema de plugins — todavía es muy joven y muchos plugins que damos por sentados en VS Code no existen en Zed. No hay herramientas de visualización de Git al nivel de GitLens, y el soporte para algunos lenguajes aún no es lo suficientemente completo.

Pero para mí, estos no son problemas críticos. Porque mis necesidades principales del editor ahora son solo dos: ver código y hacer ediciones ligeras. El trabajo pesado se lo dejo a Claude Code en la terminal.

Mi flujo de trabajo actual

Después de todo este recorrido, mi combinación actual de herramientas de desarrollo es:

Zed + Claude Code — herramientas principales de desarrollo. Zed puede tener más de diez proyectos abiertos sin ningún problema; lo uso para leer código, hacer pequeñas modificaciones y navegar definiciones. Claude Code también corre directamente en la terminal integrada de Zed para escribir código, corregir bugs y hacer refactorizaciones — básicamente todo se hace en una sola ventana.

Warp — la terminal volvió a cumplir el rol que le corresponde. Solo que esta terminal es muchísimo mejor que todas las que usé antes; es una terminal verdaderamente moderna. No entiendo por qué las terminales que vienen por defecto en los sistemas operativos actuales parecen seguir viviendo en el pasado. Por supuesto, a veces también inicio Claude Code directamente en Warp, ya que viene con un panel de archivos y visualización de Git integrados, lo cual es muy conveniente.

VS Code — aparición ocasional. Principalmente para usar GitLens cuando necesito ver el grafo de Git. Siendo honesto, lo uso cada vez menos.

Cada uno cumple su función. Zed se encarga de "ver" y "escribir", Warp se encarga de los comandos del día a día, VS Code se encarga de "investigar".

La lógica central de este flujo de trabajo es: editor ligero, terminal intensiva. En la era de la IA, la programación real ocurre en la terminal. Lo que el editor necesita hacer es simplemente permitirte ver el código cómodamente y hacer modificaciones rápidas.

Si tú también estás usando Claude Code, te recomiendo leer Mis mejores prácticas con Claude Code para conocer técnicas de uso eficiente, y Mi flujo de control de calidad con Claude Code para saber cómo garantizar la calidad del código generado por IA. Si quieres profundizar en el diseño detrás de Claude Code, puedes ver Análisis completo de la arquitectura de Claude.

Para cerrar

Repasando este camino de evolución de editores:

Eclipse → IntelliJ IDEA → Suite completa de JetBrains → Sublime Text (de paso) → VS Code + Copilot → Cursor → Claude Code + Zed + Terminal

Cada cambio no fue porque la herramienta anterior se volvió mala, sino porque mi forma de trabajar cambió.

Cuando hacía Java, IntelliJ era la mejor opción. Cuando hacía desarrollo full-stack multilenguaje, VS Code era la mejor opción. En la era de la IA con la terminal como protagonista, Zed + Warp es la mejor opción.

No existe el mejor editor para siempre, solo el editor más adecuado para tu flujo de trabajo actual.

Si ahora mismo estás usando un editor que te parece "pasable", pregúntate: ¿tu forma de trabajar ya cambió pero tus herramientas todavía no se pusieron al día?

Las herramientas están para servir a las personas. Cuando una herramienta empieza a frenarte, es momento de cambiar.