What if Shakespeare were a programmer?

To deploy, or not to deploy? That is the question.

Shakespeare stares at his laptop. The system is in production, the deadline is today, and someone has just posted in the group chat: “It’s only a tiny change.”

He closes his eyes. Takes a breath. Opens a document called tragedy_final_this_time_for_real.md.

It’s easy to imagine the author of Hamlet turning a project meeting into a five-act drama. But the comparison gets interesting when we realize how much doubt, ambition, trust, and miscommunication can fit into both a play and a development team.

And we can turn the thought experiment around: if Shakespeare had artificial intelligence at his disposal, would he write more? Would he write better? Or would he spend the afternoon arguing with an assistant determined to give Romeo and Juliet a happy ending?

Let’s raise the curtain. The technology-related dialogue and encounters with AI below are inventions of this article; references for the literary material appear at the end.

Act I: Shakespeare joins the development team

Before putting the man in a black T-shirt and opening a code editor, it’s worth remembering that Shakespeare was a playwright, an actor, and a shareholder in a theater company. He took part in the creative work, the performances, and the business. The Folger Shakespeare Library documents those different roles. [1]

In our contemporary version, I can picture him following a feature from the initial idea to the moment someone actually uses it. He would know that a script has to work in an actor’s mouth, in front of an audience. The software equivalent would be taking a solution out of its polished presentation and seeing what happens when it meets a real person.

Including the person who clicks the button three times because the first response took too long.

Hamlet: the developer who wants to understand before executing

The obvious joke would be to turn Hamlet into the programmer who can never decide which framework to use. But the character offers a better comparison.

After hearing his father’s ghost accuse Claudius, Hamlet looks for a way to test the story: he arranges a performance resembling the crime and watches the king’s reaction. Doubt, investigation, and the delay in acting are part of the play’s complexity. [2]

On our imaginary team, he would be the colleague who asks:

“Have you confirmed the cause of the problem, or have you just found an explanation that sounds convincing?”

That’s an excellent question to ask before deleting data, replacing an entire architecture, or running a command suggested by AI.

The risk would come when the investigation became a permanent residence. Hamlet would explore ten possibilities, document another twenty, and call a meeting about the nature of the meeting.

I’d like him reviewing a delicate change. I’d also set a deadline for the decision. The system needs caution, and it needs to keep moving.

Romeo and Juliet: the message that never arrived

In Romeo and Juliet, a letter is supposed to explain to Romeo the plan involving Juliet’s apparent death. Friar John cannot deliver it: he is detained because of suspected exposure to the plague. That interruption contributes to the tragic ending, within a story also shaped by violence and conflict between the families. [3]

Now imagine Shakespeare in a meeting about integrations:

“I understand that you sent the message. How do we know the other side received it?”

Silence.

Someone shares their screen. The field is green. Nobody knows exactly what that green means.

Here, the joke connects directly with the kind of work I do at Oombe. When systems depend on one another, we need to distinguish between stages: did the request leave, was it received, was it processed, and did it produce the expected result? Each answer tells part of the story.

Our programmer Shakespeare would ask for delivery confirmation, failure handling, and a way to find out what happened when communication stopped.

There might still be plenty of drama in Verona. But at least the team would have a better incident record.

Macbeth: ambition got promoted before judgment did

In Macbeth, the promise of power meets the ambition of the protagonist and Lady Macbeth. Duncan’s murder opens the way to the throne and to a devastating chain of consequences. [4]

Move that into a technology company, and you get a story about the desire to reach the top while trampling the standards that should constrain decisions.

Our Macbeth might promise an impossible delivery date, skip reviews, and treat every objection as a lack of commitment. When the first problem appeared, he would hide it. When another emerged, he would rush out a fix to prop up the previous one.

The project history would look like this:

fix: fix the consequences of the previous fix

Shakespeare would have material for a very current issue: the cost of an environment where admitting a mistake feels more dangerous than continuing to make it.

I’d keep Macbeth away from administrator permissions. And I’d pay close attention to whoever was rewarding that behavior.

Othello: when trust becomes a vulnerability

In Othello, Iago builds a deceptive narrative about Desdemona. Insinuations and manipulated evidence feed Othello’s jealousy, while Othello remains responsible for the violence he commits. [5]

In our technological version, Iago would be extremely dangerous in a team conversation. He would know how to present a genuine piece of information inside a false story, exploiting the listener’s trust.

Imagine an accurate report accompanied by an unjustified conclusion. A fragment of conversation stripped of context. An AI response accepted because it sounds impressively confident.

Shakespeare might add an uncomfortable question to the review: who is steering our interpretation?

It’s a good question for anyone who develops, manages, or uses technology. Information can look organized, elegant, and convincing. We still need to examine its origin and the path from the evidence to the conclusion.

Intermission: which language would he use?

I could bet on Python for readability, PHP because it’s familiar to me, or invent a reason for him to choose Rust because he already knew the price of letting certain things get out of control.

But I like imagining another quality: Shakespeare would care about whoever had to read the code later.

Maybe he would write memorable comments. Maybe someone would need to explain that a signup function has no room for a three-page monologue. And he would probably discover that giving a variable a clear name takes a very different kind of discipline from naming a tragedy.

However beautiful it sounds, theFateOfThoseWhoHaveDeparted is still a complicated name for a list of inactive users.

Act II: AI arrives in Shakespeare’s time

Now let’s bring an AI assistant to the playwright’s desk, accepting the historical impossibility as part of the game. Between the quill and the manuscripts, a window appears, ready for a conversation.

Shakespeare types:

“I need a scene where two people in love talk to each other knowing that their families hate one another. I want desire, risk, and something they can’t quite bring themselves to say directly.”

The tool offers alternatives. He asks for a shorter version, changes an image, and rejects a line that is too beautiful for that particular character. He reads it aloud. He notices a useful idea in the third attempt and rewrites almost everything.

I can picture him using AI to explore structures, compare rhythms, and challenge his own imagination. A kind of workshop of possibilities, subject to the author’s ear and choices.

I can also imagine the assistant hearing:

“You’ve written a perfectly correct declaration of love. Now we need to make someone believe it.”

The author already worked with existing stories

One historical fact makes this possibility richer: Shakespeare transformed narratives that already existed. The Royal Shakespeare Company identifies Arthur Brooke’s poem, published in 1562, as the immediate source for Romeo and Juliet. Among his changes, Shakespeare condensed a story unfolding over months into just a few days. [6]

That choice changes the experience: haste becomes part of the tragedy. The characters almost run out of breath.

That’s why I imagine a conversation with AI might involve questions much more specific than “write a brilliant play.” He might ask for three ways to speed up a scene, a challenge to a character’s motivation, or alternatives to a line that reveals too early what should remain uncertain.

The comparison has a limit: this practice of adapting stories does not settle today’s questions about authorship or the use of creative works by AI. It helps us see the transformation, selection, and construction involved in making something.

AI might suggest an improvement that ruins the play

Imagine the assistant analyzing Romeo and Juliet and proposing:

AI: “I’ve identified a planning failure. I suggest ensuring the letter is delivered and postponing irreversible decisions until the information has been confirmed.”

Shakespeare: “Excellent for the characters. Awkward for the tragedy.”

The suggestion makes sense when the goal is to prevent a disaster. But in that work, Shakespeare is building a dramatic experience.

That difference in purpose changes everything. A solution can be coherent, well written, and completely unsuited to the intention of the person who requested it.

In software, that deserves attention too. Imagine asking for a simpler screen and receiving a version that hides the very warning a user needs to make a decision. Or asking for a faster process and discovering that the removed step was the confirmation of an important operation.

Our Shakespeare would have to explain what he wanted to preserve: the tension, the ambiguity, the discomfort, the silence before an answer. Some difficulties are part of the experience he has chosen to create.

What if everyone had the same assistant?

Perhaps competition between theater companies would start to include absurd promises:

“Unlimited tragedies. Now with five plot twists per act. Subscribe to Bard Pro.”

Some people would use the new tool to experiment. Some would hand over the first text it produced. And I can imagine someone announcing: “I’ve discovered the ultimate prompt for outdoing Shakespeare.”

Shakespeare himself might find that amusing. Or charge admission.

In this scenario, access to more alternatives would expand the opportunities and the work of choosing between them. Faced with fifty versions of a scene, which deserves the stage? Which fits the characters? Which surprises us without destroying the story’s coherence?

We could even imagine a young author who previously had no one to exchange ideas with finding a way to develop an idea through the tool. That would be a valuable gain. The idea’s future would remain open, depending on what the author did with the help received.

Act III: who answers for the work?

We don’t know whether Shakespeare would embrace AI, despise it, or negotiate a discount for the whole company. The thought experiment is worthwhile because of the questions it raises about our own work.

For programmers, the imaginary encounter leaves a challenge: what can you explain about what you’re building?

Can you justify a decision, spot an inconsistency, recognize an unsuitable suggestion, and change course? Can you follow the effect of your work on the people who will use it?

I like imagining Shakespeare treating an AI suggestion as he would a line in rehearsal: trying it out, listening, cutting, adjusting. At times, he would use a great deal of it. At others, he would close the window and follow an idea he couldn’t quite explain yet.

The tool could take part in the creative process. The responsibility for putting that version onstage would remain his choice.

And if he were a programmer, perhaps he would finish his workday with an especially inspired comment, a well-considered solution, and the pride of having brought order to chaos.

Until someone appeared in the doorway:

“William, this looks great. We just need to change one tiny thing.”

He would open a new file.

act_ii.md

---

References

1. Folger Shakespeare Library — Shakespeare's life: his work as a playwright, actor, and shareholder in a theater company.
2. Folger Shakespeare Library — Hamlet: text and synopsis, including the performance used to investigate Claudius.
3. Folger Shakespeare Library — Romeo and Juliet, Act V, scene 2: the interruption that prevented the letter’s delivery.
4. Folger Shakespeare Library — Macbeth: ambition, power, and the consequences of the protagonist’s choices.
5. Folger Shakespeare Library — Othello: Iago’s insinuations and Othello’s violence.
6. Royal Shakespeare Company — Romeo and Juliet: Dates and Sources: Arthur Brooke’s poem as a source and Shakespeare’s transformations.