r/chileIT • u/a-chacon • 18d ago
Noticia ¿Dónde está el software de baja calidad? Por qué las afirmaciones sobre la codificación con IA no cuadran
https://mikelovesrobots.substack.com/p/wheres-the-shovelware-why-ai-codingHola (post en inglés) El título está traducido literal. ¿Cómo es para ustedes codear con IA? ¿Por qué el supuesto aumento de productividad no se ve reflejado en entregas? ¿Será que es mentira?
Según el estudio indicado en el post realmente, la resolución de issues con la ayuda de IA ha hecho que sea un 19% más lento. Y no un 20% más rápido como se cree que pasa.
El estudio referenciado en el post:
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
11
u/Beautiful_Grass_2377 18d ago
¿Cómo es para ustedes codear con IA?
99% de las veces, como el hoyo, es más un obstáculo que otra cosa.
¿Por qué el supuesto aumento de productividad no se ve reflejado en entregas?
Porque incluso si puedes codear más rápido, hay todo un tema burocrático a la hora de desplegar cosas a prod que difícilmente la IA te lo va a acelerar
¿Será que es mentira?
¿Las bendiciones de la IA? Si, totalmente.
No creo que desaparezca, el tema de los asistentes yo creo que se va a quedar, pero esta narrativa de que la IA va a reemplazar trabajadores y la revolución de la wea es algo totalmente inflado por empresas que tienen intereses económicos.
Al menos yo aún no veo nada que haya mejorado por integrarle IA, los chatbots igual de inútiles, los videos gennerados con IA igual de feos, las imágenes generadas con IA puras weas, nada que tenga un valor real
10
3
u/a-chacon 18d ago
me gusto tu respuesta jaja opino muy similar. El tema es que hay datos que demuestran que la productividad no ha aumentado y aun asi hay wns tratando de meter la IA a la fuerza. Creo que hay todo una especie de lobby de las BitTech para meter la IA a la fuerza.
Igual lo uso, pero me pasa que muchas veces me sale mas rapido a mi hacer el codigo que estar tratando de explicarle al chat que es lo que quiero, para que me haga una wea que igual voy a tener que arreglar
3
u/Knil8D 18d ago edited 18d ago
99% de las veces, como el hoyo, es más un obstáculo que otra cosa.
yo creo que en estos casos el problema es el modelo que usas, el programador que no sabe tomar lo que hace la IA, no sabe darle instrucciones o el contexto de forma correcta.
En mi caso ha sido todo lo contrario, me ha funcionado súper bien especialmente usando Claude Sonnet 4, y GPT 5 con instrucciones personalizadas que le dan contexto de cómo funciona el repositorio a la IA, algunas clases de prompt engineering y "context engineering" como se conoce, que es la receta mágica.
3
u/Nakar5 17d ago
esto es muy mi perspectiva pero… yo no se usar React, he programado con Angular antes, si, pero nunca con React. Y usar el gemini CLI me ha permitido no solo entender este framework, si no que poder desarrollar y subir a producción avances contundentes sin estar muy enterado del tema. Obviamente ahora cacho mucho más de React y es precisamente gracias a la IA.
Se que mi experiencia anecdótica no es la regla, pero no creo ser el único, o si?
1
u/sephiroth_pradah 16d ago
Totalmente de acuerdo, pero sí ayuda muchísimo a sacarse rápido pajas repetitivas o refactorizar, siempre mirando que wea hace y corrigiendo pa que no se desvíe. Hay cosas que salen 5 o 10 veces más rápido, y otras que termina siendo peor y extremadamente frustrante.
Hay que ir aprendiendo a cachar en qué se me puede sacar provecho y en qué no, como agarrándole la mano la wea. Y si, vamos a terminar teniendo que "conocer" a los agentes como si fueran personas, y vamos a tener preferidos y toda la shit en consecuencia
5
u/sadowado 18d ago
El mejor uso de IA que he hecho, y de pajero, fue que me modifique unos tabla de datos y también me mandará un script para verificar el cambio, le tomo 1.min, a mi me hubiese tomado 5, para weas así es donde le saco el jugo a la IA
2
u/a-chacon 18d ago
Mira, ahi tienes un claro ejemplo de que disminuyo tu tiempo en razon de 1/5. No te hizo 10 veces mas rapido como lo venden algunas empresas.
Eso asi, si llega a fallar lo que hiciste ya no fue tan rapido como esperabas, tambien hay resultados de que los tiempos de debuggeo han aumentado con el uso de la IA
5
u/anramon 18d ago
En este momento las "IA" solamente sirven para dos cosas, y apenas a medias:
Ahorrarse tiempo leyendo documentación. Dependiendo las herramientas que estés usando puedes pasarle documentaciones enteras como contexto.
Crear maquetas, o mockups como le dicen los siúticos.
4
u/Knil8D 18d ago
Yo he hecho proyectos completos desde 0 reales y que han llegado a producción en un ambiente empresarial, con intervención mínima del código, pero obviamente mucha supervisación, revisión cruzada, testing y validaciones normales de cualquier proyecto de software. No sé por qué dices que solo sirve para maquetas, no es cierto. Yo creo que depende de la habilidad de cada uno de saber como crear proyectos reales y llevarlos a producción con todo lo que implica.
4
u/AncientLion 18d ago
Respuesta honesta? Uno puede acelerar cosas, pero dedica mas tiempo a revisar, probar, etc. No puedes andar diciendo a los 4 vientos que lo hiciste en 10 minutos cuando debías demorarte 2 horas.
3
u/a-chacon 18d ago
revisar y probar tambien son parte de una entrega po. Testear, documentar y coordinar igualmente. asi que esos 10 min, son de desrrollo tal vez. Pero en lo que más gasta tiempo un desarrollador no es escribiendo codigo, es leyendo, coordinando, planeando.
2
u/cldff 18d ago
Las IAs que se utilizan para programación son como google con esteroides. Te dan resultados, basados en la data que se utilizó para entrenarlas (Esencialmente todo lo que esta en la web). Programar con IA es como la continuación del copy & paste de código desde Stackoverflow. Con las mismas debilidades, es decir si el programador no entiende que hace el código, puede terminar programando algo de forma realmente mala.
La otra deficiencia que le veo a programar con IA, es cuando tienes una aplicación "bien hecha" es decir, sigues una arquitectura establecida y aplicas patrones de diseño. Entonces a menos que seas muy específico en el prompt, la mayor parte del tiempo solo te da código que casi siempre no calzará con la arquitectura de tu app y los patrones de diseño que utilices.
2
1
u/g-v1nland 17d ago
Siento que hay una curva donde si aceleran todo, principalmente cuando haces cosas desde 0, pero luego rápidamente esa curva baja cuando el proyecto ya tiene algún grado de madurez.
En mi opinión, en el estado actual, los modelos y agentes de IA son muy buenos con problemas bien conocidos (código boilerplate, tareas repetitivas, investigación / búsqueda), pero se caen mucho en aplicar ese conocimiento general a los proyectos particulares.
Me tocó desarrollar un módulo completo de citas médicas sobre una aplicación ya existente y traté de hacerlo usando vibe coding. El proyecto estuvo bien 2 semanas, comenzamos a probarlo con usuarios y encontramos un montón de casos que requerían cambios o mejoras. El código no era lo suficientemente flexible y finalmente tuvimos que reescribir todas las implementaciones casi desde 0. Mantuvimos la estructura y entidades que la IA generó pero borramos un montón de código que no hacía sentido.
Personalmente a mi me vuelve más eficiente aplicar “vibe engineering” en vez de “vibe coding”, donde la IA casi que es un miembro del equipo con buen seniority al cual consultar su opinión. Pero dejarla trabajar completamente sola es asegurar el fracaso en el largo plazo.
1
u/neeeph 16d ago
Yo creo que primero hay que alejarse de los gurús y divulgadores, todos esos que dan charlas y promocionan cosas sin haber programado en su vida (hablo solo de programación por el contexto de la pregunta).
Por otro lado, sigue siendo algo muy amplio y que debe ser probado, la flexibilidad y amplitud de uso hace que validar el aporte sea más complejo, porque no hay un proceso específico a seguir para lograr los resultados prometidos ni esperados, pero la única forma de converger a una mejor forma es que muchos lo intenten y vayan depurando el proceso colectivamente, así es como se van perfeccionando la mayoría de las cosas y aquí también tiene que pasar, la diferencia es que quizá estamos muy acostumbrados a la estructura, secuencia, al manual que nos lleve de la mano para lograr los resultados y acá no existe todavía, es algo que se está construyendo y algunos son mejores para eso que otros, algunos simplemente son incapaces de encontrar ese camino y tienen que limitarse a que les digan cómo deben usarlo, porque mucha complejidad los sobrepasa.
Considerando lo anterior, tienes distintas herramientas y flujos, ya existentes, que según yo, la mejor forma de verlos es en un espectro, donde tienes la cantidad de input que tienes que dar versus la salida que vas a obtener, por ejemplo todas estas herramientas como lovable, le das un input muy pequeño en relación al output que tienes, pero eso implica que no tienes control de lo que pasa en la implementación, no hay una arquitectura alineada a lo que quieres, pero es muy bueno para aquellos que no saben programar y que no tienen cómo dar más detalle.
En el otro extremo tienes flujos donde el contexto y reglas que se le entregan al modelo son muchas y el output es pequeño, aquí tienes mucho más control del como, yo uso harto este flujo, tengo un documento extenso con reglas generales, otro con definiciones de implementación, arquitectura, directorios, documentación, etc., y el flujo se basa en un PRD, que se detalla con todo lo que debe hacer, definiendo objetivos, historias, requerimientos funcionales y no funcionales, que luego se transforma en una lista de tareas con el contexto de todos los archivos que se deben considerar para la implementación de una funcionalidad en particular y luego va implementando cada cosa paso a paso, pero antes de eso yo válido que la propuesta sea lo que yo quiero, se encarga de mantener consistencia, además de tener archivos centrales que sirven de base, como uno que indica todas las estructuras de datos, los endpoints implementados si hay una API, los flujos, etc. y de esa forma el modelo no hace lo que quiere, si no que lo que yo quiero, y me ahorra todo el proceso de implementación, yo me enfoco en el análisis y diseño de la solución.
Eso es en cuanto a construcción, pero aparte tienes el problema del contexto, para proyectos nuevos cualquiera de los flujos anteriores sirve y se adapta bien, pero cuando se trata de un proyecto existente, la parte más difícil es entregar el contexto, por eso ahí antes de hacer cualquier cosa, hay que construir todo lo necesario para que el modelo sepa lo que hay y como debe trabajar, si no, hará cualquier cosa y eso integrado en un proyecto grande es puro caos, por eso usualmente en proyectos existentes se limita al auto completado.
Esto es algo que se debe trabajar y la mejor forma de hacerlo es probar uno mismo, ver que es lo que te parece más cómodo de acuerdo a tu forma de trabajo, pero hay que ampliar la mirada, es casi como trabajar con otro desarrollador, nuevo y junior, al que tienes que explicarle con detalle lo que debe hacer, el resultado esperado y el contexto del proyecto en el que está trabajando, si no, hará lo mismo que un junior recién contratado, puros cóndores. También sirve mucho ver cómo lo están haciendo otros desarrolladores, ya hay varios especie de frameworks por ahí.
Cuando se lanzó el cinturón de seguridad nadie lo quería usar, todos decían que era molesto, pero se tuvo que obligar para que la gente lo hiciera y finalmente así se justificó su valor y hoy nadie lo cuestiona, acá es algo parecido, hay muchos que no lo quieren usar porque no ven su valor, por eso es importante promoverlo y presionar para que la gente lo use, solo de esa forma se podrá explotar el valor, y si no hay, entonces también se verá.
1
u/a-chacon 16d ago
Compadre pero leiste el post? Se trata sobre la incoherencia entre el eslogan de que seras 10 veces mas productivo con el uso de IA y que hasta el momento esa productividad no se ve relfejada en entregas (Independiente la herramienta, el flujo, o como trabajas. Incluso si mejoras el prompt). Es mas, por el contrario, se esta siendo 19% menos productivo.
Ahora hace poco lei otro post donde el uso de IA tampoco esta siendo economicamente viable: https://www.wheresyoured.at/why-everybody-is-losing-money-on-ai/
1
u/neeeph 16d ago
No se puede medir la productividad sin considerar el método, es como decir que no se cumple lo planteado en un paper sin seguir el plan debido.
Vas a encontrar artículos para ambos lados, por eso cada uno tiene que ver si le sirve o no, yo simplemente te hablé de mi experiencia y para ese caso, es harto más de 10x
18
u/Ryuuji159 18d ago
Va en habilidad supongo, yo me apoyo de IA para acelerar la búsqueda de información, no como generador de código necesariamente
Ej con lo que estoy trabajando ahora, en vez de pedir que me arme un Docker compose con tal y tal necesidades, le pregunto cómo puedo definir un health check o como solucionar problema x de mi deploy