Una extensión AL escrita por un agente: qué debe detectar la revisión

Un agente de IA puede escribir AL, compilarlo contra sus símbolos y publicarlo en un entorno sandbox. El código normalmente funciona. Justo por eso importa la revisión.

Esta página es la lista de comprobación que un consultor debería recorrer antes de que el AL escrito por un agente llegue a un entorno de producción, ordenada por lo que más cuesta cuando está mal.

¿Qué puede hacer hoy un agente en AL?

Más de lo que espera la mayoría de los equipos. El plan de la primera oleada de lanzamientos de 2026 recoge seis puntos para este trabajo:

• Herramientas de agentes de IA para el desarrollo en AL
• Un servidor MCP de AL para diagnóstico
• Conectarse y depurar sesiones de agentes de Business Central
• Pruebas de AL que se ejecutan desde Visual Studio Code
• Descarga de símbolos desde un feed de NuGet
• BC-Bench, para evaluar agentes de programación en AL

Un ciclo práctico tiene este aspecto. Una persona describe el cambio. El agente lee los símbolos, escribe los objetos, compila, publica en un sandbox y ejecuta las pruebas. La persona lo prueba, lo corrige, y el agente da otra vuelta.

Lo que el ciclo no incluye es el criterio sobre su entorno de producción. Eso es trabajo del revisor, y no se encoge porque el código se haya vuelto más fácil de producir.

¿Por qué la revisión no es opcional?

Porque ha cambiado el modo de fallo.

Un programador júnior escribe código que no compila y código que está evidentemente mal. Los dos son baratos de detectar. Un agente escribe código que compila, pasa sus propias pruebas y hace lo que no debe de una manera que se lee como deliberada.

El segundo tipo de error es más caro, y es invisible para las comprobaciones que detectan el primero.

La lista de comprobación de la revisión

Recorra esta lista. El orden es por coste de equivocarse, no por facilidad de comprobación.

1. Todo lo que toque datos registrados

Mire primero cada escritura en una tabla de movimientos registrados, cada suscriptor de un codeunit de registro y cualquier uso de COMMIT dentro de un flujo de registro. Un agente que «mejora» el registro ha producido la clase de defecto más cara de Business Central, porque el daño está en la contabilidad y la contabilidad es el registro.

Trate un cambio en el registro como un cambio que necesita un motivo escrito, una prueba y un segundo lector.

2. Permisos

Los objetos nuevos necesitan conjuntos de permisos. Un agente escribe con frecuencia los objetos y olvida los permisos, o concede más de lo que la función necesita.

Compruebe que cada tabla y cada página nuevas están en un conjunto de permisos, que el conjunto se ajusta al trabajo, y que no se ha añadido nada a un conjunto comodín por comodidad.

3. Actualización y migración de datos

Esta es la pieza que falta con más fiabilidad. Un campo nuevo con un valor predeterminado, un tipo de campo cambiado o datos que hay que mover necesitan código de actualización. Sin él, la extensión se instala limpiamente en un sandbox sin datos y falla en un entorno de producción con cinco años de datos.

Pregunte directamente: ¿qué pasa con las filas existentes? Si la respuesta no está en el código, el trabajo no está terminado.

4. Rangos de objetos, nomenclatura y espacios de nombres

Compruebe que los identificadores de objeto están dentro del rango que le pertenece, que los nombres siguen su convención con el prefijo correcto, y que los espacios de nombres están puestos. Son baratos de corregir ahora y caros de corregir después de publicar la extensión.

5. Rendimiento

Busque el bucle que debería haber sido una consulta, los SetLoadFields que faltan, un FlowField usado dentro de un bucle y cualquier filtro sobre un campo sin una clave que lo respalde.

Un agente optimiza para obtener la salida correcta sobre los datos que puede ver. Sus datos de producción son más grandes que eso, y el coste solo aparece a escala.

6. Gestión de errores

Compruebe que los errores no se tragan. Una TryFunction cuyo fallo se ignora convierte un fallo ruidoso en un resultado silenciosamente equivocado, que es el peor de los dos.

Compruebe que los mensajes de error nombran el registro y el motivo, porque estos mensajes aparecen en la telemetría como RT0030 y un mensaje vago le hace perder una hora a la siguiente persona.

7. Traducción y textos

Confirme que todos los textos son traducibles y que ninguna cadena de cara al usuario está escrita en duro en un solo idioma. Para un cliente danés o alemán esto no es un acabado. Es la diferencia entre una página usable y un batiburrillo bilingüe.

8. Pruebas

Pregunte qué comprueban realmente las pruebas. Las pruebas escritas por un agente tienden a comprobar que el código se ejecutó, no que el resultado es correcto.

Una prueba que contrasta una cifra calculada con un valor conocido vale por diez que comprueban que no hubo error.

Qué se le da peor a los agentes

De nuestro propio trabajo de revisión, aproximadamente por frecuencia:

1. Falta el código de actualización para campos nuevos o modificados.
2. Conjuntos de permisos que nunca se crearon.
3. Un suscriptor que se ejecuta en todos los registros cuando debería ejecutarse en un solo tipo de documento.
4. Filtros que no pueden buscar, sobre tablas donde eso importa.
5. Textos que no son traducibles.
6. Pruebas que no comprueban nada útil.
7. Uso resuelto de un patrón de una versión antigua de Business Central.

El punto 7 merece vigilancia. Los agentes aprenden de código publicado, y mucho AL publicado es antiguo. Un patrón que era correcto en una versión anterior puede estar obsoleto ahora, y sigue compilando.

Cómo abaratar la revisión

La revisión es el cuello de botella, así que diséñelo pensando en ella.

Mantenga las sesiones pequeñas. Un cambio por sesión. Una sesión que toca seis áreas no se puede revisar bien y se aprobará igualmente.

Exija un sandbox. Nada llega directamente a producción. El agente publica en un sandbox, una persona prueba el cambio, y solo entonces revisa el código un consultor.

Ponga un presupuesto a la sesión. Un tope fijado antes de empezar impide que un agente se pase una hora con el enfoque equivocado.

Haga del diff la unidad de revisión. Revise el cambio, no el archivo. Un revisor que tenga que leer el objeto entero lo leerá por encima.

Tenga las reglas en un solo sitio. Un conjunto escrito de reglas de calidad que usen tanto el agente como el revisor convierte la revisión de opinión en comprobación. El agente lee las mismas reglas antes de escribir.

El sentido del ciclo

El valor no es que el código salga gratis. El valor es que la persona que entiende el proceso de negocio puede expresar el cambio por sí misma, y el consultor dedica su tiempo al criterio en lugar de a teclear.

Ese intercambio solo funciona si la revisión es real. Una extensión escrita por un agente que nadie ha leído es un cambio en producción que nadie ha leído, y las herramientas que lo hicieron fácil no son una defensa.