Usar IA o no usarla

• Se realizó un experimento de 2 semanas para crear una app usando únicamente un flujo de trabajo de desarrollo asistido por IA, pero el resultado no fue tan satisfactorio como se esperaba
• Se repitió el proceso de definición de issues → implementación con IA → revisión de código → despliegue usando un stack basado en Claude Code y Remix
• Sin embargo, la frustración fue aumentando por la falta de contexto, la duplicación de código no reutilizable, la interrupción del flujo, las alucinaciones (hallucination) y el problema de la ley de Pareto
• Al final, después de 2 semanas, se abandonó el desarrollo centrado en IA y se volvió al método tradicional, logrando mayor satisfacción al ordenar el código y mejorar su calidad
• Actualmente, la IA solo se usa de forma limitada para búsqueda, rubber ducking, snippets de código, pruebas y corrección de lenguaje, y no hay planes de ampliarlo hasta que ocurra un cambio tecnológico de fondo

---

Resumen del experimento

• Se llevó a cabo un experimento de 2 semanas de desarrollo de una app aplicando directamente el flujo de trabajo de desarrollo con LLM (modelos de lenguaje grandes), que ha recibido mucha atención recientemente
• A partir de la compleja experiencia de UI de las cuentas de Facebook Ads, se inició el desarrollo del prototipo de adbrew, una herramienta simplificada de gestión de anuncios que usa únicamente la Facebook Ads API
• El experimento se realizó con el objetivo de verificar el potencial de la IA y con la expectativa de resolver problemas reales

Enfoque

• Se eligió el stack técnico tras seguir varias cuentas relacionadas con IA e investigar distintos flujos de trabajo, optando por Remix/React Router v7
• Después de suscribirse a Claude Code, se invirtió tiempo en la configuración inicial: prompts, herramientas de DX, definición de issues y otros ajustes del entorno
• Rutina diaria
  • Definición de issues
  • Solicitar a la IA la implementación
  • Ajustar requisitos con la IA
  • Revisar en detalle el código generado
  • Hacer commit y desplegar el código
  • Repetir el proceso
  • Mejorar periódicamente las guías y los archivos de verificación automática
• Se mantuvo de forma continua el esfuerzo por alinear el flujo de desarrollo con la IA

Problemas frecuentes

1. Siempre falta contexto
   • Aunque se proporcionara mucho contexto, la IA no solicitaba retroalimentación sobre los requisitos
   • La IA avanzaba haciendo suposiciones arbitrarias, lo que terminaba produciendo implementaciones erróneas con frecuencia
2. Código sin reutilización ni mantenibilidad
   • Deficiencias en abstracción y generación de código reutilizable
   • Creación repetida de componentes existentes, lo que aumentó la fatiga en la revisión
   • El efecto de incorporar lineamientos fue mínimo
3. Interrupción del flujo de trabajo
   • Era necesario monitorear constantemente el trabajo de la IA
   • Resultaba difícil asegurar bloques de concentración eficientes por issue, con la consiguiente caída de productividad
4. Fenómeno de alucinación (Hallucination)
   • Combinado con la complejidad de la Facebook API, la escasa documentación y un SDK mal tipado, la confianza errónea de la IA aumentó la confusión
   • Generó repetidamente información incorrecta sobre distintos frameworks y librerías
5. Profundización del efecto Pareto
   • La IA podía avanzar rápido en el 80% del trabajo, pero el 20% restante de finalización y corrección requería el 80% del esfuerzo
   • Aparecieron muchos defectos y bugs importantes en el manejo de excepciones y en la interacción entre funcionalidades

Resultados y retrospectiva

• Después de 2 semanas, el código se fue volviendo cada vez más desordenado e incontrolable
• Debido a la pérdida de disfrute en el desarrollo y a los problemas de calidad, se regresó al flujo de trabajo tradicional
• Al reorganizar el código manualmente, se encontraron partes que la revisión de la IA había pasado por alto, y como resultado se obtuvo una mejor base de código

Forma actual de usar la IA

• Motor de búsqueda potente: eficiente para explorar información compleja y obtener respuestas ajustadas al contexto; si falla, se puede volver rápidamente al método tradicional
• Rubber ducking (lluvia de ideas): especialmente efectivo para proponer alternativas, ampliar el rango de exploración y reforzar la búsqueda de palabras clave relacionadas
• Asistente de snippets de código: automatiza la creación de funciones utilitarias repetitivas y reduce la fatiga del desarrollo
• Apoyo para código de pruebas: se usa IA para descubrir nuevos escenarios de testing
• Tareas relacionadas con el lenguaje: útil para editar textos como mensajes de commit, issues y PR
  • Últimamente, en lugar de que la IA redacte, se ha invertido la dinámica: el desarrollador escribe y la IA revisa

Conclusión y perspectiva

• Se seguirá usando IA para apoyo en tareas cotidianas, pero por ahora la postura es negativa respecto a ampliar su uso hacia la delegación de todo el proceso de desarrollo
• Se está priorizando el uso de LLM locales y el mantenimiento del control sobre los datos
• Se seguirá observando la posibilidad de cambios tecnológicos futuros, pero por ahora se planea mantener un uso limitado de la IA

[shakespeares]

Es una desventaja que se siente muchísimo al trabajar en tareas complejas.
Pérdida de disfrute + código hecho un desastre..
Muchas veces realmente parece que no es adecuado usarlo más allá de refactorizar código y para generar ideas.

[GN⁺]

Opiniones de Hacker News

• Hace poco pasé más de una hora intentando pedirle a ChatGPT un comando de rsync muy simple, pero seguía dándome parámetros que no funcionaban con la versión de rsync que tengo en mi Mac. Como la mitad del fracaso se fue en troubleshooting absurdo, y la otra mitad en que “se daba cuenta” de su error para luego dar otra respuesta equivocada para otra versión. Le indiqué que validara los parámetros contra la versión que yo tenía, pero claramente no pudo hacerlo. En realidad, si lo hubiera hecho solo, lo resolvía en 5 minutos, pero me quedé viendo cómo esta tecnología tan fascinante desperdiciaba mi tiempo sin poder parar. No soy desarrollador profesional, pero me pregunté si este tipo de experiencia también es común entre desarrolladores. Tal vez si programas con versiones de software que coinciden con el principal conjunto de entrenamiento del LLM no te pasa esto, y me pregunto si hay alguna forma de evitarlo con prompts. Por ahora, me cuesta ver que los LLM realmente ahorren tiempo en tareas de programación; más bien creo que, por su naturaleza tan peculiar, hacen que uno pierda más tiempo.

  • Aunque le pida al LLM que valide los parámetros para mi versión, no lo hace bien. Me interesa la opinión de expertos en IA sobre este punto; a mí también me pasa mucho. Al final, el LLM no está entendiendo de verdad lo que uno dice. Matemáticamente se puede explicar por qué. Pero al mismo tiempo, parece que en tareas menos vergonzosas que contar letras sí se le han añadido tecnologías como transformers o algunos trucos aparte. Me pregunto si se me está escapando algo.

  • Entre desarrolladores esta experiencia también es muy común. Alguien podría decir “a mí nunca me ha pasado”, pero sería una excepción mínima; la mayoría se queja de cosas parecidas. También preguntaste si se puede evitar con prompts, pero si no está en los datos de entrenamiento, no sirve de nada. En muchos lenguajes los LLM son realmente malísimos. En herramientas CLI, aunque le digas al LLM que estás en macOS o en una versión BSD, muchas veces igual te sigue dando flags de GNU. En macOS, en particular, hace poco cambió rsync, así que tampoco hay mucha información en línea. Ver el enlace: artículo sobre el reemplazo de rsync, y además la idea de que los LLM te van a ahorrar tiempo programando ya es el best case. Más bien, hay muchos casos en que la gente confía ciegamente en código generado por LLM, lo commitea y termina introduciendo bugs o vulnerabilidades de seguridad. Referencias: blog ai-coding-slowdown y paper en arXiv

  • No estoy seguro sobre si se puede evitar esto con prompts, pero en Claude Code puedes ejecutar comandos directamente. O sea, en vez de dejar que el LLM se imagine cualquier cosa, le agregas al contexto la salida real de comandos como ! man rsync o ! rsync --help.

  • Si de todos modos vas a buscar el manual de una herramienta específica, me pregunto por qué usar un LLM para eso.

  • Sobre lo de haber pasado más de una hora intentando sacar un comando simple de rsync con ChatGPT: yo intentaría varias veces agregando suficiente información del entorno y mensajes de error, y si aun así no funciona, probaría otros modelos como Claude o Gemini. Si después de cierto número de intentos no se resuelve, entonces ya no vale la pena seguir buscando ayuda en un LLM; es mucho más rápido pasar al manual, foros u otros métodos tradicionales. Un criterio realista es probar unos 10-20 minutos y luego seguir adelante. Hay problemas que el LLM no va a resolver por más tiempo que le dediques, y solo se queda dando vueltas.

• A mí también me pasa mucho. La IA realmente ayuda cuando le pides tareas que yo ya sé hacer. Si puedo describir el problema con suficiente precisión para que el LLM lo entienda, entonces suele dar un resultado razonable, y yo puedo revisar enseguida si el código generado es lo que quiero. Pero si le delegas algo que no conoces en absoluto, termina siendo más complicado.

  • Creo que este texto (excepto el título) tiene una visión bastante equilibrada. “¡Déjale todo al LLM!” está lleno de problemas, mientras que “usar IA para ahorrar tiempo en código repetitivo o en parte del código de pruebas está bastante bien; solo que con un título normal como ‘a veces la IA funciona y a veces no’ jamás vas a conseguir clics”.

  • La IA se siente más como un intern que como un contratista.

• Conecto mucho con la idea de que “la información contextual no es suficiente”. Por más contexto que metamos, la mayoría de las veces la IA no pide retroalimentación y se pone a adivinar por su cuenta hasta fallar. Me acordé de una escena de una serie donde alguien le pide un deseo a un genio y tiene que hablar como abogado, revisando cada condición con extremo cuidado. Hablar con un LLM se siente parecido.

  • La IA es como ese compañero de trabajo súper inteligente que nunca dice lo que realmente piensa. Parece que podría hacer cualquier cosa, pero no sirve para trabajar en equipo, y jamás sale con algo como “no entiendo qué quieres aquí, explícame un poco más”.

  • (Creo saber qué escena de TV era esa.) En esa escena al final sí salió bien, pero creo que un LLM no siente ninguna necesidad de cumplir sus “promesas”. Más bien, el genio se parece más a una IA clásica de ciencia ficción, atrapada por normas y reglas. Un LLM es totalmente distinto.

• No me gusta mucho eso de hacer vibe coding, de comunicarme con la IA más que programar de verdad. En cambio, lo que más he cambiado es estructurar el proceso de desarrollo desde más temprano. Primero escribo un archivo de especificaciones, luego hago que el LLM identifique qué partes de los requerimientos hay que describir con claridad usando el codebase y la información en línea, y que divida la implementación en una checklist paso a paso. Solo después de terminar cada etapa paso a la siguiente sesión y voy puliendo el resultado. Si me agota conversar con la IA, entonces yo mismo o alguien del equipo puede implementarlo siguiendo la especificación, así que se puede usar de forma flexible.

• Hace poco incorporé IA al desarrollo en un proyecto. No sé exactamente qué significa vibe coding, pero el enfoque que elegí fue una interacción repetitiva y relajada. Usé Gemini AI studio y quedé muy satisfecho con el resultado, al punto de documentar todo el proceso y publicarlo como proyecto open source. Me dio un boost de productividad claramente visible. Lo único que me molestó fue que la IA hablara con demasiada cortesía. En mi opinión, la IA tiene el mayor ROI cuando el resultado deseado está claro y durante el proceso hay que comparar alternativas. La usé para todos los entregables del proyecto (código core, casos de prueba, scripts de build, documentación, app de ejemplo, utilidades). El registro completo de conversaciones de desarrollo puede verse aquí, y el código fuente del proyecto está aquí.

• Yo uso la IA de manera parecida. Esperar de la IA abstracciones revolucionarias es pedirle demasiado. Funciona bien cuando se trata de un camino totalmente común que ya recorrieron miles de desarrolladores. En ese sentido, se parece mucho a un motor de búsqueda extremadamente poderoso.

  • Creo que ChatGPT es básicamente el motor de búsqueda que Google debió haber construido. Me parece que Google lo fue postergando porque no quería afectar su negocio existente.

• Mi forma preferida es pedirle al LLM una primera solución o ejemplo de código de manera rápida, y después de eso ya no seguir refinando prompts, sino continuar yo mismo. Al final, si hace falta, le pido al LLM que revise mi código. La mayor ventaja es saltarme el loop de refinar prompts. Ese loop es realmente tedioso, consume muchísimo tiempo y, a largo plazo, incluso puede bajar la eficiencia del trabajo.

• Es muy frustrante que la IA simplemente siga adelante sin hacer preguntas claras ni pedir feedback.

• En mi equipo decimos algo como: “Por ahora solo usamos la IA hasta ese punto; si más adelante la tecnología cambia de manera fundamental, volveremos a evaluar la situación”. Me pregunto si los LLM podrán hacer más que eso. Aun así, creo que incluso ahora pueden ser muy útiles si se usan bien.

  • No entiendo la duda sobre si los LLM pueden llegar a hacer mucho más. A mí se me ocurren todos los días varias ideas nuevas para mejorar herramientas basadas en LLM, y la mayoría son tareas de ingeniería simples que podría construir yo mismo si quisiera. Aunque Dios prohibiera entrenar más modelos LLM de verdad, estoy convencido de que durante décadas todavía podríamos sacar aumentos de productividad de varias decenas de veces. Con procesos adecuados de desarrollo de software y QA, solo con mejorar wrappers agentic o pipelines ya hay muchísimo margen de crecimiento.

• Usar IA para mejorar los anuncios de Facebook es como los breakers de la serie Dark Tower.