El setup de desarrollo que uso en 2026

Cada año o dos hago un reset de setup. Reviso lo que realmente estoy usando versus lo que instalé una vez y olvidé. La brecha suele ser vergonzosa.

Esto es lo que sobrevivió el corte de 2026, y el razonamiento detrás de cada pieza.

Editor

PhpStorm es mi editor principal. Sé que la respuesta obvia es “¿por qué no VS Code?” y la respuesta honesta es: probé VS Code por seis meses en 2024 y seguía regresando. El refactoring, las herramientas de base de datos y el soporte multilenguaje de PhpStorm sin cazar extensiones vale el costo. Trabajo regularmente en PHP, TypeScript y Python, suficiente para que un IDE generalista tenga más sentido que armar uno con plugins.

Fuente: MonoLisa. Probé la mayoría de las fuentes mono populares y esta es la única que dejo de notar, que es exactamente lo que quiero de una fuente de código. Las ligaduras son discretas. La variante cursiva se usa como un peso separado, no solo inclinado, lo cual importa más de lo que debería.

Terminal

Warp como emulador de terminal. Las funciones de IA no son la razón por la que lo uso. La razón real es el UX del historial de comandos y la gestión de sesiones. Mantengo tres sesiones nombradas abiertas: deliver (trabajo del proyecto actual), logs (tailing de producción) y scratch (experimentos que no estoy listo para commitear). Dentro de cada una tengo tmux para divisiones de paneles.

Suena excesivo y quizás lo es, pero la separación mantiene mi cabeza clara sobre en qué contexto estoy.

Defaults de stack

La mayoría de lo que construyo ahora cae en una de dos categorías: sitios de contenido o prototipos de producto.

Para sitios de contenido, el default es: Astro para el build, Tailwind CSS v4 para estilos, Cloudflare Pages para entrega. Este sitio corre en ese stack. El tiempo de build es de menos de 3 segundos, los deploys son automáticos en cada push, y la entrega desde el edge significa que carga rápido desde cualquier lugar en LATAM sin necesidad de pensar en regiones.

Para prototipos de producto y trabajo SaaS: Laravel sigue siendo mi backend principal. Conozco sus convenciones lo suficientemente bien como para no estar tomando decisiones de framework cuando debería estar tomando decisiones de producto. El ecosistema está maduro, la documentación es excelente, y para los tipos de productos que construyo, cualquier cosa intensiva en datos con flujos de trabajo reales de usuario, sigue siendo la herramienta que me permite moverme más rápido.

Lo que descarté

Docker para desarrollo local. Lo usaba por hábito más que por necesidad. Para los proyectos que ejecuto solo o con un equipo pequeño, el overhead de mantener archivos compose y depurar problemas de red dentro de contenedores costaba más tiempo del que ahorraba. Ahora uso servicios locales con versionado explícito y documento los supuestos de setup claramente en su lugar.

También descarté: Notion como mi entorno principal de escritura. Escribo en iA Writer ahora. La ausencia de editores basados en bloques y el enfoque en archivos markdown significa que mi escritura no está atrapada en una base de datos que no controlo, y el editor mismo se quita de en medio.

El principio real

Cada herramienta que agrego tiene que eliminar una decisión que de otro modo tendría que tomar constantemente, o comprimir el tiempo entre idea y feedback. Si no hace ninguna de las dos, no se queda.

Los setups sofisticados son una trampa de procrastinación. El mejor setup es el que dejas de pensar en él.