Catatan Editor: Ketika AI Agent semakin murah dan mudah dipanggil, pengembangan perangkat lunak memasuki tahap baru: masalahnya bukan lagi apakah kita bisa menjalankan lebih banyak Agent, melainkan apakah manusia masih memiliki cukup perhatian untuk mengelola, menilai, dan menggabungkan hasil kerja mereka.
Artikel ini mengemukakan konsep yang sangat inspiratif — "pajak penyusunan" ("orchestration tax"). Biaya memulai Agent sangat murah, cukup dengan sebuah Prompt atau satu klik; namun yang benar-benar mahal adalah tahap selanjutnya: memeriksa apakah hasilnya benar, memahami dampaknya terhadap arsitektur sistem, menangani konflik antara Agent yang berbeda, dan akhirnya memutuskan kode mana yang bisa masuk ke branch utama. Pekerjaan ini tidak bisa diparalelkan dengan mudah, tetap harus kembali ke satu sumber daya serial: penilaian manusia.
Penulis mengibaratkan pengembang sebagai "GIL" dalam sistem AI Agent, yaitu "kunci tunggal" yang membatasi throughput akhir sistem konkuren. Banyak Agent bisa berjalan bersamaan, tetapi begitu memasuki tahap penilaian arsitektur, peninjauan kode, dan penggabungan konflik, semuanya harus melewati otak pengembang lagi. Jadi, lebih banyak Agent tidak selalu berarti output yang lebih tinggi, mungkin hanya membuat antrian tugas yang perlu ditinjau lebih panjang, membuat pengembang terjebak dalam pergantian konteks dan kelelahan kognitif yang lebih sering.
Ini juga adalah poin yang sering diabaikan dalam tren alat pemrograman AI saat ini: rasa efisiensi dan produktivitas nyata tidak selalu sama. Dasbor yang penuh dengan Agent yang sedang berjalan, akan menciptakan ilusi "produktif"; tetapi jika pengembang tidak benar-benar memahami, meninjau, dan mengintegrasikan perubahan ini, yang akhirnya terakumulasi dalam sistem mungkin bukan produktivitas, melainkan utang teknis dan utang kognitif.
Oleh karena itu, artikel ini sebenarnya tidak membahas "bagaimana menggunakan lebih banyak Agent", melainkan "bagaimana merancang ulang alur kerja di sekitar perhatian manusia". Di era Agent, kemampuan kunci bukan hanya tahu bagaimana bertanya dan mendelegasikan tugas, tetapi juga mengetahui tugas mana yang bisa diserahkan ke mesin untuk diproses secara paralel, tugas mana yang harus disimpan untuk penilaian manusia; kapan harus meninjau secara batch, kapan harus berhenti menyusun, dan kembali fokus pada satu masalah inti.
AI sedang memperluas kemampuan konkurensi produksi perangkat lunak, tetapi perhatian manusia tetap menjadi sumber daya paling langka dan paling tidak bisa diduplikasi dalam sistem. Alur kerja Agent yang benar-benar matang, bukan melemparkan semua tugas ke mesin, melainkan seperti merancang sistem produksi, merancang arsitektur perhatian sendiri dengan serius.
Berikut adalah artikel aslinya:
Sekarang, menjalankan lebih banyak AI Agent sudah menjadi sangat mudah. Tetapi lebih banyak Agent yang berjalan bersamaan, tidak berarti "Anda" juga bertambah banyak. Bandwidth kognitif Anda tidak bisa diparalelkan. Semua penilaian yang benar-benar digunakan untuk memandu mereka, menilai hasil, menggabungkan perubahan, pada akhirnya masih harus melewati prosesor serial yang sama — yaitu Anda sendiri.
Apa yang disebut "pajak penyusunan" ("orchestration tax"), pada dasarnya adalah harga yang Anda bayar ketika melupakan hal ini. Dan satu-satunya solusi sejati, adalah seperti merancang sistem konkuren apa pun, mulailah merancang perhatian Anda sendiri.
Saya sebelumnya menghadiri diskusi panel di Google I/O, bersama Richard Seroter, Aja Hammerly, Ciera Jaspan membahas bagaimana rekayasa perangkat lunak saat ini, dan bagaimana kemungkinan perkembangannya selanjutnya. Mendekati akhir, Richard bertanya kepada kami: Apa satu hal yang paling penting untuk dibawa dan diubah oleh pengembang setelah mendengarkan ini?
Saya menyebutkan satu poin yang telah saya pikirkan berulang kali selama beberapa bulan ini: merasa sibuk sama sekali tidak berarti benar-benar produktif. Anda bisa menjalankan 20 Agent sekaligus, dan merasa sangat sibuk. Tetapi itu tidak berarti Anda telah menyelesaikan volume kerja yang setara dengan 20 Agent.
Di awal percakapan itu, Richard memberi nama untuk masalah ini. Dia berkata: "Apa yang baru saja Anda jelaskan sebenarnya adalah pajak penyusunan. Anda tidak mungkin berhasil mengelola 20 Agent di kepala Anda sendiri."
Dia benar sekali. Saya ingin membongkar konsep ini lebih lengkap, karena ini bukan masalah disiplin diri, melainkan masalah arsitektur.
Ada satu kalimat yang hampir saya ucapkan tanpa sengaja dalam diskusi panel itu, yang kemudian terus terngiang di benak saya: Menjalankan banyak Agent, tidak berarti dunia memiliki satu lagi diri Anda.
Asimetri yang Tidak Diperhitungkan Orang
Ada asimetri tersembunyi dalam alur kerja Agent.
Memulai sebuah Agent sangat murah. Anda hanya perlu menekan tombol keyboard, atau menulis sebuah Prompt. Tetapi menyelesaikan siklus penuh Agent sama sekali tidak murah. Pasti ada seseorang yang harus memeriksa apakah hasil yang dikembalikannya benar, dan menyelaraskannya kembali dengan konten yang telah diubah oleh Agent lain.
Orang itu adalah Anda. Dan Anda hanya satu.
Bulan lalu, saya menulis tentang sebagian masalah ini dalam "Batas Paralel Agent Anda", terutama membahas kecemasan lingkungan itu: Anda tidak tahu utas paralel mana yang diam-diam gagal. Artikel ini ingin membahas struktur di balik biaya ini.
Ketika Anda mulai melihat pengembangan Agent sebagai sistem konkuren, Anda akan menyadari bahwa manusia hanyalah sebuah komponen dalam sistem ini. Sebuah komponen serial yang lambat.
Anda Adalah Sumber Daya Berutas Tunggal Itu
Jika Anda pernah menulis kode konkuren, sebenarnya Anda sudah memiliki intuisi untuk memahami masalah ini. Hanya saja selama ini Anda menggunakan intuisi ini di tempat yang salah.
Python memiliki Global Interpreter Lock, atau GIL. Anda bisa membuat banyak thread, tetapi hanya satu thread yang bisa mengeksekusi bytecode Python dalam satu waktu, karena mereka semua harus mendapatkan kunci ini terlebih dahulu.
Anda adalah GIL untuk AI Agent Anda.
Mereka semua bisa berjalan bersamaan. Tetapi selama pekerjaan mereka memerlukan pemahaman sebenarnya tentang arsitektur sistem, atau perlu menyelesaikan konflik penggabungan, mereka harus mendapatkan kunci ini terlebih dahulu. Dan kunci ini hanya ada satu, dipegang oleh Anda.
Hukum Amdahl menyatakan hal ini dengan sangat tepat: Batas atas percepatan yang diberikan oleh paralelisasi, tergantung pada bagian pekerjaan yang masih harus diselesaikan secara serial. Jika ada bagian besar dalam proses Anda yang tidak dapat diparalelkan, maka berapa pun inti yang Anda masukkan, pada akhirnya akan menabrak batas atas yang keras.
Dalam pengembangan Agent, bagian serial ini adalah penilaian.
Menjalankan 8 Agent tidak akan mempercepat waktu penilaian Anda. Itu hanya akan membuat antrian yang menunggu untuk Anda proses menjadi lebih panjang.
Ini adalah fakta lama dalam rekayasa kinerja, tetapi banyak orang masih terkejut karenanya: Mengoptimalkan bagian yang bukan bottleneck tidak akan meningkatkan throughput keseluruhan. Anda hanya menumpuk lebih banyak pekerjaan yang belum selesai di depan bottleneck.
Menambah Agent mengoptimalkan bagian yang sebenarnya bukan kendala. Kendala sebenarnya adalah tahap peninjauan, dan throughput seluruh sistem, kebetulan sama dengan throughput tahap ini.
Pajak penyusunan, adalah kesenjangan struktural antara kemampuan produksi Agent dan konten yang sebenarnya bisa Anda gabungkan. Itu terjadi ketika Anda membuat sumber daya berutas tunggal mengelola sistem konkuren.
Memaksa Tidak Menyelesaikan Batas Atas Struktural
Dalam diskusi panel itu, saya pernah berkata: Saya belum pernah merasa alat saya sangat efisien seperti sekarang, tetapi saya juga belum pernah merasa begitu lelah seperti sekarang.
Kedua perasaan ini sepenuhnya nyata, dan mereka berasal dari alasan yang sama.
Kelelahan ini memiliki sumber yang sangat spesifik: itu adalah perasaan ketika sebuah prosesor serial terus-menerus ditekan hingga 100%, dan tidak diberi ruang apa pun.
Setiap kali Anda kembali memeriksa Agent yang telah keluar dari lingkup perhatian Anda, Anda membayar biaya pergantian konteks. Anda harus mengosongkan pikiran, kemudian memuat ulang konteks lain dari nol.
CPU bisa melakukan ini dalam mikrodetik, bahkan begitu, arsitek masih akan berusaha menghindari pergantian yang terlalu sering. Tetapi Anda butuh beberapa menit untuk menyelesaikannya, dan tidak pernah bisa memulihkan konteks dengan sempurna.
5 Agent bukanlah beban kerja 1 kali diulang 5 kali. Itu adalah 5 kali pemuatan ulang konteks seperti cold start, ditambah proses otak yang terus berjalan di latar belakang, terus-menerus khawatir Agent mana yang seharusnya Anda periksa sekarang.
Anda tidak bisa mengatasi batasan struktural dengan "berusaha lebih keras". Pajak ini selalu harus dibayar.
Jika Anda mencoba memaksa, pada akhirnya akan muncul dalam bentuk lain: baik peninjauan kode menjadi semakin dangkal, atau Anda masuk ke keadaan "menyerah kognitif" — karena membentuk penilaian sendiri terlalu menguras perhatian, Anda akhirnya langsung menerima kode yang ditulis Agent.
Anda bisa membayar pajak ini secara aktif, atau membiarkannya diam-diam menghancurkan pemahaman Anda tentang sistem Anda sendiri.
Rancang Perhatian Anda Seperti Merancang Sistem
Jadi, Anda harus memperlakukan perhatian Anda sendiri sebagai sumber daya serial yang langka.
Anda tidak akan merancang sistem terdistribusi tanpa mempertimbangkan bottleneck sama sekali. Maka, berikan otak Anda rasa hormat yang sama.
Berikut adalah beberapa metode yang benar-benar efektif bagi saya:
Perluas Tim Agent Berdasarkan Kemampuan Review, Bukan Berdasarkan Kemampuan UI.
Sistem konkuren yang baik akan menggunakan mekanisme backpressure, menghindari antrian tumbuh tanpa batas. Produsen harus memperlambat kecepatan, untuk menyesuaikan dengan kemampuan pemrosesan konsumen.
Jumlah Agent Anda adalah produsen, kemampuan review Anda adalah konsumen. Jumlah Agent paralel yang benar, seharusnya adalah jumlah yang bisa Anda tinjau dengan serius. Bagi kebanyakan orang, ini biasanya hanya satu digit rendah.
Alat AI tentu akan dengan senang hati membiarkan Anda menjalankan 20 Agent, tetapi itu hanyalah fitur UI, tidak berarti Anda benar-benar mampu mengelolanya.
Kategorikan Tugas.
Ketika Richard bertanya bagaimana saya menangani ini, saya menyebutkan metode ini. Saya akan membagi tugas menjadi dua tumpukan.
Tumpukan pertama, adalah pekerjaan yang relatif independen, yang saya serahkan kepada Agent yang berjalan di latar belakang cloud. Tugas ini bisa dieksekusi secara asinkron, biasanya hanya memerlukan saya melakukan pemeriksaan akhir.
Tumpukan kedua, adalah tugas kompleks, di mana pekerjaan sebenarnya itu sendiri adalah penilaian. Misalnya bug yang sangat aneh, atau desain arsitektur.
Kesalahan terbesar, adalah mencoba memparalelkan tugas jenis kedua juga. Memproses banyak tugas kompleks secara paralel tidak akan memperluas output Anda, hanya akan membuat kunci itu diperebutkan berulang kali, akhirnya semua hasil akan menjadi lebih buruk.
Review Secara Batch.
Setiap pergantian konteks akan membuat Anda membayar biaya tinggi. Duduk sekaligus untuk mereview hasil 4 Agent, jauh lebih murah daripada melihat satu, melakukan hal lain, kemudian cold start kembali untuk melihat yang lain.
Berikan tali penuntun yang lebih panjang kepada Agent. Biarkan pekerjaan sedikit terakumulasi, lalu proses sebagai satu batch.
Hanya Gunakan Kunci Ini Untuk Penilaian.
Jangan sia-siakan otak Anda untuk hal-hal yang bisa diverifikasi mesin sendiri. Buat Agent menulis tes yang bisa lolos, atau menghasilkan screenshot.
Biarkan mereka membuktikan sendiri 80% bagian yang membosankan tetapi dapat diverifikasi. Dengan demikian, perhatian langka Anda hanya perlu dihabiskan untuk 20% yang benar-benar membutuhkan penilaian manusia.
Lindungi Waktu Serial Anda.
Bottleneck membutuhkan waktu terbaik Anda, bukan sisa waktu pecahan di antara beberapa pemeriksaan Agent.
Terkadang, tindakan leverage tertinggi justru berhenti menyusun sepenuhnya: matikan komputer yang penuh dengan Agent itu, fokus saja memikirkan satu masalah, dan pegang erat-erat kunci itu selama seluruh proses.
Penyusunan bukan pekerjaan sebenarnya. Itu hanya overhead yang dihasilkan di sekitar pekerjaan.
Aja menunjukkan, kemampuan arsitektur sekarang telah menjadi keterampilan paling mendesak: Anda perlu tahu tugas apa yang cocok dimasukkan ke dalam sebuah Agent, tugas apa yang terlalu besar untuknya.
Saya juga ingin menambahkan: Anda sendiri juga adalah sebuah komponen dalam sistem ini. Perhatian Anda memiliki throughput serial yang diketahui, dan rendah. Sistem harus menghormati angka ini, atau akan menyiasatinya dengan diam-diam menurunkan standar Anda.
Sibuk Tidak Sama dengan Produktif
Hal ini sangat penting, karena mode kegagalan ini hampir tak terlihat bagi Anda sendiri.
20 Agent yang sedang berjalan akan memberi Anda perasaan "ledakan produktivitas". Dasbor penuh, semuanya bergerak. Tetapi perasaan ini telah terlepas dari tindakan nyata menggabungkan kode berkualitas tinggi ke dalam branch utama.
Anda bisa sibuk sampai batas, tetapi hampir tidak menghasilkan apa pun secara nyata. Dari pengalaman internal, kedua hal ini hampir identik.
Ciera menyebutkan penelitian Margaret-Anne Storey tentang utang. Kami membahas utang teknis, juga utang kognitif.
Pajak penyusunan yang tidak dibayar, akan membuat Anda mengakumulasi kedua jenis utang ini secara bersamaan.
Anda menggabungkan sesuatu yang belum Anda baca dengan serius. Model mental Anda tentang basis kode benar-benar kedaluwarsa. Masalah ini tidak akan muncul di dasbor hari ini. Mereka akan muncul ketika terjadi kerusakan di lingkungan produksi — saat itu Anda melihat sistem, tiba-tiba menyadari bahwa Anda sudah tidak tahu bagaimana cara kerjanya.
Jadi, kesimpulan sebenarnya adalah: Menjalankan Agent bukanlah kemampuan. Siapa pun bisa menjalankan 20.
Kemampuan sebenarnya, adalah merancang sistem di sekitar sumber daya serial yang tidak bisa dikloning, tidak bisa diparalelkan.
Sumber daya itu, adalah perhatian Anda.
Rancanglah seperti komponen kunci apa pun yang Anda andalkan dalam lingkungan produksi.
