Desarrollo agéntico en Business Central: cómo usar instrucciones para guiar a tu agente de código

Cuando hablamos de agentes en Business Central, casi siempre pensamos en funcionalidades para el usuario final: un copiloto que ayuda a facturar, a analizar ventas o a resolver dudas dentro de la aplicación. Pero hay otro uso, menos visible y igual de potente, que consiste en aplicar agentes al propio proceso de desarrollo: utilizarlos para escribir código AL, crear tablas, páginas y el resto de objetos que forman una extensión.

Este artículo abre una serie dedicada al desarrollo agéntico en Business Central, y empieza por la pieza más básica de todas: las instrucciones.

Qué es el desarrollo agéntico

El desarrollo agéntico consiste en trabajar con un agente de código, en este caso, GitHub Copilot en modo agente dentro de Visual Studio Code, que no se limita a autocompletar líneas, sino que ejecuta tareas completas: crea tablas, páginas, revisa el app.json para entender el contexto del proyecto y proponer cambios que el desarrollador puede aceptar o descartar.

El objetivo no es sustituir al equipo de desarrollo, sino aumentar su productividad, delegando tareas repetitivas o estructurales para que el equipo pueda centrarse en el diseño y la lógica de negocio.

El problema de partir de cero

Al pedirle a un agente algo tan simple como "créame una tabla y una página que se llame Logging con los siguientes campos: ID, Description, Hora, Fecha", el resultado funciona, pero refleja exactamente lo que se ha escrito en el prompt: los nombres de campo aparecen tal cual, sin convenciones de nomenclatura, sin prefijo de empresa y, en ocasiones, sin criterio consistente sobre el idioma.

Es un buen punto de partida, pero no es el resultado que la mayoría de los equipos necesita para mantener un código homogéneo entre desarrolladores.

Instrucciones: la primera pieza del desarrollo agéntico

Para resolver esto, GitHub Copilot permite definir instrucciones persistentes que el agente lee automáticamente cada vez que trabaja sobre un tipo de fichero concreto. En un proyecto de AL, esto se organiza así:

• Se crea una carpeta .github en la raíz del proyecto.
• Dentro de ella se añade un fichero de instrucciones.
• El fichero incluye una cabecera applyTo que indica a qué tipo de ficheros se aplican esas reglas (por ejemplo, todos los ficheros con extensión .al).

A partir de ahí, cualquier instrucción que se defina se convierte en una regla que el agente sigue de forma automática, sin que el desarrollador tenga que repetirla en cada prompt.

Qué tipo de reglas conviene definir

En el caso de AL, algunas de las instrucciones más útiles son:

• Convención de nombres: por ejemplo, PascalCase para objetos y campos.
• Prefijo de la extensión: la mayoría de empresas trabajan con un prefijo identificativo que debe aparecer en el nombre de cada objeto.
• Patrón de nomenclatura: nombre del objeto + tipo de objeto + prefijo, con un límite de caracteres (por ejemplo, 30) para evitar nombres excesivamente largos.
• Prohibición de abreviaturas salvo que sean ampliamente reconocibles, para mantener el código legible.
• Idioma de variables y campos: si el equipo trabaja en inglés, conviene indicarlo explícitamente. El agente puede recordar una preferencia de una sesión anterior, pero eso no garantiza que la aplique de forma consistente en todos los casos; solo una instrucción explícita lo convierte en una regla obligatoria.

Al repetir exactamente el mismo prompt inicial (crear la tabla y página Login) una vez definidas estas instrucciones, el resultado cambia por completo: el agente respeta el prefijo, aplica PascalCase, sigue el patrón de nomenclatura definido y utiliza los campos en inglés, porque ahora forma parte de una regla y no de una preferencia puntual.

Por qué esto importa

Las instrucciones no son una funcionalidad decorativa: son la forma de asegurar que un agente de código se comporta según los estándares del equipo, en lugar de improvisar en cada interacción. Cuanto más clara sea la instrucción, menos margen hay para que el agente tome decisiones por su cuenta —como elegir el idioma de un campo sin que se le haya pedido explícitamente.

Este es solo el primer bloque del desarrollo agéntico aplicado a Business Central. En próximas entregas se irán añadiendo más piezas: otras herramientas, configuraciones adicionales y ejemplos que permiten llevar este flujo de trabajo más allá de lo básico.

Si tu equipo ya está probando agentes de código en proyectos de AL, empezar por definir un buen fichero de instrucciones es el paso con mayor retorno para el menor esfuerzo.