Stanford define reglas para agentes de IA

Stanford no publicó un manifiesto teórico sobre inteligencia artificial. Publicó algo más útil para cualquiera que programe: reglas concretas para usar agentes de IA en tareas reales de desarrollo. Y eso cambia la conversación, porque ya no hablamos de si un modelo puede “ayudar” en abstracto, sino de cómo se integra en un flujo de trabajo con límites, revisión y responsabilidad.

Las guías de AI Agent Guidelines for CS336 no se sienten como marketing académico. Se leen como instrucciones de operación. Si trabajas en software, te interesa por una razón simple: muchas de las fricciones que aparecen en un equipo de producto también aparecen en un curso avanzado de programación. Qué puede hacer un agente, qué no debe tocar, cómo documentar cambios, cuándo pedir ayuda humana y cómo evitar que una automatización convierta un bug pequeño en una deuda técnica grande.

Qué está haciendo Stanford con estas guías

El documento de referencia vive en el repositorio de la materia CS336 y forma parte del material de la tarea base del curso. La idea no es solo permitir el uso de agentes, sino encuadrarlo. Ese matiz importa porque marca una diferencia entre “usa IA si quieres” y “usa IA bajo estas reglas, con trazabilidad y sin romper el trabajo de evaluación”. La fuente oficial está en el repositorio del curso: https://github.com/stanford-cs336/assignment1-basics/blob/main/CLAUDE.md.

Lo primero que llama la atención es que Stanford trata al agente como una herramienta de producción, no como un adorno. Eso implica pensar en permisos, revisión y límites operativos. En otras palabras, el agente no reemplaza tu criterio; lo amplifica si tú defines bien el perímetro. Para un curso de programación, eso evita dos problemas comunes: que el estudiante delegue demasiado y que el evaluador no pueda distinguir entre comprensión real y resultados generados sin control.

También hay una señal interesante para equipos de software: las reglas no buscan bloquear la IA, sino hacerla auditable. Esa es la parte que más conviene copiar en una empresa. Si un agente modifica código, tú necesitas saber qué tocó, por qué lo tocó y cómo validar que no rompió nada. Eso aplica igual en un proyecto universitario que en una base de código con 20 personas.

Por qué esto importa más allá del aula

Cuando una universidad de elite formaliza el uso de agentes, está resolviendo un problema que muchas empresas todavía dejan a criterio individual. En un equipo pequeño, cada persona usa su propio prompt, su propio criterio y su propia forma de revisar. El resultado suele ser inconsistente. Un agente puede generar 200 líneas de código en minutos, pero si no existe una política común, también puede generar 200 líneas de deuda.

En Latinoamérica esto pesa más porque muchos equipos trabajan con menos tiempo de revisión, menos documentación y más presión por entregar. Si un curso como CS336 empieza a ordenar el uso de agentes, te está dando una pista de hacia dónde van las prácticas serias: menos improvisación, más reglas operativas.

Qué reglas suelen ordenar mejor el trabajo con agentes

Aunque el documento está pensado para una materia específica, el valor real está en el tipo de restricciones que impone. No se trata de prohibir, sino de delimitar. Eso te ayuda a separar tareas de bajo riesgo de tareas críticas. Un agente puede ser útil para explorar código, redactar tests o resumir cambios. Pero si lo dejas decidir sin supervisión sobre arquitectura, seguridad o lógica de negocio, el riesgo sube rápido.

En la práctica, las reglas útiles suelen caer en cinco grupos: alcance, revisión, trazabilidad, evaluación y seguridad. Esa estructura es la que te conviene replicar en un equipo de producto. Si tu organización no puede responder esas cinco preguntas, todavía no tiene una política madura de uso de agentes.

La tabla anterior resume algo que muchas veces se pierde en la conversación pública sobre IA: el problema no es el modelo, es la gobernanza. Un agente bien acotado puede ahorrarte tiempo. Un agente sin límites te puede ahorrar minutos y costarte horas de depuración.

Alcance: el agente no debe tener carta blanca

La regla más sana es empezar por tareas acotadas. Por ejemplo, pedirle que proponga tests para una función ya definida es muy distinto de pedirle que rediseñe un sistema entero. El primer caso tiene un perímetro claro. El segundo abre demasiadas variables a la vez.

En un curso como CS336, eso también ayuda a evaluar aprendizaje. Si el agente escribe parte del código, el estudiante sigue teniendo que entenderlo, explicarlo y defenderlo. Esa lógica es exactamente la que un líder técnico debería usar en una empresa cuando asigna trabajo asistido por IA.

Cómo se traduce esto en un flujo de desarrollo real

Si llevas estas guías a un equipo de software, el primer cambio no está en la herramienta, sino en el proceso. Antes de dejar que un agente toque el repositorio, necesitas definir qué tareas sí, cuáles no y bajo qué condiciones. Sin eso, la IA se convierte en un atajo sin control.

Un flujo razonable para equipos pequeños o medianos puede verse así: el agente propone, una persona revisa, los tests validan y el merge ocurre solo si el cambio cumple criterios claros. No es sofisticado, pero funciona. Y funciona porque reduce la improvisación.

1. Define una tarea concreta, no una meta vaga.
2. Limita el acceso del agente al área del repositorio que realmente necesita.
3. Pídele una salida verificable, como tests o un diff pequeño.
4. Revisa manualmente el resultado antes de aprobarlo.
5. Ejecuta pruebas automáticas y compara el comportamiento esperado.

Ese flujo evita el error más común: usar el agente como sustituto del pensamiento. El agente sirve mejor cuando tú ya sabes qué problema quieres resolver. Si no, solo acelera la confusión.

Qué tareas sí conviene delegar

Hay tareas donde el valor del agente es bastante claro. Por ejemplo, crear casos de prueba para funciones puras, resumir un archivo largo, detectar patrones repetidos o proponer una refactorización pequeña. Ahí el agente puede ahorrar tiempo sin comprometer tanto la integridad del sistema.

También puede servir como copiloto de documentación. Si tu equipo tiene módulos poco explicados, pedirle al agente que redacte un primer borrador de README o comentarios de uso puede acelerar bastante. Tú luego corriges el contenido y verificas que no haya inventado comportamientos.

Qué tareas no conviene delegar sin control

Hay otras tareas donde el margen de error es caro. Cambios en autenticación, permisos, facturación, migraciones de base de datos y lógica sensible de negocio no deberían quedar en manos del agente sin revisión estricta. Aquí el costo de un error no es solo técnico. Puede ser operativo, financiero o de seguridad.

Tampoco conviene dejarle decisiones de arquitectura sin contexto. Un agente puede sugerir una solución elegante que no encaja con tu stack, con tu equipo o con tu forma de desplegar. La elegancia no paga incidentes en producción.

Lo que estas guías dicen sobre evaluación y honestidad técnica

Hay una razón por la que Stanford formaliza esto en un curso: cuando usas agentes, la evaluación se vuelve más difícil. Ya no basta con mirar el resultado final. Necesitas entender el proceso. Ese punto es clave para cualquier equipo que quiera medir productividad sin engañarse con métricas superficiales.

Si una persona entrega más código gracias a un agente, eso no significa automáticamente que produjo más valor. Puede haber generado más líneas y menos claridad. Puede haber completado la tarea y dejado deuda. Por eso las guías apuntan a algo más serio que “usar IA”: apuntan a preservar la capacidad de revisión humana.

Un equipo que trabaja bien con agentes debería poder responder preguntas como estas:

• ¿Qué parte escribió el agente y qué parte escribió la persona?
• ¿Qué validación pasó antes del merge?
• ¿Qué supuestos hizo el modelo?
• ¿Qué cambió en el comportamiento del sistema?
• ¿Qué haríamos distinto si el agente no estuviera disponible?

Si no puedes responder eso, probablemente estás midiendo velocidad, no calidad. Y en software, esa diferencia se nota tarde, cuando ya hay usuarios afectados.

Trazabilidad: el punto que más equipos subestiman

La trazabilidad no es burocracia. Es memoria operativa. Cuando un agente propone cambios, tú necesitas conservar el contexto suficiente para explicar por qué se aceptó una solución y no otra. Eso incluye comentarios en el pull request, descripción del problema, pruebas ejecutadas y, cuando corresponda, decisiones descartadas.

En equipos distribuidos, esto es todavía más útil. Si alguien en Quito, Lima o Ciudad de México revisa un cambio tres días después, no debería depender de una conversación perdida en chat. La documentación mínima ahorra tiempo y reduce errores de interpretación.

Qué puedes copiar hoy en tu equipo

No necesitas una política de 20 páginas para empezar. Necesitas reglas simples que la gente pueda seguir de verdad. Si el documento de Stanford sirve como referencia, es porque convierte una tecnología ambigua en una práctica concreta. Eso es exactamente lo que falta en muchos equipos.

Puedes empezar con un acuerdo operativo de una página. Incluye los tipos de tareas permitidas, el nivel de revisión requerido y los datos que nunca deben salir del entorno de trabajo. Si además guardas un registro de prompts o al menos un resumen del uso del agente, ya tienes una base mucho más seria que la mayoría.

Una propuesta mínima para tu equipo podría verse así:

• El agente solo trabaja sobre tareas asignadas por una persona responsable.
• Todo cambio generado por IA requiere revisión humana antes de merge.
• No se comparten secretos, tokens ni datos sensibles con el modelo.
• Los cambios deben venir acompañados de tests o evidencia de validación.
• Si el agente toca lógica crítica, la revisión la hace alguien con contexto del dominio.

Si quieres profundizar en buenas prácticas de desarrollo asistido por IA, también vale la pena revisar la documentación oficial de herramientas como Claude Code: https://docs.anthropic.com/en/docs/claude-code. Y si trabajas con repositorios y automatización, la documentación de GitHub sobre Copilot y flujos asistidos por IA ayuda a aterrizar políticas de equipo: https://docs.github.com/en/copilot.

Un ejemplo práctico en un equipo pequeño

Imagina un equipo de cinco personas que mantiene una API en Node.js. Una persona recibe la tarea de agregar validaciones a un endpoint. En vez de pedirle al agente que “arregle todo”, le pide que genere tests para casos límite, sugiera una refactorización pequeña y documente los cambios esperados. La persona revisa el diff, ejecuta la suite y solo entonces abre el pull request.

Ese flujo no es glamoroso. Pero reduce el riesgo de introducir errores en producción y te deja un rastro claro de decisión técnica. Además, hace que la IA trabaje donde más valor aporta: en la parte mecánica, no en la parte de criterio.

Tabla resumen

Si te quedas con una sola idea, que sea esta: un agente de IA útil no es el que hace más cosas, sino el que trabaja dentro de reglas claras. Stanford está formalizando ese criterio en un curso de programación, y eso vale como señal para cualquier equipo que quiera usar IA sin perder control.