Parece que la IA no hará que sus procesos sean más rápidos
(frederickvanbrabant.com)- En la ola de optimización de procesos se están extendiendo expectativas poco realistas sobre la IA, pero incorporar IA por sí solo no mejora la velocidad de ejecución
- La verdadera razón por la que el desarrollo de software toma tanto tiempo no es la velocidad de codificación, sino el proceso de convertir requisitos ambiguos en una definición clara del problema
- La generación de código con IA enfrenta el mismo problema aguas arriba, y para obtener resultados correctos es indispensable una participación profunda de expertos en dominio y producto
- En los casos comparativos sobre uso de IA, suele omitirse el proceso de acompañamiento detallado (handholding), que es lo que realmente crea la diferencia de productividad; un desarrollador humano también dispararía su productividad si recibiera la misma documentación detallada
- Para acelerar de verdad un proceso, la prioridad, como enseña The Goal, es "suministrar entradas predecibles y de alta calidad al cuello de botella"
Optimización de procesos y expectativas sobre la IA en medio de la desaceleración del mercado
- Cuando el mercado se enfría, la mayoría de las organizaciones tienden a enfocarse, al menos en parte, en optimizar procesos; recientemente, a esto se ha sumado el factor IA junto con expectativas poco realistas
- The Toyota Way y The Goal recuerdan que es fácil malinterpretar en qué deberían enfocarse muchas iniciativas de optimización de procesos
- Que una etapa tarde mucho puede ser una señal para empezar a mejorar, pero no significa necesariamente que ahí esté el problema real
- Si uno simplemente espera resolverlo metiendo más gente o asumiendo que la IA aumentará enormemente la velocidad, deja de ver por qué el trabajo se está demorando
- Para acelerar un proceso, primero hay que verificar si quienes ejecutan el trabajo realmente cuentan con las entradas y condiciones necesarias para poder empezarlo y terminarlo
El cuello de botella visual (The visual bottleneck)
- Con un ejemplo de gráfico de Gantt se puede ver visualmente que la etapa que más tarda es el desarrollo de software
- Normalmente sería más común usar BPMN, pero aquí se presenta un gráfico de Gantt para facilitar la explicación
- Si el objetivo es mejorar el throughput del proyecto, el enfoque de revisar primero la etapa más larga es, en sí mismo, correcto
- El problema está en cómo la gente intenta resolverlo
- Meter más personas al problema (throw people at the problem)
- Asumir que la IA lo hará mucho más rápido
- Lo que no se examina es "por qué esta etapa tarda tanto", y aún más importante: que una etapa tome mucho tiempo no significa que la causa del problema esté en esa misma etapa
Resolver el problema aguas arriba
- Aunque aquí se usa el desarrollo de software como ejemplo, esto aplica igual a cualquier proceso que tarde más de lo deseado
- El desarrollo de software no se acelera solo aumentando la velocidad de tecleo; si así fuera, todos estarían tomando clases de mecanografía
- La esencia del desarrollo de software es traducir un problema en una solución que la computadora pueda resolver automáticamente, idealmente de forma segura y escalable
- Para eso se necesita una comprensión integral del problema
- Si se trabaja más cerca de un enfoque waterfall, se necesitan documentos funcionales o de alcance
- Si se trabaja en agile, se requiere iteración continua con expertos del dominio
- Lo que de verdad ralentiza el desarrollo es el proceso de averiguar qué significa una solicitud ambigua de feature que solo tiene un título
- Incluso la solicitud "enviar correo al usuario una vez que se complete la venta (send mail to user once sale is completed)" no es un requerimiento que pueda implementarse de inmediato
- Se puede enviar un correo, pero ¿qué debe contener ese correo?
- Si hubo un problema en el proceso de venta, ¿también debe enviarse un correo de error?
- ¿En qué momento se considera que la venta está "completada"?
La idea de dejárselo todo a la IA
- Un argumento que se escucha seguido es que con la generación de código con IA se puede saltar la etapa de desarrollo y que los desarrolladores de software solo tendrían que actuar como project managers
- Mucha gente espera que el largo tramo actual de desarrollo de software sea reemplazado por una etapa de desarrollo con IA de unos 3 días
- Existe una imagen de cómo debería verse ese desarrollo con IA, pero en la práctica no funciona así: se enfrenta exactamente a los mismos problemas aguas arriba
- Es cierto que la IA puede generar código rápido (si eso es algo bueno ya es otro debate), pero generar rápido no equivale a generar código correcto
- Lo que siempre se ignora en la comparación entre desarrollo humano vs. IA es el proceso de acompañamiento detallado (handholding) necesario para que la IA funcione bien
- Este enfoque puede ser más rápido que el método tradicional, pero no es una comparación justa
- Para que el desarrollo con IA funcione, se necesita una participación mucho más profunda de expertos del dominio y del producto
- Hay que escribir todas las funciones hasta el más mínimo detalle
- También en cada corrección de bug hay que dejar muy claro cuál es el resultado esperado
- Eso es precisamente lo que los desarrolladores de software han pedido desde siempre: una descripción detallada del problema y del resultado final esperado
- Si a un desarrollador humano se le entrega el mismo volumen de documentación de feature/scope, su productividad también aumentará de forma drástica
Cómo aumentar realmente la velocidad de un proceso
- Para aumentar la velocidad de un proceso, hay que asegurarse de que las personas que deben hacer el trabajo realmente tengan todos los medios para hacerlo
- Si el proceso de aprobación legal es lento, primero hay que revisar qué se necesita para iniciar ese proceso de aprobación legal
- Si hay que perseguir a cinco personas por culpa de documentación incompleta, agregar más abogados al área no hará que el proceso vaya más rápido
- Una de las grandes lecciones de The Goal es que el cuello de botella debe recibir entradas predecibles y de alta calidad
- "bottlenecks should receive predictable, high-quality inputs"
- El primer punto de partida de la automatización de procesos no debería ser el cuello de botella en sí, sino mejorar la calidad de las entradas y su previsibilidad antes de que lleguen ahí
1 comentarios
Comentarios de Hacker News
Se dice que lo que el desarrollo de software siempre quiso desde el principio era “recibir una descripción detallada del problema y del resultado deseado”, pero en realidad eso en sí mismo es ingeniería de software
Incluso en 2026 hay que abandonar la idea de que, si solo tienes requisitos y especificaciones lo bastante detallados, puedes crear una solución perfecta de una sola vez
En mi experiencia, gracias a la IA ahora se puede iterar mucho más rápido sobre funciones e ideas, y la fricción hoy surge sobre todo de la alineación y coordinación con otros equipos
Si quieres acelerar el proceso, hay que reducir el costo de coordinación y dar a las personas y a los equipos más autoridad para decidir y ejecutar
Incluso Anthropic, con especificaciones perfectas, una implementación de referencia y miles de pruebas escritas por humanos durante años, no pudo crear ni siquiera algo tan simple como un compilador de C que funcionara
Los modelos actuales no son lo bastante buenos como para crear software operativo no trivial bajo una supervisión humana mínima, aunque tengan especificaciones perfectas y pruebas perfectas
Sin especificaciones perfectas y un conjunto perfecto de pruebas escritas por humanos, es aún más difícil, y quizá sea posible hacia 2027
A menudo recibo tareas que al PM se le ocurrieron en la tarde, y solo se enfocan en la ruta feliz, a veces solo en una parte de ella
Como somos una empresa global, tenemos que cumplir normativas y leyes de cada país; implementas la función y luego te dicen “en realidad, en el 90% de los mercados donde operamos esto no se puede hacer legalmente”, así que vuelves a meter una opción para desactivarlo
Después regresan con “bueno, en algunos de esos mercados sí se puede si se pasa por el proceso regulatorio correspondiente, así que implémentalo así”
Como la fecha límite ya está encima, al final tienes que parchear la solución a toda prisa
Eso no es ingeniería de software, y ni siquiera tiene que ver con el software en sí
El trabajo del ingeniero de software es tomar una lista de requisitos y encontrar cómo cumplirlos, y la recopilación de requisitos no es un problema de ingeniería de software
El software es implementación y el producto es comportamiento; el comportamiento de lo que se va a construir debería conocerse antes de empezar a construirlo en serio
Si alguien hubiera esperado una semana e investigado bien, se habría podido diseñar una estructura escalable, fácil de ampliar, fácil de mantener y que hiciera el futuro mucho más llevadero
Llevo más de 40 años desde que escribí mi primer programa, y nunca he visto un caso en el que primero se complete la especificación y luego se escriba el software y todo salga bien
En toda ingeniería no trivial, la parte más difícil es entender el problema, y las primeras versiones del software son la forma de llegar a ese entendimiento
Por eso creo que una “fábrica de software” basada en IA nunca va a funcionar bien
Al final vuelve a ser desarrollo en cascada: arquitectos haciendo diagramas UML y pasándole a un equipo de programadores una tarea de implementación esencialmente simple, solo que implementan lo equivocado
La IA es muy buena para pasar rápido de una primera versión equivocada a una segunda versión menos equivocada
Pero no hay que olvidar que la misión principal es entender el problema que se intenta resolver
Si solo me dieran especificaciones detalladas, no sería más que un robot de codificación, y ese trabajo se lo paso a un junior
Como antes, mi trabajo es leer esos requisitos, entenderlos y validarlos frente a la realidad que conozco
Con el código pasa lo mismo
Durante al menos los últimos 20 años, la esencia de la ingeniería de software ha sido no confiar en nadie; eso no ha cambiado y sigue costando mucho tiempo y esfuerzo
Cuando aparecieron los LLM, parece que la gente pensó que bastaría con decir cosas como “hazme un clon de Facebook”
Ahora se están dando cuenta de que hay que escribir los requisitos con más precisión y definirlos mejor
Ese siempre fue el cuello de botella del software
Antes, en el trabajo, realmente recibía requisitos como “trae los datos y dáselos al usuario”
No se definía qué datos, dónde estaban guardados ni en qué formato había que devolverlos, así que había que pasar mucho tiempo con producto para descubrir qué era lo que realmente querían
Para obtener buenos resultados con un LLM hace falta algo parecido, y los requisitos ambiguos producen resultados ambiguos
Llenan plantillas explicando qué problema existe y por qué, por ejemplo que el backend tiene el campo X pero el frontend no, de dónde y cómo obtener los datos, y hasta cuáles son los criterios de aceptación
Antes no lo hacían por flojera o por pensar “el desarrollador ya verá”
Después, el desarrollador puede copiar y pegar ese ticket de Jira en el agente LLM que quiera, o dejar que el LLM lo lea automáticamente con Atlassian MCP
Esto ayudó muchísimo a los desarrolladores y volvió los requisitos muy claros
Si soy sincero, viendo solo esa primera etapa, parece que los PM ya están a medio camino de implementar la función; quizá en el futuro ellos hagan todo directamente y algunos desarrolladores queden más como SDET que como implementadores completos
Ahí describe con mucha precisión las características centrales del vibe coding y la experiencia que estamos teniendo ahora
La idea es que, tras éxitos iniciales en algunos dominios cuidadosamente elegidos, al expandirse fuera de ellos aparecen mejoras de productividad razonables, pero no revolucionarias
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Nunca he usado un prompt cercano a “hazme un clon de Facebook”; más bien explico cómo debería funcionar
Por ejemplo, pedí un script en Python que leyera
/etc/hosts, buscara valores de host específicos configurados en.conf, le pusiera nombre a cada configuración, detectara el entorno actual, creara un ícono en la esquina superior derecha del GNOME por defecto de Ubuntu 22, y que al hacer clic listara los nombres de configuración y, al elegir uno, respaldara/etc/hostsy modificara solo la línea del nombre de host correspondienteCon eso salió casi de una vez un simple conmutador de entorno tipo app indicator para GNOME, y con corregir unas pocas líneas ya funcionaba en su mayor parte
Si le das al LLM una especificación decente, construye bien las cosas, e incluso entiende si te inventas un DSL falso para describir lo que quieres
Si el proceso anterior no funcionaba, era porque quien escribía los requisitos no entendía la intención del negocio o era descuidado y entregaba requisitos ambiguos o malos
El LLM solo hace que esos mismos requisitos ambiguos o malos parezcan plausibles, pero si escarbas un poco, se ve el problema
Saldrían preguntas como “¿qué significa exactamente ‘traer los datos’?”
El LLM solo responde “¡claro! aquí está el código completo para traer los datos y dárselos al usuario” y ya
Este artículo asume que la IA solo afecta la etapa de desarrollo, pero eso claramente no es cierto
Puede acelerar todas las etapas, incluyendo ideación, legal, documentación, desarrollo y despliegue
En ideación puedes intercambiar ideas, contrastarlas con la base de conocimiento y generar documentos de diseño; en documentación puede generar grandes partes de la documentación
El desarrollo ni se diga, y en despliegue puede crear manifiestos de despliegue, herramientas de prueba y conocimiento relacionado con plataformas cloud
Todas las etapas pueden mejorar y acelerarse con IA; no todo, pero sí muchas partes
Lo mismo en desarrollo: una parte consiste en entender el problema mejor que nadie y crear la solución, pero otra parte es puro trabajo mecánico
Si ya sabes que un botón debe hacer X, entonces diseñarlo, colocarlo, pensar en las excepciones de hover y press y conectarlo al backend es trabajo mecánico que puedes saltarte; y casi la misma lógica aplica a todas las etapas
Cuando intentas agregar una función nueva importante, normalmente pasas días, semanas o meses en reuniones con responsables del negocio para entender cómo fluye el trabajo entre los sistemas X, Y y Z, y cuáles son las excepciones importantes
Por ejemplo, el subconjunto A se procesa así, B se procesa de otra forma, pero en el último paso ambos grupos se combinan, salvo que C necesita el proceso especial 97
A partir de ese entendimiento viene el diseño de una solución de sistema que abarca varios sistemas, mezclando sistemas internos y de proveedores, cada uno con distintos niveles de personalización, lo que empuja la forma final de la solución en muchas direcciones
Acelerar la codificación sin duda tiene valor, pero es solo una pieza del rompecabezas, y los LLM actuales no ayudan a recopilar información del dominio ni a definir la solución
Y hay algo más: ahora más personas de distintos roles pueden crear herramientas de software para resolver problemas que antes empujaban a pura fuerza con procedimientos manuales
Somos un pequeño fabricante, no una empresa con proyectos corporativos gigantes que requieren experiencia profunda en ingeniería de software, pero herramientas simples de software están mejorando procesos y productividad por todas partes
Cuando el responsable de envíos puede resolver con una herramienta a medida un problema que antes le quemaba muchas horas de trabajo, pasan cosas realmente impresionantes
Usamos mucha IA en desarrollo de software, pero no estamos lanzando más rápido; incluso da la impresión de que vamos más lento, por razones parecidas o distintas
Se siente raro, como estar esperando a que llegue la utopía, pero no llega, y tampoco es fácil señalar exactamente dónde está el problema
De hecho, este tipo de desacuerdo y desconfianza crea oportunidades y puntos de irrupción en el mercado
Si el IQ promedio de quienes participan en un proyecto es 140, entonces una IA con IQ 150 puede replicar a cada individuo del pipeline
Quienes dicen que la IA no puede hacer esto o aquello tienen que aceptar que esta brecha de IQ está aumentando de forma monótona
Por un lado, este texto explica con claridad y precisión lo que mucha gente que hace trabajo técnico en organizaciones grandes piensa y ve en el terreno
Estoy 110% de acuerdo con el autor y ojalá más personas entendieran lo que dice aquí
Por otro lado, tanto en HN como en el trabajo real, siento que ya he tenido esta conversación decenas de veces últimamente
Los líderes tienen incentivos sociales y económicos para fingir que la IA realmente va a acelerar las cosas, así que un solo post de blog no los va a convencer
Así que ya solo queda esperar a que sus proyectos de IA fracasen o avancen tan lento como los proyectos de siempre, y ojalá aprendan algo
Incluso da cosa compartir artículos así en la empresa; da la impresión de que lo que no encaja con el statu quo no se recibe bien
Creo que los recursos visuales y los diagramas de Gantt son exactamente el lenguaje PM que los PM pueden entender
Mientras la gente de nivel C y los inversionistas sigan mandando señales de innovación, esto no se va a resolver de inmediato, pero tampoco puede durar para siempre
Estos días paso el tiempo haciendo jardinería y obsesionándome con proyectos personales de código usando herramientas agenticas
Cosas como crear desde cero una base de datos OLTP de alto rendimiento, un nuevo entorno de programación persistente relacional lógica, sintetizadores raros basados en matemáticas y soft processors en FPGA
O sea, las cosas normales que hace la gente normal
Por eso sé lo que estas herramientas pueden hacer cuando una sola persona las tiene en sus manos, y de verdad es sorprendente
Pero cuando escucho a amigos que siguen en empresas hablar de cuotas mínimas de tokens, rankings de “star AI coder”, “no hagas code review” o “no codifiques a mano”, no puedo más que negar con la cabeza
En invierno hice algo de trabajo por contrato y estuvo bien, pero mientras el fundador hacía vibe coding de proyectos completos cada fin de semana, el code review degeneró en un duelo entre LLM
Estas herramientas no sirven mucho para el trabajo en equipo ni para la verdadera ingeniería de software en equipo
Mi plan es hacerme a un lado y mirar hasta que la industria se ordene
Los únicos lugares decentes para trabajar serán aquellos donde alguien pueda decir “¡ve más despacio!” y haya personas mayores y sabias capaces de sostener eso
Mientras tanto, vendo manojos de ruibarbo recién cortado a 5 dólares en Hamilton, Ontario
También tengo espárragos, y muchos
Hay una dualidad interesante
En las cosas que ya hago bien, los LLM tienen relativamente poco impacto, pero en lo que no sé hacer son un cambio de juego brutal
Las grandes empresas pueden contratar a la mayoría de los roles que necesita un proyecto, así que el efecto total será relativamente pequeño
Como mucho, una persona podrá hacer medianamente el trabajo de cinco, reduciendo costos laborales, a cambio de obtener un producto peor
Ya se sabe cómo termina esa combinación de ganancia a corto plazo y costo a largo plazo
Pero para estudios pequeños o desarrolladores independientes, los LLM sí son un gran cambio
Hacer medianamente el trabajo de cinco personas es un salto enorme comparado con aguantar sin esos roles, depender de assets de terceros u otro contenido, o peor aún, improvisar algo terrible
Basta con mirar casi cualquier UI de programa donde se nota que un programador la acomodó sin diseñador
O los casos en que intentan copiar algo de Dribbble pero no les da la habilidad
Con IA, de repente puedes copiar de forma plausible casi todo y a casi todos, que en realidad es casi todo el modo de funcionamiento de la IA
Suena a definición de manual
En lo personal, me pasa exactamente al revés
Los LLM solo me ayudan cuando yo ya sé exactamente lo que estoy haciendo
La gente no entiende bien que, en desarrollo de software no trivial, ni siquiera 50% es codificación
La etapa de codificación suele ser de las más fáciles y se le delega a desarrolladores junior
En organizaciones grandes, la mayoría de los cambios de producto atraviesan varios sistemas y operaciones humanas
Los senior y mid-level dedican gran parte del tiempo a reordenar prioridades locales dentro de un ente cibernético existente y a conseguir que otros equipos, cada uno con sus propias prioridades, acepten esa nueva visión
En eso entran naturalmente muchos trade-offs y mucha política
Los ingenieros senior pelean con fuerza para evitar añadir “peso” a los sistemas de los que son responsables y para impedir ampliaciones de alcance o desvíos de la dirección en la que intentaban avanzar
Así que hace falta compromiso, o escalar la elección de prioridades a dirección
No sé si la IA también podrá resolver eso, pero es muchísimo más difícil
Ahora es un invocador de herramientas, así que los agentes de codificación pueden ejecutar lint, type checks y tests, corregir esos errores, meterse en plataformas de observabilidad como Sentry para encontrar la causa raíz, correr benchmarks para detectar código lento o hot paths, y leer y aplicar documentación de migración de nuevas major versions de las librerías que usas para mantener el sistema actualizado
Si no están configurados para que esas cosas generen retroalimentación sobre el agente y le permitan entender mejor el sistema, se quedarán como simples y tontos redactores de código LLM
Pero con los modelos y los harnesses mejorando tan rápido, claramente pueden llegar bastante más lejos
Este artículo es mayormente correcto y da pistas sobre dónde enfocarse si uno quiere que la IA realmente acelere los procesos
Por ejemplo, un gerente de producto dijo que imagina un futuro donde, si al terminar una reunión con stakeholders no sale un prototipo interactivo, se considera un fracaso; me parece que va en la dirección correcta
Otra cosa que preveo es que el vibe coding se convierta en “Excel 2.0”
Permitirá crear aplicaciones conversacionales bastante self-service y meterá a TI en una guerra permanente por transformar eso en algo con mejores garantías de seguridad, control de acceso y logging adecuados, escalabilidad, gestión de cambios, etc.
Desde una perspectiva histórica más amplia, toda transición revolucionaria al principio produce “caballos de vapor”
Cuando se inventó la máquina de vapor, la gente imaginaba que el futuro del transporte serían objetos con forma de caballo movidos por vapor que tirarían de los carros existentes
Solo después entendimos la función del transporte separada de su forma
Empecé a hablar de caballo de vapor cuando se discutían los MOOC, porque los MOOC eran la idea típica de un caballo de vapor
No necesitas código para hacer un prototipo
Es como decir que para capturar una escena hacen falta actores y una cámara, cuando bastan unos cuantos bocetos
El Gantt presentado es un ejemplo de modelo en cascada o de otra metodología que asume que el software tiene un destino final
Hoy en día, el 99.999% del software no se construye así
El desarrollo de software moderno no tiene destino
Cada dos semanas el negocio cambia lo que el software debe hacer
Siguen apareciendo nuevas funciones, nuevas integraciones, funciones modificadas, componentes actualizados o reemplazados, mayor escala y otro hosting
Después de algunos años, el software queda transformado fundamentalmente y la calidad y las pruebas salen volando por la ventana
No solo hay que lidiar con cambios a punta de parches, sino con la tortura constante de luchar contra la entropía
El software se convierte en un ser vivo herido, con cambios de estilo de vida y envejeciendo
La empresa pasa a ser como el cuidador de un zoológico que intenta mantener con vida a una bestia deprimida
Como los humanos son animales de costumbre, todos esos mismos problemas aparecerán incluso usando IA
Eso sí, todo irá un poco más rápido y el code review puede mejorar un poco el código
Al mismo tiempo, la falta de buenas pruebas y el deseo de desplegar más rápido empeorarán un poco todo
El resultado de ese tira y afloja será software de calidad casi similar, pero moviéndose algo más rápido
En última instancia sí habrá un proceso más rápido, pero todo lo demás seguirá siendo una tortura, así que nadie lo sentirá demasiado
Probablemente todos terminemos quemándonos más rápido
La complejidad existe por una razón, y no se puede quitar sin quitar esa razón
No se pueden resolver problemas de negocio con herramientas
Sobre la frase “la IA puede generar código rápido, pero eso no significa que genere el código correcto”: en realidad, el código casi siempre está bien
Lo que normalmente no me gusta es cómo se agrega ese código
Si conoces lo bastante bien el codebase, hay rituales sobre dónde añadir las cosas, cómo nombrarlas, cuántos comentarios poner y dónde
Si el agente no hace bien eso, gente como yo se irrita, y parece que ni siquiera ponerlo en AGENTS.md funciona
La idea de que “si les dieras a desarrolladores humanos la misma cantidad de documentación de funcionalidades y alcance, la productividad se dispararía” no me la creo en absoluto, y llevo casi 20 años en TI
Incluso si pasara, sería tan raro que no valdría la pena hablar de ello
Basta comparar el esfuerzo de replicar un sistema ya escrito con el esfuerzo de crear ese mismo sistema desde cero
Sobre todo cuando la entrada es un bug o un problema de rendimiento, alucina seguido y, si no lo llevas de la mano, diagnostica mal
Aun así, si vigilas lo que hace y lo empujas en la dirección correcta, es bueno para el análisis de causa raíz y para el análisis en general, y puede volverte más eficiente
Creo que los humanos tienen un límite en la velocidad con que pueden digerir y analizar información frente a una máquina, y eso también pone un techo a la ganancia de productividad
La IA no tiene que saltarse el proceso, pero sí puede acelerarlo
Puede ayudar con refactorización, escritura de código boilerplate, detección de errores que no habías visto antes y cosas que el linter no detecta
Muchos comentarios parecen venir de gente que no usa procesos estándar conocidos, o que asume que si usa IA ya no hace falta seguir esos estándares
Si se pueden lanzar más líneas de código y más funcionalidades, claro que sí, siempre que haya buenos requisitos y suficientes pruebas
Todo el código escrito por IA debe pasar por revisión y pruebas, y dividirse en commits y pull requests separados
Alguien que sube un PR de miles de líneas es una señal de alerta
Sin IA tampoco harías eso, así que ¿por qué hacerlo por usar IA?
La única excepción conocida son las reescrituras o refactorizaciones grandes, pero incluso ahí creo que es mejor tener commits individuales convertibles que permitan ver el proceso del cambio para juzgarlo mejor
Si me muestras un commit o PR gigantesco de una sola vez, lo voy a rechazar
Hay que dividirlo en partes que un desarrollador común pueda auditar