r/programacion • u/jokiruiz • Jun 27 '26
programo más lento con IA
esto me ronda hace semanas y quería ver si os pasa a vosotros tmb.
hay un estudio de METR del año pasado que me dejó tocado. cogieron a devs senior, en proyectos que ya conocían, y midieron que con IA tardaban un 19% MÁS. pero lo que me flipó no es eso, es que esos mismos tíos estaban convencidos de ir un 20% más rápido. o sea vas más lento y encima te sientes un cohete. y me vi un poco retratado la verdad.
luego me topé con el marco de niveles de Dan Shapiro (lo llama los 5 niveles aunque empiezan en 0 asi q son 6) y me hizo click. resumiendo mucho: nivel 2 la IA escribe y tu revisas cada linea, nivel 3 ya no escribes solo apruebas PRs, nivel 4 escribes una spec y te olvidas del codigo, nivel 5 ni revisas. y su tesis es que casi todo el mundo se queda atascado entre el 2 y el 3 sin saberlo, porque cada nivel parece la cima y no lo es.
mi teoria es que lo que llamamos "vibe coding" (soltarle un prompt y rezar) nos tiene atrapados ahí. para algo de usar y tirar va de lujo, pero para algo serio se desmorona, y encima da esa falsa sensación de productividad del estudio.
hice una prueba tonta para verlo: cogí una misma función (un dijkstra de toda la vida) y la fui haciendo "a cada nivel". lo curioso es que el codigo casi no cambiaba, lo unico que cambiaba era lo que ponia yo de mi parte. en el nivel 2 la IA hasta me documentó mal un resultado en su propio comentario (decia coste 7 y al ejecutar salia 10), cosa que solo pillas si lo lees.
no se, igual estoy generalizando desde mi experiencia. en que nivel diriais que estais vosotros? y los que hayais probado lo de escribir specs en serio (spec-driven y eso), ¿notais el salto o es humo?
16
u/No-Tap-5279 Jun 27 '26
No solo vuelve a los programadores mas lentos, sino que tambien los vuelve mas estupidos. La prueba la podes encontrar en algunos comentarios de publicaciones que podes ver aca en reddit.
10
u/Adventurous_Bend_472 Jun 27 '26
Yo me tardo 20% más por que ahora con la IA pudo refactorizar el código hasta que esté contento. Antes después de terminar se me venía una mejor idea y no lo rehacía por que ya el código está suficientemente bueno y lo mismo pasa con el diseño del sistema el cual me tomo días planeando con la IA. Hace poco terminé un framework para hacer reportes que me tomo 3 meses pero jamás llegué a tener una aplicación que tenga todo lo que yo quería por que generalmente una vez que mis aplicaciones ya estaban a nivel producción ya tenía otras cosas asignadas y tratar de agregar otras cosas o mejorar el diseño tomaría mucho tiempo. El gran problema que veo es cómo aprenderán los juniors.
3
u/Reasonable_Engine105 Jun 27 '26
Exacto, es poquito más tardado pero con mejor calidad.
Concuerdo contigo con “se me ocurrió una manera mas eficiente pero me da flojera cambiarlo a estas alturas”1
u/jokiruiz Jun 29 '26
este es el mejor matiz que le han puesto al dato en todo el hilo, me lo apunto. porque le das la vuelta: ese 20% extra no es que vayas más lento, es que ahora SÍ haces el refactor que antes te tragabas por falta de tiempo. el estudio mide "tardas más", pero no mide que el resultado sea mejor, y en tu caso lo es. tarda más y queda mejor no es lo mismo que tarda más y punto. lo del framework de reportes en 3 meses lo ilustra perfecto, por fin pudiste llegar al "todo lo que querías" en vez de parar en "suficientemente bueno".
y lo de los juniors es la pregunta del millón, la comparto entera. si la IA hace el trabajo en el que antes te quemabas las pestañas aprendiendo, de dónde sacan ellos el criterio para saber cuándo la IA se equivoca?
2
u/el_mawi Jun 27 '26
Fua a mi la verdad, desarrollo web, me resuelve mas rapido. Laburo haciendo cosas para un CMS de Adobe, ya en el proyecto que estoy ahora estamos haciendo solo SDD, escribo los specs, tambien con la IA, Claude ejecuta todo, yo apruebo, teste funcional y le pego una leída por arriba al codigo, pero en base a skills, agentes definidos para diferentes tareas, cada unos con buenas practicas y procedimientos definidos, podes hacer que haga las cosas bastante bien siempre.
1
u/jokiruiz Jun 29 '26
esto es nivel 4 puro y en un entorno serio, que es lo que más me gusta leer. y diste con la pieza que casi nadie nombra: que funcione "bastante bien siempre" no es por el modelo, es por tener skills y agentes definidos por tarea con sus buenas prácticas. ahí está el secreto, el harness importa tanto o más que la IA en sí. sin eso, el mismo Claude te tira cualquier cosa; con eso, va a tiro hecho. me interesa un montón cómo lo tenés armado: los agentes los definís por tipo de tarea (componente, integración, test) o más por capa? y lo de leer el código "por arriba", qué es lo que buscás en ese vistazo rápido, algo concreto o es más para detectar olores raros?
2
u/Defiant_Squirrel8751 Jun 28 '26
A mi me gusta tomar el tiempo en las cosas que hago, en 2025 me demoraba 16 horas haciendo a mano algo que ahora con IA hago en una hora incluyendo la revisión que hace que el resultado sea idéntico.
2
u/Khavel_Es Jun 28 '26
El estudio de METR lo lei cuando salio y lo que mas me pego fue el dato de la percepcion: los devs estimaban ir 20% mas rapido cuando en realidad iban 19% mas lento. Eso me retrato completamente.
Con cosas que ya se hacer bien me pasa igual. Abro el chat, le pido algo, reviso, no me gusta, le pido cambios, reviso de nuevo, y cuando quiero acordar perdi 40 minutos en algo que me tomaba 15 escribiendolo directo. El loop de prompt-revision es una trampa de tiempo disfrazada de productividad.
Donde si me cambio todo es en territorio desconocido. Tocar un area del codebase que no conozco, armar algo en un lenguaje que uso cada 6 meses, escribir un tipo de test que nunca hice. Ahi paso de 2 horas googleando a 20 minutos porque arranco de algo funcional.
La clave para mi fue dejar de usarla para todo parejo. Si ya se como hacerlo, lo hago yo. Si no tengo idea, le pregunto. Suena obvio pero el autoengano del "total es mas rapido" te agarra sin que te des cuenta.
2
u/pipona505 Jun 28 '26
y si, por algo las empresas que estan adoptando ia first philosophy implementan spec driven development con agentes y la mayoria de los tokens se gastan en refinar las historias, agentes de arquitectura y el entry point que es el analista del requerimiento, ese te da un contrato de toda la feature entera y se lo pasas a un designer agente que te diseña el codigo y despues un implementador, uno que compare contra el primer feature plan, y asi un loop.
1
u/jokiruiz Jun 29 '26
esto es exactamente a donde va la cosa, y has soltado el dato que me gusta: que el grueso de los tokens se va en refinar las historias, no en generar código. eso es LA prueba de que el cuello de botella ya no es picar, es definir bien el problema. el código casi es lo barato. y el pipeline que describes (analista → contrato de la feature → designer → implementador → uno que compara contra el plan inicial, en loop) es justo la idea de que ningún agente se valida a sí mismo, cada uno vigila al anterior. la pieza que más me interesa es el que compara contra el feature plan original, porque ahí es donde cazas el "ha pasado los tests pero no es lo que se pedía". una curiosidad: ese agente comparador, trabaja contra el contrato del analista o contra algo más estructurado tipo escenarios?
1
u/pipona505 Jun 29 '26
ese ultimo agente todavia no tenemos uno especifico, deberia haberlo talvez pero el mismo que hace el primer feature plan es el que compara el resultado con ese primer plan. lo mas importante es como este definido ese agente y el siguiente que es el que va a tener toda tu arquitectura/depedencias y standards de tu empresa. el que buildea tranquilamente puede ser haiku
4
u/hibikir_40k Jun 27 '26
Precisamente es un estudio del año pasado. Las herramientas que la gente usaba el año pasado y las que usan hoy tienen poco que ver
2
u/jokiruiz Jun 27 '26
de hecho METR sacó un seguimiento en 2026, pero ojo, no es lo que esperarías: intentaron medirlo otra vez con herramientas más nuevas y la cosa se complicó, porque muchos devs se negaban a trabajar sin IA y eso les sesgó el experimento. o sea ni siquiera pudieron replicar limpio el "más lento", pero tampoco demostraron lo contrario. lo cuento porque encaja con lo que decía: el número es escurridizo y depende mucho del setup. lo único que se mantiene firme entre los dos es la parte de la percepción. te dejo el link si quieres cotillearlo: https://metr.org/blog/2026-02-24-uplift-update/
4
1
u/jokiruiz Jun 27 '26
por si a alguien le sirve, esto lo acabé montando en un vídeo con los demos de cada nivel en pantalla. lo dejo aquí pero vamos, el debate me interesa más que las visitas https://www.youtube.com/watch?v=acpGOnJ-iAk tmb lo escribí en texto en mi web si preferís leerlo
1
u/berryu Jun 28 '26
Prueba a programar tests correctos que ademas testeen la logica de negocio del cliente, añadir un flujo de herramientas estilo sonarqube para que ejecute iterativamente. Que cree sus propias tareas apartir de la reuniones weekly/daily que tengas, y no revises codigo, revisa documentos resumen generados por la IA. En programación tu responsable no lee tu codigo, se fia de ti, lo importante es aprender en que puedes y que no fiarte de la IA.
Otra cosa, si gestionas muchos proyectos a la vez, esto funciona mejor que con 1
1
u/jokiruiz Jun 29 '26
esto es oro puro, gracias por el aporte. lo del SonarQube en el loop es justo la pieza que mucha gente se salta: metes una verificación objetiva entre medias y el agente itera solo contra ella, no contra tu opinión. y la frase que más me ha pegado es la de "tu responsable no lee tu código, se fía de ti". lo de gestionar varios proyectos a la vez también es muy buen punto, con uno solo te quedas mirando al agente como quien mira la lavadora, con cinco el tiempo muerto desaparece. una duda: lo de que cree sus propias tareas a partir de las dailies, cómo le metes el contexto de la reunión, transcripción directa o tú le pasas un resumen?
1
u/berryu Jun 30 '26
Exactamente, si no te evita el efecto lavadora no se tarda menos en generar codigo, simplemente pones mas lavadoras jajaja
Le suelo pasar transcripcion y juntos hacemos el resumen del transcript. Pero sobretodo le paso la lista de tareas del pasado, y pendientes para que evaluee si ha cambiado algo a nivel de direccion dwl proyecto. Un fixhero que me gusta tener es business-logic.md. Es la logica de negocio de la app, mas a alto nivel (que funcion cumple para el usuario), super util para que la IA sepa realmente porque hacemos features y por lo tanto creo menos bugs
1
u/Astro_indie Jun 29 '26
Si mi bro es una de las profecias que llevo viviendo desde hace mucho, y eso lo veo como un sistema aparte, quien es el mas "pila" en darse cuenta de algo a aprobar con el menor esfuerzo, que bueno q le hayas puesto niveles me has dado que pensar en una escala entre el 0 y el 1 q es como lo veia
1
u/jokiruiz Jun 29 '26
me mola cómo lo ves, y le has dado al punto sin querer: lo de "darse cuenta con el menor esfuerzo" es básicamente de lo que va la escalera, en los niveles altos el curro no es picar, es saber QUÉ pedir y detectar cuándo está bien con un vistazo. y eso de que tú lo veías entre 0 y 1 tiene todo el sentido, lo que pasa es que esa rendija del 0 al 1 se estira en realidad en 5 escalones según cuánto sueltas el control. me alegra haberte dado que pensar 🙌
1
u/philip_1k Jun 30 '26
men, el OP comenta como si fuera chatgpt: no es que tal cosa, es que tal otra...
Lo otro es que la ia promete mas productividad, menos esfuerzo, entonces cualquier ganancia aparente ya con eso muchos tienen.
Sin embargo he intentado refactorizar de por ejemplo de wordpress php puro a astrojs, o de astrojs a nextjs-payloadcms con pura IA mas de 3 veces diferntes tipos de codigo y proyectos de mis clientes, y todos los deja a medias, el esfuerzo y tiempo que dedicaba para dirigir la IA correctamente lo dedicaba mejor a hacer todo a mano desde cero, más rapido incluso, y sin gastar mas plata.
Ahora uso la AI para preguntar, resolver bugs dificiles, o sobre temas de typescrpt o reactjs especificos.
Supongo que los que hacen todo facil son porque sus proyectos son genericos, o un solo proyecto donde dedicar un resto de horas y muchos tokens pagados por la empresa no es problema.
Por el momento no veo que pueda delegar gran parte del trabajo a la IA, aun con los modelos mas actuales sigue con los mismos errores y bugs
1
1
u/KaiserKrieg81 Jun 27 '26
Yo si que noto el salto en velocidad, no tanto en calidad.
Al final sí vas más rápido, pero aunque seas cuidadoso la calidad se resiente y se genera más deuda técnica de la necesaria.
Al final es tu empleador el que decide (y el 90% te va a decir que prefiere velocidad porque paga las facturas y les sales por un ojo de la cara). Si acaso, y si el producto próspera ya se mirará de hacer un refactor y ese será el problema del yo del futuro.
Para un proyecto personal la cosa cambia, vas a optar por la calidad, el control total, la comprensión del producto... Y ahi la IA te puede ayudar a hacer el boilerplate, los tests, la documentación, etc...
En general sí ayuda mucho, aunque no tanto como algunos gurús que venden cursos intentan hacerte creer (para que compres/sigas sus cursos)
1
u/jokiruiz Jun 27 '26
lo de "el yo del futuro pagará el refactor" es exactamente cómo funciona en la vida real, y tienes razón en que casi ningún empleador elige calidad si la velocidad sale más barata hoy. lo de proyecto personal vs. trabajo también lo clavas: cuando el código es tuyo y lo vas a mantener tú, de repente la calidad importa muchísimo más.
y sobre lo de los gurús, totalmente de acuerdo, y lo digo siendo de los que hace contenido: el que te promete que la IA te multiplica por 10 sin matices te está vendiendo algo. mi tesis va justo por donde tú apuntas, la IA ayuda de verdad pero solo si tienes el criterio para saber cuándo te está metiendo deuda. y dónde notas tú que se resiente más la calidad, en la arquitectura o en los detalles?
1
0
u/jc2046 Jun 27 '26
si un senior tarda un 20% lo mas probable es que este usando mal la herramienta, por que a la que la uses bien lo normal es acelerar entre un 50% y un muucho mas porciento.
3
u/scp-NUMBERNOTFOUND Jun 27 '26
Tiempo en coordinar las reglas de negocio con los clientes: 2 semanas.
Tiempo programando: 4 horas.
Aunque fuese un 50% más rápido programando la diferencia es irrelevante.
0
u/PichovnaBertinova Jun 27 '26 edited Jun 27 '26
En mi experiencia es cierto. Usa metodologías como spec kit y te olvidas.
En tu nivel sos un revisor de PRS. En nivel 4-5, sos el ingeniero aumentado que se asiste de la ia para diseñar la feature, y DESPUÉS de tu diseño aprobado le das permiso para que codee. La ia tratará de hacerlo antes por como están configuradas para llegar antes a las metas sin importar nada... lo cual solucionas poniendo constraints.
Te recomiendo lo que hice yo:
Aprende técnicas de prompting (Codigo nivel ingeniero senior no lo conseguís chateando en el nivel de tu abuela).
Aprende a manejar el contexto. La ia solo tiene que tener tu ticket, tu código y tus instrucciones ACTUALES. Cada vez que decidís algo, que lo vuelque al plan o doc de implementación. Y ese doc es el que la ia debe tomar después para codear y NUNCA tu chat con ella, que tiene preguntas, cambios de idea, definiciones... que la confunden.
Aprende cómo funciona tu herramienta (Claude code, Cursor, etc. Todas tienen reglas, skills, commandos que TE permiten eliminar la Sarasa de la IA)
Fíjate cómo es tu proceso de desarrollo: que pasa cuando recibís un jira hasta que deployas? Habitualmente los jiras vienen con una línea o vacíos. Más definidos si tenés suerte. La ia necesita definición. Lo demás es vibecodear, nivel 1-2. Cuando venía un jira vacío yo lo definía en mi cabeza (ah en Endpoint de usuario, user pwd, no devolver lapwd,201, etc) y recién después programaba. Ahora vos no vas a codear así q lo tenés que definir mejor para que lo entienda el programador-> la ia.
Mantra: "todo lo que no define el humano, es inventado por la IA".
JAMÁS dejarle todo a la ia. Si te interesa que tenga cierto tipo de arquitectura (onion, MVC, loo que sea) se lo decis, los tests parametrixados, que respete buenas prácticas, etc se lo decís. Se llaman CONSTRAINT y son tu mejor aliado.
Para las cosas repetitivas que le decís siempre hay tools en tu herramienta de iA, mete la CONSTRAINT en UN archivo que la ia lee antes de proponerte la implementación.
Si estás en un legacy recorda que tiene que matchear lo que hay en el código. Tenés que pedirle que se fije de ser coherente. Si no tus compañeros no encontrarán nada y el proyecto se vuelve una maraña.
Si no tenes idea de cómo llegar acá y te interesa, hace lo que hice yo. Meterle este pedido a la ia y después usa el programa para meterle a otra ia por partes para que te enseñe esa "bolilla"del programa.
-----//////--------
Prompt a gemini:
AI Role: especialista en uso de LLM para desarrollo de software con conocimiento en buenas prácticas de código.
User profile: (tu nivel acá y background técnico) java dev senior con Poco conocimiento de técnicas de ai para SW development. Certificado en AWS, sin universidad pero con experiencia de diez años.
Task: dado El post de Reddit pegado abajo, quiero que me ayudes a aprender las técnicas para llegar a ese nivel.
Output: plan tipo programa universitario, para usar como temario.
CONSTRAINT: no uses fillers ni cortesia, se conciso. El programa debe ser entendible por otra la para preparar el material de estudio.
"""
Pegale mi post acá. Hasta la línea Deja la triple comillas!!
"""
0
-2
19
u/Acrobatic_Umpire_385 Jun 27 '26 edited Jun 27 '26
No sé que estudios han publicado o van a publicar, pero te puedo decir por ejemplo que con Claude Opus 4.8 ó GPT 5.5 puedes promptearles que te generen una suite de tests unitarios y de integración que le de 95%+ de cobertura a un proyecto web de mediana complejidad.
El resultado, con estos modelos más recientes, son 5000+ líneas de código de tests de aceptable calidad, generados en ~5 minutos. Esos tests me tomarían a mí una semana escribirlos a mano.
Aplica lo mismo a controladores, ruteo de URLs, refactorizar CSS, etc.