Bellacosa Mainframe e a codificação vibe coding e context engineering

☕ Um Café no Bellacosa Mainframe

💵 Bud Fox e a Fintech de Wall Street — Quando Vibe Coding encontra Context Engineering

SDD, DDD, Monólito Modular, Evals, Engineering Loop, agentes de IA e a perigosa diferença entre gerar código que funciona e construir software em que podemos confiar.

Nova York, 1987.

Bud Fox atravessa os corredores da Jackson Steinem & Co. com dois telefones, uma agenda cheia de nomes e uma obsessão: descobrir alguma informação que os outros ainda não possuem.

Em Wall Street, informação significa vantagem.

Quase quarenta anos depois, troque o pregão por uma IDE, os terminais financeiros por agentes de IA e as ações por milhares de classes Java.

A questão continua surpreendentemente parecida:

informação sem contexto pode ser tão perigosa quanto informação nenhuma.

Nossa história começa com uma proposta irresistível.

Vamos construir uma fintech.

E vamos usar IA.

---

🎬 CAPÍTULO 1 — Bud Fox descobre Vibe Coding

Imagine Bud Fox chegando ao escritório de tecnologia.

Ele abre seu agente de IA e escreve:

Crie uma fintech em Java 21.

Spring Boot
PostgreSQL
Kafka
DDD
Arquitetura Hexagonal
Monólito Modular

Módulos:

Customers
Accounts
Pix
Fraud
Ledger
Notifications

ENTER.

Alguns minutos depois aparecem:

Controllers
Services
Repositories
Entities
DTOs
Migrations
Tests
Dockerfiles
Kafka configuration
REST APIs

Bud olha para a tela.

— Isso costumava levar semanas!

Bem-vindo ao Vibe Coding.

Gerar software tornou-se extraordinariamente barato. O material que analisamos começa justamente com essa constatação: descrevemos algo para um agente e rapidamente aparecem controllers, migrations, testes, Dockerfiles e dezenas de classes.

Bud encontrou sua primeira ação quente.

Só existe um problema.

O programa funcionar hoje não significa que sua arquitetura sobreviverá aos próximos 500 prompts.

---

📈 CAPÍTULO 2 — O primeiro lucro esconde a primeira dívida

Bud pede:

Implemente Send Pix.

A IA escreve.

Depois:

Adicione limite Pix.

Ela escreve.

Depois:

Adicione análise antifraude.

Mais código.

Prompt número 47:

Implemente estorno.

Prompt número 83:

Adicione Pix agendado.

Então aparece:

account.setBalance(
    account.getBalance().subtract(amount)
);

Excelente Java.

Provavelmente compila.

Talvez passe nos testes.

E está completamente errado.

Por quê?

Porque meses atrás nossa equipe tomou uma decisão arquitetural:

Ledger é a única fonte de verdade financeira.

Accounts conhece conta, estado, bloqueios e limites. Ledger conhece journals, débitos, créditos e posição financeira. Essa divisão de responsabilidade está explicitamente definida no modelo que estamos estudando.

O agente sabia Java.

Sabia Spring.

Sabia PostgreSQL.

Sabia como subtrair amount.

O que ele não sabia era:

como esta empresa decidiu representar dinheiro.

E encontramos nosso primeiro princípio.

Código correto localmente pode estar errado globalmente.

---

🦈 CAPÍTULO 3 — Gordon Gekko aparece na arquitetura

Se Gordon Gekko estivesse olhando nosso repositório, provavelmente perguntaria:

— Quem é dono de quê?

Excelente pergunta.

Porque software corporativo não é apenas um conjunto de classes.

É uma coleção de responsabilidades.

Nossa fintech possui:

Customers
    │
    │ identidade, cadastro, KYC
    │
Accounts
    │
    │ status, bloqueios, limites
    │
Pix
    │
    │ transferências
    │
    ├────────────► Fraud
    │               risco
    │
    ▼
Events
    │
    ├────────────► Ledger
    │               contabilidade
    │
    └────────────► Notifications
                    mensagens

Essa arquitetura possui uma característica particularmente interessante:

é um monólito modular.

Existe um único grande deployment, mas dentro dele tentamos preservar fronteiras claras.

com.bellacosa.fintech

├── customers
├── accounts
├── pix
├── fraud
├── ledger
└── notifications

Não confunda isso com um monólito desorganizado.

A intenção é praticamente:

uma cidade dentro de uma muralha, mas dividida em bairros com responsabilidades próprias.

---

🏦 CAPÍTULO 4 — Accounts não é Ledger

Essa distinção merece ficar gravada na parede do pregão.

Imagine:

ACCOUNT

A tentação inicial seria criar:

Account

customer
number
status
balance
limit
riskScore
pixKeys
transactions

Pronto.

Nasceu o God Object.

Em nossa fintech preferimos:

ACCOUNTS

Account
AccountStatus
AccountLimit
AccountRestriction

Enquanto:

LEDGER

Journal
LedgerEntry
Debit
Credit
Balance

E Fraud possui:

RiskAssessment
RiskScore
RiskDecision

Pix:

PixTransfer
PixKey
TransferStatus

Portanto:

ACCOUNT != MONEY

Essa aparentemente pequena decisão arquitetural é enorme.

Accounts responde:

A conta pode operar?

Fraud:

Esta operação apresenta risco aceitável?

Pix:

Qual é o estado da transferência?

Ledger:

O que aconteceu financeiramente?

Agora nossa IA começa a receber uma coisa muito mais importante do que instruções de programação.

Ela recebe semântica.

---

🧠 CAPÍTULO 5 — Bud Fox descobre Context Engineering

Bud percebe que ficar repetindo tudo em prompts é inviável.

Inicialmente:

Crie uma API Pix.

Depois:

Crie uma API Pix usando DDD.

Logo chegamos ao monstro:

Java 21.
Spring Boot.
PostgreSQL.
Kafka.
DDD.
Hexagonal.
Modular Monolith.
Pix não acessa AccountRepository.
Ledger controla saldo.
Use Outbox.
Use idempotência.
Use double-entry bookkeeping.
...

O próprio material mostra essa evolução e aponta o limite da estratégia: o prompt não deveria funcionar como banco de memória da engenharia do produto.

É quando Bud encontra algo muito mais valioso que uma ação privilegiada.

Context Engineering.

Prompt Engineering pergunta:

Como faço uma boa pergunta ao modelo?

Context Engineering pergunta:

Quais informações o agente precisa ter disponíveis para tomar uma boa decisão?

Parece apenas uma mudança de frase.

Não é.

É uma mudança de arquitetura.

---

📚 CAPÍTULO 6 — O conhecimento sai do chat

Começamos a construir:

docs/

├── domain/
│   ├── bounded-contexts.md
│   ├── ubiquitous-language.md
│   ├── ownership.md
│   ├── business-rules.md
│   └── context-map.md
│
└── architecture/
    ├── c4.md
    └── adr/

Agora podemos registrar:

OWN-001

Customers é proprietário
da identidade do cliente.

OWN-002

Accounts é proprietário
do estado operacional da conta.

OWN-003

Ledger é proprietário
da posição financeira.

E:

ARCH-007

Pix não acessa diretamente
Accounts Infrastructure.

Agora a IA não precisa “lembrar” dessas decisões.

Elas existem fora dela.

Essa é uma diferença monumental:

ANTES

Chat
 ↓
IA
 ↓
Code

torna-se:

DOMAIN
   +
ARCHITECTURE
   +
DECISIONS
   +
RULES
   ↓
AGENT
   ↓
CODE

A organização começa a possuir uma memória de engenharia.

---

🗺️ CAPÍTULO 7 — Bud desenha o mapa de Wall Street

Existe outra pergunta.

Se Pix precisa descobrir se uma conta pode transferir, ele pode simplesmente acessar:

AccountRepository

?

Não.

Porque isso atravessa a fronteira do módulo Accounts.

O material sugere algo conceitualmente parecido com:

PIX
 │
 ▼
AccountTransferEligibility
 │
 ▼
ACCOUNTS

Pix pergunta:

Essa conta pode transferir?

Ele não pergunta:

Me entregue sua tabela, repository e estrutura interna que eu resolvo daqui.

A mesma lógica vale para Fraud.

Errado:

PIX
 ↓
FraudRepository
 ↓
FraudRule
 ↓
RiskModel

Melhor:

PIX
 ↓
RiskAssessment
 ↓
FRAUD

Pix quer uma decisão.

Não precisa conhecer a cozinha inteira que produziu essa decisão.

---

🚨 CAPÍTULO 8 — O maior perigo do monólito modular

Aqui existe uma armadilha deliciosa.

No microservice:

PIX SERVICE

    rede

ACCOUNTS SERVICE

existe uma barreira física.

No monólito:

pix/
accounts/

está tudo no mesmo lugar.

Então alguém pensa:

“Vou pegar só esse repository rapidinho.”

import accounts.infrastructure.AccountRepository;

Funciona.

E exatamente por funcionar é perigoso.

Começamos:

Pix → Accounts

Depois:

Pix → Accounts Infrastructure

Fraud faz igual.

Notifications também.

Logo:

        Customers
       ↙    ↓    ↘
Accounts ↔ Pix ↔ Fraud
  ↕       ↕       ↕
Ledger ↔ Events ↔ Notifications

Parabéns.

Criamos o espaguete modular.

A pasta continua bonita.

A arquitetura morreu.

---

🎯 CAPÍTULO 9 — SDD entra no pregão

Bud recebe a próxima demanda:

Send Pix.

Antes ele pediria:

Implemente Send Pix.

Agora começa pela intenção.

INTENT
   ↓
SPEC
   ↓
RESEARCH
   ↓
DATA MODEL
   ↓
CONTRACTS
   ↓
PLAN
   ↓
TASKS
   ↓
IMPLEMENTATION

Esse é justamente o fluxo de Spec-Driven Development proposto no material.

Criamos:

specs/
└── 005-send-pix/

    ├── spec.md
    ├── research.md
    ├── data-model.md

    ├── contracts/
    │   ├── api.md
    │   └── events.md

    ├── evals/

    ├── plan.md
    └── tasks.md

Ainda não começamos pelo PixController.

Começamos perguntando:

O que significa transferir dinheiro neste negócio?

Essa pergunta vale mais que cinquenta classes.

---

📜 CAPÍTULO 10 — A Spec é o prospecto da operação

Nossa spec.md pode declarar:

FEATURE

Send Pix

Objetivo:

Transferir dinheiro entre contas
respeitando elegibilidade,
fundos disponíveis,
limites,
risco,
contabilidade
e idempotência.

E então aparecem as regras:

BR-001
A conta deve existir.

BR-002
A conta deve estar ativa.

BR-003
O valor deve ser maior que zero.

BR-004
Devem existir fundos disponíveis.

BR-005
O limite Pix deve ser respeitado.

BR-006
A análise de risco deve aprovar
a operação.

BR-007
A mesma Idempotency-Key não pode
produzir duas transferências.

São exatamente as classes de regras usadas no exemplo original.

Agora o agente não precisa adivinhar o negócio.

Mas surge outro problema.

---

🕵️ CAPÍTULO 11 — Gordon Gekko pergunta: “Quem fiscaliza?”

Podemos escrever:

Pix não pode acessar Accounts Infrastructure.

Excelente.

Então um agente escreve:

import accounts.infrastructure.AccountRepository;

A documentação dizia não.

O código disse sim.

Quem ganhou?

O compilador.

Precisamos transformar regras humanas em regras verificáveis.

Entram os:

🧪 EVALS

Podemos pensar:

SPEC
=
o que esperamos

EVAL
=
como demonstramos que continua verdadeiro

Essa relação aparece claramente no material.

---

🛡️ CAPÍTULO 12 — A SEC da nossa arquitetura

Vamos criar alguns fiscais.

Architecture Eval

PIX não pode importar:

accounts.infrastructure
ledger.infrastructure
fraud.infrastructure

Idempotency Eval

Given

Idempotency-Key = ABC123

When

POST /pix/transfers
é executado duas vezes

Then

existe apenas uma PixTransfer.

Ledger Eval

Pix = R$100

Debit  = R$100
Credit = R$100

sum(debits) == sum(credits)

Esses exemplos aparecem diretamente no modelo estudado.

Evals tornam a arquitetura menos dependente da boa vontade do programador.

Ou da memória da IA.

---

🧪 CAPÍTULO 13 — Eval não significa apenas JUnit

Essa distinção é essencial.

Podemos ter:

DOMAIN EVALS

Regras de negócio.

ARCHITECTURE EVALS

Fronteiras.

CONTRACT EVALS

APIs e eventos.

INTEGRATION EVALS

Banco, Kafka, Outbox.

SECURITY EVALS

Autorização e exposição de dados.

CONCURRENCY EVALS

Operações simultâneas.

ACCOUNTING EVALS

Integridade contábil.

OBSERVABILITY EVALS

Se conseguiremos descobrir o que aconteceu quando tudo der errado.

O material também trata Evals dessa maneira ampla, indo muito além de testes unitários.

---

⚔️ CAPÍTULO 14 — Dois traders querem gastar o mesmo dinheiro

Temos:

Saldo disponível = R$1.000

Chegam simultaneamente:

PIX A = R$800
PIX B = R$800

Processo A lê:

saldo = 1000

Processo B:

saldo = 1000

A conclui:

1000 >= 800

B também.

Resultado possível:

R$1.600 transferidos

contra:

R$1.000 disponíveis.

Nosso happy-path:

Given saldo 1000
When Pix 800
Then aprovado

passaria maravilhosamente.

Mas precisamos de:

CONCURRENCY-EVAL-001

Given

availableFunds = 1000

When

Pix A = 800
Pix B = 800

simultaneamente

Then

somente uma operação
pode consumir os fundos.

Agora começamos a testar não apenas exemplos.

Testamos invariantes.

---

🔁 CAPÍTULO 15 — A mesma ordem chegou duas vezes

Outro clássico do mercado financeiro.

Cliente envia:

POST /pix/transfers
Idempotency-Key: ABC123

A rede fica lenta.

Nenhuma resposta.

O aplicativo tenta novamente.

Sem idempotência:

PIX #1001   R$100
PIX #1002   R$100

Com idempotência:

Request 1 ──┐
            │
            ├── ABC123 ──► PIX #1001
            │
Request 2 ──┘

Mas existe uma segunda armadilha.

---

📬 CAPÍTULO 16 — Kafka telefona novamente

Nossa arquitetura:

PIX
 │
 ▼
OUTBOX
 │
 ▼
KAFKA
 │
 ▼
LEDGER

Ledger recebe:

PixTransferCompleted #777

Produz:

Debit  R$100
Credit R$100

Depois o evento chega novamente.

Se o consumidor não for idempotente:

Debit 100
Credit 100

Debit 100
Credit 100

O livro continua matematicamente equilibrado!

Mas economicamente duplicamos a operação.

Esse é um detalhe extraordinariamente importante:

consistência matemática não implica correção de negócio.

O próprio exemplo do material usa duplicação de eventos gerando lançamentos repetidos para demonstrar como produção pode revelar uma invariante que faltava.

---

🔄 CAPÍTULO 17 — Engineering Loop: o fechamento do pregão não encerra a história

Software não termina no merge.

Nem no deploy.

Nosso ciclo passa a ser:

UNDERSTAND
    ↓
IMPLEMENT
    ↓
TEST
    ↓
REVIEW
    ↓
OBSERVE
    ↓
LEARN
    ↺

Understand

O agente consulta:

Spec
Business Rules
Ownership
Context Map
ADRs
Contracts
Evals

Implement

Escreve dentro dessas fronteiras.

Test

Executa:

Unit
Integration
Contract
Architecture
Security
Evals

Review

Perguntamos:

Atendeu à intenção?

Quebrou algum contexto?

Introduziu acoplamento?

Idempotência continua válida?

Há risco concorrente?

Observe

Produção finalmente fala.

Learn

E aqui acontece a mágica.

---

📊 CAPÍTULO 18 — Produção é o verdadeiro mercado

Nosso Pix entra em produção.

Passamos a observar:

pix_transfer_total

pix_transfer_success_total

pix_transfer_failed_total

pix_transfer_duration_seconds

fraud_analysis_duration_seconds

outbox_pending_events

Esses sinais também aparecem no modelo de Engineering Loop estudado.

Então...

03:17.

O telefone toca.

☕ Easter egg Bellacosa desbloqueado.

Existe lançamento duplicado.

Bud Fox olha para o monitor.

O mercado está aberto.

Só que agora o mercado é produção.

---

🧯 CAPÍTULO 19 — Não corrija apenas o bug

A abordagem antiga:

INCIDENT
 ↓
BUG
 ↓
FIX
 ↓
DEPLOY

A abordagem que estamos construindo:

INCIDENT
    ↓
ANALYSIS
    ↓
FINDING
    ↓
DECISION
    ↓
 ┌──┴───────────────┐
 ▼                  ▼
CODE              CONTEXT
 ▼                  ▼
TEST               ADR
 ▼                  ▼
EVAL               SPEC
 └────────┬─────────┘
          ▼
       LEARNING

Descobrimos:

Duplicate event delivery
can generate duplicate
ledger postings.

Decidimos:

All financial consumers
must be idempotent.

Criamos:

006-ledger-consumer-idempotency/

Exatamente como no cenário do material.

O incidente não produziu apenas patch.

Produziu conhecimento.

---

🧠 CAPÍTULO 20 — Aqui está a verdadeira fortuna de Bud Fox

Agora chegamos ao ponto que considero mais importante de toda essa arquitetura.

Um incidente ocorrido hoje não deveria permanecer apenas:

na memória do arquiteto

num ticket

num e-mail

num post-mortem

num canal de chat

num comentário de código

Ele precisa alimentar:

INCIDENT
   ↓
LEARNING
   ↓
CONTEXT

E então:

CONTEXT
   ↓
NEXT AGENT

O material faz exatamente essa inversão: contexto deixa de ser apenas entrada e passa a ser também saída do processo de engenharia.

Isso transforma Context Engineering numa espécie de memória institucional versionada.

---

🗃️ CAPÍTULO 21 — ADR: o arquivo secreto de Gordon Gekko

Imagine:

ADR-023

Título:

Ledger is the financial
source of truth

Não basta escrever:

Decision:

Ledger owns balance.

Precisamos explicar:

Context:

Accounts represents operational state.

Ledger represents financial state.

Decision:

All financial postings belong to Ledger.

Consequences:

Accounts cannot change balance.

Pix cannot maintain balance.

Cards cannot maintain balance.

Financial position must be derived
from Ledger.

Agora, meses depois, alguém pede:

Implemente cashback.

O agente encontra ADR-023.

Sem ele poderia criar:

account.addBalance(cashback);

Com ele percebe:

Cashback
   ↓
Ledger Posting
   ↓
Debit/Credit

ADR não é apenas documentação histórica.

Para agentes, pode funcionar como memória de decisões e de suas justificativas.

---

🧭 CAPÍTULO 22 — Mas Context Engineering também pode virar um monstro

Agora Bud encontra outro problema.

Temos:

900 ADRs
3.000 Specs
20.000 testes
500 incidentes
10.000 documentos

Podemos simplesmente colocar tudo no prompt?

Não.

Isso seria trocar:

PROMPT GIGANTE

por:

CONTEXTO GIGANTE

Context Engineering maduro também precisa responder:

Qual contexto é relevante para esta tarefa?

Para:

Implement Pix Scheduled Transfer

talvez precisemos:

Pix Domain Context

Accounts public contract

Fraud public contract

Ledger public contract

Pix business rules

relevant ADRs

current spec

relevant incidents

relevant evals

Não precisamos carregar todo o sistema.

Surge então:

TASK
 │
 ▼
CONTEXT ROUTER
 │
 ├── Domain
 ├── Architecture
 ├── ADR
 ├── Spec
 ├── Contracts
 ├── Evals
 └── Learning
 │
 ▼
AGENT

A próxima evolução não é apenas ter contexto.

É entregar o contexto certo no momento certo.

---

🤖 CAPÍTULO 23 — Wall Street ganha uma mesa inteira de agentes

Por que usar somente um agente?

Podemos ter:

                  HUMAN
                    │
                    ▼
              PLANNER AGENT
                    │
                    ▼
           IMPLEMENTATION AGENT
                    │
                    ▼
               TEST AGENT
                    │
                    ▼
          ARCHITECTURE AGENT
                    │
                    ▼
            SECURITY AGENT
                    │
                    ▼
              REVIEW AGENT
                    │
                    ▼
                  HUMAN

Implementation Agent produz:

import accounts.infrastructure.AccountRepository;

Architecture Eval responde:

FAILED

ARCH-002

PIX cannot depend on
ACCOUNTS.infrastructure

O agente consulta o contexto.

Encontra:

AccountTransferEligibility

Corrige.

Executa novamente.

PASS

Perceba a mudança.

Evals deixam de servir apenas ao pipeline.

Eles se tornam feedback para o raciocínio iterativo dos agentes.

---

👨‍💻 CAPÍTULO 24 — E onde ficou o programador?

Essa pergunta inevitavelmente aparece.

Se agentes:

geram código
geram testes
fazem review
analisam contratos
procuram bugs

qual é o papel humano?

Ele sobe de nível.

Antes:

HUMAN
  ↓
CODE

Agora:

                 HUMAN
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
    INTENT       RISK       TRADE-OFF
       │           │           │
       └───────────┼───────────┘
                   ▼
               CONTEXT
                   │
                   ▼
                 AGENT
                   │
                   ▼
                 CODE

O desenvolvedor continua precisando entender código.

Mas passa a dedicar muito mais energia a:

intenção, fronteiras, invariantes, contratos, risco, decisões e evidências.

---

🏗️ CAPÍTULO 25 — O repositório deixa de guardar somente código

Nossa BellacosaBank pode terminar assim:

bellacosa-fintech/

├── docs/
│
│   ├── domain/
│   │   ├── ubiquitous-language.md
│   │   ├── bounded-contexts.md
│   │   ├── context-map.md
│   │   ├── ownership.md
│   │   └── invariants.md
│   │
│   └── architecture/
│       ├── c4/
│       └── adr/
│
├── specs/
│   ├── 001-create-customer/
│   ├── 002-open-account/
│   ├── 003-create-pix-key/
│   ├── 004-risk-analysis/
│   ├── 005-send-pix/
│   └── 006-ledger-idempotency/
│
├── evals/
│   ├── architecture/
│   ├── domain/
│   ├── contracts/
│   ├── accounting/
│   ├── concurrency/
│   ├── security/
│   └── observability/
│
├── engineering/
│   ├── loops/
│   ├── incidents/
│   ├── feedback/
│   └── learning/
│
└── src/
    ├── customers/
    ├── accounts/
    ├── pix/
    ├── fraud/
    ├── ledger/
    └── notifications/

A estrutura-base de documentação, specs, loops, feedback e implementação é justamente a proposta apresentada no material original.

Agora cada diretório responde a uma pergunta.

docs/domain
→ Como nosso negócio funciona?

docs/architecture
→ Como decidimos estruturá-lo?

specs
→ O que queremos construir?

evals
→ Como provamos?

engineering
→ O que aconteceu enquanto construíamos?

incidents
→ Onde a realidade contrariou nossas hipóteses?

learning
→ O que aprendemos?

src
→ Qual implementação existe atualmente?

Isso é muito mais poderoso que simplesmente armazenar código.

---

⚡ CAPÍTULO 26 — E o Vibe Coding volta pela porta da frente

Depois de toda essa burocracia arquitetural alguém poderia concluir:

Então Vibe Coding acabou.

Exatamente o contrário.

Agora Bud pode escrever:

Implemente Pix agendado.

Só que por trás dessa frase curta existe:

          "Implemente Pix agendado"
                     │
                     ▼
              CONTEXT ROUTER
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
     DOMAIN         ADRs          SPEC
       │             │             │
       ├─────────────┼─────────────┤
       ▼             ▼             ▼
   CONTRACTS       RULES         EVALS
       │             │             │
       └─────────────┼─────────────┘
                     ▼
                   AGENT
                     │
                     ▼
              IMPLEMENTATION
                     │
                     ▼
                   EVALS
                     │
                     ▼
                  REVIEW

O material chama atenção para esse paradoxo:

quanto melhor estruturado o contexto, menos precisamos repetir tudo no prompt.

Portanto Vibe Coding não precisa ser sinônimo de engenharia irresponsável.

Podemos ter:

Vibe Coding sobre trilhos.

---

🖥️ CAPÍTULO 27 — E onde entra o COBOL?

Agora chegamos ao ponto especialmente interessante para quem vive no mundo mainframe.

Muito antes de alguém dizer Context Engineering, mainframes já conviviam com o problema.

Imagine um programa:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PGMPX001.

Quarenta anos de história.

Ele usa:

COPYBOOKS
VSAM
Db2
CICS
MQ
JCL
PROCs
RACF
SORT
programas chamados
programas chamadores
arquivos downstream
jobs batch

Alguém pede:

“Altere a regra de limite.”

O programador iniciante pensa:

abrir COBOL
       ↓
achar IF
       ↓
alterar
       ↓
compilar

O veterano pergunta:

Quem chama?

Quem é chamado?

Qual COPYBOOK?

Qual tabela?

Qual transação CICS?

Qual arquivo?

Qual JCL?

Qual janela batch?

Qual downstream?

Qual rollback?

Qual regra histórica?

Por que aquele IF existe?

Isso é Context Engineering antes do nome existir.

---

🏛️ CAPÍTULO 28 — O mainframe é uma catedral de contexto

Imagine:

               BUSINESS RULE
                     │
                     ▼
                 COPYBOOK
                     │
             ┌───────┼───────┐
             ▼       ▼       ▼
           COBOL    CICS     BATCH
             │       │       │
             ▼       ▼       ▼
            Db2     MQ      VSAM
             │               │
             └───────┬───────┘
                     ▼
                 DOWNSTREAM

Um agente que simplesmente recebe:

“Modernize esse COBOL.”

está quase cego.

Ele precisa saber:

Business Context
Architecture Context
Data Context
Integration Context
Security Context
Operational Context
Historical Context

Ou seja, o desafio não é:

A IA sabe COBOL?

A pergunta muito mais importante é:

A IA sabe o que esse COBOL significa dentro daquela organização?

Aí a conversa sobre Context Engineering deixa de parecer moda de IA.

Ela começa a parecer extremamente familiar para qualquer veterano de mainframe.

---

💎 CAPÍTULO 29 — A verdadeira informação privilegiada

Bud Fox começou nossa história procurando a próxima informação capaz de lhe dar vantagem.

No desenvolvimento com IA também existe uma informação privilegiada.

Não é:

"Use Spring Boot."

Todo modelo sabe isso.

Não é:

"Use Kafka."

Também sabe.

Não é sequer:

"Use DDD."

A verdadeira vantagem está em conhecimento que só sua organização possui:

Por que Ledger controla saldo?

Por que Pix não acessa AccountsRepository?

Por que determinado consumer precisa ser idempotente?

Por que aquele limite existe?

Por que aquela decisão foi tomada?

Qual incidente revelou aquela regra?

Qual comportamento não pode mudar?

Qual contrato não pode quebrar?

Isso é conhecimento institucional.

E, ao contrário do insider trading de Wall Street, aqui queremos exatamente o contrário:

tornar esse conhecimento acessível, explícito, governado e verificável para quem legitimamente precisa construir o sistema.

---

🎞️ EPÍLOGO — Bud Fox fecha o terminal

No começo tínhamos:

PROMPT
   ↓
CODE

Parecia revolucionário.

Depois descobrimos:

VIBE CODING
     ↓
VELOCIDADE

Mas velocidade precisava de direção.

Então:

SDD
 ↓
INTENÇÃO

A intenção precisava respeitar fronteiras.

DDD
+
MODULAR MONOLITH
 ↓
OWNERSHIP
+
BOUNDARIES

As fronteiras precisavam estar disponíveis aos agentes.

CONTEXT ENGINEERING
 ↓
MEMÓRIA DE ENGENHARIA

A memória precisava ser verificável.

EVALS
 ↓
EVIDÊNCIA

E nenhuma especificação conhece completamente a realidade.

Então:

ENGINEERING LOOP
 ↓
OBSERVAR
 ↓
APRENDER

Finalmente fechamos o círculo:

                  INTENT
                    │
                    ▼
                 CONTEXT
                    │
                    ▼
                   SDD
                    │
                    ▼
                  EVALS
                    │
                    ▼
                  AGENT
                    │
                    ▼
             IMPLEMENTATION
                    │
                    ▼
             ENGINEERING LOOP
                    │
                    ▼
               PRODUCTION
                    │
                    ▼
                 SIGNALS
                    │
                    ▼
                FEEDBACK
                    │
                    ▼
                LEARNING
                    │
                    └────────────► CONTEXT
                                   ↺

É exatamente a síntese alcançada pelo material: Vibe Coding acelera; SDD dá direção; DDD protege fronteiras; Evals tornam intenção verificável; Engineering Loop converte execução em aprendizado; Context Engineering conecta o conjunto.

Bud olha para Gordon Gekko.

Gekko talvez dissesse:

informação é o ativo mais valioso da sala.

Mas no desenvolvimento de software com agentes existe uma versão melhor dessa máxima:

Código está ficando barato. Contexto confiável está ficando valioso.

Porque não será particularmente impressionante uma IA produzir dez mil linhas de Java, COBOL ou Python em uma tarde.

O verdadeiro feito será ela chegar ao prompt número 500, depois de quarenta features, dez desenvolvedores, cinco agentes, três mudanças arquiteturais e aquele inevitável incidente das 03:17, e ainda compreender que:

Accounts
≠
Ledger

que:

Pix
NÃO acessa
Accounts Infrastructure

que:

Debit == Credit

não é suficiente se o mesmo evento financeiro tiver sido processado duas vezes;

e, sobretudo, compreender por que cada uma dessas decisões existe.

Quando conseguirmos isso, teremos ido muito além de Vibe Coding.

Teremos construído algo que empresas perseguem desde muito antes da IA:

software capaz de preservar o conhecimento acumulado por quem o construiu.

E talvez aí esteja a maior ironia desta história.

O futuro dos agentes de IA pode acabar redescobrindo uma das grandes lições do mainframe:

sistemas críticos sobrevivem durante décadas não porque alguém escreveu código perfeito, mas porque sucessivas gerações conseguiram preservar contratos, regras, interfaces, decisões e conhecimento suficientes para continuar mudando sem destruir aquilo que já funcionava.

Bud Fox queria descobrir qual seria a próxima grande operação.

No nosso pregão tecnológico, talvez já tenhamos encontrado uma:

Vibe Coding gera código. Context Engineering preserva engenharia.

E em sistemas que movimentam dinheiro — seja uma fintech Java de 2026 ou um COBOL processando milhões de transações num IBM Z — essa diferença vale muito mais do que algumas linhas de código produzidas em segundos.