IA

E se Shakespeare fosse programador?

Hamlet investigando bugs, Romeu e Julieta enfrentando falhas de comunicação e uma IA tentando melhorar Shakespeare: um encontro entre código, teatro e criatividade.

Ilustração de William Shakespeare diante de um notebook, entre uma pena, manuscritos e um crânio teatral, observando uma representação luminosa de inteligência artificial.
Uma licença poética: Shakespeare entre o palco, o código e a inteligência artificial. · Crédito: Imagem gerada com inteligência artificial para ernani.dev.

Fazer deploy ou não fazer deploy? Eis a questão.

Shakespeare encara o notebook. O sistema está em produção, o prazo termina hoje e alguém acaba de escrever no grupo: “É só uma alteraçãozinha”.

Ele fecha os olhos. Respira. Abre um documento chamado tragedia_final_agora_vai.md.

É fácil imaginar o autor de Hamlet transformando uma reunião de projeto em um drama de cinco atos. Mas a aproximação fica interessante quando percebemos quanto de dúvida, ambição, confiança e falha de comunicação cabe tanto numa peça quanto numa equipe de desenvolvimento.

E dá para inverter a brincadeira: se Shakespeare tivesse uma inteligência artificial à disposição, será que escreveria mais? Escreveria melhor? Ou passaria a tarde discutindo com um assistente que insiste em dar um final feliz a Romeu e Julieta?

Vamos abrir as cortinas. As falas tecnológicas e os encontros com IA a seguir são invenções deste artigo; as referências às obras têm fontes ao final.

Ato I: Shakespeare entra para o time de desenvolvimento

Antes de colocar uma camiseta preta no homem e abrir um editor de código, vale lembrar: Shakespeare foi dramaturgo, ator e sócio de uma companhia teatral. Participava da criação, da execução e do negócio. A Folger Shakespeare Library documenta essas diferentes funções. [1]

Na nossa versão contemporânea, consigo imaginá-lo acompanhando uma funcionalidade desde a ideia até o momento em que alguém realmente a usa. Ele saberia que um texto precisa funcionar na boca do ator, diante de uma plateia. O equivalente, no software, seria tirar a solução da apresentação bonita e observar o que acontece quando ela encontra uma pessoa de verdade.

Inclusive aquela pessoa que clica três vezes no botão porque a primeira resposta demorou.

Hamlet: o desenvolvedor que quer entender antes de executar

O trocadilho mais óbvio seria transformar Hamlet no programador que nunca decide qual framework usar. Só que o personagem oferece uma comparação melhor.

Ao ouvir do fantasma do pai uma acusação contra Cláudio, Hamlet procura uma forma de testar a história: organiza uma encenação semelhante ao crime e observa a reação do rei. A dúvida, a investigação e a demora em agir fazem parte da complexidade da peça. [2]

No nosso time imaginário, ele seria o colega que pergunta:

“Você confirmou a causa do problema ou apenas encontrou uma explicação que parece convincente?”

É uma pergunta excelente antes de apagar dados, trocar uma arquitetura inteira ou executar o comando sugerido por uma IA.

O risco surgiria quando a investigação virasse uma moradia permanente. Hamlet abriria dez possibilidades, documentaria outras vinte e convocaria uma reunião sobre a natureza da reunião.

Eu gostaria dele revisando uma mudança delicada. Também colocaria um prazo para a decisão. O sistema precisa de cautela e precisa continuar andando.

Romeu e Julieta: a mensagem que nunca chegou

Em Romeu e Julieta, uma carta deveria explicar a Romeu o plano envolvendo a aparente morte de Julieta. Frei João não consegue entregá-la: fica retido por suspeita de exposição à peste. Essa interrupção contribui para o desfecho trágico, dentro de uma história também marcada pela violência e pelo conflito entre as famílias. [3]

Agora imagine Shakespeare numa reunião sobre integrações:

“Entendi que vocês enviaram a mensagem. Como sabemos que o outro lado a recebeu?”

Silêncio.

Alguém compartilha a tela. O campo está verde. Ninguém sabe exatamente o que aquele verde significa.

Aqui a brincadeira conversa diretamente com o tipo de trabalho que faço na Oombe. Quando sistemas dependem uns dos outros, precisamos distinguir etapas: a solicitação saiu, foi recebida, foi processada e produziu o resultado esperado? Cada resposta conta uma parte da história.

Nosso Shakespeare programador pediria confirmação de entrega, tratamento de falhas e um caminho para descobrir o que aconteceu quando a comunicação parasse.

Talvez ainda sobrasse bastante drama em Verona. Mas, pelo menos, a equipe teria um registro melhor do incidente.

Macbeth: a promoção chegou antes do juízo

Em Macbeth, a promessa de poder encontra a ambição do protagonista e de Lady Macbeth. O assassinato de Duncan abre caminho para o trono e para uma sequência devastadora de consequências. [4]

Transponha isso para uma empresa de tecnologia e aparece uma história sobre a vontade de chegar ao topo atropelando os critérios que deveriam limitar as decisões.

Nosso Macbeth poderia prometer uma entrega impossível, dispensar revisões e tratar qualquer objeção como falta de comprometimento. Quando surgisse o primeiro problema, esconderia. Quando aparecesse outro, faria uma correção apressada para sustentar a anterior.

O histórico do projeto ficaria assim:

fix: corrigir as consequências da correção anterior

Shakespeare teria material para discutir um assunto bem atual: o custo de um ambiente em que admitir um erro parece mais perigoso do que continuar errando.

Eu manteria Macbeth longe das permissões de administrador. E observaria com atenção quem estivesse premiando aquele comportamento.

Otelo: quando a confiança vira uma vulnerabilidade

Em Otelo, Iago constrói uma narrativa enganosa sobre Desdêmona. Insinuações e evidências manipuladas alimentam o ciúme de Otelo, que continua responsável pela violência que pratica. [5]

Na nossa versão tecnológica, Iago seria perigosíssimo numa conversa de equipe. Ele saberia apresentar um pedaço verdadeiro de informação dentro de uma história falsa, explorando a confiança de quem o escuta.

Imagine um relatório correto acompanhado de uma conclusão indevida. Um trecho de conversa sem contexto. Uma resposta de IA aceita porque veio escrita com uma segurança impressionante.

Shakespeare talvez colocasse na revisão uma pergunta incômoda: quem está conduzindo nossa interpretação?

É uma boa pergunta para quem desenvolve, administra ou usa tecnologia. A informação pode parecer organizada, elegante e convincente. Ainda precisamos examinar sua origem e o caminho entre a evidência e a conclusão.

Intervalo: em qual linguagem ele programaria?

Eu poderia apostar em Python pela legibilidade, PHP pela minha familiaridade ou inventar que ele escolheria Rust porque já conhecia o preço de deixar certas coisas sem controle.

Mas gosto de imaginar outro traço: Shakespeare teria interesse em quem vai ler o código depois.

Talvez escrevesse comentários memoráveis. Talvez precisasse ouvir que uma função de cadastro não comporta um monólogo de três páginas. E provavelmente descobriria que dar um nome claro a uma variável exige uma disciplina bem diferente de batizar uma tragédia.

Por mais bonito que soe, oDestinoDaquelesQuePartiram continua sendo um nome complicado para uma lista de usuários inativos.

Ato II: chega uma IA aos tempos de Shakespeare

Agora vamos levar um assistente de IA para a mesa do dramaturgo, aceitando a impossibilidade histórica como parte da brincadeira. Entre a pena e os manuscritos, aparece uma janela pronta para conversar.

Shakespeare digita:

“Preciso de uma cena em que duas pessoas apaixonadas conversem sabendo que suas famílias se odeiam. Quero desejo, risco e alguma coisa que elas não consigam dizer diretamente.”

A ferramenta apresenta alternativas. Ele pede uma versão mais curta, muda uma imagem, recusa uma fala bonita demais para aquele personagem. Lê em voz alta. Percebe que a terceira tentativa tem uma ideia aproveitável e reescreve quase tudo.

Consigo imaginá-lo usando a IA para explorar estruturas, comparar ritmos e provocar a própria imaginação. Uma espécie de oficina de possibilidades, sujeita ao ouvido e às escolhas do autor.

Também consigo imaginar o assistente ouvindo:

“Você escreveu uma declaração de amor perfeitamente correta. Agora precisamos fazer alguém acreditar nela.”

O autor já trabalhava com histórias anteriores

Há um dado histórico que enriquece essa hipótese: Shakespeare transformava narrativas que já existiam. A Royal Shakespeare Company aponta o poema de Arthur Brooke, publicado em 1562, como fonte imediata de Romeu e Julieta. Entre suas mudanças, Shakespeare condensou em poucos dias uma história que se desenrolava ao longo de meses. [6]

Essa escolha altera a experiência: a pressa vira parte da tragédia. Quase falta ar aos personagens.

Por isso, imagino que a conversa com uma IA pudesse envolver perguntas muito mais específicas do que “escreva uma peça genial”. Ele poderia pedir três maneiras de acelerar uma cena, uma objeção à motivação de um personagem ou alternativas para uma fala que entrega cedo demais o que deveria permanecer incerto.

A comparação tem um limite: esse costume de adaptar histórias não resolve as questões atuais sobre autoria ou uso de obras por IA. Ele ajuda a enxergar o trabalho de transformação, seleção e construção que existe numa criação.

A IA poderia sugerir uma melhoria que estragasse a peça

Imagine o assistente analisando Romeu e Julieta e propondo:

IA: “Identifiquei uma falha no planejamento. Sugiro garantir a entrega da carta e adiar decisões irreversíveis até confirmar as informações.”

Shakespeare: “Excelente para os personagens. Complicado para a tragédia.”

A sugestão faz sentido quando o objetivo é evitar um desastre. Só que, naquele trabalho, Shakespeare está construindo uma experiência dramática.

Essa diferença de objetivo muda tudo. Uma solução pode ser coerente, bem escrita e completamente inadequada à intenção de quem a pediu.

No software, isso também merece atenção. Imagine solicitar uma tela mais simples e receber uma versão que esconde justamente o aviso necessário para o usuário decidir. Ou pedir um processo mais rápido e descobrir que a etapa removida era a confirmação de uma operação importante.

Nosso Shakespeare teria de explicar o que queria preservar: a tensão, a ambiguidade, o desconforto, o silêncio antes de uma resposta. Algumas dificuldades fazem parte da experiência que ele escolheu criar.

E se todo mundo tivesse o mesmo assistente?

Talvez a disputa entre companhias começasse a incluir promessas absurdas:

“Tragédias ilimitadas. Agora com cinco reviravoltas por ato. Assine o plano Bardo Pro.”

Haveria quem usasse a novidade para experimentar. Haveria quem entregasse o primeiro texto produzido. E consigo imaginar alguém anunciando: “Descobri o prompt definitivo para superar Shakespeare”.

O próprio Shakespeare talvez se divertisse. Ou cobrasse ingresso.

Nesse cenário, o acesso a mais alternativas ampliaria as oportunidades e também o trabalho de escolher. Diante de cinquenta versões de uma cena, qual merece o palco? Qual combina com os personagens? Qual surpreende sem destruir a coerência da história?

Poderíamos até imaginar um jovem autor, antes sem acesso a interlocutores, encontrando na ferramenta uma forma de desenvolver uma ideia. O ganho seria valioso. O destino daquela ideia continuaria aberto, dependendo do que ele fizesse com a ajuda recebida.

Ato III: quem responde pela obra?

Não sabemos se Shakespeare abraçaria a IA, a detestaria ou negociaria um desconto para a companhia inteira. A hipótese vale pelo que nos faz perguntar sobre o nosso próprio trabalho.

Para quem programa, o encontro imaginário deixa uma provocação: o que você consegue explicar sobre aquilo que está construindo?

Consegue justificar uma decisão, perceber uma inconsistência, reconhecer uma sugestão inadequada e mudar de caminho? Consegue acompanhar o efeito do seu trabalho sobre quem vai usá-lo?

Eu gosto de imaginar Shakespeare tratando uma proposta da IA como trataria uma fala num ensaio: experimentando, escutando, cortando, ajustando. Em certos momentos, aproveitaria muito. Em outros, fecharia a janela e seguiria com uma ideia que ainda não sabia explicar direito.

A ferramenta poderia participar da criação. A responsabilidade de colocar aquela versão no palco permaneceria uma escolha dele.

E, se fosse programador, talvez terminasse o expediente com um comentário especialmente inspirado, uma solução bem pensada e o orgulho de ter colocado ordem no caos.

Até alguém aparecer na porta:

“William, ficou ótimo. Só precisamos mudar uma coisinha.”

Ele abriria um novo arquivo.

ato_ii.md


Referências

  1. Folger Shakespeare Library — Shakespeare's life: sua atuação como dramaturgo, ator e sócio de companhia teatral.
  2. Folger Shakespeare Library — Hamlet: texto e sinopse, incluindo a encenação usada para investigar Cláudio.
  3. Folger Shakespeare Library — Romeo and Juliet, ato V, cena 2: o impedimento da entrega da carta.
  4. Folger Shakespeare Library — Macbeth: ambição, poder e consequências das escolhas do protagonista.
  5. Folger Shakespeare Library — Othello: as insinuações de Iago e a violência de Otelo.
  6. Royal Shakespeare Company — Romeo and Juliet: Dates and Sources: a fonte em Arthur Brooke e as transformações feitas por Shakespeare.
EN

Ernani Nascimento

Desenvolvimento de sistemas, inteligência artificial, automações, dados e jogos. Um espaço para compartilhar experiências e aprendizados construindo projetos reais.

Conheça o autor ↗

Continue explorando.

DA IDEIA À PRÁTICA

Tem algo em mente?
Vamos construir.

Vamos conversar ↗