Vibe coding: cómo construir con IA sin que se te caiga encima

El término vibe coding se popularizó en febrero de 2025 después de que Andrej Karpathy describiera una forma de programar en la que aceptaba las propuestas de la inteligencia artificial, apenas revisaba los cambios y devolvía los errores al modelo hasta que la aplicación terminaba funcionando.

La frase que resumía aquella idea era deliberadamente extrema: dejarse llevar por las vibraciones y olvidarse de que el código existe. El mensaje tenía parte de experimento y parte de broma, pero acabó poniendo nombre a una forma de trabajar que ya se estaba extendiendo: construir software explicando el resultado en lenguaje natural mientras una IA escribe buena parte del código.

Yo trabajo así prácticamente todos los días.

Esta web, con su tienda, su blog, su catálogo dinámico y su panel de administración, ha sido construida dirigiendo herramientas de IA. El frontend utiliza HTML, CSS y JavaScript sin frameworks. La parte dinámica funciona con Cloudflare Pages Functions, D1 y R2.

Y no... No escribí personalmente cada línea desde cero.

Pero tampoco escribí una frase, pulsé un botón y recibí un sistema terminado.

Entre una primera demostración y una web preparada para manejar productos, datos, sesiones y pagos existe una gran cantidad de trabajo que no aparece en los vídeos de treinta segundos.

Por eso puedo sostener dos afirmaciones al mismo tiempo:

Construir software con IA funciona de verdad.

Construir sin control puede dejarte un proyecto que nadie entiende y que se rompe con cada cambio.

Esta guía explica la diferencia.

Vibe coding no es lo mismo que desarrollo responsable con IA

Conviene separar dos formas de trabajo.

Vibe coding en su sentido más literal

El proceso se parece a esto:

1. Describes una idea.
2. La IA genera código.
3. Aceptas todos los cambios.
4. Ejecutas la aplicación.
5. Copias el error.
6. La IA propone otro parche.
7. Repites hasta que parece funcionar.

Este método puede ser válido para:

• Probar una idea.
• Preparar una demostración.
• Construir una herramienta personal.
• Explorar una interfaz.
• Crear un proyecto desechable.

El problema aparece cuando esa misma forma de trabajo se utiliza para publicar:

• Una tienda.
• Un panel administrativo.
• Un sistema de pagos.
• Una base de datos con clientes.
• Una aplicación con usuarios.
• Un servicio que otra persona tendrá que mantener.

Desarrollo asistido por IA

Aquí la inteligencia artificial sigue escribiendo gran parte del código, pero existe un proceso:

1. Se define el resultado.
2. Se proporciona el contexto del proyecto.
3. Se limita el alcance.
4. Se inspeccionan los archivos relacionados.
5. Se propone un plan.
6. Se aplica un cambio pequeño.
7. Se revisa el diff.
8. Se ejecutan comprobaciones.
9. Se prueban errores y casos límite.
10. Se guarda una versión recuperable.

Un estudio empírico sobre sesiones de vibe coding concluyó que este enfoque no elimina la necesidad de conocimientos técnicos. La experiencia se desplaza hacia gestionar el contexto, evaluar rápidamente el código generado y decidir cuándo dejar de delegar para intervenir directamente.

Esa descripción se parece mucho más a mi forma real de trabajar.

La IA produce.

Yo sigo siendo responsable de decidir qué entra en el proyecto.

Por qué funciona tan bien

La IA puede generar código a una velocidad muy superior a la escritura manual.

También puede reconocer patrones habituales:

• Formularios.
• Componentes.
• Consultas.
• Validaciones.
• Endpoints.
• Estilos responsive.
• Estados de carga.
• Mensajes de error.
• Pruebas.
• Documentación.

Eso elimina una gran parte del trabajo mecánico.

Antes, para construir una función sencilla, podía ser necesario:

1. Buscar documentación.
2. Comparar varios ejemplos.
3. Adaptar el código.
4. Resolver incompatibilidades.
5. Corregir errores de sintaxis.
6. Integrarlo con el proyecto.

Ahora puedes describir el comportamiento deseado y recibir una primera implementación en pocos minutos.

Esto resulta especialmente útil cuando ya entiendes:

• Qué problema intentas resolver.
• Qué partes existen.
• Qué datos entran.
• Qué resultado esperas.
• Qué no debería ocurrir.

La velocidad aparece porque dejas de empezar desde una página vacía.

Por qué también se rompe

La IA no conoce automáticamente la historia completa del proyecto.

Aunque pueda leer el repositorio, no sabe por sí sola:

• Qué decisión comercial existe detrás de una función.
• Por qué descartaste una librería.
• Qué archivos no deben tocarse.
• Qué compatibilidad necesitas conservar.
• Qué partes son temporales.
• Qué flujos manejan dinero.
• Qué comportamiento depende de otra página.
• Qué errores ya aparecieron anteriormente.

Además, una solución puede ser técnicamente válida y aun así no encajar con tu sistema.

La IA puede construir correctamente la función equivocada.

También puede:

• Duplicar código existente.
• Introducir una dependencia innecesaria.
• Utilizar una API desactualizada.
• Inventar una propiedad.
• Eliminar una validación.
• Corregir un síntoma sin resolver la causa.
• Crear una ruta sin protegerla.
• Saltarse una restricción que estaba escrita en otra conversación.
• Afirmar que ha terminado sin haber probado el recorrido completo.

GitHub recomienda revisar el código generado por IA comprobando funcionalidad, intención, mantenibilidad, dependencias y seguridad. También advierte de errores específicos como APIs inexistentes, restricciones ignoradas, paquetes sospechosos o pruebas eliminadas en vez de corregidas.

La herramienta puede producir una respuesta convincente.

Eso no constituye una prueba.

1. Un archivo de contexto vale más que repetir el mismo prompt

Una de las mejoras que más ha reducido errores en mi proyecto fue crear un archivo CLAUDE.md en la raíz.

Ese documento explica:

• Qué es el proyecto.
• Qué stack utiliza.
• Qué objetivo comercial tiene.
• Qué estructura debe mantenerse.
• Qué zonas no deben tocarse sin autorización.
• Qué idioma utiliza.
• Qué comandos se ejecutan.
• Qué decisiones ya están tomadas.

En mi caso incluye reglas como:

# Reglas técnicas

- Utilizar HTML, CSS y JavaScript vanilla.
- No introducir frameworks.
- Respetar los estilos existentes.
- No modificar /functions, /admin ni migraciones salvo que se solicite.
- No guardar secretos en el código.
- Mantener el sitio en español.
- Todo cambio debe funcionar en móvil.
- El despliegue se realiza mediante push a main.

El efecto es sencillo: la IA deja de adivinar una parte importante del contexto.

Claude Code carga los archivos CLAUDE.md al inicio de cada sesión y permite utilizarlos para documentar comandos de construcción, pruebas, convenciones, arquitectura y flujos habituales. Anthropic recomienda que las instrucciones sean concretas, breves y verificables. También señala que un documento excesivamente largo puede consumir contexto y reducir el grado de cumplimiento.

Qué debe incluir

Un archivo útil debería contener principalmente información que la IA no pueda deducir con facilidad leyendo el código.

Descripción del proyecto

## Proyecto

Web de marca personal con servicios, blog y una tienda secundaria.
El objetivo principal es generar solicitudes para servicios de marca y desarrollo web.

Stack

## Stack

- Frontend: HTML, CSS y JavaScript vanilla.
- Backend: Cloudflare Pages Functions.
- Base de datos: D1.
- Archivos: R2.
- Pagos: Stripe Checkout.

Restricciones

## Restricciones

- No instalar dependencias sin justificarlo.
- No cambiar respuestas públicas de la API sin revisar el frontend.
- No modificar pagos o autenticación como efecto secundario de otra tarea.
- No incluir secretos, datos personales ni claves de producción.

Comandos

## Comprobaciones

- npm run check
- npm run dev

Flujo de entrega

## Antes de terminar

1. Ejecutar las comprobaciones disponibles.
2. Resumir los archivos modificados.
3. Indicar qué debe probarse manualmente.
4. Informar de cualquier cambio no realizado.

Qué no debe incluir

Evitaría llenar el archivo con:

• Una descripción de cada archivo.
• Tutoriales completos.
• Documentación que cambia semanalmente.
• Reglas obvias como “escribe buen código”.
• Textos comerciales largos.
• Información que el agente puede leer directamente.
• Decenas de excepciones contradictorias.

Anthropic recomienda tratar CLAUDE.md como una pieza mantenible del proyecto: revisarlo cuando el agente repite un error, eliminar ruido y conservar aquello que realmente modifica su comportamiento.

El matiz importante: contexto no significa protección

Escribir:

Nunca modifiques las migraciones.

no garantiza técnicamente que el agente no las modifique.

Anthropic explica que CLAUDE.md se trata como contexto, no como una configuración obligatoria. Para bloquear una operación de forma determinista deben utilizarse controles como permisos o hooks previos a la ejecución.

Puedes orientar mediante documentación:

- No modificar /migrations.

Y reforzar mediante un control:

Bloquear cualquier escritura dentro de /migrations

Los hooks de Claude Code pueden ejecutar comandos automáticamente, impedir cambios en archivos protegidos y aplicar reglas independientemente de que el modelo las recuerde.

La documentación guía.

Los controles técnicos limitan.

2. Primero inspecciona, después modifica

Una de las peores peticiones posibles es:

Añade autenticación a mi web.

La tarea afecta probablemente a:

• Interfaz.
• Formularios.
• Cookies.
• Sesiones.
• Base de datos.
• Middleware.
• Recuperación.
• Permisos.
• Seguridad.
• Rutas.
• Logs.

Permitir que la IA empiece a modificar archivos sin comprender el flujo actual aumenta la posibilidad de terminar con dos sistemas superpuestos.

Antes de tocar el código, suelo pedir:

Analiza cómo funciona actualmente el acceso al panel.

Localiza:
- Rutas relacionadas.
- Middleware.
- Cookies.
- Variables de entorno.
- Funciones administrativas.
- Comportamiento en local y producción.

No modifiques nada todavía.

Explícame:
1. El flujo actual.
2. Los riesgos.
3. Qué cambio mínimo propondrías.
4. Qué archivos tendrían que modificarse.
5. Cómo comprobaríamos el resultado.

Esta etapa permite detectar problemas antes de generarlos.

Las propias recomendaciones de Claude Code proponen explorar primero, planificar después y programar finalmente cuando el cambio toca varias partes o cuando no se conoce bien la zona afectada. También recomiendan señalar archivos, restricciones, síntomas y patrones existentes en lugar de utilizar peticiones genéricas.

Cuándo puedes saltarte el plan

No toda modificación necesita una investigación extensa.

Probablemente no hace falta preparar un plan completo para:

• Corregir una falta.
• Cambiar una frase.
• Ajustar un margen.
• Añadir una clase.
• Renombrar una variable local.
• Actualizar un enlace.

Mi regla práctica es:

Si puedo describir con claridad el cambio y su resultado en una o dos frases, probablemente puedo pedir que se implemente directamente.

Cuando la petición incluye varias páginas, datos, autenticación o pagos, primero analizo.

3. Pide cambios pequeños y cerrados

El error habitual al empezar consiste en pedir:

Hazme una tienda online completa.

La IA puede generar rápidamente:

• Home.
• Catálogo.
• Producto.
• Carrito.
• Pago.
• Panel.

La demostración puede parecer impresionante.

Pero todavía no sabes si:

• El precio se valida en el servidor.
• Las variantes coinciden con la base de datos.
• El stock se controla correctamente.
• El pago confirma el pedido.
• El panel comprueba permisos.
• Las imágenes están limitadas.
• Los errores se gestionan.
• Las sesiones expiran.
• Los pedidos se pueden recuperar.

Un enfoque más controlable sería:

1. Mostrar productos desde la base de datos.
2. Abrir una ficha por identificador.
3. Seleccionar una variante.
4. Añadirla al carrito.
5. Validar el carrito en el servidor.
6. Crear el pedido.
7. Crear la sesión de pago.
8. Procesar el webhook.
9. Mostrar el pedido en el panel.
10. Probar fallos y duplicados.

Cada fase tiene un resultado observable.

Si algo se rompe, sabes dónde mirar.

Cómo cierro el alcance

En cada solicitud intento incluir:

• Archivo o zona.
• Comportamiento esperado.
• Restricciones.
• Casos de error.
• Prueba necesaria.
• Elementos que no deben cambiar.

Ejemplo:

En product.html y su JavaScript asociado, desactiva las variantes sin stock.

Requisitos:
- Mantener la API actual.
- No modificar /functions.
- No cambiar el diseño general.
- Mostrar un mensaje cuando no haya ninguna variante disponible.
- Impedir añadir al carrito una variante agotada.
- Funcionar con teclado y en móvil.

Después:
- Ejecuta npm run check.
- Resume los archivos modificados.
- Indica qué debo probar manualmente.

La petición no dice únicamente qué añadir.

También define cuándo estará terminada.

4. Dale una forma de comprobar su trabajo

Pedir código sin explicar cómo verificarlo obliga al agente a decidir por su cuenta cuándo ha terminado.

Esa decisión puede limitarse a:

• El archivo guarda.
• No aparece un error de sintaxis.
• La función parece coherente.
• La página carga.

Eso es insuficiente.

En mi proyecto existe:

npm run check

El comando comprueba la sintaxis del JavaScript y de las Functions.

Por eso puedo pedir:

Realiza el cambio y ejecuta npm run check antes de terminar.
Si falla, corrige la causa. No elimines la comprobación ni ignores el error.

Para otros proyectos podría utilizarse:

npm test
npm run lint
npm run typecheck
npm run build
pytest
cargo test
go test ./...

GitHub recomienda ejecutar primero pruebas automatizadas y análisis estático al revisar código generado por IA. Anthropic también aconseja proporcionar siempre una forma concreta de verificación y no publicar aquello que no se puede comprobar.

Las pruebas deben salir del comportamiento

No pediría simplemente:

Añade tests.

Pediría:

Añade pruebas para estos casos:

- Usuario no autenticado.
- Sesión válida.
- Sesión caducada.
- Token manipulado.
- Falta una variable de entorno.
- El servidor devuelve un error.

Cuanto más concreto sea el comportamiento, menos probable es que la IA genere pruebas que únicamente confirman su propia implementación.

Una prueba aprobada no demuestra que todo esté bien

Una suite puede pasar y seguir existiendo problemas:

• Faltan casos.
• La prueba reproduce la misma suposición incorrecta.
• La interfaz móvil está rota.
• Existe una vulnerabilidad fuera del alcance.
• La lógica comercial está mal definida.
• La integración real utiliza una configuración distinta.

Las comprobaciones automáticas son una barrera.

No sustituyen la revisión del resultado.

5. Revisa el cambio, no solo la pantalla

Una función puede verse correctamente mientras el código ha introducido un problema.

Por eso reviso el diff.

Busco:

• Archivos inesperados.
• Eliminaciones.
• Código duplicado.
• Dependencias nuevas.
• Cambios de nombres públicos.
• Modificaciones de API.
• Validaciones eliminadas.
• Comentarios que ya no coinciden.
• Funciones antiguas que permanecen.
• Cambios mucho mayores que la solicitud.

Si pedí modificar un botón y aparecen 800 líneas nuevas, quiero saber por qué.

Trabaja con Git desde el principio

El control de versiones permite:

• Saber qué cambió.
• Recuperar una versión anterior.
• Comparar soluciones.
• Probar una rama.
• Deshacer un error.
• Revisar el historial.
• Separar cambios.

El flujo mínimo sería:

1. Crear o utilizar una rama.
2. Aplicar un cambio limitado.
3. Revisar el diff.
4. Ejecutar comprobaciones.
5. Probar manualmente.
6. Crear un commit descriptivo.
7. Desplegar.
8. Comprobar producción.

No esperaría a tener la aplicación “terminada” para empezar a usar Git.

La capacidad de volver atrás es parte del desarrollo, no una tarea administrativa.

6. La seguridad no se delega

Esta es la regla más importante.

La IA puede ayudarte a:

• Detectar riesgos.
• Preparar validaciones.
• Revisar permisos.
• Crear pruebas.
• Localizar secretos.
• Proponer cabeceras.
• Auditar endpoints.

Pero no deberías asumir que una función es segura porque el mismo sistema que la escribió afirma que lo es.

Secretos fuera del código

No deberían aparecer dentro del repositorio:

• Contraseñas.
• Claves privadas.
• Secretos de webhooks.
• Tokens.
• Credenciales.
• Claves de sesión.
• Datos reales de clientes.

En mi proyecto, los secretos locales viven en un archivo ignorado por Git y los de producción se guardan como secretos cifrados en Cloudflare.

OWASP recomienda evitar las credenciales hardcodeadas y utilizar sistemas específicos para almacenar, inyectar, rotar y auditar secretos. También advierte que incluso las variables de entorno deben gestionarse con cuidado porque pueden terminar expuestas mediante procesos, volcados o logs.

Una instrucción razonable sería:

No escribas valores de secretos en ningún archivo.

Utiliza los nombres:
- STRIPE_SECRET_KEY
- STRIPE_WEBHOOK_SECRET

Indica dónde deben configurarse, pero utiliza valores ficticios en la documentación.

Todo dato externo se considera no fiable

Esto incluye:

• Formularios.
• Parámetros de URL.
• Cabeceras.
• Cookies.
• Archivos.
• JSON.
• Webhooks.
• Respuestas de terceros.
• Valores guardados en el navegador.

La validación del frontend mejora la experiencia, pero puede evitarse.

La validación de seguridad debe existir en el servidor.

OWASP recomienda validar todas las entradas externas tanto a nivel sintáctico como semántico. También explica que las comprobaciones realizadas únicamente mediante JavaScript pueden ser anuladas por un atacante.

No basta con comprobar:

¿Es un número?

También debes comprobar:

¿Puede ser negativo?
¿Está dentro del stock?
¿El usuario puede modificarlo?
¿La variante pertenece al producto?
¿Este estado permite la operación?

Pagos

En cualquier función relacionada con dinero revisaría específicamente:

• Precio calculado en el servidor.
• Moneda.
• Cantidades.
• Stock.
• Descuentos.
• Identificación del pedido.
• Firma del webhook.
• Idempotencia.
• Reintentos.
• Estados asíncronos.
• Reembolsos.
• Logs.

La frase:

El pago funciona.

no es una verificación suficiente.

La pregunta correcta es:

¿Qué ocurre cuando la misma confirmación llega dos veces, cuando el usuario manipula el carrito o cuando el pago se completa pero nuestra base de datos falla?

Autenticación y autorización

No son lo mismo.

Autenticación: quién es el usuario.

Autorización: qué puede hacer.

Una API no está protegida porque el botón administrativo esté oculto.

Cada operación sensible debe comprobar permisos en el servidor.

Subidas de archivos

La IA debe recibir requisitos concretos:

• Tamaño máximo.
• Extensiones permitidas.
• Tipo MIME.
• Validación real.
• Nombre generado.
• Lugar de almacenamiento.
• Quién puede acceder.
• Qué ocurre al sustituirlo.
• Cómo se elimina.

Aceptar cualquier archivo porque termina en .jpg no es una validación suficiente.

Auditoría adversarial

Después de una implementación sensible, puedes abrir una revisión separada:

No modifiques código todavía.

Actúa como revisor de seguridad y analiza este cambio como si intentaras atacarlo.

Busca:
- Entrada manipulable.
- Falta de autorización.
- Exposición de secretos.
- Condiciones de carrera.
- Duplicación.
- Reintentos.
- Errores silenciosos.
- Acceso a datos de otro usuario.

Indica archivo, línea aproximada, riesgo y corrección.

Esto ayuda a cambiar el ángulo de análisis.

Pero no constituye una revisión independiente si utilizas el mismo modelo, el mismo contexto y las mismas suposiciones.

Para zonas críticas combinaría:

• Revisión humana.
• Pruebas.
• Escáneres.
• Documentación oficial.
• Un segundo modelo o sesión sin el historial anterior.
• Herramientas específicas.

NIST recomienda integrar prácticas de desarrollo seguro durante todo el ciclo de vida para reducir vulnerabilidades, limitar el impacto de fallos no detectados y corregir sus causas, no solo los síntomas.

7. Comprueba las dependencias y la documentación

Una IA puede sugerir una librería que:

• No existe.
• Está abandonada.
• Tiene una licencia incompatible.
• Añade cientos de dependencias.
• Resuelve un problema demasiado pequeño.
• Tiene vulnerabilidades conocidas.
• Se parece a un paquete legítimo, pero no lo es.

GitHub recomienda verificar manualmente que los paquetes sugeridos existan, estén mantenidos y tengan una licencia adecuada. También advierte sobre APIs inventadas y paquetes alucinados o sospechosos.

Antes de instalar algo preguntaría:

¿Por qué necesitas esta dependencia?

Comprueba:
- Paquete oficial.
- Repositorio.
- Licencia.
- Fecha de la última versión.
- Número de dependencias.
- Alternativa sin librería.
- Si ya existe una solución equivalente en el proyecto.

La documentación oficial gana

Cuando la IA afirma:

Esta opción de Stripe funciona así.

o:

Cloudflare permite este comportamiento.

comprueba la documentación oficial actual.

Los modelos pueden utilizar:

• Información antigua.
• Sintaxis de otra versión.
• Ejemplos de terceros.
• Comportamiento de otro framework.

La IA es buena ayudándote a localizar y explicar documentación.

No debería sustituirla cuando implementas una API crítica.

8. Pregunta el porqué

Cuando recibas una solución no obvia, pregunta:

¿Por qué elegiste este enfoque?

¿Qué alternativas consideraste?

¿Qué inconvenientes tiene?

¿Qué parte del proyecto existente estás reutilizando?

¿Qué ocurriría si mañana cambio X?

¿Hay una solución más pequeña?

Esto cumple dos funciones.

Detectar decisiones débiles

La IA puede reconocer que:

• Añadió una librería innecesaria.
• Supuso algo que no estaba confirmado.
• Eligió un patrón genérico.
• No encontró una función existente.
• La solución complica el mantenimiento.

Aprender mientras construyes

Después de trabajar así durante meses, empiezas a comprender:

• Cómo se mueve un dato.
• Qué diferencia hay entre cliente y servidor.
• Cómo funciona una sesión.
• Por qué existe un webhook.
• Qué significa una transacción.
• Cómo se organiza una API.
• Qué hace una migración.
• Qué errores pueden repetirse.

No necesitas escribir personalmente cada carácter para aprender.

Sí necesitas negarte a aceptar sistemas que no puedes explicar.

9. Aprende cuándo detener la iteración

Un patrón peligroso es este:

1. La IA propone una solución.
2. Falla.
3. Añade una condición.
4. Sigue fallando.
5. Añade otra función.
6. Duplica el estado.
7. Introduce un temporizador.
8. El error desaparece aparentemente.

El archivo termina lleno de parches.

Después de dos o tres intentos fallidos, suelo detener la conversación y pedir:

No añadas otro parche.

Analiza por qué las soluciones anteriores no resolvieron la causa.

Resume:
- Qué se intentó.
- Qué suposiciones eran incorrectas.
- Qué código quedó obsoleto.
- Cuál es la causa raíz probable.
- Qué solución limpia propones.

No modifiques nada hasta que aprobemos el nuevo enfoque.

En ocasiones resulta mejor:

• Restaurar una versión.
• Abrir una sesión limpia.
• Reescribir una función pequeña.
• Reducir el alcance.
• Eliminar código.
• Consultar documentación.
• Pedir ayuda especializada.

La velocidad de generación no justifica conservar una solución incomprensible.

10. Cuándo no utilizar vibe coding sin supervisión

Este enfoque funciona especialmente bien para:

• Interfaces.
• Landings.
• Prototipos.
• Herramientas internas.
• Automatizaciones sencillas.
• Formularios.
• Trabajo repetitivo.
• Migraciones pequeñas y revisadas.
• Refactorizaciones acotadas.
• Documentación.
• Pruebas.

Aumentaría mucho la revisión en:

• Pagos.
• Autenticación.
• Datos personales.
• Permisos.
• Facturación.
• Archivos privados.
• Borrados.
• Sistemas legales o médicos.
• Infraestructura.
• Operaciones irreversibles.
• Software donde un fallo pueda producir un perjuicio real.

La IA no debe tener libertad total en una zona que tú no puedes evaluar.

La solución no es necesariamente dejar de utilizarla.

La solución puede ser:

• Reducir permisos.
• Trabajar en una copia.
• Utilizar datos ficticios.
• Exigir aprobación.
• Añadir comprobaciones.
• Contratar una auditoría.
• Utilizar una plataforma administrada.

Mi flujo real, resumido

1. Mantengo el contexto

El proyecto tiene un documento que explica:

• Objetivo.
• Stack.
• Reglas.
• Límites.
• Comandos.
• Zonas sensibles.

2. Investigo antes de tocar

Para cambios importantes pido que localice:

• Archivos.
• Dependencias.
• Flujo actual.
• Riesgos.
• Posibles efectos secundarios.

3. Apruebo un plan pequeño

La tarea se divide hasta que puedo comprobar cada fase.

4. La IA implementa

El agente modifica únicamente las zonas acordadas.

5. Ejecuta comprobaciones

Como mínimo:

npm run check

Dependiendo de la función, también se prueban recorridos manuales.

6. Reviso el diff

Compruebo qué cambió realmente.

7. Hago una segunda revisión en zonas críticas

Especialmente en:

• Dinero.
• Sesiones.
• Permisos.
• Datos.
• Archivos.

8. Creo una versión recuperable

El cambio queda registrado en Git.

9. Compruebo producción

Una implementación que funciona en local puede fallar por:

• Variables.
• Cookies.
• Dominios.
• CORS.
• Rutas.
• Base de datos.
• Configuración de proveedores.

Prompt base para cambios seguros

Puedes utilizar esta estructura:

CONTEXTO

Este proyecto utiliza:
- HTML, CSS y JavaScript vanilla.
- Cloudflare Pages Functions.
- D1.
- R2.

OBJETIVO

Describe el cambio concreto y el resultado esperado.

ANTES DE MODIFICAR

1. Localiza los archivos implicados.
2. Explica el flujo actual.
3. Señala los riesgos.
4. Propón el cambio mínimo.
5. Indica cómo verificarlo.

RESTRICCIONES

- No introducir frameworks.
- No instalar dependencias sin justificarlo.
- No modificar pagos, autenticación o migraciones.
- No exponer secretos.
- Mantener compatibilidad móvil.
- Respetar los patrones existentes.

CASOS QUE DEBE CUBRIR

- Caso correcto.
- Entrada vacía.
- Error del servidor.
- Petición repetida.
- Usuario sin permiso.
- Estado inexistente.

AL TERMINAR

1. Ejecuta npm run check.
2. Corrige cualquier error real.
3. Resume los archivos modificados.
4. Explica las decisiones no obvias.
5. Indica qué debo probar manualmente.
6. No afirmes que está listo si no pudiste verificarlo.

Checklist antes de aceptar código generado

Contexto

• El agente conoce el objetivo del proyecto.
• Sabe qué stack debe utilizar.
• Tiene límites claros.
• Ha leído los archivos relevantes.
• No está suponiendo la lógica comercial.

Alcance

• El cambio es pequeño.
• Los archivos esperados están identificados.
• No mezcla tareas diferentes.
• Existe un resultado comprobable.

Código

• No duplica funciones.
• No añade dependencias sin motivo.
• No elimina validaciones.
• Respeta convenciones.
• Los nombres se entienden.
• Los errores se gestionan.

Seguridad

• No hay secretos.
• La entrada se valida en el servidor.
• Los permisos se comprueban.
• No se confía en precios o estados del navegador.
• Los archivos tienen límites.
• Los logs no guardan datos sensibles.

Verificación

• La sintaxis pasa.
• Las pruebas pasan.
• Se revisó el diff.
• Se probó el fallo.
• Se comprobó móvil cuando corresponde.
• Existe una forma de volver atrás.

La conclusión honesta

La inteligencia artificial ya puede ayudarte a construir una cantidad enorme de software.

Eso no es una promesa futura.

Yo mismo la utilizo para desarrollar esta web, mejorarla y mantenerla.

Pero la ventaja real no está en pedir:

Créame una aplicación.

Está en aprender a dirigir un proceso:

• Proporcionar contexto.
• Dividir.
• Limitar.
• Revisar.
• Probar.
• Proteger.
• Simplificar.
• Decidir qué no debe construirse.

La IA aporta velocidad.

La disciplina evita que esa velocidad convierta el proyecto en una acumulación de código que funciona únicamente mientras nadie lo toque.

Mi regla final es esta:

No publiques código generado porque la IA diga que está terminado. Publícalo cuando puedas explicar qué hace, comprobar el recorrido principal y recuperar el sistema si algo falla.

Eso no elimina el riesgo.

Pero convierte el vibe coding en una herramienta de producción, no en una apuesta.