[Peralihan Bottleneck] Ketika kode hampir gratis, ke mana perginya bottleneck teknik perangkat lunak? Transformasi Teknik Perangkat Lunak di Era AI — Belajar AI Secara Perlahan 173
Saat Kode Hampir Gratis, Bottle-neck Pindah ke Kebutuhan, Integrasi, Verifikasi, dan Alignment
Ketika produksi kode hampir gratis, bottle-neck dalam pengiriman perangkat lunak berpindah dari “menulis kode” ke tempat lain: mendefinisikan masalah yang tepat, menyatukan fragmen menjadi sistem yang berjalan, memverifikasi bahwa itu benar-benar tepat, dan menyelaraskan organisasi. Ini adalah ulangan teori constraint (Theory of Constraints) di industri perangkat lunak. Manufaktur sudah melewati jalan ini 40 tahun lalu: setiap kali satu tahap menjadi lebih murah, bottle-neck tidak hilang—ia hanya bergeser ke tahap berikutnya yang paling mahal. Memahami hal ini menjelaskan kebingungan umum: alat pemrograman AI telah diterapkan di seluruh perusahaan, menulis kode jelas lebih cepat, tetapi kecepatan pengiriman tidak banyak berubah.
Seorang CIO dari grup manufaktur menunjukkan data enam bulan terakhirnya kepada saya. Tim IT beranggotakan lebih dari 80 orang, telah sepenuhnya mengadopsi alat pemrograman AI. Dari sisi output kode, rata-rata jumlah commit dan kecepatan merge meningkat lebih dari 30%. Namun, persepsi di sisi bisnis sangat berbeda: fitur kecil seperti penjadwalan cerdas tetap membutuhkan waktu minimal 3 bulan sejak inisiasi hingga peluncuran. Ia awalnya mengira alat ini akan mempercepat proses dua kali lipat, tetapi yang ia dapatkan hanyalah “kode yang ditulis lebih cepat”. Kalimatnya sangat jujur: “Saya menghabiskan jutaan dolar untuk lisensi, tapi yang saya dapatkan adalah developer yang lebih sibuk dan bisnis yang lebih panik.”
Dia salah mengidentifikasi lokasi bottleneck. Bottleneck sebenarnya adalah hal lain: setiap fitur baru harus melewati MES, ERP, sistem inspeksi kualitas, terminal pabrik, ditambah satu set laporan regulasi—integrasi dan pengujian terpadu memakan sebagian besar waktu proyek; sementara kode yang dihasilkan AI tidak memiliki satu pun titik penerimaan resmi yang menghalanginya dari lingkungan produksi. Seberapa cepat pun kode ditulis, itu hanya antri di belakang bottleneck yang salah.
I. Manufaktur: 40 Tahun Lalu Sudah Tahu: Bottleneck Berpindah
Untuk memahami masa kini, mari gunakan kacamata yang telah dipakai manufaktur selama 40 tahun.
Pada 1984, fisikawan sekaligus konsultan Israel Eliyahu Goldratt menulis novel berjudul The Goal, yang menceritakan bagaimana seorang manajer pabrik yang hampir bangkrut menyelamatkan pabriknya. Inti seluruh buku ini hanya satu kalimat: Output dari setiap sistem ditentukan oleh tahap paling sempitnya (constraint, atau bottleneck).
Memperlebar tahap yang bukan bottleneck tidak akan meningkatkan output total; hanya dengan memperlebar bottleneck itu sendiri, keseluruhan sistem akan menjadi lebih cepat. Dan begitu kamu memperlebar bottleneck, ia langsung berpindah ke tahap paling sempit berikutnya. Inilah yang disebut Theory of Constraints (TOC).
Setelah 40 tahun otomasi di sektor manufaktur, hampir seluruhnya adalah sejarah “perpindahan bottleneck”. Ketika mesin CNC membuat proses pemotongan menjadi lebih murah, bottleneck berpindah ke pergantian cetakan dan inspeksi kualitas; ketika lini produksi fleksibel mempercepat pergantian cetakan, bottleneck berpindah ke perencanaan produksi dan koordinasi rantai pasok; ketika MES membuat perencanaan produksi lebih akurat, bottleneck berpindah ke prediksi permintaan dan penjadwalan lintas pabrik. Setiap kali satu segmen diotomasi, segmen berikutnya muncul ke permukaan. Otomasi tidak pernah menghilangkan bottleneck, ia hanya mengganti posisinya. Aturan ini bukan milik eksklusif manufaktur. Pada Juli 2026, dalam podcast a16z berjudul Software in the Age of Agents, mantan Presiden Windows Microsoft, Steven Sinofsky, menggunakan contoh perangkat lunak perusahaan untuk secara independen menyimpulkan kesimpulan yang sama. Ucapannya persis: > “The long tail got no shorter. It just got longer in a different way.”
Ia contoh layanan pelanggan Amazon: menghapus panggilan telepon dan membiarkan chatbot langsung mengirim ulang produk—terlihat hemat tenaga kerja, tapi sistem belakang segera menghadapi kebutuhan analisis akar penyebab: “Bagaimana mencegah masalah serupa terulang?”—yang jauh lebih kompleks daripada menjawab telepon. Proses pelaporan biaya pun sama: setelah OCR otomatis mencatat transaksi, tugas keuangan berubah menjadi optimasi kinerja perjalanan dinamis dan perbandingan harga real-time—pekerjaannya tidak hilang, tapi bergeser dari “pemasukan data” ke “analisis dan pengambilan keputusan”. Seorang veteran Microsoft dan mitra a16z, tanpa menggunakan teori Goldratt, sampai pada kesimpulan yang sama seperti yang muncul di manufaktur 40 tahun lalu. Satu berasal dari lantai pabrik, satu lagi dari perangkat lunak perusahaan—dua jalur independen yang menuju pada hukum yang sama.
Namun, perlu ditambahkan batasan pada hukum ini agar tidak dianggap sebagai kebenaran mutlak. Memang ada pekerjaan yang benar-benar hilang selamanya: pengetik, operator telepon, pekerja cetak timah—pekerjaan-pekerjaan ini tidak “bergeser ke atas”, mereka benar-benar menghilang. Untuk menentukan apakah suatu pekerjaan akan dipindahkan atau dihapus, kuncinya adalah melihat apakah kapasitas yang dirilis oleh otomatisasi memicu permintaan baru (dalam ekonomi disebut paradoks Jevons), atau hanya membuat permintaan tersebut menyusut. Sebagian besar pekerjaan di sekitar sistem inti perusahaan termasuk kategori pertama: semakin cepat akun dihitung, semakin banyak dan semakin detail analisis yang ingin dilihat bos. Jadi kesimpulan di sini bukan “otomatisasi bisa menghapus berapa banyak pekerjaan”, melainkan “pindahkan orang dan anggaran dari lapisan yang otomatisasi, ke lapisan baru yang muncul.” (Lanjutan perspektif perangkat lunak perusahaan tentang pemindahan ekor panjang—dijelaskan lengkap dalam esai tambahan “Kekuatan Lengket Perangkat Lunak Perusahaan”.)
Hal ini lebih dekat dengan perangkat lunak daripada yang Anda kira. Pada 2013, Gene Kim hampir secara langsung mengadaptasi kisah pabrik Goldratt ke dalam operasi TI, menulis The Phoenix Project: bagaimana seorang CIO menyelamatkan departemen TI yang hampir menghancurkan perusahaan dengan menggunakan Theory of Constraints. Jadi, “melihat perangkat lunak melalui lensa bottleneck manufaktur” adalah jalur yang sudah teruji, bukan sekadar metafora sementara. # II. Kembali ke Perangkat Lunak: Menulis Kode Sedang Menjadi Tahap Paling Murah Tiga angka menjelaskan dengan jelas “biaya produksi kode mendekati nol”.
- Copilot: Penelitian internal GitHub menunjukkan bahwa di file yang mengaktifkan Copilot, sekitar 46% kode dihasilkan oleh Copilot. Perhatikan cakupannya: ini adalah persentase dalam file yang mengaktifkan fitur, bukan 46% dari seluruh kode di GitHub.
- Stripe: Agent coding buatan sendiri bernama “Minions” menghasilkan dan menggabungkan lebih dari 1.300 PR per minggu (awalnya 1.000, terus meningkat). Ada detail kunci yang perlu diingat: setiap PR harus melalui tinjauan manusia sebelum digabungkan. Stripe mengotomatisasi “penulisan”, tetapi mempertahankan “penerimaan” untuk manusia. Poin ini akan digunakan di bagian keempat.
- NVIDIA: Jensen Huang secara terbuka menyatakan bahwa 100% insinyur NVIDIA menggunakan alat pemrograman AI seperti Cursor; “bekerja tanpa AI” sudah tidak diterima di NVIDIA.
Gabungkan ketiga angka ini, kesimpulannya jelas: biaya per baris kode sedang cepat mendekati nol. Pertanyaan tajam muncul: jika menulis kode hampir gratis, mengapa perangkat lunak masih mahal, lambat, dan sulit diserahkan? Jawabannya sesuai dengan Teori Kendala: Anda memperlebar proses “menulis kode”, tetapi bottleneck hanya bergeser. Ke mana ia bergeser?
Tiga: Botol Leher Pindah ke Empat Tempat
Kali ini, botol leher terkonsentrasi pada empat tahap proses. Setiap tahap adalah hal yang tidak bisa dijangkau AI dalam jangka pendek.
Tahap Pertama: Mendefinisikan Masalah yang Tepat.
AI bisa menulis “fitur yang kamu sebutkan” dalam beberapa detik, tapi tidak bisa menulis “fitur yang benar-benar kamu butuhkan”. Sebagian besar proyek perangkat lunak gagal karena hasilnya tidak digunakan siapa pun—awalnya, masalah yang ingin dipecahkan tidak dipahami secara mendalam. Setelah produksi kode menjadi murah, “mengurai masalah bisnis yang kabur menjadi spesifikasi yang jelas, dapat dipecahkan, dan layak dipecahkan” (problem formulation) menjadi kemampuan paling langka dan paling mahal. Rekan industri manufaktur tidak asing dengan hal ini: jika jalur proses dan gambar teknik salah, semakin efisien pabrik memproses, semakin banyak produk yang diproduksi secara massal tapi rusak.
Tahap Kedua: Integrasi Sistem.
AI ahli dalam menghasilkan “sepotong kode”, “sebuah fungsi”, “sebuah halaman”. Tapi sistem yang bisa diluncurkan adalah integrasi dari ratusan potongan yang harus saling berkomunikasi, menangani batasan, menjaga konsistensi, dan bertahan terhadap pengecualian. Menghasilkan potongan-potongan itu murah, tapi menyatukannya menjadi keseluruhan yang andal harganya mahal. Biaya ini berakar pada sinkronisasi organisasi dan arsitektur—hal yang menjadi fokus Hukum Conway dan Team Topology (lihat dua artikel sebelumnya dalam seri ini). Kembali ke CIO manufaktur di awal: waktunya tidak habis untuk menulis kode, tapi untuk mengintegrasikan sistem MES, ERP, inspeksi kualitas, dan pelaporan.
Ketiga: Verifikasi. Jumlah kode meledak, tingkat kepercayaan bervariasi. Siapa yang memutuskan “ini benar”? Pengujian, code review, observabilitas, dan peluncuran bertahap—beban pekerjaan “verifikasi” ini justru meningkat. Ini adalah bottleneck paling diremehkan, sekaligus bayangan paling dalam dari manufaktur. Akan dibahas tersendiri di bagian keempat.
Keempat: Penyelarasan Organisasi. Ketika tim dipenuhi agen AI, siapa yang menentukan apa yang harus dikerjakan, siapa yang meninjau, dan siapa yang bertanggung jawab atas hasilnya? Ini adalah kelanjutan dari Hukum Conway dan Topologi Tim—penyelarasan organisasi sendiri kini menjadi bottleneck. Artikel ke-11 dalam seri ini akan membahasnya secara khusus: ketika simpul organisasi bukan lagi semuanya manusia, tata kelola menjadi kompetensi inti.
# Empat: Potongan Paling Dalam: Verifikasi, dan Apa Sebenarnya yang Diajarkan "Jidoka" ToyotaDari keempat bottleneck, yang paling sering salah dipahami adalah verifikasi. Banyak orang menganggapnya sebagai “karena AI cepat menulis kode, maka lakukan lebih banyak pengujian.” Ini hanya separuh benar. Untuk memahami mengapa verifikasi jadi lebih mahal, kita harus memperbaiki konsep Toyota yang paling sering disalahartikan—dan paling sering disalahgunakan: Jidoka.
Pertama, perbaiki kesalahpahaman yang tersebar luas. Jidoka bukan berarti “mengganti manusia dengan AI atau mesin”, juga bukan “membuat manusia seperti mesin, terus bekerja tanpa henti”. Kedua arah ini justru salah arah.
Kataoka secara harfiah sudah menyimpan jawabannya. Dalam bahasa Jepang, “otomatisasi” biasa ditulis sebagai “自動化”, tetapi Toyota sengaja menggunakan “自働化”—karakter “働” yang memiliki radikal manusia, menekankan “otomatisasi dengan sentuhan manusia” (automation with a human touch). Makna tepatnya adalah: ketika mesin atau lini produksi mendeteksi anomali, ia berhenti secara otomatis, memungkinkan manusia masuk untuk mengidentifikasi dan menyelesaikan akar masalah, lalu melanjutkan produksi. Ada dua mekanisme yang berjalan paralel: mesin dilengkapi deteksi anomali sendiri dan akan berhenti otomatis; siapa pun di lini produksi yang mendeteksi ketidaknormalan bisa menarik tali andon, dan seluruh lini akan langsung berhenti. Kualitas tidak diuji di ujung lini, tetapi diintegrasikan ke setiap tahap proses dan diselesaikan di tempat.
Ini adalah kesimpulan yang kontra-intuitif, yang secara langsung berpadanan dengan perangkat lunak: semakin dalam otomatisasi, semakin besar pula jumlah checkpoint kualitas dan peran manusia yang diperlukan. Kataoka membebaskan manusia dari “operasi berulang” dan menempatkannya kembali pada posisi “mendeteksi anomali, menghentikan lini, menyelesaikan akar masalah.” Toyota memberi pekerja lini hak untuk menghentikan seluruh produksi—justru karena mereka paham: sekuat apa pun otomatisasi, tetap dibutuhkan manusia yang bisa menghentikannya saat terjadi masalah. Inilah makna sejati dari slogan “memberi kecerdasan pada robot”: memberi mesin kemampuan untuk berhenti dan memanggil manusia. Manusia tetap hadir, bertanggung jawab atas penyelesaian akar masalah.
Perangkat lunak sedang menempuh jalan ini dengan sangat cepat. Penelitian GitClear tentang kualitas kode yang dibantu AI telah mengamati tanda-tanda peningkatan blok kode berulang dan churn jangka pendek: AI menulis cepat, tetapi juga menulis “terlihat benar”. Ketika sejumlah besar kode tidak pernah ditulis baris demi baris oleh manusia, mekanisme kepercayaan tradisional seperti “pengembang paham apa yang mereka lakukan” menjadi tidak berlaku. Di titik ini, yang Anda butuhkan adalah versi perangkat lunak dari tali Andon dan mekanisme penghentian produksi:
- Pengujian (unit, integrasi, end-to-end) naik dari “sebaiknya dilakukan” menjadi batas wajib: tidak lulus, tidak boleh digabungkan;
- Code review bergeser fokus dari “memeriksa cara penulisan” menjadi “memeriksa niat dan batasan”: kode ini sebenarnya ingin menyelesaikan apa, dan apakah semua kondisi batas sudah tercakup;
- Observability (monitoring, logging, tracing) menjadi standar wajib, karena perilaku di produksi lebih jelas menggambarkan masalah daripada kode itu sendiri;
- Gray release / feature flag memungkinkan kode yang dihasilkan AI diuji terlebih dahulu dalam skala kecil, baru diluncurkan luas setelah diverifikasi aman.
Melihat kembali bagian kedua tentang 1.300 PR Stripe: penulisan dikerjakan oleh agen, proses penggabungan tetap sepenuhnya diserahkan ke tinjauan manusia. Ini adalah contoh nyata otomasi dalam perangkat lunak: otomatisasi produksi, tetapi penilaian akhir tetap di tangan manusia—dan manusia diberi wewenang untuk “menghentikannya”. Produksi menjadi lebih murah, kontrol kualitas menjadi lebih mahal—ini adalah hukum yang tidak berubah selama 40 tahun.
V. Premi “Mendefinisikan Masalah”: Kemampuan yang Lebih Berharga daripada Prompt
Jika verifikasi adalah bottleneck yang diremehkan, “mendefinisikan masalah” adalah kemampuan yang jauh lebih diremehkan. Prompt engineering sempat populer, dan banyak yang mengira “bisa menulis prompt” adalah kemampuan inti. Tapi prompt hanyalah teknik untuk “mengekspresikan masalah”. Yang benar-benar langka adalah langkah lebih jauh lagi: problem formulation — memecah masalah bisnis yang kabur menjadi sebuah masalah yang jelas, dapat dipecahkan, dan layak dipecahkan. Langkah ini tidak bisa dilakukan AI dalam jangka pendek, karena AI harus menunggu Anda memberi tahu dulu: “Apa masalahnya?”
Para ahli manufaktur paling memahami betapa pentingnya langkah ini. Jika satu gambar teknik atau jalur proses salah, seberapa pun efisien pemrosesan dan perakitan di hilir, hasilnya tetap produksi massal kesalahan. Sama halnya dengan perangkat lunak: jika spesifikasi kebutuhan salah, AI akan membantu Anda membuat sepuluh kali lebih cepat — tapi produk yang tak ada yang mau.
Kriteria sederhananya: Jangan lagi bersaing dalam “kecepatan menulis kode”, tapi latih “kejelasan memecah masalah”. Dalam organisasi, ini berarti menjadikan “definisi kebutuhan” dan “verifikasi penerimaan” sebagai posisi resmi — jangan biarkan pengembang mengerjakannya secara sambilan. Setelah AI membuat implementasi jadi murah, kedua peran ini akan menghasilkan return tertinggi.
VI. Seperti Apa Bottleneck Nyata di Empat Industri
Menerapkan “pergeseran bottleneck” ke empat industri, bottleneck masing-masing tidak berada pada penulisan kode.
Manufaktur. Garis utamanya adalah CIO yang disebutkan di awal. Fungsi-fungsi seperti penjadwalan cerdas, pelacakan kualitas, dan optimasi konsumsi energi secara teknis tidak sulit—model-modelnya sudah tersedia. Kendalanya terletak pada integrasi dan penyesuaian antar sistem MES/ERP/quality inspection/laporan, serta validasi lapangan di terminal pabrik. Kode proyek semacam ini biasanya cepat ditulis, tetapi integrasi MES/ERP memakan waktu beberapa kali lebih lama daripada penulisan kode; hanya dengan menempatkan tim penerimaan langsung di titik terminal pabrik dan proses integrasi, cacat bisa dicegah sejak dini, bukan baru terungkap saat produksi sudah berjalan.
Telekomunikasi / Operator. Proses perubahan paket atau pembukaan jalur khusus korporat harus melewati beberapa domain: saluran, billing, CRM, pembukaan jaringan, dan penjadwalan instalasi. AI mempercepat pengembangan di masing-masing domain, tetapi integrasi end-to-end lintas domain dan verifikasi konsistensi justru menjadi porsi terbesar dari jadwal proyek. Operator juga memiliki hambatan unik: kepatuhan dan rekonsiliasi. Selisih satu sen dalam billing adalah insiden; verifikasi di sini lebih berat daripada di industri mana pun. Misalnya, dalam pembukaan jalur khusus korporat: meski AI mempercepat pengembangan di tiap domain, integrasi end-to-end ditambah rekonsiliasi billing sering tetap memakan separuh atau lebih dari seluruh waktu proyek.
Keuangan. Penyesuaian aturan kredit risk management atau anti-money laundering melibatkan berbagai sistem: App, sistem inti, engine risk management, data platform, dan pelaporan regulasi. Validasi di sini memiliki bobot sangat tinggi, karena satu kesalahan saja bisa menjadi insiden kepatuhan. Bottlenecknya ada pada penjelasan, auditabilitas, dan traceability: aturan yang ditulis AI seakurat apa pun, jika tidak bisa menjawab pertanyaan regulator “mengapa keputusan ini diambil”, tetap tidak bisa diluncurkan. Iterasi aturan anti-money laundering adalah contoh klasik: AI mempercepat penulisan aturan, tetapi proses audit terhadap interpretabilitas model dan sinkronisasi pelaporan regulasi sering kali memakan separuh lebih dari seluruh siklus.
E-commerce. Fungsi promosi atau kampanye besar melibatkan produk, transaksi, pemasaran, gudang, dan layanan pelanggan. AI mempercepat penulisan halaman dan antarmuka, tetapi bottleneck bergeser ke stress testing, konsistensi stok, pencegahan penyalahgunaan promo, dan reconciliasi. Sistem yang down pada malam kampanye besar bukan karena kode yang lambat ditulis, tapi karena batasan yang tidak diuji. Persiapan kampanye besar adalah cerminan nyata: halaman promosi bisa dihasilkan AI dalam sekejap, tetapi stress testing end-to-end dan verifikasi konsistensi stok sering kali memakan separuh lebih dari seluruh waktu persiapan.
Empat industri ini memiliki kesamaan jelas: AI mempercepat “penulisan”, tetapi yang menghambat adalah “pemaduan, verifikasi, dan sinkronisasi”. Menyalurkan kapasitas pengembangan yang dihemat ke tiga hal ini adalah cara nyata untuk meningkatkan efisiensi.
7. Apa yang Terjadi Jika Salah: Tiga Ketidaksesuaian Paling Umum
Pertama: Menganggap “menulis kode cepat” sebagai “pengiriman lebih cepat”. Ini adalah ilusi paling umum. Kode hanyalah satu tahap dalam rantai pengiriman; memperlebarnya tidak akan mempercepat keseluruhan rantai, justru hanya menumpuk lebih banyak produk setengah jadi di belakang bottleneck. Teori Constraint menyebut ini sebagai stok, di dunia perangkat lunak disebut PR yang belum diterima dan cabang yang belum diintegrasikan. Hasilnya: pengembang semakin sibuk, bisnis semakin mendesak, tapi output tetap sama — persis seperti situasi CIO yang disebutkan di awal.
Kedua: Mempercepat produksi sekaligus menghapus gerbang kualitas. Ini adalah kesalahan klasik yang melanggar prinsip Jidoka. Ada yang berpikir, “AI menulis kode cepat dan bagus, jadi code review bisa disederhanakan, pengujian bisa dihapus.” Justru sebaliknya: semakin cepat produksi, semakin penting tarikan tali An andon. Menghapus gerbang verifikasi sama saja dengan membiarkan lini produksi tanpa pengawas berjalan full speed — cacat akan mengalir lebih cepat ke lingkungan produksi.
Ketiga: Menginvestasikan uang di tempat yang bukan bottleneck. Integrasi adalah bottleneck, tapi Anda membeli lebih banyak lisensi AI programming; verifikasi adalah bottleneck, tapi Anda merekrut lebih banyak pengembang. Teori Constraint sudah jelas: menambahkan sumber daya di luar bottleneck tidak memberi kontribusi pada output total, hanya membuat laporan keuangan semakin buruk. Urutan yang benar: pertama identifikasi bottleneck, lalu arahkan semua sumber daya ke sana.
Delapan: Implikasi bagi Pembuat Keputusan
Pesan Satu: Sebelum membeli alat, buat peta bottleneck terlebih dahulu.
Pecah tiga deliverable terakhir yang membuatmu terhenti, lalu lihat waktu benar-benar habis di mana. Apakah karena tidak bisa menulis kode, tidak bisa menyatukan komponen, tidak ada yang mengecek, atau kebutuhan belum jelas? Jika tidak bisa ditandai, berarti kamu hanya menebak-nebak di level teknis. Peta bottleneck lebih berharga daripada daftar pembelian alat apa pun—ia bisa mencegah setidaknya separuh investasi TI yang sia-sia di perusahaan besar.
Pesan Dua: Gunakan kapasitas yang dihemat untuk kebutuhan dan verifikasi.
AI membuat pengembangan lebih cepat, artinya kamu punya sumber daya yang bisa dialihkan. Masukkan orang-orang ini secara resmi ke dalam dua peran: “definisi kebutuhan” dan “verifikasi penerimaan”—jangan biarkan mereka terus menulis lebih banyak kode. Return on investment dari dua peran ini paling cepat naik di era AI.
Pesan Tiga: Pasang tali an-dan pada perangkat lunakmu.
Implementasi paling langsung dari jidoka adalah menetapkan batas keras di CI/CD-mu: tidak boleh merge jika tes gagal, review wajib memeriksa niat dan batasan, rilis gray-scale dimulai dari skala kecil, dan observabilitas menjadi standar wajib. Semakin otomatis produksimu, semakin kencang batas ini harus dijaga. Ini mencegah “kode gratis” berubah menjadi “kecelakaan gratis”.
Pesan Empat: Atur ulang posisi manusia, jangan hapus mereka.
Jidoka mengarah pada kesimpulan yang sama: semakin dalam otomasi, semakin manusia harus ditempatkan di posisi “penilaian, verifikasi, dan pencarian akar penyebab”. Lepaskan manusia dari operasi berulang, lalu redeploy mereka ke verifikasi dan alignment—ini adalah tindakan inti dalam desain organisasi di era AI, dan akan dikembangkan lebih lanjut di beberapa artikel berikutnya dalam seri ini.
Sembilan: Mungkin kamu bertanya
“Kami hanya menguji coba AI secara terbatas, kenapa harus membuat peta bottleneck seluruh perusahaan?”
Namun, uji coba pun harus dimulai dengan memahami: apakah tahap yang diuji coba ini benar-benar bottleneck? Jika titik penyumbatannya justru ada di integrasi atau verifikasi, maka menguji coba AI di tahap “menulis kode” berarti membuang uang di tempat yang bukan bottleneck—tepat memicu ketidaksesuaian tipe ketiga yang dibahas di Bab 7. Lakukan diagnosa bottleneck kecil terlebih dahulu, baru uang alat bisa terpakai dengan tepat.
“Apakah gerbang verifikasi akan memperlambat pengiriman?”
Secara jangka pendek memang ada gesekan, tapi jangka panjang justru mempercepat. “Kecepatan” tanpa gerbang verifikasi adalah kecepatan yang mendorong cacat ke lingkungan produksi—biaya rework mulai dari sepuluh kali lipat. Pengalaman otomatisasi menunjukkan: biaya memperbaiki satu cacat di tempat asalnya, hanyalah sebagian kecil dari biaya memperbaikinya setelah cacat itu mengalir ke tahap selanjutnya.
“Ini ada hubungannya dengan transformasi AI yang sedang kami lakukan?”
Hubungannya sangat langsung. Jebakan paling sering dijumpai dalam transformasi AI adalah asumsi bahwa bottleneck ada di “menulis kode / kapasitas produksi”, lalu membeli banyak alat untuk memperlebar tahap itu. Lakukan diagnosa bottleneck terlebih dahulu, baru putuskan di mana uang harus dihabiskan. Inilah sebabnya saya menempatkan “evaluasi kemampuan” dan “identifikasi skenario nilai” di posisi awal dalam Framework Pelatih 7 Langkah Transformasi AI: lihat dulu di mana bottleneck-nya, baru bicara soal alat.
Pemeriksaan Balik (jawab tanpa mempercantik): Terakhir kali kamu terjebak dalam pengiriman, waktu habis lebih banyak untuk menulis kode, atau untuk menyusun, memeriksa, dan menyelaraskan? Berapa banyak kode yang dihasilkan alat AI-mu yang benar-benar bisa diluncurkan secara stabil dan digunakan oleh pengguna? Di CI/CD-mu, apakah ada pintu keras berupa “tidak boleh merge jika tes gagal”? Jika salah satu dari tiga pertanyaan ini membuatmu merasa tidak yakin, jangan buru-buru membeli lebih banyak alat AI—pertama, temukan dulu bottleneck-mu.
Langkah Selanjutnya
Ini adalah bagian ketiga dari seri 15 tulisan “Transformasi Rekayasa Perangkat Lunak di Era AI”. Dari Conway (organisasi menentukan arsitektur), hingga Team Topologies (bagaimana merancang organisasi), kita sekarang sampai pada pergeseran bottleneck (ketika kode hampir gratis, ke mana bottleneck pergi?). Tulisan berikutnya (bagian ke-4) akan beralih ke perspektif yang lebih praktis: bagaimana memilih alat pemrograman AI utama. Namun, kesimpulannya mungkin kontra-intuitif: pemilihan alat pada dasarnya adalah keputusan organisasi—pilih berdasarkan tingkat kedewasaan dan tingkat tata kelola-mu, bukan berdasarkan “siapa yang menghasilkan kode paling keren”.
Catatan Seri: Seri ini akan terus memantau perkembangan terbaru dalam alat pemrograman AI, arsitektur organisasi, dan paradigma rekayasa perangkat lunak—seperti perubahan Hukum Conway di era agen AI tahun 2026, atau kedewasaan ekosistem alat terbaru. Ikuti seri ini untuk mendapatkan wawasan pembaruan berkelanjutan.
Tentang Seri Ini
Perubahan Rekayasa Perangkat Lunak di Era AI adalah seri penelitian mendalam yang ditujukan bagi CIO/CDO/CTO dan pemimpin digital di industri telekomunikasi, keuangan, manufaktur, dan e-commerce, terdiri dari 15 artikel. Berdasarkan 200+ makalah akademis dan laporan industri, seri ini menyediakan referensi keputusan dengan label tingkat bukti.
Saya adalah mantan insinyur IBM dan pelatih bersertifikat ICF, yang telah mengimplementasikan proyek AI/digital di operator telekomunikasi dan perusahaan besar. Semua yang saya tulis di sini adalah penilaian praktis yang diuji melalui pengalaman langsung membantu perusahaan melewati tantangan.
Sumber Referensi (telah diverifikasi)
- a16z (2026). Software in the Age of Agents. The a16z Podcast. (Kutipan Steven Sinofsky, mantan Presiden Windows Microsoft: “The long tail got no shorter, it just got longer in a different way”; perspektif perangkat lunak enterprise secara mandiri mengonfirmasi Hukum Pemindahan Bottleneck TOC; sumber primer — rekaman asli podcast. Penanda Posisi: Mitra a16z / mantan eksekutif Microsoft, posisi VC. Tamu telah diverifikasi: Mitra tim enterprise a16z Seema Amble, mantan Presiden Windows Microsoft Steven Sinofsky (board partner), penulis a16z Elena Burger; dirilis Juli 2026.)
- Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Sumber asli Teori Constraints (TOC); sumber primer; novel yang menggambarkan pabrik manufaktur.)
- Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Menerapkan TOC Goldratt secara langsung ke运维 IT; jembatan dari manufaktur ke perangkat lunak; sumber primer.)
- Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = otomasi dengan karakter 人; berhenti garis produksi saat anomali + intervensi manusia untuk mengatasi akar masalah; sistem Andon; sumber primer.)
- GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot menghasilkan sekitar 46% kode dalam file yang diaktifkan; metrik “enabled file”; sumber primer.)
- Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ melaporkan 1.300+ PR per minggu, ditinjau sepenuhnya oleh manusia (sumber primer + sekunder)
- NVIDIA / Jensen Huang. Pernyataan publik bahwa 100% insinyur menggunakan alat pemrograman AI seperti Cursor (pernyataan langsung.)
- GitClear (2025). AI-Assisted Code Quality Research. (Mengamati peningkatan kode berulang dan churn jangka pendek di bawah bantuan AI, mendukung argumen “verifikasi menjadi lebih mahal”; sumber sekunder.)
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Kinerja pengiriman ditentukan oleh budaya, kecepatan aliran, dan umpan balik, bukan kecepatan coding individu; sumber primer.)
buymeacoffee
![[Peralihan Bottleneck] Ketika kode hampir gratis, ke mana perginya bottleneck teknik perangkat lunak? Transformasi Teknik Perangkat Lunak di Era AI — Belajar AI Secara Perlahan 173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
![[Arsitektur organisasimu, sudah menentukan takdir perangkat lunakmu] Hukum Conway—Hukum Manajemen yang Diremehkan Selama 56 Tahun Transformasi Rekayasa Perangkat Lunak di Era AI—Belajar AI Secara Perlahan 171](https://cdn.iaiuse.com/img/2026/04/06/97308b44819c0d12a4fd8e758b91ddd0.webp)
