Hace más de tres décadas que GeneXus hace una apuesta que hoy suena extrañamente actual: no se escribe el sistema, se modela; y desde ese modelo se genera el código de forma determinística. Cuando el negocio cambia, cambia el modelo, y el sistema se regenera.

La irrupción de los LLMs pone esa apuesta bajo una luz nueva. El desarrollo asistido por Inteligencia Artificial avanza rapidísimo, pero lo hace tropezando con un problema viejo que GeneXus lleva años resolviendo: ¿cómo confiar en lo que se construyó, entenderlo y responder por ello?

Este artículo describe cómo estamos repensando GeneXus para esta era -qué conservamos de su núcleo, qué abrimos y qué incorporamos de los LLMs- para desarrollar y mantener sistemas críticos con IA de forma segura y auditable.

La idea en una frase: en el nuevo GeneXus
, la conversación no produce directamente el código. Produce un modelo formal y versionado; el código es una de sus proyecciones.

Dos enfoques frecuentes en el desarrollo con LLMs

El primero es dejarse llevar:
pedirle al modelo lo que queremos y confiar en que lo resuelva bien
, apostando a que cada nueva versión sea un poco mejor que la anterior. Es rápido y llega lejos, hasta que hay que entender, mantener o responder por lo que se construyó.

El segundo es ponerle andamiaje:
una especificación que declara la intención, acompañada de hooks y controles que vigilan al modelo mientras trabaja. Es un enfoque disciplinado y serio. Pero conserva un límite de fondo: la especificación es prosa.

Se puede revisar, pero es difícil comprobar de forma determinística que esté completa, que no se contradiga y que cada parte de la implementación responda a una intención explícita. La correspondencia entre lo pedido y lo construido termina descansando en revisar el código, los tests y el comportamiento final, justamente lo que cada vez cuesta más examinar en profundidad.

Los dos enfoques son legítimos y resuelven cosas reales. La diferencia que proponemos no es de velocidad, sino de qué tipo de garantía queda al final del proceso.

La tercera forma: modelar la intención

En lugar de dejar la intención escrita solamente en prosa, GeneXus convierte la conversación con el usuario en un modelo formal, guiado por una ontología que sabe qué preocupaciones debe resolver un sistema y qué preguntas deben responderse para considerarlo completo.

Conviene ser preciso sobre qué es esa ontología, porque ahí está la clave – y también el límite del enfoque.

No es un oráculo neutral: es conocimiento opinado, la codificación de lo que GeneXus aprendió en treinta años construyendo sistemas de negocio. Esa opinión es su valor: no se reinventa en cada proyecto qué hace falta para que un sistema esté completo. Y, como todo lo demás en GeneXus, es inspeccionable y versionable.

Sobre ese modelo, la verificación deja de ser solamente una lectura. Y acá vale decir exactamente qué garantiza y qué no.

Lo que se comprueba de forma determinística es que el modelo cumpla las reglas de la ontología: que se hayan atendido todas las preocupaciones obligatorias, que cada referencia apunte a algo que existe, que las restricciones se cumplan y que el modelo no se contradiga.

Lo que no se demuestra por máquina es que el modelo diga lo que el negocio realmente necesita. Ese salto – de la intención real a los hechos tipados- lo sigue haciendo una conversación.

La diferencia con la prosa no es que hayamos eliminado esa conversación, sino que la subimos a un terreno verificable. Antes, la interpretación quedaba dispersa en un documento que alguien leía y consideraba suficientemente bueno. Ahora queda tipada, registrada y contrastable contra una ontología explícita.

El riesgo no desaparece: se concentra, se hace visible y se vuelve auditable. El proceso no puede declarar completo, respecto de la ontología, aquello que todavía no lo está.

Un ejemplo, de punta a punta

Tomemos algo tan común como los permisos.

El agente no pregunta por modelos de autorización, políticas ni roles. Pregunta si cualquiera puede entrar al sistema, si todas las personas ven las mismas opciones y quién puede hacer cada cosa.

Cada respuesta se guarda como un hecho tipado en el modelo.

Y acá se ve la diferencia: si el sistema declara, por ejemplo, una operación para borrar una factura pero nunca se definió quién puede ejecutarla, la verificación lo detecta. Esa preocupación quedó abierta y el sistema no puede avanzar como si estuviera resuelta.

No hace falta confiar en que un revisor lo descubra leyendo código: existe una operación declarada y falta el conocimiento necesario para gobernarla. Ese vacío es visible para una máquina.

Cuando el modelo de permisos está completo y verificado, las estructuras, las validaciones y los controles de acceso repetibles pueden generarse de forma determinística.

Y si hubiera una regla de permiso única que ningún generador cubre todavía, por ejemplo, “solo el gerente regional que aprobó la operación puede reabrirla”, esa parte se trata de otra forma, como veremos más adelante, pero también queda registrada y debe presentar evidencia.

El mismo principio se vuelve todavía más importante cuando el negocio cambia.

Supongamos que una factura que antes podía cerrarse directamente ahora requiere una aprobación previa. El cambio no empieza buscando qué archivos hay que tocar. Empieza modificando el modelo: aparece una nueva regla, una nueva operación o estado y las relaciones necesarias para representarla.

A partir de ahí, el sistema puede calcular qué partes dependen de ese conocimiento y qué proyecciones quedaron alcanzadas por el cambio. Las que correspondan se regeneran; las que no dependen de él permanecen intactas.

Así, la pregunta deja de ser “¿nos acordamos de modificar todos los lugares afectados?” y pasa a ser “¿qué dice el grafo que depende de este cambio?”.

Ese hilo – conversación en lenguaje de negocio, hechos tipados, verificación que expone lo que falta, análisis explícito del impacto, generación de lo repetible y un tratamiento distinto para lo único- es el que recorren los nueve principios.

Cómo se captura la intención

1. Conversación en lenguaje de negocio, no en jerga técnica

Todo ocurre dentro de un
ambiente de desarrollo agéntico, un ADE
, con un chat desde el cual el usuario conversa con el agente sobre el sistema que quiere construir.

El usuario no necesita conocer los términos de la ontología: habla del negocio y el agente traduce.

Así incorporamos una de las grandes ventajas de los LLMs – una conversación fluida en lenguaje natural –  sin trasladarle al usuario el vocabulario técnico del modelo.

2. Nivel de exigencia declarado al inicio; la ontología adapta lo obligatorio

Al comenzar se declara el nivel de exigencia del proyecto: una prueba de concepto, una herramienta interna o un sistema de misión crítica.

Según ese perfil, la ontología determina qué preocupaciones deben cubrirse obligatoriamente y cuáles pueden resolverse con
decisiones ya establecidas por GeneXus
.

A partir de ahí, el agente explora lo que falta. No improvisa preguntas en cada conversación, sino que trabaja sobre el conocimiento que GeneXus codificó acerca de lo que hace falta para construir sistemas de calidad.

Esto es especialmente importante en los Sistemas de Misión Crítica. El usuario no tiene por qué conocer todas las dimensiones técnicas que hacen falta para construir uno: seguridad, acceso, integración, accesibilidad, operabilidad, internacionalización, gobernanza y otras preocupaciones del sistema.

GeneXus toma una posición sobre eso. Su ontología codifica qué debe ser considerado para cada tipo de sistema y obliga a que esas preocupaciones sean atendidas o explícitamente declaradas como no aplicables. El agente lleva esas decisiones a una conversación en lenguaje de negocio.

El usuario explica qué necesita. GeneXus aporta el conocimiento sobre qué hace falta considerar para construirlo con el nivel de exigencia declarado.

Cómo se verifica

3. Modelo formal con hechos tipados, no prosa interpretable

En el desarrollo guiado por especificaciones, el agente sigue instrucciones escritas en prosa.

Acá, las respuestas quedan representadas como hechos tipados dentro de un modelo formal.

Por eso lo que el sistema debe cumplir puede comprobarse de manera determinística. No es una especificación que alguien lee y considera suficientemente buena: es un modelo que una máquina puede aceptar o rechazar.

4. El modelo vive en Git, no en una base propietaria

El modelo son archivos de texto en un repositorio Git.

Se puede hacer diff. Se puede revisar en un pull request. Se puede trabajar con branches. Git blame puede decir quién declaró cada hecho, cuándo y en qué cambio apareció.

Un hook de pre-commit valida el modelo contra la ontología y rechaza el commit si no conforma.

La fuente de verdad no está encerrada dentro del ADE ni de una base propietaria. Está en archivos abiertos, versionables y procesables con las mismas herramientas con las que ya trabaja cualquier equipo de desarrollo.

Si mañana el usuario quiere construir otra herramienta sobre ese conocimiento, el modelo sigue estando ahí. Si quiere auditarlo, también.

5. Nada ocurre en una caja negra

El ADE ofrece vistas para comprender el modelo, saber qué falta para que el sistema esté listo, explorar sus relaciones y anticipar qué artefactos van a producirse.

Y el modelo no devuelve simplemente “válido” o “inválido”.

Puede mostrar qué preocupación sigue abierta, qué fue resuelto por una decisión del perfil, qué se declaró como no aplicable y qué necesita todavía una respuesta humana.

En cada momento se puede ver el estado real del sistema y las razones por las que todavía no puede avanzar.

El gate bloquea; el ADE explica por qué.

Cómo se vuelve código

Antes de hablar de generación conviene definir una expresión que usaremos de acá en adelante.

Llamamos régimen compilado
a los casos en los que el conocimiento necesario está representado en el modelo y existe un generador capaz de transformarlo en un artefacto sin volver a pedirle a un LLM que interprete la intención.

En ese régimen, generar deja de ser una nueva decisión. Es una compilación de conocimiento ya capturado.

6. Generación determinística para lo repetible

Cuando el modelo está completo y verificado, comienza la generación.

Lo que se repite – estructuras de datos, operaciones, políticas, contratos y patrones recurrentes de los sistemas de negocio- puede producirse mediante generadores determinísticos.

Cuando existe un generador para ese conocimiento dentro del régimen compilado, dado el mismo modelo y el mismo generador se produce siempre la misma salida. No hay nada que reinterpretar ni adivinar: el generador transforma en código conocimiento que ya fue capturado.

7. El código es una proyección del modelo, no un artefacto suelto

Como vimos en el ejemplo de la factura, cuando cambia el negocio cambia el modelo, y las dependencias del grafo permiten determinar qué proyecciones quedaron alcanzadas y deben regenerarse.

En el régimen compilado, el código no es el lugar donde se conserva la intención: es una consecuencia del modelo.

La disciplina para lo único

No todo es repetible.

Para lo verdaderamente nuevo – que muchas veces es la lógica más crítica y diferenciadora de un negocio – no alcanza con un generador.

La respuesta no es pretender que sí, sino ofrecer una garantía distinta y explícita.

8. Objetos genéricos con procedencia y evidencia

Cuando algo ocurrirá una sola vez y todavía no existe un generador que lo cubra, se representa como un objeto genérico.

Ahí el LLM puede construirlo, pero no desde una conversación que después se pierde.

La entrada que utilizó, la especificación y el material de contexto quedan guardados y versionados. El resultado debe declarar cómo fue producido y presentar evidencia de que funciona.

No se le exige la misma garantía que a un artefacto compilado. Se le exige otra, de forma explícita: procedencia y evidencia
.

Es deliberadamente el punto donde el enfoque convive con la incertidumbre en vez de negarla y la administra dejándola trazable.

9. Regla de la segunda instancia: lo repetible se convierte en generador

Existe una regla fundamental: si aparece una segunda instancia del mismo tipo de entrada, el sistema ya no permite seguir tratándola como un caso único.

Y esto no es una recomendación metodológica que un desarrollador tenga que recordar. La cardinalidad forma parte del modelo y la validación rechaza que una segunda instancia siga declarada como un caso único.

En ese momento, ese conocimiento debe convertirse en un generador.

El LLM puede ayudar a escribirlo, pero desde entonces deja de volver a inventar cada resultado.

La primera aparición puede necesitar autoría y evidencia. La segunda revela que existe un patrón. El patrón se formaliza y pasa al territorio compilado.

Así, el territorio de lo incierto no crece indefinidamente con el sistema: se estrecha a medida que el conocimiento se endurece
.

El producto que estamos diseñando

Estamos diseñando un nuevo GeneXus
: un agente con el que hablás de tu negocio y que transforma esa conversación en un modelo formal y verificable.

Vos no necesitás saber qué hace falta técnicamente para construir un Sistema de Misión Crítica. GeneXus opina sobre eso:
su ontología incorpora ese conocimiento y se asegura de que las preocupaciones importantes no queden silenciosamente olvidadas.

La apuesta no es solo construir más rápido. Es poder confiar en lo que se construye
: saber que lo necesario fue considerado, que lo que falta es visible y que lo que ya sabemos resolver se produce de forma repetible.

Esa confianza se sostiene sobre una sola línea de conocimiento, verificable de punta a punta, donde cada eslabón dice qué garantiza y cuál es su límite.

No estamos diseñando un agente que escriba más código.

Estamos diseñando un GeneXus que convierte conversaciones en conocimiento verificable, y conocimiento verificable en software en el que podamos confiar.

También te puede interesar leer:

GeneXus y la Arquitectura Neuro-Simbólica

El problema del desarrollo basado en prompts

GeneXus for Agents: qué es, cómo funciona y cómo empezar