Repartir licencias de IA no transforma una empresa
Mi experiencia con agentes de codificación me ha enseñado que repartir licencias no basta: también importan la tarea, el contexto y el esfuerzo de revisión.
He trabajado de forma intensiva con agentes de codificación en repositorios reales. He contado ese recorrido con más detalle. Esa experiencia me ha enseñado que el acceso a una herramienta no decide por sí solo el resultado: también importan el problema, el contexto que puedo aportar y mi capacidad para revisar lo que devuelve. El mismo agente me ayuda en un cambio acotado y puede dejarme más trabajo de revisión cuando el alcance crece o la decisión de partida sigue abierta.
Mi recorrido es individual. No lo presento como una prueba del efecto de las licencias en una empresa. Sí me sirve para explicar qué queda sin resolver cuando una organización confunde dar acceso con mejorar el trabajo. Una licencia abre la puerta a una capacidad tecnológica; convertirla en valor exige decidir para qué usarla, qué procesos modificar y cómo comprobar el resultado.
Diferenciar acceso, adopción y productividad
Por eso separo conceptos que con frecuencia aparecen mezclados. El acceso, la adopción, la capacidad, la integración, la productividad y el valor son dimensiones relacionadas, no una secuencia necesaria ni equivalente en todas las organizaciones.
En mi trabajo, tener acceso no me dice si la herramienta resuelve una tarea ni cuánto esfuerzo añade después. Puedo obtener una propuesta en poco tiempo y tardar bastante más en entenderla, revisarla e integrarla. Si quisiera saber si la IA aporta valor a una organización, observaría qué trabajo ha cambiado y qué ocurre con la calidad, el retrabajo y el tiempo total.
El trabajo es la unidad de transformación
Cuando automaticé parte de mi ciclo editorial, descubrí que la auditoría podía aprobar errores que debía detectar. Para entender por qué, tuve que revisar qué contexto recibía y qué criterios compartía con la generación. El modelo era solo una pieza; también tenía que examinar las instrucciones, las comprobaciones y la independencia de la revisión.
Esa experiencia es la razón por la que, al hablar de transformación, no me quedo en la herramienta. Recorro el trabajo completo: la información que entra, las reglas y decisiones, los permisos, la validación, los fallos, el registro y la medición del resultado. Acelerar un paso no modifica por sí solo el resto del proceso.
La IA también amplifica los problemas
En mi trabajo con agentes he aprendido que una implementación puede parecer terminada y seguir sin resolver bien el problema. He tenido que revisar cambios que modificaban varios archivos y contrastarlos con el comportamiento que debía conservar el producto. Que el código compile o que las pruebas pasen no basta si nadie comprueba qué requisito demuestran y qué caminos del sistema siguen abiertos.
El agente puede haber producido más rápido sin que eso corrija una decisión equivocada. En mi experiencia, la velocidad de ejecución no sustituye el criterio que permite decidir si el cambio encaja en el producto.
Cuando aumenta mi capacidad para producir cambios, también puede crecer el alcance de mis errores. La producción puede acelerarse más que la comprensión y la revisión. Una decisión equivocada que antes afectaba a unas pocas líneas puede propagarse por decenas de archivos en cuestión de minutos.
El criterio sigue siendo necesario
En mi trabajo uso instrucciones, documentación, agentes y comprobaciones para reducir parte de ese riesgo. El contexto ayuda a trasladar conocimiento al sistema, pero no elimina la necesidad de juzgarlo. Una regla puede pedirme que compruebe si ya existe un componente equivalente; la decisión de si realmente lo es sigue siendo mía. Un procedimiento puede exigir una revisión arquitectónica; yo sigo teniendo que reconocer cuándo la decisión no encaja.
La IA puede aumentar mi capacidad para ejecutar una tarea, pero no garantiza que yo haya elegido bien el problema, el enfoque o la solución. Por eso, en mi experiencia, el conocimiento del dominio y el criterio profesional siguen formando parte del trabajo.
Automatizar tampoco consiste en poner un modelo en medio
De ese caso saco una cautela para cualquier automatización: yo no daría por válido el proceso tras una demostración correcta. Comprobaría cómo se resuelven la identidad, los permisos, las integraciones y las excepciones; qué puede detectar la revisión y cómo se puede descubrir o corregir un error. El modelo es una pieza del sistema, no una prueba de que el proceso vaya a funcionar a escala.
El riesgo de medir lo que resulta fácil medir
Al evaluar mi propio trabajo, no me bastaría con contar peticiones o líneas generadas: compararía el tiempo de producción con el esfuerzo de revisar e integrar el resultado. Si una organización quiere medir el efecto de la IA, yo miraría también la calidad, los errores, el retrabajo, el tiempo total y el resultado conseguido. La producción es una señal; no demuestra por sí sola que haya mejorado el trabajo.
La productividad tampoco se distribuye uniformemente
No tengo una comparación propia entre cien personas con la misma licencia, así que no presento mi experiencia como prueba de esa diferencia. Lo que sí he comprobado en mi trabajo es que el resultado cambia según la tarea, el contexto disponible y lo que sé revisar. En los cambios amplios que he abordado, delegar la ejecución me ha servido menos cuando todavía no podía evaluar bien las decisiones que el agente iba tomando.
La investigación tampoco permite prometer un efecto uniforme. Tres experimentos de campo con 4.867 desarrolladores encontraron mayores ganancias medias entre quienes tenían menos experiencia (Cui y otros, Management Science). Un experimento del Banco de Pagos Internacionales con CodeFuse atribuyó buena parte de la diferencia a que los programadores sénior usaban la herramienta con menor frecuencia (Gambacorta y otros). En cambio, un análisis observacional de 100.097 desarrolladores estadounidenses con actividad en GitHub encontró aumentos asociados al uso entre perfiles sénior, pero no entre quienes empezaban (estudio publicado en Science). Son tareas, herramientas, medidas y diseños distintos: no predicen lo que ocurrirá en una empresa concreta ni demuestran que la experiencia siempre favorezca a una persona.
Por eso formulo la conclusión con cuidado: repartir el mismo acceso no garantiza que cada persona lo convierta en el mismo resultado. Para saber qué ocurre, hay que observar el trabajo real y las condiciones de uso, no inferir productividad del número de licencias.
La formación en IA tampoco puede reducirse a redactar instrucciones
Esa experiencia también cambia cómo entiendo la formación. En mi trabajo no me ha bastado con aprender instrucciones: necesito saber cuándo delegar, qué contexto aportar, cómo verificar el resultado y qué información proteger. Cada profesión suma sus propios criterios; por ejemplo, en desarrollo hay que revisar código, en análisis comprobar datos y supuestos, y en educación valorar la adecuación pedagógica y la exactitud factual. Para mí, la competencia consiste en ejercer la profesión con IA, no solo en redactar peticiones.
De desplegar licencias a construir capacidad organizativa
Por eso, si me pidieran diseñar una adopción organizativa, empezaría por cambiar la pregunta.
Mi experiencia me lleva a esta conclusión: adoptar IA cambia el sistema de trabajo; tratarla solo como un despliegue de software deja fuera buena parte del problema.
En lugar de preguntar «¿A cuántas personas voy a dar una licencia?», preguntaría «¿Qué capacidad quiero aumentar y qué debo cambiar para conseguirlo?».
1. Partir del trabajo, no de la herramienta
Identificaría tareas y decisiones donde exista una oportunidad real de mejora. No empezaría preguntando dónde introducir IA, sino qué trabajo quiero hacer mejor y por qué.
2. Establecer una línea base
Antes de cambiarlo, mediría cuánto tarda ese trabajo, dónde falla, cuánto retrabajo genera y qué calidad produce. Sin una referencia previa no podría saber si ha mejorado.
3. Diseñar la intervención
Decidiría qué capacidades puede ampliar la IA, qué podría automatizar, qué reservaría a una persona y qué contexto, datos, permisos e integraciones necesitaría el nuevo proceso.
4. Construir capacidad, no solo acceso
Prepararía formación para cada disciplina y la acompañaría de conocimiento compartido, patrones de trabajo, instrucciones, herramientas, skills, agentes y servidores MCP. Así podría trasladar una práctica útil más allá de quien la descubrió.
5. Introducir verificación y gobierno
Definiría cómo evaluar los resultados, dónde hace falta revisión humana y qué controles necesito para seguridad, privacidad, trazabilidad, observabilidad, calidad y costes.
6. Medir resultados, no solamente uso
Mediría tiempo de ciclo, calidad, errores, retrabajo, costes, autonomía y resultados de negocio. Los usuarios activos, las peticiones enviadas y el código generado explicarían el uso, pero no demostrarían productividad.
7. Extender lo que funciona
Extendería herramientas, patrones y automatizaciones cuando hubieran demostrado mejorar el trabajo. Ampliar el acceso sería una decisión posterior, no el punto de partida. La licencia aparece en algún punto de esa lista, lejos de completar la transformación.
Proporcionar acceso también puede ser una forma de aprender
No descartaría dar acceso ampliamente como una forma de explorar. En mi trabajo he descubierto usos mientras resolvía tareas concretas, no al empezar por una lista de herramientas. Para una organización, experimentar puede revelar oportunidades; después habría que comprobar cuáles mejoran el trabajo y convertirlas en prácticas sostenibles. Probar sin conocer todavía el retorno puede ser razonable. Extender una práctica sin saber qué valor produce es otra decisión.
La IA no hace productiva a una organización por sí sola
En mi trabajo, el cambio no llega cuando abro el agente, sino cuando consigo integrarlo en un proceso que puedo entender y revisar. En una organización puede ocurrir algo parecido a otra escala: el modelo contratado importa, pero también importa cómo se reorganiza el trabajo alrededor de él. Reducir el coste de producir algo no garantiza que se esté produciendo lo correcto. Por eso, yo trataría el reparto de licencias como un posible comienzo y mediría después qué ha cambiado realmente.
Desarrollo el paso de la experimentación a una capacidad organizativa en «De las licencias a la capacidad: cómo abordar la adopción de IA en una organización». La diferencia se comprueba al observar si la organización se ha limitado a desplegar IA o ha transformado realmente su forma de trabajar.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Seguir leyendo
- Cómo saber si la IA está aumentando realmente la productividad
La velocidad es una de las mejoras más visibles que introduce la inteligencia artificial y, precisamente por eso, también puede convertirse en una de las más engañosas.
- De las licencias a la capacidad: cómo abordar la adopción de IA en una organización
La adopción de IA comienza por el trabajo que la organización quiere mejorar y por las capacidades necesarias para sostener ese cambio.
- Qué hacía antes un desarrollador y qué tiene que hacer ahora con agentes de IA
Cuento qué ha cambiado en mi trabajo con agentes de IA: el análisis, el contexto que preparo, la revisión del código y mi responsabilidad sobre el resultado.