AI adalah penguat, bukan arah.

Penulis artikel, sumber: InfoQ

AI membuat anda menulis kod 10 kali lebih pantas, lalu apa? Kod yang lebih banyak bermaksud masa kompilasi yang lebih panjang, pengujian yang lebih berat, pemeriksaan kod yang lebih tersumbat, dan sebuah perpustakaan kod yang tiada siapa fahami. Perisian adalah hutang; semakin pantas anda menulis, semakin banyak hutang yang anda miliki.

Peringatan daripada Adam Bender, Jurutera Perisian Utama Google, sangat terus terang: cara anda membina perisian hari ini tidak akan berfungsi sekiranya dipercepatkan sepuluh kali ganda. Tetapi pemenang sebenar di era AI bukanlah pasukan yang menghasilkan paling banyak, tetapi mereka yang mempunyai asas paling kukuh. Kerana AI hanya memperbesar, bukan menentukan arah.

Dalam ucapan utama di Google I/O 2026, Adam Bender mengemukakan satu soalan yang kebanyakan orang belum sempat fikirkan: apakah yang akan runtuh terlebih dahulu dalam ekosistem pembangun kita apabila AI mendorong kelajuan pengeluaran kod melampaui kapasiti proses kejuruteraan semasa? Beliau menghubungkan keseluruhan ucapan dengan satu konsep yang mungkin belum pernah anda dengar: ekologi perisian, iaitu disiplin yang mengkaji secara holistik ekosistem sosio-teknikal yang menghasilkan perisian. Dengan kata lain, anda tidak hanya perlu melihat teknologi, tetapi juga orang-orang, budaya, dan peraturan tidak tertulis dalam organisasi. Berdasarkan video ucapan tersebut, InfoQ telah menyusun semula kandungannya.

Pandangan utama adalah seperti berikut:

• AI tidak secara lalai menyelesaikan sebarang masalah untuk anda. Jika amalan anda baik, ia akan memperbesarkannya. Tetapi jika tidak cukup baik, ia hanya akan menciptakan lebih banyak masalah.
• Setiap orang adalah pembina adalah kerja yang hebat, sehingga anda perlu mengekalkan semua yang dibina oleh semua orang.
• Praktik kejuruteraan bukanlah suci dan tak boleh disentuh. Praktik boleh berubah, prinsiplah yang penting.
• Sebagai jurutera perisian di garis depan, pada titik kritikal ini, anda berada di pusat yang menentukan arah masa depan kejuruteraan perisian. Dari alat hingga aliran kerja, dari amalan kejuruteraan hingga budaya kejuruteraan, jika anda dapat memahami sistem yang sedang beroperasi, anda akan dapat menemukan tuas.

Apa itu "Sistem"?

Pekerjaan anda pada tahun 2026 sama sekali tidak seperti yang anda bayangkan pada tahun 2020. Jika anda cuba menjelaskan kepada saya tahun 2020 tentang apa yang berlaku hari ini, saya tidak akan percaya. Perubahan terlalu banyak, sehingga agak sukar untuk menyesuaikan diri. Saya tidak dapat meramal masa depan, tetapi saya percaya bahawa jika kita mengkaji ekosistem perisian semasa dengan teliti, beberapa jawapan lebih dekat daripada yang kita bayangkan.

Hari ini saya ingin bercakap dengan anda tentang satu perkataan: Ekologi Perisian (Software Ecology). Ia kedengaran seperti perkataan yang saya cipta secara sembarangan untuk naik ke atas pentas, tetapi bukan, ia adalah istilah yang serius. Sebelum memberikan definisi, saya ingin memberikan latar belakang, mari kita masuk sedikit lebih dalam ke dalam pemikiran sistem.

Satu sistem ialah sekumpulan elemen yang saling berkaitan, yang beroperasi mengikut sekumpulan peraturan untuk membentuk satu keseluruhan yang seragam. Mendengar seperti abstrak, tetapi anda tidak asing dengan sistem. Contohnya, penghawa dingin: termostat yang mengetahui suhu sasaran, sistem HVAC yang bertanggungjawab untuk memanaskan atau menyejukkan, satu ruangan, apabila suhu mencukupi, isyarat akan berhenti—inilah satu sistem.

Jika anda seorang jurutera perisian, anda berurusan dengan sistem setiap hari, anda merekabentuk sistem, membina sistem, dan mengendalikan sistem, dan dalam proses ini anda mungkin telah belajar satu perkara: semuanya saling berkaitan.

Seterusnya ialah ekosistem, iaitu satu sistem khas. Definisi agak panjang, tetapi penting: Ekosistem ialah rangkaian dinamik yang terdiri daripada pelaku yang saling bergantung, yang bersepadu dengan persekitaran mereka, dengan ciri-ciri tingkah laku muncul dan autonomi terpusat. Dalam perkataan mudah, ekosistem sangat kompleks, komponen-komponennya saling terhubung secara mendalam, dan setiap komponen mempunyai autonominya sendiri untuk membuat keputusan dan mengambil tindakan. Dan yang paling penting: persekitaran adalah sebahagian daripada sistem ini, dan anda tidak boleh memisahkan keduanya.

Ekosistem juga merupakan sistem adaptif kompleks yang mampu tumbuh, berubah, dan berevolusi seiring waktu. Mereka juga memiliki sifat yang disebut sifat muncul (Emergent Property), iaitu sesuatu yang tidak dapat dilihat dengan mengamati sebahagian tunggal mana pun, tetapi hanya muncul apabila keseluruhan sistem dipasang bersama. Justeru, perubahan berterusan, pembelajaran berterusan, dan sifat muncul ini menjadikan sukar untuk memahami apa yang sebenarnya berlaku dalam ekosistem.

Apabila berbicara tentang ekosistem, yang mungkin terbayang dalam pikiran Anda adalah gunung, sungai, suara burung, dan bau bunga. Tetapi lingkungan pengembang internal juga merupakan sebuah ekosistem: terdiri dari berbagai alat dan perkhidmatan, orang-orang dengan idea dan keperluan masing-masing, serta batasan perniagaan. Ia juga merupakan sistem khas: sistem sosio-teknikal, iaitu sistem yang dibentuk oleh manusia dan teknologi secara bersama-sama. Sistem sosio-teknikal sangat kompleks, kerana anda bermula dengan semua teknologi tersebut, kemudian memasukkan manusia ke dalamnya.

Anda kemungkinan besar telah terdedah kepada kebijaksanaan sistem sosio-teknikal tanpa sedar. Adakah anda tahu Hukum Conway: teknologi yang dibina oleh organisasi akan mencerminkan struktur komunikasi dalaman mereka. Dengan kata lain, jika anda mempunyai empat pasukan yang bekerja pada kompilator yang sama, anda akan mendapat kompilator empat langkah—itu sahaja. Pemerhatian utama Hukum Conway ialah cara kita membina teknologi tidak dapat dipisahkan daripada struktur organisasi yang membinaannya; organisasi membentuk apa yang akhirnya dibina.

Namun, bukan hanya struktur organisasi yang mempengaruhi ekosistem pembangun, nilai dan budaya juga memberi kesan mendalam. Ekosistem yang anda bangun adalah apa yang didorong oleh organisasi anda, dan budaya kejuruteraan anda menciptakan persekitaran di sekeliling ekosistem pembangun. Sekali anda memahami sistem sosio-teknikal, anda akan melihatnya di setiap sudut pembangunan perisian: arsitektur, budaya pasca-kejadian, semakan kod, strategi keselamatan—ia ada di mana-mana. Apa yang kita bangun, serta cara kita memilih untuk membina nya, mencerminkan apa yang kita hargai. Jika kita cukup teliti, kita boleh memanfaatkan kesedaran ini untuk memperkuat nilai-nilai kita, dan menyuntikkan nilai-nilai tersebut ke dalam apa yang kita bangun.

Sekarang saya boleh memberikan definisi yang betul: ekologi perisian ialah disiplin yang mengkaji secara menyeluruh ekosistem sosio-teknikal yang menghasilkan perisian. Jika yang tadi agak abstrak, tidak apa-apa, mari kita lihat kes sebenar sekarang.

Ekosistem pembangun Google

Saya membincangkan Google bukan kerana saya bekerja di sana sehingga perlu memujiannya, tetapi kerana ia adalah ekosistem pembangun yang paling saya fahami. Tujuan saya bukan untuk memberitahu anda supaya meniru Google, kerana itu tidak akan memberi manfaat kepada anda. Anda adalah syarikat yang berbeza, berada pada peringkat yang berbeza, dan menghadapi kompromi yang berbeza. Banyak pilihan yang diambil oleh Google adalah berdasarkan keperluan spesifik kami semasa membina ekosistem pada masa itu.

Beberapa tahun lalu, kami menulis sebuah buku yang dipanggil secara dalaman "Buku Flamingo". Separuh daripada buku itu membahas pengawalan versi dan ujian, tetapi seluruh bahagian awalnya membincangkan budaya kejuruteraan. Banyak orang bertanya mengapa kami menghabiskan begitu banyak ruang untuk membincangkan budaya, kerana jika anda tidak memahami budaya Google, anda tidak akan dapat memahami mengapa kami membuat pilihan teknikal tertentu—semua perkara ini saling berkaitan.

Google mempunyai beberapa ciri budaya yang unik. Kami adalah organisasi yang sangat berorientasikan kejuruteraan, di mana jurutera sentiasa hadir semasa membuat keputusan penting; kami sangat menghargai transparansi, dengan usaha sebanyak mungkin untuk membuat semua dokumen dan kod terbuka kepada semua orang; kami mendorong semangat membantu, sebenarnya, apabila berbual dengan sesiapa sahaja yang pernah meninggalkan Google, sikap saling membantu rakan sekerja akan menjadi perkara pertama yang mereka sebut; kami memandang semakan kod sebagai peluang untuk membimbing, bukan seperti memeriksa ujian; kami sangat menghargai standardisasi; kami percaya kepada peningkatan berterusan; kami menganjurkan semakan insiden tanpa penyalahan; kami percaya teguh bahawa kelestarian lebih utama daripada heroisme, dan automatik lebih baik daripada kerja manual. Tentu saja, kami tidak selalu mencapai semua ideal ini, tetapi ini adalah arah yang kami usahakan secara budaya.

Secara teknikal? Repositori kod monolitik, hampir semua kod berada dalam satu repositori; pembangunan berasaskan mainline, setiap perubahan disatukan terus ke mainline; semasa membina fail binari, hampir setiap baris kod dibina dari sumber; rantai alat pembinaan seragam yang digunakan oleh semua orang; platform automatik ujian global, semua ujian dijalankan di satu tempat, berbilion kes ujian setiap hari; isyarat "hijau terakhir" global, saya boleh memberitahu anda status sebarang pembinaan hanya dengan laman web dalaman yang mudah; persekitaran pengiraan seragam, jadi perkara seperti "ia berjalan di mesin saya" hampir tidak mungkin berlaku; kerangka pembangun yang sangat terstandardisasi dan sedikit bahasa pengaturcaraan inti.

Campuran budaya dan teknologi ini membentuk Google seperti yang kita kenali hari ini; anda tidak boleh memahami separuh sahaja dan mengabaikan separuh lagi.

Berbagi takdir

Jika saya harus memilih satu prinsip yang terus-menerus membimbing kami, saya akan memilih “Nasib Bersama (Shared Fate)”. Ia menggambarkan sejauh mana suatu ekosistem dan komponen-komponennya saling terkait rapat; dalam ekosistem dengan nasib bersama yang tinggi, satu komponen boleh mempengaruhi semua komponen lain. Dalam ekosistem pembangun, nasib bersama adalah pilihan teknikal serta pilihan sosial. Anda tidak mungkin mencapai nasib bersama hanya dengan memastikan semua orang menggunakan teknologi yang sama; anda juga perlu membina perjanjian sosial mengenai cara mengurus teknologi-teknologi tersebut.

Di Google, nasib bersama bermula daripada repositori kod monolitik. Setiap baris kod syarikat, kecuali beberapa pengecualian seperti Android dan Chrome, berada dalam repositori bersama. Semua kod diserahkan ke cabang utama, tanpa cabang terpisah, tanpa nombor versi, semuanya berada di satu tempat. Nasib bersama ini membolehkan kami memperbaiki satu kelemahan keselamatan dalam satu fail, dan kami tahu bahawa dalam tempoh seminggu, setiap aplikasi di syarikat akan diperbaiki. Memperbaiki sepuluh baris kod untuk memperbaiki sepuluh miliar baris perisian aplikasi dan sistem adalah seperti kuasa super.

Namun, berkongsi nasib tidak selalunya perkara baik—ia adalah pilihan. Ada tempat di mana berkongsi nasib tidak sesuai, seperti dalam persekitaran pengeluaran, di mana kita tidak pernah ingin satu perkhidmatan menarik semua perkhidmatan lain turun, atau satu kluster menginfeksi keseluruhan kawasan. Oleh itu, kami telah berusaha keras untuk mengelakkan berkongsi nasib yang berbahaya, iaitu berkongsi nasib yang menyebabkan kegagalan berantai. Berkongsi nasib adalah kompromi—anda perlu mencari tempat yang tepat untuk meletakkannya, kemudian memastikan ia berfungsi untuk anda.

Perubahan besar-besaran

Salah satu sifat muncul paling menarik dalam lingkungan kami yang saling terkait adalah perubahan berskala besar. Perhatikan ini: jauh sebelum AI muncul, alat dalaman Google sudah memungkinkan seorang pengembang mengubah jutaan baris kod, jutaan baris yang mereka tidak akan pernah baca, tidak akan pernah lihat semula, dan mungkin tidak tahu apa-apa tentangnya. Kami membina alat yang membuat semua ini menjadi mungkin secara automatik, dan hari ini ia tetap begitu, dan kami telah melakukan ini selama sekurang-kurangnya lima belas tahun terakhir.

Kemampuan ini membolehkan kami terus memperbaharui repositori kod monolitik, memperbaharui bahasa dan kerangka kerja, serta mencegah persekitaran dalaman menjadi kaku. Tanpa perubahan besar-besaran ini, kami tidak akan menjadi Google seperti sekarang. Rakan-rakan kami yang menghasilkan alat-alat ini melakukan pekerjaan pahlawan tanpa nama yang membolehkan syarikat bergerak pada kelajuan yang diperlukan.

Tetapi intinya ialah, anda tidak akan benar-benar memahaminya jika anda tidak memahami komponen budaya dan teknologi yang memungkinkan perubahan berskala besar. Apa yang anda perlukan? Budaya pengujian yang meluas, di mana setiap orang harus menulis ujian. Platform pengujian seragam, supaya anda tahu di mana mendapatkan hasilnya. Alat pembinaan bersama, supaya hasil pembinaan anda sama dengan hasil pembinaan saya. Pustaka yang distandardkan, supaya apabila menggantikan komponen, anda tidak perlu berpindah-pindah mencari versi yang berfungsi untuk anda tetapi tidak untuk saya. Semakan kod yang distandardkan, serta transparansi repositori kod itu sendiri, supaya anda tahu kod mana yang perlu diubah. Perubahan berskala besar merupakan puncak daripada konsep Google “automasi lebih baik daripada kerja manual”, dan ia hanya mungkin apabila seluruh ekosistem bekerjasama. Anda tidak boleh menunjuk kepada satu bahagian sahaja dalam persekitaran pembangun dan berkata, “Inilah sebabnya ia berlaku”—semua bahagian yang saling terhubunglah yang menjadi sebabnya.

Ekosistem anda, keseimbangan anda

Setiap ekosistem pembangun mempunyai sifat muncul seperti ini. Ia biasanya merupakan perkara yang membuat anda rasa tempat anda bekerja ada keunikan tersendiri, kerana ia adalah hasil daripada siri pilihan yang anda buat.

Ekosistem pengembang Google menghasilkan satu set kompromi unik yang melayani tujuan teknologi dan perniagaan kami. Tetapi seperti setiap ekosistem, ia tidak mungkin unggul dalam semua tugas. Kami memilih untuk mengoptimumkan skala ekstrem, keselamatan, dan prestasi, walaupun ini bermakna kadang-kadang mengorbankan produktiviti pengembang—kami bersedia membuat kompromi ini. Ekosistem sebuah syarikat mula-mula yang terdiri daripada lima orang akan kelihat berbeza, di mana kelajuan dan kecekapan adalah yang paling penting.

Eko sistem yang kebanyakan daripada anda berada di antara lima orang dan dua ratus ribu orang. Kompromi yang perlu anda buat sangat patut diperhatikan, kerana apabila anda mengkaji kompromi-kompromi ini, anda boleh mula memahami nilai-nilai organisasi: apa yang benar-benar diutamakan, bukan apa yang dikatakan di mulut, tetapi apa yang diungkapkan oleh pilihan yang sebenarnya anda perhatikan. Apabila anda memahami nilai-nilai ini, anda boleh mula membentuk perubahan yang sedang berlaku.

Masa 10 kali ganda: Setiap nod berada di bawah tekanan

Sudah tiba masanya untuk membincangkan gajah yang memakan token di ruangan ini: Apakah bentuk ekosistem pembangun yang berfokus pada AI itu?

Membina ekosistem baru dari sifar memang bagus, tetapi tiada siapa di antara anda yang mempunyai kemewahan itu. Anda mesti terus menghantar perisian sambil menggantikan hampir setiap bahagian di dalamnya. Syarikat mengharapkan anda terus mencipta nilai, sambil memastikan tiada masalah berlaku.

Jadi, tanyakan pada diri sendiri: seberapa banyak yang kamu ketahui tentang ekosistem pengembangmu hari ini? Bisakah kamu menggambarkannya secara lengkap? Apakah kamu tahu di mana semua komponennya berada, bukan hanya yang bersifat teknis, tetapi juga yang bersifat sosial? Bisakah kamu menyebutkan apa saja yang membentuk ekosistemmu? Seberapa banyak orang lain di organisasimu mengetahuinya? Apa kelebihan dan kelemahannya? Di mana bottleneck-nya? Di mana ia terbatas, dan di mana ia bebas? Berapa banyak pilihan yang kamu miliki? Apa saja sifat muncul yang pernah kamu lihat? Mungkin yang paling penting: jika ekosistemmu tiba-tiba harus menangani 10 hingga 15 kali lebih banyak kode dalam 18 bulan ke depan, apa yang menurutmu akan gagal terlebih dahulu?

Setiap ekosistem pembangun di bumi sedang mengalami perubahan mendasar, mungkin ia belum sampai ke setiap sudut tempat anda berada, tetapi ia sedang dalam perjalanan, dan setiap ekosistem pembangun akan terpaksa menghadapi masa 10 kali ganda ini. Ini adalah zaman yang luar biasa, tetapi juga agak membingungkan. Kompromi-kompromi yang sengaja kami kembangkan selama dua puluh lima tahun terakhir akan diberi semula keseimbangannya.

Menghasilkan kod 10 kali lebih pantas dan mempercepatkan pembangunan kejuruteraan 10 kali lebih pantas adalah dua perkara yang berbeza. Di Google, kami sering berkata, kejuruteraan adalah pengaturan kod seiring masa. Tetapi masalahnya, kami sedang mempercepatkan bahagian pengaturan kod secara besar-besaran, mempercepatkan mesin kod. Oleh itu, kami perlu mencari cara untuk melakukan kejuruteraan dengan baik di sekeliling mesin kod ini, supaya kami benar-benar dapat menghantar hasil kepada pelanggan. Tidak ada yang tahu sejauh mana peningkatan produktiviti ini boleh mendorong, tetapi ada satu perkara yang pasti: kami bermula dari sini dengan arah yang naik.

Masalahnya, cara kita membina dan menghantar perisian hari ini tidak akan berfungsi pada kelajuan 10 kali atau 100 kali ganda; sesuatu perlu berubah.

Mari kita mulakan dengan gambaran ekosistem pembangun yang disederhanakan. Dalam dunia di mana aktiviti meningkat sepuluh kali ganda, apa yang perlu berubah?

Kod dimasukkan ke dalam gudang

Tulis kod sumber. Jika setiap orang menulis kod dengan lebih pantas, jumlah kod akan meningkat banyak, dan ini bukan perkara yang baik. Jeff Atwood pernah berkata, perisian adalah satu tanggungjawab. Oleh itu, 10 kali kod, 10 kali tanggungjawab. Dan anda tidak boleh hanya memberi setiap orang sekumpulan token lalu berkata, “Semoga berjaya.” Saya harap anda berinvestasi selepas latihan: Di manakah dokumen amalan kejuruteraan anda? Bagaimana anda membangunkannya? Pertimbangkan selepas itu.

Membina sistem. Lebih banyak kod, sistem yang lebih besar bermaksud masa kompilasi yang lebih panjang. Saya pasti tiada siapa di syarikat anda sekarang yang mengeluh tentang kelajuan kompilasi yang perlahan. Tapi teka apa, ia akan menjadi lebih perlahan lagi. Dan jika agen mengendalikan jumlah kerja yang besar, bilangan kompilasi juga akan meningkat dengan ketara. Kompilasi bukanlah percuma, sama ada dari segi masa atau sumber pengkomputeran. Anda mungkin tidak pernah memperhatikan berapa banyak masa yang anda habiskan untuk kompilasi, tetapi pada skala 10 kali ganda, anda pasti akan menyedarinya.

Reka bentuk kod. Adakah anda mempunyai kemahiran agen yang sesuai untuk mendorong pemisahan? Adakah terdapat kerangka pelayan yang sesuai untuk memastikan penggabungan cepat dan selamat terhadap pelbagai kemampuan? Adakah anda tahu berapa banyak cara pelaksanaan aplikasi web yang ada di syarikat anda? Berapa banyak kerangka pelayan yang berbeza yang sedang berjalan? Bagaimanakah anda mengurus semula komponen kod yang ditulis oleh agen? Mungkin anda sedang bertaruh bahawa ini tidak penting. Tetapi jika agen menghasilkan kod yang mudah ditulis tetapi sukar dipelihara, jangan terkejut—ini adalah tahap asas semasa. Agen mahir menulis kod, tetapi tidak selalu berfikir dari perspektif jangka panjang. Kod-kod itu, saya pasti tidak akan mudah dirubah bentuk. Tidak apa-apa, bahagian ini akan kita selesaikan pada masa depan. Tetapi kenyataannya, agen sedang melakukan banyak kerja untuk kita, dan kita perlu mencari cara paling berkesan setiap hari untuk memanfaatkan kemampuan ini.

Pada suatu ketika, pekerjaan yang diagentkan ini boleh membuat fail binari anda menjadi terlalu besar untuk dikompilasi. Atau terlalu besar untuk dihantar ke telefon. Adakah anda pernah bertanya soalan ini: Berapakah saiz maksimum fail binari yang boleh anda kompilasi? Saya tidak tahu jawapannya, tetapi saya tahu bahawa di Google, kami sedang menyentuh had, dan ada beberapa tempat di mana fail binari sudah terlalu besar untuk dikompilasi, dan saya percaya kami akan menyelesaikannya. Tetapi kenyataannya, skala besar mempunyai banyak kesan berantai; kesan skala ada di mana-mana.

Mungkin anda menggunakan tatanan teknologi perkhidmatan mikro, dan anda berfikir: Semua perkhidmatan saya sangat kecil, mengapa saya perlu risau? Tetapi saya ada satu soalan: 10 kali laluan rangkaian, 10 kali bilangan perkhidmatan, 10 kali jumlah komunikasi, adakah anda bersedia? Tidak ada siapa pun yang dapat keluar tanpa kena kesan; kesan skala ada di mana-mana.

Ulasan kod. Andaikan anda tidak dapat mengompilasi semua kod ini dengan boleh dipercayai, bagaimanakah proses ulasan kod anda? Semua orang bimbang tentang ulasan kod, dan ada sebabnya. Kami sedang memberi tekanan besar kepada proses yang sangat manusiawi ini, dan dalam banyak kes ia berubah menjadi halangan, dan manusia tidak suka menjadi halangan. Apabila anda memberi tekanan kepada mereka, tingkah laku mereka menjadi aneh. Sepuluh kali jumlah kod, anda akan mendapat sepuluh kali saiz perubahan, atau sepuluh kali lebih banyak perubahan. Pemimpin teknikal anda mampukah mengekalkan kelajuan ulasan yang diperlukan? Kebanyakan pemimpin teknikal tidak mampu mengulas kod sehari dari lima pembangun 10 kali ganda.

Oleh itu, mereka akan mula menyusun semula proses, mengambil jalan pintas, dan memastikan tiada siapa yang terbantut, kerana tiada siapa yang ingin menjadi penghalang. Anda mungkin boleh menyelesaikan sebahagian masalah ini dengan AI, dengan melaksanakan AI untuk memperbaiki tinjauan kod. Tetapi ini hanya menyelesaikan sebahagian masalah, kerana jika ahli pasukan anda tidak lagi menulis kod, satu-satunya masa mereka berhadapan dengan kod ialah semasa tinjauan, dan jika perhatian semasa tinjauan tidak mencukupi, siapakah yang memperhatikan perkembangan kod pangkalan? Tiada siapa. Dengan cepat, pangkalan kod anda akan menjadi kekacauan yang tiada siapa faham.

Ekonomi token. Token mahal, sebahagian daripada anda sudah tahu. Dalam skala besar, token adalah kos nyata yang perlu dipertimbangkan. Apa yang akan berlaku jika setiap orang di syarikat mulai menggunakan token 10 kali atau 100 kali ganda? Jika anda tanpa sengaja menghabiskan anggaran sebulan dalam sehari? Jika anda perlu membuat keputusan prioriti tentang di mana token harus dibelanjakan, adakah anda tahu di mana harus memberi keutamaan? Adakah anda bahkan mempunyai visibiliti ke arah di mana token sedang mengalir?

Hanya dalam beberapa nod pertama sistem ringkas ini, kami telah menemui masalah. Dan sangat jelas, akan terdapat beberapa kesan sekunder yang mencabar.

Ujian dan kawalan versi

Adakah anda pernah memeriksa berapa banyak sumber komputasi yang digunakan oleh infrastruktur ujian anda? Di Google, saya tidak pernah puas dengan kelajuan ujian saya sendiri.

Setiap perubahan yang dimasukkan ke dalam pengawasan versi mesti diuji. Tetapi selain itu, agen juga suka menjalankan ujian kerana ujian memberitahu mereka sejauh mana mereka berprestasi baik. Oleh itu, agen menghasilkan beban kerja tambahan, menjadikan tugas saya lebih banyak. Jadi, dengan 10 kali jumlah penghantaran ditambah semua kerja yang dilakukan oleh agen, berapa banyak sumber pengiraan ujian yang kini digunakan?

Sebenarnya, situasinya mungkin lebih buruk. Kami memperhatikan di Google bahawa apabila kodbase bertumbuh, graf ketergantungan meningkat secara kuadratik, bukan linear. Jadi, jika kodbase menjadi 10 kali lebih besar, anda mungkin perlu menjalankan 100 hingga 1000 kali lebih banyak ujian, bukan hanya 10 kali. Ini akan menjadi cabaran yang sangat menarik, dan pada suatu ketika ia akan menjadi satu baris dalam anggaran anda. Jika anda tidak risau tentang kos sumber pengiraan ujian sekarang, itu justru membuat saya lebih risau, kerana ia bermakna anda mungkin tidak mempunyai cukup ujian, dan agen-agen tersebut sedang bergerak di dalam kodbase anda tanpa jaring keselamatan.

Setelah masalah kompilasi dan pengujian selesai, mari kita lihat sistem kawalan versi. Kebanyakan sistem kawalan versi yang popular tidak dioptimumkan untuk prestasi; mereka dioptimumkan untuk konsistensi dan pengurutan. Itu adalah tugas asal mereka—mengekalkan rekod yang lengkap, bukan bergerak dengan pantas. Berapa banyak kali sistem kawalan versi anda boleh menerima commit dalam satu minit? Saya janji, ia jauh lebih sedikit daripada yang anda bayangkan. Ia tidak boleh diskalakan kepada kelajuan 10 kali ganda yang anda perlukan. Bilakah terakhir kali anda memikirkan prestasi sistem kawalan versi? Jika anda bukan pembangun Git, kemungkinan besar anda tidak pernah memikirkannya. Sebenarnya, jika anda terpaksa membincangkan prestasi sistem kawalan versi, ia bermakna ada sesuatu yang sudah sangat tersasar. Kita berada di dasar pengalaman pembangun, tetapi inilah kesan perubahan sistematik: ia mencapai setiap sudut sistem anda dan berkata, “Hei, awak sedang perhatikan?” Kerana sesuatu yang tidak anda jangkakan telah datang.

Untuk mereka yang bercadang menggunakan banyak repositori kecil untuk menyelesaikan masalah pengawalan versi, tanyakan kepada sesiapa yang telah menjalankan ratusan atau ribuan repositori kecil—saya jamin, itu hanyalah satu set cabaran baru yang lengkap, dan AI tidak serta-merta menjadikan masalah-masalah ini lebih mudah.

Senarai Perkara Tidak Terduga

Sejauh ini, kami hanya memerhatikan nod-nod kapasiti yang relatif mudah dikenal pasti, iaitu mengalikan nombor dengan 10 dan bertanya sama ada ia akan baik atau buruk, serta banyak cabaran yang tidak dijangka.

Mengesahkan strategi. Pengesahan hari ini biasanya melibatkan banyak ujian unit dan beberapa ujian integrasi. Tetapi di dunia dengan 10 kali kod dan 10 kali perkhidmatan, ujian integrasi akan menjadi bahagian paling penting dalam strategi kualiti. Berapa ramai di antara anda yang puas dengan strategi ujian integrasi hari ini? Saya juga tidak puas. Ujian integrasi benar-benar sukar, dan saya masih belum mempunyai alat yang mampu melakukan ujian integrasi mengikut cara yang saya inginkan.

Masalah konjungsi nilai boolean. Hari ini anda ingin melancarkan perisian, dan anda memerlukan setiap ujian lulus, semua nilai boolean menjadi hijau, dan semuanya beres sebelum anda melancarkan—ini masuk akal. Apa yang berlaku apabila anda mempunyai satu juta ujian, dan kebolehpercayaan infrastruktur ujian asas itu sendiri untuk menjalankan satu juta ujian menjadi meragukan? Mungkin ia menjadi tidak mungkin untuk memastikan semua nilai boolean benar sebelum melancarkan perisian. Anda memerlukan strategi baharu, kemungkinan besar berdasarkan kaedah statistik, untuk menentukan ujian mana yang betul untuk dijalankan, kerana anda tidak mungkin menjalankan semua ujian.

Perubahan besar. Memang menarik untuk boleh merombak semula, menukar bahasa dan kerangka kerja di mana-mana sahaja. Tetapi, adakah anda mempunyai aliran kerja dan perjanjian sosial yang menyokong untuk menguruskan konflik penggabungan yang beribu-ribu, ratusan ribu, atau jutaan baris? Mungkin tidak. Jika setiap orang di syarikat ini boleh melakukan perubahan besar, kita memerlukan strategi aliran kerja yang baru.

Perang penyuntingan agen. Seorang agen membuat perubahan, lalu agen lain datang dan berkata, "Tidak, saya tidak suka, saya akan buat perubahan yang berbeza." Kelihatan lucu, sehingga anda sedar bahawa anda membayar caj token untuk kedua-dua belah pihak.

Ketukan pelepasan. Berapa kerap anda melepaskan kepada pelanggan hari ini? Setiap hari? Itu agak baik. Jika tidak, ada masalah: anda akan mendapat lebih daripada 10 kali ganda perisian, dan semua ini perlu diletakkan di suatu tempat. Jika anda tidak melepaskan setiap hari, setiap perubahan akan menjadi jauh lebih besar. Dan rakan-rakan SRE saya akan memberitahu anda bahawa perubahan yang sangat besar adalah sangat menakutkan. Jangan lakukan itu. Tetapi kod perlu dideploy supaya ia menghasilkan nilai, jadi anda mungkin akan cuba melepaskan lebih kerap, yang bagus, dan rakan-rakan DORA akan gembira. Tetapi pada suatu titik, faedahnya akan berkurang, dan melepaskan setiap saat mungkin tidak memberi banyak nilai. Kod masih akan bertumbuh, dan anda perlu memahami di mana ia harus diletakkan supaya tidak mencipta lebih banyak risiko.

API dalaman. Saya selalu memberitahu rakan-rakan sekerja saya bahawa semua API anda tiba-tiba menjadi awam. Agen tidak akan berbincang dengan anda; ia akan mencari API dan memanggilnya secara langsung. Apa sahaja yang boleh diaksesnya, itulah yang akan digunakan. Saya janji. Jika anda tidak pernah memperkukuhkan antaramuka dalaman dan set data dalaman seperti yang anda lakukan terhadap API awam, agen akan menemui perkara-perkara yang tidak anda inginkan ia temui.

Paradoks Jevons. Jevons berkata, semakin murah dan cekap suatu sumber, semakin banyak kita menggunakannya. Ledakan token adalah contoh nyata. Kita meletakkannya di mana-mana, yang mengubah cara kita bekerja dan cara kita memikirkan kerja. Kita sedang memberi harga kepada tenaga kerja produktif yang sebelumnya tidak kelihatan—apakah ini akan memberi kesan apa-apa terhadap tingkah laku kita? Saya belum tahu.

Rollback. Tahukah kamu mengapa rollback hari ini secara asasnya boleh dilakukan? Kerana kamu mengeluarkan perisian sedikit lebih perlahan daripada masa yang diperlukan untuk mengesan masalah dalam persekitaran pengeluaran. Jika kamu mampu mengeluarkan dengan sangat, sangat pantas—sehingga kamu tidak sempat mengesan sebarang masalah—apakah sikap rollback kamu? Setiap rollback akan terpaksa menghadapi pelbagai perubahan bertentangan yang tertimbun di atasnya. Oleh itu, hanya mempercepatkan pengeluaran tidak cukup; kamu mesti mempertimbangkan keseluruhan sistem, termasuk rollback sebagai saluran keselamatan yang penting. Ngomong-ngomong, kamu perlu berhati-hati di mana meletakkan token engine. Jika proses rollback kamu bergantung pada agent yang mempunyai kapasiti mencukupi, dan sebelum ini seseorang telah menghabiskan anggaran token agent tersebut, menyebabkan kamu kini tidak boleh rollback, itu mungkin bukan perkara yang baik.

Setiap orang adalah pembina. Anda mungkin pernah berfikir untuk menciptakan alternatif bagi alat yang tidak anda sukai di syarikat. Sekarang, kalikan itu dengan setiap orang dan setiap alat di syarikat. Apa yang berlaku pada tekstur sosial syarikat apabila setiap orang menggunakan alat yang sama sekali berbeza? Jika anda beruntung mempunyai asas data yang seragam, di mana semua data masuk ke satu tempat, ia masih boleh diterima. Tetapi jika tidak? Setiap orang adalah pembina memang hebat, sehingga anda perlu menyelenggara segala sesuatu yang dibina oleh semua orang.

Kelas pantas kepimpinan teknikal. Ia mengambil masa lama untuk menjadi seorang pemimpin teknikal kerana anda perlu mengumpulkan intuisi, keupayaan penilaian, dan kecekapan profesional untuk membantu anda membuat keputusan, kerana apabila anda memimpin sebuah pasukan, kesilapan anda akan memberi kesan yang jauh lebih besar berbanding apabila anda bertindak sendiri. Apa yang akan salah apabila seorang graduan baru memasuki persekitaran yang membolehkan mereka memanggil lima puluh agen, tetapi tidak mempunyai sebarang intuisi atau keupayaan penilaian? Bagaimana saya boleh mengajar sepuluh tahun pengalaman dalam enam bulan? Saya tidak tahu.

Perhatian manusia adalah sumber daya paling berharga yang kita miliki. Kini, kebisingan sangat banyak, begitu banyak agen dan banyak hal yang bersaing untuk menarik perhatian kita, kita harus mencari cara untuk mengelolanya. Dulu kita mendapat manfaat dari fakta bahwa kemampuan kita untuk menciptakan masalah tidak melebihi kemampuan kita untuk memberikan perhatian, tetapi kini keadaannya sudah tidak lagi seperti itu.

Ini kedengaran banyak, kerana dalam satu sistem, semuanya saling berkaitan. Semua cabaran yang saya sebutkan tadi, anda tidak mungkin menyelesaikan mana-mana satu hanya dengan melihat satu nod dalam sistem; anda perlu melihat keseluruhan sistem.

Untuk menyesuaikan diri dengan pembangunan berbasis agen, kita semua mesti belajar berfikir secara berterusan dengan pendekatan sistem. Apabila anda berfikir tentang sistem, ini adalah perkara yang perlu anda perhatikan: bagaimana sesuatu menjadi lebih besar, kesan yang berubah seiring masa, arah aliran sebab-akibat, node mana yang berkomunikasi dengan semua jirannya, bagaimana bentuk munculnya, dan apa itu perkara-perkara yang muncul tanpa jelas asal-usulnya. Apakah mekanisme insentif? Termasuk yang bersifat sosial dan teknikal, kapasiti, gelung maklum balas, dan bottleneck—ini adalah alat analisis sistem.

Kelihatan rumit, tetapi anda sebenarnya hanya perlu dua soalan: mengapa (Why?), dan bagaimana jika (What if?). Mengapa kami mempunyai sedikit ujian integrasi? Bagaimana jika kami mempunyai lebih banyak ujian integrasi daripada ujian unit? Mengapa kami menggunakan bahasa-bahasa tertentu ini? Bagaimana jika AI menulis semua kod?

“Mengapa” adalah bor yang anda gunakan untuk menembus inti sistem dan memahami bagaimana ia berfungsi. Semua anda sangat mahir dalam bertanya “mengapa”, tetapi “bagaimana jika” adalah bahagian yang lebih sukar. “Bagaimana jika” mungkin menakutkan, jika ia memerlukan anda untuk melepaskan amalan yang pernah anda anggap direka dengan sangat baik. Apa jadinya jika anda tidak menguji? Apa jadinya jika anda tidak menulis ujian sama sekali? Jangan melangkah terlalu jauh. Tetapi jika anda membenarkannya berlaku, “bagaimana jika” juga boleh sangat menarik.

AI adalah penguat, bukan arah

AI adalah penguat. Gagasan ini berasal dari rakan-rakan saya di DORA, yang mendapati dalam laporan pembangunan AI tahun lalu bahawa terdapat hubungan antara pasukan yang benar-benar memahami perkara tersebut: mereka berjaya mengetahui cara menjadikan AI sebagai penguat.

AI boleh memberi anda lebih banyak. Lebih banyak ujian, lebih banyak dokumen, lebih banyak kod, tetapi juga lebih banyak kekacauan. Pemekaran adalah tentang magnitud, bukan arah. AI tidak peduli ke mana semua itu pergi, ia hanya memberi anda lebih banyak. Apa yang sebenarnya ditemui oleh DORA ialah, pasukan yang mempunyai asas yang kukuh mampu mengarahkan kesan pemekaran ke arah yang berguna.

Ini membawa kita kepada soalan: Bagaimana perasaan anda terhadap asas anda sendiri? Bagaimana budaya pengambilan keputusan di syarikat anda? Apa yang boleh anda lakukan untuk memperbaikinya? Bagaimana pula strategi teknologi anda? Adakah seseorang memperhatikan produktiviti pembangun? Bagaimana kerjasama antara orang-orang dalam organisasi hari ini? Bagaimana postur keselamatan anda? Bagaimana kesihatan kod, kebersihan pelancaran, dan kebolehpercayaan anda? AI tidak akan menyelesaikan sebarang masalah untuk anda secara lalai. Jika amalan anda baik, ia akan memperbesarkannya. Tetapi jika tidak cukup baik, ia hanya akan mencipta lebih banyak masalah.

Namun, walaupun asasnya kukuh, kita akan segera memasuki satu perjalanan yang sebenar. Saya menduga, pada tahun 2030, ekosistem pembangun kita hari ini akan kelihatan sejauh tahun 2001 dari perspektif kita sekarang. Pada tahun 2001, kita masih menggunakan CD-ROM untuk mengeluarkan perisian, tetapi pada tahun 2030, kita mungkin akan berada sejauh itu.

Semasa anda meneruskan penguatan asas, izinkan saya memberi anda empat perkara untuk dipertimbangkan sepanjang perjalanan.

Pertama, kapasiti infrastruktur. Jika anda tidak tahu berapa banyak sumber daya yang boleh anda gunakan, anda tidak boleh melaksanakan AI atau sumber komputasi; anda memerlukan cara yang baik untuk memantau ini.

Kedua, verifikasi strategi. Anda tidak boleh dan tidak sepatutnya menerbitkan perisian yang belum diverifikasi. Tetapi strategi verifikasi berubah, sekarang saatnya untuk memikirkan dengan jelas. Ujian integrasi akan menjadi senjata paling penting anda, dan anda mungkin belum mempunyai alat yang sesuai.

Ketiga, pengasingan. Anda akan mendapat banyak kod yang digunakan untuk tujuan berbeza, beberapa di antaranya sebelum ini tidak pernah menggunakan kod. Ini tidak masalah, tetapi anda tidak ingin kod prototaip yang menarik benar-benar masuk ke persekitaran pengeluaran. Biarkan perkara yang menyeronokkan tidak mempengaruhi perkara yang menghasilkan wang.

Keempat, abstrak. Kita membina abstrak untuk mencegah pembangun membuat pilihan yang buruk, itulah sebabnya kita mempunyai pustaka dan kerangka kerja. Tidak ada yang menulis pelayan web dari awal. Membiarkan agen membuat banyak keputusan akan menyebabkan kesan yang sama, jadi anda memerlukan abstrak yang baik agar agen mengikutinya. Jangan berikan mereka pilihan yang buruk.

Anda juga mesti menerima satu perkara: amalan kejuruteraan bukanlah suci dan tidak boleh diubah. Amalan boleh berubah, tetapi prinsiplah yang penting. Mudah untuk dikatakan, tetapi sukar untuk dilakukan—jika anda tidak pernah benar-benar memikirkan mengapa pasukan anda menguji perisian dengan cara tertentu, atau mengapa proses pelancaran berfungsi seperti itu, anda tidak akan mampu membangunkannya. Memahami prinsip akan memberi anda kekuatan dan keyakinan untuk melalui masa 10 kali ganda ini.

Sekarang merupakan masa yang menarik untuk jurutera perisian. Setiap dimensi kerja kita sedang ditakrif semula; kita lebih memerlukan kreativiti daripada sebelum ini; kita memerlukan kemahiran untuk menghadapi masalah seperti pengurusan konteks, ekonomi token, dan pergeseran model; kita memerlukan kreativiti; kita tidak boleh terlalu tergoda untuk mengoptimumkan segala-galanya, dan perlu mendorong eksplorasi.

Satu soalan yang selalu membuat saya susah tidur, dan ia tidak dapat diselesaikan hanya dengan pengoptimuman: Bagaimana kita mempertahankan penguasaan intelektual terhadapnya seiring dengan pertumbuhan kod? Penguasaan intelektual merujuk kepada sama ada manusia mampu menarik kesimpulan terhadap apa yang dihadapi. Kita sudah kalah dalam peperangan ini selama sekurang-kurangnya lima belas tahun; sistem terbesar kita sudah jauh melampaui ukuran yang boleh difikirkan oleh seorang individu. Jika anda tidak percaya, lakukan satu eksperimen: minta setiap ahli pasukan anda melukis satu gambarajah arsitektur sistem, dan lihat berapa banyak versi berbeza yang anda dapat.

Banyak sistem perisian kami sangat rapuh; satu baris kod yang buruk atau tanda konfigurasi yang salah boleh merosakkan sistem yang mempunyai sejuta baris kod, kerapanya kerap membuatkan anda perlu berfikir tiga kali sebelum membuat perubahan. Tetapi saya mempunyai idea yang sangat menggembirakan mengenai AI: ruang arsitektur yang dikemas kini secara berterusan dan hampir boleh diinteraktifkan, di mana saya boleh bertanya kepada ia. Apa yang akan berlaku jika kami memindahkan kapasiti di sini ke pantai timur? Apa yang akan berlaku jika pertumbuhan pengguna meningkat tiba-tiba sebanyak 40%? Untuk sistem berskala sederhana sekalipun hari ini, melakukan perkara ini secara fungsional hampir mustahil, kerana terlalu banyak pemboleh ubah. Tetapi AI boleh memahami set data yang sangat besar, jadi saya rasa ada sesuatu yang boleh digali di sini.

Saya suka soalan ini kerana kami tidak hanya fokus sepenuhnya pada mempercepatkan mesin kod, kami bertanya: bagaimana cara memperdalam pemahaman kami terhadap sesuatu yang telah kami bina?

Perubahan berlaku dengan sangat pantas, lebih pantas daripada yang kebanyakan daripada anda alami. Salah satu perkara paling penting yang boleh anda lakukan sekarang ialah membantu mereka yang sedang berjuang, dan memberi bantuan kepada mereka yang belum memahami. Kita semua bergerak dengan kelajuan yang berbeza, dan menghadapi perubahan ini dengan cara yang berbeza. Mudah sahaja untuk merasa bahawa anda tertinggal.

Para jurutera berpengalaman, jadilah mentor. Cari orang-orang yang terhenti, bantu mereka. Jika anda sudah memahami alur pengembangan AI, kongsikan dengan orang lain—ini bukan rahsia yang berharga. Sebagai pemimpin teknikal, anda perlu terlibat secara aktif untuk membimbing arah perkembangan kejuruteraan perisian di syarikat anda. Jika anda peduli terhadap kualiti perisian atau reka bentuk perisian, anda harus menggunakan suara anda untuk mempertahankannya. Anda semua di sini adalah orang-orang yang perlu melakukan perkara-perkara ini—bos anda mungkin tidak akan melakukannya.

Jika kita membayangkan ekosistem pembangun sebagai ekosistem yang hidup, kita semua sudah terbiasa memperhatikan setiap daun di setiap ranting, merawat setiap pokok seperti memelihara bentuk kehidupan khas. Tetapi tidak lama lagi, yang perlu kita urus bukan lagi satu pokok, tetapi seluruh hutan. Dan anda tidak boleh mengurus hutan dengan hanya memperhatikan satu pokok—anda perlu melihat hutan sebagai satu ekosistem untuk dikelola.

Perubahan sistemik mempunyai ciri khas: ia berlaku serentak di segala tempat dan segala perkara, begitu besar sehingga membuatkan anda merasa tiada apa-apa yang boleh dipegang. Pada saat ini, anda mungkin merasa tiada apa-apa yang boleh membantu anda berdiri teguh di tengah gelombang perubahan yang datang seolah-olah setiap minggu. Tetapi seperti yang baru kita ketahui, dalam satu sistem, segala sesuatu saling berkaitan; tindakan kecil boleh menghasilkan kesan yang besar.

Walaupun kelihatan sebaliknya, transformasi AI bukanlah bidang eksklusif pemimpin syarikat. Sebagai jurutera perisian lini hadapan, pada titik kritikal ini, anda berada di pusat yang menentukan arah masa depan kejuruteraan perisian. Dari alat hingga aliran kerja, dari amalan kejuruteraan hingga budaya kejuruteraan, jika anda mampu memahami sistem yang sedang beroperasi, anda akan menemui tuas. Anda mempunyai lebih banyak kebebasan daripada yang anda sangka—gunakan kebebasan ini untuk mencipta masa depan bagi organisasi, pasukan, dan diri anda sendiri.