Por qué los desarrolladores humanos siguen siendo mejores que los LLM

• antirez, creador de Redis, usa con frecuencia IA y LLM, pero cree que la capacidad humana de resolver problemas sigue estando muy por delante de la de los LLM en este momento
• Experimentó directamente las limitaciones de los LLM mientras corregía un bug complejo en Redis Vector Sets
• Los algoritmos que sugieren los LLM se quedan en soluciones estándar o simples
• El enfoque creativo de los desarrolladores humanos es más favorable para proponer soluciones innovadoras a las que a los LLM les cuesta llegar
• Los LLM son muy útiles para validar ideas o como interlocutores, pero la creatividad final sigue estando en manos de los humanos

---

Introducción: comparación entre humanos y LLM

• No tengo ningún rechazo hacia la IA y los LLM
• Llevo mucho tiempo usando LLM de forma cotidiana, para probar ideas, revisar código, explorar alternativas y más
• El nivel actual de la IA es claramente práctico y notable, pero subrayo que la brecha con la inteligencia humana sigue siendo grande
• Escribo esto porque últimamente siento aún más la necesidad de decirlo, al punto de que se ha vuelto difícil tener una discusión equilibrada sobre IA

El caso del bug en Redis Vector Sets

• Hace poco estaba corrigiendo un bug relacionado con Vector Sets en Redis
• Como mis colegas de Redis no estaban disponibles, introduje una protección adicional contra corrupción de datos de archivos (RDB/RESTORE)
  • Está desactivada por defecto y funciona como una red de seguridad extra para impedir corrupción incluso si el checksum pasa
• El problema surgió al optimizar la velocidad de serialización en RDB de la representación del grafo de la estructura HNSW
  • El método consistía en guardar como enteros las listas de conexiones entre nodos y restaurarlas como punteros durante la deserialización
  • Debido a características de la propia implementación de HNSW (garantía de conexiones mutuas), si el grafo o la memoria se corrompen pueden ocurrir estos problemas
    • Puede quedar registrado que A está conectado con B, pero que B no esté conectado con A (por error de numeración, etc.)
    • Si se elimina el nodo B, la violación de la conexión mutua puede dejar un enlace A→B, y más adelante, al recorrer B->A, provocar un bug de use-after-free
• Después de cargar los datos, era necesario verificar que todos los enlaces cumplieran la condición de ser "mutuos"
  • Aplicar un algoritmo puro daba una complejidad O(N^2). Con grandes volúmenes de datos (~20 millones de vectores), se confirmó que el tiempo de carga se duplicaba de 45 a 90 segundos

Integración de LLM y sus límites

• Conversé con Gemini 2.5 PRO para preguntarle por un método más eficiente y revisé sus propuestas
  • Primera propuesta del LLM: ordenar la lista de nodos vecinos y aplicar búsqueda binaria (binary search), un método ya muy conocido
  • Como no aportaba una gran mejora, pedí más ideas, pero no obtuve una respuesta mejor
• Mi alternativa fue usar una tabla hash para registrar y eliminar pares de enlaces (A:B:X, ordenados y sin distinguir dirección)
  • El LLM también dijo que era una buena idea, pero señaló como desventajas el rendimiento al generar claves y el costo del hashing
  • Añadí que se podía mejorar la eficiencia procesando claves de longitud fija con memcpy en lugar de snprintf

Creatividad humana vs. límites de los LLM

• Propuse una idea sin tabla hash: aplicar una técnica XOR a un acumulador
  • Se hace XOR de pares de punteros (y de la información de nivel) dentro del acumulador; si la conexión es mutua se cancela (0), y si falta algo queda un patrón residual
  • Eso sí, señalé la posibilidad de colisiones y la predictibilidad de los punteros (el LLM también estuvo de acuerdo en eso)
• Mejora adicional: combinar semilla aleatoria y hashing (murmur-128 y semilla de urandom) y aplicar XOR sobre un acumulador de 128 bits
  • Al final, se determina si la conexión mutua se cumple verificando si el valor del acumulador es 0
  • El LLM evaluó este método como eficiente y también más robusto frente a errores generales y atacantes externos

Conclusión

• Finalmente terminé el análisis para decidir, según su confiabilidad, si convenía adoptarlo o no
• En este caso confirmé que el enfoque creativo y no estándar de un desarrollador humano fue superior a las respuestas limitadas que ofrecía el LLM
• Los LLM son muy útiles para validar ideas y como interlocutor intelectual (cumpliendo el papel de un "pato inteligente")
• Sin embargo, en la capacidad de llegar a una solución creativa final, la ventaja humana sigue siendo clara

[nb13557]

Parece que redis pronto se va a quedar atrás

[aer0700]

Se siente como poner a competir una bicicleta contra alguien corriendo.

[ethanhur]

antirez es un desarrollador humano del 1%. Creo que los desarrolladores humanos del 1% seguirán siendo mejores que los LLM. Pero no sé qué pasará con el 99%.

[spp00]

Varias veces he intentado hacer troubleshooting con IA y todo falló, así que al final terminé resolviendo el problema por mi cuenta.

[softer]

Creo que los LLM parecen de alto nivel y creativos porque fueron entrenados con textos de ese tipo, y porque innumerables científicos verificaron ese conocimiento para mejorar la calidad de los datos de entrenamiento y así elevar sus resultados.

Pero con el tiempo cambian las tendencias o se necesita una creatividad distinta según la situación, así que al final ¿no será que la persona que los usa tiene que ejercer su creatividad de acuerdo con su propio contexto?

[GN⁺]

Opiniones de Hacker News

• Siento que esto coincide exactamente con mi experiencia. De hecho, el gran valor que me da un asistente LLM es que hace el papel de un rubber duck bastante inteligente. A veces ese “duck” incluso rebate mis ideas, y hasta me ayuda a refinarlas mejor. (¿Qué es el rubber duck debugging?) Pero creo que la pregunta clave que todo el mundo quiere saltarse es: “¿este valor seguirá existiendo dentro de 2 años?”. Yo tampoco sé la respuesta

  • Para mí, un LLM no es un rubber duck, sino una especie de “generador de respuestas incorrectas”. Dicen que la mejor forma de obtener una respuesta en internet es publicar una respuesta equivocada, y para mí cumple justo ese papel. Le pido al LLM tareas simples pero tediosas, y entrega resultados tan terriblemente mal hechos que termino irritándome y, con pura fuerza de rabia, lo hago yo mismo

  • Hace de duck excesivamente seguro de sí mismo; muestra mucha más confianza de la que realmente justifica su capacidad. He visto a demasiada gente perderse hablando con un LLM

  • Para mí, un LLM se parece a un desarrollador junior que trabaja conmigo, que conoce bien las APIs pero carece de sentido común en arquitectura. Reviso la mayoría de los PR unas 3 o 4 veces, preocupado por errores absurdos, antes siquiera de pasarlos a revisión del equipo. Aun así, está bien porque me permite dedicar mi cerebro a otros problemas

  • ¿Que si ese valor seguirá dentro de 2 años? Para mí, más que el problema de “quiero pasar de esta conversación”, me preocupa más “¿de aquí a 2 años siquiera llegaremos hasta ese punto?”. El mundo actual es tan inestable que ni siquiera se puede predecir cómo será en 6 meses

  • Para mí, un LLM se siente como un compañero de programación en pareja. Es alguien con quien puedo hablar ideas, que me ofrece revisión de código y alternativas. Y también puedo aprender porque usa funciones que yo no conocía

• Viendo esta sección de comentarios, siento que hay cierta expectativa puesta en frases como “los humanos son indispensables”, “los LLM no saben depurar”, “los LLM te llevan por mal camino”. Claro, es verdad, pero la generación automática de código, que hace 2 años era imposible, ha mejorado muchísimo y sigue avanzando a gran velocidad. Puede que en adelante el ritmo de mejora se desacelere, como en una especie de “ley de Pareto”, pero sin duda va a seguir progresando. Hace poco, en r/fpga, conté que logré usar un LLM para crear la primera versión de un testbench, y me sorprendió muchísimo ver a gente que ni siquiera lo había intentado descartar por completo esa posibilidad

  • Esta actitud es muy común entre profesionales. También pasé por /r/law y sentí ese reflejo de desdén instantáneo al escuchar las declaraciones de Dario Amodei sobre IA en el ámbito legal. Quizá sea un mecanismo de adaptación o una forma de conformarse con la realidad, pero creo que es algo muy malo para la capacidad futura de responder a cambios económicos y sociales

  • Se parece a cuando la programación era principalmente ensamblador y, al aparecer los lenguajes de programación, muchos programadores se burlaban de ellos como ineficientes, poco flexibles y demasiado simplificados, aunque eso tuviera poco que ver con la realidad. Es una reacción natural que tiene poco que ver con el valor real de una nueva tecnología

  • Da la impresión de que los LLM tuvieron un crecimiento explosivo por un tiempo, pero últimamente los modelos incluso parecen haber retrocedido. Dan buenos resultados generando tests, pero si se usan demasiado a fondo en tareas como implementar funciones nuevas, empiezan a comportarse raro. Funcionan bien para proyectos nuevos o webapps sencillas, pero no son tan efectivos para refactorizar código grande o legado ni para agregar funciones. Por ejemplo, veo con frecuencia a Claude o ChatGPT inventarse por completo la API de D3

  • Al final, tú mismo estás construyendo a tu reemplazo, mientras tus colegas avanzan con cautela

  • ChatGPT-4o muestra una capacidad impresionante para escribir VHDL. Hoy mismo sigo viendo resultados sorprendentes al usarlo para prototipar controladores de bajo nivel

• El contexto necesario para escribir software real de verdad es demasiado amplio para un LLM. El software es, en esencia, “el negocio codificado”. ¿Cómo va a saber un LLM todas las condiciones especiales que ventas prometió a clientes o las reglas implícitas de cada departamento? Lo que los LLM pueden resolver hoy es algo general y limitado. En cuanto hay más de dos clases o más de 20 o 30 archivos, incluso los mejores LLM empiezan a perderse y a desenfocarse. Como no mantienen bien el contexto, generan code churn innecesario. Para que un LLM realmente reemplace a un desarrollador real, tendría que absorber muchísimo más contexto, reunir contexto de toda la organización y mantener un hilo de pensamiento en proyectos de larga duración. Cuando esos problemas de verdad estén encaminados a resolverse, recién ahí voy a empezar a preocuparme en serio

  • Recomiendo probar la ventana de contexto de 1M de Gemini 2.5 Pro. Incluso metiendo toda la base de código de mi pequeño proyecto ETL (100 mil tokens), da resultados bastante decentes. No es perfecto, pero es una buena señal del cambio de época

• Cada vez que se discute si los LLM van a reemplazar a los desarrolladores, todos olvidan algo: en la ingeniería de software real hay muchísimo trabajo aparte de escribir código. De hecho, escribir código es una parte pequeña. Lo importante son las habilidades sociales, el análisis de requisitos y descubrir lo que realmente quería el cliente, porque ni el propio cliente suele saber bien qué quiere, y al ingeniero le toca averiguarlo. Si eso ya es difícil para un humano, no hay forma de que un LLM lo haga

  • Al final, esto es un problema de bucle de retroalimentación: un proceso de iteración inmediata donde el cliente usa el producto de verdad y da su opinión. La UI de chat es excelente para ese ciclo de feedback, y los agentes generan nuevas versiones con rapidez. Los LLM sí pueden encargarse de abstracciones, sistemas con múltiples componentes, diseño de la estructura general y hasta análisis de requisitos. La clave es qué tan rápido puede iterarse. La robustez y el IQ de los modelos siguen mejorando. Toda la ingeniería de software ya entró en una etapa de automatización. Probablemente en 5 años, los humanos sin asistencia serán un enorme cuello de botella. Si no te integras profundamente con la IA, inevitablemente te vas a quedar atrás

  • Este era exactamente el problema durante la ola de offshoring de los 2000. Los equipos en el extranjero tenían dificultades para pedir cambios o plantear problemas, así que solo hacían lo que se les pedía, y al final todo se iba acumulando. Creo que con la IA va a pasar algo parecido. Y probablemente el resultado también será similar

  • Un LLM, para empezar, no hace ingeniería de software como tal. Pero ese no es necesariamente el problema. En la práctica, muchos programas exitosos funcionan bien incluso sin “ingeniería de software”. Más aún en entornos donde nadie se preocupa por la estructura de costos de la nube. Más bien, creo que en el futuro gente con sensibilidad técnica, como socios de negocio de IT, va a poder hacer apps completas sin ayuda de ingenieros de software. En la industria de energía verde eso ya pasa todos los días. Pero el problema explota cuando hace falta mantenimiento, escalabilidad y eficiencia. Ahí recién importan cosas como “usar una lista o un generador en Python”, y es justo el punto donde hace falta ingeniería real

  • En 5 años puede que casi ya no diseñemos código. Ya hoy escribo muchísimo menos código a mano que hace 1 año. Pero eso sigue siendo solo una parte del proceso; no significa que los desarrolladores vayan a desaparecer

  • Por otro lado, el rol del simple “coder” sí está siendo bastante reemplazado. Ese es justamente el terreno donde los LLM destacan. Hay muchos coders sin criterio que solo miran tickets del tipo “recibe esta API y devuelve este valor”, sin hacer ningún esfuerzo por entender requisitos o análisis del cliente, y ahí los LLM están avanzando rápido. La ingeniería de software de verdad es otra cosa completamente distinta, pero no hay que ignorar que la demanda de coders simples era enorme

• Un punto muy importante es que solo los humanos tienen la capacidad de manejar conceptos abstractos del programa y resolver problemas de forma creativa. Un programador es un arquitecto de la lógica, y la computadora es lo que convierte el pensamiento humano en instrucciones. Las herramientas pueden imitar al ser humano y generar código para tareas concretas, pero no pueden reemplazar el papel fundamental de abstracción, diseño y construcción. Si los modelos llegan a tener la capacidad no solo de escribir código, sino de crear proyectos completos a partir de una especificación, entonces el rol del desarrollador volverá a cambiar

• Siempre hay que partir de la idea de que “qué es mejor” depende de la tarea. Los LLM ya son mucho mejores que yo en trabajo repetitivo y regido por fórmulas, como acertar la sintaxis de CSS o recordar cómo invocar librerías conocidas. Antes estos “eventos diversos” me consumían muchísimo tiempo, y ahora se resuelven casi al instante, lo cual me deja muy satisfecho

  • Para el styling más fundamental (más allá del CSS básico), los resultados del LLM más bien son malos. Cuando cuesta explicar claramente el efecto deseado o el trabajo se vuelve sutil, con mucha frecuencia no logra el resultado más importante y se queda atascado en una sola forma de hacerlo

  • En lo que se me da mal (SQL), el LLM es mucho mejor que yo, pero en lo que sí conozco bien (CSS), en realidad es peor. Ahí se ve clarísimo el criterio

  • Estoy de acuerdo con eso de que “es mejor que la mayoría de los desarrolladores” y con la idea de que parece mejor porque mucha gente no sabe CSS. En realidad, es un malentendido que surge porque mucha gente odia CSS, no lo aprende y solo lo usa a la fuerza. Si una empresa quiere ahorrarse contratar a un verdadero experto en CSS, entonces el LLM puede ser una alternativa; si tiene recursos para conseguir a alguien realmente bueno, obviamente no hay comparación posible con un LLM. Al final, el verdadero competidor del LLM es el desarrollador malo

  • El autocompletado del LLM ayuda mucho en lenguajes principales o áreas que uno no domina con precisión. Pero si no desarrollas esa capacidad de “recordar de forma refleja” y dependes solo del LLM, corres el riesgo de no tener criterio para evaluar lo que recomienda esta herramienta y quedarte con soluciones deficientes

• Me alegra que tanta gente se preocupe por el “buen código”, pero me da miedo que en la práctica eso no signifique nada. La industria del software ya fue absorbida por el mundo de los negocios desde hace mucho tiempo, y ni siquiera estoy seguro de desde cuándo exactamente (¿desde la carta abierta de Bill Gates en 1976?). El problema real es que a accionistas y ejecutivos cada vez les importa menos el código mientras suban las ganancias. Si no hay resistencia cultural por parte de desarrolladores y usuarios, esta estructura va a seguir así

  • Sobre eso de que sin resistencia cultural de desarrolladores y usuarios ya todo está perdido, quiero decir que sí hay empresas que hacen buen código y que no todo es un desastre. El problema no es la calidad del código, sino una cuestión ética: si estás de acuerdo o no con los objetivos de negocio capitalistas. Lo más importante es equilibrar el software hermoso con la realidad. Yo también soy desarrollador y fundador, me gusta el open source y la ingeniería, pero al mismo tiempo quiero vivir con suficiente comodidad

  • El código es el motor del negocio. El mal código termina en malos negocios. Hay una diferencia muy clara entre los equipos de hosting (firewalls físicos, vmware, proxies, etc.) y la nube pública (QEMU, netfilter, hardware básico, etc.). Quién absorbió a quién, y qué traerá el futuro, nadie lo puede predecir

• Anoche perdí todo el tiempo peleándome con o3. En mi vida había hecho un Dockerfile, así que preferí darle a o3 el repositorio de GitHub para que lo resolviera automáticamente, pero terminé desperdiciando horas depurando el resultado. Le agregaba cosas que ni existían, borraba otras que no estaban, mezclaba todo, y hasta confundía conceptos básicos como la diferencia entre python3 y python. Al final me harté, busqué la documentación de Google y lo resolví rápido. La lección es que la IA también es una gran herramienta, pero no es omnipotente, y alguien tiene que mantenerse “despierto” sí o sí

  • Tip: te recomiendo usar Claude o Gemini. En tareas de programación alucinan mucho menos. O también puedes activar en o3 la opción de búsqueda en internet para mejorar su capacidad de consultar documentación online. Adaptarse toma tiempo, así que no hay que esperar que sea magia; la curva de aprendizaje para usarlo bien es alta, y en eso se parece a otras herramientas de desarrollo como vim/emacs. Y en ChatGPT también, si presionas el “botón del globo”, aprovecha mejor la búsqueda en internet

• Las empresas que usan LLM/IA para aumentar la productividad de sus empleados van a prosperar; las que intenten reemplazar por completo a sus empleados van a fracasar. A corto plazo, puede que CEOs y ejecutivos queden satisfechos con resultados inmediatos mientras se comen el crecimiento futuro

  • Exactamente eso. Lo correcto es usar LLM como asistente del programador; un reemplazo total no es realista. Adoptar la tecnología con moderación es el camino correcto

  • La idea de que reemplazar empleados podría aumentar el valor a corto plazo y beneficiar a la empresa me parece bastante interesante. O sea, a mediano y largo plazo podría perjudicarla, pero temporalmente sí podría hacer subir la acción

  • Los asistentes de código son una herramienta común indispensable, no un arma para reemplazar personas. En una época donde la competencia también puede pagar la misma suscripción de IA, no puedes reemplazar a la gente con eso

• Comparto experiencia de campo: antes era desarrollador y ahora soy gerente, pero sigo escribiendo código. Los asistentes LLM ayudan, pero a veces también incomodan. Cuando empiezan a soltar sugerencias de código inesperadas, uno puede terminar yendo en una dirección distinta a la intención original, y además se pierde tiempo revisándolas. Tal vez sea un tema de configuración, pero me gustaría cambiar el valor por defecto para que solo aparezcan cuando yo los invoque explícitamente. Hay algo que sí tengo claro: aunque deje que el LLM escriba código completo o funciones enteras, siempre pasa por mi proceso de revisión

  • El editor Zed tiene una función así, un modo de “sugerencias sutiles” (ver más). Ojalá todos los editores ofrecieran un modo así

  • Últimamente, como me toca hacer de todo en una startup, no me gusta mucho la UI que generan los LLM. Los bloques básicos tipo building blocks sí son útiles, pero si le dejas a Claude bloques largos de código completos, hace falta muchísimo retrabajo antes de llegar al resultado que yo quiero

[redcrash0721]

https://freederia.com coexistirá manteniendo una relación de convivencia como en el sitio de científicos de IA.