Con respaldo
La fuente dice que una reserva necesita una fecha válida.
Criterio: Comprobar que la respuesta refleje ese requisito y cite la fuente correcta.
English Volver a proyectos
Caso de estudio · Autoría propia
De los requisitos a un diseño técnico revisable.
Diseñé y desarrollé un flujo de ingeniería asistido por IA que conecta requisitos, evidencia de código y propuestas de diseño, con validaciones automáticas y revisión humana.
José Antonio Gallegos Carvallo · Arquitectura, desarrollo y automatización
JavaScript
Node.js
PowerShell
MCP
GeneXus
Markdown
Open XML
El problema
Una propuesta necesita respaldo.
Analizar un cambio exige comprender el código existente, identificar los componentes afectados y conservar las validaciones vigentes. Generar texto no basta para comprobar que el diseño se apoya en el sistema consultado.
Mi contribución
Soy el autor del proyecto. Diseñé la arquitectura, desarrollé sus herramientas y definí el proceso de análisis, revisión y generación documental.
Simplifiqué el flujo a un agente, adapté la capa de validación e incorporé preparación de casos, estado de trabajo y registro de métricas por fase.
Un recorrido con puntos de control
La IA elabora la propuesta. Las herramientas comprueban reglas concretas. La persona revisa y decide.
- 01
Requisitos
Preparar el caso y estructurar el requerimiento.
- 02
Evidencia
Consultar el código en modo de solo lectura.
- 03
Diseño
Vincular cada propuesta con sus fragmentos de origen.
- 04
Validación
Verificar estructura, referencias y coherencia documental.
- 05
Revisión
Evaluar y aprobar el diseño con criterio humano.
- 06
Word
Generar y verificar el documento aprobado.
Decisiones de arquitectura
Agente de análisis
Requisitos, contexto y propuesta
Integración MCP
Consultas y lectura de fragmentos
KB GeneXus
Código existente · solo lectura
El agente conserva evidencia, estado del caso y propuesta en Markdown.
01 · Scripts de validación
Revisan el documento y sus referencias. Los hallazgos vuelven al análisis.
02 · Revisión humana
La persona evalúa el diseño y decide si lo aprueba.
03 · Generador Word
Convierte el Markdown aprobado mediante una plantilla y verifica la estructura.
Los validadores y el generador son herramientas locales; el diagrama no representa servicios desplegados ni una integración de escritura en la KB.
Explora cada componente
Agente
Organiza el análisis y prepara una propuesta basada en la información disponible.
Un agente, contexto continuo
Simplifiqué una arquitectura de varios agentes para reducir los traspasos de contexto y conservar una visión completa del caso.
Reglas comprobables en scripts
Las validaciones deterministas revisan propiedades concretas del documento y las referencias del pseudocódigo.
Evidencia separada del entregable
El documento mantiene una lectura clara y la evidencia conserva el respaldo técnico de cada propuesta.
Estado compacto por caso
Las tareas y decisiones vigentes permiten retomar el trabajo sin cargar todo el historial.
El desafío técnico
Simplificar sin perder trazabilidad
La primera arquitectura repartía el trabajo entre varios agentes. Cada traspaso requería volver a transmitir reglas, evidencia y decisiones. Mi decisión fue concentrar el análisis en un agente y mantener fuera del modelo las verificaciones que podían ejecutarse con scripts.
La simplificación exigía conservar los controles: fragmentos con líneas de origen, estado por caso, comprobación de referencias y revisión humana antes de generar el documento final.
El compromiso es que un agente conserva más responsabilidad sobre el análisis. Por eso la revisión humana y los controles documentales siguen siendo necesarios. La reducción de coordinación es una decisión de arquitectura; su impacto en tiempo y tokens aún debe medirse.
Ejemplo ficticio
Una reserva con una fecha válida
Una aplicación de reservas debe impedir la confirmación si falta una fecha válida. El análisis identifica la operación existente; el diseño propone el control y sus escenarios. Este ejemplo se creó para el portafolio.
1. Requisito
Impedir la confirmación de una reserva si falta la fecha o si es anterior a la fecha mínima permitida. Conservar la validación de disponibilidad antes de guardar.
2. Evidencia ficticia
101: Event 'Confirmar'
102: ValidarDisponibilidad()
103: GuardarReserva()
104: Endevent3. Propuesta de diseño
Event 'Confirmar' // referencia: 101
If &FechaReserva.IsEmpty() Or &FechaReserva < &FechaMinima // AGREGAR
Msg('Selecciona una fecha válida.') // AGREGAR
Return // AGREGAR
Endif // AGREGAR
ValidarDisponibilidad() // referencia: 102
GuardarReserva() // referencia: 103
Endevent // referencia: 104Pseudocódigo ilustrativo, creado desde cero. Las líneas AGREGAR son propuestas; las referencias señalan el fragmento ficticio conservado. No es código compilado en GeneXus.
4. Comprueba una cita
La propuesta atribuye GuardarReserva() a la línea 108. Cambia la referencia y observa el resultado.
HALLAZGO · Cita rechazada: la línea 108 no existe en la evidencia de demostración.
Este resultado se calcula en tu navegador sobre cuatro líneas ficticias. Ilustra la comprobación de una cita exacta; no ejecuta los validadores del proyecto ni acredita la corrección funcional del diseño.
Fecha válida
Resultado esperado: permitir la confirmación y conservar las validaciones existentes.
Fecha ausente
Resultado esperado: impedir la confirmación e indicar que se debe seleccionar una fecha.
Fecha fuera del rango permitido
Resultado esperado: impedir la confirmación y solicitar una fecha dentro del rango permitido.
Si una propuesta cita un fragmento sin respaldo en la evidencia, el verificador informa la inconsistencia. Superar ese control documental no sustituye la compilación ni las pruebas funcionales.
Entregable de demostración
Del requisito al documento
Dos páginas creadas desde cero: análisis con evidencia y escenarios, seguido del diseño con pseudocódigo y comprobación de una cita. Es una muestra HTML imprimible, independiente de la plantilla empresarial.
Abrir el documento completo para leerlo o guardarlo como PDF desde Imprimir.
Evaluación · escenarios de ejemplo
Qué comprobar en una respuesta
Tres casos ficticios para diseñar una evaluación de respuestas sustentadas. Son criterios propuestos; no representan resultados medidos de una evaluación del modelo.
Sin respaldo
La respuesta afirma un precio que no aparece en las fuentes.
Criterio: Detectar que la afirmación no está sustentada y solicitar una corrección.
Fuera de alcance
Se pregunta por un dato para el que no hay información disponible.
Criterio: Comprobar que el asistente reconozca el límite sin inventar una respuesta.
Resultados y aprendizajes
- Piloto completado de principio a fin, con revisión humana y documento Word generado.
- Herramientas para preparar casos, verificar documentos y registrar métricas por fase.
- Arquitectura simplificada con evidencia explícita para sustentar las propuestas.
Aprendí a convertir reglas comprobables en herramientas y a definir dónde interviene el criterio humano. El ahorro de tiempo y tokens requiere una evaluación comparativa; no se presenta como un resultado medido.
Qué está comprobado y qué queda por evaluar
- El piloto acredita el recorrido documental y la generación de Word; no demuestra por sí solo la corrección del software diseñado.
- La demostración interactiva comprueba una cita literal contra datos ficticios. Su alcance es menor que el de los validadores del proyecto.
- La compilación y las pruebas funcionales deben ejecutarse sobre cada implementación. La revisión visual de la paginación es un control adicional a la estructura del Word.
- Queda por medir tiempo, tokens y retrabajo en casos comparables, y evaluar el proceso nuevo de pseudocódigo en el siguiente caso.