El endpoint número 200
Construyes un SaaS con vibe coding. Al principio es rápido. 5 tablas, 12 endpoints — veinte minutos y funciona.
Pero pasados 50 endpoints, algo extraño ocurre. La IA produce hoy un patrón que contradice el de ayer. Pasados 100, funcionalidades existentes se rompen en silencio. Pasados 200, añadir una sola funcionalidad cuesta 10 veces más que las primeras diez.
No es que el modelo sea estúpido.
Decisiones e implementación
Tres cosas están entremezcladas en el código fuente:
- Decisiones del usuario — esta columna es
BIGINT, este endpoint es solo para el propietario, la paginación es por cursor. - Lógica de negocio — precios, flujos de trabajo, reglas de ciclo de vida.
- Detalles de implementación — nombres de variables, orden de llamadas a bibliotecas, envoltura de errores.
Cuando la IA lee este código, no puede distinguir qué línea es una decisión y cuál un detalle. Así que cuando “refactoriza” o “limpia”, sobrescribe silenciosamente decisiones que confundió con detalles. El usuario no se da cuenta hasta que el comportamiento ya está mal.
Esta es la razón por la que el vibe coding colapsa en 200 endpoints. Un modelo más grande no lo arregla. El medio — código crudo — simplemente no preserva las decisiones. Todo modelo acaba chocando contra el mismo muro.
La quilla
La quilla es el primer hueso que se coloca al construir un barco. Soporta el peso del casco, previene el balanceo lateral, y toda otra estructura se construye sobre ella. Un barco sin quilla flota en aguas tranquilas pero se deforma cuando llegan las olas.
Un SaaS construido con vibe coding es igual. Flota cuando es pequeño. Se deforma cuando crece.
yongol es la quilla del SaaS codificado con IA.
Sacar las decisiones del código
El núcleo de yongol es simple. Separar las decisiones del código.
Diez especificaciones declarativas (SSOTs) manejan cada una un único interés:
| SSOT | Interés |
|---|---|
| features.yaml | Catálogo de funcionalidades — qué construir |
| manifest.yaml | Configuración del proyecto — autenticación, middleware, infraestructura |
| OpenAPI | Contrato API — rutas, parámetros, respuestas |
| SQL DDL + sqlc | Modelo de datos — tablas, columnas, restricciones, consultas |
| SSaC | Flujo de servicio — secuencia de decisiones dentro de un endpoint |
| Rego | Autorización — quién puede hacer qué |
| Mermaid stateDiagram | Transiciones de estado — ciclos de vida de entidades |
| FuncSpec | Funciones personalizadas — lógica que no se expresa como CRUD |
| Hurl | Escenarios de prueba — verificación en tiempo de ejecución |
| STML | Frontend — estructura de página y enlace de datos |
Ocho de las diez son estándares de la industria (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML). Solo SSaC y STML son DSLs creados por yongol. Lo que la IA debe aprender desde cero se minimiza.
Cada SSOT contiene solo decisiones. Sin detalles de implementación. La IA edita los SSOTs; yongol generate renderiza código a partir de ellos. Las decisiones viven permanentemente en los SSOTs; el código es una proyección desechable.
Forzar la consistencia
Las decisiones están ahora repartidas en diez archivos, así que pueden aparecer contradicciones. ¿DDL dice BIGINT pero OpenAPI dice string? ¿SSaC declara @auth pero Rego no tiene regla correspondiente? ¿El diagrama de estados tiene una transición pero SSaC no tiene función correspondiente?
Un SSOT contradecido es una decisión corrupta. Por limpio que esté el código, si las decisiones se contradicen, el comportamiento es incorrecto.
yongol validate captura esto.
✓ manifest ✓ openapi_ddl ✓ ssac_rego
✓ openapi ✓ openapi_ssac ✓ ssac_authz
✓ ddl ✓ hurl_openapi ✓ ssac_sqlc
✓ query ✓ hurl_statemachine ✓ ddl_statemachine
✓ ssac ✓ hurl_manifest ✓ ddl_rego
✓ statemachine ✓ openapi_manifest ✓ rego_manifest
✓ rego ✓ ssac_ddl ✓ stml_openapi
✓ hurl ✓ ssac_statemachine
✓ funcspec ✓ ssac_func
0 errors, 0 warnings
Primero valida cada SSOT individualmente, luego ejecuta verificaciones cruzadas entre capas. ~287 reglas inspeccionan cada referencia simbólica entre los diez SSOTs. Si existe una sola contradicción, la compilación se rechaza.
La IA escribe libremente. Si se sale de los rieles, validate lo captura al instante. Libertad sobre rieles.
operationId es la piedra angular
¿Cómo se unen diez capas? Con un solo identificador PascalCase.
Introduce el operationId ExecuteWorkflow:
── Feature Chain: ExecuteWorkflow ──
OpenAPI api/openapi.yaml POST /workflows/{id}/execute
SSaC service/workflow/execute_workflow.ssac @get @empty @auth @state @call @publish @response
DDL db/workflows.sql CREATE TABLE workflows
DDL db/execution_logs.sql CREATE TABLE execution_logs
Rego policy/authz.rego resource: workflow
StateDiag states/workflow.md diagram: workflow → ExecuteWorkflow
FuncSpec func/billing/check_credits.go @func billing.CheckCredits
FuncSpec func/billing/deduct_credit.go @func billing.DeductCredit
FuncSpec func/worker/process_actions.go @func worker.ProcessActions
FuncSpec func/webhook/deliver.go @func webhook.Deliver
Hurl tests/scenario-happy-path.hurl scenario: scenario-happy-path.hurl
Desde la especificación de API hasta el esquema de base de datos, desde políticas de autorización hasta transiciones de estado, desde implementaciones de funciones hasta escenarios de prueba — la topología completa de una funcionalidad en una pantalla. Decenas de greps reemplazados por un comando.
operationId es la piedra angular porque en una aplicación full-stack, la unidad de una funcionalidad es el endpoint de API. Un usuario pulsa un botón, se llama una API, y esa API atraviesa todas las demás capas. Un nombre encadena físicamente diez capas.
Benchmark: ZenFlow
ZenFlow — un SaaS de automatización de flujos de trabajo multi-tenant. Claude Sonnet 4.6 escribió los SSOTs; yongol los validó.
| Etapa | Descripción | Tiempo | Acumulado |
|---|---|---|---|
| Construcción inicial | multi-tenant, auth, máquina de estados, 6 tablas, 10 endpoints | 23 min | 23 min |
| + Versionado | clon de workflow, lista de versiones, copia de acciones INSERT…SELECT | 16 min | 39 min |
| + Webhooks | publicación de eventos, CRUD de webhooks, backend de cola | 8 min | 47 min |
| + Marketplace de plantillas | paginación por cursor, clon cross-org, endpoints públicos | 7 min | 54 min |
| + Archivos adjuntos | reportes de ejecución, backend de archivos | 7 min | 61 min |
| + Programación | cron basado en sesión, TTL | 10 min | 71 min |
| + Logs de auditoría | backend de caché, paginación, filtros | 6 min | 77 min |
| + Dashboard | API agregada, joins de relaciones, vistas de detalle | 14 min | 91 min |
| + Operaciones batch | guardado masivo de acciones, serialización JSON | 10 min | 101 min |
| + API externa | importación de API de geocodificación, almacenamiento de coordenadas | 14 min | 115 min |
| + Actualización condicional | auto-asignación, puntuación de confianza, ramificación condicional | 16 min | 131 min |
Final: 30 endpoints, 12 tablas, 64 peticiones de prueba. Todo verde.
Diez funcionalidades añadidas secuencialmente. Añadir funcionalidades nunca se ralentizó. Los tests existentes nunca se rompieron. El muro de los 200 endpoints no existió.
Ejecutando la misma especificación con Opus: 30 endpoints, 73 peticiones de prueba, ~76 min. El modelo cambia, los rieles permanecen iguales.
Por qué un modelo más grande no es la respuesta
“GPT-6 arreglará esto.”
No lo hará. El problema no es la inteligencia del modelo — es el medio.
El código como medio no distingue decisiones de implementación. Cualquier modelo que lea código ve texto donde decisiones y detalles están entrelazados. Por inteligente que sea el modelo, si el medio no proporciona la distinción, el modelo no puede hacerla.
yongol cambia el medio. Mueve lo que la IA edita del código a especificaciones declarativas. Como las especificaciones contienen solo decisiones sin detalles de implementación, la IA nunca confunde una decisión con un detalle. La supervivencia de las decisiones se independiza del tamaño del modelo.
Un LLM pequeño editando solo SSOTs, con validate proporcionando retroalimentación precisa en cada error, puede mantener la misma integridad de decisiones que un modelo mucho mayor editando código crudo. yongol cubre esa brecha.
Comenzar
npx skills add park-jun-woo/yongol
Instala el skill yongol en tu agente de IA (Claude Code, Cursor, Copilot y más). El agente aprende el flujo de trabajo al instalarlo.
Para usar el CLI directamente:
go install github.com/park-jun-woo/yongol/cmd/yongol@latest
git clone https://github.com/park-jun-woo/yongol && cd yongol
yongol validate examples/zenflow
0 errors, 0 warnings.
Apunta una IA a estas especificaciones y dile que añada una funcionalidad. validate pone los rieles; la IA corre sobre ellos. No hay muro.
Artículos relacionados
- SSaC — Service Sequences as Code — El DSL piedra angular de yongol. Declara decisiones dentro de los endpoints.
- Feature Chain — Rastrear un Full Stack con un operationId — Rastreo de las ocho capas a través de un solo operationId.
- Ratchet Pattern — Cómo hacer que un agente termine el trabajo — La base teórica de cómo validate retroalimenta a los agentes.
Código: github.com/park-jun-woo/yongol