Durante los últimos años he ido ajustando mi entorno de desarrollo con una idea bastante clara: reducir fricción. Menos tiempo peleando con herramientas, más tiempo pensando, escribiendo código y entendiendo problemas.

En esta experiencia hipotética de cinco meses, imaginemos un setup compuesto por tres piezas principales: Ghostty como terminal rápida y moderna, LazyVim como configuración base para Neovim, y Claude Code como asistente de programación integrado al flujo diario.

No se trata de perseguir herramientas por moda, sino de observar qué pasa cuando el entorno empieza a sentirse menos como una colección de piezas sueltas y más como una extensión natural del proceso de desarrollo.

Primer mes: configurando el terreno

El primer mes estaría marcado por adaptación. Ghostty entraría como reemplazo de una terminal tradicional, con una propuesta sencilla: buen rendimiento, buena integración con el sistema y una experiencia visual cuidada. Una terminal rápida se nota menos por lo que hace y más por lo que deja de interrumpir.

LazyVim, por otro lado, simplificaría bastante la entrada a Neovim. En lugar de construir una configuración desde cero, ofrece una base con LSP, autocompletado, búsqueda, navegación, diagnósticos y plugins útiles ya integrados. Eso no significa que no haya curva de aprendizaje, pero sí reduce mucho el costo inicial.

Claude Code sería la pieza más distinta del conjunto. No es solo autocompletado. La gracia estaría en poder pedirle ayuda dentro del contexto del proyecto: entender archivos, explicar decisiones, proponer cambios, escribir pruebas o revisar errores.

Segundo mes: el editor empieza a desaparecer

Después de varias semanas, el objetivo no sería “usar Neovim”, sino dejar de pensar tanto en el editor.

LazyVim empieza a sentirse cómodo cuando los comandos más usados ya están incorporados en la memoria muscular: buscar archivos, saltar entre símbolos, abrir diagnósticos, ejecutar acciones del LSP, moverse entre buffers y editar con precisión.

En este punto, el valor no está en tener una configuración espectacular, sino en tener una que no estorbe. LazyVim funciona bien porque ofrece una base razonable sin obligarte a convertir tu configuración en un proyecto paralelo.

Un detalle pequeño, pero importante, sería definir un tema visual cómodo desde el inicio. En mi caso hipotético, Tokyo Night sería una excelente opción como tema por defecto: oscuro, legible, popular y muy bien soportado dentro del ecosistema Neovim.

Un ejemplo de configuración en LazyVim podría verse así:

return {
  {
    "folke/tokyonight.nvim",
    opts = {
      style = "night",
    },
  },
  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "tokyonight",
    },
  },
}

No es una mejora funcional enorme, pero sí ayuda a que pasar muchas horas leyendo código sea más cómodo.

Tercer mes: Claude Code como compañero de trabajo

El tercer mes sería donde Claude Code empezaría a cambiar el flujo. La diferencia principal estaría en pasar de usar IA como una ventana separada a usarla como parte del proceso de desarrollo. En vez de copiar y pegar fragmentos aislados, se puede trabajar sobre archivos reales, pedir análisis de una función, generar una prueba o revisar una modificación concreta.

En la práctica, Claude Code sería especialmente útil para entender código heredado o poco claro, proponer refactors pequeños, generar pruebas unitarias a partir de comportamiento existente, encontrar el origen de errores, resumir cambios antes de hacer commit y revisar posibles casos borde.

La clave sería no delegar criterio. Claude Code puede acelerar mucho, pero sigue siendo necesario revisar, probar y entender lo que se está integrando. Usado bien, funciona menos como piloto automático y más como un segundo par de ojos disponible todo el tiempo.

Cuarto mes: subagentes personales para trabajar mejor

Una de las prácticas más útiles después de varias semanas sería crear subagentes personales para Claude Code.

La idea es simple: en lugar de pedirle todo al mismo asistente con instrucciones genéricas, se pueden definir agentes especializados para tareas repetitivas o con criterios muy concretos.

Un code reviewer podría enfocarse en revisar cambios como si estuviera haciendo review en un pull request. Su trabajo sería buscar bugs potenciales, casos borde, regresiones, código difícil de mantener, falta de pruebas o cambios innecesariamente grandes. Este agente no debería limitarse a decir que “todo se ve bien”; su valor está en ser crítico, concreto y señalar decisiones problemáticas.

Un investigador de código sería útil para explorar partes desconocidas del proyecto. Podría ayudar a responder dónde se implementa cierta funcionalidad, qué módulos toca un flujo, qué archivos conviene revisar antes de cambiar algo o qué patrones existentes ya resuelven problemas parecidos. En proyectos grandes, este tipo de agente ahorra mucho tiempo porque reduce la fricción inicial de entrar a una zona desconocida del código.

Un creador de copys puede parecer secundario, pero termina siendo muy práctico. No todo en desarrollo es lógica de negocio; muchas veces también hay que escribir textos de interfaz, mensajes de error, estados vacíos, tooltips, documentación breve o contenido para pantallas. Tener un agente dedicado a esto ayuda a mantener consistencia en el tono del producto sin convertir cada frase en una mini campaña de marketing.

Un inspector de estilo de código tendría una función distinta al code reviewer. En vez de buscar bugs, se enfocaría en consistencia: convenciones del proyecto, nombres de variables y funciones, tamaño de componentes o módulos, uso de patrones existentes y complejidad accidental. Es especialmente útil cuando se trabaja con varios lenguajes, frameworks o equipos, porque ayuda a evitar que cada cambio parezca escrito con un criterio distinto.

Quinto mes: productividad real vs. sensación de productividad

Después de cuatro o cinco meses, probablemente aparecería una distinción importante: no todo lo que se siente rápido produce mejor software.

Ghostty y LazyVim pueden hacer que moverse por el proyecto sea muy veloz. Claude Code puede generar código con facilidad. Pero la productividad real no está solo en escribir más líneas, sino en tomar mejores decisiones con menos desgaste.

El setup brillaría especialmente al navegar proyectos grandes, entender módulos desconocidos, hacer cambios incrementales, automatizar partes repetitivas y mantener el foco sin cambiar constantemente de contexto. Pero también habría riesgos: aceptar sugerencias de IA sin suficiente revisión, sobrecargar Neovim con plugins innecesarios, ajustar demasiado el entorno en vez de trabajar o confundir velocidad de edición con calidad de diseño.

La herramienta ayuda, pero no reemplaza fundamentos: leer bien, diseñar con calma, probar cambios y mantener el código simple.

Tip rápido: configurar Ghostty como terminal por defecto

Otro ajuste pequeño, pero muy útil, sería configurar Ghostty como terminal por defecto en el sistema operativo.

Esto hace que cualquier acción que abra una terminal use directamente el entorno principal de trabajo. Parece un detalle menor, pero reduce fricción cuando se abren proyectos, scripts o comandos desde otras aplicaciones.

En macOS, esto puede implicar dejar Ghostty en el Dock, usarlo como terminal principal y configurar herramientas externas para abrir comandos con Ghostty cuando sea posible. En Linux, dependerá del entorno de escritorio o distribución: algunos permiten definir el emulador de terminal desde preferencias, mientras que otros pueden requerir herramientas como update-alternatives o configuración del gestor de ventanas. Si usas un launcher o window manager, lo ideal es mapear el atajo principal de terminal directamente a ghostty.

La idea no es complicar el sistema, sino hacer que el camino más común sea también el más cómodo.

Flujo final después de cinco meses

Para el quinto mes, el setup idealmente ya no se sentiría nuevo. Ghostty sería simplemente “la terminal”. LazyVim sería “el editor”. Claude Code sería una herramienta más dentro del flujo, no una novedad.

Un flujo típico podría empezar abriendo el proyecto desde Ghostty, navegando el código con LazyVim e identificando una tarea o bug concreto. A partir de ahí, un subagente investigador podría ayudar a entender el contexto antes de tocar archivos; luego vendrían cambios pequeños, una revisión con el code reviewer, una pasada del inspector de estilo, pruebas locales, revisión del diff y finalmente documentación o commit.

Nada demasiado mágico. Justamente ahí está el punto: las mejores herramientas terminan volviéndose aburridas en el buen sentido. Están ahí, responden rápido y permiten concentrarse en el problema.

Lo que más destacaría

Si tuviera que resumir esta experiencia hipotética, diría que Ghostty mejora la base del trabajo diario, LazyVim ofrece una entrada pragmática a Neovim y Claude Code agrega una capa de asistencia contextual que puede acelerar comprensión, edición y revisión, especialmente cuando se combina con subagentes especializados.

Juntas, estas herramientas apuntan a un entorno más fluido: menos cambios de contexto, más velocidad para explorar código y más apoyo para resolver problemas concretos.

Conclusión

Cinco meses con Ghostty, LazyVim y Claude Code podrían representar una evolución natural para alguien que disfruta trabajar desde la terminal, valora la eficiencia de Neovim y quiere incorporar IA sin abandonar el control técnico.

No sería un setup perfecto para todo el mundo. Requiere comodidad con herramientas CLI, paciencia para aprender atajos y disciplina para revisar lo que genera la IA.

Pero para un perfil de desarrollador que busca un entorno rápido, configurable y centrado en el código, esta combinación tiene mucho sentido.

Al final, el mejor entorno no es el que más impresiona, sino el que desaparece mientras trabajas. Y en ese sentido, Ghostty, LazyVim y Claude Code podrían formar una combinación bastante difícil de abandonar.

---

#Ghostty, #LazyVim, #Claude Code, #Neovim, #Productividad,