La Fábrica de Tokens: generación masiva de código, deuda técnica invisible y el caso por una ingeniería consciente

Hay un momento en que una promesa tecnológica deja de ser promesa y comienza a ser ideología. La inteligencia artificial aplicada al desarrollo de software llegó a ese umbral en algún punto entre 2023 y 2025, cuando el discurso dominante dejó de preguntar si los sistemas podían generar código funcional y comenzó a asumir que generar más código, más rápido, era inherentemente equivalente a construir mejor software.

Esta asunción merece ser examinada con rigor, porque sus consecuencias no son solo técnicas. Son epistemológicas, laborales y sociales.

La narrativa dominante tiene la textura de una promesa económica: si la IA puede escribir código a velocidad de máquina, el cuello de botella del desarrollo —el ingeniero humano limitado por su velocidad de escritura, su fatiga, su curva de aprendizaje— queda eliminado. El resultado sería abundancia: más software, más rápido, más barato, democratizado.

Lo que los datos empíricos de 2024 y 2025 muestran es una imagen radicalmente diferente. El estudio de Carnegie Mellon University sobre 807 repositorios de código abierto que adoptaron herramientas de IA generativa encontró que la IA acelera brevemente la generación de código, pero que las tendencias de calidad del código subyacente continúan deteriorándose. La velocidad aumenta. La calidad no. Y en muchos casos, empeora.

Esta disociación no es un error técnico corregible con el siguiente modelo. Es estructural.

GitClear, en su análisis de más de 153 millones de líneas de código, identificó que la duplicación de código asistido por IA está vinculada a cuatro veces más clonación de código que en períodos previos, y el "code churn" —código descartado menos de dos semanas después de haber sido escrito— se proyectaba a duplicarse en 2024.

La empresa Cortex midió diferencias en métricas de ingeniería entre Q3 2024 y Q3 2025: el cycle time subió 9%, los pull requests por autor subieron 20%, los incidentes por PR subieron 23.5%, y el change failure rate subió 30%. Más código. Más rápido. Más roto.

El indicador más revelador quizás sea de percepción: según la encuesta de Stack Overflow 2025, solo el 29% de los desarrolladores confía en los outputs de herramientas IA —bajando desde el 40% un año antes. Y el 66% reporta pasar más tiempo arreglando código "casi correcto" generado por IA del que ahorran al escribirlo.

La noción de deuda técnica —introducida por Ward Cunningham en 1992— describe el costo diferido de decisiones técnicas apresuradas. La IA generativa no inventó la deuda técnica, pero la escala y automatiza de maneras que cambian cualitativamente el problema.

Cuando un ingeniero toma un atajo, existe una memoria cognitiva de ese atajo: sabe dónde está, por qué lo tomó, qué implicaciones tiene. Cuando un sistema de IA genera código que nadie leyó con atención antes de integrar, esa memoria no existe. El código entra al repositorio como un objeto extraño cuya lógica interna es opaca incluso para quien lo introdujo.

Esta transformación tiene consecuencias para la gobernanza del software. El software que nadie entiende completamente es software del que nadie puede responsabilizarse completamente. Un ingeniero senior en GitHub lo expresó con precisión descarnada: "Si un agente IA escribe código, es mi responsabilidad limpiarlo antes de que mi nombre aparezca en git blame."

Ese principio, razonable a escala individual, se vuelve imposible de sostener a escala industrial. Cuando el 30% del nuevo código en empresas como Google y Microsoft es generado por IA —cifra reportada por ambas compañías para 2025— la pregunta de quién es responsable de ese código no tiene respuesta clara.

El término vibe coding, acuñado por Andrej Karpathy —ex-director de IA en Tesla—, describe el paradigma dominante: el desarrollador describe en lenguaje natural lo que quiere, la IA genera código, el desarrollador evalúa el resultado visualmente y ajusta según las "vibras" de lo que ve. Productivo en el corto plazo para prototipos. Peligroso sin contrato.

El problema no es que el vibe coding sea inútil. El problema es que opera sin especificación formal de lo que el código debe hacer, cómo debe comportarse en casos límite, qué propiedades debe preservar. La validación es visual y subjetiva. En contextos donde el fallo tiene consecuencias menores, esto puede ser aceptable. En contextos donde el software maneja datos médicos, financieros, o infraestructura crítica, es una apuesta irresponsable.

El Spec-Driven Development (SDD) propone el principio contrario: definir primero una especificación detallada, y usar esa especificación como contrato que la IA debe cumplir, no como descripción post-facto de lo que generó. En el SDD, el criterio de éxito existe antes de la generación, no después.

Test-Driven Development (TDD) con agentes IA recupera un principio que la industria abandona bajo presión de velocidad: escribir las pruebas antes que el código. El humano define qué cuenta como correcto; la IA intenta producir algo que lo sea.

Behavior-Driven Development (BDD) opera en un nivel de abstracción mayor: las especificaciones se escriben en lenguaje casi-natural, describiendo el comportamiento esperado desde la perspectiva del usuario o del negocio. Esto hace el contrato legible para stakeholders no técnicos.

Lo notable es estas metodologías convergen en el mismo principio estructural: el humano define el contrato antes de que la IA ejecute.

Los incentivos de quienes venden infraestructura de generación de código están alineados con el volumen de uso, no con la calidad del output. Una empresa que cobra por token generado tiene incentivos para que se generen más tokens, no para que cada token sea más valioso. Este desalineamiento de incentivos no es una acusación de mala fe — es una descripción estructural.

Sus consecuencias las pagan quienes no participan en la decisión de adoptar estas herramientas: los usuarios finales del software mediocre, los equipos que heredan código que nadie entiende completamente, las organizaciones que despliegan sistemas cuya lógica interna es opaca a quienes los operan.

Hay además un problema de accountability que la industria apenas está comenzando a reconocer. Cuando el 30% del código de una empresa es generado por IA, ¿quién es el autor? ¿Quién es responsable cuando ese código falla? Estas preguntas no tienen respuestas claras en el marco jurídico vigente en la mayoría de los países, y ese hecho es un riesgo sistémico que se está ignorando activamente.

Existe una dimensión adicional que rara vez aparece en la literatura técnica: el impacto sobre la cognición y el desarrollo profesional de los ingenieros que usan estas herramientas.

El problema más profundo es el que no mide ninguna encuesta: lo que sucede cuando un ingeniero pasa años evaluando y ajustando código que no generó, en lugar de construir el modelo mental completo de un sistema. Las habilidades que no se ejercitan se atrofian. Un modelo de desarrollo donde la IA genera y el humano aprueba puede estar produciendo, en el largo plazo, una generación de ingenieros que saben operar herramientas de IA pero que han perdido la capacidad de construir sin ellas.

Esto no es un argumento ludita. La pregunta relevante no es si usar IA, sino cómo usarla de manera que el humano que la usa se vuelva más capaz con el tiempo, no menos.

No significa ir más lento por principio. Significa que cada paso importe. Un proceso de desarrollo puede usar IA extensivamente y ser riguroso si cada etapa tiene criterios de validación explícitos, si el humano comprende lo que ha sido construido antes de avanzar, y si existe accountability clara sobre cada componente del sistema.

Los principios que emergen de las metodologías más robustas pueden articularse en términos simples: el criterio de éxito debe existir antes de la generación, no después. El humano debe comprender lo que despliega. La accountability debe ser trazable. La velocidad no puede ser el único criterio de calidad.

El Iron Triangle del desarrollo de software —rápido, bueno, barato: elige dos— no ha sido eliminado por la IA generativa. Lo que ha cambiado es que el trade-off puede estar ocurriendo de manera invisible, difiriendo los costos hacia futuros equipos y usuarios que heredarán sistemas que funcionan pero que nadie comprende completamente.

¿Es la generación masiva de código deseable para la sociedad que es impactada, y no solo para quien la produce?

La respuesta honesta es: depende de qué se construye, con qué criterios, bajo qué sistema de accountability. La democratización de la capacidad de construir software es genuinamente valiosa. La democratización de la capacidad de desplegar software sin entenderlo es una externalidad que la sociedad está comenzando a absorber sin haberla elegido conscientemente.

El argumento no es contra la IA como herramienta de desarrollo. Es contra la ideología que convierte la velocidad de generación en virtud cardinal, que automatiza la gestión de calidad esperando que la IA resuelva lo que la IA creó, y que externaliza los costos del software mediocre hacia quienes menos poder tienen para rechazarlo.

La ingeniería consciente no es una postura nostálgica. Es una postura ética: la de quien reconoce que construir software es un acto con consecuencias reales para personas reales, y que esas consecuencias no desaparecen por haber sido generadas estadísticamente.