← VOLVER ES/EN
2026.03.10 · 3 MIN DE LECTURA

Evitemos el vibe coding: context engineering en serio

Foto: Zetong Li · Unsplash

El vibe coding es divertido exactamente hasta el día tres, cuando hay que explicar por qué el sistema hace lo que hace.

No estoy en contra de programar a puro feeling: para un prototipo desechable es la técnica correcta. El problema es que los prototipos no se mueren, se despliegan.

Vibe coding, definido sin cariño

Pedirle cosas a un modelo, aceptar lo que salga porque se ve bien, y repetir. Sin contrato, sin verificación, sin memoria entre sesiones. Cada iteración parte de cero y el estado del sistema vive solamente en el diff acumulado.

Funciona mientras el proyecto cabe en la ventana de contexto. Después empieza el ciclo clásico: el modelo reintroduce el bug que arreglaste ayer, inventa una convención distinta en cada archivo, y tú te conviertes en el sistema de memoria de tu propio proyecto.

Context engineering: el contexto es infraestructura

La alternativa no es escribir prompts más largos. Es tratar el contexto como se trata un entorno de ejecución: versionado, explícito, revisable en un PR. Tres piezas, en orden de retorno sobre esfuerzo.

1. AGENTS.md — las reglas de la casa

Un archivo en el repo con lo que un desarrollador nuevo tardaría dos semanas en aprender por dolor: comandos reales, convenciones, trampas conocidas, decisiones tomadas y por qué.

La prueba de si el tuyo sirve: ¿tiene algo que no se pueda deducir leyendo el código? Si dice “usamos TypeScript”, lo borraste bien. Si dice “las utilidades de margin no funcionan porque hay un reset sin capa en globals.css:38, el spacing va en CSS con scope”, eso vale su peso en horas.

Un buen AGENTS.md es un postmortem preventivo: cada línea existe porque alguien ya perdió una tarde ahí.

2. MCP — herramientas en vez de adivinanzas

El Model Context Protocol resuelve algo aburrido y crítico: darle al modelo acceso a la fuente de verdad en vez de a su recuerdo de la documentación. El esquema real de la base, el issue real, el log real, la doc de la versión que efectivamente tienes instalada.

Un modelo con acceso al esquema no inventa columnas. Uno sin acceso siempre inventa la columna que tendría sentido que existiera, que es peor que inventar cualquiera, porque pasa la revisión visual.

Y la contraparte: cada herramienta que conectas es superficie de ataque y presupuesto de contexto. Conectar catorce servidores MCP “por si acaso” es el equivalente moderno a instalar toda la suite de Google en un netbook.

3. Skills — procedimientos que no se renegocian

Lo que en un equipo humano sería un runbook: cómo se hace un release, cómo se agrega una migración, cómo se investiga un incidente. Escrito una vez, invocado siempre igual.

La ventaja no es que el modelo lo haga mejor; es que lo haga igual todas las veces. La consistencia es la mitad de la calidad, y es la mitad que la gente subestima porque no se ve en la demo.

El costo real

Todo esto es trabajo previo sin resultado visible. Nadie aplaude un AGENTS.md. Es la misma categoría de esfuerzo que escribir tests o configurar CI: invisible cuando funciona, evidente cuando falta.

La diferencia frente al vibe coding se nota en la semana tres, cuando uno de los dos proyectos todavía avanza y el otro está en una sesión de arqueología para descubrir por qué hay dos funciones que hacen lo mismo con nombres distintos.

Spoiler: las escribió el mismo modelo, con una semana de diferencia, sin memoria de la primera.

Context EngineeringAGENTS.mdMCP