Sumber data dalam artikel ini: CodeRabbit 2025.12 / laporan New Relic 2026, Microsoft Work Trend Index 2026, pengumuman Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Studi kasus merupakan ringkasan skenario representatif, tidak merujuk pada perusahaan tertentu.

Kesalahan terbesar Anda bukan tidak membeli tools, tapi tidak menulis CLAUDE.md

Seorang CIO dari bank swasta mengeluh kepada saya: tools AI sudah dibeli, model sudah di-deploy, orang-orang sudah dilatih, tapi selama paruh pertama 2026, delivery cycle nyaris tidak bergerak. Lead tim core system bahkan lebih blak-blakan: “Kode yang ditulis AI memang bisa dipakai, tapi tiap kali harus ditulis ulang—AI-nya tidak paham aturan internal bank kami, tidak paham regulasi kepatuhan, tidak paham cara integrasi dengan sistem lama yang umurnya 30 tahun.”

Masalahnya bukan karena AI kurang canggih, melainkan karena kalian tidak menuliskan aturannya. Analisis CodeRabbit terhadap 470 pull request open-source pada Desember 2025 menghasilkan sejumlah angka yang banyak dikutip: PR kolaborasi AI rata-rata mengandung 10,83 masalah, sedangkan PR murni manual 6,45 — 1,7 kali lipat, 70% lebih banyak bug dibanding manual. Sampai 2026, ceritanya tidak berbalik: New Relic dalam 2026 State of AI Coding Report menemukan bahwa 78% tim melaporkan lebih banyak insiden setelah kode AI dirilis, dan 62% pemimpin teknis mengakui tim mereka “dengan percaya diri langsung mengirim kode AI tanpa meninjaunya baris per baris” (laporan resmi New Relic 2026, skor 0,866, sumber primer). Kedua kumpulan data ini menceritakan hal yang sama — AI tidak kekurangan kemampuan, yang kurang adalah konteks.

Pada titik waktu Agustus 2026 ini, semua narasi “percepatan transformasi AI” harus dilihat dalam satu kerangka perbandingan:

| Kategori | Kemajuan (2026 H1) | Kontra-contoh (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot diterapkan ke 150.000 karyawan, menghemat 2,5 juta jam / USD 250 juta; diperluas ke 400.000 karyawan global | Namun juga mengakui bahwa percepatan 95% dan penurunan 37% biaya operasional keuangan hanya berlaku jika “tata kelola diterapkan lebih dulu” |
| Atos | Diterapkan di 54 negara / 56.000 karyawan; menjalankan 19.000 agen AI secara bersamaan, dengan control plane terpadu untuk identitas/keamanan/kepatuhan/tata kelola | Berpegang teguh pada prinsip “naikkan kapabilitas tata kelola Agent 365 dulu, baru skalakan” |
| Microsoft sendiri | Work Trend Index 2026: 82% pemimpin berencana memperluas tenaga kerja dengan agen AI dalam 12–18 bulan | Pada periode yang sama mengakui bahwa “laju perubahan organisasi tertinggal dari adopsi individu” — ini adalah kontradiksi inti dalam konsep Frontier Firm |

Sumber: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Dua perbandingan ini menunjukkan satu hal: tanpa tata kelola, scaling sama saja dengan mengalikan risiko dengan N. Yang membuat EY/Atos/Microsoft bergerak “cepat” bukanlah kecepatan modelnya, melainkan karena “organisasi mereka sudah lebih dulu menjawab pertanyaan bagaimana memakai AI”. Inilah latar belakang mengapa Spec-Driven Development (SDD) benar-benar menjadi arus utama di H1 2026 — bukan karena engineer menyukai dokumentasi, tapi karena tanpa menulis spek, mustahil bertahan hidup di lingkungan yang dipenuhi 19.000 agen.

Artikel ini menjabarkan tiga hal: 1) mengapa cacat pada kode buatan AI 1,7 kali lebih parah daripada kode manual; 2) bagaimana lima platform — GitHub, AWS, OpenAI, Anthropic, dan Alibaba — pada H1 2026 bergerak menuju paradigma yang sama: menggunakan dokumentasi untuk mengendalikan perilaku AI; 3) mengapa spec-driven development adalah kapabilitas organisasi, bukan sekadar pilihan tools, serta tiga tahap implementasinya di H1 2026.

Bar length = AI defects as multiple of human; baseline 1.0× = human level

Baseline 1.0×

Total issues

1.7×
AI 10.83 vs human 6.45 / PR

Logic/correctness errors

1.75×

Code quality/maintainability

1.64×

Security findings (combined)

1.57×

Improper password handling

1.88×

XSS vulnerabilities

2.74×
↑ highest

Unconstrained AI code exceeds human on every dimension
Finance/telecom = compliance reconciliation, password management, sensitive field encryption — AI misses all

I. Tingkat Cacat AI Bukan Masalah Model, tapi Masalah Konteks

Ada satu kalimat dalam laporan CodeRabbit yang sering dikutip: “AI kekurangan logika bisnis lokal: model menyimpulkan pola kode secara statistik, bukan melalui pemahaman semantik. Tanpa batasan yang ketat, mereka akan melewatkan aturan sistem yang telah diinternalisasi oleh engineer senior.”

Kalimat ini menjelaskan mengapa platform pemrograman AI milik CodeRabbit sendiri (perusahaan yang khusus mengerjakan review kode berbasis AI) bisa melihat data ini lebih awal daripada yang lain — mereka memeriksa ribuan pull request setiap hari, dan setiap hari mereka melihat seperti apa kode yang ditulis AI. Temuan yang “paling krusial” bukanlah angka totalnya, melainkan distribusinya:

Logika/kebenaran +75%: error logika bisnis, error dependensi, error alur kontrol, error konfigurasi — masalah jenis ini mungkin tidak muncul saat pengujian, tapi bisa menyebabkan insiden di lingkungan produksi.
Kualitas kode +64%: penamaan yang tidak konsisten, struktur yang tidak jelas, pelanggaran pola proyek — ini adalah “kategori dengan perbedaan terbesar”. Engineer senior langsung bisa melihat “ini bukan gaya penulisan tim kita”.
Keamanan +57% (XSS tertinggi 2,74×): penanganan password yang tidak tepat (1,88×), referensi objek yang tidak aman (1,91×), kebocoran informasi sensitif, deserialisasi yang tidak aman (1,82×) — di industri keuangan, ini bukan soal “bisa dipakai atau tidak”, tapi soal “bisa dirilis atau tidak”.

Masalahnya bukan AI-nya yang kurang canggih. Masalahnya AI tidak bisa melihat.

Kembali ke titik hambatan nyata yang dihadapi CIO tersebut, ada tiga kegagalan konkret AI di sistem inti perbankan:

Pertama, AI tidak bisa melihat logika rekonsiliasi 30 tahun. Aturan manajemen risiko bank tertulis di stored procedure sistem inti—ditulis 30 tahun lalu, tidak ada yang ingat semuanya. Logika kode yang dihasilkan AI tampak benar, tapi di lingkungan produksi akan memicu pemeriksaan rekonsiliasi yang tidak diingat siapa pun itu, menyebabkan seluruh batch transaksi gagal.

Kedua, AI tidak bisa melihat batasan kepatuhan. Password wajib lewat key management system, field sensitif wajib dienkripsi saat disimpan, log tidak boleh mencetak informasi nasabah—ini batasan keras regulasi, tertulis di kebijakan internal. AI tidak tahu, kode yang ditulisnya bisa jalan tapi gagal lolos review kepatuhan.

Ketiga, AI tidak bisa melihat utang teknis Anda. Sistem host berusia 30 tahun itu memakai protokol antarmuka sendiri, dokumentasinya sudah hilang sejak lama. AI menulis kode sesuai standar RESTful umum, setelah rilis baru ketahuan antarmukanya tidak cocok—ulang dua minggu.

Kembali ke angka New Relic yang lain: 62% tim “percaya diri rilis tanpa review” kode AI, 78% melaporkan lebih banyak insiden setelah rilis. Dua angka ini digabungkan, artinya—tingkat cacat kode AI itu sendiri bukan masalahnya; “saya tidak tahu kode AI punya cacat apa” justru masalahnya.

Skenario umum: sebuah bank saham gabungan memperkenalkan AI untuk membantu pengembangan modul kontrol risiko pada sistem inti. Dalam tiga bulan, tingkat penolakan tinjauan kepatuhan meningkat signifikan. Masalah utamanya adalah aturan internal seperti manajemen kata sandi, enkripsi field sensitif, dan kepatuhan log. Aturan-aturan ini tertulis di dokumen internal, tetapi AI tidak dapat melihatnya. Belakangan, tim menulis aturan inti ke dalam CLAUDE.md, dan tingkat penolakan turun drastis.

II. Lima Platform pada H1 2026: “Berbasis Aturan” yang Menuju Arah yang Sama

Pada Juli 2025, GitHub merilis Spec Kit. Pada awal 2026, AWS Kiro, OpenAI Codex, dan Anthropic Claude Code semuanya melengkapinya. Pada Mei 2026, Alibaba Qoder memasukkan “Spec-Driven Workflow” ke dalam positioning produknya. Lima platform besar pada H1 2026 sampai pada paradigma yang sama—menggunakan dokumen untuk membatasi perilaku AI. Ini bukan penemuan dari satu perusahaan, melainkan respons kolektif industri terhadap “krisis kualitas kode AI”.

Mari kita lihat satu per satu aksi terbaru setiap platform pada H1 2026:

GitHub Spec Kit: Referensi Implementasi, Gerbang Lima Tahap. Dirilis open source pada September 2025, hingga H1 2026 telah menjadi referensi implementasi industri. 5 perintah inti + 2 pelengkap: /speckit.constitution (prinsip yang tidak bisa dinegosiasikan), /speckit.specify (apa yang akan dikerjakan dan mengapa), /speckit.plan (bagaimana mengubahnya), /speckit.tasks (memecah tugas), /speckit.implement (eksekusi), ditambah /clarify dan /analyze. Desain kuncinya adalah model-agnostic — file spec/plan/tasks yang sama tidak terikat pada agen eksekusi tertentu; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code semuanya bisa terhubung. Ini menjadikannya “protokol SDD tingkat organisasi”, bukan produk eksklusif GitHub (ulasan vibecoding.app 2026.6, skor 0.816, sumber sekunder).

AWS Kiro: Menanamkan Specification-Driven Langsung ke IDE. Dirilis Juli 2025, berevolusi menjadi Agent IDE penuh pada H1 2026. Alur kerja tiga tahap: Requirements → Design → Tasks. Bedanya dengan Spec Kit ada di “hooks”—file spec di Kiro bisa memicu aksi agen yang sudah didefinisikan, menanamkan langkah-langkah yang butuh sistem eksternal (seperti kepatuhan, audit, deployment) langsung ke dalam workflow. Kalau mau memaksa tim menulis spec, pilih Kiro—karena kalau kamu nggak nulis spec, Kiro nggak akan jalan (AWS Kiro official 2025.7; Kiro.dev docs 2026).

OpenAI Codex: AGENTS.md + Skills yang Dapat Dikombinasikan. Pada 2025–2026, AGENTS.md didorong menjadi pusat ekosistem pengembangan. Skills adalah perluasan kunci di paruh pertama 2026: alur kerja seperti “membaca file Excel,” “membuat SQL,” dan “menjalankan migrasi data” kini bisa dirangkai sebelumnya, lalu dipanggil seperti menyusun balok Lego. Hingga Juni 2026, pengguna aktif mingguan Codex telah menembus 5 juta, dan 20% di antaranya bukan developer — ini sinyal yang sering terlewat: pendekatan berbasis spesifikasi kini bukan hanya urusan tim engineering, melainkan semua orang. Tim produk, operasional, dan risk management pun ikut menulis AGENTS.md (pengumuman OpenAI, 2 Juni 2026; ulasan thebcms.com, 2026, skor 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic menyebut dokumen instruksi proyek sebagai CLAUDE.md (masuk pasar resmi Februari 2026), .claude/rules/ (aturan berlapis per direktori), dan Skills (alur kerja yang bisa dibagikan). Claude Code adalah tools dengan tingkat kepuasan developer tertinggi di 2026 H1 — survei JetBrains 2026.1 mencatat CSAT 91% dan NPS 54, didukung dua riset independen (Pragmatic Engineer 2026.2). Ini skor tertinggi di industri AI coding tools saat ini (uvik.net 2026.5, skor 0.956, agregasi sumber primer). Claude Code melesat dari nol ke pendapatan tahunan $2,5 miliar hanya dalam 9 bulan (data putaran Seri G Anthropic, 2026.2), dengan 112 ribu stars di GitHub (repositori Skills) — developer sudah memilih dengan kaki mereka, dan itu membuktikan nilai nyata dari pendekatan berbasis aturan.

Alibaba Qoder: Didorong Regulasi di Pasar Tiongkok. Dirilis pada Agustus 2025, Qoder ditingkatkan ke versi 1.0 pada 15 Mei 2026, resmi bertransformasi dari “AI IDE” menjadi “Autonomous Agent Development Workbench”. Workflow berbasis spesifikasi (Spec-Driven Workflow) ini diluncurkan bersamaan dengan Quest Mode (tugas multi-file otonom), Expert Mode (paralel tim ahli), dan RepoWiki (knowledge graph repositori). Cloud Agents (runtime agen terkelola penuh) hadir pada 28 Mei 2026, disusul Qoder Security (kemampuan kepatuhan keamanan) pada 21 Juli 2026, dan versi Mobile (Android/iOS/HarmonyOS) pada bulan yang sama. Hingga Mei 2026, pengguna globalnya telah melampaui 5 juta, dan DingTalk CLI mencantumkannya sebagai salah satu lingkungan eksekusi agen yang didukung (Yahoo Finance 2025; Alibaba Cloud Official 2026; Baidu Baike 2026.7).

Paradigma Bersama: Tuliskan secara eksplisit “bagaimana kita berkolaborasi dengan AI” sebagai dokumen, simpan di repositori, dan buat semua orang serta semua agen AI bekerja mengacu pada standar yang sama. Kelima platform memiliki detail implementasi yang berbeda (nama file/jumlah tahap/mekanisme hook), tetapi tujuannya persis sama.

Mengapa hal ini terjadi serentak pada H1 2026? Karena ambang batas kemampuan AI sudah terlewati—Claude Code sebagai agen otonom, Codex dengan multi-agen paralel, Cursor untuk refactoring multi-file. AI bukan lagi “alat pelengkapan kode”, melainkan “rekan kerja”. Dokumen orientasi yang Anda berikan untuk rekan baru, harus bisa juga dibaca oleh AI.

III. Standar-Driven adalah Kapabilitas Organisasi, Bukan Pilihan Tools

Ini poin terpenting bagi para pengambil keputusan. Standar-driven bukan soal memilih tools, tapi mendefinisikan “bagaimana organisasi kita berkolaborasi dengan AI”. Mau pakai GitHub Spec Kit atau Claude Code itu tidak penting. Yang penting: apakah Anda sudah menuliskan standar tersebut sebagai dokumen, memasukkannya ke repositori, dan membuat semua orang serta AI bekerja mengacu padanya.

Tanpa ini, tools secanggih apa pun hanya akan membuat tim Anda menghasilkan utang teknis lebih cepat.

Jika kita melihatnya dalam konteks deployment berskala besar pada H1 2026, buktinya jauh lebih kuat. Dalam retrospective FY26 yang dirilis Juli 2026, Microsoft menjadikan studi kasus EY dan Atos sebagai template “Frontier Firm”—bukan karena modelnya baru, melainkan karena kedua perusahaan ini lebih dulu menjawab pertanyaan “bagaimana cara menggunakan AI”:

EY: Governance lebih dulu, skalabilitas menyusul. Sepanjang 2024–2025, EY meluncurkan Microsoft 365 Copilot ke 150.000 karyawan, menghemat 2,5 juta jam dan sekitar US$250 juta. Kuncinya: kerangka tata kelola AI dibangun sebelum deployment. EY menggunakan Power Platform, Copilot Studio, Azure, Foundry, dan Fabric sebagai satu toolchain terpadu, dengan kepatuhan, regulasi, dan audit berada dalam satu fondasi yang sama. Hasilnya baru terlihat kemudian: percepatan 95%, penurunan biaya operasional finance sebesar 37%, dan pengurangan hingga 90% pada alur kerja manual. VP EY menyampaikannya dengan tegas di AI Tour 2026: “Kami tidak menyebarkan AI lalu menambal governance—kami membangun governance dulu, baru menyebarkan AI.”

Atos: Satu Bidang Kendali untuk 19.000 Agen. Atos adalah salah satu organisasi pertama di dunia yang menerapkan Microsoft 365 E7 (Frontier Suite), dengan Copilot yang digunakan oleh 56.000 karyawan di 54 negara. Mereka menjalankan 19.000 agen AI secara bersamaan—mulai dari IT internal, unit bisnis, hingga proyek klien, semuanya dibangun menggunakan Foundry dan Copilot Studio. Kunci keberhasilan Atos adalah “satu bidang kendali”: Entra (identitas) + Defender (keamanan) + Intune (perangkat) + Purview (kepatuhan) + Agent 365 (tata kelola agen), kelima komponen ini terikat menjadi satu kesatuan. Cara pengikatan ini, jika dipetakan ke industri keuangan, setara dengan “kepatuhan keamanan berlapis + penilaian transfer data lintas batas + registrasi algoritma + audit + tata kelola model”—ini adalah arsitektur tata kelola, bukan sekadar alat AI.

Paradoks Perubahan Organisasi ala Microsoft. Dalam laporan 2026 Work Trend Index, Microsoft sendiri mengakui satu hal: “ritme perubahan organisasi tertinggal dari adopsi individu.” Dari 20.000 pengguna AI yang mereka survei, 82% pemimpin berencana memperluas tenaga kerja dengan agen AI dalam 12–18 bulan ke depan, tetapi hanya 24% yang sudah menyelesaikan deployment di tingkat enterprise. 81% pemimpin memperkirakan agen AI akan terintegrasi secara moderat hingga masif ke dalam strategi AI mereka — tetapi lagi-lagi, hanya 24% yang benar-benar sudah melakukannya. Artinya, mayoritas perusahaan masih berada di jarak 12–18 bulan antara “berniat” dan “terwujud.” Pertanyaannya, bagaimana celah ini diisi? Pendekatan berbasis tata kelola (governance) menjadi penopang utamanya.

Sumber: Microsoft FY26 retrospective, 28 Juli 2026; Microsoft 2026 Work Trend Index Annual Report, 5 Mei 2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, sumber primer PDF); analisis Futurum Group, 26 Januari 2026 (sumber sekunder).

Implikasi pertama: investasi di tata kelola adalah ROI tinggi.

Data CodeRabbit memberikan dasar perhitungan ROI yang jelas: rasio masalah kode AI sekitar 1,7 kali lipat, kerentanan keamanan turun 2,74 kali lipat. Artinya:

Lebih sedikit pengerjaan ulang (di industri keuangan, satu kali review kepatuhan ulang bisa memakan waktu 2-4 minggu)
Lebih sedikit insiden keamanan (denda regulasi dan kerugian reputasi akibat satu kebocoran data)
Biaya pemeliharaan lebih rendah (pengurangan technical debt 40% adalah angka yang umum)

Menulis spesifikasi proyek CLAUDE.md/AGENTS.md adalah tindakan engineering dengan ROI tertinggi di era AI. Studi kasus EY memberikan konversi dunia nyata—150.000 orang menggunakan Copilot, menghemat USD 250 juta. Perlu dicatat: EY menghemat bukan karena “toolnya hebat”, melainkan karena “spesifikasi berhasil mewujudkan nilai dari tool tersebut.”

Pelajaran kedua: tuangkan spesifikasi ke dalam proses organisasi, jangan bergantung pada individu.

Jika spesifikasi hanya ada di kepala seorang engineer senior, begitu orangnya pindah, semuanya hilang. Spesifikasi harus diendapkan ke:

Dokumentasi repository (AGENTS.md / CLAUDE.md / constitution.md)
CI gating (memeriksa kepatuhan terhadap spesifikasi secara otomatis)
Konfigurasi bersama tim (sistem Skills memungkinkan seluruh tim menggunakannya)

Jadikan standar sebagai aset organisasi, bukan sekadar keterampilan individu. Ini sangat penting di industri keuangan—persyaratan kepatuhan, aturan keamanan, dan aturan bisnis kalian adalah aset tingkat organisasi, bukan sekadar “pengalaman” seorang engineer. 19.000 agen Atos bisa beroperasi di 54 negara karena tata kelolanya bukan soal “siapa yang paham”, melainkan “sistem yang memaksa”.

Pelajaran ketiga: Gerbang kendali (gate) lebih penting daripada kecepatan.

Gerbang kendali lima tahap GitHub Spec Kit (constitution → specify → plan → tasks → implement), aturan Claude Code “tidak menulis kode sebelum tes gagal”, dan Kiro yang “tidak bisa dimulai tanpa spec”—semuanya melakukan hal yang sama: menambahkan “rem” antara AI dan hasil akhir. Setiap langkah memiliki artefak yang bisa diaudit (spec.md, plan.md, tasks.md), dan semuanya bisa diveto atau diubah sebelum kode dibuat.

Semakin otonom AI-nya, semakin butuh gerbang kendali. Change Advisory Board (CAB) di industri keuangan, proses registrasi algoritma, dan evaluasi keamanan berlapis (dengbao)—pada dasarnya semuanya menambahkan gerbang kendali sebelum produksi. Kode AI juga butuh gerbang kendali serupa, hanya saja bentuknya berbeda. Tim yang 62% “percaya diri mengirim tanpa review” dalam laporan New Relic 2026 itu, sedang membayar mahal kepercayaan diri tersebut dengan tingkat insiden yang lebih tinggi (78%).

Fase Pertama Paling Memakan Waktu, tetapi ROI Tertinggi
Sebagian Besar Aturan Organisasi Keuangan Tersebar di Dokumen/Email/Otak Manusia, Investasi Pertama 3-8 Minggu

Empat, Tiga Tahap Implementasi Nyata pada H1 2026

Dengan mengambil industri keuangan sebagai contoh, jalur tiga tahap ini juga dapat menjadi referensi bagi industri lain yang memiliki regulasi ketat. Praktik EY dan Atos pada H1 2026 kebetulan sejalan dengan ketiga tahap tersebut.

Tahap Pertama: Inventarisasi Aturan (2–4 minggu).

Ini adalah tahap yang paling memakan waktu, tetapi ROI-nya paling tinggi. Tugasnya adalah mengumpulkan semua aturan yang tersebar di berbagai tempat:

Kepatuhan regulasi: baseline minimum untuk industri keuangan = standar keamanan siber BSSN (standar nasional untuk keamanan siber) + penilaian transfer data lintas batas + pendaftaran algoritma di Kominfo (jika satu saja tidak terpenuhi, jangan mulai menerapkan AI), ditambah aturan pelaporan regulasi, perlindungan data nasabah, pembatasan transfer data lintas negara, dan ketentuan data apa saja yang boleh diakses oleh AI
Aturan keamanan: manajemen kata sandi, standar enkripsi, penanganan kolom data sensitif, persyaratan log
Aturan bisnis: ambang batas manajemen risiko, ketentuan klaim, batasan transaksi, logika penagihan
Kendala teknis: antarmuka sistem lama, penamaan basis data, batasan versi framework
Tata kelola vendor: bagaimana mewajibkan vendor mematuhi standar kita dalam kontrak, bagaimana mengaudit penggunaan AI oleh vendor

Skenario umum: pada tahap inventarisasi, sebuah perusahaan sekuritas menemukan bahwa aturan-aturan tersebar di banyak dokumen Word, wiki JIRA, email pribadi, dan spreadsheet Excel — baru setelah dirapikan, mereka mendapatkan daftar aturan yang terstruktur. Pendekatan Atos lebih sistematis — mereka langsung memecah aturan ke dalam lima kategori: “kepatuhan, keamanan, bisnis, teknis, vendor”, masing-masing dengan alur kerja tata kelola sendiri, dan terhubung ke bidang kontrol Agent 365.

Ini bukan soal teknis, melainkan soal organisasi — Anda harus membawa departemen kepatuhan, departemen keamanan, dan departemen bisnis ke satu meja, lalu menuliskan aturan yang disepakati semua pihak. Untuk pertama kalinya, organisasi finansial biasanya membutuhkan 3–8 minggu — tetapi ini adalah aset organisasi yang permanen.

Tahap kedua: masukkan ke repositori (1–2 minggu).

Tulis aturan yang telah dirapikan pada tahap pertama menjadi dokumen dan masukkan ke repositori. GitHub Spec Kit menggunakan constitution.md, Claude Code menggunakan CLAUDE.md, OpenAI Codex menggunakan AGENTS.md, dan Alibaba Qoder menggunakan Spec Workflow. Nama file berbeda, tujuannya sama — memastikan AI memuatnya begitu repositori dibuka.

Struktur yang Disarankan (Bentuk Umum untuk Paruh Pertama 2026):

Ringkasan Proyek: Sistem ini digunakan untuk apa, dan siapa yang dilayaninya
Prinsip yang Tidak Dapat Ditawar: Batas keamanan, batas kepatuhan, batas bisnis
Tumpukan Teknologi dan Batasan: Framework apa, database apa, standar antarmuka apa
Standar Kode: Konvensi penamaan, struktur direktori, persyaratan minimum cakupan pengujian (tidak mewajibkan ritme TDD—cukup tuliskan persentase cakupan pengujian, jalur yang wajib diuji, dan jalur terlarang; TDD adalah ritme opsional bagi organisasi, bukan kewajiban yang didorong standar)
Aturan Bisnis: Logika manajemen risiko, aturan transaksi, aturan penagihan
Persyaratan Kepatuhan: standar keamanan siber BSSN (perlindungan berlapis), transfer data lintas batas, pelaporan regulatori, apakah algoritma yang dihasilkan AI perlu pendaftaran
Pedoman Penggunaan AI: Skenario apa yang boleh menggunakan AI, skenario apa yang wajib ditinjau manual, aturan transfer data lintas batas
Tata Kelola Vendor: Klausul kontrak, mekanisme audit, pembagian tanggung jawab

Lampiran: Kerangka CLAUDE.md Versi Perbankan (sekitar 200 baris, bisa langsung di-fork dan dimodifikasi)

Berikut adalah kerangka CLAUDE.md untuk proyek modernisasi sistem inti bank saham gabungan, yang telah disusun dengan urutan “Prinsip yang Tidak Dapat Ditawar → Persyaratan Kepatuhan → Pedoman Penggunaan AI → Aturan Bisnis → Batasan Teknik”. Perusahaan Anda tidak perlu memulai dari nol—cukup isi slot kosongnya dengan aturan spesifik Anda.

# CLAUDE.md — <Nama Sistem> Standar Kolaborasi AI

> Cakupan: <Nama Sistem> v<Versi>, semua agen AI (Claude Code / Cursor / Copilot / Codex)
> yang bekerja di repositori ini wajib mematuhi standar ini. Dokumen ini dikelola oleh <Komite Tata Kelola>, ditinjau setiap kuartal.
> Pembaruan terakhir: YYYY-MM-DD

## 1. Gambaran Proyek
- **Posisi Bisnis**: nama sistem inti / segmen pelanggan yang dilayani / jenis transaksi utama
- **Rantai Kritis**: transaksi → manajemen risiko → kliring → rekonsiliasi → pelaporan
- **Jendela Tidak Tersedia**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (dilarang keras melakukan perubahan apa pun)
- **Dependensi Inti**: hulu <Sistem>, hilir <Sistem>, platform pelaporan regulator

## 2. Prinsip Tidak Dapat Ditawar (Garis Merah, Pelanggaran = Penolakan Penggabungan)

### 2.1 Garis Merah Keamanan
- Kata sandi, kunci, dan Token wajib melewati KMS (Key Management Service), **dilarang keras hardcoding**, **dilarang keras mencetak di log**
- Kolom sensitif pelanggan (KTP / nomor kartu / CVV / nomor ponsel) **wajib dienkripsi saat disimpan**, teks polos dilarang masuk basis data
- Log tidak boleh memuat: KTP lengkap, nomor kartu lengkap, kata sandi teks polos, kombinasi nama pelanggan + nomor ponsel
- Pemanggilan API eksternal wajib melewati API Gateway, koneksi langsung dilarang

### 2.2 Garis Merah Kepatuhan
- Kode yang dihasilkan AI yang mengakses data pelanggan wajib mencantumkan label "Akses Data: <Kolom>" di deskripsi PR
- Transfer data lintas batas dilarang, **semua pengiriman data ke luar negeri wajib melalui Penilaian Transfer Data Lintas Batas** (hubungi departemen kepatuhan)
- Keputusan algoritmik (kredit / penetapan harga asuransi / antipenipuan) wajib mempertahankan jalur tinjauan ulang manusia
- Perubahan model wajib melalui Pendaftaran Algoritma, nomor pendaftaran wajib dirujuk di deskripsi PR

### 2.3 Garis Merah Bisnis
- Perubahan ambang batas manajemen risiko memerlukan tanda tangan ganda dari penanggung jawab manajemen risiko + penanggung jawab bisnis
- Operasi yang melibatkan dana pelanggan wajib memiliki desain idempoten + mekanisme rollback saat gagal
- Perubahan batas transaksi, tarif, dan parameter produk melewati platform manajemen parameter, tidak di-hardcode dalam kode

## 3. Tumpukan Teknologi dan Batasan
- **Bahasa**: Java 17 (inti) / Kotlin (modul baru) / SQL (basis data)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Basis Data**: OceanBase 4.x (mode kompatibel MySQL), **dilarang menggunakan foreign key**
- **Standar Antarmuka**: internal wajib gRPC; antarmuka eksternal OpenAPI 3.0; RESTful hanya untuk antarmuka manajemen
- **Konvensi Penamaan**: kelas Java PascalCase, metode camelCase, konstanta UPPER_SNAKE; nama tabel `t_<Domain Bisnis>_<Entitas>`; indeks `idx_<Tabel>_<Kolom>_<Urutan>`
- **Struktur Paket**: `com.<Perusahaan>.<Domain Bisnis>.<Subdomain>.<Lapisan>` (misal `com.bank.pay.tx.core.service`)

## 4. Standar Kode
- **Cakupan Uji Minimum**: rantai kritis ≥ 80%, kelas utilitas ≥ 60%, PR kode baru wajib menyertakan pengujian
- **Jalur Wajib Diuji**: semua controller wajib memiliki integration test (termasuk jalur gagal); semua cabang enum wajib memiliki unit test
- **Jalur Terlarang**: dilarang memodifikasi direktori `<Modul Warisan>` — harus membangun lapisan adaptasi terlebih dahulu
- **Manajemen Dependensi**: penambahan dependensi pihak ketiga wajib melalui pemindaian SCA + persetujuan keamanan

## 5. Aturan Bisnis (per Domain)
### 5.1 Transaksi
- Batas per transaksi: <Jumlah>; batas harian: <Jumlah>; melampaui batas wajib melalui persetujuan manual
- Jendela waktu transaksi: <HH:MM> ~ <HH:MM>
- Penentuan transaksi duplikat: <Jendela Waktu> dengan <Kolom> yang sama dianggap duplikat

### 5.2 Manajemen Risiko
- Prioritas pencocokan daftar hitam: daftar hitam internal → daftar yang diterbitkan regulator → pembekuan yudisial
- Ambang batas output model antipenipuan: <Skor>; jika terlampaui wajib tinjauan ulang manual tingkat dua

### 5.3 Penagihan
- Perubahan tarif wajib memiliki nomor versi + waktu berlaku
- Pesanan historis dihitung berdasarkan tarif yang berlaku pada saat berlaku, tanpa surut-danik

## 6. Persyaratan Kepatuhan
- MLPS Level 3: <Lembaga Penilaian>, <Tanggal Penilaian Berikutnya>
- Penilaian Transfer Data Lintas Batas: cakupan (hanya modul bisnis lintas batas)
- Pendaftaran Algoritma: cakupan (algoritma kunci seperti kredit / penetapan harga asuransi), nomor pendaftaran `<No. Pendaftaran>`
- Pelaporan Regulator: tabel pemetaan kolom CBIRC / Bank Rakyat Tiongkok di `<Jalur>`

## 7. Standar Penggunaan AI
- **Skenario yang Diizinkan Menggunakan AI**: templat CRUD, pembuatan unit test, draf dokumen, saran optimasi SQL
- **Skenario yang Wajib Tinjauan Manual**: logika manajemen risiko, aturan penagihan, kontrol izin, enkripsi/dekripsi, data lintas batas
- **Skenario yang Dilarang Dikerjakan AI Sendirian**: material persetujuan CAB, eksekusi perubahan produksi, tanggap darurat
- **Aturan Data Lintas Batas**: data pelatihan / prompt / log output sama sekali tidak boleh keluar negeri; versi deployment lokal (<Vendor>) diprioritaskan
- **Persyaratan Audit**: semua kode yang dihasilkan AI wajib ditandai "Bantuan AI: <Nama Alat>" di deskripsi PR

## 8. Tata Kelola Vendor
- **Penerimaan Vendor**: wajib menyediakan laporan SOC 2 / ISO 27001; model AI wajib menyediakan model card
- **Klausul Kontrak**: kepemilikan data, interpretabilitas model, klausul keluar, hak audit
- **Mekanisme Audit**: audit penggunaan AI vendor per kuartal; vendor berisiko tinggi diaudit per bulan

## 9. Tata Kelola dan Pembaruan
- **Pemilik**: <Komite Tata Kelola> (kepatuhan + keamanan + arsitektur + bisnis)
- **Frekuensi Pembaruan**: tinjauan per kuartal; perubahan darurat melalui jalur cepat (tanda tangan ganda + pengumuman 24 jam)
- **Log Perubahan**: lihat `CLAUDE_CHANGELOG.md`
- **Penanganan Pelanggaran**: pelanggaran pertama = peringatan + pelatihan wajib; pelanggaran kedua = penangguhan penggunaan alat AI; pelanggaran ketiga = pencabutan hak akses

Kerangka ini bukanlah “jawaban standar”, melainkan “template yang harus diisi”. Apa yang diisi di setiap slot kosong jauh lebih penting daripada seberapa banyak yang ditulis—bagian yang kosong justru memperlihatkan bagian mana dari perusahaan Anda yang “belum dipikirkan matang”.

Contoh tipikal: CLAUDE.md di sebuah bank saham gabungan secara khusus mendefinisikan aturan penanganan password—ketika AI menghasilkan kode yang melibatkan password, kode tersebut wajib memanggil API manajemen kunci internal, dan hardcoding dilarang. Aturan semacam ini menyumbang proporsi yang sangat tinggi dalam alasan penolakan review kepatuhan.

Satu field penting baru di H1 2026 adalah Skills/definisi alur kerja—bukan sekadar dokumen, melainkan rantai alat yang bisa dipanggil oleh AI. Sistem Skills milik Claude Code (masuk ke pasar resmi Anthropic pada Februari 2026, 112 ribu stars di GitHub) mengubah proses-proses seperti “membaca file Excel”, “membuat SQL”, dan “menjalankan migrasi data” menjadi alur kerja yang bisa dibagikan. Ini adalah evolusi kunci dari pendekatan berbasis aturan di H1 2026: aturan bukan sekadar batasan, melainkan alur kerja yang bisa dieksekusi.

Tahap ketiga: Institusionalisasi (berkelanjutan).

Menulis standar bukanlah akhir, melainkan awal. Anda harus mengubahnya menjadi bagian dari proses organisasi:

Integrasi gerbang CI: Periksa secara otomatis apakah kode mematuhi standar (misalnya mendeteksi hardcoded password, field sensitif yang tidak dienkripsi)
Konfigurasi bersama tim: Gunakan sistem Skills agar seluruh tim dapat memakai standar yang sama
Mekanisme pembaruan berkala: Jika aturan berubah, standar pun harus ikut berubah (review kuartalan)
Metrik dan umpan balik: Lacak tingkat defek kode AI, tingkat kelulusan review kepatuhan, dan tingkat pengerjaan ulang
Tata kelola agen: Perluas tata kelola dari manusia ke agen AI — yang dilakukan Atos di Agent 365 adalah menjadikannya “tingkat sistem” bukan “tingkat individu”

EY dan Atos di H1 2026 sama-sama menjadikan fase ketiga sebagai “kapabilitas organisasi”. Penghematan 2,5 juta jam EY terjadi karena fase pertama dan ketiga dieksekusi dengan benar — fase kedua hanyalah menerjemahkan aturan menjadi dokumen yang bisa dibaca AI.

Lima: Varian Regulasi Ketat: Tiga Pendekatan Rekayasa untuk Menanamkan Kepatuhan

Industri dengan regulasi ketat seperti keuangan, telekomunikasi, dan kesehatan memiliki satu tantangan ekstra dalam implementasi berbasis standar — kepatuhan bukan pelengkap proses, melainkan tertanam dalam kode. Tiga pendekatan di bawah ini adalah cara penanaman kepatuhan yang telah teruji di H1 2026, dan dapat langsung dijadikan referensi oleh CIO/direktur digital saat merancang organisasi.

5.1 Menanamkan Perwakilan Kepatuhan dalam Stream Team: Membuat Kepatuhan “Hadir di Lapangan”, Bukan Sekadar “Menunggu Persetujuan”

Pendekatan tradisional: tim bisnis menulis kode, tim kepatuhan melakukan review setelahnya—saat masalah ditemukan dalam review, kode sudah berjalan di produksi selama dua minggu, dan biaya pengerjaan ulang mencapai 2-4 minggu. Akar masalahnya adalah kepatuhan berada di ujung akhir proses.

Pendekatan baru: tanamkan perwakilan kepatuhan di setiap stream-aligned team, dengan struktur pelaporan ganda—“garis solid” ke departemen kepatuhan dan “garis putus-putus” ke tim bisnis. Desainnya sebagai berikut:

Alokasi SDM: 1 perwakilan kepatuhan untuk setiap 6-8 stream team, secara organisasi berada di bawah departemen kepatuhan, tetapi secara fisik duduk bersama tim bisnis—bukan sekadar “pinjaman” ala tugas luar
KPI Garis Putus-Putus: 50% bobot KPI perwakilan kepatuhan dikaitkan dengan “tingkat cacat kepatuhan” dan “tingkat lolos review sekali jalan” milik tim bisnis, bukan hanya “cakupan audit” dari departemen kepatuhan
Intervensi Dini: perwakilan kepatuhan ikut serta dalam daily stand-up (cukup seminggu sekali), review pull request, dan kode yang dihasilkan AI wajib melewati perwakilan kepatuhan sebelum di-merge—bukan ketahuan setelah merge lalu diperbaiki belakangan
Dukungan Tools: perwakilan kepatuhan menggunakan Skills untuk memanggil checklist kepatuhan, bukan memeriksa satu per satu secara manual

5.2 Menjadikan Kepatuhan sebagai Enabling Team: Mengubah Kendala Menjadi Affordance

Pendekatan tradisional: tim kepatuhan berperan sebagai “penjaga gerbang,” sementara tim bisnis menganggap kepatuhan sebagai “pembuat masalah.” Kedua belah pihak berada dalam permainan zero-sum.

Pendekatan baru: tim kepatuhan direstrukturisasi mengikuti pola enabling team dari Team Topologies — tidak menulis kode secara langsung, tidak meninjau pull request secara langsung, tetapi menyediakan tiga hal agar tim bisnis dapat “mematuhi secara mandiri”:

Pemeriksaan kepatuhan dalam pipeline CI: membungkus titik-titik risiko tinggi seperti hardcoded password, penyimpanan plaintext pada field sensitif, transfer data lintas batas, dan titik keputusan algoritma ke dalam gerbang wajib (mandatory gate) di GitHub Actions / GitLab CI. Begitu pull request tim bisnis memicu, sistem otomatis menjalankan pemeriksaan; jika tidak patuh langsung fail — tidak perlu perwakilan kepatuhan menjalankannya secara manual.
Mengubah persyaratan regulatori menjadi affordance (kendala responsif lingkungan): misalnya, ketika fitur yang berkaitan dengan data nasabah dikembangkan, plugin IDE akan memunculkan notifikasi “kolom ini sebaiknya memanggil KMS”; ketika menulis log, secara otomatis mendeteksi apakah memuat informasi sensitif dan mengeluarkan peringatan. Membuat persyaratan kepatuhan menjadi “tindakan yang terjadi secara natural selama proses pengembangan”, bukan “baru diberitahu melanggar aturan apa tepat sebelum peluncuran”.
Perpustakaan Skills bersama + pelatihan kepatuhan: tim kepatuhan mengelola satu set “Skills kepatuhan” yang bisa dipanggil langsung oleh karyawan baru saat orientasi atau saat pindah antar-tim — mengubah pengetahuan kepatuhan dari “dokumen” menjadi “alat yang bisa dieksekusi”.

Skenario tipikal: sebuah bank kota (city commercial bank) di Indonesia pada paruh pertama 2026 menerapkan gerbang kepatuhan CI + notifikasi kepatuhan IDE, menurunkan waktu rata-rata per orang untuk tinjauan kepatuhan kode AI dari 45 menit/tinjauan menjadi 8 menit/tinjauan. Intinya bukan kepatuhan “tinjauan menjadi lebih cepat”, melainkan ketika AI menghasilkan kode, secara inheren “tidak membuat kesalahan”.

5.3 Kepatuhan Dua Kecepatan: Melapisi Aturan agar Selaras dengan Ritme Bisnis

Detail terakhir: kepatuhan tidak boleh diseragamkan dengan “satu ukuran untuk semua”. Bagi aturan ke dalam dua tingkat berdasarkan tingkat risikonya:

Aturan berisiko tinggi (melibatkan dana nasabah / keputusan algoritmik / data lintas batas / garis merah keamanan siber) menggunakan pintu gerbang ketat: wajib review manual + konfirmasi kedua oleh AI + pencatatan di Change Advisory Board (CAB)
Aturan berisiko rendah (template CRUD / kode perkakas / pembuatan dokumen) menggunakan pintu gerbang layanan mandiri: cukup pemeriksaan otomatis CI, tanpa review manual

Bidang kendali Agent 365 dari Atos pada dasarnya adalah pelapisan semacam ini—agen dengan tingkat berbeda terikat pada persyaratan tata kelola yang berbeda. Dengan melapisi aturan kepatuhan berdasarkan risiko, tim bisnis akan merasakan bahwa “kepatuhan tidak menghambat di mana-mana”.

Skenario tipikal: sebuah bank daerah di Indonesia pada paruh pertama 2026 menerapkan gerbang kepatuhan CI + peringatan kepatuhan IDE, menurunkan waktu rata-rata tinjauan kepatuhan kode AI dari 45 menit per tinjauan menjadi 8 menit per tinjauan. Nilai intinya bukan kepatuhan “tinjauan menjadi lebih cepat”, melainkan ketika AI menghasilkan kode, secara inheren “tidak membuat kesalahan”.

Kesimpulan dari ketiga hal ini secara bersamaan: kepatuhan yang tertanam bukanlah menambah satu proses, melainkan mendesain ulang struktur dan insentif tim. Jika bagian kepatuhan Anda masih dalam mode “review setelah kejadian”, penerapan berbasis aturan akan tersendat di tahap “pelembagaan” yang paling sulit—bagian kepatuhan harus bertransformasi lebih dulu, baru tim bisnis bisa berjalan lancar dengan pendekatan berbasis aturan.

Enam, Pertanyaan yang Mungkin Anda Ajukan

“Kami sudah punya standar pengkodean, apa bedanya dengan ini?”

Standar pengkodean mengatur “cara menulis kode”, sedangkan pendekatan berbasis aturan mengatur “cara berkolaborasi dengan AI”. Standar pengkodean tidak mencakup: aturan bisnis, persyaratan kepatuhan, kebijakan penggunaan AI. Pendekatan berbasis aturan adalah mengeksplisitkan “seluruh alur kolaborasi manusia dan AI”, bukan sekadar panduan gaya kode.

“Apakah menulis standar akan memperlambat kecepatan pengembangan?”

Dalam jangka pendek, ya. Dalam jangka panjang, tidak. Data dari CodeRabbit memberikan jawaban yang jelas: kode AI tanpa batasan memiliki risiko cacat sekitar 1,7 kali lebih tinggi, dan kerentanan keamanan 2,74 kali lebih tinggi. Di industri keuangan, satu kali pengerjaan ulang akibat audit kepatuhan memakan waktu 2-4 minggu — menghemat satu kali pengerjaan ulang saja sudah cukup untuk membayar biaya menulis standar selama sebulan. Penghematan US$250 juta yang dicapai EY adalah bukti nyata bahwa ini bisa menjadi kapabilitas organisasi jika dikelola dengan serius.

“Bagaimana kalau tim kami tidak ada yang bisa menulis standar?”

Tidak perlu memulai dari nol. GitHub Spec Kit, Claude Code Superpowers, dan AWS Kiro semuanya menyediakan template. Anda tinggal mengisi aturan spesifik organisasi Anda — sebagian besar adalah aturan kepatuhan dan keamanan yang sebenarnya sudah lama disusun oleh departemen compliance dan keamanan, hanya saja belum pernah ditaruh di tempat yang bisa diakses oleh AI.

“Banyak sekali tools AI, harus pilih yang mana?”

Tidak penting. Pilih saja yang sudah kalian pakai. Standar yang digerakkan oleh aturan tidak terikat pada alat tertentu — CLAUDE.md bisa dipakai di Claude Code, Cursor, maupun Codex; AGENTS.md berjalan di ekosistem OpenAI; constitution.md tidak bergantung pada model apa pun. Kuncinya adalah menulis standarnya, bukan ganti alat. EY menerapkannya di ekosistem Microsoft, Atos juga menerapkannya di ekosistem Microsoft — perbedaan pilihan alat hanyalah kulit luar; keseragaman tata kelola itulah inti sebenarnya.

“EU AI Act mulai berlaku penuh pada Agustus 2026, apakah ini berdampak pada kita?”

Ada. EU AI Act memasuki tahap implementasi penuh pada 2 Agustus 2026, dengan persyaratan kepatuhan wajib untuk sistem AI berisiko tinggi—termasuk kredit, penetapan harga asuransi, penyaringan tenaga kerja, dan infrastruktur penting—mencakup manajemen risiko (Art. 9), tata kelola data (Art. 10), transparansi dokumentasi (Art. 11–13), pengawasan manusia (Art. 14), serta akurasi dan ketahanan sistem (Art. 15). Denda maksimum mencapai €35 juta atau 7% dari pendapatan global. Bagi perusahaan Tiongkok yang berekspansi ke luar negeri, pasar Uni Eropa adalah ujian wajib; bagi perusahaan domestik, kerangka EU AI Act juga menjadi standar yang paling banyak dirujuk secara global—Anda mungkin tidak wajib mematuhinya secara langsung, tetapi sulit untuk menghindari efek transmisinya terhadap pemasok, mitra, dan operasi lintas batas Anda (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Perbandingan domestik: UE mengatur AI, kita mengatur apa?”

Di dalam negeri, tata kelola AI generatif berjalan melalui tiga pilar: “pendaftaran algoritma + pemeriksaan korpus data + penilaian keamanan”, dengan Regulasi Sementara tentang Pengelolaan Layanan AI Generatif yang berlaku sejak Agustus 2023 sebagai instrumen utamanya. Perbedaan terbesar antara keduanya bukan terletak pada ketebalan pasal-pasalnya, melainkan pada filosofi legislatif masing-masing.

Dimensi	EU AI Act	Tiongkok “Langkah-Langkah Pengelolaan Layanan AI Generatif”
Posisi Hukum	Regulasi horizontal (berlaku untuk semua sistem AI)	Regulasi vertikal (berfokus pada layanan AI generatif)
Tingkat Risiko	4 tingkat (tidak dapat diterima / tinggi / terbatas / minimal)	2 tingkat (terkait keamanan opini publik / komersial umum)
Titik Pengawasan	Di muka (pendaftaran sejak tahap pengembangan)	Di belakang (pendaftaran setelah peluncuran + pendaftaran algoritma)
Transparansi	Tinggi (wajib memublikasikan ringkasan sumber data pelatihan, model card)	Sedang (wajib kepatuhan korpus tetapi tidak diwajibkan mengungkapkan sumber)
Batas Denda	7% pendapatan global atau €35 juta	Penghentian layanan / denda (biasanya kelipatan dari keuntungan ilegal)
Cakupan Penerapan	Semua perusahaan dalam ambang pendapatan global	Semua entitas yang menyediakan layanan di wilayah Tiongkok

Dalam praktiknya, sistem AI di institusi keuangan Indonesia umumnya terikat oleh tiga lapis regulasi sekaligus — UU PDP No. 27/2022 tentang Perlindungan Data Pribadi (lapisan fundamental) + UU ITE 2008/2016 junto PP 71/2019 tentang Penyelenggaraan Sistem Elektronik (lapisan bisnis) + standar keamanan siber BSSN dan regulasi algoritma Kominfo (lapisan kepatuhan). Ini berarti untuk membangun tata kelola berbasis regulasi di Indonesia, kita tidak bisa sekadar menyalin kerangka EU AI Act — ketiga jalur kepatuhan domestik, yaitu “perlindungan data pribadi + pendaftaran algoritma + pelaporan regulatori”, semuanya harus dituangkan ke dalam CLAUDE.md.

Bagi perusahaan Indonesia yang berekspansi ke Uni Eropa: empat pilar EU AI Act — “manajemen risiko + tata kelola data + transparansi dokumentasi + pengawasan manusia” — juga merupakan arah yang secara bertahap diadopsi oleh regulator Indonesia, baik Kominfo maupun BSSN. Beberapa pedoman tata kelola AI yang dikeluarkan Kominfo pada 2025 sudah menunjukkan tingkat granularitas yang serupa dengan standar Eropa, dan Komnas PDP semakin sering menyelaraskan panduannya dengan praktik internasional. Standar yang kompatibel dengan EU AI Act yang Anda tulis hari ini, kemungkinan besar juga akan kompatibel dengan tren regulasi domestik yang semakin ketat dalam 3 tahun ke depan (pedoman AI Kominfo 2025–2026; kepatuhan EU AI Act berlaku Juni 2026).

7. Implikasi bagi Para Pengambil Keputusan

Implikasi pertama: menulis standar proyek dalam bentuk CLAUDE.md/AGENTS.md adalah investasi rekayasa dengan ROI tertinggi di era AI.

Investasinya adalah 3–8 minggu waktu perapihan + 1–2 minggu waktu dokumentasi. Imbalannya: batas atas risiko cacat sekitar 1,7×, kerentanan keamanan turun 2,74×, dan tingkat pengerjaan ulang turun 40%+. Di industri keuangan, menghemat satu kali pengerjaan ulang review kepatuhan (2–4 minggu) saja sudah cukup untuk menutup biaya ini. EY memakai Copilot untuk 150.000 karyawannya dan menghemat USD 250 juta—tapi itu semua berawal dari adanya standar yang jelas.

Pelajaran kedua: Standar adalah kapabilitas organisasi, bukan sekadar pilihan tools.

Mau pilih GitHub Spec Kit atau Claude Code itu tidak penting. Yang penting: apakah kamu sudah mendefinisikan “bagaimana organisasi kita berkolaborasi dengan AI”? Tanpa itu, tools secanggih apa pun hanya membuat tim menumpuk utang teknis lebih cepat.

Pelajaran ketiga: Tuangkan standar ke dalam proses organisasi, jangan bergantung pada individu.

Kalau standar cuma ada di kepala satu engineer senior, begitu orangnya pindah, semuanya hilang. Standar harus dikristalisasi ke dalam dokumentasi repo, CI gating, konfigurasi bersama tim, dan platform tata kelola agen. Jadikan standar sebagai aset organisasi, bukan keterampilan pribadi. 19.000 agen Atos bisa berjalan di 54 negara karena tata kelolanya bukan soal “ada orang yang paham”, melainkan “sistem yang memaksa”.

Pelajaran keempat: Gating lebih penting daripada kecepatan.

Gerbang lima tahap GitHub Spec Kit, prinsip Superpowers “tidak menulis kode sebelum tes gagal”, dan Kiro yang “tidak bisa dijalankan tanpa spec”—semuanya menambahkan “rem” antara AI dan hasil akhir. Semakin kuat kemampuan AI, semakin awal tata kelola harus diterapkan. Angka 78% tingkat insiden dalam laporan New Relic 2026 adalah harga yang dibayar oleh 62% tim yang “rilis tanpa review”. CIO di industri keuangan paling paham hal ini: Change Advisory Board (CAB), proses pendaftaran algoritma di Kominfo, dan asesmen keamanan siber BSSN—semuanya menambahkan gerbang kendali sebelum produksi. Kode AI juga membutuhkan gerbang kendali serupa, dan harus lebih upfront (lebih di depan).

Self-check terbalik (jangan mempercantik jawaban): apakah kode yang dihasilkan AI di tim Anda sering dikembalikan oleh tinjauan kepatuhan? Masalah apa yang terakhir kali ditimbulkan oleh kode AI? Jika Anda bertanya kepada pemimpin teknis “bagaimana kita berkolaborasi dengan AI”, bisakah dia menunjukkan sebuah dokumen? Jika ada satu saja dari tiga pertanyaan itu yang tidak bisa dijawab, artinya spec-driven belum benar-benar landing — tulis standar dulu, baru beli tools.

Tiga Pertanyaan Pelatih untuk Pengambil Keputusan

Terakhir, tiga pertanyaan—bukan checklist, melainkan bisa langsung Anda gunakan saat berdiskusi dengan tim:

“Jika semua alat AI offline mulai besok, seberapa besar penurunan kualitas kode tim Anda?” — Pertanyaan ini mengungkap nilai nyata dari spec-driven development: jika jawabannya “penurunan signifikan”, berarti spesifikasi Anda belum termaterialisasi; jika jawabannya “hampir tidak berubah”, berarti spec-driven sudah berjalan dengan baik.
“Dalam proyek spec-driven Anda, apakah tim kepatuhan berperan sebagai ‘penjaga gerbang’ atau ‘enabler’?” — Jika jawabannya “penjaga gerbang”, kecepatan implementasi Anda akan terhambat oleh bottleneck review; jika jawabannya “enabler”, Anda sudah berada di jalur yang benar sesuai Bagian 5.2.
“12–18 bulan ke depan, bagaimana ukuran tim Anda akan berubah?” — Jawaban dari Microsoft WTI 2026: 82% pemimpin akan menggunakan AI agent untuk “memperluas” tenaga kerja. Jika jawaban Anda “tidak berubah”, bisa jadi bisnis Anda tidak bertumbuh, atau desain organisasi Anda belum mengikuti dividen dari spec-driven.

Tidak ada jawaban standar untuk ketiga pertanyaan ini. Namun arah jawaban lebih penting daripada jawaban itu sendiri.

Langkah Berikutnya

Ini adalah artikel keenam dalam seri “Transformasi Rekayasa Perangkat Lunak di Era AI”. Dimulai dari Conway (organisasi menentukan arsitektur), berlanjut ke Team Topologies (bagaimana mendesain organisasi), lalu pergeseran bottleneck (bottleneck ada di verifikasi, bukan di penulisan kode), dan hari ini membahas spec-driven (menggunakan dokumentasi untuk mengendalikan perilaku AI).

Artikel berikutnya (ketujuh), kita akan membahas infrastruktur dasar yang menopang semua ini — Protokol MCP (Model Context Protocol): mengapa protokol sumber terbuka dari Anthropic ini disebut sebagai “USB-C untuk AI”, mengapa OpenAI, Google, dan Microsoft semuanya mengikutinya, dan bagaimana protokol ini memungkinkan interoperabilitas multi-alat dan multi-agen.

Ingin Menerapkan Keseluruhan Penilaian Ini di Perusahaan Anda?

Setelah spec-driven masuk ke perusahaan, masalah konkret yang biasanya perlu dipecahkan adalah: bagaimana aturan inti dikristalisasi menjadi CLAUDE.md / AGENTS.md, bagaimana kode yang sudah ada dilengkapi dengan standar, bagaimana kepatuhan ditanamkan, dan indikator apa yang harus dipakai untuk menilai tahap pilot.

Saat ini kami menawarkan tiga bentuk kerja sama:

Pelatihan internal perusahaan: dikombinasikan dengan proyek nyata perusahaan Anda, selesaikan perapian dokumen standar, desain gerbang CI, jalur penanaman kepatuhan, dan pembangunan mekanisme tata kelola.
Konsultasi khusus: fokus pada satu keputusan yang jelas, misalnya “apakah perusahaan kami harus menulis CLAUDE.md / AGENTS.md dulu”, atau prioritas perbaikan kepatuhan untuk kode yang sudah ada.
Berbagi dengan manajemen & pidato industri:mengenai alat pemrograman AI, spec-driven, tata kelola organisasi, dan Frontier Firms.

Artikel ini memberikan kerangka kerja umum. Implementasi spesifik tetap perlu dirancang ulang dengan mempertimbangkan kepatuhan perusahaan, batas regulasi, kematangan rekayasa, dan proses delivery yang ada. Kerja sama dapat menghubungi coach@iaiuse.com.

Bacaan lanjutan: Metodologi Signboard v1.0 (Belajar AI Perlahan-lahan 187), yang memperkenalkan kerangka 7 langkah untuk transformasi AI perusahaan.

Tentang Seri Ini

“Transformasi Rekayasa Perangkat Lunak di Era AI” adalah seri riset yang ditujukan untuk CIO, CDO, CTO, dan pimpinan transformasi digital di industri telekomunikasi, keuangan, manufaktur, dan e-commerce. Seri ini terdiri dari 18 artikel yang berfokus pada bagaimana alat pemrograman AI, dorongan standarisasi, dan tata kelola organisasi memengaruhi proses delivery perangkat lunak, struktur organisasi, dan kematangan rekayasa.

Seri ini terus memantau makalah akademis, materi vendor, dan laporan industri. Basis riset telah mengumpulkan lebih dari 200 referensi, dengan setiap penilaian kunci diberi label tingkat bukti untuk membedakan fakta terverifikasi, klaim vendor, observasi industri, dan penalaran penulis.

Saya memiliki hampir 8 tahun pengalaman konsultasi perusahaan besar dan analisis bisnis, pernah bekerja di IBM dan terlibat dalam proyek-proyek di sektor telekomunikasi, keuangan, asuransi, dan manufaktur. Setelah itu, saya terus berkecimpung di lini depan pengembangan produk operator, produk internet, dan aplikasi AI, menangani analisis kebutuhan, desain produk, dan implementasi lintas tim.

Seri ini tentang keputusan yang digerakkan oleh standar, tata kelola organisasi, dan rekayasa, berasal dari praktik-praktik tersebut, dan divalidasi silang dengan penelitian publik serta studi kasus industri. Konten yang menyangkut proyek spesifik telah dianonimkan; sebagian skenario industri merupakan simulasi masalah tipikal, dan referensi terkait dapat dilihat di bagian sumber di akhir artikel.

Akun ini sebenarnya dijalankan oleh tim kecil—saya dan 1–2 kolega yang bekerja sama dalam jangka panjang, masing-masing menangani riset alat pemrograman AI, studi kasus tata kelola organisasi, dan pendampingan coaching. Sebagian besar proyek yang kami sebut “kami dampingi bersama perusahaan” adalah hasil kerja kolektif kami. Batas kepatuhan klien dan nama individu tetap tidak disebutkan; anonimitas dipertahankan untuk memberi ruang bagi kolaborasi di masa depan.

Referensi (semuanya telah diverifikasi, dengan tingkat bukti yang ditandai per item)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Kode yang dihasilkan AI memiliki 1,7× lebih banyak masalah dibanding kode buatan manusia (10,83 vs 6,45 masalah/PR), dengan rincian: logika/kebenaran 1,75×, kualitas kode 1,64×, keamanan 1,57×, penanganan password 1,88×, XSS 2,74×. Tingkat bukti: primer. Sumber: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). Melaporkan laporan lengkap CodeRabbit: analisis terhadap 470 PR open source menunjukkan PR yang melibatkan kolaborasi AI mengandung 10,83 masalah vs 6,45 masalah pada PR murni manual. Tingkat bukti: sekunder. Sumber: URL yang sama
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap”——2026 adalah tahun transisi dari “kecepatan menghasilkan kode” menuju “kualitas kode dan tata kelola”. Tingkat bukti: sekunder. Sumber: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. 78% tim mengalami lebih banyak insiden setelah kode AI diluncurkan; 62% pemimpin teknis mengakui tim mereka “dengan percaya diri mengirim kode AI tanpa review”; 96% menganggap observability sebagai keharusan. Tingkat bukti: primer (laporan vendor). Sumber: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Survei terhadap 20.000 pekerja AI, mencakup 10 negara; 82% pemimpin berencana memperluas tenaga kerja dengan AI agent dalam 12–18 bulan ke depan; 81% memperkirakan integrasi AI agent pada tingkat sedang hingga besar; 24% telah menerapkan di tingkat enterprise; 49% percakapan Copilot mendukung pekerjaan kognitif; 58% pengguna AI berhasil melakukan hal-hal yang “tidak mungkin dilakukan setahun lalu”, dan angka ini naik menjadi 80% di kalangan Frontier Professionals. Tingkat bukti: Level 1. Sumber: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Retrospektif FY26 Microsoft: Dari Eksperimen AI Menuju Transformasi Kelas Dunia (28 Juli 2026). EY menerapkan Microsoft 365 Copilot untuk 150.000 karyawan, menghemat 2,5 juta jam dan sekitar 250 juta dolar AS; kemudian diperluas ke 400.000 karyawan global, dengan 95% percepatan proses, 37% penurunan biaya operasional finansial, dan pengurangan hingga 90% alur kerja manual. Atos menerapkan Copilot ke 56.000 karyawan di 56 negara, ditambah 19.000 agen AI, dengan satu bidang kendali terpadu untuk identitas, keamanan, kepatuhan, dan tata kelola. Tingkat bukti: Level 1 (retrospektif resmi Microsoft). Sumber: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Kolaborasi Strategis Atos Group dan Microsoft (2026.6.9). Atos menerapkan Microsoft 365 E7 (Frontier Suite) untuk 56.000 karyawan di 56 negara, plus 19.000 agen AI; menyatukan bidang kontrol Entra/Defender/Intune/Purview/Agent 365. Tingkat bukti: Level satu (siaran pers bersama kedua pihak). Sumber: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (dirilis open source Sep 2025, berkembang H1 2026). Gerbang 5 tahap /speckit.constitution → /specify → /plan → /tasks → /implement, ditambah /clarify /analyze; agnostik model (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code semuanya bisa terhubung). Level bukti: tingkat satu. Sumber: https://github.com/github/spec-kit
AWS Kiro (dirilis Juli 2025, berkembang H1 2026). Alur kerja tiga tahap: kebutuhan → desain → tugas; spec memicu aksi agen yang telah ditentukan sebelumnya; tanpa menulis spec, tidak bisa dijalankan. Level bukti: tingkat satu. Sumber: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 mencapai 5 juta+ pengguna aktif mingguan, 20% di antaranya non-developer; AGENTS.md + Skills sebagai set instruksi yang dapat dikombinasikan. Tingkat bukti: Level 1 (pengumuman resmi OpenAI). Sumber: https://developers.openai.com/codex/skills
Claude Code (Anthropic, 2026 H1). Sistem CLAUDE.md + .claude/rules/ + Skills; memasuki pasar resmi Anthropic pada 2026.2; repositori Skills di GitHub meraih 112 ribu bintang; pengungkapan Putaran G 2026.2 menunjukkan pendapatan tahunan sebesar USD 2,5 miliar. Tingkat bukti: Level 1. Sumber: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Survei terhadap 10.000+ developer profesional secara global, dilokalkan dalam 8 bahasa; CSAT Claude Code 91% / NPS 54 (tertinggi di industri); adopsi Claude Code di tempat kerja 18% (naik 6x lipat dari 3% dalam 9 bulan), di Amerika Utara 24%; Copilot 29% adopsi di tempat kerja namun pertumbuhannya stagnan; Cursor 18%. Tingkat bukti: Tier 1. Sumber: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Survei terhadap 15.000 developer; 46% memilih Claude Code sebagai “paling disukai”, Cursor 19%, Copilot 9%. Tingkat bukti: Tier 1. Sumber: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). Dirilis oleh Alibaba pada 2025.8; pada 2026.5.15, Qoder 1.0 ditingkatkan menjadi Autonomous Agent Development Workbench; mencakup Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; pada 2026.5.28 meluncurkan Cloud Agents (runtime agen terkelola); pada 2026.7.21 merilis Qoder Security; per Mei 2026, pengguna global mencapai 5 juta+; terintegrasi dengan CLI DingTalk; pada 2026.5.20, Tongyi Lima berganti nama menjadi Qoder CN. Tingkat bukti: primer. Sumber: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (2026 H1). Perintah lima tahap Spec Kit, perbandingan ulasan alat SDD, metode notasi EARS. Tingkat bukti: sekunder (ulasan pihak ketiga). Sumber: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (berlaku penuh 2.8.2026). Batas kepatuhan untuk sistem AI berisiko tinggi adalah 2.8.2026; model GPAI yang sudah ada diberi perpanjangan hingga 2.8.2027; denda maksimum €35 juta atau 7% pendapatan global; Art. 9–15 mencakup manajemen risiko, tata kelola data, transparansi dokumentasi, pengawasan manusia, serta akurasi dan ketangguhan. Tingkat bukti: Level 1 (regulasi + analisis kepatuhan sekunder). Sumber: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). 44% akar masalah berasal dari kurangnya konteks. Tingkat bukti: Level 2 (laporan vendor). Sumber: https://www.qodo.ai/reports/state-of-ai-code-quality/