TryCatch.tv

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ón01:30 Estado actual: iniciativas y Work Items02:58 Foundation, AWS Events y autenticación04:14 Knowledge, AI y Learning06:12 11 Work Items y los dos grandes bloques del sistema07:36 Cómo quedó organizado el repositorio08:10 Autenticación con AWS Builder ID09:10 Por qué planear antes aceleró el desarrollo10:04 Qué vamos a construir en esta sesión10:41 Retomando el proyecto y actualizando su estado11:47 Dónde estamos dentro del roadmap12:24 El trabajo offline dejó inconsistencias14:46 Trazabilidad y verificaciones que no cuadraban17:19 ¿Corregir el pasado o crear trabajo nuevo?19:51 Creando un Work Item para reconciliar el proyecto23:05 Refinando la corrección23:50 Implementando el Work Item 1225:39 Corrigiendo evidencia y reconciliando el lifecycle28:07 Entramos a la iniciativa 4: Learning Path29:19 Así está el frontend de Pathfinder30:47 Project Context → Knowledge Profile → Knowledge Gaps31:34 El siguiente paso: Learning Path recomendado33:13 Materializando el Work Item 1335:10 Decisiones de producto antes de implementar37:23 Local-first, human in the loop y defaults del MVP39:40 Implementando el Learning Path42:30 Probando el flujo de autenticación local45:35 Learning Path implementado46:24 Aparece un bug real en el frontend46:46 Node Crypto vs Web Crypto47:42 Verificando el arreglo48:47 Learning Path funcionando en la UI50:56 Ahora toca reflexión y adaptación52:04 Qué hará el Work Item 1453:56 Cómo quedó la topología del sistema55:58 Iniciativa 4 completada56:44 Qué queda para cerrar Pathfinder57:56 Estado final del roadmap01:00:06 Base del API, frontend y flujo end-to-end01:01:20 Qué falta: IA real, UI y despliegue01: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.

¿Cómo se ve Kiro cuando deja de ser una herramienta para hacer demos y empieza a utilizarse dentro de equipos, procesos y sistemas reales?En este conversatorio hablamos con profesionales que ya están usando Kiro en escenarios de infraestructura, desarrollo, automatización de despliegues y adopción empresarial. Revisamos cómo trabajan con agentes especializados, steering, skills, MCP, Spec-Driven Development y pipelines, pero también los problemas que aparecen cuando estas prácticas empiezan a escalar.La conversación entra en temas que normalmente no aparecen en una demo: costos por exceso de contexto, resistencia al cambio, sistemas legacy, deuda técnica, confianza en el código generado, gobierno, métricas y ROI. También discutimos cómo cambia el rol del desarrollador cuando escribir código deja de ser el principal cuello de botella.El resultado es una mirada bastante práctica a lo que significa trabajar con IA en el mundo real: menos foco en generar código y más en arquitectura, contexto, validación, orquestación y criterio.