La IA puede escribir buen código. La pregunta es quién sigue poniendo atención después
Hay algo seductor en el código generado por IA que se ve bien desde el primer momento.
Pides un cambio pequeño. El asistente piensa un momento. Luego aparece un parche con nombres de funciones ordenados, pruebas razonables y un resumen que suena como si alguien hubiera recorrido la base de código con una tabla de control.
Build en verde. Pruebas en verde. Resumen de IA con tono verdoso.
Entonces llega el momento en el que conviene bajar la velocidad.
¿Entiendo este código yo mismo? ¿Encaja con el resto del sistema? ¿Está realmente probado, o solo viene bien vestido para tranquilizarnos? ¿Podré explicárselo a un compañero en seis meses sin señalar una ventana de chat?
Para mí, esa es la idea central del desarrollo de software asistido por IA. No si la IA puede escribir código. Eso ya lo sabemos. La mejor pregunta es: ¿qué queda de nuestros estándares de ingeniería después de que la IA escribe algo?
El problema no es que la IA ayude
Los asistentes de codificación con IA ya no son experimentales. Están en editores, chats, agentes, pull requests y flujos de revisión. Escriben boilerplate, pruebas, documentación, scripts, refactorizaciones y a veces cosas que uno mira después y piensa: un momento, ¿por qué apareció una segunda capa de caché?
Suena cínico, pero no lo digo en ese sentido.
La IA sí puede ayudar. Sobre todo en tareas bien delimitadas. Montar una prueba. Escribir una llamada a una API. Adaptar una función existente siguiendo un patrón visible. Explicar un mensaje de error. Proponer una primera lista de revisión. Son momentos en los que la IA se siente como alguien que empieza a levantar el andamio mientras tú todavía miras el plano.
La literatura también muestra eso. En estudios de campo grandes, las herramientas de IA generan ganancias promedio de productividad. Los desarrolladores completan más tareas, hacen más commits y avanzan más rápido en trabajo rutinario. Los desarrolladores con menos experiencia pueden beneficiarse especialmente, porque gastan menos tiempo en sintaxis, boilerplate y búsqueda (Cui et al., 2025).
Pero promedio es una palabra peligrosa.
Promedio no dice qué pasa en una base de código antigua con convenciones implícitas. Promedio no dice cuánto tiempo se va en revisar. Promedio no dice si el desarrollador todavía entiende el código. Y promedio mucho menos dice si el equipo estará contento en tres meses con lo que hoy se aceptó rápido. La productividad es más que commits; también incluye comprensión, mantenibilidad y apropiación (Chen et al., 2026).
Lo rápido no siempre resulta más rápido
Uno de los hallazgos más interesantes de la literatura reciente es que los desarrolladores con experiencia a veces pueden volverse más lentos con IA (Becker et al., 2025).
No porque no sepan usarla. No porque quieran volver a la máquina de escribir. Sino porque, en el experimento de Becker y sus colegas, trabajaron en sus propios proyectos open source conocidos, con convenciones y conocimiento implícito que no caben completos en un prompt.
En ese entorno, una sugerencia de IA suele estar casi bien.
Casi bien es traicionero.
Lo completamente equivocado se reconoce rápido. Se descarta la sugerencia y se sigue escribiendo. Pero lo casi correcto exige atención. Lees. Comparas. Ajustas. Piensas: esto está ordenado, pero no es así como manejamos errores. O: esta prueba prueba el mock, no el comportamiento. O: esta solución funciona para el ejemplo, pero olvida los casos borde que producción siempre parece estar esperando.
Ahí está la factura escondida.
La IA ahorra tiempo de escritura, pero agrega tiempo de verificación. Y ese tiempo no es gratis. La investigación sobre programación asistida por IA muestra que los desarrolladores gastan mucho tiempo leyendo, evaluando y reparando la salida de la IA (Mozannar et al., 2024). Otros estudios muestran que la carga de verificación se puede acumular: entre más tiempo pasas revisando salida de IA, más probable es que la revisión se vuelva superficial (Fan et al., 2026).
Eso también se reconoce en la práctica. La primera sugerencia la revisas con cuidado. En la quinta piensas más rápido: sí, se ve lógico. Ese es exactamente el momento en el que necesitas café, no un botón de merge.
La primera pregunta es: ¿esto siquiera es una tarea para IA?
Un buen flujo de trabajo con IA no empieza con un prompt.
Empieza con la pregunta de si esta tarea debería entregarse a la IA.
Hay una distinción útil entre dos modos. En el primero, sabes lo que quieres. Usas la IA como acelerador. La tarea es pequeña, la dirección es clara y puedes evaluar la salida rápidamente. Piensa en una variante de prueba, una refactorización dentro de un patrón conocido, un fragmento de documentación o escribir código necesario pero aburrido (Barke et al., 2023).
En el segundo modo, todavía no sabes exactamente qué quieres. Usas la IA para explorar opciones. Eso puede servir, pero exige una revisión más pesada. Si tú todavía no conoces la dirección, la IA puede caminar con mucha confianza hacia el lado equivocado. Con nombres de variables impecables. Eso no ayuda.
Hay otro punto: la IA no entiende automáticamente tu mundo. No la base de código, no los usuarios, no la política interna, no el riesgo de release. En entrevistas con desarrolladores, ese límite aparece con claridad: la IA puede ayudar con una tarea, pero a menudo le falta el contexto del mundo real que le da sentido a esa tarea (Vigh et al., 2026).
Por eso hay una segunda pregunta: ¿cuál es el nivel de riesgo?
Para boilerplate, la IA suele estar bien. Para código sensible en seguridad, decisiones de arquitectura, lógica de cumplimiento o juicio de release, la situación cambia. Puedes dejar que la IA piense contigo, pero el criterio sigue siendo humano. No humano de ceremonia. Humano de verdad. Alguien tiene que entender qué está pasando y asumir responsabilidad por lo que entra al repositorio.
Eso no es nostalgia por el trabajo manual. Es apropiación profesional.
Especificar no es llenar papeles
Mucha salida mala de IA empieza con una tarea demasiado fácil de pedir.
“Termina esta función.”
“Arregla este bug.”
“Escribe pruebas.”
Suena eficiente. Casi siempre es vago.
La IA llena los vacíos. Ese es su trabajo. Pero el modelo no llena esos vacíos con tu conocimiento del dominio, tu contexto de release ni los acuerdos que surgieron en un pull request hace tres años y nunca quedaron escritos. Los llena con probabilidad.
A veces eso basta. Muchas veces casi basta.
Por eso la especificación es uno de los pasos más importantes en el desarrollo asistido por IA. La aclaración de requisitos puede mejorar de forma medible la calidad del código generado, precisamente porque el modelo tiene que adivinar menos (Mu et al., 2024). No como un documento pesado. Como preparación explícita:
- ¿Qué debe pasar funcionalmente?
- ¿Qué restricciones aplican?
- ¿Qué código o interfaz existente manda?
- ¿Qué queda explícitamente fuera de alcance?
- ¿Qué riesgos deben probarse o revisarse?
Eso puede sentirse como ir más despacio, pero es el punto más barato para evitar errores. Un prompt confuso produce un parche confuso. Después te toca jugar al arqueólogo en tu propio diff. Con un poco de mala suerte, también encuentras cerámica.
Una buena especificación no vuelve mágica a la IA. La vuelve acotada. Y acotada es justo como la quieres en desarrollo de software. El objetivo no es tercerizar el pensamiento, sino mantenerse involucrado mientras la IA reduce fricción (Gerlich, 2025; Sarkar et al., 2024).
La verificación es donde está el trabajo real
La regla más importante del flujo de trabajo es simple:
La salida de IA es un borrador.
No una decisión. No una prueba. No un mini compañero que ya asumió responsabilidad. Un borrador.
Por eso la verificación tiene que ser explícita. No solo mirar el diff por encima. No “las pruebas corren, entonces listo”. Hay que revisar conscientemente qué hace el cambio.
Yo miro cuatro cosas.
Primero: ¿entiendo el código yo mismo? Si no puedo explicar una línea, eso no significa que la IA sea inteligente. Significa que yo no he terminado.
Segundo: ¿el comportamiento es correcto? No solo para el ejemplo del prompt, sino también para entradas representativas y casos borde.
Tercero: ¿encaja en la base de código? Nombres, manejo de errores, logging, performance, dependencias, estilo de pruebas. La IA suele escribir código genéricamente ordenado. Una base de código necesita código que encaje específicamente.
Cuarto: ¿cuáles son las consecuencias no funcionales? Mantenibilidad, seguridad, legibilidad, observabilidad. Las palabras aburridas sobre las que corre producción.
Aquí ayuda la herramienta. Pruebas, linters, type checks, análisis estático, escáneres de seguridad. No porque las herramientas lo vean todo. Sino porque ven de forma consistente lo que los humanos preferimos saltarnos un viernes por la tarde.
La literatura es bastante clara: la salida de IA introduce problemas estructurales de calidad. En un estudio a gran escala de más de 300.000 commits generados por IA, el 22,7 por ciento de los issues identificados seguía presente en la versión más reciente del repositorio, con los code smells como el tipo de problema dominante (Liu et al., 2026). En seguridad, el asunto es todavía más delicado. La investigación sobre generación de código seguro muestra que “seguro” y “funcional” no aparecen juntos automáticamente, especialmente bajo adversarial prompting (Tessa et al., 2026). Que un modelo diga que el código es seguro no le da autoridad. Produjo texto. Eso es distinto.
La revisión se vuelve más importante, no menos
Un malentendido sobre la IA es que hace menos necesaria la revisión.
Yo creo que pasa lo contrario.
La IA puede ayudar en la primera capa. Puede señalar convenciones, detectar patrones sospechosos, resumir un diff o proponer preguntas para el reviewer. Eso es útil; en Google, por ejemplo, la IA se ha usado precisamente como primer filtro para coding practices, de modo que los revisores humanos puedan dedicar más atención a la lógica y al diseño (Vijayvergiya et al., 2024). Nadie se vuelve mejor ingeniero por el comentario número doce sobre formato.
Pero la revisión por pares es más que encontrar errores.
La revisión también es transferencia de conocimiento. Es memoria del equipo. Es donde alguien pregunta: ¿por qué lo estamos haciendo así? Es donde los estándares implícitos se vuelven explícitos. Y es un momento social de accountability: entrego trabajo a personas con las que voy a seguir trabajando mañana (Bacchelli & Bird, 2013).
Una revisión de IA no puede reemplazar eso sin más. Puedes sentir responsabilidad frente a un compañero. Frente a un modelo, eso funciona distinto (Alami et al., 2025).
Eso no significa que la IA deba quedarse fuera de la revisión. Significa que puede ser un filtro, no la puerta final. Que la IA recoja las señales fáciles. Que las personas juzguen semántica, arquitectura, riesgo y apropiación.
La pregunta final del reviewer no debería ser: “¿La IA encontró algo aquí?”
Debería ser: “¿El autor entiende este cambio, y esto encaja con lo que el equipo está dispuesto a mantener?”
La apropiación no se puede transferir
Este tal vez sea el punto más práctico.
Si hago commit de código, es mi código.
Incluso si la IA lo sugirió. Incluso si un agente lo escribió. Incluso si la sugerencia se veía mejor que mi primera versión. El repositorio no tiene una nota moral al pie que diga: “No se enojen, esto salió de un modelo”. Si el código está mal, “lo escribió la IA” no es una defensa (Vigh et al., 2026).
Apropiación no significa que tengas que escribir todo tú mismo. Esa es una idea romántica, pero poco práctica. Apropiación significa que entiendes lo que aceptas. Que puedes explicar por qué esta solución encaja. Que sabes qué verificaciones se hicieron. Que eres capaz de nombrar los riesgos. Y que estás dispuesto a mantener el código después.
Por eso la pregunta “¿cuánto código escribió la IA?” no me parece tan interesante. Esa pregunta habla sobre todo del origen.
La mejor pregunta es: ¿cuánto de la salida de IA fue entendido, adaptado, probado y aceptado conscientemente?
En estudios sobre pull requests con uso de ChatGPT, los desarrolladores a menudo no integran los parches de IA completos. Seleccionan, modifican, reescriben y combinan (Ogenrwot & Businge, 2026). Eso no es una debilidad de la herramienta. Así se ve el uso profesional.
La IA puede ser un punto de partida. Incluso puede ser un muy buen punto de partida. Pero el punto final sigue siendo el juicio humano.
Un flujo de trabajo que sí funciona
Si quieres usar IA en desarrollo de software en serio, no necesitas un manifiesto enorme. Necesitas un flujo de trabajo lo suficientemente aburrido como para sostenerlo.
Para mí, se reduce a siete pasos:
- Decidir primero si la tarea es adecuada para IA.
- Hacer explícitos la intención, el contexto y las restricciones.
- Dejar que la IA produzca un borrador pequeño.
- Revisar la salida de forma estructurada.
- Ejecutar pruebas, análisis estático y security checks cuando haga falta.
- Usar la revisión como puerta final humana.
- Hacer visible el uso de IA y la verificación en la entrega.
Eso suena menos espectacular que “el agente construye la feature solo”.
Mejor.
Lo espectacular no es el objetivo. El objetivo es software que funcione y que la gente se atreva a cambiar.
El mejor flujo de trabajo con IA no se siente como magia. Se siente como trabajo profesional normal, con un asistente rápido cerca. La herramienta importa, pero el flujo de trabajo alrededor importa por lo menos igual. Ese asistente puede hacer mucho, pero no conoce tu sistema como lo conoce tu equipo. No siente el riesgo de producción. No tendrá que explicar el código en seis meses. No estará en la retro cuando alguien pregunte por qué la complejidad subió de repente.
Tú sí.
La pregunta que queda
No estoy en contra de la IA en desarrollo de software. Al contrario. Me gusta usarla, justamente porque puede hacer mucho trabajo más rápido, más claro y más fácil de revisar.
Pero no quiero que velocidad se confunda con calidad.
Un parche de IA que aparece rápido todavía no es un cambio terminado. Es una propuesta. A veces una buena propuesta. A veces una propuesta con zapatos limpios y barro en la suela. El código rápido todavía puede dejar deuda si la validación y la revisión se debilitan (Liu et al., 2026; Sun et al., 2026).
La pregunta profesional, entonces, no es: ¿podemos hacer que la IA escriba código?
La pregunta es: ¿podemos usar IA sin entregar nuestros propios estándares?
Ahí empieza el trabajo real. No en el prompt. En lo que haces después.
Fuentes
Este artículo se basa en la síntesis de literatura La IA como acelerador, no como reemplazo.
Alami, A., Jensen, V., & Ernst, N. (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, 712-721.
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., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv. https://doi.org/10.48550/arXiv.2507.09089
Chen, V., He, J., Williams, B., Valentino, J., & Talwalkar, A. (2026). Beyond the commit: Developer perspectives on productivity with AI coding assistants. arXiv. https://doi.org/10.48550/arXiv.2602.03593
Cui, Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. SSRN. https://doi.org/10.2139/ssrn.4945566
Fan, G., Liu, D., Pan, L., & Zhang, R. (2026). When help hurts: Verification load and fatigue with AI coding assistants. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, 1-25. 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(11), 172. https://doi.org/10.3390/data10110172
Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., & Lo, D. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild. arXiv. https://doi.org/10.48550/arXiv.2603.28592
Mozannar, H., Bansal, G., Fourney, A., & Horvitz, E. (2024). Reading between the lines: Modeling user behavior and costs in AI-assisted programming. Proceedings of the CHI Conference on Human Factors in Computing Systems, 1-16. https://doi.org/10.1145/3613904.3641936
Mu, F., Shi, L., Wang, S., Yu, Z., Zhang, B., Wang, C., Liu, S., & Wang, Q. (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
Sarkar, A., Xu, X., Toronto, N., Drosos, I., & Poelitz, C. (2024). When Copilot becomes Autopilot: Generative AI’s critical risk to knowledge work and a critical solution. arXiv. https://doi.org/10.48550/arXiv.2412.15030
Sun, X., Ståhl, D., Sandahl, K., & Kessler, C. (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., Olatunji, I. E., War, A., Klein, J., & Bissyande, T. F. (2026). How secure is secure code generation? Adversarial prompts put LLM defenses to the test. arXiv. https://doi.org/10.48550/arXiv.2601.07084
Vigh, E., Sunesen, F., & Barkhuus, L. (2026). “AI does not understand the real world.”: AI augmented software development. Proceedings of the Extended Abstracts of the 2026 CHI Conference on Human Factors in Computing Systems, 1-5. https://doi.org/10.1145/3772363.3799079
Vijayvergiya, M., Salawa, M., Budiselić, I., Zheng, D., Lamblin, P., Ivanković, M., Carin, J., Lewko, M., Andonov, J., Petrović, G., Tarlow, D., Maniatis, P., & Just, R. (2024). AI-assisted assessment of coding practices in modern code review. Proceedings of the 1st ACM International Conference on AI-Powered Software, 85-93. https://doi.org/10.1145/3664646.3665664
Declaración de uso de IA
La IA se usó como apoyo para convertir la síntesis de literatura en un artículo de blog para público general, incluyendo estructura, formulación y revisión de consistencia. Las decisiones de contenido, la interpretación de las fuentes, la edición final y la responsabilidad por el texto definitivo siguen siendo del autor.