Artículos

Hace casi un año escribí sobre cómo mantener la disciplina en AI-assisted TDD. En aquel flujo dirigía al agente en tiempo real, en la misma sesión en la que escribía el código: elegía cada test, corregía el diseño sobre la marcha y aprobaba cada commit. Ese flujo fue cambiando de forma gradual. Los modelos mejoraban de una versión a otra, y las convenciones del repositorio se iban afinando con cada corrección que dejaba por escrito. Con ambas cosas, cada vez tenía menos sentido dirigir la implementación paso a paso y más sentido poner el peso en la spec: dejar claro qué construir y cómo, y delegar el resto. Llegó un punto en que la implementación iba en piloto automático hasta quedar lista para revisión. ...

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

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

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

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

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