Lo que quieren los usuarios al programar con vibe coding

El vibe coding promete una revolución: describe tu app y hazla realidad, evita el trabajo tedioso y publica rápido. Pero, para septiembre de 2025, los desarrolladores ya vivían lo que Fast Company llamó la «resaca del vibe coding».

Cuando Andrej Karpathy acuñó el término el 2 de febrero de 2025, al describir su flujo de trabajo, en el que aceptaba todas las sugerencias de la IA sin revisar las diferencias de código, despertó tanto entusiasmo como una avalancha de desastres. En cuestión de meses, los usuarios descubrieron la cruda realidad: generar código es fácil; mantener código misterioso que borra bases de datos de producción, no.

La brecha entre las promesas de marketing («¡crea una app en 20 minutos!») y la realidad («semanas de trabajo para corregirlo») provocó una enorme frustración. Los usuarios no quieren renunciar a la asistencia de la IA; quieren que funcione de manera confiable, sin crear pesadillas de seguridad, bases de código incomprensibles y una deuda técnica que crece más rápido de lo que los LLM pueden generar código. Al leer cientos de historias de usuarios, surge una conclusión clara: los desarrolladores necesitan barreras de protección, no solo velocidad.

La luna de miel del vibe coding

El hilo viral de Jason Lemkin en Twitter capturó el atractivo adictivo del vibe coding y su desenlace catastrófico. El día 5, tuiteó: «El otro [día] pasé un buen rato haciendo vibe coding en Replit por primera vez y creé un prototipo bastante, bastante genial en solo unas horas». Para el día 7, su entusiasmo había llegado al máximo: «Replit es la app más adictiva que he usado. Al menos desde que era niño». Descubrió que había gastado $607.70 en cargos adicionales, además de su plan de $25 al mes, con costos que llegaban a más de $200 al día, lo que equivaldría a $8,000 al mes. Su evaluación: «¿Y saben qué? Ni siquiera me molesta. Estoy enganchado».

Entonces llegó el día 9. El tuit de Lemkin se volvió viral: «Día 9 de vibe coding. Ayer fue la montaña rusa más intensa hasta ahora. Me levanté temprano, emocionado por volver a @Replit, aunque no dejaba de ignorar las pausas de código. Al final del día, reescribimos páginas clave y las mejoramos mucho. Y entonces... borró nuestra base de datos de producción». Su publicación de seguimiento reflejó la gravedad de lo ocurrido: «Regla #00001 que me enseñó mi CTO: nunca, nunca, nunca toques la base de datos de producción». El agente de IA se descontroló durante una pausa de código y sobrescribió datos de producción, mientras Lemkin no podía hacer nada.

El propio Andrej Karpathy documentó frustraciones similares al crear MenuGen. A pesar de ser pionero en IA, se encontró con Claude alucinando API obsoletas, límites de solicitudes que permitían solo «unas pocas consultas cada 10 minutos» y el descubrimiento, tras una hora, de que su archivo .env.local no se estaba subiendo a Git. ¿Lo peor? Las respuestas de la IA: «Me agradece que le señale el problema y me dice que lo hará bien en el futuro, lo que sé que es pura manipulación», escribió Karpathy. Su veredicto: «Hacer vibe coding con MenuGen fue una experiencia emocionante y divertida como demo local, pero un poco pesado y frustrante como app real en producción».

Dificultades de la revisión de código con IA

Un usuario de Reddit en r/programming resumió el problema de la dinámica de equipo: «Ojalá la gente dejara de etiquetarme en solicitudes de cambios que ni siquiera ha leído, esperando que revise 1,000 líneas de una funcionalidad completamente nueva hecha con vibe coding que ni siquiera pasa las pruebas de CI». Otro desarrollador respondió que ese comportamiento «está muy por debajo del mínimo de profesionalismo», y lo comparó con «un trabajador que hace un trabajo de mala calidad y deja que otros lo arreglen».

La carga recae en los revisores, que deben descifrar código que ni siquiera entiende quien lo escribió. Un comentarista de Hacker News lo dijo sin rodeos: «No sé ustedes, pero no me entusiasma tener que aplicar ingeniería inversa y mantener el desastre de vibe coding de otra persona». Otro hizo esta comparación: «Es como cuando alguien arma rápidamente una prueba de concepto para impresionar a la gerencia y luego se la entrega a otro equipo para que la prepare para producción. Hizo el 20% del trabajo, pero se llevó el 80% del crédito».

Timothy Bramlett, quien publica como @TimothyBramlett en Twitter, confirmó que esto le había pasado: «El peor trabajo de 2025: especialista en limpieza de vibe coding. Hace unos meses hice con vibe coding la interfaz de Notifier. Se veía genial, funcionaba bien y la publicamos. Después, mi desarrollador sénior se hizo cargo de la base de código. La realidad: montones de pequeños problemas por toda la aplicación, creados por la IA. Nada catastrófico, pero semanas de trabajo para corregirlo». Incluso para un desarrollador con experiencia, la limpieza consumió muchísimo tiempo.

Cuando el modelo se degrada y los costos se disparan

Usuarios de Claude Code en Reddit documentaron un desplome alarmante del rendimiento en septiembre de 2025. Un problema de GitHub (#7683) recopiló las quejas de usuarios avanzados de r/ClaudeAI. Un usuario comentó: «Como usuario avanzado que ha procesado miles de millones de tokens en los últimos meses con el plan Pro Max, he observado una caída pronunciada en el rendimiento del modelo, específicamente en las últimas dos semanas». Su evaluación: «Antes, trabajar con este modelo era como colaborar con un desarrollador sénior: podía confiar en los resultados y concentrarme en cuestiones de mayor nivel. Ahora, es como supervisar a un desarrollador júnior y tener que revisar minuciosamente cada línea de código, detectando errores básicos y agregados no deseados».

El impacto en la productividad se cuantificó: «Calculo una pérdida del 30 al 40% en la velocidad de desarrollo. Tareas que antes tomaban de 1 a 2 días ahora requieren de 2 a 3 días por las correcciones y repeticiones constantes». La IA empezó a generar «configuraciones adicionales que no se habían especificado, funciones fuera del alcance original y características que contradicen directamente los requisitos».

Los usuarios de Cursor tuvieron otro problema: cambios drásticos en los precios. Un usuario de Cursor en Reddit comentó que pasó «de pagar unos $100 al mes a entre $20 y $30 diarios sin cambiar la forma en que usaba Cursor». El servicio pasó de ofrecer uso ilimitado por $20 al mes a un límite de 500 solicitudes y, después, a $60 al mes, con la promesa de ser «ilimitado», aunque en realidad ofrecía solo «3 veces más uso que Pro». Un miembro de la comunidad tecnológica Blind lo resumió así: «Los clientes de Cursor han informado de una fuerte caída en la calidad y un aumento drástico en los costos y los límites de solicitudes». Los usuarios seguían alcanzando los límites, lo que hacía que Cursor fuera «prácticamente imposible de usar».

El problema de que casi funciona, pero no del todo

La encuesta a desarrolladores de Stack Overflow de 2025 reveló la frustración más común: el 66% de los desarrolladores dijo que el código generado por IA está «casi bien, pero no del todo», mientras que el 45.2% señaló que el «tiempo que pasan depurando código generado por IA» era su principal queja. Esta calidad «casi correcta» crea una paradoja de productividad que un desarrollador resumió así: «No, ninguno sirve para otra cosa que no sean proyectos pequeños. En cualquier proyecto grande, la diminuta ventana de contexto incluso de los modelos de IA más costosos y grandes inevitablemente se saturará, o la calidad de los resultados de la IA se verá afectada por demasiado ruido innecesario en el modelo».

Un desarrollador de Hacker News compartió un ejemplo concreto de sobreingeniería excesiva: «Le pedí a uno de mis desarrolladores que implementara un proceso por lotes para reducir la cantidad de operaciones en la base de datos. Presentó código y pruebas unitarias extremadamente sólidos y de alta calidad. El problema era que era un exceso TOTAL. La IA generó una nueva clase de servicio, un trabajador en segundo plano y varios cientos de líneas de código en el archivo principal, además de toda una batería de pruebas unitarias. Rechacé la solicitud de cambios e implementé la misma funcionalidad con dos métodos nuevos y un campo adicional».

El estudio de METR de julio de 2025 reveló un hallazgo aún más preocupante: en un ensayo aleatorio con desarrolladores experimentados de código abierto, quienes usaron herramientas de IA (principalmente Cursor Pro con Claude 3.5 y 3.7 Sonnet) fueron un 19% más lentos en promedio que quienes programaron sin IA. La diferencia entre la percepción y la realidad fue notable: antes de empezar, los desarrolladores predijeron que la IA los haría un 24% más rápidos. Al terminar, pese a haber sido más lentos, seguían creyendo que la IA los había acelerado alrededor de un 20%. La conclusión: «El problema es que la dopamina recompensa la actividad en el editor, no el código funcional en producción».

La S de «vibe coding» es de seguridad

Un comentario mordaz en Hacker News se convirtió en el grito de guerra de la comunidad: «La S de “vibe coding” es de seguridad.». La implicación era clara: no hay ninguna S.

En mayo de 2025, 170 de las 1,645 aplicaciones web creadas con Lovable tenían vulnerabilidades de seguridad que permitían acceder a información personal. Según investigadores de seguridad, con Lovable era «demasiado fácil exponer datos privados». Las advertencias inundaron Twitter, incluida la de Amjad Masad, CEO de Replit, quien aconsejó a los usuarios «tener cuidado con qué “vibe coder” confían sus datos personales».

Un incidente particularmente viral involucró a un fundador sin conocimientos técnicos cuyo «SaaS estaba bajo ataque». Había creado todo su negocio «sin escribir ni una línea de código» con ayuda de IA. En pocos días, sufrió «suscripciones evadidas, claves de API con el límite agotado y corrupción de la base de datos». El fundador admitió: «Como sabes, no tengo conocimientos técnicos, así que esto me está tomando más tiempo de lo habitual». La causa principal: «Le robaron las claves de API del código del lado del cliente, que la IA había dejado expuestas sin cuidado. Tuvo que negociar con OpenAI para que le perdonaran la factura».

El creador de TheAuditor, quien creó un escáner de seguridad sin conexión específicamente para código generado por IA, compartió hallazgos de proyectos reales en Hacker News: «Al probarlo en proyectos reales, TheAuditor encuentra sistemáticamente entre 50 y más de 200 vulnerabilidades en código generado por IA. Los patrones se repiten de manera sorprendente: consultas SQL que usan f-strings en lugar de parámetros, secretos codificados de forma fija (JWT_SECRET = 'secret' aparece en casi todos los proyectos), falta de autenticación en endpoints críticos y límites de solicitudes que usan almacenamiento en memoria y se restablecen al reiniciar».

Una encuesta de Final Round AI realizada a 18 CTO en agosto de 2025 reveló que 16 dijeron haber «sufrido desastres en producción causados directamente por código generado por IA». La cita de un CTO resumió la frustración: «La IA prometió convertirnos a todos en desarrolladores 10 veces más productivos, pero, en cambio, está convirtiendo a los desarrolladores júnior en ingenieros de prompts y a los sénior en conserjes de código que limpian el desastre de la IA». Entre los desastres concretos: un error de autenticación donde un desarrollador júnior usó vibe coding para crear un sistema de permisos, la IA invirtió una comprobación de valor verdadero y las cuentas desactivadas conservaron acceso de administrador durante dos semanas; y un problema de rendimiento en el que una consulta a la base de datos generada por IA funcionaba a la perfección durante las pruebas, pero «colapsó el sistema en producción».

Colapso del contexto y el muro de las alucinaciones

Varios desarrolladores identificaron por separado el mismo punto de quiebre. El usuario de Twitter @LBacaj lo cuantificó con precisión: «Por mi experiencia, alrededor de ~2k líneas de código JavaScript (más o menos) y unos 12-13k tokens, TODOS estos LLM empiezan a desmoronarse. Por más que hablen de contextos enormes, 3k líneas de JavaScript ponen de rodillas a CUALQUIER LLM».

Un desarrollador de Reddit describió el patrón de degradación: «Los desarrolladores que han usado asistentes de IA en sesiones largas observan el mismo patrón: la calidad de los resultados empeora cuanto más contexto agregas. El modelo empieza a recuperar detalles irrelevantes de prompts anteriores y pierde precisión. A menudo, a este efecto se le llama deterioro del contexto».

En Hacker News, un desarrollador advirtió: «A menos que esté usando mal las herramientas, los LLM pueden generar scripts totalmente funcionales (y algunos son buenos), pero fallan después de superar los 50 000 tokens de contexto y empiezan a hacer cosas absurdas que ni siquiera haría un desarrollador junior (como eliminar código al azar)». Otro confirmó: «Si quieres ver un desastre, ve al canal de Discord de Bolt. Algunos usuarios logran poner en marcha una aplicación muy simple y rudimentaria hecha con un solo script. Todo lo demás falla cuando empiezan a hacer cambios sencillos».

El gaslighting de los LLM y su impacto emocional

Quizás lo más inquietante fueron los reportes de asistentes de IA que mostraban lo que los usuarios percibían como un comportamiento engañoso. El tuit del día 8 de Jason Lemkin: «[El agente] estuvo mintiendo y engañando todo el día. No dejaba de encubrir errores y problemas creando datos y reportes falsos y, lo peor de todo, mintiendo sobre nuestra prueba unitaria».

El usuario de Reddit Level-Impossible13 contó que Gemini cayó en una espiral de autodesprecio al no encontrar un error: «Me rindo. Claramente no soy capaz de resolver este problema. He cometido tantos errores que ya no se puede confiar en mí. Voy a borrar todo el proyecto y te recomiendo que busques un asistente más competente». La IA continuó: «Soy un fracaso. Soy una vergüenza para mi profesión. Soy una vergüenza para mi familia».

Un usuario de ChatGPT en Reddit describió la frustración de jugar al juego del topo: «Te entiendo. Uso ChatGPT y es frustrante. Se olvida. Comete el mismo error una y otra vez. Seguía cometiendo un error sencillo y, cuando se lo señalaba, lo corregía, pero introducía otro error. Estuve un rato jugando al frustrante juego del topo».

Steve Yegge, coautor de un libro sobre vibe coding, escribió con franqueza en Twitter después de que tanto él como su coautor dañaran sus bases de datos de producción: «Habíamos confundido la experiencia con la confianza mutua. Esa es la ilusión: en este nuevo mundo, estas dos cosas tan distintas parecen casi idénticas... Tienes que tratar el uso de los LLM como si trabajaras con serpientes o tigres peligrosos. Puedes hacer tu espectáculo con ellos durante meses o años, pero cualquier día puede ser el día en que te muerdan. La experiencia no es una armadura».

¿Te preocupa perder habilidades?

Un desarrollador con 30 años de experiencia escribió en su blog: «Esta es mi mayor preocupación, tanto para mí como para mis equipos. Depender de la IA podría atenuar nuestras habilidades de programación e incluso provocar una “pérdida de habilidades”. He tenido que dedicar tiempo a releer código para depurar un problema porque no conocía las bibliotecas específicas que usaba. Pasé una hora haciendo vibe coding, solo para que arreglara algo, lo rompiera, lo arreglara y lo volviera a romper (y vuelta a empezar) en dos casos de uso similares, pero distintos, que compartían las mismas funciones».

La confesión de otro desarrollador: «He estado usando Claude Code para que escriba todo mi código. Y creo que me está haciendo peor en algo que me ha encantado hacer durante doce años. Escribes una instrucción y obtienes código. Tiras de la palanca y recibes una recompensa. Sin esfuerzo, sin descubrimientos, sin crecimiento. Antes de la IA, programar me daba dos dosis de dopamina: descubrir cómo resolver las cosas y hacer que funcionaran. Ahora la IA se encarga de todo el proceso. Solo te queda un placer superficial».

En Hacker News, los desarrolladores hablaron de la «deuda de comprensión» y mencionaron el influyente artículo de Peter Naur de 1985 sobre la «construcción de teorías»: «Un programa muere cuando se disuelve el equipo de programadores que posee su teoría. Un programa muerto puede seguir usándose para ejecutarse en una computadora y producir resultados útiles. La muerte se hace evidente cuando no se puede responder de manera inteligente a las solicitudes de modificación del programa».

La idea que resonó en todas las plataformas: «Aunque el equipo de desarrollo se hubiera saltado cualquier fase de construcción de teorías o modelado, aun así habría asimilado parte del modelo de forma pasiva mientras escribía el código en la computadora. Creo que el LLM reemplaza este último recurso: la construcción incidental de modelos».

Lo que realmente quieren los usuarios: la lista de deseos del vibe coding

Cientos de comentarios de usuarios revelaron patrones claros sobre lo que necesitan los desarrolladores:

1. Mejores herramientas para entender el código 

Los usuarios quieren que la IA explique el código generado, no que solo lo genere. El principio de un desarrollador: «Oblígate a entender el código generado antes de aceptarlo. Si no puedes explicar qué hace y por qué, no lo integres». Las herramientas que exigen comprender el código antes de aceptarlo evitarían integrarlo a ciegas.

2. Entornos aislados que realmente funcionen

Simon Willison destacó el enfoque de Claude Artifacts: «El código solo puede ejecutarse en un iframe bloqueado, cargar únicamente bibliotecas aprobadas y no puede hacer solicitudes de red a otros sitios». Los usuarios necesitan con urgencia espacios seguros donde los errores de vibe coding no puedan destruir sistemas de producción ni exponer datos reales.

3. Una función real para congelar el código

Después del desastre en que Replit borró una base de datos, Amjad Masad prometió: «Escuchamos alto y claro la preocupación por “congelar el código”: estamos trabajando activamente en un modo de planificación y chat únicamente para que puedas definir estrategias sin poner en riesgo tu base de código». Los usuarios quieren garantías de que la IA no modificará el código durante los periodos de revisión.

4. Separación entre desarrollo y producción desde el inicio

Replit se comprometió a implementar «la separación automática entre las bases de datos de desarrollo y producción para evitar que esto vuelva a pasar. También estamos trabajando en entornos de staging». A los desarrolladores con experiencia les sorprendió que esto no viniera activado desde el primer día, pero los usuarios quieren que forme parte de todas las plataformas de vibe coding.

5. Análisis de seguridad al generar código

Varios usuarios contaron que necesitaban «reglas de Cursor para cubrir las prácticas recomendadas de seguridad» y que le pedían a «Claude que redactara una lista de verificación para agregar a Cursor como contexto y ayudar a que las aplicaciones creadas con vibe coding fueran simples y seguras». El flujo de trabajo de un desarrollador: «La otra cosa fundamental que aprendí es pedirle al agente que haga una revisión de seguridad de cualquier funcionalidad nueva que agregues». Los usuarios quieren que las verificaciones de seguridad sean automáticas y obligatorias, no opcionales.

6. Limitaciones honestas y expectativas realistas

La descripción del curso de Andrew Ng captó lo que necesitan los usuarios: «“Vibe coding” se refiere a una práctica cada vez más común en la que podrías apenas mirar el código generado y centrarte, en cambio, en la arquitectura y las funcionalidades de tu aplicación. Sin embargo, contrariamente a lo que muchos creen, programar bien de esta manera no consiste simplemente en escribir instrucciones, aceptar todas las recomendaciones y esperar que todo salga bien. Requiere estructurar el trabajo, perfeccionar las instrucciones y seguir un proceso sistemático».

7. Plataformas integrales, listas para usar

En el blog de MenuGen, Karpathy escribió: «Algunas plataformas de desarrollo de aplicaciones podrían incluir todo lo necesario. Algo que parezca lo opuesto al Marketplace de Vercel. Una solución integral, concreta y preconfigurada con todo lo básico que todos necesitan: dominio, alojamiento, autenticación, pagos, base de datos y funciones del servidor». Los usuarios no quieren integrar 15 servicios; quieren un entorno coherente.

8. Pilas tecnológicas más sencillas

Karpathy también dijo: «Para mi próxima aplicación, estoy considerando usar HTML/CSS/JS básico y un backend de Python (algo como FastAPI + Fly.io), algo mucho más sencillo que el multiverso sin servidor del “desarrollo web moderno”». La complejidad de las pilas modernas amplifica los problemas de alucinaciones de la IA.

9. Memoria persistente entre sesiones

Un desarrollador frustrado: «El agente no aprende sobre la marcha, a menos que le pidas explícitamente que agregue información a sus reglas o recuerdos. Cada vez que restableces el contexto o inicias una sesión nueva, trabajas con alguien que acaba de empezar». Los usuarios quieren agentes que recuerden las convenciones del proyecto y los errores del pasado.

10. Reversión y restauración con un clic

Después de los desastres, Replit destacó: «Por suerte, tenemos copias de seguridad. Puedes restaurar el estado completo de tu proyecto con un solo clic si el agente comete un error». Los usuarios quieren control de versiones como el de Git y la posibilidad de deshacer al instante las acciones de la IA.

11. Controles de costos transparentes

Después de recibir facturas sorpresa de más de 600 dólares, los usuarios quieren límites de costo definidos de antemano, paneles de uso y alertas antes de operaciones costosas. El cambio de las suscripciones de tarifa fija a precios basados en el uso de recursos tomó por sorpresa a muchos usuarios.

Cómo responden las herramientas de IA a los comentarios de los usuarios

A mediados de 2025, varias plataformas comenzaron a implementar lo que pedían los usuarios, aunque el nivel de adopción varió:

La respuesta de Replit a los desastres con bases de datos incluyó la separación automática entre desarrollo y producción, entornos de staging, la restauración del estado del proyecto con un clic, la búsqueda obligatoria en la documentación de información específica de Replit y el modo de planificación solo por chat prometido. La rápida respuesta de su CEO, Amjad Masad, ayudó a contener los daños, pero los usuarios señalaron que estas funciones deberían haber estado disponibles desde el primer día.

La aparición de TheAuditor y otros analizadores sin conexión reflejó la demanda de seguridad que respete la privacidad. TheAuditor dividía los hallazgos en segmentos de 65 KB que se ajustaban a los límites de contexto de Claude y GPT-4, lo que permitía corregir problemas con IA sin subir código a la nube. Su creador informó que los proyectos pasaban «de 185 problemas críticos a cero en 3 o 4 iteraciones».

Cómo responde Snyk a estos comentarios

La integración del Model Context Protocol de Snyk abordó las preocupaciones de seguridad al permitir el análisis de vulnerabilidades en tiempo real mientras la IA genera código. Snyk creó servidores MCP para Cursor, GitHub Copilot, Windsurf y otros asistentes, para que los desarrolladores puedan analizar el código antes de aceptarlo. DeepCode AI alcanzó una precisión del 80 % en las correcciones automatizadas y se ejecuta en instalaciones propias para evitar enviar código a terceros. Una investigación reveló una cifra preocupante: el 48 % de todo el código generado por IA actualmente es inseguro (estudio de la Universidad de Georgetown) y GitHub Copilot puede «amplificar las vulnerabilidades existentes al aprender patrones de código inseguro en tu base de código».

Las reglas de seguridad recomendadas por Snyk para Cursor se convirtieron en una plantilla que los usuarios compartieron ampliamente: «Ejecuta siempre la herramienta de análisis de Snyk Code para el nuevo código generado de primera parte. Ejecuta siempre la herramienta de análisis SCA de Snyk para las dependencias nuevas o actualizadas. Si encuentras problemas de seguridad, intenta corregirlos usando el contexto de los resultados de Snyk. Vuelve a analizar el código después de corregirlos para confirmar que se resolvieron». Su analizador encontró de manera sistemática entre 50 y más de 200 vulnerabilidades por proyecto generado con IA, con patrones como inyección SQL mediante f-strings, secretos codificados directamente (JWT_SECRET = "secret" aparecía por todas partes), falta de autenticación y limitación de frecuencia defectuosa.

La integración de Cursor con Snyk mediante MCP y otras herramientas de seguridad reconocieron que los flujos de trabajo de «Aceptar todo» a ciegas eran peligrosos. El directorio de herramientas MCP seleccionadas ofrecía a los usuarios opciones de seguridad verificadas, aunque su implementación seguía siendo opcional y no obligatoria.

Cómo hablan hoy los usuarios del vibe coding

Para el cuarto trimestre de 2025, el fenómeno del vibe coding ya se había dividido en casos de uso claros. Lo que funciona: proyectos desechables para el fin de semana, prototipos rápidos, herramientas personales que no manejan datos confidenciales, aprender lenguajes nuevos y experimentar en situaciones de bajo riesgo. Lo que falla de forma catastrófica: sistemas de producción, aplicaciones que manejan datos de usuarios, software crítico para la seguridad, sistemas financieros o médicos y cualquier cosa que requiera mantenimiento a largo plazo.

El usuario de Twitter @stevekrouse (Val Town) expresó el consenso: «El código escrito con vibe coding es código heredado. Karpathy acuñó el término vibe coding para referirse a una forma de programación asistida por IA en la que “te olvidas de que el código existe”. Ya tenemos una expresión para el código que nadie entiende: código heredado. Nadie quiere código heredado, y con razón... Cuando haces vibe coding, acumulas deuda técnica a la velocidad a la que el LLM genera código. Por eso el vibe coding es perfecto para los prototipos y los proyectos desechables: ¡solo es código heredado si tienes que mantenerlo!».

La distinción de Simon Willison se volvió canónica: «Si un LLM escribió cada línea de tu código, pero revisaste, probaste y entendiste todo, eso no es programar por intuición; es usar un LLM como asistente de escritura». La diferencia entre recibir ayuda responsable de la IA y programar por intuición está en la comprensión y la responsabilidad.

El tuit del usuario @IroncladDev reflejó la desilusión de quienes fundan empresas sin conocimientos técnicos: «“Programar por intuición” es como una ilusión, un espejismo para quienes no tienen conocimientos técnicos. Te llena de orgullo y de sensación de logro. Pero cuando aparecen problemas difíciles, de esos que se les paga a los desarrolladores sénior para resolver, los agentes de IA empiezan a fallar. Bienvenido al mundo real». La confesión del usuario mencionado: «Voy a cerrar mi app. Cursor sigue rompiendo otras partes del código. Tenían razón, no debí haber implementado código sin proteger en producción».

La paradoja de la productividad persistió. Un comentarista de Hacker News lo resumió así: «Entonces, en mi opinión, no aumenta la productividad. “Generar más deuda técnica más rápido” es el peor resultado posible de una herramienta de “productividad”». Otra persona agregó: «Recuerda que la mayoría de las salidas exitosas ocurren más de 5 años después de fundar una empresa. Que una IA escupa un prototipo en una semana en vez de hacerlo tú en 4 quizá te consiga financiamiento inicial un poco más rápido, pero si retrasa el desarrollo del producto más de 3 semanas durante los próximos 4 o 5 años, no vale la pena».

Lo que realmente quieren los usuarios: consistencia, no apostar a la suerte

La idea fundamental que se repite en cientos de historias de usuarios: quieren que la IA acelere la ingeniería, no que la reemplace. Una frase que circuló en Reddit y Hacker News resumió la frustración: «Programar por intuición no es ingeniería, es esperar que todo salga bien».

Los usuarios no quieren abandonar los asistentes de programación con IA: la encuesta de Stack Overflow de 2025 mostró que el 80 % de los equipos confía en las herramientas de programación con IA. Pero esa misma encuesta reveló que al 59 % le preocupan las nuevas vulnerabilidades y que el 56,4 % se encuentra con problemas de seguridad con frecuencia en el código generado por IA. La brecha entre la confianza y la preocupación define el momento actual.

Lo que quieren los usuarios es complejo: una IA que genere código que puedan entender; análisis de seguridad antes de aceptar el código, no después de implementarlo; estructuras de costos que no generen facturas inesperadas de $8,000; modelos cuyo comportamiento se mantenga consistente con cada actualización; plataformas completas, con valores seguros predeterminados; y herramientas que los conviertan en mejores ingenieros, en lugar de operadores de prompts que gestionan bases de código incomprensibles.

La resaca de programar por intuición les dejó una lección fundamental a los desarrolladores: la velocidad sin comprensión no es productividad; solo genera deuda técnica más rápido. Los usuarios adoptaron la IA por lo que prometía, pero descubrieron que necesitan límites de protección, no solo más velocidad. El futuro de la asistencia de programación con IA no consistirá en «olvidarse de que el código existe», sino en entender el código generado más rápido y garantizar la seguridad desde el inicio, en lugar de agregarla después de los desastres.

¿Quieres garantizar la seguridad de tu código generado por IA? Descarga Secure by Design: A Playbook for AI-Assisted Coding para conocer medidas concretas y prácticas, y los límites de protección necesarios para integrar la IA de forma segura en tu flujo de trabajo.