Pelopor DevOps Memperingatkan: Adopsi Agen AI Memerlukan Perubahan Tingkat Sistem, Bukan Hanya Alat

Jangan lagi memperbaiki kode yang dihasilkan oleh Agent, perbaiki sistem yang menghasilkan kode tersebut.

Penulis artikel, sumber: InfoQ

Jika seorang pengembang sama sekali tidak bisa menggunakan Agent dengan baik, masalahnya mungkin bukan pada pengembang, tetapi pada perusahaan yang belum menyediakan sistem yang berfungsi untuk Agent.

Banyak perusahaan yang menyebut transformasi AI mereka masih berhenti pada pembelian alat-alat seperti Cursor dan Claude Code untuk pengembang, mengadakan beberapa pelatihan, lalu membiarkan semua orang mengeksplorasi sendiri. Jika akhirnya efek Agent tidak baik, tanggung jawab justru kembali kepada pengguna.

Namun, Patrick Debois, yang memperkenalkan istilah DevOps, berpendapat: “Para pengembang perlu melakukan perubahan pola pikir yang penting: ketika Agent tidak menyelesaikan tugas sesuai harapan Anda, jangan lagi mengubah kode yang dihasilkannya, tetapi perbaiki seluruh sistem, bukan hanya Prompt.”

Menurut Debois, ini adalah perubahan yang harus dialami rekayasa perangkat lunak saat berpindah dari sistem deterministik ke sistem dan alur kerja non-deterministik dan probabilitas. Ini tidak hanya melibatkan teknologi, tetapi juga akan membentuk ulang cara kerja pengembang, tim, dan seluruh organisasi. Namun, perubahan ini tidak mungkin dicapai hanya oleh satu insinyur, atau hanya terbatas pada tingkat tim tunggal. Seperti DevOps, perubahan ini hanya dapat benar-benar terwujud ketika diterapkan secara skala besar.

Inti masalahnya bukan hanya apakah pengembang akan menggunakan Agent, tetapi apakah perusahaan dapat mengorganisasi ulang tim, platform, dan cara kolaborasi di sekitar Agent.

Poin utama sebagai berikut:

• Jangan lagi memperbaiki kode yang dihasilkan oleh Agent, perbaiki sistem yang menghasilkan kode tersebut.
• Jika masih ada orang di timmu yang menggunakan pendekatan liar seperti "YOLO (jalankan dulu)" untuk melakukan vibe coding, kamu harus segera menghentikannya. Praktik teknik tidak hanya penting untuk memelihara sistemmu, tetapi juga sangat penting agar Agent terus meningkat.
• Pabrik gelap mungkin tidak sepenuhnya gelap, tetapi mempertahankan sedikit cahaya redup (dim factory), yang berarti Anda harus memutuskan seberapa besar risiko yang diambil untuk fitur tertentu, karena tidak semua fitur cocok untuk otonomi penuh.
• Orang yang Anda cari adalah yang mampu memanfaatkan AI secara ekstrem, memiliki dasar teknik yang kuat, dan bersedia berbagi serta berkolaborasi.
• Moat Anda adalah memanfaatkan pengetahuan yang telah terakumulasi, konteks bisnis yang sekarang Anda masukkan ke dalam skill, Context, bahkan batasan Harness.

Pada tahun 2009, banyak orang mengatakan kepada saya bahwa ide pengiriman berkelanjutan itu gila.

Catatan penerjemah: Pada tahun 2009, industri secara umum menggunakan model peluncuran versi besar yang jarang, setiap beberapa bulan sekali. Semua orang menganggap semakin sering rilis, semakin tinggi risikonya. Selain itu, hambatan antara pengembangan dan operasional sangat ketat, infrastruktur otomatisasi seperti kontainer dan cloud belum matang, serta belum ada alat pipeline standar. Sementara itu, mekanisme pengujian tradisional dan persetujuan perubahan berfokus pada menghilangkan sebanyak mungkin cacat sebelum peluncuran. Namun, continuous delivery mengusung pendekatan baru: peluncuran frekuensi tinggi, inkremental, dan siap dirilis kapan saja, yang menggulingkan pemahaman umum tentang risiko peluncuran perangkat lunak dan pengendalian proses. Oleh karena itu, bagi sebagian besar perusahaan, pendekatan ini tampak seperti dongeng atau sangat gila.

Dan sekarang, Dark Factory kembali menghadapi hambatan yang sama sekali identik.

Translator's note: Dark Factory refers to an AI-driven autonomous software production model where humans only input SPEC, and AI autonomously completes coding, testing, and deployment without requiring manual line-by-line code review, differing from traditional software factories that still require substantial engineer involvement in the process.

Saya terus-mendengar kalimat yang sama di berbagai kesempatan: "Hal ini tidak berfungsi di sini." Namun, pesan sebenarnya yang disampaikan bukanlah teknologinya tidak berfungsi, melainkan "kami belum siap." Mereka tidak ingin menghindari menerapkan hal ini, tetapi struktur organisasi saat ini belum mendukung model semacam ini.

Saat ini banyak orang membahas cara mengoptimalkan Agent dengan siklus, cara membangun Harness, semuanya sangat bagus. Tetapi yang ingin saya sampaikan adalah, pada akhirnya kita semua akan mencapai tingkat teknologi tersebut, suatu hari nanti mereka akan menjadi produk standar, bahkan mungkin dikemas sebagai layanan oleh laboratorium terdepan. Pada hari itu, tidak ada lagi hambatan teknis. Perbedaan sejati terletak pada bagaimana organisasi Anda merekonstruksi cara kolaborasi di sekitar hal ini.

Jadi saya asumsikan kita semua sedang bergerak menuju arah pabrik gelap. Yang saya amati di Tessl dan perusahaan lainnya adalah bahwa ketika orang mulai mengadopsi teknologi ini, dinamika kolaborasi berubah secara radikal. Jika Anda familiar dengan Hukum Conway, Anda tahu ada hubungan saling membentuk antara cara organisasi dan alat yang digunakan—bagaimana Anda mengatur orang akan menentukan jenis sistem yang dihasilkan. Tetapi hari ini saya tidak ingin membahas cara membuat Agent Anda menjadi lebih baik; yang ingin saya bahas adalah bagaimana hal ini mengubah dinamika tim Anda, platform Anda, dan seluruh organisasi Anda.

Saya tebak sebagian besar dari Anda bekerja dalam tim, bukan sendirian; kolaborasi tim sama sekali berbeda dengan seseorang mengetik sendiri ke Claude Code.

Sekarang banyak orang membicarakan istilah ini: pengembang pada akhirnya akan menjadi seorang konduktor, seorang pengatur agen. Saya merasa pernyataan ini tidak salah, memang itulah jalur yang sedang kita tempuh. Kita semakin mirip dengan manajer agen, yang harus mengelola hubungan dengan agen-agen tersebut.

Tapi masalahnya, saya mendengar banyak pengembang mengatakan secara pribadi: Kami tidak masuk ke industri ini untuk melakukan hal ini, kami tidak pernah membayangkan harus menghabiskan banyak waktu untuk mengoptimalkan Prompt atau menulis SPEC yang lebih baik. Kami adalah insinyur, kami bekerja dengan teknologi, ini menciptakan ketegangan identitas, dan kami terus bertanya pada diri sendiri: Apakah ini peran yang benar-benar ingin saya jalani?

Kemudian muncul konsep yang disebut "Context engineering", yang memberikan jalan keluar bagi para pengembang. Konsep ini menyatakan bahwa ini bukan hanya tentang memanggil Prompt, tetapi Anda juga harus menguji, mengevaluasi, mendistribusikan, dan mengoptimalkan Prompt, sehingga memang ada sedikit nuansa teknik di dalamnya. Namun, sejujurnya, banyak pengembang masih merasa kosong hanya berurusan dengan Prompt dan SPEC, merasa diri mereka berubah dari insinyur menjadi "manajer prompt".

Namun, dalam praktiknya, saya mengamati sebuah titik balik yang menarik. Ketika kami mulai memperkenalkan Harness, siklus, bahkan mendorong seluruh organisasi menuju otonomi yang lebih tinggi, jalur teknis baru terbuka. Tiba-tiba, para pengembang perlu membuat alat untuk Agent, dan ini langsung membangkitkan semangat sekelompok orang. Para pengembang yang sebelumnya berpikir “Ini bukan pekerjaan saya” tiba-tiba menjadi bersemangat. Mereka berkata, benar, kami bisa melakukannya! Kami memiliki pengetahuan ini! Kami bisa memperbaiki sistem ini melalui pemrograman. Jadi ini menarik, ketika kami terus membicarakan “abstraksi, abstraksi, dan lagi abstraksi”, nuansa “keterampilan tangan” justru muncul kembali di posisi lain, menciptakan ruang baru untuk pekerjaan teknis yang lebih mendalam.

Sering kali orang bertanya kepada saya: Bagaimana cara menghadapi orang-orang yang skeptis? Jawaban saya selalu sama: Orang-orang ini sebenarnya adalah harta Anda. Karena mereka memiliki sejumlah besar pengetahuan implisit dan kecermatan penilaian yang perlu Anda masukkan ke dalam Agent. Anda bisa berkata kepada mereka: “Silakan keluarkan semua pengetahuan dan kritik Anda,” yang akan membuat Agent dan Harness menjadi lebih baik. Jika Anda bertemu seseorang yang sangat resisten dan terus-menerus mengeluh, “Kode yang dihasilkan ini kualitasnya buruk sekali,” anggaplah mereka sebagai bahan bakar—ubah kemarahan dan keraguan mereka menjadi dorongan untuk meningkatkan sistem.

Sekarang, izinkan saya memberikan saran kepada pengembang perusahaan saya: lakukan perubahan pola pikir besar—jangan lagi memperbaiki kode yang dihasilkan oleh Agent, tetapi perbaiki sistem yang menghasilkan kode tersebut. Seperti yang pernah dikatakan beberapa tahun lalu: jangan buat benda itu, tetapi buatlah sesuatu yang bisa membuat benda itu. Kita sekarang berada di tingkat abstraksi ini, menciptakan “sesuatu yang bisa membuat sesuatu” melalui Context, Harness, dan loop. Banyak yang masih terjebak di tingkat “Human in the Loop”, autocomplete, dan penyesuaian Prompt, perlu memikirkan cara untuk naik ke tingkat pemikiran sistem.

Yang benar-benar harus kita lakukan adalah meminimalkan intervensi manusia melalui praktik teknik yang baik. Di awal, semua orang merasa “vibe coding” sangat menyenangkan—masukkan Prompt, dapatkan hasilnya, lalu lanjutkan tanpa peduli. Namun kini semakin jelas bahwa kita tidak hanya memberi instruksi ke Agent melalui Prompt; kita sebenarnya berkata: “Tolong tulis bersama dengan pengujian, perbarui dokumentasi, dan patuhi standar kode.” Semua hal yang dulu kita katakan pada insinyur yang baik, sekarang kita sampaikan persis sama ke Agent. Jika di tim Anda masih ada yang menggunakan pendekatan liar “YOLO (jalankan dulu)” untuk vibe coding, Anda harus segera menghentikannya. Praktik teknik tidak hanya penting untuk memelihara sistem Anda, tetapi juga sangat penting agar Agent terus berkembang.

Saya mulai melihat ritual baru di beberapa tim yang lebih maju, yang tetap mengadakan rapat perencanaan dan rapat tinjauan, tetapi topik diskusinya berubah total. Dalam rapat tinjauan, mereka tidak lagi membahas “Apa yang salah dengan kode?”, melainkan “Apa yang salah dengan sistem?”

Saya juga melihat pembagian menarik dalam rapat perencanaan. Tugas-tugas yang didefinisikan sangat jelas dan cakupannya cukup spesifik langsung bisa diserahkan ke Agent, karena Harness semakin baik dan mampu menangani tugas-tugas yang jelas tersebut. Sementara itu, hal-hal yang batasannya kabur dan memerlukan diskusi tetap dibiarkan untuk manusia. Jadi, muncul pembagian alami dalam rapat perencanaan: kartu-kartu ini langsung masuk ke alur Agent, sementara kartu-kartu itu kita bahas bersama.

Pengembang biasanya mengalami siklus pembelajaran: pertama belajar Prompt, lalu SPEC yang lebih baik, kemudian Context, Harness, dan loop—seluruh industri pun sedang melewati siklus ini. Namun, yang bisa dilakukan oleh Team Lead adalah menetapkan ritme dan batasan untuk proses ini, misalnya dengan mengatakan: “Jangan lagi mengubah Prompt, buat Context menjadi dapat digunakan kembali.” “Baik, langkah ini selesai, mari kita lanjut ke langkah berikutnya.” Nilai seorang Team Lead terletak pada menetapkan ritme semacam ini; jika Anda hanya berkata, “Cari tahu sendiri,” itu tidak akan efektif.

Ada efek domino lainnya: begitu produktivitas tim Anda mulai melonjak, pihak di bawahnya, seperti tim GTM (Go to Market), akan kesulitan mengikuti, bahkan pengguna pun bisa ketinggalan. Jadi, Anda perlu menggunakan otomatisasi untuk membantu mereka; kerangka kerja Anda tidak boleh berhenti di tahap pengkodean, tetapi harus diperluas hingga mencakup mereka. Prinsip yang sama juga berlaku untuk input permintaan di hulu: jika permintaan datang terlalu lambat, tim akan terhambat, dan tahapan-tahapan ini juga perlu dimasukkan ke dalam alur kerja baru ini.

Saat ini ada banyak indikator di pasaran, seperti pengeluaran Token, dll. Tetapi saya semakin percaya pada dua indikator yang benar-benar dapat mengukur produktivitas. Pertama: hitung berapa kali intervensi manusia masih diperlukan agar Agent dapat menyelesaikan satu tugas dengan benar? Angka ini harus terus menurun. Semakin baik Harness Anda, semakin baik Context-nya, dan semakin jelas panduannya, angka ini akan semakin rendah. Indikator kedua adalah efek pengganda ketika Anda beralih dari bekerja sendiri ke sistem yang dibagikan. Ketika Anda memperbaiki sesuatu di satu tempat, semua orang mendapat manfaat. Ini bukan berarti satu orang menjadi sepuluh kali lebih efisien, tetapi optimasi pada sistem Agent sekali saja dapat menghasilkan efek pengganda bagi semua orang.

Anda dapat memulainya di dalam satu repositori atau di dalam tim kecil, berbagi Context, dan bersama-sama meningkatkan Harness. Namun, yang benar-benar ingin Anda lakukan adalah memperluas efek ini ke seluruh organisasi. Pada titik ini, kita harus membahas tim platform.

Tim platform adalah organisasi berbasis berbagi yang biasa, kini mereka mungkin sedang fokus pada infrastruktur, layanan cloud, gateway MCP, dan hal-hal semacam itu, sehingga belum terlalu memperhatikan aspek Agent. Namun, banyak hal baru sedang muncul yang perlu mereka ambil alih, seperti pusat pendaftaran keterampilan (tidak boleh setiap orang menciptakan keterampilan yang sama di sudut masing-masing), sistem evaluasi Context (apakah Context ini benar-benar berguna? Bisakah itu diukur?), serta pengaturan dan manajemen identitas khusus untuk coding agent (dengan identitas siapa Agent mengirimkan kode? Di mana batas wewenangnya?). Oleh karena itu, tim platform membutuhkan bantuan untuk mendorong mereka tumbuh menuju peran pusat yang baru ini.

Ini sulit, Anda harus memiliki pemilik yang jelas untuk mendorongnya. Tapi siapa seharusnya itu? Tim platform? Tim pengalaman pengembang? Yang pertama biasanya tidak menyentuh hal-hal tingkat pengembangan, sementara yang kedua jarang menyentuh infrastruktur, sehingga diperlukan某种融合, tetapi融合 ini tidak akan terjadi secara otomatis. Anda harus memastikan ada seorang penanggung jawab yang mendorong pekerjaan terpusat ini, jika tidak, tim Anda hanya akan sibuk di lahan masing-masing, dan tidak akan ada "Paved Road".

Mengapa setiap tim harus mengembangkan cara integrasi sistem otentikasi sendiri-sendiri? Ini adalah komponen bersama yang seharusnya dimasukkan ke dalam registry. Mengapa kita harus membangun Harness masing-masing? Jika kita semua menggunakan linter yang sama dan alat pemindaian keamanan yang sama, maka ini adalah komponen yang dapat digunakan kembali. Saya percaya ini akan seperti pembangunan infrastruktur cloud di masa lalu, yang secara bertahap terpusat ke dalam platform registry.

Tapi masalahnya, jika siapa pun bisa memasukkan apa saja ke dalam repositori pusat ini, maka akan tumbuh secara liar. Misalnya, sebuah skill diunggah, siapa yang memeliharanya? Orang lain kemudian membuat fork dari skill yang serupa, lalu saya harus memilih yang mana? Jadi, harus ada seseorang yang secara jelas memiliki kepemilikan atas suatu bidang tertentu, dan dia harus memastikan bahwa hal tersebut dapat diuji, bersifat modular, dan orang lain dapat memperluas bagian pemindaian keamanan di Context atau Harness berdasarkan itu. Anda harus melakukannya dengan cara terpusat, bukan hanya beredar secara sembarangan di dalam organisasi.

Mencapai konsensus itu sulit. Ini tidak sekenal perdebatan antara tabs dan spasi, tapi terkadang rasanya sama saja. Jika Anda meminta dua tim pengembang untuk mencapai konsensus tentang cara kerja mereka, itu memerlukan banyak komunikasi dan mediasi. Jadi pada akhirnya, Anda kemungkinan besar tidak akan memiliki hanya satu jalan beraspal, melainkan tiga atau empat, yang bisa mereka pilih. Jika mereka benar-benar ingin membuat versi sendiri, itu juga boleh, tapi itu menggunakan anggaran mereka sendiri. Yang dipelihara secara terpusat adalah "jalan mudah" yang dirancang untuk menarik orang agar menggunakannya.

Jika orang-orang secara sembarangan menggunakan kemampuan bersama ini, Anda harus membuat mereka melihat biayanya. Selama Anda memvisualisasikan pengeluaran tersebut, mereka secara alami akan ingin mengoptimalkannya. Ini adalah tanggung jawab tim platform untuk membuat biaya transparan: berapa banyak yang dihabiskan? Seberapa besar manfaatnya? Jika saya bisa mengurangi jumlah iterasi Agent, itu adalah optimasi. Tetapi jika saya tidak bisa melihat indikator ini, hanya melihat hasil akhir, maka saya tidak bisa memulai apa-apa—visualisasi adalah prasyarat semua optimasi.

Jadi, argumen inti saya adalah: kita harus berpindah dari pengembang yang bekerja sendiri-sendiri, menuju tingkat tim dengan berbagi konteks dan komponen bersama, dan akhirnya menuju sistem "permainan multi-pemain" di seluruh organisasi. Efek pengganda akan meledak di sana, karena Anda memiliki roda pendorong di mana perbaikan dapat meradiasi ke beberapa arah secara bersamaan.

Di tingkat yang lebih tinggi lagi, bagaimana VP Engineering memikirkan hal ini? Saya hampir bisa memprediksi cerita yang akan terjadi di organisasi Anda: hackathon atau sesi berbagi makan siang, berbagi kasus sukses, membuat saluran Slack bersama, dan mengadakan program champions. Semua ini adalah pola transformasi umum. Dulu transformasi Agile dilakukan seperti ini, DevOps juga dilakukan seperti ini, tidak ada yang baru.

Di sisi lain, kita juga tahu bahwa strategi “memberikan lisensi, mengadakan pelatihan, membiarkan orang-orang berkreasi secara bebas, membiarkan seribu bunga mekar” belum pernah berhasil. Hasil dari seribu bunga biasanya adalah seribu gulma—banyak bunga bermekaran, tetapi tidak ada satu pun yang berbuah. Oleh karena itu, saya mendukung agar di sisi organisasi diberikan otorisasi yang jelas kepada Team Lead dan tim platform untuk melaksanakan hal ini. Ini bukan sesuatu yang bisa diselesaikan oleh satu individu super, tetapi harus ada seseorang yang secara resmi diberi wewenang untuk mendorongnya.

Mencari bantuan juga merupakan hal yang menyusahkan. Nama jabatan saat ini sangat membingungkan—insinyur produk AI, forward deployed engineer, insinyur agentic, insinyur AI... istilah-istilah ini sebenarnya tidak memiliki makna substansial. Anda tidak bisa menilai tingkat kedewasaan seseorang hanya dari gelar mereka, karena seluruh industri ini masih belum matang. Namun, ketika Anda memposting lowongan pekerjaan, istilah-istilah ini memang memberikan sinyal tertentu dan menarik orang yang memiliki niat untuk melamar, tetapi itu sendiri tidak menjamin bahwa orang tersebut benar-benar memiliki keterampilan yang sesuai. Saya juga pernah mendengar kisah yang lebih aneh lagi, di mana beberapa kandidat menggunakan AI untuk memberikan jawaban secara real-time di telinga mereka selama wawancara; ketika pewawancara mengajukan pertanyaan, saran dari AI langsung terdengar melalui AirPods mereka.

Jadi saya mendengar semakin banyak perusahaan menggunakan metode wawancara seperti ini. Langkah pertama, berikan latihan yang memungkinkan mereka menggunakan AI sebebas mungkin untuk menyelesaikan soal. Jika AI bisa membantu mereka menyelesaikannya, itu justru menunjukkan bahwa mereka ahli dalam memanfaatkan AI. Tahap kedua, minta mereka menjelaskan solusi mereka: “Mengapa Anda memilih solusi ini? Bagaimana Anda memverifikasi bahwa itu benar?” Di sini Anda menguji kemampuan pengujian dan penilaian teknis. Bagian pertama menguji kemampuan memanfaatkan AI, bagian kedua menguji dasar-dasar teknik. Ketiga, perhatikan bagaimana mereka berkolaborasi, apakah mereka bersedia berbagi, atau lebih suka bekerja sendiri. Ada orang yang sangat ahli teknis tetapi ingin mengendalikan semuanya sendiri; di era Agent, orang seperti ini justru akan menjadi hambatan.

Orang yang Anda cari adalah yang mampu memanfaatkan AI secara ekstrem, memiliki dasar teknik yang kuat, dan bersedia berbagi serta berkolaborasi. Bukan sekadar orang yang pernah belajar ML atau AI, bukan pula seorang ahli dekode, melainkan kombinasi ketiganya. Anda mungkin tidak akan menemukan orang yang memenuhi ketiganya secara sempurna—dan itu tidak apa-apa. Misalnya, seorang kandidat mungkin sangat unggul di satu aspek, tetapi memerlukan bimbingan di aspek lain. Jangan campuradukkan keterampilan-keterampilan ini dengan label “pemula” atau “ahli,” karena mereka adalah dimensi keterampilan yang berbeda; seseorang mungkin memiliki kemampuan memanfaatkan AI pada tingkat “ahli,” tetapi tingkat kebersediaan untuk berkolaborasi masih pada tingkat “pemula.”

Departemen Teknik VP masih harus melaporkan hasil kepada atasan. Kita telah membeli begitu banyak lisensi, apakah bisa membuktikan return on investment? Apakah pengiriman menjadi lebih cepat? Mungkin ada janji, tetapi sulit dibuktikan. Apakah kualitas menjadi lebih baik? Sama sulitnya untuk dikatakan. Tetapi kembali ke dua indikator yang saya sebutkan sebelumnya, Anda bisa menunjukkan berapa banyak penurunan jumlah intervensi, seberapa besar perbaikan yang dicapai, serta seberapa tinggi peningkatan tingkat pemanfaatan ulang. Ini jauh lebih mudah dan lebih meyakinkan dibandingkan membandingkan "produktivitas coding dengan dan tanpa Agent".

Jadi, ketika seseorang mengeluh bahwa Agent terlalu boros dan ingin membatasi anggaran, reaksi insting Anda seharusnya bukan "kita potong semua pengeluaran," melainkan "bagaimana kita mengoptimalkan pengeluaran." Cara paling sederhana adalah memilih model yang tepat—tidak semua tugas memerlukan model terkuat; beberapa tugas cukup dengan model yang lebih murah. Edukasi pengembang tentang kapan menggunakan model apa, dan lebih jauh lagi, berikan mereka Context dan Harness yang lebih baik, sehingga Agent bisa menghindari jalan buntu dan biaya bisa ditekan lebih dalam.

Masih ada topik tentang ukuran tim. Seseorang yang serba bisa yang menangani semua tugas memang impian utama. Tetapi coba hitung secara rinci: orang ini biasanya perlu didukung oleh keterampilan yang saling melengkapi, seperti produk manajer atau desainer. Lalu Anda juga perlu mempertimbangkan staf cadangan (backup), bagaimana jika ada orang yang cuti? Ini kembali ke tiga orang. Kemudian mungkin perlu ada orang yang memantau produksi dan tiket kerja; jika Anda benar-benar sangat efisien, mungkin orang yang sama bisa melakukannya secara paruh waktu. Namun, begitu Anda memperbaiki bug, kecepatan pengembangan fitur akan menurun. Terakhir, ada anggota baru yang perlu Anda bimbing agar memahami seperti apa itu “baik”. Jadi saya tetap percaya bahwa dalam sebuah organisasi, kita tidak mungkin benar-benar membuat setiap tim hanya terdiri dari satu atau dua orang.

Akhirnya, pabrik gelap mungkin tidak sepenuhnya gelap, tetapi mempertahankan sedikit cahaya redup (dim factory), yang berarti Anda harus memutuskan seberapa besar risiko yang akan diambil untuk fitur tertentu, karena tidak semua fitur cocok untuk otonomi penuh. Anda dapat menginvestasikan lebih banyak dalam audit, seperti pelacakan asal: siapa yang mengubah kode? Manusia atau Agent? Tambahkan validator untuk memeriksa apakah kode tersebut benar-benar berguna, dan berinvestasilah dalam kemampuan kontekstual saat proses otomatis gagal. Ini adalah spektrum penuh, dari manajemen mikro sepenuhnya (setiap baris kode harus diperiksa manusia) hingga persetujuan otonom penuh (mengasumsikan semua output Agent benar). Yang harus Anda lakukan adalah memilih tingkat otomasi yang berbeda untuk jenis perubahan yang berbeda berdasarkan tingkat risikonya.

Dan menurut saya, moat Anda adalah menangkap pengetahuan yang telah terakumulasi, konteks bisnis yang sekarang Anda masukkan ke dalam skill, Context, bahkan ke dalam batasan Harness. Bagi saya, ini sebenarnya membawa continuous delivery menuju continuous learning. Tanyakan pada diri Anda: seberapa cepat kita bisa memasukkan sesuatu yang baru ke dalam sistem dan mengeluarkan sesuatu yang lama? Ini adalah kemampuan respons Anda. Jika Anda dapat terus meningkatkan kemampuan ini, masalah utamanya bukan lagi “Saya ingin membuat seluruh sistem lebih andal,” tetapi “Apakah saya bisa menjaga keandalan sistem sambil terus mengubah semakin banyak bagiannya?”

Jika hanya mengambil satu kalimat, itu seharusnya: Pemenangnya bukanlah pemain super yang berjuang sendirian, melainkan mereka yang memahami cara meningkatkan organisasi di berbagai tingkatan.