TryCatch.tv

¿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.

Un LLM puede razonar sobre información, pero cuando necesita buscar, leer, navegar o interactuar con una página web, necesita herramientas que le permitan salir de su contexto. En esta sesión probamos TinyFish, una plataforma enfocada en darle esas capacidades web a aplicaciones y agentes de IA.

Primero entendemos las diferencias entre Search, Fetch, Agent y Browser, cuándo tiene sentido utilizar cada uno y cómo cambia el nivel de autonomía cuando integramos TinyFish mediante MCP. Después hacemos el onboarding desde cero, conectamos TinyFish con un agente y ejecutamos pruebas reales de búsqueda y extracción.

La prueba termina siendo especialmente interesante con el sitio de Reebok: Fetch encuentra rápidamente el límite del contenido estático, así que pasamos a un Web Agent para intentar navegar las 18 páginas del outlet. La ejecución tarda cerca de 45 minutos, consume alrededor de 57 pasos y consigue extraer 174 productos únicos, dejando claras tanto las capacidades como las limitaciones y el trade-off entre autonomía, tiempo y costo.

La conclusión no es que todo deba resolverse con un Web Agent. Search, Fetch, Agent y Browser tienen costos y niveles de control diferentes; la decisión correcta depende del problema que realmente necesitamos resolver.

Dar contexto a un agente mejora mucho la calidad de lo que construye, pero aparece otro problema cuando termina: ¿cómo sabemos que realmente hizo lo que le pedimos?

En esta sesión recorremos Kaddo Lifecycle v2, la evolución del ciclo de desarrollo de Kaddo para acompañar un cambio desde la intención inicial hasta su verificación. Vemos cómo un Work Item pasa por refinement, planning e Implementation Handoff antes de llegar al agente, y cómo el nivel de contexto se ajusta proporcionalmente al alcance de la tarea.

Después de la implementación, el ciclo continúa con Implementation Evidence, Verification, knowledge drift y Learning. La idea es que “terminé” deje de ser suficiente: queremos saber qué cambió, qué validaciones se ejecutaron, si la implementación se desvió del plan y qué nuevo conocimiento debería regresar al proyecto.

La idea central es que el desarrollo asistido por IA no debería terminar cuando el agente genera código; debería terminar cuando podemos explicar, verificar y aprender de lo que hizo.

AWS re:Invent tiene cientos de sesiones, workshops y actividades. El problema no es encontrar contenido, sino decidir qué vale la pena ver según lo que estás construyendo y el conocimiento que todavía te hace falta. De ahí nace re:Invent Pathfinder, un proyecto para convertir el catálogo del evento en una ruta de aprendizaje personalizada. re_invent-pathfinder-contexto-d…

En esta sesión recorremos el contexto completo del proyecto: cómo detectar knowledge gaps, generar recomendaciones explicables, adaptar la ruta a medida que la persona aprende y organizar la experiencia antes, durante y después del evento. También revisamos la arquitectura propuesta con AWS Events API, API Gateway, Lambda, Amazon Bedrock, CloudWatch y Amplify, evitando agregar infraestructura que todavía no necesitamos. re_invent-pathfinder-contexto-d…

Finalmente aterrizamos los milestones de construcción: primero detectar brechas y recomendar sesiones, después incorporar agenda y conflictos, y finalmente construir el ciclo adaptativo que recalcula qué conviene hacer a continuación. El proyecto será open source y se irá construyendo con la comunidad. re_invent-pathfinder-contexto-d… re_invent-pathfinder-contexto-d…

La idea central es simple: Pathfinder no busca decirte qué sesiones son populares, sino entender qué estás construyendo para ayudarte a descubrir qué deberías aprender.

En esta sesión hablamos de varias cosas que están cambiando la forma en que desarrollamos software: cómo Kaddo está evolucionando y empezando a usarse en proyectos reales, cómo gestionar conocimiento entre sistemas, y qué pasa cuando dejamos de trabajar con un solo agente para empezar a ejecutar varias tareas en paralelo.

También hablamos de Git worktrees, de usar modelos diferentes para planeación y ejecución, y de un problema que empieza a hacerse evidente con los agentes: la IA puede construir más rápido de lo que nosotros podemos revisar, entender y cambiar de contexto.

La conversación termina llevándonos a carrera y crecimiento profesional: cómo diferenciarse cuando todos están aprendiendo lo mismo, por qué perseguir cada nueva herramienta puede terminar agotándonos, qué pesa cuando queremos pasar de senior a arquitecto, y por qué liderazgo, comunicación, criterio e impacto empiezan a importar más a medida que avanzamos.

La idea que atraviesa toda la sesión es sencilla: no se trata de aprender todo lo nuevo que aparece, sino de construir una base sólida y saber hacia dónde queremos crecer.

En la sesión anterior definimos la arquitectura de Tryckers. En esta damos el siguiente paso: convertir esas decisiones en infraestructura desplegable y reproducible usando Terraform.

Partimos de los servicios que ya habíamos seleccionado para AWS —Amplify, EC2, RDS PostgreSQL, ECR, S3, IAM y SSM— y construimos el flujo completo: definición del Work Item, generación de los archivos .tf, validación, terraform plan, revisión del dimensionamiento y finalmente terraform apply.

Durante el ejercicio también usamos Kaddo para mantener trazabilidad entre lo que queríamos construir y los cambios realizados. Al final verificamos directamente en AWS que los recursos fueron creados y encontramos un pendiente real: Amplify quedó aprovisionado, pero todavía falta vincular correctamente el repositorio que deberá desplegar.

La idea central de la sesión es sencilla: la arquitectura deja de ser solamente un dibujo cuando podemos reproducirla.

Construimos exactamente la misma aplicación dos veces con IA para comparar dos formas distintas de trabajar: primero con Vibe Coding, entregándole directamente la intención al agente, y después usando Specs de Kiro, pasando por requirements.md, design.md y tasks.md antes de implementar.

El experimento fue Roomly, una pequeña aplicación para reservar salas. La versión Vibe llegó a una primera versión funcional en unos cinco minutos y resolvió correctamente varios casos, pero permitió crear una reserva en una fecha pasada.

Con Specs, Kiro generó requisitos, diseño, arquitectura, tareas y una implementación más estructurada. También apareció el otro lado de la comparación: el proceso tomó bastante más tiempo y consumió muchos más créditos. Al final, la versión basada en Specs sí bloqueó correctamente la reserva en una fecha pasada y cumplió las reglas que probamos.

La conclusión no es que un enfoque sea siempre mejor: Vibe Coding puede llevarte mucho más rápido al primer resultado; Specs agrega estructura, trazabilidad y claridad, pero también tiene un costo.

SOLID suele enseñarse como cinco principios que todo buen proyecto debería aplicar, pero seguirlos sin entender el contexto también puede terminar haciendo el código más difícil de mantener.

En esta sesión del capítulo 7 de Código Sostenible recorremos responsabilidad única, Open-Closed, sustitución de Liskov, segregación de interfaces e inversión de dependencias, pero desde una mirada práctica: qué problema resuelve cada principio, cuándo aporta valor y cuándo podemos estar agregando complejidad innecesaria.

También hablamos de abstracciones, composición frente a herencia, inyección de dependencias y de por qué el criterio y la proporción siguen siendo más importantes que aplicar SOLID como una checklist.

La idea central: SOLID no debería hacer que tu código parezca más sofisticado; debería hacer que cambiarlo sea menos peligroso.

¿Darle más contexto a un agente de IA siempre produce mejores resultados? No necesariamente.

En esta sesión hablamos de cómo el conocimiento que necesita un agente debería crecer según el alcance de la tarea. No requiere lo mismo cambiar el texto de un botón que modificar un flujo completo de registro, donde ya entran APIs, base de datos, reglas de producto y otras partes del sistema.

También vemos qué pasa cuando nos vamos al otro extremo y cargamos demasiado contexto, cómo encontrar ese conocimiento mínimo suficiente, qué cambia cuando crecen los equipos y cómo enrutar conocimiento entre módulos y repositorios sin obligar al agente a entender todo el sistema cada vez.Cerramos con un framework práctico para pensar el alcance, componentes, decisiones, riesgos, límites y criterios de aceptación antes de dejar que un agente empiece a construir.

En esta sesión dejamos la escaleta a un lado y respondimos preguntas de la comunidad sobre IA, desarrollo de software, aprendizaje, carrera, mercado laboral, proyectos y emprendimiento.

La conversación pasó por cómo podría cambiar el código en un mundo cada vez más agent-native, qué aprovechar realmente de la universidad, cómo usar roadmaps sin intentar aprenderlo todo, qué está pidiendo hoy el mercado y por qué algunas vacantes empiezan a mezclar desarrollo, producto, negocio y comunicación en un mismo rol.

También hablamos de proyectos personales, habilidades para vender lo que construimos, preparación para entrevistas, búsqueda de trabajo y hasta herramientas que ya están usando agentes para automatizar postulaciones.

La idea que terminó conectando casi toda la sesión fue sencilla: las herramientas cambian muy rápido, pero criterio, fundamentos, comunicación y capacidad para resolver problemas siguen siendo cada vez más importantes.