Endpoint ke-200
Anda membangun SaaS dengan vibe coding. Awalnya cepat. 5 tabel, 12 endpoint — dua puluh menit dan berjalan.
Tapi melewati 50 endpoint, sesuatu yang aneh terjadi. AI menghasilkan pola hari ini yang bertentangan dengan kemarin. Melewati 100, fitur yang ada diam-diam rusak. Melewati 200, menambahkan satu fitur biayanya 10x lipat dari sepuluh fitur pertama.
Bukan karena modelnya bodoh.
Keputusan dan implementasi
Tiga hal tercampur dalam kode sumber:
- Keputusan pengguna — kolom ini adalah
BIGINT, endpoint ini hanya untuk pemilik, pagination menggunakan cursor. - Logika bisnis — pricing, workflow, aturan lifecycle.
- Detail implementasi — nama variabel, urutan pemanggilan library, pembungkusan error.
Ketika AI membaca kode ini, ia tidak bisa membedakan baris mana yang keputusan dan mana yang detail. Jadi ketika “refactoring” atau “membersihkan”, ia diam-diam menimpa keputusan yang dikira detail. Pengguna baru sadar setelah perilakunya sudah salah.
Inilah mengapa vibe coding runtuh di 200 endpoint. Model yang lebih besar tidak menyelesaikannya. Medium — kode mentah — tidak menyimpan keputusan. Setiap model akhirnya menabrak tembok yang sama.
Lunas kapal
Lunas adalah tulang pertama yang diletakkan saat membangun kapal. Ia menahan berat lambung, mencegah oleng ke samping, dan semua struktur lainnya dibangun di atasnya. Kapal tanpa lunas mengapung di air tenang tapi melengkung saat ombak datang.
SaaS yang dibangun dengan vibe coding sama seperti itu. Mengapung saat kecil. Melengkung saat membesar.
yongol adalah lunas SaaS yang dikodekan AI.
Pindahkan keputusan keluar dari kode
Inti yongol sederhana. Pisahkan keputusan dari kode.
Sepuluh spesifikasi deklaratif (SSOT) masing-masing menangani satu concern:
| SSOT | Concern |
|---|---|
| features.yaml | Katalog fitur — apa yang akan dibangun |
| manifest.yaml | Konfigurasi proyek — autentikasi, middleware, infrastruktur |
| OpenAPI | Kontrak API — rute, parameter, respons |
| SQL DDL + sqlc | Model data — tabel, kolom, constraint, query |
| SSaC | Alur layanan — urutan keputusan di dalam endpoint |
| Rego | Otorisasi — siapa boleh melakukan apa |
| Mermaid stateDiagram | Transisi state — lifecycle entitas |
| FuncSpec | Fungsi kustom — logika yang tidak bisa diekspresikan sebagai CRUD |
| Hurl | Skenario pengujian — verifikasi runtime |
| STML | Frontend — struktur halaman dan data binding |
Delapan dari sepuluh adalah standar industri (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML). Hanya SSaC dan STML yang DSL buatan yongol. Yang harus dipelajari AI dari nol diminimalkan.
Setiap SSOT hanya berisi keputusan. Tanpa detail implementasi. AI mengedit SSOT; yongol generate merender kode darinya. Keputusan hidup permanen di SSOT; kode adalah proyeksi sekali pakai.
Memaksakan konsistensi
Keputusan sekarang tersebar di sepuluh file, jadi kontradiksi bisa muncul. DDL bilang BIGINT tapi OpenAPI bilang string? SSaC mendeklarasikan @auth tapi Rego tidak punya aturan yang cocok? Diagram state punya transisi tapi SSaC tidak punya fungsi yang sesuai?
SSOT yang bertentangan adalah keputusan yang rusak. Sebersih apa pun kodenya, jika keputusan bertentangan, perilakunya salah.
yongol validate menangkap ini.
✓ 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
Pertama memvalidasi setiap SSOT secara individual, kemudian menjalankan pemeriksaan silang antar lapisan. ~287 aturan memeriksa setiap referensi simbolik di antara kesepuluh SSOT. Jika ada satu kontradiksi, kompilasi ditolak.
AI menulis dengan bebas. Keluar dari rel, validate langsung menangkap. Kebebasan di atas rel.
operationId adalah batu kunci
Bagaimana mengikat sepuluh lapisan? Dengan satu identifier PascalCase.
Masukkan 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
Dari spesifikasi API ke skema database, dari kebijakan otorisasi ke transisi state, dari implementasi fungsi ke skenario pengujian — topologi lengkap satu fitur dalam satu layar. Puluhan grep digantikan satu perintah.
operationId adalah batu kunci karena dalam aplikasi full-stack, unit dari sebuah fitur adalah endpoint API. Pengguna menekan tombol, API dipanggil, dan API itu menembus setiap lapisan lainnya. Satu nama menghubungkan sepuluh lapisan secara fisik.
Benchmark: ZenFlow
ZenFlow — SaaS otomasi workflow multi-tenant. Claude Sonnet 4.6 menulis SSOT; yongol memvalidasinya.
| Tahap | Deskripsi | Waktu | Kumulatif |
|---|---|---|---|
| Build awal | multi-tenant, auth, state machine, 6 tabel, 10 endpoint | 23 mnt | 23 mnt |
| + Versioning | clone workflow, daftar versi, INSERT…SELECT salin aksi | 16 mnt | 39 mnt |
| + Webhook | publikasi event, CRUD webhook, backend antrian | 8 mnt | 47 mnt |
| + Marketplace template | pagination cursor, clone cross-org, endpoint publik | 7 mnt | 54 mnt |
| + Lampiran file | laporan eksekusi, backend file | 7 mnt | 61 mnt |
| + Penjadwalan | cron berbasis sesi, TTL | 10 mnt | 71 mnt |
| + Log audit | backend cache, pagination, filter | 6 mnt | 77 mnt |
| + Dashboard | API agregat, join relasi, tampilan detail | 14 mnt | 91 mnt |
| + Operasi batch | penyimpanan massal aksi, serialisasi JSON | 10 mnt | 101 mnt |
| + API eksternal | impor API geocoding, penyimpanan koordinat | 14 mnt | 115 mnt |
| + Pembaruan kondisional | penugasan otomatis, skor kepercayaan, percabangan kondisional | 16 mnt | 131 mnt |
Final: 30 endpoint, 12 tabel, 64 permintaan pengujian. Semua hijau.
Sepuluh fitur ditambahkan secara berurutan. Menambahkan fitur tidak pernah melambat. Tes yang ada tidak pernah rusak. Tembok 200 endpoint tidak ada.
Menjalankan spesifikasi yang sama dengan Opus: 30 endpoint, 73 permintaan pengujian, ~76 menit. Model berubah, rel tetap sama.
Mengapa model yang lebih besar bukan jawabannya
“GPT-6 akan menyelesaikan ini.”
Tidak akan. Masalahnya bukan kecerdasan model — tapi medium-nya.
Kode sebagai medium tidak membedakan keputusan dari implementasi. Model apa pun yang membaca kode melihat teks di mana keputusan dan detail bercampur. Sepintar apa pun modelnya, jika medium tidak menyediakan pembedaan, model tidak bisa membedakan.
yongol mengubah medium. Memindahkan apa yang diedit AI dari kode ke spesifikasi deklaratif. Karena spesifikasi hanya berisi keputusan tanpa detail implementasi, AI tidak pernah salah mengira keputusan sebagai detail. Kelangsungan keputusan menjadi independen dari ukuran model.
LLM kecil yang hanya mengedit SSOT, dengan validate memberikan feedback presisi di setiap kesalahan, bisa mempertahankan integritas keputusan yang sama dengan model jauh lebih besar yang mengedit kode mentah. yongol menjembatani kesenjangan itu.
Mulai
npx skills add park-jun-woo/yongol
Instal skill yongol ke agen AI Anda (Claude Code, Cursor, Copilot, dan lainnya). Agen mempelajari alur kerja secara otomatis saat instalasi.
Untuk menggunakan CLI langsung:
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.
Arahkan AI ke spesifikasi ini dan suruh tambahkan fitur. validate memasang rel; AI berlari di atasnya. Tidak ada tembok.
Artikel terkait
- SSaC — Service Sequences as Code — DSL batu kunci yongol. Mendeklarasikan keputusan di dalam endpoint.
- Feature Chain — Lacak Full Stack dengan Satu operationId — Melacak kedelapan lapisan melalui satu operationId.
- Ratchet Pattern — Cara Membuat Agen Menyelesaikan Tugasnya — Dasar teori bagaimana validate memberi feedback ke agen.