✨ 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
Embora não produza mangás, seus projetos chamam tanta atenção quanto uma grande obra de ficção científica.
Fairy Lights in Femtoseconds
Usa lasers ultrarrápidos para criar pontos luminosos no ar.
Literalmente.
Luz flutuando.
Parecia magia.
Mas era física.
Levitação Acústica
Talvez seu trabalho científico mais famoso.
Utiliza ondas ultrassônicas para suspender pequenos objetos.
Sem fios.
Sem ímãs.
Sem contato físico.
É um dos trabalhos que ajudaram a popularizar pesquisas sobre manipulação acústica. (arXiv)
Expo Osaka 2025
Foi um dos produtores temáticos da Expo 2025.
Criou instalações imersivas que misturam:
arquitetura
IA
computação
arte
filosofia oriental
Tudo baseado na ideia de Digital Nature. (Yoichi Ochiai)
Livros
Entre seus livros mais conhecidos:
Digital Nature
Magic Century
Survival Strategy in the AI Era
Future Changed by Generative AI
The World Atlas of 2030
Misturam filosofia, tecnologia e futuro da sociedade. (Yoichi Ochiai)
Prêmios
A lista impressiona.
Entre eles:
🏆 World Technology Award
🏆 Prix Ars Electronica
🏆 STARTS Prize
🏆 SXSW Creative Experience Awards
🏆 MIT Technology Review Innovators Under 35 Japan
🏆 Apollo 40 Under 40 Art & Tech
Pouquíssimos pesquisadores transitam com destaque entre ciência e arte dessa maneira. (Yoichi Ochiai)
Personagens?
Como não é mangaká,
ele não possui personagens clássicos.
Mas, metaforicamente, seus "personagens" são:
partículas de luz
ondas sonoras
algoritmos
IA
robôs
hologramas
pessoas interagindo com tecnologia
Ou seja...
o protagonista é o próprio futuro.
Polêmicas
Ochiai costuma gerar debates por defender uma integração profunda entre IA e sociedade.
Entre as discussões:
excesso de automação;
impacto da IA sobre empregos;
questões filosóficas sobre o que é "natural";
visão otimista em contraste com críticos da tecnologia.
São debates intelectuais, e não grandes escândalos pessoais conhecidos. (Yoichi Ochiai)
Curiosidades
Ele concluiu o doutorado muito rapidamente.
Foi considerado um dos jovens pesquisadores mais brilhantes do Japão.
Trabalha entre arte e engenharia.
Para ele:
não existe diferença.
É empresário.
Além da carreira acadêmica, atua no desenvolvimento de tecnologias aplicadas por meio da Pixie Dust Technologies.
Participa de políticas públicas
Já integrou conselhos ligados à inovação, cultura digital e tecnologia no Japão, influenciando discussões sobre o futuro da sociedade conectada. (Yoichi Ochiai)
Easter Eggs Bellacosa Mainframe
Easter Egg 1
Digital Nature lembra muito o conceito do z/OS:
O sistema operacional praticamente desaparece...
...mas está coordenando tudo.
Easter Egg 2
Para um programador COBOL,
um programa conversa com:
CICS
Db2
MQ
VSAM
Para Ochiai,
o programa conversa com:
árvores
luz
vidro
pessoas
cidades
Easter Egg 3
Se IBM criasse um laboratório dentro de um anime cyberpunk,
provavelmente pareceria um laboratório do Yoichi Ochiai.
O legado
Embora não desenhe mangás,
Yoichi Ochiai desenha algo talvez ainda maior:
uma visão de futuro.
Ele pertence à rara categoria de pessoas capazes de reunir:
arte;
ciência;
engenharia;
filosofia;
inteligência artificial;
design;
computação.
Seu trabalho inspira pesquisadores, artistas e engenheiros a imaginar um mundo onde a tecnologia deixa de ser apenas uma ferramenta e passa a integrar o ambiente de forma quase invisível — uma espécie de "sistema operacional" da realidade.
A Poesia Visual dos Animes: Quando o Desenho se Torna Emoção
Há quem veja o anime apenas como entretenimento — uma forma de fuga ou passatempo. Mas para quem observa com atenção, há algo muito mais profundo: uma poesia visual, um modo de sentir o mundo através da cor, da luz e do silêncio. Certos animes são verdadeiros quadros em movimento, retratando emoções que as palavras não alcançam.
🌸 A origem estética: da arte tradicional japonesa ao anime moderno
A beleza dos animes nasce das raízes da arte japonesa. As gravuras ukiyo-e do período Edo, o minimalismo zen e a filosofia wabi-sabi (a beleza do imperfeito e efêmero) influenciaram gerações de artistas e animadores.
Séries como Mononoke Hime (Princesa Mononoke) e Spirited Away, de Hayao Miyazaki, trazem planos amplos e neblinas sutis que lembram obras de Hokusai e Hiroshige. Não é apenas uma questão de estética, mas de espírito: capturar o que é passageiro, o instante antes de desaparecer.
Essa sensibilidade está ligada a um conceito japonês chamado ma — o espaço entre as coisas, o intervalo entre um som e outro, entre uma ação e outra. O anime faz poesia nesse silêncio.
🎨 Principais estilos visuais de anime
Realismo poético – detalhismo e iluminação emocional. (5 Centimeters per Second)
Estilo pictórico – traços soltos e texturas de pintura. (The Tale of Princess Kaguya)
Expressionismo emocional – distorções visuais para representar a alma. (Neon Genesis Evangelion)
Minimalismo atmosférico – o poder do silêncio e do vazio. (Mushishi)
✍️ Mestres que transformaram a animação em arte
Hayao Miyazaki (Studio Ghibli) – o poeta da infância e da natureza.
Makoto Shinkai – o pintor da luz e da saudade.
Isao Takahata – o cronista da fragilidade humana.
Masaaki Yuasa – o experimentalista do movimento.
Naoko Yamada – a diretora das emoções contidas.
Cada um, à sua maneira, entendeu que a arte do anime não está em “contar uma história”, mas em fazer o espectador senti-la.
💡 Dicas para apreciar a beleza de um anime
Pause. Observe o cenário — ele carrega tanto sentimento quanto o protagonista.
Ouça o som ambiente. Chuva, vento e passos são parte da poesia.
Repare na luz. Manhãs, crepúsculos e reflexos d’água são metáforas do tempo.
Descubra as referências. Muitos animadores visitam os locais reais que inspiram suas obras.
🎬 10 Animes Poéticos que São Verdadeiras Obras de Arte
1. Mushishi (2005) – Hiroshi Nagahama
Cada episódio é uma fábula sobre equilíbrio e solidão, com trilhas suaves e visuais que parecem pinturas em névoa.
2. 5 Centimeters per Second (2007) – Makoto Shinkai
A distância entre duas pessoas é medida pela beleza das estações. Um filme sobre o tempo e a impossibilidade de recomeçar.
3. The Tale of Princess Kaguya (2013) – Isao Takahata
Feito com traços de aquarela, é uma experiência sensorial sobre a efemeridade e o desejo de liberdade.
4. Spirited Away (2001) – Hayao Miyazaki
Um universo onírico onde o banal e o espiritual coexistem. Cada criatura carrega um símbolo.
5. Natsume Yūjin-chō (2008) – Takahiro Ōmori
Poético e suave, fala sobre empatia e aceitação dos invisíveis.
6. The Garden of Words (2013) – Makoto Shinkai
A chuva é a personagem principal. Cores e reflexos revelam o silêncio entre dois estranhos.
7. A Silent Voice (2016) – Naoko Yamada
Delicado e profundo, fala sobre redenção e a dificuldade de se comunicar.
8. Mononoke (2007) – Kenji Nakamura
Estilo visual único, inspirado em xilogravuras e pintura japonesa. Uma viagem sensorial ao sobrenatural.
Beleza em cada detalhe — flores, tecidos, cartas. Um retrato da humanidade através das palavras.
10. Haibane Renmei (2002) – Yoshitoshi ABe
Um conto metafísico sobre arrependimento e renascimento, com ritmo contemplativo e atmosfera sagrada.
✨ Conclusão: O instante que não volta
O anime é uma arte de emoções suspensas. Ele nos convida a desacelerar, a sentir o vento passando, a ouvir o som da chuva. Cada traço, cada pausa, carrega a alma do artista.
A verdadeira beleza do anime não está na história que ele conta, mas no instante que ele faz a gente lembrar — o olhar que dura um segundo, a luz que desaparece, a sensação de algo que foi e não volta mais.
Assistir a um bom anime é aprender a ver o mundo com os olhos da delicadeza.
Bellacosa Mainframe e o beija flor de 30 mil quadros feito em cartões perfurados
☕ Um Café no Bellacosa Mainframe
O Beija-flor que Entrou no Mainframe — Quando 30 Mil Quadros, Cartões Perfurados e um IBM 7094 Anteciparam a Arte Generativa
Ou: como Charles Csuri e James Shaffer fizeram um computador desenhar, distorcer, multiplicar e apagar uma ave em 1967 — décadas antes de prompts, GPUs, Transformers, LLMs e RAGs
Prólogo — o computador recebeu um pássaro, mas ninguém lhe deu asas
Em 1967, um professor de arte chamado Charles “Chuck” Csuri aproximou-se de um computador que ocupava uma sala, custava uma fortuna e não possuía monitor gráfico como conhecemos hoje.
Não havia mouse.
Não havia Photoshop.
Não havia terminal colorido.
Não havia botão escrito Generate.
Também não existia uma simpática caixa de texto perguntando:
“Como posso ajudá-lo hoje?”
Para produzir uma imagem, era necessário escrever um programa, preparar os parâmetros, perfurar cartões, submeter o trabalho ao centro de processamento, esperar sua vez e torcer para que um erro de digitação não transformasse algumas horas de processamento em uma elegante pilha de papel inútil.
Foi nesse ambiente que Csuri e o programador James Shaffer, trabalhando na Ohio State University, criaram Hummingbird: uma das primeiras animações artísticas produzidas com auxílio de computador.
O protagonista era um beija-flor desenhado com linhas.
O antagonista era praticamente todo o resto:
memória limitada;
processamento caro;
ausência de monitor gráfico;
programação matemática;
entrada por cartões;
processamento em lote;
gravação em película;
depuração sem interatividade;
e mais de 30 mil imagens que precisavam cooperar para que o pássaro parecesse vivo.
Para um desenvolvedor COBOL, a cena é familiar: o artista queria poesia, mas antes precisava acertar o arquivo de entrada.
1. Antes de Hummingbird: um artista atravessa a fronteira dos departamentos
Charles Csuri não começou como cientista da computação. Era artista, professor de arte e veterano da Segunda Guerra Mundial. Já possuía carreira acadêmica e presença no circuito artístico quando começou a perceber que o computador poderia ser mais do que uma máquina de cálculos científicos e administrativos.
Na primeira metade da década de 1960, computadores ainda eram associados principalmente a:
cálculos militares;
pesquisa nuclear;
engenharia;
astronomia;
balística;
processamento estatístico;
folhas de pagamento;
censos;
universidades e grandes empresas.
Utilizar uma máquina dessas para produzir arte parecia quase uma apropriação indevida de recurso corporativo:
“Vocês compraram esse equipamento para calcular trajetórias e ele está desenhando um pássaro?”
Em 1966, Csuri atravessou as fronteiras internas da Ohio State University e encontrou o programador James Shaffer. O próprio arquivo dedicado à obra de Csuri informa que ele procurou colaboração em outros departamentos, começou a trabalhar com Shaffer e aprendeu FORTRAN para transformar suas ideias artísticas em operações matemáticas. Naquele ambiente não existiam dispositivos gráficos interativos; o resultado visual saía principalmente por plotters. Arquivo de Charles Csuri
Essa colaboração é importante porque desmonta um mito moderno: o de que inovação nasce sempre de um gênio isolado.
Csuri dominava forma, movimento e intenção artística. Shaffer dominava programação e a realidade operacional do computador. Hummingbird nasceu na interface entre os dois.
Era, em linguagem atual, um projeto multidisciplinar:
Papel
Contribuição
Charles Csuri
conceito artístico, desenho, movimento e experimentação visual
James Shaffer
programação, transformação matemática e viabilização computacional
Centro de computação
mainframe, filas de processamento, cartões e periféricos
Plotter de microfilme
conversão das coordenadas calculadas em quadros de película
Processo cinematográfico
seleção, montagem e exibição das sequências
A primeira lição para o dev COBOL aparece antes mesmo do primeiro cartão:
Uma boa solução não nasce quando todos sabem a mesma coisa. Ela nasce quando conhecimentos diferentes conseguem conversar.
2. Afinal, o que era Hummingbird?
Hummingbird é uma animação experimental em preto e branco, produzida em 1967 e associada a Charles Csuri e James Shaffer.
Ela começa com o espaço vazio. Gradualmente, uma força invisível desenha um beija-flor com segmentos de linha. Em seguida, o computador transforma essa figura:
movimenta;
inclina;
dobra;
distorce;
fragmenta;
multiplica;
reorganiza;
conduz à abstração;
e finalmente apaga.
Não existe uma narrativa tradicional, diálogos ou personagens discutindo se as máquinas dominarão o mundo. A narrativa está no próprio comportamento da imagem.
O computador primeiro assume o papel de desenhista. Depois, o de animador. Em seguida, comporta-se como força transformadora. Por fim, converte-se em apagador.
A descrição do próprio Csuri apresenta uma ideia quase cinematográfica: o computador teria uma inteligência que desenha a ave, brinca com sua forma e, quando decide que “o tempo acabou”, elimina lentamente o pássaro e devolve a tela ao vazio. Descrição de Hummingbird por Charles Csuri
Isso não significa que o computador realmente tomasse decisões autônomas. A intenção e as regras haviam sido programadas. Entretanto, para o espectador de 1967, a ausência da mão do artista criava uma sensação inédita: havia uma força invisível produzindo e alterando o desenho.
Era uma provocação sobre autoria:
Se a linha não está sendo desenhada pela mão humana, quem está desenhando?
3. O computador não imaginou um beija-flor — ele recebeu uma geometria
Aqui é necessário retirar um pouco da fumaça da máquina.
Hummingbird não funcionava como uma IA generativa atual. Ninguém escreveu:
“Crie um beija-flor elegante, minimalista, em movimento, estilo plotter dos anos 1960.”
O sistema também não havia estudado milhões de fotografias de pássaros. Não possuía uma rede neural treinada para aprender o conceito de ave, asa, bico ou voo.
A figura original foi preparada como um desenho linear. Essa imagem foi representada computacionalmente por coordenadas e segmentos. O programa aplicava transformações matemáticas sobre essa estrutura:
translação;
rotação;
escalonamento;
distorção;
repetição;
fragmentação;
alteração progressiva de parâmetros.
Em termos simplificados, imagine o beija-flor como um conjunto de pontos:
Para movimentar a figura, o programa poderia somar deslocamentos:
Para girá-la:
Para distorcer o desenho, funções como curvas senoidais podiam modificar as coordenadas de maneira progressiva. Csuri já explorava esse princípio em obras como Sine Curve Man, na qual uma figura humana era alterada por mapeamentos de curva senoidal.
O que vemos, portanto, não é uma máquina “imaginando” um beija-flor, mas um programa transformando sua representação geométrica.
Entretanto, isso não diminui a obra. Pelo contrário: mostra que a arte generativa não começou com modelos capazes de produzir imagens fotográficas. Começou quando alguém percebeu que regras matemáticas poderiam gerar variações visuais impossíveis ou extremamente trabalhosas para a mão humana.
4. O elefante na sala: foi mesmo um IBM 7094?
O IBM 7094 é frequentemente associado aos primeiros experimentos de Csuri e aparece em bases históricas como equipamento usado em trabalhos seus daquele período. Era um dos grandes computadores científicos da primeira metade da década de 1960.
Entretanto, há uma pequena divergência digna de uma investigação do Bellacosa Mainframe.
Algumas fontes históricas associam diretamente o trabalho inicial de Csuri ao IBM 7094. Já uma retrospectiva acadêmica sobre computação gráfica na Ohio State informa que seus primeiros trabalhos utilizaram o 7094, mas que, em 1967, Csuri e Shaffer também trabalhavam com o IBM System/360 da universidade. História da computação gráfica na Ohio State
O MoMA descreve detalhadamente os cartões, as 30 mil imagens e o plotter de microfilme, mas não identifica o modelo do mainframe na ficha principal da obra. MoMA — Hummingbird
A maneira historicamente responsável de contar a história é esta:
O IBM 7094 fez parte da infraestrutura dos primeiros experimentos computacionais de Csuri, mas a documentação disponível também aponta a utilização de um IBM System/360 na Ohio State em 1967. Sem o relatório técnico completo da execução de cada sequência, não convém transformar o modelo exato da CPU em certeza absoluta para todos os quadros do filme.
Esse detalhe é uma bela lição sobre tecnologia antiga: quando várias plataformas, plotters, centros de processamento e versões de programa participam de um projeto, a pergunta “em qual computador foi feito?” pode ter mais de uma resposta.
É como perguntar em qual máquina foi processada uma aplicação bancária de quarenta anos que atravessou desenvolvimento, homologação, produção, migrações e reprocessamentos.
A resposta honesta pode ser:
“Qual execução?”
5. O que era o IBM 7094?
Anunciado em 1962, o IBM 7094 pertencia à família científica IBM 700/7000. Era descendente do IBM 7090 e utilizava transistores, memória de núcleos magnéticos e palavras de 36 bits.
Uma configuração padrão possuía aproximadamente:
32.768 palavras de memória;
36 bits por palavra;
cerca de 144 KiB brutos, se fizermos uma conversão aproximada;
sete registradores de índice;
aritmética de ponto flutuante;
suporte a dupla precisão;
canais de entrada e saída;
processamento em lote;
entrada por cartões, fitas e outros periféricos.
O equipamento era enorme, caro e destinado a universidades, centros científicos, forças armadas, indústria aeroespacial e grandes organizações. O 7094 esteve ligado a ambientes como NASA, laboratórios de pesquisa e projetos de computação compartilhada.
Uma referência histórica do MIT registra que um 7094 padrão possuía 32K palavras de 36 bits e podia realizar operações na ordem de aproximadamente 0,35 MIPS, dependendo do tipo de instrução e da forma de medição. História do IBM 7094 e CTSS
O mais importante não é compará-lo diretamente a um smartphone — comparação que geralmente produz números engraçados, mas pouco conhecimento. O importante é entender sua arquitetura operacional.
Ele não era “um computador pessoal muito lento”. Era um recurso institucional compartilhado.
O desenvolvedor não se sentava diante dele para experimentar livremente. Em muitos ambientes, preparava um job, entregava os cartões, aguardava o processamento e recebia a saída posteriormente.
Em outras palavras: era um antepassado sofisticado daquele velho ritual:
EDITAR
SUBMETER
ESPERAR
CONSULTAR O OUTPUT
DESCOBRIR UM ERRO
CORRIGIR
SUBMETER NOVAMENTE
O dev COBOL reconheceu o cheiro do café antes mesmo de chegar ao fim da lista.
6. Mais de 30 mil imagens: o render farm era uma fila de batch
Csuri relatou que foram geradas mais de 30 mil imagens, distribuídas em aproximadamente 25 sequências de movimento. Depois, trechos selecionados foram usados na animação final.
O MoMA informa que cada quadro era programado com o auxílio de um cartão perfurado e que as imagens eram desenhadas diretamente em filme por um plotter de microfilme. MoMA
Isso significa que a animação não foi criada quadro a quadro por um artista empunhando lápis. O programa produzia as coordenadas de cada estágio do movimento.
Mas alguém ainda precisava definir:
a posição inicial;
o ângulo;
a intensidade da distorção;
a velocidade da transformação;
o número de repetições;
o momento da fragmentação;
o comportamento de cada sequência;
a duração;
e a ordem dos efeitos.
Os parâmetros de cada quadro podiam ser fornecidos em cartões. Assim, a pilha de cartões funcionava como uma espécie de timeline física.
Cada cartão dizia, em essência:
“Neste instante, use estes valores.”
O cartão seguinte dizia:
“Agora altere ligeiramente o ângulo.”
O seguinte:
“Fragmente um pouco mais.”
E assim por diante.
A obra possuía, portanto, algo parecido com um arquivo de configuração gigantesco. O programa era o motor; os cartões eram os dados de controle; o plotter era o dispositivo de saída; a película era o meio final.
Para um dev COBOL, isso pode ser expresso assim:
PROGRAMA + ARQUIVO DE PARÂMETROS + PROCESSAMENTO BATCH + SAÍDA FÍSICA
Troque o beija-flor por um extrato bancário e alguém certamente perguntará qual é a LRECL.
7. O plotter de microfilme: a impressora que virou câmera
O IBM 7094 não possuía uma GPU moderna nem uma tela gráfica capaz de mostrar a animação em tempo real.
O programa calculava as linhas. Depois, um plotter de microfilme registrava as imagens diretamente em película.
O processo, de forma simplificada, era:
flowchart TD
A["Desenho vetorial"] --> B["Programa e parâmetros"]
B --> C["Mainframe calcula coordenadas"]
C --> D["Plotter de microfilme"]
D --> E["Quadros em película"]
E --> F["Seleção e montagem"]
Essa etapa é essencial. O computador não produzia um MP4, um GIF ou uma sequência PNG. Ele gerava instruções geométricas que um equipamento especializado convertia em imagens físicas.
A película precisava então ser tratada como cinema:
revelação;
inspeção;
seleção;
montagem;
projeção.
Se algo estivesse errado no programa, a falha não apareceria instantaneamente numa janela de preview. O erro poderia surgir somente depois de consumir processamento, material e trabalho laboratorial.
Essa distância entre código e resultado era um dos maiores desafios técnicos.
Hoje alteramos um prompt, clicamos novamente e reclamamos porque a imagem levou dois minutos.
Em 1967, dois minutos talvez fossem apenas o tempo necessário para localizar a caixa correta de cartões.
8. Os verdadeiros desafios técnicos
8.1 Ausência de feedback imediato
O artista não via a transformação enquanto ajustava o programa. Precisava imaginar matematicamente o resultado, submeter o job e analisar a saída.
Era desenvolvimento sem debugger visual, sem hot reload e sem preview.
8.2 Memória extremamente limitada
Toda a representação precisava caber num ambiente minúsculo pelos padrões atuais. Isso favorecia desenhos vetoriais, estruturas compactas e transformações calculadas.
8.3 Processamento compartilhado e caro
A máquina atendia vários pesquisadores. Tempo de CPU não era uma torneira aberta. A utilização artística do equipamento precisava conviver com prioridades acadêmicas e científicas.
8.4 Programação e arte falavam línguas diferentes
Uma intenção como “faça as asas parecerem vibrar” precisava ser traduzida em funções, coordenadas e variações numéricas.
O programador não podia compilar “sensação de voo”.
8.5 Controle de milhares de quadros
Uma mudança brusca de parâmetro poderia causar um salto visual. Os valores precisavam variar de maneira coerente entre quadros.
Era necessário criar o equivalente matemático do in-betweening da animação tradicional.
8.6 Saída cinematográfica
Mesmo que o cálculo estivesse correto, ainda havia riscos no plotter, no microfilme, na revelação, na seleção e na montagem.
O pipeline não terminava quando o job recebia retorno zero.
Aqui repousa uma lição eterna do mainframe:
RC=00 não significa que o negócio recebeu o resultado correto. Significa apenas que determinada etapa não declarou fracasso.
9. Quem financiou o pássaro?
Essa é uma área na qual convém evitar invenções.
As fontes institucionais consultadas confirmam a realização na Ohio State University, a colaboração com James Shaffer e o uso da infraestrutura computacional universitária. Porém, não encontrei documentação primária suficiente que identifique um patrocinador externo específico ou um orçamento exclusivo para Hummingbird.
Portanto, é mais seguro afirmar que o projeto nasceu dentro do ambiente acadêmico e utilizou recursos institucionais da universidade.
Não se deve afirmar, sem documento, que IBM, Departamento de Defesa, NASA ou determinada fundação “financiou o filme” apenas porque computadores daquela família eram usados por essas organizações.
O apoio pode ter ocorrido na forma mais valiosa e menos cinematográfica possível:
acesso à máquina;
tempo de processamento;
colaboração técnica;
laboratório;
plotter;
materiais;
liberdade acadêmica;
e tolerância institucional para uma experiência sem retorno comercial previsível.
Muitas inovações não começam com um cheque cinematográfico entregue por um executivo. Começam quando alguém com autoridade decide não interromper uma ideia estranha.
10. Lançamento, prêmio e entrada no MoMA
Hummingbird foi produzido em 1967 e recebeu reconhecimento na 4ª International Experimental Film Competition, em Bruxelas. Database of Digital Art
No ano seguinte, o MoMA organizou um programa de filmes gerados por computador associado à exposição The Machine as Seen at the End of the Mechanical Age. A programação incluiu Hummingbird ao lado de trabalhos de pioneiros como John Whitney.
Pouco depois, o museu adquiriu o filme. Ele se tornou uma das primeiras obras geradas por computador incorporadas à coleção do MoMA.
A versão registrada pelo museu é um filme em preto e branco, originalmente em 16 mm, com aproximadamente 12 minutos e classificado como silencioso. Algumas versões disponíveis na internet receberam trilha sonora posteriormente, o que explica por que muitos espectadores se lembram dele com som.
O verdadeiro impacto não foi apenas demonstrar que computadores faziam desenhos. Isso já vinha sendo experimentado.
Hummingbird mostrou que:
uma imagem figurativa podia ser descrita computacionalmente;
regras podiam produzir movimento;
parâmetros podiam gerar variações;
o computador podia participar do processo artístico;
uma figura reconhecível podia transitar para a abstração;
a repetição perfeita da máquina também podia produzir surpresa estética.
11. O easter egg do vazio
O detalhe mais interessante talvez não seja o pássaro, mas o espaço vazio antes e depois dele.
O filme começa sem imagem.
A máquina cria o beija-flor.
Depois o transforma, fragmenta e multiplica.
Finalmente o apaga.
Isso pode ser lido como uma demonstração técnica, mas também como uma metáfora:
o computador cria uma realidade;
explora as possibilidades dessa realidade;
produz cópias perfeitas;
perde a forma original em meio às transformações;
e elimina sua própria criação.
É difícil assistir hoje sem pensar em IA generativa, autoria, abundância de imagens e descarte digital.
Produzimos em segundos aquilo que talvez nunca seja visto novamente. A máquina cria, multiplica e o feed apaga.
O beija-flor de 1967 não tinha rede social, mas já conhecia o algoritmo.
12. Outro easter egg: o computador que cantava “Daisy”
A família IBM 7090/7094 também ocupa um lugar curioso na cultura da inteligência artificial.
Em 1961, pesquisadores da Bell Labs fizeram um IBM 7094 sintetizar a canção “Daisy Bell”. Arthur C. Clarke assistiu a uma demonstração e o episódio inspirou a cena de 2001: A Space Odyssey em que HAL 9000 canta “Daisy” enquanto suas funções cognitivas são desligadas.
Isso cria uma bela ponte cultural:
um computador dessa família canta;
outro participa dos primórdios da arte computacional;
HAL transforma a máquina pensante em personagem;
décadas depois, LLMs conversam, escrevem, resumem e produzem código.
O computador científico deixou de apenas calcular trajetórias. Ganhou voz, imagem e, na ficção, medo da morte.
13. Hummingbird era inteligência artificial?
Em sentido estrito, não era uma IA generativa comparável aos modelos atuais.
O programa não aprendia com dados, não treinava uma rede neural e não inferia uma nova imagem a partir de um prompt. As regras de transformação eram programadas explicitamente.
Mas a obra participava de uma questão central da IA:
Até que ponto uma máquina pode realizar atividades associadas à inteligência e à criatividade humanas?
O termo “inteligência artificial” havia sido formalizado pouco mais de uma década antes, na proposta do encontro de Dartmouth de 1956. O documento já mencionava linguagem, redes neurais, abstração, criatividade e formação de conceitos. Proposta de Dartmouth
Csuri transportou parte desse debate para a arte.
A máquina não sabia o que era um beija-flor. Ainda assim, executava uma sequência visual que parecia possuir intenção.
Essa diferença continua importante hoje. Um LLM pode produzir uma explicação convincente sem experimentar entendimento humano. A aparência de intenção não prova consciência.
O espectador de Hummingbird via uma máquina “brincar” com um pássaro.
Nós vemos um chatbot “refletir” sobre um problema.
Nos dois casos, o cuidado começa quando separamos a experiência percebida do mecanismo real.
14. Do cartão perfurado ao LLM
O caminho entre Hummingbird e os LLMs não foi uma linha reta. Houve avanços, fracassos, invernos de IA, novas arquiteturas e explosões de capacidade computacional.
Uma versão resumida dessa viagem seria:
1956 — A IA recebe um nome
O encontro de Dartmouth ajuda a estabelecer inteligência artificial como campo de pesquisa.
Décadas de 1950 e 1960 — IA simbólica
Pesquisadores constroem programas baseados em regras, busca, lógica e manipulação de símbolos.
1957–1969 — Perceptrons e primeiras redes
A ideia de unidades artificiais capazes de ajustar pesos ganha forma, mas o hardware e as técnicas ainda são limitados.
Décadas de 1970 e 1980 — Sistemas especialistas
Conhecimento humano é transformado em regras:
SE condição
ENTÃO ação
Era inteligência empacotada por especialistas, muito parecida com um gigantesco conjunto de regras de negócio.
Décadas de 1980 e 1990 — Redes neurais retornam
Técnicas de retropropagação tornam mais viável treinar redes multicamadas.
Décadas de 1990 e 2000 — Dados e estatística
Reconhecimento de fala, classificação, busca e modelos probabilísticos avançam à medida que mais dados se tornam digitais.
Anos 2010 — Deep learning, GPUs e escala
Redes profundas, grandes bases de dados e processamento paralelo permitem avanços em visão, fala e linguagem.
2017 — O Transformer
O artigo Attention Is All You Need apresenta a arquitetura Transformer, baseada em mecanismos de atenção e altamente paralelizável. Essa arquitetura se tornaria a fundação dos grandes modelos de linguagem modernos. Artigo original
LLMs — linguagem como previsão
Um LLM aprende padrões estatísticos em enormes volumes de texto e gera tokens prováveis conforme o contexto.
Um executa transformações explicitamente programadas.
O outro aprende uma função gigantesca a partir de dados.
15. Do LLM ao RAG: quando o modelo consulta o arquivo antes de responder
Um LLM guarda muito conhecimento implicitamente em seus parâmetros. Essa memória é chamada de paramétrica.
Mas há problemas:
o conhecimento pode estar desatualizado;
a origem da informação pode ser difícil de determinar;
o modelo pode misturar fatos;
documentos privados não fizeram parte do treinamento;
atualizar o modelo inteiro é caro;
respostas convincentes podem estar erradas.
Em 2020, o trabalho Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks formalizou uma arquitetura que combina memória paramétrica com uma memória externa pesquisável. Artigo original sobre RAG
Num RAG típico:
o usuário faz uma pergunta;
o sistema transforma a pergunta em representação pesquisável;
procura trechos relevantes numa base documental;
entrega os trechos ao LLM;
o modelo produz a resposta usando aquele contexto.
flowchart TD
A["Pergunta"] --> B["Busca"]
B --> C["Documentos relevantes"]
C --> D["Contexto para o LLM"]
D --> E["Resposta fundamentada"]
Para o programador COBOL, RAG não é magia. É quase uma combinação sofisticada de:
indexação;
recuperação de informação;
contexto;
geração textual;
controle de acesso;
rastreabilidade.
Imagine um assistente que consulta:
copybooks;
fontes COBOL;
JCLs;
manuais;
incidentes;
mudanças;
documentação do Db2;
normas internas;
registros do ServiceNow.
Ele não precisa “memorizar” tudo durante o treinamento. Pode recuperar o trecho correto no momento da pergunta.
É como impedir que o analista responda de memória e obrigá-lo a abrir a documentação antes da reunião.
16. IBM 7094 versus IA generativa atual
Aspecto
Hummingbird e mainframe
IA generativa atual
Entrada
cartões e parâmetros numéricos
prompts, imagens, áudio e documentos
Conhecimento
regras escritas no programa
padrões aprendidos durante treinamento
Memória
dezenas de milhares de palavras de 36 bits
bilhões de parâmetros distribuídos em aceleradores
Processamento
CPU central e batch
GPUs, TPUs e clusters paralelos
Saída
linhas registradas em microfilme
texto, imagem, áudio, vídeo e código
Interação
indireta e demorada
conversacional e quase imediata
Autonomia aparente
baixa e determinada por regras
elevada, mas ainda condicionada por modelo e contexto
Atualização
alterar programa e cartões
novo contexto, RAG, ajuste fino ou retreinamento
Falhas
erro de programa ou parâmetro
alucinação, viés, contexto inadequado e erro probabilístico
Auditoria
programa e cartões relativamente determinísticos
modelos complexos e respostas não totalmente determinísticas
Há, contudo, uma semelhança profunda:
Em ambos os casos, o resultado depende da representação fornecida à máquina.
Em 1967, coordenadas ruins produziam um pássaro ruim.
Hoje, dados ruins, contexto ruim e prompts ruins produzem respostas ruins — só que com uma gramática muito mais convincente.
17. O que um dev COBOL do século XXI pode aprender?
17.1 A interface muda; o pipeline permanece
Cartão perfurado, arquivo sequencial, JSON ou embedding são formas diferentes de fornecer dados e controle a um processamento.
O dev que entende entrada, transformação, estado e saída não ficou obsoleto. Apenas precisa aprender novas interfaces.
17.2 Batch não morreu
Treinamento de modelos, geração em massa de embeddings, indexação documental e avaliação de modelos são workloads de batch.
A nuvem não aboliu o batch. Apenas lhe deu YAML, APIs e uma fatura variável.
17.3 Dados e parâmetros são parte do programa
Em Hummingbird, os cartões controlavam os quadros. Em sistemas modernos, configuração, contexto, prompts e dados de recuperação controlam o comportamento do modelo.
O código sozinho não explica a solução.
17.4 Interdisciplinaridade é força, não decoração
Csuri precisava de Shaffer. Shaffer precisava da visão artística de Csuri.
Hoje, uma solução responsável de IA pode exigir:
especialista de negócio;
desenvolvedor;
arquiteto;
cientista de dados;
segurança;
jurídico;
operação;
UX;
governança.
Entregar tudo ao “especialista em prompt” é como entregar o CPD ao sujeito que aprendeu ontem a executar SUB.
17.5 Limitação pode produzir elegância
Com pouca memória e sem tela interativa, a equipe criou uma obra preservada por um dos maiores museus do mundo.
Recursos abundantes não garantem relevância. Às vezes produzem apenas mais imagens que ninguém verá.
17.6 Documentação é memória não paramétrica
O dev COBOL trabalha há décadas com uma forma artesanal de RAG:
recebe o incidente;
pesquisa o código;
abre a copybook;
consulta o manual;
verifica o JCL;
lê o dump;
combina as evidências;
formula a resposta.
A diferença é que o veterano faz a recuperação mentalmente e sabe quais documentos não devem ser confiados ao estagiário.
17.7 O ser humano continua responsável
O computador de Csuri podia apagar o beija-flor porque alguém programou essa possibilidade.
Um agente moderno pode excluir um arquivo, abrir uma mudança ou executar uma transação somente se recebeu ferramentas e permissões.
A máquina não “escapou”. Alguém concedeu RACF SPECIAL ao passarinho.
18. A grande diferença: de regras explícitas para padrões aprendidos
O salto mais importante entre 1967 e os LLMs não é apenas velocidade.
É a mudança de paradigma.
Em Hummingbird, o comportamento estava explicitamente descrito:
APLIQUE ESTA TRANSFORMAÇÃO
USE ESTE ÂNGULO
DESLOQUE ESTES PONTOS
REPITA A FIGURA
APAGUE PROGRESSIVAMENTE
Num LLM, ninguém escreve todas as regras necessárias para responder milhões de perguntas. O modelo ajusta bilhões de pesos durante o treinamento e aprende regularidades estatísticas.
Isso dá flexibilidade extraordinária, mas reduz a previsibilidade.
Um programa determinístico tende a repetir o mesmo resultado quando recebe os mesmos dados e condições.
Um modelo generativo pode variar. Pode produzir uma solução brilhante, uma resposta mediana ou uma invenção muito segura de si.
O mainframe ensinou:
Confie no processamento, mas reconcilie a saída.
A IA generativa acrescenta:
E verifique também se a saída não inventou o arquivo de entrada.
Epílogo — o pássaro ainda está voando
Hummingbird não é importante porque foi a primeira imagem de um pássaro feita por computador, nem porque antecipou literalmente o ChatGPT.
Sua importância está em mostrar uma mudança de relação.
Antes, o computador era visto como calculadora industrial.
Csuri e Shaffer perguntaram:
“E se ele também pudesse participar da criação?”
O IBM 7094 — ou a infraestrutura de mainframes que cercava esses experimentos na Ohio State — não compreendia arte. Não conhecia pássaros. Não sentia admiração pelo voo. Mesmo assim, permitiu que regras, coordenadas e tempo produzissem uma experiência estética.
Sessenta anos depois, os computadores escrevem, desenham, conversam e consultam bibliotecas documentais por meio de RAG. A pilha de cartões tornou-se prompt. O plotter virou modelo de imagem. A fila de batch virou cluster de GPUs. O manual guardado no armário virou base vetorial.
Mas a pergunta central permanece:
O que exatamente entregamos à máquina, que liberdade concedemos e quem responde pelo resultado?
O maior ensinamento de Hummingbird para um dev COBOL não é que o velho mainframe já fazia “IA”.
É algo mais valioso:
Toda revolução tecnológica começa parecendo uma utilização estranha da infraestrutura existente.
Um artista viu uma máquina científica e enxergou movimento.
Um programador viu um conjunto de coordenadas e enxergou asas.
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
