Las cifras de adopción de IA en desarrollo se citan mal con frecuencia. Qué miden realmente, qué no cambian, y qué prácticas hay que endurecer cuando el código no lo escribe una persona.
Los reportes de adopción de IA generativa en desarrollo de software vienen dejando titulares que circulan rápido: equipos que duplican su output, dos tercios del código escrito por asistentes, un 90% a la vuelta de la esquina. Vale la pena detenerse en qué miden esas cifras antes de sacar conclusiones, porque la mayoría se cita de una manera que el dato original no sostiene. Y después, la pregunta que de verdad importa: ¿qué pasa con la calidad cuando una parte creciente del código no la escribió una persona?
El dato más repetido viene de un informe de Jellyfish, recogido por la prensa técnica a comienzos de 2026: cerca del 64% de las empresas generan la mayoría de su código con asistencia de IA, y esa proporción podría llegar al 90% en el plazo de un año. Es importante leerlo con precisión: el 64% y el 90% describen cuántas empresas usan IA de forma predominante, no qué porcentaje del código escribe la máquina. Son dos afirmaciones muy distintas, y la segunda es la que se volvió titular.
Lo mismo pasa con la duplicación del output. Lo que el informe mide es el throughput de pull requests: las organizaciones que adoptan IA de forma agresiva reportan el doble de PRs que las de baja adopción, en una ventana de tres meses. Más pull requests no es lo mismo que más funcionalidad entregada, ni que más valor para el negocio.
Y los agentes autónomos, los que generan pull requests sin intervención humana, todavía son una porción menor: en el decil de empresas más avanzadas pasaron del 10% de los PRs en enero de 2026 al 14% en febrero. Crece rápido, pero está lejos del relato de que el código ya se escribe solo.
Nada de esto quita que el cambio sea real y profundo. Lo que cambia es la conversación: no estamos discutiendo si la IA reemplaza a los desarrolladores, estamos discutiendo cómo trabaja un equipo cuando una parte importante de lo que llega a revisión no la escribió un humano.
Esto no es una opinión contraria al informe: es lo que el informe dice. Los datos muestran que el incentivo de la adopción está ligado a ganancias de productividad medibles y no a mejoras de calidad, y que acelerar la producción no garantiza menos errores ni mejor mantenibilidad del código.
Generar código más rápido no resuelve por sí solo los problemas de fondo de un proyecto de software: arquitectura mal pensada, deuda técnica acumulada o falta de criterio de negocio. La IA acelera la escritura, pero no reemplaza el juicio técnico sobre qué construir y por qué. Un equipo que duplica su velocidad sobre una base mal diseñada llega antes al problema, no lo evita.
Cuando una porción importante del código no fue escrita por una persona, la revisión de código y el testing dejan de ser un paso más y pasan a ser la primera línea de defensa. Los equipos que mantienen la calidad son los que endurecieron sus prácticas de code review y ampliaron su cobertura de tests automatizados, no los que simplemente adoptaron una herramienta nueva.
Hay un efecto secundario que conviene anticipar: si el volumen de pull requests se duplica pero la capacidad de revisión sigue igual, el cuello de botella se corre a la revisión. El riesgo no es solo que entre código malo, sino que entre código que nadie llegó a mirar con atención porque la cola era demasiado larga. Escalar la capacidad de revisar es parte del proyecto de adoptar IA, no una consecuencia que se resuelve sola.
La IA generativa es más efectiva cuando trabaja dentro de límites claros: una arquitectura bien definida, contratos de API explícitos, y convenciones de código consistentes. Sin ese marco, la velocidad que gana un equipo se paga después en incidentes y refactors.
En sistemas de misión crítica, esto pesa el doble. Una decisión de arquitectura equivocada en una plataforma bancaria o en un sistema con requisitos de compliance no se corrige con un pull request: se corrige con un proyecto. La herramienta que escribe más rápido no cambia quién decide qué se construye.
Para una empresa que desarrolla software a medida, la pregunta no es si usar IA generativa, sino cómo integrarla sin sacrificar la calidad de entrega. Eso implica procesos de revisión más rigurosos, buenas prácticas de arquitectura y equipos que entienden tanto la herramienta como el oficio de construir software.
En Sagant incorporamos IA en nuestros procesos de desarrollo, pero manteniendo los mismos estándares de calidad que exigimos desde siempre. La tecnología cambia la forma de trabajar; el criterio técnico sigue siendo lo que marca la diferencia.
¿Cómo está encarando tu equipo la adopción de IA generativa en el ciclo de desarrollo? Nos encantaría conocer tu experiencia.
