El espejismo del Vibe Coding : cuando la IA programa por ti

Llevamos un par de años viendo cómo la inteligencia artificial deja de ser una promesa académica y se convierte en una herramienta de trabajo cotidiana. Para quienes nos movemos en el ámbito STEM —ingenieros, científicos, desarrolladores, matemáticos— esto ha supuesto un cambio real y, en muchos casos, profundamente positivo. Pero hay una sombra que crece a la par del entusiasmo, y conviene mirarla de frente: el llamado Vibe Coding.

La IA es genuinamente útil — y conviene reconocerlo

Antes de entrar en lo crítico, hay que ser honestos: la IA generativa ha cambiado la productividad en programación de forma medible. No es marketing, es una experiencia compartida por miles de equipos. Cuando trabajas con un stack como Laravel + Livewire + FilamentPHP, hay tareas que antes consumían tardes enteras y hoy se resuelven en minutos: escribir un resource de Filament a partir de un modelo, refactorizar un trait que se repite en seis controladores, generar tests de feature para validar una policy, o traducir un script de Python a una Artisan command equivalente.

En investigación científica el impacto es aún más evidente. Procesar datasets, escribir scripts de análisis estadístico, automatizar pipelines de simulación, generar visualizaciones... La IA actúa como un puente entre la pregunta científica y la implementación técnica, permitiendo que un físico, un biólogo o un químico no tengan que detener su investigación cada vez que necesiten 200 líneas de NumPy o pandas.

Hasta aquí, todo bien. La IA es una palanca. El problema empieza cuando dejamos de empuñar la palanca y nos limitamos a admirar cómo se mueve.

¿Qué es exactamente el Vibe Coding?

El término lo acuñó Andrej Karpathy a principios de 2025 en un tweet que se viralizó. Su definición original era casi cariñosa: programar dejándote llevar, describiendo lo que quieres, aceptando lo que el modelo te devuelve, sin entrar mucho en el detalle. "Forget the code even exists", escribió. Para Karpathy, en su contexto, era una forma divertida de prototipar fines de semana.

Pero los términos viven más allá de quien los crea. Vibe Coding se ha convertido en la etiqueta que describe una práctica mucho menos inocente: programar por sensación, sin comprensión, dejando que el modelo decida la arquitectura, las dependencias, los nombres de las variables y, sobre todo, las decisiones que más adelante van a doler.

Vibe Coding es escribir un prompt, copiar la respuesta, ver que "funciona" en local, hacer commit, y pasar al siguiente prompt. Es construir una aplicación entera sin ser capaz de explicarla. Es resolver el síntoma sin entender la enfermedad.

La sensación de productividad no siempre es productividad

Aquí está el truco psicológico —y por tanto, el peligro real—: el Vibe Coding se siente extraordinariamente productivo. Tu IDE se llena de código, tu repositorio acumula commits, tu Pull Request crece. Hay actividad. Hay output. Si midiéramos la productividad por líneas escritas o tareas cerradas en el sprint, serías un superhéroe.

El problema es que esa métrica miente. La productividad real en software no es escribir código, es resolver problemas de forma que se mantengan resueltos. Y lo que el Vibe Coding produce, con una frecuencia incómoda, es código que funciona en el camino feliz pero rompe en cuanto sale de él, porque no se pensaron los edge cases. Código que introduce dependencias innecesarias o, peor, inseguras: paquetes obsoletos, librerías "alucinadas" por el modelo que ni siquiera existen en el repositorio oficial. Código que repite patrones inconsistentes a lo largo del proyecto, porque cada conversación con la IA empieza desde cero. Código que arrastra problemas de N+1 en Eloquent, fugas de memoria, vulnerabilidades de tipo mass assignment o SQL injection que el modelo no señaló porque tú no preguntaste. Código que acumula deuda técnica a una velocidad que solo se hace visible meses después, cuando alguien —probablemente tú— tiene que tocar ese módulo.

Hay un fenómeno especialmente cruel: cuando algo se rompe en producción, no sabes por qué se rompió. No escribiste el código. No lo pensaste. No tienes el modelo mental que se construye al diseñar algo desde cero. Estás depurando una caja negra que tú mismo creaste hace tres meses, prompt a prompt.

La pregunta incómoda

Aquí es donde toca mirarse al espejo. Hazte la pregunta y responde con honestidad, sin matices que te protejan:

Si te quitásemos ahora mismo todas las herramientas de IA, ¿podrías seguir haciendo tu trabajo?

No "lo harías más despacio". No "tardaría más en googlear". La pregunta es categórica: ¿podrías hacerlo? Si tienes que entregar un panel de Filament con permisos por rol, una policy compleja, un job en cola que procese un CSV de 200.000 filas, ¿sabrías construirlo desde cero abriendo solo la documentación de Laravel?

Si la respuesta es sí, la IA es lo que debe ser: una herramienta. Te acelera, te quita fricción, te ayuda a explorar opciones, pero el ingeniero sigues siendo tú.

Si la respuesta es no, hay que detenerse. No para abandonar la IA —eso sería tirar al niño con el agua sucia— sino para reconocer que se ha invertido la relación. La herramienta te está usando a ti más de lo que tú la usas a ella. Y a medio plazo, esto es un problema profesional serio: tu valor en el mercado es exactamente lo que sabes hacer cuando la herramienta no está, porque eso es lo que diferencia a un ingeniero de un operador.

La diferencia entre apoyarse y depender

Una analogía útil: un médico moderno usa resonancias magnéticas, analíticas de sangre, software de diagnóstico. Nadie le pediría que renunciase a esas herramientas. Pero si un médico no es capaz de razonar un diagnóstico cuando el equipo de imagen está averiado, no es médico, es un intérprete de máquinas. La diferencia se nota cuando el caso es raro, cuando los síntomas son ambiguos, cuando la máquina dice una cosa y el paciente está diciendo otra.

En programación pasa exactamente lo mismo. Cuando el problema es estándar —un CRUD, un endpoint REST, una migración rutinaria— la IA basta y sobra. Cuando el problema es raro —una concurrencia que solo aparece en producción con cierto patrón de tráfico, una decisión arquitectónica con implicaciones a tres años, un bug en una librería de terceros que requiere leer su código fuente— la IA es un asistente, pero quien tiene que pensar eres tú. Y para pensar bien necesitas haber pensado mal antes muchas veces, sin atajos. Esa capacidad solo la construyes con horas de cabezazos contra problemas reales.

Cómo usar la IA sin perderte en ella

No hay receta universal, pero sí hay hábitos que separan al ingeniero que usa IA del que es usado por ella.

1. Entiende cada línea que comiteas. Si la IA te genera un trozo de código y no eres capaz de explicarlo en voz alta, no está listo para entrar en tu repositorio. La presión por entregar es real, pero el código que no entiendes es una hipoteca con intereses ocultos.

2. Lee la documentación primero, a veces. No siempre. Pero algunas veces a la semana, resuelve un problema sin asistencia. Abre la documentación oficial de Laravel, de Livewire, de Filament, de Tailwind. Construye el modelo mental tú mismo. Esto es el equivalente intelectual de ir al gimnasio: no es lo más eficiente para resolver el problema concreto, pero es lo que mantiene tu capacidad muscular a medio plazo.

3. Usa la IA como tutor, no como redactor fantasma. Pregúntale por qué algo funciona, no solo cómo hacer que funcione. Pídele que te explique los trade-offs de una decisión, que te liste alternativas, que te diga qué problemas tendrías que vigilar. La conversación cambia radicalmente cuando dejas de pedir código y empiezas a pedir entendimiento.

4. Desconfía de las dependencias que no has revisado. Los modelos tienen tendencia a sugerir paquetes que no existen, paquetes abandonados, o paquetes con vulnerabilidades conocidas. Antes de añadir una librería a tu composer.json o a tu package.json, abre el repositorio, mira la última fecha de commit, lee los issues abiertos, comprueba quién la mantiene.

5. Revisa el output con escepticismo profesional. El modelo no sabe lo que es cierto, sabe lo que es probable. En tareas estándar, lo probable y lo cierto coinciden. En tareas raras, no. Trata cada respuesta como tratarías la de un junior brillante pero inexperto: probablemente bien, pero hay que verificar.

Cierre: la herramienta amplifica al artesano

Las buenas herramientas amplifican. Amplifican al que sabe y amplifican al que no sabe. Esa es su naturaleza neutral. La cuestión no es si la IA es buena o mala para programar —es claramente buena— sino quién está al volante.

El Vibe Coding es lo que pasa cuando soltamos el volante y dejamos que el coche conduzca solo, mientras nosotros miramos por la ventana disfrutando del paisaje. Funciona en autopistas rectas y bien iluminadas. Falla, a veces de forma catastrófica, en cuanto aparece una curva que el sistema no había visto antes.

Sigue usando la IA. Apóyate en ella sin pudor. Pero, de vez en cuando, hazte la pregunta. Apaga el copiloto. Resuelve algo solo. Comprueba que sigues siendo el ingeniero que crees que eres. Si la respuesta es sí, enhorabuena: estás usando la herramienta. Si la respuesta es no, todavía estás a tiempo de cambiar la relación.

Y cambiarla, créeme, es lo más rentable que vas a hacer este año.