No dejamos que la IA corrija su propio examen
Cada cambio pasa por un ciclo fijo, un modelo independiente y pruebas obligatorias antes de llegar a su repositorio.
El harness es un plano de control propietario que construimos y operamos internamente. Convierte la programación con IA en una organización de ingeniería con memoria duradera, revisión independiente y decisiones que siguen siendo suyas. Gobierna también nuestra propia entrega, incluida esta web.
¿Cómo garantiza Oronts que el código escrito con IA sea fiable?
Eliminando los dos atajos que hacen poco fiable la programación agéntica. El modelo que escribe el código nunca lo aprueba, y la conversación nunca es la fuente de verdad. La revisión corre sobre un modelo distinto y el estado vive en archivos duraderos que sobreviven a un reinicio de contexto.
- Un modelo distinto revisa el trabajo, con dos perspectivas adversariales y especialistas activados por superficie modificada
- La reutilización se comprueba contra el grafo real de dependencias, así que no basta con afirmarla
- Terminado significa criterios de aceptación cumplidos y pruebas vigentes, no un único test en verde
- Las decisiones de producto, legales e irreversibles siguen siendo suyas
Cuatro modos de fallo, cuatro mecanismos
La programación agéntica corriente falla de cuatro formas predecibles. El harness responde a cada una con un mecanismo, no con una promesa.
| Modo de fallo | Lo que ocurre en realidad | El mecanismo |
|---|---|---|
| Genera en lugar de hacer ingeniería | Aparece código nuevo aunque el framework, la biblioteca estándar o el propio repositorio ya resolvían el problema. | Una escalera de reutilización que se detiene en el primer peldaño correcto, más un verificador que rechaza cualquier plan que cite un paquete o una ruta inexistente. |
| Olvida | El contexto se llena, la conversación se compacta y el agente pierde el objetivo y le pide que se lo explique otra vez. | Los archivos de memoria duradera son la fuente de verdad. La reanudación se dispara al arrancar y tras cada compactación, y continúa la siguiente acción exacta. |
| Corrige su propio examen | El mismo modelo que escribió el código lo revisa y lo aprueba. | Revisa un modelo distinto, más dos perspectivas adversariales independientes y especialistas. Los hallazgos se concilian por evidencia y se vuelven a ejecutar en limpio tras cada corrección. |
| Entrega el camino feliz | Un test en verde, sin casos negativos, sin prueba en ejecución, y se da por terminado. | Terminado significa: aceptación cumplida, pruebas proporcionales al riesgo y vigentes frente al estado real de Git, revisores sin hallazgos y estado sincronizado. |
Cómo es realmente una ejecución
Dos paneles de una sesión real. A la izquierda, el ciclo informa de cada etapa según ocurre. A la derecha, el observador de solo lectura deriva una instantánea de los archivos de memoria y del Git vivo, y la imprime.
Un hallazgo devuelve el trabajo a la verificación en lugar de empujarlo a un commit. La ejecución se detiene en una autorización en vez de publicar.
$ node .claude/tools/oronts-status.cjs --watch
- HEAD
- ad2fcd4 · tree: clean
- active
- T-008
- next
- German barge-in
- gates
- G-004
- TASKS
- 12 total · active 1 · ready 4 · completed 7
- BLOCKERS
- 1
- FINDINGS
- crit 0 · high 0 · med 2 · low 5 (2 open of 7)
El observador nunca escribe un archivo ni modifica Git. Borrarlo dejaría intacto el ciclo de ingeniería.
Una cadencia, esfuerzo proporcional a la consecuencia
Toda tarea sustancial sigue la misma cadencia. Una errata recibe una comprobación puntual. Una condición de carrera en pagos, una migración o una ruta de autorización recibe debate de diseño, revisión especializada y prueba real en ejecución. La profundidad viene de la consecuencia, nunca del número de líneas cambiadas.
Los hallazgos devuelven el trabajo a la verificación, no lo empujan hacia un commit. El ciclo solo se cierra cuando los revisores no encuentran nada.
Detenerse en el primer peldaño que lo resuelve bien
El harness optimiza el mínimo de código nuevo necesario para un sistema correcto, no la máxima programación visible. Un verificador determinista fundamenta cada afirmación de reutilización en el grafo real de dependencias, de modo que un plan que cite un paquete ausente falla antes de que empiece la implementación.
- 1¿Esto necesita existir siquiera?
- 2¿El repositorio ya lo hace?
- 3¿Lo hace la biblioteca estándar?
- 4¿Es nativo del framework o de la plataforma?
- 5¿Lo hace una dependencia ya instalada?
- 6¿Existe un punto de extensión disponible?
- 7Solo entonces: el mínimo de código nuevo
Un motor, tres preocupaciones, una autorización
Puntos de entrada con nombre alimentan un único motor. El motor impulsa razonamiento, determinismo y durabilidad en paralelo, y todo lo irreversible sale por una puerta que le pertenece a usted.
Puntos de entrada
Lenguaje natural, una skill con nombre o una campaña autónoma acotada.
- Skills33
- Objetivo
- Campaña
Motor
Un único archivo legible atiende los eventos del ciclo de vida: reconciliar Git, inyectar estado, dosificar el esfuerzo, imponer autorizaciones. Sin servicios ocultos ni procesos en segundo plano.
- engine.cjs1
- Reconciliación Git
- Reanudación
Razonamiento
Revisores independientes y despliegues deterministas con varios agentes.
- Agentes de revisión21
- Workflows5
Determinismo
Comprobaciones que pasan o fallan sin un modelo de por medio.
- Herramientas24
- Reglas37
Durabilidad
Estado que sobrevive a la conversación y a cualquier reinicio de contexto.
- Archivos de memoria15
- Registros encadenados
Su autorización
Las acciones irreversibles y comerciales se detienen aquí en todos los modos de permiso, incluidas las ejecuciones desatendidas.
- Push y publicación
- Release y despliegue
- Operaciones destructivas
- Almacenes de secretos
El plano de control se copia dentro de un repositorio y lo gobierna. Se distribuye genérico; cada proyecto rellena su propio estado.
Un modelo distinto, no una segunda opinión de la misma mente
Cuatro preguntas de revisión independientes y un mecanismo de decisión. Los hallazgos se concilian por evidencia, no por mayoría. Un bloqueante correcto pesa más que diez aprobaciones. Tras cada corrección las revisiones se repiten en limpio, porque un revisor que toca el árbol invalida la huella anterior.
| Instancia revisora | La pregunta que plantea |
|---|---|
| Revisión entre modelos | ¿Qué falla que el modelo que escribió, siendo la misma mente, puede haber pasado por alto? |
| Perspectiva de corrección | ¿Esto puede fallar, corromper, filtrar, entrar en condición de carrera o violar el comportamiento esperado? |
| Perspectiva de mantenibilidad | ¿Es comprensible, mínimo, sin duplicación y está en el lugar correcto? |
| Especialistas activados | ¿Es correcto para seguridad, base de datos, contrato de API, interfaz, infraestructura o IA? |
| Instancia de arquitectura | ¿Hacia dónde va una bifurcación de diseño real? Decide, no vota. |
Los especialistas se activan por superficie modificada, no de forma general por proyecto. Una migración llama al revisor de base de datos, un límite de autorización a seguridad y un flujo distribuido a concurrencia.
Cuando el revisor entre modelos no está disponible, se registra como no disponible y se añade otra perspectiva independiente. El harness nunca informa de una revisión que no ocurrió.
Qué prevalece sobre qué
La jerarquía es explícita y sobrevive a un cambio de modelo. Un test en verde es autoridad sobre el comportamiento observado. Un revisor es autoridad sobre si ese comportamiento es la invariante correcta. Ninguno sustituye al otro.
- 1Tests ejecutables y evidencia en ejecución
- 2Revisión independiente entre modelos
- 3Revisión del mismo modelo
- 4Razonamiento de la instancia principal
- 5Simple afirmación
La compactación es un punto de control, no un reinicio
El problema más difícil en ejecuciones autónomas largas es el contexto. Se llena, la conversación se resume y un agente ingenuo olvida el objetivo y se detiene. El harness trata el resumen como un punto de control. Archivos duraderos guardan el objetivo, la tarea actual, la siguiente acción exacta, las decisiones, los bloqueos, la evidencia y la historia. La conversación puede descartarse; el estado permanece.
Estado, no conversación
Los archivos de memoria son la fuente de verdad. La transcripción es prescindible.
Reanudación al arrancar y al compactar
Un hook reconcilia Git y reinyecta el estado vivo, la tarea activa, sus criterios de aceptación y las autorizaciones abiertas.
Sus instrucciones sobreviven
Las indicaciones se registran de forma determinista, así que no se pierden las peticiones puntuales que nunca llegaron a ser una tarea.
Continúa en lugar de esperar
Tras reconciliar, retoma la siguiente acción registrada sin volver a pedir un contexto que ya posee.
Skills, plugins y servidores MCP
Las capacidades viven en tres capas para que el sistema siga siendo cohesionado y rápido en lugar de un paquete de herramientas solapadas. Primero la capacidad del núcleo, un especialista solo ante profundidad real, nunca un duplicado de lo que el núcleo ya hace.
33 puntos de entrada con nombre al ciclo
Una skill determina con qué profundidad entra una tarea en la cadencia. Los nombres son identificadores propios del producto y no cambian en ningún idioma.
Iniciar y encaminar
- start
- route
- triage
- plan
- estimate
- capabilities
Construir
- implement
- fix
- refactor
- ui
- api-change
- database-change
- ai-change
- infrastructure-change
- dependency-change
Asegurar
- review
- verify
- audit
- security-review
- red-team
- gdpr
- debate
Operar y entregar
- autopilot
- campaign
- memory
- doctor
- handoff
- finish
- release
- present
- team
- adopt
Incluida
- excalidraw-diagram
Plugins habilitados
Seis plugins forman la espina dorsal de razonamiento y revisión. Están integrados en el ciclo, no ofrecidos como extras opcionales.
- superpowers
Depuración sistemática, método guiado por tests, planificación y verificación, invocados en cada tarea para que depurar sea reproducir y corregir, no adivinar.
- codex
Un modelo independiente y genuinamente distinto para la revisión. La revisión del mismo modelo comparte los mismos puntos ciegos; otro modelo rompe esa correlación.
- andrej-karpathy-skills
Salvaguardas frente a errores habituales: suponer en lugar de preguntar, sobreingeniería y diffs desbordados.
- impeccable
Anclaje de producto y diseño para el trabajo de interfaz, de modo que las pantallas respondan a una tarea real y no a una salida genérica.
- claude-mem
Memoria entre sesiones, complementaria a la del repositorio y nunca por encima de lo que dice Git.
- claude-obsidian
Integración opcional con una base de conocimiento para contexto de negocio y dominio duradero.
Cada plugin habilitado carga sus descripciones en todas las sesiones, así que el conjunto habilitado se mantiene deliberadamente pequeño.
Servidores MCP, invocados a demanda
Los conectores de datos están cableados solo a operaciones de lectura y búsqueda, de modo que una sesión autónoma no puede modificar esos sistemas. La automatización de navegador sí puede actuar sobre una página, así que cualquier efecto externo queda sujeto a su autorización en vez de ejecutarse en silencio.
- Context7lectura
Documentación de bibliotecas y frameworks correcta para la versión instalada, en lugar de adivinar por los datos de entrenamiento.
- GitHublectura
Hechos actuales sobre dependencias, contexto de pull requests e incidencias, y código fuente aguas arriba.
- Playwrightnavegador
Prueba real en navegador para recorridos de interfaz, de forma que una captura complemente la prueba en vez de sustituirla.
- filesystemlectura
Acceso a archivos acotado y estructurado para investigar en árboles grandes.
- memorylectura
Un grafo de memoria complementario, subordinado al estado del repositorio.
- sequential-thinkingrazonar
Razonamiento estructurado en varios pasos para un problema genuinamente difícil.
- opentabsnavegador
Acceso autenticado al navegador mediante su propia sesión, usado con parquedad y autorizado para cualquier escritura.
Especialistas por proyecto
Expertos de lenguaje, análisis estático real y herramientas de dominio estrecho se instalan por repositorio en lugar de fijarse en la configuración compartida, porque cada plugin habilitado consume contexto en todas las sesiones.
En trabajo crítico de seguridad la brecha real frente a la revisión por modelo es el análisis real: un motor de análisis estático más un escáner de dependencias, contenedores e infraestructura corren junto al revisor de seguridad, porque un analizador detecta clases que una revisión por modelo pasa por alto.
Qué contiene el plano de control
El harness se distribuye genérico e independiente del proyecto. Se copia dentro de un repositorio y cada proyecto rellena su propio estado. Un único archivo de motor legible gobierna el ciclo de vida. No hay servicios ocultos ni procesos en segundo plano.
| Capa | Cantidad | Función |
|---|---|---|
| Reglas de ingeniería | 37 | Estándares siempre cargados, más paquetes de lenguaje y superficie |
| Skills | 33 | Puntos de entrada con nombre al ciclo |
| Agentes de revisión | 21 | Revisores independientes, especialistas e investigadores |
| Workflows | 5 | Despliegues deterministas con varios agentes |
| Herramientas deterministas | 24 | Autocomprobaciones, evaluadores, sincronización y observador de estado |
| Archivos de memoria | 15 | Estado duradero que sobrevive a la compactación |
| Documentos de referencia | 36 | Especificaciones de arquitectura y protocolo |
| Plantillas | 34 | Registros de decisión, contratos, runbooks, modelos de amenaza |
| Motor | 1 | Un único archivo legible que atiende los eventos del ciclo de vida |
Medido sobre el repositorio el 5 de septiembre de 2026. El harness es un producto propietario de Oronts y no está publicado. Lo recorremos en directo en una llamada o bajo acuerdo de confidencialidad.
Lo que nunca hace por su cuenta
La autonomía está acotada por diseño. Las decisiones irreversibles y comerciales se deniegan en la capa de permisos en todos los modos, incluidas las ejecuciones desatendidas, y no pueden habilitarse con una instrucción en la conversación.
- Semántica de producto, visibilidad y política de retención
- Licencias, precios y contratos públicos que rompen compatibilidad
- Acceso a producción, despliegue y publicación de versiones
- Publicación de paquetes, force push y operaciones destructivas de git
- Acciones destructivas de infraestructura
- Lecturas de almacenes de credenciales y secretos
- Cualquier reducción de un control de seguridad
Cuando debe preguntar, pregunta con evidencia: las opciones, las contrapartidas, un análisis, una objeción del modelo independiente y una recomendación. La decisión es suya; la investigación no es su trabajo.
Lo que no afirmamos
Los límites conocidos son hechos de ingeniería, no algo que esconder. Un sistema empresarial no es el que carece de incertidumbre. Es aquel en el que la incertidumbre es conocida, acotada, visible y respaldada por evidencia proporcional a sus consecuencias.
Empresarial no significa arquitectura máxima
El harness contiene un proceso que deriva la arquitectura adecuada por proyecto, no una pila universal. Una utilidad interna pequeña y una plataforma multiinquilino reciben rigor distinto del mismo sistema.
Un proceso sano no es un producto entregado
Un harness en verde demuestra que el proceso de ingeniería está sano. Su producto llega a producción cuando sus propias puertas están en verde: cifras de carga, prueba de migración y reversión, tests de aislamiento y una revisión de seguridad.
El verificador de reutilización tiene un límite
Es una comprobación sólida de integridad referencial contra manifiestos y archivos, no un resolutor completo de paquetes para todos los ecosistemas.
La calidad arquitectónica es en parte criterio
Se respalda con revisión independiente, no se vende como garantía automatizada.
Por qué esto importa para usted, no para nosotros
Código que puede defender en una revisión
Cada cambio lleva consigo sus criterios de aceptación, su evidencia y los veredictos que lo aprobaron.
Registro de decisiones, no tradición oral
Las decisiones de diseño quedan escritas con sus alternativas y su razonamiento, de modo que su equipo hereda el porqué y no solo el qué.
La velocidad como consecuencia
El rigor es el objetivo. La velocidad surge de no reconstruir lo que ya existe y de no volver a discutir lo ya decidido.
Propiedad total en la entrega
El plano de control dirige el trabajo. El código, las decisiones y la documentación son suyos.
Preguntas que hacen los responsables técnicos
Véalo funcionar sobre un problema real
Traiga un cambio que normalmente le pondría nervioso. Recorremos cómo lo aborda el ciclo, qué evidencia produce y en qué punto se detendría para preguntarle.
Con quién trabaja
Niveles de compromiso
Oronts trabaja con equipos serios que necesitan entrega senior, no externalización de bajo coste.
- Production Pilot
- desde 25k EUR
- Proyectos de software e IA a medida
- desde 50k EUR
- Retainers técnicos continuos
- desde 15k EUR/mes
El precio exacto depende del alcance, la responsabilidad, la velocidad de entrega, el tamaño del equipo, las integraciones, las expectativas de soporte y el riesgo de producción.