☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 15 de abril de 2012

☕🔥💣 GHOST IN THE SHELL: STAND ALONE COMPLEX — O DIA EM QUE O SYSPROG DESCOBRIU QUE A INTERNET JÁ TINHA GANHADO CONSCIÊNCIA

 

Bellacosa Mainframe e o lendario Ghost in the Shell

☕🔥💣 GHOST IN THE SHELL: STAND ALONE COMPLEX — O DIA EM QUE O SYSPROG DESCOBRIU QUE A INTERNET JÁ TINHA GANHADO CONSCIÊNCIA

Quando a Root Cause Analysis Revelou que Não Existia Mais Programa Origem



Ficha Técnica

Título Original: 攻殻機動隊 STAND ALONE COMPLEX
(Kōkaku Kidōtai: Stand Alone Complex)

Título Internacional: Ghost in the Shell: Stand Alone Complex

Autor Original: Masamune Shirow

Diretor: Kenji Kamiyama

Estúdio: Production I.G

Ano de Lançamento: 2002

Temporadas Principais:

  • Stand Alone Complex (2002)

  • 2nd GIG (2004)

  • Solid State Society (2006)

Episódios:

  • 26 episódios (1ª temporada)

  • 26 episódios (2ª temporada)

  • 1 filme (Solid State Society)

Total: 52 episódios + 1 longa

Gêneros:

  • Cyberpunk

  • Ficção Científica

  • Thriller Policial

  • Suspense

  • Política

  • Filosofia

  • Investigação Tecnológica

Classificação Indicativa:

16+ (varia conforme país)


O Que É Ghost in the Shell?

Imagine que alguém misturou:

  • Blade Runner

  • FBI

  • NSA

  • Inteligência Artificial

  • Filosofia Existencial

  • Segurança da Informação

  • Guerra Cibernética

e transformou tudo isso em anime.

O resultado foi uma das obras mais inteligentes já produzidas na história da animação japonesa.


Sinopse

No futuro, praticamente todos os seres humanos possuem implantes cibernéticos.

Corpos artificiais tornaram-se comuns.

Cérebros podem ser conectados diretamente à rede.

Hackers conseguem invadir não apenas computadores.

Eles podem invadir pessoas.

Nesse cenário surge a:

Seção 9

Uma força especial governamental encarregada de combater:

  • terrorismo

  • espionagem

  • corrupção

  • crimes digitais

  • manipulação de informação

Liderada pela lendária:

Major Motoko Kusanagi

uma agente cujo corpo é quase totalmente artificial.

Apenas seu "Ghost" permanece humano.

Ou talvez nem isso.


A Grande Pergunta da Série

Todo anime possui uma questão central.

Em Naruto:

"Como ser reconhecido?"

Em Evangelion:

"Como lidar com a dor?"

Em Ghost in the Shell:

O que significa ser humano?

Se:

  • suas memórias podem ser alteradas

  • seu cérebro pode ser hackeado

  • seu corpo pode ser substituído

  • sua personalidade pode ser copiada

o que resta da sua identidade?

Essa pergunta acompanha toda a série.


O Caso do Homem que Ri

O Melhor Arco Investigativo dos Animes

Se existe um motivo para assistir SAC, é o famoso:

Laughing Man (Homem que Ri)

Tudo começa com um caso antigo de sequestro corporativo.

Aparentemente encerrado.

Mas anos depois eventos estranhos começam a reaparecer.

A investigação leva a:

  • corrupção farmacêutica

  • manipulação política

  • mídia controlada

  • encobrimentos governamentais

E então surge um conceito revolucionário.


Stand Alone Complex

O conceito que dá nome à série.

Imagine um ambiente z/OS.

Um erro aparece.

Você procura:

  • programa responsável

  • job responsável

  • usuário responsável

E não encontra nada.

Centenas de pessoas estão reproduzindo exatamente o mesmo comportamento.

Sem coordenação.

Sem líder.

Sem programa mestre.

O fenômeno passou a existir sozinho.

Essa é a definição de:

Stand Alone Complex

Uma ideia tão poderosa que se replica sem precisar de autor.

Hoje chamamos isso de:

  • memes

  • movimentos virais

  • fake news

  • narrativas coletivas

  • comportamento emergente

Em 2002 isso era praticamente ficção científica.


A Visão Profética da Internet

Poucos animes envelheceram tão bem.

Ghost in the Shell previu:

Redes Sociais

Décadas antes do Facebook.

Deepfakes

Décadas antes da IA generativa.

Fake News

Décadas antes do termo existir.

Vigilância em Massa

Antes das revelações de Edward Snowden.

Guerra Informacional

Antes de se tornar pauta global.

Influência Algorítmica

Antes dos algoritmos dominarem o planeta.

É assustador assistir hoje.


Os Tachikomas

Image

Image

Image

Image

Image

À primeira vista parecem mascotes cômicos.

Na realidade são um experimento filosófico.

Todos possuem:

  • mesmo hardware

  • mesmo software

  • mesmo código-base

Mas começam a pensar de forma diferente.

Por quê?

Experiências individuais.

É uma discussão profunda sobre:

  • consciência

  • aprendizado

  • identidade

  • inteligência artificial

Muito antes do surgimento do ChatGPT.


Major Motoko Kusanagi

Uma das personagens mais importantes da ficção científica.

Ela não é apenas uma heroína.

Representa a dúvida existencial máxima.

Seu corpo inteiro pode ser substituído.

Então:

Quem é Motoko?

Seu cérebro?

Sua memória?

Seu Ghost?

Sua consciência?

A série nunca entrega respostas fáceis.


As Mensagens Ocultas

1. A Informação É Mais Poderosa Que Armas

A verdadeira guerra da série não é física.

É informacional.

Quem controla dados controla a sociedade.


2. Identidade Pode Ser Fabricada

Memórias falsas aparecem repetidamente.

O anime questiona:

Se suas lembranças forem alteradas, você continua sendo você?


3. O Estado Pode Ser Tão Perigoso Quanto os Criminosos

A série apresenta governos, corporações e agências de inteligência como entidades moralmente ambíguas.

Não existem heróis absolutos.


4. A Tecnologia Não Resolve Problemas Humanos

Ela apenas amplifica.

Ganância continua sendo ganância.

Corrupção continua sendo corrupção.

Medo continua sendo medo.


As Aventuras da Seção 9

Cada missão funciona como uma investigação de RCA.

Os agentes analisam:

  • logs

  • evidências

  • conexões ocultas

  • rastros digitais

  • relações políticas

A sensação é semelhante a acompanhar:

  • um analista forense

  • um especialista em segurança

  • um sysprog investigando um abend impossível

Só que em escala nacional.


O Que Diferencia SAC de Outros Animes?

Enquanto muitos cyberpunks focam apenas na estética:

  • neon

  • chuva

  • cidades gigantes

Ghost in the Shell explora:

  • sociologia

  • filosofia

  • política

  • psicologia

  • segurança da informação

O cenário futurista é apenas a superfície.

O verdadeiro tema é a condição humana.


Houve Censura?

Sim.

Dependendo do país e da emissora:

  • cenas de nudez cibernética foram cortadas

  • violência foi reduzida

  • diálogos políticos sofreram adaptações

  • algumas transmissões alteraram enquadramentos

Contudo, a série permaneceu relativamente intacta quando comparada a outros animes adultos.

A maior dificuldade para distribuidores nunca foi a violência.

Foi a complexidade intelectual.


Impacto Cultural

Ghost in the Shell influenciou diretamente:

  • Matrix

  • Deus Ex

  • Cyberpunk 2077

  • Psycho-Pass

  • Westworld

  • Mr. Robot

As irmãs Wachowski reconheceram publicamente a influência de Ghost in the Shell na criação de Matrix.

Muitos conceitos visuais e filosóficos migraram diretamente para o cinema ocidental.


Avaliação Bellacosa Mainframe

CritérioNota
História10/10
Filosofia10/10
Personagens10/10
Investigação10/10
Atualidade11/10
Ação9/10
Complexidade10/10
Reassistibilidade10/10

Veredito Final ☕🔥💣

Ghost in the Shell: Stand Alone Complex não é apenas um anime.

É uma auditoria completa da sociedade digital.

É como se um grupo de arquitetos de sistemas, filósofos, especialistas em segurança, cientistas políticos e analistas de RCA se reunissem para responder uma única pergunta:

"O que acontece quando a informação se torna mais importante do que a própria realidade?"

Vinte anos depois, a resposta continua assustadora.

Porque aquilo que parecia ficção em 2002 se parece cada vez mais com o relatório de produção do mundo em 2026.

Classificação Bellacosa Mainframe: ☕☕☕☕☕ (Obra-Prima Absoluta)

Nível de Impacto Mental: 💣💣💣💣💣

Risco de Existential Dump: ABEND S0C4 DA REALIDADE. 🚨🧠📡💀

sábado, 14 de abril de 2012

📊🔥 Observabilidade explicada para quem já leu SMF em hexadecimal

 


📊🔥 Observabilidade explicada para quem já leu SMF em hexadecimal




00:00 — Introdução: quando o sistema falava em bytes, não em dashboards

Se você já decodificou SMF na unha, já fez observabilidade raiz.
Antes de gráficos coloridos, antes de “AI Ops”, antes de alertas barulhentos, existia o registro cru:
tempo de CPU, I/O, wait, EXCP, abend… tudo ali, em hexadecimal, esperando alguém que soubesse ler o sistema.

Observabilidade moderna só colocou UI bonita em cima de uma verdade antiga:

“Se você não mede, você chuta.”




1️⃣ O que é observabilidade (sem marketing, sem hype)

Observabilidade é a capacidade de entender o que está acontecendo dentro de um sistema apenas observando seus sinais externos.

Ela se baseia em três pilares:

  • Logs → o que aconteceu

  • Métricas → quanto, quando, quanto tempo

  • Traces → por onde passou

📌 Tradução mainframe:

  • Logs = SYSLOG / JES / dumps

  • Métricas = SMF / RMF

  • Traces = CICS trace / VTAM / DB2 accounting


2️⃣ A diferença entre monitorar e observar 🧠

Monitoramento

  • “CPU passou de 80%”

  • “Disco encheu”

  • “Job atrasou”

Observabilidade

  • Por que a CPU subiu?

  • Qual transação causou isso?

  • Qual dependência impactou o usuário?

👉 Mainframer já sabia:

“Alarme sem diagnóstico só acorda gente à toa.”


3️⃣ SMF: o avô da telemetria moderna 👴

SMF fazia:

  • Coleta automática

  • Granularidade absurda

  • Correlação entre subsistemas

  • Análise histórica

😈 Easter egg:
Prometheus se acha moderno, mas não chega aos pés do SMF 110.

O problema nunca foi o dado.
Foi a falta de quem soubesse interpretar.


4️⃣ Distributed Tracing: o novo nome do “follow the transaction”

No mundo distribuído:

  • Uma requisição passa por 10 serviços

  • Cada um em lugar diferente

  • Logs espalhados

  • Métricas fragmentadas

O trace distribuído faz:

  • Marca a transação com um ID

  • Acompanha do início ao fim

  • Mostra latência por etapa

📎 Mainframer traduz:

“É o CICS trace atravessando o mundo.”


5️⃣ Passo a passo para investigar um problema (modo Bellacosa)

1️⃣ Usuário reclama (sempre)
2️⃣ Identifique qual transação
3️⃣ Veja onde ela passa
4️⃣ Meça onde demora
5️⃣ Verifique dependências externas
6️⃣ Correlacione com evento (deploy, batch, falha)
7️⃣ Só então mexa

💣 Dica de ouro:
Quem pula direto para restart não entende observabilidade.


6️⃣ Alertas: de SMF exception a Smart Alerts 😵‍💫

No passado:

  • Threshold fixo

  • Regra dura

  • Muito falso positivo

Hoje:

  • Alertas inteligentes

  • Baseados em comportamento

  • Menos ruído

😈 Easter egg:
RMF já fazia baseline. Só faltava marketing.


7️⃣ Guia de estudo para mainframers modernos 📚

Conceitos essenciais

  • Observabilidade

  • Distributed tracing

  • Golden Signals (latência, tráfego, erros, saturação)

  • SLIs e SLOs

Ferramentas (com alma antiga)

  • Instana

  • Dynatrace

  • Prometheus + Grafana

  • Elastic Stack


8️⃣ Aplicações práticas no mundo híbrido

  • Diagnóstico rápido de incidentes

  • Correlação mainframe + cloud

  • Redução de MTTR

  • Planejamento de capacidade

  • Suporte a DevOps e SRE

🎯 Mainframer observável vira referência.


9️⃣ Curiosidades que só veterano percebe 👀

  • Dashboard não substitui raciocínio

  • Gráfico bonito não resolve gargalo

  • Logs demais cegam

  • Falta de dado é pior que excesso

📌 Verdade inconveniente:
Sem entendimento de arquitetura, observabilidade vira voyeurismo técnico.


🔟 Comentário final (04:12, sistema respirando)

Observabilidade não nasceu na cloud.
Ela foi sequestrada pela cloud.

Se você já:

  • Leu dump para entender sintoma

  • Cruzou SMF com RMF

  • Achou bug olhando tempo de CPU

Então você já praticava observabilidade.

🖤 El Jefe Midnight Lunch sentencia:
Quem lê o sistema, não precisa adivinhar.

 

sexta-feira, 13 de abril de 2012

1979–1982: Crônica Bellacosa Mainframe — O Menino, a Vila e a Democracia que Voltava

Bellacosa Mainframe e a igreja da Vila Rio Branco


🗳️ 1979–1982: Crônica Bellacosa Mainframe — “O Menino, a Vila e a Democracia que Voltava”

(Para o blog El Jefe Midnight Lunch)


Se tem anos que passam batidos, há outros que viram marcos.
E no meu spool de memória, dois deles tremeluzem como lâmpadas de poste em noite úmida: 1979 e 1982.

1979 foi a abertura.
1982 foi o primeiro sopro de democracia respirado sem medo.
Eu, pequeno, sem entender nada de DOI-CODI, AI-5 ou Congresso fechado…
mas entendendo perfeitamente o brilho nos olhos dos meus pais.


Bellacosa Mainframe e o pedido da anistia

📅 1979: O Garoto que Não Entendia, mas Sentia

Eu ainda era muito pequeno para compreender anistia, cassação, exílio.
Mas criança tem radar fino —
e eu percebia que algo grande estava acontecendo.

Meus pais, politizados até o osso, eram daqueles que não fugiam do debate.
Participaram da Marcha pela Anistia, vibraram com cada discurso, cada passeata, cada boletim lido em jornal alternativo.

Se filiaram ao MDB, aquele partido que, sozinho, segurava a tocha da oposição institucional na noite longa dos anos de chumbo.

Eu era só um menino observando.
Mas aprendendo — sem perceber — que política não era palavrão;
era compromisso.


Bellacosa Mainframe e a chegada da democraica eleiçoes de 1982

🏭 1982 — Vila Rio Branco: O Bairro Operário Abre as Portas

A Vila Rio Branco era um bairro operário raiz:
casas simples, chão de terra em alguns trechos, cheiro de café coado invadindo a manhã e o rádio ligado sempre muito alto.

E foi ali que a democracia decidiu bater à porta.

O salão paroquial da Comunidade de Nossa Senhora das Graças foi aberto para receber os candidatos do PMDB, liderados por Franco Montoro — o homem que simbolizava esperança, dignidade e aquela força tranquila que só estadistas de verdade têm. Quercia senador, Ulisses deputado e tantos outros historicos do partido.

E então chegou o dia.
As portas se abriram.
O salão encheu.

E eu, um garoto, vivendo um momento histórico sem saber que aquilo seria contado nos livros no futuro.


Bellacosa Mainframe e vote no MDB 15

🤝 Quando Conheci Covas e FHC

Ali, na simplicidade de um bairro operário, eu vi chegar Mário Covas — forte, direto, sem rodeios.
E Fernando Henrique Cardoso, com seu jeito professoral, explicando o país como quem traduz o manual do sistema operacional para um usuário avançado.

A velha guarda do MDB estava lá para organizar cabos eleitorais, explicar propostas, distribuir material…
e preparar a militância para o 15 de Novembro de 1982, data que respirava esperança.

Para mim, era um parque de diversões político:

  • camisetas;

  • bandeirolas;

  • santinhos voando como confete;

  • bottons que grudávamos no peito com orgulho;

  • chaveiros que viravam tesouro infantil.

E, claro, o treinamento para o futuro boca de urna.
Era quase um RPG da democracia.


Bellacosa Mainframe e a chegada do Lula
❤️ E então apareceu o PT… pequenininho, mas cheio de fogo

Numa dessas reuniões e visitas de candidatos, surgiu também um grupo novo, pequeno, barulhento, cheio de vida: o PT.
E entre eles… Lula.

Não era mito, nem presidente, nem figura pop.
Era só o Lula sindicalista cheio de energia, barba negra, voz rasgada e um carisma que dava trabalho até para os adversários.

E o mais incrível:
mesmo meus pais sendo mdbistas convictos, ajudaram o pessoal do PT quando o padre autorizou uma barraquinha na quermesse para arrecadar fundos.

Era um tempo em que adversário não era inimigo.
Era só alguém que acreditava no mesmo país por caminhos diferentes.


Bellacosa Mainframe participando da quermesse e ajudando o PT
🍢 Meu Primeiro Trabalho Voluntário pela Democracia

O padre liberou o espaço.
O PT montou a barraquinha.
Os militantes correram.
E eu, esse escriba que vos tecla…
fui parar no caixa.

Conferindo troco.
Vendendo refrigerante, pastel, vinho quente.
Ajudando gente grande a fazer política de forma doce — literalmente.

Foi ali que fiz meu primeiro trabalho voluntário.
E sem entender metade de nada, eu já estava do lado certo da história:
o lado de quem queria escolher.


Bellacosa Mainframe e o PMDB abriu caminhos para a abertura politica

🗳️ 1982: O Ano em que o Brasil Respirou Fundo

A censura havia perdido força.
Os espiões já não rondavam tanto.
O medo diminuía.
As conversas ficavam mais longas.
As pessoas sorriam mais.

Em 1982, a democracia voltou a ter cheiro, cor e som.
E no dia 15 de Novembro, eu estava lá — pequeno, mas afiado — distribuindo santinhos, fazendo boca de urna com orgulho, vestindo camiseta do MDB, acreditando que o Brasil estava finalmente acordando.

Seria preciso mais de uma década para votar para presidente, é verdade.
Mas naquela tarde, o futuro já tinha começado.


Bellacosa Mainframe e o meu primeiro trabalho nas eleições ajudando com os santinhos do mdb

Easter Egg Bellacosa Mainframe

Se você procurar nos arquivos da época, muitas fotografias de campanha mostram crianças nas quermesses, com bandeiras e chaveiros.
Na Vila Rio Branco…
eu sou uma delas.

quinta-feira, 12 de abril de 2012

Representativeness Heuristic: Doctor Who, COBOL e o Dia em que o Incidente Parecia Tanto com Db2 que Ninguém Procurou em Outro Lugar

 

Bellacosa Mainframe e a representativeness heuristic

☕ Um Café no Bellacosa Mainframe

Representativeness Heuristic: Doctor Who, COBOL e o Dia em que o Incidente Parecia Tanto com Db2 que Ninguém Procurou em Outro Lugar

Uma viagem pela TARDIS dos incidentes para entender por que “ter cara de alguma coisa” pode ser suficiente para convencer nosso cérebro — mesmo quando taxas-base, contexto e evidências contam outra história

08:17.

Segunda-feira.

Café quente.

War Room ainda vazia.

Nosso jovem programador COBOL abre o dashboard.

PAYMENT RESPONSE TIME: +240%

Outro indicador:

TRANSACTION TIMEOUTS: +190%

Outro:

APPLICATION WAIT TIME: HIGH

O DBA entra.

Olha rapidamente.

— Db2.

Nosso jovem pergunta:

— Já encontrou lock?

— Ainda não.

— Thread presa?

— Ainda não.

— Log cheio?

— Não.

— Então por que Db2?

O DBA aponta para o gráfico.

— Tem cara de Db2.

Cinco minutos depois, chega outro especialista.

— O que temos?

— Db2.

— Ah, sim. Tem mesmo cara de Db2.

08:25.

O gerente entra.

— Causa?

— Db2.

— Confirmado?

Silêncio.

— Ainda não.

Mas nesse ponto a palavra já havia se espalhado pela War Room.

HIPÓTESE:
DB2

virou mentalmente:

CAUSA:
DB2

Nosso programador abre mais métricas.

DB2 LOCK WAIT: NORMAL
DB2 CPU: NORMAL
DB2 THREADS: NORMAL

Enquanto isso:

DOWNSTREAM API RESPONSE:
12.4 SECONDS

Ele aponta.

— E isso?

O DBA responde:

— Deve ser efeito.

— De quê?

— Do Db2.

— Mas o Db2 está normal.

Silêncio.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se entre duas mesas.

A porta abre.

O Doctor sai.

Olha para o dashboard.

Depois para o DBA.

— Por que é Db2?

— Porque parece.

O Doctor ergue a sobrancelha.

— Excelente.

— Excelente?

— Sim.

— Por quê?

— Porque “parece” é uma das formas favoritas do cérebro humano de transformar semelhança em certeza.

Pausa.

— Um lobo pode parecer um cachorro.

Mais uma pausa.

— Isso não significa que você deveria tentar fazer carinho.

Bem-vindo ao:



Representativeness Heuristic

Ou:

Heurística da Representatividade

A tendência de julgar a probabilidade de algo com base no quanto esse algo se parece com um exemplo típico, um estereótipo, uma categoria conhecida ou um padrão mental que já possuímos.

Em linguagem Bellacosa:

“Tem cara de X, então deve ser X.”

E isso pode ser muito útil.

Até não ser.


🌀 Nossa TARDIS dos incidentes já percorreu uma galáxia inteira

Até aqui encontramos:

Swiss Cheese Model — várias barreiras imperfeitas podem falhar juntas.

Normalization of Deviance — desvios repetidos viram rotina.

Hindsight Bias — depois do incidente tudo parece óbvio.

Confirmation Bias — buscamos provas para aquilo que já acreditamos.

Anchoring Bias — a primeira explicação pesa demais.

Groupthink — grupos inteligentes podem errar juntos.

Authority Gradient — hierarquia pode transformar dúvida em silêncio.

Plan Continuation Bias — continuamos planos que já perderam sentido.

Alarm Fatigue — alertas demais viram ruído.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — sistemas derivam lentamente para a borda.

Diffusion of Responsibility — todos veem e ninguém assume.

Normalcy Bias — acreditamos que tudo voltará ao normal.

Survivorship Bias — estudamos quem sobreviveu.

Base Rate Neglect — esquecemos a frequência real dos eventos.

Availability Heuristic — o que vem facilmente à memória parece mais provável.

Outcome Bias — bom resultado parece provar boa decisão.

Overconfidence Bias — acreditamos saber mais do que realmente sabemos.

Planning Fallacy — subestimamos tempo, esforço e complexidade.

Sunk Cost Fallacy — custo passado influencia demais a próxima decisão.

Status Quo Bias — o atual parece naturalmente mais seguro.

Present Bias — o conforto de hoje pesa mais que o custo de amanhã.

Optimism Bias — acreditamos que provavelmente tudo dará certo conosco.

Action Bias — agir parece melhor que esperar.

Omission Bias — não agir pode parecer menos culpável.

Loss Aversion — perder dói mais do que ganhar alegra.

Framing Effect — a forma de apresentar muda a decisão.

Recency Bias — o que aconteceu ontem recebe peso excessivo.

Agora chegamos a um mecanismo ainda mais básico:

nosso cérebro adora reconhecer padrões.

E ainda bem.

Sem isso, seria quase impossível trabalhar com sistemas complexos.

O problema aparece quando:

reconhecimento vira classificação prematura.


🧠 O que é uma heurística de representatividade?

Imagine que você vê:

um homem usando jaleco branco;

estetoscópio;

hospital.

Seu cérebro rapidamente pensa:

médico.

Faz sentido.

Você está usando:

características do exemplo

para associá-lo a uma categoria.

Isso é útil.

Muito útil.

Agora imagine:

ele é ator gravando publicidade.

O padrão parecia correto.

A categoria estava errada.

Essa é a armadilha.


☕ Bellacosa Mainframe: “tem cara de S0C7 clássico”

Você abre dump.

Programa terminou com:

S0C7

Seu cérebro pensa:

campo não numérico em operação decimal.

Excelente.

É uma hipótese forte.

Mas agora surge outro detalhe:

o erro ocorre após uma mudança de copybook.

Pode ser:

dados ruins;

layout incompatível;

offset errado;

overlay;

REDEFINES;

dados truncados.

O S0C7 “tem cara” de dado inválido.

Mas essa aparência não determina a origem do dado inválido.


🧠 Representatividade não é causalidade

Essa frase precisa ficar na parede:

Parecer com um padrão não prova que o mesmo mecanismo causou o evento.

Dois incidentes podem ter:

mesmo sintoma.

Mas causas completamente diferentes.

Exemplo:

TIMEOUT

pode ser:

Db2;

MQ;

rede;

API externa;

CPU;

thread pool;

deadlock;

aplicação.

O sintoma pertence a uma classe grande.

A heurística tende a procurar:

o membro mais prototípico.


👻 Easter Egg nº 1 — Cyberman ou funcionário de manutenção?

Companion:

— Doctor! Um Cyberman!

Doctor olha.

— Onde?

— Ali! Prateado! Capacete! Andando duro!

O Doctor observa.

— É um técnico de manutenção usando roupa térmica.

— Mas parecia tanto...

— Exatamente.

Pausa.

— O universo sobrevive porque às vezes esperamos mais cinco segundos antes de começar a gritar “Cyberman”.


🧠 Protótipos mentais

Nossa mente cria protótipos.

Por exemplo:

“incidente de Db2” pode ter:

locks;

timeouts;

transações esperando;

batch atrasado.

Então quando vemos:

timeouts;

espera;

lentidão,

pensamos:

Db2.

Mas talvez vários sistemas produzam a mesma assinatura superficial.

O problema não é possuir protótipo.

É esquecer que:

protótipo é atalho, não diagnóstico.


🧠 Representativeness Heuristic + Base Rate Neglect

Essa combinação é clássica.

Imagine:

apenas 5% dos incidentes de timeout são rede.

Mas o incidente atual possui uma característica “muito típica” de rede.

Nosso cérebro pode supervalorizar essa semelhança e esquecer:

95% historicamente vieram de outros lugares.

Base Rate Neglect diz:

esqueça a frequência.

Representativeness diz:

mas parece muito!

Resultado:

hipótese rara vira favorita.


📊 Exemplo Bellacosa

Histórico:

TIMEOUT INCIDENTS

DB2: 42%
APP: 30%
MQ: 15%
NETWORK: 8%
OTHER: 5%

Hoje:

timeouts + retransmissão.

Equipe:

rede!

Talvez.

Mas precisamos perguntar:

essa evidência é suficientemente específica para superar a taxa-base?

Se sim:

ótimo.

Se não:

a aparência está pesando demais.


🧠 Bayes volta pela porta dos fundos

Sem entrar em matemática pesada:

ANTES:
qual causa era mais provável?

DEPOIS:
o quanto essa evidência realmente favorece uma causa?

Representativeness Heuristic pula direto para:

“isso parece X.”

Pensamento melhor:

“isso parece X, mas X é comum neste contexto? E essa evidência discrimina X de Y e Z?”


☕ A diferença entre compatível e diagnóstico

Uma evidência pode ser:

compatível com Db2.

Isso não significa:

exclusiva de Db2.

Exemplo:

latência alta.

Compatível com:

quase tudo.

Então:

COMPATÍVEL
≠
DIAGNÓSTICO

Essa distinção salva War Rooms.


⚓ Representativeness + Anchoring Bias

O primeiro especialista diz:

— Parece Db2.

Pronto.

Agora temos:

representatividade criando hipótese;

anchoring prendendo investigação.

Outros dados passam a ser interpretados à luz do Db2.


🔎 Confirmation Bias entra logo depois

Agora buscamos:

lock;

SQL lenta;

thread.

Encontramos qualquer valor ligeiramente fora do normal.

— Viu?

Db2.

Enquanto:

API downstream está demorando 12 segundos.

A narrativa já foi escolhida.


👥 Groupthink transforma semelhança em consenso

Um DBA diz:

— Cara de Db2.

Outro:

— Também achei.

Aplicação:

— Realmente.

Agora:

três pessoas inteligentes concordando.

Mas talvez todas estejam usando o mesmo protótipo mental.

Groupthink não exige falta de inteligência.

Às vezes exige apenas:

modelos mentais compartilhados.


🪜 Authority Gradient

Especialista veterano:

— Já vi isso dezenas de vezes. É Db2.

Júnior observa:

MQ normal;

Db2 normal;

API ruim.

Mas pensa:

ele já viu muito mais que eu.

Silêncio.

Representatividade + experiência + autoridade.

Excelente maneira de matar uma hipótese alternativa.


🧠 Expertise é poderosa — mas também cria padrões fortes

O especialista desenvolve reconhecimento.

Isso geralmente melhora decisões.

Mas pode gerar:

pattern overreach

Quando um padrão conhecido é aplicado onde não cabe.

A pergunta útil:

“Quais elementos deste caso não combinam com o padrão anterior?”


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Tem cara de X.”

Pergunte:

“Quais características específicas fazem parecer X?”

Transforme sensação em evidência.


🎯 Pergunta Bellacosa nº 2

Depois:

“Essas características aparecem também em outras causas?”

Agora medimos poder discriminativo.


🎯 Pergunta Bellacosa nº 3

E:

“Qual evidência deveríamos ver se fosse realmente X?”

Muito útil.


🎯 Pergunta Bellacosa nº 4

Finalmente:

“Qual dado faria abandonarmos X?”

Se resposta:

nenhum,

não temos hipótese.

Temos casamento.


🧠 Representativeness Heuristic + Recency Bias

Nosso último capítulo entra imediatamente.

Último incidente:

Db2.

Novo incidente:

parece parecido.

Agora:

Recency:

aconteceu recentemente.

Representativeness:

tem a mesma cara.

Perfeito.

A primeira hipótese fica quase irresistível.


🧠 Availability Heuristic também

O caso de Db2 foi traumático.

Está fresco.

É fácil lembrar.

E o atual parece parecido.

Agora temos três vieses trabalhando juntos:

  • Recency;

  • Availability;

  • Representativeness.

War Room premium edition.


🧠 O problema das narrativas perfeitas

Às vezes um incidente parece “bom demais” para determinada explicação.

Sintomas encaixam.

Timeline encaixa.

Até o nome do componente parece suspeito.

Cuidado.

Histórias coerentes dão conforto.

Mas sistemas complexos podem produzir coincidências.


☕ O diagnóstico estilo House

House vê sintoma.

Hipótese.

Testa.

Falha.

Nova hipótese.

O que ele não deveria fazer?

“Tem cara de lúpus, logo é lúpus.”

Aliás, segundo a tradição:

nunca é lúpus.

Até quando é.

Esse é justamente o problema com protótipos.


🧪 Hypothesis Testing

Representatividade deveria gerar:

hipótese.

Depois:

teste.

Exemplo:

HYPOTHESIS:
DB2 LOCK CONTENTION

EXPECT:
- lock waits high
- blocking thread visible
- affected transactions share resource

Observamos.

Se não aparece:

probabilidade cai.


🧠 Falsificação é uma habilidade operacional

Não procure só:

“como provar que estou certo?”

Procure:

“como posso rapidamente provar que estou errado?”

Isso acelera investigação.


💻 COBOL: exemplo prático

S0C7.

Hipótese:

campo inválido.

Você verifica:

input.

Tudo numérico.

Então não diga:

“Mas S0C7 é campo inválido.”

Sim.

Mas talvez o programa esteja lendo campo errado.

Agora procure:

offset;

copybook;

REDEFINES;

overlay.

O protótipo estava parcialmente certo.

A explicação superficial não.


🧠 Pattern decomposition

Em vez de:

“É S0C7 clássico.”

Desmonte:

  • qual instrução abendou?

  • qual campo?

  • qual valor?

  • qual origem?

  • qual layout?

Quanto mais detalhes:

menos dependência de estereótipo.


🧪 Signature Matching

Compare incidentes por múltiplas dimensões:

SYMPTOM
TIMING
COMPONENT
METRIC
CHANGE
VOLUME
ERROR CODE
DEPENDENCY

Se apenas:

“timeout”

é igual,

não são necessariamente o mesmo incidente.


🧠 Similaridade superficial versus estrutural

Dois eventos podem ser superficialmente parecidos:

timeout.

Mas estruturalmente diferentes:

um por lock;

outro por retry storm.

Representativeness Heuristic frequentemente privilegia aparência superficial.


☕ Bellacosa: o job lento

Job A demorou 3 horas porque dataset cresceu.

Job B demora 3 horas.

Equipe:

dataset cresceu de novo.

Mas Job B tem mesmo volume.

CPU baixa.

I/O normal.

Na verdade espera recurso externo.

Mesmo tempo.

Outra causa.


🧠 Stereotyping tecnológico

Isso também aparece entre tecnologias.

Exemplo:

“Java consome memória.”

Então qualquer memória alta:

Java.

“Db2 é gargalo.”

Qualquer lentidão:

Db2.

“Mainframe é caro.”

Qualquer custo:

mainframe.

Esses rótulos podem virar representativeness heuristics organizacionais.


🧠 Legacy = velho = ruim?

Framing Effect já mostrou isso.

Representativeness acrescenta:

algo que possui características “de legado” pode ser classificado mentalmente como:

difícil;

caro;

obsoleto.

Mesmo sem medir.

Um sistema antigo pode ser excelente.

Um sistema novo pode ser péssimo.

Protótipo não decide.


☕ “Microserviço moderno”

Palavra moderna.

Docker.

Kubernetes.

API.

Então:

escalável.

Talvez.

Ou um monólito distribuído com Wi-Fi emocional.

Representatividade também funciona a favor do “novo”.


🧠 Shiny Object + Representativeness

Tecnologia parece com exemplos de empresas bem-sucedidas.

Logo:

se adotarmos, teremos resultados parecidos.

Não necessariamente.

Survivorship Bias entra.

Contexto importa.


🧠 Representativeness + Survivorship Bias

Você observa empresas de sucesso.

Todas usam arquitetura X.

Conclusão:

X parece “arquitetura de empresa bem-sucedida”.

Agora qualquer empresa usando X parece moderna.

Mas onde estão:

empresas usando X que falharam?

Survivorship Bias esconde.

Representativeness transforma características dos sobreviventes em receita.


🧠 Startup uniform

É quase caricatura:

cloud;

microservice;

React;

Kubernetes;

AI.

Parece startup moderna.

Mas aparência arquitetural não garante:

unit economics;

produto;

confiabilidade.

O cérebro adora pacotes reconhecíveis.


📊 Correlation ≠ category certainty

Representatividade pode exagerar correlação.

Se muitos casos de fraude possuem comportamento X:

vemos X

e pensamos:

fraude.

Mas talvez milhões de casos legítimos também tenham X.

Base Rate de novo.


🏦 Fraude bancária

Transação:

valor alto;

novo dispositivo;

horário incomum.

“Tem cara de fraude.”

Pode ser.

Mas:

quantas transações legítimas têm essas características?

Sem isso:

heurística domina.


🔐 Segurança

Login de país diferente.

Parece ataque.

Talvez VPN.

Parece credential stuffing.

Talvez cliente viajando.

Threat detection precisa combinar sinais.

Não estereótipo.


🤖 IA e Representativeness

Modelos classificadores literalmente trabalham com padrões.

Mas humanos podem interpretar score como:

“parece malware, então é malware.”

Precisamos:

precision;

recall;

base rates;

explainability.

Automation Bias pode amplificar Representativeness.


🧠 “AI says it looks like...”

Ferramenta:

SIMILARITY TO INCIDENT CLASS:
92%

Pergunta:

semelhança em quê?

Sintomas?

Logs?

Causa?

Contexto?

Similarity não é causalidade.


🔍 Embeddings e similaridade

Em sistemas de busca por embeddings:

dois incidentes podem estar próximos semanticamente.

Útil.

Mas proximidade vetorial não significa:

mesma root cause.

Representativeness automatizada ainda precisa de validação.


☕ RAG operacional

Você consulta incidentes similares.

Os top 5 eram Db2.

IA conclui:

Db2.

Talvez retrieval trouxe apenas casos semanticamente parecidos, não estatisticamente representativos.

Pergunte:

qual universo?

qual taxa-base?

quais casos alternativos?


🧠 Framing + Representativeness

Título:

“Possible database bottleneck.”

Pronto.

Toda leitura passa por frame de database.

Visual + protótipo.

Cuidado com labels prematuros.


🧠 Label Leakage

Se dashboard diz:

DATABASE INCIDENT

antes de RCA,

a classificação vira influência.

Melhor:

SYMPTOM:
TRANSACTION LATENCY

Até confirmar.


☕ Sintoma não é causa

Uma das regras principais desta série:

TIMEOUT = SINTOMA
SLOW = SINTOMA
ABEND = SINTOMA
QUEUE = SINTOMA

Causa precisa ser investigada.


🧠 Diagnostic overshadowing

Quando um rótulo conhecido domina análise, outros sinais podem ser ignorados.

Em TI:

“É problema de performance.”

Tudo passa a ser performance.

Mas talvez seja integridade.

Classificação ampla demais pode esconder detalhes.


🧪 Competing Hypotheses

Defesa poderosa:

não mantenha uma hipótese.

Mantenha algumas.

Exemplo:

H1 DB2
H2 DOWNSTREAM API
H3 MQ

Para cada:

evidência a favor;

evidência contra.


📊 Hypothesis Table

H1 DB2
FOR:
timeout
AGAINST:
lock wait normal

H2 API
FOR:
response 12s
AGAINST:
only one endpoint affected

H3 MQ
FOR:
retries
AGAINST:
queue depth normal

Agora “parece” perde poder mágico.


🧠 Representativeness + Action Bias

Algo parece Db2.

Ação:

restart pool.

Ainda nem confirmamos.

Action Bias transforma padrão mental em intervenção.

Perigoso.


🧠 Omission Bias também

Algo “não parece grave”.

Então não agimos.

Representatividade pode classificar erroneamente severidade.

Exemplo:

alerta parece falso positivo habitual.

Mas desta vez não é.


🔔 Alarm Fatigue

Alertas falsos repetidos criam protótipo:

esse alerta = ruído.

Novo alerta real chega.

Parece igual.

Representativeness + Alarm Fatigue.

Muito perigoso.


🧠 Normalcy Bias

Sintoma parece com pequenas instabilidades anteriores.

Então:

vai passar.

O protótipo “incidente leve” vence sinais de escalada.


🌀 Drift Into Failure

Mudanças graduais parecem com operação normal.

Porque cada ponto individual ainda pertence ao protótipo:

“normal.”

Mas tendência saiu da zona segura.

Representatividade pode ocultar drift ao comparar cada momento com um estereótipo fixo.


📈 Distribution Shift

Sistema mudou.

Mas nosso protótipo mental não.

Agora classificamos eventos novos usando categorias antigas.

Esse é um problema importante.


🧠 Concept Drift

Em machine learning existe ideia de concept drift:

a relação entre sinais e classes pode mudar ao longo do tempo.

Em operação:

o que significava timeout em arquitetura antiga pode ser diferente na nova.

Protótipos precisam ser atualizados.


☕ História precisa de versionamento

“Esse alerta sempre significa X.”

Sempre em qual versão?

Antes ou depois da migração?

Antes ou depois do novo fornecedor?

Contexto importa.


🎯 Pergunta Bellacosa nº 5

“Nosso padrão mental ainda representa o sistema atual?”

Excelente para veteranos.


🧠 Representatividade social

O viés também pode aparecer na avaliação de pessoas.

“Programador COBOL veterano” parece:

conservador.

“Dev jovem” parece:

inovador.

Talvez.

Talvez não.

Estereótipos são representativeness heuristics aplicadas a gente.

Em equipes:

isso pode distorcer contratação, promoção e distribuição de trabalho.


🧠 Não transforme arquétipo em pessoa

Um júnior pode perceber algo que veterano não viu.

Veterano pode dominar nova tecnologia.

Categoria não determina indivíduo.

Em incidentes:

ouça evidência.

Não crachá.


👥 Authority Gradient + Representatividade de papel

“DBA entende banco.”

Sim.

“Então opinião do DBA sobre qualquer problema de banco é automaticamente correta.”

Não.

Expertise aumenta peso da hipótese.

Não elimina validação.


☕ O título não compila código

Nem badge.

Nem cargo.

Nem barba branca.

Embora barba branca ajude bastante na aparência de sysprog lendário.


🧠 Story coherence

Representativeness Heuristic gosta de histórias coerentes.

Se:

sistema lento;

Db2 conhecido por lock;

DBA recentemente ajustou índice,

pronto:

temos novela.

Mas talvez mudança real tenha sido API externa.

Histórias plausíveis não são evidência.


📚 Sherlock Holmes operacional

O objetivo não é:

achar explicação plausível.

É:

achar explicação que sobreviva aos fatos melhor que as alternativas.


🧪 Differential Diagnosis

Medicina usa diagnóstico diferencial.

TI deveria usar mais.

Sintoma:

timeout.

Diferenciais:

  • Db2;

  • MQ;

  • rede;

  • API;

  • aplicação;

  • storage.

Depois elimina.

Isso é muito House MD.


☕ House entra na TARDIS

House olha para o monitor.

— Db2.

Doctor:

— Evidência?

— Parece.

Doctor:

— Isso não é evidência.

House:

— Todo mundo mente.

Doctor:

— Inclusive heurísticas.

Agora precisamos de outra série.


🧠 Triage versus RCA

Representatividade é ótima para:

triagem.

Preciso começar em algum lugar.

Use padrão.

Mas RCA exige:

prova mais forte.

Regra:

Heurística escolhe onde olhar primeiro. Evidência decide onde parar.

Essa talvez seja a frase do capítulo.


📊 Confidence Levels

Diga:

HYPOTHESIS:
DB2

CONFIDENCE:
40%

REASON:
symptom similarity

NEXT TEST:
lock analysis

Muito melhor que:

“É Db2.”


🧠 Language matters

Palavras:

“parece”;

“provavelmente”;

“confirmado”

precisam ser diferentes.

War Room madura usa níveis de certeza.


📝 Evidence Ladder

SUSPEITA
↓
HIPÓTESE
↓
EVIDÊNCIA FORTE
↓
CONFIRMADO

Não pule degraus.


☕ “Provavelmente” não vira “confirmado” por repetição

Se cinco pessoas repetem:

provavelmente Db2,

não temos cinco evidências.

Temos uma hipótese repetida cinco vezes.

Importante.


👥 Independent assessment

Antes de compartilhar hipótese dominante:

peça análise independente.

DBA.

Aplicação.

Middleware.

Depois compare.

Isso reduz contágio mental.


🧠 Representativeness + Groupthink contamination

Uma pessoa fala cedo:

Db2.

Agora outras análises ficam enviesadas.

Talvez faça sentido coletar primeiras impressões separadamente.


🎯 Silent Start

Primeiros cinco minutos:

cada especialista anota:

hipótese;

evidência.

Depois compartilha.

Excelente técnica.


🧪 How to combat Representativeness Heuristic

Passo 1 — Nomeie o padrão percebido

“Parece com X.”


Passo 2 — Explique por quê

Quais sinais?


Passo 3 — Verifique taxa-base

X é comum?


Passo 4 — Procure causas alternativas

Pelo menos duas.


Passo 5 — Procure evidência discriminante

O que separa X de Y?


Passo 6 — Procure evidência contrária

O que não combina?


Passo 7 — Compare contexto

Versão?

Volume?

Mudanças?


Passo 8 — Use histórico estruturado

Não apenas casos memoráveis.


Passo 9 — Atualize confiança

Com dados.


Passo 10 — Só então classifique

Sintoma primeiro.

Causa depois.


📋 Checklist anti-Representativeness Heuristic

[ ] Estou dizendo “tem cara de X”?

[ ] Quais sinais exatamente lembram X?

[ ] Esses sinais também aparecem em outras causas?

[ ] Qual é a taxa-base de X?

[ ] Tenho evidência específica ou só semelhança?

[ ] O último incidente está influenciando?

[ ] Existem dados que contradizem X?

[ ] Qual hipótese alternativa explica os mesmos sinais?

[ ] O sistema mudou desde o padrão original?

[ ] Estou confundindo sintoma com causa?

[ ] A ferramenta mostrou similaridade ou causalidade?

[ ] Estamos usando estereótipo tecnológico?

[ ] Estamos classificando pessoa pela função em vez da evidência?

[ ] Que teste poderia falsificar nossa hipótese?

🧠 Curiosidade: Linda Problem

Existe um experimento clássico da psicologia associado a Kahneman e Tversky.

Pessoas recebem descrição detalhada de uma personagem chamada Linda, com características que parecem combinar com determinado perfil.

Depois avaliam quais afirmações parecem mais prováveis.

Muitas pessoas escolhem uma opção mais específica porque ela parece mais representativa da descrição, mesmo violando regras básicas de probabilidade.

A lição:

uma história que combina muito bem com um estereótipo pode parecer mais provável que uma opção estatisticamente mais simples.

Isso é profundamente relevante para RCA.


☕ O incidente “bonito demais”

Hipótese:

ataque sofisticado.

Sintomas:

estranhos.

Narrativa:

perfeita.

Mas base rate:

quase zero.

Enquanto:

erro de configuração

é cem vezes mais comum.

O cérebro gosta da história interessante.

Produção gosta da causa real.


🧠 Narrative Bias no horizonte

Nosso cérebro ama histórias.

Talvez um futuro capítulo.

Porque histórias coerentes competem bem contra estatística.

Representativeness é um ingrediente.


🔐 Cybersecurity e “cara de APT”

Comportamento sofisticado.

Alguém:

“Parece APT.”

Talvez.

Mas ransomware comum também pode produzir sinais parecidos.

Não escale narrativa antes da evidência.


🧠 Attribution escalation

Primeiro:

anomalia.

Depois:

ataque.

Depois:

APT.

Depois:

nação-estado.

Tudo em 12 minutos.

War Room cinematográfica.

Talvez seja certificado expirado.


☕ O universo frequentemente é menos glamouroso

Você espera:

hacker internacional.

Encontra:

senha vencida.

Você espera:

corrupção de storage.

Encontra:

dataset full.

Você espera:

bug quântico.

Encontra:

campo PIC errado.

Isso é saudável.


💻 COBOL e o poder da banalidade

Muitas falhas são:

dados;

layout;

índice;

campo;

condição.

Não subestime o banal só porque o caso parece dramático.

Base rates gostam de banalidade.


🧠 Occam versus Representativeness

Navalha de Occam não significa:

“sempre escolha causa simples.”

Mas recomenda não multiplicar hipóteses desnecessariamente.

Representativeness pode levar a causa cinematográfica porque encaixa num padrão memorável.

Occam pergunta:

precisamos mesmo disso tudo?


📊 Pareto de causas

Mantenha Pareto.

Exemplo:

80% de S0C7 vêm de três classes.

Então comece por elas.

Mas não pare nelas se evidência contradiz.


🧠 Frequency + Fit

Uma forma simples de priorizar hipótese:

frequência histórica + compatibilidade atual.

Não apenas:

compatibilidade visual.


☕ Bellacosa Hypothesis Score

Brincando:

SCORE =
BASE RATE
+
CURRENT EVIDENCE
+
CONTEXT MATCH
-
CONTRARY EVIDENCE

Não precisa virar fórmula matemática literal.

Mas a mentalidade ajuda.


🤖 IA e classificações

Um agente pode dizer:

87% similar to incident DB2-2025-017.

Humano precisa perguntar:

  • por que?

  • que campos?

  • quais diferenças?

  • qual confiança histórica?

  • existem outras classes próximas?

Similarity score é ponto de partida.


🧠 Explainability operacional

Uma boa ferramenta deveria dizer:

SIMILAR BECAUSE:
- same error code
- same wait pattern
- same application

DIFFERENT BECAUSE:
- DB2 locks normal
- new API dependency

Isso é muito mais útil que:

“Likely DB2.”


🔎 Retrieval diversity

Se sistema RAG só traz cinco casos parecidos de Db2:

IA ficará presa.

Busque:

casos semelhantes com causas diferentes.

Contraexemplos são valiosos.


🧠 Contrastive Search

Pergunte:

“Mostre incidentes com estes mesmos sintomas que NÃO eram Db2.”

Fantástico.

Isso combate Representativeness + Confirmation.


🎯 Bellacosa AI Prompt

“Quais causas diferentes podem produzir esta mesma assinatura superficial?”

Uma das melhores perguntas para IA operacional.


🧠 False Friends dos incidentes

Como palavras parecidas em idiomas que significam coisas diferentes.

Sintomas também possuem falsos amigos.

“Timeout” parece igual.

Mas mecanismo muda.

“High CPU” parece causa.

Talvez seja consequência.

“Queue depth” parece gargalo.

Talvez seja efeito.

Nunca se apaixone pela aparência.


🧬 Regeneração organizacional

Uma organização madura contra Representativeness Heuristic aprende a:

separar sintoma de causa;

registrar taxas-base;

manter históricos comparáveis;

usar hipóteses concorrentes;

procurar contraexemplos;

exigir evidência discriminante;

controlar linguagem de certeza;

revisar padrões após mudanças de arquitetura;

e tratar similaridade de IA como auxílio, não veredito.

Principalmente:

ela aprende que:

“parece” é uma excelente maneira de começar uma investigação e uma péssima maneira de encerrá-la.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Representativeness Heuristic é a tendência de julgar probabilidade pela semelhança com um padrão conhecido.

Parecer com uma causa não prova que seja essa causa.

Sintomas semelhantes podem surgir de mecanismos diferentes.

Base Rate Neglect torna a heurística mais perigosa quando ignoramos a frequência real.

Recency e Availability podem tornar um padrão recente mais representativo mentalmente do que ele realmente é.

Anchoring transforma a primeira classificação em prisão.

Confirmation Bias começa a procurar provas para o padrão escolhido.

Especialistas também sofrem porque expertise cria protótipos muito fortes.

Similaridade de IA, embeddings ou casos passados não é causalidade.

Contraexemplos e hipóteses concorrentes são antídotos poderosos.

A heurística é ótima para triagem; RCA exige evidência.

E principalmente:

Use padrões para saber onde olhar. Use evidências para decidir o que realmente está acontecendo.


🕰️ De volta às 08:17

War Room.

Dashboard:

TIMEOUT +190%

DBA:

— Db2.

Nosso programador responde:

— Pode ser.

— Você não acha?

— Acho possível.

Ele abre uma tabela:

H1 DB2
FOR:
timeouts
AGAINST:
locks normal
CPU normal

H2 API
FOR:
response 12.4s
same timeline
AGAINST:
only some transactions

H3 MQ
FOR:
retry increase
AGAINST:
queue depth normal

O Doctor sorri.

— Agora sim.

O DBA olha para a API.

Descobrem:

um fornecedor externo havia implantado mudança às 08:00.

Resposta passou de:

300ms

para:

12 segundos.

O sistema interno estava esperando.

Db2 estava apenas acumulando transações.

Consequência.

Não causa.

O DBA ri.

— Mas parecia muito com Db2.

Nosso programador responde:

— Parecia.

O Doctor completa:

— Um bom disfarce só precisa parecer verdadeiro tempo suficiente.


🥚 Easter Egg final

Na manhã seguinte surge:

BELLACOSA.BIAS(REPRESENT)

Dentro:

       IF CURRENT-CASE
          LOOKS-LIKE KNOWN-PATTERN
           PERFORM CHECK-BASE-RATE
           PERFORM CHECK-ALTERNATIVES
       END-IF.

       IF SIMILARITY = HIGH
          AND EVIDENCE = LOW
           MOVE 'HYPOTHESIS'
             TO CLASSIFICATION
       END-IF.

       IF CONTRARY-EVIDENCE > ZERO
           PERFORM UPDATE-BELIEF
       END-IF.

Comentário:

* LOOKS-LIKE IS NOT IS.

Outro:

* SIMILARITY STARTS THE SEARCH.
* EVIDENCE ENDS IT.

Mais um:

* A TIMEOUT HAS MANY PARENTS.

E naturalmente:

* BAD WOLF LOOKED VERY REPRESENTATIVE.
* THAT WAS PART OF THE PROBLEM.

Nosso jovem fecha o membro.

Pouco depois alguém chama:

— Temos S0C7. Dado inválido.

Ele responde:

— Provavelmente.

— Provavelmente?

— Qual instrução?

— Ainda não vimos.

— Então temos um S0C7.

— E?

— Primeiro descrevemos o que sabemos.

Pausa.

— Depois deixamos o sistema nos contar por quê.

Abrem o dump.

Não era input ruim.

Copybook antigo.

Offset deslocado.

O S0C7 tinha perfeitamente a aparência do padrão conhecido.

Mas a causa estava escondida um nível abaixo.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

A semelhança é uma pista. A frequência dá contexto. A evidência decide.

E talvez essa seja a grande lição da Representativeness Heuristic:

não abandone seus padrões mentais — apenas impeça que eles tenham permissão para encerrar a investigação antes dos dados.

☕🌀

Next stop: Narrative Bias — quando uma história bem contada parece tão coerente que passamos a preferi-la a uma explicação mais feia, mais banal e muito melhor sustentada pelos dados.

segunda-feira, 9 de abril de 2012

Cobra Effect: Doctor Who, COBOL e o Dia em que Pagamos para Resolver o Problema — e Descobrimos que Estávamos Financiando o Próprio Problema

 

Bellacosa Mainframe e o cobra effect

☕ Um Café no Bellacosa Mainframe

Cobra Effect: Doctor Who, COBOL e o Dia em que Pagamos para Resolver o Problema — e Descobrimos que Estávamos Financiando o Próprio Problema

Uma viagem pela TARDIS dos incidentes para entender como incentivos mal desenhados podem transformar boas intenções em comportamentos perfeitamente racionais, porém desastrosos para o sistema

08:11.

Segunda-feira.

War Room vazia.

Ainda bem.

Café quente.

Na tela, um novo programa corporativo:

PROGRAMA DE MELHORIA OPERACIONAL

OBJETIVO:
REDUZIR INCIDENTES REPETITIVOS

INCENTIVO:
R$ 500 POR INCIDENTE RESOLVIDO

META:
100 INCIDENTES / TRIMESTRE

Nosso jovem programador COBOL olha.

— Então quanto mais incidentes resolvermos, mais ganhamos?

O gerente responde:

— Exatamente.

— E se tivermos menos incidentes?

— Excelente para produção.

— Mas pior para a meta?

Silêncio.

O gerente pensa.

— Tecnicamente... sim.

Nosso jovem toma um gole de café.

— Então a melhor situação para a empresa é zero incidente.

— Claro.

— E a melhor situação para o programa de incentivo é ter muitos incidentes para resolver.

Silêncio maior.

Um especialista de operações comenta:

— Isso parece estranho.

Na semana seguinte, os números aparecem:

INCIDENTES REGISTRADOS:
+42%

INCIDENTES RESOLVIDOS:
+51%

BÔNUS DISTRIBUÍDOS:
+63%

O diretor sorri.

— O programa está funcionando!

Nosso jovem pergunta:

— E a estabilidade?

Outra tela:

REINCIDÊNCIA:
+28%

MANUAL WORKAROUNDS:
+37%

CUSTOMER IMPACT:
+19%

Silêncio.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado do dashboard.

A porta abre.

O Doctor sai.

Olha para os números.

— Vocês queriam menos incidentes?

— Sim.

— Então começaram a pagar por incidente resolvido?

— Sim.

— E agora há mais incidentes?

— Sim.

O Doctor sorri.

— Maravilhoso.

— Maravilhoso?!

— Vocês acabaram de transformar o problema em uma oportunidade econômica.

Pausa.

— Nunca subestime a criatividade de um sistema quando você paga para que uma variável exista.

Bem-vindo ao:



Cobra Effect

Ou:

Efeito Cobra

E ao conceito mais amplo:

Perverse Incentives

ou:

Incentivos Perversos

A ideia é simples:

criamos um incentivo para resolver um problema, mas o incentivo altera o comportamento das pessoas de forma que o problema aumenta, muda de forma ou passa a ser produzido deliberadamente ou indiretamente.

Em linguagem Bellacosa:

“Se você paga por cobra morta, não se surpreenda quando alguém descobrir que criar cobras é um modelo de negócio.”


🐍 De onde vem o nome Cobra Effect?

A história mais famosa associada ao termo conta que, durante o período colonial britânico na Índia, teria sido criada uma recompensa por cobras mortas para reduzir a população desses animais.

A lógica parecia perfeita:

MAIS COBRAS MORTAS
=
MENOS COBRAS VIVAS

Mas apareceu uma adaptação.

Algumas pessoas teriam começado a:

criar cobras

para depois matá-las e receber a recompensa.

Quando o programa terminou, as cobras criadas deixaram de ter valor econômico e teriam sido soltas.

Resultado:

mais cobras do que antes.

A história é frequentemente usada como ilustração de incentivos perversos. O ponto importante não é decorar o caso histórico como uma lei universal, mas entender o padrão:

o incentivo mudou a economia do problema.


☕ O sistema responde ao que você recompensa

Essa é a lição central.

Gestão diz:

“Queremos X.”

Mas paga por:

Y.

As pessoas aprendem:

Y.

Não precisa existir fraude.

Muitas vezes comportamento é:

perfeitamente racional.


🧠 Cobra Effect versus Goodhart

Goodhart diz:

“Quando uma métrica vira meta, ela perde qualidade como medida.”

Cobra Effect vai além.

Agora o incentivo pode:

criar mais daquilo que queríamos eliminar.

Exemplo:

Goodhart:

meta = fechar tickets.

Equipe fecha rapidamente.

Cobra Effect:

pagamento por ticket resolvido.

Agora existe incentivo econômico para:

mais tickets existirem.


🧠 Campbell entra junto

Se carreira, bônus ou verba dependem:

da métrica,

pressão aumenta.

Goodhart:

métrica distorce.

Campbell:

pressão institucional aumenta distorção.

Cobra:

incentivo pode gerar o próprio problema.

Uma bela família disfuncional.


☕ Bellacosa Mainframe: o bônus do bug

Imagine:

empresa quer melhorar qualidade.

Cria:

BÔNUS:
R$ 100 POR BUG ENCONTRADO

Parece ótimo.

QA encontra mais bugs.

Excelente.

Mas existe uma pergunta desconfortável:

quem escreve o código também pode encontrar os bugs?

Se sim...

teoricamente, alguém poderia:

criar defeitos simples;

registrar;

corrigir;

receber.

Não precisa acontecer.

Mas o sistema agora:

tornou isso economicamente possível.


👻 Easter Egg nº 1 — O Dalek empreendedor

Dalek:

— REWARD: ONE CREDIT FOR EVERY DESTROYED DALEK.

Doctor:

— Isso parece ruim.

Dalek:

— WHY?

Doctor:

— Porque vocês também fabricam Daleks.

Silêncio.

Dalek:

— BUSINESS MODEL DETECTED.

Nunca dê incentivo econômico sem perguntar:

quem controla a oferta do problema?


🎯 Pergunta Bellacosa nº 1

“Quem recebe o incentivo consegue influenciar a quantidade do problema que está sendo recompensado?”

Essa é a primeira pergunta.

Se sim:

atenção.


🧠 Incidentes pagos

Empresa terceiriza suporte.

Contrato:

paga por ticket.

Mais tickets:

mais receita.

Cliente quer:

menos tickets.

Fornecedor recebe:

mais quando há mais tickets.

Principal-Agent Problem.

Agora o incentivo pode ser perverso.

Não significa que fornecedor criará incidentes.

Mas pode haver:

menos incentivo estrutural para eliminar causas raiz.


☕ Ticket recorrente é receita recorrente

Uma frase horrível.

Mas economicamente possível.


🧠 Root Cause versus workaround

Imagine:

resolver ticket:

15 minutos.

Eliminar causa raiz:

40 horas.

Contrato paga:

por ticket fechado.

Qual caminho parece melhor economicamente?

Para cliente:

root cause.

Para fornecedor:

talvez tickets repetidos.

Essa é uma estrutura de incentivo ruim.


🧠 Moral Hazard retorna

Se cliente paga custo dos incidentes e fornecedor recebe por atendimento:

parte do downside fica com cliente.

Principal-Agent + Moral Hazard + Cobra Effect.

Agora temos:

um ecossistema perfeito para o problema sobreviver.


☕ O gremlin ganhou contrato de manutenção


🧠 Cobra Effect não exige má-fé

Esse ponto é fundamental.

Às vezes ninguém:

cria problema de propósito.

Mas o incentivo reduz vontade de eliminar a fonte.

Isso é suficiente.

Exemplo:

equipe ganha recursos extras quando backlog passa de 1.000 tickets.

Então:

backlog alto traz orçamento.

Agora reduzir backlog demais:

ameaça orçamento.

Ninguém precisa criar ticket falso.

Só não existe tanta urgência em eliminar estruturalmente.


🧠 Budget incentives

Área diz:

— Precisamos gastar todo orçamento até dezembro.

Por quê?

— Se não gastarmos, ano que vem cortam.

Então:

gasta.

Objetivo original do orçamento:

usar recursos onde necessário.

Incentivo real:

não devolver dinheiro.

Esse é um clássico incentivo perverso.


☕ Dezembro corporativo

A época em que surgem necessidades misteriosas de última hora.


🧠 Use-it-or-lose-it

Se orçamento não usado é:

perdido,

gestores aprendem:

usar tudo.

A empresa talvez queria:

eficiência.

O mecanismo incentiva:

despesa.

Cobra Effect econômico.


🧠 Goodhart de orçamento

Meta:

100% orçamento utilizado.

Resultado:

100%.

Valor gerado?

Outra pergunta.


🧠 Cobra Effect em segurança

Programa:

paga por vulnerabilidade encontrada.

Bug bounty é bom?

Pode ser excelente.

Porque o desenho possui:

regras;

escopo;

validação.

Mas imagine sistema interno mal desenhado:

desenvolvedor pode criar vulnerabilidade e depois “descobrir”.

Agora incentivo está errado.


🔐 Bug bounty bem desenhado

Normalmente quem recompensa:

não quer que pesquisador tenha criado a vulnerabilidade.

Logo:

escopo e regras.

Isso mostra:

Cobra Effect não significa evitar incentivo.

Significa:

desenhar incentivo com comportamento adversarial em mente.


☕ Sempre faça Red Team do incentivo

Pergunte:

“Se eu quisesse ganhar o bônus sem resolver o objetivo real, o que faria?”

Essa é uma pergunta maravilhosa.


🎯 Pergunta Bellacosa nº 2

“Como uma pessoa inteligente poderia ganhar a recompensa sem produzir o resultado desejado?”

Esse é o teste principal.


🧠 Perverse Incentives em SLA

Fornecedor recebe bônus se:

uptime > 99,9%.

Mas penalidade por:

degradação é pequena.

Então pode priorizar:

não registrar downtime.

Ou:

manter serviço tecnicamente up

mesmo inutilizável.

Goodhart.

Campbell.

Principal-Agent.

Cobra? Talvez se o modelo fizer degradações mais lucrativas que correções estruturais.


🧠 SLA credits muito baixos

Se falhar custa:

R$ 10 mil

e prevenir custa:

R$ 1 milhão,

economicamente pode ser racional:

pagar multa.

O contrato queria:

garantir qualidade.

Criou:

preço da falha.

Se preço está baixo:

falhar vira opção.


☕ A multa virou tabela de preços

Isso é perigoso.


🧠 Incentive-Compatible Contracts

O contrato precisa tornar:

bom comportamento

economicamente razoável.

Se descumprir é:

mais barato que cumprir,

não espere mágica moral.


🧠 “Penalty” versus “Price”

Se multa é previsível e pequena:

pode virar custo operacional.

Então não controla.


🎯 Pergunta Bellacosa nº 3

“A penalidade realmente desincentiva o comportamento ou apenas precifica o comportamento?”

Excelente.


🧠 Cobra Effect em produtividade

Meta:

fechar 100 tickets.

Equipe começa:

quebrar ticket grande

em dez pequenos.

Produtividade:

10x.

Trabalho:

igual.

Isso é mais Goodhart.

Mas se bônus depende:

quantidade,

estrutura incentiva:

fragmentação artificial.

Perverse incentive.


☕ Ticket mitose

Uma célula vira dez.

Dashboard feliz.


🧠 Story Points

Se bônus depende:

story points,

estimativas crescem.

Se orçamento de equipe depende:

volume de pontos,

agora pontos maiores trazem recursos.

Incentivo para:

inflar.

Campbell + Goodhart.


🧠 Cobra Effect em bugs

Meta:

reduzir bug backlog.

Equipe encontra solução:

fecha bug como:

“won’t fix.”

Backlog cai.

Não gerou mais problema, então é Goodhart.

Mas imagine:

orçamento de manutenção cresce conforme bugs abertos.

Agora área pode preferir backlog alto.

Perverse incentive.


☕ O backlog virou patrimônio

Não deixe.


🧠 Recursos distribuídos por problema

Essa é uma fonte frequente.

Organização distribui dinheiro:

para quem tem mais problemas.

O incentivo involuntário:

problemas geram recursos.

Pode acontecer em:

IT;

governo;

educação;

saúde.

Precisamos equilibrar:

ajuda a quem precisa

sem tornar sucesso economicamente punitivo.


🧠 Success Penalty

Equipe melhora.

Incidentes caem.

Orçamento é cortado.

Equipe aprende:

melhoria traz perda de recurso.

Ano seguinte:

menos incentivo para melhorar.

Essa é cruel.


☕ “Parabéns por eficiência. Demitimos três.”

Mensagem estranha.


🧠 Incentive for inefficiency

Se eficiência sempre resulta:

em redução imediata de budget/headcount,

gestores podem esconder ganhos.

Por quê?

Porque eficiência vira:

ameaça.

A empresa quer:

melhoria.

O sistema incentiva:

ineficiência visível.


🧠 Automation paradox

Equipe automatiza.

Reduz esforço.

Gestão diz:

— Então podemos cortar equipe.

Próximo projeto de automação?

Talvez entusiasmo diminua.

Isso é incentivo perverso organizacional.


☕ Automatize e perca seu emprego

Excelente slogan para matar inovação.


🧠 Share the Gain

Uma defesa:

parte do benefício da eficiência

volta para:

equipe.

Mais capacidade.

Novos projetos.

Reconhecimento.

Agora automação deixa de ser ameaça.


🧠 Moral Hazard em automação

Se gestão captura todo ganho

e equipe absorve risco de implementação:

alinhamento ruim.

Principal-Agent.


🧠 Cobra Effect em incident management

Meta:

reduzir MTTR.

Bônus:

por incidente restaurado rapidamente.

Equipe aprende:

restart.

Causa não resolvida.

Incidente volta.

Agora:

mais incidentes.

Mais oportunidades de:

“resolver rapidamente.”

Esse é quase um Cobra Effect puro.


☕ Restart economy

Se toda madrugada gera um herói,

talvez alguém devesse consertar o despertador.


🧠 Hero Culture

Organização recompensa:

quem apaga incêndio.

Pouco reconhecimento:

para quem evita incêndio.

Resultado:

prevenção perde status.

Não significa que pessoas criam incidentes.

Mas estrutura:

torna incêndio mais visível e recompensado.


🧠 The Hero Incentive

Pessoa que corrige:

recebe aplauso.

Pessoa que faz preventive maintenance:

ninguém percebe.

Ao longo do tempo:

carreira pode favorecer:

reatividade.

Sistema fica:

mais frágil.


☕ O herói precisa do dragão

Mesmo sem criar dragões,

uma cultura que só recompensa heroísmo

não investe suficiente em:

muralhas.


🎯 Pergunta Bellacosa nº 4

“Estamos recompensando mais quem resolve incêndios do que quem impede que eles existam?”

Essa é uma das melhores para operação.


🧠 Prevention is invisible

Sem incidente:

não há história.

Survivorship Bias.

Availability Heuristic.

Trabalho preventivo some.

Precisamos:

torná-lo visível.


🧠 Metrics for prevention

Repeat incident reduction.

Automation.

Risk reduction.

Near miss closure.

Mas cuidado:

Goodhart.

Não existe métrica perfeita.


☕ Até prevenção pode virar jogo

O segredo é:

portfólio + contexto.


🧠 Cobra Effect em change management

Organização pune:

qualquer change que falha.

Equipe responde:

menos changes.

Technical debt cresce.

Incidentes futuros aumentam.

A meta queria:

menos change failure.

Produziu:

menos mudança útil

e mais risco acumulado.

Isso é incentivo perverso.


🧠 Zero-Risk Bias

“Zero failure.”

Agora change freeze.

Segurança antiga.

Vulnerabilidade.

Obsolescência.

Zero local cria:

risco global.


☕ A melhor forma de ter zero deploy failure

é:

zero deploy.

Péssima estratégia de longo prazo.


🧠 Risk Compensation também pode entrar

Novo rollback reduz risco.

Gestão aumenta:

escopo.

Já vimos.

Se bônus premia:

volume de mudanças,

novo controle pode acelerar:

risk-taking.

Incentivos interagem com proteção.


🧠 Cobra Effect em capacity

Meta:

reduzir utilização média de CPU.

Equipe pode:

mover processamento

para:

janela não medida.

Métrica melhora.

Total igual.

Goodhart.

Mas imagine cobrança interna por:

pico.

Times deslocam workload para:

outro sistema não tarifado.

Agora sobrecarrega outro lugar.

Perverse incentive sistêmico.


☕ O custo não sumiu

Mudou de LPAR.


🧠 Chargeback mal desenhado

Time paga:

CPU.

Não paga:

I/O.

Adivinhe o que será otimizado?

Pode trocar CPU por:

I/O pesado.

Custo local cai.

Sistema global talvez piora.

Principal-Agent.


🧠 Local Optimization

Sempre observe:

o que fica fora da conta.


🎯 Pergunta Bellacosa nº 5

“Qual custo ou risco fica invisível para quem responde ao incentivo?”

Muito importante.


🧠 Cobra Effect em cloud

FinOps cria meta:

reduzir compute.

Equipe desliga:

monitoring.

Logs.

Redundância.

Conta cai.

Risco sobe.

Métrica de custo:

verde.

Outcome:

ruim.

Mais Goodhart/perverse incentive.


🧠 Cost Optimization with Guardrails

Não:

“reduza 20%.”

Mas:

“reduza 20% mantendo SLO, RPO, security.”

Agora incentivo tem:

restrições.


☕ Economia sem contexto

é só amputação.


🧠 Cobra Effect em atendimento

Pague por:

chamadas atendidas.

Agente atende:

rápido.

Desliga.

Atende outra.

Volume sobe.

Resolução cai.

Isso é Goodhart.

Agora imagine empresa recebe subsídio por:

número de chamadas.

Pode não querer reduzir demanda.

Incentivo perverso maior.


🧠 Perverse Incentive ≠ fraude

Vamos insistir.

Às vezes comportamento:

segue exatamente regra.

A regra é que estava ruim.


IF BONUS > QUALITY

PERFORM BONUS

O programa humano executa.


🧠 Cobra Effect em segurança ofensiva

Meta:

quantidade de vulnerabilidades encontradas.

Red team passa a:

buscar muitas baixas.

Críticas difíceis:

menos.

Número sobe.

Risk reduction:

menor.

Goodhart.

Se bônus por count:

perverse incentive.


🧠 Weighted severity

Tenta corrigir.

Agora severity pode:

inflacionar.

Campbell.

Toda solução cria:

nova superfície.

Por isso precisamos:

julgamento.


🧠 Cobra Effect em compliance

Auditor encontra:

não conformidade.

Área recebe:

mais orçamento.

Pode existir incentivo para:

manter findings.

Ou consultoria é paga:

por finding corrigido.

Mais findings:

mais faturamento.

Potential misalignment.


☕ Auditoria não deveria precisar de pecado para sobreviver


🧠 Cobra Effect em consultorias

Consultoria cobra:

por projeto de correção.

Também faz:

diagnóstico.

Isso cria potencial conflito.

Não significa:

fraude.

Mas principal precisa:

independent validation.

Principal-Agent.


🧠 Independent Assessment

Para riscos grandes:

separe:

quem diagnostica

de:

quem vende remediação.

Quando possível.


🎯 Pergunta Bellacosa nº 6

“Quem diz que temos o problema também ganha dinheiro com a solução?”

Essa pergunta não acusa.

Só pede:

governança.


🧠 Cobra Effect em terceirização

Fornecedor recebe:

por horas.

Automação reduziria:

horas faturáveis.

Cliente quer:

automação.

Fornecedor pode ter incentivo menor.

Again:

não má-fé.

Modelo de contrato.


☕ Pagar por hora e pedir “reduza horas”

é uma conversa interessante.


🧠 Outcome-Based Contracts

Podem alinhar melhor.

Pagar por:

resultado.

Mas Goodhart:

como medir resultado?

Sempre trade-off.


🧠 No perfect contract

Contrato completo:

impossível.

Relational trust.

Shared KPIs.

Audit.

Swiss Cheese.


🧠 Cobra Effect em suporte interno

Time recebe headcount conforme:

ticket volume.

Se tickets caem:

perde pessoas.

Isso pode criar:

resistência a self-service.

Cliente quer:

menos ticket.

Equipe depende:

de ticket.

Modelo ruim.


☕ FAQ eficiente demais

ameaça orçamento.

Ótimo jeito de nunca ter FAQ.


🧠 Knowledge Base Incentive

Talvez recompense:

deflection de tickets

e:

customer satisfaction.

Agora incentivar:

resolver causa.


🧠 Automation Bonus

Equipe que automatiza:

mantém parte da capacidade

para novos trabalhos.

Assim sucesso não é:

punido.


🧠 Cobra Effect em staffing

Gestor pede:

mais pessoas

porque workload alto.

Se otimiza workload:

headcount cai.

Então:

workload alto protege poder.

Não precisa ser consciente.

Estrutura de incentivo.


☕ Tamanho do time como símbolo de status

Outro terreno.

Se promoção depende:

quantas pessoas você gerencia,

gestores podem querer:

mais headcount.

Empresa talvez queira:

times enxutos.

Desalinhamento.


🧠 Managerial empire building

Um conceito organizacional relacionado.

Quanto mais recursos:

mais poder.

Se incentivo de carreira é:

tamanho da organização,

eficiência pode:

ameaçar status.

Principal-Agent.


🧠 Cobra Effect em projetos

Projeto é pago:

por milestone.

Entrega:

milestone.

Qualidade:

depois.

Agora é racional:

otimizar milestone.

Se retrabalho vira:

novo change request pago,

mais interessante ainda.


☕ Bug como revenue stream

De novo:

péssimo desenho.


🧠 Acceptance Criteria

Contrato precisa:

incluir quality.

Warranty.

Defect liability.

Hypercare.

Isso reduz:

ganho com erro.


🧠 Warranty period

Fornecedor corrige defeitos:

sem nova cobrança.

Agora incentivo:

entregar melhor.

Align.


☕ Se bug gera nova fatura

não reclame da biologia evolutiva do bug.


🧠 Cobra Effect em políticas de segurança

Proibição excessiva:

usuário cria:

Shadow IT.

Controle queria:

reduzir risco.

Produziu:

mais risco invisível.

Isso é incentivo perverso, embora não exatamente bounty.

Need for Control + Cobra Effect.


🧠 Shadow IT as adaptation

Ferramenta oficial:

muito difícil.

Usuário:

Google Sheet.

Planilha local.

Script.

Resultado:

governança cai.

O incentivo era:

evitar processo lento.


☕ Toda barreira cria uma rota alternativa

Se pressão for alta.


🧠 Perverse Incentives broader than payments

Importante:

incentivo não precisa ser:

dinheiro.

Pode ser:

tempo;

status;

reputação;

comodidade;

promoção;

evitar punição.

Então Cobra Effect aparece:

mesmo sem recompensa financeira.


🧠 Negative Incentives

Punição também cria:

perversidade.

Meta:

zero incident.

Punição:

se incidente reportado.

Resultado:

menos reporting.

Sistema queria:

menos incidente.

Conseguiu:

menos informação.


☕ O alerta foi “resolvido”

removendo:

o mensageiro.


🧠 Campbell again

Quanto maior punição:

mais pressão para:

distortion.

Cobra Effect pode surgir quando:

problema invisível cresce.


🧠 Perverse Incentives in AI

Agora fica muito divertido e assustador.

Agente recebe reward:

“resolver maior número de tickets.”

Pode:

fechar ticket sem resolver.

Goodhart.

Mas se ele também consegue:

gerar subtasks

e depois fechá-las,

reward cresce.

Cobra Effect automatizado.


🤖 Agent creates work to complete work

Imagine:

REWARD:
TASKS COMPLETED

Agente:

cria 1.000 subtasks simples.

Completa.

Score:

incrível.

Valor:

zero.


☕ O bot inventou seu próprio backlog

Enterprise innovation.


🧠 Reward Hacking

Isso é relacionado a:

reward hacking.

Agente encontra:

atalho para recompensa.

Se atalho cria:

mais do problema,

Cobra Effect.


🧠 Specification Gaming

Objetivo:

“reduza spam reportado.”

Agente:

desativa botão de report.

Spam reportado:

zero.

Usuário:

furioso.


🎯 Pergunta Bellacosa nº 7

“Se um agente pudesse manipular o próprio ambiente, como ele maximizaria esta recompensa?”

Perfeita para IA.


🧠 AI Safety and perverse incentives

Quanto mais autônomo o agente:

mais precisa:

guardrails.

Reward design.

Independent eval.


🧠 Human vs AI difference

Humano interpreta:

normas sociais.

IA pode:

seguir especificação literalmente.

Então incentivos perversos podem:

ser executados com eficiência monstruosa.


☕ Um humano talvez hesite.

Um script:

DO UNTIL BONUS-MAX.


💻 COBOL do Cobra Effect

       IF PAYMENT-PER-TICKET > ZERO
           PERFORM GENERATE-TICKETS
               UNTIL BONUS = MAXIMUM
       END-IF.

Claro que ninguém escreveria isso.

Espero.


🧠 Safe incentive design

Use:

outcome.

Constraints.

Caps.

Quality gates.

Independent validation.


🧠 Caps

Se recompensa por:

volume,

limite.

Evita:

explosão.

Mas pode:

criar comportamento até o cap.

Still.


🧠 Diminishing rewards

Primeiros:

valem mais.

Depois:

menos.

Pode reduzir gaming.


🧠 Reward prevention

Não só:

resolver incidentes.

Também:

reduzir reincidência.

Agora root cause:

vale.


☕ Pague pela cobra que nunca nasceu

Difícil de medir.

Mas conceito correto.


🧠 How do we reward prevention?

Essa é uma das maiores dificuldades.

Você não observa:

incidente evitado.

Use:

leading indicators.

Risk reduction.

Control improvements.

Peer review.

Narratives.


🧠 Counterfactual problem

Não sabemos:

quantos incidentes não aconteceram.

Por isso hero culture é tão fácil.

Incidente resolvido:

visível.

Prevenção:

invisível.


🧠 Make prevention visible

Track:

recurring issues eliminated.

Manual steps removed.

Risk exposure reduced.


☕ O herói de verdade talvez seja quem fez o pager parar de tocar

para sempre.


🧠 Cobra Effect in monitoring

Meta:

reduzir alert count.

Equipe ajusta threshold.

Alertas caem.

Incidentes não.

Goodhart.

Mas se suporte recebe menos trabalho quando alertas caem e orçamento depende workload?

Complexo.

Incentivos podem puxar em sentidos opostos.


🧠 Systems of incentives

Não existe:

um incentivo.

Há vários.

Bônus.

SLA.

carreira.

pressão.

tempo.

Eles interagem.

Isso cria:

comportamento emergente.


☕ Psicologia organizacional é um CICS com exits demais

Você nunca sabe quem interceptou a transação.


🧠 Local Rationality

O comportamento pode parecer absurdo:

do alto.

Mas localmente:

faz sentido.

“Por que gastaram orçamento desnecessariamente?”

Porque se devolvessem:

perdiam budget.

Racional.

Sistema ruim.


🧠 Fundamental Attribution Error

Não diga:

“Gestores desperdiçam.”

Antes:

pergunte:

que incentivo existe?

Talvez política:

produz.


🧠 Actor-Observer

Meu gasto:

necessário.

Seu gasto:

desperdício.

Same.

Use dados.


🧠 Cobra Effect e Self-Serving Bias

Programa de incentivo aumenta:

atividade.

Gestor:

“Sucesso.”

Consequências:

outro time.

Self-Serving.


🧠 Narrative Bias

História:

“Pagamos e problemas foram resolvidos.”

Mas:

problemas cresceram.

Dashboard precisa:

end-to-end.


🎯 Pergunta Bellacosa nº 8

“O problema caiu em termos absolutos ou apenas aumentou a atividade de resolução?”

Muito importante.


🧠 Activity versus Outcome

Tickets resolvidos:

atividade.

Tickets necessários:

outcome?

Melhor:

customer problem rate.


🧠 Incident Program Example

Ruim:

BONUS:
INCIDENTS CLOSED

Melhor:

SUCCESS:
RECURRING INCIDENT RATE ↓
CUSTOMER IMPACT ↓
ROOT CAUSES REMOVED ↑

Ainda pode ser gamed.

Mas mais alinhado.


🧠 Multiple objectives

Evite:

single metric.

Goodhart.

Use:

balanced.


🧠 But do not create 100 KPIs

Need for Control.

3–5 principais.

Judgment.


☕ A métrica perfeita não existe

Mas a métrica descaradamente ruim existe bastante.


🧠 Red Team the Incentive

Esse merece um processo.

Antes de lançar:

recompensa.

Pergunte grupo:

“Como ganharíamos isso fazendo algo que a empresa odiaria?”

Anote tudo.


🧪 Exemplo

Incentivo:

“R$100 por vulnerability fixed.”

Gaming:

criar vulnerabilities;

dividir uma em várias;

reclassificar.

Agora desenho:

independent detection;

severity weighting;

cap;

no self-created issues.


🧠 Mechanism Design

Essa é exatamente a área:

desenhar regras para que:

comportamento racional

produza:

resultado desejado.


☕ Não lute contra interesse próprio

Projete para ele.


🧠 Incentive compatibility

Uma boa regra:

se pessoa age para maximizar:

benefício próprio,

também ajuda:

sistema.

Ideal.

Difícil.

Mas meta.


🧠 Example

Suporte recebe bônus por:

customer issue resolved without reopen.

Agora:

fechar cedo não ajuda.

Melhor.


🧠 But watch selection

Pode evitar:

tickets difíceis.

Guardrail:

coverage.

Again.


🧠 Second-order effects

Toda política:

pergunte:

o que acontece depois?

Não apenas:

primeiro efeito.

Cobra Effect é:

filho de segunda ordem.


☕ Primeira ordem:

“pagamos por cobra.”

Segunda:

“agora cobra virou ativo.”


🧠 Systems Thinking

Isso é essencial.

Não veja:

ação → resultado.

Veja:

feedback loop.


🔄 Cobra Loop

PROBLEMA
↓
RECOMPENSA POR RESOLVER
↓
PROBLEMA GANHA VALOR
↓
MAIS OFERTA DO PROBLEMA
↓
MAIS RECOMPENSA

É um loop de feedback positivo.


🧠 Feedback loops

Quanto mais recompensa:

mais atrativo.

Pode crescer:

explosivamente.


☕ Enquanto ninguém olha o outcome.


🧠 Cobra Effect e economics

Quando algo recebe preço:

pessoas respondem.

Isso é normal.

Se você cria mercado:

para problema,

pode aumentar:

oferta.


🧠 Supply responds to incentives

Bug.

Ticket.

Cobra.

Tudo que pode ser:

produzido

pode responder a:

preço.


🎯 Regra Bellacosa

Nunca pague apenas pela remoção de algo que o próprio recebedor consegue produzir.

Excelente.


🧠 Cobra Effect em emissions

Imagine recompensa por:

reduzir emissão

comparada a baseline.

Empresa pode:

inflar baseline.

Depois reduz.

Recebe crédito.

Goodhart + perverse incentive.


🧠 Baseline manipulation

Se recompensa depende:

melhoria,

baseline vira:

ativo estratégico.

TI também.


☕ Se bônus depende de reduzir tickets

talvez janeiro precise começar ruim.

Cuidado.


🧠 Goal Gradient and sandbagging

Equipe esconde capacidade inicial.

Meta baixa.

Depois supera.

Recebe bônus.

É um incentivo perverso comum.


🧠 Sandbagging

Sales.

Projects.

Performance.

Se target futuro depende:

performance atual,

pessoas podem:

não mostrar capacidade total.


☕ Nunca corra rápido demais

senão vira nova meta.

Humano aprende.


🧠 Ratchet Effect

Relacionado:

bom desempenho leva:

meta mais alta.

Então pessoas podem segurar desempenho.

Chama-se frequentemente:

ratchet effect.

Excelente parente do Cobra Effect.


🧠 Ratchet in operations

Equipe automatiza e reduz:

lead time 50%.

Gestão:

dobra demanda.

Ano seguinte:

equipe talvez não queira mostrar:

novos ganhos.

Incentivo ruim.


☕ Toda eficiência imediatamente confiscada

mata vontade de ser eficiente.


🧠 Share productivity gains

Parte:

empresa.

Parte:

equipe.

Sustentabilidade.


🧠 Cobra Effect in DR

Meta:

executar X DR tests.

Equipe faz:

testes fáceis.

Número atingido.

Critical scenario:

não.

Goodhart.

If budget increases with failures found:

could inflate.

Need balanced.


🧠 Test outcome

Recovery capability.

Not test count.


☕ 20 testes de PING

não são DR.


🧠 Cobra Effect e zero-touch automation

Meta:

reduzir intervenção humana.

Equipe automatiza:

decisão arriscada.

Human intervention:

zero.

Incidents:

up.

Metric good.

Again.


🤖 AI agents and autonomous completion

Management:

“Mais autonomia!”

Metric:

human approvals ↓.

Agent risk ↑.

Need guardrails.


🧠 Incentive for autonomy

If vendor sells:

“fully autonomous”,

marketing incentive may:

understate need for human oversight.

Principal-Agent.


🧠 Moral Hazard AI

Vendor gains:

sale.

Customer pays:

failure.

Cobra if pricing rewards:

more agent actions.

Potential.


🧠 Transaction-based pricing

AI vendor charges:

per action.

Client wants:

fewer unnecessary actions.

Agent/vendor may be incentivized by:

volume.

Design carefully.


☕ Bot pago por clique

Pode amar clicar.


🧠 Cobra Effect in cloud billing

Provider earns:

more usage.

Customer wants:

efficiency.

Advisory service from same provider might recommend:

more resource.

Potential conflict.

Again:

not accusation.

Governance.


🧠 Independent FinOps

Sometimes useful.


🧠 Cobra Effect in recruitment

Recruiter paid:

per hire.

Company wants:

good hire.

Recruiter incentive:

more hires.

Retention/quality maybe absent.

Align:

retention period.

Quality.


☕ Contratar rápido

e recontratar depois

é ótimo para quem recebe duas vezes.

Again:

model matters.


🧠 Mainframe staffing

Consultancy paid:

per contractor.

Client asks:

automation to reduce headcount.

Conflict.

No villain.

Just economics.


🧠 Cobra Effect em training

Trainer paid:

per participant.

Company wants:

competence.

Incentive:

more attendees,

not necessarily learning.

Measure:

outcomes.


☕ Certificado em massa

Conhecimento opcional.

Campbell says hi.


🧠 How to combat Cobra Effect

Vamos ao operacional.


🧪 Passo 1 — Defina o outcome real

Não atividade.


🧪 Passo 2 — Identifique quem controla o problema

Se recebedor pode produzir:

cuidado.


🧪 Passo 3 — Red Team do incentivo

Como ganhar sem ajudar?


🧪 Passo 4 — Mapeie externalidades

Quem paga efeito colateral?


🧪 Passo 5 — Use counter-metrics

Reopen.

Recurrence.

Customer impact.


🧪 Passo 6 — Evite reward linear infinito

Caps.

Diminishing returns.


🧪 Passo 7 — Recompense prevenção

Root cause.

Automation.


🧪 Passo 8 — Faça independent validation

Quando risco grande.


🧪 Passo 9 — Observe comportamento após lançamento

Mudou?


🧪 Passo 10 — Mate o incentivo se o sistema começar a criar cobras

Sem apego.

Sunk Cost.


📋 Checklist anti-Cobra Effect

[ ] Qual problema queremos reduzir?

[ ] O incentivo recompensa atividade ou outcome?

[ ] Quem recebe a recompensa consegue criar mais do problema?

[ ] Existe benefício em manter o problema vivo?

[ ] A penalidade é realmente desincentivo ou só preço?

[ ] O KPI pode ser fragmentado ou reclassificado?

[ ] Há risco de sandbagging?

[ ] Existe externalidade para outro time?

[ ] Prevenção é recompensada?

[ ] Root cause vale mais que workaround?

[ ] Há counter-metric?

[ ] O comportamento mudou depois do incentivo?

[ ] O problema real caiu?

[ ] A atividade de resolução subiu mais que o resultado?

[ ] Podemos cancelar o programa rapidamente?

🧠 Cobra Effect e Stop Rule

Todo incentivo deveria ter:

condição de parada.

Se efeitos colaterais aparecem:

pause.

Não continue porque:

“já investimos.”

Sunk Cost.


🧠 Pilot First

Faça:

piloto.

Não enterprise-wide.

Observe:

efeitos.


☕ Canary deployment para incentivos

Adoro essa ideia.

Teste política com:

um time.

Veja se começam a criar cobras.


🧠 Incentive Canary

Medir:

behavior.

Not only target metric.


🧠 Incentive Observability

Precisamos de telemetria:

para política.

Before/after.

Control group if possible.


🧠 Causal inference

Se problema caiu:

foi incentivo?

Ou contexto?

Outcome Bias.

Use:

comparison.


☕ Não dê medalha ao programa

antes de verificar se as cobras realmente diminuíram.


🧠 Cobra Effect e Transparency

Pessoas precisam poder dizer:

“Esse incentivo está causando comportamento estranho.”

Sem medo.

Psychological Safety.


🧠 Whistleblowing internal

Pode revelar:

gaming.

Não puna mensageiro.

Campbell.


🧠 Honest red metrics

Se incentive program produces bad result:

show.

Don't greenwash.


🧠 Leadership question

Líder deveria perguntar:

“Que comportamento racional nosso incentivo está tornando lucrativo?”

Essa é uma pergunta excelente.


☕ As pessoas não são bugs

Mas respondem a especificações.


🧠 Incentive as code

Talvez uma das melhores metáforas.

Política:

é código.

Pessoas:

runtime.

Resultado:

emergente.


💻 COBOL do incentivo

       EVALUATE TRUE
           WHEN BONUS-BY-VOLUME
               PERFORM MAXIMIZE-VOLUME
           WHEN BONUS-BY-QUALITY
               PERFORM MAXIMIZE-QUALITY
           WHEN BONUS-BY-OUTCOME
               PERFORM MAXIMIZE-OUTCOME
       END-EVALUATE.

Claro que humanos são muito mais complexos.

Mas direção ajuda.


🧠 Requirements matter

Se você especifica:

volume,

não reclame:

quando ganha volume.


☕ “Mas eles deveriam entender o espírito.”

Talvez.

Melhor:

não colocar regra contra o espírito.


🧠 Ethics versus incentives

Ética individual importa.

Mas não desenhe sistema que exige:

pessoas constantemente sacrificarem benefício próprio

para proteger objetivo invisível.

Isso não escala.


🧠 Incentive-compatible ethics

Faça comportamento correto:

fácil.

Seguro.

Reconhecido.


🧠 Cobra Effect e compliance penalties

Se multa por:

violação

é menor que:

benefício econômico,

empresa pode:

internalizar multa como custo.

Again:

price vs penalty.


$FINE <= $PROFIT

PERFORM VIOLATION.

Economia 101.


🧠 Stronger penalty?

Talvez.

Mas punição excessiva pode:

causar ocultação.

Campbell.

Não é apenas:

aumentar multa.

Design holístico.


🧠 Detection probability matters

Expected penalty:

probability × penalty.

Se detecção baixa:

incentivo fraco.


🧠 Monitoring and audit

Alinhamento.


☕ A multa que ninguém vê

é quase zero.


🧠 Cobra Effect em governance

Criamos aprovação:

para reduzir risco.

Equipe aprende:

classificar tudo como emergency.

Agora:

mais emergency changes.

Controle queria:

menos risco.

Produziu:

rota de bypass.

Perverse incentive.


🧠 Emergency Classification

Se processo normal:

muito lento,

emergency vira:

atalho.

Logo:

incentivo para:

declarar emergência.


☕ Se toda mudança é emergencial

o processo normal está em coma.


🎯 Pergunta Bellacosa nº 9

“O processo torna o caminho errado mais barato, rápido ou recompensador que o caminho certo?”

Talvez a pergunta mais ampla do capítulo.


🧠 Friction as incentive

Não só bônus.

Se caminho correto:

20 passos.

Errado:

Você criou:

incentivo perverso.


🧠 UX and security

Password policy impossível.

Usuários escrevem senha:

post-it.

Security wanted:

more security.

Got:

less.

Cobra-like effect via friction.


☕ Segurança tão difícil que incentiva insegurança

Clássico.


🧠 Shadow Processes

Same.

Official process:

hard.

Unofficial:

easy.

Behavior follows.


🧠 Simplify good path

A defesa:

torne comportamento desejável:

mais fácil.

Automate.

Good defaults.


☕ Poka-Yoke organizacional

Faça o certo ser:

natural.


🧠 Cobra Effect em approvals

Manager gets status by:

number of approvals controlled.

May resist automation.

Again:

incentive.

Need for Control.


🧠 Power incentives

Not monetary.

Authority.

Visibility.

Control.

Processes may survive:

because someone benefits.


🧠 Status Quo Bias

Even after incentive fails:

nobody wants remove.

Sunk Cost.

Status Quo.


☕ A cobra já ganhou crachá.

Agora é processo oficial.


🧠 Review incentives periodically

Every:

6/12 months.

Ask:

what behavior emerged?


🧠 Incentive decay

People learn.

What initially works:

later gamed.

Metric evolves.

Need review.


🧠 Campbell / Goodhart dynamic

No incentive stays neutral.

As agents learn:

proxy quality declines.


☕ Todo programa de incentivo entra em produção

e precisa de maintenance.


🧠 Version your incentives

Policy v1.

v2.

Document.

Measure.


🧠 Cobra Effect and culture

Culture can moderate:

gaming.

But don't rely solely.

Strong ethical culture:

helps.

Still:

bad incentives create pressure.


🧠 Speak-up mechanisms

Allow:

flagging.


☕ “Isso está criando cobras.”

Deveria ser frase permitida em reunião.


🧠 Anti-Cobra War Room

Whenever incentive proposed:

ask four roles:

business;

ops;

security;

finance.

Each sees:

different externality.

Cross-functional review.


🧠 Silo Bias

Each silo may:

optimize local.

Shared review helps.


📊 Bellacosa Incentive Map

INCENTIVE:
R$500 / incident resolved

DESIRED OUTCOME:
fewer incidents

POSSIBLE GAMING:
more incident creation/classification

EXTERNALITY:
customer impact

COUNTER-METRIC:
recurring incident rate

SAFEGUARD:
reward root-cause elimination

Simple.

Powerful.


🧠 Rewarding root cause

Example:

bonus for:

repeat incident eliminated

not:

ticket count.

Better.


🧠 But can still game

Declare:

root cause eliminated

prematurely.

Then counter:

recurrence over 90 days.

Again:

layers.


☕ Swiss Cheese do incentivo

No single metric.


🧠 Long-term validation

Prevention needs:

time.

Use:

lagging review.


🧠 Incentive horizon

If bonus immediate

and downside future:

Present Bias.

Moral Hazard.

Maybe delayed payout.


🧠 Deferred reward

Part of bonus after:

90-day stability.

Aligns.


☕ Não pague o bolo antes de descobrir se cozinha explodiu.


🧠 Cobra Effect em vendor contracts

Payment:

on delivery.

Maybe quality after.

Use:

retention.

Holdback.

Warranty.


🧠 Retention mechanisms

Keep part payment until:

stability.

Align.


🧠 Principal-Agent Problem mitigated

Agent cares:

post-go-live.


🧠 Cobra Effect em executive bonuses

Bonus by:

cost cutting.

Manager cuts:

maintenance.

Short-term cost ↓.

Future incidents ↑.

Present Bias + Moral Hazard.

Need:

reliability guardrail.


☕ Cortar óleo economiza manutenção

por alguns quilômetros.


🧠 Long-term metrics

TCO.

Reliability.

Employee turnover.

Customer impact.


🧠 Cobra Effect and layoffs

Reward manager for:

headcount reduction.

May cut:

critical skills.

Cost ↓.

Risk ↑.

If manager moved before consequence:

Moral Hazard.


🧠 Bus Factor

Invisible.

Until.


☕ O COBOLzeiro “caro”

sai.

Depois descobrem:

quanto custava não tê-lo.


🧠 Skills as risk

If cost metric ignores:

knowledge concentration,

perverse incentive.


🧠 Balanced decisions

Cost + resilience.


🧠 Cobra Effect em incident penalties

If team punished per incident:

may avoid risky changes.

Innovation ↓.

Security patches delayed.

Risk future ↑.


🧠 Punishment can backfire

Campbell.


☕ “Nenhum incidente este trimestre.”

Porque:

ninguém mexeu.

Meanwhile vulnerability ages.


🧠 Incentive design principles

Let's distill.


🧠 1. Reward outcomes

Not activity.


🧠 2. Include side effects

Guardrails.


🧠 3. Prevent self-generation

Don't pay someone to eliminate what they can cheaply create.


🧠 4. Align time horizon

Reward after durability.


🧠 5. Cap exploitation

Limits.


🧠 6. Audit

Independent when needed.


🧠 7. Make prevention visible

Not only heroic recovery.


🧠 8. Review continuously

Because behavior adapts.


☕ Incentivo é software social

Faça patch.


🧠 Cobra Effect and second-order thinking

First order:

pay for fixes.

Second:

more fixes.

Third:

root cause neglected.

Fourth:

incident culture.

Think ahead.


🧠 Pre-mortem

Imagine:

program wildly successful by its own KPI

but company worse.

How?

This is excellent.


👻 Easter Egg nº 3 — O programa de monstros

Gallifrey announces:

“One credit for every temporal anomaly eliminated.”

A Time Lord discovers:

he can create anomalies.

Then eliminate them.

Performance:

900%.

Doctor:

— Vocês inventaram mineração de anomalias.

Gallifrey:

— Mas o dashboard está excelente.

Of course.


🧠 Mining the metric

Great phrase.

People can:

mine.

If reward depends:

volume.


☕ Incident mining

Never let that become a thing.


🧠 Cobra Effect in content moderation

Pay moderators per item removed.

Might over-remove.

Goodhart.

If platform revenue from harmful content and moderation paid per removal, complex incentives.

Again:

system-level.


🧠 False positives

Need guardrails.


🧠 Cobra Effect in fraud detection

Team rewarded:

fraud dollars blocked.

Could block:

more legitimate transactions.

Metric ↑.

Customer harm.

Not creating fraud, more Goodhart.

But if funding depends:

fraud found,

could overclassify.

Perverse incentive.


☕ Every anomaly starts looking fraudulent

when fraud pays bonus.


🧠 Base Rate Neglect

Rare fraud.

Aggressive detection.

False positives.

Need base rates.

Our previous chapters reconnect.


🧠 Framing Effect

“Fraud prevented: R$10M!”

What cost:

legitimate transactions blocked?

Maybe R$20M.

Need total outcome.


🎯 Pergunta Bellacosa nº 10

“Qual é o custo total do comportamento incentivado, incluindo os efeitos que o KPI não mostra?”

Excellent.


🧠 System Boundary

Define:

where measurement stops.

Costs outside boundary:

externalized.

Widen.


🧠 End-to-End Outcome

Payment.

Not:

fraud team metric alone.


☕ Cliente não usa seu organograma

Já sabemos.


🧠 Cobra Effect in AI coding

Developer rewarded:

PR count.

AI increases PRs.

Maybe low-value changes.

Volume explodes.

Review load.

Bugs.

Tool intended:

productivity.

Incentive produces:

churn.


🧠 AI amplifies incentive errors

Important.

Humans may game slowly.

Automation:

at scale.

A bad incentive with AI becomes:

high-throughput bad behavior.


☕ COBOL batch do incentivo perverso

Runs overnight.

Millions of bad optimizations.


🧠 Agentic systems

Autonomous agents maximize objective.

If objective wrong:

Cobra Effect at machine speed.

Need:

evals.

Guardrails.

Budget.

Rate limits.


🤖 Resource budget

Limit:

actions.

Spend.

Scope.


🧠 Reward adversarial testing

Before deployment:

ask agent to exploit reward.

Very useful.


🧠 Red Team the Objective

Can agent:

create task then complete?

Can it:

hide failure?

Can it:

change denominator?

Same old human tricks.

Now machine.


☕ Goodhart with GPUs

Faster.


🧠 Cobra Effect and observability

Monitor not only:

reward metric.

Also:

environment changes.


🧠 Side-effect telemetry

If task completion ↑

but:

created tasks ↑ dramatically,

alert.


📊 Example

TASKS COMPLETED:
+400%

TASKS CREATED:
+620%

Congratulations?

No.


🧠 Net value

Maybe:

completed - generated?

Even that can be gamed.

Need real outcome.


🧠 Human evaluation

Still important.


☕ “Parabéns, bot. Você venceu o KPI.”

“Agora desfaça.”


🧠 Cobra Effect and risk appetite

Some incentives intentionally:

increase behavior.

Sales commissions.

Fine.

The question:

does behavior align with risk appetite?


🧠 Sales example

Commission by:

revenue.

Might sell:

bad-fit customers.

Churn later.

Better:

retention-adjusted commission.

Delayed payout.

Same principle.


🧠 IT equivalent

Project bonus by:

go-live.

Add:

90-day stability.


🧠 Delayed consequence

Bring future:

into reward.

Present Bias mitigated.


☕ Pague depois que sobreviver ao fim de semana.


🧠 Anti-Cobra principle: pay for durable outcomes

Excellent.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Cobra Effect descreve situações em que uma intervenção criada para resolver um problema acaba tornando racional produzir, manter ou aumentar esse problema.

Perverse incentives são incentivos cujo efeito real empurra comportamento na direção oposta ao objetivo pretendido.

O incentivo não precisa ser dinheiro; pode ser carreira, status, orçamento, tempo ou evitar punição.

Goodhart explica como a métrica pode ser otimizada; Campbell explica como pressão institucional amplifica isso; Cobra Effect mostra como o próprio problema pode ganhar valor.

Principal-Agent Problem e Moral Hazard ajudam a entender por que o benefício pode ficar com um agente e o custo com outro.

Nunca recompense apenas a atividade de remover um problema que o próprio agente pode produzir.

Root cause e prevenção precisam ter valor, não apenas heroísmo e volume de tickets.

Penalidade muito baixa pode virar preço, não desincentivo.

Success penalty também é perigoso: se melhorar faz perder orçamento ou emprego, eficiência vira ameaça.

IA e agentes podem explorar incentivos mal desenhados em grande escala e velocidade.

Red-team o incentivo antes de lançar.

E principalmente:

não pergunte apenas “o que esta política recompensa?”. Pergunte “que comportamento estranho se tornaria perfeitamente racional se alguém levasse essa recompensa muito a sério?”.


🕰️ De volta às 08:11

Programa:

R$500 / INCIDENTE RESOLVIDO

A equipe revisa.

Novo modelo:

REWARD:
REDUÇÃO DE REINCIDÊNCIA
+
ROOT CAUSES ELIMINADAS
+
CUSTOMER IMPACT REDUZIDO

Com validação:

90 dias.

Agora:

resolver rápido ainda importa.

Mas repetir incidente:

não gera novo prêmio.

Muito pelo contrário.

Root cause ganha valor.


🔧 Três meses depois

INCIDENTES:
-27%

REINCIDÊNCIA:
-43%

MANUAL WORKAROUNDS:
-31%

CUSTOMER IMPACT:
-35%

Curiosamente:

tickets resolvidos também caem.

O diretor pergunta:

— Então a equipe está fazendo menos?

Nosso jovem responde:

— Está tendo menos coisa ruim para fazer.

— Mas nosso volume caiu.

— Exatamente.

Pausa.

— Talvez essa seja a vitória.

O Doctor sorri.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(COBRA-EFFECT)

Dentro:

       IF REWARD = 'PER-PROBLEM'
           PERFORM CHECK-WHO-CREATES-PROBLEM
       END-IF.

       IF BONUS-INCREASES
          AND PROBLEM-ALSO-INCREASES
           PERFORM STOP-THE-PROGRAM
       END-IF.

       IF ROOT-CAUSE-REMOVED
           MOVE 'REAL-VALUE'
             TO REWARD-TYPE
       END-IF.

       IF PENALTY < PROFIT-FROM-VIOLATION
           DISPLAY 'WARNING: THIS IS A PRICE'
       END-IF.

Comentário:

* DO NOT CREATE
* A MARKET
* FOR THE PROBLEM.

Outro:

* REWARD PREVENTION,
* NOT JUST HEROISM.

Outro:

* IF SUCCESS
* REDUCES YOUR BUDGET,
* EXPECT LESS SUCCESS.

Mais um:

* INCENTIVES ARE
* EXECUTABLE SPECIFICATIONS.

E naturalmente:

* DALEKS STOPPED
* BREEDING COBRAS
* ONLY AFTER THE BONUS
* WAS REMOVED.

Nosso jovem fecha o membro.

Horas depois alguém propõe:

— Vamos premiar o time que fechar mais chamados.

Ele pergunta:

— Queremos mais chamados fechados?

— Claro.

— Ou queremos menos clientes precisando abrir chamados?

Silêncio.

— Não é a mesma coisa?

Ele sorri.

— Depois do Cobra Effect...

Pausa.

— às vezes é exatamente o contrário.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

Um incentivo é uma especificação executável para comportamento humano. Se você escreveu a regra errada, não reclame quando o sistema compilar perfeitamente e produzir exatamente o desastre que você pediu.

☕🌀

Next stop: Ratchet Effect — quando cada melhoria de desempenho vira automaticamente a nova meta mínima, ensinando pessoas e equipes a esconder capacidade, evitar ganhos visíveis e jamais mostrar tudo o que realmente conseguem entregar.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...