Saat Kode Nyaris Gratis, Bottleneck Pergi ke Requirement, Integrasi, Verifikasi, dan Penyelarasan

Saat produksi kode nyaris gratis, bottleneck pengiriman perangkat lunak berpindah dari “menulis kode” ke tempat lain: mendefinisikan masalah yang benar, menyatukan pecahan menjadi utuh yang berjalan, memverifikasi bahwa itu memang benar, dan menyelaraskan organisasi. Ini adalah pengulangan Teori Batasan (Theory of Constraints) di industri perangkat lunak. Manufaktur sudah menempuh jalan ini 40 tahun lalu: setiap kali satu proses menjadi murah, bottleneck tidak hilang, ia hanya pindah ke proses berikutnya yang paling mahal. Memahami hal ini, Anda bisa menjelaskan satu kebingungan yang merata: perkakas pemrograman AI sudah dipasang di seluruh perusahaan, menulis kode jelas lebih cepat, tetapi kecepatan pengiriman nyaris tidak berubah.

Seorang CIO grup manufaktur pernah menunjukkan padaku data enam bulan terakhir. Tim IT-nya 80-an orang, sudah sepenuhnya memakai perkakas pemrograman AI. Dilihat dari sisi produksi kode, jumlah commit per orang dan kecepatan merge keduanya naik di atas tiga puluh persen. Tetapi di sisi bisnis, rasanya sungguh berbeda: satu fitur kecil penjadwalan produksi cerdas, dari gagasan sampai live tetap butuh tiga bulan minimum. Dia semula mengira perkakas akan memberi percepatan dua kali lipat. Yang didapat hanya “kode ditulis lebih cepat”. Ucapannya blak-blakan: “Aku menghabiskan ratusan juta rupiah untuk lisensi, yang kudapat malah developer makin sibuk dan bisnis makin mendesak.”

Dia salah menebak di mana bottleneck berada. Bottleneck sebenarnya adalah hal lain: setiap fitur baru harus menembus MES, ERP, sistem inspeksi kualitas, terminal lantai produksi, plus satu set pelaporan regulator — integrasi dan uji silang (joint commissioning) melahap sebagian besar waktu proyek; sedangkan kode yang dihasilkan AI tidak ada satu pun gerbang penerimaan resmi yang berdiri di antara dirinya dan lingkungan produksi. Secepat apa pun kode ditulis, ia hanya mengantri di belakang bottleneck yang salah.

1. Manufaktur Sudah Tahu Sejak 40 Tahun Lalu: Bottleneck Akan Pindah

Untuk memahami masa kini, pinjam dulu satu kacamata yang sudah dipakai manufaktur selama 40 tahun.

Pada 1984, Eliyahu Goldratt — konsultan berlatar belakang fisikawan asal Israel — menulis novel berjudul The Goal, tentang seorang kepala pabrik yang hampir bangkrut dan bagaimana dia menyelamatkan pabriknya. Inti seluruh buku hanya satu kalimat: produksi sistem apa pun ditentukan oleh tahap yang paling sempit (constraints, alias bottleneck). Melebarkan tahap non-bottleneck tidak memberi sumbangan apa pun pada output total; hanya melebarkan bottleneck itu sendiri yang membuat keseluruhan menjadi lebih cepat. Dan begitu Anda melebarkan bottleneck, ia langsung pindah ke tempat paling sempit berikutnya. Itulah Teori Batasan (Theory of Constraints, TOC).

Sejarah otomasi manufaktur selama 40 tahun sesudahnya nyaris adalah sebuah “sejarah perpindahan bottleneck”. Ketika mesin CNC membuat proses pemesinan menjadi murah, bottleneck pindah ke pergantian die dan inspeksi kualitas; ketika lini produksi fleksibel membuat pergantian die cepat, bottleneck pindah ke penjadwalan produksi dan koordinasi rantai pasok; ketika MES membuat penjadwalan menjadi akurat, bottleneck pindah ke prakiraan permintaan dan penjadwalan antar-pabrik. Setiap kali satu segmen diotomasi, segmen berikutnya naik ke permukaan. Otomasi tidak pernah menghapus bottleneck, ia hanya memindahkannya.

Jarak hal ini dengan perangkat lunak lebih dekat dari yang Anda kira. Pada 2013, Gene Kim memindahkan hampir persis cerita pabrik Goldratt ke dalam operasional IT, dan menulis The Phoenix Project: bagaimana seorang CIO memakai Teori Batasan untuk menyelamatkan departemen IT yang hampir menyeret seluruh perusahaan ke jurang. Jadi “memandang perangkat lunak dengan kacamata bottleneck manufaktur” bukanlah metafora yang dicari-cari sekarang, melainkan jalan yang sudah divalidasi.

2. Kembali ke Perangkat Lunak: Menulis Kode Sedang Menjadi Tahap Termurah

Tiga angka untuk membuat “biaya produksi kode mendekati nol” menjadi jelas.

Copilot: Riset GitHub sendiri mengukur bahwa pada file yang mengaktifkan Copilot, sekitar 46% kode diselesaikan oleh Copilot. Perhatikan cakupannya — ini adalah proporsi di dalam file yang diaktifkan, bukan 46% dari seluruh kode di GitHub.
Stripe: Agen coding internal buatan mereka sendiri, “Minions”, setiap minggu menghasilkan dan menggabungkan lebih dari 1.300 PR (dulu 1.000, terus naik). Ada satu detail penting yang patut diingat: setiap PR harus melewati review manusia sebelum di-merge. Stripe mengotomasi “menulis”, tetapi menyerahkan “penerimaan” kepada manusia. Poin ini akan dipakai di Bagian 4.
NVIDIA: Jensen Huang secara terbuka mengatakan bahwa 100% engineer NVIDIA memakai perkakas pemrograman AI semacam Cursor, dan “bekerja tanpa AI” di NVIDIA sudah tidak lagi diterima.

Tumpuk tiga angka ini, dan kesimpulannya sangat keras: biaya unit untuk memproduksi satu baris kode sedang mendekati nol dengan cepat.

Muncul pertanyaan yang menusuk: kalau menulis kode nyaris tidak butuh biaya, mengapa perangkat lunak masih begitu mahal, begitu lambat, dan begitu sulit dikirimkan? Jawabannya persis yang diberikan Teori Batasan: Anda melebarkan tahap “menulis kode”, dan bottleneck hanya pindah. Pergi ke mana?

3. Bottleneck Pergi ke Empat Tempat

Kali ini, bottleneck terkonsentrasi pada empat tahap. Masing-masing adalah hal yang tidak bisa disentuh AI dalam jangka pendek.

Tahap pertama: mendefinisikan masalah yang benar. AI bisa dalam hitungan detik menulis “fitur yang Anda ucapkan”, tetapi tidak bisa menulis “fitur yang sebenarnya Anda butuhkan”. Kebanyakan proyek perangkat lunak gagal pada akarnya: yang dibuat tidak dipakai orang, karena sejak awal tidak dipikirkan tuntas masalah apa yang ingin dipecahkan. Setelah produksi kode menjadi murah, “mengurai satu gangguan bisnis yang kabur menjadi spesifikasi yang jelas, terpecahkan, dan patut dipecahkan” (problem formulation) menjadi kemampuan paling langka sekaligus paling mahal. Rekan-rekan dari manufaktur tidak asing dengan hal ini: jalur proses dan gambar teknik yang salah, seefisien apa pun proses produksinya, hanya akan memproduksi barang rusak secara massal.

Tahap kedua: integrasi sistem. AI piawai menghasilkan “sepotong kode”, “satu fungsi”, “satu halaman”. Tetapi sistem yang bisa live adalah integrasi ratusan pecahan: saling bertukar data, menangani boundary, menjaga konsistensi, bertahan terhadap exception. Menghasilkan pecahan murah, menyatukan pecahan menjadi utuh yang andal mahal. Biaya ini berakar pada penyelarasan organisasi dan arsitektur — persis urusan Hukum Conway dan Team Topologies (lihat dua artikel sebelumnya dalam seri ini). Kembali ke CIO manufaktur di pembuka: waktu proyeknya tidak habis di menulis kode, melainkan di uji silang MES, ERP, inspeksi kualitas, dan pelaporan.

Tahap ketiga: verifikasi. Jumlah kode melonjak, tingkat kepercayaan campur aduk. Siapa yang menetapkan “ini benar”? Pengujian, code review, observabilitas, rilis bertahap — kerja “verifikasi” ini tidak turun, malah naik. Ini adalah bottleneck yang paling diremehkan, juga bayangan manufaktur yang paling dalam. Bagian 4 membahasnya khusus.

Tahap keempat: penyelarasan organisasi. Ketika dalam tim muncul agen AI, siapa menentukan mengerjakan apa, siapa mengaudit, siapa bertanggung jawab atas hasil? Ini perpanjangan Hukum Conway dan Team Topologies: penyelarasan organisasi sendiri menjadi bottleneck. Artikel ke-11 seri ini akan khusus membahasnya: ketika simpul organisasi tidak lagi seluruhnya manusia, bagaimana tata kelola menjadi inti daya saing.

4. Potongan Terdalam: Verifikasi, dan Apa yang Sebenarnya Diajarkan Jidoka Toyota

Dari empat bottleneck, yang paling sering disalahpahami adalah verifikasi. Banyak orang membayangkannya sebagai “karena AI menulis cepat, ya tinggal banyak test beberapa putaran”. Ini benar setengah. Untuk memahami mengapa verifikasi menjadi mahal, lebih dulu luruskan satu konsep Toyota yang paling sering dikutip dan paling banyak kelirunya: Jidoka (自働化).

Luruskan dulu satu kesalahpahaman yang tersebar luas. Jidoka bukan “memakai AI atau mesin menggantikan manusia”, juga bukan “menjadikan manusia seperti mesin, bekerja tanpa henti layaknya mesin”. Kedua arah ini sama-sama terbalik.

Jawabannya tersembunyi di kata itu sendiri. Dalam bahasa Jepang, “自動化” adalah otomasi biasa. Toyota sengaja memakai “自働化” — “働” membawa radikal “manusia” (人), menegaskan “otomasi yang membawa sentuhan manusia” (automation with a human touch). Maknanya yang akurat: ketika mesin atau lini produksi mendeteksi anomali, mesin berhenti dengan sendirinya, membiarkan manusia turun tangan, menyelesaikan akar masalah, baru produksi dilanjutkan. Dua mekanisme berjalan beriringan: mesin dipasangi deteksi anomali dan bisa berhenti sendiri; di lini produksi, siapa pun yang menemukan kejanggalan bisa menarik tali andon, dan seluruh lini berhenti seketika. Kualitas tidak diperiksa di ujung, melainkan ditanam di setiap tahap dan diselesaikan di tempat.

Di sini ada satu kesimpulan yang berbalik dari intuisi, dan ia berkorespondensi langsung dengan perangkat lunak: makin dalam otomasi, makin bertambah bobot gerbang kualitas dan campur tangan manusia — bukan berkurang. Jidoka membebaskan manusia dari “operasi berulang”, lalu menempatkannya kembali ke posisi “menemukan anomali, menghentikan lini, menyelesaikan akar masalah”. Toyota memberikan kekuatan pada pekerja lini untuk menghentikan seluruh produksi, justru karena sadar: sekuat apa pun otomasi, harus ada manusia yang bisa meneriakkan “berhenti” saat masalah muncul. Baru di situlah letak sebenarnya dari slogan “memberikan kecerdasan pada robot”: membuat mesin memiliki kemampuan untuk berhenti dan memanggil manusia. Manusia selalu hadir, bertanggung jawab menyelesaikan akar masalah.

Perangkat lunak sedang menempuh jalan yang sama, dan dalam tempo yang sangat cepat. Riset GitClear tentang kualitas kode berbantuan AI sudah mengamati peningkatan blok kode ganda dan naiknya kode churn jangka pendek: AI menulis cepat, tetapi juga menulis “seolah-olah semuanya benar”. Ketika sebagian besar kode tidak ditulis baris demi baris oleh manusia, mekanisme kepercayaan tradisional semacam “pengembang tahu apa yang dia tulis” menjadi rusak. Yang Anda butuhkan saat itu adalah versi perangkat lunak dari tali andon dan mekanisme penghentian lini:

Pengujian (unit, integrasi, end-to-end) naik dari “sebisanya” menjadi gerbang keras — belum lulus tidak boleh di-merge;
Code review bergeser dari “memeriksa cara menulis” ke “memeriksa intent dan boundary”: kode ini sebenarnya ingin memecahkan apa, dan apakah boundary condition tertutup;
Observabilitas (monitoring, log, tracing) jadi standar baku, karena perilaku di produksi bicara lebih jujur daripada kode itu sendiri;
Rilis bertahap / feature flag membuat keluaran AI diuji dulu di lingkup kecil, baru dilebarkan setelah dipastikan aman.

Lihat kembali 1.300 PR Stripe di Bagian 2: menulis memang urusan agen, tetapi gerbang merge sepenuhnya diserahkan pada review manusia. Inilah contoh hidup Jidoka di perangkat lunak: produksi diotomasi, penerimaan tetap di tangan manusia, dan manusia diberi kuasa untuk “menghentikannya”. Produksi menjadi murah, kontrol kualitas menjadi mahal — ini satu hukum yang tidak berubah selama 40 tahun.

5. Premi “Mendefinisikan Masalah”: Kemampuan Lebih Mahal daripada Prompt

Kalau verifikasi adalah bottleneck yang diremehkan, “mendefinisikan masalah” adalah kemampuan yang diundur nilainya secara serius.

Prompt engineering sempat ramai, dan tidak sedikit orang mengira “piawai menulis prompt” adalah kemampuan inti. Padahal prompt hanyalah teknik “menyatakan masalah”. Yang benar-benar langka adalah satu langkah lebih ke depan: problem formulation — mengurai satu gangguan bisnis yang kabur menjadi masalah yang jelas, terpecahkan, dan patut dipecahkan. Langkah ini tidak bisa dikerjakan AI dalam jangka pendek, karena ia harus menunggu Anda memberitahunya lebih dulu “apa masalahnya”.

Pakar berpengalaman di manufaktur paling punya rasa terhadap bobot langkah ini. Satu lembar gambar teknik atau satu jalur proses yang salah, seefisien apa pun pengerjaan dan perakitan di hilir, hanya akan memproduksi kesalahan secara massal. Perangkat lunak sama: spesifikasi requirement yang salah, AI bantu Anda memproduksi setumpuk barang yang tidak dipakai siapa pun dengan kecepatan sepuluh kali lipat.

Satu penilaian lurus saja: berhentilah berlomba pada “kecepatan menulis kode”, asahlah “ketajaman dalam memecah masalah”. Dalam organisasi, ini berarti mendirikan “definisi requirement” dan “verifikasi penerimaan” sebagai pos resmi, jangan lagi diserahkan kepada pengembang yang mengerjakan sambil lalu. Setelah AI membuat implementasi menjadi murah, pos-pos inilah yang imbalannya naik paling cepat.

6. Bagaimana Rupa Bottleneck Nyata di Empat Industri

Pakaikan “perpindahan bottleneck” pada empat industri — di setiap industri, bottleneck tidak berada di menulis kode.

Manufaktur. Garis besarnya adalah CIO di pembuka artikel. Fitur seperti penjadwalan produksi cerdas, penelusuran kualitas, dan optimasi konsumsi energi — secara teknis tidak sulit, dan banyak modelnya sudah jadi. Bottleneck tersangkut pada integrasi dan uji silang antara MES, ERP, inspeksi kualitas, dan pelaporan, serta verifikasi lapangan di terminal lantai produksi. Kode proyek semacam ini biasanya ditulis sangat cepat, tetapi uji silang MES/ERP bisa melahap waktu beberapa kali lipat dari menulis kode; hanya dengan menempatkan pos penerimaan di terminal lantai produksi dan titik integrasi, cacat bisa dicegah di tempat, bukan mengalir ke produksi baru terkuak. Astra International, dengan ekosistem otomotif dan bisnis unitnya yang tersebar dari perakitan kendaraan hingga agribisnis, menghadapi pola yang persis sama: setiap unit bisnis menjalankan MES dan ERP generasi berbeda, dan pekerjaan integrasinya nyaris selalu menjadi pembatas kecepatan.

Telekomunikasi / operator. Satu perubahan paket atau proses aktivasi jalur khusus korporat harus menembus kanal, billing, CRM, aktivasi jaringan, dan penjadwalan pemasangan-pemeliharaan — sejumlah domain. AI mempercepat pengembangan di tiap domain, tetapi uji silang end-to-end lintas domain dan verifikasi konsistensi adalah yang memakan waktu paling besar. Operator punya satu bottleneck khas: kepatuhan dan rekonsiliasi. Selisih satu rupiah di billing adalah insiden, dan bobot verifikasi di sini lebih berat daripada industri mana pun. Telkomsel dan Indosat Ooredoo, misalnya, saat meluncurkan produk paket data baru atau layanan korporat, harus memastikan konsistensi pelaporan antar-sistem — dari kanal pemesanan, billing, hingga rekonsiliasi keuangan — sebelum satu perubahan pun bisa live. Aktivasi jalur khusus korporat adalah contoh nyata: AI mempercepat tiap domain, tetapi uji silang end-to-end plus rekonsiliasi billing tetap melahap separuh waktu proyek.

Keuangan. Satu penyesuaian aturan risiko kredit atau anti-pencucian uang menembus App, sistem inti, mesin risiko, data platform, dan pelaporan regulator. Bobot verifikasi di sini sangat tinggi, karena satu kesalahan berarti insiden kepatuhan. Bottleneck ada pada dapat dijelaskan, dapat diaudit, dapat ditelusuri: aturan yang ditulis AI seakurat apa pun, kalau tidak lulus satu pertanyaan regulator “mengapa diputus seperti ini”, tidak akan pernah live. Iterasi aturan anti-pencucian uang adalah tipikal: AI mempercepat penulisan aturan, tetapi audit dapat-dijelaskan-nya dan penyelarasan pelaporan regulator kerap melahap lebih dari separuh siklus. BCA dan Bank Mandiri, yang menjalankan kerangka anti-pencucian uang dengan kewajiban audit regulator, menghadapi pola ini setiap kali aturan diperbarui — kapasitas verifikasi dan audit menjadi penentu kapan sebuah aturan benar-benar bisa dipakai.

E-commerce. Satu fitur promosi atau kampanye besar menembus katalog produk, transaksi, marketing, gudang, dan layanan pelanggan. AI membuat halaman dan API ditulis dengan cepat, tetapi bottleneck pindah ke uji beban, konsistensi inventaris, antifraud, dan rekonsiliasi. Yang membuat platform tumbang pada malam kampanye besar tidak pernah kode yang ditulis terlalu lambat — melainkan boundary yang tidak terverifikasi. Persiapan kampanye adalah miniatur: halaman promosi bisa dihasilkan AI dalam sekejap, tetapi uji beban end-to-end dan verifikasi konsistensi inventaris sering melahap separuh waktu persiapan. Tokopedia dan Shopee Indonesia, saat menghadapi kampanye tanggal kembar atau akhir tahun, justru menghabiskan porsi terbesar waktu untuk uji beban dan rekonsiliasi inventaris — bukan membangun halaman kampanyenya.

Benang merah dari empat industri terlihat jelas: AI mempercepat “menulis”, tetapi yang menghambat adalah “menyambung, memverifikasi, menyelaraskan”. Mengalihkan kapasitas pengembangan yang dihemat ke tiga hal inilah percepatan yang sesungguhnya.

7. Salah Menilai Berakibat Apa: Tiga Jenis Ketidakcocokan Paling Umum

Jenis pertama: menganggap “kode ditulis cepat” sama dengan “pengiriman jadi cepat”. Inilah ilusi yang paling merata. Kode hanyalah satu mata rantai dalam pengiriman, dan melebarkannya tidak membuat seluruh rantai jadi cepat — hanya membuat lebih banyak barang setengah jadi menumpuk di belakang bottleneck. Teori Batasan menyebutnya inventory; di perangkat lunak namanya PR yang belum diverifikasi dan cabang yang belum diintegrasikan. Hasilnya: pengembang makin sibuk, bisnis makin mendesak, output tidak berubah — persis situasi si CIO di pembuka.

Jenis kedua: saat produksi dipercepat, justru membongkar gerbang kualitas. Ini pelanggaran tipikal terhadap Jidoka. Ada yang beranggapan “AI menulis cepat dan baik, code review bisa disederhanakan, pengujian bisa dipangkas”. Justru sebaliknya — makin cepat produksi, makin penting tali andon. Membongkar gerbang penerimaan sama dengan membiarkan lini produksi tanpa manusia berputar penuh kecepatan tanpa pengawasan, dan cacat akan mengalir ke lingkungan produksi dengan laju yang lebih cepat.

Jenis ketiga: menghabiskan uang di tempat yang bukan bottleneck. Integrasi adalah bottleneck, tetapi Anda justru membeli lisensi pemrograman AI tambahan; verifikasi adalah bottleneck, tetapi Anda justru merekrut lebih banyak pengembang. Teori Batasan sudah menjelaskannya sejak lama: investasi pada non-bottleneck memberi sumbangan nol pada output total, dan hanya membuat laporan keuangan makin jelek. Urutan yang benar adalah menemukan bottleneck lebih dulu, lalu menumpuk sumber daya di sana.

8. Implikasi bagi Pengambil Keputusan

Implikasi 1: sebelum membeli perkakas, gambar dulu satu peta bottleneck. Bongkar tiga pengiriman terakhir yang tersangkut, dan lihat ke mana waktu benar-benar pergi. Apakah ke tidak-bisa-menulis-kode, atau ke tidak-bisa-disambung, tidak-adayang-verifikasi, requirement-tidak-jelas? Yang tidak bisa ditandai berarti sedang menebak-nebak di lapis teknis. Peta bottleneck lebih bernilai daripada daftar belanja perkakas apa pun, dan bisa menahan setidaknya separuh investasi IT yang sia-sia di perusahaan besar.

Implikasi 2: alihkan kapasitas yang dihemat ke requirement dan verifikasi. AI membuat pengembangan lebih cepat, yang berarti Anda bisa melepaskan sebagian tangan. Masukkan orang-orang ini secara resmi ke pos “definisi requirement” dan “verifikasi penerimaan” — jangan biarkan mereka terus menunduk menulis lebih banyak kode. Imbalan kedua pos inilah yang naik paling cepat di era AI.

Implikasi 3: pasang satu tali andon pada perangkat lunak Anda. Pendaratan Jidoka yang paling langsung adalah memasang gerbang keras di CI/CD: tidak lulus uji tidak boleh merge, review wajib memeriksa intent dan boundary, rilis bertahap dimulai dari lingkup kecil, observabilitas jadi standar baku. Makin otomatis produksi, makin kokoh gerbang ini harus berdiri. Ini mencegah “kode gratis” berubah menjadi “insiden gratis”.

Implikasi 4: posisikan ulang manusia, jangan dicabut. Jidoka menunjuk pada satu kesimpulan yang sama: makin dalam otomasi, makin harus ditempatkan pada posisi “menilai, menerima, menyelesaikan akar masalah”. Membebaskan manusia dari operasi berulang dan menempatkannya kembali ke verifikasi serta penyelarasan — ini adalah aksi inti desain organisasi di era AI, sekaligus materi yang akan dibuka lebih lanjut di beberapa artikel berikutnya dalam seri ini.

9. Mungkin Anda Ingin Bertanya

“Kami baru uji coba AI di satu bagian, tidak perlu gambar peta bottleneck seluruh perusahaan kan?” Uji coba pun harus lebih dulu melihat jelas: bagian yang diuji coba, apakah benar-benar bottleneck? Kalau titik tersangkut sebenarnya di integrasi atau verifikasi, maka menguji AI di bagian “menulis kode” adalah membuang uang di non-bottleneck — persis ketidakcocokan jenis ketiga di Bagian 7. Lakukan satu diagnosis bottleneck dalam lingkup kecil, dan uang perkakas baru benar-benar berharga.

“Gerbang verifikasi tidak akan memperlambat pengiriman?” Jangka pendek menimbulkan gesekan, jangka panjang justru mempercepat. “Cepat” tanpa gerbang penerimaan adalah cepat mendorong cacat ke produksi, dengan biaya rework mulai sepuluh kali lipat. Pengalaman Jidoka: biaya menyelesaikan satu cacat di tempat hanyalah sebagian kecil dari biaya membiarkannya mengalir ke hilir baru dipecahkan.

“Apa hubungannya dengan transformasi AI yang sedang kami jalani?” Hubungannya sangat langsung. Jebakan paling sering dalam transformasi AI adalah mengasumsikan bottleneck ada pada “menulis kode / kapasitas”, lalu membeli setumpuk perkakas untuk melebarkan mata rantai itu. Lakukan diagnosis bottleneck lebih dulu, baru putuskan uang dibelanjakan ke mana. Ini juga alasan saya menempatkan “asesmen kemampuan” dan “identifikasi skenario nilai” di posisi depan dalam 7-Step AI Transformation Coaching Framework — lihat dulu bottleneck di mana, baru bicara perkakas.

Pemeriksaan balik (jangan dipermak saat menjawab): pengiriman terakhir yang tersangkut, ke mana waktu benar-benar pergi — ke menulis kode, atau ke menyambung, memverifikasi, menyelaraskan? Perkakas AI Anda menghasilkan setumpuk kode — berapa banyak yang stabil live dan benar-benar dipakai pengguna? Apa di CI/CD Anda ada satu gerbang keras “tidak lulus uji tidak boleh merge”? Kalau satu di antara tiganya membuat Anda jawabnya tidak yakin, maka tunda dulu membeli perkakas AI tambahan, dan temukan bottleneck Anda berada.

Langkah Berikutnya

Ini artikel ke-3 dari 15 artikel seri “Transformasi Rekayasa Perangkat Lunak di Era AI”. Dari Conway (organisasi menentukan arsitektur), Team Topologies (bagaimana mendesain organisasi), sampai perpindahan bottleneck (saat kode nyaris gratis, ke mana bottleneck pergi). Artikel berikutnya (ke-4) beralih ke sudut pandang yang lebih operasional: bagaimana memilih perkakas pemrograman AI mainstream. Tetapi kesimpulannya mungkin berbalik dari intuisi: pemilihan perkakas pada akhirnya adalah satu keputusan organisasi, dan harus dipilih sesuai tingkat kematangan dan tata kelola Anda — bukan sesuai “siapa yang kodenya paling keren”.

Keterangan seri: seri ini terus memantau evolusi terbaru perkakas pemrograman AI, arsitektur organisasi, dan paradigma rekayasa perangkat lunak — misalnya bagaimana Hukum Conway berubah di era agen AI pada 2026, kematangan ekosistem perkakas terbaru, dan sebagainya. Ikuti seri ini untuk wawasan yang terus diperbarui.

Tentang Seri Ini

“Transformasi Rekayasa Perangkat Lunak di Era AI” adalah seri riset mendalam untuk CIO/CDO/CTO dan pemimpin digitalisasi di sektor telekomunikasi, keuangan, manufaktur, dan e-commerce — total 15 artikel. Berbasis 200+ makalah akademik dan laporan industri, memberi rujukan keputusan dengan anotasi tingkat bukti.

Saya mantan engineer IBM, pelatih bersertifikat ICF, pernah menangani implementasi proyek AI dan digitalisasi di operator serta perusahaan besar. Apa yang ditulis di sini adalah penilaian lapangan dari menemani perusahaan melewati jebakan-jebakan ini.

Rujukan (semua telah diverifikasi)

Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (sumber asli Teori Batasan TOC, sumber primer; novel berlatar pabrik manufaktur)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (memindahkan TOC Goldratt persis ke operasional IT, jembatan manufaktur→perangkat lunak, sumber primer)
Toyota. Toyota Production System — Jidoka. toyota-global.com (Jidoka = otomasi dengan sentuhan manusia, berhenti saat anomali + manusia menyelesaikan akar; sistem andon; sumber primer)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot menyelesaikan sekitar 46% kode pada file yang diaktifkan, cakupan “dalam file yang diaktifkan”, sumber primer)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; laporan InfoQ lebih dari 1.300 PR per minggu, seluruhnya di-review manusia (primer + sekunder)
NVIDIA / Jensen Huang. Pernyataan terbuka bahwa 100% engineer memakai perkakas pemrograman AI semacam Cursor (pernyataan tangan pertama)
GitClear (2025). AI-Assisted Code Quality Research. (mengamati peningkatan kode ganda / churn jangka pendek pada kode berbantuan AI, mendukung “verifikasi makin mahal”, sekunder)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (kinerja pengiriman ditentukan oleh budaya, aliran, umpan balik — bukan kecepatan koding individu, sumber primer)