Occidente olvidó cómo fabricar cosas, y ahora está olvidando el código
(techtrenches.dev)- El colapso de la capacidad de producción de defensa deja en evidencia que, si se corta la continuidad del personal veterano y del conocimiento de procesos que desaparece con él, no es posible reactivar rápidamente la producción aunque surja demanda en tiempos de guerra
- Los casos de la restauración de Stinger, de los proyectiles de 155 mm y de Fogbank muestran que la optimización de costos y los puntos únicos de falla elevaron la eficiencia en tiempos de paz, pero debilitaron gravemente el margen de la cadena de suministro y la velocidad de recuperación
- El software también se está moviendo por una ruta en la que depende de sustitutos más baratos y debilita el pipeline de talento, y tras la adopción de IA están creciendo al mismo tiempo la reducción de contratación junior y el review bottleneck
- La experiencia no puede crearse rápido solo con dinero, y tanto en defensa como en software la acumulación de conocimiento y pericia requiere años de experiencia en campo y capacidad de revisión
- Si los juniors no pasan por errores formativos y depuración, no acumulan conocimiento tácito, lo que aumenta el riesgo de que en el futuro falten ingenieros senior e institutional knowledge
El paralelismo entre el colapso de la capacidad de producción militar y la reducción de personal en software
- Raytheon tuvo que volver a llamar a ingenieros de más de 70 años para reanudar la producción del Stinger, y reactivar el proceso a partir de viejos planos en papel y equipos de prueba guardados en bodegas
- Después de que el Pentagon 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 los pedidos hechos en mayo de 2022 recién iban a entregarse en 2026
- En apenas 10 meses de guerra se consumió el equivalente a 13 años de producción de Stinger, y la pérdida del conocimiento de producción y los vacíos de personal ya se habían convertido en cuellos de botella
- No era simplemente un problema presupuestal: el obstáculo central fue la estructura en la que se retiró el personal experto sin que hubiera una generación de reemplazo que continuara el trabajo
La fragilidad de la cadena de suministro revelada por el fracaso al aumentar la producción de municiones
-
La promesa de un millón de proyectiles y la capacidad real de producción
- La UE prometió en marzo de 2023 entregar a Ucrania un millón de proyectiles en 12 meses, pero la capacidad anual de producción de Europa rondaba apenas los 230,000, mientras Ucrania consumía entre 5,000 y 7,000 por día
- Para la fecha límite, Europa había entregado aproximadamente la mitad, y una investigación de 11 medios en 9 países estimó que la capacidad real de producción era de apenas un tercio de la cifra oficial afirmada por la UE
- La fecha para alcanzar el millón se recorrió a diciembre de 2024, 9 meses más tarde de lo prometido originalmente
-
Una estructura con varios cuellos de botella superpuestos
- France dejó de producir su propio propelente en 2007 y la actividad permaneció detenida durante 17 años
- El principal centro de producción de TNT en Europa era solo uno, en Poland, y las reservas de municiones de Germany alcanzaban apenas para dos días
- La planta de Nammo en Denmark había cerrado en 2020 y hubo que reiniciarla desde cero
- La industria de defensa europea estaba optimizada para productos personalizados, caros y en bajo volumen, y no había sido diseñada pensando en producción masiva ni en respuesta a crisis
-
EE. UU. tiene debilidades similares
- EE. UU. también dependía de una sola planta en Scranton y de una sola instalación de carga de explosivos 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 Pentagon les dio a los CEOs de defensa el mensaje de que si no se consolidaban, quedarían fuera, 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%
- Surgieron single point of failure a lo largo de toda la cadena de suministro de municiones, y la fabricación de los cuerpos de proyectiles de 155 mm se concentró en una sola empresa en Coachella, California
- Las cargas propulsoras también dependían de una única instalación en Canada, y la optimización enfocada en el costo mínimo aumentó 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 la instalación fuera cerrada
- En 2000 se intentó fabricarlo de nuevo para un programa de extensión de vida útil, pero la mayoría del personal con experiencia en producción ya se había jubilado, había fallecido o se había ido de la institución, y casi no quedaban registros
- Según el material relacionado de la GAO, solo después de gastar 69 millones de dólares adicionales y varios años de ingeniería inversa se logró volver a producir Fogbank utilizable
-
El conocimiento tácito que no estaba en los documentos fue decisivo
- El Fogbank recreado tenía una pureza demasiado alta, 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 aparecía en ningún documento, y solo la conocían los operadores que habían producido el material originalmente, pero para entonces ya se habían retirado
- La razón por la que ni siquiera pudieron volver a crear un material desarrollado por ellos mismos fue que el conocimiento había quedado solo en las personas
El software se está moviendo por la misma ruta
-
Los sustitutos más baratos y rápidos debilitan el pipeline de talento
- El patrón de reemplazar capacidades construidas durante décadas por sustitutos más baratos, debilitar el pipeline humano de talento y luego volver a necesitar esas capacidades en una crisis se repite tanto en defensa como en software
- Si en defensa ese sustituto fue el peace dividend, en software ese lugar lo está ocupando la IA
- El colapso del pipeline de talento y la crisis de comprensión ya eran visibles, y el caso de defensa también muestra cuán largo es el periodo de reconstrucción
-
Reconstruir requiere tiempo más que dinero
- Los grandes aumentos de producción en defensa tomaron entre 3 y 5 años para sistemas simples y entre 5 y 10 años para sistemas complejos
- En el caso del Stinger, el tiempo mínimo entre pedido y entrega era de 30 meses; el Javelin necesitó 4 años y medio para aumentar la producción a menos del doble; y los proyectiles de 155 mm seguían por debajo del objetivo aun después de 4 años y una inversión de 5 mil millones de dólares
- A France también le tomó 17 años retomar la producción de propelente, y la limitación estaba menos en el dinero que en el conocimiento y la pericia
- Un estudio de RAND estimó que el 10% de la habilidad de diseño de submarinos requiere incluso después del PhD una década de experiencia práctica, y los oficios especializados en defensa también necesitaban 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 comprime
- A un desarrollador junior le toma entre 3 y 5 años convertirse en un mid-level sólido, entre 5 y 8 años llegar a senior, y más de 10 años alcanzar nivel principal o architect
- Ese tiempo no se reduce por gastar más dinero, y tampoco parece fácil de comprimir con IA
Los cuellos de botella y el debilitamiento de la pericia tras la adopción de IA
-
El cuello de botella crece más en la revisión que en la velocidad de producción
- En un experimento controlado aleatorio de METR, cuando desarrolladores experimentados usaron herramientas de codificación con IA, el trabajo real en open source tomó 19% más tiempo
- Antes de empezar, se esperaba que la IA permitiera trabajar 24% más rápido, pero la diferencia frente al resultado real fue de 43 puntos porcentuales
- En experimentos posteriores también fue nada menor la proporción de desarrolladores que dijeron que no participarían si tuvieran que trabajar sin IA, y ni siquiera parece fácil imaginar un retorno al trabajo sin IA
-
Reducción de contrataciones y caída en inscripciones universitarias
- Salesforce dijo que en 2025 no hará más contrataciones adicionales de ingenieros de software
- En una encuesta de LeadDev, el 54% de los líderes de ingeniería consideró que los AI copilots reducirán a largo plazo la contratación junior
- Una encuesta de CRA reportó que el 62% de los departamentos universitarios de computación vio una caída en la matrícula este año
-
El code review se convierte en la restricción principal
- La IA genera código con rapidez, pero la revisión humana avanza lentamente, lo que crea un review bottleneck
- En respuesta, se está evitando dejar que una IA revise código de otra IA, y las plantillas de pull request ahora exigen incluir de forma obligatoria qué cambió, por qué cambió, qué tipo de cambio fue y capturas de pantalla de antes y después
- También se están añadiendo revisores dedicados por proyecto para usar más ojos humanos y detectar lo que el modelo pasó por alto
Las capacidades que harán falta en el futuro
-
El entorno está cambiando hacia uno donde la técnica sola no basta
- Ahora ya no basta con la especialidad técnica: también hacen falta criterio y liderazgo para asumir responsabilidad, explicar trade-offs y rechazar propuestas erróneas que la máquina presenta con confianza
- En una contratación reciente, de 2,253 postulantes, 2,069 fueron descartados y solo 4 fueron contratados, lo que dejó una tasa de conversión de 0.18%
- Queda al descubierto la realidad de que casi no hay talento en el mercado que combine capacidad técnica con el 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 expertise de ingeniería, pero no está claro si el mismo mecanismo seguirá funcionando cuando esa expertise desaparezca
- No se puede predecir el desempeño de los modelos en 2031, ni es seguro que la IA llegue a ser lo bastante buena como para causar menos problemas
-
Las crisis llegan sin avisar, y los seniors no se fabrican al instante
- Así como nadie anticipó que en 2022 habría una guerra total en Europa, las crisis no llegan siguiendo un calendario
- Dentro de 5 a 10 años harán falta ingenieros senior capaces de entender todo el sistema, depurar una falla distribuida a las 2 de la mañana y cargar además con el institutional knowledge que existe fuera del codebase
- Pero ese personal no se está formando hoy, y los juniors que deberían estar aprendiendo no están siendo contratados o están acumulando lo que una investigación financiada por el DoD llama AI-mediated competence
- Puede que quede la habilidad de lanzar prompts a la IA, pero no la capacidad de detectar 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 acumulan conocimiento tácito, y cuando la generación actual de ingenieros se retire, ese conocimiento no se transferirá a la IA
- Como resultado, ese conocimiento puede simplemente desaparecer, y esa estructura se parece a lo que pasó con Fogbank
- La guerra en Ucrania fue el momento en que el fracaso de las optimizaciones en defensa se convirtió en un costo real, y Stinger, Javelin, Fogbank y el millón de proyectiles que no pudieron producir muestran ese precio
- La ingeniería de software también está apostando por la misma optimización, y 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