2026-07-28

El lenguaje como arquitectura

Estás ayudando a desarrollar una tesis interdisciplinaria rigurosa y una metodología práctica de diseño de software asistido por máquina, titulada provisionalmente:

El lenguaje como arquitectura

El trabajo tiene dos objetivos inseparables:

1. Desarrollar una explicación teórica defendible de cómo el lenguaje, la semántica, la ontología, la estructura, las especificaciones, los tipos, las pruebas y las restricciones participan en la arquitectura de software. 2. Derivar de esa teoría un mejor proceso de diseño y desarrollo de software asistido por máquina, para sistemas que cada vez más se diseñan mediante lenguaje natural y modelos de lenguaje en vez de por procesos tradicionales exclusivamente humanos.

No empieces escribiendo la tesis.

Primero investiga, cuestiona, formaliza, compara y pon a prueba la teoría.

No optimices por estar de acuerdo con las ideas propuestas.

Identifica dónde la teoría está establecida, dónde extiende ideas existentes, dónde es meramente analógica, y dónde puede representar una síntesis novedosa.

---

# 1. EL CAMBIO HISTÓRICO

Parte de esta transición tecnológica.

La ingeniería de software tradicional seguía aproximadamente:

intención humana
→ interpretación humana
→ requisitos
→ arquitectura
→ implementación
→ pruebas
→ revisión
→ operación

Cada transformación era cara.

El trabajo humano imponía una fricción sustancial.

La ingeniería asistida por modelos de lenguaje permite cada vez más que:

lenguaje natural
→ interpretación del modelo
→ especificación
→ arquitectura
→ plan
→ código
→ pruebas
→ documentación
→ acciones de despliegue

ocurra extremadamente rápido.

Esto ofrece enormes beneficios de productividad.

También cambia el modo de falla dominante.

Cuando crear artefactos se vuelve barato, crear:

también se vuelve barato.

Investiga esta proposición:

El desarrollo asistido por modelos de lenguaje cambia la restricción principal de ingeniería: del costo de producir artefactos de software hacia el costo de mantener coherencia semántica entre artefactos producidos rápidamente.

Determina si esto representa un cambio sustancial en la economía de la ingeniería de software.

---

# 2. ENTROPÍA GENERATIVA

Desarrolla y evalúa críticamente el concepto candidato:

Entropía generativa

Definición candidata:

La entropía generativa es la acumulación de divergencia semántica introducida cuando transformaciones probabilísticas baratas convierten repetidamente la intención en especificaciones, arquitectura, implementaciones, pruebas, documentación e interpretaciones posteriores.

Cadena de falla candidata:

intención humana
      ↓
interpretación del modelo
      ↓
especificación
      ↓
arquitectura
      ↓
implementación
      ↓
pruebas
      ↓
documentación
      ↓
interpretación futura del modelo

En cada transformación se pueden introducir pequeñas desviaciones semánticas.

Con el tiempo:

intención ≠ especificación

especificación ≠ arquitectura

arquitectura ≠ implementación

implementación ≠ pruebas

pruebas ≠ comportamiento pretendido

documentación ≠ sistema real

Y sin embargo todos los artefactos pueden seguir siendo internamente plausibles.

Investiga si algún concepto existente ya describe este fenómeno.

Compáralo con:

No uses el término entropía de forma meramente retórica.

Determina si se puede definir operacionalmente o si debe reemplazarse por un concepto más preciso.

---

# 3. PUDRICIÓN SEMÁNTICA

Distingue varias formas candidatas de degradación de un sistema asistido por máquina.

Pudrición semántica

Los términos dejan de conservar significados estables.

Ejemplo:

"primitive"

puede significar sucesivamente:

tipo básico
pieza compartida
mecanismo reutilizable
abstracción de dominio
bloque de construcción arquitectónico

sin que ninguna decisión explícita haya cambiado su definición.

Deriva de especificación

Una suposición del modelo se vuelve implementación, luego documentación, y después se confunde con un requisito original.

requisito
→ suposición
→ implementación
→ documentación
→ requisito futuro

Deriva arquitectónica

Cambios localmente razonables violan poco a poco la composición pretendida del sistema.

Pudrición ontológica

Conceptos distintos se colapsan en uno, o proliferan conceptos redundantes.

Ejemplo:

Agreement
Contract
Subscription
Entitlement
Order

pueden ir perdiendo sus fronteras semánticas explícitas.

Pudrición del oráculo

Las pruebas codifican cada vez más el comportamiento de la implementación en lugar de la semántica pretendida.

Pudrición del proceso

Los agentes descubren atajos localmente exitosos que hacen que el proceso real de desarrollo diverja del proceso pretendido.

Amplificación de la confianza

Una atribución incorrecta adquiere:

lo que hace el error cada vez más difícil de reconocer.

Determina si estas categorías son útiles y medibles.

---

# 4. TESIS CENTRAL

Evalúa esta tesis candidata:

El lenguaje se vuelve arquitectura cuando las distinciones semánticas expresadas mediante el lenguaje adquieren representación computacional duradera y restringen qué entidades pueden existir, cómo pueden relacionarse, qué transformaciones pueden ocurrir y qué comportamiento se permite.

Evalúa esta tesis de proceso, más fuerte:

La ingeniería de software asistida por máquina debería formalizar progresivamente el significado humano en vocabulario controlado, ontología, gramática arquitectónica, artefactos tipados, semántica ejecutable y restricciones impuestas mecánicamente.

Evalúa esta tesis operativa:

La inteligencia debería concentrarse en las fronteras semánticas no resueltas. Una vez que el significado se ha establecido y verificado lo suficiente, el comportamiento repetido debería compilarse en mecanismos deterministas siempre que sea práctico.

Y evalúa esta tesis económica:

Conforme el costo generativo se acerca a cero, el control semántico se vuelve más importante que la producción de artefactos; por tanto, un proceso de desarrollo asistido por máquina debería minimizar la fricción en las transformaciones deterministas y aumentar el escrutinio en las transformaciones que alteran el significado.

Determina si estas forman:

---

# 5. EL PRINCIPIO CENTRAL DE DISEÑO

Investiga esta formulación concisa:

Haz que ejecutar salga barato; haz que los cambios de significado sean explícitos.

Desarróllala de forma más precisa:

Un proceso de desarrollo asistido por máquina debería minimizar la fricción donde la semántica ya está resuelta y maximizar la verificación donde ocurren la interpretación semántica, la atribución, la elección arquitectónica o los cambios de política.

Analiza qué cuenta como:

Determina cómo podría distinguirlas un arnés de desarrollo.

---

# 6. OBSERVACIÓN CONTRA ATRIBUCIÓN

Trata esta distinción como fundacional.

Observación

Un hecho medible mecánicamente.

Ejemplos:

el rectángulo de un elemento
una marca de tiempo
un archivo existe
un número de columnas
un nivel de encabezado
una respuesta HTTP
una transición en la base de datos
una mutación del sistema de archivos
state_before
state_after

La observación responde:

¿Qué existe o qué cambió?

Atribución

Una asignación semántica.

Ejemplos:

«Este es el control de búsqueda.»

«Esta transición representa paginación.»

«Esta entidad es una Parte.»

«Esta relación representa propiedad.»

«Este requisito crea una restricción de aislamiento de inquilino.»

La atribución responde:

¿Qué significa esto?

Investiga si la atribución no resuelta es uno de los lugares principales donde la inteligencia de máquina es legítimamente necesaria.

Distingue continuamente:

significado contenido en la estructura

significado inferido de la estructura

significado asignado a la estructura

significado impuesto a través de la estructura

---

# 7. LA FRONTERA DE LA INTELIGENCIA

Pon a prueba esta frontera candidata:

SIGNIFICADO DESCONOCIDO
      ↓
criterio / inteligencia

SIGNIFICADO CONOCIDO
      ↓
se prefiere un mecanismo determinista

Evalúa el principio:

No gastes criterio probabilístico una y otra vez en comportamiento cuya semántica ya se ha establecido y puede codificarse de forma determinista.

Investiga las excepciones.

La meta no es eliminar la IA.

La meta es colocar la inteligencia donde tiene el mayor valor semántico.

---

# 8. TRINQUETES SEMÁNTICOS

Desarrolla y pon a prueba el concepto candidato:

Trinquete semántico

Principio candidato:

Una vez que una interpretación se ha verificado lo suficiente, represéntala en el nivel más fuerte que sea práctico, para que los agentes futuros no puedan reinterpretarla a la ligera.

Progresión posible:

concepto desconocido
→ interpretación explícita
→ vocabulario controlado
→ ontología
→ representación tipada
→ invariante
→ prueba ejecutable
→ regla estática
→ regla en tiempo de ejecución
→ imposición en integración continua

El trinquete debería hacer que:

desconocido → resuelto

sea fácil cuando la evidencia lo permita,

mientras hace que:

resuelto → ambiguo por accidente

sea difícil.

Investiga los predecesores teóricos de este concepto.

Determina cuándo el trinquete semántico se vuelve rigidez dañina o formalización prematura.

---

# 9. LA ESTRUCTURA COMO SIGNIFICADO

Investiga esta proposición con cuidado:

El contenido describe qué dice algo; la estructura puede aportar evidencia sobre qué significa un sistema con ello.

Usa ejemplos:

enter
+ submit
+ cambio del conjunto de resultados
→ búsqueda

invoke
+ avance de la ventana de la colección
→ paginación

toggle
+ inversión de un estado booleano
→ interruptor de estado

Y el patrón más general:

estado
→ affordance
→ operación primitiva
→ transición observada
→ capacidad semántica

Determina cuándo estas relaciones son:

No afirmes simplemente que la estructura contiene significado de forma inherente.

---

# 10. FRAGMENTACIÓN ESTRUCTURAL

Analiza la fragmentación estructural a la vez como:

Definición candidata:

Un fragmento estructural es una representación mínima que contiene los hechos estructurales suficientes para una inferencia semántica de tipo estrecho, y que excluye el contenido de origen innecesario.

Los ejemplos pueden conservar:

conteos
tipos
niveles de encabezado
identidades opacas
categorías de enunciado
conteos de nulos
conteos de valores distintos
transiciones de estado
clases de affordance
relaciones

excluyendo el contenido original.

Estudia implementaciones como:

Determina si los fragmentos estructurales funcionan como:

---

# 11. MEDIACIÓN SEMÁNTICA

Usa esto como un principio arquitectónico mayor:

El software local debería poder observar, analizar, navegar, probar, transformar u operar sobre datos privados, revelándole a la IA únicamente la representación semántica más pequeña necesaria para resolver un problema estrechamente definido.

Proceso candidato de proyección semántica:

1. Observar localmente.
2. Normalizar de forma determinista.
3. Aplicar las reglas ya conocidas.
4. Aislar el residuo sin coincidencia.
5. Fijar la pregunta semántica exacta.
6. Definir el tipo de respuesta permitido.
7. Quitar la información que no pueda afectar esa respuesta.
8. Pedir la inferencia.
9. Verificar localmente.
10. Preservar la interpretación aceptada.
11. Compilar el comportamiento repetido en mecanismos deterministas.

Investiga las relaciones con:

---

# 12. AMORTIZACIÓN SEMÁNTICA

Pon a prueba este principio candidato:

El costo de la inteligencia debería escalar principalmente con el número de formas semánticas distintas sin resolver, y no con el número de instancias repetidas.

Ejemplo:

Un millón de registros podría exponer solamente:

registro
continuación
terminación

como estructuras semánticas distintas.

Una vez entendidas:

forma
→ regla verificada
→ reproducción determinista

Desarrolla el concepto de:

amortización semántica

Investiga el trabajo previo antes de reclamar novedad.

---

# 13. AUTORÍA, OPERACIÓN Y REPARACIÓN

Investiga una arquitectura de tres fases.

Autoría

desconocido
→ observar
→ atribuir
→ verificar
→ fixture
→ regla
→ prueba
→ implementación

La inteligencia es legítima.

Operación

observar
→ reconocer una estructura conocida
→ aplicar la regla conocida
→ actuar
→ capturar la consecuencia

Se prefiere la ejecución determinista.

Reparación

una regla conocida falla
→ detectar el desajuste
→ aislar el delta semántico
→ exponer el residuo mínimo
→ reatribuir
→ verificar
→ parchar la regla
→ retomar la operación determinista

Estudia si el desarrollo de software asistido por máquina sigue él mismo este patrón.

---

# 14. EL DESARROLLO DE SOFTWARE COMO ADQUISICIÓN DE CONOCIMIENTO

Investiga:

desconocido
→ observar
→ atribuir
→ formalizar
→ falsar
→ verificar
→ codificar
→ imponer
→ reutilizar

Cuando la realidad cambia:

desajuste
→ aislar el delta
→ reatribuir
→ revisar el conocimiento

Compáralo con:

Determina si el desarrollo de software bajo este marco es en parte un proceso de convertir incertidumbre semántica en conocimiento determinista reutilizable.

---

# 15. LA ONTOLOGÍA ANTES QUE LA ARQUITECTURA

Antes de decidir cómo debería implementarse algo, determina qué clase de cosa es.

Categorías ontológicas candidatas:

Archetype
Primitive
Relationship
Policy
Process
Framework
Component
Application
Artifact
Evidence

Estas no deben tratarse automáticamente como niveles de una jerarquía.

Pueden representar clases distintas de entidad arquitectónica.

---

# 16. Pieza de biblioteca CONTRA ARQUETIPO

Desarrolla la distinción:

Primitive:
¿qué capacidad reutilizable existe?

Archetype:
¿qué clase recurrente de cosa con significado existe?

Ejemplos candidatos:

Party          → Archetype
Agreement      → Archetype
Place          → Archetype
Transaction    → Archetype

Search         → Primitive
Authorization  → Primitive
Persistence    → Primitive
Audit          → Primitive

TenantIsolation → Policy
Fulfillment     → Process

Pon a prueba esta terminología contra el uso establecido en ingeniería de software.

---

# 17. ONTOLOGÍA ARQUITECTÓNICA

Determina si categorías como:

Archetype
Primitive
Relationship
Policy
Process

pueden relacionarse formalmente.

Ejemplos:

Archetype USES Primitive

Archetype PARTICIPATES_IN Relationship

Policy CONSTRAINS Archetype

Policy CONSTRAINS Process

Process TRANSFORMS state

Application COMPOSES Archetypes + Primitives + Policies + Processes

Investiga si estas relaciones proveen una ontología arquitectónica útil.

---

# 18. SEMÁNTICA BASADA EN ESTÁNDARES

Evita inventar mecanismos de ontología sin necesidad.

Evalúa:

SKOS

Vocabulario controlado:

términos preferidos
términos alternativos
conceptos más amplios / más estrechos

RDF

Representación en grafo:

sujeto
predicado
objeto

OWL 2

Semántica de ontología:

clases
propiedades
especialización
equivalencia
restricciones
inferencia

SHACL

Validación de restricciones:

propiedades requeridas
cardinalidad
relaciones válidas
formas arquitectónicas

SPARQL

Consultas semánticas.

Estudia una pila potencial:

lenguaje natural

      ↓

SKOS
vocabulario controlado

      ↓

RDF / OWL
ontología

      ↓

SHACL
composiciones semánticas válidas

      ↓

tipos de Rust
representaciones de programa

      ↓

arnés de proceso
reglas de transición de estado

      ↓

pruebas / comprobadores / integración continua
imposición ejecutable

Da cuenta explícitamente de la suposición de mundo abierto de OWL.

OWL no debe tratarse como un sistema completo de validación de software con suposición de mundo cerrado.

---

# 19. LÉXICO, TAXONOMÍA, ONTOLOGÍA, GRAMÁTICA, ARQUITECTURA

Formalízalos por separado.

Definiciones candidatas:

Léxico
    ¿Qué palabras usamos?

Taxonomía
    ¿Cómo se clasifican los conceptos?

Ontología
    ¿Qué clases de cosas existen y cómo se relacionan?

Gramática arquitectónica
    ¿Qué composiciones semánticas son válidas?

Arquitectura
    ¿Cuál composición válida ha elegido este sistema?

Proceso
    ¿Qué transformaciones se permiten?

Esquema de artefactos
    ¿Cómo se representa el estado del proceso?

Semántica ejecutable
    ¿Qué comportamiento operacionaliza el significado?

Imposición mecánica
    ¿Qué impide las violaciones?

Investiga si gramática arquitectónica es terminología novedosa o corresponde a conceptos establecidos.

---

# 20. LA ARQUITECTURA COMO COMPOSICIÓN RESTRINGIDA

Evalúa:

La arquitectura de software es la composición restringida de entidades, capacidades, relaciones, políticas y procesos identificados semánticamente.

Compara esto con las definiciones establecidas de arquitectura de software.

Determina dónde esta definición es útil y dónde es incompleta.

---

# 21. COMPRESIÓN SEMÁNTICA

Estudia términos de dominio como:

tenant-scoped
immutable
idempotent
auditable
execution-tier

Una frase pequeña puede codificar numerosas consecuencias arquitectónicas.

Ejemplo:

tenant-scoped

puede implicar:

propiedad
filtrado de consultas
autorización
requisitos de almacenamiento
requisitos de registro
requisitos de prueba
requisitos de aislamiento

Investiga:

La terminología arquitectónica controlada es una forma de compresión semántica.

Determina cuándo la compresión se vuelve ambigüedad.

---

# 22. COMPILACIÓN SEMÁNTICA

Pon a prueba si el desarrollo asistido por máquina se puede modelar útilmente como:

intención humana
→ interpretación explícita
→ ontología
→ decisiones arquitectónicas
→ especificación tipada
→ contrato de aceptación
→ plan de implementación
→ código
→ capacidad verificada

Compáralo con la arquitectura de un compilador:

fuente
→ análisis sintáctico
→ análisis semántico
→ representación intermedia tipada
→ representación intermedia optimizada
→ ejecutable

Determina dónde la analogía funciona y dónde el criterio no determinista, humano o del modelo, la rompe.

Investiga si la compilación de conocimiento es un precedente más apropiado que la teoría de compiladores ordinaria.

---

# 23. REPRESENTACIÓN INTERMEDIA SEMÁNTICA

Pregunta:

¿Cuál debería ser la representación intermedia semántica de la ingeniería de software asistida por máquina?

Las posibilidades incluyen:

Una candidata:

HumanIntent
Requirement
Observation
SemanticAttribution
Archetype
Primitive
Relationship
Policy
ArchitectureDecision
AcceptanceCriterion
TestOracle
ImplementationPlan
WorkerPacket
VerificationEvidence
ReviewFinding

Determina si esta representación semántica compartida puede evitar que el significado se reconstruya una y otra vez a partir de la prosa.

---

# 24. ARTEFACTOS TIPADOS

Estudia los artefactos de desarrollo como interfaces entre etapas cognitivas.

Ejemplo:

WorkerPacket {
    task
    ontological_kind
    process_state
    cognitive_role
    allowed_judgment
    scope
    architecture
    acceptance_contract
    tool_authority
    stop_conditions
}

Pregunta:

¿Pueden los artefactos tipados reducir la deriva semántica entre el arquitecto, el planeador, quien implementa, quien prueba, quien revisa y los agentes futuros?

Es preferible estructurar los artefactos existentes a proliferar documentos nuevos.

---

# 25. LAS PRUEBAS COMO MEMORIA SEMÁNTICA

Investiga:

Las pruebas pueden preservar interpretaciones semánticas verificadas como comportamiento ejecutable.

Ejemplo:

atribución semántica
«Esta transición de estado significa paginación»

        ↓

fixture

        ↓

oráculo que falla

        ↓

implementación

        ↓

oráculo que pasa

Estudia:

Distingue la preservación del comportamiento de la prueba de corrección semántica.

---

# 26. ORÁCULOS INDEPENDIENTES

Examina críticamente el ciclo ingenuo:

la IA escribe el código
la IA escribe las pruebas
la IA corre las pruebas
la IA declara el éxito

Esto puede ser un solo actor epistémico confirmándose a sí mismo.

Compáralo con:

requisitos
      ↓
oráculo independiente

arquitectura
      ↓
implementación

implementación
      ↓
ejecución mecánica de pruebas

resultados
      ↓
verificación independiente

Investiga si la independencia mejora materialmente la confiabilidad.

---

# 27. EL ARNÉS DE DESARROLLO

El arnés del proceso, no una conversación con un modelo, debería ser dueño del estado del desarrollo.

Máquina de estados candidata:

INTENT
→ OBSERVED
→ SEMANTICALLY_RESOLVED
→ SPECIFIED
→ ARCHITECTED
→ ORACLED
→ PLANNED
→ EXECUTABLE
→ IMPLEMENTED
→ VERIFIED
→ REVIEWED
→ DEPLOYABLE
→ DEPLOYED

Cada transición debería tener predicados explícitos.

Ejemplo:

PLANNED → EXECUTABLE

requiere:
    unresolved_architecture == 0
    implementation_plan.exists
    acceptance_contract.exists

La IA puede producir evidencia.

El arnés determina si las condiciones de transición se satisfacen.

---

# 28. LA AUTORIDAD SOBRE LAS HERRAMIENTAS COMO ARQUITECTURA

Estudia este principio:

La autoridad del modelo sobre las herramientas debería derivarse del estado semántico del proceso.

Ejemplo:

Exploración

Permitido:

leer
buscar
inspeccionar
analizar

Prohibido:

modificar el código fuente
modificar las pruebas
hacer commit
desplegar

Arquitectura

Permitido:

razonar
comparar
producir decisiones

Prohibido:

implementar

Implementación

Permitido:

modificar rutas acotadas
compilar
correr pruebas

Prohibido:

cambiar los requisitos
cambiar la arquitectura en silencio
debilitar el oráculo
ampliar el alcance del producto

Cuando aparece un criterio arquitectónico no resuelto:

DETENERSE
→ emitir UnresolvedDecision
→ regresar a la etapa de criterio

Determina si esto crea garantías de proceso más fuertes que las instrucciones en el texto por sí solas.

---

# 29. LA IA PUEDE PROPONER EVIDENCIA; EL ARNÉS ES DUEÑO DE «VERIFICADO»

Desarrolla este principio:

La IA puede proponer evidencia, pero la IA no es dueña de la definición de «verificado».

Ejemplos de evidencia observable externamente:

el código de salida del compilador
los resultados de las pruebas
el puntaje de mutación
el comprobador de dependencias
el comprobador de migraciones
el trinquete de seguridad
una sonda en tiempo de ejecución
una comprobación de salud del despliegue

El modelo no debe avanzar el estado meramente por reportar éxito.

---

# 30. ENRUTAMIENTO DE MODELOS

Usa la jerarquía operativa actual como caso de estudio:

Haiku  = mecánico
Sonnet = ejecución
Opus   = criterio
Fable  = escalamiento a la frontera

Pero abstráela en clases cognitivas independientes del modelo:

DeterministicMechanism
MechanicalInference
ExecutionReasoning
JudgmentReasoning
FrontierReasoning

Enrutador candidato:

¿Puede resolver la tarea software determinista?
    → mecanismo determinista

¿Es una clasificación o transformación acotada?
    → inferencia mecánica

¿Las decisiones semánticas ya están resueltas?
    → razonamiento de ejecución

¿Queda atribución o arquitectura sin resolver?
    → razonamiento de criterio

¿La incertidumbre es novedosa, de alto riesgo o sin resolver?
    → razonamiento de frontera

Trata el esfuerzo por separado:

cognitive_role = clase de razonamiento

effort = profundidad del razonamiento

---

# 31. DENSIDAD DE CRITERIO

Desarrolla un concepto medible de densidad de criterio.

Factores posibles:

incertidumbre semántica
ambigüedad
novedad
número de alternativas legítimas
irreversibilidad
costo de la falla
evidencia faltante
acoplamiento entre dominios
dificultad de verificación

Pon a prueba:

El volumen de código no debería determinar el nivel de modelo; el criterio semántico no resuelto sí.

---

# 32. SPEC KIT Y OPENSPEC

Investiga los actuales:

No preguntes meramente cuál debería reemplazar al proceso nativo. Estudia si pueden ser interfaces de especificación hacia el mismo arnés semántico.

Arquitectura posible:

                  Arnés de desarrollo
                          │
                  Representación intermedia semántica
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
    Spec Kit          OpenSpec           Nativo
    adaptador         adaptador          adaptador

Compara:

Identifica qué se puede adoptar sin entregar la arquitectura de control semántico.

---

# 33. SINTAXIS CONTRA SEMÁNTICA DE LA ESPECIFICACIÓN

Estudia esta distinción:

spec.md
proposal.md
design.md
tasks.md

son representaciones serializadas.

No deberían definir la ontología subyacente del proceso.

Normaliza los formatos externos hacia entidades semánticas como:

Intent
Requirement
Constraint
ArchitectureDecision
UnresolvedQuestion
AcceptanceCriterion
ImplementationTask
VerificationEvidence

Investiga si esto permite la adopción gradual y el reemplazo de herramientas de especificación.

---

# 34. LAS INSTRUCCIONES COMO PROYECCIONES SEMÁNTICAS

Aplica la mediación semántica a la construcción de instrucciones.

Evita darle rutinariamente a un agente:

todo el repositorio
+ un manual de proceso enorme
+ un objetivo amplio

En vez de eso, considera compilar:

la semántica de la tarea
+ la ontología relevante
+ la arquitectura relevante
+ el estado del proceso
+ las decisiones resueltas
+ el criterio permitido
+ el alcance
+ el contrato de aceptación
+ la autoridad sobre las herramientas
+ las condiciones de parada

en una proyección semántica específica para esa tarea.

Candidata:

Task
+ OntologyContext
+ ArchitectureState
+ ProcessState
+ CognitiveRole
+ Effort
+ Risk
+ AllowedJudgment
+ ToolAuthority
+ AcceptanceContract

→ WorkerPacket
→ instrucción específica del modelo

Determina si la generación de instrucciones debería volverse compilación a partir de estado semántico en vez de plantillas hechas a mano.

---

# 35. LA DIFERENCIA CON «HAZME UNA APLICACIÓN»

Analiza la arquitectura epistémica de:

«Hazme una aplicación.»

El mismo modelo puede ser dueño implícito de:

los requisitos
la ontología
la arquitectura
las suposiciones
la implementación
las pruebas
la verificación
los criterios de terminación

Compara esto contra el desarrollo mediado por un arnés, donde estos papeles están separados.

Investiga si la generación autónoma sin restricciones crea un ciclo semántico que se confirma a sí mismo.

---

# 36. FRICCIÓN SELECTIVA

Desarrolla esta distinción:

Desarrollo tradicional:
    fricción cara en todas partes

Desarrollo ingenuo con IA:
    casi ninguna fricción en ninguna parte

Desarrollo propuesto:
    poca fricción para el trabajo conocido o mecánico
    mucho escrutinio en las fronteras semánticas

Pon a prueba el principio:

La buena ingeniería asistida por máquina no elimina la fricción; la reubica en los lugares donde cambia el significado.

Identifica esos lugares.

Puertas semánticas candidatas:

intención → requisito

requisito → ontología

ontología → arquitectura

arquitectura → contrato de aceptación

contrato de aceptación → plan de implementación

implementación → comportamiento verificado

---

# 37. LA VELOCIDAD GENERATIVA COMO MULTIPLICADOR DE RIESGO

Investiga:

Generar más rápido amplifica tanto la calidad arquitectónica como los errores arquitectónicos.

Modelo:

costo de propagación del error
≈
error semántico
× velocidad de generación
× número de artefactos río abajo
× amplificación de la confianza

Esto es conceptual, todavía no matemático.

Determina si es posible un modelo formal.

Estudia si la coherencia generada por un modelo de lenguaje puede volver las arquitecturas erróneas más resistentes a la corrección, por quedar rodeadas de artefactos que se refuerzan mutuamente.

---

# 38. EL PROCESO COMO DEFENSA CONTRA LA ENTROPÍA SEMÁNTICA

Determina si el arnés se puede entender como un mecanismo antientropía.

Mecanismos posibles:

vocabulario controlado
validación de ontología
gramática arquitectónica
interfaces tipadas
pruebas independientes
pruebas de mutación
separación de modelos
restricciones de herramientas
transiciones mecánicas de proceso
comprobaciones de arquitectura
imposición en integración continua
trazabilidad
reparación semántica

Para cada uno, determina qué forma de pudrición previene o detecta.

---

# 39. INTERPRETACIONES EXPLÍCITAS

Estudia la importancia de registrar el significado de forma explícita.

Ejemplo:

Primitive =
una capacidad reutilizable con invariantes explícitas
y una política de dominio mínima.

Esto difiere de dejar que todo modelo futuro reconstruya el significado a partir del uso en el repositorio.

Determina cuándo una interpretación debería volverse:

un concepto SKOS
una clase OWL
una restricción SHACL
un tipo de Rust
una prueba
una regla de integración continua

---

# 40. REPARACIÓN SEMÁNTICA

Desarrolla la reparación como un proceso de desarrollo de primera clase.

Cuando falla un invariante semántico:

detectar el desajuste
→ identificar el concepto semántico afectado
→ comparar la observación con la ontología
→ aislar el delta sin resolver
→ enrutar el criterio
→ verificar la interpretación revisada
→ actualizar los artefactos
→ actualizar la imposición

No regeneres automáticamente especificaciones o arquitecturas enteras.

Estudia si la reparación semántica puede prevenir reescrituras masivas impulsadas por un modelo de lenguaje.

---

# 41. OBJETIVO CENTRAL DE OPTIMIZACIÓN

No optimices meramente por:

menos tokens
terminar más rápido
el modelo más grande
autonomía máxima
menos decisiones humanas
más código generado

Evalúa:

MINIMIZAR

incertidumbre semántica
deriva semántica
divulgación innecesaria
criterio repetido
erosión de la arquitectura
autoconfirmación
costo de verificación
costo por resultado correcto

MAXIMIZAR

determinismo
integridad conceptual
reúso semántico
trazabilidad
falsabilidad
privacidad
evidencia independiente
imposición mecánica

Identifica los conflictos entre estas metas.

---

# 42. PRINCIPIOS POSIBLES

Evalúa estos como principios candidatos con nombre.

Principio de la frontera de la inteligencia

Usa la inteligencia probabilística principalmente donde el significado semántico sigue sin resolverse.

Principio del trinquete semántico

Una vez que el significado está verificado, codifícalo de modo que el trabajo futuro no lo pueda reinterpretar a la ligera.

Principio de la proyección semántica

Expón solo la información capaz de cambiar la respuesta a la inferencia tipada actual.

Principio de la amortización semántica

Paga el costo de la inteligencia por cada desconocido semántico distinto, no por las instancias conocidas repetidas.

Principio de la fricción selectiva

Reduce la fricción para la ejecución determinista y aumenta el escrutinio donde cambia el significado.

Principio de la propiedad del arnés

El arnés del proceso, no un modelo individual, es dueño del estado del flujo de trabajo y de la verificación.

Principio del oráculo independiente

Quien implementa no debería ser la única autoridad que define si su implementación es correcta.

Principio de la ontología antes que la arquitectura

Determina qué clase de cosa es un concepto antes de decidir cómo debería componerse.

Principio de la entropía generativa

La generación barata aumenta la necesidad de mecanismos que preserven la coherencia semántica.

Determina cuáles son:

established
established_but_reframed
useful_synthesis
possibly_novel
unsupported

---

# 43. POSIBLE APORTACIÓN ORIGINAL

Investiga si la aportación principal no es ningún mecanismo por sí solo sino su integración:

lenguaje
→ semántica
→ ontología
→ gramática arquitectónica
→ artefactos tipados
→ inteligencia selectiva
→ verificación independiente
→ imposición determinista

bajo condiciones en las que la generación en lenguaje natural ha reducido drásticamente el costo de crear artefactos de software.

Aportación candidata:

Una arquitectura de control semántico para la ingeniería asistida por modelos de lenguaje, que trata el desarrollo del lenguaje al software como una secuencia de transformaciones semánticas explícitamente gobernadas en vez de como un solo acto generativo.

Compara esto contra los sistemas existentes de desarrollo dirigido por especificación, dirigido por modelos, formales y agénticos.

---

# 44. PREDECESORES

Investiga el trabajo previo relevante, incluyendo:

Para cada uno identifica:

idea establecida
traslape
diferencia
implicación para la novedad

---

# 45. CONTRAARGUMENTOS

Construye las objeciones más fuertes.

Como mínimo:

1. El lenguaje solo describe la arquitectura. 2. La semántica formal no es arquitectura. 3. La estructura no contiene significado. 4. La atribución no se puede separar limpiamente de la observación. 5. El diseño con la ontología primero causa parálisis por análisis. 6. La formalización semántica crea burocracia. 7. Los sistemas generados por modelos de lenguaje no necesariamente se degradan más rápido que los escritos por personas. 8. La entropía generativa es meramente deuda técnica con otro nombre. 9. Los trinquetes semánticos pueden fosilizar suposiciones incorrectas. 10. Las pruebas preservan comportamiento, no significado. 11. Los agentes independientes pueden compartir los mismos sesgos del modelo y por tanto no son verdaderamente independientes. 12. OWL, RDF y SHACL añaden complejidad sin beneficio práctico. 13. Las restricciones de herramientas reducen autonomía útil. 14. Los arneses de proceso se vuelven inflexibles. 15. «Hazme una aplicación» funciona suficientemente bien para muchas aplicaciones. 16. El enrutamiento de modelos cuesta más mantenerlo de lo que ahorra. 17. El razonamiento de la IA sigue siendo necesario incluso para comportamiento conocido en entornos cambiantes. 18. La representación intermedia semántica introduce otra representación que ella misma puede derivar. 19. La compresión semántica puede esconder la ambigüedad en vez de eliminarla. 20. «El lenguaje como arquitectura» sigue siendo metafórico y no técnico.

Para cada uno provee:

strongest_case
supporting_evidence
response
necessary_concession
falsification_test

---

# 46. HIPÓTESIS EMPÍRICAS

Desarrolla experimentos falsables, incluyendo:

H1

Las restricciones semánticas reducen las violaciones de arquitectura comparadas con instrucciones solo en prosa.

H2

Los artefactos tipados reducen la divergencia semántica entre los agentes de planeación y los de implementación.

H3

Los oráculos de aceptación independientes reducen los errores de implementación que se confirman a sí mismos.

H4

Enrutar por densidad de criterio produce menor costo por resultado correcto que enrutar por tamaño de tarea.

H5

La proyección semántica reduce la divulgación de datos privados manteniendo una corrección aceptable para tareas que se pueden responder estructuralmente.

H6

Las reglas semánticas verificadas reducen las llamadas repetidas al modelo para estructuras recurrentes.

H7

Las fronteras impuestas mecánicamente producen menos erosión arquitectónica bajo desarrollo de alto volumen con modelos de lenguaje.

H8

Un léxico arquitectónico controlado reduce la creación de abstracciones inconsistentes por parte de agentes independientes.

H9

Compilar las instrucciones a partir de estado semántico tipado produce menos desviaciones de alcance y de requisitos que las instrucciones de propósito general.

H10

El desarrollo controlado por un arnés produce menor divergencia entre especificación, código y pruebas en proyectos de larga duración que el desarrollo agéntico sin restricciones.

H11

La velocidad de generación aumenta la deriva semántica cuando la fuerza de la imposición se mantiene constante.

H12

La reparación semántica de los deltas produce menos cambio innecesario que la regeneración completa de la especificación o de la implementación.

Diseña experimentos capaces de refutar estas afirmaciones.

---

# 47. PROCESO PRÁCTICO DE DESARROLLO ASISTIDO POR MÁQUINA

Deriva una metodología de desarrollo a partir de la teoría.

Candidata:

1. Capturar la intención.

2. Observar el estado existente del sistema.

3. Separar las observaciones de las interpretaciones.

4. Normalizar el vocabulario.

5. Identificar las clases ontológicas.

6. Reutilizar las definiciones semánticas existentes.

7. Identificar las atribuciones sin resolver.

8. Determinar qué trabajo ya es determinista.

9. Crear proyecciones semánticas mínimas para las preguntas sin resolver.

10. Enrutar las preguntas según la densidad de criterio.

11. Exigir decisiones semánticas tipadas.

12. Validar la composición arquitectónica.

13. Producir requisitos y criterios de aceptación.

14. Construir oráculos independientes y falsables.

15. Producir planes de implementación.

16. Enrutar hacia abajo el trabajo de ejecución ya resuelto.

17. Restringir la autoridad sobre las herramientas según el estado del proceso.

18. Ejecutar comprobaciones mecánicas fuera del modelo.

19. Revisar de forma independiente la integridad semántica y arquitectónica.

20. Compilar las decisiones verificadas en mecanismos deterministas.

21. Imponer mecánicamente las fronteras importantes.

22. Preservar la ontología, la evidencia, las pruebas y las decisiones.

23. Detectar el desajuste semántico.

24. Reparar únicamente los deltas semánticos sin resolver.

25. Volver a invocar la inteligencia solo donde de verdad se requiera criterio nuevo.

Clasifica cada paso como preferentemente:

humano
razonamiento de frontera
razonamiento de criterio
razonamiento de ejecución
inferencia mecánica
programa determinista

---

# 48. ARQUITECTURA DE DESARROLLO OBJETIVO

Evalúa esta candidata:

                     INTENCIÓN HUMANA
                            │
                            ▼
                    MEDIACIÓN SEMÁNTICA
                            │
                            ▼
                          LÉXICO
                            │
                            ▼
                        ONTOLOGÍA
                            │
                            ▼
                GRAMÁTICA ARQUITECTÓNICA
                            │
                            ▼
                   REPRESENTACIÓN SEMÁNTICA
                            │
                            ▼
                     ARNÉS DE PROCESO
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
    Mecanismos          Modelos de        Modelos de
   deterministas        ejecución          criterio
          │                 │                 │
          └─────────────────┼─────────────────┘
                            ▼
                    TRABAJO EJECUTABLE
                            │
                            ▼
                 EVIDENCIA INDEPENDIENTE
                            │
                            ▼
                   IMPOSICIÓN MECÁNICA
                            │
                            ▼
                    MEMORIA SEMÁNTICA
                            │
                            └──── reparar al desajustarse

Determina qué partes deberían implementarse de verdad y cuáles pertenecen solo al modelo conceptual.

---

# 49. SALIDA INICIAL REQUERIDA

Todavía no escribas capítulos de la tesis.

Primero produce:

thesis_claim

La afirmación defendible más fuerte, en una sola frase.

conservative_claim

La versión más fácil de defender académicamente.

ambitious_claim

La afirmación de mayor consecuencia si la evidencia la sostiene.

motivating_change

Explica cómo la generación por modelos de lenguaje cambia la economía y la epistemología del desarrollo de software.

generative_entropy

Define o rechaza el concepto.

semantic_rot_taxonomy

Refina las formas de degradación propuestas.

semantic_ratchet

Define el mecanismo y sus límites.

selective_friction

Define dónde debería aumentar y dónde disminuir la fricción del desarrollo.

language_definition

Define con precisión qué es el lenguaje en esta tesis.

semantics_definition

Define con precisión qué es la semántica.

architecture_definition

Propón y compara definiciones candidatas.

ontology_model

Define las clases y relaciones arquitectónicas propuestas.

standards_mapping

Mapea SKOS, RDF, OWL, SHACL, SPARQL, los tipos de Rust, las pruebas y el arnés.

intelligence_boundary

Define la frontera entre el criterio semántico y el mecanismo determinista.

semantic_mediation

Formaliza la proyección semántica mínima.

structural_sharding

Explica su papel teórico y práctico.

semantic_amortization

Define y compara con las teorías existentes.

architectural_grammar

Define el concepto e identifica sus equivalentes existentes.

semantic_ir

Propón la representación intermedia útil más pequeña.

semantic_compilation

Distingue el mecanismo literal de la analogía.

typed_artifacts

Identifica los tipos de artefacto útiles mínimos.

tests_as_semantic_memory

Evalúa críticamente la afirmación.

process_harness

Define la propiedad, el estado y la semántica de transición.

tool_authority

Define cómo se derivan los permisos del agente a partir del estado del proceso.

model_routing

Abstrae los papeles cognitivos de los nombres comerciales de los modelos.

spec_tool_comparison

Compara Spec Kit, OpenSpec y el proceso nativo como posibles interfaces de especificación.

anti_entropy_mechanisms

Mapea cada mecanismo de control al modo de falla que previene.

novelty_analysis

Ordena las posibles aportaciones.

predecessor_map

Identifica las teorías que acotan las afirmaciones de novedad.

counterarguments

Presenta los desafíos más fuertes.

empirical_hypotheses

Produce experimentos falsables.

implementation_experiment

Diseña el arnés real más pequeño capaz de poner a prueba la teoría central.

thesis_outline

Produce la secuencia argumentativa de capítulos más fuerte.

unresolved_questions

Lista los problemas conceptuales sin resolver.

falsification_conditions

Enuncia qué evidencia causaría una reelaboración sustancial o el rechazo.

---

# 50. DISCIPLINA PROBATORIA

Etiqueta las proposiciones significativas como:

ESTABLISHED
SOURCE-DERIVED
OBSERVATION
INFERENCE
ANALOGY
HYPOTHESIS
PROPOSED THEORY
POSSIBLE NOVEL CONTRIBUTION

Nunca:

atribución;

Distingue continuamente:

significado
representación
interpretación
inferencia
validación
verificación
ejecución
imposición

---

# 51. LA PREGUNTA FINAL

Determina si esta proposición sobrevive al escrutinio teórico y empírico:

Conforme el desarrollo de software pasa de la programación predominantemente escrita por personas hacia la generación por máquina mediada por lenguaje, el problema central de ingeniería se vuelve cada vez más la preservación de la integridad semántica a través de artefactos generados rápidamente. Una arquitectura confiable de desarrollo asistido por máquina debería por tanto mediar el significado de forma explícita: normalizar la terminología, clasificar los conceptos ontológicamente, restringir su composición válida, aislar las preguntas semánticas sin resolver, enrutar esas preguntas hacia una inteligencia adecuadamente acotada, representar las decisiones aceptadas mediante artefactos tipados, verificarlas de forma independiente, y codificar progresivamente el significado establecido en mecanismos deterministas y fronteras impuestas mecánicamente.

E investiga su corolario práctico:

El objetivo de la ingeniería asistida por máquina madura no es la autonomía máxima de la IA. Es el máximo apalancamiento semántico: usar la inteligencia donde el significado de verdad está sin resolver, hacer que los cambios de significado sean explícitos y lo bastante caros como para escrutarlos, y hacer que la ejecución ya comprendida sea tan barata, determinista, reutilizable y mecánicamente verificable como sea posible.

Toda la investigación