Vibe Coding Es Real y la Programación Tradicional Está Muriendo
Hace tres años, me habría reído del término "vibe coding."
En serio. Tenía ingenieros que respetaba diciéndome que estos codebases generados por IA eran juguetes frágiles — lógica espagueti envuelta en hype. Yo era una de esas personas que abría un archivo generado por IA, detectaba la primera inconsistencia lógica y pensaba "sí, por eso los humanos todavía tienen trabajo." Lo dije en voz alta. A otros ingenieros. En sesiones de code review.
Estaba equivocado. La velocidad a la que me di cuenta de que estaba equivocado es la verdadera historia aquí.
Lo que cambió mi opinión no fue un solo avance. Fue ver algo suceder en cámara lenta, y luego de repente todo de golpe — como un edificio que ha estado agrietándose durante meses y finalmente se derrumba. El momento que lo cristalizó para mí fue cuando Anthropic lanzó Claude Code con capacidades de seguridad en la nube integradas. No como un plugin. No como un complemento. Como una característica arquitectónica central que entiende lo que estás construyendo, razona sobre la superficie de amenazas, y produce infraestructura segura automáticamente.
Ahí fue cuando entendí: esto no se trata de que la IA te ayude a escribir código más rápido. Se trata de que la IA se convierta en la cosa que hace todo el trabajo.
Para 2030, los ingenieros que todavía insistan en escribir cada línea a mano — como prueba de su habilidad — van a verse como personas que se negaron a usar el email porque las cartas escritas a mano eran más personales. Las personas que pasaron los últimos años insistiendo en voz alta que el vibe coding era falso? Van a dejar de decirlo silenciosamente.
Esto es lo que he visto realmente — y dónde creo que termina esto.
El Escepticismo Era Razonable. Hasta Que Dejó de Serlo.
La crítica alrededor del vibe coding fue justa durante mucho tiempo. Le pedías a una IA que te construyera una web app, generaba algo que se veía bien pero se desmoronaba bajo carga real. Los casos límite no se manejaban. La seguridad se trataba como algo secundario. La ventana de contexto era demasiado pequeña para que la IA entendiera todo tu codebase — lo que significaba que "arreglaba" una cosa y silenciosamente rompía otras tres.
Si hubieras intentado construir un sistema de grado producción solo con IA en 2022 o principios de 2023, habrías pasado más tiempo limpiando después de la IA de lo que la IA te ahorraba. La promesa estaba claramente ahí. La ejecución no.
La mayoría de los desarrolladores — incluido yo — probamos las herramientas durante esa ventana, nos topamos con esos puntos de fricción, y archivamos todo el concepto bajo "experimento interesante, no listo para producción." Esa fue la decisión correcta en ese momento.
Pero algo cambió en 2024-2025 que la mayoría de la gente aún no ha procesado completamente.
Las ventanas de contexto se hicieron masivas. Claude 3.5 se extendió a un territorio donde podías mantener estructuras de proyecto enteras en una sola conversación. Claude 3.7 fue más allá — no solo más tokens, sino razonamiento cualitativamente mejor sobre entradas más grandes. Cuando un modelo puede mantener todo tu backend, tu frontend, tus archivos de configuración y tu documentación en contexto simultáneamente, ya no está solo "escribiendo código". Está razonando sobre todo tu sistema como algo conectado.
He visto esto directamente en mis propios proyectos. Describir una funcionalidad a Claude Code, referenciando un módulo específico, pidiendo una implementación que encaje con los patrones existentes — lo que regresa no es una función independiente que tengo que conectar manualmente. Es una implementación completa que entiende el codebase existente. Eso no funcionaba de manera confiable hace dieciocho meses. Ahora generalmente sí.
El problema del código muerto, que era otra objeción real, también ha cambiado de forma. "La IA genera código inflado — basura legacy que se acumula con el tiempo hasta que tienes un desastre inmantenible." Eso era cierto cuando la gente usaba la IA como un autocompletado glorificado. Es menos cierto cuando ejecutas Claude Code en modo agéntico con acceso al sistema de archivos, donde el modelo puede escanear tu código existente, identificar funciones no utilizadas, y limpiar mientras avanza. El código muerto se convierte en algo que el agente nota. El código legacy se convierte en algo que puede refactorizar cuando lo pides, no algo que empeora al construir encima.
Pero el cambio más grande — el que eliminó la última objeción seria — está en la seguridad. Y eso merece su propia sección.
La Seguridad Era el Último Argumento Creíble en Contra. Acaba de Perder Su Fuerza.
Así era la conversación sobre vibe coding durante años:
"Claro, la IA puede escribir código funcional. Pero ¿quién es responsable de la seguridad?"
Ese era un punto justo. El código generado por IA tenía vulnerabilidades reales. SQL injection, validación de entrada incorrecta, secretos expuestos en archivos de configuración, implementaciones de autenticación débiles — estos no eran riesgos hipotéticos de tradicionalistas preocupados. Aparecían en codebases reales. Los vi. Otros ingenieros los vieron. La preocupación era legítima.
Lo que el reciente trabajo de seguridad de Claude Code de Anthropic aborda es exactamente esa brecha. Cuando la IA está razonando sobre tu infraestructura en la nube, tus políticas IAM, tu configuración de red — y haciéndolo con modelado de amenazas de seguridad integrado en el proceso — no solo estás obteniendo código más rápido. Estás obteniendo código que ha sido verificado contra una superficie de ataque que no tuviste que definir tú mismo.
Eso es lo que la gente se está perdiendo cuando ve la reacción del mercado a estos lanzamientos. Cuando las acciones de seguridad en la nube se mueven por anuncios de IA, no es ruido irracional. Son inversores reconociendo que la estructura de costos del software seguro está a punto de cambiar. Herramientas que anteriormente requerían personal dedicado de ingeniería de seguridad están siendo absorbidas en el flujo de trabajo de desarrollo.
Esto no es perfecto. Las herramientas de seguridad con IA capturan los patrones comunes — lo del OWASP Top 10, permisos mal configurados, vectores de inyección obvios. No reemplaza una prueba de penetración real en un sistema complejo. Pero mueve la vara de "absolutamente necesitas revisión de seguridad dedicada en cada archivo generado por IA" a "la IA maneja la primera capa, los humanos se enfocan en el modelado de amenazas genuinamente complejo." Esa es una estructura de costos completamente diferente para construir software. Y elimina la última excusa que la gente tenía para descartar todo este cambio.
Ahora la pregunta difícil: ¿qué significa esto realmente para cómo deberías estar trabajando?
Qué Es Realmente el Vibe Coding (La Mayoría lo Define Mal)
El vibe coding no es escribir "constrúyeme una app SaaS" en un chatbot de IA y esperar que salga algo bueno. Eso no es vibe coding — eso es apostar con prompts. Los resultados son tan confiables como esperarías.
El vibe coding, en su definición real, es una metodología de desarrollo donde comunicas intención, restricciones y arquitectura a una IA a alto nivel, y la IA se encarga de los detalles de implementación. Tú sigues entendiendo lo que estás construyendo. Sigues siendo dueño de las decisiones. Simplemente no eres quien escribe el código.
Piensa en cómo trabajan los ingenieros senior en equipos grandes. No escriben la mayoría del código — diseñan la arquitectura, definen los patrones, revisan el resultado y toman decisiones sobre la dirección. Entienden cada componente, pero no producen manualmente cada línea. Tratan a los ingenieros junior haciendo el trabajo línea por línea como extensiones de su pensamiento.
El vibe coding es eso — excepto que los "ingenieros junior" haciendo la implementación son agentes de IA que trabajan a un ritmo que ningún equipo humano puede igualar.
Los ingenieros que prosperarán no son los que pueden escribir el for loop más elegante. Son los que pueden diseñar sistemas bien, comunicar requisitos con precisión y evaluar la salida de la IA críticamente. Las personas que más lucharon con las herramientas de IA no eran ingenieros junior que no sabían mucho. A menudo eran los mejores escritores de sintaxis — el tipo de desarrolladores que podían producir código complejo y hábil de memoria. Irónicamente, esa habilidad se convirtió en una muleta. Peleaban con la salida de la IA, la reescribían para que coincidiera con su estilo personal, perdían el punto.
Los ingenieros que se adaptaron más rápido fueron los que ya se sentían cómodos describiendo arquitectura en términos abstractos. Si puedes decir "necesito un servicio que maneje eventos de webhook, valide la firma, actualice la base de datos y emita un evento interno para procesamiento downstream" — Claude Code puede implementar eso limpiamente. Si piensas en términos de nombres de variables y firmas de funciones, pasarás tu tiempo discutiendo con las elecciones de la IA en lugar de entregando producto.
Hay un cambio práctico en cómo trabajo que hizo la mayor diferencia, y vale la pena recorrerlo.
Cómo He Cambiado Realmente Mi Flujo de Trabajo de Desarrollo
El primer cambio que hice: antes de comenzar cualquier proyecto nuevo, escribo un system prompt detallado describiendo las convenciones del proyecto. Patrones de nombres de base de datos. Estrategia de manejo de errores. Cómo quiero que se estructuren las respuestas de la API. Qué librerías estoy usando y por qué. Reglas de organización de archivos.
Este documento se convierte en el contexto en el que la IA opera para todo el proyecto. En lugar de explicar convenciones una y otra vez — o ver a la IA elegir sus propias convenciones cada vez — le doy la arquitectura una vez. Cada sesión subsiguiente hereda ese contexto. La diferencia de calidad en la salida de la IA es dramática cuando el modelo conoce las reglas que se supone debe seguir versus cuando improvisa desde cero.
Si no has hecho esto, pruébalo en tu próximo proyecto antes de hacer cualquier otra cosa.
El segundo cambio: reorienté mi energía de evaluación. La habilidad que más importa en un flujo de trabajo de vibe coding no es escribir prompts. Es la evaluación de la salida. ¿Puedes leer código que no escribiste y entender si hace lo que debería? ¿Puedes detectar un error lógico en una función generada por IA? ¿Puedes identificar cuándo una decisión de seguridad parece razonable versus cuándo es un atajo que se manifestará como vulnerabilidad después?
Los buenos ingenieros ya tienen estas habilidades. La diferencia es que en un flujo de trabajo de vibe coding, las ejercitas constantemente — no ocasionalmente, cuando revisas un PR, sino cada vez que la IA te entrega output. Piensa en ti mismo como el tech lead de un equipo muy rápido y muy capaz que necesita code review en todo. No escribes la mayor parte del código. Pero eres dueño de cada decisión.
El tercer cambio es más difícil de discutir en círculos de desarrolladores: empecé a invertir en distribución antes de terminar el código.
Aquí está la realidad incómoda. A medida que la IA reduce la barrera para construir software, el mercado se satura más rápido que nunca. Apps que tomaban tres meses construir en 2020 toman dos semanas ahora. La escasez se desplaza de "¿puedes construir esto?" a "¿puedes poner esto frente a las personas que lo necesitan?" El conocimiento de marketing y distribución — que solía ser opcional para fundadores técnicos — se está convirtiendo en lo mínimo necesario.
Los ingenieros que conozco que están construyendo exitosamente ahora mismo no son los mejores programadores. Son los mejores encontrando mercados desatendidos, construyendo para ellos, y llegando a ellos antes de la saturación. Ese es un juego diferente al que la mayoría de nosotros nos entrenamos. También es un juego más interesante, una vez que te ajustas.
En Qué Me Equivoqué — Y En Qué Todavía Tengo Dudas
Quiero ser honesto sobre algo que confundí durante demasiado tiempo.
Mi preocupación original sobre el vibe coding no era "esto no puede producir software funcional" — claramente podía, incluso en los primeros días. Mi preocupación era "esto produce software que nadie entiende realmente, y cuando se rompa a las 3 AM vas a estar completamente perdido." Y esa preocupación sigue siendo parcialmente válida.
Si usas IA para construir un sistema que genuinamente no entiendes arquitectónicamente — si estás prompteando tu camino hacia funcionalidades sin saber qué está haciendo realmente el código — estás construyendo sobre terreno inestable. No porque el código de IA sea necesariamente malo, sino porque no puedes mantener lo que no puedes razonar. Cuando algo se rompe en producción, la comprensión es lo único que te salva.
Pero estaba confundiendo dos cosas separadas: "desarrolladores que usan IA sin entender sus sistemas" y "vibe coding como metodología." La metodología no requiere ignorancia. Requiere un tipo diferente de comprensión — arquitectónica y sistémica en lugar de sintáctica. Esa es una distinción real.
La otra cosa en la que me equivoqué: subestimé severamente lo rápido que las herramientas madurarían. En 2023, pensaba que estábamos a cinco a siete años de que la IA pudiera manejar codebases de producción reales de manera confiable. Estábamos a aproximadamente dos años. Ese es un error que te hace humilde. Cuando escucho a gente hoy diciendo "el código generado por IA nunca será verdaderamente apto para producción," escucho a mi yo de 2023 — y ahora soy escéptico en una dirección diferente.
Sobre lo que estoy genuinamente incierto es la cuestión de saturación del mercado. A medida que construir software se acerca a un costo cercano a cero, la ventaja competitiva se desplaza completamente hacia la distribución y la diferenciación. Eso es una buena noticia si eres un marketer que quiere construir apps. Es una noticia genuinamente desafiante si eres un ingeniero que pensaba que la habilidad técnica era la ventaja duradera.
La respuesta honesta es que nadie sabe exactamente cómo se resuelve esto. Pero esperar para averiguarlo mientras todos los demás lo descifran es probablemente la peor opción disponible.
Qué Cambia Cuando Realmente Te Comprometes Con Esto
Así se ven los números en mi propio trabajo desde que cambié mi flujo de trabajo:
Proyectos que solían tomarme seis a ocho semanas construir solo ahora toman dos a tres semanas. Eso no es porque esté cortando esquinas — la calidad del código es comparable y a menudo mejor, porque la IA captura cosas que habría pasado por alto cuando me movía rápido. El tiempo ahorrado viene de no gastar energía mental en código repetitivo, búsqueda de documentación de APIs, o depuración de sintaxis. Esa energía va a la arquitectura y decisiones de producto en su lugar, donde realmente se multiplica.
En cuanto a seguridad: usando las funciones de seguridad de Claude Code durante el desarrollo, he detectado problemas reales que anteriormente habrían requerido una ronda de auditoría dedicada. No todos los problemas — estaría mintiendo si afirmara que las herramientas de seguridad con IA reemplazan una prueba de penetración adecuada en un sistema complejo. Pero las vulnerabilidades de "fruta madura" que llegan a producción por presión de tiempo? Esas se están detectando más temprano en el ciclo ahora.
Una compensación honesta: el desarrollo asistido por IA eleva el piso de calidad dramáticamente (incluso el trabajo apresurado tiene estructura y manejo de errores) pero puede bajar el techo si no tienes cuidado (código verdaderamente elegante para lógica de dominio compleja todavía se beneficia del diseño dirigido por humanos). Sabe para cuál estás optimizando en cada proyecto. La mayoría de los proyectos necesitan un piso más alto, no un techo más alto.
Si has llegado hasta aquí, ya estás pensando en esto más seriamente que la mayoría de los ingenieros. Aquí hay un benchmark práctico: mide tu tiempo desde "idea" hasta "prototipo funcional" y desde "prototipo" hasta "listo para producción" en tus próximos tres proyectos usando un flujo de trabajo de vibe coding. Ambos deberían comprimirse mediblemente. Si no lo hacen, todavía estás peleando con las herramientas en lugar de usarlas — y eso usualmente es un problema de flujo de trabajo, no un problema de capacidad.
Tu primer proyecto así será más lento de lo que esperas. Estás construyendo nuevos hábitos en paralelo con construir un producto. El segundo será más rápido. Para el quinto, te preguntarás qué estabas haciendo antes.
La Única Pregunta Que Vale la Pena Reflexionar
Al principio de esto, dije que el trabajo de seguridad en la nube de Claude Code de Anthropic fue el momento en que algo hizo clic para mí. No porque fuera la primera herramienta de desarrollo con IA impresionante — no lo fue. Sino porque la seguridad era la última objeción creíble en pie.
Todas las demás preocupaciones habían sido abordadas. "El código realmente no funciona" → resuelto por ventanas de contexto y depuración agéntica. "La IA hace un desastre de tu codebase con el tiempo" → la IA también puede limpiar y refactorizar codebases. "No puedes construir sistemas de producción reales así" → sistemas de producción construidos principalmente mediante métodos asistidos por IA están ejecutándose ahora mismo, a escala, en empresas que usas diariamente.
La seguridad era la que quedaba. Y ahora ya no.
Antes de cerrar esta pestaña, nombra un bloqueador práctico legítimo que tengas actualmente para adoptar un flujo de trabajo de desarrollo más asistido por IA. No una objeción filosófica. No "pero los ingenieros de verdad escriben código." Un bloqueador real, específico, práctico. Luego dedica treinta minutos esta semana a probar si ese bloqueador todavía existe con las herramientas actuales — porque hay una posibilidad genuinamente buena de que se resolvió hace seis meses y nadie te envió el memo.
Las personas que estarán más frustradas en 2030 no son las que probaron el vibe coding y les costó trabajo. Son las que siguieron esperando hasta que no tuvieron opción.
🤝 Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- 🔗 Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
- 🎨 ColorPark (diseño y branding): colorpark.io
- 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io
