Volver al artículo del blog

La IA como acelerador, no como reemplazo: flujo de trabajo, calidad del código y apropiación

Michel Mix · Medellín, Colombia · 7 de mayo de 2026

Resumen

Esta síntesis de literatura examina qué principios de flujo de trabajo se asocian con productividad, calidad del código y apropiación humana en el desarrollo de software asistido por IA. La conclusión práctica es clara: los asistentes de codificación con IA pueden acelerar a los desarrolladores, pero sobre todo cuando están integrados en un flujo explícito con delimitación clara de tareas, buena especificación, generación controlada, verificación estructurada, aseguramiento de calidad y revisión humana. Al mismo tiempo, la literatura muestra por qué el uso poco dirigido de IA puede ser engañoso. Los desarrolladores suelen sentirse más rápidos, mientras la verificación, la adaptación, la deuda técnica y la pérdida de apropiación pueden reducir o incluso invertir esa ganancia. El flujo más fuerte no es, entonces, “más IA”, sino uso disciplinado de IA dentro de controles normales de ingeniería.

Puntos clave

• Las ganancias de productividad con IA son reales, pero desiguales y dependen mucho de la experiencia, el tipo de tarea, la fase del proyecto y el costo de verificación.
• La IA funciona mejor en tareas acotadas de aceleración; la exploración, la arquitectura, la seguridad y el trabajo de alta responsabilidad exigen más juicio humano.
• La especificación antes de la generación es una palanca de calidad: intención, restricciones, contexto y límites explícitos deben estar claros primero.
• La verificación no es una tarea secundaria sino un paso diseñado del flujo; la fatiga y la carga de verificación pueden volver los controles mediblemente más superficiales.
• El análisis estático, las pruebas, la validación de seguridad y la revisión por pares se vuelven más importantes con IA, no menos.
• La apropiación humana sigue siendo la puerta final: el desarrollador debe entender el código, poder explicarlo y estar dispuesto a mantenerlo.

Posicionamiento

Este texto es una síntesis de literatura para una presentación sobre desarrollo de software asistido por IA. No es una revisión sistemática completa ni una comparación de productos de IA. La síntesis conecta estudios empíricos, preprints, casos industriales y artículos conceptuales en una línea de razonamiento práctica para equipos de desarrollo.

Pregunta de investigación

¿Qué principios de flujo de trabajo se asocian con productividad, calidad del código y apropiación humana en el desarrollo de software asistido por IA?

Síntesis de literatura

Introducción

Los asistentes de codificación con IA se han vuelto comunes en muy poco tiempo. GitHub Copilot, ChatGPT, Claude, Cursor y sus sucesores autónomos ya no se usan solo de forma experimental: hoy escriben más del 20 por ciento del código nuevo en organizaciones como Google y Microsoft, mientras que la Stack Overflow Developer Survey 2025 reporta que el 84 por ciento de los desarrolladores profesionales usa o planea usar herramientas de codificación con IA (citado en Liu et al., 2026). Sin embargo, sus efectos sobre productividad, calidad del código y apropiación profesional no son uniformemente positivos, y dependen mucho de la forma en que los desarrolladores usan la IA.

La tesis central de esta síntesis es que la pregunta de si la IA ayuda es menos útil que la pregunta de cómo se usa. Los estudios empíricos y conceptuales seleccionados muestran que existe un conjunto coherente de principios de flujo de trabajo que puede permitir ganancias de productividad, proteger la calidad del código y preservar la apropiación humana. Al mismo tiempo, los mismos estudios muestran que ignorar esos principios puede producir costos de tiempo ocultos, deuda técnica persistente y una erosión gradual de la accountability profesional.

La síntesis está organizada por temas. Primero se presenta el panorama de productividad; luego se desarrollan cinco principios de flujo de trabajo: ajuste de tarea, especificación antes de generación, verificación explícita, aseguramiento estructural de calidad y apropiación humana. Después se trata el code review como un nodo crítico del flujo y se identifican las condiciones organizacionales que influyen en la adopción. El texto cierra con un flujo integrado y directamente aplicable, y con los límites dentro de los cuales las conclusiones son más fuertes.

Productividad: un panorama matizado y dependiente del contexto

Los efectos de los asistentes de codificación con IA sobre la productividad son positivos en promedio, pero desiguales y en parte ilusorios si se ignora el panorama más amplio. Esta es una de las conclusiones más consistentes de la literatura, y también una de las más fáciles de malinterpretar.

Las cifras positivas más fuertes provienen del estudio RCT de Cui et al. (2025), que siguió a 4.867 desarrolladores en Microsoft, Accenture y una empresa Fortune 100: la asistencia de IA produjo, en promedio, 26,08 por ciento más tareas completadas, 13,55 por ciento más commits y 38,38 por ciento más compilaciones. Los desarrolladores con menos experiencia se beneficiaron más. Song et al. (2024) encontraron ganancias similares, aunque más modestas, en proyectos open source: el uso de Copilot produjo un aumento neto de 5,9 por ciento en contribuciones de código a nivel de proyecto. Mohamed et al. (2025), en una revisión sistemática de 39 estudios, confirman que la mayoría reporta beneficios, sobre todo aceleración de tareas rutinarias y reducción del tiempo dedicado a buscar sintaxis y boilerplate.

Pero la misma literatura contiene un hallazgo contraintuitivo que baja el entusiasmo. Becker et al. (2025) realizaron un RCT intra-sujeto con 16 contribuidores open source experimentados, trabajando en 246 tareas dentro de sus propios proyectos conocidos; los autores reconocen riesgos de artefactos experimentales, pero consideran robusto el resultado principal. El resultado fue un aumento del 19 por ciento en el tiempo de finalización de tareas con IA, aunque los participantes habían predicho una mejora del 24 por ciento. Esta brecha entre percepción y realidad aparece en varios estudios (Liang et al., 2024; Mozannar et al., 2024) y crea un riesgo serio: los equipos que creen trabajar más rápido, sin hacerlo realmente, tienen poca base para evaluar críticamente su flujo de trabajo.

La explicación está en lo que Mohamed et al. (2025) llaman la multidimensionalidad de la productividad, y en lo que Chen et al. (2026) desarrollan empíricamente mediante un estudio mixed-methods en BNY Mellon, con 2.989 respuestas de encuesta y 11 entrevistas. Chen et al. identifican seis factores de productividad, entre los cuales la experticia técnica y la apropiación del trabajo están entre los más subestimados. Métricas de corto plazo como commits y tareas completadas no miden si el desarrollador realmente entiende el código, puede mantenerlo o puede defenderlo con confianza. Fan et al. (2026) agregan otra dimensión: verification load. Su experimento con 60 participantes muestra que el uso de IA redujo el tiempo de trabajo en promedio en 22 por ciento, pero que un índice de carga de verificación (compilaciones fallidas, time-to-first-compile, reversión de código, pausas e interrupciones de interacción) se acumuló entre tareas y explicó parcialmente el aumento de estrés y fatiga.

El límite de la ganancia de productividad no es arbitrario. Becker et al. (2025) muestran que se mueve con la familiaridad con la base de código: en proyectos maduros y complejos, los costos de verificación y adaptación pueden pesar más que el ahorro de escritura del código generado. Song et al. (2024) agregan una dimensión colectiva: la IA aumenta las contribuciones individuales, pero también aumenta el tiempo de coordinación en 8 por ciento. Según los autores, el efecto neto a nivel de proyecto sigue siendo positivo, pero menor de lo que sugeriría una medición puramente individual. En resumen: la pregunta no es si la IA produce ganancias de productividad, sino para quién, en qué fase del proyecto y con qué distribución de tareas — y si esa ganancia se logra sin costos silenciosos de calidad y apropiación.

Principio de flujo 1: ajuste de tarea

La primera y más fundamental conclusión de la literatura es que no todas las tareas son igual de adecuadas para la asistencia de IA, y que emparejar conscientemente el tipo de tarea con el uso de IA maximiza la ganancia de productividad mientras limita el riesgo de calidad.

Barke et al. (2023) ofrecen la base de este principio mediante un análisis grounded theory de 20 programadores que trabajaban con GitHub Copilot. Distinguen dos modos de interacción cualitativamente distintos. En el modo de aceleración, el desarrollador sabe exactamente qué quiere lograr y usa la IA como mecanismo de velocidad: las sugerencias se evalúan rápidamente y se aceptan o rechazan. En el modo de exploración, el desarrollador no está seguro de la dirección y usa la IA para explorar opciones, lo cual puede ayudar pero también puede ralentizar el trabajo. El punto crucial es que cada modo requiere una estrategia de verificación distinta: en modo de aceleración puede bastar una inspección rápida, mientras que en modo de exploración se necesita una evaluación más profunda.

Sergeyuk et al. (2024) aportan evidencia empírica sobre el ajuste de tarea a partir de una encuesta a 481 usuarios de JetBrains. Los desarrolladores usan asistentes de IA en actividades como nuevas features, pruebas, bug triage, refactorización y artefactos en lenguaje natural, pero tareas concretas como generación de pruebas y docstrings parecen más adecuadas que tareas que requieren contexto amplio del proyecto. Esto coincide con Li et al. (2024), cuyo benchmark DevEval muestra que los LLM actuales tienen limitaciones importantes en fases tempranas del SDLC, como diseño de sistema, configuración de entorno y pruebas de aceptación, y rinden mejor en tareas de implementación aisladas.

La práctica confirma el patrón. Li et al. (2026) analizaron 2.547 conversaciones de ChatGPT en GitHub y encontraron que la mayoría de interacciones tenía entre uno y tres turnos: enfocadas en una tarea, de alcance reducido y orientadas a generación de código, modificación de código o resolución de problemas. Vigh et al. (2026) confirman en entrevistas con 11 desarrolladores que el uso de IA es condicional y selectivo: los desarrolladores evitan deliberadamente la IA en tareas críticas de seguridad, definiciones del sistema o trabajo de alta accountability. No es resistencia; es juicio profesional. La responsabilidad por corrección y seguridad fue tratada por estos desarrolladores como no transferible.

El principio de flujo que se deriva es que el ajuste de tarea debe decidirse antes, no tratarse como una guía vaga. ¿Esta es una tarea de aceleración o de exploración? ¿El nivel de riesgo permite delegar a IA? ¿Hay suficiente contexto para evaluar una sugerencia de IA rápidamente? Russo (2024) muestra que esto no es una abstracción académica: en un estudio mixed-methods de adopción (encuesta a 100 desarrolladores, validación PLS-SEM con 183 respondientes), la compatibilidad con el flujo de trabajo fue el factor más fuerte de adopción de IA, por encima de utilidad percibida o presión social. Las herramientas que rompen el flujo existente no se adoptan de forma sostenible; las que encajan en él, sí.

Principio de flujo 2: especificación antes de generación

La segunda conclusión es que la generación de código con IA rinde mucho mejor cuando la intención, el contexto y las restricciones arquitectónicas se hacen explícitos antes de que el modelo empiece a trabajar. Este principio va en contra de la práctica más común, donde el desarrollador formula una tarea de inmediato y espera una sugerencia útil.

Mu et al. (2024) ofrecen la demostración empírica más clara con ClarifyGPT: un framework que detecta ambigüedades en requisitos, hace preguntas de aclaración al usuario y solo después genera código. En una evaluación validada por humanos sobre MBPP-sanitized, el Pass@1 de GPT-4 subió de 70,96 por ciento a 80,80 por ciento gracias a este paso explícito de aclaración. La raíz de la mejora es simple: los LLM adivinan cuando la entrada es ambigua, y esa suposición falla más de lo que el usuario cree.

Ullrich et al. (2025) profundizan este punto con entrevistas a 18 practitioners de 14 empresas. Su hallazgo es que los requirements, tal como normalmente se documentan, son demasiado abstractos para usarse directamente como entrada de un LLM. Los desarrolladores deben descomponerlos manualmente en tareas de programación concretas, enriquecidas con decisiones de diseño, restricciones arquitectónicas y contexto relevante. Esto no es un rodeo costoso; es el trabajo fundamental de requirements engineering que siempre fue necesario, pero que ahora también se vuelve preparación explícita del prompt. La implicación es clara: la apropiación de la especificación es la contribución humana más crítica al flujo con IA, y omitirla casi seguro produce salida subóptima.

Mallya et al. (2025) agregan un matiz práctico desde requirements engineering: los LLM pueden clasificar feedback de usuarios y generar especificaciones de requisitos, pero su rendimiento sigue siendo moderado y exige validación humana. Por tanto, la IA puede servir como primer filtro para entrada cruda de tickets, reviews o canales de soporte, pero no como reemplazo del paso humano de especificación. Antes de generar código, el desarrollador debe revisar si intención funcional, requisitos no funcionales y prioridad se tradujeron correctamente.

Liang et al. (2024) apoyan esto desde una perspectiva de usabilidad. En su encuesta a 410 desarrolladores, las razones más frecuentes para rechazar sugerencias de IA fueron que la salida no cumplía requisitos no funcionales y que era difícil de orientar. Ambas objeciones muestran el mismo problema: falta de contexto y dirección en el prompt. Como evidencia cercana desde literatura más amplia sobre GenAI, Gerlich (2025) muestra en un experimento transnacional (n=150) que el prompting estructurado, en el que el usuario debe formular la pregunta de manera metódica, aumenta la calidad de la salida y reduce cognitive offloading mientras mejora el razonamiento crítico. El uso no estructurado de IA aumenta la percepción de productividad, pero no la calidad del razonamiento ni de la salida.

Sarkar et al. (2024) resumen la consecuencia de principio: las interfaces de IA deben diseñarse para preservar pensamiento crítico bajo delegación creciente. Su mecanismo propuesto son provocations: objeciones textuales cortas que critican la salida de IA y apuntan alternativas. Tales mecanismos no surgen automáticamente de la interacción; deben diseñarse explícitamente como elementos de interfaz. El riesgo principal de omitirlos no es la alucinación, sino la delegación cognitiva: el desplazamiento gradual del pensamiento crítico del desarrollador al modelo, sin que el desarrollador lo note o lo haya decidido.

Principio de flujo 3: verificación como paso explícito

Que la salida de IA requiere verificación es evidente. Lo que la literatura agrega — y lo que la práctica suele subestimar — es que la verificación tiene un costo de tiempo sustancial, que su calidad puede disminuir acumulativamente por fatiga y que debe diseñarse activamente en el flujo en lugar de ejecutarse de forma ad hoc.

Mozannar et al. (2024), usando la taxonomía CUPS (Code Understanding and Participation Structures), mostraron cómo 21 programadores realmente distribuían su tiempo al trabajar con GitHub Copilot. Los resultados son sobrios: una gran parte del tiempo de interacción se iba en leer y evaluar sugerencias de IA, no en escribir o resolver problemas. La ganancia de productividad era, por tanto, menor de lo que los usuarios esperaban. Fan et al. (2026) cuantifican esto con un experimento controlado: introducen el verification-load index, una medida compuesta de compilaciones fallidas, tiempo hasta primera compilación, reversión de código e interrupciones de interacción. El índice muestra que la carga de verificación se acumula entre tareas, produce fatiga y se asocia con controles estadísticamente más superficiales.

La consecuencia práctica se ve con especial claridad en Becker et al. (2025). Su RCT mostró que desarrolladores experimentados en bases de código conocidas tardaron 19 por ciento más con IA que sin IA. La causa no fue simplemente que la IA fuera mala, sino que los desarrolladores dedicaron mucho tiempo a evaluar, adaptar y reparar sugerencias que eran correctas en dirección, pero carecían de contexto. Este es el problema de los proyectos maduros: convenciones, patrones arquitectónicos, deuda técnica y conocimiento implícito no están completamente disponibles para la IA, y el desarrollador debe compensarlo repetidamente.

Liu et al. (2026) muestran qué ocurre cuando la verificación es insuficiente. En un análisis a gran escala de 302.600 commits generados por IA en 6.299 repositorios de GitHub, identificaron 484.366 issues individuales, de los cuales 22,7 por ciento seguía presente en la última versión del repositorio. Los code smells fueron el tipo de issue más prevalente (89,3 por ciento). Cada herramienta de IA estudiada introdujo al menos un issue en más del 15 por ciento de los commits. Agarwal et al. (2026) encuentran patrones similares con agentes autónomos de codificación: las advertencias de static analysis aumentaron 18 por ciento y la complejidad cognitiva 39 por ciento, y esos efectos persistieron después de que las ganancias de velocity de los agentes se desvanecieron.

El principio que se deriva es que la verificación no funciona bien por sí sola, y no debe dejarse para el final cuando la presión es alta. Adalsteinsson et al. (2025) muestran que el code review asistido por IA es más efectivo cuando el contexto de revisión se compone explícitamente mediante una pipeline RAG, de modo que la salida de IA sea más relevante y el reviewer humano tenga que compensar menos. Vijayvergiya et al. (2024) muestran en Google que la IA puede funcionar como primer filtro para coding conventions, permitiendo que revisores humanos se concentren en lógica y arquitectura. Fan et al. (2026) recomiendan seleccionar la interfaz de forma adaptativa según la dificultad de la tarea: IA inline para tareas simples, chat para mayor complejidad y prompts estructurados para principiantes.

En resumen: la verificación debe diseñarse — planearse como paso, equiparse según dificultad y riesgo, y limitarse conscientemente en tiempo para reducir fatiga.

Principio de flujo 4: aseguramiento estructural de calidad

La cuarta conclusión es que el uso de IA hace más necesario, no menos, el aseguramiento estructural de calidad mediante análisis estático, pruebas y estándares de código. Varios estudios muestran que la salida de IA introduce problemas de calidad que permanecen en la base de código si no hay pasos adicionales de QA.

Liu et al. (2026) entregan la evidencia empírica más convincente. Además de la alta persistencia de issues (22,7 por ciento), encontraron que los code smells son el tipo de problema dominante: un riesgo fundamental de mantenibilidad que aparece más tarde como mayor costo de cambio. Sun et al. (2026) llegan al mismo punto desde otra vía: tras analizar 109 papers, realizar dos workshops industriales y ejecutar un estudio empírico de patches, concluyen que existe una misalignment sistemática entre prioridades académicas (security, performance), prioridades industriales (maintainability, readability) y el comportamiento real de los LLM. Las non-functional quality characteristics (NFQCs) no están suficientemente cubiertas en ninguno de los tres dominios. Los practitioners temen acumulación de deuda técnica, pero carecen de mecanismos adecuados de QA para código generado por IA.

Yu et al. (2026) concretan esta conclusión a nivel organizacional. En su estudio multi-caso de tres proyectos industriales GenAI, los equipos usaban principalmente métricas de calidad contextuales y orientadas a la tarea, porque las métricas genéricas de investigación rara vez se conectan directamente con el valor operativo. Para código generado por IA, esto significa que el aseguramiento de calidad no puede quedarse en una prueba o lint genérico. Los equipos deben explicitar qué criterios importan por base de código y tipo de tarea: mantenibilidad, manejo de errores, performance, seguridad, explicabilidad o alineación con reglas de dominio.

La idea de que el prompting resuelve el problema es atractiva, pero no está respaldada por los datos. Della Porta et al. (2025) estudiaron 7.583 archivos de código del dataset Dev-GPT sobre tres atributos de calidad (maintainability, security, reliability) y tres patrones de prompt (zero-shot, chain-of-thought, few-shot). Una prueba Kruskal-Wallis no encontró diferencias significativas de calidad entre patrones, incluso en código existente y no controlado de proyectos reales. El patrón de prompt no determina la calidad del código; el aseguramiento debe organizarse en otra parte del flujo.

Una dirección más prometedora es combinar análisis estático con LLM. Patcas y Motogna (2026) evaluaron seis LLM para resolver problemas reportados por SonarQube y encontraron una reducción promedio de 36 por ciento, con el mejor modelo (Grok 3) alcanzando 71,54 por ciento en un proyecto. Wadhwa et al. (2024) desarrollaron CORE, una pipeline proposer-ranker con LLM que corrige issues de análisis estático y aproxima criterios de revisión humana; 59,2 por ciento de archivos Python pasó tanto la herramienta como revisión humana, mientras 76,8 por ciento de archivos Java pasó análisis estático. Berabi et al. (2024) muestran que la reparación dirigida de vulnerabilidades, donde el análisis de programa limita el contexto del LLM, funciona mejor que la generación no guiada. El patrón común es claro: el análisis estático guía la IA; la IA no reemplaza el análisis estático. Simões y Venson (2024) confirman que la evaluación de calidad con LLM es complementaria al análisis estático, no sustituta: su comparación de modelos GPT con SonarQube muestra variabilidad sustancial entre modelos y enfatiza que los estándares humanos finales siguen siendo necesarios.

Para seguridad, el aseguramiento es todavía más urgente. Tessa et al. (2026) realizaron una auditoría adversarial de tres métodos state-of-the-art de generación segura de código y encontraron que los analizadores estáticos sobreestimaban la seguridad entre 7 y 21 veces, que entre 37 y 60 por ciento de las salidas clasificadas como “seguras” no eran funcionales, y que bajo condiciones adversariales la salida realmente segura y funcional bajaba a entre 3 y 17 por ciento. El aseguramiento de seguridad no puede delegarse a un modelo de IA, ni siquiera a modelos diseñados para ese propósito. Tony et al. (2024) confirman desde un ángulo complementario que técnicas estructuradas de prompt, especialmente Recursive Criticism and Improvement (RCI), reducen debilidades de seguridad, pero la validación externa de seguridad sigue siendo necesaria.

Haroon et al. (2026) completan el panorama de calidad en generación de pruebas. Los LLM alcanzan inicialmente 79 por ciento de line coverage, pero bajo cambios semánticos de código (SAC), la tasa de éxito de nuevas pruebas generadas baja a 66 por ciento y el branch coverage a 60 por ciento. Las pruebas quedan acopladas superficialmente al código original y reaccionan a cambios léxicos más que semánticos. Las suites de pruebas generadas por IA requieren reevaluación humana después de cada cambio significativo para preservar cobertura de regresión.

El principio de flujo es que el aseguramiento de calidad es un paso estructural y multidimensional, no un complemento opcional. Concretamente: ejecutar análisis estático como SonarQube o CodeQL sobre código generado por IA antes del review; validar código sensible en seguridad con una herramienta dedicada además del LLM; reevaluar periódicamente suites de pruebas generadas por IA después de cambios; y declarar explícitamente NFQCs como mantenibilidad, legibilidad y performance como criterios de aceptación.

Principio de flujo 5: apropiación humana

La quinta conclusión es que la apropiación humana en el desarrollo asistido por IA no ocurre automáticamente; hay que preservarla activamente. Sin atención explícita, los mecanismos que sostienen la apropiación — estándares personales, integridad profesional, pensamiento crítico y reciprocidad social — se erosionan bajo la delegación a IA.

Alami y Ernst (2024) aportan la base conceptual en su estudio de entrevistas con 12 desarrolladores. Distinguen dos formas de accountability: accountability institucional (procesos formales, KPI medibles) y grassroots accountability (motivación intrínseca, reputación, normas de pares). La accountability de base no se transfiere a un sistema: depende de reciprocidad, orgullo por la calidad y expectativas de los pares. Alami et al. (2025) muestran en un estudio posterior (16 entrevistas y focus groups con simulaciones de AI review) que el code review asistido por LLM rompe precisamente esa reciprocidad: los desarrolladores no se sienten accountable frente a una IA como sí frente a un colega. Esto afecta directamente los estándares de calidad que aplican al código generado o revisado por IA.

Sarkar et al. (2024) describen el riesgo estructural de la delegación creciente a IA como “copilot-to-autopilot drift”: el desplazamiento gradual del pensamiento crítico del desarrollador al modelo sin una decisión consciente. Sostienen que las alucinaciones son menos peligrosas que esta pérdida silenciosa de involucramiento cognitivo, y proponen provocations como mecanismos de interfaz que obligan al usuario a pensar antes de aceptar salida de IA. Gerlich (2025) apoya esto desde literatura más amplia sobre GenAI: el uso estructurado de IA, donde el usuario debe formular preguntas metódicamente, reduce significativamente cognitive offloading y aumenta razonamiento crítico frente al uso no estructurado.

Los desarrolladores reconocen intuitivamente este límite. Vigh et al. (2026) muestran que los desarrolladores usan IA de forma selectiva y evitan deliberadamente tareas de alta accountability, como trabajo crítico de seguridad, definición de sistemas y decisiones arquitectónicas. La responsabilidad por corrección y seguridad fue tratada por casi todos los participantes como no transferible. Esto no es reticencia por falta de familiaridad con IA; es juicio profesional.

Ogenrwot y Businge (2026) entregan evidencia cuantitativa de que los desarrolladores también ejercen esa apropiación en la práctica: en su análisis de 338 pull requests de GitHub con uso auto-declarado de ChatGPT, la tasa mediana de integración de patches de IA fue apenas 25 por ciento. La mayoría de patches integrados fueron modificados selectivamente, extraídos o refinados iterativamente. La adopción completa fue la excepción. Watanabe et al. (2026) encuentran patrones similares con agentes autónomos de codificación (Claude Code): 83,8 por ciento de agent PRs fueron merged, pero 45,1 por ciento requirió revisión humana, especialmente por bugs, estilo de documentación y estándares específicos del proyecto.

El principio es doble. Primero, el desarrollador debe fijar límites conscientes a la delegación a IA según accountability y riesgo. Segundo, la infraestructura de flujo debe apoyar esos límites: el juicio humano iterativo debe ser la norma, no la excepción; peer review debe seguir siendo la puerta social de calidad y apropiación, apoyada pero no reemplazada por AI review; y los equipos deben cultivar involucramiento crítico con la salida de IA en lugar de aceptación rápida.

Code review como nodo crítico

El code review merece tratamiento aparte porque es el nodo más estudiado y más cargado del flujo de desarrollo asistido por IA. Es el momento donde productividad, calidad del código y apropiación se encuentran, y donde la tensión entre asistencia de IA y accountability humana se hace más visible.

Bacchelli y Bird (2013) ofrecen la línea base para entender cualquier intervención de AI review. En su estudio empírico en Microsoft (17 desarrolladores, 16 equipos, 873 programadores), el code review moderno se mostró como mucho más que detección de defectos: es un mecanismo principal de transferencia de conocimiento, estándares de calidad guiados por el equipo, conciencia del código de otros y apropiación compartida. Esta función social no puede ser reemplazada por un sistema automatizado, sin importar su precisión. Una revisión por un colega tiene valor más allá de los comentarios escritos; también contiene la responsabilidad recíproca que Alami et al. (2025) identifican como central para la accountability profesional.

Esto no excluye asistencia de IA en code review, pero sí limita el papel que debe jugar. Vijayvergiya et al. (2024) muestran en Google que la IA (Autocommenter) puede funcionar eficazmente como primer filtro para desviaciones de coding practices, permitiendo que revisores humanos se concentren en lógica, semántica y arquitectura. Adalsteinsson et al. (2025) muestran en WirelessCar que un prototipo de AI review basado en RAG, que recupera información contextual relevante antes de la revisión, fue mejor recibido que una revisión de IA sin contexto, y que la preferencia por AI review dependía de la familiaridad del reviewer con la base de código. Wadhwa et al. (2024) desarrollaron CORE, una pipeline donde el análisis estático guía al LLM y un ranker LLM aproxima criterios humanos de aceptación. Peng et al. (2025) lograron 84 por ciento de aceptación en producción en Huawei mediante una arquitectura mixture-of-prompts para revisión enfocada en seguridad.

Cihan et al. (2025) coinciden con su propuesta de human-in-the-loop LLM code review: AI review como apoyo para compartir conocimiento y señalizar problemas, no como juicio final. Lin et al. (2024) agregan una perspectiva de entrenamiento: la calidad de los comentarios de AI review depende de la calidad de los datos de entrenamiento, y la experticia humana sigue siendo el estándar normativo. Entrenar modelos de revisión con conciencia de experiencia mejora significativamente la salida sin recolectar datos adicionales.

La implicación para el flujo es que la IA en code review siempre tiene un papel asesor, nunca decisorio. El reviewer mantiene el juicio final, y la práctica social de peer review, con su accountability recíproca, se conserva. AI review puede reducir el costo de detectar problemas técnicos como estilo, seguridad y convenciones, pero no puede asumir la función social de calidad de la revisión humana. Sí puede hacer la revisión humana más eficiente: menos comentarios triviales, más tiempo para juicio sustantivo.

Adopción y condiciones organizacionales

Los cinco principios funcionan solo cuando el contexto organizacional los apoya. Tres factores son decisivos: compatibilidad con el flujo de trabajo, confianza y soporte social, y diferenciación profesional.

Russo (2024), en un estudio mixed-methods de adopción con el framework HACAF, identificó la compatibilidad con el flujo de trabajo como el factor de adopción más fuerte, por encima de utilidad percibida o influencia social. Las herramientas de IA que encajan suavemente en procesos existentes se adoptan de forma estructural; las herramientas que rompen el flujo se evitan, incluso si son objetivamente fuertes. Esto tiene implicaciones directas para introducir flujos con IA en equipos: el flujo debe integrarse a prácticas existentes y ampliarse gradualmente, no imponerse como rediseño total.

Banh et al. (2025), mediante un framework sociotécnico de adopción basado en 18 entrevistas con expertos de software engineering, enfatizan que la integración exitosa de GenAI requiere alineación organizacional: gobernanza clara sobre cuándo y cómo se usa IA, políticas que apoyen confianza y experimentación, e integración incremental con espacio para ajustes. Sergeyuk et al. (2024) confirman que confianza y política empresarial son dos de las barreras más mencionadas para el uso de IA, y que la falta de contexto de proyecto en los asistentes es una tercera barrera técnica que influye en la selección de herramientas.

Shao e Ishengoma (2026) identifican un efecto importante de diferenciación profesional: los profesionales aplican sistemáticamente estrategias de refinamiento a la salida de IA (maintainability, alineación arquitectónica), mientras estudiantes se enfocan principalmente en un producto final que funcione. Esta diferencia en cultura de apropiación importa para equipos que adoptan IA: sin normas explícitas sobre refinamiento de calidad como práctica esperada, el equipo deriva hacia el estándar más bajo. Yu et al. (2026) confirman esto en un estudio multi-caso: la calidad de aplicaciones GenAI en la práctica varía mucho y depende de su inserción organizacional y de su aseguramiento de calidad. Hao et al. (2024) agregan la transparencia: compartir públicamente conversaciones con ChatGPT en PRs e issues, práctica que analizaron en 580 hilos de GitHub, funciona como artefacto de trazabilidad que hace visible y revisable el uso de IA.

Flujo recomendado

Conclusión integrada

Los estudios convergen en un núcleo coherente: la asistencia de IA para código produce beneficios demostrables, pero solo cuando se usa como un flujo consciente, gobernado y de varios pasos — no como fuente ad hoc de inspiración ni como subcontratación de tareas. La paradoja central de la literatura es que los mayores riesgos de productividad aparecen cuando la IA parece funcionar mejor: sugerencias rápidas aceptadas de inmediato pueden acumular silenciosamente code smells, problemas de seguridad y daño de apropiación. La mejor protección no es menos IA, sino mejor flujo de trabajo.

Los cinco principios centrales que se repiten en la literatura — ajuste de tarea, especificación primero, verificación explícita, aseguramiento estructural de calidad y apropiación consciente — no son consejos independientes sino un sistema conectado. Cada principio refuerza a los demás. Una buena especificación hace más eficiente la verificación. La verificación explícita protege la apropiación. El aseguramiento estructural de calidad hace operacional el ajuste de tarea. La apropiación consciente define los límites dentro de los cuales operan los demás principios. Los siete pasos siguientes operacionalizan estos principios para el trabajo diario.

Los siete pasos

El flujo siguiente se basa en la evidencia ponderada de los estudios empíricos y conceptuales seleccionados. Está pensado como guía diaria de trabajo, no como imagen idealizada.

Paso 1 — Ajuste de tarea: decide antes de empezar

Hazte dos preguntas antes de abrir la IA:

1. ¿Qué tipo de tarea es esta?
   • Tarea de aceleración: sé lo que quiero; la IA me ayuda a avanzar más rápido — la entrada directa de IA es adecuada.
   • Tarea de exploración: no estoy seguro de la dirección — uso IA para generar opciones, pero evalúo con más cuidado.
2. ¿Cuál es el nivel de riesgo?
   • Bajo: boilerplate, generación de pruebas, docstrings, refactorización de funciones aisladas — la delegación a IA es relativamente segura.
   • Alto: código crítico de seguridad, decisiones arquitectónicas, lógica de cumplimiento, definición del sistema — limita el uso de IA; el juicio humano no es transferible.

Evidencia: Barke et al. (2023), Vigh et al. (2026), Li et al. (2026), Sergeyuk et al. (2024), Li et al. (2024).

Paso 2 — Especificación: haz explícitas intención y contexto

Formula antes de escribir el prompt:

• Qué quieres lograr. (intención funcional)
• Qué restricciones aplican. (arquitectura, convenciones del lenguaje, performance, estándares de seguridad)
• Qué contexto necesita el modelo. (código existente relevante, interfaces, dependencias)
• Qué queda explícitamente fuera de alcance. (di lo que no quieres)

Para requisitos más complejos, pídele aclaración a la IA antes de pedir código: “¿Entiendes la intención? Haz preguntas antes de generar.”

Si la entrada viene de tickets, feedback de usuarios o canales de soporte, usa IA como máximo para agrupar temas o proponer una especificación inicial. Luego valida tú mismo si intención funcional, NFRs y prioridad están correctos antes de pedir implementación.

Evidencia: Mu et al. (2024), Ullrich et al. (2025), Mallya et al. (2025), Liang et al. (2024), Gerlich (2025), Sarkar et al. (2024).

Paso 3 — Generación: orienta, no confíes a ciegas

Genera código, pero ubica la salida de IA como borrador, no como código final.

• Usa sesiones cortas y enfocadas (1-3 iteraciones) para subtareas claramente definidas.
• Da feedback explícito si una versión no cumple la intención — no “esto está mal”, sino “esto omite X por Y”.
• Detén la sesión si la IA carece estructuralmente del contexto correcto; seguir orientándola puede costar más que escribir tú mismo.

Evidencia: Li et al. (2026), Becker et al. (2025), Ogenrwot & Businge (2026).

Paso 4 — Verificación: estructurada y acotada en tiempo

Verifica la salida de IA de forma sistemática:

• Legibilidad y comprensión: ¿entiendes cada línea? Si no, reescribe o pide explicación.
• Corrección funcional: ejecuta el código (manualmente o con unit tests) sobre entradas representativas.
• Ajuste arquitectónico: ¿encaja con convenciones, nombres y estructura existentes?
• Aspectos no funcionales: ¿pensaste en legibilidad para el próximo desarrollador, uso de memoria y manejo de errores?

Acota la verificación en tiempo. Define un límite por sesión. La carga de verificación aumenta con fatiga; toma una pausa si notas que estás revisando más superficialmente.

Evidencia: Mozannar et al. (2024), Fan et al. (2026), Becker et al. (2025), Adalsteinsson et al. (2025).

Paso 5 — Aseguramiento de calidad: análisis estático y review como enlaces fijos

Haz siempre aseguramiento de calidad después de la generación con IA, sin importar qué tan convincente se vea la salida:

• Análisis estático: ejecuta SonarQube, Pylint, ESLint o equivalente sobre código generado por IA antes de llevarlo a review. La salida de IA tiene mayor probabilidad estructural de code smells (Liu et al., 2026).
• Validación de seguridad: usa un escáner dedicado, como Snyk o Semgrep, en código sensible. No confíes en la declaración de la IA de que algo es seguro (Tessa et al., 2026; Berabi et al., 2024).
• Cobertura de pruebas: las pruebas generadas por IA pueden verse fuertes inicialmente, pero degradarse bajo cambios de código. Reevalúa suites generadas por IA después de cada refactorización o cambio funcional significativo (Haroon et al., 2026).
• Criterios de calidad contextuales: define por base de código qué requisitos no funcionales importan en este cambio, como mantenibilidad, manejo de errores, performance o alineación de dominio. Las métricas genéricas ayudan, pero no bastan (Sun et al., 2026; Yu et al., 2026).
• Documenta el uso de IA: haz visibles las contribuciones de IA en commits o descripciones de PR (Hao et al., 2024; Ogenrwot & Businge, 2026). Esto ayuda a reviewers y mantiene trazable la apropiación.

Evidencia: Liu et al. (2026), Agarwal et al. (2026), Sun et al. (2026), Patcas & Motogna (2026), Haroon et al. (2026), Tessa et al. (2026).

Paso 6 — Code review: IA como primer filtro, humanos como puerta final

En la fase de review, los roles son:

Autor:

• Envía el código con una nota sobre contribuciones de IA y pasos de verificación ya completados.
• Agrega contexto relevante para ayudar al reviewer a evaluar el cambio.

Reviewer:

• Usa AI review, si está disponible, como primer filtro para convenciones, estilo y patrones conocidos.
• Reserva la atención humana para comprensión semántica, ajuste arquitectónico, preguntas de apropiación y evaluación de riesgo.
• Peer review no se reemplaza con AI review: también es el momento de transferencia de conocimiento y apropiación compartida (Bacchelli & Bird, 2013; Alami et al., 2025).

Evidencia: Bacchelli & Bird (2013), Alami et al. (2025), Vijayvergiya et al. (2024), Adalsteinsson et al. (2025), Cihan et al. (2025), Wadhwa et al. (2024).

Paso 7 — Reflexión: mantén activa la apropiación

A nivel individual:

• Pregúntate después de cada sesión con IA: ¿entiendo el código que voy a commitear? ¿Puedo explicárselo a un colega? ¿Puedo mantenerlo en seis meses?
• Trata la salida de IA como punto de partida, no como punto final. La tasa mediana de integración del 25 por ciento en PRs reales (Ogenrwot & Businge, 2026) es una referencia útil: la selectividad es práctica profesional, no desconfianza de la herramienta.

A nivel de equipo:

• Discutan regularmente qué partes de la base de código justifican alto o bajo uso de IA.
• Incluyan deuda técnica de código generado por IA en las retrospectivas de sprint (Liu et al., 2026).
• Cultiven estándares explícitos de refinamiento de salida de IA; esta es una diferencia central entre uso profesional y estudiantil (Shao & Ishengoma, 2026).

Evidencia: Sarkar et al. (2024), Gerlich (2025), Alami & Ernst (2024), Alami et al. (2025), Chen et al. (2026), Shao & Ishengoma (2026).

Definición práctica de terminado

Para uso diario de equipo, el flujo puede resumirse como una Definition of Done mínima para trabajo asistido por IA. Una contribución de IA solo está lista cuando:

• el tipo de tarea y nivel de riesgo fueron nombrados antes;
• los requisitos, tickets o feedback usados fueron traducidos a restricciones concretas y validados por humanos cuando era necesario;
• el autor entiende el código generado, puede explicarlo y está dispuesto a mantenerlo;
• pruebas, análisis estático, security checks y criterios contextuales de calidad fueron ejecutados;
• el uso de IA y los pasos de verificación son visibles para el reviewer;
• un reviewer humano da el juicio final sobre semántica, ajuste arquitectónico y apropiación.

Esta definición vuelve aplicable la síntesis sin perder el matiz de la literatura: la IA puede acelerar, pero solo dentro de un flujo donde especificación, verificación, criterios de calidad y responsabilidad humana siguen siendo explícitos.

Límites de la conclusión

Toda síntesis exige honestidad sobre los límites de sus conclusiones. Tres boundary conditions son relevantes:

1. El nivel de experiencia define el balance de productividad. Los desarrolladores con menos experiencia se benefician más de la IA (Cui et al., 2025), mientras desarrolladores experimentados en bases de código conocidas pueden terminar con pérdida neta de tiempo (Becker et al., 2025). El paso 1 (ajuste de tarea) y el paso 4 (tiempo de verificación) son especialmente críticos para desarrolladores experimentados.

2. Fase del proyecto, tipo de tarea y madurez. En repositorios donde los agentes son la primera herramienta de IA observable, Agarwal et al. (2026) encuentran sobre todo ganancias de velocity de corto plazo; en entornos con tooling de IA previo, este efecto es más débil. En bases de código maduras y grandes, con dependencias complejas, los riesgos de calidad y costos de verificación son más altos. Tareas acotadas de implementación se benefician antes; integración legacy y arquitectura, menos (Li et al., 2024; Becker et al., 2025). Los agentes autónomos requieren el aseguramiento de calidad más fuerte en proyectos maduros.

3. Contexto organizacional. Sin gobernanza, confianza y una cultura explícita de calidad, los principios individuales no bastan (Russo, 2024; Banh et al., 2025). El flujo funciona mejor en equipos que comparten normas sobre uso de IA, estándares de calidad y apropiación.

Resumen: los siete pasos de un vistazo

Fuentes usadas y rol en la síntesis

La tabla muestra qué fuentes sostienen la argumentación principal y cuáles se usan sobre todo como contexto o evidencia práctica.

Referencias

Adalsteinsson, G. H., et al. (2025). Rethinking code review workflows with LLM assistance. Proceedings of the 2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 488-497. https://doi.org/10.1109/ESEM64174.2025.00013

Agarwal, S., et al. (2026). AI IDEs or autonomous agents? Measuring the impact of coding agents. Proceedings of MSR 2026. https://doi.org/10.1145/3793302.3793589

Alami, A., & Ernst, N. A. (2024). Understanding the building blocks of accountability in software engineering. Empirical Software Engineering.

Alami, A., et al. (2025). Accountability in code review: The role of intrinsic drivers and the impact of LLMs. ACM Transactions on Software Engineering and Methodology, 34(8), 1-44. https://doi.org/10.1145/3721127

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th International Conference on Software Engineering (ICSE), 712-721.

Banh, L., et al. (2025). Copiloting the future: How GenAI transforms software engineering. Information and Software Technology, 183, 107751. https://doi.org/10.1016/j.infsof.2025.107751

Barke, S., James, M. B., & Polikarpova, N. (2023). Grounded Copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), 85-111.

Becker, J., et al. (2025). Measuring the impact of early-2025 AI on experienced OSS developer productivity. METR Technical Report. https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

Berabi, B., et al. (2024). DeepCode AI Fix: Fixing security vulnerabilities with large language models. ICML 2024.

Chen, V., et al. (2026). Beyond the commit: Developer perspectives on productivity with AI coding assistants. Proceedings of ICSE-SEIP 2026. https://doi.org/10.1145/3786583.3786848

Cihan, T., et al. (2025). Evaluating large language models for code review. arXiv:2505.20206.

Cui, Z., et al. (2025). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. SSRN Working Paper, No. 4945566. https://doi.org/10.2139/ssrn.4945566

Della Porta, J., et al. (2025). Do prompt patterns affect code quality? Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering, 181-192. https://doi.org/10.1145/3756681.3756938

Fan, G., et al. (2026). When help hurts: Verification load and fatigue with AI coding assistants. Proceedings of CHI 2026. https://doi.org/10.1145/3772318.3791176

Gerlich, M. (2025). From offloading to engagement: An experimental study on structured prompting and critical reasoning with generative AI. Data, 10, 172. https://doi.org/10.3390/data10110172

Hao, Y., et al. (2024). Developers’ shared conversations with ChatGPT in GitHub pull requests and issues. Empirical Software Engineering, 29(6). https://doi.org/10.1007/s10664-024-10540-x

Haroon, S., Khan, M. T., & Gulzar, M. A. (2026). Evaluating LLM-based test generation under software evolution. arXiv:2603.23443.

Li, M., et al. (2024). Prompting LLMs to tackle the full SDLC: DevEval. arXiv preprint.

Li, R., et al. (2026). Unveiling the role of ChatGPT in software development: Insights from developer-ChatGPT interactions on GitHub. ACM Transactions on Software Engineering and Methodology.

Liang, J., et al. (2024). Usability of AI programming assistants: Successes and challenges. Proceedings of ICSE 2024, 1-13. https://doi.org/10.1145/3597503.3608128

Lin, B., et al. (2024). Improving automated code reviews: Learning from experience. Proceedings of MSR 2024, 278-283. https://doi.org/10.1145/3643991.3644910

Liu, Y., et al. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild. arXiv:2603.28592.

Mallya, M. A., Ferrari, A., Zadenoori, M. A., & Dąbrowski, J. (2025). From online user feedback to requirements: Evaluating large language models for classification and specification tasks. arXiv:2510.23055.

Mohamed, A., et al. (2025). The impact of LLM-assistants on software developer productivity: A systematic review and mapping study. arXiv:2507.03156.

Mozannar, H., et al. (2024). Reading between the lines: Modeling user behavior and costs in AI-assisted programming. Proceedings of CHI 2024.

Mu, F., et al. (2024). ClarifyGPT: A framework for enhancing LLM-based code generation via requirements clarification. Proceedings of the ACM on Software Engineering, 1(FSE), 2332-2354. https://doi.org/10.1145/3660810

Ogenrwot, D., & Businge, J. (2026). PatchTrack: A comprehensive analysis of ChatGPT’s influence on pull request outcomes. Empirical Software Engineering, 31(5). https://doi.org/10.1007/s10664-026-10869-5

Patcas, R., & Motogna, S. (2026). An evaluation study of large language models for addressing code quality issues. Empirical Software Engineering, 31, 118. https://doi.org/10.1007/s10664-026-10858-8

Peng, Y., Kim, K., Meng, L., & Liu, K. (2025). iCodeReviewer: Improving secure code review with mixture of prompts. arXiv:2510.12186.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology.

Sarkar, A., et al. (2024). AI should challenge, not obey. Communications of the ACM, 67(10), 18-21. https://doi.org/10.1145/3673413 (Preprint: arXiv:2412.15030)

Sergeyuk, A., et al. (2024). Using AI-based coding assistants in practice: State of affairs, perceptions, and ways forward. Information and Software Technology. https://doi.org/10.1016/j.infsof.2024.107610

Shao, D., & Ishengoma, F. (2026). Empirical analysis of generative AI tool adoption in software development. Information and Software Technology, 192, 108036.

Simões, M., & Venson, E. (2024). Evaluating source code quality with large language models. arXiv preprint.

Song, Y., et al. (2024). The impact of generative AI on collaborative OSS development. arXiv:2410.02091.

Sun, X., et al. (2026). Quality assurance of LLM-generated code: Addressing non-functional quality characteristics. Journal of Systems and Software, 238, 112885. https://doi.org/10.1016/j.jss.2026.112885

Tessa, M., et al. (2026). How secure is secure code generation? Adversarial prompts put LLM defenses to the test. arXiv:2601.07084.

Tony, C., et al. (2024). Prompting techniques for secure code generation. arXiv preprint.

Ullrich, J., et al. (2025). From requirements to code: Developer practices in LLM-assisted software engineering. Proceedings of IEEE RE 2025. https://doi.org/10.1109/RE63999.2025.00032

Vijayvergiya, M., et al. (2024). AI-assisted assessment of coding practices in modern code review. Proceedings of the 1st ACM International Conference on AI-Powered Software (AIware ’24), 85-93. https://doi.org/10.1145/3664646.3665664

Vigh, E., Sunesen, F., & Barkhuus, L. (2026). “AI does not understand the real world”: AI augmented software development. CHI EA ’26.

Wadhwa, N., et al. (2024). CORE: Resolving code quality issues using LLMs. Proceedings of the ACM on Software Engineering, 1(FSE), 789-811. https://doi.org/10.1145/3643762

Watanabe, M., et al. (2026). On the use of agentic coding: An empirical study of pull requests on GitHub. ACM Transactions on Software Engineering and Methodology.

Yu, L., et al. (2026). Evaluating the quality of GenAI applications in software engineering: A multi-case study. Empirical Software Engineering, 31, 29. https://doi.org/10.1007/s10664-025-10759-2

Declaración de uso de IA

La IA se usó como apoyo para estructurar esta síntesis de literatura, comparar fuentes, revisar la consistencia entre uso de fuentes y argumentación, y afinar formulaciones. Las decisiones de contenido, la ponderación de fuentes, la interpretación, la edición final y la responsabilidad por el texto definitivo siguen siendo del autor.