Desarrollando desde la trinchera.

Usando IA para detectar problemas de performance en aplicaciones GeneXus

2026-04-06T08:59:00.003-03:00

En aplicaciones grandes desarrolladas con GeneXus, detectar problemas de performance puede ser una tarea compleja. Los logs generados con log4net contienen muchísima información valiosa, pero leerlos manualmente no escala.

En este post te comparto una metodología práctica para analizar estos logs utilizando NotebookLM, aprovechando su capacidad de entender documentos y responder preguntas sobre ellos.

Idea general

La propuesta es simple pero poderosa:

Convertir los logs de ejecución en documentos (PDF)
Subirlos como fuentes a NotebookLM
Hacer preguntas inteligentes sobre el contenido
Obtener insights de performance automáticamente

Esto transforma un análisis manual tedioso en un proceso asistido por IA.

Paso 1: Generar los logs correctamente

Asegurate de que tu aplicación GeneXus esté generando logs con suficiente detalle (al menos DEBUG).
Yo lo uso asi:

Un formato típico de log4net (es el default que trae GX) que funciona muy bien es:

%d{yyyy-MM-dd'T'HH:mm:ss.fffzzz} [%t] %-5p %c - %m%n

Esto te da:

Timestamp con precisión de milisegundos
Nivel de log (INFO, DEBUG, WARN, etc.)
Mensaje (incluyendo SQL, nombre de programa, parametros, etc.)

Paso 2: Convertir logs a PDF

NotebookLM trabaja mejor con documentos estructurados. Por eso:

Convertí tus archivos .log a .pdf . Yo uso un driver de impresion a PDF.
Si el archivo es muy grande, dividilo por partes (ej: por día o por thread)

Paso 3: Subir los logs a NotebookLM

Crear un nuevo notebook en NotebookLM
Subir los PDFs como “Sources”
Esperar a que indexe el contenido

Una vez hecho esto, NotebookLM ya puede “leer” y entender tus logs.

Paso 4: Hacer consultas inteligentes

Acá está la clave del valor.

Ejemplos de preguntas útiles:

🔹 Detección de cuellos de botella

“¿Cuáles son las operaciones más lentas?”
“¿Qué consultas SQL tienen mayor tiempo de ejecución?”

🔹 Análisis de patrones

“¿Hay procesos que se repiten muchas veces?”
“¿Qué sentencias sql aparecen más frecuentemente en los logs?”

🔹 Problemas potenciales

“¿Detectas esperas largas entre eventos?”
“¿Hay indicios de problemas de concurrencia o bloqueos?”

🔹 Recomendaciones

“Dame 3 recomendaciones para mejorar la performance basadas en estos logs”

NotebookLM no solo responde, sino que además cita partes específicas del log como evidencia.

Paso 5: Iterar como si fuera un analista experto

Una gran ventaja es que podés iterar:

Refinar preguntas
Focalizar en un proceso específico
Pedir explicaciones más técnicas

Esto simula tener un analista senior revisando logs contigo.

Casos de uso concretos en GeneXus

Esta metodología es especialmente útil para:

Identificar procedimientos batch lentos
Detectar SQL mal optimizado
Analizar conexiones lentas
Entender comportamiento en producción
Validar mejoras luego de optimizaciones

Bonus: combinándolo con herramientas propias

Si ya tenés herramientas como analizadores de logs (por ejemplo scripts o utilidades internas), podés combinarlas:

Preprocesar los logs (ej: detectar demoras grandes)
Luego usar NotebookLM para el análisis cualitativo

Lo mejor de ambos mundos: automatización + interpretación inteligente

Consideraciones importantes

Los logs pueden contener datos sensibles → anonimizar si es necesario
NotebookLM tiene límites de tamaño → dividir archivos grandes
No reemplaza el conocimiento técnico → lo potencia

Conclusión

El análisis de performance ya no tiene que ser un proceso manual, lento y propenso a errores.

Usando NotebookLM, podés transformar tus logs de GeneXus en una fuente de conocimiento accionable, acelerando el diagnóstico y mejorando la calidad de tus sistemas. No es el uso mas tradicional de NotebookLM pero es efectivo y ahorra mucho en en analisis de logs.

Si estás trabajando con aplicaciones grandes o sistemas críticos, esta metodología puede marcar una diferencia enorme en productividad.

* Esta metodologia es mejor cuando analiza proceso batch. Para esto, es recomendable utilizar procedures command line como wrapper que llame al procedure que se quiere optimizar y generar el log solo de ese objeto.

La Yapa

Comparto alguno de los prompts que uso para analizar los logs.

Prompt para iniciar el NotebookLM

Actúa como un experto en performance de aplicaciones GeneXus.

Analiza estos logs generados con log4net.
Los logs contienen timestamps, niveles de log y mensajes de ejecución.

Tu objetivo es:
1) Detectar cuellos de botella
2) Identificar operaciones lentas
3) Encontrar patrones repetitivos ineficientes
4) Detectar esperas entre eventos
5) Proponer mejoras concretas

Cuando respondas:
- Usa evidencia concreta del log
- Cita ejemplos
- Sé específico (no general)
- Prioriza impacto alto en performance

Pregunta Generica

Analiza estos logs de GeneXus como experto en performance.

1) Detecta las operaciones más lentas
2) Encuentra gaps de tiempo > 500 ms
3) Identifica patrones repetitivos
4) Analiza SQL problemático

Devuelve:
- Top 5 problemas
- Evidencia concreta
- Recomendaciones accionables

Sentencias SQL

Extrae todas las sentencias SQL detectadas en los logs.

Para cada una:
- Identifica frecuencia
- Evalúa posibles problemas (filtros, índices, joins, funciones)
- Detecta patrones de mala performance

Devuelve:
- Top queries más problemáticas
- Recomendaciones específicas

Prueba de CODA_CLI

2026-03-17T13:21:13.860-03:00

Para hacer la primer prueba de CODA CLI, decidi ir por algo sencillo y conocido.
Queria un utilitario command line, que permita analizar un log de la ejecucion de una aplicacion GeneXus y me ayudara a detectar problemas (fundamentalmente para mejorar performance).

Lo que hice fue partir de cero, dandole ejemplos del archivo que queria procesar y luego ir agregando una a una las diferentes funcionalidades que queria.

✅ Detección de demoras - Identifica operaciones lentas
✅ Análisis de errores - Separa y agrupa errores y warnings
✅ Totalización por programa - Cuenta ejecuciones de cada programa
✅ Totalización por SQL - Identifica queries más frecuentes
✅ Análisis de conexiones - Detecta conexiones lentas o no cerradas
✅ Duración de logs - Calcula el periodo cubierto por cada log

Hasta ahi, todo fue muy bien.

Cuando le pedi algo un poco mas sofisticado, como armar un arbol de llamadas, partiendo de log, cuando abria y cerraba conexiones a la base de datos, no logro resultados satisfactorios. Y demoro muchisimo. Lo deje igual en el proyecto, pero claramente es algo que se puede hacer, pero aun no tiene todo como para lograrlo o no supe explicarselo suficientemente bien.

✅ Árbol de llamadas - Visualiza jerarquía de ejecución de programas

De cualquier forma, con esto ya tengo como para empezar a trabajar.

El repositorio es publico y quedo en https://github.com/enriquealmeida/KBLogAnalyzer

y me llevo una mañana y unos 50 USD de tokens.

Tengo varias mejoras en la lista de cosas a hacer https://github.com/enriquealmeida/KBLogAnalyzer/blob/main/doc/TECHNICAL_GUIDE.md

Estoy usando claude 4.5 y quiero pasarme al 4.6 que dicen que es mucho mejor.
Tambien voy a hacer otros experimientos con Gemini CLI y Codex.

Como justo tengo que optimizar un proceso batch pesado, va a ser un buen momento para probarlo en ejecucion.

Personalizacion de Genexus Next.

2026-03-12T09:38:00.003-03:00

Estoy haciendo algunas pruebas con Genexus Next, para aclimatarme y utilizar agentes de IA en codigo GeneXus.
Aun siento que le faltan algunos minutos de coccion como para que este pronto para ser usado en proyectos de verdad, pero esta bueno ver un poco como se avanza en el tema.

Una de las cosas que tenia que hacer es lograr conectarme a la base de datos generada, con SQL Server Management Studio y poder ver los datos y hacer algunos ajustes.

Como estoy usando Docker en windows para esta prueba, la base de datos queda dentro del contenedor que distribuyen con Genexus Next. El usuario y la password del administrador, tambien quedan no visibles. Ya no tenemos mas el icono del ojo para ver el valor de la contraseña en el IDE.

Haciendo algo de ingenieria reversa en los docker-compose que levantan el IDE de GXNext, pude ver que dentro del archivo app.asar (es un formato de archivos indexados de atom que se puede abrir con VS Code y algunos otros ) se encuentra el config.json, donde estan las contraseñas y otros datos de configuracion de GeneXus Next.

No domino nada de docker, pero no entiendo como puedo levantar mi sql server local y escucha en el puerto 1433 y que GXNext levante el SQLServer en el mismo puerto, pero esa es la realidad. Entiendo que es otra red, pero no me doy cuenta como logran compartir el mismo puerto.

Para poder acceder a la base de datos, tuve que bajar mi SQLServer local (el que uso para GX18) y ahi si pude entrar con localhost,1433 al servidor sql server que usa GXNext.

Entonces los pasos fueron

Ubicar el app.asar en el dir de instalacion de GXNext y abrir el config.json para conocer la password
Bajar mi SQL Server local
Conectarme con MSSQL Management Studio a localhost,1433 usando el usuario y password del paso 1)

Lo documento aca, por si a alguien mas le sirve, porque no lo vi en ningun lado.

Modelo Ejecutable con Markdown: Specification by Example aplicada al dominio

2026-03-03T23:11:00.003-03:00

Una de las ideas más potentes de Specification by Example es simple: las reglas del negocio no deben quedar en documentos ambiguos, sino en ejemplos concretos que puedan ejecutarse. Si bien este libro se escribio antes que la IA generativa tuviera la visibilidad que tiene hoy, sigue teniendo mucha vigencia.

Si combinamos esto con un enfoque model-driven, podemos ir un paso más allá: definir el modelo de datos, las reglas y los escenarios de aceptación en un único Markdown ejecutable.

Ese archivo puede ser:

Legible por negocio
Procesable por una herramienta
Generador de código
Generador de tests automáticos
Documentación viva

Ejemplo: Sistema de Gestión de Pedidos

1️⃣ Modelo de Datos

model:
  entities:

    - name: Cliente
      attributes:
        - { name: ClienteId, type: int, key: true }
        - { name: Nombre, type: string, required: true }
        - { name: Email, type: string }

    - name: Pedido
      attributes:
        - { name: PedidoId, type: int, key: true }
        - { name: Fecha, type: date }
        - { name: Estado, type: enum[Borrador,Confirmado,Cancelado], default: Borrador }
        - { name: ClienteId, type: int, foreignKey: Cliente }
        - { name: Total, type: decimal, derived: true }

    - name: ItemPedido
      attributes:
        - { name: ItemId, type: int, key: true }
        - { name: PedidoId, type: int, foreignKey: Pedido }
        - { name: ProductoId, type: int }
        - { name: Cantidad, type: decimal, required: true }
        - { name: PrecioUnitario, type: decimal, required: true }
        - { name: Subtotal, type: decimal, derived: true }

2️⃣ Reglas de Negocio

rules:

  - name: SubtotalCalculation
    entity: ItemPedido
    expression: Subtotal = Cantidad * PrecioUnitario

  - name: PedidoTotalCalculation
    entity: Pedido
    expression: Total = sum(ItemPedido.Subtotal where PedidoId = Pedido.PedidoId)

  - name: PedidoDebeTenerItems
    entity: Pedido
    validation: count(ItemPedido where PedidoId = Pedido.PedidoId) > 0
    error: "El pedido debe tener al menos un ítem"

  - name: PedidoNoPuedeConfirmarseConTotalCero
    entity: Pedido
    when: Estado changes to Confirmado
    validation: Total > 0
    error: "El pedido no puede confirmarse con total cero"

3️⃣ Escenarios Ejecutables

Estos ejemplos funcionan como tests de aceptación. Si cambian las reglas y estos escenarios fallan, sabemos que rompimos el contrato del sistema.

Escenario: Pedido sin ítems


scenario: PedidoSinItems
given:
  Pedido:
    PedidoId: 1
    Estado: Borrador

when:
  action: validar

then:
  error: "El pedido debe tener al menos un ítem"

Escenario: Cálculo correcto del total


scenario: CalculoTotalCorrecto
given:
  Pedido:
    PedidoId: 10
    Estado: Borrador

  ItemPedido:
    - { PedidoId: 10, Cantidad: 2, PrecioUnitario: 50 }
    - { PedidoId: 10, Cantidad: 1, PrecioUnitario: 100 }

when:
  action: calcular_total

then:
  Pedido.Total: 200

Escenario: Confirmación inválida

scenario: ConfirmacionTotalCero
given:
  Pedido:
    PedidoId: 20
    Estado: Borrador

  ItemPedido:
    - { PedidoId: 20, Cantidad: 1, PrecioUnitario: 0 }

when:
  action: cambiar_estado
  Estado: Confirmado

then:
  error: "El pedido no puede confirmarse con total cero"

¿Por qué esto es poderoso?

Usando archivos con Markdown:

Definimos el modelo conceptual
Expresamos reglas formales
Documentamos comportamiento esperado
Generamos pruebas automáticas

El modelo deja de ser solo diseño y pasa a ser el centro ejecutable del sistema.

En un futuro cercano, herramientas de IA podrán, en forma consistente y correcta

Generar/mantener la estructura de la base de datos
Crear APIs automáticamente
Construir UI inicial
Generar tests unitarios y de aceptacion
Validar inconsistencias

El código será una consecuencia del modelo que podra expresarse de varias maneras.

Al ser archivos de Markdown tambien se facilita el versionado de los mismos y se deberan contar con algun mecanismo de centralizacion (tipo GIT) y solucion de colisiones cuando dos personas (o dos IA) modifiquen el mismo archivo o intenten ingresar requerimientos contradicctorios.

Cada vez es mas importante conocer el problema que queremos resolver con el sistema que estamos desarrollando, para poder expresarlo y definirlo correctamente.

Conclusión

Specification by Example no es solo una técnica de testing. Es una forma de pensar el desarrollo donde los ejemplos son el contrato.

Si esos ejemplos viven junto al modelo en Markdown ejecutable, tenemos una base sólida para sistemas generados, adaptables y verificables.

Visita a Japon

2026-02-26T08:57:00.002-03:00

Fuimos unos de los ganadores del concurso LetsPlAI (para programar soluciones que incoroporte inteligencia artificial).
La aplicacion que programe es un clasificador arancelario, que ayuda a encontrar el codigo arancelario para el MERCOSUR dada una descripcion de producto.
Tambien funciona con una imagen de una factura de importacion, o con una imagen del producto.
Tiene como ventaja que personas con no tanto conocimiento tecnico de la clasificacion arancelaria pueden ser guiadas a una clasificacion correcta (o al menos mejor informada).

El premio del viaje era un viaje a Japon, y exponer la solucion ante la comunidad GeneXus de Japon.

Ya conocia algo de Japon, pero es una sociedad y una cultura que admiro muchisimo y siempre se aprenden cosas nuevas de ellos.

Cosas a destacar, y que dependen mucho de su cultura, es la limpieza, el orden, el respeto por el grupo, su comida y la seguridad. Todas cosas que dependen de la cultura y la educacion, y me provocan una sana envidia.

Dejo algunas fotos de lo que pude ver en Tokio. Me encantaria volver en algun momento.

Webinar: Clasificacion Arancelaria asistida con Inteligencia Artificial

2026-01-02T08:22:00.001-03:00

Me invitaron a contar la experiencia de desarrollar CLARA v2.0, que es un clasificador arancelario, usando agentes de inteligencia artificial, usando Globant Enterprise IA.
Fue uno de los ganadores del concurso LETSPLAI y por eso nos ganamos un viaje a Japón.
El video de la charla se puede ver en youtube.

Cambiar el valor default de una propiedad en una KB GeneXus

2025-11-05T15:39:00.004-03:00

En GeneXus, las propiedades de los objetos tienen un comportamiento jerárquico: pueden definirse a distintos niveles (KB, Version, Environment, Generator, Folder, Object, etc.), y los valores definidos en niveles superiores se heredan como default por los niveles inferiores.

Este modelo facilita la consistencia general del desarrollo, pero plantea un desafío cuando queremos cambiar el valor por defecto de una propiedad en toda la Knowledge Base (KB).
Ese cambio puede tener un impacto masivo, afectando a miles de objetos en cascada.

Un ejemplo concreto: Commit on Exit

Supongamos que tenemos la propiedad Commit on Exit configurada en YES a nivel del Environment.
Esto significa que todos los objetos que no tengan un valor explícito heredan ese comportamiento y realizan un commit automático al finalizar la ejecución.

Ahora imaginemos que queremos modificar esta configuración para que cada desarrollador maneje manualmente las UTL (Unit of Transaction Logic), y por tanto necesitamos cambiar el valor por defecto a NO.

Si hacemos el cambio directamente a nivel de Environment, todos los objetos que usan el valor por defecto pasarán a tener Commit on Exit = NO.
En este caso, el cambio es global, instantáneo y coherente.

Cuando el cambio debe ser paulatino

El problema aparece cuando el cambio no puede hacerse de forma total e inmediata, por ejemplo:

Queremos que los objetos nuevos adopten el nuevo valor (NO),
pero mantener los objetos existentes con el valor anterior (YES) hasta que puedan ser revisados uno a uno.

En este escenario, la herencia jerárquica deja de ser suficiente.
Necesitamos romper la herencia en los objetos existentes (es decir, establecer explícitamente Commit on Exit = YES en cada uno) antes de cambiar el valor por defecto en el nivel superior.

De esta manera:

Los objetos existentes quedan con su comportamiento actual (valor fijo).
Los nuevos objetos, al heredar el nuevo default, comenzarán con el valor actualizado.

Estrategia recomendada

Identificar los objetos afectados: aquellos que tienen la propiedad en valor por defecto.
Puede hacerse con herramientas como KBDoctor o mediante un script de exportación de propiedades.
Asignar explícitamente el valor actual (YES) a esos objetos.
Cambiar el valor default a nivel de Environment o Version (NO).
Migrar paulatinamente los objetos, revisando el manejo de transacciones.

Conclusión

Cambiar el valor default de una propiedad en GeneXus parece simple, pero implica entender la herencia jerárquica de configuraciones.
Si el cambio es global, basta con modificarlo en el nivel superior.
Si es gradual, se requiere una estrategia intermedia que preserve la estabilidad del sistema mientras se avanza hacia el nuevo estándar.

Creo que es una buena oportunidad para automatizar y definir una buena práctica para lograr cambiar propiedades. Ayudaría mucho, poder tener una herramienta que fije el valor actual en los objetos que tienen el valor default, de forma de poder cambiar sin miedo a los valores más modernos.

Otros ejemplos de propiedades definidas a varios niveles (hay mas)

Default Style (Version / Objeto)
Default Master Page (Version / Objeto)
Web Form Defaults (Version / Objeto)
Default Web Form Editor (Version / Objeto)
Web User Experience (Version / Objeto)
Default Form Layout (Version / Instancia / Objeto)
Exposed Namespace (Version / SDT / BC)
Disabled Warning (Generador / Objeto)
Object Visibility (Modulo / Objeto)

Convertir de Theme a Design System

2025-10-30T11:45:00.002-03:00

Durante años, los Themes fueron la forma clásica de definir la estética de una aplicación GeneXus. Colores, fuentes y estilos centralizados, pero rígidos. Hoy, con Design System Objects (DSO), GeneXus da un paso enorme hacia la consistencia y la evolución visual controlada.

Migrar de Theme a Design System no es solo un cambio técnico: es adoptar una mentalidad de diseño unificado. El Design System permite definir tokens reutilizables (colores, tipografías, espaciados) y componentes que se adaptan automáticamente a la plataforma —web, mobile o ambas—, mejorando la experiencia de usuario y facilitando el mantenimiento.

En este proceso, lo que vamos a cambiar incluye:

Reemplazo de Theme por Design System.
Creación de una nueva MasterPage moderna.
Adopción del Editor Abstracto para una edición más limpia y visual.
Implementación de un diseño responsive para adaptarse a todos los dispositivos.
Limpieza de recursos no utilizados (Themes y MasterPages viejas, etc.).
Pasaje a valores por defecto de la mayoría de las clases.
Pasaje a valores por defecto de propiedades en los objetos GeneXus.

El proceso de conversión tiene que ser gradual y debe garantizar que la aplicación continúe funcionando en todo momento. Dado que la KB tiene más de 3.300 objetos con pantallas web, no se busca un cambio radical, sino una transición paulatina y controlada.

El proceso de conversión suele implicar las siguientes etapas:

Comenzar por los WebForms de transacciones que usan patterns, asegurando que los nuevos formularios sean compatibles con el Design System.
Continuar con los objetos generados automáticamente por los patterns, verificando su adaptación al nuevo esquema visual.
Luego avanzar con el resto de las transacciones no basadas en patterns, migrando gradualmente sus layouts al nuevo DSO.

Finalmente, actualizar los WebPanels personalizados, revisando estilos, clases y propiedades para alinearlos con el Design System.

Defincion de indicadores

Para poder medir el avance del proyecto, defini un indicador simple para usar era contar la cantidad de objetos que tienen formiulario web que usan el nuevo DSO.

Para colaborar con la conversion, tenemos programas que detectan clases referenciadas en los objetos, que no existen en el DSO.

Estudio del alcance del proyecto. Que cambiar y cuando

Tambien hice programas con ayuda de IA, que identifican objetos por módulos y obtienen las siguientes caracteristicas.

FullyQualifiedName
Type
MasterPage
ParentType (si el objeto esta en un FOLDER / MODULO O ES GENERADO POR WORKWITH)
Theme (SI ESTA EN BLANCO, TOMA EL DEFAULT)
WebUX (SI ES SMOOTH O NO)
WebFormDefaults (SI ES RESPONSIVE O NO)
FormLayout (UNANIMOTEMPLATE O CARMINE TAMPLATE)
FormEditor (HTML O ABSTRACT) Si el form es DEFAULT, no tiene nada
RulesDefault (si es workwith, dice si las rules no perdieron dinamismo)
EventsDefault (si es workwith, dice si los eventos no perdieron dinamismo)
ConditionDefault (si es workwhith, dice si las condition no perdieron dinamismo)
FormDefault (si es workwith, dice si el form, no perdio el dinamismo)
Description (descripcion del objeto)

Con todo esto, pudimos analizar que tanto teniamos para cambiar, cuantos objetos podiamos cambiar por sprint y que tanto ibamos a tener que trabajar para lograr el objetivo.

Propiedades involucradas en el cambio. .

Las propiedades que afectan este cambio, son varias, y tienen diferentes niveles de jerarquía.
Tuve que hacer un diagrama para poder entenderlo .

Conclusiones

Lo que al principio me pareció que era un cambio no tan grande, luego de realizar la evaluacion, termino siendo mucho mas grande y complejo de lo que me parecía.
Nos va a exigir automatizar varias de las etapas de y vamos a dedicar recursos para la prueba de todas las pantallas.
Si bien el proyecto no esta terminado, el resultado obtenido hasta el momento, es bueno. Y si bien la parte de UI no es mi fuerte, si entiendo que nos deja con un sistema mucho mas fácil de mantener.

Algunos links interesantes

GeneXus Theme y GeneXus DSO
Que es un DS?
Mitos de DS

Cómo integrar GeneXus 18 con Globant Enterprise AI

2025-10-07T10:24:00.003-03:00

Si trabajás con GeneXus 18, podés potenciar tus apps con Globant Enterprise AI (GEAI) para sumar inteligencia conversacional, recuperación de conocimiento (RAG) y automatización mediante agentes. En esta guía vas a ver: conceptos clave, arquitectura, paso a paso del lado de GEAI y del lado de GeneXus, y ejemplos de código listos para adaptar.

¿Qué es Globant Enterprise AI?

GEAI es una plataforma empresarial para crear y gobernar asistentes y agentes que combinan modelos generativos, herramientas externas y pipelines de recuperación (RAG) dentro de un entorno controlado. Actúa como capa de orquestación: desacopla tu aplicación del modelo, gestiona credenciales, costos, métricas, versiones y cumplimiento.

Componentes típicos

The Lab: diseño, test y despliegue de agentes/asistentes.
RAG: conexión a fuentes/documentos para respuestas con evidencia.
Tools: integraciones a APIs internas/externas.
Gobernanza: métricas, logs, versiones y seguridad.

¿Por qué usarlo?

Modelo-agnóstico (cambiás de modelo sin reescribir tu app).
Observabilidad y control de costos/tokens.
Escenarios multi-paso/autónomos con agentes.
Mejor time-to-value en equipos low-code.

Definiciones: Asistente, Agente y Asistente RAG

Tipo	Qué hace	Autonomía	Cuándo usar
Asistente	Responde a un prompt (chat clásico).	Baja	Q&A, redacción, transformaciones.
Asistente RAG	Busca evidencia antes de responder.	Media	Soporte, políticas, catálogos, procedimientos.
Agente	Orquesta pasos y tools, toma decisiones.	Alta	Flujos multi-paso, automatización, acciones.

Arquitectura de la integración

Usuario → App GeneXus (UI / evento)
       → Llamada REST a GEAI (endpoint de Asistente/Agente)
       → Ejecución en GEAI (opcional: RAG + Tools)
       → Respuesta estructurada
       → GeneXus (renderiza / ejecuta acciones de negocio)

Idea clave: GeneXus envía el prompt + contexto y recibe una respuesta (texto/JSON) y metadatos. Si es un agente, puede devolver también intenciones/acciones para que tu app las ejecute.

Paso a paso en GEAI (The Lab)

Permisos y proyecto: accedé a The Lab y creá un Assistant o Agent.
Definir propósito: qué resuelve, inputs esperados y formato de salida (texto/JSON).
Probar: ajustar prompts, roles y límites (tokens, temperatura, timeouts).
Tener claros estos datos para poder invocar:

BaseURL = https://api.saia.ai/chat o algo parecido.
Nombre del agente/asistente

Para asistente : "saia:assistant:%1"
Para agente: "saia:agent:%1"
Para RAG: "saia:search:%1"

Obtener el Token de autenticación : BaererToken="adadsfadsf....."

Los que yo programe, recibian un texto de entrada y tenian un texto estructurado de salida
Es importante ponerle a los asistentes/agentes que la salida sea de un formato especifico (puede ser json, xml, CSV, HTML pero que se pueda procesar correctamente desde GeneXus.
Tambien es importante explicitarle en el prompt que no agregue nada mas a la salida y conviene ponerle ejemplo de lo que quiero como salida.

Paso a paso en GeneXus 18

1) Variables y propiedades

Con las valores anteriores, ya podemos consumir los asistentes / agentes desarrollados. 
En mi caso, use procedimiento que haga el llamdo REST, pero tambien agregue el manejo de un CACHE 
DE INVOCACIONES, para ahorrar cuando se realizan invocaciones con el mismo texto. 
El texto puede incluir caracteres que hagan invalido el request, por lo que hay que hacer la sustitucion para que siempre sea valido, es lo que hago con el procedure TextoEscapado()

2) Llamada HTTP (REST) desde un Procedure o Event

&HttpClient.Timeout = 140

if not ExisteCacheAsistente(&Asistente,&TextoIN,&TextoOUT)  

	&HttpClient.AddHeader(!"Authorization", format(!"Bearer %1", BearerToken()))
	&HttpClient.AddHeader(!"Content-Type", !"application/json")

	&HttpClient.AddString(format(!'{"model":"%1",
            "messages": [{"role": "user","content": "%2"}],"stream": false}',
             &Asistente,TextoEscapado(&TextoIN)))

     	     &HttpClient.Execute(!"POST", BaseURL())

	if &HttpClient.ErrCode<> 0
		&Msg = format("Error: %1 - %2 - %3", &Pgmname,&HttpClient.ErrCode, &HttpClient.ErrDescription)
		Log.Error(&Msg)
		Msg(&Msg,status)
	else
		&TextoOUT = &HttpClient.ToString()
		&AsistenteResponse.FromJson(&HttpClient.ToString())
		&TextoOUT = &AsistenteResponse.choices.Item(1).message.content
		GraboCacheAsistente(&Asistente,&TextoIN,&TextoOUT)
	endif

Endif

Simplifique un poco el codigo, para que quedara mas lindo, pero le falta chequeo de errores y 
ver si tiene mas de una respuesta.

3) Parseo de respuesta

Si la salida es json, lo que hice es desde GX generar un SDT con el JSON (Tools / Application Integration / JSON Import)
y eso genera un SDT. 

En el código, se puede hacer

&SDT.FromJson(&SalidaDelAgente)
if NoHayErrores()
   Proceso(&SDT)
endif


Si la salida es un HTML se puede mostrar en pantalla, luego de hacer alguna validación que no contenga nada peligroso.

Buenas prácticas y checklist

Prompts estructurados: preferí entradas con campos (“objetivo”, “restricciones”, “formato de salida”).
Manejo de errores: validá StatusCode y contemplá timeouts/reintentos.
Versionado: mantené IDs/versions de agentes y feature flags para canary.
Observabilidad: log de prompts/latencias/tokens (sin datos sensibles).
Seguridad: protegé el token de GEAI; sanitizá entradas (no confiar en el modelo).
Contratos claros: definí bien el JSON de ida/vuelta; documentá ejemplos.
Costos: cacheá resultados repetibles; limitá longitud de prompts.

Conclusiones.

La combinación GeneXus 18 + Globant Enterprise AI te permite construir soluciones con bajo tiempo de desarrollo y alto impacto. Empezá con un Asistente, incorporá RAG para responder con evidencia y evolucioná a Agentes que orquestan procesos y herramientas.

GeneXus NEXT hace todo este proceso mucho mas facil y queda todo mucho mas integrado, pero quienes ya tenemos aplicaciones en Genexus vamos a necesitar un tiempo de transicion para incorporar agentes de IA a los sistemas que ya tenemos, por lo que este me parece un camino valido.

Cómo achicar el disco de Docker Desktop cuando se usa GeneXus Next (WSL2 en Windows)

2025-09-06T12:21:00.002-03:00

Contexto: GeneXus Next usa Docker Desktop sobre WSL2. Con el tiempo, el archivo de disco virtual de Docker (“ext4.vhdx” o “docker_data.vhdx”) crece y no se achica solo aunque borres imágenes.
Al cambiar de versión (en la fase beta se hace muy a menudo) se crean imágenes y contenedores que luego se dejan de usar, pero a veces no libera el espacio.
En mi caso, pude recuperar 28 Gb con la limpieza.

¿Por qué pasa?

Docker Desktop guarda sus datos en una distro WSL2 (docker-desktop-data) dentro de un disco virtual dinámico .vhdx que crece cuando necesitás más espacio, pero no reduce tamaño automáticamente al liberar datos.

Rutas típicas del VHDX

%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx (clásico)
%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx (nombres nuevos)

Tip: En Docker Desktop podés ver o cambiar Settings → Resources → Advanced → Disk image location y el tamaño máximo.

Paso a paso

Recomendación: hacé una copia del .vhdx antes de compactar.

Liberá espacio dentro de Docker
```
docker system df
docker system prune -a --volumes
```
Esto borra imágenes huérfanas, contenedores detenidos, redes y volúmenes no usados.
Cerrá Docker Desktop (tray icon → Quit Docker Desktop).
Apagá WSL (PowerShell como Administrador):
```
wsl --shutdown
```

Compactá el VHDX (elegí una):

Opción A – Optimize-VHD (Windows Pro/Enterprise con herramientas Hyper-V):

PowerShell (Administrador)

$Vhdx = "$env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx"   # Ajustá si usás \disk\docker_data.vhdx
Optimize-VHD -Path $Vhdx -Mode Full

Opción B – DiskPart (sirve en cualquier edición de Windows):

PowerShell (Administrador)

$Vhdx = "$env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx"

$dp = @"
select vdisk file="$Vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
"@

$tmp = New-TemporaryFile
Set-Content -LiteralPath $tmp -Value $dp -Encoding ASCII
diskpart /s $tmp
Remove-Item $tmp -Force

Reiniciá Docker Desktop y verificá:
```
docker ps
```
Comprobá el ahorro mirando el tamaño del archivo antes/después (Propiedades del archivo).

Usando Globant Enterprise AI para desarrollo de aplicaciones

2025-09-03T12:56:00.002-03:00

Preparándonos para lo que viene con GeneXus Next, estuve probando Globant Enterprise AI (GEAI) para incorporar Agentes y Asistentes a aplicaciones ya existentes construidas con GeneXus 18.

Resumen rápido: suma un nivel de potencia que puede elevar mucho la productividad en varios frentes. Por otro lado, se notan asperezas de una implementación que todavía evoluciona, lo que hace que la experiencia no sea tan fluida como podría ser.

Inconvenientes

Problemas de conexión / reconexión / desconexión

Dentro de GEAI hay varios componentes con Single Sign-On (SSO). En teoría, al iniciar sesión en uno quedo autenticado en todos; en la práctica, al alternar entre módulos a distintas horas aparecen errores 403 – Forbidden y hay que hacer “magia” para seguir trabajando. Además, no encontré forma de extender la duración de la sesión y cada ~20 minutos debo volver a loguearme. Huele a bugs propios de un producto todavía en transición.

Asistentes vs. Agentes

La terminología y el modelo mental no son del todo claros. En principio, un Asistente ejecuta una tarea específica apoyada en IA, mientras que un Agente puede orquestar varias herramientas (entre ellas, asistentes), mantener contexto y devolver resultados compuestos. Los Asistentes se gestionan en una sección y los Agentes en otra. Puedo crear un agente “estilo asistente”, pero —por ahora— no pude hacer agentes que ejecuten búsquedas RAG de forma nativa.

Flujos y “Procesos Agénticos”

Además existen Flujos y Procesos Agénticos. Da la sensación de que el diseño original está migrando hacia un nuevo modelo y estamos en plena adaptación. Falta una vista unificada que reduzca la confusión.

Salidas estructuradas de Asistentes

No hay ejemplos realmente claros de cómo lograr salidas estrictamente estructuradas (JSON, esquemas, etc.) en Asistentes. Curiosamente, esto es más sencillo cuando se trabaja desde Agentes.

Asistentes RAG vs. “otros” Asistentes

Los Asistentes aparecen en listas separadas y no termina de quedar claro el porqué. Intuyo que algunos requieren carga de documentos y otros no; aun así, preferiría ver todo en una única lista con filtros.

Documentación no integrada

La documentación de uso de asistentes es buena y el bot asociado responde con eficacia. Me gustaría que la guía para crear e invocar un asistente o agente estuviera integrada en el producto (aunque sea como ítem en el menú lateral). https://docs.globant.ai/en/chat

Información para desarrolladores

GEAI apunta a un público diverso, pero muchos usuarios seremos desarrolladores. Se agradecería una ruta clara para invocar agente/asistente/flow/proceso desde una aplicación (GX o no GX). Un patrón ideal sería: probar en la UI y obtener automáticamente el curl equivalente para la misma invocación (copiar/pegar y listo), evitando bucear en docs para cada detalle.

Errores encontrados

RAGAssistant: intenté crear un asistente para procesar una tabla simple y arrojó:

Error processing file: can only concatenate str (not 'int') to str.

No encontré forma de salir de ese estado.

DataAnalyst Assistant: al indexar un CSV llegó al 50% y falló sin indicar motivo. No vi logs ni requests con error para diagnosticar.

Ventajas

Potencia

No es mérito exclusivo de GEAI sino de los LLMs. Tenía que hacer un programa que leyera un documento, lo escaneara, hiciera OCR, extrajera datos estructurados, tradujera al español, procesara el texto y devolviera resultados estructurados a una app. Hace años resolvimos algo así integrando varios componentes distintos; hoy se cubre con un solo asistente. En casos así, el ahorro en meses de desarrollo e instalación (escaneo, OCR, traducción, etc.) es muy significativo.

Facilidad de integración

Es relativamente sencillo integrar con aplicaciones GeneXus y no GeneXus. Todo se puede invocar por API y queda centralizado y auditado.

Mayor nivel de abstracción

Podemos empezar a pensar soluciones a un nivel más alto, sin preocuparnos tanto por varios detalles de implementación (al menos, no de entrada). El enfoque de agentes y asistentes encaja bien con el espíritu de GeneXus Next, que promueve diseñar y automatizar más tareas con IA.

Independencia del LLM

Quizás la ventaja más importante: aún estamos en fase temprana y no está claro quiénes serán los ganadores. Es clave poder reutilizar conocimiento, moverlo de proveedor y no quedar atado a un único modelo. La sensación es similar a la burbuja .com: prevalecerán quienes agreguen valor real; por eso, abstraerse del LLM específico es estratégico.

Conclusión

Aún es pronto para dictar sentencia sobre el papel que jugarán GeneXus y GEAI en los próximos años; falta ver cómo se materializan en soluciones reales. Lo que sí está claro es que GeneXus parte con una ventaja estructural: un modelado sólido y una “fábrica” de backoffice madura.

El desafío ahora es completar el rompecabezas: front-end moderno y para usuarios finales; analítica a gran escala; documentación viva; testing automatizado; gestión de requerimientos y operaciones; buen soporte para bases no relacionales; y nuevos patrones de UI (con audio, video, imagenes, etc).

Si GEAI consigue integrarse bien en estas capas —con agentes, RAG y abstracciones reutilizables— podremos construir aplicaciones más completas, mantenibles y portables entre modelos, con un salto real de productividad. Hasta entonces, prudencia y experimentación: medir dónde aporta valor, documentar aprendizajes , para poder reutilizarlo.

iText + GeneXus : riesgo legal de su uso sin licencia.

2025-09-02T10:46:00.002-03:00

Si generás PDFs con GeneXus, seguro te cruzaste con iText (Java) o iTextSharp (.NET). Lo clave: las versiones modernas de iText ya no son gratuitas para uso empresarial salvo que cumplas AGPL; de lo contrario, requieren licencia comercial.

1) Línea de tiempo (qué fue gratis y desde cuándo se paga)

Gratis (para proyectos cerrados)
- iText 2.1.7 (Java): bajo MPL/LGPL. Última “antigua”. iTextpdf
- iTextSharp 4.1.6 (.NET Framework): última bajo MPL/LGPL. GitHubNuGet
Desde iText 5 (7-Dic-2009): dual AGPL + comercial. Si no podés/querés cumplir AGPL, tenés que licenciar (aplica también a iText 7/8). kb.itextpdf.com

AGPL implica obligaciones de compartir código si hay interacción por red con el programa que incorpora iText; para evitarlo, se usa licencia comercial. kb.itextpdf.com

2) GeneXus hoy: por generador

Java

Default: PDFBox (Apache 2.0, sin costo). docs.genexus.com
Opciones: iText (Legacy) = iText 2.x; iText 8 (AGPL/comercial). La posibilidad de elegir apareció en GX18 U4. dev-docs.genexus.comdocs.genexus.com

.NET (moderno, ex .NET Core / “.NET Generator”)

Default: iText (Legacy) (equivale a iText 4.x/iTextSharp histórico). docs.genexus.comdev-docs.genexus.com
Opciones: iText 8 (AGPL/comercial) y PDFPig como alternativa OSS agregada luego. sac.genexus.com

.NET Framework (viejo)

Sigue con iText (Legacy) por defecto (la rama histórica 4.x/iTextSharp). Si cambiás a iText 7/8, aplica el mismo esquema AGPL/comercial. dev-docs.genexus.com

Pista práctica: revisá la propiedad “PDF Reports Library” en tu KB (por generador) antes de compilar/deployar. docs.genexus.com

3) Qué conviene usar (en 2 líneas)

Si no querés licenciar iText:
- Java → PDFBox.
- .NET → evaluá PDFPig (según tus necesidades). docs.genexus.comsac.genexus.com
Si necesitás features de iText 7/8 (pdfHTML, PDF/A/UA, etc.) → comprá licencia comercial o asegurá cumplimiento AGPL. kb.itextpdf.com

4) Caso real

Caso Real: Demanda por el uso de iText sin Licencia

El riesgo de no pagar la licencia no es teórico. Ha habido varios casos de empresas demandadas por la empresa detrás de iText. Un caso que conozco involucró a una empresa en el extranjero que fue contactada por un representante de iText Group, la compañía desarrolladora. Después de un análisis del software de la empresa, los auditores de iText descubrieron que utilizaban la versión 5.x de la biblioteca en un producto comercial, sin haber adquirido la licencia comercial correspondiente.

La empresa recibió una carta de demanda exigiendo el pago de royalties retroactivos por el uso no autorizado y una tarifa por la licencia futura, lo que resultó en un costo significativamente mayor que el precio original de la licencia. Estos casos demuestran que las empresas que desarrollan software iText Group tienen equipos dedicados a la auditoría de licencias y no dudan en tomar acciones legales para proteger su propiedad intelectual.

La moraleja de la historia es clara: los costos y problemas legales de no cumplir con las licencias superan con creces el costo de adquirir una. Es fundamental auditar el software que se utiliza, especialmente las librerías de terceros, para evitar problemas que puedan poner en riesgo a tu empresa.

Fuentes

Cambio de licencia y línea histórica (iText): kb.itextpdf.comiTextpdf
Última versión LGPL/MPL en .NET (iTextSharp 4.1.6): GitHubNuGet
GeneXus “PDF Reports Library” (defaults y opciones por generador) + GX18 U4: docs.genexus.com

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

2025-08-18T10:09:00.004-03:00

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?

El usuario ingresa un nuevo requerimiento.
El sistema lo traduce y elimina ambigüedades.
Se clasifican los requerimientos concretos y se presentan al usuario.
Si falta información, el sistema propone o solicita aclaraciones.
Se mide el impacto en el repositorio central.
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.

Cómo manejar Slow Changing Dimensions (SCD) en GeneXus — Ejemplo práctico con Ventas y Clientes

2025-08-09T22:54:00.004-03:00

Este es un problema básico en el modelado de sistemas y bases de datos, pero es el causante de algunos inconvenientes en el momento de hacer reportes.

En muchos casos, se decide modelar el modelo operacional de la forma fácil (SCD Tipo 1) y en la plataforma de BI se mantiene la historia con SCD Tipo 2. **

El problema

Tenemos tres entidades:

Clientes: ClienteId, ClienteNombre, TipoClienteId.
Ventas: VentaId, ClienteId, Fecha, Monto.
TipoCliente: TipoClienteId, TipoClienteNombre (Grande, Mediano, Chico).

El sistema debe brindar el reporte de Ventas por Tipo de Cliente, para un rango de fechas

TipoCliente, Total Vendido
Grande 1000
Mediano 700
Chico 1200

Un dia, un cliente pasa de Mediano a Grande. Si el reporte “Ventas por Tipo de Cliente” junta las ventas con el tipo actual del cliente, entonces todas sus ventas históricas podrían aparecer como “Grande”, incluso las realizadas cuando era “Mediano”. Resultado: histórico inconsistente.

Señal de alerta: si tus sumatorias por categoría “se mueven” en el tiempo sin que cambien las ventas, probablemente estés usando solo el estado actual de la dimensión.

SCD Tipo 1 — Sobrescritura (sin histórico)

Se actualiza el registro de Cliente con el nuevo TipoClienteId. Las consultas siempre ven el estado actual.

El JOIN por ClienteId usa el tipo actual; el pasado queda sobrescrito.

Ventajas

Implementación simple.
No cambia el modelo físico.

Desventajas

Pierde histórico: reportes del pasado se recalculan con el estado actual.

SCD Tipo 2 — Histórico con versiones por rango de fechas

Se mantienen múltiples filas para el mismo Cliente, con FechaInicio, FechaFin y un flag EsRegistroActivo. Cada venta se asocia a la versión válida en su fecha.

Cada versión del cliente tiene validez. Las ventas se unen a la versión vigente en la fecha de la venta.

Estructura de la dimensión

// Tabla Cliente (Dimensión historificada)
ClienteId*         // Negocio
ClienteSK*         // (opcional) surrogate key interno
ClienteNombre
TipoClienteId
FechaInicio        // DATETIME
FechaFin           // DATETIME (NULL = vigente)
EsRegistroActivo   // boolean

Proceso de cambio (ETL/Procedure GX)

// Pseudocódigo GeneXus para cerrar versión y abrir una nueva
&hoy = now()
for each Cliente
   where ClienteId = &ClienteId
   where EsRegistroActivo
      Cliente.FechaFin = &hoy
      Cliente.EsRegistroActivo = False
      update
endfor

new Cliente
   ClienteId        = &ClienteId
   ClienteNombre    = &ClienteNombre
   TipoClienteId    = &NuevoTipoClienteId
   FechaInicio      = &hoy
   FechaFin         = null
   EsRegistroActivo = True
endnew;

Ventajas

Preserva histórico completo y consistente.
Permite “as of date”.

Desventajas

Mayor complejidad de carga y mantenimiento.
Más filas en la dimensión y joins con rangos de fechas.

Comparativa rápida

Modelo	Cuándo usar	Ventajas	Desventajas
SCD Tipo1	Cuando no importa el histórico.	Muy simple, sin cambios en modelo.	Pierde historia; reportes pueden “moverse”.
SCD Tipo2	Cuando el histórico es crítico (ej. ventas por tipo en el tiempo).	Histórico consistente; “as of date”.	Carga/ETL más compleja; join por rango de fechas.

Conclusión

Define el manejo de SCD antes de publicar reportes. Si tu informe “Ventas por Tipo de Cliente” debe reflejar el estado correcto en cada fecha, el enfoque recomendado es SCD Tipo 2. Para escenarios simples o sin necesidad de histórico, Tipo 1 puede bastar.

Tip GeneXus: puedes resolver SCD2 en la capa de ETL/Procedures (actualizando la dimensión) y consumirla desde Data Providers, garantizando que cada hecho apunte a la versión válida en su fecha. Se pueden usar atributos formulas con find() para ir a buscar el TipoCliente correcto en cada fecha.

Extensiones/Asistentes en GeneXus que me gustaría tener

2025-07-30T11:42:00.001-03:00

Se viene una nueva versión de GeneXus, que es la primera en incorporar inteligencia artificial en el IDE.

Esto nos abre la posibilidad de tener nuevos asistentes dentro del ide que nos automaticen tareas que en general son aburridas de hacer.

Algunos ejemplos de tareas que llevan mucho tiempo y podrían automatizarse

Analizador de Errores de Compilación

Un programa que lea el output de Genexus con errores y proponga soluciones. Muchas veces Genexus tiene errores que se solucionan mandando a especificar forzado algún objeto. Lo que me interesa principalmente es deducir cuales son los objetos que deben forzarse y que los genere automáticamente.

Generar Scripts de CREATE TABLE

Dada una tabla, crear un script para crear dicha tabla.
Es común tener que elegir un conjunto de tablas para hacer alguna prueba. Genexus es muy bueno para generar scripts de creación de toda la base de datos para los diferentes DBMS. Pero no es tan bueno para generar solo algunas tablas.
Me gustaría contar con un asistente que le pueda dar un conjunto de tablas y genere los scripts de creación de dicha tabla.

Generar programas para cargar datos.

Tengo una tabla en el ambiente de desarrollo con datos y quiero pasar esa tabla con datos a otro ambiente.
Lo que me interesa es dada una tabla, que ya tiene datos en la base de datos, generar un programa GX que cargue dicha tabla al ejecutar.
Esto puede hacerse con un script SQL (si me mantengo en la misma base de datos) o con un Procedure GX que permite hacerlo para múltiples environments.

Adaptador de ambientes de ejecución

Me gustaría contar con una herramienta que analice todo lo que voy a llevar a producción con un DEPLOY y me pregunte cuales son los valores nuevos que tendrán en producción.
Por ejemplo:

Connection String para la base de datos
Cache
Proxy
Observability
Session
Locations de servicios consumidos
Variables de ambiente
Secretos necesarios

Package ALL

Tener una herramienta que permita ejecutar las tareas de Package de la aplicación, tomando todas las Deployment Units y empaquetando la solución para un ambiente determinado. Opcionalmente podría hacer el deploy de la aplicación en el ambiente de ejecución.

Comparador de navegaciones

Tener un comparador de navegaciones integrado con el IDE que permita comparar navegaciones de versiones anteriores de Genexus con las mas nuevas. Que detecte los objetos que hayan modificado la navegación al especificalo y que clasifique las diferencias como Grandes, Medianas, Chicas y permitir que el desarrollador revise las mas graves.

GX-Linter

Tener un mecanismo de analizar código al salvar o al hacer un build all, que permita analizar los objetos modificados y marcar diferentes errores potenciales o estilos de código que son mejorables.
Por ejemplo se puede chequear

* Uso de Atributos que no están en ninguna tabla
* Código repetido
* Código comentado
* Variable definida pero no usada
* Eventos no usados
* Codigo demasiado largo
* Codigo demasiado complejo
* Lógica de negocio, en eventos de programas con UI
* Formulas complejas
* For each potencialmente lentos

* Mejoras en la modularizacon
* Variables no basadas en atributos / dominios

* Atributos no basados en dominios
* Descripciones incompletas de objetos

Por qué es clave actualizar tu versión de GeneXus (aunque duela un poco)

2025-07-30T10:16:00.002-03:00

En el mundo del desarrollo con GeneXus, trabajar con una versión antigua puede parecer cómodo, pero a la larga es una trampa silenciosa. Las migraciones o actualizaciones de versión no son solo una cuestión técnica: son una decisión estratégica que impacta en productividad, seguridad, mantenimiento y evolución del software.

¿Por qué actualizar GeneXus?

Seguridad y compatibilidad
Cada nueva versión de GeneXus mejora el soporte para tecnologías modernas, navegadores actualizados, motores de base de datos y protocolos de seguridad (como OAuth, HTTPS, JWT). Seguir en versiones antiguas te expone a vulnerabilidades y dependencias obsoletas.
Mejoras de performance y productividad
Desde nuevas estructuras como SD Panels hasta herramientas como los Design Systems, la evolución de GeneXus no solo permite hacer más, sino hacerlo mejor y más rápido. Ignorarlo es perder ventaja competitiva.
Soporte oficial y comunidad activa
Las versiones antiguas eventualmente quedan sin soporte. Esto significa que ante un error crítico, quedas solo. Además, la comunidad y la documentación se centran cada vez más en las versiones actuales.
Preparación para la IA y asistentes inteligentes
Las últimas versiones integran capacidades de automatización, testing asistido y generación de código mejorado, abriendo la puerta al desarrollo aumentado con IA.

Principales dificultades al migrar

Dependencias con tecnologías antiguas
Muchos sistemas heredados están ligados a plataformas como RPG, Win o WebForms. Migrar a Java, .NET Core o Angular implica revisar todo: desde la arquitectura hasta los procedimientos internos.
Cambios en el modelo de ejecución
El paso de aplicaciones stateful (Win) a aplicaciones stateless (Web) obliga a replantear la gestión del estado, sesiones y llamadas encadenadas.
Requiere tiempo, planificación y pruebas
Migrar no es apretar un botón. Requiere planificación, análisis de impacto, adaptación de código y mucho testing. Es un proyecto en sí mismo.
Adaptación de los equipos de desarrollo
Nuevas versiones traen nuevos conceptos. Si el equipo no se capacita, la migración puede estancarse o generar soluciones forzadas que terminan siendo peores.

Recomendaciones

Haz primero una prueba de concepto con una parte representativa del sistema.
Documenta las dificultades encontradas y las estrategias de mitigación.
Simplifica la KB si es posible antes de migrar, borrando todo lo que no se usa. Medir cuantos objetos hay que migrar e indicadores claves (cantidad de lineas de codigo, cantidad de reglas, cantidad de controles en pantalla, cantidad de parámetros, etc) para identificar los programas mas propensos a tener diferencias en la migracion.
Usa herramientas automáticas de GeneXus, pero no te fíes ciegamente: revisa manualmente los comportamientos clave.

Migrar duele. Pero no migrar, tarde o temprano, duele más.

Envío y Recepción de Emails con OAuth desde GeneXus (Gmail / Office 365)

2025-07-24T12:04:00.000-03:00

Con el aumento de las medidas de seguridad en servicios como Gmail y Office 365, el uso de usuario/contraseña para enviar correos electrónicos dejó de ser una opción viable. Actualmente, OAuth 2.0 es el estándar para autorizar el acceso a estos servicios. En este post, te muestro cómo integrarlo con GeneXus para enviar y recibir correos de forma segura.

Por un tiempo funciono correctamente el generar "application specific passwords" generando y registrando dichas contraseñas, pero estan dejando de funcionar y ya no es tan facil llegar a generar nuevas contraseñas. Por eso, es importante actualizar las aplicationes que necesiten enviar o recibir mail con estos proveedores para que usen OAuth 2.0.

Para esto, se necesita usar el OAuth Module, y programar algo asi:

&Success = OAuth.v2.RefreshToken(&OAuthAuthorizationConfig, &RefreshToken, &OAuthAccessToken, &DateTimeTokenExpire, &Messages) if (NOT &Success) Log.Error(&Messages) return endif

&AccessTokenString = &OAuthAccessToken.access_token &SMTPSession.Host = 'smtp.gmail.com' &SMTPSession.Port = 465 &SMTPSession.Timeout = 20 &SMTPSession.Secure = 1 &SMTPSession.Authentication = 1 &SMTPSession.UserName = 'Info@gmail.com' &SMTPSession.Password = &AccessTokenString &SMTPSession.AuthenticationMethod = "XOAUTH2" &SMTPSession.Login() &MailMessage.Subject="Email Subject" &MailMessage.Text="Message body" &MailRecipient.Address = "xxx@gmail.com" &MailRecipient.Name = "xxx"

&MailMessage.To.Add(&MailRecipient) &SMTPSession.Send(&MailMessage)

Para recibir mails, seria algo parecido (sin manejo de errores)

/* Antes de usar esto, hay que obtener el &ClientId &ClientSecret &MailHostToken */ &OAuthAuthorizationConfig.AccessTokenUrl = OAuth.v2.AccessTokenProvider.Google &OAuthAuthorizationConfig.ClientId = &ClientID &OAuthAuthorizationConfig.ClientSecret = &ClientSecret &Success = OAuth.v2.RefreshToken(&OAuthAuthorizationConfig, &MailHostToken, &OAuthAccessToken, &DateTimeTokenExpire, &OutMessages) if Not &Success Log.Error(&OutMessages.ToJson()) ... return else &POP3Session.newMessages = 0 &POP3Session.Host = 'pop.gmail.com' &POP3Session.Port = 995 &POP3Session.Secure=1 &POP3Session.UserName = &MailUserName &POP3Session.Password = &OAuthAccessToken.access_token &POP3Session.AuthenticationMethod = "XOAUTH2" if &POP3Session.ErrCode <> 0 .... endif endif Una cosa que es importante si están con .net, es AGREGAR EL ARCHIVO config.gx en la raíz de la KB y poner las líneas:

SMTPSession=MailKit OpenPOP=MailKit

De esta forma se va modificar para que use esa biblioteca para el envio y recepcion de mails.

Edición masiva en GeneXus: Cerrar las pestañas References antes de empezar

2025-07-03T11:30:00.001-03:00

Si tu Knowledge Base contiene miles de objetos, cada Save puede convertirse en una pausa innecesaria: el IDE recalcula de inmediato la información mostrada en las pestañas References y Referenced by. Cuando estás haciendo cambios en serie (ajustes de propiedades, limpieza de variables sin uso, marcar objetos como Not Generated, importar objetos, etc.) ese refresco continuo añade segundos —o minutos— a tu tarea.

¿Qué está pasando en segundo plano?

Las pestañas de referencia se alimentan de un grafo que describe todas las dependencias entre objetos. Cada guardado desencadena:

Análisis sintáctico del objeto modificado.
Re-cálculo de las aristas que cambian en el grafo.
Render del resultado en cada pestaña abierta.

En KB grandes el paso 2 puede tomar varios segundos. Repetido cientos de veces se vuelve un cuello de botella innecesario.

La práctica recomendada

1. Cierra todas las pestañas References/Referenced by antes de iniciar los cambios.

Usa el botón × de cada pestaña de referencias o usa la opcion "Close All But this" , que cierra todas los tabs, menos el activo.

2. Realiza toda la tanda de ediciones.

3. Guarda y confirma.

4. Cuando termines, vuelve a abrir las pestañas. El refresco se hará solo una vez, con todas las modificaciones ya consolidadas.

Ventajas inmediatas

Menos tiempo de espera: la percepción de “lag” desaparece.
Menor carga de CPU y disco: ideal en máquinas virtuales o KB con repositorio remoto.
Flujo de trabajo más fluido: te concentras en los cambios y no en la interfaz.

Conclusión

El truco es simple: mantén cerradas las pestañas de referencias mientras haces ediciones masivas. Ganarás agilidad sin perder la información; siempre podrás consultarla cuando realmente la necesites y con un solo refresco.

Extra: SOLO PARA NERDS

Solo para los que les guste optimizar sentencias en la base de datos, en GeneXus 18 Upgrade 12, para calcular las referencias, esta usando esta consulta sobre SQL Server.

WITH ObjectsInModule AS (
SELECT
mcr.ToEntityId AS ModuleId,
mcr.FromEntityTypeId AS EntityTypeId,
mcr.FromEntityId AS EntityId
FROM ModelCrossReference mcr WITH (NOLOCK)
WHERE ModelId = @ModelId
AND ToEntityTypeId = @ModuleTypeId
AND LinkType = @ParentLinkType

UNION ALL

SELECT
oim.ModuleId,
mcr.FromEntityTypeId AS EntityTypeId,
mcr.FromEntityId AS EntityId
FROM ModelCrossReference mcr WITH (NOLOCK)
INNER JOIN ObjectsInModule oim
ON oim.EntityTypeId = mcr.ToEntityTypeId
AND oim.EntityId = mcr.ToEntityId
WHERE mcr.ModelId = @ModelId
AND mcr.FromEntityTypeId <> @ModuleTypeId
AND mcr.LinkType = @ParentLinkType
AND oim.EntityTypeId <> @ModuleTypeId
),
ModulesInModule AS (
SELECT
EntityId AS ModuleId,
CONVERT(VARCHAR(MAX), '') AS ModuleName
FROM ModelEntityVersion WITH (NOLOCK)
WHERE ModelId = @ModelId
AND EntityTypeId = @ModuleTypeId
AND ModelParentEntityTypeId = 0

UNION ALL

SELECT
mev.EntityId AS ModuleId,
IIF(
mim.ModuleName = '',
mev.ModelEntityVersionName,
CONCAT(mim.ModuleName, '.', mev.ModelEntityVersionName)
) AS ModuleName
FROM ModelEntityVersion mev WITH (NOLOCK)
INNER JOIN ModulesInModule mim
ON mev.ModelParentEntityId = mim.ModuleId
WHERE mev.ModelId = @ModelId
AND mev.EntityTypeId = @ModuleTypeId
)
SELECT
mcr.EntityTypeId,
mcr.EntityId,
COALESCE(mev.ModelEntityVersionName, '') AS EntityVersionName,
mcr.LinkType,
mcr.LinkTypeInfo,
mcr.ReferenceType,
mcr.HasReferences,
COALESCE(mim.ModuleName, '') AS ModuleName
FROM (
SELECT
mcr1.ToEntityTypeId AS EntityTypeId,
mcr1.ToEntityId AS EntityId,
mcr1.LinkType,
mcr1.LinkTypeInfo,
mcr1.ReferenceType,
CONVERT(BIT, (
SELECT TOP(1) 1
FROM ModelCrossReference mcr2 WITH (NOLOCK)
WHERE mcr2.ModelId = @ModelId
AND mcr2.FromEntityTypeId = mcr1.ToEntityTypeId
AND mcr2.FromEntityId = mcr1.ToEntityId
AND mcr2.LinkType = @ObjectLinkType
AND mcr2.ToEntityTypeId IN (
SELECT EntityTypeId
FROM EntityType
WHERE EntityTypeIsModelable = 0
OR EntityTypeNamespace <> ''
)
)) AS HasReferences
FROM ModelCrossReference mcr1 WITH (NOLOCK)
WHERE mcr1.ModelId = @ModelId
AND mcr1.FromEntityTypeId = @EntityTypeId
AND mcr1.FromEntityId = @EntityId
AND mcr1.LinkType = @ObjectLinkType
AND mcr1.ToEntityTypeId IN (
SELECT EntityTypeId
FROM EntityType
WHERE EntityTypeIsModelable = 0
OR EntityTypeNamespace <> ''
)
) AS mcr
LEFT JOIN (
SELECT EntityTypeId, EntityId, ModelEntityVersionName
FROM ModelEntityVersion WITH (NOLOCK)
WHERE ModelId = @ModelId
) AS mev
ON mev.EntityTypeId = mcr.EntityTypeId
AND mev.EntityId = mcr.EntityId
LEFT JOIN ObjectsInModule oim
ON oim.EntityTypeId = mcr.EntityTypeId
AND oim.EntityId = mcr.EntityId
LEFT JOIN ModulesInModule mim
ON oim.ModuleId = mim.ModuleId;

En la KB en la que estaba trabajando, es bastante ineficiente, pues demora hasta 18 segundos en la base, y eso lo repite tantas veces como tabs de referencias abiertos tengas, multiplicado por la cantidad de objetos que modifiques en forma batch.

Use un modelo de inteligencia artificial para optimizarlo, y paso de un costo de 158 a un costo de 5 con la siguiente sentencia equivalente.

-- 1) Lista de tipos permitidos
DECLARE @AllowedTypes TABLE (EntityTypeId INT PRIMARY KEY);
INSERT INTO @AllowedTypes
SELECT EntityTypeId
FROM EntityType
WHERE EntityTypeIsModelable = 0
OR EntityTypeNamespace <> '';

-- 2) Precalcula flags de referencias
;WITH RefFlags AS (
SELECT DISTINCT
FromEntityTypeId AS EntityTypeId,
FromEntityId,
1 AS HasReferences
FROM ModelCrossReference WITH (NOLOCK)
WHERE ModelId = @ModelId
AND LinkType = @ObjectLinkType
AND ToEntityTypeId IN (SELECT EntityTypeId FROM @AllowedTypes)
),
-- 3) CTE recursiva de módulos (sin cambios sustanciales)
ObjectsInModule AS (
SELECT mcr.ToEntityId AS ModuleId
, mcr.FromEntityTypeId AS EntityTypeId
, mcr.FromEntityId AS EntityId
FROM ModelCrossReference mcr WITH (NOLOCK)
WHERE ModelId = @ModelId
AND ToEntityTypeId = @ModuleTypeId
AND LinkType = @ParentLinkType

UNION ALL

SELECT oim.ModuleId
, mcr.FromEntityTypeId
, mcr.FromEntityId
FROM ModelCrossReference mcr WITH (NOLOCK)
JOIN ObjectsInModule oim
ON oim.EntityTypeId = mcr.ToEntityTypeId
AND oim.EntityId = mcr.ToEntityId
WHERE mcr.ModelId = @ModelId
AND mcr.FromEntityTypeId<> @ModuleTypeId
AND mcr.LinkType = @ParentLinkType
),
ModulesInModule AS (
SELECT EntityId AS ModuleId
, CAST('' AS VARCHAR(MAX)) AS ModuleName
FROM ModelEntityVersion WITH (NOLOCK)
WHERE ModelId = @ModelId
AND EntityTypeId = @ModuleTypeId
AND ModelParentEntityTypeId= 0

UNION ALL

SELECT mev.EntityId
, CASE
WHEN mim.ModuleName = '' THEN mev.ModelEntityVersionName
ELSE mim.ModuleName + '.' + mev.ModelEntityVersionName
END
FROM ModelEntityVersion mev WITH (NOLOCK)
JOIN ModulesInModule mim
ON mev.ModelParentEntityId = mim.ModuleId
WHERE mev.ModelId = @ModelId
AND mev.EntityTypeId = @ModuleTypeId
)
SELECT
mcr.ToEntityTypeId AS EntityTypeId,
mcr.ToEntityId AS EntityId,
COALESCE(mev.ModelEntityVersionName,'') AS EntityVersionName,
mcr.LinkType,
mcr.LinkTypeInfo,
mcr.ReferenceType,
COALESCE(rf.HasReferences,0) AS HasReferences,
COALESCE(mim.ModuleName,'') AS ModuleName
FROM ModelCrossReference mcr WITH (NOLOCK)
-- 4) Aplica filtros directos y únete a AllowedTypes
JOIN @AllowedTypes at
ON mcr.ToEntityTypeId = at.EntityTypeId
AND mcr.ModelId = @ModelId
AND mcr.FromEntityTypeId = @EntityTypeId
AND mcr.FromEntityId = @EntityId
AND mcr.LinkType = @ObjectLinkType

-- 5) Enlaza el flag precomputado
LEFT JOIN RefFlags rf
ON rf.EntityTypeId = mcr.ToEntityTypeId
AND rf.FromEntityId = mcr.ToEntityId

-- 6) Trae nombre de versión si existe
LEFT JOIN ModelEntityVersion mev WITH (NOLOCK)
ON mev.ModelId = @ModelId
AND mev.EntityTypeId = mcr.ToEntityTypeId
AND mev.EntityId = mcr.ToEntityId

-- 7) Finalmente enlaza con los módulos
LEFT JOIN ObjectsInModule oim
ON oim.EntityTypeId = mcr.ToEntityTypeId
AND oim.EntityId = mcr.ToEntityId
LEFT JOIN ModulesInModule mim
ON mim.ModuleId = oim.ModuleId
OPTION (RECOMPILE);

Se lo pase a la gente de Genexus por si les interesa hacer esta optimización o una parecida, pero muchas veces hay restricciones como las versiones de SQL Server soportadas, o efectos secundarios que pueden acarrear estos cambios que impiden implementarla.

En resumen, si quieren que GeneXus esta un poquito mas rapido, CIERREN LAS VENTANAS DE REFERENCIAS cuando no las necesiten.

Conclusión Extra

Cada vez que veo este tipo de cosas, pienso que GeneXus debería utilizar una base de datos orientada a grafos, para almacenar las referencias de los objetos en la base de conocimiento.

Preparando tu KB GeneXus para Aplicaciones de Inteligencia Artificial

2025-06-19T14:36:00.000-03:00

En el desarrollo moderno, donde la IA se integra cada vez más en la creación y mantenimiento de aplicaciones, GeneXus ya ha mostrado que en su próxima versión vamos a tener dentro del IDE y vamos a poder generar asistentes de inteligencia artificial.

Como desarrollador GeneXus, ¿que es lo que puedo hacer hoy en las versiones liberadas, para prepararme para ese desafío?

Las herramientas de inteligencia artificial en su estado actual, necesitan descripciones textuales para poder entender los elementos con los que operan. Por lo tanto, tenemos que tener claro que vamos a tener que mejorar la metadata que describe nuestros objetos.

¿Por qué la metadata es tan importante?

Describe la intención y contexto de cada componente, no solo su estructura técnica.

Permite a herramientas de IA entender cómo reutilizar, adaptar o proponer cambios en base a la semántica.

Facilita la generación de pruebas, documentación y migraciones automatizadas.

A continuación, paso una lista de las tareas que a mi me sirvieron para poder incorporar agentes a la KB

Prácticas clave para una KB lista para IA

1) Eliminar lo que no se usa

A las herramientas y agentes, hay que brindarle cuales son los objetos que debe usar en forma clara. Tener en la KB objetos que no se usan, dificulta mucho esta tarea.

Revisa y borra: atributos que no estén en tablas, objetos no alcanzables, objetos main no usados, tablas sin uso y variables no utilizadas.

Si hay objetos en folder Borrar, To_Delete, etc o con nombres del tipo _BACKUP, *_borrar, etc hay que hacer un esfuerzo y borrarlos.

Para esto hay herramientas como el KBDoctor, VariableCleaner que puede ayudarte.

2) Mejora los campos Description y Documentation de los objetos

Completa el campo Description en cada objeto, describiendo QUE ES ese objeto

El orden de importancia que yo le doy a esto es:

Tablas
Atributos
API
Objetos con UI mas usados (si tenes Google Analytics es facil hacer una lista)
Resto de los objetos

Si la base de datos va a ser accedida por herramientas externas, también es bueno poner la propiedad "Generate COMMENT ON statements" en YES de forma que las descripciones de tablas y atributos lleguen a la base de datos, cuando se hacen reorganizaciones a través de GeneXus.

Para objetos con UI, en el tab Documentation, escribe el PARA QUE de ese objeto o sea la intención de uso de la pantalla: qué operación realiza, en qué contexto se usa y a qué usuarios está dirigida.

Los nombre de los eventos, es bueno que tenga nombres que indique que operacion hacen desde el punto de vista del usuario, asegurándote de que tengan nombres claros que reflejen exactamente qué acción ejecutan (ValidarCamposEntrada, ConfirmarPago, EnviarNotificacionCliente).

3) Nombrar con intención

Evita nombres genéricos (Procedure1, Prompt1).

Usa nombres que expliciten acción y contexto: GenerarFacturaPDF, CalcularRetencionesProveedor.

Siempre pensar en para que va a usarse el objeto que estoy nombrando y describiendo.

Tener objetos chicos que solo hacen una cosa, facilita muchísimo ponerle nombre.

4) Modularizar la KB

La inteligencia artificial funciona mejor si trabaja con un conjunto chico de objetos. En KB grandes, conviene clasificar las tablas y objetos en módulos para reflejar los grupos funcionales de la aplicación y esto ayuda a tener contextos mas limitados para ciertos problemas.

Agrupa objetos por contexto funcional, no solo por tipo técnico, por ejemplo:

DatosBasicos/Clientes,
DatosBasicos/Depositos,
Facturacion,
Cobranza.

5) Hacer explícita las funciones que cada modulo expone como servicio.

Si queremos que los agentes de inteligencia artificial usen los servicios provistos por nuestra KB, es bueno crear objetos API con nombres claros, parámetros significativo y una buena explicación de que es lo que hacen para que sea fácil a los agentes hacer llamadas a dichas API.

Consistencia en la forma de pasar parámetros y resultados. Usar formatos legibles para IA: JSON, YAML o tablas de base de datos.

6) Encontrar y agrupar las pantallas parecidas

Es común que en las aplicaciones tengamos patrones de pantallas (aunque no sean generadas con herramientas de GeneXus Patterns), sino que son pantallas que se usan de una forma consistente en todo el sistema.

Es bueno tener esos objetos catalogados (puede ser en categorías) de forma de luego poderle dar a los agentes un conjunto de objetos sobre los que trabajar.

7) Crear y mantener un glosario de sinónimos

Empieza a generar una lista de sinónimos y términos equivalentes que tus usuarios usan para referirse a entidades y atributos clave. Para esta tarea, podemos usar inteligencia artificial.

Esto aun no tiene un lugar claro para guardar en la KB, pero es de mucha ayuda cuando hacemos agentes que sean usados por público diverso y mas si es de diferentes paises.

Facilita la comprensión de la KB por parte de la IA mejorando la precisión de asistentes de lenguaje natural o chatbots. Por ejemplo:

Término Sinónimos

Cliente Usuario, Comprador, Consumidor, CuentaCliente

Depósito Almacén, Bodega, CentroDistribución, StockLocation

Ciudad Localidad, Municipio, Población, CiudadResidencia

Beneficios concretos

Si se aplican estos cambios, que ninguno es demasiado complejo, se tendrán varios beneficios:

Acelera la incorporación de asistentes a una KB existente
Facilita la migración o refactorización asistida por IA, haciendo mas fácil el mantenimiento
Potencia la precisión de asistentes conversacionales al entender sinónimos y términos usados por los usuarios finales.

Conclusión

Invertir en una buena estructura de metadata no es opcional: es la base para integrar inteligencia artificial en tu proceso de desarrollo. Empieza hoy a hacer explícita la intención de cada componente y a mantener un glosario de términos usados por tus usuarios: tu KB GeneXus se convertirá en una fuente de conocimiento vivo, lista para trabajar codo a codo con herramientas de IA.

Aunque aún no vayas a incorporar herramientas de IA, es un trabajo que se puede adelantar, es indispensable para lo que se viene y lleva bastante trabajo, por lo que conviene anticiparse en lo posible. Es una tarea que puede ser hecha por usuarios con conocimiento funcional de la aplicación, sin necesitad de grandes conocimientos técnicos.

Comparacion de herramientas de inteligencia artificial para la escritura de Post

2025-06-12T16:24:00.001-03:00

Hice un pequeño experimento, para ver el estado de las herramientas de inteligencia artificial para escribir documentación técnica.

A partir del prompt.

El Impacto de la Inteligencia Artificial en el Desarrollo de Aplicaciones con GeneXus: Una Revolución Comparable a la Retroexcavadora (by Grok)

2025-06-12T15:50:00.004-03:00

La Analogía de la Retroexcavadora

Imagina una obra en construcción hace un siglo. Cavar una zanja requería un equipo de obreros trabajando arduamente con palas, un proceso lento y físicamente agotador. Luego llegó la retroexcavadora: una máquina capaz de realizar el trabajo de varios operarios en una fracción del tiempo, con mayor precisión y menor esfuerzo físico. Este cambio no eliminó la necesidad de trabajadores, pero transformó sus roles, exigiendo operadores capacitados para manejar la maquinaria.

En el desarrollo de software, estamos viviendo una revolución similar. Antes, crear aplicaciones requería que los programadores escribieran línea por línea de código, un proceso laborioso que demandaba equipos numerosos para proyectos complejos. Hoy, los agentes de inteligencia artificial (IA) que generan código actúan como la retroexcavadora del desarrollo: automatizan tareas repetitivas, aceleran la producción y permiten a los desarrolladores enfocarse en aspectos más estratégicos. En este contexto, plataformas como GeneXus, conocidas por su capacidad de generar código automáticamente, se potencian aún más con la integración de la IA.

Cómo la IA Está Transformando el Desarrollo con GeneXus

GeneXus es una plataforma low-code que ya simplifica el desarrollo al generar aplicaciones multiplataforma a partir de modelos y especificaciones de alto nivel. Con la incorporación de la IA, esta capacidad se multiplica, llevando la productividad y la calidad del desarrollo a nuevos niveles. A continuación, exploramos cómo la IA está transformando el trabajo con GeneXus:

Generación Automática de Código Mejorada: Los agentes de IA, integrados en GeneXus, pueden interpretar requisitos en lenguaje natural y convertirlos en modelos o código funcional. Por ejemplo, un desarrollador puede describir una funcionalidad como "crear un formulario para registrar clientes con validación de correo electrónico" y la IA generará el código base, ajustado a las convenciones de GeneXus, en minutos. Esto reduce significativamente el tiempo de codificación manual.
Optimización de Diseños y UX: La IA analiza patrones de uso y tendencias de diseño para proponer interfaces de usuario optimizadas. En GeneXus, esto se traduce en recomendaciones automáticas para mejorar la experiencia del usuario, como layouts responsivos o flujos de navegación intuitivos, sin que el desarrollador deba invertir horas en investigación.
Pruebas y Depuración Automatizadas: Los agentes de IA pueden generar casos de prueba, identificar errores en el código y sugerir correcciones antes de que el desarrollador los detecte. En GeneXus, esto asegura que las aplicaciones generadas sean más robustas y reduzcan el tiempo dedicado a la fase de testing.
Mantenimiento Proactivo: La IA puede monitorear aplicaciones en producción, detectar cuellos de botella y proponer mejoras en el código generado por GeneXus. Esto permite a los equipos anticiparse a problemas y mantener sistemas actualizados con menos esfuerzo.
Aceleración del Ciclo de Desarrollo: Al combinar la capacidad de GeneXus para generar aplicaciones multiplataforma con la velocidad de la IA, los proyectos que antes tomaban meses ahora se completan en semanas. Esto es especialmente valioso en un mercado donde la rapidez para lanzar productos es un diferenciador competitivo.

En resumen, la IA actúa como un "copiloto" para los desarrolladores en GeneXus, automatizando tareas rutinarias y permitiéndoles enfocarse en la lógica de negocio, la innovación y la estrategia. Sin embargo, al igual que una retroexcavadora no elimina la necesidad de un operador, la IA no reemplaza a los programadores, sino que redefine su rol.

Conclusión: Nuevas Habilidades para una Nueva Era

La llegada de la retroexcavadora no significó el fin de los trabajadores de la construcción, pero sí requirió que aprendieran a operar maquinaria avanzada. De manera similar, la integración de la IA en el desarrollo con GeneXus no elimina la necesidad de desarrolladores, pero exige habilidades más avanzadas. Los programadores deben aprender a supervisar, configurar y validar el trabajo de los agentes de IA, así como a interpretar sus sugerencias en el contexto del negocio. Esto incluye competencias en diseño de prompts efectivos, comprensión de modelos de IA y toma de decisiones estratégicas sobre cuándo y cómo usar estas herramientas.

En un mundo donde la IA es la retroexcavadora del desarrollo, los desarrolladores que dominen GeneXus y las herramientas de IA estarán mejor posicionados para construir aplicaciones innovadoras, rápidas y confiables. La clave está en abrazar esta transformación, capacitarse continuamente y liderar la evolución del desarrollo de software.

De la Pala a la Retroexcavadora: Cómo la IA Revoluciona el Desarrollo con GeneXus (by Claude.ai)

2025-06-12T15:42:00.002-03:00

La evolución tecnológica siempre ha transformado la manera en que trabajamos. Hoy, los agentes de IA están redefiniendo el desarrollo de aplicaciones de la misma forma que las máquinas revolucionaron la construcción.

La Analogía Perfecta: De Cavar Zanjas a Escribir Código

Imagina una obra de construcción hace 50 años. Para cavar una zanja de 100 metros, se necesitaba un equipo de 8 a 10 operarios armados con palas, trabajando durante días bajo el sol. Era un proceso lento, físicamente demandante y costoso en términos de tiempo y recursos humanos.

Luego llegó la retroexcavadora y cambió las reglas del juego por completo. Lo que antes requería una cuadrilla completa y varios días de trabajo, ahora podía completarse en pocas horas con un solo operador especializado y una máquina potente.

Esta misma revolución está ocurriendo hoy en el desarrollo de software, especialmente en plataformas como GeneXus, donde los agentes de IA que escriben código están cumpliendo el rol de esa retroexcavadora digital.

El Antes y el Después en el Desarrollo con GeneXus

El Escenario Tradicional: "Los Operarios con Palas"

En el desarrollo tradicional de aplicaciones con GeneXus, aunque la plataforma ya simplificaba muchos procesos, aún se requería:

Múltiples desarrolladores trabajando en diferentes módulos
Semanas o meses para completar funcionalidades complejas
Revisiones manuales extensivas de código y lógica de negocio
Pruebas iterativas que consumían tiempo considerable
Documentación manual de cada componente desarrollado

La Nueva Era: "La Retroexcavadora de la IA"

Con la integración de agentes de IA en el ecosistema GeneXus, el panorama ha cambiado radicalmente:

Generación Automática de Código: Los agentes de IA pueden escribir procedimientos, transacciones y web panels completos basándose en especificaciones de alto nivel, reduciendo el tiempo de desarrollo en un 70-80%.

Optimización Inteligente: La IA analiza patrones en el código existente y sugiere mejoras automáticas, identificando redundancias y optimizando consultas SQL de forma proactiva.

Testing Automatizado: Los agentes generan casos de prueba exhaustivos y ejecutan validaciones automáticas, detectando errores que podrían pasar desapercibidos en revisiones manuales.

Documentación Inteligente: La IA crea documentación técnica y funcional de manera automática, manteniéndola actualizada con cada cambio en el código.

Refactoring Asistido: Cuando es necesario modificar la arquitectura de una aplicación, la IA puede reestructurar miles de líneas de código en minutos, manteniendo la funcionalidad intacta.

Casos de Uso Reales en GeneXus

Desarrollo de APIs REST

Donde antes un desarrollador tardaba días en crear una API completa con todos sus endpoints, validaciones y documentación, ahora la IA puede:

Generar automáticamente los web services basándose en el modelo de datos
Crear la documentación OpenAPI correspondiente
Implementar validaciones y manejo de errores estándar
Todo en cuestión de minutos

Migración de Aplicaciones Legacy

La IA puede analizar aplicaciones antiguas desarrolladas en GeneXus y:

Identificar patrones obsoletos automáticamente
Sugerir y aplicar mejores prácticas actuales
Modernizar la interfaz de usuario siguiendo estándares contemporáneos
Optimizar la estructura de datos para mejor rendimiento

Generación de Reportes Complejos

Los agentes de IA pueden crear reportes sofisticados que antes requerían programación manual detallada:

Análisis automático de relaciones entre tablas
Generación de consultas optimizadas
Creación de visualizaciones apropiadas para cada tipo de dato
Formateo profesional del output final

El Impacto Cuantificable

Las métricas hablan por sí solas. Las organizaciones que han adoptado herramientas de IA en sus procesos de desarrollo con GeneXus reportan:

Reducción del 60-80% en tiempo de desarrollo de funcionalidades estándar
Mejora del 45% en la calidad del código generado
Disminución del 70% en errores detectados en producción
Incremento del 200% en la velocidad de entrega de proyectos

Pero quizás lo más importante es el cambio cualitativo: los desarrolladores pueden dedicar más tiempo a arquitectura, innovación y resolución de problemas complejos, en lugar de escribir código repetitivo.

El Nuevo Perfil del Desarrollador GeneXus

Así como el operador de retroexcavadora necesita habilidades diferentes al obrero con pala, el desarrollador que trabaja con IA requiere un skillset evolucionado:

Pensamiento Arquitectónico: Capacidad para diseñar sistemas complejos y definir especificaciones de alto nivel que la IA pueda interpretar correctamente.

Supervisión Inteligente: Habilidad para revisar, validar y optimizar el código generado por IA, identificando posibles mejoras o problemas potenciales.

Prompt Engineering: Competencia para comunicarse efectivamente con los agentes de IA, proporcionando contexto y restricciones apropiadas.

Integración de Sistemas: Experiencia en conectar diferentes herramientas de IA con el ecosistema GeneXus y otros sistemas empresariales.

Conclusión: Más Poder, Mayor Responsabilidad

La analogía de la retroexcavadora nos enseña una lección fundamental: las herramientas más poderosas requieren operadores más capacitados.

Cualquiera puede tomar una pala y cavar, pero operar una retroexcavadora eficientemente requiere entrenamiento especializado, comprensión de mecánica, conocimiento de seguridad y habilidades de coordinación espacial avanzadas. El operador de retroexcavadora no solo debe saber cómo usar la máquina, sino cuándo usarla, dónde aplicar la fuerza correcta y cómo evitar daños colaterales.

De la misma manera, supervisar herramientas de IA en el desarrollo con GeneXus exige habilidades más avanzadas que la programación tradicional. El desarrollador moderno debe comprender arquitecturas complejas, ser capaz de validar código generado automáticamente, y tener la experiencia para guiar a los agentes de IA hacia soluciones óptimas.

La diferencia es que, mientras el operario con pala quedó desplazado, el programador con IA se ha potenciado exponencialmente. La clave está en evolucionar junto con la tecnología, desarrollando las competencias necesarias para ser no solo un usuario, sino un maestro de estas nuevas herramientas.

El futuro del desarrollo no pertenece a quienes temen a la IA, sino a quienes aprenden a dirigirla con sabiduría y precisión. En GeneXus, esta revolución ya comenzó. ¿Estás listo para ser el operador de tu propia retroexcavadora digital?

La Retroexcavadora Digital: Cómo la IA Potencia el Desarrollo de Aplicaciones con GeneXus (by Gemini)

2025-06-12T15:33:00.001-03:00

¿Recuerdas cuando construir una zanja significaba horas de sudor y esfuerzo para un equipo de obreros, pala en mano? Era un trabajo arduo, lento y que demandaba una considerable cantidad de mano de obra. Luego, la tecnología nos trajo la retroexcavadora. De repente, una sola máquina, operada por una persona, podía realizar el trabajo de decenas de operarios en una fracción del tiempo. La eficiencia se disparó, los costos disminuyeron y la forma de abordar proyectos de excavación cambió para siempre.

Esta misma revolución, esta "retroexcavadora digital", está ocurriendo ahora mismo en el mundo del desarrollo de software, y GeneXus está a la vanguardia.

De la Pala del Programador al Agente de IA: Una Analogía Reveladora

Imagina a esos programadores del pasado, meticulosamente escribiendo línea tras línea de código, resolviendo cada detalle, depurando incansablemente. Cada nueva funcionalidad, cada ajuste, era como cavar una pequeña sección de esa zanja con una pala. Era un proceso manual, propenso a errores humanos y que escalaba linealmente con la complejidad del proyecto.

Hoy, la Inteligencia Artificial, especialmente los agentes de IA capaces de generar código, está asumiendo el rol de esa retroexcavadora. Ya no se trata de que varios programadores caven con sus "palas" de código individual. Ahora, un único programador, con la ayuda de herramientas de IA, puede lograr resultados que antes requerirían un equipo mucho más grande y un tiempo considerablemente mayor. La IA puede generar fragmentos de código, completar funcionalidades, e incluso identificar y sugerir soluciones a problemas, acelerando drásticamente el proceso de desarrollo.

La IA Transformando el Desarrollo con GeneXus

GeneXus, con su enfoque de desarrollo basado en modelos y su capacidad para generar automáticamente aplicaciones para múltiples plataformas, siempre ha sido un pionero en la automatización del desarrollo. La integración de la Inteligencia Artificial eleva esta automatización a un nivel completamente nuevo:

Generación de Prototipos Inteligente: La IA puede analizar descripciones de requisitos en lenguaje natural y sugerir estructuras de datos, interfaces de usuario y lógicas de negocio iniciales, acelerando la fase de diseño y prototipado.
Optimización del Código Generado: Los algoritmos de IA pueden analizar el código generado por GeneXus y sugerir optimizaciones para mejorar el rendimiento, la seguridad o la eficiencia, llevando el código a un nuevo nivel de calidad.
Asistencia en la Depuración y el Mantenimiento: La IA puede identificar patrones en errores, sugerir posibles causas y proponer soluciones, reduciendo el tiempo de depuración. Además, puede ayudar a entender y mantener código legacy, incluso si no fue desarrollado por el programador actual.
Creación de Agentes Conversacionales y Bots: Integrar capacidades de IA permite a los desarrolladores de GeneXus incorporar asistentes virtuales y chatbots inteligentes directamente en sus aplicaciones, mejorando la experiencia del usuario y automatizando tareas repetitivas.
Análisis Predictivo e Inteligencia de Negocio: La IA puede potenciar las aplicaciones GeneXus con capacidades de análisis predictivo, permitiendo a las empresas tomar decisiones más informadas basándose en grandes volúmenes de datos.

En esencia, la IA permite a los desarrolladores de GeneXus enfocarse en la lógica de negocio y la innovación, mientras que las tareas repetitivas y de baja complejidad son manejadas por la inteligencia artificial.

La Nueva Habilidad: Operar la Retroexcavadora Digital

Retomando nuestra analogía: así como operar una retroexcavadora no es lo mismo que usar una pala – exige una capacitación diferente, una comprensión de la máquina y sus límites, y una mayor responsabilidad –, supervisar y dirigir herramientas de IA en el desarrollo de software también demanda un conjunto de habilidades evolucionado.

Los desarrolladores del futuro no solo necesitarán saber "programar", sino también:

Entender los principios de la IA: Comprender cómo funcionan estas herramientas, sus fortalezas y sus limitaciones.
Diseñar prompts efectivos: Saber cómo comunicarse con los agentes de IA para obtener el código o la solución deseada.
Evaluar y validar el código generado: La IA es una herramienta; la validación y el criterio humano son cruciales para asegurar la calidad, la seguridad y la adecuación del código.
Ser "arquitectos" de la solución: En lugar de solo "constructores", los desarrolladores se convierten en orquestadores de múltiples herramientas y agentes de IA.

La llegada de la IA al desarrollo de aplicaciones con GeneXus no es un reemplazo de los programadores, sino una amplificación de sus capacidades. Es una invitación a subirnos a la retroexcavadora digital y transformar la forma en que construimos el futuro del software. Aquellos que dominen estas nuevas "máquinas" serán los que lideren la próxima era de la innovación en desarrollo de aplicaciones.

De palas a retroexcavadoras: el nuevo paradigma del desarrollo con IA (by GhatGpt)

2025-06-12T15:24:00.002-03:00

En el mundo de la construcción, hubo un antes y un después con la aparición de la retroexcavadora. Antes, hacer una zanja requería a varios operarios con palas, trabajando durante horas bajo el sol. Luego llegó una máquina que no solo reemplazó a varios de ellos, sino que lo hizo más rápido, con mayor precisión y sin descanso.

Hoy, en el desarrollo de software, estamos viviendo una revolución similar.

De líneas de código a agentes inteligentes

Durante décadas, el desarrollo de aplicaciones con herramientas como GeneXus fue sinónimo de modelar, codificar, generar, probar y ajustar. Aunque GeneXus ya ofrecía una ventaja al abstraer muchos de estos pasos, la inteligencia artificial está empujando los límites aún más allá.

Los agentes de IA que escriben código, entienden requerimientos, generan pruebas automáticas, refactorizan programas o incluso diseñan interfaces, están transformando profundamente cómo se construyen las soluciones. Lo que antes requería un equipo entero durante semanas, ahora puede comenzar a resolverse en horas con un solo desarrollador apoyado por una batería de asistentes inteligentes.

La retroexcavadora digital ya está entre nosotros

Así como nadie en su sano juicio construiría una zanja a pala hoy en día si tiene acceso a maquinaria, tampoco tiene sentido enfrentar un desarrollo complejo sin aprovechar IA. No se trata de reemplazar al programador, sino de multiplicar su capacidad.

El desarrollador moderno debe convertirse en operador de esta nueva “retroexcavadora digital”: saber cómo usarla, cuándo intervenir manualmente, y cómo guiarla para obtener el mejor resultado.

¿Y qué pasa con GeneXus?

GeneXus, como plataforma low-code basada en modelos, está especialmente posicionada para aprovechar estos avances. Su enfoque declarativo, la separación clara entre modelo y código generado, y su integración con extensiones y asistentes, permite incorporar IA de forma natural.

Desde la generación de reglas y validaciones a partir de lenguaje natural, hasta la automatización de documentación o pruebas, la IA está empujando a GeneXus hacia un nuevo nivel de productividad.

Conclusión

No estamos ante una moda pasajera. Estamos ante una transformación de fondo. Así como la retroexcavadora cambió la forma de construir, los agentes de IA están cambiando la forma de desarrollar. Resistirse a adoptarlos es como aferrarse a la pala cuando la zanja puede estar lista antes del mediodía.

Pero esta nueva herramienta también exige algo más: capacitación. Así como para manejar una retroexcavadora se requiere un operador capacitado y no solo alguien con fuerza física, para supervisar y aprovechar al máximo los agentes de inteligencia artificial también se necesita un perfil técnico más sofisticado, capaz de entender el contexto, validar resultados y tomar decisiones estratégicas.

El futuro del desarrollo no es humano o máquina. Es humano con máquina. Y ese humano deberá estar mejor preparado que nunca.

Agente AI para automatizar el ciclo de vida de nuevas funcionalidades en una KB GeneXus

2025-05-19T12:52:00.003-03:00

Introducción

La adopción de agentes inteligentes en los procesos de desarrollo de software está revolucionando la forma en que las tareas repetitivas, complejas o de largo plazo se gestionan en proyectos reales. Imaginemos un escenario en el que un Agente AI se integra con nuestra KB GeneXus y, a lo largo de varias semanas o meses, realiza todo el proceso de evolución controlada de una funcionalidad crítica.

En este post, describo un caso práctico sobre cómo este agente podría manejar de manera autónoma la implementación, testeo, despliegue progresivo y, eventualmente, el retiro seguro de una funcionalidad en producción, utilizando Feature Flags y pruebas automáticas. El ejemplo me gusta porque permite unificar en un flujo el trabajo de varios asistentes (el que hace programas, el que hace deploy, el que prueba, etc0

Caso de uso: Automatización inteligente de una nueva funcionalidad

Escenario:
Queremos incorporar una nueva forma de calcular precios en un sistema core, pero sin arriesgar la estabilidad del entorno productivo. Usaremos una Feature Flag para controlar la activación progresiva y aseguraremos calidad a través de pruebas automáticas en producción.

Paso 1: Recepción de la especificación y generación de código

El agente AI recibe la especificación de la nueva funcionalidad (puede ser una descripción en lenguaje natural, un documento formal, o un issue en el backlog).
Traduce esa especificación a lógica GeneXus (procedimientos, reglas, paneles, etc.).
Integra el nuevo código en la KB, pero bajo el control de una Feature Flag (por ejemplo: Feature.NewPriceCalculation).

Paso 2: Diseño de casos de prueba automáticos

El agente diseña y programa varios casos de prueba que cubren las ramas críticas de la nueva lógica. Aqui es fundamental la intervención humana para chequear que las pruebas estén bien diseñadas. En el caso de programas que reciben parámetros y devuelven algún resultado, puede ser mas fácil probar que hacer las llamadas con ambos programas devuelve el mismo resultado. En caso que tenga algún cambio en el entorno (por ejemplo, grabar en la base de datos o grabar archivos) es necesario pruebas mas rigurosas.
Estas pruebas están diseñadas para ejecutarse automáticamente en los ambientes de QA, staging y producción.

Paso 3: Despliegue paulatino y monitoreo

La Feature Flag permite activar la nueva funcionalidad solo para un porcentaje controlado de usuarios o escenarios.
El agente monitorea diariamente los resultados de las pruebas automáticas y analiza logs, errores y feedback de usuarios.

Paso 4: Gestión de rollback y mejora continua

Si se detectan errores, el agente puede desactivar automáticamente la nueva lógica (gracias a la Feature Flag) y enviar un reporte de errores.
Luego, intenta corregir la funcionalidad en base al análisis de los incidentes, reprogramando el ciclo de pruebas y despliegue.
Este proceso se repite tantas veces como sea necesario hasta que las pruebas pasen de forma consistente.

Paso 5: Retiro del código viejo y limpieza de Feature Flags

Cuando la nueva funcionalidad ha estado activa durante 3 meses sin errores ni incidentes relevantes, el agente propone la eliminación del código anterior y la Feature Flag asociada.
Sugiere y/o ejecuta una refactorización para dejar la KB limpia y actualizada, eliminando deuda técnica.

Beneficios de este enfoque

Reducción de riesgo: El despliegue controlado y automatizado minimiza impactos negativos en producción.
Aceleración del delivery: Automatizar el ciclo completo acorta tiempos y reduce la intervención humana.
Mejora continua: El agente puede aprender de los errores y ajustar futuras implementaciones.
Mantenimiento evolutivo: La eliminación programada de código obsoleto evita la acumulación de complejidad innecesaria.

Conclusiones

La incorporación de agentes AI autónomos para gestionar el ciclo de vida de funcionalidades en GeneXus abre un nuevo paradigma en la productividad y calidad del desarrollo low-code. Automatizar desde la programación hasta la refactorización final permite que los equipos humanos se enfoquen en la innovación, dejando las tareas repetitivas y de control a la inteligencia artificial.

Por el momento, esto no es posible hacer en un cien por ciento, pero es algo que nos amos aproximando en forma acelerada. Cuando tengamos este tipo de ayudas, vamos a poder aumentar nuestra productividad, sustituyendo varias tareas repetitivas y que se prolongan en el tiempo.