Vibe coding sin pegarte un tiro en el pie: 5 reglas para programar con IA
La sierra eléctrica del desarrollo moderno puede cortarte el dedo si la sueltas. Aquí están las reglas que separan a quien la usa bien de quien llega a urgencias.
En este artículo
La sierra eléctrica que nadie te enseñó a
Hay una fantasía muy extendida en el mundo del desarrollo estos días: le describes lo que quieres a una IA, ella escupe el código, tú lo pegas, funciona y todos contentos. Eso es el vibe coding en su versión de cuento de hadas.
La versión real es más parecida a darle una sierra eléctrica a alguien que nunca ha visto madera. La herramienta es potente. El resultado depende enteramente de quién la maneja y de si sabe lo que está cortando.
En la RSA Conference 2026, Richard Horne, CEO del NCSC (el equivalente británico a la agencia de ciberseguridad nacional), subió al escenario y dijo algo que el sector lleva meses evitando decir en voz alta: el código generado por IA puede propagar vulnerabilidades si se deja sin supervisión. Pero también dijo lo contrario, y esa parte es igual de importante: si se hace bien, con herramientas bien entrenadas y salvaguardas desde el principio, puede ser la mayor oportunidad que ha tenido la industria para romper el ciclo de software crónicamente inseguro.
"Disrupting the status quo of manually produced software that is consistently vulnerable is a huge opportunity, but not without risk of its own.", Richard Horne, NCSC CEO, RSA Conference 2026
Ahí está el meollo. No es que la IA sea buena o mala para programar. Es que la mayoría de la gente la está usando como si fuera magia, y la magia no existe en ingeniería de software.
Lo que sí existe son reglas. Cinco, concretamente.
Por qué el vibe coding sin criterio es un problema de seguridad, no solo de calidad
Antes de las reglas, vale la pena entender por qué esto importa más allá de "el código quedó feo".
Cuando un desarrollador escribe código a mano, hay un proceso cognitivo implícito: piensas en los casos límite, recuerdas el contexto del sistema, tienes presentes las dependencias que ya existen. Puedes hacerlo mal igualmente, pero al menos el razonamiento pasa por tu za.
Cuando le pides a una IA que genere código, ese proceso no ocurre en ningún lado. La IA no conoce tu arquitectura. No sabe que ese endpoint ya tiene un rate limiter. No sabe que la tabla de usuarios tiene una columna deprecated que nunca deberías tocar. No sabe que en producción corres una versión del framework con un comportamiento específico que difiere de la documentación más reciente.
La IA escribe código plausible. Código que parece correcto. Código que a veces es correcto. Y código que, en los casos más peligrosos, tiene el aspecto exacto del código correcto pero introduce un side effect que no verás hasta que ya sea demasiado tarde.
David C, CTO del NCSC, publicó en paralelo a la charla de Horne un conjunto de principios para asegurar el vibe coding. Entre ellos: integrar prácticas secure-by-default en los modelos de IA, adoptar una postura de "confía pero verifica" con trazabilidad del modelo, IA para auditar todo el código generado, y establecer guardrails deterministas sobre lo que el código puede hacer. No son regulaciones obligatorias ni estándares formales, son criterios de sentido común elevados a política. El tipo de cosas que deberías estar haciendo de todas formas.
El problema no es el vibe coding. El problema es el vibe coding sin adulto en la sala.
Regla 1: Contexto explícito antes de pedir una sola línea
La IA no adivina. Genera texto estadísticamente probable dado lo que le has contado. Si le das poco contexto, rellena los huecos con suposiciones razonables que pueden ser completamente erróneas para tu caso.
Antes de hacer cualquier petición de código, define explícitamente:
- El stack y las versiones exactas. No "uso React", sino "React 18.2 con TypeScript 5.1 y Vite como bundler". Las diferencias de comportamiento entre versiones menores pueden ser el origen de un bug que tardarás días en encontrar.
- Qué NO debe tocar. Esto es lo que más se olvida. Si hay partes del sistema que son intocables (una integración legacy, un contrato de API con terceros, una tabla de base de datos que otro equipo gestiona), díselo explícitamente. La IA no sabe que eso existe si no se lo cuentas.
- El objetivo real, no solo la tarea inmediata. "Añade validación al formulario" es una instrucción. "Añade validación al formulario de registro sin modificar el esquema de base de datos existente ni romper la integración con el proveedor de identidad externo" es una instrucción útil.
El contexto no es overhead. Es la diferencia entre código que encaja en tu sistema y código que parece encajar pero explota en producción.
Regla 2: Revisión línea a línea, como a un becario listo pero impulsivo
Aquí hay que ser honesto sobre algo incómodo: la mayoría de la gente que usa vibe coding no revisa el código con la misma exigencia que revisaría el de un colega. Lo pegan, lo prueban superficialmente, funciona, merge.
Ese es exactamente el comportamiento que Horne describió como el riesgo central del vibe coding sin supervisión.
La IA es como un becario muy listo y muy impulsivo. Resuelve el problema que le planteas con una velocidad impresionante y una confianza absoluta. Pero no tiene el contexto de por qué las cosas están como están, y no tiene el instinto de preguntar antes de hacer algo que parece razonable pero tiene consecuencias.
Al revisar código generado por IA, busca específicamente:
- Side effects ocultos. ¿Modifica estado global? ¿Escribe en algún sitio que no debería? ¿Hace llamadas a servicios externos que no estaban en la especificación?
- Dependencias nuevas. ¿Ha importado una librería que no tenías? ¿Esa librería tiene vulnerabilidades conocidas? ¿Es compatible con tu licencia?
- Manejo de errores real vs. decorativo. Hay una diferencia enorme entre un bloque
try/catchque maneja el error de forma útil y uno que lo traga silenciosamente o devuelve un mensaje genérico que no te dice nada. La IA tiende a generar el segundo tipo porque "parece correcto". - Hardcoding silencioso. Valores mágicos, URLs hardcodeadas, timeouts arbitrarios. Cosas que funcionan en desarrollo y se convierten en bombas de relojería en producción.
No es que la IA lo haga mal a propósito. Es que optimiza para que el código parezca correcto y resuelva el problema inmediato. Tú eres el responsable de que también sea correcto en el sistema real.
Regla 3: Los tests los defines tú, no la IA
Pedirle a la IA que genere tests para el código que acaba de generar es como pedirle al estudiante que se autocorrija el examen. Puede funcionar para los casos obvios. Para los que importan, probablemente no.
Los casos límite que realmente importan en tu sistema son los que emergen de su contexto específico: los datos reales de tus usuarios, los estados de error que has visto en producción, las condiciones de carrera que sabes que pueden ocurrir por cómo está construido el sistema. Eso no está en el prompt. No puede estarlo.
La IA puede escribir los tests una vez que tú has definido los casos. Eso es útil: te ahorra el boilerplate, la sintaxis, la estructura. Pero la decisión de qué probar es tuya.
Antes de integrar cualquier código generado por IA, define explícitamente:
- Los casos de entrada válida esperada.
- Los casos de entrada inválida que tu sistema debe rechazar.
- Los estados de error que deben manejarse de forma específica.
- Los límites de rendimiento que el código debe respetar.
Luego deja que la IA escriba los tests para esos casos. Así tienes velocidad sin ceder el criterio.
Regla 4: La arquitectura es tuya. La implementación es asistida.
Este es el error conceptual más profundo del vibe coding mal entendido: confundir "la IA puede implementar" con "la IA puede decidir".
La arquitectura de un sistema es una acumulación de decisiones con consecuencias a largo plazo. Qué patrones usas, cómo separas responsabilidades, dónde pones los límites entre módulos, qué contratos defines entre servicios. Esas decisiones determinan si el sistema es mantenible dentro de dos años o si se convierte en un monolito de barro que nadie quiere tocar.
La IA no tiene acceso a esas restricciones. No sabe cuánto equipo tienes, cuál es el nivel técnico de quien va a mantener esto, qué partes del sistema van a cambiar más y cuáles van a ser estables. Genera soluciones técnicamente válidas que pueden ser arquitectónicamente desastrosas para tu contexto.
El flujo correcto es:
- Tú defines la arquitectura. Qué componentes existen, cómo se comunican, qué responsabilidades tiene cada uno.
- Tú defines las interfaces. Las firmas de las funciones, los contratos de los módulos, los tipos de datos.
- La IA implementa dentro de esas restricciones. Rellena el interior de las cajas que tú has dibujado.
Cuando la IA propone una arquitectura y tú la aceptas porque "suena bien", estás cediendo la decisión más importante a algo que no tiene ni idea de lo que estás construyendo ni para quién.
David C, del NCSC, lo planteó en términos de seguridad: los guardrails deterministas sobre lo que el código puede hacer deben definirlos los humanos. La IA ejecuta dentro de esos guardrails, no los define. Exactamente el mismo principio aplicado a la arquitectura.
Regla 5: Refactoriza el código generado cada sprint o se pudre
El código generado por IA envejece mal. Más mal que el código escrito a mano, y eso ya es decir bastante.
El motivo es estructural: la IA genera código que resuelve el problema del momento de forma local, sin visión del conjunto. Cada pieza funciona. La suma de piezas tiende a ser incoherente: nombres inconsistentes, patrones mezclados, lógica duplicada en sitios distintos, abstracciones que se solapan.
A corto plazo no se nota. A medio plazo, el sistema se vuelve difícil de entender. A largo plazo, nadie quiere tocarlo porque nadie sabe qué romperá si mueve algo.
David C señaló en su post del NCSC que la IA puede ayudar a pagar deuda técnica, incluyendo el endurecimiento de aplicaciones legacy. Es una observación interesante: la misma herramienta que genera deuda técnica rápidamente puede también ayudar a reducirla, si se usa con ese objetivo explícito. Y aquí el razonamiento de los modelos empieza a jugar un papel real: modelos como VibeThinker-3B, diseñados específicamente para razonar sobre código, pueden identificar inconsistencias estructurales con más criterio que un modelo generativo estándar.
Pero eso requiere que alguien decida activamente refactorizar. Que no sea algo que "ya haremos cuando tengamos tiempo" (es decir, nunca), sino un ítem concreto en cada sprint.
Las señales de que el código generado está pudriéndose:
- Hay lógica similar implementada de formas distintas en distintos módulos.
- Los nombres de variables y funciones no siguen ningún patrón coherente.
- Para entender qué hace una función hay que leer el cuerpo entero porque el nombre no lo dice.
- Los comentarios explican el qué en lugar del por qué (señal de que la IA los generó para parecer documentado).
La refactorización no es un lujo. Es el mantenimiento mínimo para que el código generado no se convierta en un pasivo.
El aviso que la industria lleva meses ignorando
Horne lo dijo en RSA 2026 con la claridad que se le exige a alguien en su posición: la oportunidad es real, el riesgo también, y la diferencia está en si construyes con criterio o sin él.
El NCSC no nombró ninguna herramienta específica. No hizo anuncios de producto. No vendió nada. Se limitó a señalar que el software producido manualmente ha sido consistentemente vulnerable durante décadas, y que la IA ofrece una oportunidad genuina de romper ese ciclo, pero solo si las salvaguardas se integran desde el principio, no como parche a posteriori.
Ese "desde el principio" es la clave. Secure-by-default significa que el sistema arranca seguro, no que alguien lo asegura después. Aplicado al vibe coding: el criterio va antes del código, no después de que el bug ya esté en producción.
La sierra eléctrica sigue siendo una herramienta extraordinaria. Corta más rápido, con más precisión, con menos esfuerzo que cualquier alternativa manual. Pero sigue necesitando a alguien que sepa qué está cortando, por qué, y dónde no meter los dedos.
Eso no lo enseña la herramienta. Lo pones tú.
