☕ 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

quinta-feira, 15 de maio de 2025

🔥 CICS Mainframe — As Últimas Grandes Releases (Linha do Tempo Mítica)

 


🔥 CICS Mainframe — As Últimas Grandes Releases (Linha do Tempo Mítica)


Nota: a IBM evolui o CICS através de releases principais (major), com novidades, foco em produtividade, segurança e modernização contínua. Este índice usa datas de general availability históricas e o que cada versão trouxe de mais bacana, junto com curiosidades e contexto técnico.


🧠 Como ler este índice Bellacosa

Cada item abaixo tem:

Versão e versão legível
Data de lançamento (GA / Generally Available)
Fim do ciclo de suporte (quando aplicável)
Principais novidades
Comentários Bellacosa



🔟 1) CICS Transaction Server for z/OS 5.1

📅 GA: ~3 out 2012
📌 Fim de Vida: já fora de serviço
Principais novidades: foco em eficiência operacional e service agility — foi grande passo para integração com padrões web e automação.
💬 Bellacosa comenta: primeira versão que rompeu claramente com legado puro, abrindo portas para aplicativos modernos.


2) CICS TS 5.2

📅 GA: 7 abr 2014
📌 Fim de Vida: fora de serviço
Novidades: melhorias em SOA, JSON e REST, suporte a mobilidade e service delivery.
💬 Coffeelore: a galera bancária vibrou — finalmente dava pra integrar com apps modernos sem sacrificar velocidade.


3) CICS TS 5.3

📅 GA: 5 out 2015
📌 Fim de Vida: 31 dez 2021
Novidades: DevOps no mainstream, métricas expandidas, simplicidade de gestão e segurança mais firme.
🐣 Easteregg: a versão que “pegou fogo” por incluir mais de 300 pedidos de clientes!


4) CICS TS 5.4

📅 GA: 16 mai 2017
📌 Fim de Vida: 31 dez 2023
Novidades: Mixed language app-serving, APIs assíncronas potentes, gestão dinâmica e MQ ampliado.
💬 Bellacosa talk: começou a se parecer com um app server corporativo moderno.


5) CICS TS 5.5

📅 GA: 2 out 2018
📌 Fim de Vida: 30 set 2025 (planejado para z/OS?)
Novidades: Suporte a Node.js, GraphQL API, melhor CICS Explorer e segurança.
🔎 Curiosidade: primeira versão com foco explícito em modern workloads (JavaScript e Node).


6) CICS TS 5.6

📅 GA: 12 jun 2020
📌 Fim de Vida: não listado (suporte atual até pelo menos 2025)
Novidades: Experiência do dev, melhorias de resiliência, segurança e gerenciamento.
💬 Bellacosa: aqui o “desenvolvedor CICS” começou a cantar alto — Maven, Spring Boot ligando nativo.


7) CICS TS 6.1

📅 GA: 5 abr 2022
📌 Fim de Vida: não anunciado
Novidades: Produtividade de dev, segurança e gestão modernizada.
📌 Bellacosa insight: versão guardiã — preparou base para zero trust e infra crítica.


8) CICS TS 6.2

📅 GA: 14 jun 2024
📌 Fim de Vida: 30 set 2025
Novidades:

  • Suporte Java 17

  • Node.js 18

  • Contêiner e produtividade

  • Segurança e conformidade reforçada

  • Threadsafe data reads

  • Policy extensões
    🎉 Easteregg: CAFC já tinha day-one support no mesmo dia em 2024!


9) CICS TS 6.3

📅 GA: 05 set 2025 (confirmado)
📌 Fim de Vida: prevista ~2027/2028, sujeito a IBM SAP policy
Novidades anunciadas:

  • OpenTelemetry distributed tracing

  • Observabilidade e configuração simplificada

  • AI agent ready

  • Java 21, Jakarta EE 10, MicroProfile 6

  • VS Code dev experience

  • Mais segurança Zero Trust

  • Políticas enriquecidas e TLS extendido
    🚀 Bellacosa Spoiler: esta versão é a carta na manga para times que querem CICS moderno de verdade.


🧾 Releases “Ancestrais” (meramente contexto)

Antes da série 5.* e 6.*, houve clássicos que ainda ecoam:

  • CICS TS V3.1 / V3.2 — base sólida de integração e performance nos anos 2000

  • CICS TS V2.x série — primeira expansão empresarial no início dos anos 2000

  • E claro, versões históricas de OS/390 que definiram o padrão corporativo.


🧠 Linha do tempo Bellacosa (Resumo de Open e End of Life)

VersãoGAEnd of Life / EOSDestaque
5.12012EoS passadoAgilidade operacional
5.22014EoS passadoSOA / JSON / mobile
5.320152021DevOps e métricas
5.420172023Mixed-language & async
5.520182025+Node.js & GraphQL
5.62020suporteDev + Resiliência
6.12022suporteProdutividade & segurança
6.220242025Modern app support
6.32025futuroObservability & AI readiness

(EOS = End of Service; marcas com * estarão no manual oficial IBM Lifecycle)


🎓 Bellacosa Insights & Eastereggs

CICS nunca morre: a cada release, CICS não “recomeça”, ele amplia — ampliando suporte a linguagens modernas, contêineres e infra corporativa.
🐣 Dev-centric shift: CICS TS 5.5+ foi a transição de “sistema OLTP puro” para plataforma de desenvolvimento moderna.
🧠 Continuous delivery: além dos grandes marcos, IBM injeta capacidades via APAR e continuous delivery entre versões.


🚀 Conclusão Bellacosa

CICS segue vivo e evoluindo com:

Modernização para nuvem e contêiner
🔐 Segurança Zero Trust
📊 Observabilidade distribuída (OpenTelemetry)
🛠️ Experiência de desenvolvimento integrada (VS Code)

🔥 Lição de casa: dominar CICS TS não é conhecer versões — mas saber o que cada release habilita em arquitetura, dev experience e operações.

quarta-feira, 14 de maio de 2025

☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

Bellacosa Mainframe e a ajuda do watsonx no mainframe


☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

"Muitos Padawans acreditam que Inteligência Artificial significa apenas conversar com um chatbot. Os Mestres sabem que a verdadeira batalha acontece muito antes: na compreensão dos dados."


Introdução – O Dia em que o Padawan Descobriu que a IA Não Sabia o que era um PIC X(10)

Imagine a seguinte cena.

Você é um programador COBOL júnior.

Recebe a missão de modernizar uma aplicação bancária construída há quase quarenta anos.

O gerente de inovação aparece sorrindo.

— Vamos colocar IA nisso.

Você pensa:

— Fácil. Basta enviar os dados para um modelo generativo.

Então encontra o seguinte layout:

01 CLIENTE-REG.
   05 CLI-NUMERO        PIC 9(09).
   05 CLI-NOME          PIC X(40).
   05 CLI-RENDA-LIQ     PIC S9(07)V99.
   05 CLI-SITUACAO      PIC X.

A IA observa aquilo.

E responde:

Não faço ideia do que seja CLI-RENDA-LIQ.

Nesse momento, o Padawan aprende uma das maiores lições da Engenharia de Dados moderna.

IA não entende tabelas.

IA entende contexto.

E é exatamente aqui que entra o conceito de Data Intelligence.


Durante muitos anos, empresas compraram ferramentas separadas

O mercado tradicional funcionava assim.

Equipe de Governança:

Possui uma ferramenta.

Equipe de Qualidade:

Possui outra.

Equipe de Catálogo:

Possui outra.

Equipe de Linhagem:

Mais uma.

Equipe de Compliance:

Outra plataforma.

Equipe de Segurança:

Mais uma solução.

Resultado?

Cinco contratos.

Cinco bancos de metadados.

Cinco interfaces.

Cinco APIs.

Cinco equipes discutindo.

Algo parecido com isto:

Governança
     │
Qualidade
     │
Lineage
     │
Catálogo
     │
Compliance
     │
IA

Parece organizado.

Mas na prática é um enorme spaghetti corporativo.


O que a IBM percebeu

A IBM começou a observar um padrão interessante.

As perguntas feitas pelas equipes eram sempre parecidas.

Governança pergunta

Quem é o dono?

Quem aprovou?

Quem pode acessar?


Qualidade pergunta

Posso confiar?

Está completo?

Possui erros?


Lineage pergunta

De onde veio?

Quem alterou?

Qual programa produz?


IA pergunta

O que significa?

Posso usar?

Existe restrição?

Na realidade, todas essas perguntas falam sobre a mesma coisa.

Conhecimento sobre os dados.


A pilha do watsonx.data intelligence

Podemos imaginar a arquitetura como um holocron dividido em cinco camadas.


Primeira camada

Hybrid Cloud Platform

É a fundação.

Conecta:

Db2

Oracle

SAP

Snowflake

MongoDB

Kafka

AWS

Azure

IBM Z

IMS

VSAM

CICS

É como um grande tradutor universal.


Segunda camada

Data Governance

O catálogo corporativo.

Aqui ficam armazenadas informações como:

Campo:

CPF

Classificação:

PII

Sensível:

Sim

LGPD:

Aplicável

Owner:

Área Financeira


Terceira camada

Data Quality

Pergunta simples.

Posso confiar?

Exemplo.

Esperado:

CPF válido

99,99%

Encontrado:

88%

Problema detectado.


Quarta camada

Data Lineage

Talvez a mais fascinante.

Permite responder:

De onde veio?

Imagine:

COBOL

VSAM

DFSORT

Db2

Kafka

Data Lake

LLM

Tudo rastreado.


Quinta camada

Data Product Hub

Talvez seja a ideia mais moderna.

Os dados deixam de ser arquivos.

Viram produtos.

Exemplo.

Produto:

Customer360

Contém:

Dados cadastrais

Histórico

Score

Endereços

Risco

Consumidores:

Fraude

CRM

Analytics

IA


Um exemplo para o Programador COBOL Jr.

Imagine este campo.

05 CLI-RENDA-LIQ PIC S9(07)V99.

Você sabe o que significa.

Mas a IA não.

Precisamos adicionar conhecimento.

Nome comercial:

Renda Líquida Mensal

Descrição:

Valor recebido após descontos.

Periodicidade:

Mensal

Sensibilidade:

Alta

Origem:

Programa COBCL001

Arquivo:

CLIENTES.KSDS

Consumidores:

CRM

Motor de crédito

Modelo IA

Agora sim.

A IA consegue responder.

Pergunta:

"Qual renda média dos clientes premium?"

Resposta:

Campo identificado.

Qualidade validada.

Autorização concedida.

Origem conhecida.

Consulta realizada.


E o Mainframe?

Aqui está a parte que mais interessa ao leitor Bellacosa Mainframe.

O IBM Z sempre teve metadados.

Só nunca os chamamos assim.

O catálogo Db2

É metadado.


Copybooks

São metadados.


RACF

É metadado.


JCL

É metadado.


DBD IMS

É metadado.


SMF

É metadado.


SYS1.PARMLIB

Também.

Durante décadas, o Mainframe guardou informações valiosíssimas.

O problema é que elas estavam dispersas.

E não eram consumidas por modelos de IA.


O novo ouro das empresas

Muitos acreditam que o ativo mais importante seja o modelo generativo.

Não é.

Modelos podem ser trocados.

GPT.

Granite.

Llama.

Mistral.

Claude.

O diferencial competitivo está em algo muito mais difícil.

Os metadados.

Porque representam conhecimento acumulado.

Décadas de regras de negócio.

Decisões.

Políticas.

Histórico.

Governança.

É aquilo que impede uma IA de produzir respostas brilhantes e completamente erradas.


Conselhos para o Padawan COBOL

Se você está iniciando sua jornada no IBM Z, comece a olhar seus programas de outra forma.

Não enxergue apenas instruções COBOL.

Enxergue conhecimento de negócio.

Documente copybooks.

Padronize nomes.

Descreva regras.

Mantenha linhagem.

Entenda quem consome seus dados.

Aprenda governança.

Estude LGPD.

Conheça APIs.

Explore Data Mesh.

Entenda catálogos modernos.

Porque o profissional mais valorizado da próxima década talvez não seja aquele que apenas programa COBOL.

Será aquele capaz de explicar para uma Inteligência Artificial o significado dos cinquenta anos de sabedoria escondidos dentro de um simples:

05 CLI-RENDA-LIQ PIC S9(07)V99.

E quando esse dia chegar, o velho programador COBOL descobrirá algo surpreendente.

Ele nunca foi apenas um codificador.

Ele sempre foi o guardião dos holocrons de dados da empresa.

Espero que este artigo ajude o Padawan COBOL a perceber que Data Intelligence é, em grande parte, a evolução natural da disciplina que o Mainframe pratica há décadas: conhecer profundamente a origem, o significado, a qualidade e a responsabilidade de cada byte armazenado no sistema corporativo.


terça-feira, 13 de maio de 2025

O Paciente Vibe Coding: IA, COBOL e o Dia em que Programar Virou Conversar com a Máquina

Bellacosa Mainframe e a vibe coding

☕ Um Café no Bellacosa Mainframe

O Paciente Vibe Coding: IA, COBOL e o Dia em que Programar Virou Conversar com a Máquina

Imagine a seguinte cena.

São duas da manhã.

O CPD está silencioso.

Algumas luzes piscam no rack.

O JES2 continua recebendo jobs como se nada tivesse acontecido.

O Db2 segue trabalhando.

O CICS atende transações.

E em algum lugar existe um programador COBOL iniciante olhando para uma tela e pensando:

— Eu preciso mesmo aprender tudo isso?

Antes que alguém responda, a porta da sala se abre.

Entra um médico de sistemas.

Não usa estetoscópio.

Usa um terminal 3270.

Olha para o paciente.

O paciente é um jovem sistema chamado:

VIBE CODING.

Sintomas:

  • cria programas apenas com descrições;

  • escreve código em segundos;

  • corrige erros automaticamente;

  • às vezes inventa coisas que não existem;

  • parece extremamente inteligente;

  • eventualmente faz besteiras monumentais com absoluta confiança.

Diagnóstico preliminar:

Síndrome Aguda de Inteligência Artificial Assistida por Linguagem Natural.

Prognóstico:

Pode transformar completamente a programação.

Também pode destruir seu ambiente se você acreditar em tudo que ele diz.

Como qualquer bom médico de sistemas diria:

O código não mente.
Mas quem gera código pode estar errado.

E é exatamente aqui que começa nossa investigação.


1. Afinal, o que é Vibe Coding?

Vibe Coding é uma maneira de construir software utilizando principalmente linguagem natural.

Em vez de começar escrevendo código linha por linha, você descreve o que deseja.

Por exemplo:

Crie uma aplicação que permita cadastrar clientes, consultar saldo, fazer transferências e gerar um histórico de movimentações.

A Inteligência Artificial interpreta essa descrição e começa a criar:

  • arquivos;

  • funções;

  • classes;

  • banco de dados;

  • APIs;

  • páginas;

  • testes;

  • documentação;

  • scripts de instalação.

Você não está necessariamente programando no sentido tradicional.

Você está orientando a construção do software.

Essa diferença parece pequena.

Não é.

Durante décadas o processo normalmente era:

IDEIA
 ↓
REQUISITO
 ↓
ANÁLISE
 ↓
DESENHO
 ↓
CÓDIGO
 ↓
COMPILAÇÃO
 ↓
ERRO
 ↓
CORREÇÃO
 ↓
TESTE
 ↓
PRODUÇÃO

Com ferramentas baseadas em Inteligência Artificial, parte disso pode acontecer em uma conversa:

IDEIA
 ↓
PROMPT
 ↓
IA
 ↓
CÓDIGO
 ↓
TESTE
 ↓
CORREÇÃO

Em sistemas mais sofisticados:

OBJETIVO
 ↓
AGENTE IA
 ↓
PLANEJAMENTO
 ↓
IMPLEMENTAÇÃO
 ↓
TESTES
 ↓
AVALIAÇÃO
 ↓
CORREÇÃO
 ↓
NOVA TENTATIVA

É uma mudança de paradigma.


2. Quem inventou esse negócio?

O termo Vibe Coding ganhou popularidade em 2025 associado a Andrej Karpathy, conhecido por seu trabalho em Inteligência Artificial e redes neurais.

A expressão possui uma certa dose de brincadeira.

A ideia seria mais ou menos:

Você explica a "vibe" do que quer construir e deixa a IA resolver os detalhes.

Não quer dizer que ninguém escrevia código com IA antes.

GitHub Copilot, ChatGPT e ferramentas semelhantes já estavam sendo utilizados.

A diferença foi dar um nome a uma nova atitude diante da programação.

Não é apenas:

“IA, complete essa função.”

É algo mais próximo de:

“IA, faça esse sistema funcionar.”

Existe uma enorme diferença entre as duas frases.

Na primeira, a IA é assistente.

Na segunda, ela começa a assumir uma parcela muito maior da engenharia.


3. O programador COBOL encontra o Vibe Coding

Agora imagine alguém começando em COBOL.

Ele aprende:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

PROCEDURE DIVISION.

    DISPLAY 'HELLO WORLD'.

    STOP RUN.

Depois aprende:

WORKING-STORAGE SECTION.

01 WS-IDADE PIC 9(03).

PROCEDURE DIVISION.

    MOVE 25 TO WS-IDADE.

    IF WS-IDADE >= 18
        DISPLAY 'MAIOR DE IDADE'
    END-IF.

Depois aparecem:

  • arquivos sequenciais;

  • VSAM;

  • JCL;

  • Db2;

  • CICS;

  • IMS;

  • MQ;

  • RACF;

  • LE;

  • JES2;

  • datasets;

  • abends.

O jovem programador começa a suspeitar que escolheu a profissão errada.

Então aparece uma IA.

Ele pergunta:

Crie um programa COBOL que leia um arquivo de clientes e exiba apenas registros ativos.

A IA escreve algo.

O iniciante olha.

E pensa:

— Pronto. Acabou a profissão.

Não.

Calma.

Esse é o primeiro erro de diagnóstico.


4. IA gerar COBOL não significa IA entender seu mainframe

Essa distinção é fundamental.

Uma IA pode gerar:

READ ARQ-CLIENTES
    AT END
        SET EOF TO TRUE
    NOT AT END
        IF STATUS-CLIENTE = 'A'
            DISPLAY NOME-CLIENTE
        END-IF
END-READ

Isso é relativamente simples.

Agora diga:

Este programa participa do fechamento contábil de um banco, roda dentro de uma cadeia de 430 jobs, utiliza arquivos GDG, acessa Db2, envia mensagens MQ e precisa terminar antes das 05:40 porque às 06:00 começa a compensação.

Bem-vindo à medicina intensiva.

A IA pode conhecer:

  • COBOL;

  • JCL;

  • Db2;

  • MQ.

Mas talvez não conheça:

  • sua operação;

  • suas dependências;

  • seus datasets;

  • seus SLAs;

  • seus procedimentos;

  • suas convenções;

  • seus controles;

  • sua arquitetura histórica.

É aqui que o especialista humano continua essencial.


5. A grande ilusão: “a IA sabe programar”

É verdade.

E não é.

A IA é extraordinariamente boa em reconhecer padrões.

Se você disser:

Faça uma API REST de clientes em Java.

Ela provavelmente escreverá algo muito convincente.

Se disser:

Crie uma classe Python para acessar PostgreSQL.

Também.

Se disser:

Faça um JCL para executar um SORT.

Provavelmente também.

Mas existe uma diferença gigantesca entre:

gerar código plausível

e

garantir que esse código é correto no seu ambiente.

Esse é um dos pontos mais importantes deste artigo.

Uma IA pode produzir algo que:

  • compila;

  • executa;

  • parece bonito;

  • passa por testes simples;

e ainda assim está conceitualmente errado.


6. O sintoma mais perigoso: código convincente

Imagine um médico olhando um exame errado e dizendo com total segurança:

— Perfeito. O paciente está ótimo.

Esse é o equivalente técnico de uma IA produzindo código incorreto com aparência profissional.

Chamamos isso frequentemente de alucinação.

Por exemplo, a IA pode sugerir:

IBM.CICS.AUTO.REPAIR

como se fosse um parâmetro real.

Você procura.

Não existe.

Ou sugerir uma API.

Você abre a documentação.

Também não existe.

O modelo não está conscientemente mentindo.

Ele está produzindo uma sequência de palavras estatisticamente plausível.

Em desenvolvimento tradicional, o compilador geralmente avisa:

EI, ISSO NÃO EXISTE.

Mas alguns erros não aparecem na compilação.

Esse é o verdadeiro perigo.


7. Um programa pode funcionar e continuar errado

Considere:

COMPUTE WS-JUROS =
    WS-SALDO * 0.10

Perfeitamente válido.

Compila.

Executa.

Mas e se a taxa deveria ser:

0.01

O compilador não pode ajudar.

A IA também não pode saber, a menos que alguém informe.

Estamos falando de regra de negócio.

Esse é o coração de sistemas corporativos.

Programadores mainframe sabem disso muito bem.

Frequentemente o maior valor de um programa COBOL não está no código.

Está no conhecimento incorporado nele.

Pode existir uma regra escrita em 1989 que diz:

IF TIPO-CONTA = 17
   AND REGIAO = '03'
   AND DATA-MOVIMENTO < 19980101
       PERFORM ROTINA-ESPECIAL.

Por quê?

Ninguém sabe.

Apague.

Três dias depois metade da contabilidade explode.

E alguém aparece dizendo:

— Ah... isso existia por causa da fusão de 1997.

Esse tipo de conhecimento contextual ainda é um enorme desafio para sistemas de IA.


8. A história está se repetindo

Vamos voltar no tempo.

Na década de 1950, programação era extremamente próxima do hardware.

Imagine escrever instruções como:

LOAD
MOVE
ADD
JUMP
STORE

Então vieram linguagens de alto nível.

FORTRAN.

COBOL.

ALGOL.

Programadores Assembly reclamaram.

Provavelmente alguém disse:

Isso não é programação de verdade.

Décadas depois apareceu C.

Depois C++.

Depois Java.

Depois Python.

Depois frameworks.

Depois low-code.

Depois no-code.

Depois assistentes de IA.

Agora Vibe Coding.

Observe:

CÓDIGO DE MÁQUINA
        ↓
ASSEMBLY
        ↓
LINGUAGENS DE ALTO NÍVEL
        ↓
FRAMEWORKS
        ↓
LOW-CODE
        ↓
IA
        ↓
LINGUAGEM NATURAL

Cada camada abstrai alguma complexidade anterior.


9. COBOL já era uma forma ancestral de Vibe Coding?

Aqui temos uma bela curiosidade.

COBOL significa:

COmmon Business-Oriented Language.

Uma das filosofias da linguagem era facilitar a expressão de regras comerciais de forma relativamente próxima do inglês.

Compare Assembly:

L R1,VALUE1
A R1,VALUE2
ST R1,TOTAL

com COBOL:

ADD VALUE1 VALUE2
    GIVING TOTAL.

Agora compare com linguagem natural:

Some VALUE1 e VALUE2 e guarde em TOTAL.

A trajetória é evidente.

Talvez possamos brincar dizendo:

Assembly
 ↓
COBOL
 ↓
Prompt

Grace Hopper talvez olhasse para isso com bastante curiosidade.


10. Easter Egg: Grace Hopper entra na sala

Imagine Grace Hopper entrando no laboratório.

Um programador moderno mostra:

Crie um programa para calcular salários.

A IA gera COBOL.

Hopper observa.

Fica alguns segundos em silêncio.

Então provavelmente perguntaria:

— E quem valida o resultado?

Silêncio.

Esse talvez seja o principal conselho do Vibe Coding.

Nunca confunda geração com validação.


11. Prompt é o novo requisito?

Em parte.

Veja este prompt:

Faça um sistema bancário.

Resultado provável:

caos.

Agora:

Desenvolva uma aplicação bancária simples com cadastro de clientes, contas correntes, depósitos e transferências. Use autenticação, registre auditoria das operações, impeça saldo negativo e crie testes unitários para depósitos e transferências.

Muito melhor.

Agora evolua:

Nenhuma transferência pode ocorrer sem validação de saldo. Toda operação deve possuir timestamp, identificador de transação e trilha de auditoria. Operações superiores a R$ 10.000 devem ser registradas separadamente para análise.

Agora temos algo parecido com especificação.

O que aconteceu?

Você fez engenharia de requisitos.

Por isso existe uma ironia interessante.

A IA pode tornar o analista de sistemas ainda mais importante.


12. O melhor Vibe Coder talvez não seja o melhor digitador

Imagine dois profissionais.

Programador A:

digita 120 palavras por minuto.

Conhece a sintaxe inteira de Java.

Programador B:

entende profundamente:

  • arquitetura;

  • negócio;

  • segurança;

  • testes;

  • observabilidade;

  • infraestrutura.

Com IA gerando código, quem possui maior vantagem?

Provavelmente B.

Porque o gargalo muda.

Antes era:

Como escrever?

Agora começa a ser:

O que precisa ser feito?

E depois:

Como saber que está correto?


13. A nova profissão: programador como supervisor

Imagine uma oficina.

Antes:

HUMANO
 ↓
FAZ TUDO

Com IA:

HUMANO
 ↓
PLANEJA
 ↓
IA IMPLEMENTA
 ↓
HUMANO REVISA
 ↓
IA CORRIGE

O profissional muda de artesão puro para algo parecido com:

  • arquiteto;

  • supervisor;

  • revisor;

  • engenheiro;

  • operador.

Isso não significa que programação desaparece.

Significa que escrever código manualmente deixa de ocupar 100% do processo.


14. O programador júnior de velocidade absurda

Uma analogia muito útil é pensar na IA como um programador júnior com características bizarras.

Ele:

  • leu milhões de programas;

  • digita instantaneamente;

  • conhece centenas de linguagens;

  • nunca fica cansado;

  • trabalha 24 horas;

  • gera documentação;

  • escreve testes.

Mas possui um pequeno problema.

Às vezes inventa coisas.

E frequentemente não conhece seu ambiente.

Portanto você precisa dizer:

Não altere essa interface.

Não adicione dependências.

Preserve compatibilidade.

Use COBOL Enterprise 6.x.

O arquivo possui RECFM=FB.

LRECL=120.

Não altere o layout.

Quanto mais contexto correto você oferece, melhor.


15. Contexto é combustível

Dizer:

Corrija meu programa.

é pouco.

Dizer:

Este programa COBOL Enterprise 6.3 roda em z/OS, lê um VSAM KSDS pelo campo chave CLIENT-ID e recebe dados de CICS através de COMMAREA. O erro ocorre quando CLIENT-ID não existe.

é muito melhor.

A IA agora possui:

  • linguagem;

  • plataforma;

  • acesso;

  • estrutura;

  • condição do erro.

Resultado tende a melhorar drasticamente.


16. Vibe Coding e ferramentas modernas

O fenômeno cresceu porque surgiram ferramentas capazes de juntar diferentes capacidades.

Em vez de apenas gerar um trecho de código, ambientes modernos conseguem:

  1. ler o projeto;

  2. entender arquivos;

  3. alterar código;

  4. executar comandos;

  5. testar;

  6. examinar erros;

  7. corrigir;

  8. repetir.

Ferramentas conhecidas passaram a oferecer diferentes versões desse modelo.

Cursor.

Replit.

Lovable.

GitHub Copilot.

Windsurf.

Ambientes com agentes de programação.

O detalhe importante não é a marca.

É a arquitetura.

A IA deixou de ser apenas:

Pergunta → Resposta

e passou a ser:

OBJETIVO
 ↓
AÇÃO
 ↓
RESULTADO
 ↓
ANÁLISE
 ↓
NOVA AÇÃO

17. Isso nos leva aos agentes

Agora entramos em território ainda mais interessante.

Vibe Coding pode evoluir naturalmente para Agentic Coding.

Um agente pode receber:

Corrija o bug no módulo de cadastro.

Então:

  1. lê o código;

  2. encontra a função;

  3. procura logs;

  4. identifica possível causa;

  5. altera código;

  6. cria teste;

  7. executa;

  8. falha;

  9. modifica novamente;

  10. executa;

  11. passa.

Isso é muito mais poderoso que simples geração textual.

É um loop fechado.


18. O loop é fundamental

Considere dois sistemas.

Sistema A:

IA
 ↓
GERA CÓDIGO
 ↓
FIM

Sistema B:

IA
 ↓
GERA
 ↓
TESTA
 ↓
AVALIA
 ↓
CORRIGE
 ↓
TESTA

Sistema B possui uma vantagem gigantesca.

Ele recebe feedback.

Programadores humanos trabalham assim há décadas.

escreve
 ↓
compila
 ↓
erro
 ↓
corrige
 ↓
executa
 ↓
erro
 ↓
corrige

Agentes estão aprendendo exatamente esse ciclo.


19. Só que existe um novo problema

Um agente pode continuar tentando indefinidamente.

Imagine:

tentativa 1
tentativa 2
tentativa 3
tentativa 4
...
tentativa 329

Cada tentativa custa:

  • tokens;

  • CPU;

  • tempo;

  • dinheiro;

  • chamadas de API.

Portanto bons sistemas agentic precisam de limites.

Chamamos isso de guardrails.


20. Guardrails: cercas ao redor do robô

Nunca devemos simplesmente dizer:

Faça o que for necessário.

Principalmente em produção.

Melhor:

Você pode:
- ler código;
- criar testes;
- modificar ambiente DEV.

Você não pode:
- acessar produção;
- alterar RACF;
- deletar datasets;
- executar deploy sem aprovação.

Isso é governança.

No mainframe essa filosofia é familiar.

RACF já existe exatamente porque:

Nem todo usuário deve poder fazer tudo.

Agentes precisam da mesma disciplina.


21. Human-in-the-loop

Outro conceito essencial.

Significa manter seres humanos nos pontos críticos.

Por exemplo:

IA cria alteração
 ↓
IA executa testes
 ↓
IA gera relatório
 ↓
HUMANO APROVA
 ↓
DEPLOY

Isso é muito mais seguro que:

IA teve uma ideia
 ↓
PRODUÇÃO

Qualquer veterano mainframe provavelmente sentiu um arrepio lendo a segunda opção.

Com razão.


22. Vibe Coding não elimina DevOps

Pelo contrário.

Quanto mais rápido produzimos código, mais importantes tornam-se:

  • Git;

  • versionamento;

  • pipeline;

  • testes;

  • code review;

  • segurança;

  • observabilidade.

Imagine gerar 50 alterações em uma hora.

Sem governança, você simplesmente produz bugs mais rápido.

Portanto:

IA + DevOps

faz sentido.

Mas:

IA - DevOps

é receita para desastre.


23. O famoso “funciona na minha máquina”

Com IA ganha uma nova versão:

“Funcionou no ambiente da IA.”

Excelente.

Agora teste:

  • DEV;

  • QA;

  • homologação;

  • integração;

  • produção.

Porque software empresarial possui dependências invisíveis.


24. Exemplo COBOL completo

Imagine um pedido:

Crie um programa COBOL para calcular desconto de clientes VIP.

A IA produz:

IF CLIENTE-VIP = 'S'
    COMPUTE VALOR-FINAL =
        VALOR-COMPRA * 0.90
ELSE
    MOVE VALOR-COMPRA TO VALOR-FINAL
END-IF.

Parece perfeito.

Até o analista perguntar:

— Clientes VIP acima de 60 anos têm desconto adicional?

Silêncio.

E clientes corporativos?

Silêncio.

E compras internacionais?

Silêncio.

E arredondamento monetário?

Silêncio.

É por isso que conhecimento de negócio continua valendo ouro.


25. Easter Egg: o paciente “IF”

Nosso médico olha para o código:

IF CLIENTE-VIP = 'S'

e pergunta:

— Por que?

O programador responde:

— Porque a documentação mandou.

— Quem escreveu?

— Não sei.

— Quando?

— 1996.

— Ainda vale?

— Acho que sim.

O médico sorri.

Esse é o momento em que o caso deixa de ser programação e vira arqueologia corporativa.

Bem-vindo ao mainframe.


26. Vibe Coding pode ajudar iniciantes?

Muito.

Desde que seja utilizado corretamente.

Um iniciante pode perguntar:

Explique este trecho COBOL linha a linha.

Pode pedir:

Mostre como funciona OCCURS.

Depois:

Crie um exemplo usando OCCURS DEPENDING ON.

Depois:

Agora mostre o mesmo conceito utilizando uma tabela de clientes.

Isso cria um tutor personalizado.

É extraordinário.

Mas existe uma regra.

Não apenas copie.

Pergunte:

Por quê?


27. Método Bellacosa para aprender com IA

Experimente este fluxo.

Passo 1 — peça um exemplo simples

Crie um programa COBOL que some dois valores.

Passo 2 — peça explicação

Explique linha por linha.

Passo 3 — altere o problema

Agora leia os valores de um arquivo.

Passo 4 — introduza erro

O que acontece se o arquivo não existir?

Passo 5 — peça produção

Como esse programa seria diferente em ambiente bancário?

Passo 6 — peça testes

Crie casos de teste.

Passo 7 — questione a própria IA

Quais riscos existem no código que você criou?

Isso ensina muito mais do que simplesmente copiar código.


28. Nunca use IA apenas como copiadora

Use-a como:

  • professor;

  • debugger;

  • revisor;

  • colega;

  • explicador;

  • gerador de exemplos.

Uma pergunta poderosa:

Explique esse programa como se eu fosse um programador COBOL iniciante.

Outra:

Agora explique como um sysprog analisaria esse problema.

Outra:

Agora liste possíveis falhas em produção.

Perceba a evolução.

Você está explorando diferentes perspectivas.


29. Segurança merece atenção

Imagine pedir:

Crie uma API de transferência bancária.

A IA talvez produza algo funcional.

Mas segurança exige:

  • autenticação;

  • autorização;

  • validação;

  • criptografia;

  • proteção contra replay;

  • logs;

  • auditoria;

  • rate limiting;

  • tratamento de erros.

E mais.

Código funcional não significa código seguro.

Essa distinção será cada vez mais importante.


30. Observabilidade também

Se sua IA cria um sistema, pergunte:

Como saberei se ele está funcionando?

Você precisa de:

LOGS

MÉTRICAS

TRACES

ALERTAS

No mundo mainframe já utilizamos ferramentas equivalentes há décadas:

  • SMF;

  • RMF;

  • logs;

  • JES;

  • CICS statistics;

  • Db2 accounting;

  • monitors.

Nada disso perde importância com IA.

Na realidade, ganha importância.

Porque sistemas serão modificados mais rapidamente.


31. O futuro pode ser estranho

Talvez daqui alguns anos alguém abra uma IDE e diga:

Temos lentidão no fechamento mensal.

O agente responde:

Analisei SMF, WLM, logs do Db2 e histórico dos últimos seis meses. O tempo médio do job aumentou 23% depois da alteração do índice X. Criei uma mudança de teste em homologação e a execução caiu de 18 para 11 minutos. Deseja revisar?

Isso não é ficção absurda.

É a direção natural da integração entre IA, observabilidade e automação.


32. Então programadores vão desaparecer?

Provavelmente não.

Mas certas tarefas podem diminuir drasticamente.

Especialmente trabalho repetitivo.

Por exemplo:

  • criar CRUD;

  • gerar boilerplate;

  • escrever getters;

  • converter formatos;

  • escrever testes simples;

  • gerar documentação inicial.

Outras tarefas aumentam em importância:

  • arquitetura;

  • regras de negócio;

  • segurança;

  • decisão;

  • integração;

  • diagnóstico;

  • governança.


33. Quem deve ficar preocupado?

Talvez não quem sabe programar.

Talvez quem apenas digita código sem entender por quê.

Isso vale para qualquer tecnologia.

COBOL.

Java.

Python.

JavaScript.

A IA é muito boa em tarefas mecânicas.

Quanto mais seu trabalho depende exclusivamente de tarefas mecânicas, maior a pressão de automação.


34. Quem ganha vantagem?

Profissionais com conhecimento profundo.

Imagine um especialista que entende:

COBOL
+
CICS
+
DB2
+
NEGÓCIO BANCÁRIO
+
DEVOPS
+
IA

Esse profissional não perde valor.

Ele pode multiplicar sua produtividade.

Porque agora possui um exército de assistentes digitais.


35. O verdadeiro Superpoder

Não é escrever prompt bonito.

É saber dizer:

Isso está errado.

Imagine a IA produzindo 500 linhas.

O iniciante pensa:

— Impressionante.

O especialista olha por 30 segundos:

— Essa transação não pode atualizar essas duas tabelas nessa ordem.

Esse conhecimento vale muito.


36. Dica de ouro: peça evidências

Quando a IA recomendar alguma coisa, pergunte:

Por que?

Depois:

Qual documentação suporta isso?

Depois:

Quais alternativas existem?

Depois:

Quais riscos?

Esse pequeno hábito muda completamente a qualidade do trabalho.


37. Dica ainda melhor: peça autocrítica

Depois da IA gerar código:

Revise criticamente o código anterior.

Depois:

Procure vulnerabilidades.

Depois:

Procure race conditions.

Depois:

Procure problemas de performance.

Depois:

Procure problemas de manutenção.

Você transforma a IA em revisora da própria IA.

Não garante perfeição.

Mas aumenta muito a qualidade.


38. A regra das três perguntas

Antes de confiar em código gerado, pergunte:

1. Compila?

2. Funciona?

3. Faz o que deveria fazer?

Essas perguntas parecem iguais.

Não são.

Um programa pode:

COMPILAR = SIM

EXECUTAR = SIM

ESTAR CORRETO = NÃO

Essa distinção é absolutamente fundamental.


39. O paciente melhora

Nosso paciente Vibe Coding está agora sentado na maca.

O médico consulta os exames.

Sintaxe:

Excelente.

Produtividade:

Altíssima.

Velocidade:

Absurda.

Conhecimento contextual:

Variável.

Segurança:

Precisa supervisão.

Confiabilidade:

Depende de validação.

Diagnóstico final:

Ferramenta extremamente poderosa com risco severo de uso irresponsável.

Tratamento recomendado:

IA
+
ENGENHARIA
+
TESTES
+
GOVERNANÇA
+
HUMANO

40. A receita do doutor do mainframe

Para utilizar Vibe Coding sem criar um monstro:

  1. Entenda o problema antes de gerar código.

  2. Dê contexto suficiente.

  3. Estabeleça restrições.

  4. Gere pequenas alterações.

  5. Revise.

  6. Compile.

  7. Teste.

  8. Observe.

  9. Versione.

  10. Nunca entregue produção diretamente à IA sem controle.

Parece conservador?

Sim.

Também funciona.


41. Curiosidade final: o programador não desaparece, ele sobe de nível

Em cada revolução tecnológica ouvimos:

Essa profissão vai acabar.

Compiladores acabariam com programadores Assembly.

COBOL acabaria com programadores.

CASE tools acabariam com programadores.

Fourth Generation Languages acabariam com programadores.

Low-code acabaria com programadores.

Outsourcing acabaria com programadores.

Cloud acabaria com infraestrutura.

Agora IA acabará com programação.

A história costuma ser mais complicada.

Tecnologias raramente simplesmente apagam profissões.

Elas mudam o que é considerado trabalho valioso.


42. Easter Egg final: produção às 03:17

São 03:17.

O telefone toca.

Produção.

— O job AB1234 terminou com S0C7.

O jovem programador abre a IA.

Explique S0C7.

A IA responde:

Data Exception. Provavelmente operação numérica sobre campo contendo dados inválidos.

Excelente.

O jovem pergunta:

Corrija o programa.

A IA altera 47 linhas.

O veterano olha.

— Não.

O jovem:

— Por quê?

— Porque o erro está no arquivo de entrada.

Silêncio.

O veterano abre o dump.

Encontra:

VALOR = '12A45'

Ele aponta para a tela.

— A IA conhece COBOL.

— E você?

— Eu conheço o sistema.

Essa é talvez a melhor definição do futuro.

A máquina terá conhecimento gigantesco.

O humano continuará responsável por contexto, julgamento e consequência.


Conclusão

Vibe Coding não é simplesmente uma moda.

Também não é uma tecnologia mágica que elimina a necessidade de programadores.

É mais uma etapa na longa história da abstração da computação.

Máquina.

Assembly.

COBOL.

Linguagens modernas.

Frameworks.

Low-code.

IA.

Linguagem natural.

Estamos lentamente removendo a necessidade de dizer ao computador exatamente como fazer cada pequena coisa.

E migrando para uma época em que dizemos principalmente o que queremos.

Isso muda o papel do desenvolvedor.

O programador do futuro talvez escreva menos código.

Mas precisará compreender mais sistemas.

Precisará dominar:

  • arquitetura;

  • negócio;

  • segurança;

  • dados;

  • integração;

  • observabilidade;

  • governança;

  • testes.

Principalmente precisará desenvolver algo que nenhum autocomplete substitui facilmente:

juízo técnico.

Para quem está começando em COBOL, portanto, não veja a Inteligência Artificial como motivo para abandonar os fundamentos.

Faça o contrário.

Use-a para aprender mais rápido.

Pergunte.

Teste.

Quebre.

Investigue.

Compare.

Peça explicações.

Leia código antigo.

Observe dumps.

Entenda JCL.

Conheça Db2.

Descubra por que aquele programa de 1987 ainda está funcionando.

Porque talvez o profissional mais poderoso da próxima década não seja aquele que escreve dez mil linhas de código.

Talvez seja aquele capaz de olhar dez mil linhas escritas por uma IA e dizer:

“Aqui.”

“É exatamente aqui que vai dar problema.”

E nesse instante o programador COBOL iniciante compreenderá uma verdade antiga do mainframe:

tecnologia muda.

Ferramentas mudam.

Linguagens mudam.

Mas alguém sempre precisa entender o paciente.

segunda-feira, 12 de maio de 2025

O Rinoceronte que Dürer Nunca Viu — quando Portugal enviou um prompt para 1515 e a Europa gerou uma alucinação por 300 anos

 

Bellacosa Mainframe e a primeira alucinaçao em generacao texto para imagem Durer e o rinoceronte branco de portugal

☕ Um Café no Bellacosa Mainframe

O Rinoceronte que Dürer Nunca Viu — quando Portugal enviou um prompt para 1515 e a Europa gerou uma alucinação por 300 anos

🦏 Um rinoceronte verdadeiro chegou a Lisboa. Um artista que nunca o viu desenhou sua imagem. O animal morreu. A imagem errada sobreviveu durante séculos. Se isso não parece uma história sobre inteligência artificial, talvez seja porque aconteceu quinhentos anos cedo demais.

Existe uma experiência maravilhosa para quem gosta de caminhar por igrejas, museus e cidades antigas da Europa.

Observe os animais.

Não os animais verdadeiros.

Os animais esculpidos.

Especialmente os leões.

Passe algum tempo pelas igrejas medievais do interior da Itália e você acabará encontrando criaturas que, segundo toda a documentação disponível, são leões.

Você olha.

Olha novamente.

Inclina um pouco a cabeça.

Dá dois passos para trás.

Talvez seja a iluminação.

Não.

Aquilo parece o resultado de um relacionamento proibido entre um cachorro, um urso, um demônio e uma couve-flor.

Mas é um leão.

O escultor sabia que era um leão.

O padre sabia que era um leão.

A população sabia que era um leão.

E aparentemente ninguém perguntou:

— Giovanni... você já viu um leão?

Provavelmente não.

Eis nosso primeiro problema.

Durante grande parte da história humana, conhecemos o mundo sem necessariamente ver o mundo.

Alguém via.

Alguém descrevia.

Outro desenhava.

Outro copiava.

Outro traduzia.

Outro interpretava.

Séculos depois, aquilo se transformava na representação oficial da coisa.

Era uma espécie de inteligência artificial distribuída, só que extremamente lenta.

O modelo generativo era Giovanni.

O dataset era meia dúzia de manuscritos.

O treinamento levava vinte anos.

E a GPU era:

martelo + cinzel.

☕😆

Mas em 1515 aconteceu algo extraordinário.

Um animal desembarcou em Lisboa e entrou para a história da arte, da diplomacia, das navegações e, involuntariamente, daquilo que quinhentos anos depois chamaríamos de alucinação generativa.

Seu nome ficou conhecido como Ganda.

E ele era um rinoceronte.



🦏 Lisboa recebe um monstro — perfeitamente verdadeiro

Estamos em 1515.

Portugal vive o auge de sua expansão marítima.

Os portugueses haviam criado uma rede que ligava Europa, África, Índia e partes da Ásia.

Especiarias circulavam.

Mercadorias circulavam.

Cartas circulavam.

Informações circulavam.

Animais também.

E foi assim que um rinoceronte-indiano, Rhinoceros unicornis, acabou enviado ao rei D. Manuel I.

O animal chegou a Lisboa em 20 de maio de 1515.

Pare um segundo e tente imaginar isso sem utilizar nosso cérebro de 2026.

Nós sabemos perfeitamente como é um rinoceronte.

Mesmo quem nunca entrou num zoológico provavelmente já viu centenas deles.

Livros.

Televisão.

Documentários.

Fotografias.

Internet.

YouTube.

Desenhos infantis.

Google Images.

Em 1515 não existia absolutamente nada disso.

Para grande parte da população europeia, um rinoceronte pertencia praticamente ao mesmo universo mental dos animais descritos nos textos antigos e nos bestiários.

E então aparece um.

De verdade.

Respirando.

Andando.

Pesando toneladas.

Com pele grossa.

Um enorme chifre.

Imagine o primeiro cidadão português que olhou para aquilo.

LISBOA.SYSTEM — 1515

NEW DEVICE DETECTED

TYPE ............. UNKNOWN
ORIGIN ........... INDIA
WEIGHT ........... ABSURDO
ARMOR ............ POSSIBLE
HORN ............. YES
DOCUMENTATION .... PLINY.DAT

STATUS:

CARALHO.

☕🤣

Não era simplesmente um animal chegando a Lisboa.

Era a materialização de um mundo que até então grande parte dos europeus conhecia principalmente através de histórias.



👑 D. Manuel tinha um departamento de marketing extraordinário

D. Manuel I percebeu perfeitamente o valor político desses animais.

Portugal não estava apenas dizendo:

“Chegamos à Índia.”

Portugal podia mostrar:

“Quer prova?”

E colocar diante do visitante algo que veio da Índia.

Animais exóticos funcionavam como demonstrações vivas do alcance do império.

Hoje apresentaríamos gráficos.

GLOBAL PRESENCE

Portugal ............... ████████████
Trade Routes ........... ██████████
Asian Operations ....... ████████
Strategic Expansion .... █████████

Em 1515:

— Santidade, trouxemos um elefante.

Muito mais eficiente.

🤣

Aliás, o papa Leão X já havia recebido de D. Manuel um presente espetacular.

Um elefante.

Seu nome era Hanno.



🐘 Hanno entra em Roma

Em 1514, uma extraordinária embaixada portuguesa liderada por Tristão da Cunha chegou a Roma.

Era diplomacia transformada em espetáculo.

Presentes.

Tecidos.

Objetos preciosos.

Produtos orientais.

Animais.

E Hanno.

O elefante tornou-se uma verdadeira celebridade na corte papal.

Isso tinha uma mensagem política extremamente clara.

Portugal era pequeno no mapa europeu.

Mas havia conseguido colocar suas embarcações do outro lado do mundo.

O animal era praticamente uma demonstração tecnológica:

“Nossa infraestrutura logística chega onde a sua não chega.”

Então, quando o rinoceronte apareceu em Lisboa no ano seguinte, provavelmente alguém percebeu:

temos o presente perfeito para o Papa.



🐘 versus 🦏 — porque aparentemente isso precisava ser testado

Antes disso, porém, D. Manuel teria decidido testar uma história registrada desde a Antiguidade.

Textos antigos descreviam uma suposta rivalidade natural entre:

elefante e rinoceronte.

E Portugal possuía os dois.

É aquele momento perigoso em que alguém olha para uma documentação de 1.500 anos e diz:

“Temos ambiente de homologação. Vamos testar.”

🤣

Organizou-se então um encontro entre o rinoceronte e um elefante.

A expectativa era provavelmente:

ELEPHANT.EXE
      VS
RHINOCEROS.EXE

PRESS ENTER TO BEGIN

O combate épico não aconteceu.

Segundo os relatos tradicionais, o elefante se assustou com o rinoceronte e fugiu.

Resultado científico:

inconclusivo.

Resultado para a população:

MARAVILHOSO.



🎁 Vamos mandar o rinoceronte para o Papa

D. Manuel decidiu enviar o animal para Leão X.

Era um presente diplomático extraordinário.

O Papa já tinha recebido um elefante.

Agora receberia algo ainda mais raro na Europa:

um rinoceronte vivo.

Portugal estava praticamente executando:

//PAPAL001 JOB CLASS=DIPLOMACY
//STEP01   EXEC PGM=IMPRESSROME
//GIFT     DD  DSN=RHINOCEROS.INDIAN
//DEST     DD  CITY=ROME
//STATUS   DD  DISP=ALIVE

Só havia um problema.

Entre Lisboa e Roma existia uma coisa chamada:

mar.



🌊 E o Mediterrâneo executou ABEND

No final de 1515 o rinoceronte foi colocado num navio com destino à Itália.

Durante a viagem, porém, uma tempestade atingiu a embarcação próximo da costa da Ligúria, na região de Porto Venere/La Spezia.

O navio naufragou.

E Ganda morreu.

A tradição diz que o animal estava preso e, portanto, não conseguiu escapar do naufrágio.

É uma morte particularmente triste quando lembramos a jornada absurda daquele bicho.

Índia.

Oceano Índico.

Cabo da Boa Esperança.

Atlântico.

Lisboa.

Meses sendo observado por multidões.

Depois colocado novamente num navio.

Tudo porque reis europeus haviam descoberto que animais exóticos eram excelentes presentes diplomáticos.

DELIVERY STATUS

PACKAGE ............ RHINOCEROS
DESTINATION ........ POPE LEO X
EXPECTED ........... ALIVE
CURRENT ............ DEAD

ROOT CAUSE ......... SHIPWRECK

SEVERITY ........... 1

O pobre rinoceronte jamais chegou vivo a Roma.

Mas a história aparentemente ficou ainda mais macabra.



📦 “Santidade... sobre aquele rinoceronte...”

Relatos históricos posteriores indicam que o cadáver teria sido recuperado.

A pele teria sido preparada.

O animal teria sido empalhado ou recheado.

E então enviado para Roma.

Imagine a reunião de gerenciamento do incidente:

— O rinoceronte morreu.

— O Papa sabe?

— Ainda não.

— Conseguimos recuperar o animal?

— Mais ou menos.

— Defina “mais ou menos”.

— Temos o corpo.

Silêncio.

— Dá para entregar?

🤣🤣🤣

É possivelmente um dos maiores casos de:

“cumprimos parcialmente o SLA”

da história diplomática europeia.


🇮🇹 E aqui começa o folclore italiano

Existe uma deliciosa tradição anedótica segundo a qual episódios desse gênero teriam contribuído para uma fama italiana pouco elogiosa dos portugueses:

gente que promete grandes coisas e depois não entrega exatamente aquilo que prometeu.

É uma história maravilhosa.

Mas precisamos colocar uma etiqueta importante:

não encontrei documentação contemporânea suficiente para afirmar que esse estereótipo italiano tenha realmente nascido do desastre do rinoceronte.

Portanto:

NAVEGAÇÕES PORTUGUESAS .... DOCUMENTADO
RINOCERONTE EM LISBOA ..... DOCUMENTADO
PRESENTE PARA LEÃO X ...... DOCUMENTADO
NAUFRÁGIO ................. DOCUMENTADO
MORTE DO ANIMAL ........... DOCUMENTADO
CADÁVER RECUPERADO ......... RELATADO HISTORICAMENTE

"PORTUGUÊS NÃO ENTREGA"
ORIGINADO AQUI ............. FOLCLORE / NÃO COMPROVADO

E isso não estraga a história.

Pelo contrário.

Torna-a ainda melhor.

Porque nosso artigo é justamente sobre como acontecimentos reais adquirem novas camadas conforme são transmitidos.

O próprio rinoceronte está demonstrando o fenômeno.


🇵🇹 Antes disso, aparentemente todo italiano queria ser português

Existe ainda outra deliciosa tradição associada ao período de enorme prestígio português em Roma.

Conta-se que, durante uma grande celebração portuguesa, teria sido dada aos porteiros uma instrução:

portugueses poderiam entrar mesmo sem convite.

A intenção seria garantir que compatriotas não fossem barrados.

Excelente política.

Péssima implementação de segurança.

Porque alguém aparentemente descobriu o exploit.

AUTHENTICATION RULE:

IF invitation = TRUE
   ACCESS GRANTED
ELSE
   IF nationality = PORTUGUESE
      ACCESS GRANTED
   END-IF
END-IF

Problema:

nationality era self-declared.

🤣

Segundo a lenda, bastava o italiano descobrir que portugueses entravam sem convite para imediatamente encontrar dentro de si séculos de ancestralidade lusitana.

— Convite?

— Não tenho.

— Então não entra.

Ó pá!

— Português?

Ora pois, pois!

ACCESS GRANTED.

🤣🤣🤣

Daqui a pouco Roma inteira:

Ó PÁ! POIS! PORTUGAL! BACALHAU! CARALHO!

E os porteiros:

Bem-vindo, compatriota.

Novamente: é uma história que merece ser preservada como folclore, não promovida automaticamente a fato histórico.

Mas é deliciosa porque demonstra exatamente como histórias funcionam.

Talvez algo parecido tenha ocorrido.

Talvez cinco pessoas tenham feito isso.

A tradição transforma cinco em cinquenta.

Depois cinquenta em quinhentas.

Séculos depois:

A noite em que todos os picaretas italianos viraram portugueses.


🎨 Enquanto isso, em Nuremberg...

Agora finalmente entra nosso segundo protagonista.

Albrecht Dürer.

Um dos maiores artistas do Renascimento alemão.

Dürer soube da chegada do rinoceronte à Europa.

E decidiu representá-lo.

Há apenas um pequeno problema.

Dürer nunca viu Ganda.

Ele trabalhou a partir de informações que chegaram até ele — descrições e provavelmente uma representação anterior do animal.

Em outras palavras:

INPUT:
descrição textual
+
imagem de referência
+
conhecimento anterior

ORIGINAL OBJECT:
NOT AVAILABLE

TASK:
GENERATE RHINOCEROS

Meu amigo...

Albrecht Dürer executou text-to-image em 1515.

☕🤣


🖼️ E Dürer alucinou

Observe a famosa xilogravura.

O rinoceronte de Dürer parece usar uma armadura.

A pele foi transformada em placas.

Existem texturas elaboradíssimas.

Dobras parecem componentes mecânicos.

E há inclusive uma pequena estrutura semelhante a um segundo chifre sobre as costas.

Rinocerontes-indianos não possuem aquilo.

Mas existe uma explicação perfeitamente humana.

A pele do rinoceronte-indiano realmente possui grandes dobras e placas naturais.

Para alguém trabalhando a partir de uma descrição, aquilo podia ser interpretado utilizando um repertório conhecido.

Pele grossa.

Placas.

Proteção.

Europa do século XVI.

Armadura.

Dürer não estava necessariamente inventando arbitrariamente.

Ele estava inferindo.

E inferência é justamente aquilo que fazemos quando a informação disponível não é suficiente.


🤖 ALUCINAÇÃO GENERATIVA — 1515 EDITION

Aqui nossa história atravessa quinhentos anos.

Quando uma IA generativa recebe uma solicitação, ela não abre necessariamente uma janela e olha o objeto real.

Ela trabalha a partir das representações aprendidas e do contexto disponível.

Dürer enfrentou conceitualmente um problema semelhante.

DÜRER MODEL — 1515

TRAINING DATA:
animais conhecidos
armaduras
gravuras
textos clássicos
descrições
desenhos

PROMPT:
"Rinoceronte indiano recém-chegado a Lisboa"

ORIGINAL IMAGE:
UNAVAILABLE

GENERATING...

████████████████ 100%

OUTPUT:
RHINOCEROS.DURER

E o resultado era convincente.

Muito convincente.

Esse é justamente o problema.


📚 O erro começou a treinar o próximo erro

A xilogravura de Dürer foi reproduzida.

Muito.

Durante décadas.

Depois durante séculos.

A imagem apareceu em livros e coleções.

Outros artistas copiaram Dürer.

Pessoas que nunca tinham visto um rinoceronte passaram a conhecer o animal através daquela representação.

E aconteceu algo epistemologicamente maravilhoso:

a representação começou a substituir o objeto representado.

RINOCERONTE REAL
      ↓
DESCRIÇÃO
      ↓
DÜRER
      ↓
GRAVURA
      ↓
CÓPIA
      ↓
CÓPIA DA CÓPIA
      ↓
LIVRO
      ↓
OUTRO ARTISTA
      ↓
"É ASSIM QUE UM RINOCERONTE É"

A certa altura, alguém desenhando um rinoceronte não precisava mais consultar um rinoceronte.

Bastava consultar Dürer.

A saída anterior virou dataset.


🦁 Exatamente como os leões italianos

E voltamos às igrejas.

Aquele escultor medieval talvez nunca tivesse visto um leão.

Mas havia visto:

outro leão esculpido.

Uma iluminura.

Um manuscrito.

Um símbolo heráldico.

Uma representação religiosa.

Então reproduzia aquilo.

O próximo escultor copiava sua solução.

Depois de algumas gerações:

LEÃO REAL
   ↓
REPRESENTAÇÃO
   ↓
REPRESENTAÇÃO
   ↓
REPRESENTAÇÃO
   ↓
TRADIÇÃO

E aí surge uma possibilidade extraordinária.

Talvez corrigir aquele leão para deixá-lo zoologicamente perfeito pudesse fazê-lo parecer menos leão para a comunidade.

Porque a população aprendera que:

leão é aquilo.


❤️ Nós fazemos isso até hoje

Veja:

❤️

Isso não se parece muito com um coração humano.

Mas ninguém precisa explicar o símbolo.

A representação tornou-se independente do objeto.

O mesmo acontece com:

mapas,

ícones,

bandeiras,

emojis,

personagens,

estereótipos nacionais.

E agora:

imagens geradas por inteligência artificial.


🇧🇷 Peça para uma IA desenhar “um brasileiro”

Aqui começa outra experiência interessante.

O que é:

“um brasileiro típico”?

Um país com mais de duzentos milhões de habitantes.

Descendentes de indígenas.

Africanos.

Portugueses.

Italianos.

Alemães.

Japoneses.

Árabes.

Espanhóis.

Poloneses.

Ucranianos.

E dezenas de outras populações.

Não existe:

BRAZILIAN.DEFAULT.

Mas o sistema precisa gerar alguma coisa.

Então ele comprime.

SELECT
    MODE(symbols),
    MODE(clothing),
    MODE(appearance)
FROM cultural_representations
WHERE country = 'BRAZIL';

E talvez apareça:

pele bronzeada,

praia,

futebol,

Carnaval,

camiseta verde-amarela,

vegetação tropical.

Pronto.

Nasceu:

Brasilianus Stereotypicus.

🤣

Talvez aquela pessoa praticamente não exista.

Mas todos reconhecem imediatamente:

“brasileiro”.

É o rinoceronte de Dürer novamente.


🐉 E talvez alguns monstros tenham nascido assim

Agora nossa máquina de café fica perigosa.

Imagine relatos antigos atravessando milhares de quilômetros.

Um marinheiro vê um animal desconhecido.

Conta para outro.

O segundo conta para um mercador.

O mercador conta para um escriba.

O escriba traduz.

Outro copia.

Um ilustrador recebe a descrição.

ANIMAL GRANDE
QUATRO PATAS
UM CHIFRE
MUITO FORTE

O artista procura referências disponíveis.

Cavalo.

Boi.

Cabra.

Resultado:

unicórnio.

Não significa que unicórnios tenham necessariamente surgido dessa maneira específica.

Significa que esse mecanismo é perfeitamente capaz de fabricar criaturas coerentes a partir de informações fragmentárias.

É praticamente geração multimodal humana.


🧜 A sereia também pode entrar no backlog

Um marinheiro vê alguma criatura marinha.

Está cansado.

Está longe.

Observa por poucos segundos.

Conta depois:

“Parecia uma mulher.”

A frase viaja.

Na geração seguinte:

“Tinha corpo de mulher.”

Depois:

“Era metade mulher.”

Depois alguém desenha:

mulher + peixe.

BUILD SUCCESSFUL.

E a criatura entra em produção durante mil anos.


🏺 E o arqueólogo encontra nosso lixo

Agora imagine 2726.

Arqueólogos encontram milhões de imagens produzidas por IA no início do século XXI.

Eles observam brasileiros.

Muitos aparecem:

na praia,

com futebol,

Carnaval,

capivaras,

Cristo Redentor.

O pesquisador publica:

“Representações ritualísticas do povo brasileiro durante o período inicial da Inteligência Artificial.”

🤣🤣🤣

E tecnicamente estará trabalhando com evidência arqueológica real.

As imagens existem.

O problema será descobrir:

elas representam aquilo que existia ou aquilo que nossos sistemas acreditavam que existia?

Exatamente o problema que enfrentamos olhando para o rinoceronte de Dürer.


🧠 O verdadeiro problema não é a alucinação

Talvez seja a repetição.

Um erro isolado pode ser corrigido.

Mas um erro reproduzido milhares de vezes ganha autoridade.

Depois deixa de parecer erro.

Torna-se referência.

ERRO
 ↓
CÓPIA
 ↓
REPETIÇÃO
 ↓
FAMILIARIDADE
 ↓
AUTORIDADE
 ↓
TRADIÇÃO

E então acontece a inversão mais perigosa:

em vez de compararmos a representação com a realidade...

começamos a comparar a realidade com a representação.

— Esse rinoceronte está estranho.

Não.

O rinoceronte está certo.

Dürer é que estava errado.


🦏 O rinoceronte morreu. O rinoceronte de Dürer não.

Existe algo quase poético nisso.

Ganda atravessou oceanos.

Sobreviveu à viagem da Índia até Portugal.

Foi observado por milhares de pessoas.

Participou de uma experiência absurda com um elefante.

Virou instrumento diplomático.

Foi colocado novamente num navio.

Morreu numa tempestade tentando chegar ao Papa.

Seu corpo desapareceu da história.

Mas um homem que nunca o encontrou produziu uma imagem.

E aquela imagem atravessou:

cinco séculos.

O animal verdadeiro morreu.

A representação imperfeita tornou-se imortal.

Talvez seja uma das melhores demonstrações históricas do poder da informação.


☕ Um último café com Albrecht Dürer

Se pudéssemos colocar Dürer diante de um computador em 2026 e explicar inteligência artificial generativa, talvez ele não ficasse tão espantado quanto imaginamos.

Diríamos:

— Você descreve aquilo que deseja.

— Certo.

— A máquina utiliza aquilo que aprendeu anteriormente.

— Certo.

— Quando faltam informações, ela pode preencher lacunas.

— Naturalmente.

— Às vezes produz detalhes que não existem.

Dürer olha para seu rinoceronte.

Olha para nós.

E vocês só descobriram agora que isso acontece?

🤣

Talvez seja esse o detalhe mais divertido da história.

Não inventamos a alucinação generativa.

Automatizamos.

Durante milhares de anos, seres humanos receberam informações incompletas, consultaram aquilo que conheciam e preencheram o restante.

Chamamos isso de:

imaginação,

interpretação,

tradição,

arte,

mitologia,

cartografia,

folclore.

Em 2026 acrescentamos outro nome:

inteligência artificial.


🦏 $HASP395 RHINO ENDED

Talvez o maior legado daquele pobre rinoceronte não tenha sido chegar a Lisboa.

Nem impressionar D. Manuel.

Nem quase ser entregue ao Papa.

Nem aparecer numa das gravuras mais famosas do Renascimento.

Foi demonstrar, quinhentos anos antes da inteligência artificial generativa, algo profundamente humano:

quando não conseguimos observar diretamente o mundo, construímos uma representação dele com os dados disponíveis.

Às vezes acertamos.

Às vezes erramos.

Às vezes produzimos um rinoceronte usando armadura.

O verdadeiro perigo começa quando esquecemos que aquilo era apenas uma representação.

Porque então:

REALIDADE
   ↓
OBSERVAÇÃO
   ↓
DESCRIÇÃO
   ↓
INTERPRETAÇÃO
   ↓
REPRESENTAÇÃO
   ↓
CÓPIA
   ↓
REPETIÇÃO
   ↓
VERDADE APARENTE

Em 1515, o dataset era pequeno.

A rede era humana.

A transmissão levava meses.

O processamento acontecia dentro da cabeça de um artista.

A impressora era uma prensa.

E o armazenamento era papel.

Em 2026 temos bilhões de imagens, redes neurais, GPUs e geração em segundos.

Mas continuamos enfrentando a mesma pergunta:

Estamos olhando para a realidade ou para aquilo que milhares de representações anteriores nos ensinaram que a realidade deveria parecer?

Talvez algum arqueólogo em 2726 encontre nossas imagens e tenha exatamente o mesmo problema.

E provavelmente classificará metade delas como:

“objeto de representação sacrorreligiosa de função indeterminada.”

☕🤣

Enquanto isso, em algum lugar daquele grande datacenter celestial, Ganda finalmente abre um ticket:

FROM: GANDA
TO: HUMANITY
SUBJECT: CORREÇÃO DE DOCUMENTAÇÃO
PRIORITY: 1515

Prezados,

há aproximadamente cinco séculos
vocês continuam utilizando uma imagem
que não corresponde ao ambiente de produção.

Solicito correção.

Observação:

EU NÃO TINHA AQUELA ARMADURA.

Atenciosamente,

Ganda
Rhinoceros unicornis

E Major Tom finalmente responde:

TICKET RECEIVED.

STATUS:
KNOWN ERROR.

ESTIMATED FIX:

UNKNOWN.

☕🦏

Porque o rinoceronte morreu em 1516.

Mas a alucinação continua em produção.

sexta-feira, 2 de maio de 2025

Kotonoha Katsura em destaque homenagem de um otaku

Bellacosa Mainframe homenageia Kotonoha Katsura

Kotonoha Katsura em destaque homenagem de um otaku

Kotonoha Katsura é uma das personagens mais marcantes e trágicas do anime School Days (2007). Estudante do ensino médio, ela é apresentada como uma jovem extremamente gentil, educada, tímida e reservada. Sua beleza e comportamento delicado fazem dela a representação do arquétipo da "garota ideal" dos romances escolares japoneses.

Apesar da aparência frágil, Kotonoha possui uma grande capacidade de amar e confiar nas pessoas. Quando inicia seu relacionamento com Makoto Itou, entrega-se emocionalmente de forma sincera, abrindo espaço para que ele conheça sua vida pessoal, sua família e seus sentimentos mais profundos. Essa confiança absoluta é justamente o que torna sua trajetória tão dolorosa para muitos espectadores.

Ao longo da história, Kotonoha enfrenta rejeição, isolamento, humilhações e sucessivas decepções amorosas. Sua jornada mostra como a vulnerabilidade emocional pode ser explorada por pessoas egoístas e irresponsáveis. Diferente de outras personagens da série, ela raramente age por interesse próprio, o que faz com que muitos fãs a enxerguem como a principal vítima dos acontecimentos.

Mais do que uma personagem de romance, Kotonoha tornou-se um símbolo da confiança traída e do sofrimento emocional. Quase vinte anos após o lançamento de School Days, ela continua sendo lembrada como uma das figuras mais impactantes, debatidas e emocionantes da história dos animes. 🌸💔📼


🌳 O Universo Overflow

A série School Days pertence a uma linhagem de Visual Novels iniciada com:

1. Summer Radish Vacation!!

(2000)

Primeira aparição de alguns personagens que mais tarde seriam parentes de figuras importantes de School Days.


2. Shuffle! People?

(Não confundir com o anime Shuffle!)

Obra menor do universo Overflow.


3. Cross Days

(2010)

A mais famosa derivada de School Days.

Aqui Kotonoha aparece novamente.


4. Island Days

(2014)

Uma espécie de spin-off em ambiente de sobrevivência numa ilha.

Kotonoha também pode aparecer dependendo da rota.


5. Shiny Days

(2012)

Remake expandido de Summer Days.

Inclui várias personagens ligadas à árvore genealógica de School Days.


🎮 Cross Days

Esta é provavelmente a obra mais importante para quem gosta de Kotonoha.

Título Original

クロスデイズ

(Cross Days)

Lançamento

2010

Protagonista

Yuuki Ashikaga

Não é Makoto.


O que acontece?

A história ocorre paralelamente aos eventos de School Days.

Você observa vários acontecimentos sob outra perspectiva.

Kotonoha possui participação significativa dependendo da rota escolhida.


Curiosidade

Muitos fãs consideram algumas rotas de Cross Days mais satisfatórias para Kotonoha do que os eventos vistos no anime.


🌸 Shiny Days

Título Original

Shiny Days

Lançamento

2012

Remake de Summer Days.


Relação com Kotonoha

Ela aparece porque faz parte da gigantesca árvore genealógica do universo Overflow.

E aqui chegamos à parte mais curiosa.


☕💣 O UNIVERSO OVERFLOW É UMA CONFUSÃO GENEALÓGICA GIGANTESCA

Operador...

Prepare-se.

O universo School Days possui uma das árvores familiares mais bizarras dos animes e Visual Novels.

Existem:

  • primos

  • meios-irmãos

  • parentes distantes

  • relações cruzadas

Em alguns casos os próprios criadores brincavam com isso.

Muitos fãs chamam a árvore genealógica de:

"o JCL mais impossível já escrito"


📺 Kotonoha no Anime

No anime tradicional:

School Days (2007)

é sua única participação principal.

Ela não recebeu:

  • spin-off próprio;

  • série própria;

  • continuação focada nela.


😢 Por que ela nunca ganhou um spin-off?

Porque School Days foi concebido como uma tragédia.

A função narrativa de Kotonoha era representar:

  • amor idealizado;

  • confiança;

  • vulnerabilidade emocional.

O impacto da obra depende justamente da destruição dessa inocência.

Criar uma continuação poderia enfraquecer a mensagem original.


📚 Existe material extra?

Sim.

Há:

  • Drama CDs

  • Artbooks

  • Mangás

  • Visual Novels

Neles é possível ver lados diferentes da personagem.

Alguns apresentam situações mais leves e felizes do que o anime.


🌸 Um detalhe que muitos fãs não sabem

Na Visual Novel original existem rotas em que Kotonoha tem finais felizes.

Isso surpreende quem conhece apenas o anime.

Muita gente acredita que a tragédia é inevitável.

Não é.

Dependendo das escolhas do jogador:

  • Kotonoha pode ser feliz;

  • pode namorar Makoto;

  • pode evitar boa parte do sofrimento.

O anime escolheu deliberadamente uma das linhas mais sombrias possíveis.


☕💔 Veredito Bellacosa Mainframe

Talvez a razão pela qual tantos fãs continuam lembrando de Kotonoha quase vinte anos depois seja simples.

Ela não foi escrita para ser a garota mais engraçada.

Nem a mais poderosa.

Nem a mais carismática.

Ela foi escrita para ser a personagem que faz o espectador pensar:

"Ela merecia algo melhor."

E personagens assim são raros.

Por isso, mesmo existindo outras obras do universo Overflow, para muitos fãs a imagem definitiva de Kotonoha continua sendo aquela garota tímida que abriu seu coração, mostrou seu mundo, apresentou sua família e acabou se tornando uma das personagens mais trágicas da história dos romances em anime. ☕🌸💔📼


Bellacosa Mainframe e a doce kotonoha Katsura

🌸 Easteregg

O nome Kotonoha Katsura (桂 言葉) é extremamente simbólico e provavelmente foi escolhido de forma intencional pelos criadores de School Days.


🌸 Kotonoha (言葉)

O nome Kotonoha é escrito com os kanjis:

言葉

Que significam literalmente:

  • 言 (koto) = palavra, fala, dizer

  • 葉 (ha) = folha

Mas em japonês moderno:

言葉 (kotoba/kotonoha) significa:

"palavras"

"linguagem"

"expressão verbal"

A leitura "Kotonoha" é mais poética e literária.


☕ Interpretação Bellacosa Mainframe

Isso é quase uma ironia cruel.

Kotonoha significa:

"Palavras"

Mas durante boa parte do anime ela é justamente a personagem que:

  • tem dificuldade para se expressar;

  • guarda sentimentos;

  • não consegue comunicar sua dor;

  • permanece em silêncio quando deveria ser ouvida.

É como se o sistema tivesse um dataset chamado:

KOTONOHA = PALAVRAS

Mas ninguém executasse:

READ KOTONOHA

🌳 Katsura (桂)

O sobrenome:

Lê-se:

Katsura

Refere-se à árvore Katsura (Cercidiphyllum japonicum).

No simbolismo japonês ela é associada a:

  • elegância

  • beleza discreta

  • delicadeza

  • refinamento

Em algumas tradições também aparece ligada à Lua e à imortalidade.


🌸 O Significado Completo

Juntando os dois:

桂 言葉

Pode ser interpretado poeticamente como:

"Palavras delicadas"

ou

"Palavras elegantes"

ou ainda

"Folhas da árvore Katsura"

dependendo do contexto literário.


📖 Uma Curiosidade Interessante

Muitos personagens de School Days possuem nomes ligados a:

  • estações ferroviárias;

  • linhas de trem;

  • regiões de Tóquio.

Os criadores da Overflow tinham o hábito de usar referências geográficas reais para batizar personagens.

Por isso vários nomes da série possuem significados ocultos ou ligações com locais do Japão.


☕💔 A Triste Ironia de Kotonoha

Analisando a obra inteira, o nome dela se torna quase profético.

Ela é:

  • a personagem que mais ama;

  • a personagem que mais confia;

  • a personagem que mais sofre;

e ao mesmo tempo:

  • a que menos consegue ser ouvida.

Por isso muitos fãs enxergam um simbolismo involuntário ou proposital:

Kotonoha significa "palavras", mas sua tragédia nasce justamente porque suas palavras nunca foram realmente escutadas.

Talvez seja por isso que, quase vinte anos depois de School Days, o nome Kotonoha Katsura continue despertando tanta empatia entre os fãs. Ela não é lembrada apenas como uma personagem, mas como a voz de alguém que tentou amar, confiar e se comunicar... e que acabou sendo ignorada quando mais precisava ser ouvida. 🌸💔📼☕

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...