Vibecoding en 2026: construí mi web entera con IA sin ser programador de carrera

“Vibecoding” se ha convertido en una de esas palabras que aparecen en todas partes: vídeos de gente que construye una aplicación en un fin de semana, herramientas que prometen crear una empresa escribiendo una frase, agentes que diseñan, programan, despliegan y corrigen aparentemente solos.

La promesa siempre es parecida:

Describe lo que quieres y la inteligencia artificial se encarga del resto.

Hay una parte de verdad en eso. Yo he construido esta web usando IA como herramienta principal de desarrollo, y no hablo de una landing bonita: hay tienda con catálogo dinámico, fichas de producto, carrito, pagos con Stripe, blog, base de datos, almacenamiento de imágenes, panel de administración con inicio de sesión y despliegue automático. El frontend es HTML, CSS y JavaScript sin frameworks; la parte dinámica corre sobre Cloudflare Pages Functions con D1 para los datos y R2 para las imágenes.

También hay una parte que casi nadie cuenta, y es la que me interesa explicar aquí: generar código no es lo mismo que tener un producto fiable.

De dónde partía yo

No soy ingeniero de software ni he hecho una carrera de programación. Pero tampoco partía de cero, y decir lo contrario sería vender una historia más bonita que la real.

Vengo del diseño y el arte digital, y además tengo formación como técnico en informática y redes: mantenimiento, diagnóstico de hardware, WordPress, WooCommerce, HTML, CSS, algo de PHP y Python, SEO para comercio electrónico. Mi ventaja no era saber construir un backend. Era entender aproximadamente qué estaba intentando construir: que una base de datos, un servidor, una API y una interfaz hacen cosas distintas, y que una tienda necesita productos, variantes, stock, pedidos, pagos, administración y estados de error, no solo páginas bonitas.

Lo que no tenía era la capacidad de escribir yo solo, línea a línea, todo ese sistema. Ahí es donde la IA cambió mi límite. Pero no lo hizo pulsando un botón.

Qué significa realmente “vibecoding”

El término se popularizó en 2025, después de que Andrej Karpathy describiera una forma de programar en la que te entregas al flujo de la IA: aceptas los cambios, ejecutas, devuelves los errores al modelo y no prestas demasiada atención a cada línea. En su definición original la idea incluía literalmente dejar de pensar tanto en el código, y él mismo situaba ese enfoque en proyectos experimentales o de fin de semana, no como metodología para sistemas serios.

Esa distinción es la clave de todo el artículo.

Si la IA escribe el código y tú no lees los cambios, no entiendes la estructura, aceptas todo, pruebas solo si “se ve bien” y publicas cuando deja de fallar visualmente, eso es vibecoding en su sentido literal.

Si la IA escribe gran parte del código pero tú defines la arquitectura, limitas qué archivos puede tocar, revisas los cambios, ejecutas pruebas, compruebas la seguridad y mantienes control de versiones, eso ya es desarrollo asistido por IA. Se parecen en la herramienta y se diferencian en quién se hace responsable.

Yo uso la palabra vibecoding porque describe bien cómo empecé: hablando con una IA para convertir ideas en código. Pero cuanto más serio se volvió el proyecto, menos podía depender de las vibraciones.

Conviene decir también lo que no significa. No significa que la IA dirija bien el proyecto por sí sola, ni que el código generado sea seguro, ni que una web esté terminada porque carga, ni que puedas olvidarte del mantenimiento. Una IA puede producir una interfaz convincente en cinco minutos, y eso no demuestra que los formularios guarden bien los datos, que los pagos se confirmen, que el stock no se descuadre o que el panel esté protegido. Una demo está hecha para enseñar una idea. Un producto tiene que seguir funcionando después.

Lo que la IA hizo bien de verdad

Matar la página en blanco

Empezar bloquea más que corregir. Yo podía describir “una página de producto con galería, selector de talla, precio, información de envío y botón de compra” y recibir una primera versión con su HTML, su CSS, su comportamiento, sus estados vacíos y su versión móvil. A partir de ahí mi trabajo era el que sé hacer: mirar y señalar que esta sección sobra, que ese botón no destaca, que el móvil se rompe o que el diseño no encaja con la marca. La primera versión dejó de costarme horas.

Traducir decisiones visuales a estructura

Como diseñador suelo tener claro cómo quiero que se vea algo: la jerarquía, el espacio, el peso visual, la sensación que debe transmitir y —sobre todo— lo que no debe parecer. La IA traduce buena parte de eso a contenedores, grid, flexbox, breakpoints y variables CSS. No sustituye el diseño; acorta la distancia entre diseñarlo y verlo funcionando.

Hacer el trabajo repetitivo

Al margen del código, el resto del arsenal que uso está en las cinco herramientas de IA para montar una marca. Gran parte del desarrollo no consiste en inventar sistemas complejos, sino en repetir bien patrones conocidos: crear una tarjeta, mostrar un estado de carga, validar un campo, preparar una consulta, añadir atributos de accesibilidad, actualizar varias referencias a la vez. Ahí la IA es imbatible en tiempo.

Convertir un error en una clase particular

Un mensaje de error es difícil de interpretar cuando empiezas. Pegando el mensaje, el archivo y lo que estaba intentando hacer, la herramienta propone una causa y señala la zona relevante. Pero lo que más me ha servido no es la corrección, sino añadir una frase:

Explícame por qué ha ocurrido y qué concepto debo entender para que no se repita.

Cuando la respuesta es buena, el error deja de ser un obstáculo y se convierte en una clase hecha a tu medida.

Atacar mi propia idea antes de implementarla

Puede que este sea el uso más rentable y el menos comentado: no pedir código, sino pedir que destrocen la propuesta. Cuando planteé guardar el carrito en el navegador y enviar el precio total al servidor, la respuesta señaló lo evidente en cuanto lo lees: el usuario puede manipular ese precio, el servidor tiene que consultar los importes reales, las cantidades y el stock deben validarse y el total hay que recalcularlo. Una segunda voz crítica antes de escribir ahorra días.

Lo que la IA no hizo por mí

Decidir qué negocio estaba construyendo

Esta es la más importante y la que menos se menciona. Mi web empezó pareciéndose demasiado a una tienda de ropa (el proceso de esa parte lo conté en la guía para montar una marca de ropa desde cero). Técnicamente funcionaba, pero comunicaba mal la prioridad real del negocio, que son los servicios de marca y tienda para negocios pequeños, con el contenido y la construcción en público detrás y el merch como expresión secundaria.

Ese no era un problema de código. Era un problema de posicionamiento. Una IA puede implementar perfectamente la web equivocada.

Sostener una dirección visual

Cuando generas secciones en momentos distintos aparecen botones que no son el mismo botón, márgenes que no coinciden, sombras diferentes y colores parecidos pero no iguales. Cada pieza aislada parece correcta y el conjunto deja de parecer una marca. Mantener las reglas y corregir las desviaciones me tocó a mí.

Ver el proyecto entero

Una herramienta puede arreglar el archivo que tiene delante y romper otro que no ha mirado: cambia una clase usada en cinco páginas, modifica una función compartida, duplica lógica que ya existía o altera una respuesta de la API sin actualizar el frontend. Trabaja mucho mejor cuando puede leer el repositorio, pero incluso entonces pierde decisiones anteriores. El contexto no es memoria perfecta.

Saber cuándo algo es excesivo

Me ha propuesto un framework entero para una interacción sencilla, una librería para lo que se resuelve en diez líneas y arquitecturas pensadas para millones de usuarios. La sobreingeniería también es un error: un proyecto pequeño no necesita fingir que es una gran plataforma.

Garantizar la seguridad

Este es el límite duro, y no es una opinión. El código generado puede funcionar y seguir siendo vulnerable.

Un estudio empírico sobre fragmentos generados por asistentes encontró debilidades de seguridad en torno al 29,5 % de los fragmentos Python analizados y al 24,2 % de los de JavaScript, repartidas en decenas de categorías CWE, algunas consideradas críticas. Eso no significa que una cuarta parte de tu proyecto sea automáticamente vulnerable. Significa algo más incómodo: no puedes asumir que el código es seguro porque la IA lo produjo con seguridad en el tono.

El error de fondo: confundir “funciona” con “está bien”

Un botón funciona cuando responde al clic. Una implementación correcta, además, ha respondido antes a otras preguntas: qué pasa si se pulsa dos veces, si no hay conexión, si la respuesta tarda, si el servidor devuelve HTML en vez de JSON, si falta un campo, si alguien manipula la petición o si la misma operación se repite.

La primera versión casi siempre cubre el camino perfecto. La calidad aparece cuando cubres todo lo demás. Y es justo ahí donde “ir a la vibra” deja de servir.

Con la interfaz puedes permitírtelo: una web informativa al 90 % es una web aceptable. Con los pagos no. Un sistema de pagos al 90 % está roto. Por eso hay zonas que no publico sin revisar con calma: autenticación y sesiones, autorización (no solo quién eres, sino qué puedes hacer), pagos y sus webhooks, subidas de archivos, consultas a base de datos y cualquier API del panel. En esas partes el coste de equivocarse no lo paga el código: lo pagan los datos de una persona real.

Mi flujo de trabajo real

Mi proceso no es pedir → aceptar → publicar. Se parece más a esto:

Definir → limitar → generar → revisar → probar →
romper → corregir → comprobar → documentar → desplegar

Antes de pedir nada, defino el resultado. Qué problema resuelvo, quién lo va a usar, qué debe ocurrir, qué no debe ocurrir, qué archivos puede tocar y cómo sabré que funciona. “Mejora la tienda” no es una petición; es un deseo. Esto sí lo es:

En product.html, mejora el selector de variantes para que las opciones sin stock aparezcan desactivadas. Reutiliza la API actual, no cambies /functions, mantén JavaScript vanilla y comprueba la experiencia móvil. Si falta stock, muestra un mensaje accesible y no permitas añadir la variante al carrito.

Ahí hay alcance, restricciones, comportamiento esperado y criterio de aceptación.

Cuando la tarea toca varias partes, primero pido leer, no escribir: que localice los archivos relacionados, explique el flujo actual y señale riesgos sin modificar nada todavía. Esa fase de lectura evita la mitad de los cambios innecesarios.

Divido siempre. Nunca “construye la tienda completa”, sino catálogo, ficha, variantes, carrito, checkout, pedidos, webhook, panel, seguridad y correos, en ese orden y probando cada pieza antes de añadir la siguiente. Cuando algo falla, el origen está acotado.

Mantengo las reglas del proyecto por escrito —vanilla, sin frameworks, respetar los estilos existentes, no tocar funciones ni migraciones sin pedirlo, cero secretos en el código— porque son lo que impide que la IA reinvente el proyecto cada semana.

Reviso el diff, no la pantalla. Que la página se vea bien no basta: miro qué archivos cambió, si duplicó código, si borró algo, si añadió dependencias o si tocó seguridad. Un cambio pequeño debería producir un diff pequeño; cuando no es así, casi siempre hay una razón que conviene conocer.

Y pruebo el fallo a propósito. No solo si puedo iniciar sesión con la contraseña correcta, sino qué pasa con la contraseña incorrecta, con la sesión caducada, sin la cookie, sin el secreto, con una petición sin CSRF, con una imagen demasiado grande o con la API caída. Una función fiable no es la que no falla nunca: es la que falla de forma controlada.

Después, el despliegue pasa siempre por Git —push a main y Cloudflare Pages publica— y vuelvo a comprobar los flujos importantes en producción, porque las variables de entorno, los dominios, las cookies y la configuración de Stripe no son las mismas que en local.

Para tareas delicadas uso una estructura de petición parecida a esta:

Contexto:
Esta web utiliza HTML, CSS y JavaScript vanilla.
El backend funciona con Cloudflare Pages Functions y D1.

Objetivo:
Añadir una función para editar el stock de una variante desde el panel.

Restricciones:
- No utilizar frameworks.
- No cambiar el esquema de D1.
- No exponer secretos.
- Mantener el sistema actual de autenticación.

Comportamiento:
- Validar que el stock sea un entero igual o mayor que cero.
- Comprobar permisos en el servidor.
- Mantener el valor anterior si la actualización falla.

Antes de modificar:
1. Localiza los archivos implicados.
2. Explica el flujo actual y señala riesgos.
3. Propón el cambio mínimo.

La calidad de la respuesta no depende de usar palabras técnicas. Depende de explicar el problema con precisión.

Los fallos que se repiten

Después de meses trabajando así, los errores dejan de sorprenderme porque son casi siempre los mismos.

El más habitual es que la IA declare que ha terminado cuando falta una parte: el botón no llama a nada, la función existe pero no está importada, la migración no se aplicó o el estado de error está vacío. La declaración de la IA no es una prueba.

Después está corregir el síntoma en vez de la causa. Si un objeto llega vacío, añade un if (!data) return; y el error desaparece de la consola. Pero quizá el problema real era que la API dejó de devolver datos, y ahora el sistema falla en silencio, que es bastante peor. De ahí se pasa fácilmente a acumular parches: una capa sobre otra hasta que el archivo tiene condiciones duplicadas, funciones muertas y comentarios que ya no describen nada. En algún momento hay que parar y simplificar.

También inventa cosas con total naturalidad: métodos que no existen, opciones de configuración incorrectas, versiones antiguas de una API o rutas que parecen oficiales. En temas técnicos actuales, la documentación oficial manda siempre.

Y luego están los fallos que afectan a la seguridad, que son los que de verdad importan. Deja secretos escritos en el archivo cuando muestra un ejemplo con una clave. Protege la interfaz pero no el servidor, como si esconder un botón del panel impidiera llamar directamente a la API. Valida solo en el navegador, olvidando que una petición puede enviarse a mano sin pasar por el formulario. Y se fía de lo que envía el cliente: en una tienda, el navegador no puede decidir el precio, el descuento, el stock ni el estado del pago. El servidor tiene que reconstruir y validar la operación entera.

La deuda técnica llega mucho antes

La IA reduce el coste de añadir funciones, y eso crea una tentación muy concreta: ya que puede hacerlo, añadamos también esto. En pocos días acumulas panel, usuarios, cupones, blog, analítica, automatizaciones, notificaciones y roles.

Cada función nueva no añade solo su código. Añade sus casos de error, sus estados, su superficie de seguridad, su mantenimiento y sus dependencias. El cuello de botella deja de ser escribir y pasa a ser entender y sostener todo lo que has creado.

Ahí está la paradoja: cuanto más fácil resulta añadir software, más importante se vuelve saber qué no añadir. Una web con veinte funciones innecesarias es peor que una con cinco bien resueltas.

Esto no me ha convertido en ingeniero de software

Me parece importante decirlo con claridad, porque el discurso fácil va en la otra dirección.

Poder construir una web con IA no me da años de experiencia, ni conocimientos profundos de algoritmos, ni criterio para cualquier arquitectura, ni capacidad de auditar cualquier vulnerabilidad. Presentarlo así sería falso.

Lo que sí tengo ahora es conocimiento práctico de arquitectura web, experiencia real tocando frontend y backend, comprensión de bases de datos y APIs, criterio para detectar bastantes riesgos y, sobre todo, un sistema en producción que he tenido que construir y mantener. La IA multiplicó mi capacidad; no sustituyó lo que todavía me queda por aprender.

Con el aprendizaje sigo una regla simple, porque una IA también explica con seguridad cosas incorrectas: la uso para entender el concepto y la documentación oficial para confirmar el comportamiento. El objetivo no es memorizar métodos, sino construir un modelo mental lo bastante bueno para notar cuándo algo no encaja.

¿Puede un negocio contratar una web hecha con IA?

Sí. Pero la pregunta relevante no es si la persona escribió todas las líneas a mano —hoy casi cualquier desarrollador usa asistentes—, sino otra bastante distinta: ¿la web resuelve el problema?, ¿el código se puede mantener?, ¿está probado?, ¿es seguro?, ¿quién responde si falla?, ¿el cliente controla sus propias cuentas?, ¿se puede migrar a otra persona sin rescatar nada?

El valor profesional no está en demostrar que cada carácter se tecleó manualmente. Está en hacerse responsable del resultado.

Por eso hay cosas que no vendería. No prometería “te construyo cualquier plataforma con IA en 48 horas”, porque eso fuerza decisiones rápidas justo en las áreas que necesitan revisión. Tampoco ofrecería funciones que después no pudiera mantener. Mi trabajo está dirigido a negocios pequeños que necesitan pasar de una idea a una marca y una web o tienda que funcione, en un rango de 800 a 2.500 € según el alcance, usando esta misma web como caso de estudio. Puedes ver el detalle en servicios o reservar una llamada si quieres comentarlo. La IA forma parte del proceso, pero no es la propuesta de valor: nadie me paga por usar una herramienta concreta, sino por entender el negocio, definir la estructura, construir el sistema y entregar algo que se pueda gestionar sin depender de mí.

Lo que de verdad ha cambiado

La revolución no es que la IA programe sola. Es que mucha más gente puede participar en construir software: un diseñador prepara una interfaz funcional, alguien de operaciones automatiza un proceso, un negocio pequeño prueba una herramienta interna.

Eso ha reducido muchísimo la distancia entre imaginar y probar. No ha reducido la distancia entre probar y mantener. El prototipo se ha vuelto barato; la fiabilidad sigue costando lo mismo.

Y como cada vez más gente puede generar una landing, un panel o una tienda, generar la primera versión deja de ser una ventaja. La ventaja pasa a ser elegir el problema correcto, sostener una dirección, simplificar, proteger, documentar, responder cuando falla y seguir mejorándolo durante meses. La IA ha abaratado producir código. No ha abaratado el criterio.

Mi conclusión

Construí esta web con inteligencia artificial sin ser programador de carrera. Eso es cierto.

También es cierto que no apareció con una sola instrucción, que la IA se equivocó, que algunas soluciones hubo que rehacerlas enteras, que la seguridad necesitó atención específica y que cada función importante requirió pruebas. Tuve que aprender bastantes conceptos solo para poder dirigirla bien.

Lo más valioso no fue que escribiera código por mí. Fue que me permitió aprender mientras construía. Hoy puedo pensar una función, dividirla, entender qué piezas necesita, dirigir su implementación y detectar buena parte de sus riesgos. Eso no me convierte en ingeniero de software de la noche a la mañana; me convierte en alguien con mucha más capacidad para ejecutar ideas técnicas.

Mi definición, después de todo esto, sería esta:

El vibecoding sirve para empezar a construir antes de dominar cada detalle. El desarrollo responsable empieza cuando dejas de aceptar todo y te haces cargo del resultado.

Esta web es la prueba de que la barrera de entrada ha bajado. La tienda, el blog, la base de datos y el panel existen porque pude trabajar con la IA como copiloto. Pero si el proyecto funciona, no es solo porque la IA generó código: es porque detrás hubo decisiones, pruebas, errores, revisiones y alguien repitiendo constantemente la misma frase incómoda.

Esto funciona, pero todavía no está listo.