Devex on Patrones — Exeal

API Lite: un segundo host con infraestructura en memoria

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Un frontend (o una suite de Playwright) que depende del backend real para poder trabajar arrastra todos los problemas del backend real: hay que levantar Postgres, colas, un proveedor OIDC, a veces Hangfire o un bucket S3, y el estado se acumula entre ejecuciones. Para tocar UI esto es fricción pura — nadie necesita persistencia real para ver si un botón pinta bien. Para tests de extremo a extremo es peor: los tests dejan de ser deterministas (dependen de datos que quedaron de ejecuciones anteriores, de latencia real contra servicios externos, de que Postgres/Hangfire arranquen a tiempo) y se vuelven lentos de levantar y frágiles de mantener.

CLAUDE.md como mapa de contexto para el agente

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Es tentador convertir CLAUDE.md en el sitio donde se vuelca todo lo que un agente “debería saber”: la arquitectura completa, las reglas de negocio, el contrato de la API, el histórico de decisiones. El resultado es un archivo que crece sin límite y que se desincroniza solo, porque cada cambio real (una entidad nueva, un endpoint, una regla de dominio) obliga a acordarse de tocar también el CLAUDE.md a mano — y nadie se acuerda siempre. Un CLAUDE.md largo tampoco resuelve nada mejor que uno corto: un agente no lee mejor 300 líneas que 40, y la información específica (qué endpoint hace qué, qué campo significa qué) cambia con frecuencia suficiente para que documentarla ahí sea garantía de que quede obsoleta.

Comandos de mantenimiento en apps .NET

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Tarde o temprano toda API con un composition root no trivial (DI container, configuración por entorno, logging estructurado) necesita ejecutar una tarea de mantenimiento puntual: un backfill, recalcular una agregación, purgar registros huérfanos, deduplicar datos tras un bug. Esto no es solo leer o escribir filas: a menudo hay que invocar los mismos servicios de dominio que la app usa para garantizar sus invariantes (un agregador, un motor de fusión de duplicados, un validador), en vez de reimplementar su lógica en un script.

Fake OIDC: proveedor de autenticación de mentira

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Una API que autentica con OIDC no se puede levantar en local ni ejercitar en tests de aceptación sin resolver antes “¿contra qué me autentico?”. Apuntar a un proveedor OIDC real de verdad (Zitadel, Auth0, lo que sea) para desarrollo local o para CI trae credenciales que gestionar, usuarios de prueba que crear y mantener a mano en una consola externa, y dependencia de red contra un servicio que no controlas. La alternativa fácil — saltarse la autenticación en local con un middleware que la desactiva, o mockear el token a mano — hace que ni el pipeline de auth real ni el contrato HTTP real se ejerciten nunca fuera de producción, así que un bug de autenticación no aparece hasta que ya está desplegado.

One build, many deploys para imágenes de frontend

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Un frontend construido con Vite lee sus variables de entorno (VITE_*) en tiempo de build: Vite las sustituye literalmente en el bundle. Eso significa que la URL de la API, el authority OIDC o el DSN de Sentry quedan “planchados” dentro del JavaScript compilado. Si quieres desplegar la misma app en staging y en production con distinta configuración, te ves obligado a construir una imagen por entorno — un pipeline de CI que hace build, build y build otra vez, cada uno con sus --build-arg, solo para cambiar cuatro strings.

Skill Run: entorno local determinista para un agente

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando pido a Claude que levante un proyecto en local, suele liarse: no sabe qué variables de entorno necesita, en qué orden arrancar los servicios, o qué comando exacto usar. Cada vez que lo hace, redescubre el mismo proceso a base de prueba y error, y encima con proyectos con frontend + backend + infra, “levantar el proyecto” no es una sola cosa: a veces solo hace falta el frontend contra un backend de mentira para tocar UI, a veces hace falta el backend real con Postgres para depurar persistencia, a veces hace falta todo tal cual se despliega. Sin un contrato claro, el agente tiende a levantar de más (todo el stack cuando solo hacía falta el frontend) o de menos (arranca el backend a pelo, sin las variables de entorno correctas, y luego no sabe por qué falla la autenticación).

Skill Verify: verificación basada en riesgo

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando un agente termina de implementar algo, tiende a declarar la tarea hecha en cuanto el diff “tiene buena pinta”. Eso no es evidencia: un diff que compila y parece razonable puede romper una migración, dejar sin cubrir un caso de error, o cambiar un contrato HTTP sin que ningún test lo note. Y el problema inverso es igual de real: sin un criterio explícito, el agente también puede sobre-verificar, lanzando la suite completa (incluida infraestructura real) para un cambio interno que un test unitario ya cubre de sobra. Ninguno de los dos extremos es barato: uno deja bugs pasar, el otro quema tiempo y contenedores por nada.