TryCatch.tv

En esta sesión 45 de Directorio Trycker retomamos el despliegue de la solución: revisamos Terraform, AWS Amplify, GitHub, variables y secretos, el pipeline, los ajustes de CSS, un backend en Go, un frontend en Angular y la preparación del entorno con Docker.

La IA puede escribir código, pero la mantenibilidad depende de decisiones conscientes: legibilidad, composición, límites, nombres claros y criterio técnico. En este capítulo revisamos 12 prácticas para que el software siga siendo fácil de entender, evolucionar y mantener.

La IA ya escribe código, propone diagramas y acelera pruebas. Julián Luna explica por qué la arquitectura de software sigue siendo decisiva: contexto, restricciones, gobernanza, acuerdos y criterio para diseñar sistemas que funcionen en el mundo real.

Julián Luna conversa con Jimy Dolores sobre frontend en la era de la IA: el reto de los juniors, Generative UI, modelos en el cliente, catálogos de componentes, A2UI y el criterio técnico para trabajar con agentes. Una charla directa sobre herramientas experimentales, aprendizaje y cambios del rol. Las proyecciones laborales y tecnológicas son opiniones de los participantes; las referencias a disponibilidad corresponden a lo que se comenta en la sesión.

¿Podemos construir y mantener software con agentes de IA sin generar código fuente tradicional?

Lo pusimos a prueba con un enfoque Agent-Native Development, utilizando una representación semántica en JSON (Semantic IR) que un agente puede generar, reparar y modificar, y una herramienta determinista desarrollada en Rust para verificarla y compilarla directamente a WebAssembly.

Durante la transmisión construimos cuatro experimentos: generación desde cero, reparación de errores, extensión de funcionalidades y mantenimiento de reglas de negocio. Los cuatro cumplieron sus criterios de éxito, incluyendo pruebas funcionales, regresiones y reproducibilidad binaria.

Y después llegó una comparación interesante. En un benchmark adicional frente a una implementación equivalente en Rust, nuestra ruta IR → WASM registró 49 veces menos tiempo en el ciclo inicial de verificación y compilación, y produjo un archivo WASM 44,9 % más pequeño, con las mismas pruebas funcionales aprobadas.

Estos resultados corresponden a una POC de alcance limitado y no incluyen el tiempo que necesita el agente para generar el programa. Todavía no demuestran una ventaja general frente a los lenguajes tradicionales, pero abren una línea de investigación sobre cómo diseñar representaciones que los agentes puedan construir y evolucionar de manera verificable.

El experimento ya no demuestra solamente que funciona: ahora también tenemos una primera evidencia cuantitativa para investigar su rendimiento.

¿Agile realmente está muriendo o simplemente seguimos utilizando Scrum como si desarrollar software no hubiera cambiado en los últimos años?

En esta sesión analizamos dos artículos que cuestionan la forma en que organizamos el desarrollo de software: The Death of Agile, Jira, and Confluence y Spec-Driven Development in Scrum and Kanban. A partir de ellos recorremos el origen de Agile, los problemas que buscaba resolver y cómo, en algunos equipos, las ceremonias, los tickets y los tableros terminaron adquiriendo más importancia que el valor que deberían generar.

También discutimos cómo cambia el desarrollo cuando incorporamos agentes de IA. Si ahora podemos producir código mucho más rápido, necesitamos prestar más atención a la claridad de los requisitos, el contexto, las decisiones y la verificación. Ahí aparece Spec-Driven Development, no como un reemplazo obligatorio de Scrum o Kanban, sino como una manera de integrar especificaciones vivas dentro de sus ciclos de trabajo.

Finalmente revisamos los niveles de especificación, por qué no todas las tareas necesitan el mismo contexto y cómo medir si realmente estamos mejorando mediante tiempos de entrega, retrabajo y aprendizaje continuo.

La conclusión no es que Scrum esté muerto ni que Jira haya dejado de servir. El desafío es recuperar los principios ágiles y adaptar nuestras prácticas a una realidad en la que personas y agentes participan en la construcción de software.

Pathfinder comenzó como una idea para resolver un problema de AWS re:Invent: entre miles de sesiones, ¿cómo identificar cuáles realmente nos ayudan a aprender lo que necesitamos para nuestros proyectos?

En esta sesión revisamos cómo evolucionó re Pathfinder hasta su versión v0.22.0, las decisiones que tomamos para construir su arquitectura y la integración de inteligencia artificial con Amazon Bedrock. Explicamos por qué no todo necesita resolverse con un LLM, cómo funciona el análisis de brechas de conocimiento, el ranking de sesiones y la separación entre los modos Demo y Live.

También recorremos el MVP: desde describir un proyecto y descubrir sus Knowledge Gaps hasta obtener un Learning Path, evaluar las sesiones mediante reflexiones, adaptar las recomendaciones y generar un Learning Report. Además, mostramos el Availability Heatmap para encontrar charlas disponibles y gestionar favoritos y reservas.

Finalmente probamos la integración Live con AWS Builder ID y revisamos algunas limitaciones que todavía deben validarse, especialmente la disponibilidad del catálogo y el procesamiento real con Bedrock. Cerramos mostrando cómo quedó organizado el proyecto, su arquitectura y el trabajo realizado para llegar a esta versión.

La idea central es que Pathfinder no busca simplemente recomendar charlas: busca convertir lo que estás construyendo o quieres aprender en una ruta de aprendizaje que evoluciona durante el evento.

Pathfinder dio un salto importante: dejó de trabajar únicamente con el journey de aprendizaje y empezó a interactuar con el evento real de AWS re:Invent.

En esta sesión mostramos el problema que apareció al intentar encontrar disponibilidad entre más de 2.000 sesiones y cómo terminó convirtiéndose en una nueva capacidad de Pathfinder. Probamos el login mediante AWS Builder ID, consumimos información real de AWS Events y construimos una vista que permite identificar rápidamente sesiones disponibles, con disponibilidad limitada o sin cupo, además de consultar agenda y favoritos.

Después volvemos al roadmap para cerrar otra parte importante del producto. Replanteamos el alcance de INI-005, separamos la observabilidad relacionada con IA hacia INI-006 y construimos el Learning Report, que compara las brechas iniciales con el conocimiento adquirido durante el evento y genera una ruta posterior con lo que todavía queda pendiente.

Finalmente construimos una primera demo pública del proyecto y recorremos Pathfinder de principio a fin: contexto del proyecto, Knowledge Profile, Knowledge Gaps, recomendaciones, Learning Path, reflexión, adaptación, Learning Report y la nueva Live Event Experience.

Al terminar la sesión, la base funcional del producto queda prácticamente cerrada y el siguiente gran bloque es claro: reemplazar la inteligencia local/prototipada por la implementación real con servicios de IA en AWS.

Pathfinder avanzó bastante fuera de transmisión, así que en esta sesión retomamos el proyecto para entender qué estaba realmente construido, qué seguía pendiente y cómo continuar hasta dejar una base sólida de backend y frontend.

Primero revisamos las iniciativas y los 11 Work Items ya completados: foundation del monorepo, integración con AWS Events y Builder ID, contratos de Knowledge/AI y las primeras piezas del journey. Al reconciliar el estado descubrimos además inconsistencias entre el código implementado y la evidencia del delivery, por lo que antes de seguir creamos un Work Item específico para corregir esa deuda.

Después continuamos con la experiencia de Pathfinder. Levantamos el frontend, recorremos el flujo de contexto del proyecto → perfil de conocimiento → knowledge gaps y construimos el siguiente paso: un Learning Path priorizado y reconciliado con la agenda. Durante la implementación aparece un problema real de compatibilidad entre Node Crypto y el navegador, que corregimos antes de continuar.

La sesión termina con la iniciativa 4 completada, 14 Work Items cerrados y una base funcional del API y frontend lista para el siguiente paso: conectar la IA y los servicios reales de AWS para completar el journey end-to-end.

00:00 Qué avanzó Pathfinder fuera de transmisión

01:30 Estado actual: iniciativas y Work Items

02:58 Foundation, AWS Events y autenticación

04:14 Knowledge, AI y Learning

06:12 11 Work Items y los dos grandes bloques del sistema

07:36 Cómo quedó organizado el repositorio

08:10 Autenticación con AWS Builder ID

09:10 Por qué planear antes aceleró el desarrollo

10:04 Qué vamos a construir en esta sesión

10:41 Retomando el proyecto y actualizando su estado

11:47 Dónde estamos dentro del roadmap

12:24 El trabajo offline dejó inconsistencias

14:46 Trazabilidad y verificaciones que no cuadraban

17:19 ¿Corregir el pasado o crear trabajo nuevo?

19:51 Creando un Work Item para reconciliar el proyecto

23:05 Refinando la corrección

23:50 Implementando el Work Item 12

25:39 Corrigiendo evidencia y reconciliando el lifecycle

28:07 Entramos a la iniciativa 4: Learning Path

29:19 Así está el frontend de Pathfinder

30:47 Project Context → Knowledge Profile → Knowledge Gaps

31:34 El siguiente paso: Learning Path recomendado

33:13 Materializando el Work Item 13

35:10 Decisiones de producto antes de implementar

37:23 Local-first, human in the loop y defaults del MVP

39:40 Implementando el Learning Path

42:30 Probando el flujo de autenticación local

45:35 Learning Path implementado

46:24 Aparece un bug real en el frontend

46:46 Node Crypto vs Web Crypto

47:42 Verificando el arreglo

48:47 Learning Path funcionando en la UI

50:56 Ahora toca reflexión y adaptación

52:04 Qué hará el Work Item 14

53:56 Cómo quedó la topología del sistema

55:58 Iniciativa 4 completada

56:44 Qué queda para cerrar Pathfinder

57:56 Estado final del roadmap

01:00:06 Base del API, frontend y flujo end-to-end

01:01:20 Qué falta: IA real, UI y despliegue

01:02:55 Conclusiones

Pathfinder ya tenía definido el problema y la experiencia que queríamos construir. En esta sesión damos el siguiente paso: descubrir qué componentes necesita realmente el sistema y convertir ese diseño en un roadmap ejecutable.

Partimos de las capacidades mínimas del MVP, identificamos qué responsabilidades necesita cada una y construimos progresivamente el mapa de componentes de Pathfinder. Durante el proceso aterrizamos la separación entre cliente, AWS Events, conocimiento, recomendaciones y Adaptive Learning Journey, además de tomar decisiones sobre TypeScript, DynamoDB, Amazon Bedrock, AgentCore, Strands Agents, Serverless Framework y CDK.

Con ese contexto llevamos la definición de negocio, producto y tecnología a Kaddo para estructurar el roadmap. El resultado fueron cinco grandes iniciativas: fundación técnica del monorepo, integración con AWS Events API, motor de conocimiento y recomendaciones, experiencia de learning path y reflexión, y cierre del ciclo con la experiencia de demo. A partir de ellas también quedaron identificados 16 candidatos a Work Items.

La idea central de la sesión es que antes de pedirle a un agente que escriba código necesitamos entender qué sistema estamos construyendo, qué responsabilidades existen y en qué orden tiene sentido construirlas.