Cada vez más equipos de desarrollo ya usan IA en su día a día: autocompletado avanzado, generación de código, incluso agentes que abren pull requests por su cuenta. Y sin embargo, muchos de esos mismos equipos notan que la adopción se frena justo cuando empieza a importar de verdad, cuando se intenta pasar de "un desarrollador probando una herramienta" a "un proceso de desarrollo que incorpora IA de forma sistemática". Ese salto no falla por falta de modelos potentes. Falla por tres motivos muy concretos, que se repiten en organización tras organización: la IA no tiene un contexto fiable sobre el que trabajar, los equipos de seguridad no están dispuestos a abrir la puerta sin garantías, y la revisión humana del código generado se convierte en un cuello de botella nuevo justo cuando se suponía que todo iba a ir más rápido.
Esto no es una afirmación gratuita: quedó muy claro durante el State of AI SDLC, el summit digital organizado por Atlassian y celebrado el pasado 22 de septiembre, al que se registraron 30.000 personas, abierto por Mike Cannon-Brookes, CEO y cofundador de Atlassian, junto a Guillermo Rauch, CEO de Vercel, con la participación de responsables de Lovable, DX, Dropbox, 1Password, Honeycomb y la propia Atlassian. Durante la sesión en directo, tres preguntas se repitieron una y otra vez, planteadas por personas distintas y en momentos distintos: cómo construir un contexto fiable para los agentes cuando la documentación está dispersa entre varias herramientas; cómo convencer a los equipos de seguridad de dar acceso a esos agentes sin disparar el riesgo de fuga de información sensible; y cómo evitar que la revisión humana se convierta en el nuevo cuello de botella cuando el código se genera mucho más rápido de lo que se puede revisar con calidad. Tres preguntas de gente que ya trabaja con estas herramientas todos los días, no de alguien intentando venderles algo.
Contexto disperso: el problema no es la IA, es lo que la rodea
Un agente de IA solo es tan bueno como el contexto que se le da. Y en la mayoría de las organizaciones, ese contexto está repartido entre un gestor de proyectos, un wiki interno, hilos de Slack, documentos sueltos en una unidad compartida y el propio código, sin que exista un único lugar donde todo eso encaje. Cuando la documentación está así de fragmentada, el agente no tiene forma de saber por qué se tomó una decisión de arquitectura, qué convenciones sigue el equipo o qué partes del sistema son especialmente sensibles a cambios. El resultado es previsible: sugerencias que parecen razonables pero no encajan con el resto del sistema, código que hay que reescribir a mano después, o directamente respuestas inventadas porque el modelo rellena huecos con suposiciones en lugar de con información real.
La reacción habitual es parchear el problema caso por caso, escribiendo prompts cada vez más largos y detallados para compensar lo que falta. Funciona a pequeña escala, pero no escala como proceso de equipo: cada persona termina construyendo su propio contexto manual, no reutilizable, no auditable y que se desactualiza en cuanto cambia algo. El problema de fondo no es que la IA no sea lo bastante potente, es que nadie le ha dado un contexto fiable y centralizado sobre el que trabajar, algo que abordamos de raíz en nuestra solución de AI SDLC.
Seguridad y gobierno: por qué la resistencia no es infundada
Cuando un equipo de desarrollo pide dar a un agente de IA acceso a repositorios, pipelines o sistemas internos, es razonable que seguridad ponga freno. No se trata de resistencia al cambio por resistencia al cambio: es que dar ese acceso implica abrir una nueva superficie de ataque que la mayoría de los marcos de seguridad todavía no contemplan. Un agente que puede leer código y documentación interna también puede exponer información sensible en un prompt, en un log o en una respuesta, sin que exista todavía un modelo de permisos granular ni un registro de auditoría que permita saber qué ha visto y qué ha hecho.
Por eso, la pregunta que de verdad hay que responder no es "¿confiamos en la IA?", sino "¿qué puede ver, qué puede tocar y quién puede comprobarlo después?". Sin una gobernanza clara —permisos por rol, trazabilidad de cada acción, límites explícitos sobre qué sistemas y qué datos son accesibles—, cualquier despliegue de IA a escala se queda bloqueado en el mismo punto: seguridad diciendo que no hasta que alguien demuestre que el riesgo está controlado. Y tienen razón en pedirlo.
El cuello de botella se mueve, no desaparece
Uno de los argumentos de venta más repetidos sobre la IA en desarrollo es que acelera la escritura de código. Es cierto, pero solo cuenta la mitad de la historia. Cuando el código se genera mucho más rápido de lo que un equipo puede revisarlo con garantías, el cuello de botella no desaparece: simplemente se desplaza de la escritura a la revisión. Un desarrollador que antes tardaba una hora en escribir una función ahora puede generar varias en minutos, pero seguir necesitando el mismo tiempo, o más, para revisar que ese código es correcto, seguro y coherente con el resto del sistema.
Si esa revisión no se rediseña, pasa una de dos cosas: o la calidad se resiente porque se revisa por encima para no frenar el ritmo, o los tiempos de entrega no mejoran realmente porque la cola se ha movido, no se ha eliminado. Ninguna de las dos opciones es la promesa que se vendió. Escalar la IA en el ciclo de desarrollo exige repensar también cómo se revisa, no solo cómo se genera.
Ya has visto dónde suelen bloquearse los equipos al escalar la IA en su ciclo de desarrollo: contexto, gobierno y revisión. El siguiente paso lógico es contrastarlo con tu propia organización. Te dejamos el mismo checklist que usamos para evaluar el punto de partida de un equipo antes de abordar un AI SDLC maduro, para que puedas identificar en cuál de estos tres frentes estás realmente más expuesto.
¿No ves el botón? Accede aquí a la solución AI SDLC y descarga el checklist
Ninguna de las tres se resuelve por separado
Contexto, gobierno y revisión no son tres proyectos independientes: son tres piezas del mismo problema, y tratarlas por separado suele ser la razón por la que las iniciativas de IA se quedan a medio camino. Un contexto centralizado sin permisos claros es un riesgo de seguridad. Un modelo de permisos sin un contexto fiable no evita que el agente trabaje con información incompleta. Y ninguna de las dos cosas sirve de nada si la revisión humana sigue siendo un cuello de botella sin rediseñar.
Llevamos más de 30 años integrando y desarrollando sobre el ecosistema Atlassian, y ese es precisamente el enfoque con el que trabajamos un AI SDLC maduro: no como una herramienta aislada, sino como un proceso completo que conecta planificación, desarrollo, pruebas y lanzamiento sobre una base común. Eso significa llevar Jira, Confluence, Jira Product Discovery y Rovo a un mismo contexto compartido, con permisos y trazabilidad definidos desde el diseño, y con la revisión integrada como parte del flujo, no como un paso añadido al final. Es un trabajo de arquitectura e integración tanto como de desarrollo, y es la diferencia entre incorporar IA como un experimento puntual y convertirla en parte real de cómo el equipo construye software.
Si estas tres barreras te resultan familiares, hablemos de tu caso concreto.