Eso no es ficción aspiracional. Es lo que producen siete propiedades de especificación cuando se aplican. La metodología está publicada, es reproducible y está respaldada por un estudio controlado con 58 desarrolladores.
A continuación están las 25 capacidades estructurales que tu base de código gana cuando se aplica GS — y las 25 modos de falla que las mismas propiedades previenen.
npx pragmaworks audit
Cada capacidad es una adquisición estructural — algo que tu base de código gana de forma permanente, no un proceso que tienes que mantener.
| # | Capacidad | Qué significa en la práctica |
|---|---|---|
| 1 | Coherencia Arquitectónica entre Sesiones (Cross-Session Architectural Coherence) | El código generado en cualquier sesión de IA es estructuralmente consistente con todas las sesiones anteriores. La especificación es el árbitro persistente. |
| 2 | Derivabilidad Sin Estado (Stateless Derivability) | Una nueva sesión de IA — o un nuevo ingeniero — deriva la implementación correcta únicamente desde los artefactos. No se necesita traspaso verbal. |
| 4 | Contratos Explícitos entre Sistemas (Explicit Inter-System Contracts) | Cada interfaz entre sistemas está escrita y es ejecutable. El modo de falla del Mars Climate Orbiter es estructuralmente eliminado. |
| 12 | Verificación Ligada a la Especificación (Specification-Bound Verification) | El conjunto de pruebas verifica contratos de comportamiento contra ejecución real — no solo que el código compila. |
| 14 | Transferencia de Conocimiento Sin Estado (Stateless Knowledge Transfer) | Rotaciones de equipo, reinicios de sesión de IA, incorporaciones — todo gestionado por la especificación. La tradición oral se convierte en artefacto. |
| 18 | Disciplina Formal Sostenible (Sustainable Formal Discipline) | El sistema aplica SOLID, TDD y arquitectura limpia de forma automática — no a través de presión cultural. |
| 22 | Seguridad a Nivel de Especificación (Spec-Level Security) | La clasificación de consecuencias está escrita. Las operaciones irreversibles tienen puertas de confirmación. Estructural, no procedimental. |
| 24 | Dependencia de IA Invertida (Inverted AI Dependency) | La IA ejecuta contra tu especificación, no contra su distribución previa. Tú diriges al modelo; el modelo no te dirige a ti. |
| # | Capacidad | Qué significa en la práctica |
|---|---|---|
| 5 | Conocimiento de Proyecto Derivable (Derivable Project Knowledge) | Cualquier ingeniero o sesión de IA puede reconstruir el contexto completo del proyecto solo desde artefactos. |
| 6 | Memoria de Sesión Persistente (Persistent Session Memory) | El contexto establecido en una sesión está disponible en todas las sesiones posteriores — sin re-narración. |
| 9 | Verificación Conductual (Behavioral Verification) | Las pruebas demuestran lo que el sistema hace bajo condiciones reales, no solo que compila. |
| 15 | Deuda Técnica Visible (Visible Technical Debt) | La deuda se registra en artefactos auditables. La IA sabe que existe. La remediación es planificada, no descubierta. |
| 21 | Prompting Estructurado (Structured Prompting) | La especificación es el prompt. Agnóstico al modelo, estable por versión, reproducible en cualquier ejecutor de IA. |
| 25 | Automatización del Ciclo de Vida Completo (End-to-End Lifecycle Automation) | Desde la especificación hasta staging y el monitoreo en producción — cada nivel del ciclo de vida gobernado por el mismo conjunto de artefactos. |
| # | Capacidad | Qué significa en la práctica |
|---|---|---|
| 3 | Aplicación de Restricciones Arquitectónicas (Architectural Constraint Enforcement) | Reglas de capas, patrones prohibidos, convenciones de nomenclatura aplicadas en tiempo de generación — no en revisión de código. |
| 7 | Fuente Única de Verdad (Single Source of Truth) | Una especificación canónica. El código, las pruebas y los docs derivan de ella. La divergencia es un error de build, no un problema de personas. |
| 8 | Constitución Acotada (Bounded Constitution) | Cada artefacto de especificación cabe dentro de la ventana de contexto utilizable de la IA. Sin truncación silenciosa. Sin puntos ciegos. |
| 10 | Integridad de Fase TDD (TDD Phase Integrity) | La fase RED no puede ser omitida. Las puertas estructurales aplican test-antes-de-código a nivel de commit. |
| 11 | Discriminación de Fallos Fantasma (Ghost Failure Discrimination) | Los fallos de prueba te dicen qué requiere el contrato, no qué hace la implementación actual. |
| 13 | Output de IA Determinístico (Deterministic AI Output) | Dada la misma especificación y el mismo requerimiento, las sesiones de IA convergen en el mismo output. Reproducibilidad por diseño. |
| 16 | Linaje de Decisiones Arquitectónicas (Architectural Decision Lineage) | Cada decisión no obvia tiene una justificación registrada. La IA no puede "corregir" silenciosamente lo que no sabe que fue intencional. |
| 17 | Historial de Cambios Tipado (Typed Change History) | Cada commit tiene tipo, alcance e intención. El git log es un registro de auditoría legible por máquina. |
| 19 | Documentación Viva (Living Documentation) | Los docs se derivan de la especificación — se actualizan cuando la especificación se actualiza. No pueden quedar desincronizados. |
| 20 | Consistencia de Contratos entre Lenguajes (Cross-Language Contract Consistency) | Los contratos de interfaz se mantienen a través de los límites del servicio independientemente del lenguaje de implementación. |
| 23 | Superficie de IA Gobernada (Governed AI Surface) | La autoridad de la IA está acotada. Lo que puede y no puede hacer está escrito, no inferido. |
Marca las que apliquen:
Reconocer las tuyas es el primer paso para resolverlas.
| # | Patología | Qué observas |
|---|---|---|
| 1 | Deriva Arquitectónica (Architectural Drift) | El output de IA es estructuralmente incoherente entre sesiones. Cada sesión es localmente válida; el sistema diverge con el tiempo. |
| 2 | Ausencia de Especificación (Specification Absence) | No existe una especificación derivable. Cada sesión reconstruye la intención desde el código — de manera incorrecta y diferente cada vez. |
| 3 | Arquitectura Implícita (Implicit Architecture) | Las reglas arquitectónicas existen en la memoria de las personas, no en artefactos. La IA viola fronteras que nunca le fueron comunicadas. |
| 4 | Síndrome del Contrato Implícito (Implicit Contract Syndrome) | Dos sistemas coinciden en comportamiento por suposición, no por contrato escrito. El modo de falla del Mars Climate Orbiter: USD 327 millones perdidos por una especificación de unidades que nunca se escribió. |
| 5 | Punto Ciego de Seguridad IA (AI Security Blindspot) | Sin clasificación de consecuencias. La IA ejecuta operaciones irreversibles — eliminaciones, transacciones financieras — sin una puerta de confirmación humana. |
| 6 | Amnesia de Sesión (Session Amnesia) | El contexto se reinicia en cada límite de sesión. Decisiones anteriores, restricciones y razonamiento desaparecen. La IA recomienda lo que ya descartaste. |
| # | Patología | Qué observas |
|---|---|---|
| 7 | Teatro de Pruebas (Test Theater) | Las pruebas pasan. Los contratos de comportamiento no se verifican. CI verde sobre funcionalidades rotas. |
| 8 | Deuda de ADRs (ADR Debt) | Las decisiones arquitectónicas se toman y se pierden. La misma decisión se vuelve a debatir en cada sesión. |
| 9 | Expansión de Alcance (Scope Creep) | Cada sesión de IA expande ligeramente el alcance más allá de la tarea. Las fronteras nunca se hacen cumplir. |
| 10 | Dependencia del Copiloto (Copilot Dependency) | Solo la IA sabe qué hace el código. Los humanos no pueden revisar ni auditar output que no pueden seguir. |
| 11 | Desbordamiento de Ventana de Contexto (Context Window Overflow) | Las sesiones colapsan bajo su propio peso. La calidad se degrada; el modelo atiende las señales incorrectas. |
| 12 | Factor de Autobús (Bus Factor) | Una sola persona entiende el sistema. Si la IA o esa persona se va, el conocimiento se pierde. |
| 13 | Entropía de Nomenclatura (Naming Entropy) | Nomenclatura inconsistente entre sesiones. La IA inventa sinónimos. La búsqueda falla. |
| 14 | Caos de Commits (Commit Chaos) | Los commits son sin tipo, demasiado grandes o sin trazabilidad. El log de git es inútil como registro de auditoría. |
| 15 | Documentación Obsoleta (Documentation Decay) | Documentación escrita al inicio del proyecto. El código siguió adelante. Los docs engañan activamente a la IA. |
| 16 | Ceguera en Cascada (Cascade Blindness) | Un cambio en la especificación se propaga hacia abajo sin que nadie lo sepa. Las pruebas pasan sobre el contrato viejo. |
| 17 | Violación de Capas (Layer Violation) | Lógica de dominio en controladores. Consultas a base de datos en vistas. La IA agrega a la capa más cercana, no a la correcta. |
| 18 | Dependencia Fantasma (Phantom Dependency) | Componentes dependen entre sí de formas no declaradas. La refactorización rompe cosas que no deberían estar conectadas. |
| # | Patología | Qué observas |
|---|---|---|
| 19 | Fricción de Incorporación (Onboarding Friction) | Los desarrolladores nuevos necesitan semanas de acompañamiento. Las sesiones de IA nuevas necesitan el mismo acompañamiento cada vez. |
| 20 | Dependencia de Prompt Engineering (Prompt Engineering Dependency) | Los prompts son la especificación. Cambia el modelo, pierde el output. Funciona hasta que deja de funcionar. |
| 21 | Optimización Prematura (Premature Optimization) | La IA optimiza para la métrica más cercana, no para las restricciones reales del sistema. |
| 22 | Sobreingeniería (Over-Engineering) | La IA añade capas de abstracción que la especificación nunca pidió. La complejidad se acumula entre sesiones. |
| 23 | Deuda Técnica Invisible (Tech Debt Invisibility) | La deuda es conocida pero no está registrada en artefactos. La IA no sabe que existe. |
| 24 | Brecha de Cumplimiento (Compliance Gap) | Los requisitos regulatorios o de seguridad existen en la cabeza de alguien. La IA nunca los tuvo. |
| 25 | Desajuste de Herramientas (Tooling Mismatch) | La IA usa la herramienta incorrecta para la tarea. No porque sea incorrecta — sino porque la especificación nunca dijo qué herramienta usar y cuándo. |
| Propiedad GS | Patologías que previene | Capacidades que construye |
|---|---|---|
| Auto-descriptiva | Deriva Arquitectónica, Amnesia de Sesión, Arquitectura Implícita, Fricción de Incorporación, Deuda de ADRs | Coherencia Arquitectónica entre Sesiones, Derivabilidad Sin Estado, Conocimiento de Proyecto Derivable |
| Acotada | Desbordamiento de Ventana de Contexto, Expansión de Alcance, Violación de Capas, Desajuste de Herramientas | Constitución Acotada, Aplicación de Restricciones Arquitectónicas |
| Verificable | Teatro de Pruebas, Ceguera en Cascada, Brecha de Cumplimiento | Verificación Conductual, Verificación Ligada a la Especificación |
| Defendida | Punto Ciego de Seguridad IA, Ceguera en Cascada, Optimización Prematura | Seguridad a Nivel de Especificación, Integridad de Fase TDD, Superficie de IA Gobernada |
| Auditable | Deuda de ADRs, Caos de Commits, Documentación Obsoleta, Deuda Técnica Invisible | Linaje de Decisiones Arquitectónicas, Historial de Cambios Tipado, Documentación Viva |
| Componible | Dependencia Fantasma, Violación de Capas, Sobreingeniería | Consistencia de Contratos entre Lenguajes, Fuente Única de Verdad |
| Ejecutable | Teatro de Pruebas, Brecha de Cumplimiento, Desajuste de Herramientas | Discriminación de Fallos Fantasma, Output de IA Determinístico |
Las siete propiedades y su rúbrica (puntuación 0–14) están publicadas en el GS White Paper v4.0.