ATLAS + GOTCHA -- Parte 4
El Mapeo Perfecto: ATLAS Conoce a GOTCHA
El Problema
Ya conoces dos frameworks. ATLAS te hace pensar. GOTCHA organiza ese pensamiento para la IA. Pero hasta ahora los hemos tratado por separado. ATLAS en un artículo, GOTCHA en otro.
En la práctica, los desarrolladores tienen problemas con el espacio entre los dos. Rellenan ATLAS, y luego se quedan mirando una plantilla GOTCHA vacía preguntándose: “¿Dónde va esto? ¿Mi flujo de datos es un Goal o un Context? ¿Mi orden de build es Orchestration o Heuristics?”
Esta confusión es normal. Pasa porque ATLAS y GOTCHA usan palabras diferentes para conceptos relacionados. ATLAS habla en lenguaje de arquitectura: fases, flujos, integraciones. GOTCHA habla en lenguaje de IA: goals, context, heuristics. La conexión entre ellos no es obvia hasta que la ves.
De eso va este artículo. El mapeo 1:1 entre ATLAS y GOTCHA. Cuando lo veas, no volverás a tener problemas para rellenar un prompt GOTCHA — porque tu checklist de ATLAS ya tiene todas las respuestas.
La Solución
Aquí está el mapeo completo:
| Fase ATLAS | Capa GOTCHA | Tú decides… | La IA recibe… |
|---|---|---|---|
| Architect | Goals | Qué construir y los límites | La misión y criterios de éxito |
| Trace | Orchestration | Cómo fluyen los datos por el sistema | La secuencia y dependencias |
| Link | Tools + Context | Cómo se conectan los componentes | Qué usar y el entorno |
| Assemble | Heuristics | Cómo construirlo bien | Las reglas y puertas de calidad |
| Stress-test | Args | Cómo validarlo | Los inputs concretos y objetivos |
Cinco fases ATLAS. Seis capas GOTCHA. El mapeo no es uno-a-uno en sentido estricto — Link mapea a dos capas GOTCHA (Tools y Context). Pero cada decisión de ATLAS tiene un lugar claro en GOTCHA.
Vamos a recorrer cada mapeo.
Architect → Goals
Tu fase Architect define qué estás construyendo y qué queda fuera. Eso se convierte en la misión de la IA.
| Escribiste en Architect | Se convierte en Goals |
|---|---|
| ”Servicio de notificaciones para plataforma e-commerce" | "Construye un worker service en .NET 10 que envíe notificaciones" |
| "Debe procesar eventos en 30 segundos" | "Procesa cada evento en 30 segundos desde su recepción" |
| "Entrega at-least-once" | "Garantiza entrega at-least-once" |
| "Fuera de alcance: emails de marketing” | (Lo dejas fuera de Goals — la IA solo construye lo que está listado) |
El “fuera de alcance” de Architect es muy potente. Al no incluir algo en Goals, evitas que la IA lo construya. No necesitas decir “no construyas emails de marketing.” Simplemente no los mencionas.
Trace → Orchestration
Tu fase Trace sigue los datos de principio a fin. Esa secuencia se convierte en el orden de build de la IA.
| Escribiste en Trace | Se convierte en Orchestration |
|---|---|
| ”El evento llega a Service Bus" | "Paso 1: Service Bus consumer" |
| "El servicio consulta preferencias del usuario" | "Paso 3: User preference service" |
| "Cargar template, renderizar, enviar" | "Pasos 4-6: Template engine, dispatcher, providers" |
| "Reintentar 3 veces si falla" | "Paso 7: Retry logic" |
| "Confirmar después de procesar” | (Implícito en el paso del consumer) |
Trace te da el flujo. Orchestration le da a la IA la secuencia de build. Es la misma información en formatos diferentes. El flujo te dice qué pasa en runtime. La orchestration le dice a la IA qué construir primero.
Link → Tools + Context
Link es la única fase ATLAS que mapea a dos capas GOTCHA. Tiene sentido porque las integraciones tienen dos partes: QUÉ usas (Tools) y CÓMO funciona tu entorno (Context).
De la misma tabla de Link:
| Escribiste en Link | Tools recibe | Context recibe |
|---|---|---|
| ”Suscripción AMQP a Service Bus” | Azure.Messaging.ServiceBus | ”Comunicación entre servicios vía Service Bus topics" |
| "TCP/EF Core a PostgreSQL” | Entity Framework Core + Npgsql | ”Patrón database per service" |
| "HTTPS REST a ACS Email” | Azure.Communication.Email | ”Managed identities para acceso a Azure" |
| "Circuit breaker, 5s timeout” | (no es un tool) | “Modo de fallo: circuit breaker después de 5 fallos” |
¿Ves la separación? Los nombres de tecnología van a Tools. Los patrones de arquitectura y detalles del entorno van a Context. La misma fila de Link produce información para ambas capas.
Por eso Link es la fase ATLAS más importante. Alimenta las dos capas GOTCHA que previenen más errores. Tools equivocados = código equivocado. Context equivocado = código que funciona aislado pero falla en tu entorno.
Assemble → Heuristics
Tu fase Assemble define cómo se construyen las cosas. Las reglas, los patrones, los estándares de calidad. Eso se convierte en las barreras de comportamiento de la IA.
| Escribiste en Assemble | Se convierte en Heuristics |
|---|---|
| ”Repository → service → controller" | "Usa el patrón repository para todo el acceso a base de datos" |
| "Tests unitarios por cada capa" | "Escribe tests unitarios para services, tests de integración para repositories" |
| "Fase 4: Fiabilidad — retry, dead letter, idempotency" | "Comprueba notification_log antes de enviar (idempotency)” |
Assemble va de orden de build Y calidad de build. El orden va a Orchestration (desde Trace). Las reglas de calidad van a Heuristics. Cuando rellenas Assemble y te encuentras escribiendo reglas como “siempre usa async/await” o “nada de lógica de negocio en controllers,” eso son heuristics.
Stress-test → Args
Tu fase Stress-test define escenarios concretos de validación con números específicos. Esos números se convierten en los parámetros de la IA.
| Escribiste en Stress-test | Se convierte en Args |
|---|---|
| ”500 usuarios concurrentes" | "K8s: 2 replicas, 250m/500m CPU" |
| "Latencia P95 < 200ms" | "Health: /healthz en puerto 8080" |
| "1000 eventos en 60 segundos" | "Service Bus: max concurrent calls 10" |
| "Replay de eventos → sin duplicados” | (Ya es un heuristic: idempotency) |
Stress-test te da los números. Args le da esos números a la IA. Connection strings, replica counts, memory limits, port numbers — todos los valores concretos que convierten un servicio genérico en TU servicio.
Ejecución
Hagamos el ejercicio completo. Vamos a coger el servicio de notificaciones ATLAS del Artículo 2 y mapearlo a un prompt GOTCHA, paso a paso.
Aquí está el checklist ATLAS (condensado):
[A] ARCHITECT
Servicio de notificaciones. Email, SMS, push. 30s procesamiento. At-least-once.
[T] TRACE
Evento → consumer → preferencias → template → dispatch → provider → log
[L] LINK
Service Bus (AMQP), PostgreSQL (EF Core), ACS Email, ACS SMS,
Notification Hubs. Managed identities. Circuit breakers.
[A] ASSEMBLE
Foundation → Core → Providers → Reliability → Deployment.
Repository pattern. Async everywhere. DI. Tests por capa.
[S] STRESS-TEST
1000 eventos/60s. Manejo de fallos de providers. Idempotency.
2 replicas, 250m-500m CPU, 256Mi-512Mi memory.
Y aquí es donde cada pieza aterriza en GOTCHA:
graph LR
A[Architect] -->|defines mission| G[Goals]
T[Trace] -->|defines sequence| O[Orchestration]
L[Link] -->|defines tools| TL[Tools]
L -->|defines environment| C[Context]
AS[Assemble] -->|defines rules| H[Heuristics]
S[Stress-test] -->|defines values| AR[Args]
style A fill:#3b82f6,color:#fff
style T fill:#3b82f6,color:#fff
style L fill:#3b82f6,color:#fff
style AS fill:#3b82f6,color:#fff
style S fill:#3b82f6,color:#fff
style G fill:#10b981,color:#fff
style O fill:#10b981,color:#fff
style TL fill:#10b981,color:#fff
style C fill:#10b981,color:#fff
style H fill:#10b981,color:#fff
style AR fill:#10b981,color:#fff
Azul es ATLAS (pensamiento humano). Verde es GOTCHA (instrucciones para la IA). Cada flecha es un mapeo. Link tiene dos flechas porque alimenta tanto Tools como Context.
¿El resultado? Un prompt GOTCHA completo donde cada línea se puede trazar a una decisión ATLAS. Nada se inventa. Nada se adivina. La IA recibe instrucciones estructuradas que vienen de pensamiento estructurado.
Aquí tienes una comparación lado a lado de la misma decisión fluyendo por ambos frameworks:
| Decisión | ATLAS (tú piensas) | GOTCHA (la IA lee) |
|---|---|---|
| “Usar Azure Communication Services para email” | Link: Notification Service → ACS Email, HTTPS REST | Tools: Azure.Communication.Email. Context: managed identities para acceso a Azure |
| ”Reintentar 3 veces con backoff” | Assemble: Fase 4 Reliability | Heuristics: SÍ reintentar 3x con exponential backoff |
| ”2 replicas en Kubernetes” | Stress-test: Escenario 1 throughput | Args: K8s replicas: 2, CPU 250m/500m |
| ”Procesar eventos en 30 segundos” | Architect: Restricciones | Goals: procesa cada evento en 30 segundos |
| ”Evento → consumer → preferencias → enviar” | Trace: Pasos 1-7 | Orchestration: construir consumer primero, luego preferencias, luego providers |
Cinco decisiones. Cinco caminos claros del pensamiento humano a la instrucción para la IA. Sin ambigüedad sobre dónde van las cosas.
Plantilla
Aquí está la plantilla maestra de prompts. Combina ATLAS y GOTCHA en un único flujo de trabajo:
=== MASTER PROMPT: ATLAS → GOTCHA ===
Paso 1: Rellena ATLAS (tu pensamiento)
─────────────────────────────────────
[A] ARCHITECT → Qué + límites + restricciones
[T] TRACE → Flujo de datos de principio a fin
[L] LINK → Integraciones + protocolos + modos de fallo
[A] ASSEMBLE → Orden de build + patrones + reglas de calidad
[S] STRESS-TEST → Escenarios de validación + números concretos
Paso 2: Mapea a GOTCHA (instrucciones para la IA)
─────────────────────────────────────
=== GOALS (desde Architect) ===
(Misión + criterios de éxito medibles)
=== ORCHESTRATION (desde Trace) ===
(Secuencia de build con dependencias)
=== TOOLS (desde Link — nombres de tecnología) ===
(Frameworks, librerías, APIs con versiones)
=== CONTEXT (desde Link — detalles del entorno) ===
(Patrones de arquitectura, convenciones, restricciones)
=== HEURISTICS (desde Assemble — reglas de calidad) ===
SÍ:
-
NO:
-
=== ARGS (desde Stress-test — valores concretos) ===
(Connection strings, puertos, límites, replicas)
Imprímelo. Úsalo cada vez que trabajes con una IA en una tarea de desarrollo. La primera vez toma 10-15 minutos. Después de unos cuantos proyectos, lo rellenarás en 5 minutos. Y la calidad del output de la IA será diferente cada vez — porque dejaste de adivinar y empezaste a pensar.
Reto
Antes del Artículo 5, haz esto: coge un proyecto real — no un tutorial, uno real que estés construyendo o manteniendo — y pásalo por el flujo completo ATLAS → GOTCHA. Rellena las cinco fases ATLAS. Mapéalas a las seis capas GOTCHA. Escribe el prompt completo.
Luego envía ese prompt a tu herramienta de IA. Compara el resultado con lo que obtendrías con un prompt de una línea. La diferencia será obvia.
En el Artículo 5, dejamos de hablar de frameworks y empezamos a construir. Vamos a coger el flujo ATLAS + GOTCHA y construir una API de usuarios completa — PostgreSQL, autenticación JWT, .NET, desplegada en Kubernetes. Cada fase, cada capa, cada línea de código. Del checklist a producción.
Si esta serie te ayuda, considera invitarme a un café.
Loading comments...