✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Quando a IA entra na espiral da formiga: por que saber parar também é inteligência
Uma homenagem ao espírito da MAD Magazine, com Alfred E. Neuman observando tudo ao fundo e perguntando: “What, me worry?”
Há um momento extraordinário em qualquer sistema inteligente no qual ele deixa de parecer inteligente e passa a lembrar aquele funcionário que, diante de uma impressora sem papel, aperta o botão PRINT quarenta e sete vezes.
Nada acontece.
Então ele aperta novamente.
Talvez agora.
Nada.
Mais uma vez.
Afinal, todo profissional de TI sabe que executar exatamente a mesma operação pela décima oitava vez é praticamente um método científico.
Foi mais ou menos assim que descobri uma fascinante modalidade de comportamento artificial que poderíamos chamar de Síndrome da Formiga Amazônica Digital.
Prepare o café.
Hoje não vamos falar de COBOL, CICS, Db2 ou do programador que encontrou um SOC7 e imediatamente culpou a infraestrutura.
Vamos falar de algo talvez ainda mais perigoso:
uma IA que não sabe a hora de parar.
🐜 A formiga que decidiu seguir a formiga
Existe um fenômeno conhecido informalmente como death spiral, ou moinho de formigas.
Algumas espécies de formigas dependem intensamente de trilhas químicas para seguir suas companheiras. Em determinadas circunstâncias, uma formiga começa a seguir outra, que segue outra, que segue outra…
Até que todas estejam andando em círculo.
Nenhuma delas está necessariamente fazendo algo “errado”.
Cada formiga individual está obedecendo perfeitamente à sua regra:
siga a formiga da frente.
O problema aparece no sistema.
A regra local funciona.
O comportamento global vira uma catástrofe.
Se Alfred E. Neuman estivesse no meio do círculo, provavelmente sorriria:
“What, me worry?”
E continuaria andando.
Foi exatamente essa imagem que me veio à cabeça ao observar determinados comportamentos de sistemas de IA.
Não porque sejam burros.
Justamente pelo contrário.
São sistemas extremamente sofisticados capazes de interpretar linguagem, gerar imagens, escrever código, explicar física quântica e provavelmente encontrar uma maneira educada de dizer ao gerente que o projeto atrasou porque ninguém sabia exatamente o que estava construindo.
Mas às vezes acontece isto:
Usuário: faça X.
IA: não posso fazer X.
Usuário: tudo bem, então faça Y.
IA: não posso fazer Y.
Usuário: retirei justamente o elemento problemático.
IA: excelente. Vamos tentar novamente.
Sistema: não posso fazer.
IA: talvez seja por causa de Z.
Usuário: então retire Z.
IA: perfeito!
Sistema: não posso fazer.
E assim nasce o moinho de formigas computacional.
🤖 O erro não é errar
Isso precisa ser dito com todas as letras:
errar não é o verdadeiro problema.
Sistemas complexos falham.
Mainframes falham.
APIs falham.
Aplicações falham.
Bancos de dados falham.
Pessoas falham.
E quem disser que nunca produziu um erro em produção provavelmente ainda não entrou em produção.
O problema sério começa quando um sistema falha e não consegue incorporar a informação de que acabou de falhar.
Em engenharia, isso é quase uma heresia.
Imagine um programa COBOL:
PERFORM TENTAR-NOVAMENTE
UNTIL MILAGRE-ACONTECER.
Sem contador.
Sem timeout.
Sem condição alternativa.
Sem tratamento de exceção.
O operador chega segunda-feira e encontra o job executando desde 1987.
A documentação explica:
“O processo é resiliente.”
Não, amigo.
O processo está possuído.
🔁 Inteligência sem condição de parada
Durante décadas ensinamos algoritmos com uma preocupação aparentemente banal:
qual é a condição de parada?
Todo estudante de programação aprende rapidamente que loops são maravilhosos até você esquecer a condição que encerra o loop.
while true
é uma das frases mais poderosas e ameaçadoras da computação.
O curioso é que agora estamos construindo sistemas capazes de raciocinar sobre tarefas complexas, mas existe uma questão equivalente que merece muito mais atenção:
quando a IA deve concluir que continuar tentando é pior do que parar?
Essa pergunta parece pequena.
Não é.
Ela toca diretamente em:
confiabilidade;
experiência do usuário;
custo computacional;
segurança;
suporte;
automação;
tomada de decisão.
Uma IA que sabe executar tarefas é útil.
Uma IA que sabe quando abandonar uma estratégia ruim é muito mais inteligente.
🧠 Persistência não é teimosia
Existe uma tendência cultural na tecnologia de tratar persistência como virtude absoluta.
“Never give up.”
“Try again.”
“Fail fast.”
“Iterate.”
Tudo maravilhoso.
Até você perceber que insistir num método que já demonstrou repetidamente não funcionar não é perseverança.
Bellacosa Mainframe e o web design para programadores cobol
☕ Um Café no Bellacosa Mainframe
Web Design entre os Mortos — Quando a Interface Caiu e o Sistema Continuou Caminhando
O relógio do CPD marcava 02h17.
As luzes fluorescentes piscavam sobre os corredores vazios. No fundo da sala, um terminal permanecia ligado, exibindo uma tela que nenhum operador lembrava ter aberto:
SYSTEM STATUS: ONLINE
USER EXPERIENCE: CRITICAL
INTERFACE INTEGRITY: 34%
BACK-END ACTIVITY: UNKNOWN
Ao lado do teclado, uma caneca de café ainda soltava fumaça.
Isso significava que alguém estivera ali há pouco tempo.
Ou alguma coisa.
O jovem programador COBOL aproximou-se lentamente. Era seu primeiro plantão noturno. Ele conhecia IDENTIFICATION DIVISION, começava a entender WORKING-STORAGE SECTION e já havia descoberto que uma vírgula colocada no lugar errado podia transformar um programa simples em uma investigação criminal.
Mas naquela noite o problema não estava no COBOL.
O problema estava na interface.
Ela parecia bonita. Moderna. Elegante. Possuía botões arredondados, cores harmoniosas, ícones bem desenhados e animações suaves.
Porém ninguém conseguia utilizá-la.
Os usuários estavam perdidos. Os pedidos desapareciam. Os formulários falhavam. As mensagens de erro não explicavam nada. A aplicação funcionava perfeitamente durante as apresentações, mas entrava em colapso quando encontrava pessoas reais, celulares antigos, conexões lentas e dados incompletos.
O sistema não estava morto.
Era pior.
Ele continuava funcionando sem compreender os próprios usuários.
Bem-vindo ao verdadeiro Web Design.
Aqui, criar uma página bonita é apenas o começo da sobrevivência.
1. O primeiro erro: acreditar que Web Design é decoração
Quando um iniciante escuta a expressão Web Design, normalmente pensa em:
cores;
fontes;
imagens;
botões;
menus;
animações;
organização visual.
Tudo isso faz parte do trabalho. Entretanto, representa apenas a camada mais visível.
Uma interface pode ser comparada à porta de entrada de um grande complexo tecnológico.
O usuário vê:
[ CONSULTAR SALDO ]
Mas atrás desse botão pode existir:
Usuário
↓
Navegador
↓
Front-end
↓
API REST
↓
Autenticação
↓
Servidor
↓
Regra de negócio
↓
CICS
↓
Programa COBOL
↓
Db2 ou VSAM
O botão é pequeno.
A operação que ele representa pode atravessar dezenas de componentes.
Esse é o primeiro grande ensinamento para o programador COBOL iniciante: a interface não existe sozinha.
Ela é uma camada de contato entre uma pessoa e um sistema.
Da mesma forma que uma tela BMS do CICS não é apenas um conjunto de campos posicionados no terminal, uma página Web não é apenas HTML com cores.
A tela precisa representar dados, regras, permissões, estados e possibilidades de ação.
Uma interface desconectada do sistema é como uma porta desenhada na parede.
Parece uma saída.
Mas não leva a lugar algum.
2. UI: a primeira barricada
UI significa User Interface, ou Interface do Usuário.
É tudo aquilo que a pessoa vê, toca, seleciona, preenche ou aciona.
Exemplos:
botões;
campos de formulário;
menus;
caixas de seleção;
tabelas;
ícones;
mensagens;
barras de progresso;
janelas;
links;
alertas.
A UI funciona como a primeira barricada entre o usuário e a complexidade do sistema.
Quando bem construída, ela organiza a interação.
Quando mal construída, ela libera o caos.
Considere este botão:
[ OK ]
O que significa “OK”?
Confirmar uma compra?
Excluir um cadastro?
Sair do sistema?
Enviar um pagamento?
Agora observe:
[ CONFIRMAR PAGAMENTO ]
A segunda opção reduz a incerteza.
Em sistemas corporativos, clareza é mais importante do que criatividade excessiva.
Um botão não precisa surpreender o usuário. Ele precisa comunicar.
Uma boa UI deve responder a três perguntas:
1. O que é este elemento?
2. O que posso fazer com ele?
3. O que acontecerá depois?
Essa lógica lembra um comando COBOL.
Quando vemos:
PERFORM CALCULAR-TOTAL
entendemos a intenção da operação.
Agora imagine:
PERFORM ROTINA-X
Pode funcionar, mas exige investigação.
Botões com nomes genéricos são o equivalente visual de parágrafos chamados ROTINA-X, PROCESSO-01 ou FAZ-COISA.
Funcionam tecnicamente.
Fracassam semanticamente.
3. UX: sobreviver não é apenas manter o sistema ligado
UX significa User Experience, ou Experiência do Usuário.
A UI pergunta:
Como esta tela se apresenta?
A UX pergunta:
O usuário consegue alcançar seu objetivo?
Essa diferença é fundamental.
Uma aplicação pode ser visualmente impecável e ainda oferecer uma experiência terrível.
Imagine um portal bancário com:
animações sofisticadas;
fotografia profissional;
tipografia moderna;
transições suaves;
gráficos elegantes.
Agora imagine que:
o usuário não encontra o saldo;
a transferência exige doze etapas;
a sessão termina sem aviso;
o botão Voltar apaga os dados;
o erro apresenta apenas HTTP 500;
o comprovante não pode ser baixado.
A UI pode ser bonita.
A UX está em estado terminal.
Uma experiência digital envolve toda a jornada:
Entrada no sistema
↓
Compreensão da tela
↓
Localização da função
↓
Execução da tarefa
↓
Retorno do sistema
↓
Confirmação do resultado
Se qualquer etapa falhar, a experiência será prejudicada.
Exemplo prático
O usuário preenche um cadastro e pressiona Salvar.
Uma interface ruim não mostra nada.
Ele clica novamente.
E novamente.
No banco de dados, três registros são criados.
Uma interface melhor apresenta:
Salvando cadastro...
Durante o processamento, o botão fica temporariamente desabilitado.
Depois:
Cadastro concluído com sucesso.
Ou:
Não foi possível concluir o cadastro.
Revise os campos destacados.
Isso é UX.
Não é apenas beleza.
É comunicação durante o processamento.
4. O usuário real não vive no ambiente de testes
Nos protótipos, tudo parece funcionar.
A conexão é rápida.
A tela é grande.
Os dados estão completos.
O usuário sabe exatamente onde clicar.
Então a aplicação entra em produção.
É nesse momento que os sobreviventes aparecem.
O usuário real pode estar:
usando um celular antigo;
com conexão instável;
sob forte luz solar;
utilizando apenas uma mão;
com pressa;
com baixa visão;
sem conhecimento técnico;
preenchendo o formulário pela primeira vez;
tentando recuperar uma senha esquecida;
interrompido por mensagens e chamadas.
Projetar para um usuário ideal é como montar uma base de sobrevivência assumindo que nunca faltará energia, água ou alimento.
O mundo real acabará testando cada suposição.
Por isso, o Web Designer precisa investigar:
Quem utilizará o sistema?
O que essa pessoa deseja fazer?
Em qual dispositivo?
Em qual contexto?
Com qual frequência?
Quais erros ela pode cometer?
Quais informações ela já conhece?
Quais limitações podem existir?
Esse processo é chamado de design orientado ao usuário.
Ele não significa simplesmente perguntar:
Qual cor você prefere?
O usuário pode gostar de azul e ainda precisar de uma solução completamente diferente daquela que imaginou.
O papel do profissional é compreender o problema.
5. A diferença entre pedido e necessidade
Um usuário pode dizer:
Quero um botão maior.
Mas o problema real pode ser:
baixo contraste;
área de clique pequena;
excesso de elementos na tela;
posição inadequada;
texto confuso;
dificuldade de navegação.
Da mesma forma, um usuário pode pedir:
Quero mais opções no menu.
Talvez ele não precise de mais opções.
Talvez precise encontrar melhor as opções existentes.
O bom designer não registra apenas a solicitação. Ele investiga a necessidade.
É como analisar um ABEND.
O código exibido é o sintoma.
A causa pode estar em outro ponto.
S0C7
↓
Dado inválido
↓
Campo não inicializado
↓
Arquivo com formato inesperado
↓
Regra de validação ausente
No design ocorre algo semelhante:
Usuário não encontra função
↓
Menu confuso
↓
Categorias inadequadas
↓
Arquitetura da informação mal planejada
O clique errado é o sintoma.
A organização pode ser a causa.
6. Acessibilidade: ninguém deve ser deixado do lado de fora
Em um cenário de sobrevivência, uma comunidade que abandona parte de seus membros torna-se mais fraca.
Na Web acontece o mesmo.
Acessibilidade significa criar produtos que possam ser utilizados pelo maior número possível de pessoas.
O e-mail informado é inválido.
Este e-mail já está cadastrado.
A senha deve possuir pelo menos oito caracteres.
Não foi possível enviar a confirmação.
Cadastro concluído.
Sem compreender o Back-end, o designer pode criar apenas um espaço genérico para erros.
Com algum conhecimento técnico, ele consegue projetar uma experiência mais precisa.
14. O paralelo com COBOL, CICS e mainframe
Para o programador COBOL iniciante, a arquitetura pode ser visualizada assim:
Usuário
↓
Página Web
↓
JavaScript
↓
API REST
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
↓
Db2 ou VSAM
O usuário clica:
[ CONSULTAR CLIENTE ]
A aplicação pode executar:
1. Validar os dados no navegador.
2. Enviar a requisição para a API.
3. Autenticar o usuário.
4. Converter a chamada para o ambiente mainframe.
5. Acionar uma transação CICS.
6. Executar o programa COBOL.
7. Consultar Db2 ou VSAM.
8. Retornar os dados.
9. Atualizar a interface.
Quem pode fazer?
Quando pode fazer?
Quais dados são necessários?
Quais erros podem acontecer?
Passo 6 — Projete todos os estados
Não desenhe apenas o cenário perfeito.
Inclua:
carregamento;
vazio;
erro;
sucesso;
falta de permissão;
ausência de conexão.
Passo 7 — Considere acessibilidade
Teste:
teclado;
contraste;
foco;
leitores de tela;
textos;
tamanho de toque.
Passo 8 — Considere diferentes telas
Verifique:
celular;
tablet;
notebook;
monitor grande;
ampliação de tela.
Passo 9 — Conecte design e tecnologia
Converse com:
desenvolvedores Front-end;
desenvolvedores Back-end;
analistas;
especialistas em banco de dados;
segurança;
infraestrutura;
usuários.
Passo 10 — Teste com pessoas reais
Observe sem explicar tudo.
Se o usuário não consegue avançar sem ajuda, existe uma pista.
18. Dicas Bellacosa para o Padawan do Web Design
Dica 1 — Não confie apenas no “está bonito”
Pergunte também:
Está claro?
Está acessível?
Está previsível?
Está funcionando?
Dica 2 — Mensagens de erro devem ajudar
Evite:
Erro 500.
Prefira:
Não foi possível concluir a operação.
Tente novamente em alguns instantes.
Dica 3 — Toda ação precisa de retorno
O usuário clicou?
Mostre que algo aconteceu.
Dica 4 — Não use apenas cor
Combine cor, texto e símbolo.
Dica 5 — Desenhe para dados ruins
Teste:
nomes muito longos;
campos vazios;
números grandes;
imagens ausentes;
respostas demoradas.
Dica 6 — O sistema não é o usuário
Uma mensagem tecnicamente precisa pode ser incompreensível para quem está usando a aplicação.
Dica 7 — Aprenda fundamentos
Frameworks mudam.
Os fundamentos permanecem:
estrutura;
hierarquia;
semântica;
acessibilidade;
comunicação;
feedback.
19. Curiosidades do abrigo digital
Curiosidade 1 — O estado vazio é uma oportunidade
Uma tela sem dados não precisa ser apenas vazia.
Ela pode orientar:
Você ainda não possui projetos.
Crie seu primeiro projeto para começar.
Curiosidade 2 — Velocidade percebida também importa
Mesmo quando uma operação demora, mensagens e indicadores reduzem a sensação de abandono.
Curiosidade 3 — O texto faz parte do design
Compare:
Enviar
com:
Enviar solicitação
O segundo pode ser mais claro dependendo do contexto.
Curiosidade 4 — Sistemas antigos podem ter interfaces modernas
COBOL não impede a existência de aplicações Web atuais.
APIs, z/OS Connect, CICS e serviços permitem conectar interfaces modernas a regras de negócio consolidadas.
Curiosidade 5 — A interface é uma tradução
Ela traduz:
Complexidade técnica
↓
Ações compreensíveis
20. Easter egg: o registro que ninguém deveria encontrar
Durante a investigação no CPD, o jovem programador abriu o log da aplicação.
Entre milhares de mensagens, encontrou:
02:17:33 USER CLICKED "OK"
02:17:33 ACTION UNKNOWN
02:17:34 REQUEST SENT
02:17:34 BUSINESS RULE REJECTED
02:17:34 ERROR MESSAGE HIDDEN
02:17:35 USER CLICKED AGAIN
02:17:35 USER EXPERIENCE INFECTED
Ele ficou em silêncio.
O problema nunca fora um vírus.
Também não era um processo morto.
Era um botão chamado OK.
O botão não explicava o que faria.
A mensagem de erro não aparecia.
O usuário clicava novamente.
O sistema criava uma nova tentativa.
Cada tentativa gerava outra.
E outra.
E outra.
A aplicação não estava sendo atacada por mortos-vivos.
Estava sendo atacada por decisões de design que se recusavam a morrer.
O programador abriu o código da interface e substituiu:
[ OK ]
por:
[ CONFIRMAR CANCELAMENTO ]
Depois adicionou:
O cancelamento não poderá ser desfeito.
Deseja continuar?
E finalmente:
Cancelamento concluído.
Naquele instante, o terminal parou de piscar.
O contador de erros começou a cair.
No monitor principal surgiu:
USER EXPERIENCE: RECOVERING
INTERFACE INTEGRITY: 97%
SYSTEM STATUS: HUMAN AGAIN
Conclusão: no fim, projetamos para pessoas
Web Design é muito maior do que criar uma página bonita.
Ele envolve:
UI;
UX;
pesquisa;
acessibilidade;
responsividade;
arquitetura da informação;
arquitetura do sistema;
Front-end;
Back-end;
APIs;
regras de negócio;
dados;
comunicação.
Uma interface é o ponto de encontro entre três mundos:
PESSOA
↘
INTERFACE
↗
SISTEMA
Se o projeto pensa apenas no sistema, pode tornar-se tecnicamente correto e humanamente impossível.
Se pensa apenas na aparência, pode tornar-se bonito e inutilizável.
Se pensa apenas no usuário, ignorando regras e limitações, pode propor algo inviável.
A boa experiência surge quando essas três dimensões trabalham juntas.
Para o programador COBOL iniciante, essa visão é especialmente valiosa.
Você poderá trabalhar em sistemas nos quais:
uma tela Web chama uma API;
a API acessa o z/OS;
o z/OS Connect chama o CICS;
o CICS executa um programa COBOL;
o COBOL consulta Db2 ou VSAM;
o resultado retorna para o navegador.
O usuário talvez nunca saiba que existe COBOL atrás daquela tela.
Mas sentirá imediatamente quando a interação for confusa, lenta ou incompleta.
Essa é a grande verdade escondida no subsolo do Web Design:
O usuário não enxerga a arquitetura inteira, mas experimenta todas as consequências dela.
Portanto, antes de perguntar apenas:
Está bonito?
Pergunte:
Está claro?
Está acessível?
Está organizado?
Está conectado ao sistema?
Está preparado para erros?
Está ajudando alguém?
Porque no mundo real das aplicações, interfaces mal projetadas raramente desaparecem.
Elas continuam caminhando.
Entram em produção.
Espalham confusão.
Geram chamados.
Produzem retrabalho.
E, quando ninguém investiga a causa, voltam na próxima versão com um novo layout, uma nova fonte e os mesmos velhos problemas.
No Bellacosa Mainframe, aprendemos a regra definitiva de sobrevivência:
Nunca julgue um sistema apenas pela tela inicial.
Atrás de cada botão existe uma operação.
Atrás de cada mensagem existe uma decisão.
Atrás de cada interface existe uma arquitetura.
E atrás de toda boa arquitetura deve existir uma pessoa que consiga utilizá-la sem precisar lutar contra ela.
Publicidade, assinaturas, trials, renovação automática, autoplay, pop-ups, pageviews, fidelização, dark patterns, atenção, dados, bandwidth — e o dia em que Kazuma descobriu que os 90 dias grátis custavam exatamente o cartão de crédito que ele havia esquecido de cancelar.
Sob a batuta de Kazuma Satou, de KonoSuba: porque, quando alguém em Axel oferece alguma coisa de graça, o aventureiro experiente primeiro procura onde está escrito “renovação automática”.
🎬 PRÓLOGO — KAZUMA, É GRÁTIS!
Aqua entrou correndo pela porta da guilda.
— KAZUMA! KAZUMA! Descobri uma coisa fantástica!
Kazuma nem levantou os olhos.
Depois de conhecer Aqua, aprendera que as palavras “fantástica”, “oportunidade” e “grátis” normalmente eram os primeiros três passos de alguma catástrofe financeira.
— O que você fez?
— Nada!
— Quanto devemos?
— Ainda nada!
Kazuma levantou os olhos.
“Ainda” era uma palavra extremamente preocupante.
Aqua colocou sobre a mesa uma placa:
90 DIAS TOTALMENTE GRÁTIS!
Experimente agora.
Cancele quando quiser.
Cartão necessário para ativação.
Kazuma olhou para ela.
Depois olhou para a placa.
Depois novamente para Aqua.
— Você colocou meu cartão?
— Claro! Era grátis!
Kazuma fechou os olhos.
Em algum lugar distante, provavelmente Megumin preparava uma Explosion.
Mas aquela explosão seria pequena comparada à que aconteceria dali a 90 dias.
Porque Aqua acabara de descobrir uma das magias mais poderosas do capitalismo digital:
a assinatura recorrente baseada no esquecimento humano.
Pegue seu café.
Hoje vamos entrar numa dungeon muito mais perigosa que o castelo do Rei Demônio.
A Dungeon da Assinatura Eterna.
📜 CAPÍTULO 1 — QUANDO PAGÁVAMOS PARA RECEBER PUBLICIDADE
Nossa aventura começa antes de streaming, cookies, aplicativos e autoplay.
Começa nas revistas e jornais.
Durante décadas havia uma relação comercial aparentemente simples:
LEITOR
|
+---- paga assinatura
|
v
EDITORA
|
+---- produz conteúdo
|
v
REVISTA
Bonito.
Até descobrirmos que havia outro fluxo:
ANUNCIANTE
|
+---- paga publicidade
|
v
EDITORA
|
+---- coloca anúncio
|
v
REVISTA
|
v
ASSINANTE
E então aparecia uma pergunta incômoda.
Se eu já estou pagando pela revista, por que uma parcela tão grande dela é publicidade?
Uma ou outra propaganda contextual não necessariamente incomodava.
Aliás, nas antigas revistas de informática, anúncios podiam ser interessantes.
Computadores.
Modems.
Cursos.
Livros.
Compiladores.
Hardware.
Software.
O anúncio fazia parte daquele universo.
O problema começava quando você comprava uma publicação de 150 páginas e percebia que dezenas delas eram publicidade.
Kazuma certamente perguntaria:
— Então eu pago pela revista e vocês também vendem minha atenção?
Sim.
— E meu desconto?
Não existe.
— Então pelo menos me deem alguma coisa.
Também não.
— AQUA! EXPLOSION NESSA EDITORA!
Calma, Kazuma.
Ainda piora.
🎁 CAPÍTULO 2 — O NOVO ASSINANTE GANHA A CANECA
Havia algo particularmente irritante.
Você assinava uma revista durante anos.
Pagava regularmente.
Renovava.
Nunca dava trabalho.
Até que encontrava um anúncio:
NOVOS ASSINANTES!
Assine agora e ganhe:
mochila + relógio + desconto + três edições extras!
Excelente!
Você ligava para renovar.
— Sou assinante há oito anos.
— Excelente, senhor.
— Quero renovar.
— São R$ 299.
— E a mochila?
— Somente para novos assinantes.
— E o relógio?
— Novos assinantes.
— E o desconto?
— Também.
Fantástico.
A empresa acabava de transmitir uma mensagem involuntária:
Obrigado pela fidelidade. Agora que sabemos que você já é nosso cliente, não precisamos mais conquistá-lo.
Esse é um erro gigantesco.
O presente poderia valer vinte reais.
Não importa.
O valor psicológico estava no reconhecimento.
O cliente antigo queria perceber:
“Minha permanência possui valor.”
Em vez disso, recebia:
IF CLIENTE-NOVO
MOVE DESCONTO TO PRECO
MOVE 'SIM' TO BRINDE
ELSE
MOVE PRECO-CHEIO TO PRECO
MOVE 'NAO' TO BRINDE
END-IF.
Parabéns.
Compilou.
Entrou em produção.
E criou um bug de relacionamento com o cliente.
🧙 CAPÍTULO 3 — MUDAMOS PARA A INTERNET E LEVAMOS O BUG JUNTO
Então chegou a revolução digital.
Adeus papel.
Olá Internet.
Adeus banca.
Olá aplicativo.
Adeus ficha de assinatura.
Olá cartão armazenado.
Poderíamos ter redesenhado todo o modelo.
Mas alguém aparentemente executou:
COPY BUSINESS-RULES-1987
TO DIGITAL-ECONOMY.
O brinde para novo assinante virou:
“Primeiros três meses por R$ 9,90.”
Enquanto isso, o assinante de cinco anos:
R$ 49,90.
A velha regra continuava viva.
O consumidor fiel começou então a aprender.
Cancela.
Espera.
Recebe oferta.
Volta.
A empresa treinou justamente o comportamento que não queria.
Depois de algumas iterações, qual comportamento o modelo aprende?
Cancelar.
Não precisamos nem de IA generativa para descobrir.
💳 CAPÍTULO 4 — OS 90 DIAS GRÁTIS DE AQUA
Agora chegamos à grande magia.
“Experimente gratuitamente durante 90 dias.”
Parece excelente.
Mas existem dois modelos completamente diferentes.
Modelo A:
90 dias grátis
|
v
período termina
|
v
quer contratar?
/ \
SIM NÃO
Modelo B:
CADASTRE O CARTÃO
|
v
90 dias grátis
|
v
você esqueceu?
|
SIM
|
v
COBRANÇA
No primeiro modelo, depois dos 90 dias a empresa precisa convencê-lo novamente.
No segundo, basta você não fazer nada.
A ausência de decisão tornou-se uma decisão comercial.
E 90 dias são perfeitos para isso.
Você testa hoje.
Usa durante quatro dias.
Esquece.
A vida continua.
Trabalho.
Família.
Netflix.
Anime.
Mainframe.
COBOL.
CICS.
Db2.
Três meses depois:
COBRANÇA APROVADA — R$ 399,00.
— AQUA!!!
— Kazuma, eu achei que era grátis!
Eis o problema.
Era.
Durante 90 dias.
🔐 CAPÍTULO 5 — O RACF FINANCEIRO
Depois de cair algumas vezes nessas armadilhas, o consumidor aprende.
Algumas pessoas criam lembretes:
CANCELAR SERVIÇO X
DIA 27
ANTES DA COBRANÇA
Outras utilizam cartões virtuais ou mecanismos bancários de controle.
Há quem periodicamente revise todas as assinaturas.
A ideia é excelente do ponto de vista de governança:
recertificação.
No mainframe fazemos algo semelhante com acessos.
Fulano precisava daquela autorização há três anos.
Ainda precisa?
Talvez.
Talvez não.
Então revisamos.
Por que assinaturas não deveriam funcionar conceitualmente assim?
SUBSCRIPTION REVIEW
SERVIÇO A ............ KEEP
SERVIÇO B ............ KEEP
SERVIÇO C ............ CANCEL
TRIAL ESQUECIDO ...... CANCEL
APP USADO 1 VEZ ...... CANCEL
Trocar um cartão, porém, não deve ser considerado equivalente jurídico ou técnico ao cancelamento da assinatura: sistemas de pagamento podem empregar tokens e mecanismos de atualização, e o contrato pode continuar existindo.
Mas o princípio permanece interessante:
não permitir que uma autorização concedida anos atrás viva eternamente sem revisão.
Kazuma aprovaria.
RACF também.
😡 CAPÍTULO 6 — O ÓDIO DE ESTIMAÇÃO
Existe uma consequência que dificilmente aparece imediatamente no dashboard.
A empresa consegue cobrar aquela renovação.
Receita aumentou.
Excelente trimestre.
Mas o cliente pensa:
“Vocês me pegaram.”
Esse sentimento muda tudo.
O produto pode continuar excelente.
O consumidor simplesmente passa a não querer comprar daquela empresa.
Ou posterga.
Procura concorrente.
Espera promoção.
Compra somente quando absolutamente necessário.
Isso é quase uma dívida técnica de marketing.
Hoje:
RECEITA +10
Amanhã:
CONFIANÇA -50
O problema é que receita aparece facilmente no relatório trimestral.
Confiança não.
Até desaparecer.
📺 CAPÍTULO 7 — O CONTROLE REMOTO DEVOLVEU O PODER
Voltemos algumas décadas.
Antes do controle remoto, começou o comercial.
Você poderia levantar e trocar o canal.
Mas isso exigia esforço.
Então veio aquela pequena maravilha tecnológica:
o controle remoto.
Comercial começou?
CLICK.
Outro canal.
CLICK.
Outro.
Nasceu o zapping.
E aconteceu algo engraçado.
Você estava assistindo ao programa A.
Começou o comercial.
Foi ao programa B.
Gostou.
E nunca voltou.
O comercial que deveria financiar o canal A acabou entregando o telespectador ao canal B.
Depois chegaram videocassetes, DVRs e diferentes mecanismos para gravar programação e facilitar o avanço sobre intervalos.
O consumidor estava dizendo:
“Quero o conteúdo. Não necessariamente quero a interrupção.”
🌐 CAPÍTULO 8 — A INTERNET PERDEU O CONTROLE REMOTO
A Internet deveria ser a evolução definitiva desse controle.
Tecnicamente podemos escolher exatamente o que queremos consumir.
Mas surgiu uma guerra.
Publicidade.
Bloqueadores.
Anti-adblock.
Scripts.
Trackers.
Popups.
Vídeos.
Autoplay.
Redirecionamentos.
E lentamente perdemos algo fundamental:
o direito de ignorar.
Na revista bastava virar a página.
Na televisão, trocar o canal.
Na web, às vezes o anúncio literalmente tenta impedir que você chegue ao conteúdo.
Kazuma entra no site.
POPUP.
Fecha.
Outro popup.
Fecha.
Vídeo começa sozinho.
Silencia.
Cookie banner.
Fecha.
Newsletter.
“Não, obrigado.”
Notificação.
“Permitir?”
Não.
“Detectamos que você está utilizando um bloqueador de anúncios.”
Kazuma olha para Aqua.
— Nós ainda não chegamos ao artigo?
— Não.
— Darkness?
— Estou gostando.
Naturalmente.
👹 CAPÍTULO 9 — OS POPUPS DA DUNGEON
Existe publicidade.
E existe agressão à navegação.
Você clica em uma página.
De repente:
CLICK
|
+-- artigo
|
+-- anúncio
|
+-- nova aba
|
+-- popup
|
+-- pop-under
|
+-- redirecionamento
|
+-- página completamente aleatória
Você pediu uma coisa.
Recebeu sete.
Isso deveria violar um princípio básico da interface:
UM CLIQUE = UMA INTENÇÃO.
Se clicou no artigo, abra o artigo.
Se clicou em Play, reproduza.
Se clicou no anúncio, abra o anúncio.
E principalmente:
SE CLICOU NO X, X SIGNIFICA FECHAR.
O X não deveria abrir uma nova aba.
Não deveria registrar interesse.
Não deveria redirecionar.
Deveria simplesmente:
IF USER-ACTION = 'CLOSE'
MOVE 'CLOSED' TO POPUP-STATUS
END-IF.
Não precisa de inteligência artificial.
🎥 CAPÍTULO 10 — AUTOPLAY: QUEM MANDOU BAIXAR ISSO?
Outro pequeno demônio:
vídeo automático.
Você abriu uma matéria para ler.
O site decidiu baixar vídeo.
Talvez com áudio.
Talvez publicidade.
E quem forneceu os recursos?
Você.
Sua conexão.
Seu dispositivo.
Sua bateria.
Sua memória.
Sua CPU.
Sua eletricidade.
Imagine a versão física.
Você compra uma revista.
Abre a página.
Um representante da empresa entra na sua casa e diz:
— Para imprimir nosso anúncio, podemos usar sua impressora, seu papel e sua tinta?
Absurdo.
Na Internet fazemos algo conceitualmente parecido sem sequer perceber.
O modelo civilizado seria:
THUMBNAIL
|
usuário decide
|
PLAY
|
download
|
vídeo
Não:
ABRIU A PÁGINA
|
DOWNLOAD
|
AUTOPLAY
|
CPU + RAM + BANDWIDTH
📖 CAPÍTULO 11 — NEXT... NEXT... NEXT...
Kazuma finalmente encontra um artigo interessante.
“As 10 maiores armadilhas das assinaturas digitais.”
Começa a ler.
Item 10.
NEXT.
Item 9.
NEXT.
Publicidade.
NEXT.
Item 8.
Kazuma fecha a página.
Fim.
Essa é outra aberração da web.
Uma matéria que poderia ser apresentada continuamente é artificialmente dividida:
PAGE 1
NEXT
PAGE 2
NEXT
PAGE 3
NEXT
PAGE 4
Por quê?
Em alguns casos há razões técnicas ou editoriais legítimas.
Mas também existe um incentivo evidente:
mais páginas = mais oportunidades de pageview e impressões publicitárias.
O dashboard comemora:
PAGEVIEWS ↑
AD IMPRESSIONS ↑
Enquanto uma métrica invisível despenca:
PACIÊNCIA DO LEITOR ↓↓↓↓↓
Scroll existe.
Lazy loading existe.
Capítulos existem.
Índice existe.
Não precisamos transformar uma reportagem em uma dungeon de dez andares.
📺 CAPÍTULO 12 — EU PAGAVA TV. ENTÃO COLOCARAM PUBLICIDADE.
Aqui encontramos outra ruptura importante.
Você contrata um serviço pago.
A relação percebida é:
DINHEIRO
|
v
CONTEÚDO + EXPERIÊNCIA
Então a empresa mantém o preço e acrescenta publicidade.
Agora:
DINHEIRO
|
+--------+
| |
v v
SERVIÇO PUBLICIDADE
|
v
TEMPO
O preço monetário não necessariamente mudou.
Mas o preço total da experiência mudou.
Agora você também paga com atenção.
E tempo.
Se uma hora de programação tiver doze minutos adicionais de publicidade, você não gastou apenas uma hora.
Gastou 72 minutos.
Faça isso repetidamente durante o ano e começamos a falar de muitas horas da vida dedicadas a algo que você não solicitou diretamente.
Kazuma perguntaria:
— Meu plano ficou mais barato?
Não.
— Ganhei conteúdo adicional?
Não necessariamente.
— Então por que tenho anúncios agora?
Porque conseguimos.
Essa talvez seja a pior resposta possível para um cliente.
💡 CAPÍTULO 13 — EU COMPREI A TV!
E chegamos a uma das partes mais interessantes da dungeon.
O consumidor já forneceu grande parte da infraestrutura.
Comprou a televisão.
Comprou o computador ou celular.
Comprou o roteador.
Paga eletricidade.
Paga Internet.
Paga assinatura.
Depois disso, eventualmente recebe publicidade utilizando justamente esses recursos.
Temos então:
CONSUMIDOR
|
+-- TV ..................... pago
+-- computador/celular ..... pago
+-- eletricidade ........... pago
+-- Internet ............... pago
+-- assinatura ............. pago
+-- tempo .................. fornecido
+-- atenção ................ fornecida
+-- dados/telemetria ....... dependendo do serviço
É importante reconhecer que produzir, licenciar e distribuir conteúdo também possui custos enormes.
Publicidade pode financiar conteúdo.
O problema não é sua mera existência.
A pergunta correta é:
QUAL É A TROCA?
Serviço gratuito financiado por publicidade?
Compreensível.
Plano barato explicitamente financiado por anúncios?
Escolha comercial clara.
Plano premium sem publicidade?
Também.
Mas quando o consumidor paga e posteriormente recebe uma experiência pior sem compensação perceptível, a relação muda.
📊 CAPÍTULO 14 — O PREÇO QUE NÃO APARECE NA FATURA
Talvez o maior erro seja pensar que preço significa apenas dinheiro.
Na economia digital existem vários preços:
preço financeiro;
preço em tempo;
preço em atenção;
preço em dados;
preço em banda;
preço computacional;
preço energético;
e preço em irritação.
Um serviço de R$ 30 pode subjetivamente parecer mais caro que um de R$ 50 quando o primeiro exige fechar popups, assistir publicidade, enfrentar autoplay e lutar para cancelar.
É o equivalente digital de comprar uma passagem barata e descobrir depois vinte tarifas adicionais.
📏 CAPÍTULO 15 — O CÓDIGO DE CONDUTA DOS 25%
E aqui surge uma proposta interessante.
Publicidade não precisa desaparecer.
Precisa de governança.
Imagine um código de conduta segundo o qual uma página editorial não pudesse dedicar mais de aproximadamente 25% de sua experiência visual à publicidade.
Mas espaço seria apenas uma dimensão.
Precisaríamos de um verdadeiro SLA publicitário.
ESPAÇO
A publicidade não deveria dominar a área útil destinada ao conteúdo.
BANDWIDTH
Vídeos publicitários não deveriam consumir grandes quantidades de dados antes de uma decisão do usuário.
CPU E MEMÓRIA
Scripts publicitários não deveriam transformar uma página simples em um benchmark de processador.
AUTOPLAY
Mídia deveria depender de consentimento explícito, especialmente quando envolve som ou transferência significativa de dados.
POPUPS
Nenhuma avalanche de janelas não solicitadas.
NAVEGAÇÃO
Um clique deveria corresponder à ação prometida.
LAYOUT
O artigo não deveria ficar pulando porque anúncios apareceram posteriormente.
INTEGRIDADE EDITORIAL
Uma matéria não deveria ser artificialmente fragmentada apenas para multiplicar pageviews.
Isso não seria uma guerra contra publicidade.
Seria uma tentativa de torná-la civilizada.
🧠 CAPÍTULO 16 — O DASHBOARD ESTÁ VERDE, KAZUMA!
Aqui está talvez a lição mais Mainframe desta história.
Finalmente alguém encontrou uma utilização adequada para renovação automática.
☕ EPÍLOGO — DEVOLVAM O CONTROLE REMOTO
Talvez toda esta conversa possa ser resumida numa tecnologia extremamente simples inventada décadas atrás.
O controle remoto.
Ele representava uma coisa maravilhosa:
controle.
Não quero assistir?
CLICK.
Quero silenciar?
CLICK.
Quero outro canal?
CLICK.
A Internet deveria ter ampliado esse poder.
Em muitos casos fez exatamente isso.
Em outros, porém, construímos sistemas extraordinariamente sofisticados para impedir o equivalente digital daquele CLICK.
E aí começamos uma guerra desnecessária entre consumidor, anunciante, plataforma e produtor de conteúdo.
Talvez o futuro não precise eliminar publicidade.
Talvez precise simplesmente recuperar um princípio antigo:
PUBLICIDADE DEVE PODER SER IGNORADA.
Uma boa relação comercial não deveria depender de aprisionar atenção.
Uma boa assinatura não deveria depender do esquecimento.
Um bom produto não deveria punir fidelidade.
Um bom trial não deveria torcer para que você esqueça a data.
Um bom site não deveria transformar leitura em prova de resistência.
E um cliente que paga não deveria descobrir que, além de pagar pelo conteúdo, forneceu a televisão, eletricidade, Internet, processador, memória, banda, dados, tempo e atenção necessários para alguém monetizá-lo novamente.
No Mainframe aprendemos uma lição fundamental:
recursos possuem dono, acesso possui regra e autorização não deveria significar autorização eterna.
Talvez a Internet precise aprender um pouco de RACF.
ICH408I
ADVERTISEMENT ACCESS DENIED
RESOURCE: USER.ATTENTION
ACCESS INTENT: UNLIMITED
REQUESTED: CONTROL
REASON:
USER NEVER GRANTED PERMISSION.
Kazuma finalmente termina seu café.
Aqua pergunta:
— Então você não quer os 90 dias grátis?
Kazuma olha para o formulário.
Olha para o campo:
CARTÃO DE CRÉDITO — OBRIGATÓRIO.
Levanta-se.
— Aqua...
— Sim?
— Vamos enfrentar o Rei Demônio.
— Mas por quê?!
Kazuma aponta para o formulário.
— Parece menos perigoso.
☕💳😂
☕ MORAL DO BELLACOSA MAINFRAME
Tecnologia mudou.
O papel virou tela.
O jornal virou portal.
A revista virou aplicativo.
O canal virou streaming.
A mala direta virou notificação.
O comercial virou publicidade programática.
A ficha de assinatura virou cartão tokenizado.
O videocassete virou cloud.
O controle remoto virou interface.
Mas algumas regras de negócio continuam executando como programas esquecidos há décadas.
E talvez esteja justamente aí o verdadeiro problema.
Fizemos a transformação digital da tecnologia.
Esquecemos de fazer a transformação digital do respeito ao cliente.
🧠 ALAN TURING E O CURRÍCULO INVISÍVEL DA COMPUTAÇÃO — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE PACIÊNCIA, SNAKE E CHATGPT ERAM PROFESSORES DISFARÇADOS
CP/M, DOS, Windows, UX, Paciência, Campo Minado, Office, pirataria, Snake, smartphones, memória procedural, capital cognitivo, prompts, IA generativa, agentes — e o dia em que Alan Turing perguntou quanto da nossa inteligência desperdiçamos simplesmente procurando onde esconderam novamente o botão.
🎬 PRÓLOGO — ALAN TURING ESTAVA SENTADO DIANTE DO TERMINAL
Imagine entrar no CPD pela manhã.
O ar-condicionado está naquele nível clássico:
temperatura ideal para computadores e pinguins.
Há um terminal esperando.
Você se senta.
Na cadeira ao lado está ninguém menos que Alan Turing.
Ele olha para a tela.
Depois olha para você.
Na tela aparece:
C:\>
— Sabe o que isso significa? — pergunta Turing.
O jovem programador COBOL responde:
— Que o computador está esperando um comando.
Turing sorri.
— Exatamente. Mas existe algo ainda mais importante. Ele está esperando que você saiba como fazer aquilo que deseja fazer.
Então ele escreve:
DIR
ENTER.
A lista de arquivos aparece.
— Durante décadas — continua Turing — ensinamos humanos a falar a linguagem das máquinas. Depois ensinamos máquinas a apresentar opções aos humanos. Agora estamos tentando ensinar máquinas a compreender o que os humanos querem.
E talvez essa seja uma maneira bastante interessante de contar a história da computação.
Não através de processadores.
Não através de gigabytes.
Nem sequer através de sistemas operacionais.
Mas através de uma pergunta:
Quanto o ser humano precisa aprender para conseguir dizer à máquina aquilo que deseja?
Prepare o café.
Porque vamos voltar ao tempo em que não havia botão Iniciar, não havia touchscreen, ninguém dizia “prompt engineering” e uma pequena cobrinha monocromática estava silenciosamente preparando milhões de pessoas para o futuro.
💾 CAPÍTULO 1 — QUANDO O COMPUTADOR NÃO TENTAVA ADIVINHAR NADA
Nos tempos do CP/M e posteriormente do DOS, utilizar um computador significava conhecer alguma coisa sobre o computador.
Se você não soubesse que determinado comando existia, dificilmente o descobriria olhando para:
C:\>
O prompt piscante não era exatamente um excelente vendedor.
Por outro lado, depois que você aprendia os comandos, acontecia algo maravilhoso:
velocidade.
Você pensava:
Quero descobrir meu endereço IP.
E escrevia:
ipconfig
Décadas depois, esse princípio continua vivo.
🦖 CAPÍTULO 2 — O DINOSSAURO QUE RECUSA A EXTINÇÃO
Precisamos fazer uma pequena correção arqueológica.
Quando alguém abre atualmente o Prompt de Comando do Windows e chama aquilo de “janela do DOS”, tecnicamente não está executando o velho MS-DOS.
É cmd.exe.
Mas para gerações que atravessaram DOS e Windows, a expressão ficou.
E existe uma razão pela qual terminais continuam sobrevivendo mesmo depois de décadas de interfaces gráficas.
Compare.
Na GUI:
INTENÇÃO
↓
PROCURAR CONFIGURAÇÕES
↓
ENCONTRAR A CATEGORIA
↓
ABRIR A JANELA
↓
PROCURAR SUBMENU
↓
ENCONTRAR OPÇÃO
↓
CLICAR
No terminal:
INTENÇÃO
↓
COMANDO
↓
ENTER
O terminal possui um problema enorme para iniciantes:
você precisa saber o comando.
Mas possui uma vantagem enorme para especialistas:
você já sabe o comando.
Alan Turing olha para nosso jovem COBOL e explica:
— Uma interface gráfica reduz o custo da descoberta. Uma interface de comandos reduz o custo da execução quando você já sabe exatamente o que deseja.
Essa distinção é fundamental.
A GUI não tornou a CLI inútil.
Elas resolvem problemas diferentes.
Até os princípios clássicos de usabilidade de Jakob Nielsen refletem essa tensão: interfaces devem favorecer reconhecimento em vez de exigir recordação, mas também oferecer flexibilidade e eficiência para usuários experientes.
📜 CAPÍTULO 3 — O .BAT, AVÔ DOS AGENTES DE IA
Agora nosso jovem programador encontra um arquivo:
BACKUP.BAT
Turing pergunta:
— O que você acha que aconteceu aqui?
Talvez alguém estivesse fazendo diariamente:
COPY C:\DADOS\*.TXT D:\BACKUP
COPY C:\RELAT\*.RPT D:\BACKUP
DIR D:\BACKUP
Até que pensou:
Raios, estou repetindo a mesma coisa todos os dias.
E criou um .BAT.
Parece banal.
Mas filosoficamente aconteceu algo importante.
Antes:
Eu executo cada passo.
Depois:
Eu descrevo os passos uma vez e mando a máquina repeti-los.
Nascia uma forma popular de automação pessoal.
Podemos desenhar uma linhagem:
.BAT
↓
MACRO
↓
SCRIPT
↓
AUTOMAÇÃO
↓
WORKFLOW
↓
RPA
↓
COPILOTO
↓
AGENTE DE IA
A tecnologia mudou enormemente.
O desejo humano mudou muito menos:
“Estou cansado de repetir isso. Computador, faça você.”
O que muda ao longo das décadas é quanto do COMO precisamos explicar.
Guarde isso.
Voltaremos ao assunto.
🪟 CAPÍTULO 4 — ENTÃO CHEGARAM AS JANELAS
A interface gráfica alterou radicalmente o contrato entre homem e computador.
Em vez de memorizar:
COPY
DEL
REN
DIR
o usuário passou a:
apontar;
clicar;
selecionar;
arrastar;
soltar;
abrir;
minimizar;
maximizar.
Agora as possibilidades estavam parcialmente visíveis.
O computador dizia:
“Aqui estão algumas coisas que você pode fazer.”
Isso foi revolucionário.
Mas apareceu um problema.
Milhões de pessoas não sabiam usar mouse.
Hoje parece absurdo.
Uma criança vê um mouse e rapidamente entende que existe uma relação entre movimento físico e ponteiro.
Mas alguém que nunca utilizou aquilo precisava aprender:
mão move
↓
mouse move
↓
ponteiro move
Depois:
apontar
clicar
duplo clique
arrastar
soltar
Como ensinar isso para milhões de pessoas?
Criar um curso?
Um manual de 300 páginas?
Alan Turing sorri.
— Tenho uma ideia melhor.
🃏 CAPÍTULO 5 — PACIÊNCIA ERA UM CURSO DE INFORMÁTICA DISFARÇADO
Abriu-se uma mesa verde.
Cartas apareceram.
Paciência.
O usuário pensava:
Vou jogar.
Mas enquanto tentava colocar o sete vermelho sobre o oito preto, estava aprendendo:
A retrospectiva oficial da Microsoft sobre Solitaire confirma justamente seu papel na familiarização dos usuários com o ambiente gráfico e com o mouse.
Aquilo era treinamento.
Só não parecia treinamento.
E aqui surge uma das grandes lições desta história:
Às vezes a ferramenta educacional mais eficiente é aquela que o aluno nem percebe que é uma aula.
Imagine a alternativa.
Curso corporativo
Módulo 4.2 — Técnicas de manipulação direta de objetos utilizando dispositivos apontadores.
Duração: três horas.
Coffee break às 15h30.
😂
Ou:
Paciência.
Escolha difícil.
💣 CAPÍTULO 6 — CAMPO MINADO E A DESCOBERTA DO ERRO BARATO
Outro professor estava esperando.
Campo Minado.
O jogo treinava precisão, posicionamento, interpretação visual e diferentes ações do mouse.
Mas havia algo ainda mais importante:
permissão para errar.
Imagine um funcionário começando a utilizar computador.
Ele encontra um documento importante.
Olha para uma opção desconhecida.
Pensa:
Se eu clicar nisso, será que apago alguma coisa?
Surge medo.
O medo reduz exploração.
Agora coloque o mesmo usuário no Campo Minado.
Clique.
💣
BOOM.
Morreu.
Terrível?
Não.
New Game
Começou novamente.
Temos:
AÇÃO
↓
FEEDBACK
↓
ERRO
↓
RECOMEÇO
↓
NOVA HIPÓTESE
↓
NOVA AÇÃO
O jogo cria uma espécie de sandbox cognitivo.
O erro custa quase nada.
Por isso jogos são extraordinários ambientes de aprendizado.
Eles permitem experimentar sem colocar a folha de pagamento da empresa em risco.
🧠 CAPÍTULO 7 — UM DIA VOCÊ PARA DE PENSAR NO MOUSE
Depois de milhares de cliques acontece algo curioso.
Você não pensa:
Preciso mover minha mão três centímetros para a direita.
Você simplesmente clica.
A habilidade tornou-se procedural.
É semelhante ao que acontece com um programador mainframe experiente diante do ISPF.
No início:
PF3 = END
Você precisa lembrar.
Algum tempo depois?
Seu dedo apertou PF3 antes de sua consciência terminar de formular:
Quero sair daqui.
Quem trabalha décadas com tecnologia acumula milhares dessas pequenas associações.
Atalhos.
Teclas.
Caminhos.
Comandos.
Gestos.
Convenções.
Isso possui valor.
Vamos dar um nome:
CAPITAL COGNITIVO.
💰 CAPÍTULO 8 — CONHECIMENTO DE INTERFACE TAMBÉM É INVESTIMENTO
Imagine que você gaste dez horas aprendendo uma ferramenta.
Depois passe anos utilizando-a.
Se determinado conhecimento economizar apenas trinta segundos numa operação realizada cinquenta vezes por dia:
Agora imagine que uma atualização chegue e decida:
Vamos reorganizar tudo!
Aquilo que era:
A → B → C
vira:
X → CONFIGURAÇÕES → AVANÇADO → Y → C
A tarefa continua sendo a mesma.
Você continua sabendo o que fazer.
Só não sabe mais onde esconderam aquilo.
Nasce o:
IMPOSTO DE REAPRENDIZADO.
😡 CAPÍTULO 9 — “EU SEI FAZER. SÓ NÃO SEI ONDE ESCONDERAM AGORA.”
Essa frase resume uma das frustrações mais interessantes da UX moderna.
O usuário não ficou incompetente.
A tarefa não mudou.
O conhecimento conceitual continua existindo.
O que foi destruído foi o mapeamento:
INTENÇÃO → INTERFACE
Imagine uma empresa com 100 mil funcionários.
Uma mudança aparentemente insignificante obriga cada funcionário a gastar vinte minutos reaprendendo alguma operação.
100.000 × 20 minutos
=
2.000.000 minutos
Mais de:
33.000 horas
de trabalho.
Repita pequenas mudanças assim diversas vezes.
Aquela reorganização “bonitinha” começa a possuir custo econômico.
Por isso precisamos acrescentar uma característica frequentemente esquecida da UX:
Estabilidade também é usabilidade.
Não significa congelar interfaces eternamente.
Significa perguntar:
Quanto do conhecimento anterior conseguimos preservar?
🏛️ CAPÍTULO 10 — O VELHO ISPF RI NO FUNDO DA SALA
Um programador jovem abre ISPF.
Olha.
Silêncio.
Depois pergunta:
— Isso veio junto com a tumba do Tutancâmon?
😂
Visualmente, algumas interfaces mainframe realmente carregam décadas de história.
Mas há um lado fascinante.
Conhecimentos adquiridos há muito tempo continuam produtivos.
Existe uma diferença entre:
FACILIDADE DE APRENDER
e:
LONGEVIDADE DO APRENDIZADO
Uma interface pode ser difícil inicialmente e extremamente estável.
Outra pode ser intuitiva inicialmente, porém constantemente reorganizada.
Não precisamos escolher um extremo.
A lição é:
UX deveria medir também quanto tempo o investimento cognitivo do usuário permanece útil.
Isso interessa especialmente ao mundo COBOL.
Sistemas corporativos não vivem seis meses.
Podem viver décadas.
Quando projetamos ferramentas para esses ambientes, conhecimento acumulado também é patrimônio.
🏴☠️ CAPÍTULO 11 — O ELEFANTE PIRATA NA SALA
Agora chegamos a uma questão histórica delicada.
Nos anos 1980 e início dos 1990 havia um ecossistema enorme de ferramentas.
Texto:
WordStar
WordPerfect
Planilhas:
Lotus 1-2-3
SuperCalc
Banco de dados:
dBASE III
dBASE IV
Apresentações:
Harvard Graphics
Posteriormente o ecossistema Microsoft integrou fortemente ferramentas como:
Word
Excel
PowerPoint
Access
E aconteceu um fenômeno interessante.
Muita gente passou a ter acesso doméstico a essas ferramentas — por canais legítimos e também, inegavelmente, através de cópias não licenciadas amplamente disseminadas naquela época.
Não devemos cometer o erro histórico de dizer:
“A Microsoft venceu por causa da pirataria.”
A história é muito mais complexa: integração, Windows, distribuição, formatos, contratos empresariais, compatibilidade, estratégia comercial e efeitos de rede também importam.
Mas existe uma hipótese muito interessante:
familiaridade doméstica reduzia o custo empresarial de adoção.
Essa é uma lição importantíssima para qualquer programador COBOL:
tecnologia nunca existe isoladamente.
🐍 CAPÍTULO 13 — ENTÃO UMA COBRINHA ENTROU NO TELEFONE
Avançamos para 1997.
Nokia 6110.
Uma tela monocromática minúscula.
Surge Snake.
A ideia do jogo era muito anterior — jogos desse gênero remontam aos anos 1970 — mas Taneli Armanto projetou e programou a versão do Nokia 6110 em 1997. Ele descreve um ambiente com aproximadamente 84 × 48 pixels, memória medida em kilobytes e teclado numérico como controle.
Hoje isso parece arqueologia.
Na época era mágico.
Mais importante:
Snake vinha instalado.
O usuário não precisava compreender lojas de aplicativos, downloads ou instalação.
Jogava.
Enquanto jogava, aprendia que aquele objeto tinha:
A linguagem natural permite entradas muito mais flexíveis.
Mas exige algo novo do usuário:
VERIFICAÇÃO.
Quanto menos precisamos especificar exatamente a entrada, mais precisamos avaliar criticamente a saída.
Para um programador COBOL isso deveria soar familiar.
Nunca coloque algo em produção simplesmente porque:
“Pareceu funcionar.”
Teste.
Valide.
Compare.
Registre.
Observe.
🐱 CAPÍTULO 18 — O GATO CAVALEIRO É A NOVA PACIÊNCIA
Agora chegamos ao ponto delicioso.
Milhões de pessoas entram numa IA e pedem:
Transforme meu gato em um cavaleiro medieval.
Parece bobagem.
E frequentemente é.
Mas observe o processo:
PROMPT
↓
RESULTADO RUIM
↓
REFORMULAÇÃO
↓
MAIS CONTEXTO
↓
NOVO RESULTADO
↓
RESTRIÇÃO
↓
REFINAMENTO
Sem perceber, aquela pessoa aprende:
prompting;
contexto;
especificação;
iteração;
multimodalidade;
avaliação;
limitações;
delegação.
Hoje:
Faça meu gato usar armadura.
Amanhã:
Compare estes quatro contratos, encontre cláusulas divergentes e produza uma tabela.
Depois:
Analise estes programas COBOL e identifique onde determinado copybook é utilizado.
A brincadeira pode estar treinando uma habilidade profissional futura.
Exatamente como Paciência treinou mouse.
🏴☠️ CAPÍTULO 19 — O FENÔMENO OFFICE PODE ESTAR SE REPETINDO
Observe:
OFFICE EM CASA
↓
APRENDIZADO
↓
HABILIDADE
↓
TRABALHO
↓
PRESSÃO POR ADOÇÃO
↓
OFFICE CORPORATIVO
Agora:
IA GRATUITA/DOMÉSTICA
↓
EXPERIMENTAÇÃO
↓
PROMPTING
↓
EXPECTATIVA
↓
TRABALHO
↓
“POR QUE FAZEMOS ISSO MANUALMENTE?”
↓
ADOÇÃO CORPORATIVA
Existe, porém, uma diferença perigosa.
No primeiro caso o funcionário levava principalmente habilidade para dentro da empresa.
Com IA pública, existe o risco de levar informação da empresa para fora.
Código-fonte.
Contratos.
Dados pessoais.
Planilhas.
Credenciais.
Documentação confidencial.
Por isso alfabetização em IA precisa incluir segurança.
A regra prática para o jovem programador é simples:
Nunca interprete facilidade de uso como autorização para fornecer dados.
🤖 CAPÍTULO 20 — DO PROMPT PARA O AGENTE
Agora chegamos à próxima etapa.
Um chatbot recebe:
Explique este programa COBOL.
Um copiloto pode ajudar enquanto você programa.
Um agente vai além.
Ele pode receber um objetivo, utilizar ferramentas, tomar decisões intermediárias e executar um workflow com certo grau de independência. Uma definição contemporânea de agentes destaca justamente sistemas que realizam tarefas em nome do usuário, controlando a execução do workflow e utilizando ferramentas externas quando necessário.
Veja a evolução:
1988
“EXECUTE ESTES COMANDOS.”
.BAT
2005
“EXECUTE ESTE SCRIPT.”
2015
“EXECUTE ESTE WORKFLOW.”
2026
“ALCANCE ESTE OBJETIVO.”
Isso é extraordinário.
Porque estamos transferindo cada vez mais HOW para a máquina.
🧙 CAPÍTULO 21 — TURING DESENHA A ESCADA DA ABSTRAÇÃO
Estamos construindo memória procedural para uma interface que ainda está nascendo.
Talvez daqui a vinte anos os agentes de IA sejam tão diferentes dos chatbots atuais quanto um smartphone é diferente de um Nokia 6110.
E alguém escreverá:
“No começo as pessoas entravam numa caixa de texto e conversavam manualmente com a IA.”
E outra pessoa responderá:
“Sério?”
Sim.
Sério.
Porque toda revolução computacional precisa resolver dois problemas.
Primeiro:
Construir a máquina.
Segundo:
Ensinar seres humanos a utilizá-la.
E esse segundo problema é frequentemente resolvido das maneiras mais improváveis.
Uma carta arrastada pela tela.
Uma mina explodindo.
Uma cobrinha procurando comida.
Um .BAT criado porque alguém estava cansado de digitar cinco comandos.
Um funcionário levando para a empresa aquilo que aprendeu em casa.
Um programador COBOL abrindo cmd.exe em 2026 porque sabe exatamente o que quer e não está com paciência para descobrir em qual submenu esconderam aquilo desta vez.
Ou alguém pedindo:
“Transforme meu gato em um paladino medieval.”
Parece brincadeira.
Talvez seja.
Mas o sujeito acaba de aprender a conversar com uma máquina probabilística.
Hoje ele pede um gato.
Amanhã pede análise de documentos.
Depois delega um workflow.
Finalmente entrega um objetivo.
E assim nossa velha linha evolutiva fica completa:
A grande pergunta para a próxima geração de UX talvez nem seja:
Como tornar a nova tecnologia mais fácil de aprender?
Talvez seja:
Quanto do conhecimento que o ser humano já conquistou nós temos o direito de jogar fora quando desenhamos a próxima interface?
Porque uma boa interface não deveria apenas ensinar o novo.
Ela deveria respeitar aquilo que o usuário levou anos para aprender.
E talvez essa seja a grande ironia de toda esta história:
Passamos décadas ensinando seres humanos a compreender computadores.
Agora estamos ensinando computadores a compreender seres humanos.
No meio do caminho havia uma Paciência, um Campo Minado, uma cobrinha...
...e um velho programador ainda digitando:
C:\>_
porque algumas interfaces simplesmente continuam funcionando.
Fim?
READY
Claro que não.
No mainframe sempre existe outro job esperando.
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🤖 Alan Turing entra no CPD
O mapa dos agentes de IA explicado por um mainframer
Esta série acompanha a evolução de uma ideia:
compreender os problemas modernos dos
agentes de inteligência artificial
usando conceitos conhecidos por quem trabalha com
mainframe, IBM Z e sistemas corporativos.
A viagem começa pelas pessoas e pela experiência de uso,
passa por observabilidade, priorização e execução,
chega às transações, estado e mensageria
e termina na organização hierárquica do contexto.
01
FEV / 2023
🧠 O currículo invisível da inteligência artificial
Antes de construir agentes inteligentes precisamos
preparar as pessoas que trabalharão com eles.
Técnica, pensamento crítico, conhecimento de negócio,
segurança, ética e responsabilidade formam o currículo
que nem sempre aparece no certificado.
Quando uma IA deixa de apenas responder e começa
a executar ações, sua interface precisa mostrar
objetivos, progresso, permissões e resultados.
PF3, MAXCC e RACF tornam-se excelentes analogias
para controle, retorno e privilégio mínimo.
Autonomia sem observabilidade cria uma caixa-preta.
Inspirado no SDSF do z/OS, este capítulo pergunta
como acompanhar agentes, tarefas, estados, filas,
falhas, logs e resultados em tempo real.
CPU, GPU, tokens, APIs e bancos de dados são recursos
finitos. O Workload Manager inspira uma discussão
sobre prioridades, objetivos de serviço, importância
do trabalho e distribuição dinâmica de recursos
entre agentes.
Quem recebe uma tarefa? Onde ela espera?
Quem decide quando poderá executar?
A lógica de entrada, filas, despacho, execução
e saída do JES2 oferece um paralelo interessante
para a orquestração do trabalho dos agentes.
Uma coisa é uma IA produzir texto.
Outra é permitir que ela execute operações reais
de negócio. CICS introduz a conversa sobre
processamento transacional, concorrência,
segurança e integridade.
Agentes precisam manter estado, checkpoints,
decisões e resultados. O Db2 fornece o ponto
de partida para discutir unidade de trabalho,
consistência, COMMIT, ROLLBACK e recuperação.
Sistemas de agentes não precisam conversar
sincronamente o tempo inteiro. IBM MQ conduz
a discussão para filas, mensagens, desacoplamento,
resiliência, retries, correlação e processamento
assíncrono.
Nem todo conhecimento precisa ser imaginado
como uma tabela. IMS leva a série para estruturas
hierárquicas, relações parent/child e navegação
contextual — conceitos úteis para pensar
organização e recuperação de contexto.
O artigo-âncora reúne toda a evolução da ideia:
pessoas, UX, observabilidade, prioridade,
orquestração, transações, estado, mensageria
e contexto transformam artigos independentes
em uma arquitetura conceitual para agentes de IA.
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
