domingo, 15 de noviembre de 2026

La IA como riesgo social y ecológico

Una narrativa sintética 

La controversia en torno a la IA como riesgo social y ecológico es una disputa distributiva sobre quién soporta los costos, quién captura los beneficios y bajo qué reglas. Los datos institucionales muestran que la tendencia de crecimiento es real: la Agencia Internacional de la Energía proyecta que el consumo eléctrico global de los centros de datos se duplicará de 485 TWh en 2025 a aproximadamente 950 TWh en 2030, representando el 3% de la demanda eléctrica mundial; el consumo directo de agua para refrigeración también podría casi triplicarse de 222 mil millones de litros en 2025 a 644 mil millones de litros en 2030. Sin embargo, la narrativa dominante que simplemente atribuye esto a «la IA consume demasiada energía y agua» pasa por alto un hecho clave: la eficiencia por tarea está mejorando, el problema es que la escala de implementación se está expandiendo de manera explosiva, y la velocidad de construcción de la infraestructura energética (10-15 años) está fundamentalmente desalineada con la de los centros de datos (1-2 años).

Lo que es más importante es que los costos no se distribuyen equitativamente. El caso de Memphis es el ejemplo más claro: xAI, para alimentar su centro de datos Colossus 2, operó decenas de turbinas de gas sin los permisos correspondientes, con emisiones anuales que podrían superar las 1,700 toneladas de óxidos de nitrógeno, convirtiéndose potencialmente en la mayor fuente industrial de contaminación del aire en el área de Memphis, mientras que las comunidades negras circundantes ya enfrentan cargas desproporcionadas de enfermedades respiratorias. La NAACP presentó una demanda, y el gobierno federal intentó intervenir para desestimarla alegando «seguridad nacional», pero el tribunal finalmente permitió que el caso continuara. Esto expone la lógica central: las ganancias se privatizan (velocidad de implementación, ventaja competitiva), los costos se socializan (contaminación del aire, competencia por agua, presión sobre la red eléctrica), y las instituciones de rendición de cuentas están ausentes o deliberadamente debilitadas.

La narrativa a favor: eficiencia, escala y competencia

La narrativa a favor de «dejar que los oligopolios controlen la IA» se apoya en la lógica de la eficiencia y la competencia: la escala de inversión es enorme (la inversión global en centros de datos alcanzó los 500 mil millones de dólares en 2024), solo los gigantes tecnológicos pueden sostenerla; los gigantes tecnológicos representan aproximadamente el 40% de todos los acuerdos corporativos de compra de energía renovable, con efectos de arrastre; la energía nuclear y las pequeñas plantas modulares también son impulsadas por su demanda. Pero esta narrativa enfrenta una refutación institucional directa: el «control» de los oligopolios no equivale a «eficiencia», sino a la capacidad de externalizar costos. La velocidad de implementación de xAI en Memphis se basa en eludir los permisos, no en la innovación tecnológica. La IEA también advierte que si la inversión en infraestructura no sigue el ritmo, el aumento de la demanda eléctrica se traducirá directamente en facturas más altas para los residentes.

La narrativa en contra: realismo, despojo y rendición de cuentas

La perspectiva realista de Mearsheimer añade otra capa: la IA es una variable en la competencia entre grandes potencias, y la regulación unilateral se percibe como una desventaja estratégica, lo que reduce aún más el espacio para la rendición de cuentas institucional

Mearsheimer no ha discutido sistemáticamente la IA, pero su marco teórico realista ofrece una interpretación clara: la IA es una variable en la competencia de poder entre estados, no un problema de bienestar global. La lógica del realismo ofensivo sostiene que los estados, en un sistema internacional anárquico, buscan maximizar su poder, y la ventaja tecnológica es una herramienta central para lograr este objetivo. Desde esta perspectiva, la actitud de Estados Unidos hacia el desarrollo de la IA no se verá restringida por consideraciones de "sostenibilidad ambiental" o "equidad intergeneracional", sino que se determinará por el ritmo de la competencia tecnológica con China.

El marco de Klein señala que «la velocidad en sí misma es un instrumento de despojo», y que la carrera contra el tiempo se utiliza para eludir la evaluación ambiental y la participación pública. La conclusión de estas tres perspectivas converge: el problema no es la IA, sino la IA sin rendición de cuentas institucional. La verdadera pregunta no es «¿debemos permitir que los oligopolios controlen la IA?», sino «¿bajo qué reglas, a qué nivel de gobierno, con qué mecanismos vinculantes de compensación comunitaria, se permite operar a cualquier actor?». Sin estas reglas, los beneficios de la IA se quedarán en los balances corporativos, mientras que los costos recaerán sobre Boxtown en Memphis y los acuíferos de Querétaro.

El centro de datos de Musk en Memphis

Este es el ejemplo más adecuado para la "economía política institucional" porque expone la estructura completa de costos con total claridad.El centro de datos Colossus de xAI en Memphis, para poder operar rápidamente, instaló docenas de turbinas de gas natural para generar electricidad en el sitio, sin obtener permisos federales de aire limpio. La NAACP (Asociación Nacional para el Avance de las Personas de Color) presentó una demanda, alegando que xAI operaba turbinas de gas en Mississippi sin permiso, violando la Ley de Aire Limpio. La comunidad negra de Boxtown, adyacente al centro de datos, ha estado luchando durante dos años contra las turbinas, con residentes reportando un aumento en asma y casos de cáncer.

El acuerdo de agua es aún más revelador. xAI prometió construir una instalación de agua reciclada, pero los funcionarios locales nunca obtuvieron un acuerdo vinculante, y la construcción se detuvo cuando estaba a medio terminar. Sarah Houston, directora ejecutiva de Protect Our Aquifer, señaló que completar la instalación requeriría otros 100 millones de dólares, menos de lo que Anthropic paga a xAI en tres días por el alquiler de capacidad de cómputo. El CEO de Memphis Light, Gas and Water, dijo al concejo municipal que se enteró del estancamiento del proyecto "al mismo tiempo que todos los demás"

Un miembro del concejo municipal de Memphis lo expresó claramente: "xAI tuvo la oportunidad de desarrollar estas instalaciones de una manera que no use agua y devuelva el agua más limpia de lo que la tomó, y no eligió hacerlo, porque están en una carrera contra el tiempo."

Nota metodológica: esta síntesis integra datos de la Agencia Internacional de Energía, el caso judicial NAACP v. xAI, y los marcos analíticos de John Mearsheimer (realismo ofensivo) y Naomi Klein (capitalismo de desastre), sin pretender agotar las posturas existentes ni sustituir el juicio del lector.

sábado, 14 de noviembre de 2026

Los incidentes del 12 y 13 de noviembre de 2026

La coincidencia temporal de dos fallos sistémicos de gran escala en Estados Unidos —la caída global de Microsoft 365 y la parada nacional de vuelos ordenada por la FAA— constituye un escenario que, aunque explicable por causas técnicas independientes, exige un examen riguroso de las hipótesis planteadas. Los informes oficiales y las auditorías técnicas disponibles permiten descartar atribuciones maliciosas y revelan vulnerabilidades estructurales que merecen atención.

La caída de Microsoft 365

El incidente que afectó a Outlook, Teams, Exchange Online, SharePoint y Copilot en más de 70 países se originó, según la investigación de Microsoft, en un fallo de los mecanismos automatizados de verificación de estado de los servidores (health checks). Varios servidores dejaron de responder a estas comprobaciones, lo que provocó que la infraestructura restante absorbiera su carga y saturara los procesos de autenticación y conectividad. La empresa fue explícita al afirmar que no encontró evidencia de actividad maliciosa, y las agencias de ciberseguridad internacionales no reportaron telemetría compatible con un ataque de denegación de servicio distribuido ni con una intrusión estatal.

La hipótesis de un hackeo por parte de Israel, Rusia, China o Irán carece de sustento en los datos disponibles. La hipótesis de una sobrecarga o "ataque" de sistemas de inteligencia artificial también fue descartada: el fallo se localizó en componentes básicos de gestión de infraestructura, no en comportamientos anómalos de modelos de IA ni en flujos de tráfico generados por agentes autónomos. Desde una perspectiva de ingeniería de sistemas, el incidente es consistente con un error de configuración latente que se manifestó tras un cambio de red, un patrón conocido en infraestructuras de nube a gran escala que han experimentado fallos similares en el pasado reciente.

La parada nacional de vuelos

La orden de la FAA de suspender todos los despegues en territorio estadounidense respondió a una interrupción en los sistemas de telecomunicaciones que conectan los 22 centros regionales de control de tráfico aéreo. El secretario de Seguridad Nacional, Markwayne Mullin, declaró explícitamente que "no se trata de un nuevo 11 de septiembre" y que la causa era una "interrupción masiva de telecomunicaciones", mientras que el FBI confirmó que no había indicios de ciberataque ni de delito informático. La FAA y Microsoft negaron cualquier vínculo entre ambos incidentes.

El análisis técnico de la FAA apunta a limitaciones operativas y al desgaste de infraestructura heredada. Los centros de control utilizan líneas terrestres convencionales para interconectarse, y la modernización del sistema —que aún depende en algunos casos de disquetes y tecnologías de las décadas de 1940 a 1960— ha sido objeto de advertencias durante años. La coincidencia con la caída de Microsoft es, por tanto, cronológica pero no causal. La única línea de investigación que menciona la inteligencia artificial se refiere a la implementación gradual de un sistema basado en IA para la gestión del tráfico aéreo, pero se trata de una indagación sobre posibles interacciones con el sistema legado, no de una atribución de causalidad.

Nvidia: una transición corporativa 

La renuncia de Jensen Huang como CEO de Nvidia, anunciada el 11 de noviembre y efectiva de inmediato, se produjo en un contexto de investigación interna por parte del consejo de administración sobre posibles vínculos personales del ejecutivo con una empresaria supuestamente relacionada con inteligencia extranjera. Colette Kress asumió como CEO interina mientras se busca un sucesor. Los reportes financieros y de mercado indican que la transición respondió a dinámicas de gobernanza corporativa, y no existe evidencia técnica ni documental que conecte la estructura de Nvidia, sus desarrollos en hardware de IA o la trayectoria de sus directivos con las interrupciones en la nube de Microsoft o en el sistema aéreo estadounidense. La coincidencia temporal es un hecho, pero la atribución de una conexión causal no está respaldada por ninguna fuente verificable.

Alertas militares y escenario con Irán

Las fuentes oficiales no reportan alertas globales en bases militares del Reino Unido ni de otros países durante el 12 y 13 de noviembre que puedan vincularse con los fallos informáticos civiles. Las rutinas de seguridad en instalaciones de defensa responden a protocolos ordinarios ante tensiones regionales en Europa del Este y Medio Oriente, pero no se ha validado un estado de alerta unificado derivado de los incidentes tecnológicos. Respecto a Irán, las declaraciones de la administración estadounidense indican un cambio de enfoque en los canales de negociación, pero las especulaciones sobre un ataque nuclear inminente carecen de sustento en comunicados oficiales de los ministerios de defensa. La ausencia de evidencia en el corpus consultado no equivale a inexistencia de los hechos, pero impide cualquier afirmación categórica en uno u otro sentido.

Hipótesis planteadas

Desde una perspectiva técnica, la hipótesis de un hackeo o chantaje coordinado por parte de Israel o de naciones hostiles como Rusia, China o Irán no encuentra respaldo en la telemetría disponible ni en las declaraciones de las agencias de ciberseguridad. La hipótesis de una falla técnica es la única que cuenta con evidencia empírica: un error de configuración en los health checks de Microsoft y una interrupción de telecomunicaciones en la FAA, cada uno con causas raíz distintas y sin nexo demostrado entre sí. La hipótesis de una sobrecarga o "ataque" de la IA también carece de sustento, aunque la mención de la FAA a un sistema de IA en fase de implementación introduce un elemento que merece seguimiento en los informes posteriores que Microsoft ha prometido publicar.

La convergencia de estos eventos en un lapso de 48 horas generó un ambiente propicio para la especulación, pero el análisis riguroso exige distinguir entre correlación temporal y causalidad. La lección técnica que emerge es la fragilidad de infraestructuras críticas que operan con capas de redundancia insuficientes y tecnologías legadas, un problema que trasciende cualquier atribución geopolítica y que constituye, en sí mismo, un riesgo sistémico de primer orden.

martes, 27 de mayo de 2025

Las buenas maneras de las llamadas recursivas

The Power of 10 Rules (El poder de las 10 reglas) es una guía para código seguro creada en 2006 por Gerard J. Holzmann del Laboratorio de Software Fiable de la NASA/JPL.

Las reglas prohíben ciertas prácticas de codificación en C que dificultan la revisión o el análisis estático del código. Estas reglas son un complemento a las directrices MISRA C y se han incorporado en el mayor conjunto de estándares de codificación de JPL.

Las diez reglas

  1. Restrinja todo el código a construcciones de flujo de control muy simples. No utilice sentencias GOTO, construcciones set jmp o long jmp, ni recursividad directa o indirecta.
  2. Todos los bucles deben tener un límite superior fijo. Debe ser trivialmente posible para una herramienta de comprobación demostrar estáticamente que no se puede superar un límite superior preestablecido en el número de iteraciones de un bucle. Si el límite del bucle no puede demostrarse estáticamente, se considera que se ha infringido la norma.
  3. No utilice la asignación dinámica de memoria después de la inicialización.
  4. Ninguna función debe ser más larga de lo que se puede imprimir en una sola hoja de papel.
  5. Use un mínimo de dos aserciones en tiempo de ejecución por función. Las aserciones siempre deben estar libres de efectos secundarios y deben definirse como pruebas booleanas.
  6. El scope de los datos debe ser el más pequeño posible.
  7. Cada función de llamada debe comprobar los valores de retorno de función no vacíos, y la validez de los parámetros debe comprobarse dentro de cada función.
  8. El uso del preprocesador debe limitarse a los headers y definiciones de macros simples.
  9. El uso de punteros debe estar restringido a un nivel de des referencia. No se permiten punteros a funciones.
  10. Todo el código debe ser compilado, desde el primer día de desarrollo, con todas las advertencias del compilador habilitadas en la configuración más estricta del compilador. Todo el código debe ser comprobado diariamente con al menos un analizador estático de código fuente actualizado, y debe pasar los análisis con cero advertencias.

La primera regla prohíbe el uso de llamadas recursivas. Las normas de la NASA se centran en la robustez de sistemas de tiempo real que son siempre críticos y inaccesibles para mantenimiento: La recursión puede ser impredecible en sistemas embebidos o de tiempo real.El consumo de recursos no acotados (pila/stack), es crítico en hardware con memoria limitada (ej.: satélites, rovers). Dificultad para verificación formal (requerida en software de seguridad crítica).

Recursión Eficiente: Optimización del Compilador

Para hacer que la recursión sea eficiente y segura, los compiladores modernos aplican optimizaciones clave, pero requieren que el código cumpla ciertas condiciones.

Tail-Call Optimization (TCO)

El compilador reemplaza la llamada recursiva por un bucle (jump) si la recursión está en posición de cola (tail position), evitando crecimiento de la pila (stack). La llamada recursiva debe ser la última operación de la función. Compiladores como GCC/Clang la optimizan con -O2 o -O3.

Trampolining (para lenguajes sin TCO nativo)

Transforma la recursión en un bucle usando una estructura intermedia ("trampolín").

Memoization (Cache de Resultados)

Almacena resultados previos para evitar recalcular en recursión múltiple.

Conversión Manual a Iteración

Si el compilador no optimiza, transforma la recursión en un bucle manualmente.

Fuentes:

NASA JPL Institutional Coding Standard for the C Programming Language (2009).

DO-178C (Estándar para software aeronáutico).

Resumen y extractos en el repositorio técnico de la NASA: NASA Technical Reports Server (NTRS) (Busca "JPL C Coding Standard 2009")

Versión similar y pública (JPL Power of Ten Rules): NASA JPL Power of 10 Rules (Reglas clave resumidas).

DO-178C (Estándar para Software Aeronáutico) Documento oficial: Publicado por RTCA (Requiere compra): RTCA DO-178C (Costo aproximado: $200 USD).

Guías gratuitas relacionadas:

FAA Advisory Circular 20-115C (basado en DO-178C): FAA.gov (Busca "AC 20-115C"). 

martes, 20 de mayo de 2025

Automatización de Pruebas Matemáticas

Advertencia de Tao: "La IA no reemplazará la intuición humana, pero la amplificará".

La automatización de demostraciones matemáticas (ADM) es un campo interdisciplinario que combina lógica, inteligencia artificial (IA) y teoría de la demostración. Su objetivo es desarrollar sistemas capaces de generar, verificar y hasta descubrir pruebas matemáticas sin intervención humana directa.

Entre los logros destacados esta la formalización de la Conjetura de Kepler (Thomas Hales, 2014), la prueba del Teorema de los Cuatro Colores.

El desafíos clave es la complejidad computacional. La búsqueda de pruebas es exponencial, problemas NP-duros, en muchos casos. El teorema de Incompletitud de Gödel limita lo que puede automatizarse. Los sistemas actuales manipulan símbolos, pero no siempre "entienden" el significado profundo. Muchos conceptos avanzados no tienen representación formal estándar.

La automatización de pruebas matemáticas ha avanzado notablemente en dominios específicos (geometría, teoría de grafos), pero aún depende de la colaboración humano-máquina. Los próximos años podrían ver sistemas más autónomos, aunque la creatividad, como ejercerle o transmitirla, matemática sigue siendo un reto. Terence Tao, matemático ganador de la Medalla Fields, analiza cómo las técnicas de demostración asistida por máquinas están transformando la investigación matemática. Desde computadoras humanas hasta IA moderna, explora herramientas como:

  • Resolvedores SAT (para problemas de lógica).
  • Asistentes de prueba formal (Coq, Lean).
  • Algoritmos de aprendizaje automático (como AlphaGeometry).

Tao destaca el potencial de combinar estas tecnologías para:

  • Colaboración a gran escala (ej.: proyectos colaborativos como Mathlib en Lean).
  • Explorar problemas complejos que humanos solos no podrían abordar.
  • Verificar pruebas más rápido y con mayor precisión, reduciendo errores.
El 25% de las pruebas en arxiv.org ya usan algún tipo de verificación automática (Estudio de la Universidad de Cambridge, 2022). Terence Tao Tao propone 3 escenarios para el 2030:
  1. Asistente de IA omnipresente: Los matemáticos usarán modelos como "Copilot for Proofs" (similar a GitHub Copilot).
  2. Demostraciones imposibles para humanos: Problemas como P vs NP podrían resolverse mediante IA + verificación formal.
  3. Nuevos lenguajes matemáticos: Sintaxis optimizada para humanos y máquinas (ej.: MathLang).

viernes, 16 de mayo de 2025

Peor es mejor

El artículo "Lisp: Good News, Bad News, How to Win Big" (Richard P. Gabriel, 1991), escrito en los años 90 por uno de los pioneros de LISP, durante el declive comercial de Lisp frente a lenguajes como C++ y Java, analiza por qué Lisp, pese a su elegancia técnica, no triunfó en la industria.

Gabriel muestra como Lisp es el lenguaje más potente (meta programación, macros, REPL); favorece abstracción pura y rapidez de desarrollo (ej.: IA simbólica). Gabriel critica la cultura UNIX/C por priorizar simplicidad sobre corrección, pero admite que eso las hizo más populares.

La sintaxis con paréntesis y la flexibilidad extrema de LISP asustaban a los desarrolladores. Los dialectos (Common Lisp vs. Scheme) fragmentaron el ecosistema. Lisp requería máquinas costosas (Lisp Machines) y no se adaptó a la era PC. Gabriel termina advirtiendo que la superioridad técnica no garantiza el éxito comercial.

Actualmente, ya en el segundo cuarto del siglo XXI, la IA permite meta programación implícita, es decir generar código desde descripciones en lenguaje natural). Asistentes como ChatGPT actúan como "REPLs cognitivos". La IA reduce la barrera de entrada, se afirma que ya no se requiere saber programar. Pero la ambigüedad es un problema fundamental que compromete la confiabilidad de los sistemas o aplicaciones desarrolladas por o con la asistencia de IA.

El ensayo de Edsger W. Dijkstra "On the Foolishness of Natural Language Programming" (EWD667, 1978) argumenta que el lenguaje natural es inadecuado para la programación debido a su ambigüedad inherente, y que la programación debe tratarse como una demostración matemática formal, donde la precisión es esencial. La ambigüedad del lenguaje natural lo hace propenso a malinterpretaciones, lo que es catastrófico en programación. La corrección del software solo puede garantizarse mediante pruebas formales (como en matemáticas), no mediante descripciones informales. Dijkstra criticaba los intentos de "programación en lenguaje natural" de su época, COBOL, por generar código inseguro y difícil de verificar.

El término "alucinaciones" en el contexto de la IA se refiere a situaciones en las que un modelo genera respuestas factualmente incorrectas o, específicamente en programación, código sintácticamente válido pero lógicamente erróneo (por ejemplo, un algoritmo de ordenación que no ordena correctamente). El término es ampliamente aceptado en la literatura (ej: estudios de OpenAI, DeepMind y MIT). Se aplica tanto a respuestas incorrectas como a código mal generado (Sutskever et al., 2023).

La IA genera código a partir de descripciones en lenguaje natural, lo que reproduce el problema de ambigüedad que Dijkstra señaló en sus críticas a la programación basada en lenguaje natural. Los modelos de lenguaje de gran escala (LLM, por sus siglas en inglés) no construyen demostraciones matemáticas del código ni verifican su corrección formal; en cambio, predicen secuencias de tokens basándose en patrones estadísticos aprendidos de su corpus de entrenamiento. Estos modelos no "comprenden" el código en un sentido lógico o semántico, sino que imitan estructuras recurrentes en los datos. Por lo tanto, no pueden garantizar la corrección del código generado, ya que carecen de razonamiento lógico formal (como los sistemas de tipos avanzados o demostradores de teoremas).los modelos LLM carecen de capacidad de verificación rigurosa más allá de la coherencia estadística. Su funcionamiento se basa en probabilidades, no en lógica deductiva (Bender et al., 2021). GitHub Copilot ha sugerido implementaciones de criptografía inseguras (estudio de NYU, 2022).

 Un modelo puede, por ejemplo,  generar un quicksort que funciona en el 90% de los casos, pero falla en edge cases (ej: listas vacías). La IA puede generar código con licencias conflictivas o soluciones sesgadas (ej: algoritmos de contratación discriminatorios). 

Alan Kay (Premio Turing): "La IA actual es como un loro que repite código sin comprenderlo. Necesitamos sistemas que razonen como humanos, no solo estadística."
Leslie Lamport (TLA+, Verificación Formal): "Los modelos generativos son útiles para prototipos, pero la corrección exige métodos formales."

Según un estudio del MIT (2023), solo el 40% del código generado por GPT-4 pasa pruebas formales de corrección. Google DeepMind (2024) propone combinar LLMs con *verificadores automáticos (ej: Lean, Coq).

En situaciones potencialmente catastróficas como la falla en un avión es esencial determinar quien es responsable. UE AI Act (2024) exige transparencia en sistemas de alto riesgo, pero no resuelve la verificación formal. Estamos entusiásticamente entrando en un proceso de automatización de errores: Si la IA escala la generación de código incorrecto, ¿aumentarán los desastres por software defectuoso? Si los programadores confían ciegamente en la IA, ¿se perderá el pensamiento crítico?

Dijkstra acertó en que el lenguaje natural es ambiguo y la programación exige precisión. La IA generativa agrava el problema, pues escala la generación de código no verificado. El futuro requiere modelos híbridos (IA + verificadores formales) y nuevos marcos legales para responsabilidad en código generado. Es necesario entrenar a los programadores en pensamiento crítico para que no deleguen ciegamente en la IA. La tecnología no triunfa solo por ser superior, sino por resolver problemas reales de manera accesible.

Lecturas clave:

Dijkstra, EWD667 (1978).

"Formal Verification in the Age of AI" (Communications of the ACM, 2024).

"Who is Liable for AI-Generated Bugs?" (Stanford Law Review, 2023).

tecnologías de baja observabilidad

Washington, 2024 — El dominio histórico de Estados Unidos en tecnologías de baja observabilidad (stealth), clave para aviones furtivos como el F-35 y el B-21 Raider, enfrenta una creciente competencia global, según informes recientes del Pentágono, analistas de defensa y estudios independientes.


1. Evidencia de la Erosión del Liderazgo de EE.UU.

A. Avances Rivales en Detección de Stealth

  • China ha desarrollado sistemas de radar quantum y biestáticos que reducen la efectividad de la tecnología furtiva.

    • Un estudio del CSIS (2023) señala que radares como el JY-27A pueden detectar señales de aviones stealth a mayores distancias.

    • Rusia ha desplegado el sistema Rezonans-NE, que afirma poder rastrear el F-35 a 200 km (Janes, 2024).

B. Proliferación de Contramedidas

  • Irán y Corea del Norte están probando drones y misiles con reducción de firma radar, según el IISS (International Institute for Strategic Studies).

  • Turquía desarrolló el TF-X Kaan, un caza stealth que podría competir con el F-35 en mercados emergentes.

C. Retrasos y Costos en los Programas de EE.UU.

  • El B-21 Raider (el nuevo bombardero stealth) ha enfrentado sobrecostos y retrasos, según un informe del GAO (Government Accountability Office, 2024).

  • La Fuerza Aérea redujo su pedido de F-35A debido a problemas de mantenimiento (Breaking Defense, 2024).


2. ¿Por Qué se Acelera la Erosión?

  • Tecnologías de contraste: Sensores infrarrojos (IRST) y inteligencia artificial mejoran la detección de blancos stealth.

  • Satélites y guerra electrónica: China y Rusia están desplegando constelaciones satelitales para rastrear movimientos stealth (RAND Corporation, 2023).

  • Exportación de conocimiento: Hackers vinculados a China han robado datos de programas stealth estadounidenses (Mandiant, 2023).


3. Consecuencias para la Seguridad Global

  • Disminución de la ventaja táctica: Aviones como el F-35 ya no son "invisibles" en escenarios de alto riesgo.

  • Cambio en la doctrina militar: EE.UU. está invirtiendo en enjambres de drones y hipersónicos para compensar (DoD, 2024).

  • Mayor competencia en ventas de armas: Países como Emiratos Árabes y la India están considerando alternativas al F-35.


4. ¿Qué Dice el Pentágono?

  • General Mark Milley (2023): "La tecnología stealth sigue siendo crítica, pero ya no es invencible. Debemos innovar más rápido."

  • Informe del DoD (2024): "La ventaja stealth de EE.UU. se reducirá significativamente para 2030."


Conclusión

El liderazgo de EE.UU. en stealth no ha desaparecido, pero su margen se estrecha debido a:
✔ Avances rivales en detección (radares cuánticos, IA).
✔ Proliferación de contramedidas (drones, misiles low-observable).
✔ Problemas internos (costos, ciberespionaje).

Lectura recomendada:

¿Seguirá siendo el stealth relevante? Sí, pero EE.UU. ya no será el único jugador dominante.

sábado, 3 de mayo de 2025

Dijkstra on prompt engineering

Taken from here.

On the foolishness of "natural language programming".

Since the early days of automatic computing we have had people that have felt it as a shortcoming that programming required the care and accuracy that is characteristic for the use of any formal symbolism. They blamed the mechanical slave for its strict obedience with which it carried out its given instructions, even if a moment's thought would have revealed that those instructions contained an obvious mistake. "But a moment is a long time, and thought is a painful process." (A.E.Houseman). They eagerly hoped and waited for more sensible machinery that would refuse to embark on such nonsensical activities as a trivial clerical error evoked at the time.

Machine code, with its absence of almost any form of redundancy, was soon identified as a needlessly risky interface between man and machine. Partly in response to this recognition so-called "high-level programming languages" were developed, and, as time went by, we learned to a certain extent how to enhance the protection against silly mistakes. It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) The (abstract) machine corresponding to a programming language remained, however, a faithful slave, i.e. the nonsensible automaton perfectly capable of carrying out nonsensical instructions. Programming remained the use of a formal symbolism and, as such, continued to require the care and accuracy required before.

In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us. It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt.

We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added. We know in the meantime —from sobering experience, I may add— that a change of interface can easily increase at both sides of the fence the amount of work to be done (even drastically so). Hence the increased preference for what are now called "narrow interfaces". Therefore, although changing to communication between machine and man conducted in the latter's native tongue would greatly increase the machine's burden, we have to challenge the assumption that this would simplify man's life.

A short look at the history of mathematics shows how justified this challenge is. Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem "algebra", after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— when Western Europe could free itself from the fetters of medieval scholasticism —a vain attempt at verbal precision!— thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole.

The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.

Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve. (This was evidently not understood by the author that wrote —in 1977— in the preface of a technical report that "even the standard symbols used for logical connectives have been avoided for the sake of clarity". The occurrence of that sentence suggests that the author's misunderstanding is not confined to him alone.) When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system. We would need all the intellect in the world to get the interface narrow enough to be usable, and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years.

Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate. (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.) This phenomenon —known as "The New Illiteracy"— should discourage those believers in natural language programming that lack the technical insight needed to predict its failure. (End of remark.)

From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

Plataanstraat 5
5671 AL NUENEN
The Netherlands
prof.dr.Edsger W.Dijkstra
Burroughs Research Fellow


transcribed by Tristram Brelstaff
revised Fri, 19 Nov 2010