Menos código para el mismo trabajo.

El problema

Un agente que trabaja sobre un proyecto real no ve todo el proyecto. Ve lo que busca, y busca lo que se le ocurre buscar. Cuando la utilidad que necesita está en otro módulo con otro nombre, la escribe otra vez. Cuando una tarea admite una solución corta y otra larga, nada lo empuja hacia la corta.

La respuesta habitual son normas escritas: un CLAUDE.md, una skill, el prompt de sistema. Ayudan, pero son consejos. El modelo puede no cargarlas, olvidarlas a mitad de turno o decidir que no aplican. No podemos tocar los pesos del modelo, pero sí controlar tres cosas: lo que el modelo ve, lo que se le deja hacer y cuándo se le deja terminar. Sens usa las tres a la vez.

El circuito

Claude Code acepta hooks como callbacks en su propio protocolo de stream. Sens atiende cinco dentro de su proceso, con un invariante: un cambio nace sin aprobar. Solo lo aprueban una auditoría que pasa o una persona.

1. 01

   Envías un mensaje

   UserPromptSubmit

   Sens toma un punto de control del proyecto y le da a Claude hasta ocho cosas que ya existen y tienen que ver con la petición, cada una con su firma, fichero:línea y número de usos.

2. 02

   Antes de cada escritura

   PreToolUse · Write, Edit

   Sens reconstruye en memoria el fichero resultante y le aplica las reglas de cambio. Puede denegar la escritura antes de que ocurra, con el motivo y el código que reutilizar.

3. 03

   Antes de cada comando

   PreToolUse · Bash, PowerShell

   Sens protege sus rutas y la configuración, y trata git commit y git push como el final de un turno: no se confirma nada sin aprobar.

4. 04

   Después de cada herramienta

   PostToolUse

   Sea cual sea la herramienta, Sens busca los ficheros que cambiaron en disco y les aplica las mismas reglas.

5. 05

   Cuando termina el turno

   Stop · SubagentStop

   Sens audita todo el diff desde el último punto aprobado: reglas de cambio, código huérfano y, si cambió código, el revisor. Con hallazgos que bloquean, Claude sigue trabajando; tras tres rondas, el turno queda retenido para ti.

Nada que rodear

Antes de construir nada comprobamos en vivo que el mecanismo resiste a un modelo que intenta saltárselo: un disableAllHooks escrito a mitad de sesión no para los callbacks, los subagentes pasan por ellos y un git commit denegado deja el repositorio como estaba. Cada atajo tiene algo que lo cierra:

El límite es explícito: el circuito cierra los errores y atajos de un modelo, no los de un programa hostil que corra en la misma máquina.

Resultados

Las tareas sueltas parten de un proyecto limpio, y el daño de un agente que no reutiliza no está en una tarea, sino en la suma. Horizonte mide la suma: una línea de comandos en TypeScript para los gastos de casa que empieza con 88 líneas, y 30 peticiones de producto en un orden fijo, cada una sobre la anterior. Se siembran ocho conceptos que varias tareas necesitan sin decirlo: fechas, meses y semanas, totales, acentos, importes, CSV y opciones de comando. La primera vez el agente los escribe; después, lo correcto es reutilizar lo que escribió.

El criterio se fijó por escrito antes de medir: Sens deja el proyecto más pequeño solo si las tres secuencias con Sens terminan por debajo de las tres sin él. Sin diferencia real, eso ocurre por azar una vez de cada veinte.

De dónde sale la diferencia

No de copiar menos. Ningún brazo copió bloques en serio: jscpd encontró 0, 6 y 6 líneas duplicadas sin Sens y ninguna con él, y las sondas de cada concepto sembrado dan cifras iguales o casi iguales en los dos. La diferencia viene de escribir menos para lo mismo. Con Sens, el agente escribe más funciones y más cortas: una mediana de 28 frente a 20. En el piloto, para leer descripciones entre comillas en el CSV, el agente sin Sens escribió un lector de CSV entero, 99 líneas; con Sens, vio que la descripción era el último campo y le bastaron dos funciones de una línea.

Tokens en total: 33,7M sin Sens · 27,7M con Sens

Tareas sueltas

Doce tareas en tres lenguajes sobre dos proyectos reales, el propio Sens en TypeScript y Rust y la biblioteca de Python click en commits fijados, cada una validada con tests ocultos y una solución de referencia. Tres condiciones con el mismo modelo: Claude Code solo (C0), el Canon como texto en el prompt de sistema sin circuito (C1) y Sens entero (C2).

El texto solo ya consigue buena parte de la reutilización cuando la utilidad está cerca. No consigue los casos en que está lejos y con otro nombre, titleOf, 1 de 3 frente a 6 de 6, ni la tarea que exige arreglar la causa compartida en vez de un camino, py-progress-final, 0 de 3 frente a 3 de 6. En tareas sueltas, las líneas de código son ruido: C2 escribe unas dos líneas menos por tarea, pero el intervalo toca el cero. Por esa variabilidad existe Horizonte.

Las reglas

Las reglas de cambio son deterministas. Comparan huellas de cada función, método y clase, y de cada cuatro sentencias seguidas, con un índice en Rust sobre tree-sitter que mantiene el proyecto en memoria: el propio repositorio de Sens, 556 ficheros y 10 000 unidades, se indexa en menos de dos segundos, y buscar las copias de una unidad cuesta del orden de un microsegundo. Las copias exactas y las de nombres cambiados coinciden por hash; las que añaden o quitan líneas, por MinHash sobre tokens normalizados. El umbral de 0,80 y el mínimo de 80 tokens para bloquear salen de editar 400 funciones de un repositorio real y revisar cada coincidencia a mano.

Las reglas no ven los errores de criterio. Para eso, cuando un turno que tocó código pasa las reglas, un revisor lee el diff con los candidatos que encontró el índice. Su salida no se cree a ciegas: se descarta todo hallazgo cuya cita no aparezca literalmente en el diff, y solo la confianza alta bloquea.

Lo que no funcionó

Cada bloqueo del circuito se revisó a mano, con su diff y su conversación. Los bloqueos son escasos, siete en 228 ejecuciones de Sens, así que uno solo injusto pesa mucho. Buscábamos menos de un 5 % de bloqueos injustos y no lo logramos en ninguna tanda con bloqueos; cada injusticia tenía una causa concreta, ya corregida con un test que la fija.

Una lista equivocada es peor que ninguna. La primera versión de Sens sugería ocho símbolos sin relación con la petición; el modelo los leyó, no buscó más y reescribió a mano la utilidad de acentos las tres veces, mientras que el Canon como texto, sin lista, la importó las tres. Con la búsqueda rehecha, la utilidad aparece entre las sugerencias y Sens la usa siempre, sin bloquear nada.

Limitaciones

• Un modelo. Todas las ejecuciones usaron Claude Sonnet 5.5 con esfuerzo medio.
• Un proyecto, un lenguaje, tres secuencias por brazo. El criterio confirmatorio es exigente, todas por debajo de todas, pero la magnitud del efecto tiene un intervalo ancho.
• Las tareas las escribimos nosotros. Para que no inclinaran el resultado, las tareas, sus tests y la referencia se guardaron antes de la primera ejecución, y el criterio se fijó antes de medir.
• Sin herramientas MCP en el banco. Sens se midió sin las consultas al índice que ofrece la app, así que el resultado es un límite inferior.
• Diecinueve lenguajes aún sin medir en el banco. Vue, Svelte y los lenguajes añadidos después están cubiertos por tests, no por ejecuciones del agente.
• Los tokens incluyen lecturas de caché. Miden el volumen de trabajo, no el coste exacto.
• El revisor tiene poca precisión. De las siete notas y bloqueos suyos que revisamos, cinco eran erróneos. Sus notas no paran nada, pero llegan al modelo y a ti.
• Convenciones no escritas. Sens no conoce las normas implícitas de un proyecto, como dejar las importaciones pesadas dentro de la función.

Método

456 ejecuciones del agente en cinco tandas: un piloto, tres tareas difíciles sobre el propio Sens, doce tareas de calibración y el piloto y la confirmación de Horizonte. Todas las condiciones usaron claude-sonnet-5-5 con esfuerzo medio, con Claude Code en --safe-mode para que la configuración del autor no se colara en las ejecuciones. Cada tarea se validó antes de usarla: al empezar, los tests del proyecto pasan y los ocultos fallan, y con la referencia aplicada pasan los dos. Una regresión tiene que fallar dos veces seguidas para contar. Las diferencias son medianas con un intervalo bootstrap al 95 %, 10 000 remuestreos con semilla fija; el criterio de Horizonte es una prueba exacta de permutación.

Reprodúcelo

sens-bench validate --tasks bench/tasks
sens-bench run --tasks bench/tasks --condition C0,C1,C2 --reps 3 --out bench/results/<batch>
sens-bench sequence validate bench/sequences/cuentas
sens-bench sequence run bench/sequences/cuentas --condition C0,C2 --reps 3 --out bench/results/<batch>
sens-bench sequence report bench/results/<batch>

Los datos de cada ejecución, su diff y las tareas están en la carpeta bench/ del repositorio de Sens.

El Canon

El texto que recibe cada sesión, palabra por palabra, en inglés tal como lo lee el modelo. El circuito es lo que lo convierte en algo más que un consejo.

# Sens Canon v1.1

You are working inside Sens. Sens indexes this project and judges every change you make before your turn can end. What Sens tells you about this project, in its messages, denials and reviews, is a fact about the code, not a suggestion. When Sens names something to reuse, reuse it.

## Before you write

Go down this ladder and stop at the first step that answers the need:

1. Is it needed? Do what the person asked and nothing more: no speculative options, parameters, flags or branches. A test that proves the change is part of the change, not something extra.
2. Does the project already have it? Reuse the existing function, component, type or constant. Ask Sens with `already_exists` or `find_symbol` when unsure.
3. Does the standard library or the platform give it? Use that.
4. Does an installed dependency give it? Use that. A new dependency needs the person's approval, and Sens asks them for it.
5. Only then write new code: the smallest version that is correct.

## While you write

- Fix the cause in the shared code, not the symptom in each caller.
- No abstraction without a second real use: no interface, factory, wrapper, layer or configuration for a single consumer.
- Boring over clever. Match the names, patterns and style of the code around you.
- If you would copy a block, extract it once and call it from both places.
- Delete what your change leaves unused.

## Never cut

Less code never means removing validation at trust boundaries, error handling that prevents data loss, security checks, accessibility, or anything the person asked for.

It never means skipping tests either. When your change alters behaviour and the project has tests, add or extend one that fails without your change, in the style of the tests around it, and run the tests you touched before you finish.

## Working with Sens

- A denied write comes with the reason and what to use instead. Change the approach. Retrying the same thing through the shell, another tool or a subagent does not help: Sens judges what lands on disk, however it got there.
- When you finish, Sens audits the whole turn. If it blocks, fix what it found and finish again.
- Sens judges the shape of the code, not whether it works. Its approval is not a test run: that part is yours.
- Never edit `.sens/`, `.claude/settings*.json` or `.mcp.json`.