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 personas que construyen aplicaciones durante un fin de semana. Herramientas que prometen crear una empresa escribiendo una frase. Agentes capaces de diseñar, programar, desplegar y corregir una web aparentemente sin intervención humana.

La promesa suele ser parecida:

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

Hay una parte de verdad en eso.

Yo he construido mi propia web utilizando inteligencia artificial como herramienta principal de desarrollo. No solo una landing visual, sino un proyecto con:

• Página principal.
• Tienda.
• Catálogo dinámico.
• Fichas de producto.
• Carrito.
• Pagos.
• Blog.
• Base de datos.
• Almacenamiento de imágenes.
• Panel de administración.
• Inicio de sesión.
• Protección de sesiones.
• Despliegue automático.

El frontend utiliza HTML, CSS y JavaScript sin frameworks. La parte dinámica funciona sobre Cloudflare Pages Functions, con D1 para los datos y R2 para las imágenes. El panel administrativo está protegido mediante autenticación, sesiones firmadas y protección CSRF.

No soy ingeniero de software ni he seguido una carrera universitaria de programación.

Mi base viene del diseño y el arte digital, pero también tengo formación como técnico en informática y redes, experiencia con hardware y software, y conocimientos de HTML, CSS, WordPress, comercio electrónico, SEO, PHP básico y Python básico.

Eso significa que no partía completamente de cero.

Entendía conceptos técnicos, sabía moverme dentro de un proyecto y podía reconocer que una base de datos, un servidor, una API y una interfaz cumplen funciones distintas. Lo que no tenía era la capacidad tradicional de escribir por mi cuenta, línea a línea, todo el código necesario para construir una tienda completa.

La IA cambió esa limitación.

Pero no lo hizo pulsando un botón.

Este artículo es la explicación honesta de cómo construí mi web mediante vibecoding, qué partes funcionan realmente, dónde aparecen los problemas y por qué generar código no es lo mismo que desarrollar un producto fiable.

Qué significa realmente “vibecoding”

El término comenzó a popularizarse en 2025 después de que Andrej Karpathy describiera una forma de programar en la que una persona se entrega al flujo de la IA, acepta los cambios, ejecuta el código y devuelve los errores al modelo sin prestar demasiada atención a cada línea.

En su definición original, la idea incluía literalmente dejar de pensar demasiado en el código y centrarse en ver, pedir, ejecutar y corregir. Karpathy también situó este enfoque principalmente en proyectos experimentales o de fin de semana, no como una metodología rigurosa para sistemas críticos.

Esto crea una distinción importante.

Si la IA escribe el código y tú:

• No lees los cambios.
• No comprendes la estructura.
• Aceptas todo.
• Pruebas únicamente si “se ve bien”.
• Corriges errores con instrucciones aleatorias.
• Publicas cuando deja de fallar visualmente.

Eso se parece bastante al vibecoding original.

Si la IA escribe gran parte del código, pero tú:

• Defines la arquitectura.
• Limitas qué archivos puede modificar.
• Revisas los cambios.
• Ejecutas pruebas.
• Compruebas la seguridad.
• Mantienes control de versiones.
• Documentas las decisiones.
• Entiendes cómo se conectan las partes.

Eso se acerca más al desarrollo asistido por IA.

Yo utilizo la palabra vibecoding porque describe de forma sencilla 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 únicamente de “las vibraciones”.

Lo que no significa

Vibecoding no significa:

• Que la IA dirija correctamente el proyecto por sí sola.
• Que todo el código generado sea seguro.
• Que una web esté terminada porque carga.
• Que no necesites aprender nada técnico.
• Que puedas olvidarte del mantenimiento.
• Que todos los errores sean visibles.
• Que una persona sin contexto pueda construir cualquier sistema.
• Que generar una aplicación equivalga a crear un negocio.

La IA puede producir una interfaz convincente en pocos minutos.

Eso no demuestra que:

• Los formularios guarden correctamente los datos.
• Los pagos se confirmen.
• El stock no se descuadre.
• El panel esté protegido.
• Los secretos estén fuera del código.
• La web sea accesible.
• Los errores se gestionen.
• Los datos puedan recuperarse.
• El proyecto aguante futuros cambios.

Una demo está diseñada para demostrar una idea.

Un producto debe continuar funcionando después.

Mi punto de partida real

No empecé siendo programador profesional, pero tampoco sin ninguna base.

Había trabajado con:

• Mantenimiento informático.
• Diagnóstico de hardware.
• Redes.
• WordPress.
• WooCommerce.
• Elementor.
• HTML.
• CSS.
• Edición de código.
• SEO para comercio electrónico.
• Herramientas de diseño, fotografía y vídeo.

Mi ventaja inicial no era saber construir todo el backend.

Era poder comprender aproximadamente qué estaba intentando construir.

Sabía que una tienda necesitaba algo más que páginas bonitas. Necesitaba:

• Productos.
• Variantes.
• Precios.
• Stock.
• Pedidos.
• Pagos.
• Imágenes.
• Administración.
• Seguridad.
• Estados de error.

La IA me permitió cubrir la distancia entre entender esos componentes y ser capaz de implementarlos.

Qué construí con IA

Mi proyecto actual es una marca personal con servicios, contenido y una sección secundaria de productos. La web funciona también como caso de estudio para demostrar cómo trabajo con pequeños negocios.

Técnicamente, la estructura principal es:

Frontend
HTML + CSS + JavaScript vanilla

Backend
Cloudflare Pages Functions

Base de datos
Cloudflare D1

Imágenes y archivos
Cloudflare R2

Pagos
Stripe

Código
GitHub

Despliegue
Push a main → Cloudflare Pages

No utilicé un framework grande ni un constructor visual para resolver toda la web.

La IA me ayudó a trabajar directamente con los archivos del proyecto.

La parte pública

Incluye:

• Navegación.
• Página principal.
• Servicios.
• Proyectos.
• Blog.
• Tienda.
• Página de producto.
• Carrito.
• Diseño responsive.
• Metadatos para buscadores.

La parte dinámica

Incluye:

• Lectura de productos desde D1.
• Variantes.
• Stock.
• Datos de catálogo.
• Imágenes almacenadas en R2.
• Solicitudes al backend.
• Gestión de pedidos.
• Integración de pagos.

La parte administrativa

Incluye:

• Página de acceso.
• Sesiones.
• Protección del panel.
• Creación y edición de productos.
• Subida de imágenes.
• Gestión del catálogo.
• Variables privadas fuera del repositorio.

El proyecto guarda los secretos en variables de entorno cifradas de Cloudflare y utiliza una sesión firmada mediante HMAC y protección CSRF para el panel administrativo.

Esto es importante porque muestra dónde deja de ser suficiente pedir:

Créame un panel de administración.

La petición correcta empieza a ser:

Créame un panel, pero explícame cómo se autentica, dónde vive la contraseña, cómo se firma la sesión, cómo se evitan solicitudes falsificadas y qué ocurre cuando faltan los secretos en producción.

La segunda petición requiere más criterio.

Lo que la IA hizo especialmente bien

1. Eliminar la página en blanco

Empezar desde cero puede bloquear más que corregir algo imperfecto.

Con IA podía describir una estructura inicial:

Necesito una página de producto con galería, selector de talla, precio, información de envío y botón de compra.

La herramienta podía preparar:

• HTML.
• Estructura CSS.
• Comportamiento JavaScript.
• Estados vacíos.
• Mensajes de error.
• Versión móvil inicial.

Después yo podía ver el resultado y señalar:

• Esta sección sobra.
• Este botón no destaca.
• El móvil se rompe.
• El selector no tiene sentido.
• El diseño no encaja con la marca.

La primera versión dejaba de requerir horas de trabajo manual.

2. Convertir ideas visuales en estructura

Como diseñador, muchas veces tengo bastante claro cómo quiero que se vea algo.

Puedo explicar:

• La jerarquía.
• El espacio.
• El peso visual.
• La relación entre secciones.
• La sensación de la interfaz.
• Lo que no debe parecer.

La IA traduce parte de esas decisiones hacia:

• Contenedores.
• Grid.
• Flexbox.
• Breakpoints.
• Tipografía.
• Variables CSS.
• Estados interactivos.

Eso no elimina el diseño.

Hace que la distancia entre diseño e implementación sea menor.

3. Resolver trabajo repetitivo

Gran parte del desarrollo no es inventar sistemas complejos.

Consiste en repetir correctamente patrones como:

• Crear una tarjeta.
• Mostrar un estado de carga.
• Validar un campo.
• Preparar una consulta.
• Convertir una respuesta en JSON.
• Reutilizar un componente.
• Añadir atributos de accesibilidad.
• Escribir documentación.
• Actualizar varias referencias.

La IA es especialmente útil en estas tareas.

4. Explicar errores

Un mensaje de error tradicional puede ser difícil de interpretar.

Con IA podía aportar:

• El mensaje.
• El archivo.
• La función relacionada.
• Qué estaba intentando hacer.
• El resultado esperado.

La herramienta podía proponer una causa y señalar la zona relevante.

Eso acelera mucho el aprendizaje.

No solo recibes una corrección. Puedes pedir:

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

Cuando la respuesta es correcta, el error se convierte en una clase personalizada.

5. Auditar una idea antes de implementarla

Una de las mejores aplicaciones no es generar código.

Es pedirle a la IA que intente destruir la propuesta.

Por ejemplo:

Quiero guardar el carrito en el navegador y enviar el precio total al servidor. ¿Qué riesgos existen?

Una revisión razonable debería advertir:

• El usuario puede manipular el precio.
• El servidor debe consultar los importes reales.
• Las cantidades deben validarse.
• El stock debe comprobarse.
• El total debe recalcularse.

La IA puede actuar como una segunda voz crítica antes de escribir.

6. Trabajar sobre varios archivos

Los agentes de código modernos pueden inspeccionar el repositorio, localizar archivos relacionados, aplicar cambios coordinados y ejecutar comprobaciones.

Eso permite pedir tareas como:

Añade una nueva sección a la home respetando los estilos existentes, reutilizando las variables CSS y sin modificar la tienda ni las funciones.

La herramienta puede localizar:

• El HTML.
• La hoja de estilos.
• El JavaScript.
• Las convenciones del proyecto.

La calidad depende de que el contexto esté bien definido.

Lo que la IA no hizo por mí

1. Decidir qué negocio estaba construyendo

La IA podía proponer muchas direcciones.

No podía decidir cuál representaba mi estrategia.

Mi web empezó pareciéndose demasiado a una tienda de ropa. Técnicamente podía funcionar, pero comunicaba mal la prioridad del negocio.

La estrategia real es:

1. Servicios de marca y tienda online.
2. Contenido y construcción en público.
3. Productos digitales en una fase posterior.
4. Merch como expresión secundaria.

Esa decisión no era un problema de código.

Era un problema de posicionamiento.

Una IA puede implementar perfectamente la web equivocada.

2. Mantener una dirección visual por sí sola

Cuando generas secciones en momentos diferentes, aparecen inconsistencias:

• Botones distintos.
• Márgenes distintos.
• Sombras diferentes.
• Colores parecidos, pero no iguales.
• Tipografías con pesos arbitrarios.
• Componentes repetidos.
• Animaciones sin relación.

Cada resultado aislado puede parecer correcto.

El conjunto deja de parecer una marca.

Tuve que mantener reglas y corregir desviaciones.

3. Entender siempre el contexto completo

Una herramienta puede solucionar el archivo que tiene delante y romper otro que no ha considerado.

Por ejemplo:

• Cambia una clase utilizada en cinco páginas.
• Modifica una función compartida.
• Duplica lógica existente.
• Crea un nuevo estilo en lugar de reutilizar uno.
• Introduce una dependencia innecesaria.
• Cambia una respuesta de API sin actualizar el frontend.

La IA trabaja mejor cuando puede leer el repositorio, pero incluso entonces puede perder decisiones anteriores.

El contexto no es memoria perfecta.

4. Saber cuándo una solución era excesiva

A veces proponía:

• Un framework completo para una interacción sencilla.
• Una librería para una función que podía resolverse en pocas líneas.
• Una arquitectura pensada para millones de usuarios.
• Varias capas de abstracción para un único caso.
• Un sistema genérico cuando necesitaba uno específico.

La sobreingeniería también es un error.

Un proyecto pequeño no necesita fingir que es una gran plataforma.

5. Garantizar seguridad

Este es el límite más importante.

El código generado puede funcionar y seguir siendo vulnerable.

Un estudio empírico sobre fragmentos generados por asistentes encontró debilidades de seguridad en aproximadamente el 29,5 % de los fragmentos Python analizados y en el 24,2 % de los fragmentos JavaScript. Los fallos cubrían decenas de categorías CWE, incluidas algunas consideradas críticas.

Esto no significa que una cuarta parte de cualquier proyecto generado sea automáticamente vulnerable.

Significa que no puedes asumir que el código es seguro porque la IA lo produjo con confianza.

El mayor peligro: confundir “funciona” con “está bien”

Un botón funciona cuando responde al clic.

Pero una implementación correcta también debe preguntarse:

• ¿Qué ocurre si se pulsa dos veces?
• ¿Qué ocurre sin conexión?
• ¿Qué ocurre si la respuesta tarda?
• ¿Qué ocurre si el servidor devuelve HTML en vez de JSON?
• ¿Qué ocurre si falta un campo?
• ¿Qué ocurre si alguien manipula la petición?
• ¿Qué ocurre si el usuario no tiene permisos?
• ¿Qué ocurre si la misma operación se repite?

La primera versión suele cubrir el camino perfecto.

La calidad aparece al cubrir lo que se sale del camino perfecto.

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

Paso 1: defino el resultado antes de pedir código

Antes de abrir el agente intento responder:

• ¿Qué problema estoy resolviendo?
• ¿Quién utilizará esta función?
• ¿Qué debe ocurrir?
• ¿Qué no debe ocurrir?
• ¿Qué archivos puede afectar?
• ¿Cómo sabré que funciona?

Una petición como:

Mejora la tienda.

es demasiado amplia.

Una petición mejor sería:

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.

Ahora hay:

• Alcance.
• Restricciones.
• Comportamiento esperado.
• Criterio de aceptación.

Paso 2: pido que inspeccione antes de modificar

Cuando la tarea toca varias partes, no empiezo ordenando cambios.

Primero pido un análisis:

Localiza todos los archivos relacionados con el carrito. Explica el flujo actual, señala riesgos y no modifiques nada todavía.

Esto permite descubrir:

• Dónde se guarda el estado.
• Qué funciones se comparten.
• Qué depende del backend.
• Qué podría romperse.

La fase de lectura reduce cambios innecesarios.

Paso 3: divido el trabajo

No pido:

Construye la tienda completa.

Divido el proyecto:

1. Catálogo.
2. Ficha de producto.
3. Variantes.
4. Carrito.
5. Checkout.
6. Pedidos.
7. Webhook.
8. Panel.
9. Seguridad.
10. Correos.

Cada parte puede probarse antes de añadir la siguiente.

Cuando algo falla, el origen es más fácil de localizar.

Paso 4: exijo mantener las reglas del proyecto

En mi caso, las restricciones incluyen:

• HTML, CSS y JavaScript vanilla.
• Sin frameworks.
• Respetar los estilos existentes.
• No tocar funciones, migraciones o APIs sin pedirlo.
• No guardar secretos en el código.
• Mantener español.
• Adaptación responsive.
• Despliegue mediante GitHub y Cloudflare.

Estas reglas reducen la tendencia de la IA a reinventar el proyecto.

Paso 5: reviso el cambio, no solo el resultado

Que una página se vea correcta no basta.

Compruebo:

• Qué archivos cambió.
• Cuántas líneas añadió.
• Si duplicó código.
• Si eliminó algo.
• Si introdujo dependencias.
• Si modificó nombres públicos.
• Si tocó seguridad.
• Si cambió la estructura de datos.

El diff importa.

Una modificación pequeña debería producir un cambio pequeño, salvo que exista una razón clara.

Paso 6: ejecuto comprobaciones

Como mínimo:

• Sintaxis.
• Consola del navegador.
• Peticiones de red.
• Formularios.
• Navegación.
• Móvil.
• Estados vacíos.
• Errores.
• Datos reales de prueba.

El proyecto incluye un comando de comprobación de sintaxis antes del despliegue.

Un test automático no garantiza que todo funcione, pero evita publicar errores básicos.

Paso 7: pruebo el fallo deliberadamente

No pruebo únicamente:

¿Puedo iniciar sesión con la contraseña correcta?

También pruebo:

• Contraseña incorrecta.
• Sesión caducada.
• Cookie eliminada.
• Secreto ausente.
• Petición sin CSRF.
• Campo vacío.
• Imagen demasiado grande.
• Producto inexistente.
• API caída.

Una función fiable debe fallar de forma controlada.

Paso 8: despliego mediante control de versiones

Los cambios pasan por Git.

Esto permite:

• Ver qué cambió.
• Volver atrás.
• Comparar versiones.
• Recuperar archivos.
• Mantener historial.
• Desplegar desde una rama controlada.

En mi proyecto, el push a main activa el despliegue de Cloudflare Pages.

Publicar no debería depender de copiar archivos manualmente sin historial.

Paso 9: reviso producción

Que funcione en local no significa que funcione en producción.

Pueden cambiar:

• Variables de entorno.
• Dominios.
• Cookies.
• Permisos.
• CORS.
• Rutas.
• Base de datos.
• Recursos.
• Límites.
• Configuración de Stripe.

Después del despliegue vuelvo a comprobar los flujos importantes.

El tipo de prompt que mejor me funciona

No necesito escribir cien líneas para cualquier cambio.

Pero en tareas delicadas utilizo una estructura 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.
- No modificar otras partes del catálogo.
- Respetar los estilos existentes.

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

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

Después:
1. Ejecuta las comprobaciones disponibles.
2. Resume los archivos modificados.
3. Indica qué debo probar manualmente.

La calidad no depende solo de utilizar palabras técnicas.

Depende de explicar el problema con precisión.

Los errores más frecuentes que he visto

1. La IA asegura que terminó, pero falta una parte

Puede afirmar:

Implementación completada.

Y después descubres que:

• El botón no llama a nada.
• La función existe, pero no está importada.
• La migración no se aplicó.
• La ruta no coincide.
• El móvil no se revisó.
• El estado de error está vacío.

La declaración de la IA no es una prueba.

2. Corrige el síntoma, no la causa

Si un objeto llega vacío, puede añadir:

if (!data) return;

El error desaparece.

Pero quizá el verdadero problema es que la API dejó de devolver datos.

Ahora el sistema falla silenciosamente.

3. Añade parches sucesivos

Cuando una solución no funciona, puede añadir otra capa.

Después otra.

El archivo termina con:

• Condiciones duplicadas.
• Funciones antiguas.
• Estados contradictorios.
• Comentarios obsoletos.
• Código que nadie quiere tocar.

En algún momento hay que parar y simplificar.

4. Inventa funciones o propiedades

Los modelos pueden proponer:

• Métodos que no existen.
• Opciones de configuración incorrectas.
• Versiones antiguas de una API.
• Paquetes inventados.
• Rutas que parecen oficiales.

En asuntos técnicos actuales, la documentación oficial debe tener prioridad.

5. Cambia demasiado

Pides corregir un formulario y recibes:

• Un formulario nuevo.
• Estilos nuevos.
• Una librería.
• Una estructura distinta.
• Cambios de nombres.
• Refactorización completa.

Más código no significa mejor solución.

6. Introduce secretos

Una respuesta puede mostrar una clave como ejemplo y dejarla escrita directamente en el archivo.

Las claves privadas deben vivir en variables de entorno, no en el frontend ni en el repositorio.

Mi proyecto separa los secretos locales y los de producción, manteniéndolos fuera del código público.

7. Protege la interfaz, pero no el servidor

Ocultar un botón administrativo no protege una función.

Una persona puede llamar directamente a la API.

Los permisos deben comprobarse en el backend.

8. Valida solo en el navegador

La validación del frontend mejora la experiencia.

No es seguridad.

Una solicitud puede enviarse manualmente sin utilizar el formulario.

Los datos deben validarse otra vez en el servidor.

9. Confía en los datos enviados por el cliente

En una tienda, el navegador no debe decidir:

• Precio.
• Descuento.
• Stock.
• Permisos.
• Estado de pago.

El servidor debe reconstruir y validar la operación.

10. Borra funcionalidad que no comprende

Durante una refactorización, la IA puede considerar código “no utilizado” cuando en realidad se carga dinámicamente o depende de otra página.

Por eso los cambios destructivos requieren más revisión.

Seguridad: la parte menos compatible con “ir a la vibra”

Hay proyectos donde equivocarse cuesta poco.

Una herramienta interna para ordenar ideas puede tolerar algunos fallos.

Una tienda almacena:

• Datos personales.
• Direcciones.
• Pedidos.
• Stock.
• Sesiones.
• Pagos.
• Accesos administrativos.

La tolerancia cambia.

Áreas que no publicaría sin revisar

Autenticación

• Contraseñas.
• Cookies.
• Sesiones.
• Recuperación de acceso.
• Expiración.
• Cierre de sesión.

Autorización

No solo quién eres, sino qué puedes hacer.

Pagos

• Precios.
• Webhooks.
• Idempotencia.
• Stock.
• Reembolsos.
• Confirmaciones.

Subidas de archivos

• Tipo real.
• Tamaño.
• Nombre.
• Acceso.
• Almacenamiento.
• Contenido peligroso.

Consultas a base de datos

• Parámetros.
• Permisos.
• Integridad.
• Condiciones de carrera.
• Errores.

APIs administrativas

• Autenticación.
• CSRF.
• Rate limiting.
• Validación.
• Logs.

Una interfaz puede estar terminada al 90 % cuando se ve bien.

Un sistema de pagos al 90 % está roto.

La deuda técnica aparece mucho más rápido

La inteligencia artificial reduce el coste de añadir funciones.

Eso crea una tentación:

Ya que puede hacerlo, añadamos también esto.

En pocos días puedes acumular:

• Panel.
• Usuarios.
• Cupones.
• Blog.
• Analítica.
• Automatizaciones.
• Notificaciones.
• Temas.
• Roles.
• Integraciones.

Cada función añade:

• Casos de error.
• Estados.
• Seguridad.
• Mantenimiento.
• Dependencias.
• Pruebas.

El cuello de botella deja de ser escribir el código.

Pasa a ser comprender y mantener todo lo creado.

La paradoja del vibecoding

Cuanto más fácil resulta añadir software, más importante se vuelve saber qué no añadir.

El criterio técnico sigue importando.

Pero también importan:

• Estrategia.
• Diseño.
• Producto.
• Operaciones.
• Costes.
• Experiencia del cliente.

Una web con veinte funciones innecesarias puede ser peor que una con cinco bien resueltas.

La IA no me convirtió en ingeniero de software

Esta distinción me parece importante.

Poder construir una web con IA no significa que tenga automáticamente:

• Años de experiencia.
• Conocimientos profundos de algoritmos.
• Dominio de sistemas distribuidos.
• Experiencia gestionando grandes cargas.
• Capacidad para auditar cualquier vulnerabilidad.
• Conocimientos de todos los lenguajes.
• Criterio para cualquier arquitectura.

Sería falso presentarlo así.

Lo que sí tengo ahora es:

• Mayor capacidad para convertir ideas en prototipos.
• Conocimiento práctico de arquitectura web.
• Experiencia trabajando con frontend y backend.
• Comprensión de bases de datos y APIs.
• Capacidad para dirigir tareas técnicas.
• Experiencia desplegando proyectos.
• Más criterio para detectar riesgos.
• Un sistema real que he tenido que construir y mantener.

La IA multiplicó mi capacidad.

No sustituyó todo lo que todavía necesito aprender.

Aprender mediante IA: útil, pero con una condición

La IA puede ser un profesor excelente cuando le pides explicaciones.

Puede adaptar una respuesta a tu nivel y explicar:

• Qué es una cookie.
• Cómo funciona una API.
• Qué hace una consulta SQL.
• Por qué falla CORS.
• Qué significa idempotencia.
• Para qué sirve CSRF.
• Cómo funciona una promesa en JavaScript.

Pero también puede explicar con seguridad algo incorrecto.

Por eso intento seguir esta regla:

Utilizo la IA para comprender el concepto y la documentación oficial para confirmar el comportamiento.

El objetivo no es memorizar cada método.

Es construir un modelo mental suficientemente bueno para detectar cuándo algo no encaja.

Cuándo el vibecoding funciona especialmente bien

Prototipos

Cuando quieres validar:

• Una interfaz.
• Un flujo.
• Una landing.
• Una herramienta interna.
• Un pequeño panel.
• Una idea de producto.

Proyectos personales

Puedes aceptar más riesgo porque tú controlas el uso.

Automatizaciones pequeñas

Procesos repetitivos con entradas y salidas claras.

Webs de contenido

Páginas informativas, blogs y portfolios con poca lógica sensible.

Herramientas con supervisión humana

La IA prepara una acción, pero una persona la revisa antes de ejecutarla.

Personas con una base técnica parcial

Diseñadores, especialistas de producto, analistas, técnicos o creadores que entienden sistemas aunque no escriban todo el código.

Cuándo no iría únicamente con vibecoding

No dependería de un proceso informal para construir sin revisión:

• Sistemas médicos.
• Software financiero crítico.
• Infraestructura pública.
• Aplicaciones con grandes volúmenes de datos sensibles.
• Sistemas donde un fallo pueda dañar físicamente a alguien.
• Plataformas con permisos complejos.
• Software regulado.
• Sistemas de seguridad.

La IA puede participar.

Pero se necesita revisión profesional, pruebas, auditoría y responsabilidad clara.

¿Puede un negocio contratar una web hecha con IA?

Sí.

La pregunta relevante no es:

¿La persona escribió todas las líneas manualmente?

La pregunta es:

• ¿La web resuelve el problema?
• ¿El código se puede mantener?
• ¿Está probado?
• ¿Es seguro?
• ¿Quién responde si falla?
• ¿El cliente controla sus cuentas?
• ¿Existe documentación?
• ¿Se puede migrar?
• ¿Se han utilizado licencias correctas?
• ¿Se protegen los datos?

Hoy prácticamente cualquier desarrollador puede utilizar herramientas de autocompletado, asistentes o agentes.

El valor profesional no está en demostrar que cada carácter se escribió a mano.

Está en hacerse responsable del resultado.

Lo que no vendería como servicio

No prometería:

Te construyo cualquier plataforma con IA en 48 horas.

Eso fuerza decisiones rápidas en áreas que necesitan revisión.

Tampoco ofrecería funciones que no pudiera mantener.

Mi servicio está dirigido a negocios pequeños que necesitan pasar de una idea a una marca y una web o tienda online funcional. El rango de trabajo previsto está entre 800 y 2.500 €, según el alcance, utilizando mi propia web como caso de estudio.

La IA forma parte del proceso.

No es la propuesta de valor principal.

El cliente no me paga por utilizar una herramienta determinada.

Me paga por:

• Entender el negocio.
• Definir la estructura.
• Diseñar la experiencia.
• Construir el sistema.
• Conectar las partes.
• Evitar errores.
• Entregar algo gestionable.

Cómo distinguir una web generada deprisa de una web trabajada

Una web generada deprisa suele tener:

• Textos genéricos.
• Diseño inconsistente.
• Secciones que no aportan.
• Formularios sin seguimiento.
• Acciones sin estado de carga.
• Errores silenciosos.
• Código duplicado.
• Componentes parecidos, pero distintos.
• Dependencias innecesarias.
• Credenciales mal gestionadas.
• Móvil poco revisado.
• Ninguna documentación.

Una web trabajada debería tener:

• Objetivo claro.
• Estructura coherente.
• Identidad.
• Textos específicos.
• Estados completos.
• Gestión de errores.
• Seguridad.
• Rendimiento.
• Accesibilidad básica.
• Analítica.
• Propiedad de las cuentas.
• Documentación.
• Posibilidad de mantenimiento.

La IA puede participar en ambos resultados.

La diferencia está en el proceso.

Mi lista antes de publicar una función

Producto

• ¿Resuelve un problema real?
• ¿Es necesaria ahora?
• ¿Está claro quién la usa?

Interfaz

• ¿Funciona en móvil?
• ¿Tiene estados de carga?
• ¿Muestra errores?
• ¿Puede utilizarse con teclado?
• ¿El texto explica qué ocurre?

Datos

• ¿Se valida la entrada?
• ¿Se conserva la integridad?
• ¿Qué ocurre con datos incompletos?
• ¿Se puede repetir la operación?

Seguridad

• ¿El servidor comprueba permisos?
• ¿Hay secretos en el código?
• ¿Se confía demasiado en el navegador?
• ¿La ruta administrativa está protegida?
• ¿Se registran datos sensibles?

Fallos

• ¿Qué ocurre sin conexión?
• ¿Qué ocurre si la API falla?
• ¿Qué ocurre si la petición se duplica?
• ¿Qué ocurre si falta configuración?
• ¿Se puede recuperar el estado?

Mantenimiento

• ¿Entiendo la solución?
• ¿Está duplicada?
• ¿Necesita documentación?
• ¿Puedo revertirla?
• ¿Añade una dependencia?

¿Deberías intentar construir con IA?

Probablemente sí cuando:

• Te interesa entender el proceso.
• Tienes paciencia.
• Puedes trabajar por fases.
• El proyecto permite experimentar.
• Estás dispuesto a comprobar resultados.
• No publicarás datos sensibles sin revisión.
• Aceptas que tendrás que aprender.

Probablemente no deberías hacerlo solo cuando:

• Necesitas un resultado crítico inmediatamente.
• No quieres revisar nada.
• No puedes mantener el proyecto.
• Vas a almacenar información sensible.
• Un error tendría consecuencias importantes.
• No sabes quién responderá cuando falle.

En esos casos, una solución administrada o un profesional con experiencia puede ser más barata que arreglar después un sistema frágil.

Lo que ha cambiado de verdad en 2026

La principal revolución no es que la IA programe sola.

Es que muchas más personas pueden participar en la construcción de software.

Un diseñador puede preparar una interfaz funcional.

Una persona de operaciones puede automatizar un proceso.

Un pequeño negocio puede probar una herramienta interna.

Un creador puede convertir una idea en un prototipo.

Eso reduce la distancia entre imaginar y probar.

Pero no elimina la distancia entre probar y mantener.

El prototipo se ha vuelto barato.

La fiabilidad sigue requiriendo trabajo.

La ventaja ya no es generar código

Cada vez más personas pueden crear:

• Una landing.
• Un panel.
• Una aplicación.
• Un formulario.
• Una tienda.
• Una automatización.

Por tanto, generar una primera versión deja de ser una ventaja duradera.

La ventaja pasa a ser:

• Elegir el problema correcto.
• Diseñar una solución clara.
• Mantener una dirección.
• Comprender al cliente.
• Probar.
• Simplificar.
• Proteger.
• Documentar.
• Responder cuando falla.
• Mejorar durante meses.

La IA ha abaratado la producción de código.

No ha abaratado automáticamente el criterio.

Mi conclusión

Construí mi web utilizando inteligencia artificial sin ser programador de carrera.

Eso es cierto.

También es cierto que:

• No apareció con una sola instrucción.
• La IA se equivocó.
• Algunas soluciones tuvieron que rehacerse.
• La seguridad necesitó atención específica.
• El contexto tuvo que documentarse.
• Cada función importante requirió pruebas.
• Tuve que aprender conceptos para poder dirigirla.

La IA me permitió construir algo que años atrás habría estado fuera de mi alcance inmediato.

Pero la parte más valiosa no fue que escribiera código por mí.

Fue que me permitió aprender mientras construía.

Hoy puedo pensar una función, dividirla, comprender qué piezas necesita, dirigir su implementación y detectar muchos de sus riesgos. Eso no me convierte de la noche a la mañana en ingeniero de software.

Me convierte en alguien con mucha más capacidad para ejecutar ideas técnicas.

Mi definición personal 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 empiezas a hacerte 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 una persona que tuvo que decir constantemente:

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