Pabrik industri telah mengubah cara dunia memproduksi barang fisik dengan lebih banyak hasil, biaya lebih rendah, dan kecepatan yang belum pernah ada sebelumnya. Sekarang, perubahan serupa sedang terjadi dalam bidang perangkat lunak.
Large Language Models (LLMs) telah menurunkan hambatan untuk menulis kode, meningkatkan produktivitas individu, dan mendorong perusahaan untuk memikirkan pengembangan perangkat lunak sebagai sistem produksi. Siklus hidup pengembangan perangkat lunak dan praktik CI/CD yang selama ini dipakai tidak akan mampu bertahan di bawah tekanan ini. Di sinilah pabrik perangkat lunak berperan — dan, seperti pabrik fisik, ia membutuhkan lebih dari sekadar kecepatan untuk berfungsi dengan baik.
Konsep “pabrik perangkat lunak†mulai menguat dalam setahun terakhir. Buku Luca Rossi “The Era of the Software Factory” menjelaskan dengan jelas: AI bukan hanya mengubah seberapa cepat orang menulis kode, tetapi juga mengubah seluruh sistem produksi perangkat lunak.
Istilah ini bisa berarti banyak hal: kumpulan agen pemrograman dan file keterampilan, CI/CD yang lebih cepat, sistem tinjauan yang lebih baik, atau lebih banyak otomatisasi dalam pengiriman perangkat lunak. Kerangka yang lebih baik adalah dengan memandangnya bukan hanya sebagai kategori alat, tetapi sebagai seperangkat prinsip. Pabrik perangkat lunak tidak bisa hanya sekadar kumpulan pemicu, agen, dan plugin yang sembarangan. Ia membutuhkan platform yang mendefinisikan bagaimana pekerjaan bergerak melalui sistem, serta bagaimana kode dihasilkan, ditinjau, diuji, dilacak, dikerahkan, dan ditingkatkan ketika ada yang salah.
Jika tidak, semua yang Anda lakukan hanyalah menempatkan satu mesin tambahan dalam ruangan kosong dan menyebutnya pabrik.
Mengapa ini terjadi sekarang?
Ada beberapa faktor yang berperan bersamaan.
Perusahaan selalu menginginkan lebih banyak perangkat lunak daripada yang bisa diproduksi oleh insinyur. Itulah sebabnya alat seperti Excel ada — sering kali mengisi celah untuk banyak perangkat lunak yang diinginkan berbagai perusahaan.
AI juga telah menurunkan hambatan untuk membuat kode, dan inilah bagian yang menjadi fokus semua orang. Membuat kode sekarang lebih mudah, meskipun tidak selalu lebih murah atau lebih baik, seperti yang dibuktikan oleh banyak perusahaan terkenal yang khawatir mengenai tagihan AI mereka yang tinggi. Hambatan untuk menulis kode fungsional telah runtuh.
Lebih penting lagi, seorang insinyur dapat menghasilkan lebih banyak kode daripada yang bisa mereka lakukan hanya beberapa tahun lalu. Ini mengubah titik penyumbat: sekarang bukan lagi “Seberapa cepat seseorang bisa menulis ini?†atau bahkan, dalam beberapa kasus, “Bisakah seseorang memahami cara menulis kode?†Melainkan menjadi, “Apakah ini perlu ditulis?â€
Hal yang lebih penting lagi, kita dapatkah benar-benar menciptakan produk akhir yang tahan lama dan dapat diandalkan, tanpa hanya membangun utang teknologi? Atau apakah kita hanya memproduksi lebih banyak produk AI dengan cepat? Di situlah letak bahayanya.
Bahaya dari pabrik perangkat lunak modern
Semua ini terdengar hebat. Pabrik, setelah semua, membuat produksi lebih cepat dan lebih konsisten.
Mereka memungkinkan lebih banyak mobil dan produk dibangun dengan biaya lebih rendah, yang membuat lebih banyak orang mampu membeli produk-produk tersebut. Mengesampingkan dampak lingkungan, bisa dibilang ini hal yang positif.
Tapi seperti banyak aspek dalam rekayasa, selalu ada trade-off, dan dalam hal ini, ada risiko baru.
Ketika Anda meningkatkan output dari seseorang dengan mesin, digital atau tidak, Anda juga meningkatkan kesalahan yang bisa terjadi baik oleh individu maupun mesin tersebut. Kecepatan di mana kode sekarang bisa dihasilkan berada pada skala industri. Bahkan organisasi yang lebih kecil pun tiba-tiba dapat memiliki basis kode yang membengkak hingga ukuran basis kode perusahaan teknologi sepuluh tahun lalu.
Data menunjukkan masalah ini. Faros AI menemukan bahwa walaupun throughput tugas per pengembang meningkat 33,7% dan tingkat penggabungan PR naik 16,2%, rasio insiden terhadap PR telah meningkat 242,7% dan bug per pengembang naik 54%. Penelitian DORA Google menemukan bahwa lebih banyak penggunaan AI sebenarnya terkait dengan stabilitas pengiriman yang lebih buruk.
Saya telah diminta untuk memperbaiki masalah ini sebagai kepala data sementara. Dalam setahun terakhir, saya telah terlibat dalam dua proyek di mana infrastruktur data yang dihasilkan AI mulai berubah seiring waktu.
Di antara banyak insinyur yang mencoba bergerak cepat dan kurangnya standar, proyek-proyek ini menjadi sulit diatur. Dasar kode biasanya mengalami evolusi, tapi ketika berbagai gaya bergabung, LLM pada gilirannya mulai menciptakan mutasinya sendiri. Basis kode berkembang dengan lima hingga enam gaya dalam beberapa bulan — proses yang sebelumnya memakan waktu bertahun-tahun. Secara bertahap, para insinyur mulai kehilangan pemahaman tentang apa yang sebenarnya terjadi.
Pola ini mengingatkan kita pada apa yang terjadi satu dekade lalu dengan alat layanan mandiri: peningkatan produktivitas awal yang menutupi kompleksitas yang muncul kemudian.
Dan itulah mengapa pabrik perangkat lunak tidak bisa hanya berfokus pada kecepatan.
Apa yang membuat pabrik perangkat lunak berfungsi
Ada beberapa prinsip kunci yang perlu dipertimbangkan saat membangun pabrik perangkat lunak.
Platform di atas alat: Banyak tim secara perlahan mulai mengimplementasikan AI dalam alur kerja pemrograman mereka — menambahkan agen tinjauan PR atau file keterampilan ke dalam repositori mereka. Namun, membangun pabrik perangkat lunak yang sebenarnya memerlukan platform, bukan hanya kumpulan alat di pinggiran. Platform memberikan fondasi yang terpadu di mana alat tidak tersebar di sudut-sudut terpisah. Sebaliknya, mereka secara aktif berbagi data, berkomunikasi satu sama lain, dan bekerja sebagai sistem yang kohesif — standar, proses, dan pekerjaan itu sendiri semua saling terhubung.
Kemampuan ulang dan jejak: Platform yang nyata memerlukan kemampuan untuk kembali ke setiap run, mengidentifikasi apa yang salah, dan menjalankannya kembali — itulah sebabnya agen sekali pakai tidak bisa membuat pabrik. Sistem ini perlu mendukung pengambilan ID serial, mencarinya, dan melacak dengan tepat bagaimana ia mencapai output yang dihasilkan. Inilah sebabnya mesin status lebih masuk akal daripada loop untuk alur kerja AI: mereka memudahkan untuk menjalankan kembali suatu proses dan memahami apa yang terjadi di setiap langkahnya.
Keamanan dan pengaman: Pabrik bukanlah tempat yang aman. Begitu juga pabrik perangkat lunak. Seiring semakin banyak orang yang melakukan pengembangan di platform ini, pengaman dan langkah-langkah keamanan yang lebih baik perlu dibangun. Pengujian dan kontrol kualitas perlu didorong ke depan proses — menangkap bug pada tahap terendah dapat mengurangi biaya perbaikannya dan membatasi dampak luasnya.
Standardisasi: Di tingkat perusahaan, setiap basis kode memiliki ciri khasnya sendiri. Menambahkan asisten kode tanpa standar akan menghasilkan campuran gaya. Standardisasi harus dibangun dalam proses sejak awal.
Kontrol kualitas: Dalam model manufaktur lama, kontrol kualitas terjadi di ujung jalur. Produk dibangun, diperiksa, cacat ditemukan, dan diperbaiki kemudian. Pendekatan Toyota berbeda. Kualitas didorong ke dalam proses itu sendiri — pekerja diharapkan menghentikan jalur ketika ada yang salah. Tujuannya bukan untuk menangkap cacat di akhir; tetapi untuk mencegahnya mengalir lebih jauh ke bawah.
Hal yang sama berlaku untuk pabrik perangkat lunak. QC perlu terintegrasi ke dalam seluruh proses, mulai dari cara spesifikasi ditulis. Ini berarti mengintegrasikan analisis kode statis yang menangkap kesalahan yang jelas dan menyediakan template kepada LLM agar mereka tahu struktur yang harus diikuti kode. Tanpa itu, titik penyumbat akan menjadi tinjauan akhir — atau tim hanya akan mengeluarkan lebih banyak produk AI yang kualitasnya rendah.
Kecepatan tanpa kualitas bukan produktivitas
Meningkatkan kecepatan output kode Anda bukanlah produktivitas sejati jika masalah di hilir tidak dikelola. Sebuah perusahaan tidak lebih produktif hanya karena menghasilkan jutaan mobil, yang semuanya hancur dalam jarak 100 mil. Juga tidak lebih produktif jika hanya menghasilkan aliran proof-of-concept yang tak pernah masuk ke produksi.
Produktivitas yang sesungguhnya adalah saat pabrik perangkat lunak mengubah token sementara menjadi output yang tahan lama. Mudah untuk membicarakan garis kode dan seberapa cepat tim Anda bergerak.
Pabrik perangkat lunak yang unggul bukanlah yang menghasilkan kode terbanyak, tetapi yang menghasilkan cacat paling sedikit di hilir.
