Vibe coding es programar describiendo lo que usted quiere en lenguaje natural y dejando que la IA escriba el código. La expresión salió de una publicación de febrero de 2025 y, en noviembre del mismo año, se volvió la palabra del año del diccionario Collins. Hoy se puede crear un sitio, una automatización o una app simple sin escribir una línea de código.
La pregunta útil no es si funciona, sino cómo usar las herramientas sin poner en línea algo que usted no entiende. Este artículo muestra los tipos de herramienta, un paso a paso seguro y los límites del método.
Verificación el 12 de octubre de 2026. Las herramientas citadas cambian de funciones y de precios con frecuencia; consulte la documentación oficial antes de elegir.
De dónde vino el vibe coding
El 2 de febrero de 2025, Andrej Karpathy, exdirector de IA de Tesla y uno de los fundadores de OpenAI, describió en X “un nuevo tipo de programación” en el que usted “se entrega a las vibraciones” y “olvida que el código existe”. Contó que hablaba con el asistente por voz y aceptaba los cambios sin leer las diferencias. Fuente: publicación de Karpathy.
El término prendió. Collins eligió “vibe coding” como palabra del año de 2025 y lo definió como el uso de IA, comandada por lenguaje natural, para ayudar a escribir código. Fuente: Collins Dictionary.
Conviene separar dos cosas. El desarrollador Simon Willison propone una definición estrecha: vibe coding es generar código con IA sin revisar lo generado. Usar IA y después leer, probar y entender el código es programación asistida por IA, no vibe coding. Fuente: Simon Willison. La diferencia importa porque define cuánto puede usted confiar en el resultado.
Los tres tipos de herramienta
Las herramientas se dividen por el lugar donde trabaja la IA y por cuánto control mantiene usted.
| Tipo | Cómo funciona | Ejemplos | Para quién |
|---|---|---|---|
| Generador de app en el navegador | Usted describe la app en un chat y recibe un proyecto que funciona, con vista en vivo | Lovable | Quien no programa y quiere un prototipo rápido |
| Asistente en el editor | La IA sugiere y edita código dentro del editor, archivo por archivo | GitHub Copilot, Cursor | Quien ya usa un editor de código |
| Agente de terminal | La IA lee el proyecto entero, corre comandos, ejecuta pruebas y propone cambios | Claude Code, Gemini CLI, Codex | Quien mantiene proyectos más grandes |
Cuanto más a la izquierda de la tabla (generador en el navegador), menos código ve usted. Cuanto más a la derecha (agente de terminal), más actúa sola la herramienta y más importa tener pruebas para comprobar lo que hizo.
Para empezar, elija según su punto de partida, no según la herramienta de moda: sin experiencia con código, un generador en el navegador; si ya usa un editor, un asistente; si el proyecto tiene varios archivos y pruebas, un agente.
Paso a paso para usar sin arrepentirse
El flujo de abajo vale para cualquiera de las tres categorías.
- Escriba lo que el software debe hacer antes de abrir la herramienta. Un párrafo con el objetivo, quién lo usa, qué datos entran y qué sale. La IA llena los vacíos con suposiciones; cuantos menos vacíos, menos sorpresas.
- Pida una cosa por vez. “Cree la pantalla de registro” funciona mejor que “cree el sistema completo”. Los pedidos más pequeños generan cambios que usted puede comprobar.
- Ejecute y pruebe cada cambio. Abra el resultado, haga clic, complete campos incorrectos a propósito. Si la herramienta lo permite, pida pruebas automatizadas y véalas pasar.
- Guarde versiones. Use el historial de la propia herramienta o un repositorio Git. Cuando la IA rompa algo que funcionaba, y eso ocurre, usted vuelve en segundos.
- Pida explicaciones. Pregunte “¿qué hace este fragmento?” y “¿qué datos envía este código hacia afuera?”. Si la respuesta no tiene sentido, no publique.
- Revise la seguridad antes de publicar. Las contraseñas y las claves de API nunca quedan en el código; los formularios necesitan validar lo que reciben; los datos de usuarios exigen cuidado con la LGPD.
El paso 6 no es un exceso de celo. En 2025, Veracode probó más de 100 modelos de lenguaje en 80 tareas de programación y encontró fallas de seguridad en el 45% de los casos; frente a ataques de cross-site scripting (inyección de script en páginas), los modelos fallaron en el 86% de las tareas. Los modelos más nuevos o más grandes no salieron mejor en seguridad. Fuente: Veracode.
Es decir: el código generado suele funcionar, pero funcionar no es lo mismo que ser seguro.
Dónde el vibe coding funciona y dónde no funciona
Funciona bien para:
- prototipos para validar una idea antes de invertir;
- herramientas internas y personales, usadas por pocas personas;
- automatizaciones simples, como organizar hojas de cálculo o renombrar archivos;
- aprender: pedirle a la IA que construya y explique es una buena forma de entender un código nuevo.
Exige un cuidado redoblado cuando:
- el sistema maneja pago, contraseña o dato personal;
- mucha gente va a depender de él en el día a día;
- alguien va a necesitar mantener el código dentro de un año.
En esos casos, el camino es la programación asistida: la IA escribe, pero una persona lee, prueba y responde por el resultado.
Programación asistida: las prácticas que uso
Nota de actualización (29/10/2026): este apartado incorpora el post “Programar con IA: las prácticas que separan la ayuda del daño”, publicado el 31/07/2026, que dejó de existir como página propia.
Este blog, el portal de capacitaciones y el robot que monitorea sitios oficiales nacieron con un asistente de IA en el teclado. Lo que esa rutina enseñó cabe en una frase: la IA amplifica lo que ya existe en el proceso. Donde hay disciplina, se vuelve velocidad; donde hay prisa, se vuelve daño a escala. Las prácticas de abajo están en uso, y cada una nació de un tropiezo real.
- El código que la IA entrega “listo” está solo propuesto. Nada está listo hasta que una prueba se ejecute de verdad. Aquí, todo cambio pasa por una batería de verificaciones automáticas antes de publicar, y lo que no se puede ejecutar se declara como “no probado”. Un cambio de fuentes que parecía perfecto en Windows reprobó en la prueba de layout en Linux, donde la fuente sustituta era otra; ninguna lectura de código detectaría eso.
- Una API citada por el modelo puede no existir. El modelo inventa método, parámetro y biblioteca con la misma seguridad con la que acierta. La regla: o la IA muestra la documentación real, o declara por escrito que está suponiendo. Una suposición declarada se comprueba en un minuto.
- Contrato ejecutable a mitad del camino. Cada post de este sitio pasa por un contrato de contenido que tumba el build cuando algo se sale de la regla. Ya frenó una etiqueta fuera de la lista y una descripción que superó el límite por un carácter. El contrato no distingue si quien se equivocó fue la persona o la IA, y por eso protege de los dos lados.
- Cambio pequeño, leído por personas. Con IA se produce más código por hora, y una revisión superficial se vuelve aprobación automática con otro nombre. El cambio tiene que caber en una revisión honesta, y nada llega a producción sin aprobación humana.
- Comprobar en el entorno publicado. Una prueba en verde no cierra el trabajo. Un selector de estilo genérico ya desalineó un sello en la página sin que ninguna prueba lo acusara. La automatización prueba la estructura; el acabado solo aparece para quien mira el resultado publicado.
- Reglas de la casa por escrito. Las convenciones del proyecto quedan en un archivo que la IA lee antes de empezar, y lo que se aprende se vuelve memoria de proyecto. Lo grabado orienta, pero la instrucción del momento gana, y el conflicto entre las dos se declara, nunca se resuelve en silencio.
Antes de aceptar lo que la IA escribió, responda: ¿una prueba ejecutó este código? ¿Cada API citada existe en la documentación? ¿Lo que frena el error antes de producción es código o buena intención? ¿El cambio cabe en una revisión honesta? ¿Alguien miró el resultado publicado? ¿Lo acordado está escrito donde lo encuentra la próxima sesión? Si alguna respuesta es “no”, esa es la práctica que falta.
Un ejemplo del otro lado: usar herramientas listas
No todo problema pide un software nuevo. Unir PDFs, convertir una imagen o hacer una cuenta recurrente ya tiene herramienta lista, y crear la suya solo tiene sentido cuando ninguna sirve.
Transparencia: BRUP — Ferramentas Úteis es un proyecto del autor de este blog. El sitio reúne herramientas en línea y contenido paso a paso que enseña a usar cada una. Aquí ya medimos si las herramientas de BRUP envían sus archivos a un servidor, con el procedimiento abierto para que usted lo repita.
Qué hacer ahora
El vibe coding bajó la barrera de entrada para crear software, pero no eliminó la responsabilidad por él. Elija la herramienta según su punto de partida, pida una cosa por vez, pruebe cada paso y revise la seguridad antes de publicar.
Si lo que usted necesita ya existe, empiece por las herramientas listas de BRUP — Ferramentas Úteis y siga el paso a paso de cada una. Si no existe, use el guion de este artículo y construya la suya.
Fuentes
- Origen del término — publicación de Andrej Karpathy en X, 2 de febrero de 2025.
- Palabra del año — Collins Dictionary Language Blog, 6 de noviembre de 2025.
- Definición estrecha — Simon Willison, “Not all AI-assisted programming is vibe coding”, 19 de marzo de 2025.
- Seguridad del código generado — Veracode, 2025 GenAI Code Security Report (comunicado), 30 de julio de 2025.
- Documentación oficial de las herramientas citadas, consultada el 12 de octubre de 2026.
- Prácticas de programación asistida — experiencia propia del autor: las prácticas están en uso en los proyectos citados, y los incidentes relatados están documentados en este sitio (verificado el 31 de julio de 2026).
