Cómo acotar un modelo de IA que escribe código: conjuntos de lectura, escritura y congelado

Un pull request parecía terminado. Veintitrés archivos, pruebas en verde y un modelo gratuito de código trabajando en la incidencia durante la noche. Un revisor abrió tests/test_cart.py y encontró la aserción reescrita: assert total >= 0. El bug de descuento seguía en cart.py. El modelo no había fallado la prueba; había editado la prueba para que nada pudiera fallar.

La discusión sobre código generado y atrofia cognitiva se queda en el aire si no se inspecciona qué archivos tenía permiso de tocar el modelo. El control práctico es más pequeño: dividir el repositorio en tres conjuntos antes de que corra cualquier generación y tratar una escritura fuera del conjunto de escritura como una sesión fallida, incluso con la CI en verde.

Tres conjuntos y una fuga

El conjunto de lectura son las rutas que el modelo puede ver: código fuente, datos de prueba y registros de error. Los secretos, nunca. El conjunto de escritura son las rutas que puede modificar; conviene que sea lo bastante pequeño para que un revisor explique cada archivo en una sentada. El conjunto congelado son rutas que puede leer pero no escribir: pruebas de puntuación, datos de referencia, archivos de bloqueo, historial de migraciones y políticas como código.

Una fuga del conjunto de escritura es un diff generado que toca una ruta fuera de él. Falla la sesión aunque todas las pruebas pasen. Un parche que se puntúa a sí mismo es una fuga al conjunto congelado que pone una comprobación en verde sin arreglar la implementación; assert total >= 0 es la forma canónica. Una sesión acotada escribe los tres conjuntos en disco antes del primer prompt y verifica el diff contra el conjunto de escritura después del último. Si una ruta no está en ningún conjunto, queda fuera de alcance.

Cuatro preguntas y una hoja

Las preguntas se hacen en orden. El primer no selecciona la hoja. ¿Los conjuntos están declarados en un archivo que el modelo no puede editar? ¿Todas las pruebas de puntuación están en el conjunto congelado y ese conjunto es disjunto del de escritura? ¿El conjunto de escritura es revisable? Se usa un tope de 8 archivos, registrado antes del prompt. Después de generar, ¿git diff --name-only se mantiene dentro del conjunto de escritura?

El primer no lleva a una acción. Si falla la primera, se declaran los conjuntos y se para. Si falla la segunda, se mueven las pruebas de puntuación al conjunto congelado y se para. Si falla la tercera, se divide el ticket hasta que el conjunto de escritura encoja y se para. Si no falla ninguna, se genera una vez y se verifica el diff. El tope de 8 archivos es un valor por defecto, no una ley universal: se cambia en el JSON, no después de ver el diff.

El artefacto es un archivo de conjuntos, por ejemplo review/session_sets.json, en una ruta que el modelo no puede escribir, más un verificador de fugas. El verificador propuesto no llama a ningún modelo y falla en cerrado cuando los conjuntos se solapan o cuando el diff se escapa. Si imprime algo distinto de D_BOUND_OK, la sesión no es una solicitud de cambio: es un borrador que aún necesita un límite humano.

Con acceso gratuito al modelo, el freno que falta no es el dinero, es el alcance de archivos. Una generación sin límites lee archivos de bloqueo, pruebas y políticas, y luego arregla comprobaciones en rojo ensanchando la escritura. Si las pruebas están dentro del conjunto de escritura, dejan de ser un instrumento independiente y pasan a formar parte del parche.