aiedit oculta líneas de código concretas al agente de IA: 5 niveles y 857 pruebas

El editor aiedit cierra al agente de IA no archivos, sino líneas concretas, y lo hace a nivel de código, no mediante una petición en el prompt. El proyecto lo ha escrito un desarrollador principiante: aprende Python desde finales de septiembre de 2026 y el código lo escribió Claude bajo su dirección. El resultado son unas 11 mil líneas de código, unas 10 mil líneas de tests y 857 pruebas que pasan tanto en PySide6 como en PyQt6. La licencia es MIT y las llamadas a los modelos son peticiones HTTPS corrientes, sin SDK, así que valen Anthropic, OpenAI y cualquier servidor compatible con OpenAI.

Por qué los archivos ignore no protegen

La idea nació de las debilidades de las herramientas existentes. Cursor admite de forma explícita en su documentación que los comandos de terminal y las herramientas MCP «pueden leer» los archivos de .cursorignore. Cline directamente eliminó .clineignore: según el proyecto, el archivo «nunca se concibió como una prohibición de acceso», y sus autores no quieren dar una falsa sensación de seguridad. Además, esos archivos solo funcionan con archivos enteros. Si se divide el proyecto en «accesible para la IA» y «no accesible», el agente trabaja a ciegas. aiedit mantiene el proyecto entero y cierra solo puntos concretos, como la fórmula de cálculo de precios o el manejo de pagos; el resto lo ve y lo edita el modelo.

Cinco niveles y una cadena de cinco protecciones

Las líneas se cierran directamente en el campo con la numeración de líneas. Los niveles de acceso son estos:

• hidden: el modelo recibe solo una marca del tipo <<ai-hidden:0:5 lines>>, es decir, sabe que ahí hay algo y cuántas líneas ocupa;
• interface: nombres y firmas sin el cuerpo de las funciones (para Python);
• readonly: todo el código es visible, pero se rechaza cualquier edición;
• confirm: todo el código es visible, pero las ediciones requieren la aprobación del autor;
• explain: el modelo explica ese código.

Sobre los niveles actúa una cadena de comprobaciones:

• el modelo no tiene terminal, solo herramientas del editor (leer, buscar, editar), y para él las carpetas cerradas no existen;
• cada edición se comprueba mediante diff; si afecta a una línea cerrada, se rechaza, y nada se escribe en disco sin aprobación;
• los tests y el programa se ejecutan bajo bubblewrap sobre una copia del proyecto en la que el código cerrado físicamente no existe, sin red, sin carpeta personal y sin claves. Ni siquiera volcar todos los archivos en base64 mostraría nada;
• el filtro de salida busca claves, palabras de una lista y líneas cerradas pegadas en el chat, y propone enmascararlas, enviarlas o cancelar;
• un registro local anota qué archivos se han enviado, cuántas líneas están ocultas y cuántos caracteres se han mandado, y cualquier cambio aplicado por la IA se puede revertir.

Aparte existe un pipeline multimodelo: un modelo escribe el código, el propio editor ejecuta los tests en la sandbox y un modelo de otro fabricante busca errores y agujeros. El autor ve los cambios solo después de ese proceso, junto con el resultado real de los tests, y no con un «todo funciona» de palabra.

Cómo la protección rompió el código que escribía el modelo

El autor presenta la comparación con Claude Code sin adornos. En la tarea «una aplicación sencilla en Flask», el código lo escribió Claude Opus 5.5 tanto en aiedit como en Claude Code, pero en aiedit las ediciones las revisaba además GLM 5.

3, y el resultado fue peor. La causa la encontró el registro. El modelo escribió en los tests "password": "secret123", el filtro de secretos lo tomó por una contraseña real y en la sandbox la línea se convirtió en raise NotImplementedError dentro del propio diccionario.

El archivo dejó de ser Python válido. De 22 ejecuciones en la sandbox, 13 fallaron y pytest no llegó ni una sola vez a los tests propiamente dichos. El modelo no entendió la causa y escribió seis archivos de tests más para esquivar el problema.

La corrección: ahora se sustituye solo el valor, "password": "<hidden>", y la sintaxis se conserva. El autor no ha repetido la prueba con modelos reales; el arreglo está confirmado por un test que reproduce el caso. Con los modelos locales tampoco hay regularidad: qwen2.5-coder 7B no mantuvo el formato de llamada a herramientas, y la versión de 32B resolvió las tareas sencillas, pero no terminó la tarea multiarchivo en 14 pasos.

Al revisar el código aparecieron además dos agujeros, ambos cerrados. Si un archivo se renombraba o se copiaba fuera del editor, las zonas se perdían; ahora el código cerrado se reconoce por los hashes de las líneas. Y un proyecto instalado en su propio .venv mediante pip install . quedaba allí completo, de modo que un comando en la sandbox podía leerlo; por eso esas copias ahora están ocultas.

Dónde está el límite de la protección y qué conviene aplicar

El autor enumera las limitaciones con franqueza. El filtro detecta solo lo que puede comparar: patrones de claves, palabras de una lista y líneas cerradas pegadas literalmente; un secreto parafraseado saldrá. Una firma como calc_discount_for_client_x() en la zona interface ya revela el sentido.

Todo lo que no está cerrado va al proveedor del modelo. El editor no reconoce una copia modificada del código cerrado. Los hashes de *.

aimarks.json no llevan sal, por lo que una línea corta como rate = 0.15 se puede deducir por fuerza bruta, y esos archivos no deben publicarse en un repositorio abierto.

La sandbox funciona plenamente en Linux; en macOS es experimental y no se ha probado en un Mac real, y en Windows solo funciona mediante WSL.

La conclusión práctica para los equipos que dejan entrar a agentes en código comercial: la protección debe vivir en la capa de herramientas, no en el texto del prompt. Quitarle el terminal al agente, usar una sandbox con una copia sin secretos, comprobar las ediciones con diff y filtrar la salida dan garantías verificables. El efecto secundario también es visible: cuanto más agresivo es el enmascaramiento, mayor es la probabilidad de romper la validez del código, y los registros de peticiones se convierten en la principal herramienta de depuración. El código está disponible en GitHub y GitFlic, y el autor pide que le envíen formas de eludir la protección.