La noticia no es que un agente IA escriba código. Eso ya no sorprende a casi nadie. Lo interesante, y también lo delicado, es que empresas como Endava están rediseñando su forma de entregar software alrededor de agentes conectados a herramientas, documentación y flujos de trabajo. OpenAI lo contó esta semana en un caso publicado sobre Endava y sus equipos de delivery.
Para una empresa de Donostia - San Sebastián o Gipuzkoa, la pregunta útil no es si hay que copiar ese modelo. La pregunta es más concreta: qué partes del trabajo técnico se pueden acelerar sin convertir el repositorio, el ERP o el sistema de tickets en una caja negra.
Qué cambia cuando el agente entra en el flujo de desarrollo
Un copiloto de código ayuda a escribir una función. Un agente IA bien diseñado puede hacer algo más operativo: leer un ticket, revisar documentación interna, proponer cambios, preparar pruebas, abrir una pull request o resumir el impacto para negocio.
Ahí aparece el ahorro. No tanto en "programar más rápido" como en reducir esperas entre análisis, desarrollo, revisión y despliegue. En equipos pequeños se nota mucho: menos tiempo buscando contexto, menos tareas repetidas y menos reuniones para explicar lo que ya está escrito en Jira, GitHub, GitLab, Confluence o el CRM.
Pero conviene bajar el entusiasmo a tierra. Si el proceso actual está desordenado, el agente no lo arregla solo. Lo hará más rápido, con los mismos agujeros.
Dónde suele haber retorno en pymes y equipos técnicos
En proyectos de IA para pymes y empresas medianas, los primeros casos con sentido suelen estar cerca del trabajo repetitivo y verificable:
- Clasificar tickets técnicos y detectar bloqueos antes de la reunión diaria.
- Generar borradores de pruebas a partir de requisitos ya aprobados.
- Preparar resúmenes de cambios para soporte, operaciones o dirección.
- Revisar documentación interna y avisar cuando no coincide con el código.
- Crear asistentes RAG para que nuevos perfiles entiendan producto, arquitectura y procedimientos.
No hace falta empezar con un agente que toque producción. De hecho, casi nunca lo recomendaría. Lo sensato es empezar con tareas que preparan trabajo para revisión humana.
Control humano: la diferencia entre ayuda y riesgo
Un agente con acceso a repositorios, APIs o sistemas internos debe tener límites muy claros. Consultar información no tiene el mismo riesgo que modificar datos. Preparar una pull request no es lo mismo que fusionarla. Redactar un email a cliente no es enviarlo.
La forma práctica de diseñarlo es separar permisos por nivel:
- El agente puede leer y resumir.
- El agente puede preparar cambios o borradores.
- El agente solo ejecuta acciones sensibles con aprobación explícita.
Esto encaja especialmente bien en consultoría IA en San Sebastián y proyectos de IA en Gipuzkoa, donde muchas empresas quieren eficiencia, pero no quieren perder trazabilidad ni control del dato.
Qué documentación necesitas antes de implantarlo
Los agentes IA funcionan peor cuando la empresa trabaja con conocimiento tribal. Si las reglas están en la cabeza de dos personas, el agente improvisará demasiado.
Antes de automatizar, revisa cuatro piezas:
- Repositorios y ramas: qué puede leer, dónde puede proponer cambios y quién revisa.
- Tickets y requisitos: cómo se escribe una tarea bien definida.
- Guías técnicas: patrones permitidos, dependencias, seguridad y estilo.
- Criterios de calidad: pruebas mínimas, revisión humana y registro de decisiones.
Este trabajo también mejora el equipo aunque luego no despliegues ningún agente. Es una buena señal. La IA deja al descubierto problemas que ya existían.
Señales de que merece la pena actuar ahora
Un diagnóstico tiene sentido si tu empresa reconoce alguno de estos síntomas:
- El equipo técnico pierde horas buscando contexto entre herramientas.
- Hay retrasos por documentación incompleta o tickets mal definidos.
- Soporte y desarrollo se pasan incidencias sin suficiente información.
- Las revisiones de código se acumulan por tareas repetitivas.
- Dirección quiere medir mejor el coste real de cambios y mantenimiento.
Si además ya usáis herramientas como GitHub, GitLab, Jira, Azure DevOps, Notion, Confluence o un ERP con API, hay base suficiente para un piloto pequeño.
Primer paso razonable para empresas de Euskadi
El primer paso no debería ser comprar licencias a ciegas. Mejor hacer un mapa de flujo: desde que entra una petición hasta que se despliega o se entrega al cliente. En ese mapa se ve dónde hay esperas, duplicidades y trabajo que un agente puede preparar sin asumir decisiones críticas.
En Umintia solemos plantearlo como un diagnóstico corto para empresas de IA en Donostia, equipos técnicos de Gipuzkoa y compañías de Euskadi que quieren probar agentes IA con cabeza. Cuando el proyecto encaja de forma remota, también trabajamos con empresas en España.
Puede terminar en un agente conectado a documentación interna, en una automatización de procesos con revisión humana o en una arquitectura RAG empresarial para soporte técnico. Depende del cuello de botella real, no de la herramienta de moda.
Si quieres revisar tu flujo de desarrollo o soporte técnico, escríbenos a info@umintia.com. Podemos estimar qué tareas se podrían automatizar, qué riesgos habría que controlar y qué ROI tendría un piloto de 3 a 6 semanas.
Referencia: el caso de OpenAI sobre Endava y agentes IA en delivery de software, publicado el 4 de junio de 2026: How Endava is redesigning software delivery around AI agents. También puede encajar con servicios de agentes IA autónomos, automatización inteligente y soluciones GenAI y LLMs.