Una gestora sin experiencia en programación creó con Codex un negociador de IA: qué funcionó en los prompts

Si has probado a crear un interlocutor de IA con un rol asignado, conoces el mayor problema: a las dos réplicas empieza a darte la razón en todo. El equipo de la universidad corporativa de «KORUS Consulting» resolvió este problema en un simulador de negociaciones. Lo más llamativo es que lo montó Ksenia Kalabushkina, responsable de formación que, según sus propias palabras, no había escrito una sola línea de código en su vida. Repasamos qué técnicas funcionan en este caso y cuáles se pueden aprovechar en otros productos.

Por qué hacía falta un simulador

La idea es sencilla. La habilidad de negociar solo se consolida con la práctica, y practicar con un cliente real es demasiado arriesgado: una formulación desafortunada cuesta plazos, alcance del trabajo y confianza. Entrenar con compañeros tampoco resuelve nada: se conocen entre sí, se siguen el juego y no muestran un oponente duro, evasivo o apresurado.

Por eso hace falta un rival disponible en cualquier momento, que mantenga el rol asignado y entregue un análisis tras la conversación. El usuario elige el caso, el rol, la duración, la metodología de evaluación y el estilo: cooperación o competencia. Después empieza un duelo por voz de diez minutos. La IA responde hablando y, al final, anuncia al ganador y analiza las jugadas fuertes, los riesgos y los momentos decisivos. La evaluación se basa en cinco criterios: avance hacia el objetivo, control del curso de la conversación, trabajo con los intereses, argumentación e intercambios, y calidad de los acuerdos.

Cómo enseñaron al modelo a no rendirse

Esta es la parte más útil para los desarrolladores. Los autores usaron varias técnicas.

Primera: separar los roles. Durante el duelo, el modelo juega únicamente como rival y no da pistas al usuario. Al terminar, una petición aparte recibe la transcripción completa y actúa como evaluador con la instrucción «evalúa solo lo que confirma la transcripción». A un único modelo le cuesta negociar y ser, a la vez, un entrenador objetivo, así que se usan dos prompts distintos.

Segunda: el comportamiento cambia con el tiempo. Al principio, el rival revela el contexto y se resiste a cerrar un trato prematuro. Hacia el final propone soluciones en paquete y comprueba los compromisos. Pasados los diez minutos, ayuda a fijar el acuerdo o a reconocer honestamente que no hay trato. Así el modelo no da el ejercicio por concluido tras dos réplicas educadas.

Tercera: la metodología no se le da entera. El libro de Vladímir Tarásov «El arte de la lucha gerencial» se dividió en fragmentos con sentido propio: trabajo con los intereses, preguntas, condiciones de las concesiones, fijación de los acuerdos. Antes de responder, el servicio elige varios fragmentos cercanos a la réplica actual y se los pasa al modelo. En esencia, es un RAG corriente, y reduce el riesgo de recibir consejos genéricos en lugar de una reacción a las palabras concretas del usuario.

Cuarta: probar el comportamiento, no la elegancia del prompt. Los autores aconsejan preparar un conjunto de provocaciones: «pongámonos de acuerdo y ya», «acepto todo», «terminemos ahora». Un buen rival no rompe el papel, no revela sus intereses ocultos y devuelve la conversación a las condiciones.

Construirlo sin programador

El stack se eligió deliberadamente sencillo: una página web, un pequeño servidor en Node.js, la API de OpenAI para texto y voz, Supabase para el almacenamiento, GitHub para el control de versiones y Vercel para la publicación. Trabajaron a través de Codex. El orden fue este: primero, una descripción de una página del recorrido del usuario; después, la división de los requisitos en obligatorios, convenientes y futuros. Con un desarrollador de IA, el primer paso es pedirle que reformule la tarea y haga preguntas, en lugar de ponerse a escribir código de inmediato. Cada etapa se verifica ejecutándola: primero, un duelo de texto sin base de datos ni voz; después, el resto.

Hay que recordar aparte lo de la clave de API. Se guarda en una variable de entorno en el servidor y no debe acabar en GitHub, en capturas de pantalla ni en conversaciones. Si usas materiales metodológicos internos, elimina de ellos los datos personales, los nombres de clientes y las condiciones comerciales antes de enviarlos a un modelo externo.

Limitaciones y conclusión

La historia tiene salvedades. Es el relato de los propios autores, sin mediciones independientes: se desconoce cuántas personas han mejorado realmente sus habilidades. La decisión sobre el ganador la toma el propio modelo, y ese tipo de evaluaciones tiende a ser subjetivo. Además, todo el servicio depende de una única API externa. Parte del material de nuestra fuente se interrumpe en la sección sobre la conexión del modelo, por lo que aquí no se analizan el despliegue ni los trucos de vibe coding.

La conclusión práctica va más allá de las negociaciones. Si desarrollas cualquier simulador de IA o agente de rol, separa al que «juega» del que «evalúa», incorpora el conocimiento por porciones y prueba el sistema con provocaciones, no con diálogos que salen bien. Para un product manager, es además un ejemplo de cómo una persona sin perfil técnico puede validar una hipótesis en un par de noches: primero el escenario, después las herramientas.