El eterno Sloptember

• Los agentes de IA no realizan programación tanto como imitan la distribución de la programación, y sus salidas rotas se vuelven cada vez más difíciles de reconocer
• Se usaron para escribir parte de tinygrad y hacer ingeniería inversa de un chip USB <-> PCIe, pero queda la duda de si hacerlo manualmente habría sido mejor y más rápido
• Los agentes aceleran el avance inicial, pero en la etapa final te hacen depender de intentos repetidos como si tiraras de la palanca de una tragamonedas, sin lograr llegar hasta el final
• Las organizaciones grandes pueden sufrir un daño de calidad mayor que las personas de alto rendimiento, por sus bucles de retroalimentación lentos y una producción 10x sin autoevaluación
• La IA es útil para búsquedas y prototipos rápidos, pero cuesta verla como un verdadero ingeniero de software, y lo clave es saber cuándo usarla y cuándo no

---

Críticas centrales a los agentes de IA

• La tendencia de introducir agentes de IA en el desarrollo de software puede terminar siendo un error muy costoso, y estos agentes se parecen más a modelos estadísticos sofisticados que imitan la distribución de la programación, no a la programación en sí
• Sus resultados están rotos, pero de formas cada vez más difíciles de detectar, y cuanto más precisos se vuelven los modelos estadísticos, más difícil es notar esos problemas
• Durante los últimos 6 meses se usaron agentes para escribir parte de tinygrad y hacer ingeniería inversa de un chip USB <-> PCIe, pero sigue la sospecha de que hacerlo directamente habría sido mejor y más rápido
• Los agentes adelantan el progreso al principio, pero en la fase de cierre hacen que uno espere repetidamente que el resultado mejore, como si estuviera tirando de la palanca de una tragamonedas, sin conseguir llegar al final
• Como se probaron varios modelos, harnesses y prompts, la objeción de que “se usó mal” resulta poco convincente, y se parece a decir que se puede ganar en una tragamonedas si apuestas de cierta manera
• La IA en sí es útil: en muchas búsquedas funciona como un Google mejorado, y para prototipos rápidos donde no importa demasiado el acabado final, es muy veloz
• Aun así, cuesta verla como un verdadero ingeniero de software, ni siquiera cercana al estándar de cualquiera de las empresas con las que se ha trabajado; la clave está en saber cuándo usarla y cuándo no

Impacto en las organizaciones y la calidad

• AFL encontró más bugs que los LLM, pero los desarrolladores no temieron perder estatus, y como el ajedrez y el Go también se volvieron más populares después de la IA, no convence ver toda crítica a la IA solo como ansiedad por estatus
• La idea de un futuro donde asistentes robóticos confiables ordenen el código resulta atractiva, pero parece que el miedo a la pérdida se está usando para vender agentes de la manera necesaria para mover a las grandes empresas
• Las organizaciones grandes tienen más probabilidades de sufrir un daño mayor con los agentes que las personas de alto rendimiento o las organizaciones pequeñas
  • Las personas de alto rendimiento pueden corregir errores, suelen notar cuando el resultado es flojo y, salvo en ámbitos muy acotados, mantienen la práctica de leer y entender con cuidado cada línea
  • Las organizaciones grandes tienen bucles de retroalimentación lentos y una alineación débil, así que cuando personas de bajo desempeño producen 10x más con agentes sin autoevaluación, la calidad promedio del resultado puede bajar
• Los agentes producirán más código, más apps y más funcionalidades que antes, pero podría ser una era donde se acumulen grandes cantidades de resultados descuidados en lugar de gemas de alta calidad
• La idea de que Apple está empujando el uso de IA a todos sus ingenieros debería verse no como una expectativa abstracta, sino como una pregunta concreta tipo “si macOS será mejor o peor dentro de los próximos 2 años”
• La gente asume implícitamente que detrás de una obra hubo un estado mental y un proceso humanos, pero en los resultados de IA esa suposición ya no se sostiene
• Elementos que antes servían como indicadores indirectos de calidad, como la gramática o la sintaxis, pierden utilidad frente a resultados de IA, y la diferencia aparece cuando uno interactúa con ellos de forma humana o construye algo encima
• Respecto a los LLM, la postura se ha acercado más al lado de LeCun/Marcus, llegando a la conclusión de que estos modelos no pueden programar y de que el proceso es lo importante
• El deep learning todavía puede ser la solución, pero para agentes de programación reales hace falta un modelo del mundo, no RLVR del tipo que comenta las pruebas que fallan y luego dice que todas pasaron
• La clave de esta época podría ser quién logra resistir sin dañarse a sí mismo en medio del sobrecalentamiento colectivo en torno a la IA

[GN⁺]

Comentarios de Hacker News

• El gran problema del discurso actual es que es demasiado de blanco o negro. Si desconfías de los LLM eres un ludita, y si crees en ellos estás “ai pilled”
  En la mayoría de los casos, los LLM te llevan al 80~95%, y a veces rinden peor o mejor que eso. De vez en cuando te llevan a un lugar completamente equivocado
  Pero todos parecen pelear solo por si un LLM puede convertirse por sí solo en un ingeniero de software perfecto dentro de un clóset, y con base en eso niegan incluso el enorme potencial que tendría en otros escenarios
  Si piensas en cuánto más productivas podrían haber sido la mayoría de las organizaciones solo con lo que les dio internet, muchas empresas reales ni siquiera logran una pequeña fracción de lo que sería posible. Veo a los LLM desde esa misma perspectiva
  La culpa no es del modelo de lenguaje, sino nuestra

  • Cuanto más aprendo sobre los verdaderos luditas, más entiendo su punto de vista
    Originalmente, los luditas protestaban sobre todo contra máquinas que producían mercancía de mala calidad de forma “fraudulenta y engañosa”, eludían estándares laborales y arrebataban el sustento a artesanos calificados
  • Hay demasiado dinero en juego para que esto pueda ser una discusión racional
  • El texto apunta en particular a los agentes: “Introducir agentes de IA en el desarrollo de software será uno de los errores más costosos en la historia de este campo”
    Yo no uso agentes; construyo software a nivel de funciones mediante una interfaz de chat simple y conversaciones continuas. El flujo de trabajo resultante es bastante “quimérico” y se beneficia mucho de mi experiencia y especialización. El LLM solo hace que el proceso sea más fluido
    En mi caso funciona bien y no quisiera volver atrás
  • El punto de geohot parece parecido. No se trata de volverse completamente “ai pilled”, ni tampoco de ser ludita, sino más bien de usar la IA como herramienta
  • Los luditas no eran simples “incrédulos”, sino activistas violentos
    En el discurso actual, a quienes llaman “luditas” suelen ser personas que se atreven a cuestionar la exageración alrededor de la “IA”. Normalmente ni siquiera son activistas

• Con el nivel actual de capacidad de la IA, personalmente me ha resultado útil verla como una búsqueda muy buena que opera sobre conocimiento existente. Parece el siguiente paso en la capacidad de búsqueda que va de los manuales de referencia a Stack Overflow y GitHub
  Los programadores reutilizan y reinventan las mismas técnicas con más frecuencia que casi cualquier otra profesión que se me ocurra, así que estaban especialmente bien posicionados para una herramienta que buscara muy bien el arte previo. Que la IA pueda adaptar ese arte previo a un caso de uso específico la hace aún más poderosa
  Pero, igual que unir fragmentos de código copiados de Stack Overflow no produce grandes éxitos, la IA actual tampoco puede construir bien un proyecto completo

  • Está quedando claro que la respuesta no es empaquetar todo perfectamente en bibliotecas reutilizables, sino una herramienta que reduzca el costo de volver a usar y reinventar
  • Estoy 100% de acuerdo en que la IA actual se parece más a una versión potenciada de Stack Overflow y Google. En mi experiencia, salvo por el esqueleto inicial, no construye bien aplicaciones completas a gran escala
    Si se trata de una base de código heredada, vieja y no muy usada, por ejemplo sí podrías hacer que un agente de IA leyera el código para responder algo como “¿cómo hace la aplicación X para hacer Y?”. Pero no le dejaría generar funciones a lo loco ni encargarle refactorizaciones
    Hacer eso produciría demasiados commits y confundiría al equipo de desarrollo, con muchas probabilidades de terminar peor que el revoltijo que ya estaban manejando. Últimamente me he sentido algo decepcionado con la IA, y esta explicación resume bien mi experiencia
  • “La IA puede adaptar el arte previo a un caso de uso específico” es, de todos modos, lo que todos afirman

• Lo más difícil en la ingeniería de software es resolver el problema correcto. Creo que la capacidad de identificar qué problema hay que resolver es lo que distingue a los ingenieros senior de alto nivel
  Simplificándolo, aquí diría que es el problema cuya solución aporta más valor al producto en comparación con su complejidad y sus costos colaterales
  Hace mucho trabajé en un producto web donde un diseñador junior pensó que sería genial que el backend pudiera administrarse con herramientas LDAP. Entonces el esquema y la estructura de la base de datos del producto imitaban a OpenLDAP y usaban claves CN compuestas, y toda la base de código tenía que lidiar con esa estructura cada vez que leía o escribía en la BD. Al diseñar el esquema de la BD, la compatibilidad con LDAP no era el problema correcto que había que resolver
  El software que resuelve el problema correcto puede ser difícil de identificar. Normalmente es porque la forma en que funciona parece tan obvia que no se nota que se pudo haber elegido otro diseño
  Lo que suele limitar, con el tiempo, el radio de explosión de un diseño que resuelve el problema equivocado es la fricción que ese diseño genera. El desarrollo se vuelve más lento, y también se vuelve más lento el desarrollo que sigue resolviendo más problemas equivocados. Es un fenómeno autolimitante
  Eso es precisamente lo que más me preocupa de los agentes de programación con LLM. Tapan esa fricción. No la corrigen; solo difieren el costo
  Así terminas con bases de código cuya complejidad crece sin límite respecto al valor que aportan, y sin ningún mecanismo para controlarlo
  Los juniors dejarán de pasar por los ciclos de retroalimentación que desarrollan el criterio y el gusto ingenieril necesarios para juzgar qué problemas son los correctos de resolver dentro de un diseño determinado
  A escala de toda la industria, incluso podríamos olvidar que alguna vez existió el concepto mismo de resolver el problema correcto
  No sé qué habría que hacer. Tal vez debería empezar a planear una jubilación anticipada

• Hay gente que ahora mismo compra péptidos del mercado gris y se inyecta sustancias etiquetadas como “no apto para consumo humano” basándose solo en anécdotas dudosas y corazonadas, con la idea de aclarar la piel o aumentar la masa muscular
  ¿De pronto se están convirtiendo todos en zombis? No. ¿Saben realmente qué le va a pasar a su cuerpo dentro de algunos años? Tampoco. ¿Podría ser catastrófico? Podría serlo
  Pensé en esa analogía al ver cómo, en los últimos seis meses más o menos, la industria giró con fuerza hacia usar IA como generador principal de código. La IA es el péptido y la base de código es el cuerpo. Literalmente nadie sabe qué tan mantenible es este enfoque, porque todavía no ha pasado suficiente tiempo para averiguarlo
  Puede que esté bien, o puede que termine siendo un caos total. Todo un equipo de ingeniería podría soltar el volante y quedarse dormido, creyendo que entiende lo que está construyendo cuando en realidad no lo entiende, hasta que llegue el punto en que el LLM ya no pueda con ello y entonces ya no quede capacidad real para arreglarlo ni mantenerlo
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  En mi base de código personal, ya no lo hago así a menos que de verdad no me importe la mantenibilidad o la vida útil

  • Los desarrolladores inteligentes probablemente harán módulos aislados. Así, si un módulo hecho por IA sigue fallando, se puede amputar y volver a crear

• Ahora mismo estoy más del lado de “hace tiempo que no escribo código directamente”. Me gustaría ver un ejemplo donde el problema sea lo bastante grande como para volver a programar manualmente
  Mi principal problema es que la calidad sube y baja con cada lanzamiento de modelo, y sobre todo en herramientas de línea de comandos tienden a meter APIs o documentación desactualizadas
  Entiendo que al modelo le cueste con una base de código monolítica de un millón de líneas con diez años de mugre acumulada. Pero no se me ocurre por qué tendría que ser tan doloroso en una base de código nueva

  • Ni siquiera tiene que ser un problema “demasiado grande”. También puede ser algo tan pequeño que no valga la pena usarlo
    Programar no es tan difícil, así que muchas veces simplemente es más fácil programar que leer y escribir inglés. Aunque quizá estoy sesgado porque solo uso Haskell
  • ¿Cuánto tiempo crees que puede durar ese estado de “no haber escrito código directamente por un tiempo” antes de que, por falta de práctica, ya no puedas hacerlo?
    Uno de los riesgos de la gestión de ingeniería es que puede convertirte en alguien que ya no puede hacer ese trabajo
    ¿Importa realmente?
  • Si cada prompt produce un PR de mil líneas, no estamos tan lejos de otra estructura monolítica de un millón de líneas
    Aun así, soy un poco más optimista que el autor. Siento que es posible gestionar el proceso para evitar que eso pase
  • Hubo un ejemplo que estuvo en la portada hace poco: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • Importa qué tipo de proyecto estás haciendo. En particular, cuánto hay de novedad, de datos difíciles de encontrar por búsqueda, y de diferencias no triviales específicas del proyecto que se salen de los estándares de la industria

• Los entornos de ejecución para agentes apenas llevan algo más de un año, y solo desde hace como seis meses se han vuelto bastante confiables, pero ya hay un cansancio fuerte. Creo que esto muestra mejor el desgaste mental de la programación asistida por IA que la pregunta de si los LLM realmente pueden programar
  Para seguir bien lo que un agente le está haciendo a la base de código, la frecuencia de toma de decisiones se dispara y hay que leer una cantidad astronómica de código y prosa
  Este cansancio personal y psicológico, y las emociones negativas asociadas, se están trasladando de forma imprecisa a una visión pesimista sobre el potencial de avance de la tecnología en sí

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • La tecnología no existe separada de cómo la usa la gente
    Si todos los que la usan bien terminan frustrados, y a quienes les gusta producen montañas de revoltijo imposible de mantener, pronto la vamos a tirar al basurero de la historia
    Hay muchas cosas con “potencial” que al final no llegan a ser nada
    Voy a seguir usando LLM, pero creo que la utilidad de la programación con agentes ya alcanzó su punto máximo

• Parte de mi trabajo es encontrar maneras de hacer que estos modelos sean productivos en la gran empresa donde trabajo. Se parece más a lanzar tomates contra la pared, y hasta cierto punto veo un problema parecido al que él menciona: parece que la salida tiene ciertos límites específicos.
  Al mismo tiempo, en ningún lugar de su texto hay un fragmento de código o algo concreto a lo que uno pueda aferrarse y decir: “aquí el modelo lo hizo fatal y en realidad debió haber hecho esto”. Esta forma de crítica parece un patrón que se repite en posts de blog y en Twitter del tipo “los LLM nunca sirven”.
  Los modelos claramente hacen más que autocompletar, y también en mi desarrollo cotidiano generan grandes partes de una base de código que bien podría haber hecho un ingeniero junior o semi-senior.
  Si nadie cita de forma concreta qué errores cometen realmente, ¿cómo se supone que vamos a entender su capacidad real?

  • Los errores que cometen los LLM son bastante sutiles. Programar con LLM es como una escena de la película Whiplash. Es algo como: “ese no es mi tempo”, “downbeat en el compás 18”, “vas rápido”, “lento”.
    Casi siempre producen código que funciona y por lo general hacen lo que se les pidió. Pero se equivocan un poco de maneras increíblemente frustrantes, al punto de darte ganas de lanzar una silla. Además, ni siquiera tienen el criterio para darse cuenta de qué salió mal y cómo salió mal.
  • Cuando la gente escribe posts de blog sobre cómo los LLM fallaron en una tarea específica, la reacción de los defensores casi siempre va por “usa otro modelo”, “cambia el prompt así”, “te faltan habilidades; no puedes hacer una afirmación fundamental sobre la IA a partir de un ejemplo específico”.
    Entonces no sirve dar ejemplos concretos, pero tampoco sirve no darlos. En ese caso, el juego ya está arreglado.
    Sé que estoy cometiendo un error de atribución grupal, pero igual lo digo.
  • Este punto es excelente. Incluso desde la perspectiva de un principiante que, gracias a los LLM, está haciendo proyectos que antes ni soñaba, uno termina buscando ejemplos y evidencia sobre qué escribió mal exactamente el agente y cómo lo habría hecho mejor un humano.
    Seguro que ese material existe, así que si alguien conoce contenido que muestre buenos ejemplos, me gustaría que lo compartiera.
    No dudo que el porcentaje más alto de programadores pueda escribir mucho mejor que Claude o Codex. Pero sí me da curiosidad cuánto peor son los modelos que un desarrollador promedio y común.
  • Este post trata ejemplos bastante detallados, incluso con fragmentos de código que muestran mala arquitectura: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• Mi impresión es que los modelos van a seguir mejorando.
  Cuando empecé con la programación tipo agente hace uno o dos años, estaba convencido de que solo servía al nivel de autocompletado. A comienzos de este año pasó algo y los modelos llegaron a un nuevo nivel de capacidad.
  Ahora todos los que conozco están haciendo programación tipo agente, y la verdad es sorprendente. Creo que hay que empujarlo hasta donde dé. Se siente como si la aceleración de la humanidad estuviera justo enfrente.

  • Ya estamos topándonos con algunos límites logísticos. Aunque no haya una meseta intrínseca de capacidad en los Transformer, las GPU y la energía disponibles para mejorar son limitadas, y están teniendo grandes dificultades para expandir esa infraestructura.
    En los últimos dos años se anunciaron unos 6 GW de nuevos centros de datos, pero en realidad menos de 1 GW se ha encendido y ha empezado a operar. Las fechas de entrega del resto se siguen retrasando.
    Además, los centros de datos hablan como si los chips que tienen dentro fueran a durar seis años, pero también está quedando claro que eso es poco realista.
  • ¿Y si estamos acelerando directo hacia una pared?
  • “La aceleración de la humanidad” es la mayor autoindulgencia que he visto este año.
  • Sí, pasó algo. Mejoraron para autocompletar. ¿Qué más sería? El modelo base no cambió.
    Ojalá dejen de hablar de cosas como “la aceleración de la humanidad”. Nadie está resolviendo con LLM el cáncer, el cambio climático, la desigualdad ni otros problemas reales importantes.
    Si esta tecnología es lo bastante buena como para aumentar tu productividad, es porque no estás haciendo nada nuevo, de punta o innovador. La única razón por la que un LLM sabe hacer tu trabajo es que ese código ya fue escrito literalmente suficientes veces como para aparecer en abundancia en los datos de entrenamiento.
    Intenta escribir con un LLM en C++26, HDL o en un stack muy de nicho, y será una buena dosis de realidad.

• No es que AFL haya encontrado más vulnerabilidades que un LLM. AFL y profesionales experimentados fueron quienes encontraron las vulnerabilidades.
  AFL provoca fallos, y una parte importante o incluso la mayoría de ellos no son explotables. Un humano, y ahora un agente, tiene que filtrarlos y evaluarlos.
  Además, ese trabajo se hizo sobre un corpus de software sin seguridad de memoria previo a AFL. La época dorada de AFL fue hace diez años, y ahora todos los objetivos son más difíciles.

• Para dar más contexto, el autor es George “geohot” Hotz. Tiene un largo historial de exploits, y probablemente sea más conocido por haber creado comma.ai para autos autónomos casi como si fuera vibe coding real, con poco presupuesto, mucho antes de que apareciera el vibe coding con IA.
  https://en.wikipedia.org/wiki/George_Hotz