Programar con LLM (verano de 2025)
(antirez.com)- Actualización sobre el uso de LLM por parte de antirez, desarrollador de Redis
- Los LLM de última generación como Gemini 2.5 PRO y Claude Opus 4 potencian las capacidades de los desarrolladores
- Con LLM es posible mejorar la eficiencia del trabajo de varias maneras, como eliminar bugs, probar ideas y ampliar conocimientos
- También permiten la experiencia de abordar con facilidad campos no especializados o tecnologías nuevas con ayuda de un LLM
- Sin embargo, para la calidad general y el mantenimiento del código, la colaboración 'humano + LLM' es clave
- Para aprovechar al máximo un LLM, es importante proporcionar suficiente contexto y tener habilidades de comunicación claras
Cambios en el desarrollo con LLM y puntos clave
Los LLM de vanguardia (como Gemini 2.5 PRO y Claude Opus 4), gracias a su enorme capacidad de comprensión y de procesar grandes volúmenes de código, cumplen el papel de ampliar las capacidades de los programadores
- Si sabes describir el problema con claridad y te sientes cómodo con la comunicación iterativa
- puedes eliminar bugs antes del lanzamiento (por ejemplo, en el caso de la implementación de Vector Sets en Redis, Gemini/Claude eliminaron bugs de inmediato mediante revisión de código)
- puedes probar rápidamente si una idea funciona mientras escribes código experimental y evalúas su rendimiento
- es posible hacer pair-design basado en experiencia e intuición, fusionando el amplio conocimiento especializado del LLM con la intuición humana
- si le das instrucciones claras al LLM, puedes completar rápidamente parte de la implementación del código
- puedes adaptarte con rapidez a áreas desconocidas (por ejemplo, código ensamblador 68000 para Amiga)
En el artículo anterior, 'LLMs y la programación a inicios de 2024', ya se mencionaba la utilidad de los LLM, pero en el último año y medio han avanzado de forma enorme
Para aprovecharlos al máximo, tanto los humanos como los LLM necesitan ciertas capacidades y hábitos, y por eso estos principios son importantes
Moderación con el Vibe Coding y principios de colaboración humano+LLM
Actualmente, los LLM son excelentes como amplificadores de la capacidad del desarrollador, pero todavía no han llegado al nivel de encargarse por sí solos y de forma autónoma de todo el trabajo
- En proyectos pequeños y puntuales, como pruebas o utilidades reducidas, un LLM puede diseñar por sí solo
- Pero en proyectos grandes y poco convencionales, usar solo un LLM puede generar problemas como complejidad, código innecesario y debilidad estructural
- La colaboración entre LLM y personas muestra el mayor aumento de productividad, pero el requisito previo es tener experiencia en comunicación efectiva y en la gestión del LLM
- No conviene dejarle tareas complejas únicamente al LLM; hace falta una estrategia en la que el ser humano intervenga activamente en todo el proceso
La importancia de dar suficiente contexto al LLM
Para que un LLM entienda correctamente la dirección del desarrollo o de la corrección de un problema, es indispensable proporcionarle información de contexto amplia
- Lo ideal es darle artículos académicos, el código base objetivo (en la medida de lo posible, completo) y la intención del trabajo
- Debe incluir información clave como el propósito de la implementación, enfoques innecesarios o débiles, ideas centrales viables, objetivos, invariantes y estilo de código
- Por ejemplo, al trabajar con una tecnología nueva que el LLM no conoce (como Redis vector sets), si incluyes el documento README dentro del contexto, puede ofrecer respuestas de nivel experto de inmediato
Selección del LLM y forma de uso
El LLM más conocido no necesariamente produce los mejores resultados
- Para programación, Gemini 2.5 PRO y Claude Opus 4 son especialmente eficaces
- Gemini 2.5 PRO destaca por su capacidad para detectar bugs complejos y resolver problemas
- Claude Opus 4 es bueno para escribir código nuevo y además ofrece una gran experiencia de usuario
- Alternar entre ambos modelos mejora la comprensión en diseños complejos
- Si hubiera que elegir solo uno, se recomienda Gemini 2.5 PRO
- Condiciones que conviene respetar al usar LLM
- Evitar usar agentes de código o agentes integrados dentro del IDE
- Permitir que el LLM vea directamente todo el contexto (código, documentación, etc.) para inducir la mejor respuesta posible
- Si se usan funciones que muestran solo parte del contexto, como RAG (basado en extracción de conocimiento), el rendimiento se degrada
- En cada etapa, la persona debe copiar y pegar el código manualmente y seguir el flujo de forma directa
Conclusión – mantener el control es lo esencial
La llegada de agentes que escriban código por sí solos no está lejos, pero por ahora, la forma que produce el código más sólido es la colaboración dirigida por personas con LLM
- Sigue siendo clave que el ser humano decida ‘qué’ hacer y ‘cómo’ hacerlo
- Usar LLM permite crecer aprendiendo nuevas tecnologías o conceptos más allá de los límites del conocimiento previo
- Si controlas el código directamente, puedes mantener la consistencia del diseño y la implementación, y también minimizar la incertidumbre provocada por los errores del LLM
- Revisar periódicamente cómo evoluciona el rendimiento de los agentes también es una estrategia inteligente
- En esta etapa, evitar el uso de LLM puede hacer que te quedes atrás frente al cambio, por lo que este es un momento en el que importa una forma de uso equilibrada
1 comentarios
Comentarios de Hacker News
Me da tristeza que modelos LLM cerrados como Gemini 2.5 PRO o Claude Opus 4 se estén volviendo el estándar. Veo de forma muy positiva el avance de los LLM y su potencia como herramienta, pero me cuesta entender por qué los desarrolladores, sean famosos o no, siguen considerando aceptable depender de servicios pagos de terceros para poder programar. Antes era posible escribir código solo con herramientas gratuitas y de código abierto. Me preocupa que en unos años depender de un LLM de pago se vuelva tan incómodo de evitar como hoy lo sería programar sin un IDE o sin vim. Decir que pagar $200 al mes no es gran cosa no resuelve el problema de fondo.
Los modelos abiertos que hoy pueden correr en local todavía se quedan cortos en calidad y, sobre todo, cuestan mucho más de operar. Cuando sea económicamente viable ejecutar en una computadora personal un modelo del nivel de Claude 4, mucha gente lo va a intentar. Por ahora, un modelo como Kimi K2 puede correr en dos Mac Studio de 512GB, pero solo el hardware cuesta unos $20,000.
El modelo de suscripción hace que al principio parezca ofrecer una relación precio-rendimiento extraordinaria. Pero después los precios suben, la calidad baja y al final terminas atado al servicio, como en el episodio "Common People" de Black Mirror.
Personalmente, creo que es difícil que llegue un futuro en el que todos los desarrolladores queden obligatoriamente subordinados a LLM de pago. A largo plazo, la gente se va a dar cuenta de que producir enormes cantidades de código ya es un problema en sí mismo. El código es deuda, y si se acumula código inestable o lento, esa deuda crece. La IA no va a desaparecer, pero cuando baje un poco la fiebre vamos a entender mejor dónde usarla y cómo hacerlo. También me pregunto qué va a pasar cuando se seque el financiamiento. OpenAI y Anthropic no son rentables y necesitan que siga entrando capital para mantenerse como están. Si la evolución de los LLM ya llegó a este nivel y ese es su límite, la inversión también podría retirarse; y entonces el costo de uso podría subir o incluso el servicio podría desaparecer por completo.
En términos realistas, no creo que sea un problema tan grande. Si no existe una razón concreta de productividad, no hay motivo para seguir atado a un servicio caro y poco amigable. Los modelos abiertos también siguen mejorando, así que si la brecha con los modelos abiertos no es grande, no habría necesidad de seguir usándolos. Si el avance de los LLM no se detiene y sigue siendo abrupto, entonces nosotros ya no vamos a ser competitivos con el enfoque tradicional y tendremos que movernos a otra área. En resumen, no creo que haya que preocuparse demasiado. También siento que el valor de las grandes empresas de modelos está enormemente sobreestimado respecto de la realidad.
Quiero agregar algo a eso de que se puede programar con herramientas gratuitas y de código abierto: JetBrains es una empresa más antigua que muchos de nuestros colegas, y Visual Basic/C++/Studio de Microsoft hicieron mucho más fácil el desarrollo en Windows, pero todos eran productos pagos.
No estoy de acuerdo con la expresión "PhD-level knowledge". El objetivo de un doctorado no es adquirir conocimiento existente, sino aprender a hacer investigación. Es un punto que suele malinterpretarse en las discusiones sobre IA, y por eso la idea de “conocimiento de nivel doctorado” termina siendo ambigua.
Además de que un PhD es un proceso para aprender a investigar, lo importante es si puedes formular preguntas. Un LLM se parece más a un "trabajador perezoso con mucho conocimiento" y no explora hipótesis haciéndose preguntas por sí mismo. Como ejemplo real: le pedí a Claude Code (Max Pro) que comentara la cantidad de aserciones en tests, y apareció un bug basado en una suposición incorrecta del plan original. Solo cuando le indiqué explícitamente que reescribiera el plan pudo encontrar la causa y corregirlo. Por ejemplo, el motivo por el que un objeto de ORM tenía un valor
nullera que faltaba un refresh después del commit, y otro problema venía de que algo cargado desde otra sesión de base de datos seguía quedando tal cual incluso después de cerrarse esa sesión.De acuerdo. Tienen conocimiento de nivel experto, pero hay cosas en las que los humanos siguen siendo mucho mejores. Por ejemplo, un LLM puede escribir de una sola vez un programa brillante de punta a punta, pero le cuesta mejorarlo de forma iterativa.
Incluso entendiendo que un PhD implica más que conocimiento, el simple hecho de tener una vía de acceso fácil a ese conocimiento ya tiene un valor enorme. En una empresa donde trabajé antes, un LLM llegó a dar respuestas bastante útiles a preguntas difíciles que normalmente solo podría responder alguien con doctorado, algo como, dicho muy burdamente, "¿qué fenómeno ocurre si aplicas un voltaje en cierta dirección sobre la frontera entre dos materiales?".
Obtener un PhD no significa que te importe más la materia en sí; al final, lo importante es haber aprendido a investigar.
Creo que cualquier discusión sobre programación con LLM debería mencionar sí o sí el dominio que se está tratando y el lenguaje de programación que se usa. Esas dos variables influyen mucho más que la forma concreta de usar el LLM. Si a alguien le gusta o no le gusta programar con LLM, primero habría que preguntarle qué tipo de problemas estuvo resolviendo, y luego intentar resolver ese mismo tipo de problema directamente con IA para entender bien su postura. Si no, siempre terminamos en discusiones inútiles del estilo "es que lo usaste mal" o "yo lo probé y no me convenció".
Con base en mi experiencia de haber trabajado durante varios meses muy enfocado en agentic coding, coincido con todo lo que dice la publicación. Los LLM de punta son, por ahora, los más fáciles de usar, pero espero que los modelos abiertos los alcancen pronto. Puedes pedirle a un LLM que te recomiende un enfoque nuevo o que te proponga uno que ya conoces. A veces los LLM tienen tendencia a complicar las cosas, así que basta con detectarlo a tiempo o pedir una refactorización. Y la situación también va a seguir cambiando cada vez que aparezcan nuevos modelos. No todos los trabajos requieren necesariamente el modelo más avanzado. Para funciones o correcciones de bugs sencillas, Copilot también es un muy buen punto de partida. Ojalá todos disfruten probar distintas cosas y aprender en medio de estos cambios.
He usado la GitHub action de Claude para implementar unos 10 a 20 issues y para revisar PRs, y coincido totalmente en que es una lotería y que conviene más usarlo como herramienta de apoyo que como automatización indiscriminada. Cambios pequeños y funciones o refactorizaciones chicas con buenas pruebas casi siempre salen bien en automático. Si lo corres como action, tú puedes dedicarte a otras cosas mientras tanto, y eso es una ventaja. Si Claude además te escribe el issue, es todavía más cómodo. Pero a partir de un tamaño mediano, muchas veces genera código que parece razonable pero en realidad no funciona. Puede que parte de eso sea responsabilidad mía por falta de cobertura de tests, pero sin duda pasa con frecuencia. Aunque escriba los issues con más detalle o pruebe prompts distintos, el resultado suele decepcionar. Ni hablar de trabajos grandes, que son mucho más difíciles. La función de revisión de PR sirve para trabajos pequeños o medianos, pero también hace muchas observaciones inútiles. En conclusión, creo que todavía falta bastante para que los LLM programen por sí solos. Lo más eficiente sigue siendo usarlos en tareas pequeñas: que redacten el issue y esperar a que llegue el PR. En la mayoría de mis tareas, que son de tamaño medio, con darle dirección a Claude ya casi no tengo que programar, así que la productividad sí aumenta claramente. También probé Gemini, pero si lo dejas solo el código se vuelve impredecible a un nivel absurdo. En la empresa también hacemos revisión de PR con Copilot, pero no da mucho resultado. Si el codebase fuera enorme, quizá Gemini tendría más utilidad.
A diferencia del OP, yo pasé un mes metido de lleno en este tema y encontré que Gemini 2.5 PRO y Opus 4 daban mejores resultados en discusiones abstractas como arquitectura. Para la implementación puntual del código, en cambio, resultaba más eficiente delegarla a Sonnet. 2.5 PRO y Opus tienden a rondar la respuesta correcta haciendo correcciones por su cuenta una y otra vez, mientras que Sonnet va de forma más directa a la respuesta, aunque necesita instrucciones mucho más detalladas.
Suena totalmente posible. En efecto, Sonnet/Opus 4 pueden ser más potentes en sus mejores resultados, pero en algunos aspectos quedan por detrás de Sonnet 3.5v2 (también llamado 3.6) o incluso 3.7 en consistencia o alineación. Además, los modelos son objetos complejos, así que según el dominio, un modelo que "parece más débil" puede funcionar mejor. También hay diferencias entre entornos conversacionales e interacciones orientadas a agentes, porque las técnicas de reinforcement learning no son las mismas, así que el rendimiento del modelo cambia según cómo se use.
De hecho, en estadísticas internas también se confirma que Opus y Gemini 2.5 pro rinden peor que Sonnet 4 en entornos realistas enlace a estadísticas relacionadas
Yo también tuve una experiencia parecida. Uso Gemini 2.5 Pro en AI Studio para validar o depurar ideas grandes de diseño, y luego llevo los requisitos a Claude Code, que por lo general programa de forma bastante limpia. Hace poco también probé Gemini CLI, y su capacidad de programación está muy por detrás de Claude Code. Tiene muchos errores de sintaxis, se queda atrapado en loops y produce resultados verbosos que además van tan rápido que cuesta seguirlos. En cambio, Claude Code es excelente depurando. Para resolver problemas de "panorama general", DeepSeek R1 también vale la pena; es muy lento, pero acierta bastante.
Aquí hay un caso realista que muestra cómo AI/LLM a veces escribe código tremendamente ineficiente enlace al blog relacionado
Me ha funcionado pedirle primero al LLM que solo me explique la tarea que quiero hacer y luego, dándole feedback a mitad del proceso y pasando por varias iteraciones, la calidad del código que genera mejora muchísimo. Hacer que primero valide un plan detallado resulta efectivo.
En mi experiencia, en frontend sí le puedo delegar con vibe coding tareas repetitivas, simples y fáciles de validar, pero normalmente uso el LLM como compañero de sparring para revisar mi código y evaluar distintas alternativas. Aunque a veces haga recomendaciones absurdas o con fallas lógicas, me ayuda a no pasar por alto cosas demasiado obvias. También me sirve para corregir mi costumbre de intentar soluciones excesivas cuando tengo enfrente un problema enredado.
No entiendo exactamente a qué se refiere el OP con esa forma de trabajar. ¿Está sugiriendo que uno pegue manualmente un archivo C de redis en la ventana de chat web de Gemini Pro?