La próxima generación de plataformas de desarrollo empresarial basadas en IA

Las plataformas actuales de desarrollo requieren que aprendamos su lenguaje: sintaxis, configuraciones, patrones específicos. Pero… ¿qué pasaría si fuera la plataforma la que aprendiera a hablar el idioma empresarial?

La próxima generación de plataformas de IA para desarrollo no solo generará código; también comprenderá, interpretará y traducirá el conocimiento de negocio en aplicaciones completas y funcionales.

---

Problema actual

Cuando nos llega un nuevo requerimiento que dice:

“ La cuarta medida determina un régimen simplificado de importación en el que se beneficiará una exoneración total de tributos a la importación para determinados productos. Se crea un régimen especial de importación en el que los comercios minoristas, de ramos generales, ubicados a menos de 60 km de la frontera, podrán importar, libres de todo tributo, productos que componen la canasta básica ” (*)

Esto se traduce en semanas de trabajo que incluyen:

• Análisis legal y regulatorio
• Interpretación compleja de marcos normativos
• Modelado de datos geográficos y comerciales
• Clasificación de importadores
• Desarrollo de múltiples componentes de validación e ingreso de datos
• Nuevos flujos de trabajo
• Modificaciones e integración con sistemas aduaneros y tributarios
• Pruebas exhaustivas

Está claro que las condiciones están dadas para que podamos ser más productivos al traducir este tipo de requerimientos de alto nivel en aplicaciones ejecutables.

Solo necesitamos una nueva generación de herramientas que gestionen el ciclo de vida de las aplicaciones empresariales basadas en datos.

---

¿Qué características deberán tener estas herramientas?

Mi sueño es poder gestionar todo el ciclo de vida de una aplicación, con un conjunto de herramientas que trabajen en conjunto e interactúen entre ellas para minimizar el trabajo humano y los errores.

1. Basado en modelos

Todo el conocimiento de la aplicación debe almacenarse en un repositorio centralizado, que funcione como modelo único.

Este repositorio debería incluir, como mínimo, información sobre:

• Arquitectura
• Plataforma y empaquetado
• Requerimientos
• Operaciones y manejo de incidentes
• Seguridad
• Analítica
• Instalación
• Observabilidad y monitoreo
• Criterios de calidad verificables (pruebas, validaciones, reglas )

El repositorio debe:

• Manejar versionado y mantener un estado consistente.
• Traducir los requerimientos en lenguaje de negocio antes de integrarlos.
• Resolver conflictos antes de aceptarlos.
• Ser la fuente de la verdad para todos los involucrados en el desarrollo.

2. Diferentes niveles de abstracción

Las herramientas deberán permitir trabajar en distintos niveles:

• Aplicación completa
• Módulo
• Programa/Pantalla

Ejemplo:
✔ Para ciertos componentes bastará con definir: “Altas, bajas y modificaciones de ciudades”,  y de ahi se puden deducir los atributos de la entidad Ciudades, que va a tener un API REST para interacturar con las ciudades deduciendo esto de reglas mas generales. 
✔ Pero en productos de importación se necesitará más detalle: indicar si están en la canasta básica, si cuentan con exoneraciones, e incluso definir el diseño de las pantallas.

3. Lenguajes específicos

El lenguaje natural es impreciso y ambiguo. Por eso, se necesitarán traductores hacia lenguajes estructurados, que puedan ser interpretados de forma determinística.

Se requerirán lenguajes para:

• Arquitectura de la aplicación
• Almacenamiento de datos
• Empaquetado e instalación
• Analítica de datos (qué medir, qué mostrar, cómo visualizarlo)
• ML/AI (qué partes del sistema deben aprender y adaptarse)
• Referencias y relaciones entre entidades/módulos/requerimientos (grafos con tipos y pesos)

En estos lenguajes, por ejemplo, se podrá describir qué mostrar y qué acciones realizar en una pantalla, sin preocuparse por la estética.

3. Diferentes contenidos. 

Los requerimientos podrán venir de diferentes formas y formatos. Podrán ser transcripciones de  reuniones o entrevistas, videos, audios, pruebas, reportes de errores, imagenes, dibujos, diagramas. Historias de usuario, etc. Todo deberá ser traducido a requerimientos y en lo posible incorporado al repositorio. Estos artefactos deberán ser almacenados como la fuente de requerimientos y deberá poder rastrearse un requerimiento como y porque fue introducido al sistema. 

¿Cómo sería el desarrollo con estas herramientas?

1. El usuario ingresa un nuevo requerimiento.
2. El sistema lo traduce y elimina ambigüedades.
3. Se clasifican los requerimientos concretos y se presentan al usuario.
4. Si falta información, el sistema propone o solicita aclaraciones.
5. Se mide el impacto en el repositorio central.
6. El usuario aprueba o rechaza la integración.

Además, existiría un repositorio de componentes prearmados, reutilizables en diferentes secciones de la aplicación.

Entre los componentes se incluirían:

• Patrones de diseño (Work With, MVC, etc.)
• Design System (estilo y diseño centralizados)
• Herramientas de terceros (vía APIs)
• Controles de usuario
• Otros proyectos ya desarrollados con IA

---

Conclusión

Aún falta camino por recorrer, pero la industria ya está invirtiendo grandes recursos en transformar la forma en que desarrollamos software.

Estamos en el mejor momento para imaginar cómo queremos que sea la próxima generación de herramientas de desarrollo.

Quienes lo logren tendrán un futuro brillante. Y en un futuro más lejano, quizás tengamos intérpretes directos del modelo de la aplicación, haciendo innecesaria la etapa de generación de código.

---

(*) Cualquier parecido con la realidad es mera coincidencia.