Sber presenta tres herramientas de código abierto para agentes de IA y aplicaciones JVM

Un agente de IA escribió el código, pero perdió de vista las restricciones arquitectónicas. Un servicio actualizó un pedido y falló antes de enviar el evento, por lo que un sistema conectado nunca se enteró del cambio. El resumen de Sber presenta tres herramientas de código abierto para este tipo de problemas de ingeniería: HG SDLC, Spring AI GigaChat y Schedulex. Cada una aborda una parte distinta del trabajo: transferir contexto entre agentes, conectar un modelo a una aplicación y ejecutar tareas en segundo plano después de un fallo.

La forma más útil de leer este anuncio es plantearse una pregunta concreta: ¿qué parte de la infraestructura mantiene hoy el propio equipo y podría un proyecto existente reducir ese trabajo? La descripción publicada ofrece suficientes detalles técnicos para una primera evaluación. Sin embargo, las estimaciones de eficiencia siguen siendo afirmaciones de sus autores.

HG SDLC: entregar al agente una tarea junto con su contexto

Imaginemos una mejora habitual: un analista preparó los requisitos, un desarrollador eligió la arquitectura, un agente modificó el código y las pruebas detectaron un error. Ahora hay que devolver la tarea para corregirla, de modo que el agente reciba los requisitos, las restricciones y los resultados de las pruebas. Si todo esto está repartido entre distintos chats, una persona debe mantener la continuidad del proceso.

HG SDLC permite describir el flujo de trabajo mediante un grafo YAML. Incluye nodos con tareas para los agentes, comprobaciones automáticas y puntos en los que una persona toma la decisión. El orquestador almacena el contexto, los artefactos y el historial de ejecución, gestiona las transiciones y permite devolver el trabajo a una etapa anterior.

Según el equipo, la herramienta funciona sobre agentes de programación compatibles con Agent Client Protocol. Para ejecutarla en local se indican Java 21, Node.js 22, PostgreSQL y un agente compatible. Se trata de un componente de infraestructura independiente que también habrá que configurar y mantener.

Los autores estiman una mejora de la eficiencia del desarrollo del 16–30% al combinar agentes, desarrollo basado en especificaciones y HG SDLC. No pueden aislar la contribución del propio orquestador. Por tanto, sería prematuro interpretar esa cifra como una promesa de aceleración para el equipo. Lo primero que conviene comprobar es cuántas transferencias manuales de contexto desaparecen realmente.

Spring AI GigaChat: integrar un modelo en una aplicación existente

El segundo proyecto está dirigido a equipos que utilizan Java o Kotlin y Spring Boot. Escribir una petición directa al modelo es sencillo. Después llegan el historial de conversación, la búsqueda en documentos, las llamadas a funciones, las respuestas en streaming y las métricas. Mantener todo ello en una capa de integración independiente pronto se convierte en una tarea por sí misma.

Spring AI GigaChat se distribuye como un Spring Boot Starter y conecta la API de GigaChat con las interfaces de Spring AI. La aplicación accede al modelo a través de ChatClient, mientras que los componentes relacionados del ecosistema ayudan a gestionar documentos, el historial de mensajes y las herramientas.

Un caso de uso claro es un asistente de documentación interna que responde a un empleado y, cuando hace falta, llama a una función de la aplicación. La lógica de negocio sigue siendo código Java; la integración con el modelo se realiza mediante Spring AI. El artículo también describe la anotación @GigaTool para declarar las funciones disponibles para el modelo.

Antes de integrarlo, hay que comprobar la compatibilidad entre las versiones del starter, Spring Boot y Spring AI. Los autores destacan expresamente el efecto de los cambios de la API sobre la integración. La biblioteca de código abierto tampoco elimina la necesidad de configurar el acceso a la API de GigaChat y la confianza en los certificados del servidor.

Schedulex: resistir los reinicios y mantener la coherencia de los datos

La tercera herramienta aborda el trabajo en segundo plano en la JVM. El ejemplo clave es un servicio que cambia el estado de un pedido y crea una tarea para enviar un evento dentro de una sola transacción en una base de datos compartida. Si la transacción se revierte, no se guarda ninguno de los dos cambios. Tras un commit correcto, el registro de la tarea permanece en la base de datos aunque la aplicación se reinicie.

Schedulex ofrece tareas individuales, grafos de procesos y CodeFlow: una forma de describir un proceso con código convencional, condiciones, esperas y ramas paralelas. Según los autores, la recuperación de CodeFlow se apoya en un registro de los resultados de cada paso y en el estado almacenado en la base de datos. Al actualizar la aplicación, hay que tener en cuenta la compatibilidad del nuevo código con el historial guardado.

El alcance de la garantía es fundamental: una transacción de base de datos no convierte una llamada HTTP externa en una operación atómica. Si el destinatario procesó la petición, pero el emisor no llegó a registrar el éxito, un reintento puede generar un duplicado. Por eso, las operaciones externas necesitan idempotencia: la capacidad de procesar de forma segura una petición repetida.

Los autores señalan un resultado de unas 30,7 mil ejecuciones por segundo, pero con manejadores vacíos y tareas creadas de antemano. Esto no permite predecir el rendimiento de un servicio real.

El siguiente paso práctico es elegir un escenario problemático: la pérdida de contexto, la integración del modelo o el reinicio de un proceso en segundo plano. Probarlo aportará una base más sólida para elegir que una cifra general de aceleración.