# Del "vibe coding" a la Cascada de Asimov: cómo nace la deuda técnica de conocimiento  ## Introducción: Cuando el código entra en la cascada El término **Cascada de Asimov** apareció por primera vez en un episodio de _Rick & Morty_, donde Rick crea copias de sí mismo que, a su vez, generan nuevas copias, hasta desencadenar un caos de clones imposibles de distinguir del original. Hace poco retomé esa idea para aplicarla al mundo de la inteligencia artificial: ¿qué ocurre cuando una IA empieza a alimentarse de contenido generado por otras IAs? Lo interesante es que el patrón de una Cascada de Asimov empieza a aparecer en otros ámbitos de nuestro presente tecnológico. Uno de ellos en en la forma en la que se programa. Con el auge de herramientas que generan código automáticamente ha surgido el fenómeno del **“vibe coding”**, un estilo de desarrollo que privilegia la velocidad sobre la comprensión. En esta investigación vamos a conectar ambos conceptos y analizar cómo esta nueva forma de programar puede convertirse en una cascada autorreplicante, incubando una deuda técnica —y de conocimiento— que amenaza con pasarnos factura. ## La Cascada de Asimov: feedback infinito y degradación Antes del vive coding, **¿qué es exactamente una Cascada de Asimov?** En el contexto de la IA generativa, el término describe la espiral en la que un sistema entrenado con datos generados por otra IA comienza a perder fidelidad respecto a la realidad original [1](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=artificial%20entrenada%20con%20contenidos%20generados,). En una cascada típica: - Un **primer modelo (IA-1)** aprende de datos humanos originales y produce contenido de buena calidad. - Un **segundo modelo (IA-2)** se entrena parcialmente con ese contenido sintético de IA-1. Aparecen ya pequeñas desviaciones o errores acumulados. - **Tercera generación y siguientes**: nuevos modelos aprenden de datos cada vez más “reciclados” por otras IAs. Los sesgos, imprecisiones o falsas verdades se **amplifican**, igual que un rumor que se deforma más en cada repetición [2](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=entrena%20con%20contenido%20humano%20de,La%20IA). El resultado es lo que los expertos en IA llaman el **model collapse**, un deterioro notable: el conocimiento y la información generada se vuelve menos precisa, menos original y menos confiable [3](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=que%20esto%20ocurre%2C%20,efectos%20secundarios%20derivados%20del%20uso). Esta degradación del conocimiento de la IA (no olvidemos que la IA genera mucha de la información que consumen las personas) conlleva **riesgos importantes**: desinformación multiplicada, pérdida de confianza del público, contenidos artificialmente homogéneos y una preocupante **“erosión del conocimiento humano auténtico”**[4](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=termina%20repitiendo%20o%20incluso%20inventando,cada%20vez%20m%C3%A1s%20de%20conocimientos). Dicho de otro modo, la Cascada de Asimov advierte que, si no se gestionan cuidadosamente nuestros bucles de retroalimentación entre máquinas, podríamos terminar viviendo en una burbuja de información cada vez más desconectada de la realidad. Ahora bien, traslademos la metáfora al desarrollo de software. Tradicionalmente, la programación ha sido un esfuerzo humano donde cada desarrollador aporta razonamiento, criterio y _contexto_ al código que escribe. ¿Qué pasa cuando ese circuito se cierra y la mayor parte del código nuevo proviene de sugerencias de máquinas alimentadas por toneladas de código previo (incluyendo código generado por máquinas)? Empiezan a vislumbrarse patrones preocupantes: **soluciones calcadas una y otra vez**, posibles fallos sutiles replicándose de proyecto en proyecto, y lo más alarmante, **programadores que integran código sin comprenderlo del todo**. Estamos ante la posibilidad de una _cascada autorreplicante_ en ingeniería de software, donde las IAs entrenadas en código acaban generando más código que, a su vez, educa a otras IAs. La temida Cascada de Asimov. ## Vibe coding: programación a ciegas (pero con IA) El término **“vibe coding”**, acuñado en 2023 por el investigador de IA Andrej Karpathy, describe una forma de programar **dejándose llevar por las “vibraciones” o impresiones** que transmite el código generado por una IA, más que por un entendimiento detallado de este [5](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=iteratively%20prompting%20the%20AI%20until,paste%20in%20a%20prompt%2C%20and) [6](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20a%20term%20coined,code%20based%20on%20your%20intent). En la práctica, significa que el desarrollador describe lo que quiere en lenguaje natural (por ejemplo: _“haz una función que ordene esta lista de objetos por fecha”_), el asistente de IA –GitHub Copilot, ChatGPT, Claude, etc.– genera el bloque de código correspondiente, y el humano lo acepta con mínimos retoques si a primera vista “tiene buena pinta” o parece funcionar. Es un workflow de **prompt-and-check** que algunos, con sorna, llaman _“prompt and pray”_ (prompt y a rezar), ya que confías en que la solución sugerida sea correcta sin dedicar mucho tiempo a verificarla exhaustivamente. **¿Por qué está ganando popularidad este enfoque?** Principalmente porque **acelera enormemente el desarrollo**. En vez de tomarse horas escribiendo código manualmente, o investigando en Stack Overflow, hoy un programador puede obtener en segundos una función entera escrita por la IA. La promesa es tentadora: eliminar tareas repetitivas, prototipar ideas en tiempo récord y hasta programar sin saber demasiado del lenguaje, apoyándose en las “muletas” inteligentes. De hecho, el _vibe coding_ **ha democratizado la programación** hasta cierto punto: personas con poca experiencia están montando aplicaciones funcionales simplemente describiendo lo que quieren lograr y dejando que la IA escriba el código [7](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Unlike%20traditional%20coding%2C%20which%20relies,ideas%20quickly%20into%20live%20features) [8](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=AI%20researcher%2C%20coined%20the%20term,paste%20in%20a%20prompt%2C%20and). Según un informe reciente, _aproximadamente el 25% de las startups de Y Combinator ya se construyen principalmente con código generado por IAs_, dado que permite iterar productos mínimos viables con una rapidez inédita [9](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20driven%20by%20AI,skills%20for%20complex%2C%20critical%20projects). Incluso en empresas establecidas se nota la tendencia: Google reporta que **una cuarta parte de su código nuevo ya es producido con asistencia de IA** [10](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=When%20we%20examine%20the%20numbers%2C,600%2C000%20pull%20requests%20per%20month), y se estima que en 2025 cerca de **la mitad de los desarrolladores utilizan asistentes de IA** de forma habitual en su trabajo diario [10](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=When%20we%20examine%20the%20numbers%2C,600%2C000%20pull%20requests%20per%20month). El desarrollo de software está cambiando tan rápido que muchos equipos _“aún intentan ponerse al día”_ con esta nueva realidad [11](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=The%20way%20we%20write%20code,just%20a%20few%20years%20ago). El auge del _vibe coding_ también explica su rápida popularidad fuera del ámbito estrictamente técnico: es un formato ideal para la narrativa de influencers y creadores de contenido, porque ofrece demostraciones inmediatas y espectaculares —un par de frases en lenguaje natural convertidas en aplicaciones funcionales— que se prestan a titulares del estilo “esto lo cambia todo”, aunque lo que realmente muestran es la capacidad de la IA para acelerar la producción de código, sin entrar a valorar los costes ocultos de calidad y sostenibilidad que esa misma velocidad puede generar. Ahora bien, **“moverse rápido y romper cosas”** (aquel viejo lema startup) llevado al extremo con IAs puede tener un lado B ominoso. El _vibe coding_ **privilegia la velocidad sobre la estructura**: se salta a la implementación sin un diseño previo sólido, se confía en que la IA haga lo correcto y a menudo se omiten pasos tradicionales de control de calidad. Esta cultura de _“codificar por intuición”_ tiende a **depriorizar las buenas prácticas** de ingeniería: documentación, pruebas rigurosas, revisiones por pares, etc. Es fácil caer en la tentación de _“si funciona, siguiente tarea”_, sin mirar bajo el capó. Como señala irónicamente un análisis, toda la narrativa del vibecoding gira en torno a producir _más_ código, _más rápido_, **pero casi nadie está hablando de la calidad de ese código** [12](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=What%20we%20can%20see%20is,or%20overall%20Technical%20Debt%20increase). Y ahí es donde empiezan los problemas. ## Promesas vs. realidad: del código fácil al código frágil ![[Vibe-coding-2.webp|400]] No cabe duda de que la IA puede **aumentar la productividad inicial** de un equipo de desarrollo. Estudios muestran mejoras de hasta un 55% en la velocidad para escribir código gracias a estas herramientas [13](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=More%20AI,incentivize%20technical%20debt%20inflation%20instead). Sin embargo, detrás de esa aparente eficiencia se está incubando una **nueva forma de deuda técnica**. Varias métricas recientes pintan un cuadro claro: ### Explosión de código duplicado Un análisis de 211 millones de líneas de código reveló un aumento del **17% en “copypasteo” de código** desde la adopción masiva de asistentes de IA, con fragmentos duplicados _ocho veces más comunes_ en los repositorios modernos [14](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=A%20recent%20analysis%20of%20211,times%20more%20common%20in%20commits). Por primera vez, las líneas añadidas mediante copia/pega (muchas generadas por IA) superan a las líneas refactorizadas para ser reutilizables. En vez de abstraer lógica común, la IA tiende a repetir patrones una y otra vez, violando DRY (_Don’t Repeat Yourself_) y creando bases de código más hinchadas y redundantes [15](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=For%20the%20first%20time%2C%20copy,increased%20difficulty%20in%20maintaining%20it). En la práctica, esto significa que se acumulan funciones casi idénticas por todas partes en lugar de usar una sola bien diseñada. ### Aumento del _churn_ o retrabajo El mismo estudio detectó un spike del 26% en el code churn_** (código que se agrega y luego se modifica o borra a los pocos días) [16](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=bloated%20codebase%20and%20increased%20difficulty,in%20maintaining%20it). Aproximadamente **5,7% de todo el código escrito es revisado o eliminado dentro de las dos semanas siguientes** a su creación [17](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=We%20also%20saw%20another%20red,two%20weeks%20of%20being%20written). En otras palabras, más de una de cada veinte líneas “nuevas” acaba a la basura inmediatamente, señal de que mucho código generado por IA no estaba bien pensado ni construido para durar [18](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=Image%3A%20GitClear%20Reveals%20AI%27s%20Negative,Impact%20On%20Code%20Quality). Esto concuerda con la intuición: si se acepta código de la IA sin mucha revisión, es común descubrir más tarde que tenía fallos sutiles o simplemente no encajaba bien, forzando a reescribirlo. Lejos de ahorrar tiempo, este retrabajo constante desperdicia horas y complica el mantenimiento futuro [19](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=removed%E2%80%94has%20doubled%20between%202021%20and,to%20be%20fixed%20or%20rewritten) [20](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=This%20constant%20rework%20wastes%20time,debt%20isn%E2%80%99t%20kept%20in%20check). Como dice un ingeniero, “el código se ha vuelto barato de crear, pero **caro de mantener**, porque cada línea adicional es más liability que asset” – al final, _menos_ código bien hecho habría sido preferible. ### Buenas prácticas rotas Las IAs actuales carecen de comprensión contextual profunda de tu proyecto. Generan código estadísticamente plausible, pero no conocen la arquitectura interna, ni las convenciones particulares de tu base de código [21](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=AI%20doesn%E2%80%99t%20understand%20your%20system%E2%80%94it,problem%20in%20slightly%20different%20ways). Esto deriva en pequeñas inconsistencias (nombres de variables, estilos) que rompen la uniformidad y dificultan la colaboración[22](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Broken%20Standards). Además, prefieren aportar soluciones genéricas en lugar de reutilizar módulos existentes; por ejemplo, han observado que muchas veces, ante un prompt, el asistente **reinventa funciones desde cero en lugar de llamar a una utilidad ya disponible**, solo porque en su entrenamiento no “sabe” de tu librería interna [23](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Wheel). El resultado es _reinventar la rueda_ una y otra vez: código innecesariamente verboso, menos legible y con más dependencias accidentales [24](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder). El equipo de GitClear halló que la adopción de Copilot correlacionó con hasta 8× más bloques de código duplicados filtrándose en los _pull requests_ [25](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=A%20GitClear%20study%20found%20that,of%20bugs%20and%20maintenance%20headaches). Sin fuertes guías de estilo y revisión, la arquitectura de software comienza a degradarse: **fragmentación, funciones de más, consistencia rota** – en definitiva, una erosión de la claridad de diseño a largo plazo. ### Ilusión de estabilidad Que un código _“funcione”_ en casos comunes no significa que sea correcto o robusto. Las IAs tienden a producir soluciones que pasan las pruebas básicas, pero a menudo carecen de manejo de errores, validaciones de entrada, tests exhaustivos o consideraciones de rendimiento [26](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=language%20model%20,when%20generating%20the%20information) [27](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=AI%20rarely%20optimizes%20for%20performance,It%20might%20suggest). Un desarrollador humano normalmente incorpora esos elementos tras pensar en escenarios extremos, pero el _vibe coder_ puede pasarlos por alto si el programa parece dar el output esperado. Esta “felicidad ingenua” con el resultado inmediato es peligrosa. De hecho, se ha visto que muchas funciones generadas por IA ocultan “bombas de tiempo”: lógica frágil que falla con inputs no previstos, consultas SQL ineficientes que escalan mal, o APIs usadas incorrectamente que luego rompen contratos. Un experto lo resume así: _el código de la IA parece plausible—hasta que descubres algún fallo sutil de lógica_ [28](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,But%20is%20Fragile%20as%20Hell). El problema es que estos errores suelen manifestarse tarde, en producción, “pagando la deuda con intereses” porque hay que salir a apagar fuegos de emergencia. ### Vulnerabilidades de seguridad inadvertidas Quizá el aspecto más serio. Las IAs no tienen sentido común en materia de seguridad a menos que se les guíe explícitamente. Pueden generar código que “pasa las pruebas” funcionales pero es intrínsecamente inseguro. Por ejemplo, en un experimento de Databricks Red Team, se usó _vibe coding_ con la IA Claude para crear un juego multijugador; la IA decidió serializar objetos con pickle de Python, resultando en una **puerta abierta a ejecución remota de código (RCE)** en red [29](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20Vulnerability) [30](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20network%20layer%20of%20the,other%20instance%20of%20the%20game). El programador distraído podría no darse cuenta de que, aunque el juego “andaba”, acababa de introducir un vector crítico de ataque. De forma similar, otro experimento con ChatGPT generó un parser en C++ para un formato binario que funcionaba bien… hasta que se revisó y se encontró graves fallos de manejo de memoria (lecturas fuera de rango, confusiones de tipos) que harían trivial explotar esa pieza de código [31](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=However%2C%20upon%20closer%20examination%2C%20we,memory%20corruption%20vulnerabilities%20if%20exploited). Estos ejemplos reales ilustran que el _vibe coding_ tiende a **pasar por alto medidas de seguridad básicas**, porque la IA no las prioriza a menos que se le pida. Un informe de red team lo dice claramente: _la naturaleza del vibe coding hace fácil pasar por alto riesgos potenciales cuando el código generado “simplemente funciona”_ [32](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20code%20below%2C%20taken%20directly,any%20validation%20or%20security%20checks). Y no es solo teoría: en la vida real ya hemos tenido sustos que recuerdan a esto. Se sospecha, por ejemplo, que cierta aplicación orientada a la seguridad de mujeres (_Tea App_) sufrió una brecha devastadora por fallos de primer curso –una base de datos abierta, controles de acceso rotos–, errores que un desarrollo más disciplinado habría detectado [33](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=The%20recent%20security%20incident%20at,reputational%2C%20legal%2C%20and%20financial%20ruin). No hay prueba pública de que esa app fuese hecha con vibe coding, pero encaja con el patrón de “codificar rápido sin pensar en seguridad” que estamos describiendo. En general, los lapsos de seguridad triviales están proliferando en proyectos donde la velocidad ha mandado sobre la cautela. Como se ha señalado con ironía: _el vibe coding es genial para prototipar, hasta que tu startup sufre una filtración de datos por no validar un input_. Ahí la “vibra” se acaba. ![[Vibe-coding.webp]] _Gráfico: Tendencias en la proporción de operaciones de código y_ _churn_ _por año de autoría, según un estudio de GitClear (2025). Nótese la línea marrón de_ _código reescrito/eliminado (churn), subiendo a ~5.7% en 2024, y la línea verde de_ _código eliminado, desplomándose a medida que en 2023–2025 se prefiere añadir código nuevo (often duplicado) en lugar de refactorizar o borrar. La creciente fracción de líneas_ _copiadas/pegadas_ _(rojo) sugiere más duplicación, mientras que la proporción de código verdaderamente_ _nuevo_ _(azul) se mantiene estable. El resultado: bases de código más voluminosas pero menos mantenibles_ [14](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=A%20recent%20analysis%20of%20211,times%20more%20common%20in%20commits) [17](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=We%20also%20saw%20another%20red,two%20weeks%20of%20being%20written)_._ La realidad detrás de la “magia” del vibe coding es que muchas veces el camino corto introducido por la IA nos cobra peaje más adelante. Al igual que una tarjeta de crédito técnica: hoy “compramos” velocidad y ahorro de esfuerzo, pero la _deuda_ acumulada se manifiesta después en forma de bugs esquivos, parches por doquier, refactorizaciones costosas y noches en vela depurando. Y lo más preocupante es que no se trata solo de la típica deuda técnica (código desordenado o soluciones provisionales), sino de algo más insidioso: **una deuda de conocimiento**. ## La deuda técnica de conocimiento: construir sin comprender Una de las consecuencias más sutiles –y peligrosas– del enfoque _vibe_ es la **pérdida de comprensión profunda del sistema** por parte de los desarrolladores. Cuando aceptamos trozos de código generados automáticamente sin internalizarlos, estamos esencialmente tercerizando el “entendimiento”. Se acumulan así secciones enteras de la base de código de las que ningún miembro del equipo posee un modelo mental claro. Este déficit conceptual es lo que podemos llamar **deuda técnica de conocimiento**: análogo a la deuda técnica clásica, pero en vez de deber líneas de código por refactorizar, _debemos entendimiento_. El concepto no es del todo nuevo. Ya en 1985, el pionero de la informática Peter Naur advertía que _“el acto esencial de programar es desarrollar una teoría o modelo mental del problema y su solución”_, y que esa teoría vive en la mente de los programadores, no solo en el código o la documentación [34](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=In%201985%2C%20computer%20scientist%20Peter,guidance%20for%20today%E2%80%99s%20programming%20world) [35](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=The%20most%20striking%20aspect%20of,of%20a%20program%2C%E2%80%9D%20which%20%E2%80%9Chappens). Naur incluso describió _“la muerte de un programa”_ cuando el equipo que sostenía ese conocimiento se disolvía: el código podría seguir existiendo, pero sin nadie que lo comprendiera, se volvía rígido e inmanejable [36](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=code%20itself,difficult%20despite%20the%20code%20itself) [37](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=program%20experiences%20what%20Naur%20termed,of%20shared%20mental%20models%20remains). Modificar un sistema así era tan difícil que Naur sugería que a veces era mejor _tirarlo y empezar de nuevo_ antes que lidiar con un programa cuyo “por qué” se había perdido en el tiempo. Con el _vibe coding_, corremos el riesgo de **provocar deliberadamente esa desconexión** teoría-código en nombre de la productividad inmediata. Si los programadores se habituan a integrar código generado sin formarse una idea cabal de su funcionamiento, línea a línea, acaban construyendo un sistema cuyo esqueleto _no dominan_. Puede que todo compile, pase ciertas pruebas y funcione en producción… pero si nadie sabe explicar realmente cómo interactúan sus componentes o por qué se eligieron ciertas soluciones, el proyecto queda a la deriva. Cuando (inevitablemente) surjan bugs o haya que añadir una funcionalidad compleja, los mismos autores del código tendrán que actuar como **arqueólogos de su propia creación**, deduciendo a posteriori lo que hubiera sido obvio de haber escrito el código con comprensión plena [38](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Over%20time%2C%20the%20codebase%20risks,our%20development%20practices%20rather%20than) [39](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=creating%20what%20might%20be%20called,rather%20than%20through%20team%20turnover). Se vive ya en algunas empresas: equipos que “programaron” funcionalidades con prisa apoyándose en la IA, y luego frente a una incidencia se sienten examinando _código ajeno_, porque en efecto es código que nadie del equipo escribió realmente. Las señales de esta deuda de conocimiento creciente están apareciendo. Líderes técnicos reportan que sus revisiones de código consumen más tiempo dando contexto y explicaciones que corrigiendo lógica [40](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=the%20better). Un estudio citado indicaba que los equipos dedican el **60% del tiempo de code review simplemente a entender el código generado por IA**, y solo un 20% a revisar la corrección en sí [41](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=This%20explosion%20in%20AI,code%20we%20have%2C%20the%20better). Es el mundo al revés: optimizamos la generación, pero comprometimos la comprensión. En términos de la Cascada de Asimov, podríamos decir que cada generación de código “sintético” que incorporamos, sin asimilarla del todo, nos aleja un paso del conocimiento original del sistema. La _cascada autorreplicante_ aquí toma la forma de **ingenieros cada vez más dependientes de sugerencias de IA** y menos capaces de razonar desde primeros principios cuando el código se comporta mal. Vale la pena enfatizar que esta deuda cognitiva **no se ve en el repositorio**, pero pesa tanto o más que la deuda técnica convencional. Un repositorio puede estar limpio de _code smells_, puede incluso pasar análisis estáticos y cumplir estándares, pero si el equipo no _entiende_ a fondo por qué el código es como es, están andando sobre arenas movedizas. Como señaló un comentarista, _“los equipos terminan manteniendo código que en realidad nadie escribió”_, lo cual crea una brecha de conocimiento que **puede crecer exponencialmente** con el tiempo [42](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder). Al cabo de unos meses de agregar parches sugeridos por IA, podrías tener un sistema funcional pero tan opaco para sus propios desarrolladores que cualquier cambio es una odisea. Este es el peligro más sutil del _vibe coding_: más allá de los bugs puntuales o los _workarounds_ feos, es la **pérdida gradual de la maestría humana sobre nuestras herramientas digitales**. En última instancia, el software es una extensión del pensamiento humano; si renunciamos a entender lo que construimos, estamos cediendo terreno a una especie de _autoridad alienígena_ (la IA y su entrenamiento estadístico). Se genera así una **dependencia peligrosa**: como desarrolladores, confiamos en sistemas que _ya no podemos explicar del todo_, y cuando algo va mal, dependemos _aún más_ de la propia IA para arreglarlo, perpetuando el ciclo. Es una trampa perfecta: la solución rápida de ayer siembra la confusión de mañana, que nos hará pedir otra solución rápida pasado mañana. ## Tradicional vs _vibe_ vs cascada: tabla comparativa Para visualizar estos contrastes, comparemos brevemente tres enfoques: la programación **tradicional** (humana y deliberada), el **vibe coding** asistido por IA, y un escenario hipotético de **cascada autorreplicante**, donde varias generaciones de IA entrenadas sobre código generado cierran el ciclo sin intervención humana sustancial: | **Aspecto** | **Desarrollo Tradicional** (Humano) | **“Vibe coding”** (IA asistida, uso acrítico) | **Cascada autorreplicante** (IA entrenada en outputs de IA) | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Modo de creación** | El programador escribe el código _a mano_, basándose en análisis y diseño previos. Cada línea pasa por su entendimiento. | El desarrollador describe en lenguaje natural la tarea; la IA genera el código. Se integra casi tal cual, con mínima edición si “se ve bien”. | Sistemas de IA generan código de forma autónoma alimentándose de código previamente generado por otras IAs. La intervención humana es poca o nula en la generación. | | **Velocidad inicial** | Relativamente menor. Se invierte tiempo en pensar la solución, diseñar, codificar y probar manualmente. | Muy alta. Prototipos y funciones creados en segundos/minutos. Ideal para “moverse rápido” en prototipos y hacks. | Muy alta al principio, ya que las IAs pueden producir grandes cantidades de código rápidamente y en paralelo. | | **Calidad y mantenimiento** | Si se siguen buenas prácticas, el código suele ser coherente, bien estructurado y mantenible. Los errores se detectan en revisión humana. | Calidad variable. Puede haber código funcional pero con inconsistencias, duplicación y falta de robustez [26](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=language%20model%20,when%20generating%20the%20information)[15](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=For%20the%20first%20time%2C%20copy,increased%20difficulty%20in%20maintaining%20it). Requiere _rework_ frecuente (churn) y refactorizaciones posteriores. | Calidad decreciente con el tiempo. Al entrenarse en código ya degradado o homogéneo, cada generación pierde precisión y diversidad [4](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=entrena%20con%20contenido%20humano%20de,La%20IA). Se amplifican patrones defectuosos o subóptimos sin que nadie los corrija del todo. | | **Entendimiento humano** | Total. El equipo desarrolla un **modelo mental completo** del sistema. Saben _qué hace_ y _por qué lo hace_ así cada componente. | Parcial. Los devs entienden el enunciado del problema, pero **no siempre comprenden a fondo el código generado**. Se corre el riesgo de integrar piezas “caja negra” [43](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=However%2C%20this%20revolution%20introduces%20a,correctly%20but%20lacks%20a%20corresponding) [44](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=The%20hidden%20costs%20of%20outsourcing,understanding). | Nulo o mínimo. Tras varias iteraciones, **los humanos no comprenden el código** (ni quizás las IAs sucesoras comprenden el propósito original). El sistema opera como caja negra autorreplicada. | | **Deuda técnica** | La típica: viene de atajos conscientes (p.ej. “lo arreglamos después”). Es manejable si se documenta y refactoriza más adelante. | **Deuda técnica acelerada**. Se crean muchos más _issues_ de mantenibilidad en menos tiempo [45](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Debt%E2%80%94But%20It%20Can%20Supercharge%20It). Además aparece la **deuda de conocimiento**: código en producción sin un dueño intelectual claro [42](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder). | **Deuda técnica y de conocimiento combinada y multiplicada**. El sistema puede volverse inmantenible y peligrosamente opaco. Errores o vulnerabilidades iniciales se **propagan y amplifican** en cascada [3](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=termina%20repitiendo%20o%20incluso%20inventando,cada%20vez%20m%C3%A1s%20de%20conocimientos). | | **Riesgos principales** | Bugs y fallos típicos por error humano, limitados por revisiones. Si el equipo se disgrega sin transferir conocimiento, el proyecto sufre (pero esto se puede mitigar con documentación). | **Bugs ocultos y brechas de seguridad** por confiar ciegamente en la IA [29](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20Vulnerability) [32](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20code%20below%2C%20taken%20directly,any%20validation%20or%20security%20checks). **Falsa sensación de seguridad**: “si compila y corre, está bien”. Dificultad para depurar problemas complejos al no entender del todo el código. | **Colapso de calidad** (model collapse). Posible **estancamiento tecnológico**: todos los sistemas nuevos replican las mismas soluciones mediocres. **Pérdida de confianza** en el software: ni desarrolladores ni usuarios pueden fiarse totalmente de él. | _Tabla: Comparativa entre la programación tradicional, el “vibe coding” moderno y un escenario extremo de cascada autorreplicante en desarrollo de software._ ## Conclusión: Hacia un equilibrio consciente Lejos de ser un simple debate académico, lo que está en juego aquí es el **futuro de la ingeniería de software** en la era de la inteligencia artificial. El _vibe coding_ nos ofrece un poder seductor: producir más, más rápido, con menos esfuerzo aparente. Pero como hemos visto, ese atajo conlleva trampas ocultas. Si nos dejamos llevar por la **“vibra” de la máquina** y relegamos al ser humano al papel de operador pasivo, corremos el riesgo de caer en nuestra propia versión de la Cascada de Asimov: una espiral descendente donde cada nuevo programa entiende menos de sí mismo, y donde la creatividad y el criterio humano se diluyen entre repeticiones estadísticamente probables. El tono crítico de este análisis no busca demonizar la IA en programación –sería hipócrita, cuando estas mismas herramientas bien utilizadas están acelerando avances increíbles–, sino hacer un llamamiento a la **responsabilidad técnica**. La solución no es desechar Copilot o ChatGPT, sino cambiar la forma en que los usamos. Un enfoque emergente es el de la "_velocidad estructurada_" (por oposición al caos del vibe coding) [46](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=This%20report%20is%20not%20a,By%20adopting%20this%20framework%2C%20we): es decir, aprovechar la IA para ir rápido, pero con un arnés de buenas prácticas. Esto implica, por ejemplo, integrar desde el día uno revisiones de seguridad y calidad en el ciclo, no dar _merge_ a código generado sin que pase por ojos humanos críticos, y educar a los desarrolladores para que traten las sugerencias de la IA como _borradores_ que requieren entendimiento y pulido [47](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Using%20AI%20while%20preserving%20mental,models) [48](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Teams%20can%20follow%20this%20approach,the%20shared%20mental%20model). La IA puede ser un copiloto útil, pero el piloto sigue siendo uno mismo – y un buen piloto conoce su nave a fondo antes de volarla a ciegas. En términos de **deuda técnica de conocimiento**, la recomendación es sencilla de enunciar pero desafiante de cumplir: **no te saltes el “por qué”**. Si una IA te brinda una solución, tómate el tiempo de preguntarte (y preguntarle) por qué ese código es correcto, qué alternativas hay, cuáles son sus límites [43](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=However%2C%20this%20revolution%20introduces%20a,correctly%20but%20lacks%20a%20corresponding) [49](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=approach%3F%20What%20alternatives%20might%20exist%3F,that%20Naur%20recognized%20as%20essential). Documenta las razones detrás de las decisiones, no solo el qué hace el programa. Fomenta que en las _code reviews_ se discutan las motivaciones y no solo el estilo. Solo así evitaremos que el **arte de programar** se convierta en una simple ouija tecnológica donde movemos el cursor y confiamos en espíritus silícicos. Al final del día, la **innovación real** en software siempre ha nacido de entender problemas profundamente y moldear soluciones creativas. Las herramientas de IA, bien encauzadas, pueden liberarnos de la mecánica tediosa para que dediquemos más tiempo a ese entendimiento de alto nivel. Pero mal usadas, pueden convertirse en una muleta que atrofie nuestras habilidades, llevándonos a un abismo de máquina en el que el código se escribe solo pero nadie sabe realmente qué está construyendo. Evitar la Cascada de Asimov en el desarrollo software significa mantener ese equilibrio delicado: velocidad, sí, pero con control; automatización, sí, pero con conciencia. Solo así podremos surfear la ola de la IA sin ahogarnos en ella, asegurando que seguimos siendo los autores –y no meros consumidores– de la tecnología que damos al mundo. **Referencias (citas):** La información y datos presentados provienen de fuentes especializadas, incluyendo estudios y análisis recientes sobre impacto de la IA en la calidad del código [14](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=A%20recent%20analysis%20of%20211,times%20more%20common%20in%20commits) [17](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=We%20also%20saw%20another%20red,two%20weeks%20of%20being%20written), informes de equipos de seguridad sobre vulnerabilidades introducidas por código generado automáticamente [29](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20Vulnerability) [32](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20code%20below%2C%20taken%20directly,any%20validation%20or%20security%20checks), reflexiones de expertos en ingeniería de software sobre la importancia de los modelos mentales compartidos [43](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=However%2C%20this%20revolution%20introduces%20a,correctly%20but%20lacks%20a%20corresponding) [38](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Over%20time%2C%20the%20codebase%20risks,our%20development%20practices%20rather%20than), así como artículos que documentan el auge del _vibe coding_ en la industria [9](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20driven%20by%20AI,skills%20for%20complex%2C%20critical%20projects) [6](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20a%20term%20coined,code%20based%20on%20your%20intent) y sus riesgos asociados [42](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder) [50](https://blog.openreplay.com/github-copilot-vs-chatgpt/#:~:text=3,where%20code%20comes%20from%2C%20the), entre otros. Todas las citas están enlazadas en el texto para consulta detallada de cada fuente. --- [1](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=artificial%20entrenada%20con%20contenidos%20generados,) [2](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=que%20esto%20ocurre%2C%20,efectos%20secundarios%20derivados%20del%20uso) [3](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=termina%20repitiendo%20o%20incluso%20inventando,cada%20vez%20m%C3%A1s%20de%20conocimientos) [4](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov#:~:text=entrena%20con%20contenido%20humano%20de,La%20IA) Cascada de Asimov - DavidHurtado.ai [https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov](https://davidhurtado.ai/Posts/2025.03/7-Cascada-de-Asimov) [5](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=iteratively%20prompting%20the%20AI%20until,paste%20in%20a%20prompt%2C%20and) [8](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=AI%20researcher%2C%20coined%20the%20term,paste%20in%20a%20prompt%2C%20and) [33](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=The%20recent%20security%20incident%20at,reputational%2C%20legal%2C%20and%20financial%20ruin) [46](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0#:~:text=This%20report%20is%20not%20a,By%20adopting%20this%20framework%2C%20we) Beyond the Vibe: A Deep Dive into the Dangers of Vibe Coding, Lessons from the Tea App Incident, and a Framework for Resilient Software Development | by Adnan Masood, PhD. | Jul, 2025 | Medium [https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0](https://medium.com/@adnanmasood/beyond-the-vibe-a-deep-dive-into-the-dangers-of-vibe-coding-lessons-from-the-tea-app-incident-cea9fd2d1fa0) [6](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20a%20term%20coined,code%20based%20on%20your%20intent) [7](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Unlike%20traditional%20coding%2C%20which%20relies,ideas%20quickly%20into%20live%20features) [9](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development#:~:text=Vibe%20coding%2C%20driven%20by%20AI,skills%20for%20complex%2C%20critical%20projects) When to Vibe and When to Code: Guidelines for Using AI Wisely in Development [https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development](https://www.nucamp.co/blog/vibe-coding-when-to-vibe-and-when-to-code-guidelines-for-using-ai-wisely-in-development) [10](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=When%20we%20examine%20the%20numbers%2C,600%2C000%20pull%20requests%20per%20month) [11](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=The%20way%20we%20write%20code,just%20a%20few%20years%20ago) [12](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=What%20we%20can%20see%20is,or%20overall%20Technical%20Debt%20increase) [14](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=A%20recent%20analysis%20of%20211,times%20more%20common%20in%20commits) [15](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=For%20the%20first%20time%2C%20copy,increased%20difficulty%20in%20maintaining%20it) [16](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=bloated%20codebase%20and%20increased%20difficulty,in%20maintaining%20it) [17](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=We%20also%20saw%20another%20red,two%20weeks%20of%20being%20written) [18](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=Image%3A%20GitClear%20Reveals%20AI%27s%20Negative,Impact%20On%20Code%20Quality) [26](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=language%20model%20,when%20generating%20the%20information) [40](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=the%20better) [41](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools#:~:text=This%20explosion%20in%20AI,code%20we%20have%2C%20the%20better) How to do code reviews with AI tools [https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools](https://newsletter.techworld-with-milan.com/p/how-to-do-code-reviews-with-ai-tools) [13](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=More%20AI,incentivize%20technical%20debt%20inflation%20instead) [19](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=removed%E2%80%94has%20doubled%20between%202021%20and,to%20be%20fixed%20or%20rewritten) [20](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=This%20constant%20rework%20wastes%20time,debt%20isn%E2%80%99t%20kept%20in%20check) [21](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=AI%20doesn%E2%80%99t%20understand%20your%20system%E2%80%94it,problem%20in%20slightly%20different%20ways) [22](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Broken%20Standards) [23](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Wheel) [24](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder) [25](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=A%20GitClear%20study%20found%20that,of%20bugs%20and%20maintenance%20headaches) [27](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=AI%20rarely%20optimizes%20for%20performance,It%20might%20suggest) [28](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,But%20is%20Fragile%20as%20Hell) [42](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=Sustainable%20code%20should%20be%20easy,and%20make%20future%20changes%20harder) [45](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/#:~:text=,Debt%E2%80%94But%20It%20Can%20Supercharge%20It) How AI-Generated Code is messing with your Technical Debt [https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/](https://kodus.io/en/ai-generated-code-is-messing-with-your-technical-debt/) [29](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20Vulnerability) [30](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20network%20layer%20of%20the,other%20instance%20of%20the%20game) [31](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=However%2C%20upon%20closer%20examination%2C%20we,memory%20corruption%20vulnerabilities%20if%20exploited) [32](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding#:~:text=The%20code%20below%2C%20taken%20directly,any%20validation%20or%20security%20checks) Passing the Security Vibe Check: The Dangers of Vibe Coding | Databricks Blog [https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding) [34](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=In%201985%2C%20computer%20scientist%20Peter,guidance%20for%20today%E2%80%99s%20programming%20world) [35](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=The%20most%20striking%20aspect%20of,of%20a%20program%2C%E2%80%9D%20which%20%E2%80%9Chappens) [36](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=code%20itself,difficult%20despite%20the%20code%20itself) [37](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=program%20experiences%20what%20Naur%20termed,of%20shared%20mental%20models%20remains) [38](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Over%20time%2C%20the%20codebase%20risks,our%20development%20practices%20rather%20than) [39](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=creating%20what%20might%20be%20called,rather%20than%20through%20team%20turnover) [43](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=However%2C%20this%20revolution%20introduces%20a,correctly%20but%20lacks%20a%20corresponding) [44](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=The%20hidden%20costs%20of%20outsourcing,understanding) [47](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Using%20AI%20while%20preserving%20mental,models) [48](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=Teams%20can%20follow%20this%20approach,the%20shared%20mental%20model) [49](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/#:~:text=approach%3F%20What%20alternatives%20might%20exist%3F,that%20Naur%20recognized%20as%20essential) Peter Naur's legacy: Mental models in the age of AI coding | Nutrient [https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/](https://www.nutrient.io/blog/peter-naur-legacy-mental-models-age-ai-coding/) [50](https://blog.openreplay.com/github-copilot-vs-chatgpt/#:~:text=3,where%20code%20comes%20from%2C%20the) GitHub Copilot vs ChatGPT [https://blog.openreplay.com/github-copilot-vs-chatgpt/](https://blog.openreplay.com/github-copilot-vs-chatgpt/)