De un Pattern a un Skill: cuatro años de evolución en la productividad con GeneXus
En 2022 publiqué Entity Provider Pattern. La idea era sencilla de explicar, pero bastante más difícil de implementar: dada una entidad representada por una Transaction GeneXus, generar una capa uniforme para consultar y modificar sus datos.
El objetivo era evitar que cada desarrollador resolviera una y otra vez las mismas operaciones:
Obtener todos los registros o una lista paginada.
Consultar por clave o por otras condiciones.
Verificar si una entidad existe.
Insertar, modificar y eliminar mediante el Business Component.
Publicar esas operaciones mediante un objeto API.
Mantener una interfaz similar tanto para el acceso local como para el remoto.
El ejemplo del artículo utilizaba una Transaction Customer y proponía generar Data Providers, Data Selectors, Procedures, SDT y un objeto API con operaciones como GetAll, GetByKey, Exists, Insert, Update y Delete.
La intención no era solamente ahorrar algunas líneas de código. Buscaba definir una forma consistente de acceder a las entidades de una aplicación y evitar que cada API terminara teniendo nombres, contratos, filtros y respuestas diferentes.
Lo que implicaba construir esa idea en 2022
Para convertir aquella especificación en una herramienta reutilizable había que desarrollar un Pattern o una extensión para GeneXus.
Eso implicaba, entre otras cosas:
Leer la estructura y los metadatos de una Transaction.
Diseñar una instancia configurable del Pattern.
Programar las reglas de generación.
Crear y mantener templates para cada tipo de objeto.
Resolver claves simples y compuestas, tipos de datos y niveles de la Transaction.
Definir convenciones de nombres, parámetros y mensajes de error.
Integrarse con el IDE de GeneXus.
Mantener compatibilidad con nuevas versiones y upgrades.
Probar que reaplicar el Pattern no destruyera cambios realizados por los desarrolladores.
Documentar, instalar y distribuir la herramienta.
No era imposible, pero sí era un producto de software en sí mismo. La idea podía escribirse en unas páginas; lograr que funcionara de manera general, segura y mantenible requería semanas o meses de desarrollo.
La necesidad era real y aparecieron soluciones de producto
La generación de servicios a partir de una entidad no era una inquietud aislada. Distintas herramientas del ecosistema GeneXus implementaron soluciones para el mismo problema.
K2BTools ya contaba desde antes con K2BEntityServices, un Pattern orientado a generar las interfaces básicas para acceder y administrar una entidad. Más adelante, en 2024, presentó Service Builder, una extensión específica para simplificar el desarrollo y mantenimiento de servicios de consulta y actualización de datos. A partir de una definición de servicios puede generar SDT, Procedures y su publicación mediante un objeto API. Su asistente propone operaciones como GetAll, consultas por atributos, Insert, Update y Delete.
WorkWithPlus incorporó en mayo de 2026 su Services Generator. A partir de una Transaction genera el objeto API, los Procedures y los SDT necesarios para operaciones de consulta, alta, modificación y baja. También contempla listados paginados, ordenamiento, códigos HTTP, control de concurrencia e integración con GAM.
Estas implementaciones confirman que el problema estaba bien planteado. También muestran el esfuerzo necesario para transformar una idea de generación en una herramienta profesional, configurable y soportada a lo largo del tiempo.
En 2026, la misma idea puede expresarse como un Skill
Cuatro años después, escribí un Skill llamado genexus-crud-api-generator. Su encabezado es éste:
---
name: genexus-crud-api-generator
description: Genera una capa CRUD y un objeto API GeneXus a partir de una Transaction, con consultas por clave, existencia y listados filtrados y paginados. Usar cuando se soliciten servicios de alta, baja, modificación o consulta para una entidad GeneXus.
---El resto del Skill describe el método de trabajo que debe seguir el agente:
Inspeccionar la Transaction y las convenciones de la KB.
Identificar claves, atributos, módulos y objetos equivalentes.
Preguntar qué datos pueden exponerse, qué filtros se necesitan y si la baja es física o lógica.
Acordar autenticación, autorización y ambiente de pruebas.
Definir los SDT de entrada, salida, filtros, paginación y errores.
Generar los Procedures CRUD, las consultas y el objeto API.
Crear pruebas de Procedures y, cuando sea posible, pruebas de integración HTTP.
Mostrar los objetos que se crearán y pedir aprobación antes de modificar la KB.
Importar, validar e informar los resultados sin ejecutar un Build o una reorganización no autorizados.
Este Skill puede redactarse en unos diez minutos. No contiene el código de un generador tradicional: contiene el conocimiento, las decisiones, las restricciones y los criterios de aceptación necesarios para que un agente genere la solución adecuada para cada KB.
Ahí está, para mí, el verdadero cambio de productividad.
De programar el generador a describir cómo debe trabajar
Antes, para reutilizar una solución, teníamos que convertirla en código: desarrollar un Pattern, una extensión, un asistente, sus templates y su interfaz de configuración.
Ahora podemos expresar buena parte de ese conocimiento en lenguaje natural estructurado. El agente puede inspeccionar el contexto real de la KB, encontrar sus convenciones y adaptar la solución.
| Aspecto | Pattern o generador tradicional | Skill ejecutado por un agente |
|---|---|---|
| Forma de expresar la solución | Código, templates y propiedades | Instrucciones, decisiones y criterios de aceptación |
| Tiempo para crear una primera versión | Semanas o meses | Minutos u horas |
| Adaptación a cada KB | Propiedades previstas por el desarrollador del Pattern | Inspección del contexto y preguntas al usuario |
| Cambio de una regla | Modificar, compilar, probar y distribuir el generador | Editar el Skill |
| Convenciones existentes | Deben programarse explícitamente | El agente puede descubrirlas en la KB |
| Casos no previstos | Requieren ampliar el producto | El agente puede proponer una adaptación |
| Pruebas y validaciones | Deben incorporarse al generador | Pueden formar parte del flujo obligatorio del Skill |
| Repetibilidad | Muy alta y determinista | Depende del modelo, el contexto y las herramientas disponibles |
El salto de productividad no consiste únicamente en generar más código. Consiste en bajar drásticamente el costo de convertir experiencia en una capacidad reutilizable.
Un desarrollador con conocimiento del problema puede escribir un Skill que indique no exponer atributos sensibles, respetar las reglas de la Transaction, limitar el tamaño de página, validar rangos de fechas, seguir la política de baja lógica de la KB y pedir autorización antes de modificar datos. Todo eso pasa a formar parte del proceso y puede reutilizarse en la próxima entidad o en otra KB.
Un Skill no reemplaza automáticamente a un Pattern
Sería exagerado concluir que los Skills vuelven innecesarios a los Patterns o a productos como K2BTools y WorkWithPlus.
Un Pattern ofrece una generación determinista, una interfaz de configuración conocida, soporte de producto y resultados repetibles para cientos de objetos. Es una excelente opción cuando el problema está estabilizado y se necesita aplicar la misma solución de forma masiva.
Un Skill es más flexible y mucho más barato de crear o modificar, pero su ejecución depende del agente, del acceso que tenga a la KB y de la calidad de las instrucciones. Por eso necesita controles: revisión de los cambios, aprobación previa, compilación, pruebas y validación de los contratos publicados.
No son enfoques excluyentes. Un Skill puede servir para experimentar y refinar rápidamente una metodología. Cuando esa metodología se estabiliza y requiere repetibilidad absoluta, puede transformarse en un Pattern o incorporarse a una herramienta de producto. También puede ocurrir lo contrario: un Skill puede utilizar y configurar un Pattern existente, agregando decisiones específicas de la organización.
El nuevo nivel de abstracción
GeneXus siempre buscó elevar el nivel de abstracción: describir el modelo y generar el software necesario para una tecnología determinada. Los Patterns agregaron otro nivel, permitiendo describir soluciones repetitivas sobre ese modelo.
Los Skills agregan una capa diferente: permiten describir cómo debe razonar y trabajar un agente sobre la KB.
Podemos pasar de esta cadena:
Modelo GeneXus → Pattern programado → objetos generados
a una alternativa más flexible:
Modelo GeneXus + Skill + contexto de la KB → objetos generados y validados
En 2022 escribí una especificación y pensé que, para hacerla reutilizable, debía desarrollar un Pattern. En 2026, esa misma especificación puede convertirse en un Skill en unos diez minutos y comenzar a utilizarse inmediatamente con un agente conectado a la KB.
No significa que el trabajo desaparezca. El trabajo cambia de lugar: hay menos esfuerzo dedicado a programar la mecánica del generador y más esfuerzo dedicado a explicitar decisiones, restricciones, seguridad, pruebas y criterios de aceptación.
Y eso puede ser uno de los avances de productividad más importantes de esta nueva etapa: transformar rápidamente la experiencia de un desarrollador en una herramienta que otros desarrolladores —y otros agentes— puedan reutilizar.
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.