Nadie sabe cómo funciona todo el sistema

• Los sistemas tecnológicos modernos han evolucionado hasta volverse tan complejos que una sola persona no puede comprender el conjunto completo
• A medida que aumentan el desarrollo de software y el uso de IA, también crecen los casos en que los desarrolladores construyen sistemas sin entender sus mecanismos internos
• Simon Wardley advierte sobre el riesgo de crear sistemas sin comprensión, Adam Jacob señala que la IA está cambiando la forma de desarrollar, y Bruce Perens sostiene que la complejidad ya superó el límite
• Louis Bucciarelli muestra, mediante el caso del sistema telefónico, que la tecnología está entrelazada en múltiples capas y que nadie puede alcanzar una comprensión completa
• El artículo enfatiza que la IA profundiza esta complejidad, pero que en realidad los humanos llevan mucho tiempo relacionándose con la tecnología desde una comprensión parcial

---

Complejidad tecnológica y los límites de la comprensión

• Tras el declive de Twitter, en LinkedIn se ha dado una discusión activa sobre la comprensión tecnológica y la complejidad
  • Se presentan como temas conectados las publicaciones de Simon Wardley, Adam Jacob y Bruce Perens
• Wardley advierte sobre el riesgo de construir sistemas sin conocer los principios fundamentales
  • La expresión “Magic” se usa de forma crítica para referirse a frameworks que ocultan el funcionamiento interno, y se menciona a Ruby on Rails como caso representativo
• Jacob señala que la IA está transformando de forma fundamental la manera de desarrollar software
  • La IA mejora la eficiencia, pero también tiende a hacer que los desarrolladores trabajen sin comprender la infraestructura subyacente
• Perens afirma que la situación que preocupaba a Wardley ya se hizo realidad
  • Debido a la complejidad de las CPU y los sistemas operativos modernos, muchos desarrolladores entienden mal cómo funcionan realmente

El caso del ‘teléfono’ de Louis Bucciarelli

• Bucciarelli analiza en su libro de 1994 Designing Engineers los límites de la alfabetización tecnológica
  • La mayoría de las personas no puede explicar cómo funciona un teléfono a nivel físico
  • Se entrelazan elementos de múltiples capas como el enrutamiento, el procesamiento de señales, la transmisión satelital, la operación empresarial y la estructura regulatoria de la red de comunicaciones
• Llega a la conclusión de que “nadie sabe por completo cómo funciona su teléfono”
  • Esto simboliza que los sistemas tecnológicos complejos están más allá de la comprensión total humana

Entrevistas técnicas y los ‘límites del conocimiento’

• El autor recuerda una conversación con Brendan Gregg durante su etapa en Netflix
  • Gregg decía que en las entrevistas evaluaba los límites del conocimiento del candidato y su reacción ante ellos
  • Realizaba las entrevistas partiendo del hecho de que “nadie comprende por completo todo el sistema”
• Este enfoque muestra que reconocer lo que uno no sabe es tan importante como la capacidad técnica

La naturaleza de la complejidad y el impacto de la IA

• Las posturas de Wardley, Jacob, Perens y Bucciarelli revelan, desde distintos niveles, la inevitabilidad de la complejidad
  • Wardley: el riesgo de construir sin entender
  • Jacob: la eficiencia y el distanciamiento que trae la IA
  • Perens: la realidad de una complejidad ya existente
  • Bucciarelli: la imposibilidad de comprender el sistema completo
• El artículo reconoce que la IA profundizará este problema, pero también recuerda la larga realidad humana de tratar con la tecnología desde una comprensión parcial

Resumen del debate de los lectores

• En los comentarios, muchos expresan preocupación por que la IA debilita el aprendizaje y la comprensión
  • Algunos señalan que “cuando los LLM escriben el código en lugar de nosotros, se rompe la cadena de comprensión”
  • Wardley explica que “antes la comprensión se mantenía dentro de una cadena jerárquica, pero los LLM eliminan esa cadena”
• Otros lectores responden que “es apresurado afirmar que los beneficios de la IA son mayores que sus riesgos”
• En general, la pérdida de comprensión técnica en la era de la IA y la ruptura del aprendizaje emergen como los puntos centrales del debate

[GN⁺]

Comentarios en Hacker News

• Lo preocupante en la programación actual es que está aumentando el "desarrollo de capa intermedia": no se conoce ni la capa de arriba (el propósito del producto) ni la de abajo (cómo se implementa).
  Antes quizá no se entendía el negocio, pero sí el significado del código; ahora parece que ni siquiera hace falta saber cómo funciona el código.
  Cuando uso Claude, siento que poco a poco se deteriora mi capacidad de entender el contexto. En una cultura de desarrollo donde basta con que los tests pasen y el botón responda, siento que ya no queda nada que aprender ni a lo que yo pueda aportar.

  • Se enfatiza la "ownership", pero cuando uno intenta asumir de verdad la iniciativa, se topa con restricciones de acceso y falta de información.
    Sobre todo en las grandes empresas falta transparencia. Hubo veces en que me quedé hasta tarde para cumplir una fecha límite y luego resultó que el calendario se había movido sin que yo lo supiera.
    Si me van a tratar como una simple herramienta, entonces cumpliré solo ese papel. Pero si de verdad quieren ownership, necesito un lugar en la mesa donde se toman las decisiones.
  • Yo, en cambio, siento que gracias a Claude mi concentración ha mejorado.
    Antes perdía tiempo en tareas repetitivas de configuración, pero ahora puedo enfocarme solo en la funcionalidad principal. Gracias a eso, logro mantener mejor en mi cabeza la estructura completa.
  • Este fenómeno se parece a la automatización agrícola. Hoy en día basta con sentarse en un tractor y la máquina hace todo. Al final, la persona no es más que peso para el sensor del asiento.
  • Me gustaría que Claude apoyara más la edición interactiva de código centrada en cambios pequeños que el desarrollo completamente automático.
    Por ejemplo, seleccionar unas líneas en el IDE y decir por voz: "cambia esta parte así", y que se aplique de inmediato.
    Si la velocidad fuera lo bastante buena, el control con mouse + voz también sería excelente como herramienta de accesibilidad.
  • En realidad, este problema existe desde hace tiempo. El ejemplo típico es el infierno de dependencias.
    Incluso creo que los LLM podrían reducir parte de esa complejidad. Me gustan las abstracciones razonables, pero no me gusta no conocer en absoluto lo que hay dentro.

• Este texto trata sobre el fenómeno de usar abstracciones (abstraction) sin conocer lo que ocurre por dentro.
  Pero ese es un proceso natural de evolución. Alguien diseñó esas abstracciones y las hizo utilizables para la capa superior.
  La lógica de "como no sé de drivers de Wi‑Fi, entonces tampoco necesito entender mi código" no se sostiene.

  • El problema es que ahora existe el riesgo de que la mayoría de la gente pierda la capacidad de crear nuevas abstracciones.
    Antes se desarrollaba la capacidad de pensar lidiando directamente con la "complejidad necesaria"; ahora muchas veces uno solo hace de tubería.
  • El código generado por LLM es demasiado verboso, así que revisarlo toma más tiempo.
    La solución sería envolver la abstracción con un DSL (lenguaje específico de dominio) en lugar de usar un lenguaje general. Si es un SaaS, me parece mejor un enfoque DSL-first que API-first.
  • En realidad, la cultura de Clean Code y OOP ya había causado pérdidas de rendimiento por exceso de abstracción.
    No creo que la IA sea necesariamente peor que eso. Lo importante es entender las abstracciones en las que uno se apoya.

• El árbol de dependencias es en realidad lo que causa los problemas más serios.
  Basta mirar proyectos de Node.js: tienen cientos de paquetes dependientes. En la mayoría de los casos no pasa nada por no conocer el interior, pero se vuelve peligroso cuando las interfaces se rompen con frecuencia.
  Muchas veces los equipos ni siquiera siguen el EOL (fin de soporte) o las vulnerabilidades. La realidad es que a veces ni saben responder: "¿esto sigue teniendo mantenimiento?"

  • Lo ideal sería monitorear estos problemas con herramientas de SBOM/SCA.
    Pero incluso antes de la IA ya había muchos proyectos atrapados en el infierno de dependencias por conflictos de versiones.

• No hace falta saberlo todo, pero sí creo que la ignorancia que hace perder los fundamentos es peligrosa.
  Si lo comparamos con cocinar: no hace falta cultivar trigo, pero es un problema no saber ni freír un huevo.
  Si las empresas prepararan y estandarizaran toda la comida por nosotros, la pregunta sería si eso es progreso o retroceso.

  • La mayoría de la gente no necesita saber cazar ni cultivar, porque la cadena de suministro es suficientemente distribuida y redundante.
    Si algún día los robots reemplazan por completo la producción de alimentos, entonces dejará de importar no saber cocinar.
  • La línea de referencia entre lo aceptable y lo peligroso es distinta para cada persona.
  • También existe la objeción de: "¿por qué sería peligroso no saber freír un huevo?"
    Después de todo, tampoco hace falta conocer ciencia de materiales para evitar la dependencia, ¿no?

• Las capas inferiores, como las instrucciones del CPU y la caché, llevan décadas de validación y documentación rigurosas.
  En cambio, el código generado por LLM no es igual de confiable y quizá necesite refactorización mañana mismo.

• Puede que yo no conozca el funcionamiento detallado de las capas inferiores, pero sí entiendo cómo funciona mi código.
  No conocer la capa de abajo y no conocer el área de la que soy responsable son cosas completamente distintas.

  • Antes, incluso en sistemas complejos, había alguien que conocía cada parte.
    Ahora el verdadero peligro es que aparezcan fragmentos de código que nadie entiende.

• No estoy de acuerdo con la idea de que la IA empeore necesariamente la situación.
  Al contrario, como los LLM han aprendido casi todo el conocimiento disponible, pueden explicar de manera estructurada preguntas como "¿cómo funciona un teléfono?"
  Los humanos tienen la limitación de no saber siquiera qué es lo que no saben, mientras que un LLM puede abarcar casi todo conocimiento expresado en lenguaje.
  Claro, son débiles para razonar o generar código, pero su capacidad de integrar conocimiento es superior a la humana.

  • Pero un LLM no "sabe"; solo genera algo verosímil.
    No puede reemplazar documentación real. Aun así, es muy útil para decirte, como lo haría una persona, "qué deberías buscar".

• Un buen diseño hace que el sistema funcione aunque no se conozca el todo.
  El problema no es que el sistema lo haya hecho la IA, sino que todavía no entendemos bien sus modos de falla y límites.
  Al final, lo clave es la capacidad de diseño organizacional para coordinar a humanos e IA y construir el sistema que hace falta.

• No conozco por completo el interior de una computadora, pero resuelvo problemas con automatización práctica mediante scripts.
  No necesito estudiar ensamblador x86 para administrar infraestructura con Python.
  Pero sí creo que los desarrolladores con experiencia tienen la responsabilidad de compartir ese conocimiento. Yo también quisiera asumir ese papel algún día.

  • Si uno solo defiende el "pragmatismo", al final eso lleva a una especialización excesiva.
    No hay que perder la curiosidad y hay que conversar activamente con desarrolladores más experimentados.
  • Cuando uno intenta enseñar fundamentos, muchas veces la respuesta es: "eso no hace falta".
    Pero frustra ver que, por más que uno insista en la importancia de la comprensión básica, lo ignoran.
  • Como referencia, hay buenos recursos de aprendizaje como cpu.land.

• Sí puedo responder preguntas como "¿qué pasa realmente cuando introduces una URL?"
  Trabajé como técnico de reactores submarinos en la Marina de EE. UU., donde aprendí desde teoría electrónica hasta troubleshooting de sistemas.
  Después me pasé a TI y mantuve la misma actitud de ir hasta el fondo mediante documentación y experimentación.
  Gracias a ese hábito, al resolver problemas me ayuda mucho conectar conocimientos dispersos.
  También vale la pena revisar la página de Wikipedia sobre VMEbus.

  • Yo reaccioné de forma parecida. La mayoría de esos ejemplos podría explicarlos al instante en un pizarrón.
    Eso sí, probablemente soy una excepción, porque no tolero no entender algo.
  • La profundidad de la comprensión varía. Un desarrollador web puede conocer la pila de red, pero el mundo analógico de las señales inalámbricas ya es otra dimensión.