Desde el primer commit de mi proyecto de Python, una regla importó más que ninguna otra: el agente de programación nunca debe ver los criterios de aceptación. Por eso construí dos agentes que nunca comparten notas. Uno escribe las pruebas a partir de la especificación completa, y otro agente de programación escribe el código a partir de la misma especificación, pero sin los criterios. En la mayoría de los entornos de programación, el mismo agente escribe ambas cosas, lo que compromete la validez de los resultados de las pruebas.
Forcé que el recorte se produjera en el código mediante el ensamblaje de contexto, el paso que construye el prompt del agente de programación, donde la sección de criterios del archivo de tarea se elimina antes de construir el prompt. Durante un tiempo creí que ese recorte era hermético. Luego descubrí que una sola línea de comentario lo rompía: el recorte se detenía allí y cada criterio posterior al comentario llegaba al agente de programación. Una semana después, un criterio que ocupaba una segunda línea provocó lo mismo. Ambos errores eran míos. Esta vez, tras corregirlos, añadí pruebas para que cualquier compilación futura falle si el recorte no se aplica como debe.
Skills y servidores MCP suelen compararse entre sí, pero para la regla de la que depende mi proyecto, la respuesta resultó ser ninguna de las dos. Quería que los usuarios pudieran usar qikly, mi herramienta de línea de comandos, desde un asistente de IA como Claude Code o Cursor. Eso implica dos LLM en juego, y ninguno debería ver los criterios de aceptación. El asistente ya podía ejecutar qikly, pero no sabía cuándo usarla, así que escribí un Skill: una carpeta de instrucciones en Markdown que el asistente carga cuando una solicitud coincide con su descripción.
Escribir el Skill separó dos tareas. El trabajo del Skill es ofrecer consejos sobre qué debe ir en los requisitos y qué en los criterios de aceptación. Eso solo puede enseñarse, no garantizarse. El trabajo del ensamblaje de contexto es eliminar los criterios en todo momento, tenga o no instalado un Skill. Los consejos siguen siendo importantes, porque un criterio que también aparece en los requisitos llega igualmente al agente de programación, así que añadí una comprobación en qikly --validate que advierte sobre esas repeticiones.
Pregunta frecuente
P: ¿Por qué no confiar en un modelo mejor o en una temperatura cero para evitar que el LLM vea los criterios?
R: Un modelo mejor sigue las indicaciones con más frecuencia, pero no siempre, y fijar la temperatura en cero hace las respuestas más repetibles, no más obedientes. Las reglas que deben cumplirse siempre deben aplicarse en el código, como el ensamblaje de contexto, mientras que la orientación basada en juicio puede estar en un Skill.
Fuente: Towards Data Science · Resumido por HeadlinesBriefing