En diciembre de 2025, Stack Overflow publicó su encuesta anual con más de 49 mil desarrolladores en todo el mundo. El número central: el 80% de ellos ya usa herramientas de IA en el trabajo, un salto marcado respecto al año anterior. Un mes antes, el informe Octoverse de GitHub había mostrado otro ángulo del mismo fenómeno: casi el 80% de los nuevos desarrolladores que se registran en la plataforma ya usa un asistente de IA en su primera semana de cuenta.
La encuesta de JetBrains, con más de 24 mil desarrolladores en 194 países, llega a un número parecido desde el ángulo del uso continuo: el 85% de los desarrolladores usa IA con regularidad en el trabajo, y el 62% depende de al menos un asistente de código, agente o editor con IA integrada para completar tareas, revisar fragmentos, generar pruebas o escribir documentación.
Pocas categorías de software tuvieron una curva de adopción tan rápida entre un público técnico específico. Y ahí está exactamente el punto de este texto: un público específico. Estas herramientas fueron diseñadas, probadas y optimizadas para alguien que ya sabe programar, ya convive con la terminal y el control de versiones, y ya entiende lo que significa revisar un fragmento de código antes de aceptarlo. Cuando la misma herramienta llega al escritorio de finanzas, de recursos humanos o de ventas, arrastra consigo supuestos que dejan de cumplirse.
Dónde estas herramientas realmente brillan
Los asistentes de IA para código se construyeron sobre un supuesto simple: quien está del otro lado sabe programar. Completar una función, sugerir una prueba, refactorizar un fragmento, explicar un error de compilación — cada uno de estos usos, listados por la propia encuesta de JetBrains entre los más comunes, supone que la persona puede leer el resultado, notar cuándo está mal y corregir el rumbo.
Esa es una tarea que el desarrollador ya hace desde hace décadas al revisar el código de un colega. La IA entra como un acelerador de un criterio técnico que la persona ya tenía antes de que existiera la herramienta — y eso explica por qué la adopción fue tan rápida: el producto encajó exactamente en la rutina que ya existía, dentro del entorno de programación que la persona ya usaba, sin exigir que cambiara de herramienta ni de vocabulario.
El propio dato de confianza de la encuesta de Stack Overflow confirma ese encaje, aunque de forma indirecta. Solo el 29% de los desarrolladores confía plenamente en la precisión de lo que produce la IA — una caída fuerte respecto al año anterior — y el 66% dice dedicar más tiempo del esperado a revisar código generado por IA. Eso no es un fracaso de la herramienta: es el profesional aplicando exactamente el escepticismo técnico que exige su puesto. El 75% dijo que, ante la duda, prefiere buscar ayuda de otra persona antes que confiar en la respuesta de la IA.
Por qué la misma herramienta tropieza fuera del código
Ese escepticismo entrenado es la primera pieza que falta cuando la herramienta sale del equipo técnico. Una persona de finanzas que recibe una respuesta sobre una cláusula contractual no tiene el mismo instinto para desconfiar de un número que "parece correcto pero no lo es" — porque nunca tuvo que entrenar ese instinto. El problema no es que esa persona sea menos capaz. Es que la herramienta fue diseñada suponiendo un tipo de revisión que solo practica quien programa todos los días.
La segunda pieza que falta es estructural, y explica por qué esto es una cuestión de arquitectura, no de personalidad de los equipos. Estas herramientas suelen pedir una cuenta personal, creada por quien instaló el programa en su propia máquina — muchas veces con una credencial propia, pagada con tarjeta corporativa o personal, fuera del control de identidad de la empresa. Cuando esa persona cambia de equipo o deja la empresa, el acceso no se revoca automáticamente junto con el resto de los sistemas: alguien tiene que acordarse de cancelar esa cuenta específica.
La tercera pieza es la ausencia de rol y de aprobación. La herramienta no sabe, ni necesita saber, si quien está del otro lado es un pasante o el director financiero — porque fue construida para un escenario donde eso no importa: el código pasa por la revisión de otro programador y por un proceso de aprobación antes de llegar a producción. Fuera del código, ese segundo revisor no existe por defecto. Y no hay un registro central que el área de TI o de cumplimiento pueda consultar después, porque la conversación ocurrió en una herramienta que la empresa ni siquiera sabía que se estaba usando.
Nada de esto es un defecto del producto. Es el producto correcto, diseñado para el público correcto, llegando a un público distinto de aquel para el que fue pensado.
Lo que tiene que existir en la práctica
Llevar la IA a toda la empresa — no solo a quien programa — exige un diseño distinto, verificable en cinco puntos.
Identidad corporativa, no una cuenta personal creada al momento. El acceso viene del mismo directorio que ya controla el correo y los sistemas internos, así que la baja o el cambio de función actualizan el acceso a la IA junto con todo lo demás, sin depender de que alguien recuerde una cuenta suelta.
Acceso según el rol de cada persona. Finanzas ve lo que finanzas necesita; ventas, lo que ventas necesita — sin exigir que nadie entienda el concepto de permisos de un programador para trabajar con seguridad.
Aprobación antes de una acción sensible. Cuando la solicitud implica algo con impacto real — enviar un mensaje, cambiar un registro, aprobar un monto — el flujo se detiene y pide la confirmación de una persona, dentro de la misma conversación, en lugar de asumir que quien está ahí sabe revisar como lo haría un programador.
Conocimiento aprobado de la propia empresa. Las respuestas parten de documentos, políticas y procesos con dueño y versión vigente — no del conocimiento general de internet que trae de fábrica cualquier asistente.
Registro de auditoría central. Quién pidió qué, cuándo y con qué resultado queda registrado en un solo lugar que el área de TI puede consultar — no disperso en cuentas personales que la empresa ni siquiera sabe que existen.
Así fue diseñada la Skyller: identidad proveniente del directorio de la empresa, permiso por rol, aprobación y registro como estándar para cualquier área — no solo para quien ya sabe programar.
Dónde tiene sentido cada herramienta
Nada de esto hace peores a las herramientas agénticas de programador en lo que hacen. Un asistente afinado para leer un repositorio entero, sugerir una refactorización o generar una prueba sigue siendo, para quien programa, la herramienta correcta — y lo seguirá siendo mientras exista código que escribir. El error está en el encaje: tomar una herramienta diseñada y probada para ese público específico y ofrecerla, sin adaptación alguna, al resto de la empresa, esperando que aparezcan solos la misma curva de adopción y el mismo criterio técnico en quien nunca los necesitó antes.
Una plataforma pensada para toda la empresa resuelve el problema desde el otro lado: llega ya con identidad, rol, aprobación y auditoría incorporados, y con agentes listos por área — la Skyller, por ejemplo, ya viene con más de 100 agentes preconfigurados para rutinas de finanzas, recursos humanos, ventas y otras áreas — en vez de pedirle a cada departamento que reinvente, sin apoyo, lo que el equipo técnico tardó años en aprender a hacer con seguridad.
Preguntas para la próxima reunión de TI
Antes de extender al resto de la empresa una herramienta que hoy solo usa el equipo técnico, conviene responder estas preguntas:
- ¿Quién fuera del equipo técnico ya usa IA por su cuenta, con una cuenta personal y sin que la empresa lo sepa? Si la respuesta es "no lo sabemos", el primer paso es averiguarlo, no prohibirlo.
- Si esa persona deja la empresa mañana, ¿su acceso a esas herramientas cae junto con el resto? Si la respuesta depende de que alguien recuerde cancelar una cuenta suelta, el problema es de identidad, no de la herramienta.
- ¿Existe un lugar central donde TI pueda ver qué se pidió y con qué resultado? Si la respuesta es no, la empresa está expuesta a un riesgo que ni siquiera puede medir.
- ¿La herramienta que ama el equipo técnico es la misma que debería llegar a finanzas, recursos humanos y ventas? Casi siempre la respuesta es no — y está bien. Son problemas distintos, y cada uno merece la herramienta correcta.
