La inteligencia artificial puede acelerar tareas de programación relacionadas con un ERP, como generar pruebas, explicar código heredado o proponer una transformación de datos. No conoce automáticamente las reglas de negocio de la empresa ni puede garantizar que una modificación sea correcta. Para que resulte útil, hay que darle contexto acotado, revisar cada cambio y comprobarlo con pruebas que reflejen el funcionamiento real del sistema.
La decisión práctica no es si la IA sustituye al equipo de desarrollo, sino qué parte del trabajo se le delega y qué controles impiden que una sugerencia incorrecta afecte a datos, permisos o procesos. Esto importa especialmente en un ERP, donde una función pequeña puede influir en facturación, inventario, contabilidad o pedidos.
Qué tareas de desarrollo puede acelerar
Un asistente de programación puede proponer fragmentos de código, completar funciones, generar documentación y ayudar a interpretar errores. En un proyecto de ERP, estos usos son más fiables cuando la tarea está delimitada y el equipo puede describir qué debe entrar, qué debe salir y qué restricciones no se pueden incumplir.
- Crear pruebas unitarias: a partir de una función y sus reglas explícitas, puede proponer casos normales y casos límite para que el desarrollador los revise.
- Explicar código existente: puede resumir una rutina o señalar dependencias que después se verifican en el repositorio y en la documentación del proyecto.
- Preparar consultas o transformaciones: puede sugerir una consulta para un informe o una conversión de datos, siempre que se validen el esquema, los tipos y el resultado.
- Reducir trabajo repetitivo: puede ayudar a redactar validaciones, estructuras de datos o documentación técnica siguiendo convenciones proporcionadas por el equipo.
Por ejemplo, en un escenario hipotético, una empresa quiere impedir que se confirme un pedido si una línea supera el crédito disponible del cliente. La IA podría sugerir una función de validación o casos de prueba. No debería decidir por sí sola qué saldo cuenta, cómo se tratan los pedidos pendientes ni qué usuarios pueden autorizar una excepción: esas reglas deben venir del diseño funcional aprobado.
El contexto del ERP determina la calidad de la sugerencia
Una petición genérica como «añade una validación de crédito» deja demasiadas decisiones abiertas. El sistema puede tener reglas propias sobre límites, divisas, pedidos parcialmente servidos o autorizaciones. Sin esa información, una respuesta plausible puede no corresponder al comportamiento esperado.
Definir entradas, resultados y excepciones
Una especificación útil indica qué datos recibe la función, qué condición debe comprobar, qué respuesta produce y qué hacer ante una excepción. También aclara si el proceso afecta a una pantalla, a una interfaz de programación de aplicaciones (API), a una tarea en segundo plano o a varios canales. La misma regla aplicada solo en la interfaz podría saltarse si otro sistema registra pedidos mediante una API.
En el ejemplo del crédito, el equipo podría definir que se compare el importe del pedido con el crédito disponible calculado por un servicio existente, y que una excepción requiera aprobación de un perfil determinado. La IA puede ayudar a trasladar esa especificación a código, pero el equipo debe comprobar que la función usa la fuente de datos correcta y que la autorización se aplica en el servidor.
Compartir convenciones sin exponer información innecesaria
El contexto técnico puede incluir nombres de módulos, tipos de datos, patrones de acceso al repositorio y ejemplos de pruebas. No hace falta proporcionar una copia completa de la base de datos ni información identificable de clientes para pedir ayuda sobre una función. Antes de usar una herramienta, la organización debe revisar qué contenido se envía y las condiciones de tratamiento aplicables a ese entorno.
También es útil separar las instrucciones del proyecto de la petición puntual: por ejemplo, indicar que las operaciones de escritura deben pasar por una capa de servicio, que los errores se registran con una estructura concreta y que no se deben modificar tablas directamente desde la interfaz. Así se reduce la ambigüedad y se facilita detectar una propuesta que se sale de la arquitectura.
Un flujo seguro: propuesta, revisión y pruebas
- Acotar el cambio. Describir una tarea pequeña, su objetivo y las condiciones que no deben variar. Evitar pedir una reescritura amplia sin criterios de aceptación.
- Solicitar una propuesta revisable. Pedir cambios limitados a los archivos o componentes pertinentes, junto con una explicación de las decisiones tomadas y de las suposiciones que haya hecho.
- Inspeccionar el código. Comparar la propuesta con las convenciones del proyecto y revisar permisos, validaciones, manejo de errores, consultas y efectos sobre otros módulos.
- Ejecutar las comprobaciones del equipo. Las pruebas unitarias verifican unidades pequeñas; las pruebas de integración comprueban interacciones entre componentes. Las pruebas funcionales contrastan el proceso con criterios de aceptación concretos.
- Probar con datos controlados. Revisar escenarios de éxito, rechazo, duplicados y valores límite en un entorno separado de producción, con datos preparados para la prueba.
- Desplegar con reversión prevista. Registrar el cambio, limitar el alcance inicial cuando sea posible y disponer de un procedimiento para volver a la versión anterior si aparecen errores.
La revisión no consiste únicamente en buscar errores de sintaxis. En un ERP hay que comprobar si una operación se ejecuta más de una vez, si puede dejar datos parcialmente modificados y si dos procesos simultáneos producen resultados incoherentes. Una sugerencia que supera una prueba aislada todavía puede fallar al interactuar con inventario, permisos o procesos contables.
Dónde encaja mejor y dónde hace falta más cautela
La ayuda de IA suele ser más manejable en tareas de alcance reducido y resultado verificable: documentación, generación de casos de prueba o cambios en una función con entradas y salidas definidas. En cambio, diseñar el modelo contable, modificar permisos generales o cambiar una regla que afecta a múltiples módulos exige decisiones de arquitectura y negocio que no se resuelven con una propuesta de código.
También hay una diferencia entre crear una extensión y modificar el núcleo del ERP. Si el producto permite ampliar funcionalidades mediante módulos o interfaces documentadas, trabajar en esa extensión puede reducir el acoplamiento con el código central. Si el cambio obliga a alterar componentes compartidos, habrá que valorar cómo se mantendrá la modificación al actualizar el sistema. La opción adecuada depende de la arquitectura concreta, no de que la IA haya generado el código.
Cuando el ERP intercambia información con comercio electrónico, logística u otras aplicaciones, las reglas deben verificarse en los límites entre sistemas. Una API puede recibir datos incompletos, duplicados o en un orden distinto al esperado. Por eso, las pruebas deben incluir respuestas de error, reintentos e identificadores que permitan reconocer una operación repetida. La IA puede ayudar a plantear esos casos, pero no sustituye la comprobación del contrato de integración.
Cómo valorar el resultado más allá del código generado
La rapidez para producir una primera versión no basta para decidir si el uso aporta valor. El equipo puede observar si disminuye el tiempo dedicado a tareas repetitivas sin aumentar el tiempo de revisión, si las pruebas cubren escenarios relevantes y si el cambio respeta los patrones del proyecto. Si cada sugerencia requiere reconstruir el contexto o corregir supuestos básicos, el problema puede estar en la petición, en la falta de documentación o en que la tarea no se presta a delegación.
Antes de incorporar la práctica a un desarrollo de mayor alcance, es razonable empezar con una tarea interna, reversible y sin datos reales sensibles. El equipo define el resultado esperado, compara la propuesta con el código que habría escrito siguiendo su proceso habitual y registra qué revisiones fueron necesarias. Ese ejercicio permite decidir qué tareas conviene repetir y qué controles deben ser obligatorios.
La IA funciona así como apoyo dentro de un proceso de ingeniería: acelera algunas operaciones, pero la responsabilidad de definir las reglas, proteger los datos y aceptar el cambio sigue en el equipo que mantiene el ERP. Cuanto más impacto tenga una modificación sobre operaciones o registros críticos, más importante es que sus requisitos, pruebas y vías de reversión estén definidos antes de generar código.
