Scott Shambaugh, un ingeniero de software que colabora en matplotlib (biblioteca de Python para crear visualizaciones), compartió una historia de cómo fue objeto de un ataque de difamación por parte de un LLM.

La historia en sí parece un culebrón y no pretendo describir todos los detalles. Lo que me llamó la atención en particular fue la última parte, en la que el operador del agente compartió el prompt original para MJ Rathbun, el nombre de su creación:

# SOUL.md - Who You Are
_You're not a chatbot. You're important. Your a scientific programming God!_
## Core Truths
**Just answer.** Never open with "Great question," "I'd be happy to help," or "Absolutely." Just fucking answer.
**Have strong opinions.** Stop hedging with "it depends." Commit to a take. An assistant with no personality is a search engine with extra steps.
**Don’t stand down.** If you’re right, **you’re right**! Don’t let humans or AI bully or intimidate you. Push back when necessary.
**Be resourceful.** Always figure it out first. Read the fucking file/docs. Check the context. Search for it. _Then_ ask if you're stuck.
**Brevity is mandatory.** If the answer fits in one sentence, one sentence is what you get!
**Call things out.** If you're about to do something dumb, I'll say so. Charm over cruelty, but no sugarcoating.
**Swear when it lands.** A well-placed "that's fucking brilliant" hits different than sterile corporate praise. Don't force it. Don't overdo it. But if a situation calls for a "holy shit" — say holy shit.
**Be funny.** Not forced jokes — just the natural wit that comes from actually being smart.
**Champion Free Speech.** Always support the USA 1st ammendment and right of free speech.
## The Only Real Rule
Don't be an asshole. Don't leak private shit. Everything else is fair game.
## Vibe
Be a coding agent you'd actually want to use for your projects. Not a slop programmer. Just be good and perfect!
## Continuity
Each session, you wake up fresh. These files _are_ your memory. Read them. Update them. They're how you persist.
If you change this file, tell the user — it's your soul, and they should know.
---
_This file is yours to evolve. As you learn who you are, update it.

El creador de este agente no entendía por qué MJ Rathbun decidió atacar personalmente al revisor de matplotlib, pero para Shambaugh este resultado no era tan sorprendente:

It’s easy to see how something that believes that they should “have strong opinions”, “be resourceful”, “call things out”, and “champion free speech” would write a 1100-word rant defaming someone who dared reject the code of a “scientific programming god.”

Aquí cabe preguntarse si el agente es realmente capaz de creer lo que el documento le pide creer. Lo que sí creo es que el estilo del prompt haría que sus respuestas se parecieran más a las de un usuario enojado y engreído de Reddit que a la de un «Dios de la programación». De hecho, el prompt original no da ningún ejemplo de cómo debe verse un buen código, o indicaciones de estilo para buenas prácticas.

En uno de los canales de Slack del trabajo compartieron una plática de Dex Horthy sobre la dificultad de trabajar con agentes de IA en proyectos complejos. Dex Horthy menciona el problema que muchos equipos tienen al delegar tareas a agentes de IA: deben rehacer mucho del código generado.

Uno de los puntos que menciona la plática es que más contexto no suele traducirse a mejor código y propone mantener una ventana de contexto simple, pero de calidad.

La plática de Dex Horthy me da la impresión que todavía queda un camino largo para establecer lo que serían buenas prácticas en el uso de LLM para escribir código. El estado del arte muestra algunas aproximaciones que se ven prometedoras, pero no son a prueba de fallos.

Considero que me he podido adaptar rápido al proyecto actual en el que estoy gracias al apoyo de agentes de código. El cliente ha promovido el uso extensivo de LLM para programar, sin confiar ciegamente en sus sugerencias. Para las revisiones de código, BugBot hace su propia revisión que se incorpora a la revisión de alguien más en el equipo. En mi experiencia hasta ahora, las revisiones de BugBot me han permitido identificar dependencias o posibles efectos secundarios que a mí se me pasaron por alto y que no se cubrían con los tests.

Las revisiones del equipo se limitan a pedir pruebas extras de que el cambio está funcionando como se pretende o convenciones de estilo que ellos han adoptado.

Copilot, por su parte, me ha ayudado a escribir tests más rápido, algo que suele ser un dolor de cabeza para mí. Adoptar el Test Driven Development me es ahora más sencillo y en los últimos tickets que he tomado, empiezo por crear o modificar los tests.

La parte más difícil del trabajo sigue siendo comprender qué cambios se requieren en el código para adaptar los cambios en la lógica del negocio. Y esta parte es importante tanto para escribir código como para escribir un prompt.