devground para vibe coders: revisa lo que cambia la IA antes de subirlo

Armando este sitio, Claude agregó una línea para apagar una regla de ESLint que en el proyecto ni siquiera existe. Yo no la vi. La vio el hook de pre-commit, que corrió el lint, dio error y no dejó guardar el commit. Lo arreglamos en un minuto.

Ese hook no lo configuré a mano, lo instaló devground. Es una herramienta mía, gratis y de código abierto, y en esta guía te muestro cómo instalarla en tu proyecto.

Lo que pasa cuando nadie revisa

Cuando haces vibe coding, el código lo escribe la IA y casi nunca lo revisa nadie antes de guardarlo. Le pides un botón y de paso toca otro archivo que no le pediste. O pega una clave en el código para probar algo rápido. O se olvida de una regla que le diste ayer, porque se la dijiste en el chat y el chat no queda guardado en el proyecto.

Nada de eso falla el mismo día. Falla una semana después, y si todos tus commits dicen «arreglos», encontrar cuál lo rompió te toma más tiempo que arreglarlo.

En un equipo de desarrollo esto se resuelve con herramientas que revisan cada cambio antes de guardarlo. Configurarlas toma una tarde, y si estás construyendo tu primera app es probable que no quieras gastarla en eso. devground te deja esa parte hecha.

Qué instala

No trae herramientas nuevas. Básicamente junta las que ya usan los equipos de desarrollo y las deja conectadas entre sí.

La primera es un archivo AGENTS.md, donde escribes las reglas de tu proyecto una sola vez. devground lo enlaza con el nombre que busca cada herramienta (CLAUDE.md para Claude Code, .cursorrules para Cursor, y los equivalentes de Copilot, Gemini y Codex), entonces da lo mismo con cuál abras el proyecto, porque todas leen las mismas reglas.

Después vienen los controles que corren en cada commit:

• gitleaks revisa los archivos que vas a guardar y, si encuentra algo que parece una clave o un token, bloquea el commit y te dice dónde está. Se instala aparte (en Mac, brew install gitleaks); si no lo tienes, el commit pasa igual, pero sin esa revisión.
• ESLint y Prettier buscan errores y ordenan el formato, solo en los archivos que cambiaste. También te avisan cuando un archivo crece demasiado o cuando aparece el tipo any, dos atajos que la IA toma seguido.
• commitlint te pide que el mensaje diga qué tipo de cambio es (feat:, fix:, docs:). Al principio molesta un poco, pero es lo que después te deja buscar en qué commit se rompió algo.

Hay dos cosas más que no corren en cada commit. Vitest viene con un trinquete de cobertura: cada vez que corres test:coverage, el mínimo de código probado sube hasta donde llegaste y queda guardado, así que si la IA borra tests, ese chequeo falla. Y la carpeta knowledge/ trae decisiones de arquitectura escritas, para que cuando le preguntes a Claude qué base de datos usar tenga un criterio y no elija la de siempre.

Cómo instalarlo

Funciona en proyectos JavaScript o TypeScript (Node, React, Next.js) con Node 20 o más. Desde la carpeta raíz del proyecto:

npx devground-init

Detecta tu stack y te pregunta qué quieres instalar. Si quieres todo sin que te pregunte:

npx devground-init --yes

Y si por ahora solo te interesan las reglas para la IA, sin hooks ni tests:

npx devground-init --preset agents-only

Si tu proyecto ya tiene su propia configuración de ESLint, TypeScript, commitlint o lint-staged, no la toca. Instala lo que falta y deja lo tuyo como estaba.

Cómo saber si quedó funcionando

Haz un cambio cualquiera y trata de guardarlo con un mensaje vago:

git commit -am "arreglos"

Lo va a rechazar, porque el mensaje no dice qué tipo de cambio es. Ahora prueba así:

git commit -am "fix: corrige el botón de pago"

Si ese pasa, quedó instalado. Eso es todo.

Si prefieres que lo instale Claude

Abre Claude Code en tu proyecto y pégale esto:

Instala devground en este proyecto con npx devground-init --yes.

Cuando termine:

1. Corre los tests y confirma que siguen pasando. Si algo falla, explícame por qué antes de tocar nada.
2. Corre test:coverage una vez para fijar el mínimo de cobertura.
3. Dime qué archivos creó y para qué sirve cada uno, en una línea por archivo.
4. Completa el AGENTS.md con las reglas de este proyecto que encuentres en el código: stack, cómo se corren los tests y qué no se debe tocar. Muéstramelo antes de guardarlo.

No cambies código de la aplicación en este paso.

El paso 4 es el que más te va a servir. devground te deja un AGENTS.md con reglas generales de buenas prácticas, pero no sabe nada de tu proyecto en particular, entonces lo más rápido es que Claude saque esas reglas del código y tú revises lo que escribió.

Antes de seguir programando

• Corriste npx devground-init en la raíz del proyecto.
• Instalaste gitleaks.
• Un commit con el mensaje «arreglos» se rechaza.
• Corriste test:coverage una vez.
• Tu AGENTS.md dice cómo es tu proyecto y qué no se toca.
• Le preguntaste a tu IA «¿qué reglas tiene este proyecto?» y te respondió con ese archivo.

Si todo eso se cumple, puedes seguir programando como siempre. Los controles corren solos.