TryCatch.tv

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.