¿Cómo se ve una Developer Experience potente en la época de Vibe Coding?
Una buena Developer Experience no es un lujo, es una ventaja competitiva. El que no lo crea puede hablar con alguien que haya trabajado en Google, en dónde todos hablan maravillas de sencillamente lo productivo que son y las capacidades de hacer pruebas o validar ideas que ofrecen los ambientes de desarrollo.
Pero, cómo se ve esto en un mundo donde el código cada vez más se co-escribe entre humanos y asistentes de IA?
Más allá del tooling
Así como una buena DX no se trata solo de tener un buen editor o configuraciones mágicas estáticas, la introducción de un asistente de AI va más allá de contratar Claude.
Una DX potente es sistémica: documentación que no es solo referencia sino guía, entornos de desarrollo consistentes, CI/CD que no obstaculiza sino que acelera, on-boarding actualizados que permite empezar a contribuir en días, no semanas.
Y, en tiempos de IA, el concepto se amplía y una buena DX va a implicar también darle facilidades a los modelos para que nos ayuden más efectivamente.
¿Cómo construirla?
Creo que está todo verde como para dar guías definitivas, pero sin duda existen lineamientos. Naturalmente, una de las primeras y actualmente más usada es tener prompts comunes como parte del repositorio. Plantillas predefinidas para coding assistants, especialmente para tareas repetitivas (e.g. escribir tests, agregar logs, refactorizar funciones).
Pero también hay que tener en cuenta como podemos mejorar la DX del generador de tokens, y ahí hay algunas opciones más. Una es dividir la base de código de forma que sea más fácil para una IA entender la intención de los módulos, sus contratos y sus dependencias. Tener en cuenta que el tamaño puede ser relevante, en cantidad de caracteres.
Otra es la generación de playbooks de código, donde brindamos fragmentos o ejemplos curados directamente desde la base de código de la empresa, como referencia rápida para resolver problemas comunes. Particularmente en modelos de ventanas de tokens grandes como Gemini, puede tener sentido tener snippets de referencia inyectados permanentemente en el contexto fortaleciendo la alineación con las guías de diseño.
Conclusión
Personalmente, comparto la visión de Matthew Foster sobre que la DX es un camino que nos permite tener un impacto directo en la adopción de herramientas, patrones y decisiones de arquitectura. Si algo cuesta entender, cuesta configurar, o cuesta mantener… simplemente no se usa. O peor: se usa mal.
Y aunque pido prestado forzadamente el término vibe coding, creo que es necesario repensar la DX que tenemos como equipos de desarrollo tomando en cuenta las nuevas herramientas que tenemos con sus capacidades y limitaciones intrínsecas. Una buena DX no es accidental, se diseña e itera continuamente como parte del producto.
Juan Saavedra 