AI adalah penguat, bukan arah.

Penulis artikel, sumber: InfoQ

AI membuatmu menulis kode 10 kali lebih cepat, terus apa? Lebih banyak kode berarti waktu kompilasi lebih lama, pengujian lebih berat, tinjauan kode lebih macet, dan repositori kode yang tak ada yang mengerti. Perangkat lunak adalah utang; semakin cepat kamu menulis, semakin banyak utang yang kamu kumpulkan.

Peringatan dari Adam Bender, insinyur perangkat lunak utama Google, sangat jelas: cara Anda membangun perangkat lunak hari ini tidak akan berfungsi sama sekali dengan kecepatan 10 kali lipat. Tetapi pemenang sejati di era AI bukanlah tim yang menghasilkan paling banyak, melainkan tim yang memiliki dasar paling kuat. Karena AI hanya memperkuat, bukan menentukan arah.

Dalam sebuah keynote di Google I/O 2026, Adam Bender mengajukan pertanyaan yang belum sempat dipikirkan kebanyakan orang: ketika AI mendorong kecepatan produksi kode hingga melampaui kapasitas proses teknik saat ini, apa yang akan runtuh terlebih dahulu dalam ekosistem pengembang kita? Ia menyatukan seluruh pidatonya dengan konsep yang mungkin belum pernah Anda dengar: ekologi perangkat lunak, yaitu disiplin yang mempelajari ekosistem sosio-teknis produksi perangkat lunak secara holistik. Dengan kata lain, Anda tidak hanya melihat teknologinya, tetapi juga orang-orangnya, budayanya, dan aturan-aturan tak tertulis dalam organisasi. Berdasarkan video pidato tersebut, InfoQ telah menyusun ulang kontennya.

Poin utama sebagai berikut:

• AI tidak secara otomatis menyelesaikan masalah apa pun untukmu. Jika praktikmu baik, ia akan memperkuatnya. Tapi jika tidak cukup baik, ia hanya akan menciptakan lebih banyak masalah.
• Semua orang adalah pembangun itu keren, sampai kamu harus memelihara semua yang dibangun oleh semua orang.
• Praktik teknik bukanlah sesuatu yang sakral dan tak boleh disentuh. Praktik bisa berubah, yang penting adalah prinsipnya.
• Sebagai insinyur perangkat lunak di garis depan, di titik kritis ini, Anda berada di posisi inti yang menentukan kemana arah rekayasa perangkat lunak akan pergi. Dari alat hingga alur kerja, dari praktik rekayasa hingga budaya rekayasa, jika Anda dapat melihat sistem yang sedang berjalan, Anda akan menemukan tuasnya.

Apa itu "Sistem"?

Pekerjaanmu tahun 2026 sama sekali tidak seperti yang kamu bayangkan pada tahun 2020. Jika kamu mencoba menjelaskan kepada saya tahun 2020 tentang apa yang terjadi hari ini, saya tidak akan percaya. Perubahan terlalu banyak, hingga membuatnya sedikit sulit dihadapi. Saya tidak bisa memprediksi masa depan, tetapi saya percaya bahwa jika kita mempelajari ekosistem perangkat lunak saat ini dengan cermat, beberapa jawaban jauh lebih dekat daripada yang kita bayangkan.

Hari ini saya ingin membahas satu kata: ekologi perangkat lunak (Software Ecology). Terdengar seperti istilah yang saya buat-buat untuk naik panggung, tapi bukan, ini adalah istilah resmi. Sebelum memberikan definisi, saya ingin memberikan latar belakang terlebih dahulu, mari kita telusuri sedikit pemikiran sistem.

Sebuah sistem adalah sekumpulan elemen yang saling terkait, yang beroperasi menurut seperangkat aturan untuk membentuk kesatuan yang utuh. Terdengar abstrak, tetapi Anda tidak asing dengan sistem. Misalnya, AC: termostat yang mengetahui suhu target, HVAC yang bertanggung jawab untuk memanaskan atau mendinginkan, sebuah ruangan, dan ketika suhu sudah sesuai, sinyal berhenti—inilah sebuah sistem.

Jika Anda seorang insinyur perangkat lunak, Anda setiap hari berurusan dengan sistem, merancang sistem, membangun sistem, dan mengoperasikan sistem, dan dalam proses ini Anda kemungkinan besar belajar satu hal: semuanya saling terhubung.

Selanjutnya adalah ekosistem, sebuah sistem khusus. Definisinya agak panjang, tetapi penting: Ekosistem adalah jaringan dinamis yang terdiri dari pelaku yang saling bergantung, yang berevolusi bersama lingkungannya, ditandai dengan perilaku muncul dan otonomi terdesentralisasi. Dengan kata sederhana, ekosistem sangat kompleks, komponen-komponennya terhubung secara mendalam, dan setiap komponen memiliki otonomi sendiri untuk membuat keputusan dan mengambil tindakan. Dan yang paling penting: lingkungan adalah bagian dari sistem ini, dan Anda tidak dapat memisahkan keduanya.

Ekosistem juga merupakan sistem adaptif kompleks yang dapat tumbuh, berubah, dan berevolusi seiring waktu. Mereka juga memiliki sifat yang disebut emergent property, yaitu sesuatu yang tidak dapat dilihat dengan mengamati satu komponen tunggal saja, tetapi hanya muncul ketika seluruh sistem dirakit secara keseluruhan. Inilah yang membuat sangat sulit untuk memahami apa yang sebenarnya terjadi dalam ekosistem—perubahan berkelanjutan, pembelajaran berkelanjutan, ditambah dengan emergent property.

Mengenai ekosistem, yang mungkin langsung terbayang di pikiran Anda adalah pegunungan, sungai, suara burung, dan bau bunga. Namun, lingkungan pengembang internal juga merupakan sebuah ekosistem: terdiri dari berbagai alat dan layanan, orang-orang dengan ide dan kebutuhan masing-masing, serta batasan bisnis. Dan ini adalah sistem khusus: sistem sosio-teknis, yaitu sistem yang terbentuk dari manusia dan teknologi. Sistem sosio-teknis sangat kompleks, karena Anda memulai dari semua teknologi tersebut, lalu menambahkan manusia ke dalamnya.

Anda kemungkinan besar sudah pernah terpapar pada kecerdasan sistem sosial-teknis tanpa menyadarinya. Apakah Anda tahu Hukum Conway: teknologi yang dibangun oleh suatu organisasi akan mencerminkan struktur komunikasi internalnya. Dengan kata sederhana, jika Anda memiliki empat tim yang mengerjakan kompiler yang sama, Anda akan mendapatkan kompiler empat tahap—begitulah caranya. Observasi inti Hukum Conway adalah cara kita membangun teknologi tidak dapat dipisahkan dari struktur organisasi yang membangunnya, karena organisasi membentuk apa yang akhirnya dibangun.

Namun, bukan hanya struktur organisasi yang memengaruhi ekosistem pengembang, nilai dan budaya juga memiliki dampak mendalam. Ekosistem yang Anda bangun adalah apa yang diinspirasi oleh organisasi Anda, dan budaya teknik Anda menciptakan lingkungan di sekitar ekosistem pengembang. Setelah Anda memahami sistem sosio-teknis, Anda akan melihatnya di setiap sudut pengembangan perangkat lunak: arsitektur, budaya post-mortem insiden, tinjauan kode, strategi keamanan—di mana-mana. Hal-hal yang kami bangun, serta cara kami memilih untuk membangunnya, mencerminkan apa yang kami hargai. Jika kami cukup peduli, kami dapat memanfaatkan kesadaran ini untuk memperkuat nilai-nilai kami dan menyuntikkannya ke dalam apa yang kami bangun.

Sekarang saya bisa memberikan definisi yang benar: ekologi perangkat lunak adalah disiplin yang mempelajari ekosistem sosio-teknis produksi perangkat lunak secara menyeluruh. Jika yang tadi agak abstrak, tidak apa-apa, mari kita lihat contoh nyata sekarang.

Ekosistem pengembang Google

Saya membicarakan Google bukan karena saya bekerja di sana sehingga harus memuji-muji, tetapi karena itu adalah ekosistem pengembang yang paling saya pahami. Tujuan saya bukan untuk memberi tahu Anda agar meniru Google, karena itu tidak akan bermanfaat bagi Anda. Anda adalah perusahaan yang berbeda, berada di tahap yang berbeda, dan menghadapi kompromi yang berbeda. Banyak keputusan yang diambil Google didasarkan pada kebutuhan spesifik kami saat membangun ekosistem pada waktu itu.

Beberapa tahun lalu, kami menulis sebuah buku yang secara internal disebut "Buku Flamingo". Setengah dari buku itu membahas versi kontrol dan pengujian, tetapi seluruh bagian awal berfokus pada budaya teknik. Banyak orang bertanya mengapa kami menghabiskan begitu banyak halaman untuk membahas budaya, karena jika Anda tidak memahami budaya Google, Anda tidak akan bisa memahami mengapa kami membuat pilihan teknis tertentu—semua hal ini saling terkait.

Google memiliki beberapa ciri budaya yang unik. Kami sangat berorientasi pada teknik, dan insinyur selalu hadir saat membuat keputusan penting; kami sangat menghargai transparansi, sebisa mungkin membuat semua dokumen dan kode dapat diakses oleh semua orang; kami mendorong sikap saling membantu, bahkan jika Anda berbicara dengan siapa pun yang pernah meninggalkan Google, mereka akan menyebut kepedulian rekan kerja sebagai hal pertama yang mereka ingat; kami memandang tinjauan kode sebagai kesempatan untuk membimbing, bukan sebagai ujian; kami sangat menekankan standarisasi; kami percaya pada perbaikan berkelanjutan; kami menganut rekapitulasi insiden tanpa penyalahan; kami percaya bahwa keberlanjutan lebih unggul daripada heroisme, dan otomatisasi lebih baik daripada pekerjaan manual. Tentu saja, kami tidak selalu mencapai semua ideal ini, tetapi ini adalah arah yang kami perjuangkan secara budaya.

Secara teknis, repositori kode monolitik, hampir semua kode berada dalam satu repositori; pengembangan berbasis trunk, setiap perubahan langsung digabungkan ke cabang utama; saat membangun file biner, hampir setiap baris kode dibangun dari sumbernya; rantai alat pembangunan seragam yang digunakan semua orang; platform otomasi pengujian global, semua pengujian dijalankan di satu tempat, miliaran kasus pengujian setiap hari; sinyal "terakhir hijau" global, saya bisa memberi tahu Anda status setiap build hanya dengan situs internal sederhana; lingkungan komputasi seragam, sehingga masalah "di mesin saya berjalan" hampir tidak mungkin terjadi; kerangka pengembang yang sangat terstandarisasi dan sekelompok kecil bahasa pemrograman inti.

Perpaduan budaya dan teknologi ini membentuk Google seperti sekarang, dan Anda tidak bisa memahami separuhnya saja sambil mengabaikan separuh lainnya.

Berbagi takdir

Jika saya harus memilih satu prinsip yang terus-menerus menjadi panduan bagi kami, saya akan memilih “Takdir Bersama (Shared Fate)”. Prinsip ini menggambarkan sejauh mana sebuah ekosistem dan komponen-komponennya saling terkait erat; dalam ekosistem dengan takdir bersama yang tinggi, satu komponen dapat memengaruhi semua komponen lainnya. Dalam ekosistem pengembang, takdir bersama adalah pilihan teknis sekaligus pilihan sosial. Anda tidak bisa hanya mencapai takdir bersama dengan membuat semua orang menggunakan teknologi yang sama; Anda juga perlu membangun kontrak sosial tentang cara mengelola teknologi-teknologi tersebut.

Di Google, nasib bersama dimulai dengan repositori kode monolitik. Setiap baris kode perusahaan, kecuali beberapa pengecualian seperti Android dan Chrome, berada dalam satu repositori bersama. Semua kode disubmit ke cabang utama, tanpa cabang terpisah, tanpa nomor versi, semuanya berada di satu tempat. Nasib bersama ini memungkinkan kami menerapkan patch keamanan dalam satu file dan yakin bahwa dalam seminggu, setiap aplikasi di perusahaan akan diperbaiki. Memperbaiki sepuluh miliar baris perangkat lunak aplikasi dan sistem hanya dengan sepuluh baris kode, rasanya seperti kekuatan super.

Namun, berbagi takdir tidak selalu hal yang baik, itu adalah pilihan. Ada tempat-tempat di mana berbagi takdir tidak sesuai, misalnya di lingkungan produksi, kita sama sekali tidak ingin satu layanan menarik semua layanan lainnya ke bawah, atau satu klaster menginfeksi seluruh wilayah. Oleh karena itu, kami telah berusaha keras untuk menghindari berbagi takdir berbahaya yang dapat menyebabkan kegagalan kaskade. Berbagi takdir adalah kompromi; Anda harus menemukan lokasi yang tepat, lalu memastikan bahwa hal itu bekerja untuk Anda.

Perubahan besar-besaran

Salah satu sifat muncul paling menarik dalam lingkungan kami yang saling terhubung adalah perubahan skala besar. Perhatikan hal ini: jauh sebelum AI muncul, alat internal Google sudah memungkinkan seorang pengembang mengubah jutaan baris kode—jutaan baris yang tidak akan mereka baca, tidak akan pernah mereka lihat lagi, dan mungkin sama sekali tidak mereka ketahui. Kami membangun alat-alat yang membuat semua ini menjadi otomatis, dan hari ini masih demikian, serta kami telah melakukannya selama setidaknya lima belas tahun terakhir.

Kemampuan ini memungkinkan kami terus mengembangkan repositori kode monolitik, memperbarui bahasa dan kerangka kerja, serta mencegah lingkungan internal menjadi kaku. Tanpa perubahan besar, kami tidak akan menjadi Google seperti sekarang. Rekan-rekan yang membuat alat-alat ini melakukan pekerjaan pahlawan di balik layar, memungkinkan perusahaan bergerak secepat yang dibutuhkan.

Tetapi intinya adalah, Anda tidak akan benar-benar memahaminya jika tidak memahami komponen budaya dan teknis yang membuat perubahan skala besar menjadi mungkin. Apa yang Anda butuhkan? Budaya pengujian yang meluas, di mana setiap orang harus menulis tes. Platform pengujian yang seragam, sehingga Anda tahu di mana mendapatkan hasilnya. Alat build yang sama, sehingga hasil build Anda sama dengan hasil build saya. Perpustakaan yang terstandarisasi, sehingga saat mengganti komponen, Anda tidak perlu berpindah-pindah mencari versi yang berfungsi untuk Anda tetapi tidak untuk saya. Tinjauan kode yang terstandarisasi, serta transparansi repositori kode itu sendiri, agar Anda tahu kode mana yang perlu diubah. Perubahan skala besar adalah puncak dari filosofi Google “otomatisasi lebih unggul daripada pekerjaan manual”, dan hal ini hanya mungkin terjadi jika seluruh ekosistem bekerja sama. Anda tidak bisa menunjuk ke satu bagian saja di lingkungan pengembang dan mengatakan, “Inilah penyebabnya”—semua bagian terhubung satu sama lain itulah sebabnya.

Ekosistemmu, keseimbanganmu

Setiap ekosistem pengembang memiliki sifat muncul seperti ini. Biasanya, itulah hal-hal yang membuat Anda merasa tempat Anda bekerja memiliki keunikan tersendiri, karena itu adalah hasil dari serangkaian pilihan yang Anda buat.

Ekosistem pengembang Google menghasilkan serangkaian kompromi unik yang melayani tujuan teknis dan bisnis kami. Namun, seperti setiap ekosistem, tidak mungkin unggul dalam semua tugas. Kami memilih untuk mengoptimalkan skala ekstrem, keamanan, dan kinerja, bahkan jika itu berarti terkadang mengorbankan produktivitas pengembang—kami bersedia membuat kompromi ini. Ekosistem startup berlima akan terlihat sangat berbeda, di mana kecepatan dan agilitas adalah yang paling penting.

Ekosistem yang sebagian besar dari Anda tinggali berada di antara lima orang dan dua ratus ribu orang. Kompromi yang perlu Anda buat sangat patut diperhatikan, karena ketika Anda memeriksa kompromi-kompromi ini, Anda mulai memahami nilai-nilai organisasi: apa yang benar-benar dianggap penting, bukan apa yang dikatakan penting, tetapi apa yang diungkapkan oleh pilihan nyata yang Anda amati. Ketika Anda memahami nilai-nilai ini, Anda mulai membentuk perubahan yang sedang berkembang.

Waktu 10x: Setiap node sedang mengalami tekanan

Saatnya membahas gajah di ruangan yang memakan token: seperti apa bentuk ekosistem pengembang yang berbasis AI?

Membangun ekosistem baru dari nol memang bagus, tetapi tak seorang pun dari kalian memiliki kemewahan itu. Kalian harus terus mengirimkan perangkat lunak sambil mengganti hampir setiap bagiannya. Perusahaan mengandalkanmu untuk terus menciptakan nilai, sekaligus memastikan tidak ada masalah.

Lalu, tanyakan pada diri sendiri: seberapa besar pengetahuanmu tentang ekosistem pengembangmu hari ini? Bisakah kamu menggambarkannya secara lengkap? Apakah kamu tahu di mana semua komponennya berada, tidak hanya yang teknis, tetapi juga yang sosial? Bisakah kamu menyebutkan apa saja yang membentuk ekosistemmu? Seberapa besar pengetahuan orang-orang di organisasimu tentang hal ini? Apa kelebihan dan kelemahannya? Di mana titik bottleneck-nya? Di mana batasannya, dan di mana kebebasannya? Berapa banyak pilihan yang tersedia bagimu? Sifat muncul seperti apa yang pernah kamu amati? Mungkin yang paling krusial: jika ekosistemmu tiba-tiba harus menangani 10 hingga 15 kali volume kode dalam 18 bulan ke depan, apa yang menurutmu akan rusak terlebih dahulu?

Setiap ekosistem pengembang di bumi sedang mengalami transformasi mendasar, mungkin belum sampai ke setiap sudut di mana Anda berada, tetapi ia sedang menuju ke sana, dan setiap ekosistem pengembang akan harus menghadapi momen 10 kali lipat ini. Ini adalah masa yang luar biasa, tetapi juga cukup membingungkan. Kompromi-kompromi yang sengaja kami kembangkan selama dua setengah dekade terakhir akan kembali diseimbangkan.

Menghasilkan kode 10 kali lebih cepat dan mengembangkan teknik 10 kali lebih cepat adalah dua hal yang berbeda. Di Google, kami sering mengatakan bahwa teknik adalah pemrograman yang diintegrasikan seiring waktu. Namun masalahnya, kami sedang mempercepat secara signifikan tahap pemrograman, membuat mesin kode berjalan lebih cepat. Oleh karena itu, kami harus menemukan cara untuk melakukan teknik yang baik di sekitar mesin kode ini agar benar-benar dapat memberikan hasil kepada pelanggan. Tidak ada yang tahu sejauh mana peningkatan produktivitas ini akan mendorong kita, tetapi satu hal pasti: kita mulai dari sini dan bergerak ke atas.

Masalahnya, cara kita membangun dan mengirimkan perangkat lunak hari ini tidak akan berfungsi dengan kecepatan 10 kali atau 100 kali lipat; sesuatu harus berubah.

Mari kita mulai dengan melihat diagram ekosistem pengembang versi sederhana. Di dunia di mana aktivitas meningkat sepuluh kali lipat, apa yang harus berubah?

Kode dimasukkan ke dalam gudang

Tulis kode sumber. Jika setiap orang menulis kode jauh lebih cepat, jumlah kode akan jauh lebih banyak, dan itu bukan hal yang baik. Jeff Atwood pernah mengatakan bahwa perangkat lunak adalah beban. Jadi, 10 kali kode, 10 kali beban. Dan Anda tidak bisa langsung memberi setiap orang sejumlah token lalu berkata, “Semoga beruntung.” Saya harap Anda berinvestasi setelah pelatihan: Anda tahu di mana dokumen praktik teknik Anda? Tahu bagaimana mengembangkannya? Baru pertimbangkan setelah itu.

Membangun sistem. Lebih banyak kode, sistem yang lebih besar berarti waktu kompilasi yang lebih lama. Saya yakin tidak ada satu pun orang di perusahaan Anda yang pernah mengeluh tentang kompilasi yang lambat. Tapi tebak apa? Itu akan menjadi lebih lambat. Dan jika agen mendorong sejumlah besar pekerjaan, jumlah kompilasi juga akan melonjak. Kompilasi bukanlah hal yang gratis, baik dari segi waktu maupun sumber daya komputasi. Anda mungkin belum pernah memperhatikan berapa banyak waktu yang Anda habiskan untuk kompilasi, tetapi pada skala 10 kali lipat, Anda pasti akan menyadarinya.

Desain kode. Apakah Anda memiliki keterampilan berbasis agen yang tepat untuk mendorong decoupling? Apakah ada kerangka kerja sisi server yang tepat untuk memastikan kombinasi berbagai kemampuan secara cepat dan aman? Apakah Anda tahu berapa banyak cara penyebaran yang digunakan untuk aplikasi web di perusahaan Anda? Berapa banyak kerangka kerja sisi server yang berbeda yang sedang berjalan? Bagaimana Anda mengelola reuse komponen dari kode yang ditulis oleh agen? Mungkin Anda menganggap ini tidak penting. Tetapi jika agen menghasilkan kode yang mudah ditulis tetapi sulit dipelihara, jangan terlalu terkejut—ini adalah tingkat standar saat ini. Agen ahli dalam menulis kode, tetapi tidak selalu memikirkan jangka panjang. Kode-kode itu, saya yakin, tidak akan mudah direfactoring. Tidak masalah, bagian ini akan kita selesaikan nanti. Namun, fakta bahwa agen sedang melakukan sejumlah besar pekerjaan bagi kita, kita harus setiap hari mencari cara paling efisien untuk menerapkan kemampuan ini.

Pada titik tertentu, pekerjaan yang diagentkan ini bisa membuat file biner Anda menjadi terlalu besar untuk dikompilasi. Atau terlalu besar untuk di-push ke ponsel. Apakah Anda pernah bertanya: seberapa besar file biner terbesar yang bisa Anda kompilasi? Saya tidak tahu jawabannya, tetapi saya tahu di Google, kami sedang menyentuh batasnya—beberapa file biner sudah terlalu besar untuk dikompilasi, dan saya yakin kami akan menyelesaikannya. Namun kenyataannya, skala besar memiliki banyak dampak berantai; dampak skala ada di mana-mana.

Mungkin Anda menggunakan stack teknologi mikroservis, dan Anda berpikir: Semua layanan saya sangat kecil, mengapa saya harus khawatir? Tapi saya punya pertanyaan: 10 kali lalu lintas jaringan, 10 kali jumlah layanan, 10 kali volume komunikasi—apakah Anda siap? Tidak ada yang bisa lolos tanpa dampak; pengaruh skala ada di mana-mana.

Tinjauan kode. Bayangkan Anda tidak dapat mengompilasi semua kode ini secara andal, bagaimana proses tinjauan kode Anda akan berubah? Semua orang khawatir tentang tinjauan kode, dan ada alasannya. Kami memberikan tekanan besar pada proses yang sangat manusiawi ini, dan dalam banyak kasus, ia berubah menjadi hambatan, dan manusia tidak suka menjadi hambatan. Ketika Anda memberi tekanan, perilaku mereka menjadi aneh. Sepuluh kali jumlah kode, Anda akan mendapatkan perubahan sepuluh kali lebih besar, atau sepuluh kali lebih banyak perubahan. Apakah teknis lead Anda mampu mempertahankan kecepatan tinjauan yang diperlukan? Sebagian besar teknis lead bahkan tidak mampu meninjau kode sehari dari lima pengembang berkinerja 10 kali lipat.

Jadi, untuk menghindari menjadi hambatan, mereka akan mulai mengatur ulang proses, mengambil jalan pintas, dan memastikan tidak ada yang terhambat, karena tidak ada yang ingin menjadi penghambat. Anda mungkin bisa menyelesaikan sebagian masalah ini dengan AI, misalnya dengan menerapkan AI untuk meningkatkan tinjauan kode. Namun, ini hanya menyelesaikan sebagian masalah, karena jika anggota tim Anda tidak lagi menulis kode, satu-satunya saat mereka berinteraksi dengan kode adalah saat meninjau, dan jika perhatian saat tinjauan tidak memadai, siapa yang memperhatikan evolusi kode base? Tidak ada. Dengan cepat, kode base Anda akan berubah menjadi tumpukan kacau yang tidak ada yang bisa memahami.

Ekonomi token. Token mahal, sebagian dari kalian sudah tahu itu. Dalam skala besar, token adalah biaya nyata yang harus Anda pertimbangkan. Apa yang terjadi jika setiap orang di perusahaan mulai menggunakan token 10 kali atau 100 kali lipat? Jika Anda tidak sengaja menghabiskan seluruh anggaran bulanan dalam sehari? Jika Anda harus memutuskan prioritas penggunaan token, apakah Anda tahu di mana harus berinvestasi terlebih dahulu? Apakah Anda bahkan memiliki visibilitas ke mana token sedang mengalir?

Hanya dalam beberapa simpul pertama sistem sederhana ini, kita sudah menemukan masalah. Dan sangat jelas, akan ada beberapa efek sekunder yang menantang.

Pengujian dan kontrol versi

Apakah Anda pernah melihat berapa banyak sumber daya komputasi yang dikonsumsi oleh infrastruktur pengujian Anda? Di Google, saya tidak pernah puas dengan kecepatan pengujian saya sendiri.

Setiap perubahan yang dimasukkan ke dalam kontrol versi harus diuji. Tetapi selain itu, agen juga sangat suka menjalankan pengujian karena pengujian memberi tahu mereka seberapa baik mereka melakukan pekerjaannya. Oleh karena itu, agen menghasilkan beban kerja tambahan, sehingga pekerjaan saya menjadi lebih banyak. Jadi, dengan 10 kali jumlah komit ditambah semua pekerjaan yang dilakukan agen, berapa banyak sumber daya komputasi pengujian yang sekarang dikonsumsi?

Sebenarnya situasinya bisa lebih buruk. Kami melihat di Google bahwa seiring pertumbuhan kodebase, grafik ketergantungan tumbuh secara kuadratik, bukan linier. Jadi, jika kodebase menjadi 10 kali lebih besar, jumlah pengujian yang harus Anda jalankan mungkin bukan 10 kali lipat, melainkan 100 hingga 1000 kali lipat. Ini akan menjadi tantangan yang sangat menarik, dan pada suatu titik akan menjadi satu baris dalam anggaran Anda. Jika Anda sekarang tidak khawatir tentang biaya sumber daya komputasi untuk pengujian, justru itu yang lebih saya khawatirkan, karena itu berarti Anda mungkin sama sekali tidak memiliki cukup pengujian, dan agen-agen tersebut sedang YOLO di kodebase Anda tanpa jaring pengaman.

Misalkan kompilasi dan pengujian telah diselesaikan, sekarang mari kita lihat sistem kontrol versi. Sebagian besar sistem kontrol versi yang populer tidak dioptimalkan untuk kinerja, melainkan dioptimalkan untuk konsistensi dan pengurutan. Itulah tugas utama mereka: menjaga catatan lengkap, bukan berjalan secepat kilat. Berapa banyak commit yang bisa ditangani sistem kontrol versimu dalam satu menit? Saya jamin jumlahnya jauh lebih sedikit dari yang kamu bayangkan. Sistem ini tidak dapat diskalakan hingga kecepatan 10 kali lipat yang kamu butuhkan. Kapan terakhir kali kamu memikirkan kinerja sistem kontrol versi? Jika kamu bukan pengembang Git, kemungkinan besar kamu tidak pernah memikirkannya. Sejujurnya, sampai harus membahas kinerja sistem kontrol versi berarti ada sesuatu yang sudah sangat salah arah. Kita berada di dasar pengalaman pengembang, tetapi inilah konsekuensi dari perubahan sistemik: ia menemukan setiap sudut sistemmu dan berkata, "Hei, apakah kamu memperhatikan? Karena sesuatu yang tidak kamu duga datang."

Untuk teman-teman yang berencana menggunakan banyak repositori kecil untuk menyelesaikan masalah pengendalian versi, tanyakan pada siapa pun yang telah mengelola ratusan atau ribuan repositori kecil, saya jamin itu hanya akan membawa serangkaian tantangan baru yang lengkap, dan AI tidak secara pasti akan membuat masalah-masalah ini lebih mudah.

Daftar Kejadian Tak Terduga

Sejauh ini kita hanya melihat node-node kapasitas yang relatif mudah ditemukan, yaitu mengalikan angka dengan 10 dan bertanya apakah itu akan baik atau buruk, masih banyak tantangan tak terduga.

Verifikasi strategi. Verifikasi hari ini Anda sebagian besar terdiri dari banyak unit test dan beberapa integrasi test. Tetapi di dunia dengan 10 kali kode dan 10 kali layanan, integrasi test akan menjadi bagian paling penting dalam strategi kualitas. Berapa banyak dari Anda yang puas dengan solusi integrasi test hari ini? Saya juga tidak puas. Integrasi test benar-benar sulit, saya belum memiliki alat yang bisa melakukan integrasi test sesuai keinginan saya.

Masalah konjungsi boolean. Hari ini Anda akan merilis perangkat lunak, dan Anda meminta agar setiap pengujian lulus, semua nilai boolean berwarna hijau, dan semuanya berjalan lancar sebelum Anda merilis—ini masuk akal. Namun, apa yang terjadi ketika Anda memiliki satu juta pengujian, dan keandalan infrastruktur pengujian dasar itu sendiri diragukan dalam menjalankan satu juta pengujian? Mungkin menjadi tidak mungkin lagi untuk memastikan semua nilai boolean benar sebelum merilis perangkat lunak. Anda memerlukan strategi baru, kemungkinan besar berbasis statistik, untuk menentukan pengujian mana yang benar untuk dijalankan, karena Anda tidak mungkin menjalankan semua pengujian.

Perubahan sangat besar. Memang menarik untuk bisa merekonstruksi, mengganti bahasa, dan kerangka kerja di mana-mana. Tetapi, apakah Anda memiliki alur kerja dan kontrak sosial yang mendukung agar orang-orang dapat mengelola konflik merge yang mencapai puluhan ribu, ratusan ribu, bahkan jutaan baris? Kemungkinan besar tidak. Jika setiap orang di perusahaan bisa melakukan perubahan sangat besar, kita memerlukan strategi alur kerja baru.

Perang penyuntingan agen. Sebuah agen membuat perubahan, agen lain datang dan berkata, "Tidak, saya tidak suka, saya akan membuat perubahan berbeda." Terlihat lucu, sampai Anda menyadari bahwa Anda membayar biaya token untuk kedua belah pihak.

Ritme rilis. Berapa sering Anda merilis ke pelanggan hari ini? Setiap hari? Itu cukup bagus. Jika tidak, ada masalah: Anda akan mendapatkan lebih dari 10 kali lipat perangkat lunak, dan semua itu harus ditempatkan di suatu tempat. Jika Anda tidak merilis setiap hari, setiap perubahan akan menjadi jauh lebih besar. Dan teman-teman SRE saya akan memberi tahu Anda bahwa perubahan sangat besar sangat menakutkan. Jangan lakukan itu. Namun, kode harus dideploy agar bernilai, jadi Anda mungkin mencoba merilis lebih sering, yang bagus, dan teman-teman DORA akan senang. Namun, pada titik tertentu, manfaatnya akan berkurang; merilis setiap detik kemungkinan besar tidak akan memberi Anda banyak nilai. Kode tetap akan berkembang, dan Anda perlu memahami di mana meletakkannya agar tidak menimbulkan lebih banyak risiko.

API internal. Saya terus memberi tahu teman-teman saya bahwa semua API Anda tiba-tiba menjadi publik. Agent tidak akan berkonsultasi dengan Anda; ia akan menemukan API dan langsung memanggilnya. Apa pun yang bisa diaksesnya akan digunakannya, saya janji. Jika Anda belum pernah memperkuat antarmuka internal dan kumpulan data internal seperti halnya API publik, agent akan menemukan hal-hal yang tidak Anda inginkan ditemukan.

Paradoks Jevons. Jevons mengatakan, semakin murah dan efisien suatu sumber daya, semakin banyak kita menggunakannya. Ledakan Token adalah contoh nyatanya. Kita menempatkan mereka di mana-mana, yang mengubah cara kita bekerja dan cara kita memikirkan pekerjaan. Kita sedang memberi harga pada tenaga kerja produktif yang sebelumnya tak terlihat—apa dampaknya terhadap perilaku kita? Saya belum tahu.

Rollback. Apakah kamu tahu mengapa rollback hari ini secara dasar可行? Karena kamu merilis perangkat lunak sedikit lebih lambat daripada waktu yang dibutuhkan untuk mendeteksi masalah di lingkungan produksi. Jika kamu bisa merilis sangat, sangat cepat—secepat sehingga kamu belum sempat mendeteksi masalah apa pun—bagaimana posisi rollback-mu? Setiap rollback akan harus menghadapi banyak perubahan saling bertentangan yang menumpuk di atasnya. Jadi, hanya merilis lebih cepat tidak cukup; kamu harus mempertimbangkan seluruh sistem, termasuk rollback sebagai katup pengaman penting. Ngomong-ngomong, kamu harus berhati-hati di mana meletakkan token engine. Jika proses rollback-mu bergantung pada agent yang memiliki kapasitas cukup, dan sebelumnya seseorang telah menghabiskan anggaran token agent tersebut, sehingga sekarang kamu tidak bisa melakukan rollback, itu mungkin bukan hal yang baik.

Setiap orang adalah pembangun. Anda mungkin pernah memikirkan alternatif untuk alat yang tidak Anda sukai di perusahaan. Sekarang, kalikan itu dengan setiap orang dan setiap alat di perusahaan. Ketika setiap orang menggunakan alat yang sama sekali berbeda, apa yang terjadi pada jaringan sosial perusahaan? Jika Anda beruntung memiliki dasar data terpadu di mana semua data masuk ke satu tempat, itu masih bisa diterima. Tapi bagaimana jika tidak? Setiap orang adalah pembangun memang keren, sampai Anda harus memelihara semua yang dibangun oleh semua orang.

Kursus intensif kepemimpinan teknis. Butuh waktu lama untuk menjadi pemimpin teknis karena Anda harus mengakumulasi intuisi, kemampuan penilaian, dan keahlian profesional untuk membantu pengambilan keputusan, karena ketika Anda memimpin tim, kesalahan Anda memiliki dampak yang jauh lebih besar daripada ketika Anda bertindak sendiri. Apa yang bisa salah ketika seorang lulusan baru memasuki lingkungan yang dapat memanggil lima puluh agen, tetapi tidak memiliki intuisi atau kemampuan penilaian sama sekali? Bagaimana saya bisa mengajarkan pengalaman sepuluh tahun dalam enam bulan? Saya tidak tahu.

Perhatian manusia adalah sumber daya paling berharga yang kita miliki. Saat ini, kebisingan sangat banyak, begitu banyak agen dan hal-hal yang bersaing untuk menarik perhatian kita, sehingga kita harus mencari cara untuk mengelolanya. Dulu kita diuntungkan oleh fakta bahwa kemampuan kita untuk menciptakan masalah tidak akan melebihi kemampuan kita untuk memberikan perhatian, tetapi sekarang situasinya sudah tidak lagi seperti itu.

Ini terdengar banyak, karena dalam sebuah sistem, semuanya saling terkait. Semua tantangan yang baru saja saya sebutkan, Anda tidak mungkin menyelesaikan salah satunya hanya dengan melihat satu simpul dalam sistem, Anda harus melihat keseluruhan sistem.

Untuk menyesuaikan diri dengan pengembangan berbasis agen, kita semua harus mulai belajar berpikir secara sistematis secara berkelanjutan. Ketika Anda berpikir tentang sistem, ini adalah hal-hal yang harus Anda perhatikan: bagaimana sesuatu menjadi lebih besar, efek yang berubah seiring waktu, arah aliran sebab-akibat, node-node mana yang berkomunikasi dengan semua tetangganya, seperti apa yang muncul secara emergen, dan apa itu hal-hal yang muncul tanpa jelas asal-usulnya. Bagaimana dengan mekanisme insentif? Termasuk yang bersifat sosial dan teknis, kapasitas, loop umpan balik, dan bottleneck—ini adalah alat analisis sistem.

Tampak rumit, tetapi Anda sebenarnya hanya perlu dua pertanyaan: mengapa (Why?), dan bagaimana jika (What if?). Mengapa kita memiliki begitu sedikit integrasi tes? Bagaimana jika kita memiliki lebih banyak integrasi tes daripada unit tes? Mengapa kita menggunakan bahasa-bahasa tertentu ini? Bagaimana jika AI menulis semua kode?

“Mengapa” adalah bor yang Anda gunakan untuk menembus inti sistem dan memahami cara kerjanya. Anda semua sangat ahli dalam bertanya “mengapa”, tetapi “bagaimana jika” adalah bagian yang lebih sulit. “Bagaimana jika” bisa menakutkan, terutama jika itu meminta Anda untuk melepaskan praktik yang pernah Anda anggap dirancang dengan sangat baik. Bagaimana jika tidak menguji hal itu? Bagaimana jika sama sekali tidak menulis pengujian? Jangan terlalu jauh. Tetapi jika Anda membiarkannya terjadi, “bagaimana jika” juga bisa sangat menarik.

AI adalah penguat, bukan arah

AI adalah penguat. Gagasan ini berasal dari teman-teman saya di DORA, yang dalam laporan pengembangan AI tahun lalu menemukan adanya hubungan antara tim-tim yang benar-benar memahami hal-hal tersebut: mereka berhasil memahami cara menjadikan AI sebagai penguat.

AI bisa memberi kamu lebih banyak. Lebih banyak pengujian, lebih banyak dokumentasi, lebih banyak kode, tetapi juga lebih banyak kekacauan. Penguatan adalah tentang seberapa besar, bukan arahnya. AI tidak peduli ke mana hal-hal itu pergi, ia hanya memberi kamu lebih banyak. Yang sebenarnya ditemukan oleh DORA adalah tim-tim dengan dasar-dasar kuat yang mampu mengarahkan efek penguatan ke arah yang bermanfaat.

Ini menimbulkan pertanyaan: Bagaimana perasaanmu terhadap dasar-dasarmu sendiri? Bagaimana budaya pengambilan keputusan di perusahaanmu? Apa yang bisa kamu lakukan untuk memperbaikinya? Bagaimana dengan strategi teknis? Apakah ada yang memperhatikan produktivitas pengembang? Bagaimana kolaborasi di dalam organisasi hari ini? Bagaimana postur keamanannya? Bagaimana kesehatan kode, kebersihan rilis, dan keandalannya? AI tidak akan menyelesaikan masalah apa pun secara default. Jika praktikmu baik, ia akan memperkuatnya. Tapi jika tidak cukup baik, ia hanya akan menciptakan lebih banyak masalah.

Namun, meskipun dasar-dasarnya kuat, kita akan segera menjalani perjalanan yang nyata. Saya menduga, pada tahun 2030, ekosistem pengembang kita hari ini akan terasa sejauh tahun 2001 dari perspektif kita saat ini. Pada tahun 2001 kita masih merilis perangkat lunak melalui CD-ROM, dan pada tahun 2030 kita mungkin akan berjarak sejauh itu.

Saat kalian terus memperkuat dasar-dasar kalian, izinkan saya memberikan empat hal yang bisa kalian renungkan sepanjang perjalanan.

Pertama, kapasitas infrastruktur. Jika Anda tidak tahu berapa banyak sumber daya yang tersedia, Anda tidak dapat menerapkan AI atau sumber daya komputasi; Anda memerlukan cara yang baik untuk melacak ini.

Kedua, verifikasi strategi. Anda tidak bisa dan seharusnya tidak merilis perangkat lunak yang belum diverifikasi. Namun, strategi verifikasi berubah, sekarang saatnya untuk memikirkan ini dengan jelas. Pengujian integrasi akan menjadi senjata terpenting Anda, dan Anda mungkin belum memiliki alat yang tepat.

Ketiga, isolasi. Anda akan mendapatkan banyak kode yang digunakan untuk berbagai tujuan, beberapa di antaranya sebelumnya sama sekali tidak menggunakan kode. Ini tidak masalah, tetapi Anda tidak ingin kode prototipe yang menyenangkan benar-benar masuk ke lingkungan produksi. Biarkan hal-hal yang menyenangkan tidak memengaruhi hal-hal yang menghasilkan uang.

Keempat, abstraksi. Kami membangun abstraksi untuk mencegah pengembang membuat pilihan buruk, itulah mengapa kami memiliki pustaka dan kerangka kerja. Tidak ada yang menulis server web dari nol. Membiarkan agen membuat terlalu banyak keputusan akan menghasilkan konsekuensi yang sama, jadi Anda memerlukan abstraksi yang baik agar agen dapat mengikutinya. Jangan berikan mereka pilihan buruk.

Anda juga harus menerima satu hal: praktik teknik bukanlah sesuatu yang sakral. Praktik bisa berubah, yang penting adalah prinsipnya. Mudah diucapkan, sulit dilakukan, jika Anda belum pernah benar-benar memikirkan mengapa tim Anda menguji perangkat lunak dengan cara seperti itu, atau mengapa proses rilis berjalan seperti ini, Anda tidak akan bisa mengembangkannya. Memahami prinsip-prinsipnya akan memberi Anda kekuatan dan kepercayaan diri untuk melewati momen 10 kali lipat ini.

Saat ini merupakan masa yang menarik bagi insinyur perangkat lunak. Setiap dimensi pekerjaan kita sedang didefinisikan ulang; kita lebih membutuhkan kreativitas daripada sebelumnya; kita membutuhkan keterampilan untuk mengatasi masalah seperti manajemen konteks, ekonomi token, dan model drift; kita membutuhkan kreativitas; kita tidak boleh terlalu tergoda untuk mengoptimalkan segalanya, dan perlu mendorong eksplorasi.

Ada satu pertanyaan yang terus membuat saya tidak bisa tidur, dan tidak bisa diselesaikan hanya dengan optimasi: bagaimana kita mempertahankan penguasaan intelektual atas kodebase seiring pertumbuhannya? Penguasaan intelektual berarti apakah manusia mampu bernalar tentang apa yang ada di depan mereka. Kita sudah kalah dalam perang ini setidaknya selama lima belas tahun, sistem terbesar kita jauh melampaui kapasitas seorang manusia untuk dipahami. Jika Anda tidak percaya, coba lakukan eksperimen: minta setiap anggota tim Anda membuat diagram arsitektur sistem, lalu lihat berapa banyak versi berbeda yang akan Anda dapatkan.

Banyak sistem perangkat lunak kita sangat rapuh; satu baris kode yang buruk atau satu flag konfigurasi yang salah bisa merusak sistem berjuta-juta baris, kerapuhan ini membuat Anda harus berpikir panjang sebelum melakukan perubahan. Namun, saya memiliki ide yang sangat menarik tentang AI: ruang arsitektur yang diperbarui secara terus-menerus dan hampir interaktif, tempat saya bisa bertanya. Bagaimana jika kita memindahkan kapasitas ini ke pantai timur? Bagaimana jika pertumbuhan pengguna tiba-tiba meningkat 40%? Untuk sistem berukuran menengah sekalipun hari ini, melakukan hal ini secara fungsional hampir tidak mungkin, terlalu banyak variabelnya. Tetapi AI dapat memahami kumpulan data yang sangat besar, jadi saya percaya ada sesuatu yang bisa dieksplorasi di sini.

Saya menyukai pertanyaan ini karena kami tidak hanya fokus sepenuhnya pada mempercepat mesin kode, kami bertanya: bagaimana cara memperdalam pemahaman kami terhadap hal-hal yang telah kami bangun?

Perubahan terjadi sangat cepat, lebih cepat dari yang dialami sebagian besar dari kalian. Salah satu hal paling penting yang bisa kalian lakukan sekarang adalah membantu mereka yang sedang berjuang, dan memberikan bantuan kepada mereka yang belum memahami. Kita semua bergerak dengan kecepatan berbeda, dan menghadapi perubahan ini dengan cara yang berbeda. Merasa tertinggal adalah hal yang mudah terjadi.

Para insinyur berpengalaman, jadilah mentor. Temukan orang-orang yang terhambat dan bantu mereka. Jika Anda sudah memahami alur pengembangan AI, bagikan kepada orang lain—ini bukan rahasia berharga. Sebagai teknis lead, Anda harus terlibat langsung untuk membimbing arah pengembangan rekayasa perangkat lunak di perusahaan Anda. Jika Anda peduli terhadap kualitas perangkat lunak atau desain perangkat lunak, Anda harus bersuara untuk mempertahankannya. Orang-orang di ruangan inilah yang harus melakukan hal-hal ini—bos Anda mungkin tidak akan melakukannya.

Jika kita membayangkan ekosistem pengembang sebagai ekosistem hidup, kita semua sudah terbiasa memperhatikan setiap daun di setiap cabang, merawat setiap pohon seolah-olah itu adalah bentuk kehidupan khusus. Namun, tak lama lagi, yang perlu kita urus bukan lagi satu pohon, melainkan seluruh hutan. Dan Anda tidak bisa mengelola hutan dengan hanya memperhatikan satu pohon—Anda harus melihat hutan sebagai sebuah ekosistem untuk dikelola.

Perubahan sistematis memiliki sifat: ia terjadi secara serentak di segala tempat dan segala hal, begitu besar sehingga membuat Anda merasa tak bisa menangkap apa pun. Pada saat ini, Anda mungkin merasa tak ada yang bisa membuat Anda bertahan di gelombang perubahan yang tampaknya datang setiap minggu. Namun, seperti yang baru saja kita temukan, dalam suatu sistem, segala sesuatu saling terhubung; tindakan kecil dapat menghasilkan dampak besar.

Terlepas dari penampilan luarnya, transformasi AI bukanlah wilayah eksklusif para pemimpin perusahaan. Sebagai insinyur perangkat lunak lini depan, di titik kritis ini, Anda berada di inti yang menentukan masa depan rekayasa perangkat lunak. Dari alat hingga alur kerja, dari praktik teknik hingga budaya teknik, jika Anda dapat memahami sistem yang sedang berjalan, Anda akan menemukan tuasnya. Anda memiliki otonomi yang lebih besar daripada yang Anda kira—manfaatkan otonomi ini untuk menciptakan masa depan bagi organisasi Anda, tim Anda, dan diri Anda sendiri.