- Existen desarrolladores a quienes les cuesta generar valor claro usando LLM para programación
- Algunos usuarios no están satisfechos con la calidad de salida de los LLM
- En requisitos específicos o problemas complejos, los LLM tienden a no cumplir las expectativas
- En cambio, en automatización simple o tareas repetitivas sí se percibe cierto nivel de utilidad
- Los desarrolladores están buscando formas de mejorar mediante ingeniería de prompts o ajustes en su flujo de trabajo
Debate sobre las dificultades de usar LLM para programación y cómo mejorarlo
El valor limitado de los LLM
- Recientemente, muchos desarrolladores han estado probando LLM para programación como ChatGPT, GitHub Copilot y Claude para distintos usos
- Sin embargo, una cantidad considerable de usuarios no siente la mejora real de productividad que esperaba
- En particular, al escribir algoritmos complejos, estructurar código a gran escala o diseñar la arquitectura de un proyecto, el código sugerido por los LLM suele ser fragmentado o ineficiente
Quejas sobre la calidad de salida
- Algunos desarrolladores señalan que el código proporcionado por los LLM incluye bugs o entrega resultados imprecisos por no comprender suficientemente el contexto
- Con frecuencia faltan explicaciones o análisis, o el código no refleja correctamente la complejidad y el contexto del proyecto
Ayuda en áreas de uso simple
- En aspectos como generar snippets cortos de código, tareas repetitivas o resolver problemas simples de sintaxis, sí se confirma una utilidad clara en términos de automatización básica
- El uso en tareas rutinarias como pruebas unitarias, refactorización y ajustes de estilo de código recibe una valoración alta
Intentos de mejora
- Algunos desarrolladores aplican activamente técnicas de ingeniería de prompts para obtener mejores resultados
- También están experimentando con formas de usar LLM que se adapten a su flujo de trabajo y con combinaciones junto a varias herramientas de código abierto
Conclusión y aprendizajes
- Por ahora, se reconoce que los LLM no pueden ser una solución universal para todas las necesidades de desarrollo
- La comunidad y los desarrolladores comparten experiencias mientras buscan estrategias de uso eficientes y maneras de superar sus limitaciones
1 comentarios
Opinión de Hacker News
Siento que existen dos tipos de desarrolladores. Un grupo anda diciendo que los LLM son un superpoder total para programar y que su productividad subió 100 veces, y luego está el otro grupo que los ve como una herramienta bastante complicada, que requiere mucho trabajo y esfuerzo para apenas obtener resultados normales. Pero si de verdad el primer grupo logra un aumento tan revolucionario de productividad con los LLM, entonces surge la duda de si ya no deberían estar dominando por completo el mercado y barriendo a la competencia
En trabajo greenfield sí siento que mi productividad puede subir hasta 100 veces gracias a los LLM. Por ejemplo, puedo sacar en minutos la estructura base de una app en React con varias páginas, store de Redux, autenticación y demás. Si digo "ahora agrégame X", por lo general da buenos resultados. Pero para mantener sistemas existentes, agregar funcionalidades complejas o trabajar en contextos donde el conocimiento del dominio importa, el LLM casi no sirve. Está bien para autocompletado o para completar funciones, pero al momento de implementar una funcionalidad completa choca rápido con sus límites. En esos casos, el tiempo que gasto dándole instrucciones al LLM termina siendo parecido al que me tomaría programarlo yo mismo. Por eso normalmente primero dejo código stub con la estructura que quiero y luego hago que el LLM solo rellene los huecos. La gente que habla de productividad x100 probablemente todavía solo se ha topado con la parte fácil, o aún no se ha enfrentado con lo difícil. En la práctica, el 90% del trabajo es fácil, y el último 10% es lo realmente duro, y ahí el LLM no rinde bien
Lo digo medio en broma, pero quienes hablan de productividad x100 en realidad están multiplicando un número pequeño por 100. En la etapa de investigación, el LLM ayuda muchísimo. Por ejemplo, hace poco tuve que escribir explícitamente código de álgebra lineal especializado para cierto dominio, y como no podía usar bibliotecas como LAPACK, tuve que implementarlo yo mismo. En un caso así, usar el LLM como referencia en vez de un libro para que me resuma de golpe la información que quería realmente me redujo el tiempo de investigación en 100 veces. Pero cuando le dejé la implementación real del código al LLM, metió errores sutiles que alguien no experto podría no notar. Un junior quizá los habría pasado por alto. Como para mí la revisión de código es importante, no creo que la velocidad de escritura de código en sí aumente tanto aunque los LLM mejoren muchísimo. Eso sí, en la etapa de explorar y resumir para decidir qué código escribir, el LLM sí acelera muchísimo. Al final, la innovación y las ideas creativas son el verdadero valor del mundo, y sigo pensando que eso sigue siendo tarea humana. El LLM será un ayudante importante, pero el código de alto valor agregado creo que hay que escribirlo uno mismo
En realidad hay casos que no entran en ninguno de esos dos grupos. No es productividad x100, pero tampoco es que cueste usarlo horrores. Llevo más de 30 años programando profesionalmente, y siempre he tenido que andar consultando cosas y se me olvidan seguido lenguajes o sintaxis concretas. Además, en muchos trabajos toca alternar entre varios lenguajes. Antes había que revisar libros de referencia o manuales, e incluso materiales todavía más pesados. Con la llegada de motores de búsqueda como Google mejoró un poco, y plataformas como Stack Overflow fueron todavía más eficientes. Ahora los LLM son simplemente otro paso más hacia adelante. Las sugerencias de autocompletado a veces terminan siendo justo la pista que estaba buscando. Claro, ignoro lo que no me sirve, pero la interfaz de chat me gusta porque permite preguntar de forma mucho más conversacional que Google o las búsquedas en SO
Estoy estudiando matemáticas con Math Academy, ChatGPT y YouTube, sobre todo 3Blue1Brown. Sin esa combinación habría sido una tortura, pero ahora es disfrutable. Cuando tomé un curso parecido en la University of Amsterdam, ChatGPT todavía no era tan inteligente como ahora, así que fue mucho más difícil. ChatGPT me responde preguntas que incluso a un profesor le costaría responder, y para alguien como yo, que necesita entender también el trasfondo cultural de las matemáticas para conectar con ellas y resolver problemas de forma creativa, eso encaja perfecto. Por ejemplo, pregunté por qué se usa m en los ángulos, y me explicó que históricamente viene de measure. Gracias a eso ahora puedo volver a concentrarme en la esencia de las matemáticas. También me explicó de forma sencilla la fórmula rápida para calcular la varianza. No es una herramienta para dominar el mundo, pero sí me está ayudando a aprender cosas que de otro modo no habría aprendido. Claro, también influyen mucho YouTube y Math Academy
Los LLM son un superpoder para gente que cubre muchas áreas y no es experta en cada una de ellas. Si trabajas siempre en un solo dominio y lo conoces a profundidad, sirven bastante menos. Por ejemplo, si en cada proyecto necesitas una sola vez algo de despliegue y no hay un especialista dedicado, usar un LLM para escribir un Dockerfile es excelente. También te ayuda a resolver errores de sintaxis o problemas pequeños más rápido que Google. Si le pides que analice trade-offs de arquitectura, pero dejas la decisión final en tus manos, sí puede mejorar la productividad. Eso sí, hay que acotar bien el alcance con el prompt para evitar que haga tonterías, y en la práctica a menudo inventa APIs que ni existen o comete errores absurdos, así que toca corregirlo varias veces. Aun así, incluso iterando sigue habiendo ventaja de velocidad
Yo también uso los LLM de distintas maneras. Me ayudan con debugging pequeño, scripts de shell, programación, preguntas y más. Para cosas personales elijo entre Claude, OpenAI, Google o Perplexity según cuál me dé el mejor resultado. En el trabajo uso Claude, OpenAI y Google desde VSCode mediante Copilot o una plataforma interna, y también he probado un poco Copilot Studio. Llevo más de un año y medio trabajando así; no he usado todas las herramientas todo el tiempo, pero mi impresión general es esta. Sin duda los LLM sí han aumentado mi productividad. He podido experimentar con varios lenguajes de programación y entender mejor distintos temas, así que ciertas tareas claramente se volvieron mucho más fáciles. Pero, sin importar el modelo o la versión, cuando el trabajo se vuelve complejo, o me salgo por mi propio camino, o paso de la simple combinación de piezas, todos fallan claramente. Incluso hay veces en que el tiempo que me toma corregir las tonterías del LLM se come por completo el tiempo que supuestamente ahorré al principio. Si soy honesto, por ahora mi conclusión es que los LLM sirven para autocompletado pequeño de código, debugging y explicaciones, y hasta ahí. No amenazan nuestros empleos de forma inmediata
Los LLM me ayudan muchísimo para aprender bibliotecas, APIs o lenguajes nuevos. Por ejemplo, para algo como renderizar texto en OpenGL, preguntárselo directo a un LLM es mucho más rápido que leer documentación oficial enorme y desordenada. O cuando tienes que escribir boilerplate repetitivo y aburrido, y no hay código existente del cual copiarte, el LLM también ayuda. Pero en la parte de código verdaderamente 'de trabajo', esa zona única y particular de mi servicio, el LLM no tiene mucho valor en el sentido de 'escribir el código por mí'. Como ingeniero senior, casi no gasto tiempo en teclear código; lo importante es el diseño estructural, el refactor de legado, los problemas de rendimiento, el debugging de bugs raros, etc. Como el LLM solo acelera la escritura repetitiva, si no estás arrancando proyectos nuevos desde cero cada semana, su utilidad no es tan grande. Y si todavía escribes muchísimo boilerplate, quizá además de depender del LLM deberías pensar en otras soluciones más de raíz
Para leer documentación oficial caótica y explicarla, el LLM es claramente mucho mejor que un programador promedio. En eso sí añade valor de forma clara. También hay lenguajes con demasiado boilerplate, ¿no?
No existe la bala de plata, y la parte realmente difícil es la conceptualización. The Mythical Man-Month es un texto importante y vale mucho la pena leer más sobre eso
No hay bala de plata. Sorprende que sigamos olvidando una idea tan simple de Fred Brooks. Si no inflamos demasiado las expectativas y entendemos que, como los datos de entrenamiento tienen mucho código con bugs, los LLM naturalmente también los tendrán, entonces se vuelven mucho más útiles. No hay que delegarles el diseño; conviene hacer uno mismo el trabajo previo, como dividir funciones, y usarlos para quitarse de encima las tareas tediosas o las zonas desconocidas. Pero aunque el código lo genere el LLM, si vas a hacerte responsable de él, tiene que pasar necesariamente por tu conocimiento y tu validación. Aunque el código del LLM parezca perfecto, puede esconder defectos, así que hay que seguir estudiando, mejorando las habilidades y manteniendo una actitud de duda. Nunca confiar ciegamente
Es claro que cuando el problema crece de tamaño el LLM deja de ser útil. Es excelente para tareas repetitivas o para find & replace complejos. En código cotidiano y bien definido, como llenar métodos CRUD en recursos de API, sirve muchísimo. Últimamente incluso he puesto a Claude Opus 4 a revisar mis parches, y a veces detecta errores o me recuerda cosas que yo debía hacer. Pero una vez que se supera cierto umbral de complejidad, su utilidad cae en picada. Por ejemplo, si hay que hacer cambios en muchos archivos relativamente grandes, uno ya termina razonando por sí mismo qué archivos debe tocar. Aun así, usar el LLM como rubber duck sí está bien. Si la IA lo resuelve, perfecto; si no, yo sigo de inmediato por mi cuenta. Al final, el LLM solo me ayuda al principio y la mayor parte de las modificaciones igual me toca hacerlas a mí. Que me arme una estructura aproximada y luego yo la ajuste a lo que quiero sí parece más cómodo que empezar totalmente desde cero. Si el LLM deja claro que le cuesta, no lo fuerzo. Si interpretó mal por culpa de una especificación ambigua, se lo señalo, y si aun así no puede, simplemente lo termino yo
Mi experiencia es parecida. He encontrado valor en los LLM para cosas como estas. Pueden generar bastante bien componentes o páginas de React relativamente independientes, sobre todo si usas bibliotecas de UI populares. También producen funciones puras bien definidas con una fiabilidad razonable, y además son fáciles de validar. El boilerplate de frameworks conocidos lo hacen realmente fácil y bien. Pero la gente a mi alrededor presume experiencias end-to-end impresionantes, y yo en la práctica no logro eso, así que me está volviendo un poco loco. Incluso esforzándome mucho, cuando intento una unidad funcional completa, el LLM colapsa por completo. Con herramientas como aider, ni siquiera logró hacer una función sencilla de correo por plantilla en Next.js. Si desarmo la funcionalidad en partes pequeñas y se las voy pidiendo de una en una, mejora un poco, pero poco a poco va destruyendo el código existente. Aunque le explique el problema, mientras más prompts le doy más raro se pone. Al final intenté arreglarlo a mano, pero el código quedó totalmente hecho un desastre
Algunos amigos vibe coders me han dicho que "mis estándares son demasiado altos". Yo creo que, como el vibe coder en el fondo no revisa bien el código, en realidad no tiene un estándar de calidad. Si el vibe coding de verdad funcionara bien, lugares como Google AI ya estarían mejorando productos muchísimo más rápido que los humanos gracias a sus enormes presupuestos de GPU, TPU y sus modelos de IA de punta. Si eso de verdad estuviera ocurriendo, antes que notar que nuestro trabajo se vuelve gradualmente más fácil, primero lo sabríamos por noticias de cosas enormes e inesperadas que estarían pasando, y solo mucho después nos enteraríamos de que la causa fue la IA
Los LLM son buenos para código de un solo uso. No es que luego sea fácil desarrollarlo, mantenerlo, depurarlo o corregirlo. Como gran parte del código en realidad es casi 'consumible' más que producto, encajan bien ahí. Incluso si aplicáramos analogías como comida rápida, línea de ensamblaje o producción automatizada, hay una diferencia enorme. Un objeto fabricado por una máquina en una planta sale correctamente el 99.99% de las veces, así que puedes confiar en él. Pero con un LLM tengo que verificar manualmente cada paso, y si no lo hago, simplemente no funciona. Es imposible que un LLM resuelva algo con éxito de forma autónoma, sin supervisión, durante 24 horas seguidas. Por eso todavía no nos quita el trabajo
Yo jamás intentaría entregarle un problema complejo entero al LLM y esperar el resultado final. Esa no es su fortaleza. El valor real del LLM está en darte 'pistas' para avanzar y en dejarte saltarte las partes simples pero tardadas. Hace unos días tuve que armar una cadena de logs, y el LLM me propuso de inmediato un formato de código más bonito del que yo estaba pensando, así que algo que me habría tomado 15 minutos lo resolví en 30 segundos y quedó muy bien. Ese tipo de pequeñas victorias se va acumulando y ahí está el valor
if err != nil; Rust añadió?, y Zig va por una línea parecida. Python se ha vuelto cada vez más largo y complejo con cosas como las anotaciones de tipos. Los autoformatters son comodísimos y te quitan la carga de pensar en la indentación, aunque en Python no son perfectos porque los espacios importan. Las herramientas ayudan a los lenguajes verbosos, y los lenguajes expresivos ayudan a mantener el código conciso. Pasamos mucho más tiempo leyendo código que escribiéndolo. Las herramientas deterministas son fuertes en la estructura del código; las probabilísticas, como los LLM, son fuertes para acercarse a la intención. Los modelos de lenguaje son una evolución de las herramientas de automatización y, como el autocompletado, seguirán mejorando, pero no pueden 'resolver por completo' la programación. No hay una respuesta correcta; al final solo hay diferencias de opinión