Por qué decidí reducir mi uso de los LLM
(zed.dev)- Alberto Fortin, ingeniero de software con 15 años de experiencia, tenía grandes expectativas sobre la adopción de LLM (modelos de lenguaje de gran tamaño), pero en un entorno de producción terminó experimentando varias limitaciones
- Durante el proceso de reconstrucción de una infraestructura basada en Go y ClickHouse, comprobó tanto las promesas como las limitaciones de la IA, y sintió que incluso con las mejoras del modelo seguían sin resolverse los problemas centrales
- Señala que existe una ilusión en torno al aumento de productividad, cuando en la práctica en realidad aumentan los bugs y los problemas inesperados
- Enfatiza la lección de ver al LLM como un asistente (assistant), y que el diseño y las decisiones clave deben seguir en manos del desarrollador
- "La IA es innovadora, pero todavía no es completa, así que hace falta un uso equilibrado y una visión sobria de la realidad"
La experiencia y reflexión de Alberto Fortin con los LLM
- Alberto Fortin, ingeniero de software con 15 años de experiencia, adoptó activamente los LLM en su trabajo de desarrollo con grandes expectativas
- Durante la reconstrucción de infraestructura usando Go y ClickHouse, se topó con múltiples desafíos y límites, lo que lo llevó a escribir una entrada de blog sobre la brecha entre la IA y el desarrollo real
- Después, mediante un análisis adicional reciente, evaluó si modelos más nuevos como Claude Opus 4 habían resuelto estos problemas
- La experiencia de Alberto ofrece a los ingenieros que están considerando incorporar LLM en entornos reales lecciones prácticas, además de una visión realista sobre en qué partes la herramienta aporta valor y hasta dónde llegan sus límites
Principales citas de Alberto sobre su experiencia con los LLM
"De verdad me sorprendió que no fuera solo un problema de fallas o de funciones que no corrían. Como desarrollador que va a mantener este código durante los próximos años, el código debe estar lo suficientemente limpio."
"Parecía que el problema se iba a resolver pronto, pero al final volvía a aparecer otro error nuevo, y la experiencia de tardar otras dos semanas más en resolverlo se repitió una y otra vez."
"Si le pasas la salida del error al LLM, te da una nueva respuesta, pero muy seguido termina enredando algo más o rompiendo otra parte del sistema."
Reconocer las expectativas excesivas sobre los LLM
"Cuando usas por primera vez pequeñas funciones como el autocompletado inicial, todos los desarrolladores se sorprenden. Parece como si leyera mis pensamientos, y eso hace que las expectativas se inflen."
"Empieza a parecer que la productividad en desarrollo podría multiplicarse por 10, pero en realidad existe la tendencia a formarse esa expectativa demasiado rápido."
Redefinir el rol y las expectativas
"La diferencia más grande fue el cambio en cómo entendí el rol. Yo soy el arquitecto y desarrollador senior, y el LLM no es más que mi ayudante. Yo hago el plan, y el LLM cumple un papel de apoyo."
"Después de perder la confianza en él, ya no le delego funciones importantes. Solo lo uso en unidades pequeñas, como refactorizaciones."
"Empecé a corregir los bugs yo mismo. Cuando entiendes por completo la base de código, resolver el problema directamente es mucho más rápido y eficiente."
Cambio de perspectiva sobre los LLM y consejos
"Como desarrollador senior, reconocí por mí mismo que no era falta de capacidad de mi parte que la adopción de LLM no encajara bien. La clave es mantener la forma de trabajo existente y usar la IA como apoyo."
"Es cierto que con el avance tecnológico se dio un paso adelante, pero todavía no se ha llegado a la siguiente etapa. La toma de decisiones y la arquitectura siguen siendo trabajo humano."
"La revolución de la IA es impresionante, pero por ahora hacen falta expectativas equilibradas y realistas."
2 comentarios
> https://es.news.hada.io/topic?id=20955
Comentarios de Hacker News
Siento que paso demasiado tiempo en HN porque casi todos los posts y comentarios repiten lo mismo. Los LLM son interesantes, pero el código generado es complejo, no se siente propio y, como no tengo en la cabeza toda la estructura como sí pasa con el código escrito por uno mismo, es difícil de mantener. Sirve para scripts cortos que no piensas mantener, pero en proyectos grandes se vuelve problemático. Por otro lado, también hay gente que dice que son geniales los workflows donde distribuyen y fusionan tareas usando varios agentes LLM, pero no muestran código real y da la impresión de que solo están presumiendo
Creo que este resumen sí captura muy bien el punto central. Los LLM aceleran muchísimo el desarrollo, pero como no entiendo todo el código completo, me cuesta identificar cuándo y dónde apareció un problema. Al final se siente como si un desarrollador nuevo hubiera entrado y estuviera adaptándose a su propio proyecto. Por eso hago commits frecuentes y periódicamente le vuelvo a pedir al LLM que explique el código. En ese proceso, muchas veces el propio LLM encuentra sus bugs. En tareas de alcance acotado, como análisis de datos, se puede avanzar rápido manteniendo el control. En cambio, si no tienes la capacidad ni los hábitos para usar bien un LLM en un codebase grande, es muy fácil que todo se vuelva un desastre. Saber escribir prompts, manejar el contexto, regular el ritmo, organizar el trabajo y revisar con precisión los resultados del LLM son habilidades indispensables para usarlo bien. Todavía nadie enseña esto de forma oficial, así que todos lo están aprendiendo por prueba y error. Aun así, una vez que pruebas esto, cuesta mucho volver atrás. Puedes delegarle al LLM las tareas tediosas o repetitivas. Después de más de 20 años desarrollando, ya no tengo la misma paciencia de antes, y también puedo dejarle al LLM ideas cuya implementación no conozco bien para trabajar con mucha más eficiencia
Me gusta pensar la programación como un proceso de "construcción de teoría". Ver Programming as Theory Building. No tengo rechazo al uso de AI en sí. Lo que no apoyo es la actitud de desentenderse de la responsabilidad sobre el resultado del código generado. Igual que cuando usas herramientas como grep, el resultado solo tiene sentido si también te haces responsable de él. Con el código generado, más todavía; no es algo que se resuelva solo con un disclaimer
Entiendo completamente el cansancio con los posts sobre AI. Es cierto que las opiniones están divididas. Aun así, sí hay ejemplos de gente que publica código real. Armin Ronacher, creador de Flask/Jinja2/Sentry, subió a YouTube un video de workflow y una presentación de una librería de AI hecha por él mismo, y yo también hago entre la mitad y el 80% de mi proyecto open source con AI. Ver cijene-api
Siento que los usuarios se distribuyen como una curva de campana. En un extremo están quienes se ven abrumados porque el LLM produce demasiado código con su propio estilo, así que no logran incorporar el contexto en su cabeza. En cambio, para usuarios que por sí solos no podrían implementar algo, el LLM abre la puerta a intentar construir cualquier cosa. Y en el otro extremo están quienes sí podrían implementarlo por su cuenta con calma, pero usan el LLM como si fuera un ejército de desarrolladores junior, concentrándose solo en recordar el nivel general del algoritmo y armando proyectos mucho más grandes a gran velocidad
No me parece tan distinto de trabajar en un codebase grande donde participan al mismo tiempo más de 25 desarrolladores. En mi organización hay 160 ingenieros trabajando en frontend y middle tier, y todo el tiempo hay que escarbar código sin sentido de pertenencia mientras en git blame aparece el nombre de un contratista externo de hace 3 años. El LLM parece funcionar bien a pequeña escala, no encaja en escala media, y vuelve a funcionar bien cuando se usa como módulo pequeño dentro de proyectos grandes
Los LLM me ayudan bastante a alcanzar mis objetivos, pero siento que deterioran mi capacidad de programar por cuenta propia. Es como los esteroides: hacen crecer el músculo rápido, pero con muchos efectos secundarios, y en cuanto los dejas todo se desmorona de golpe. Como a la empresa le interesan los resultados rápidos más que la salud, este fenómeno se agrava. Empecé a usarlos con moderación, tratando de mantener un punto de equilibrio
Gracias a los LLM, siento que muchos desarrolladores olvidaron la lección central de "Simple Made Easy". El código que generan los LLM es excelente para producir un "Ball of Mud" (código caótico, complejo, difícil de refactorizar o mantener). La verdadera fuerza está en dividir un problema complejo en partes pequeñas, hacer que cada componente pequeño funcione de manera simple, y dejar que sus interacciones implementen la complejidad. Cuando cada componente es simple, entenderlo, depurarlo y predecir su rendimiento se vuelve fácil. Si algún día los LLM llegan a seguir realmente bien este principio, entonces quizá de verdad ya no hagan falta desarrolladores
En realidad también puedes indicarle directamente al LLM la dirección que quieres. La diferencia entre quienes sienten que el LLM sirve y quienes no, depende de si entienden cuáles son sus fortalezas y debilidades, y de si pueden anticipar que la calidad del resultado cambia según el input (prompt). Por ejemplo, prefiero preguntarle al LLM cómo dividir un problema complejo para ver si hay algo que se me escapó, y después encargarle la implementación concreta. No le pido que genere un proyecto grande completo sin ninguna instrucción
El problema del "Ball of Mud" no ocurre solo en el código. En mi trabajo también hay líderes que insisten en que hay que "adoptar activamente la AI", y he visto la idea de poner también en manos de la AI el sistema de despliegue y una operación compleja. Al final es poner otra caja negra compleja encima de un sistema ya complejo, con la lógica de que "para entender la caja negra hace falta otra caja negra nueva", y para mí eso no tiene sentido. El ambiente coercitivo dentro de la organización incluso hace que uno sienta que es el raro por pensar así
Me pregunto si de verdad dejarían de hacer falta desarrolladores si el LLM llegara a ser perfecto. No creo que nadie quiera una máquina funcionando 24/7 solo para seguir "produciendo software". Al final seguirá haciendo falta alguien que divida los problemas y encuentre y construya el software que realmente se necesita. Igual que hoy llamamos a esas personas desarrolladores de software
Al final yo también llegué a una conclusión parecida. Los LLM no son muy buenos cuando se usan para rellenar todo el codebase como si fueran autocompletado. Ahí desaparece el modelo mental de qué hace cada cosa y dónde está. Me resultó mucho más eficiente usar el LLM solo como un StackOverflow personalizado para explicar keywords, resumir conceptos que no conozco bien o sugerir direcciones, y dejar la implementación real y la toma de decisiones en mis manos
Yo también lo uso así, pero cursor sigue insistiendo en proponer modificaciones al código. Me gustaría saber si hay algún truco para hacer que solo introspecte sin tocar el contenido del codebase
En mi caso es distinto. Si siempre reviso con cuidado el código que propone el LLM, sí puedo entender bastante claramente qué hay dónde y cómo interactúa todo
Yo también estoy reduciendo bastante la frecuencia de uso. Hubo bastantes veces en que las respuestas del LLM estaban mal. Así que últimamente solo le pregunto en qué manual o documento debería buscar, y el contenido real lo reviso yo mismo. Ese método ayuda a desarrollar la capacidad de ubicar la información y reduce la dependencia tanto del buscador como del LLM. El LLM no deja de ser una herramienta, y además suele fallar bastante en precisión
Hay un punto que casi no se mencionó: a veces el LLM puede incluso reducir la productividad. Si te arrastra por un camino equivocado con una respuesta convincente, la pérdida de tiempo puede ser seria. En términos generales muchas veces ayuda, pero verificar la evidencia es importante y, de hecho, no pocas veces implementar uno mismo termina siendo más rápido
Las limitaciones del LLM son claras. Es muy poderoso, pero le cuesta dar saltos creativos al nivel humano. Por ejemplo, ante la pregunta "En Android no puedo hacer bind a puertos menores a 1000; entonces, ¿cómo ejecuto un servidor web?", tanto Claude como Gemini solo propusieron tres soluciones obvias: 1) reverse proxy 2) rootear 3) subir el número de puerto. La solución real que yo quería era usar registros HTTPS RR (referencia relacionada). Ambos conocen esa especificación, pero no logran aplicarla a la situación. Solo encontré la respuesta cuando yo mismo añadí más contexto
En realidad no me parece tan raro que el LLM no lo recomendara. Tampoco es razonable esperar que sugiera una especificación tan nueva que ni siquiera Chrome soporta oficialmente, y probablemente yo tampoco lo habría pensado
También me voy a guardar esta información. Hablando de verdad con LLM últimamente, siento que si los tratas con un poco de tolerancia, como si fueran personas, te estresas menos. Por ejemplo, cuando escribo código con cursor y le digo "aquí faltó esto", también pienso que yo mismo podría haber cometido ese error. También usé un LLM como compañero de "club de lectura" o "club de cine" y lo puse a discutir dos películas; aunque se equivocaba al describir la situación de algunos personajes, no hace falta que sea 100% preciso. Si le das la misma tolerancia que le darías a una persona, la conversación se vuelve mucho más fluida. Está bien relacionarse de forma positiva también al hablar con AI
Había oído hablar de los registros SRV, pero como casi no se usan, nunca les presté mucha atención. HTTPS RR sí es completamente nuevo para mí. Además, parece que el soporte real es mejor que el de SRV
Es el problema clásico del LLM de "solo agrega la respuesta correcta a la lista de soluciones cuando tú mismo la mencionas primero"
Si defines con suficiente claridad el objetivo y las restricciones, ChatGPT o3 sí propone esta solución. Eso sí, aclara correctamente que solo funciona en navegadores recientes. Ejemplo de referencia
Llevo tiempo usando mucho la versión Enterprise de ChatGPT y con el tiempo aprendí varias cosas. No conviene meter grandes cantidades de código; funciona mucho mejor cuando se trabaja con funciones muy independientes o clases pequeñas. En solicitudes de generación o completado de código, alrededor de un 10% se puede corregir con instrucciones adicionales, pero la calidad baja, y cerca de un 25% no mejora por más que expliques. En esos casos, simplemente lo ignoro y lo resuelvo yo mismo. En cambio, para revisar código recién escrito sí resulta bastante útil. La mitad de los comentarios no sirve, algunos son ambiguos, pero a veces sí detecta bugs o issues realmente importantes. También conviene no meter varias páginas de una sola vez, sino ir partiéndolas. En áreas de nicho como shaders HLSL o SIMD, casi no puede responder por falta de datos de entrenamiento. En general ayuda a mejorar la calidad del código. Como obliga a validar en unidades pequeñas de código, la arquitectura termina dividida en funciones, clases y módulos, y eso mejora la calidad general
En desarrollo de software de largo plazo, lo que más me atrae es usar el LLM como un "generador avanzado de boilerplate". Ya es muy bueno para tareas de una sola vez donde no te preocupa el mantenimiento, pero incluso en desarrollo a largo plazo es realmente útil para código repetitivo difícil de abstraer, como los tests. Al principio me generaba rechazo, pero ahora estoy demasiado satisfecho. Las partes aburridas y repetitivas se convirtieron en un juego nuevo e interesante de "optimización de prompts", y mi productividad también mejoró muchísimo. Escribir prompts y revisar código termina mucho más rápido que hacer trabajo mecánico. Gracias a eso, solo me quedan las partes interesantes donde sí hay que pensar
Al final me di cuenta de que los LLM, no solo en programación sino también en muchas otras tareas, se parecen al fenómeno de las "dietas de moda". Todos quieren una solución rápida y fácil, pero al final no hay camino real. La conveniencia siempre implica trade-offs, y tarde o temprano todos terminan aceptando esa realidad