Algo ha cambiado en el desarrollo de software.
Hoy en día hay código en producción, en empresas corrientes, del que nadie puede dar cuenta por completo de principio a fin. El ingeniero que lo fusionó no puede explicarlo todo. El equipo responsable del servicio tampoco. En algunos casos, la dirección tiene todavía menos visibilidad. El sistema sigue en pie, las pruebas pasan, las funciones se publican y los números se ven bien. Eso puede ocultar el problema real durante un tiempo.
Pregunta qué hace una sección determinada, por qué emerge cierto comportamiento o qué se rompe si se elimina una parte, y las respuestas se vuelven muy finas muy rápido.
Ese es el terreno que la gente empieza a describir como código oscuro. El término encaja. El software funciona, pero la comprensión humana es incompleta porque gran parte se produjo con asistencia de IA y pasó a producción antes de que nadie construyera un modelo mental sólido de ello.
No es sólo una molestia de ingeniería. Cambia lo que significa la propiedad.
Qué es el código oscuro
El código oscuro no es lo mismo que el código malo.
No es simplemente código antiguo, código feo o código con demasiada deuda colgando. Esas categorías son conocidas. Los equipos saben con qué están lidiando, aunque la limpieza sea dolorosa. El código oscuro es distinto porque la brecha no es principalmente de calidad. Es de comprensión.
La característica que lo define es simple: el código nunca fue entendido de verdad por un humano en ninguna etapa que importara.
Eso suele ocurrir siguiendo un patrón que ahora se siente normal. Alguien escribe un prompt. Un modelo genera la implementación. Las pruebas pasan, o al menos pasan las suficientes. La función se publica. La pieza que falta es la antigua disciplina en la que alguien tenía que entender la lógica lo bastante bien como para explicarla bajo presión, modificarla de forma segura y predecir cómo se comportaría cuando cambiaran las condiciones.
El software puede ser lo bastante fiable en el día a día. Eso no significa que esté bien comprendido.
Por qué se propaga
El crecimiento del código oscuro no es un misterio. Viene de cómo se produce hoy el software.
Una razón está incorporada al propio desarrollo asistido por IA. Cuando una persona escribe un sistema pieza a pieza, se ve forzada a atravesar la lógica. Se encuentra con los bordes incómodos, las dependencias extrañas, los pequeños casos de fallo que revelan cómo funciona realmente la cosa. Ese proceso es lento, pero construye comprensión. El código generado atajado mucho de eso. Obtienes el resultado más rápido. A menudo no obtienes la misma profundidad de familiaridad. Herramientas como Cursor, Windsurf y Claude Code aceleran todas el paso de generación — el paso que antes hacía gran parte de la enseñanza.
La otra razón es la presión. Se espera que los equipos entreguen más rápido, iteren más rápido y operen con menos holgura. La IA lo hace posible, y por eso la adopción ha avanzado tan rápido. Pero la velocidad cambia el comportamiento. Cuando una función puede producirse en minutos, el tiempo dedicado a entenderla de verdad empieza a parecer opcional. En muchas empresas se vuelve opcional en la práctica, aunque nadie lo diga directamente.
Así crece la base de código. El output es real. La capa de comprensión se adelgaza.
Por qué las soluciones obvias no lo resuelven
Muchas respuestas propuestas no dan en el blanco porque tratan el código oscuro como una carencia de herramientas.
La observabilidad ayuda. Los equipos necesitan logs, trazas, métricas, alertas. Nada de eso está en disputa. Pero poder ver lo que un sistema hace en producción no es lo mismo que entender por qué se construyó así, en qué suposiciones se apoya o qué dependencias ocultas hay bajo un comportamiento aparentemente normal. Puedes instrumentar muy bien una caja negra y seguir teniendo una caja negra.
Más automatización tampoco lo resuelve. Mejores pipelines, mejores agentes, orquestación más estructurada, capas de evaluación más estrictas — todo eso puede reducir ciertas clases de error. También puede hacer más difícil razonar sobre el sistema porque ahora hay más capas entre el humano y el output. Cuando algo va mal, no sólo miras el código. Miras prompts, llamadas a herramientas, parches generados, lógica de evaluación y cualquier flujo que haya envuelto el proceso entero. El creciente uso de servidores MCP y fontanería de agentes añade capacidad, pero también añade indirección.
Las pruebas ayudan, pero sólo hasta cierto punto. Que las pruebas pasen te dice que el código cumplió las condiciones que comprobaste. No te dice si alguien entiende de verdad lo que se ha publicado. Algunos equipos son lo bastante disciplinados para llegar lejos con evaluaciones sólidas y un proceso riguroso. La mayoría no. En muchos sitios el código llega desde varias direcciones a la vez y nadie tiene una imagen precisa del conjunto.
Ahí es donde está el riesgo.
El problema real dentro de la organización
El código oscuro no es sólo una cuestión de software. Es un problema de competencia institucional.
Una empresa puede seguir operando mientras su comprensión interna se degrada. Eso es parte de lo que lo hace peligroso. La entrega continúa. La hoja de ruta avanza. Los clientes pueden no notar nada inusual. Pero dentro de la organización, cada vez menos gente puede explicar por qué el sistema se comporta como lo hace, cuáles son sus límites de fallo o qué parte de su estado actual es intencional frente a accidental.
Eso importa cuando algo se rompe. También importa cuando aún nada está visiblemente roto.
| Función | Antes (código escrito por humanos) | Con código oscuro sin control |
|---|---|---|
| Revisión de riesgos | Los equipos pueden describir cómo se comporta el sistema bajo estrés | Los revisores aprueban sistemas que no pueden explicar |
| Cumplimiento normativo | Los controles se corresponden con una lógica comprendida | Existe el papeleo; la evidencia subyacente es delgada |
| Respuesta ante incidentes | El equipo de guardia puede reconstruir la intención rápido | Los ingenieros hacen ingeniería inversa de su propio código durante un corte |
| Confianza en proveedores / suministro | Las integraciones son deliberadas y legibles | Las dependencias se acumulan sin un dueño claro |
La revisión de riesgos se debilita cuando los equipos no pueden explicar con claridad sus propios sistemas. El cumplimiento normativo se convierte en papeleo en lugar de evidencia. La respuesta ante incidentes se vuelve más lenta porque la gente está reconstruyendo una lógica que en realidad nunca tuvo. La confianza en proveedores se vuelve más difícil de evaluar. La organización empieza a apoyarse en software que no puede interrogar adecuadamente.
No es una posición estable.
Qué sí ayuda
La respuesta no es dejar de usar IA para el desarrollo de software. Eso es irreal y no da en el blanco. Las ganancias en velocidad y output son reales. La mayoría de los equipos no va a dar marcha atrás.
La pregunta es cómo evitar que la comprensión se derrumbe mientras el desarrollo se acelera.
Exige claridad antes de generar código. Antes de pedir a un modelo que produzca algo importante, un equipo debería ser capaz de decir qué se supone que hace el sistema, qué restricciones importan, cómo se ve el éxito y qué no puede permitirse. Eso no requiere documentación hinchada. Sí requiere precisión real. Si la intención es vaga, el código puede seguir funcionando, pero el equipo tiene muy poca base para juzgar si es correcto más allá del comportamiento superficial.
Haz que el sistema sea más fácil de leer después de existir. El código debe llevar su contexto consigo. Los módulos deben tener un propósito identificable. Las dependencias deben ser visibles y defendibles. Las interfaces deben decir algo más que la forma de los datos que pasan por ellas. El comportamiento esperado, las condiciones de fallo y las suposiciones operativas no deben vivir sólo en hilos de chat o en la cabeza de alguien.
Exige una comprobación de comprensión antes de producción. No una revisión de código como ritual de cajas marcadas. Un intento real de responder a las preguntas que haría un buen ingeniero al tratar de decidir si es seguro depender de este sistema. ¿Por qué está aquí esta dependencia? ¿Qué suposiciones hay enterradas en esta implementación? ¿Qué se rompe si falla esta parte? ¿Qué se ha optimizado y qué se ha sacrificado en silencio? Si nadie puede responder a esas preguntas con suficiente limpieza, el código no está listo sólo porque pasa las pruebas.
Por qué esto importa ahora
Este problema no es especulativo. Ya está aquí y empeorará a medida que generar código sea más fácil.
Según mejoren los modelos, la tentación de aceptar el output al pie de la letra aumentará. Se pedirá a los equipos que manejen más con menos gente. El código generado seguirá acumulándose en los sistemas de producción. Parte será bueno. Parte será frágil. Gran parte quedará en ese punto medio incómodo donde funciona lo bastante bien pero se entiende mal.
Las empresas que ignoren esto pueden seguir moviéndose rápido. Simplemente se moverán con menos visibilidad de la que creen.
Las empresas que se tomen el problema en serio tendrán más posibilidades de mantener el control de sus sistemas a medida que estos sean más difíciles de ver con claridad. El mismo argumento se aplica en la capa de negocio: las firmas que sustituyen SaaS por pilas impulsadas por IA están heredando en silencio el mismo riesgo de legibilidad — sólo que ahora está en los flujos de trabajo que dirigen la empresa.
La verdadera ventaja
Durante un tiempo, la velocidad por sí sola parecía el premio.
Ya no basta. Muchos equipos pueden generar software rápido. Lo más difícil es mantener ese software legible para quienes son responsables de él. Ahí es donde estará la ventaja. No en producir más código que los demás, sino en ser capaz de explicar lo que se ha construido, cambiarlo sin miedo y defenderlo cuando las respuestas fáciles se acaben.
El código oscuro no es inevitable. Es lo que ocurre cuando el output supera a la comprensión durante el tiempo suficiente como para que la gente deje de tratar la brecha como un problema.
El riesgo no es simplemente que las máquinas estén escribiendo más código. El riesgo es que las organizaciones empiecen a aceptar sistemas que ya no conocen de verdad.