Occidente olvidó cómo fabricar cosas y ahora está olvidando cómo programar
(techtrenches.dev)- El colapso de la capacidad de producción en defensa muestra que, cuando se corta la continuidad entre personal calificado que se jubila y el conocimiento de procesos que desaparece, no se puede reactivar rápidamente la producción aunque surja demanda en tiempos de guerra
- Los casos de la restauración del Stinger, los proyectiles de 155 mm y Fogbank muestran que la optimización de costos y los puntos únicos de falla mejoraron la eficiencia en tiempos de paz, pero debilitaron fuertemente el margen de la cadena de suministro y la velocidad de recuperación
- El software también se está moviendo por una ruta que, al apoyarse en sustitutos más baratos, debilita la pipeline de talento, y tras la adopción de IA están creciendo al mismo tiempo la reducción de contrataciones junior y el review bottleneck
- La pericia no puede crearse rápido solo con dinero, y tanto en defensa como en software la acumulación de conocimiento y habilidades requiere años de experiencia práctica y capacidad de revisión
- Si los juniors no pasan por errores formativos y depuración, no se acumula el conocimiento tácito, lo que aumenta el riesgo de que en el futuro falten ingenieros senior y institutional knowledge
Paralelismos entre el colapso de la capacidad de producción militar y la reducción del talento en software
- Raytheon tuvo que volver a llamar a ingenieros de más de 70 años para reiniciar la producción del Stinger, y reactivar el proceso a partir de viejos planos en papel y equipos de prueba que estaban guardados en bodegas
- Después de que el Pentágono no comprara nuevos Stinger durante 20 años, la guerra en Ucrania disparó la demanda, pero la línea de producción estaba cerrada, los componentes electrónicos y el seeker estaban descontinuados, y hasta los pedidos hechos en mayo de 2022 estaban programados para entregarse recién en 2026
- En solo 10 meses de guerra, la demanda creció hasta agotar el equivalente a 13 años de producción de Stinger, y el conocimiento de producción ya perdido junto con los vacíos de personal pasaron a ser el principal cuello de botella
- No era solo un problema de presupuesto: el obstáculo central fue una estructura en la que, tras la salida del personal calificado jubilado, no hubo reemplazos que continuaran ese conocimiento
La vulnerabilidad de la cadena de suministro que dejó al descubierto el fracaso al aumentar la producción de municiones
-
La promesa de un millón de proyectiles y la capacidad real de producción
- En marzo de 2023, la UE prometió suministrar a Ucrania un millón de proyectiles en 12 meses, pero la capacidad anual de producción de Europa era de unas 230 mil unidades, mientras Ucrania consumía entre 5,000 y 7,000 por día
- Para la fecha límite, Europa había entregado solo cerca de la mitad, y una investigación de 11 medios en 9 países estimó que la capacidad real de producción era de alrededor de un tercio de la cifra oficial de la UE
- La meta del millón de proyectiles se retrasó hasta diciembre de 2024, nueve meses después de la promesa original
-
Una estructura donde se superpusieron varios cuellos de botella al mismo tiempo
- Francia dejó de producir su propio propelente en 2007 y esa actividad estuvo detenida durante 17 años
- El principal sitio de producción de TNT en Europa era solo uno, en Polonia, y las reservas de munición de Alemania alcanzaban apenas para dos días
- La planta de Nammo en Dinamarca había cerrado en 2020 y tuvo que reactivarse prácticamente desde cero
- La industria europea de defensa estaba optimizada para productos personalizados, caros y de bajo volumen, y no había sido diseñada pensando en producción masiva ni respuesta a crisis
-
Estados Unidos tenía debilidades similares
- Estados Unidos también dependía de una sola planta en Scranton, una sola instalación de carga explosiva en Iowa, y no producía TNT en el país desde 1986
- Incluso después de invertir miles de millones de dólares, la producción seguía por debajo de la mitad del objetivo
Los puntos únicos de falla creados por la optimización de costos
- En 1993, el Pentágono envió a los CEOs de defensa el mensaje de que si no se consolidaban, desaparecerían, y después de eso 51 grandes contratistas de defensa se redujeron a 5
- Los proveedores de misiles tácticos pasaron de 13 a 3, los astilleros de 8 a 2, y la fuerza laboral cayó de 3.2 millones a 1.1 millones, una reducción del 65%
- En toda la cadena de suministro de municiones aparecieron single points of failure, y la fabricación de los cuerpos de proyectiles de 155 mm quedó concentrada en una sola empresa en Coachella, California
- Las cargas propulsoras también dependían de una única instalación en Canadá, y la optimización orientada al menor costo elevó la eficiencia en tiempos de paz, pero casi no dejó margen para responder a un salto repentino de la demanda
Cuando el conocimiento desaparece, la recuperación también se vuelve lenta
-
El fracaso al restaurar Fogbank
- Fogbank es un material confidencial usado en ojivas nucleares, producido entre 1975 y 1989 antes de que sus instalaciones fueran cerradas
- En 2000 se intentó fabricarlo otra vez para un programa de extensión de vida útil, pero la mayoría del personal con experiencia en su producción ya se había jubilado, fallecido o salido de la institución, y casi no quedaban registros
- Según el material relacionado de la GAO, hicieron falta otros 69 millones de dólares y varios años de ingeniería inversa para volver a obtener un Fogbank producible
-
El conocimiento tácito no documentado fue decisivo
- El nuevo Fogbank resultó ser demasiado puro, y solo después se descubrió que una impureza no intencional presente en los lotes originales era importante para su funcionamiento real
- Esa información no estaba en ningún documento; solo la conocían los trabajadores que habían participado en la producción original, pero ya se habían retirado
- La razón por la que ni siquiera pudieron volver a fabricar un material hecho por ellos mismos fue que el conocimiento había quedado solo en las personas
El software se está moviendo por el mismo camino
-
Los sustitutos baratos y rápidos debilitan la pipeline de talento
- El patrón de reemplazar capacidades construidas durante décadas por sustitutos más baratos, debilitar la pipeline humana y luego volver a necesitar esas capacidades eliminadas en un momento de crisis se repite tanto en defensa como en software
- Si en defensa ese sustituto fue el peace dividend, en software la IA está ocupando ese mismo lugar
- El colapso de la pipeline de talento y la crisis de comprensión ya se habían hecho visibles, y los casos de defensa también muestran cuánto puede tardar reconstruir eso
-
Reconstruir requiere tiempo más que dinero
- Los grandes aumentos de producción en defensa tardaron de 3 a 5 años para sistemas simples y de 5 a 10 años para sistemas complejos
- En el caso del Stinger, el plazo mínimo entre pedido y entrega fue de 30 meses; al Javelin le tomó cuatro años y medio aumentar la producción a menos del doble; y los proyectiles de 155 mm seguían sin alcanzar la meta incluso después de cuatro años y 5 mil millones de dólares invertidos
- A Francia también le tomó 17 años reanudar la producción de propelente, y la limitación estaba menos en el dinero que en el conocimiento y la experiencia
- Un estudio de RAND estimó que el 10% de la tecnología de diseño de submarinos requería 10 años de experiencia práctica incluso después del PhD, y los oficios calificados de defensa también requerían entre 2 y 4 años de aprendizaje y entre 5 y 8 años para desarrollar capacidad de supervisión
-
La curva de crecimiento en software tampoco se puede comprimir
- A un desarrollador junior le toma entre 3 y 5 años convertirse en un mid-level estable, entre 5 y 8 años llegar a senior, y más de 10 años alcanzar niveles de principal o architect
- Ese tiempo no se reduce solo por gastar más dinero, y tampoco parece fácil de comprimir con IA
Cuellos de botella y debilitamiento de habilidades tras la adopción de IA
-
El cuello de botella de revisión crece más que la velocidad de producción
- En un experimento aleatorizado controlado de METR, cuando desarrolladores experimentados usaron herramientas de codificación con IA, el trabajo real en open source tomó en realidad un 19% más de tiempo
- Antes de empezar, se esperaba que la IA permitiera trabajar un 24% más rápido, pero la diferencia con el resultado real fue de 43 puntos porcentuales
- En experimentos posteriores, tampoco fue menor la proporción de desarrolladores que dijo que no participaría si tuviera que trabajar sin IA, lo que sugiere que ya ni siquiera es fácil imaginar volver a un trabajo sin ella
-
Menos contrataciones y caída en la matrícula universitaria
- Salesforce dijo que no haría contrataciones adicionales de ingenieros de software en 2025
- En una encuesta de LeadDev, el 54% de los líderes de ingeniería consideró que los AI copilots reducirán las contrataciones junior en el largo plazo
- En una encuesta de CRA, el 62% de los programas universitarios de computación reportó una caída en la matrícula este año
-
El code review se vuelve la restricción principal
- La IA genera código rápidamente, pero la revisión humana avanza más lento, lo que crea un review bottleneck
- Como respuesta, se han hecho cambios para no dejar que la IA revise código generado por IA, y para exigir en las plantillas de pull request el contenido del cambio, la razón del cambio, el tipo de cambio y capturas de pantalla del antes y después
- También se usan revisores dedicados por proyecto para añadir más ojos que detecten lo que el modelo pasó por alto
Las capacidades que escasearán en el futuro
-
El entorno está cambiando a uno donde la técnica sola no basta
- Ahora la especialización técnica por sí sola ya no es suficiente; también hacen falta criterio y liderazgo para asumir responsabilidad, explicar trade-offs y descartar propuestas equivocadas que la máquina presenta con seguridad
- En una contratación reciente, de 2,253 postulantes 2,069 fueron rechazados y solo se contrataron 4, con una tasa de conversión de 0.18%
- Esto deja ver que casi no hay en el mercado talento que combine capacidad técnica con criterio para identificar errores de la IA
-
La documentación por sí sola no completa la transferencia de conocimiento
- Se está documentando ampliamente con Site Books, SDDs, reportes RVS e incluso módulos boilerplate con cobertura completa
- Hoy eso funciona porque quienes leen esos documentos tienen experiencia de ingeniería, pero no está claro si ese mismo enfoque seguirá funcionando cuando esa experiencia desaparezca
- No se puede predecir el desempeño de los modelos en 2031, y tampoco es seguro que la IA mejore lo suficiente como para causar menos problemas
-
Las crisis llegan sin aviso y los seniors no se fabrican al instante
- Igual que nadie esperaba una guerra total en Europa en 2022, las crisis no llegan según calendario
- En 5 a 10 años se necesitarán ingenieros senior capaces de entender el sistema completo, depurar una falla distribuida a las 2 a. m. y cargar también con el institutional knowledge fuera del codebase
- Pero ese talento no se está formando ahora: los juniors que deberían aprender no están siendo contratados o están acumulando la AI-mediated competence que describen investigaciones financiadas por el DoD
- Puede que quede la habilidad de lanzar prompts a la IA, pero no crezca la capacidad de señalar en qué se equivoca
El riesgo de que el código tenga su propio Fogbank
- Si los juniors se saltan la depuración y los errores formativos, no se acumula el conocimiento tácito, y cuando la generación actual de ingenieros se jubile ese conocimiento no se transferirá a la IA
- Como resultado, ese conocimiento simplemente podría desaparecer, en una estructura muy parecida a lo que ocurrió con Fogbank
- La guerra de Ucrania fue el momento en que el fracaso de la optimización en defensa volvió como costo real, y Stinger, Javelin, Fogbank y el millón de proyectiles que no pudieron producirse muestran ese precio
- La ingeniería de software está apostando por la misma optimización; si la IA llega a ser lo suficientemente buena, esa apuesta podría salir bien, pero si no, podría llegar la misma factura
1 comentarios
Comentarios de Hacker News
El verdadero problema no es la IA en sí
El problema es una forma de gestión que elimina el margen de maniobra de las personas y de las organizaciones porque no genera ganancias inmediatas, y aun así cree que ese conocimiento seguirá ahí cuando vuelva a hacer falta
Recortar costos a corto plazo reduce la contratación de juniors y también le quita a los ingenieros experimentados el espacio para enseñar, interrumpiendo así la transferencia de conocimiento tácito
Al final solo quedan la documentación y la automatización, pero la documentación no es experiencia de campo y la automatización no puede sustituir el criterio
Cuando desaparece la gente que realmente ha trabajado con el sistema, el conocimiento tácito también desaparece de la organización y la productividad termina cayendo
Ahora la IA se está vendiendo con ese mismo patrón, y en muchos ámbitos lo que parece buscarse no es tanto aumentar la productividad como reducir personal
Se ve una forma de pensar parecida a la de GE cuando se obsesionó con maximizar los resultados trimestrales y el retorno para los accionistas, vaciando sus capacidades de largo plazo
Quienes toman decisiones lejos de la ingeniería real creen que pueden reemplazar el conocimiento tácito con herramientas, procesos y documentos, pero no es así
Si eliminas a las personas y el pipeline de aprendizaje, ese conocimiento no se queda en la organización: desaparece
No queda ningún margen para experimentar, reparar o absorber impactos, y yo diría que el 90% de los sistemas que hoy se rompen lo hacen porque no tienen slack para aguantar golpes de corto plazo
En un proyecto de startup siempre hay que seguir construyendo cosas desde el principio, así que agregar más funciones equivale a crear valor, pero empresas como Visa, Salesforce o LinkedIn muchas veces ya tienen suficiente producto, suficientes funciones y suficientes recursos
Esas empresas a menudo terminan forzando clavos para que encajen con el martillo de write more software
Aunque parezca que hay muchísimas listas de deseos y sistemas de A/B testing, si realmente hubiera oportunidades claras de ganar más dinero simplemente desarrollando más software, probablemente ya las habrían aprovechado
El crecimiento real y la nueva demanda suelen aparecer más fuera de esos lugares, y puede que las oportunidades terminen en manos de empresas que no saben desarrollar software o no pueden comprarlo
Y la clave aquí es la fungibility
El capital humano no es un objeto que se pueda reempaquetar fácilmente; es algo vivo, y si se rompe el pipeline de talento y habilidades, puede desaparecer tal cual
El riesgo del coding con IA también está en que solo aprovecha el capital humano ya existente, pero no crea nuevo capital humano para el futuro
Buena parte del conocimiento que tengo sobre los sistemas que llevo sí se puede documentar, y en teoría una persona nueva podría hacerse cargo solo con esa documentación
El problema es que la cantidad de documentación necesaria sería absurda
Incluso para un sistema pequeño, me parece realista hablar de decenas de miles de páginas A4 llenas hasta el borde
La persona nueva tendría que entender casi todo ese enorme volumen de documentos como si se lo memorizara, y a la empresa no le gusta gastar dinero ni en producir esa documentación ni en el aprendizaje de nuevo personal
En mi experiencia, por eso no funciona; no porque sea absolutamente imposible en principio
Poco a poco estamos eliminando nuestras razones para hablar con otras personas
En el momento en que le preguntas algo a una IA, desaparece una interacción humana que antes habrías tenido con un colega
Esto no es solo un problema del coding; también me hace pensar qué tipo de interacción social está sustituyendo tener siempre un ChatGPT en el bolsillo
Los seres humanos somos sociales por naturaleza, y estamos optimizando la socialización hasta hacerla desaparecer tanto como sea posible
Yo tampoco estoy libre de esa tendencia, porque también prefiero Doordash antes que llamar a un restaurante como hacía antes
En un mundo ideal, las empresas deberían optimizar el beneficio de corto y mediano plazo, los gobiernos el beneficio de largo plazo y las personas su vida entera
Si las empresas reducen el slack y operan al límite, el gobierno debería preservar ese margen y el flujo de talento mediante regulación, para proteger la capacidad del país
Pero en Occidente parece que los grupos de lobby y los MBA dominan a las empresas y además arrastran al gobierno a optimizar solo el dinero
Sigo programando todos los días sin ayuda para coding porque creo que solo así no se me olvida la sensación manual del oficio, incluso en lo más pequeño
La razón principal por la que no uso IA es que, cuando estoy frente a la pantalla, prefiero no depender de nada si puedo evitarlo
Claro, exceptúo cosas como documentación, libros o Stack Overflow
Veo seguido a personas a mi alrededor apoyándose en IA hasta para tareas cotidianas mínimas, y eso me asusta bastante porque implica una reducción extrema del esfuerzo de pensar
Ceder ese esfuerzo mental no es poca cosa
Para mí, en el momento en que entregas eso te conviertes en una especie de zombi dependiente, y yo creo que el conocimiento sale de repetir ensayo y error casi todos los días
La tecnología siempre ha demostrado que puede empujar y manipular a la gente, y la dependencia de la IA parece la forma final en la que las empresas se meten incluso con la capacidad humana más delicada: pensar y tener curiosidad
Pasé la mayor parte del tiempo confundido y frustrado, y terminé el trabajo solo después de pelearme con el problema casi 7 horas
Pero esa dificultad en sí me impactó tanto que hasta me preocupé pensando si mi cerebro se había podrido un poco por no usarlo igual
Luego recordé que resolver problemas nuevos siempre había sido así de difícil
Enfrentarte a un problema que nunca habías visto antes siempre fue así de duro; lo único es que yo ya no estaba acostumbrado a esa sensación
Cuando te acostumbras a la dificultad, eso se siente normal; al revés, cuando te acostumbras a la ausencia de dificultad, volver a encontrarla se siente abrumador y extraño
Por eso creo que la capacidad de tolerar la incomodidad y la dificultad es un músculo que hay que conservar sí o sí
Eso solo fue un problema real cuando cambié de trabajo y tuve que escribir código para entrevistas en una plataforma sin revisión de sintaxis ni autocompletado, así que practiqué con anticipación en ese entorno
En el trabajo real, depender del autocompletado de sintaxis nunca me causó un gran problema, y lo importante era entender los conceptos centrales del lenguaje y el runtime
Por ejemplo, era más importante entender cómo funciona el event loop de Node.js y cómo escribir programas asíncronos y basados en eventos
En los últimos 6 meses, diría que casi no he desplegado código del que yo mismo haya leído aunque sea una sola línea
Y aun así, trabajar de esa forma es muchísimo más agotador
Cuando programaba a mano, el proceso de resolver problemas se sentía como un rompecabezas, y al terminar había un bucle de satisfacción y una recompensa de dopamina
Ahora paso la mayor parte del día sintiéndome más como alguien de QA que como quien resuelve rompecabezas, y eso desgasta muchísimo
Aunque la IA me resuelva los problemas difíciles, la satisfacción que da una tragamonedas de LLM es mucho menor que la de resolverlos yo mismo
Los otros dos días no uso asistentes de coding y solo le dejo la revisión al final, cuando ya terminé
Creo que este método ayuda también a mantener la salud mental y a conservar el filo de la habilidad
Incluso en lenguajes que manejaba bastante bien, la parte mecánica se me nubla enseguida
Por eso siento que el trabajo asistido por LLM sería como echarle cloro al cerebro
Puedo notar por mí mismo que mientras más lo use, peor me va a hacer
Mi capacidad para estructurar lo necesario y resolver problemas sigue bien, pero los nuts and bolts reales se evaporan rapidísimo
La frase el dinero no era la restricción; el conocimiento era la restricción me resulta irónica
Porque el propio texto es tan parecido a algo escrito por IA que se hace difícil leerlo
Tiene un flujo antinatural, entrecortado, y está lleno de tics típicos de LLM
La capacidad de escribir también es una habilidad que se atrofia
Entiendo usar IA por fluidez lingüística, pero siento que la traducción con IA todavía es mejor que el texto generado
Si ni siquiera te importa lo suficiente como para escribirlo tú, tampoco veo muy claro por qué yo debería leerlo
Para mí, el código y la prosa no son tan distintos en esencia
Ambos están hechos de palabras clave, gramática, sintaxis y combinaciones con significado
Si una frase creada por IA no tiene sentido o es difícil de leer, entonces por la misma lógica el código hecho por IA también debería ser difícil de leer y poco confiable
Ojalá dejáramos un poco ese doble rasero
De hecho me pareció mucho mejor que la prosa basura de IA que a veces en HN todos dan por buena sin más
Así que algunas de las características que la gente percibe como propias de los LLM podrían ser, en realidad, estilos que primero usaron personas y que luego vuelven a repetirse por mano humana
Todos los días veo varios textos generados por IA en la parte alta de resultados de búsqueda y los salto enseguida, pero este texto me pareció bastante distinto de esa clase de contenido
Me cuesta creer que las empresas realmente puedan medir bien el nivel de carrera de un desarrollador
Distinciones como junior, mid, senior o lead son más apariencia que otra cosa; en la práctica son un continuo en varios ejes y además se deforman fácilmente según la tecnología de moda
Si nos ponemos estrictos, creo que una persona sí puede llegar a nivel senior sin estar empleada por una empresa
Al final, lo central es la voluntad de aprender y construir por cuenta propia, junto con el tiempo invertido
Hoy da la impresión de que lo que las empresas realmente valoran no es tanto la habilidad de desarrollar, sino la experiencia de haber logrado sortear de algún modo estructuras organizativas rotas y sistemas torpes de comunicación y presupuesto
No sé si eso define a un senior o solo significa ser hábil para la política interna
Este patrón se nota especialmente cuando el software fracasa y se rompe la ilusión
Un grupo recibe un problema, aprende por su cuenta lo necesario, investiga lo que no sabe, entrega resultados significativos de forma repetida, se comunica con las personas necesarias, comparte avances, ayuda y recibe ayuda del equipo, y además cubre por iniciativa propia lo que falta
El resto es simplemente el resto
En los primeros años de carrera suele quedar bastante claro a cuál grupo pertenece alguien, y convertir a personas del segundo grupo en personas del primero es casi imposible
Por eso incluso alguien con 30 años de experiencia puede ser un senior del segundo tipo, y alguien recién graduado puede pertenecer al primero
Claro, también hay personas muy buenas en política, relaciones personales o fanfarronería, que ante la gerencia parecen del primer tipo pero en realidad son del segundo
Pero eso ya no es hablar de capacidad para construir software
Y también puede pasar que alguien del primer grupo esté subvalorado o no ascienda, y la correlación con el éxito real de carrera no es tan grande
Uno puede ponerse cualquier etiqueta por su cuenta, pero es algo medio raro
A un freelancer se le evalúa por su portafolio, a un académico de ciencias de la computación por sus papers, y a quien contribuye a OSS por la cantidad e impacto de sus aportes
En cualquier caso, todo termina siendo proporcional al esfuerzo dedicado a aprender y construir
Pero, independientemente de estar contratado o no, la pericia no está determinada solo por cosas que se puedan aprender en libros
Cosas como gestionar stakeholders o presentar soluciones no se dominan solo leyendo; requieren práctica real y retroalimentación
Un ingeniero senior no es solo alguien que escribe buen código, sino alguien que puede contribuir por su cuenta y ayudar a otros a lo largo de todo el SDLC, y esas capacidades probablemente se desarrollan mucho más fácil en un entorno profesional que en proyectos amateurs
Y eso casi siempre requiere habilidades sociales y organizativas; aunque moleste, el mundo funciona así
Al mismo tiempo, también siento que preferiría no saber estas cosas lo más posible
No quiero andar desarmando mi cabeza para amoldarla a alguien, y trabajar entre este tipo de problemas es sufrimiento puro
Sería como preguntar si un cirujano no empleado puede convertirse en senior surgeon
Es difícil llegar a senior sin haberlo hecho realmente como profesión durante varios años, y en este campo la experiencia lo es casi todo
No puedes internalizar el entendimiento necesario solo con libros, y los humanos no incorporamos lo suficiente solo leyendo o mirando
Hay que hacerlo directamente para aprender de verdad
Puedes aprender hechos y técnicas en libros, pero no te conviertes en Michelin Chef solo por leer un libro sobre restaurantes Michelin
Los generadores de código con IA parecen trolls
Sueltan cosas plausibles con mucha confianza, pero una parte está mal, y al final es el humano quien tiene que detectar los errores
Esto no es divertido y no tiene flow
A mí me gusta corregir errores ajenos, y en especial me gusta la sensación de ganarle a un LLM
Más que el estado de inmersión tradicional, podía concentrarme durante más tiempo vigilando con obsesión lo que hacía el LLM
Ahí no hay lógica, solo repetición de patrones, y no entiendo por qué ingenieros inteligentes caen en eso
Es un poco irónico que este mismo texto parezca haber recibido ayuda de IA de forma bastante evidente
No critico la asistencia de IA en sí, pero al ponerla junto al tema del texto da para pensar
La gente parece usarlos para “pulir” el texto, pero en realidad es probable que, sin eso, el resultado hubiera sido más agradable de leer
Lo que más me molesta últimamente son frases que abusan del punto en lugar de la coma
My people lived the other side of this equation. Not the factory floor. The receiving end.Da la impresión de querer añadir peso, pero lo usan incluso donde no hace falta y termina sonando como diálogo de tráiler de película de acción
Éticamente no creo que usar IA sea el problema en sí, pero el estilo de LLM me resultó demasiado irritante
Además, como la gente lo usa para seguir agregando volumen innecesario y relleno al texto, ahora hay que abrirse paso entre páginas y páginas de eso
Y lo peor es que no hay manera fácil de distinguir si un texto al menos se apoya en una idea nueva de una persona o si simplemente es algo completamente generado con un prompt tipo write me something about X
A este nivel, si es lo segundo, no sería exagerado decir que casi no vale la pena leerlo
Me da una sensación parecida a la de un sacerdote que condenaba la homosexualidad y luego lo encuentran en la cama con un prostituto
Lo de la cocaína ya sería opcional, pero igual te deja un sabor amargo
Este texto no tiene muchas de las marcas obvias de IA que suelen mencionarse, y lo único que a mí me parece propio de LLM es la estructura de frases cortas y tajantes
Pero ese estilo también ha sido una forma de escritura bastante prestigiosa en inglés desde Hemingway
Antes, más que la IA, ¿no se veía a los equipos remotos de desarrollo por contrato en Europa del Este como la alternativa barata?
Para empezar, ni siquiera había suficiente gente
Y aquí, al este del meridiano 15° este, al final también nos despidieron a todos
El plan real parecía ser simplemente hacer menos en general si no era algo relacionado con IA, y todos solo esperaban a ver quién empezaba a despedir primero
Yo trabajé medio tiempo durante 6 meses, y quienes tomaban decisiones dijeron claramente que a largo plazo eso era mejor
Era mejor que un despido, pero no podía sostener esa vida por mucho tiempo
Soy austero, pero no tanto
De verdad no quieren gastar dinero y, en particular, todavía menos quieren gastarlo en estadounidenses y seguro médico
Se siente raro que no haya casi freno mientras las empresas estadounidenses avanzan tan rápido por una trayectoria de sacar a los propios estadounidenses del mercado laboral
Como europeo, claro que he visto desarrolladores de Europa del Este, pero no estaban en todas las empresas donde trabajé
En cambio, personal de India siempre había
En cuanto a la calidad, siempre era la misma historia; no la voy a desarrollar, pero creo que quien esté dispuesto a aceptarlo ya sabe a qué me refiero
Si comparo la clase de Formal verification in software que escuché por primera vez a fines de los 80 con la de Programming in Java que dejé a estudiantes de primer ingreso antes de irme a inicios de los 2000, siento que el rigor académico se desplomó por un precipicio y fue reemplazado por la alineación con el empleo
Antes lo que se enseñaba se parecía más a aprender a pensar; después pasó a ser aprender a conseguir un trabajo bien pagado
Porque las empresas ya no querían seguir entrenando a los nuevos empleados
Pagarle a personas en formación cuesta, y también cuesta el tiempo de quien enseña, así que trasladaron ese gasto a universidades, estudiantes y gobiernos mediante los requisitos de título
Es raro que pedirle al empleado que pague su entrenamiento huela a estafa, pero en cambio el sistema de degree mills pase con tanta facilidad
La gente no es perfecta
Cuando fui a Ucrania unos días antes de la invasión rusa, viajar y alojarse en Kyiv era muy barato, y cuando les preguntaba a los locales si veían posible una invasión, todos decían que no iba a pasar
La reacción era que Rusia siempre habla de forma agresiva, pero que en realidad no llega a hacerlo
No estaban suficientemente preparados y, como resultado, en cuestión de días perdieron el 20% del territorio
Después de volver a Austria, me quedó dando vueltas la idea de que algunas de las personas que conocí quizá habían muerto
Más tarde, ya como empresario e ingeniero en Dubai y Saudi Arabia, pregunté qué harían si drones atacaban la infraestructura, y si uno había visto la guerra de Rusia y el primer ataque de Irán, ese tipo de ataques era claramente previsible
Pero otra vez la respuesta fue no va a pasar
No prepararse bien les costó decenas de miles de millones de dólares, aunque creo que con unos cientos de millones durante algunos años podrían haberlo evitado
Al final, el problema no es la IA sino el ser humano
Si no hubiera habido preparación, creo que a estas alturas en Kyiv estaría sentado algún portavoz ruso
Resistieron las primeras 2 semanas y por eso la guerra pasó a ser una guerra larga, y además la guerra en Donbás ya llevaba 8 años
No creo que los ucranianos estuvieran bajo la ilusión de que su adversario no era Rusia
Y muchas veces resulta que tienen un amigo que necesita quedarse con ese contrato, mientras venden el miedo de que si el enemigo ataca, tu familia va a morir de inmediato
Lo único que hiciste fue elegir dos casos donde alguien dijo eso nunca va a pasar y al final sí pasó
¿Qué hacemos con los muchísimos casos en que se dijo lo mismo y efectivamente no pasó nada?
Si a millones de personas que compran lotería les digo que no van a ganar, mi predicción va a ser correcta para casi todos
Que una persona gane no significa que mi predicción haya sido errónea; puede ser simplemente reporting bias
Nadie estaba seguro de que Putin fuera a ser tan estúpido, pero las fuerzas armadas ucranianas estuvieron muy ocupadas preparando líneas defensivas, reservas y tácticas de defensa por si acaso
Cada día siento más importante la idea de Peter Naur sobre programming as theory building
Enlace: https://gwern.net/doc/cs/algorithm/1985-naur.pdf
Es una lectura muy recomendable