 |
| 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 NOVAMENTEO 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ÍSICATroque 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=00nã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çãoEra 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.
Simplificando brutalmente:
HUMMINGBIRD:
coordenadas + regras + parâmetros → quadros
LLM:
tokens + pesos aprendidos + contexto → próximo tokenUm 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 PROGRESSIVAMENTENum 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.
O computador viu apenas números.
E, ainda assim, o beija-flor voou.
