A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

Bellacosa Mainframe o cobol nao é o problema

---

☕💣🚨 PADAWAN, O COBOL NÃO É O PROBLEMA! O VERDADEIRO MONSTRO ESTÁ ESCONDIDO DENTRO DO SISTEMA

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

---

A Guerra Contra o COBOL

Existe uma frase que se repete há mais de 30 anos:

"Precisamos eliminar o COBOL."

O curioso é que enquanto essa frase era repetida por consultorias, vendors, CIOs e arquitetos corporativos, o COBOL continuava fazendo aquilo que sempre fez:

• pagando aposentadorias;

• processando cartões;

• calculando seguros;

• movimentando bilhões em transações;

• sustentando governos inteiros.

O COBOL nunca foi o problema.

O problema sempre foi outro:

ninguém mais sabia exatamente o que estava escondido dentro dele.

---

O Dia em Que a Empresa Descobriu Que Ninguém Entendia o Sistema

Imagine um banco.

Ele possui:

• 18 milhões de linhas COBOL;

• 4.000 jobs batch;

• 1.500 copybooks;

• centenas de tabelas DB2;

• regras de negócio escritas desde 1987.

Um consultor chega e diz:

"Vamos converter tudo para Java."

A diretoria aprova.

O projeto custa dezenas de milhões.

Três anos depois...

O sistema agora roda em Java.

E o problema continua exatamente igual.

Porque ninguém entendeu o negócio.

Apenas trocaram a sintaxe.

---

O Efeito "Jobol"

O artigo menciona um termo fantástico:

JOBOL

Java + COBOL

Código Java que continua pensando como COBOL.

Exemplo:

COBOL

IF CLIENTE-ATIVO = 'S'
   COMPUTE DESCONTO = VALOR * 0.10
END-IF

Convertido automaticamente:

if(clienteAtivo.equals("S")){
    desconto = valor * 0.10;
}

Parece moderno.

Mas pergunte:

• Por que 10%?

• Desde quando?

• Existe legislação envolvida?

• Existe exceção?

Ninguém sabe.

A lógica foi transportada.

O conhecimento não.

---

O Easter Egg Mais Perigoso do Mainframe

Todo sistema antigo possui algo parecido.

Um trecho de código aparentemente absurdo:

IF DATA = '31121999'
   MOVE ZERO TO TAXA
END-IF

O programador novo pergunta:

"Quem colocou isso?"

Ninguém sabe.

Remove.

Produção explode.

Meses depois descobrem:

Aquilo corrigia um problema de cálculo criado por uma mudança tributária em 1999.

O código era feio.

Mas carregava uma regra de negócio invisível.

---

O Mainframe Guarda Mais Conhecimento Que os Documentos

Muitas empresas acreditam que possuem documentação.

Não possuem.

Possuem:

• manuais desatualizados;

• diagramas antigos;

• apresentações esquecidas.

O verdadeiro conhecimento está em:

• COBOL;

• PL/I;

• Natural;

• JCL;

• PROC;

• CICS;

• IMS;

• DB2;

• VSAM.

O código virou documentação viva.

---

Laboratório Bellacosa

Descobrindo Conhecimento Escondido

Imagine um programa de cálculo de seguro.

Passo 1

Procure constantes misteriosas.

MOVE 0.732 TO FATOR-AJUSTE

Pergunta:

Por que 0.732?

---

Passo 2

Procure datas mágicas.

IF DATA > '01012015'

Pergunta:

O que aconteceu em 2015?

---

Passo 3

Procure exceções.

IF UF = 'SP'

Pergunta:

Por que somente São Paulo?

---

Passo 4

Converse com usuários antigos.

Muitas vezes eles sabem mais que a documentação.

---

Resultado

Você começa a reconstruir o domínio do negócio.

Exatamente o que o DDD propõe.

---

Domain Driven Design Explicado Para Mainframeiros

Muita gente acha que DDD é moda.

Na verdade, o mainframe fazia DDD sem saber.

---

Exemplo

Sistema de seguros.

Temos:

Domínio

Seguros

Subdomínio

Sinistros

Contexto delimitado

Regulação

Linguagem ubíqua

Termos que o negócio entende:

• apólice;

• prêmio;

• segurado;

• franquia;

• indenização.

---

O Erro Clássico

Código moderno:

processEntity()

Código orientado ao domínio:

aprovarIndenizacao()

Qual transmite melhor o negócio?

---

O Grande Segredo dos Batchs

Existe uma verdade inconveniente.

Muitas regras de negócio não estão nos programas.

Estão na sequência dos jobs.

---

Exemplo:

JOB001 - IMPORTA CLIENTES
JOB002 - CALCULA JUROS
JOB003 - EMITE FATURAS
JOB004 - GERA ARQUIVO BACEN

Troque a ordem.

O banco para.

O fluxo batch também é conhecimento corporativo.

---

O Perigo da Reescrita Total

Todo arquiteto sonha com:

"Vamos reescrever tudo."

Na prática:

Forças

• arquitetura limpa;

• tecnologias novas;

• documentação moderna.

Fraquezas

• altíssimo risco;

• anos de projeto;

• perda de regras escondidas.

Perigos

• divergência de cálculo;

• problemas regulatórios;

• inconsistências financeiras.

---

A Estratégia Que Mais Funciona

O artigo cita o conceito mais inteligente da modernização moderna.

Strangler Fig

A Figueira Estranguladora.

Ela cresce ao redor da árvore antiga.

Até substituí-la.

---

No Mainframe

Fase 1

COBOL continua funcionando.

Fase 2

Criamos APIs.

Fase 3

Novos sistemas consomem APIs.

Fase 4

Partes são substituídas.

Fase 5

O legado diminui gradualmente.

Sem Big Bang.

Sem suicídio corporativo.

---

Raincode: O Que Muita Gente Não Entendeu

Muitos acreditam que Raincode é uma ferramenta de migração.

Na verdade:

É uma ferramenta de sobrevivência.

Ela permite:

• retirar carga do Z;

• migrar gradualmente;

• reduzir custos;

• ganhar tempo.

Mas atenção:

Ela não resolve:

• arquitetura ruim;

• regras escondidas;

• documentação ausente.

---

A Nova Função do Especialista COBOL

Aqui está a maior mudança dos próximos anos.

O programador COBOL deixa de ser:

• mantenedor;

• bombeiro de produção;

• operador de emergência.

E passa a ser:

Arqueólogo Digital

A pessoa capaz de responder:

"Por que o sistema faz isso?"

Essa resposta vale mais que escrever código.

---

Curiosidade Histórica

Muitas regras de negócio existentes hoje foram criadas por programadores que já faleceram ou estão aposentados há décadas.

Mesmo assim:

• seus algoritmos continuam rodando;

• suas decisões continuam afetando clientes;

• suas validações continuam protegendo empresas.

Em alguns casos, o código virou literalmente um patrimônio intelectual da organização.

---

O Verdadeiro Inimigo

Não é COBOL.

Não é JCL.

Não é CICS.

Não é IMS.

Não é DB2.

O verdadeiro inimigo é:

🚨 conhecimento implícito.

Aquilo que ninguém documentou.

Aquilo que ninguém explica.

Aquilo que só existe dentro do código.

---

Conclusão Bellacosa Mainframe

O mercado passou décadas tentando responder à pergunta errada.

Perguntavam:

"Como eliminamos o COBOL?"

Quando deveriam perguntar:

"Como preservamos o conhecimento do negócio?"

Porque uma empresa pode trocar:

• COBOL por Java;

• Java por C#;

• C# por Rust;

• Rust por IA Generativa.

Mas se perder o conhecimento embutido em 40 anos de operação...

não estará modernizando.

Estará apenas reconstruindo um problema antigo com ferramentas novas.

E como todo velho operador sabe:

"Trocar a cor do terminal não muda o que acontece quando você aperta ENTER." ☕💣🚨

 

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.

Conway's Law Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Apenas um Software… Era o Espelho de Quem a Construiu

 

Bellacosa Mainframe e a conways law rules

☕ Um Café no Bellacosa Mainframe

Conway's Law Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Apenas um Software… Era o Espelho de Quem a Construiu

"As organizações desenham sistemas que refletem sua própria forma de comunicação." — Melvin Conway (1967)

---

Prólogo — A Matrix Tinha o Mesmo Formato de Zion

Neo caminhava pelos corredores da Cidade das Máquinas.

Esperava encontrar servidores.

Processadores.

Centrais de controle.

Mas encontrou algo muito mais curioso.

Cada setor da Matrix era administrado por um grupo diferente.

O setor dos Agentes nunca conversava diretamente com o setor do Oráculo.

O setor do Merovíngio possuía seus próprios protocolos.

O Chaveiro trabalhava isolado.

Os Sentinelas recebiam ordens por outro canal.

Neo percebeu algo estranho.

Cada módulo da Matrix parecia exatamente igual ao departamento que o desenvolvia.

Morpheus perguntou:

— O que está vendo?

Neo respondeu:

— Não estou olhando apenas para um software...

Estou olhando para o organograma da empresa.

O Oráculo sorriu.

— Finalmente você encontrou a Lei de Conway.

---

O que é a Lei de Conway?

A Conway's Law afirma:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Em português:

"As organizações que desenvolvem sistemas acabam produzindo arquiteturas que refletem sua própria estrutura de comunicação."

Ou seja...

O software não nasce apenas das decisões técnicas.

Ele nasce da forma como as pessoas trabalham juntas.

---

A origem da Lei de Conway

A lei foi proposta em 1967 por Melvin E. Conway, cientista da computação.

Na época, Conway observou algo curioso.

Empresas organizadas em departamentos independentes acabavam criando softwares igualmente divididos.

Não era coincidência.

Era consequência direta da comunicação humana.

Décadas depois, essa observação continua sendo uma das ideias mais influentes da arquitetura de software.

---

Matrix explica perfeitamente

Imagine que a Matrix fosse construída por quatro equipes.

Equipe A.

Cuida da autenticação.

Equipe B.

Cuida da economia.

Equipe C.

Cuida dos Agentes.

Equipe D.

Cuida dos Sentinelas.

Se essas equipes quase não conversam...

o software também ficará separado.

Cada módulo desenvolverá sua própria visão da realidade.

---

O nascimento da Lei

Conway percebeu que a arquitetura técnica segue a arquitetura social.

Se duas equipes possuem dificuldades para conversar...

os sistemas também terão dificuldades para se integrar.

---

O COBOL conhece isso muito bem

Imagine um grande banco.

Departamento de Cartões.

↓

Equipe própria.

↓

Sistema próprio.

---

Departamento de PIX.

↓

Equipe diferente.

↓

API diferente.

---

Departamento de Crédito.

↓

Outro time.

↓

Outro banco de dados.

---

Departamento de Investimentos.

↓

Outro padrão.

↓

Outro framework.

O resultado?

Integrações complexas.

Duplicação de dados.

Interfaces difíceis.

Não porque os desenvolvedores desejavam isso.

Mas porque a organização já funcionava dessa maneira.

---

Um exemplo simples

Empresa.

Financeiro

RH

Comercial

Software.

Sistema Financeiro

Sistema RH

Sistema Comercial

Parece natural.

Agora imagine.

Cada departamento possui regras próprias de cadastro.

Logo surgem:

• três cadastros de clientes;

• quatro cadastros de funcionários;

• cinco cadastros de endereços.

O software apenas refletiu a organização.

---

Matrix Reloaded

Observe os personagens.

O Oráculo não faz o trabalho do Arquiteto.

O Merovíngio não administra Zion.

O Chaveiro não controla os Agentes.

Cada grupo possui funções próprias.

Agora imagine.

Nenhum deles conversa.

A Matrix rapidamente se fragmentaria.

---

O efeito psicológico

As pessoas tendem a conversar mais com quem está próximo.

Mesmo dentro da mesma empresa.

Logo.

Os sistemas acompanham essa divisão.

---

O Programador COBOL Padawan

Imagine que você trabalhe no time de CICS.

Nunca conversa com o pessoal de APIs.

Nem conhece a equipe de Open Finance.

Depois de dois anos...

as integrações começam a falhar.

Não por culpa do COBOL.

Mas porque a comunicação humana falhou antes da comunicação entre sistemas.

---

O Agente Smith adora isso

Smith sabe que basta dividir as pessoas.

O restante acontece sozinho.

Cada equipe cria:

• padrões próprios;

• nomenclaturas próprias;

• APIs próprias;

• documentação própria.

Pouco tempo depois.

Os sistemas deixam de conversar.

---

Um exemplo inspirado na Matrix

Neo pergunta.

— Quem controla o cadastro dos humanos?

Resposta.

— Depende.

A equipe dos Agentes possui um.

O Merovíngio outro.

O Oráculo outro.

Zion outro.

Neo pergunta.

— Por que existem quatro?

O Arquiteto responde.

— Porque existiam quatro departamentos.

---

Como reconhecer?

Existem sinais muito claros.

APIs incompatíveis

Cada área cria seu padrão.

---

Bancos duplicados

Mesma informação.

Vários lugares.

---

Nomenclaturas diferentes

CPF.

CPF_NUM.

DOCUMENTO.

CLIENT_ID.

Tudo significa a mesma coisa.

---

Integrações difíceis

Equipes precisam negociar constantemente.

---

Regras repetidas

Cada departamento implementa novamente.

---

O impacto no Mainframe

Grandes ambientes IBM Z frequentemente atendem diversas áreas de negócio.

Se cada área evolui isoladamente.

Logo aparecem:

• duplicação de COPYBOOKs;

• layouts diferentes;

• APIs redundantes;

• programas semelhantes;

• tabelas quase idênticas.

Tudo consequência da estrutura organizacional.

---

Curiosidade

Existe um conceito moderno chamado:

Reverse Conway Maneuver

A ideia é justamente o contrário.

Em vez de deixar a arquitetura seguir a organização...

a empresa reorganiza as equipes para produzir a arquitetura desejada.

Se deseja microsserviços independentes.

Cria equipes independentes.

Se deseja plataforma integrada.

Organiza equipes integradas.

---

Atenção!

Conway's Law não é uma crítica.

Ela é uma observação.

Toda organização sofre sua influência.

O importante é reconhecê-la.

---

O custo invisível

Quando departamentos não conversam.

Surgem:

• retrabalho;

• integrações caras;

• conflitos de requisitos;

• inconsistências.

Tudo isso custa tempo.

Dinheiro.

CPU.

Produtividade.

---

O papel do Arquiteto

Arquitetos não desenham apenas software.

Eles aproximam equipes.

Porque sabem.

Sem comunicação.

Não existe boa arquitetura.

---

Matrix e Zion

Imagine Zion dividida.

Cada setor constrói um pedaço da cidade.

Sem conversar.

Resultado.

Canos que não se conectam.

Cabos incompatíveis.

Portas que não levam a lugar nenhum.

Software funciona exatamente assim.

---

Ferramentas ajudam

Hoje usamos:

• Enterprise Architecture.

• Event Storming.

• Domain Driven Design.

• IBM ADDI.

• OpenAPI.

• AsyncAPI.

• Catálogos corporativos.

Mas nenhuma ferramenta substitui comunicação humana.

---

O papel da IA

A IA pode:

• documentar APIs;

• comparar contratos;

• identificar duplicações;

• sugerir padronizações.

Mas não resolve conflitos organizacionais.

---

Os riscos

Sistemas duplicados

---

APIs redundantes

---

Custos maiores

---

Integrações frágeis

---

Visão fragmentada do negócio

---

Arquitetura inconsistente

---

Erros clássicos

• Criar sistemas sem envolver outras áreas.

• Duplicar cadastros.

• Não compartilhar padrões.

• Cada equipe inventar sua arquitetura.

• Ignorar governança.

---

Boas práticas

• Comunicação frequente.

• Arquitetura corporativa.

• Catálogo de APIs.

• Padrões comuns.

• Revisões interequipes.

• Compartilhamento de conhecimento.

• Domínios bem definidos.

---

Aplicabilidade

A Lei de Conway aparece em:

• COBOL.

• Java.

• Cloud.

• Microsserviços.

• ERP.

• APIs.

• DevOps.

• Bancos.

• Governo.

• Telecom.

Ela independe da tecnologia.

---

Um exemplo COBOL

Imagine.

Equipe A.

Cria COPYBOOK:

CLIENTE.

Equipe B.

Cria outro.

CLIENTE-NEW.

Equipe C.

Outro.

CLIENTE-V2.

Nenhum é compatível.

O problema começou muito antes do compilador.

---

O ensinamento do Oráculo

O Oráculo leva Neo até um enorme espelho.

Cada equipe da Matrix aparece refletida.

Depois o espelho se transforma.

Agora revela o software.

Neo percebe algo impressionante.

As divisões eram exatamente iguais.

Ela pergunta:

— O que mudou?

Neo responde.

— Nada.

O software apenas copiou as pessoas.

Ela sorri.

"É exatamente isso que Conway descobriu."

---

Lições para um Programador COBOL Padawan

Ao iniciar sua carreira em um ambiente corporativo, você perceberá que muitos desafios técnicos têm origem muito antes do código ser escrito.

Às vezes o problema não está no COBOL, no CICS ou no Db2.

Está no fato de que:

• as equipes não compartilham conhecimento;

• cada área cria suas próprias definições;

• os requisitos chegam incompletos;

• não existe uma linguagem comum entre negócio e tecnologia.

Por isso, desenvolva não apenas habilidades técnicas.

Aprenda também a:

• comunicar-se claramente;

• participar de revisões arquiteturais;

• documentar decisões;

• compreender o domínio de negócio;

• construir pontes entre equipes.

Grandes arquitetos de software são, antes de tudo, excelentes comunicadores.

---

Curiosidades

A influência da Lei de Conway é tão grande que ela aparece indiretamente em diversos movimentos modernos:

• Domain-Driven Design (DDD) incentiva equipes alinhadas aos domínios de negócio.

• Team Topologies propõe estruturas organizacionais que favorecem fluxos de software saudáveis.

• Microservices funcionam melhor quando as equipes possuem autonomia compatível com os serviços que mantêm.

• DevOps surgiu justamente para reduzir barreiras entre desenvolvimento e operações.

Todos esses movimentos reconhecem, de alguma forma, a observação feita por Melvin Conway em 1967.

---

Conclusão — A Matrix Refletia Quem a Construía

No universo Matrix, Neo descobriu que a simulação não era apenas um conjunto de programas.

Ela refletia as decisões, os conflitos e a forma como seus criadores trabalhavam.

Na Engenharia de Software acontece exatamente o mesmo.

A Lei de Conway nos lembra que sistemas não são produzidos apenas por compiladores ou linguagens de programação.

Eles são produzidos por pessoas.

Se as equipes colaboram, o software tende a ser integrado.

Se as equipes vivem isoladas, o software também se fragmenta.

Para um Programador COBOL que atua em ambientes IBM Z, essa é uma lição valiosa. O sucesso de um sistema bancário depende tanto da qualidade do código quanto da qualidade da comunicação entre analistas de negócio, arquitetos, desenvolvedores, DBAs, administradores CICS, especialistas em segurança e operações.

No universo Bellacosa Mainframe existe uma máxima que certamente poderia estar gravada na entrada de Zion:

"Antes de desenhar a arquitetura do software, observe a arquitetura da empresa. Muito provavelmente uma será o reflexo da outra."

Porque, no fim, a Matrix nunca foi apenas feita de linhas de código.

Ela sempre foi feita das pessoas que aprenderam — ou deixaram de aprender — a trabalhar juntas.