Peneraju DevOps Memperingatkan: Pengambilan Agen AI Memerlukan Perubahan Peringkat Sistem, Bukan Hanya Alat

Jangan memperbaiki kod yang dihasilkan oleh Agent, tetapi perbaiki sistem yang menghasilkan kod tersebut.

Penulis artikel, sumber: InfoQ

Jika seorang pembangun tidak dapat menggunakan Agent dengan berkesan, masalahnya mungkin bukan pada pembangun itu sendiri, tetapi pada syarikat yang belum menyediakan sistem yang berfungsi untuk Agent.

Banyak perusahaan yang mengklaim transformasi AI mereka masih berhenti pada pembelian alat-alat seperti Cursor dan Claude Code untuk pembangun, mengadakan beberapa latihan, lalu membiarkan semua orang mencuba sendiri. Jika akhirnya kesan Agen tidak baik, tanggungjawab akan dipikul semula oleh pengguna.

Namun, Patrick Debois, pencipta istilah DevOps, berpendapat: “Pengembang perlu melakukan perubahan pemikiran penting: apabila Agen tidak menyelesaikan tugas seperti yang anda harapkan, jangan lagi mengubah kod yang dihasilkannya, tetapi tingkatkan keseluruhan sistem, bukan hanya Prompt.”

Menurut Debois, ini adalah perubahan yang perlu dilalui dalam kejuruteraan perisian apabila beralih dari sistem deterministik kepada sistem dan alur kerja yang tidak tentu dan berkebarangkalian. Ia tidak hanya melibatkan teknologi, tetapi juga akan membentuk semula cara kerja pembangun, pasukan, dan seluruh organisasi. Namun, perubahan ini tidak mungkin dicapai hanya oleh seorang jurutera sahaja, atau hanya pada tahap pasukan tunggal. Ia, seperti DevOps, hanya dapat dicapai secara sebenar apabila dilaksanakan secara berskala.

Inti masalah bukan hanya sama ada pembangun akan menggunakan Agent, tetapi sama ada syarikat mampu menyusun semula pasukan, platform, dan cara kerjasama berdasarkan Agent.

Poin utama adalah seperti berikut:

• Jangan memperbaiki kod yang dihasilkan oleh Agent, tetapi perbaiki sistem yang menghasilkan kod tersebut.
• Jika masih ada orang dalam pasukan anda yang menggunakan pendekatan liar seperti "YOLO (jalankan dulu)" untuk vibe coding, anda harus menghentikannya segera. Amalan kejuruteraan tidak hanya penting untuk pemeliharaan sistem anda, tetapi juga penting untuk pembaikan berterusan Agent itu sendiri.
• Pabrik gelap mungkin bukan sepenuhnya gelap, tetapi mempertahankan sedikit cahaya redup (dim factory), yang bermakna anda perlu menentukan sejauh mana risiko yang ingin diambil untuk setiap fungsi, kerana tidak semua fungsi sesuai untuk otonomi penuh.
• Orang yang anda cari ialah mereka yang mampu menggunakan AI secara maksimum, mempunyai asas kejuruteraan yang kukuh, dan bersedia untuk berkongsi serta bekerjasama.
• Kereta pertahanan anda ialah dengan menangkap ilmu yang telah terkumpul, ilmu yang sekarang anda masukkan ke dalam skill, Context, dan bahkan batasan Harness.

Pada tahun 2009, ramai orang memberitahu saya bahawa idea penghantaran berterusan adalah gila.

Catatan penerjemah: Pada tahun 2009, industri secara umum mengadopsi model pelancaran versi besar secara berkala setiap beberapa bulan, di mana orang secara default menganggap semakin kerap pelancaran, semakin tinggi risikonya. Selain itu, terdapat penghalang ketat antara pembangunan dan operasi, infrastruktur automatik seperti kontena dan awan belum matang, serta tiada alat pipeline yang standard. Sementara itu, mekanisme ujian tradisional dan persetujuan perubahan berusaha menghapus sebanyak mungkin kecacatan sebelum pelancaran, manakala penghantaran berterusan memperkenalkan idea pelancaran frekuensi tinggi, bertahap, dan boleh dilancarkan kapan sahaja, yang menggugat persepsi umum mengenai risiko dan pengawalan proses pelancaran perisian, sehingga bagi kebanyakan syarikat, ia kelihatan seperti dongeng atau sangat gila.

Dan sekarang, Dark Factory menghadapi rintangan yang sama sekali sama.

Catatan penerjemah: Pabrik Gelap merujuk kepada model penghasilan perisian autonom yang didorong oleh AI, di mana manusia hanya memasukkan SPEC, dan AI secara bebas menyelesaikan pengkodean, pengujian, dan pelancaran tanpa perlu pemeriksaan baris demi baris oleh manusia, berbeza dengan pabrik perisian tradisional yang masih memerlukan penyertaan besar-besaran jurutera dalam proses.

Saya terus-mendengar perkataan yang sama di pelbagai situasi: “Benda ini tidak berfungsi di sini.” Tetapi maklumat sebenar yang ingin disampaikan bukanlah teknologi tidak berfungsi, tetapi “kami belum bersedia.” Mereka bukan tidak mahu melaksanakan benda ini, tetapi struktur organisasi semasa belum mampu menyokong model ini.

Sekarang ramai orang membincangkan bagaimana mengoptimumkan Agent dengan kitaran, bagaimana membina Harness—semuanya sangat hebat. Tetapi yang ingin saya katakan ialah, pada akhirnya kita semua akan mencapai tahap teknologi tersebut, dan suatu hari nanti ia akan menjadi barang komoditi biasa, bahkan mungkin telah dikemas menjadi perkhidmatan oleh sebuah makmal terkemuka. Pada hari itu, tidak lagi ada halangan teknologi. Perbezaan sejati terletak pada bagaimana organisasi anda mengubah semula cara kerjasama di sekitar perkara ini.

Jadi saya mengandaikan kita semua sedang bergerak ke arah pabrik gelap. Apa yang saya perhatikan di Tessl dan syarikat lain ialah, apabila orang mula mengadopsi teknologi ini, dinamik kerjasama akan berubah sepenuhnya. Jika anda mengenali Hukum Conway, anda tahu bahawa terdapat hubungan saling membentuk antara cara organisasi dan alat — bagaimana anda mengatur orang akan menentukan jenis sistem yang dihasilkan. Tetapi hari ini saya tidak ingin membincangkan bagaimana membuat Agent anda menjadi lebih baik; saya ingin membincangkan bagaimana ini mengubah dinamik pasukan anda, platform anda, dan keseluruhan organisasi anda.

Saya teka kebanyakan daripada anda bekerja dalam pasukan, bukan bekerja sendirian; kerja sama pasukan adalah perkara yang sama sekali berbeza daripada menaip sendirian kepada Claude Code.

Sekarang, semua orang suka mengatakan: pengembang akhirnya akan menjadi seorang pengarah, seorang pengatur agen. Saya rasa pernyataan ini tidak salah, memang itulah jalan yang sedang kita tempuh. Kita semakin menyerupai pengurus agen, yang perlu mengurus hubungan dengan agen-agen tersebut.

Tetapi masalahnya, saya mendengar banyak pembangun mengatakan secara peribadi: Kami tidak masuk ke industri ini untuk melakukan perkara ini, kami tidak pernah menyangka akan menghabiskan banyak masa untuk mengoptimumkan Prompt, menulis SPEC yang lebih baik. Kami adalah jurutera, kami bekerja dengan teknologi, dan ini menciptakan ketegangan identiti, terus bertanya pada diri sendiri: Adakah ini peranan yang benar-benar saya inginkan?

Kemudian muncul konsep yang dipanggil "Kejuruteraan Konteks", yang memberi para pembangun sedikit penghiburan. Ia menyatakan bahawa ini bukan sekadar memanggil Prompt; anda juga perlu menguji, menilai, mengagih, dan mengoptimumkan Prompt, jadi memang ada sedikit unsur kejuruteraan di dalamnya. Tetapi sebenarnya, banyak pembangun masih merasa kosong apabila hanya berurusan dengan Prompt dan SPEC, dan merasa mereka berubah daripada jurutera menjadi "pengurus prompt".

Namun, saya memperhatikan satu perkembangan menarik dalam praktiknya. Ketika kami mulai memperkenalkan Harness, kitaran, dan bahkan mendorong keseluruhan organisasi menuju autonomi yang lebih tinggi, satu jalan teknikal baru terbuka. Tiba-tiba, pembangun perlu membina alat untuk Agent, dan ini segera membangkitkan semangat sekumpulan orang. Pembangun yang sebelumnya merasa “bukan kerja saya” tiba-tiba menjadi bersemangat. Mereka berkata, betul, kami boleh lakukan ini! Kami mempunyai pengetahuan ini! Kami boleh gunakan pemrograman untuk membuat sistem ini lebih baik. Jadi ini menarik—ketika kami terus berbicara tentang “abstraksi, abstraksi, dan lagi abstraksi”, rasa “keahlian” justru muncul semula di tempat lain, mencipta ruang baharu untuk kerja kejuruteraan yang lebih mendalam.

Sering kali orang bertanya kepada saya: Bagaimana cara mengatasi orang-orang yang ragu-ragu? Jawaban saya selalu sama: Orang-orang ini sebenarnya adalah harta anda. Kerana mereka memiliki banyak pengetahuan tersirat dan kecekapan penilaian yang perlu anda masukkan ke dalam Agent. Anda boleh berkata kepada mereka: "Silakan keluarkan semua pengetahuan dan sikap kritis anda," yang akan membuat Agent dan Harness menjadi lebih baik. Jika anda berhadapan dengan seseorang yang enggan dan sentiasa mengeluh, "Kod yang dihasilkan ini kualitinya sangat buruk," anda boleh menjadikan mereka sebagai bahan bakar, mengubah kemarahan dan keraguan ini menjadi tenaga untuk memperbaiki sistem.

Sekarang, saya ingin memberi cadangan kepada pembangun syarikat saya: lakukan perubahan sikap yang besar—jangan lagi memperbaiki kod yang dihasilkan oleh Agent, tetapi perbaiki sistem yang menghasilkan kod tersebut. Seperti yang pernah dikatakan beberapa tahun lalu: jangan buat benda itu, tetapi buat benda yang mampu membuat benda itu. Kita sekarang berada pada tingkat abstraksi ini, menciptakan “benda yang mampu membuat benda” melalui Context, Harness, dan perulangan. Banyak yang masih berada pada tahap “Human in the Loop”, pengisian automatik, dan penyesuaian Prompt perlu memikirkan cara untuk meningkatkan pemikiran mereka kepada perspektif sistem.

Yang sebenarnya kita perlu lakukan ialah meminimumkan bilangan intervensi manusia melalui amalan kejuruteraan yang baik. Pada awalnya, semua orang merasa “vibe coding” itu seronok—masukkan Prompt, dapatkan hasil, teruskan sahaja. Tetapi kini semakin jelas bahawa kita tidak hanya memberi arahan kepada Agent melalui Prompt; sebenarnya kita berkata: “Tolong tulis bersama ujian, tolong kemas kini dokumen, tolong ikuti piawaian kod.” Semua perkataan yang dulu kita ucapkan kepada jurutera yang baik, kini kita ucapkan secara tepat kepada Agent. Jika masih ada orang dalam pasukan anda yang menggunakan pendekatan “YOLO (jalankan dulu)” yang tidak teratur untuk vibe coding, anda harus segera menghentikannya. Amalan kejuruteraan tidak hanya penting untuk pemeliharaan sistem anda, tetapi juga penting untuk keberterusan peningkatan Agent itu sendiri.

Saya mulai melihat satu ritual baharu dalam beberapa pasukan yang lebih maju, yang masih menjalani mesyuarat perancangan dan semakan, tetapi kandungan perbincangan mereka berubah sepenuhnya. Dalam mesyuarat semakan, mereka tidak lagi berkata “Apa yang salah dengan kod?”, tetapi sebaliknya bertanya “Apa yang salah dengan sistem?”

Saya juga melihat perpecahan menarik dalam mesyuarat perancangan. Tugasan-tugasan yang didefinisikan dengan sangat jelas dan lingkup yang cukup tepat boleh terus diserahkan kepada Agen, kerana Harness menjadi semakin baik dan mampu mengolah tugasan yang jelas seperti ini. Manakala perkara-perkara yang batasannya kabur dan memerlukan perbincangan, masih disimpan untuk manusia. Oleh itu, muncul pembahagian semula alami dalam mesyuarat perancangan: kad-kad ini terus melalui saluran Agen, manakala kad-kad itu kita bincangkan bersama.

Pembangun biasanya mengalami satu kitar pembelajaran: pertama belajar Prompt, kemudian SPEC yang lebih baik, seterusnya Context, Harness, dan kitaran, seluruh industri ini juga sedang memanjat kitar ini. Tetapi apa yang boleh dilakukan oleh Ketua pasukan ialah menetapkan ritma dan batasan untuk proses ini, contohnya memberitahu mereka: “Jangan terus menyesuaikan Prompt lagi, jadikan Context boleh digunakan semula.” “Baik, langkah ini telah selesai, mari kita beralih ke langkah seterusnya.” Nilai Ketua pasukan terletak pada menetapkan ritma seperti ini; jika anda hanya meletakkan satu pernyataan “Cuba cari tahu sendiri”, ia tidak akan berkesan.

Ada juga kesan sampingan: sekali produktiviti pasukan anda meningkat tajam, pihak di bawahnya, seperti yang bertanggungjawab atas GTM (Go to Market), mungkin tidak mampu mengikuti, bahkan pengguna pun mungkin tidak mampu mengikuti. Oleh itu, anda perlu menggunakan automasi untuk membantu mereka; kerangka anda tidak boleh berhenti pada peringkat pengkodean sahaja, tetapi perlu diperluaskan hingga ke pihak mereka. Prinsip yang sama juga berlaku kepada input keperluan di hulu: jika keperluan datang terlalu perlahan, pasukan akan terhenti, dan peringkat-peringkat ini juga perlu dimasukkan ke dalam alur kerja baharu ini.

Sekarang ada begitu banyak indikator di pasaran, seperti pengeluaran Token dan sebagainya. Tetapi saya semakin percaya pada dua indikator sebenarnya yang dapat mengukur produktiviti. Pertama: hitung berapa banyak intervensi manual yang masih diperlukan agar Agent dapat menyelesaikan satu tugas dengan betul. Nombor ini seharusnya terus menurun. Semakin baik Harness anda, semakin baik Context anda, dan semakin jelas panduan anda, nombor ini akan semakin rendah. Indikator kedua ialah apabila anda beralih dari bekerja secara individu kepada sistem berkongsi, terdapat kesan ganda. Apabila anda memperbaiki sesuatu di satu tempat, semua orang mendapat manfaat. Ini bukan bermaksud seseorang menjadi sepuluh kali lebih cekap, tetapi satu peningkatan kepada sistem Agent boleh menghasilkan kesan ganda kepada semua orang.

Anda boleh memulakannya di dalam satu repositori atau pasukan kecil, berkongsi Context, dan bekerjasama untuk memperbaiki Harness. Tetapi apa yang benar-benar anda inginkan ialah memperluaskan kesan ini ke seluruh organisasi. Pada titik ini, kita terpaksa membincangkan pasukan platform.

Pasukan platform adalah organisasi berkongsi yang typikal, dan kini mereka mungkin sedang fokus pada infrastruktur, perkhidmatan awan, gerbang MCP, dan sebagainya, tanpa memberi perhatian besar kepada agen. Namun, banyak perkara baharu sedang muncul yang memerlukan mereka mengambil alih, seperti pusat pendaftaran kemahiran (tidak boleh membiarkan setiap orang mencipta kemahiran yang sama di sudut masing-masing), sistem penilaian Konteks (Adakah Konteks ini berguna? Bolehkah ia diukur?), serta pengawal dan pengurusan identiti khas untuk agen pengaturcaraan (Dengan identiti siapakah agen menghantar kod? Di manakah sempadan kebenaran?). Oleh itu, pasukan platform memerlukan seseorang untuk membantu mereka berkembang ke peranan pusat yang baharu ini.

Ini adalah perkara yang sukar; anda perlu mempunyai pemilik yang jelas untuk mendorongnya. Tetapi siapakah yang sepatutnya? Pasukan platform? Pasukan pengalaman pembangun? Yang pertama biasanya tidak menyentuh perkara-perkara peringkat pembangunan, manakala yang kedua tidak banyak menyentuh infrastruktur, jadi diperlukan suatu perpaduan, tetapi perpaduan ini tidak akan berlaku secara automatik. Anda perlu memastikan ada seorang penanggungjawab yang mendorong kerja terpusat ini, jika tidak, pasukan anda hanya akan bersusah payah di dalam kawasan masing-masing, dan tidak akan ada “Jalan Bersempadan”.

Mengapa setiap pasukan kita perlu mencipta cara tersendiri untuk mengintegrasikan sistem pengesahan? Ini adalah komponen berkongsi, sepatutnya dimasukkan ke dalam pusat pendaftaran. Mengapa kita semua perlu membina Harness masing-masing? Jika kita semua menggunakan linter yang sama dan alat pengimbas keselamatan yang sama, maka ini adalah komponen yang boleh digunakan semula. Saya percaya ini akan seperti pembinaan jalan infrastruktur awan dahulu, yang secara beransur-ansur akan terpusat ke dalam pusat platform.

Tetapi masalahnya, jika setiap orang boleh memasukkan apa sahaja ke dalam gudang pusat ini secara sembarangan, ia akan berkembang secara liar. Sebagai contoh, jika seseorang memuat naik satu skill, siapakah yang memeliharanya? Orang lain pula membuat cabang skill yang serupa, jadi mana satu yang harus saya pilih? Oleh itu, seseorang perlu secara jelas memiliki bidang tertentu, dan dia perlu memastikan bahawa perkara itu boleh diuji dan bersifat modular, supaya orang lain boleh mengembangkan bahagian pengimbasan keselamatan dalam Context atau Harness berdasarkan asas ini. Anda perlu melakukannya dengan cara terpusat, bukan dengan mengedarkan secara rawak di dalam organisasi.

Mencapai konsensus itu sukar. Ia tidak sekenal perdebatan antara tabs dan spaces, tetapi kadang-kadang rasanya hampir sama. Jika anda meminta dua pasukan pembangun untuk mencapai konsensus mengenai cara kerja mereka, ia memerlukan banyak komunikasi dan perantaraan. Oleh itu, akhirnya anda mungkin tidak hanya mempunyai satu jalan beraspal, tetapi tiga atau empat, yang mereka boleh pilih. Jika mereka benar-benar ingin membuat sistem sendiri, mereka boleh buat, tetapi itu menggunakan bajet mereka sendiri. Jalan yang diselenggarakan secara pusat adalah “jalan mudah” yang dirancang untuk menarik orang menggunakannya.

Jika orang-orang menggunakan kemampuan berkongsi ini secara buta, anda perlu memperlihatkan kosnya kepada mereka. Selagi anda membuat perbelanjaan itu kelihatan, mereka secara semula jadi akan ingin mengoptimumkannya. Ini adalah tanggungjawab pasukan platform untuk membuat perbelanjaan telus: berapa banyak yang telah dibelanjakan? Sejauh mana ia membantu? Jika saya boleh mengurangkan bilangan iterasi Agent, itulah pengoptimuman. Tetapi jika saya tidak dapat melihat indikator ini, hanya melihat hasil akhir, maka saya tidak akan mampu memulakan tindakan—visualisasi adalah prasyarat semua pengoptimuman.

Jadi, argumen utama saya adalah: kita perlu bergerak dari pengembang yang bekerja sendiri-sendiri, ke tahap tim dengan konteks dan komponen bersama, dan akhirnya ke dalam sistem “permainan multi-pemain” di seluruh organisasi. Efek penggandaan akan meledak di sana, kerana anda mempunyai roda pendorong di mana peningkatan boleh menyebar secara serentak ke pelbagai arah.

Di tingkat yang lebih tinggi lagi, bagaimana Jabatan VP Kejuruteraan memikirkan perkara ini? Saya hampir boleh meramal cerita yang akan berlaku dalam organisasi anda: hackathon atau sesi perkongsian makan tengah hari, perkongsian kes berjaya, mencipta saluran Slack bersama, dan melaksanakan program champions. Semua ini adalah rutin transformasi yang biasa. Dulu, transformasi Agile juga membuat perkara yang sama, DevOps pun begitu—tidak ada yang baru.

Di sisi lain, kita juga tahu bahawa strategi “mengeluarkan lesen, mengadakan latihan, membiarkan orang berkreasi secara bebas, membiarkan seribu bunga mekar” tidak pernah berjaya. Hasil seribu bunga biasanya adalah seribu rumput liar—banyak bunga mekar tetapi tiada satu pun yang berbuah. Oleh itu, saya mencadangkan agar pihak organisasi memberikan kuasa yang jelas kepada pemimpin pasukan dan pasukan platform untuk melaksanakan perkara ini. Ia tidak boleh dicapai hanya oleh individu super tertentu; seseorang mesti diberikan kuasa rasmi untuk mendorongnya.

Mencari bantuan juga merupakan perkara yang menyusahkan. Nama jawatan semasa sangat membingungkan—reka bentuk produk AI, forward deployed engineer, engineer agentic, engineer AI... kata-kata ini sebenarnya tidak mempunyai makna yang nyata. Anda tidak boleh menilai kedewasaan seseorang berdasarkan judul kerana seluruh industri ini masih belum matang. Namun, apabila anda memuatkan permintaan pekerjaan, kata-kata ini memang memberikan isyarat tertentu dan menarik orang yang berminat untuk melamar, tetapi ia tidak bermakna mereka pasti memiliki kemahiran yang berkaitan. Saya juga pernah mendengar kisah yang lebih aneh lagi, di mana calon menggunakan AI untuk memberikan jawapan secara langsung di telinga semasa temu bual—apabila pemeriksa bertanya satu soalan, cadangan AI akan muncul melalui AirPods.

Jadi, saya mendengar semakin banyak syarikat mengadopsi cara temu bual ini. Langkah pertama, berikan satu latihan dan biarkan mereka menggunakan AI sebebas mungkin untuk menyelesaikannya. Jika AI dapat membantu mereka menyelesaikannya, itu justru menunjukkan bahawa mereka mahir dalam memanfaatkan AI. Tahap kedua, minta mereka menerangkan pendekatan mereka: “Mengapa anda memilih pendekatan ini? Bagaimana anda memverifikasi bahawa ia betul?” Pada titik ini, anda sedang menguji kemampuan pengujian dan kecekapan kejuruteraan. Bahagian pertama menguji kemahiran memanfaatkan AI, manakala bahagian kedua menguji asas kejuruteraan. Ketiga, perhatikan bagaimana mereka bekerjasama—sedia berbagi atau lebih suka bekerja sendiri. Ada orang yang sangat mahir secara teknikal tetapi ingin mengendalikan semua perkara sendiri; dalam era Agent, orang seperti ini justru akan menjadi halangan.

Orang yang anda cari ialah yang mampu menggunakan AI secara maksimum, mempunyai asas kejuruteraan yang kukuh, dan bersedia untuk berkongsi serta bekerjasama. Bukan sekadar mereka yang pernah belajar ML atau AI, bukan juga pakar dekripsi, tetapi gabungan ketiga-tiganya. Anda mungkin tidak akan menemui seseorang yang memenuhi ketiga-tiga perkara ini sepenuhnya, dan itu tidak apa-apa—contohnya, calon tertentu mungkin sangat kuat dalam satu aspek tetapi memerlukan bimbingan dalam aspek lain. Jangan campurkan kemahiran-kemahiran ini dan labelkan sebagai “peringkat permulaan” atau “peringkat lanjutan”, kerana ia adalah dimensi kemahiran yang berbeza; seseorang mungkin mempunyai kemampuan penggunaan AI pada peringkat “lanjutan”, tetapi niat bekerjasama pada peringkat “permulaan”.

Bahagian Kejuruteraan VP masih perlu melaporkan kepada atasan. Kami membeli begitu banyak lesen, adakah kami boleh membuktikan pulangan atas pelaburan ini? Penghantaran menjadi lebih pantas? Mungkin ada janji, tetapi sukar untuk membuktikannya. Kualiti menjadi lebih baik? Begitu juga sukar untuk menyatakan. Tetapi kembali kepada dua indikator yang saya sebut sebelum ini, anda boleh menunjukkan berapa banyak pengurangan dalam bilangan intervensi, sejauh mana peningkatan, dan seberapa besar peningkatan kadar penggunaan semula. Ini jauh lebih mudah dan lebih meyakinkan berbanding membandingkan “produktiviti pengkodean dengan dan tanpa Agent”.

Jadi, apabila seseorang mengeluh bahawa Agen terlalu banyak memakan perbelanjaan dan ingin membatasi had, tindakan insting anda seharusnya bukan “kita potong semua perbelanjaan”, tetapi “bagaimana kita mengoptimumkan perbelanjaan”. Cara paling mudah ialah memilih model yang tepat—tidak semua tugas memerlukan model terkuat; beberapa tugas cukup dengan model yang lebih murah. Didik pembangun tentang skenario penggunaan model yang sesuai, dan lebih jauh lagi, berikan mereka Context dan Harness yang lebih baik, yang akan membantu Agen mengelakkan jalan buntu dan mengurangkan kos secara lebih ketara.

Masih ada topik mengenai saiz pasukan. Seseorang yang mahir dalam segala aspek yang menangani semua tugas adalah impian tertinggi. Tetapi jika anda kira dengan teliti: orang ini biasanya perlu didukung oleh kemahiran pelengkap, seperti produk manajer atau reka bentuk. Kemudian anda perlu mempertimbangkan anggota persediaan (backup), bagaimana jika seseorang cuti? Ini membawa kita kembali kepada tiga orang. Selepas itu, mungkin perlu ada seseorang yang memantau pengeluaran dan tiket kerja—jika anda benar-benar sangat efisien, mungkin orang yang sama juga menjalankan tugas tambahan ini. Tetapi sekali anda memperbaiki ralat, kelajuan pembangunan ciri akan melambat. Akhir sekali, ada ahli baharu yang perlu anda bimbing agar mereka memahami apa itu “baik”. Oleh itu, saya masih percaya bahawa dalam organisasi, kita tidak mungkin benar-benar menjadikan setiap pasukan hanya terdiri daripada satu atau dua orang.

Akhirnya, pabrik gelap mungkin tidak sepenuhnya gelap, tetapi mempertahankan sedikit cahaya redup (dim factory), yang bermaksud anda perlu menentukan sejauh mana risiko yang ingin anda ambil untuk setiap fungsi, kerana tidak semua fungsi sesuai untuk otonomi penuh. Anda boleh melabur lebih banyak dalam audit, seperti pelacakan sumber: siapa yang mengubah kod? Adakah ia manusia atau Agent? Tambahkan validator untuk memeriksa sama ada kod tersebut benar-benar berguna, dan melabur dalam kemampuan kesedaran konteks apabila proses automatik gagal. Ini adalah spektrum penuh, dari pengurusan mikro sepenuhnya (setiap baris kod perlu diperiksa oleh manusia) hingga persetujuan otonom penuh (mengandaikan semua hasil Agent adalah betul). Apa yang perlu anda lakukan ialah memilih tahap automatik yang berbeza untuk jenis perubahan yang berbeza berdasarkan paras risiko.

Dan saya rasa keunggulan kompetitif anda ialah menangkap pengetahuan yang telah terakumulasi, konteks perniagaan yang sekarang anda masukkan ke dalam skill, Context, dan bahkan batasan Harness. Bagi saya, ini sebenarnya membawa penghantaran berterusan kepada pembelajaran berterusan. Tanya diri anda: seberapa pantas kita boleh memasukkan sesuatu yang baru ke dalam sistem, dan mengeluarkan sesuatu yang lama? Ini adalah kemampuan reaksi anda. Jika anda boleh terus meningkatkan kemampuan ini, masalah utamanya bukan lagi “Saya ingin membuat keseluruhan sistem lebih boleh dipercayai,” tetapi “Bisakah saya mempertahankan kebolehpercayaannya sambil mengubah semakin banyak bahagian sistem?”

Jika hanya membawa satu ayat, maka seharusnya: Pemenang bukanlah pemain super yang berjuang sendirian, tetapi mereka yang memahami cara memperbaiki organisasi di pelbagai peringkat.