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.

Retomamos Tryckers, el directorio open source de la comunidad, para revisar en qué estado está el MVP y definir qué necesitamos para llevarlo a producción.

Durante la sesión evaluamos distintas opciones de infraestructura en AWS para el frontend, backend y base de datos, teniendo en cuenta algo clave: queremos aprender haciendo, pero sin sobrearquitectar ni gastar créditos innecesariamente.

Comparamos alternativas como Amplify, S3 + CloudFront, EC2 + Docker, ECS/Fargate y RDS PostgreSQL, y terminamos definiendo una primera arquitectura que pueda evolucionar con el proyecto.

La idea central: no se trata de usar más servicios de AWS, sino de escoger los suficientes para aprender, desplegar y poder evolucionar después.

En este episodio seguimos con la lectura de Código Sostenible, capítulo 6: Cohesión y acoplamiento.

Hablamos de por qué estos dos conceptos funcionan como una brújula para tomar mejores decisiones de diseño: mantener juntas las cosas que realmente pertenecen juntas y reducir las dependencias innecesarias entre componentes.

También recorremos ortogonalidad, dependencias cíclicas, inyección de dependencias, arquitectura hexagonal, Ley de Demeter, Tell, don’t ask y connascence para entender una pregunta fundamental: si cambio una parte del sistema, ¿cuántas otras estoy obligando a cambiar conmigo?

La idea central: el código sostenible no elimina las dependencias; evita que cada dependencia termine convirtiéndose en una cadena difícil de romper.

Durante casi un mes estuve mucho menos presente en las transmisiones de TryCatch.tv, pero fue porque la comunidad salió de la pantalla.

Pasé por AWS Summit Bogotá, Latam Architecture Day, CaribeDev Barranquilla, Containers Day en República Dominicana, DevOps Day Lima y AWS Community Day Bolivia. En este episodio cuento cómo fue vivir esos eventos, viajar entre ciudades y países, participar como speaker y encontrarme cara a cara con personas que durante años solo había conocido por un username.

Más allá de las charlas, quedaron conversaciones, comunidad, cansancio, aprendizajes y una confirmación importante: crear contenido y compartir conocimiento durante años termina abriendo puertas que muchas veces uno ni siquiera sabía que existían.

La idea central: los eventos no valen solamente por lo que ocurre en el escenario, sino por las personas y conexiones que aparecen alrededor.

En este episodio hablamos de trade-offs reales en Google Cloud a partir de tres decisiones muy comunes: Cloud SQL vs Firestore, Cloud Run vs GKE y HTTP vs Pub/Sub.

La idea no es decidir qué servicio es “mejor”, sino entender qué problema estamos resolviendo, qué atributo de calidad importa, qué complejidad introducimos y qué costo operativo estamos dispuestos a asumir.

También hablamos de escala futura, sobrearquitectura, costo humano de la infraestructura, acoplamiento, asincronía, observabilidad e idempotencia.

La conclusión: una buena decisión de arquitectura no elige la tecnología más poderosa, sino la que mejor encaja con el contexto actual y puede evolucionar cuando ese contexto cambie.

En este episodio hablamos sobre lo ocurrido durante el terremoto del 10 de agosto de 2026 en Colombia, partiendo de la experiencia personal, los reportes que se conocían durante la transmisión y los testimonios de personas en distintas ciudades.

Más allá de las cifras, la conversación se centra en preparación, infraestructura, comunicaciones, sistemas de alerta, resiliencia y uso de la tecnología durante una emergencia.

También revisamos cómo herramientas digitales pueden ayudar a ubicar personas, compartir información y coordinar respuestas, pero con una idea clave: en una emergencia, la velocidad de la información nunca debería estar por encima de su confiabilidad.

La reflexión central: no podemos decidir cuándo ocurre un terremoto, pero sí podemos decidir qué tan preparados estamos cuando sucede.

En este episodio seguimos con la lectura de Código Sostenible, capítulo 5: Principio de menor sorpresa.

Hablamos de por qué el código debería comportarse siempre de la forma en que otra persona espera, sin efectos secundarios ocultos, retornos inconsistentes ni abstracciones que obliguen al equipo a desconfiar.

También analizamos métodos que mienten sobre lo que hacen, comentarios que intentan justificar diseños confusos, monkey patching y la diferencia entre ocultar secretos de implementación y esconder consecuencias inesperadas.

La idea central: el buen diseño puede ocultar cómo funciona internamente, pero nunca debería ocultar qué provoca.

En este episodio configuramos Kaddo desde cero en el Directorio Trycker, un proyecto open source existente, pre-IA y compuesto por varios repositorios.

Vemos cómo definir un repositorio core, mapear frontend y backend como módulos, reconstruir el conocimiento del sistema y preparar contexto para que los agentes no trabajen de forma aislada.

También desarrollamos un work item de extremo a extremo para agregar la fecha de cumpleaños al perfil, cubriendo producto, privacidad, datos, backend, contrato, frontend, pruebas y actualización del conocimiento.

La idea central: la IA puede leer todos tus repositorios y aun así no entender el producto; el contexto es lo que convierte archivos separados en un sistema.

En este episodio seguimos con la lectura de Código Sostenible, capítulo 4: Técnicas para elegir nombres.

Hablamos de por qué nombrar bien no es un detalle estético, sino una decisión de diseño que afecta cómo el equipo entiende, mantiene y evoluciona el software.

Vimos heurísticas para elegir mejores nombres: que sean fáciles de pronunciar, que no incluyan ruido técnico innecesario, que eviten comodines como Helper, Manager o Utils, que formen frases naturales, que respeten el lenguaje del negocio y que se apoyen en el contexto correcto.

La idea central: un buen nombre reduce la necesidad de explicar; un mal nombre obliga al equipo a adivinar.

En este episodio analizamos el caso de Holberton y la discusión alrededor de programas de formación en tecnología que prometen estudiar ahora y pagar después.

El objetivo no es hacer un linchamiento, sino entender el problema de fondo: qué pasa cuando la promesa de entrar a tech se mezcla con deuda, expectativas laborales, pagarés, contratos difíciles de entender y publicidad agresiva.

También hablamos de la responsabilidad de las instituciones que venden educación, la responsabilidad de quienes firman este tipo de acuerdos y la realidad del mercado tech: aprender programación puede abrir oportunidades, pero no garantiza empleo automático.

La idea central: la educación tech puede cambiar vidas, pero nadie debería hipotecar su futuro por una promesa mal explicada.