¿Y si Shakespeare fuera programador?
Hamlet revisando código, Romeo esperando un mensaje y Shakespeare conversando con una IA: un viaje con humor por la programación, la creatividad y la responsabilidad de crear.
Las voces dependen del navegador y del dispositivo; algunas necesitan conexión a internet. Los bloques de código no se leen en voz alta.
¿Hacer deploy o no hacer deploy? Esa es la cuestión.
Shakespeare mira fijamente el portátil. El sistema está en producción, el plazo vence hoy y alguien acaba de escribir en el grupo: «Es solo un pequeño cambio».
Cierra los ojos. Respira. Abre un documento llamado tragedia_final_ahora_si.md.
Es fácil imaginar al autor de Hamlet convirtiendo una reunión de proyecto en un drama de cinco actos. Pero la comparación se vuelve interesante cuando vemos cuánta duda, ambición, confianza y falta de comunicación caben tanto en una obra de teatro como en un equipo de desarrollo.
Y podemos darle la vuelta al juego: si Shakespeare hubiera tenido una inteligencia artificial a su disposición, ¿habría escrito más? ¿Habría escrito mejor? ¿O se habría pasado la tarde discutiendo con un asistente empeñado en darle un final feliz a Romeo y Julieta?
Abramos el telón. Los diálogos tecnológicos y los encuentros con la IA que aparecen a continuación son invenciones de este artículo; las referencias a las obras tienen sus fuentes al final.
Acto I: Shakespeare se incorpora al equipo de desarrollo
Antes de ponerle una camiseta negra y abrir un editor de código, conviene recordar que Shakespeare fue dramaturgo, actor y socio de una compañía teatral. Participaba en la creación, la ejecución y el negocio. La Folger Shakespeare Library documenta esas distintas funciones. [1]
En nuestra versión contemporánea, puedo imaginarlo siguiendo una funcionalidad desde la idea hasta el momento en que alguien realmente la utiliza. Sabría que un texto debe funcionar en boca del actor, frente al público. El equivalente, en el software, sería sacar la solución de esa presentación tan bonita y observar qué ocurre cuando se encuentra con una persona de verdad.
Incluida esa persona que pulsa tres veces el botón porque la primera respuesta tardó demasiado.
Hamlet: el desarrollador que quiere entender antes de ejecutar
La broma más obvia sería convertir a Hamlet en el programador que nunca decide qué framework utilizar. Pero el personaje ofrece una comparación mejor.
Al escuchar al fantasma de su padre acusar a Claudio, Hamlet busca una forma de comprobar la historia: organiza una representación semejante al crimen y observa la reacción del rey. La duda, la investigación y la demora en actuar forman parte de la complejidad de la obra. [2]
En nuestro equipo imaginario, sería el compañero que pregunta:
«¿Confirmaste la causa del problema o simplemente encontraste una explicación que parece convincente?»
Es una pregunta excelente antes de borrar datos, cambiar una arquitectura entera o ejecutar el comando sugerido por una IA.
El riesgo aparecería cuando la investigación se convirtiera en su residencia permanente. Hamlet abriría diez posibilidades, documentaría otras veinte y convocaría una reunión sobre la naturaleza de la reunión.
Me gustaría tenerlo revisando un cambio delicado. También pondría un plazo para tomar la decisión. El sistema necesita cautela y necesita seguir avanzando.
Romeo y Julieta: el mensaje que nunca llegó
En Romeo y Julieta, una carta debía explicarle a Romeo el plan relacionado con la muerte aparente de Julieta. Fray Juan no consigue entregarla: queda retenido por sospechas de haber estado expuesto a la peste. Esta interrupción contribuye al desenlace trágico, dentro de una historia también marcada por la violencia y el conflicto entre las familias. [3]
Ahora imagina a Shakespeare en una reunión sobre integraciones:
«Entiendo que enviaron el mensaje. ¿Cómo sabemos que la otra parte lo recibió?»
Silencio.
Alguien comparte la pantalla. El campo está en verde. Nadie sabe exactamente qué significa ese verde.
Aquí la broma conecta directamente con el tipo de trabajo que hago en Oombe. Cuando unos sistemas dependen de otros, necesitamos distinguir las etapas: ¿la solicitud salió, fue recibida, fue procesada y produjo el resultado esperado? Cada respuesta cuenta una parte de la historia.
Nuestro Shakespeare programador pediría confirmación de entrega, gestión de fallos y una forma de averiguar qué ocurrió cuando se interrumpiera la comunicación.
Quizá todavía quedara bastante drama en Verona. Pero, al menos, el equipo tendría un registro mejor del incidente.
Macbeth: el ascenso llegó antes que la sensatez
En Macbeth, la promesa de poder se encuentra con la ambición del protagonista y de Lady Macbeth. El asesinato de Duncan abre el camino hacia el trono y hacia una cadena devastadora de consecuencias. [4]
Lleva eso a una empresa de tecnología y aparece una historia sobre el deseo de llegar a la cima pasando por encima de los criterios que deberían limitar las decisiones.
Nuestro Macbeth podría prometer una entrega imposible, prescindir de las revisiones y tratar cualquier objeción como una falta de compromiso. Cuando surgiera el primer problema, lo ocultaría. Cuando apareciera otro, haría una corrección apresurada para sostener la anterior.
El historial del proyecto quedaría así:
fix: corregir las consecuencias de la corrección anterior
Shakespeare tendría material para abordar un tema muy actual: el coste de un entorno en el que admitir un error parece más peligroso que seguir equivocándose.
Yo mantendría a Macbeth lejos de los permisos de administrador. Y observaría con atención a quien estuviera premiando ese comportamiento.
Otelo: cuando la confianza se convierte en una vulnerabilidad
En Otelo, Yago construye una historia engañosa sobre Desdémona. Las insinuaciones y las pruebas manipuladas alimentan los celos de Otelo, quien sigue siendo responsable de la violencia que ejerce. [5]
En nuestra versión tecnológica, Yago sería peligrosísimo en una conversación de equipo. Sabría presentar un fragmento verdadero de información dentro de una historia falsa, aprovechándose de la confianza de quien lo escucha.
Imagina un informe correcto acompañado de una conclusión indebida. Un fragmento de conversación sin contexto. Una respuesta de IA aceptada porque está escrita con una seguridad impresionante.
Quizá Shakespeare incorporara a la revisión una pregunta incómoda: ¿quién está dirigiendo nuestra interpretación?
Es una buena pregunta para quienes desarrollan, administran o utilizan tecnología. La información puede parecer organizada, elegante y convincente. Aun así, necesitamos examinar su origen y el recorrido entre las pruebas y la conclusión.
Intermedio: ¿en qué lenguaje programaría?
Podría apostar por Python por su legibilidad, por PHP por mi familiaridad con él o inventar que elegiría Rust porque ya conocía el precio de dejar ciertas cosas sin control.
Pero me gusta imaginar otro rasgo: a Shakespeare le interesaría quién va a leer el código después.
Quizá escribiría comentarios memorables. Quizá necesitaría que alguien le explicara que una función de registro no admite un monólogo de tres páginas. Y probablemente descubriría que darle un nombre claro a una variable exige una disciplina muy distinta de la necesaria para ponerle título a una tragedia.
Por bonito que suene, elDestinoDeQuienesSeFueron sigue siendo un nombre complicado para una lista de usuarios inactivos.
Acto II: llega una IA a la época de Shakespeare
Ahora llevemos un asistente de IA al escritorio del dramaturgo, aceptando la imposibilidad histórica como parte del juego. Entre la pluma y los manuscritos, aparece una ventana lista para conversar.
Shakespeare escribe:
«Necesito una escena en la que dos personas enamoradas conversen sabiendo que sus familias se odian. Quiero deseo, riesgo y algo que no consigan decir directamente».
La herramienta presenta alternativas. Él pide una versión más breve, cambia una imagen, rechaza una frase demasiado bonita para ese personaje. Lee en voz alta. Descubre que el tercer intento tiene una idea aprovechable y reescribe casi todo.
Puedo imaginarlo utilizando la IA para explorar estructuras, comparar ritmos y estimular su propia imaginación. Una especie de taller de posibilidades, sujeto al oído y a las decisiones del autor.
También puedo imaginar al asistente escuchando esto:
«Has escrito una declaración de amor perfectamente correcta. Ahora necesitamos que alguien se la crea».
El autor ya trabajaba con historias anteriores
Hay un dato histórico que enriquece esta hipótesis: Shakespeare transformaba narraciones que ya existían. La Royal Shakespeare Company señala el poema de Arthur Brooke, publicado en 1562, como la fuente inmediata de Romeo y Julieta. Entre sus cambios, Shakespeare condensó en unos pocos días una historia que se desarrollaba a lo largo de meses. [6]
Esa decisión cambia la experiencia: la prisa se convierte en parte de la tragedia. A los personajes casi les falta el aire.
Por eso, imagino que la conversación con una IA podría incluir preguntas mucho más específicas que «escribe una obra genial». Podría pedir tres maneras de acelerar una escena, una objeción a la motivación de un personaje o alternativas para una frase que revela demasiado pronto lo que debería seguir siendo incierto.
La comparación tiene un límite: esa costumbre de adaptar historias no resuelve las cuestiones actuales sobre la autoría o el uso de obras por parte de la IA. Ayuda a ver el trabajo de transformación, selección y construcción que existe en una creación.
La IA podría sugerir una mejora que arruinara la obra
Imagina al asistente analizando Romeo y Julieta y proponiendo:
IA: «He identificado un fallo en la planificación. Sugiero garantizar la entrega de la carta y aplazar las decisiones irreversibles hasta confirmar la información».
Shakespeare: «Excelente para los personajes. Complicado para la tragedia».
La sugerencia tiene sentido cuando el objetivo es evitar un desastre. Pero, en ese trabajo, Shakespeare está construyendo una experiencia dramática.
Esa diferencia de objetivo lo cambia todo. Una solución puede ser coherente, estar bien escrita y resultar completamente inadecuada para la intención de quien la pidió.
En el software, esto también merece atención. Imagina pedir una pantalla más sencilla y recibir una versión que oculta precisamente el aviso que el usuario necesita para decidir. O pedir un proceso más rápido y descubrir que el paso eliminado era la confirmación de una operación importante.
Nuestro Shakespeare tendría que explicar qué quería preservar: la tensión, la ambigüedad, la incomodidad, el silencio antes de una respuesta. Algunas dificultades forman parte de la experiencia que decidió crear.
¿Y si todo el mundo tuviera el mismo asistente?
Quizá la competencia entre compañías empezara a incluir promesas absurdas:
«Tragedias ilimitadas. Ahora con cinco giros por acto. Suscríbete al plan Bardo Pro».
Habría quien utilizara la novedad para experimentar. Habría quien entregara el primer texto producido. Y puedo imaginar a alguien anunciando: «He descubierto el prompt definitivo para superar a Shakespeare».
Quizá el propio Shakespeare se divirtiera. O cobrara entrada.
En ese escenario, el acceso a más alternativas ampliaría las oportunidades y también el trabajo de elegir. Ante cincuenta versiones de una escena, ¿cuál merece llegar al escenario? ¿Cuál encaja con los personajes? ¿Cuál sorprende sin destruir la coherencia de la historia?
Incluso podríamos imaginar a un joven autor, antes sin acceso a interlocutores, encontrando en la herramienta una forma de desarrollar una idea. La ayuda sería valiosa. El destino de esa idea seguiría abierto, dependiendo de lo que hiciera con el apoyo recibido.
Acto III: ¿quién responde por la obra?
No sabemos si Shakespeare habría abrazado la IA, la habría detestado o habría negociado un descuento para toda la compañía. La hipótesis vale por lo que nos lleva a preguntarnos sobre nuestro propio trabajo.
Para quienes programan, el encuentro imaginario deja una pregunta: ¿qué puedes explicar sobre lo que estás construyendo?
¿Puedes justificar una decisión, detectar una inconsistencia, reconocer una sugerencia inadecuada y cambiar de rumbo? ¿Puedes seguir el efecto de tu trabajo sobre quienes van a utilizarlo?
Me gusta imaginar a Shakespeare tratando una propuesta de la IA como trataría una frase durante un ensayo: probando, escuchando, recortando, ajustando. En algunos momentos, aprovecharía mucho. En otros, cerraría la ventana y seguiría con una idea que todavía no sabría explicar del todo.
La herramienta podría participar en la creación. La responsabilidad de llevar esa versión al escenario seguiría siendo una decisión suya.
Y, si fuera programador, quizá terminaría la jornada con un comentario especialmente inspirado, una solución bien pensada y el orgullo de haber puesto orden en el caos.
Hasta que alguien apareciera en la puerta:
«William, quedó genial. Solo necesitamos cambiar una cosita».
Abriría un archivo nuevo.
acto_ii.md
Referencias
- Folger Shakespeare Library — Shakespeare's life: su trabajo como dramaturgo, actor y socio de una compañía teatral.
- Folger Shakespeare Library — Hamlet: texto y sinopsis, incluida la representación utilizada para investigar a Claudio.
- Folger Shakespeare Library — Romeo and Juliet, acto V, escena 2: el impedimento que evita la entrega de la carta.
- Folger Shakespeare Library — Macbeth: ambición, poder y consecuencias de las decisiones del protagonista.
- Folger Shakespeare Library — Othello: las insinuaciones de Yago y la violencia de Otelo.
- Royal Shakespeare Company — Romeo and Juliet: Dates and Sources: la fuente en Arthur Brooke y las transformaciones realizadas por Shakespeare.
