 |
| Bellacosa Mainframe e o mapa do tesouro para usar ChatGPT |
☕ Um Café no Bellacosa Mainframe
Configure o ChatGPT do Zero — O Mapa de Jake Sparrow para Navegar entre Chat, Work, Codex, Projetos, Plugins e Skills sem Afundar o Datacenter
Ou: o capitão trouxe um mapa incompleto, Jake Sparrow acrescentou cinco ilhas entre dois copos de rum, os chimpanzés abasteceram o batch com saquê — e Igor descobriu tarde demais que “Full Access” não era o nome de uma banda de rock progressivo
Havia neblina sobre o datacenter quando Jake Sparrow apareceu caminhando de lado pelo corredor das fitas. Ninguém soube explicar como ele atravessara a catraca sem crachá, por que carregava uma bússola que apontava para o servidor com mais café ou de onde havia retirado um mapa desenhado sobre o verso de um listing COBOL de 1987.
— Este é o arquipélago do ChatGPT — anunciou, pousando um copo de rum ao lado do console.
Igor, que se pronuncia Eye-gor, examinou o pergaminho.
— Mas aqui existem somente sete ilhas: Aplicativo, Personalização, Projetos, Aplicativos Conectados, Work, Codex e Skills.
Jake bebeu um gole, olhou para os chimpanzés bebedores de saquê que tentavam submeter um JOB pelo teclado numérico e respondeu:
— Então deram a vocês o mapa turístico. Serve para chegar à praia, mas não mostra os recifes, os canhões, as correntes marítimas nem o lugar onde enterraram as permissões administrativas.
É exatamente esse o problema dos guias intitulados “Configure o ChatGPT do zero”. Eles normalmente acertam a direção, mas transformam um ecossistema inteiro numa sequência de botões. Parece que basta instalar um aplicativo, escolher uma cor, conectar o Gmail, criar uma Skill e pronto: nasceu um mordomo digital onisciente, obediente e incapaz de cometer erros.
Não nasceu.
O ChatGPT moderno deve ser entendido como um ambiente composto por camadas. Há um modelo que raciocina, uma conversa que transporta contexto, projetos que organizam fontes, memórias que preservam preferências, plugins que adicionam capacidades, conectores que alcançam sistemas externos, Work para delegar entregáveis, Codex para trabalhar diretamente com arquivos e código, Skills para repetir procedimentos e permissões para impedir que Igor transforme uma experiência didática num incidente com número de protocolo.
Portanto, prepare o café. Jake Sparrow assumirá o leme. Os chimpanzés cuidarão do saquê — decisão operacional questionável — e nós construiremos um mapa suficientemente completo para um programador COBOL iniciante entender não apenas onde clicar, mas o que realmente acontece por baixo do convés.
O mapa completo: as doze ilhas do arquipélago
O desenho original apresentava sete etapas. Jake acrescentou cinco territórios que não podem ser ignorados: Prompt, Fontes, Permissões, Verificação e Automação.
| Ilha | Pergunta que ela responde | Exemplo no Bellacosa Mainframe |
|---|---|---|
| 1. Superfície | Onde vou trabalhar? | Web, aplicativo desktop, CLI ou IDE |
| 2. Prompt | Qual é o objetivo desta conversa? | “Explique RACF para um coboleiro iniciante” |
| 3. Personalização | Como o agente deve falar e trabalhar comigo? | Tom de boteco, profundidade técnica e humor |
| 4. Memória | O que vale a pena carregar para conversas futuras? | Preferências, projetos recorrentes e convenções |
| 5. Projetos | Quais conversas, arquivos e regras pertencem ao mesmo assunto? | Projeto IBM Mainframe Technical Manager L1 |
| 6. Fontes | Em quais dados a resposta deve se apoiar? | Manuais IBM, notas do curso e arquivos enviados |
| 7. Plugins e conectores | Quais sistemas externos podem ser consultados ou acionados? | Drive, GitHub, calendário ou repositório documental |
| 8. Permissões | O que o agente pode ler, modificar, executar ou publicar? | Somente leitura, escrita no projeto ou aprovação prévia |
| 9. Work | Qual entregável completo deve ser produzido? | Apostila, apresentação, análise ou plano semanal |
| 10. Codex | O que deve ser construído, editado, testado ou automatizado? | Site, programa, relatório, script ou correção de código |
| 11. Skills | Qual método precisa ser repetido de maneira consistente? | Artigo Bellacosa com SEO, marcadores e easter egg |
| 12. Verificação e automação | Como comprovar o resultado e repeti-lo com segurança? | Testes, revisão, agendamento e monitoramento |
Essas ilhas não formam obrigatoriamente uma linha reta. Você pode conversar sem criar projeto, usar um projeto sem instalar plugin e pedir uma análise ao Work sem escrever uma Skill. O mapa representa maturidade, não burocracia.
A sequência saudável é simples: comece com uma necessidade real, acrescente contexto, organize o que se tornar recorrente, conceda somente o acesso necessário, verifique a entrega e automatize apenas aquilo que já funciona manualmente.
Ilha 1 — Escolha a superfície: Chat, Work e Codex não são a mesma cabine
O primeiro cartaz manda baixar o novo aplicativo e informa que Chat, Work e Codex vivem no mesmo lugar. A mensagem geral está correta, mas precisa ser traduzida.
Chat é a mesa do boteco. Você pergunta, debate, aprende, explora possibilidades ou pede um rascunho curto.
“Polindexter, o que diferencia um arquivo sequencial de um VSAM KSDS?”
O resultado principal é uma resposta.
ChatGPT Work é a sala de operações. Você entrega materiais, define um objetivo e espera um produto revisável.
“Use estes manuais e minhas anotações para criar uma apostila introdutória sobre VSAM, com exemplos, laboratório, glossário e dez questões de revisão. Entregue em DOCX e revise a diagramação.”
Agora o resultado não é simplesmente uma mensagem: é um artefato utilizável. Segundo a documentação oficial do ChatGPT Work, ele pode empregar arquivos, plugins e ferramentas aprovadas para buscar informações, executar fluxos e criar resultados prontos para revisão.
Codex é a oficina. Ele foi projetado para trabalhar com arquivos, ambientes e ferramentas. Pode examinar um projeto, alterar código, executar comandos, testar, gerar documentos, construir sites e produzir automações.
“Crie uma aplicação que leia uma lista de URLs do meu Blogspot, identifique links quebrados, extraia títulos e gere um relatório HTML. Inclua testes e não publique nada.”
O Chat explicaria como fazer. O Codex pode efetivamente criar os arquivos, executar os testes e entregar o resultado.
Curiosidade de convés
O aplicativo desktop não é obrigatório para começar. A web oferece Chat e Work; desktop, CLI e extensões de IDE ampliam a integração com arquivos locais e ambientes de desenvolvimento. Escolha a superfície pelo trabalho, não pela moda.
Para um iniciante COBOL:
use Chat para aprender conceitos;
use Work para criar material completo;
use Codex quando houver arquivos, código, testes ou construção;
use a IDE quando precisar analisar o programa ao lado do fonte.
Jake Sparrow anotou no mapa: “Não leve um encouraçado para atravessar uma banheira”. Uma pergunta simples não precisa de um projeto com doze ferramentas.
Ilha 2 — O prompt é a SYSIN do seu JOB
No mainframe, um programa pode estar perfeitamente compilado e ainda produzir uma saída absurda se receber parâmetros errados. Com inteligência artificial ocorre algo semelhante.
O prompt não é um encantamento secreto. É a combinação de pergunta, instrução ou objetivo enviada ao agente. Um bom prompt não precisa ser enorme, mas deve conter o que realmente muda o resultado.
Compare:
“Fale sobre CICS.”
com:
“Explique CICS Transaction Server para um programador COBOL iniciante. Comece pelo problema que ele resolve, compare uma transação CICS com um programa batch, mostre o ciclo de uma tela 3270, explique COMMAREA e canais/containers, inclua um exemplo pseudocódigo e destaque erros comuns. Não presuma experiência com administração CICS.”
O segundo pedido informa:
público;
ponto de partida;
profundidade;
estrutura;
exemplos desejados;
conhecimentos que não devem ser presumidos.
A fórmula de Jake Sparrow
Para tarefas maiores, use cinco campos:
Objetivo: o que deve existir ao final?
Contexto: por que isso está sendo feito e para quem?
Fontes: quais materiais devem ser usados?
Restrições: o que não pode acontecer?
Critérios de aceite: como saberemos que terminou corretamente?
Exemplo:
“Analise este programa Enterprise COBOL 6.3 que recebe
IGZ0035Squando o campo de data vem vazio. Preserve o copybook e o layout externo, encontre a menor correção possível, explique a causa para um iniciante e produza casos de teste. Não altere o JCL sem justificar. Considere concluído somente depois de verificar os casos válido, vazio e inválido.”
Isso se parece muito com especificação de programa. O programador COBOL já conhece a lógica; apenas precisa parar de tratar a IA como oráculo e começar a tratá-la como colega de equipe.
Ilha 3 — Personalização não é treinamento do modelo
Ao selecionar personalidade, instruções, memória, aparência ou estilo, você não está treinando um GPT exclusivo dentro de uma torre. Está configurando a forma como o sistema interage com você e quais preferências devem ser consideradas.
Personalidade muda o estilo de comunicação. Pode tornar a resposta mais amigável, pragmática ou neutra. Não aumenta inteligência, não libera ferramentas e não corrige automaticamente fatos errados.
Instruções personalizadas registram preferências recorrentes:
responda em português;
use exemplos mainframe;
trate o leitor como iniciante inteligente;
diferencie fato, inferência e piada;
evite linguagem corporativa burocrática;
chame o assistente de Polindexter.
Aparência modifica cores, tema e fontes da interface. É pintar a sala do computador, não trocar o processador.
Memória pode carregar contexto útil entre conversas, como preferências, objetivos, convenções e projetos recorrentes. A documentação de personalização separa claramente personalidade, instruções e memórias.
Mas memória não é documentação contratual. Se uma regra for obrigatória — “não publicar sem aprovação”, “usar apenas fontes IBM”, “preservar o layout do copybook” — coloque-a no pedido ou nas instruções do projeto.
Analogia COBOL
personalidade é o formato do relatório;
memória é uma tabela de preferências reaproveitáveis;
instrução do projeto é a regra de negócio;
prompt atual é o registro de entrada;
modelo é o programa capaz de interpretar tudo isso.
Igor tentou registrar “sempre execute em produção” como preferência global. A solicitação foi recusada e o chimpanzé responsável pelo Change Management recebeu uma banana sem álcool.
Ilha 4 — Memória é contexto reaproveitável, não um VSAM infinito
Existe uma tentação de imaginar a memória como um arquivo mestre ilimitado contendo cada palavra pronunciada desde o primeiro chat. Não é uma boa representação.
A memória deve preservar elementos úteis e relativamente estáveis:
preferências de linguagem;
formatos recorrentes;
projetos duradouros;
restrições pessoais relevantes;
convenções de trabalho.
Ela não deve ser o único lugar para guardar especificações críticas, manuais inteiros ou o estado detalhado de um projeto complexo.
Além disso, há a janela de contexto: a quantidade de informação que o modelo consegue considerar numa interação. Mesmo em sistemas com grande capacidade, jogar dezenas de arquivos irrelevantes dentro de uma conversa não melhora a resposta. É como carregar todas as gerações de um GDG para calcular o movimento de hoje.
Dica prática
Pergunte-se:
“Isso é uma preferência sobre mim, uma regra deste projeto ou um dado desta tarefa?”
preferência pessoal vai para personalização ou memória;
regra durável do projeto vai para instruções do projeto;
dado momentâneo vai para o prompt ou arquivo atual;
procedimento repetitivo poderá virar Skill.
Essa classificação reduz confusão e evita que o agente use contexto certo no trabalho errado.
Ilha 5 — Projetos são regiões lógicas, quase como aplicações no mainframe
Projetos reúnem chats, arquivos, instruções e fontes relacionados. Eles são úteis quando o trabalho continua no tempo, produz vários resultados ou reutiliza os mesmos materiais.
Imagine um projeto chamado IBM Mainframe Technical Manager L1 contendo:
lista dos vinte cursos;
progresso atual;
badges conquistados;
anotações;
simulados;
cronograma;
instrução para criar um plano semanal aos domingos.
Dentro dele, você poderia manter chats separados:
plano semanal;
revisão de arquitetura IBM Z;
simulado de 44 questões;
análise dos erros;
preparação para a prova final.
O contexto permanece relacionado, mas cada conversa tem um objetivo limpo.
Outro projeto poderia ser Bellacosa Mainframe — Editorial, contendo guia de estilo, exemplos aprovados, identidade visual, regras de SEO, links internos e instruções sobre easter eggs.
A documentação de Projetos recomenda usá-los para manter juntos chats, arquivos, instruções e fontes que pertencem ao mesmo trabalho.
Erro comum: o projeto “Tudo”
Não coloque RACF, anime, viagem à Escócia, Victor Hugo, fraude bancária e alimentação militar dentro de um único projeto chamado “Assuntos”. Isso cria o equivalente cognitivo de uma biblioteca de fitas sem catálogo.
Crie um projeto quando houver continuidade ou contexto compartilhado. Para uma pergunta autônoma, abra um chat simples e preserve a sanidade do catálogo.
Ilha 6 — Fontes: o agente não encontra a verdade só porque o mapa tem uma bússola
Uma resposta pode usar:
conhecimento geral do modelo;
arquivos anexados;
fontes de um projeto;
pesquisa na web;
dados recuperados por conectores;
resultados de ferramentas.
Cada fonte possui limitações. Um manual antigo continua antigo depois de ser anexado. Uma planilha errada continua errada depois de ser analisada. Uma página popular não se transforma em documentação oficial porque apareceu primeiro no buscador.
Para tecnologia que muda rapidamente, peça verificação atual. Para IBM Z, identifique versão e produto. “Explique COBOL” é amplo demais; Enterprise COBOL 6.3, 6.5, COBOL for AIX e ILE COBOL possuem fronteiras diferentes.
Hierarquia prática de confiança
documentação oficial vigente;
normas e especificações primárias;
documentação interna autorizada;
livros e materiais técnicos reconhecidos;
artigos especializados;
fóruns, posts e opiniões;
“um chimpanzé disse depois do terceiro saquê”.
A última fonte pode render um excelente easter egg, mas não deve definir sua política RACF.
Ilha 7 — Plugins, conectores e MCP: três objetos, três funções
Esses nomes aparecem frequentemente misturados, portanto Jake Sparrow desenhou três portos diferentes.
Skill é um procedimento reutilizável: ensina como realizar determinada tarefa.
Conector é a ponte para um serviço externo: permite pesquisar, ler ou executar ações dentro das permissões concedidas.
Plugin é um pacote instalável que pode reunir Skills, conectores e ferramentas.
MCP, Model Context Protocol, é um padrão por meio do qual ferramentas e fontes externas podem ser apresentadas ao agente.
Segundo a documentação oficial de Skills e Plugins, uma Skill empacota instruções e recursos; um plugin pode combinar Skills e conectores; conectores podem ser apoiados por servidores MCP.
Exemplo
Um plugin editorial poderia conter:
Skill “Criar artigo Bellacosa”;
conector para pesquisar documentos autorizados;
modelo de artigo;
ferramenta para conferir o tamanho da meta description;
referência com padrões visuais.
Instalar um plugin, entretanto, não concede automaticamente acesso a todos os sistemas. Um conector pode exigir login, autorização e permissões próprias.
Ilha 8 — Permissões: não dê SPECIAL para quem precisa apenas de READ
Esta é a ilha que os infográficos alegres quase sempre esquecem.
Há diferença entre:
ler um arquivo;
editar um arquivo;
executar um comando;
acessar a internet;
consultar um serviço externo;
enviar uma mensagem;
publicar conteúdo;
apagar dados.
O princípio correto é o menor privilégio necessário.
Se o objetivo é analisar documentos, comece com leitura. Se o objetivo é propor uma organização, não conceda autoridade para mover ou apagar. Se o agente precisa alterar cinco arquivos do projeto, não ofereça acesso irrestrito ao computador inteiro.
Pedido perigoso:
“Conecte tudo, organize meus arquivos e corrija o que achar necessário.”
Pedido seguro:
“Leia somente a pasta do curso, identifique duplicados e proponha uma estrutura. Não mova, renomeie, envie nem apague arquivos. Apresente o plano para aprovação.”
Isso é Zero Trust aplicado à colaboração com agentes: verifique identidade, limite escopo, registre ações e não transforme conveniência em acesso permanente.
Easter egg operacional
Se você encontrar a expressão UID(0) rabiscada no casco do navio, não é o número do camarote de Igor. É uma boa razão para perguntar por que alguém precisa de tanto poder.
Ilha 9 — Work: delegue resultados, não verbos soltos
“Pesquise”, “analise” e “escreva” são atividades. Uma boa delegação descreve um estado final.
Compare:
“Escreva sobre RACF.”
com:
“Crie uma apostila introdutória sobre RACF para programadores COBOL. Explique usuários, grupos, perfis, classes, acesso e auditoria; compare
READ,UPDATE,CONTROLeALTER; inclua exemplos seguros, laboratório, glossário e perguntas de revisão. Use somente fontes oficiais atuais, identifique a versão quando relevante e entregue um documento revisado. Não execute mudanças em nenhum ambiente.”
O segundo pedido define público, escopo, fontes, formato, segurança e critérios de aceite.
Delegar não significa abandonar. Durante trabalhos longos, você pode acompanhar, corrigir direção, acrescentar contexto e aprovar decisões importantes.
O segredo está em dizer o que deve existir quando terminar.
Ilha 10 — Codex: da explicação para a construção verificável
Codex se torna valioso quando há arquivos, código, comandos, testes ou um ambiente a ser manipulado.
Para o programador COBOL, ele pode:
explicar um fonte existente;
localizar campos e dependências;
comparar copybooks;
sugerir casos de teste;
gerar JCL de exemplo;
documentar interfaces;
criar utilitários auxiliares;
analisar logs e mensagens;
construir uma interface web em torno de dados simulados;
executar verificações permitidas.
Mas o contexto técnico importa. Informe:
compilador e versão;
sistema operacional;
CICS, IMS, Db2 ou batch;
layouts de registros;
comandos de build e teste;
mensagens completas;
restrições da instalação.
Não diga apenas “meu COBOL quebrou”. Isso equivale a telefonar ao suporte e declarar que “o mainframe está estranho”.
Fronteira essencial
O Codex pode reduzir brutalmente a barreira de implementação, mas não elimina a responsabilidade do usuário. Alguém ainda precisa saber qual problema está sendo resolvido, quais dados são sensíveis, quais resultados são corretos e o que jamais deve ser feito.
Ilha 11 — Skills: transforme experiência tácita em procedimento executável
Uma Skill não é simplesmente “um prompt que gostei”. É um pacote de instruções e recursos para repetir um método de maneira confiável.
O processo editorial Bellacosa já possui formato de Skill:
receber assunto, imagem ou notícia;
identificar tese central;
pesquisar fatos atuais;
separar documentação, inferência e humor;
explicar para um iniciante inteligente;
adicionar história, curiosidades e exemplos;
construir analogias mainframe;
inserir Igor, Polindexter ou outro personagem quando fizer sentido;
incluir easter egg;
revisar coerência;
gerar SEO dentro do limite;
produzir marcadores;
preparar conceitos visuais.
A documentação de construção de Skills explica que elas podem reunir instruções, referências, recursos e scripts opcionais.
Uma estrutura possível seria:
bellacosa-mainframe-article/
├── SKILL.md
├── references/
│ ├── estilo-editorial.md
│ └── exemplos-aprovados.md
├── assets/
│ └── modelo-artigo.md
└── scripts/
├── validar-seo
└── conferir-marcadoresQuando criar uma Skill?
Crie quando:
a tarefa se repete;
os passos são relativamente estáveis;
existem regras fáceis de esquecer;
bons exemplos melhoram o resultado;
outras pessoas poderiam reaproveitar o método.
Não crie uma Skill para cada pergunta. Uma Skill para “explicar OCCURS DEPENDING ON uma única vez” seria como instalar um CICS inteiro para somar dois números.
Ilha 12 — Verifique primeiro, automatize depois
O agente produziu um arquivo. Terminou?
Ainda não.
“Gerado” e “correto” são estados diferentes.
Para código, verifique:
compilação;
testes;
casos extremos;
alterações realizadas;
impacto em interfaces;
mensagens e retornos.
Para documentos:
estrutura;
fatos;
fontes;
consistência;
ortografia;
diagramação.
Para planilhas:
fórmulas;
totais;
referências;
tipos de dados;
recálculo.
Para artigos:
título;
tese;
datas;
distinção entre fato e piada;
links;
SEO;
ausência de contradições.
Somente depois de estabilizar o processo vale automatizá-lo. Uma automação pode executar uma tarefa em determinado horário, repetir um relatório ou verificar se uma condição mudou.
Seu plano semanal do IBM Mainframe Technical Manager L1 aos domingos às 20h é um exemplo perfeito: o método está definido, os dados de progresso mudam e existe uma periodicidade útil.
Automatizar um processo ruim apenas produz erros pontualmente, toda semana, com admirável disciplina.
Passo a passo de Jake Sparrow para configurar sem naufragar
Passo 1 — Escolha um problema real
Não comece conectando tudo. Comece com algo útil:
“Quero transformar minhas anotações de RACF numa aula para iniciantes.”
Passo 2 — Defina o entregável
Decida se precisa de explicação, artigo, apostila, apresentação, planilha, site ou programa.
Passo 3 — Forneça contexto suficiente
Informe público, versão tecnológica, objetivo, exemplos e limitações.
Passo 4 — Selecione fontes confiáveis
Anexe somente materiais relevantes e indique quando a documentação oficial deve prevalecer.
Passo 5 — Use um projeto se houver continuidade
Reúna conversas, arquivos e instruções do mesmo corpo de trabalho.
Passo 6 — Personalize o que for estável
Estilo, idioma e preferências recorrentes podem ser persistentes. Requisitos críticos continuam explícitos.
Passo 7 — Conecte apenas o necessário
Instale plugins ou autorize conectores quando o trabalho realmente depender de sistemas externos.
Passo 8 — Defina permissões mínimas
Comece com leitura. Autorize escrita, envio ou publicação somente quando necessários e revisados.
Passo 9 — Delegue ao modo adequado
Chat para resposta e exploração;
Work para entregável completo;
Codex para construção, arquivos, código e testes.
Passo 10 — Revise e corrija
Peça verificação, examine o resultado e refine os critérios de aceite.
Passo 11 — Transforme repetição em Skill
Depois de executar bem algumas vezes, documente o método, exemplos e validações.
Passo 12 — Automatize com limites
Agende somente o processo estabilizado. Defina frequência, condição, fontes, resultado e ações proibidas.
O verdadeiro tesouro não é o botão “Novo”
Ao amanhecer, Jake Sparrow enrolou o mapa e descobriu que os chimpanzés haviam consumido o saquê destinado à cerimônia de encerramento. Igor dormia sobre um manual de segurança, abraçado a uma placa onde se lia:
FULL ACCESS — USE SOMENTE QUANDO INTENCIONAL
Por sorte, ninguém havia lhe explicado onde ficava o botão.
O mapa original estava correto ao sugerir uma jornada: instalar, personalizar, organizar, conectar, delegar, construir e criar Skills. Entretanto, o verdadeiro domínio nasce quando entendemos as fronteiras entre essas etapas.
Personalidade não é capacidade. Memória não é documentação. Projeto não é depósito. Plugin não é autorização. Conector não é acesso ilimitado. Work não é abandono. Codex não é licença para alterar produção. Skill não é mágica. Automação não é garantia de qualidade.
O ChatGPT torna-se poderoso quando recebe um objetivo claro, o contexto certo, fontes confiáveis, ferramentas adequadas e permissões proporcionais. Torna-se confiável quando o resultado é verificado. Torna-se escalável quando o procedimento correto é transformado em Skill. E torna-se perigoso quando alguém confunde conveniência com autoridade irrestrita.
Para o coboleiro iniciante, há uma notícia excelente: você já conhece a maior parte dessa lógica.
Você sabe que programa precisa de entrada, regra de negócio, arquivo, autoridade, condição de retorno, teste e controle de produção. Basta transportar essa disciplina para o mundo dos agentes.
O prompt é a SYSIN. O projeto é a aplicação. A memória guarda preferências. As fontes alimentam o processamento. O plugin instala capacidades. O conector abre uma interface. A permissão define o perfil de acesso. Work coordena o JOB. Codex opera a oficina. A Skill documenta o procedimento. A verificação examina o RC. A automação coloca tudo no scheduler.
E o ser humano?
O ser humano continua sendo o responsável por decidir por que o JOB existe, quais dados ele pode tocar e se o resultado deve seguir para produção.
Jake Sparrow levantou o último copo de rum, apontou para o horizonte e pronunciou a senha encontrada no rodapé do listing de 1987:
“Nem todo
RC=00significa que o resultado está certo.”
Os chimpanzés aplaudiram. Igor acordou assustado. E, em algum lugar do datacenter, um programa compilado sem erros calculou com absoluta perfeição a idade de um cliente nascido em 30 de fevereiro.
Esse, companheiro, era o easter egg.
Porque a inteligência artificial pode executar exatamente o que você pediu — e ainda assim você pode ter pedido a coisa errada.
Sirva outro café. O arquipélago é grande, mas agora temos um mapa de verdade.
Sem comentários:
Enviar um comentário