Rekayasa Perangkat Lunak di Era Asisten AI

Rekayasa Perangkat Lunak Berbasis Agen dan “Mythical Agent-Month”

Rekayasa perangkat lunak berbasis agen mengubah secara radikal cara kita membangun sistem, namun tidak serta-merta menghapus kebutuhan akan penilaian manusia. Di lingkaran pertemanan saya yang dipenuhi insinyur dan ilmuwan data, kami kerap bertanya-tanya: berapa lama lagi keunggulan manusia yang unik ini akan bertahan. Sampai kapan “punya ide bagus” benar-benar berarti, ketika agen mulai menghasilkan ide yang secara statistik lebih baik daripada ide manusia. Untuk saat ini, keberadaan pakar manusia di dalam loop masih terasa tak tergantikan untuk mengarahkan agen menuju hasil berkualitas tinggi. Pertanyaannya: berapa lama lagi hingga ide paling ambisius dapat diubah menjadi perangkat lunak rapi dan siap produksi sementara kita tidur. Keusangan manusia bisa datang perlahan dan disambut, atau justru hadir sebagai kejutan yang tidak menyenangkan. Setidaknya untuk sekarang, saya masih merasa memiliki peran yang relevan.

Saya tidak melihat pekerjaan saya sebagai “vibe coding”, istilah yang menyiratkan pendekatan malas “prompt and chill” yang menghasilkan perangkat lunak berkualitas rendah buatan AI. Saya membangun alat seperti roborev untuk menerapkan ketelitian, pengawasan berkelanjutan, dan peninjauan sistematis pada sesi agen paralel yang saya jalankan. Saya meneliti keluaran branda dengan cermat dan tidak sekadar menerima hasil mentah tanpa verifikasi. Bekerja dengan cara ini, melalui sekumpulan agen alih-alih pengkodean langsung, secara alami mendorong saya merenungkan seperti apa masa depan rekayasa perangkat lunak berbasis agen dalam skala industri.

Relevansi “The Mythical Man-Month” di Era Agen

Sepanjang karier, buku yang paling sering saya rujuk adalah The Mythical Man-Month karya Fred Brooks, sebuah rujukan klasik dalam rekayasa perangkat lunak. Kontribusi paling terkenalnya, Hukum Brooks, menyatakan bahwa menambah tenaga kerja pada proyek perangkat lunak yang terlambat justru membuatnya semakin terlambat. Belakangan ini, saya bertanya-tanya sejauh mana pemikiran Brooks masih relevan di era rekayasa perangkat lunak berbasis agen yang sangat terotomasi. Dapatkah seorang pengembang terampil yang mengorkestrasi sekumpulan agen AI membangun sistem kompleks lebih cepat dan lebih baik dibandingkan tim tradisional. Apakah peningkatan produktivitas jangka pendek akan berujung pada keberhasilan proyek jangka panjang. Atau kita hanya akan menemukan kembali hambatan lama yang sama: perluasan lingkup, pergeseran arsitektur, dan beban koordinasi yang telah menghantui proyek perangkat lunak selama puluhan tahun.

Salah satu argumen inti Brooks adalah bahwa tim kecil berisi orang sangat kompeten mengungguli tim besar dengan kontributor rata-rata. Ia mengibaratkan struktur ideal seperti tim bedah, dengan satu “ahli bedah utama” yang didukung para spesialis yang terkoordinasi. Pengaturan ini menjaga integritas konseptual, yakni kesan bahwa satu pikiran merancang sistem meski banyak tangan yang membangunnya. Rekayasa perangkat lunak berbasis agen membuat tantangan ini semakin intens dan kompleks. Kualitas perangkat lunak yang dihasilkan kini sangat bergantung pada manusia yang mengkurasi dan menyempurnakan spesifikasi, menyetujui atau menolak fitur, serta menjaga agar kode dan arsitektur tidak berputar ke dalam kompleksitas yang tidak perlu.

“Tar Pit” Baru di Era Agen

Brooks juga memperkenalkan metafora “tar pit”, kubangan ter tempat makhluk besar berjuang dan akhirnya terjebak tanpa jalan keluar. Semua orang melihat branda dan mengira masing-masing bisa lolos, namun tar menahan branda semua tanpa pandang bulu. Kini, kita memiliki “kubangan ter agenik” yang baru dalam rekayasa perangkat lunak berbasis agen. Sesi Claude Code paralel, banyak git worktree, dan alur kerja agen lainnya terus bergulat dengan pembengkakan kode dan kompleksitas insidental yang dihasilkan rekan virtual branda. Anda dapat melakukan refactor secara sistematis, tetapi basis kode yang digerakkan agen hampir tak terelakkan menjadi lebih besar dan lebih berbelit dibandingkan sesuatu yang terutama dibuat manusia. Ini adalah utang teknis dalam skala dan kecepatan yang belum pernah kita lihat sebelumnya, utang yang terakumulasi pada kecepatan mesin.

Dalam The Mythical Man-Month, Brooks mengamati bahwa sebuah program yang berfungsi hanyalah sekitar sepersembilan jalan menuju “produk pemrograman” sejati. Produk sejati adalah perangkat lunak yang diuji, didokumentasikan, diperkuat terhadap kasus tepi, dan dapat dipelihara oleh orang selain penulis aslinya. Agen kini membuat “program yang berfungsi” awal, atau lebih tepatnya program yang tampak berfungsi, jauh lebih mudah diakses oleh pengembang. Banyak “vibe coder” bertenaga AI yang baru meremehkan seberapa besar usaha yang masih diperlukan untuk bergerak dari prototipe ke perangkat lunak kelas produksi yang andal.

Hukum Conway dan Struktur Tim Agen

Isu-isu ini menjadi lebih menonjol ketika kita mempertimbangkan Hukum Conway, yang sering dikutip dalam rekayasa perangkat lunak berbasis agen. Hukum ini menyatakan bahwa arsitektur suatu sistem cenderung mencerminkan struktur komunikasi organisasi yang membangunnya. Pertanyaannya adalah: seperti apa bentuknya ketika “tim” tersebut adalah kumpulan agen tanpa status yang tidak memiliki memori persisten dan tidak memiliki pemahaman bersama yang terus berkembang tentang sistem yang branda bangun. Rekayasa perangkat lunak berbasis agen memunculkan pertanyaan baru tentang bagaimana arsitektur lahir dari interaksi agen yang terputus-putus dan tidak selalu konsisten.

Gagasan lain yang bertahan lama dari Brooks adalah masalah koordinasi n(n−1)/2, yang menggambarkan pertumbuhan saluran komunikasi. Ketika tim tumbuh, jumlah saluran komunikasi meningkat secara kuadratik dan menambah beban koordinasi. Dalam rekayasa agenik, jumlah manusia memang lebih sedikit, tetapi masalah koordinasi tidak hilang, melainkan bermutasi menjadi bentuk baru. Sesi agen yang berbeda dapat menghasilkan desain atau rencana yang saling bertentangan dan harus didamaikan oleh manusia. Orkestrasi agen—bagaimana kita mengelola interaksi branda dan menyelesaikan kontradiksi—menjadi topik kompleks tersendiri yang memerlukan metodologi formal. Saya akan membahasnya lebih dalam di kesempatan lain dengan dukungan data empiris.

“No Silver Bullet” dan Kompleksitas Esensial

Dalam esai lanjutannya, “No Silver Bullet” yang terbit pada 1986, Brooks berargumen bahwa tidak ada terobosan teknologi atau manajerial tunggal yang akan memberikan peningkatan satu orde besaran dalam produktivitas, keandalan, atau kesederhanaan perangkat lunak dalam satu dekade. Ia membingkai kompleksitas perangkat lunak dalam dua kategori—esensial dan aksidental—yang sangat relevan untuk rekayasa perangkat lunak berbasis agen. Kompleksitas esensial melekat pada masalah yang Anda selesaikan dan tidak dapat dihilangkan tanpa mengorbankan kebutuhan. Kompleksitas aksidental muncul dari alat, bahasa, proses, dan lapisan dokumentasi yang kita gunakan untuk mengimplementasikan dan mengomunikasikan sistem.

Agen pengode dapat dikatakan sebagai alat paling kuat yang pernah kita miliki untuk menyerang kompleksitas aksidental dalam rekayasa perangkat lunak berbasis agen. Saya hampir tidak lagi menulis kode secara manual, namun kini saya menghasilkan volume kode besar dalam bahasa seperti Go yang belum pernah saya tulis secara manual sebelumnya. Ada perdebatan aktif tentang apakah IDE tradisional akan tetap relevan dalam beberapa tahun, atau apakah kita hanya akan membutuhkan alat ringan untuk meninjau diff dan perubahan tingkat tinggi. Peningkatan produktivitasnya sangat besar dan dapat diukur dalam orde besaran. Saya mengatakan ini sebagai seseorang yang mengonsumsi hingga miliaran token per bulan di Claude, Codex, dan Gemini, berdasarkan catatan penggunaan internal.

Batas Agen: Ketika Kompleksitas Berbalik Arah

Namun argumen “No Silver Bullet” Brooks memprediksi masalah persis yang saya hadapi dengan rekayasa perangkat lunak berbasis agen. Kompleksitas aksidental bukan lagi hambatan utama, tetapi kompleksitas esensial tetap ada, dan sejak awal itulah bagian tersulit dalam rekayasa perangkat lunak. Agen tidak dapat secara andal membedakan keduanya dalam konteks sistem besar. Model bahasa besar adalah pencocok pola yang luar biasa, dilatih pada sejumlah besar kode sumber terbuka dan dokumentasi teknis. Branda unggul dalam tugas yang berakar pada kompleksitas aksidental, seperti refactor, penulisan tes, dan pembersihan kode berantakan. Namun branda kesulitan dengan keputusan desain esensial yang halus dan tidak memiliki preseden jelas dalam data pelatihan branda. Branda juga cenderung memperkenalkan kompleksitas yang tidak perlu, menghasilkan boilerplate defensif dan struktur rumit yang jarang dibutuhkan dalam praktik.

Dengan kata lain, agen begitu efektif menghilangkan kompleksitas aksidental sehingga branda sering menciptakan kompleksitas aksidental baru yang tidak diinginkan. Kompleksitas baru ini justru menutupi struktur esensial yang ingin Anda bangun dan pertahankan. Dalam proyek saya sendiri, seperti roborev dan msgvault, saya sudah menghadapi masalah ini ketika basis kode mendekati seratus ribu baris. Saya dapat melihat agen mulai “mengejar ekornya sendiri”, terjebak dalam kompleksitas yang branda hasilkan secara iteratif. Di suatu titik setelah itu, mungkin pada dua ratus ribu baris atau lebih, segala sesuatu mulai runtuh. Setiap perubahan baru harus menebas hutan lebat kode warisan yang dihasilkan agen. Saya menyebutnya sebagai “batas brownfield”, yaitu titik di mana basis kode agen menjadi sulit dikelola.

Skala Industri dan Batas Brownfield

Di Posit, kami melihat agen kesulitan lebih besar lagi dengan basis kode berjuta-juta baris seperti Positron, fork VS Code kami yang kompleks. Hal ini tampaknya memvalidasi argumen Brooks tentang bagaimana kompleksitas meningkat seiring skala dan bagaimana koordinasi menjadi faktor dominan. Pengamatan ini konsisten dengan literatur rekayasa perangkat lunak yang menunjukkan bahwa ukuran basis kode berkorelasi dengan peningkatan biaya pemeliharaan.

Saya tidak cukup percaya diri untuk memprediksi apakah situasi kita saat ini merupakan plafon atau hanya dataran sementara dalam rekayasa perangkat lunak berbasis agen. Model berkembang pesat, dan masalah yang saya gambarkan mungkin tampak sepele dalam beberapa tahun jika kapasitas konteks dan memori meningkat. Namun pembedaan Brooks antara kompleksitas esensial dan aksidental menunjukkan bahwa ini bukan sekadar persoalan keterbatasan model saat ini. Memutuskan apa yang harus dibangun selalu menjadi bagian tersulit, jauh sebelum LLM ada, dan agen pengode yang sempurna sekalipun tidak akan mengubah hal itu. Ketika generasi kode praktisnya gratis, kemampuan untuk mengatakan “tidak” menjadi garis pertahanan terakhir Anda.

Biaya Nyata Kode yang “Gratis”

Seiring biaya menghasilkan kode mendekati nol, hampir tidak ada yang menghentikan agen dan operator manusianya untuk mengeksplorasi setiap fitur atau ide yang sebelumnya terlalu mahal atau memakan waktu. Godaan untuk terus mem-prompt, “dan sekarang bisakah kamu hanya…?”, sangat besar dan sulit dikendalikan. Namun meskipun fitur dan subsistem baru murah untuk dibuat, branda tidak murah untuk dipelihara, diuji, di-debug, atau dipahami seiring waktu. Setiap tambahan yang tampaknya “gratis” menimbulkan beban kognitif dan kontekstual di masa depan bagi manusia dan agen. Setiap lonceng dan peluit ekstra menjadi sumber potensial kerapuhan dan bug yang dapat merugikan pengguna.

Dilihat dari sudut ini, membangun perangkat lunak hebat tidak pernah benar-benar tentang seberapa cepat Anda mengetik atau menghasilkan kode. Dengan agen, kita dapat “mengetik” sepuluh kali atau bahkan seratus kali lebih cepat daripada sebelumnya. Namun kita tetap perlu membuat keputusan desain yang sehat, menolak sebagian besar ide produk, menjaga integritas konseptual, dan mengenali kapan sesuatu sudah selesai. Agen mempercepat bagian yang mudah sambil berpotensi membuat bagian yang sulit—seperti desain, prioritas, dan pengendalian diri—menjadi lebih menantang dan abstrak.

Dampak pada Ekosistem Open Source

Perluasan lingkup yang didorong agen juga menimbulkan kekacauan di ekosistem open source, yang menjadi laboratorium alami rekayasa perangkat lunak berbasis agen. Hambatan masuk bagi kontributor tidak pernah serendah ini, dan banyak proyek kini dibanjiri pull request “membantu” sepanjang ribuan baris yang memperkenalkan fitur baru. Ketika pengembang menjadi lebih lepas tangan dan kurang terlibat dalam desain dan perencanaan, ekspansi lingkup agen yang tak terkendali dapat dengan cepat lepas kendali. Ketika orang yang mengirim PR sebenarnya tidak benar-benar menulis atau membaca penuh kode tersebut, mungkin tidak ada seorang pun yang merasa benar-benar bertanggung jawab atas keputusan desain yang tertanam di dalam kontribusi itu.

Dalam pekerjaan saya sendiri pada roborev dan msgvault, saya melihat agen mengusulkan solusi yang rumit dan terlalu direkayasa di mana pendekatan sederhana sudah cukup. Menggunakan penilaian, mengetahui kapan harus campur tangan, kapan menyederhanakan, dan bagaimana menjaga agen tetap terkendali, sangat krusial. Brooks berargumen bahwa bakat desain dan selera yang baik adalah sumber daya paling langka dalam pengembangan perangkat lunak. Kini, ketika agen dapat menangani sebagian besar pekerjaan pengodean, saya berpendapat kualitas-kualitas ini menjadi lebih penting daripada sebelumnya. Hambatan utamanya tidak pernah pada jari yang mengetik di papan ketik. Dalam “Mythical Agent-Month” yang baru ini, kendala nyata dalam menyampaikan perangkat lunak berkualitas tinggi adalah desain, pembatasan lingkup produk, dan selera.

Profil Pengembang yang Akan Unggul

Pengembang yang akan unggul di era rekayasa perangkat lunak berbasis agen ini bukanlah branda yang menjalankan sesi paralel terbanyak atau membakar token paling banyak. Branda adalah yang mampu memegang model konseptual proyek di kepala branda, yang disiplin tentang apa yang harus dibangun dan apa yang harus diabaikan, dan yang menerapkan selera yang baik pada volume keluaran yang luar biasa besar. Kemampuan ini sulit diotomasi dan tetap menjadi domain manusia.

The Mythical Man-Month diterbitkan pada tahun 1975, lebih dari lima puluh tahun lalu, dan tetap relevan untuk rekayasa perangkat lunak berbasis agen. Sejak itu, kita telah menyaksikan kemajuan besar dalam perangkat keras, bahasa pemrograman, lingkungan pengembangan, infrastruktur cloud, dan kini model bahasa besar. Alatnya berubah drastis, tetapi kendala fundamental tetap sama, terutama terkait kompleksitas esensial dan koordinasi.

Masa Depan Peran Manusia dalam Rekayasa Agen

Mungkin saya sebagian sedang mencoba membenarkan relevansi diri saya sendiri, tetapi kenyataannya lebih bernuansa dan berbasis konteks. Tidak semua perangkat lunak sama, dan tidak semua proyek akan terdampak dengan cara identik oleh rekayasa perangkat lunak berbasis agen. Aplikasi bisnis bergaya CRUD sangat berbeda dari basis data, compiler, atau perangkat lunak sistem kritis lainnya. Saya menduga sebagian besar firma konsultan perangkat lunak berada dalam masalah serius karena margin branda tergerus otomatisasi. Namun tesis saya menyasar pekerjaan di satu persen teratas tingkat kesulitan, masalah yang tidak dapat diakses oleh sebagian besar insinyur. Masalah-masalah ini akan terus membutuhkan pakar manusia di dalam loop, bahkan jika branda hampir tidak menulis kode secara langsung.

Contoh terbaru datang dari teman saya, Alex Lupsasca di OpenAI, dan para kolaboratornya, yang menggunakan AI untuk membantu merumuskan dan memecahkan masalah fisika yang sulit. Tanpa pakar domain yang memandu proses, mengajukan pertanyaan yang tepat, menafsirkan hasil, dan mengarahkan eksplorasi, tidak jelas apakah LLM saja dapat sekaligus merumuskan masalah dan menemukan solusinya. Studi-studi awal menunjukkan bahwa kombinasi pakar manusia dan model besar memberikan hasil terbaik.

Untuk saat ini, saya memperkirakan saya akan terus bangun pukul lima pagi untuk “memberi makan” dan menjinakkan agen-agen saya. Pengodean menjadi lebih mudah dan, terus terang, lebih menyenangkan, terutama dalam konteks rekayasa perangkat lunak berbasis agen. Saya dapat menghabiskan lebih banyak waktu memikirkan apa yang harus dibangun dan lebih sedikit waktu bergulat dengan alat dan infrastruktur di sekitar proses rekayasa. Pekerjaannya telah berubah, tetapi kebutuhan akan penilaian, selera, dan pengendalian diri manusia tetap sama dan mungkin justru meningkat.