La forma en que integras un LLM en tu aplicación depende fundamentalmente de quién tiene el control: ¿tu código decide el flujo y el LLM solo responde, o el LLM decide qué hacer a continuación? Esta distinción te lleva a dos patrones arquitectónicos muy diferentes. Patrón 1: LLM como Infraestructura Cuando la interacción es sencilla —envías un prompt, recibes una respuesta— el LLM es infraestructura. Es un servicio externo más, como un servicio de traducción o de geocoding. ...
Domain Instrumentation: Manteniendo los Casos de Uso Expresivos
La instrumentación es esencial en cualquier aplicación: logs para debugging, métricas para monitorización y trazas para entender el flujo de ejecución. Pero cuando esta instrumentación se mezcla directamente en los casos de uso, el código se vuelve difícil de leer, mantener y especialmente, de testear. En este post exploraré un patrón que habitualmente aplico: abstraer la instrumentación detrás de interfaces específicas de dominio, manteniendo los casos de uso expresivos y enfocados en la lógica de negocio. Además, me facilita posponer decisiones de infraestructura y mejora dramáticamente la calidad de los tests. ...
Eventos de Dominio vs Eventos de Integración
En arquitecturas event-driven, es útil distinguir entre eventos según su propósito: comunicación dentro del dominio versus integración entre bounded contexts. Esta distinción ayuda a manejar mejor el acoplamiento y la evolución del sistema. El Contexto Cuando todo se modela como “un evento”, aparecen tensiones. Un mismo mensaje intenta servir a dos propósitos diferentes: Comunicar hechos del dominio para coordinar reacciones dentro del bounded context. Exponer cambios de estado como contrato de integración con otros bounded contexts. Por ejemplo, cuando un producto se pone a la venta en un e-commerce: ...
Manteniendo la disciplina en AI-Assisted TDD
Después de varios meses experimentando con AI-assisted TDD, he ido refinando un flujo de trabajo que me permite combinar la disciplina estricta del TDD tradicional con las capacidades de los asistentes de IA. No se trata de acelerar el proceso a cualquier coste, sino de mantener la calidad y el control mientras el agente se encarga de las tareas más mecánicas. El desafío de no perder el norte Uno de los principales problemas al trabajar con asistentes de IA en TDD es mantener la disciplina del proceso. La tentación es real: dejar que el agente genere tanto tests como implementación de una sola vez parece eficiente. Pero al hacerlo, perdemos los beneficios fundamentales del TDD. Perdemos el diseño emergente guiado por tests, la implementación mínima necesaria, y esa confianza que te da el proceso cuando necesitas refactorizar. ...
Lista de Tests como guía en AI-Assisted TDD
La práctica de AI-assisted TDD (Test-Driven Development asistido por inteligencia artificial) combina los principios fundamentales del TDD con las capacidades de los modelos de lenguaje de gran escala (LLMs). En este enfoque, el desarrollador colabora con un asistente de IA durante el ciclo de desarrollo, aprovechando su capacidad para generar código y mantener el flujo iterativo característico del TDD. Uno de los principales retos al trabajar con asistentes de IA es mantener la coherencia y la dirección del proceso. En este contexto, resulta especialmente relevante recuperar un concepto introducido por Kent Beck hace más de dos décadas: la lista de tests como guía del desarrollo. ...