Serena

Serena es una caja de herramientas para agentes de programación que necesitan consultar y editar un proyecto con información semántica. En lugar de limitarse a buscar cadenas o trabajar con números de línea, utiliza símbolos y relaciones del código. Esa capa acerca al agente capacidades asociadas a un entorno de desarrollo, mientras el modelo sigue decidiendo qué consultas realizar y qué cambios proponer.

La integración se ofrece mediante MCP. Puede utilizarse con clientes de terminal, asistentes de editor y otras aplicaciones compatibles, siempre que se configure su conexión. Serena no sustituye al modelo ni constituye por sí sola una sesión de programación autónoma: aporta herramientas que el cliente y el modelo coordinan durante el trabajo sobre el proyecto.

Una modificación de código puede requerir comprender qué símbolo se está cambiando y qué relaciones tiene con el resto del proyecto. La búsqueda de texto ayuda, pero no siempre distingue una definición de una referencia o de una coincidencia sin relación. Serena plantea una interfaz de consulta y edición que aprovecha el análisis del lenguaje para dar al agente un contexto más preciso.

El interés aparece cuando la tarea depende de la estructura del programa. Antes de una refactorización, el agente puede apoyarse en esa información para entender el área afectada. Esto no demuestra que cualquier modificación será correcta ni establece una mejora de rendimiento para tu repositorio. La utilidad debe evaluarse con las tareas y los lenguajes que realmente utiliza el equipo.

El cliente conecta al agente con el servidor de Serena. El modelo solicita operaciones y recibe información del código o resultados de edición. El análisis puede basarse en servidores de lenguaje, que constituyen la alternativa predeterminada, o en la integración de JetBrains. La elección del backend determina parte de los requisitos y de las capacidades disponibles en el proyecto.

La referencia contempla que el cliente arranque Serena mediante un comando o que se conecte a una instancia iniciada en modo HTTP. Son recorridos distintos de configuración; no conviene copiar un bloque de otro cliente sin comprobar su documentación. El proyecto también advierte que algunos lenguajes necesitan dependencias adicionales para que el backend pueda analizarlos correctamente.

Ejemplo de KIRELEN: un equipo quiere revisar una función utilizada desde varias partes de una aplicación. Antes de cambiarla, pide al agente entender el símbolo y sus relaciones. Serena aporta las herramientas de análisis y el modelo utiliza esa información para formular una propuesta acotada. El equipo revisa el alcance antes de aceptar la edición.

Después se examina el diff y se ejecutan las comprobaciones que correspondan al proyecto. Si el análisis no encuentra lo esperado, se revisan el lenguaje, el backend y sus dependencias antes de atribuir el fallo al código de la aplicación. El ejemplo describe una forma de organizar la revisión; no informa de una refactorización ejecutada ni garantiza que las relaciones recuperadas cubran todos los efectos de un cambio.

La separación entre consultar, proponer y comprobar conserva una evidencia clara de la decisión. La herramienta facilita el acceso al contexto, mientras la aceptación del resultado depende de la revisión del proyecto. Antes de integrar la propuesta, conviene confirmar que el análisis ha trabajado sobre el proyecto previsto y que los cambios corresponden al símbolo examinado. Esa comprobación relaciona la consulta semántica con una decisión de edición concreta, sin atribuir a la herramienta una validación del comportamiento que todavía no se ha realizado.

La referencia se revisó el 2026-10-26. Serena distingue la aplicación, bajo GPL-3.0-or-later, de SolidLSP, bajo MIT. La distribución conjunta queda sujeta a GPL según su documentación. Esta reseña recoge la preparación y los backends publicados sin atribuir al proyecto una licencia única para todas sus piezas. No se instaló Serena ni se ejecutaron sus operaciones durante esta revisión.