Después de pasar meses programando con LLM, decidí volver a usar mi propio cerebro

• Aproveché LLM de alto rendimiento para construir una infraestructura, pero aparecieron grandes problemas en la calidad y mantenibilidad del código
• Debido a la ineficiencia de la IA y a sus resultados inconsistentes, sentí la necesidad de entender el código por mi cuenta, investigar y fortalecer mis capacidades
• El objetivo de terminar el proyecto rápido terminó provocando caos en la estructura del código, duplicación e inconsistencias
• Ahora solo uso la IA de forma limitada como apoyo, para tareas como trabajo repetitivo o transformación de código
• Como el uso de IA puede llevar a una pérdida de intuición para programar y de capacidad de resolver problemas, priorizo volver a usar activamente mi cerebro

---

Introducción: intento de construir infraestructura con LLM

• La infraestructura existente de PHP+MySQL había llegado a su límite, así que reconocí la necesidad de una nueva infraestructura
• Elegí Go y Clickhouse, y avancé en el diseño y la planificación de la infraestructura junto con la IA
• Consulté a LLM como Claude sobre mejores prácticas y arquitectura, y a partir de eso elaboré un plan detallado
• Con el objetivo de completar funcionalidades y lanzar rápido, el desarrollo del código se llevó adelante priorizando la velocidad

Proceso de desarrollo y aparición de problemas

• Usando herramientas como Cursor, la IA escribía el código y yo me enfocaba principalmente en compilar y probar
• Aunque el codebase no estuviera bien ordenado, me concentré primero en entregar los datos que se necesitaban
• Aunque el desarrollo avanzó rápido, con el tiempo siguieron apareciendo nuevos problemas una y otra vez
• También hubo dificultades por la falta de experiencia con Go y Clickhouse, y las correcciones propuestas por la IA fueron causando problemas consecutivos

Problemas de calidad del código y sensación de límite

• Reservé tiempo para hacer una revisión de código minuciosa de todo lo que se había construido
• Había muchos casos de inconsistencia, duplicación y confusión entre archivos que cumplían la misma función, en nombres, parámetros y estructura
  • Ejemplo: WebAPIprovider y webApi significaban los mismos parámetros, pero existían por separado
  • El mismo método se redefinía en varios archivos
  • No había consistencia en la forma de acceder a los archivos de configuración
• En la práctica, el resultado parecía hecho por varios desarrolladores junior trabajando al mismo tiempo sin comunicarse entre sí

Límites del feedback contextual de los LLM y cambio de estrategia

• Aunque proporcioné información de contexto suficiente y utilicé LLM de ventana amplia como Gemini, no hubo una mejora consistente
• Reconocí la necesidad de aprender por cuenta propia sobre la infraestructura y el lenguaje, además de estudiar más con documentación, videos y otros recursos
• Para escribir código limpio y bien organizado, cambié de un desarrollo guiado por IA a un enfoque de diseño de código autónomo

Cambio en la forma de usar la IA como apoyo

• Me enfoqué en la comprensión y gestión directa del código mediante refactorizaciones repetitivas y ordenamiento del codebase
• Limitè el papel de la IA a tareas simples y repetitivas, como cambios automáticos de código, modificación masiva de parámetros y transformación de código
• La planificación de nuevas funciones y la redacción inicial del código las hago pensando yo primero, y luego dejo al LLM una función de validación o apoyo
• Dejo a la IA como “asistente”, mientras que la autoridad sobre la planificación y las decisiones estructurales permanece en el propio desarrollador

Preocupación por el deterioro del pensamiento y cambio de actitud

• Al tener IA disponible, reconocí que estaba usando menos el cerebro y dependiendo de la IA para planificar o pensar
• Busco recuperar mis capacidades como desarrollador y mi habilidad para resolver problemas mediante papel y lápiz, diseño directo y programación directa
• Tomé conciencia del riesgo de que la IA provoque una pérdida de sensibilidad para programar

Preocupaciones sobre no desarrolladores y el ‘Vibe Coding’

• Cuando una persona no desarrolladora intenta construir solo con LLM, el fenómeno de código complejo y confuso, junto con errores repetidos, puede volverse aún más grave
• En comparación con las herramientas no-code, el desarrollo basado en IA puede hacer todavía más difícil entender la estructura
• Se menciona la dificultad y el riesgo de fondo de enfrentarse a una pared de código incomprensible y a un ciclo continuo de error-corrección-reaparición

Reflexiones sobre la realidad del uso de IA y el ambiente de la comunidad

• Expresa confusión ante la comercialización de la IA, los benchmarks, los influencers, el hype de las empresas de IA y la brecha entre la publicidad y el rendimiento real
• Hay falta de consistencia, al punto de obtener resultados completamente distintos con el mismo modelo y el mismo prompt
• Incluso los LLM más recientes y potentes todavía no pueden resolver perfectamente tareas complejas del mundo real, como consultas sobre cientos de millones de filas en Clickhouse
• Cuando se imponen configuraciones complejas y flujos de trabajo ineficientes, eso mismo puede terminar siendo una ‘pérdida de tiempo’
• Aunque la IA parece impresionante, por ahora la ve con cautela como una herramienta buena, pero no extraordinaria

Conclusión

• Sigue teniendo grandes expectativas e interés por las tecnologías más recientes y la IA
• Pero en este momento, una estrategia inteligente es entender correctamente su rol y sus límites y usar la IA de forma limitada como herramienta de apoyo o de aprendizaje
• Advierte sobre la degradación de las capacidades del desarrollador por el uso de IA, y vuelve a poner en el centro su propio pensamiento y planificación
• Si no se entiende cómo funciona el código y cuál es su estructura, desarrollar dependiendo por completo de la IA tiene altas probabilidades de fracasar

[GN⁺]

Opinión de Hacker News

• No comparto la mentalidad de ir “all-in” con los LLM. Trabajo como desarrollador iOS y sigo trabajando más o menos como siempre. Ahora uso LLM para crear rápido cosas como vistas temporales basadas en diseño. No son el núcleo de la app, sino pantallas secundarias como funciones nuevas o guías para instalar widgets. Antes eso me tomaba entre 30 y 60 minutos según la complejidad; ahora lo termino en 5 minutos. No me gusta el desarrollo web, pero ahí los LLM sí son bastante útiles. También los uso en cambios grandes, pero luego reviso yo mismo y hago commit en git. El problema es que, si confías solo en el LLM y no controlas el flujo, puedes perder horas y terminar empezando de cero. Creo que lo importante es mantener un enfoque equilibrado

  • La utilidad de la herramienta depende de la persona y del problema. Por ejemplo, si un desarrollador Python con 10 años de experiencia trabaja sobre una enorme base legacy, con un IDE perfectamente adaptado y tareas enfocadas en estabilidad, herramientas como un LLM o Cursor incluso podrían estorbar. En cambio, si un desarrollador JS de 1 año de experiencia (React, Nextjs, etc.) prototipa ideas nuevas con frecuencia, no tiene una preferencia fuerte por su IDE y está abierto a experimentar, entonces LLM y Cursor pueden aumentar muchísimo su capacidad de inmediato

  • Yo también trabajo en varias áreas (iOS, desarrollo web, etc.), y los resultados del LLM son bastante distintos entre una y otra. Muchas veces el código que genera ni siquiera compila bien. Incluso me ha sugerido APIs que no existen. En cambio, con apps de Nextjs suele acertar de una sola vez. Al final eso refleja diferencias en los datos con los que fue entrenado el LLM

  • Es natural sobreestimar las capacidades de los LLM. Yo también los usé bastante tiempo como reemplazo de Stack Overflow y para sacar snippets cortos. Poco a poco les fui delegando más responsabilidad, luego me topé con problemas, entendí sus límites y volví a usarlos más para ideas y consejos. Creo que mucha gente pasa por ese mismo proceso

  • Yo siento algo parecido. No confío ciegamente en los LLM y solo los uso para tareas repetitivas y aburridas (funciones pequeñas, implementación de interfaces, automatización de documentación, etc.). Con eso he ahorrado mucho tiempo y he mejorado mi eficiencia en el trabajo

  • En desarrollo iOS, el rendimiento de los LLM es muy inconsistente. Swift y SwiftUI cambian demasiado rápido, y una de las causas es que la documentación oficial también es floja. Para generar vistas simples sirven, pero en procesamiento asíncrono o lógica de negocio compleja se rompen fácilmente. Aun así ayudan a orientar, aunque también es muy fácil que te arrastren a resultados equivocados o puro humo

• Quienes defienden los LLM suelen pasar por alto que la mayoría de los cuellos de botella no están en generar código. Tan importante como escribir código rápido es dedicar el doble o más de tiempo a revisión de código, pruebas y comprensión del codebase. A largo plazo, si quieres mantenerlo bien —corrección de bugs, refactorización, etc.—, ese proceso es indispensable

  • Leer código es mucho más difícil que escribirlo, así que en la práctica paso mucho más tiempo tratando de entenderlo. Pero un CEO con el que hablé decía que, si se le da el contexto a la herramienta, los desarrolladores ya ni tendrían que leer código. Su argumento era que la IA está cambiando la esencia misma de la ingeniería. Honestamente, me deja bastante confundido

  • Cuando el LLM me vuelve a explicar mi propio código, sí me parece bastante útil

  • Pienso lo mismo cada vez que alguien elogia demasiado a los editores de código automatizados

  • Siendo realistas, a la mayoría de los desarrolladores no les importa tanto la implementación interna de las librerías de dependencias. Lo importante es si la interfaz funciona. Hay una gran diferencia entre traer código generado por un LLM y añadir un paquete npm o un crate de Rust. Sé que hay problemas, pero también hay una razón por la que esta práctica está tan extendida

• Yo también lo veo parecido. Últimamente uso LLM sobre todo para aprender tecnologías nuevas o para generar código cliente de APIs estándar, especialmente boto3. También probé Windsurf para ayudar con cambios en archivos de docker compose, pero me decepcionó porque no funcionó bien. Puede que sirva para prototipos, pero eso no lo es todo. Sí creo que los LLM cambiaron el panorama en devops (ahora importan menos los detalles finos de la API). Aun así, las decisiones importantes las sigo tomando yo. Defino yo mismo las interfaces y dejo al LLM solo la implementación. No considero que eso sea “vibe coding”

  • A mí me pasó algo parecido. Cursor y Copilot son fantásticos para autocompletado inteligente, generar funciones cortas y hacer prototipos rápidos. Pero después de pasar una semana trabajando en un codebase guiado por LLM, la estructura terminó hecha un desastre. Tal vez el verdadero avance llegue algún día, pero por ahora (mayo de 2025) este es el nivel

• En una revisión de código explotó un bug enorme, y la eficiencia que había ganado usando Cursor desapareció en un instante. Volví a VSCode y ahora uso Copilot de forma limitada, solo cuando le pido algo muy específico. La función de completar con tab en Cursor al principio se siente mágica, pero pronto ese efecto se desvanece

  • Lo más divertido es ver cómo Cursor, con autocompletado por tab, intenta volver a escribir código que un compañero acaba de borrar

  • Me da curiosidad saber qué restricciones le dieron al agente generador de código (por ejemplo, principios SOLID, lint, cobertura al 100%, documentos de diseño claros, etc.)

• Es una opinión con la que también conecto. Yo uso muchísimo los LLM, pero sigo dos reglas. Nunca les dejo problemas que requieran pensar a fondo (el diseño complejo siempre lo resuelvo yo). Y segundo: cualquier código que produzcan lo reviso y corrijo cuidadosamente línea por línea. Normalmente el código generado por LLM es verboso o demasiado defensivo. Aunque lo ajustes por prompt, al final la responsabilidad del mantenimiento futuro sigue siendo mía. Si uno se vuelve descuidado con lo que generan, queda una sensación de inseguridad. Usándolos a mi manera, sigo aprovechando mucho los LLM y aun así desarrollo más rápido

  • Yo sí delego el análisis profundo a la IA, pero con el objetivo de obtener planes de ejecución concretos (pasos detallados de implementación, criterios de validación, etc.) y redactar reportes reproducibles. Tanto la planificación como la validación requieren iteración, pero con ayuda de la IA lo termino mucho más rápido. A veces incluso sale todo de una sola vez siguiendo el plan. Tener consistencia gracias a planes y documentación detallados resulta muy satisfactorio

  • Si tienes que revisar con tanto cuidado, línea por línea, el código que hizo el LLM, entonces surge la duda de si de verdad ahorra tiempo

• Algunas empresas están obligando a los ingenieros de software a usar LLM (miden el uso de Copilot/Cursor). Es muy probable que esas métricas acaben usándose como indicador para despidos. Después de usar LLM a la fuerza durante un mes, sentí que mis habilidades se deterioraban rápidamente. Ayuda en cosas simples, pero si dependes demasiado del LLM hasta para pensar, es muy fácil quedar atrapado en un loop. Mi productividad no subió; al contrario, solo aumentó la carga del sprint. Dentro de la empresa hay una fe casi religiosa en los LLM. Los problemas de seguridad también son graves. Por todas partes veo señales de que estamos en la cima del ciclo de hype. A menos que las empresas de IA construyan centrales nucleares, creo que mantener estos grandes modelos de IA cuesta tanto que terminarán desapareciendo. Lo único que probablemente sobreviva será algo tipo autocompletado turbo. Los modelos transformer también tienen límites claros, así que acabarán quedándose en usos específicos, como pasó con las redes neuronales en los años 80, y luego volverán a desaparecer. Después de varios altibajos, resurgirán otra vez dentro de 30 años. Cuando eso pase, se sabrá quién estaba nadando sin traje

  • Para evitar justamente eso, tenemos una regla interna de trabajar una vez por semana con Copilot completamente apagado: “no Copilot Fridays”

  • Yo también uso Cursor solo para autocompletado y snippets cortos, y aun así siento que se me debilitan las habilidades. Al final uno comprueba en carne propia cómo funciona el cerebro: “si no lo usas, lo olvidas”

• Yo también he visto problemas parecidos. En proyectos de juguete uso LLM en un 90%. Es 10 veces más rápido que programar a mano, pero la calidad del diseño baja y todo se siente algo extraño. Sí creo que el código guiado por LLM es el futuro, pero si no lo gestionas bien acabas en el caos. He intentado ir cambiando prompts para inducir mejoras iterativas en la arquitectura, pero los resultados son irregulares. Quizá la respuesta sea mejor prompt engineering, o documentar con claridad el diseño y las reglas. Si las herramientas se vuelven 10 veces más rápidas y baja la latencia, la percepción cambiará por completo

  • Ojalá llegue pronto esa etapa de “10 veces mejor”. El problema ahora es que el ambiente publicitario ya actúa como si hubiéramos llegado a ese punto. Mucha gente termina pensando “¿será que yo lo estoy usando mal?”. Pero yo no creo que la herramienta todavía esté a ese nivel

  • Conviene definir uno mismo las clases y métodos, y dejarle al LLM solo la implementación. En las partes complejas, puedes anotar dentro del cuerpo del método la dirección que debe seguir la implementación. Así tú mantienes la visión general y el LLM solo se encarga de generar código puntual. El LLM se siente como un desarrollador junior rápido que se esfuerza demasiado por ayudar. Como generar código ya es tan barato, puedes desecharlo y rehacerlo cuantas veces quieras. En mi caso, con ayuda del LLM tiré y reescribí varias veces por completo código de procesamiento de datasets, y al final logré justo el resultado y el rendimiento que quería. Si me lo hubiera escrito otra persona, probablemente habría desistido

  • Estas herramientas brillan en la fase de prototipo de un proyecto greenfield. Pero cuanto más te acercas a producción, más se va desvaneciendo ese efecto de 10x. Si no gestionas la arquitectura con cuidado, al final solo te generan más trabajo

  • En codebases complejos, por ahora solo sirven como una especie de entrada avanzada de voz a texto (aunque, si no es por voz, muchas veces escribir el código a mano sigue siendo más rápido)

  • Coincido en que hay que dejar explícitas la arquitectura y las guías. Cuanto más explícitamente definas las condiciones y el comportamiento, más efectivo resulta

• La vieja obra clásica de Dijkstra, “On the foolishness of natural language programming”, encaja bien con esta discusión. Su idea central era que solo los lenguajes formales hicieron posible el enorme progreso de la programación. Visto así, existe el riesgo de que los LLM y el vibe-coding conviertan programar en una especie de magia reservada para una minoría que sabe promptar bien

• Para mí, Copilot solo funciona bien cuando sugiere menos de 500 caracteres de código. En Go y Python me ayuda a aprender patrones nuevos y a teclear menos. Para mí es simplemente un mejor autocompletado. Si la sugerencia es más larga o compleja, el costo de corregirla y señalarle errores supera el beneficio, especialmente cuando no se trata de código repetitivo

• Por ahora, es indispensable entender y supervisar de cerca lo que generan los LLM. Al mismo tiempo, cada 2 o 3 semanas sale un modelo nuevo mucho mejor que el anterior, así que creo que todavía es pronto para sacar conclusiones demasiado firmes.

[sharpina3]

Creo que es un texto que refleja muy bien las dificultades y preocupaciones reales en el desarrollo usando LLM. Lo leí sintiéndome identificado con las limitaciones que muchas personas están experimentando actualmente. En particular, sentí que es imprescindible señalar temas como la inconsistencia de los LLM, la dificultad para predecir sus resultados y las preocupaciones desde la perspectiva del mantenimiento a largo plazo.

Dicho esto, nosotros estamos intentando colaborar con la IA desde un ángulo un poco distinto para abordar estos problemas, así que comparto nuestra perspectiva con cautela. Nuestra IA, Jane, no se limita simplemente a generar código; más bien, se enfoca en aprender y comprender el propio "patrón": qué constituye un "buen patrón de código" a partir de la profunda intuición de las personas (desarrolladores), y cómo se puede asegurar la "consistencia de mantenimiento" del código.

Como la IA no puede ser perfecta desde el principio, no vemos las inconsistencias ni los "errores" que surgen como simples problemas; al contrario, los aprovechamos activamente como datos de patrones importantes para que Jane aprenda por sí misma y se mejore a sí misma. Así como los humanos leen patrones dentro de una naturaleza compleja, nosotros adoptamos un enfoque que busca pistas de mejora dentro de la imperfección de la IA.

A través de este enfoque de "aprendizaje/gestión de patrones" liderado por humanos, buscamos resolver de raíz problemas como el deterioro de la calidad del código y las inconsistencias señaladas en el artículo, y producir resultados con una "consistencia de mantenimiento" muy alta. Estamos entrenando a la IA para que vaya más allá de simplemente generar código boilerplate y se convierta en un socio de colaboración más profundo, capaz de analizar patrones ocultos de inconsistencia en la base de código existente y proponer formas de mejorarlos.

Todavía queda mucho camino por recorrer y es un proceso desafiante, pero creemos que esta forma de colaboración, en la que nuestra Jane y los desarrolladores aprenden y evolucionan juntos teniendo la "consistencia de mantenimiento" como valor central, muestra una posibilidad revolucionaria para superar las limitaciones actuales del uso de LLM. Más que usar la IA solo como una herramienta, esperamos que haya mucho interés en nuestro intento de convertirla en un socio que crece junto con nosotros y ayuda a construir una mejor cultura de código.

¡Gracias de nuevo por el buen texto y los valiosos insights!