Volver
Kevin Riedl

10 min de lectura · 23 ago 2026
Última revisión

Siguiente
Se crea en tu dispositivo, sin conectar con Instagram. Copiamos el enlace para su sticker de enlace.

Por qué las ediciones de agentes necesitan identidad semántica: SEMAPRAX en Rust

Un agente de programación debería editar una declaración por su identidad y significado esperado, no por un número de línea posiblemente obsoleto. En SEMAPRAX, los IDs persistentes sobreviven a movimientos normales del código, el HIR comprobado centraliza el significado resuelto y los parches ligados a revisión fallan de forma cerrada si cambia el snapshot. Rust hace explícitas estas diferencias en los tipos del compilador.

Este artículo explica el diseño implementado en el compilador de investigación prealfa. Los mismos límites sirven para motores de refactorización, servicios de compilador y herramientas de agentes que convierten una intención en un cambio revisable.

¿Por qué las líneas y offsets son objetivos frágiles?

Una edición textual suele decir «reemplaza los bytes 418 a 463». Esa dirección describe un snapshot, no la entidad que quería modificar el agente. Un formateador, comentario o edición concurrente puede moverla. Un nombre ayuda, pero scopes, sobrecargas y renombrados también lo vuelven contextual.

El contrato de SEMAPRAX trata el código .spx legible como proyección canónica de Git y ofrece un grafo semántico versionado como interfaz preferida para agentes. Las declaraciones públicas tienen identidades @id persistentes. Las identidades de expresiones son locales a la revisión porque prometer identidad estable para cada nodo transitorio sería deshonesto. El contrato del lenguaje y compilador especifica esta separación.

¿Cómo codifica Rust el límite de identidad?

El HIR no pasa strings sin tipo. Define newtypes separados:

pub struct DeclarationId(String);
pub struct ExpressionId(String);

pub struct ResolvedFunction {
    pub id: DeclarationId,
    // firma, cuerpo y efectos comprobados
}

El ejemplo abreviado refleja los tipos de src/hir.rs en la revisión auditada. Una función que espera un objetivo de declaración persistente no puede recibir por accidente la dirección de una expresión. El compilador exige una conversión explícita o rechaza la operación.

El módulo guarda índices en BTreeMap y relaciones en BTreeSet. Las colecciones ordenadas no bastan para garantizar determinismo, pero eliminan la iteración aleatoria de hashes. Cuando el orden afecta a la ejecución, debe conservarse el orden semántico.

¿Por qué resolver una vez como HIR comprobado?

Si el exportador del grafo y cada backend reconstruyen significado desde la sintaxis, pueden discrepar sobre tipos, ownership o destinos de llamadas. SEMAPRAX resuelve y verifica primero; después, las proyecciones consumen la representación comprobada. El documento de arquitectura y límites de confianza describe la canalización y separa rutas implementadas de autoridad futura.

  1. Analizar el código legible.
  2. Resolver nombres e identidades persistentes como HIR.
  3. Verificar tipos, efectos, reglas de ownership y contratos admitidos por el subconjunto actual.
  4. Proyectar JSON determinista o artefactos objetivo desde semántica comprobada.
  5. Ligar los cambios a la revisión y al objetivo semántico esperado.

El grafo es una proyección del compilador, no otra fuente de verdad. Git continúa revisando código legible mientras el agente recibe contexto estructurado.

¿Qué hace determinista un grafo semántico?

El determinismo pertenece a toda la canalización. IDs estables no ayudan si el orden de aristas cambia entre ejecuciones. SEMAPRAX utiliza índices ordenados, serialización explícita, recorrido acotado y reglas canónicas en su proyección de grafo en Rust.

No se deben ordenar vectores de ejecución para producir un JSON más bonito. El orden de evaluación y limpieza es semántico. La ordenación canónica solo corresponde a conjuntos matemáticamente no ordenados.

¿Cómo limita la evidencia un parche de agente?

Una cápsula de evidencia explica por qué un parche es admisible, pero poseerla no debe conceder escritura. SEMAPRAX separa datos de prueba del componente con autoridad de commit. La ruta adquiere el bloqueo normal, reproduce de forma independiente la evidencia exacta, comprueba el snapshot y solo entonces prepara el candidato. La implementación de evidencia de parches mantiene separadas reproducción y aplicación.

  • Intención obsoleta: el parche era válido para una revisión anterior.
  • Objetivo incorrecto: el texto coincide, pero ahora representa otra declaración.
  • Confianza falsificada: un caller presenta un informe plausible sin reproducir las comprobaciones.

La reproducción independiente no demuestra que una funcionalidad sea prudente. Demuestra algo más estrecho: la propuesta acotada todavía satisface las comprobaciones a las que está ligada.

¿Qué patrones conviene copiar?

  1. Newtypes de dominio: separar entidades persistentes, nodos locales, digests y capacidades en el sistema de tipos.
  2. Un núcleo semántico comprobado: grafos y backends consumen significado resuelto.
  3. Determinismo explícito: especificar orden, serialización, diagnósticos y fallos, y comparar ejecuciones byte a byte.
  4. Ediciones ligadas a snapshots: un objetivo semántico sin digest aún puede desviarse.
  5. Evidencia sin poder: reproducirla dentro del límite de autoridad antes de preparar cambios.
  6. Límites publicados: una matriz evita convertir evidencia de una ruta en una afirmación sobre todos los destinos.

SEMAPRAX aplica el último punto con una matriz de completitud ligada a evidencia.

¿Qué no demuestra SEMAPRAX?

SEMAPRAX v0.2 es investigación experimental prealfa. El repositorio documenta rutas acotadas para C11/Clang nativo y WebAssembly Core, herramientas semánticas deterministas y un subconjunto verificado creciente. No afirma madurez productiva, seguridad de memoria completa, todos los sistemas operativos, ownership completo, interoperabilidad total, un runtime público del Component Model ni autoridad económica real.

Evalúa el proyecto mediante código y evidencia fechada. Empieza por la arquitectura de SEMAPRAX y compara las afirmaciones con la revisión fijada.

¿Cómo se reproduce este recorrido?

git clone https://github.com/wavect/semaprax.git
cd semaprax
git checkout ca339feffcadf77a679abe2f159376287cf2e22c
cargo run -- graph examples/hello.spx

El comando inspecciona la proyección del grafo en la revisión exacta del artículo. Ejecuta las puertas de calidad documentadas antes de considerar una modificación local como evidencia.

Nota editorial: OpenAI Codex ayudó con borrador y traducción. Wavect comprobó afirmaciones y referencias contra el commit ca339fe de SEMAPRAX. El artículo no infiere afirmaciones de rendimiento o seguridad de una salida del modelo.

Reflexiones finales

La edición fiable empieza por nombrar la entidad, la revisión en la que existe y las comprobaciones que deben seguir cumpliéndose. Rust codifica esas diferencias: identidad persistente no es dirección de expresión, HIR comprobado no es sintaxis cruda y evidencia no es autoridad.

SEMAPRAX implementa ese límite de forma experimental. La lección útil hoy es menor que su objetivo a largo plazo: ofrece identificadores semánticos, haz deterministas las proyecciones y falla de forma cerrada cuando cambien el significado o el estado.

Ayuda para IA en producción

Si estás construyendo un producto de IA y te preocupan el coste de inferencia, la arquitectura o la preparación para producción, Wavect ayuda a fundadores a convertir prototipos de IA en sistemas fiables.

Ruta de servicio:

Tu bandeja, sin ruido

Sigue el trabajo que te importa

Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan.

¿Qué quieres recibir?
Elige tus temas

Gratis, doble opt-in y sin píxeles de seguimiento.

Volver
Kevin Riedl

10 min de lectura · 23 ago 2026
Última revisión

Siguiente

Recibe nuevos artículos por correo

Un correo breve cuando publicamos. Gratis y sin seguimiento.

Gratis, doble opt-in y sin píxeles de seguimiento.