Editor's Note: Ketika AI Agent menjadi semakin murah dan semakin mudah dipanggil, pengembangan perangkat lunak memasuki tahap baru: masalahnya bukan lagi apakah kita bisa memulai lebih banyak Agent, tetapi apakah manusia masih memiliki cukup perhatian untuk mengelola, menilai, dan menggabungkan hasil-hasilnya.

Artikel ini mengusulkan konsep yang sangat menginspirasi—“pajak orkestrasi.” Biaya untuk memulai Agent sangat rendah, hanya memerlukan satu Prompt atau satu klik; namun yang benar-benar mahal adalah tahapan berikutnya: memeriksa apakah hasilnya benar, memahami dampaknya terhadap arsitektur sistem, menangani konflik antar Agent, dan akhirnya memutuskan kode mana yang boleh masuk ke cabang utama. Pekerjaan ini tidak dapat disederhanakan menjadi paralel, tetapi tetap harus kembali ke sumber daya serial yang sama: penilaian manusia.

Penulis membandingkan pengembang dengan 'GIL' dalam sistem AI Agent, yaitu kunci single-thread yang membatasi throughput akhir sistem paralel. Beberapa Agent dapat berjalan secara bersamaan, tetapi setiap kali memasuki tahap penilauan arsitektur, tinjauan kode, dan penggabungan konflik, semuanya harus kembali melewati otak pengembang. Oleh karena itu, semakin banyak Agent, tidak selalu berarti产出 lebih tinggi, tetapi bisa saja hanya memperpanjang antrian tugas yang menunggu tinjauan, membuat pengembang mengalami lebih sering peralihan konteks dan kelelahan kognitif.

Ini juga merupakan hal yang sering diabaikan dalam gelombang alat pemrograman AI saat ini: rasa efisiensi dan produktivitas nyata tidak selalu sama. Sebuah dashboard agen yang penuh dengan aktivitas dapat menciptakan ilusi "produktivitas tinggi"; namun, jika pengembang tidak benar-benar memahami, meninjau, dan mengintegrasikan perubahan-perubahan ini, sistem pada akhirnya mungkin tidak menumpuk produktivitas, melainkan utang teknis dan utang kognitif.

Oleh karena itu, yang sebenarnya dibahas dalam artikel ini bukanlah "bagaimana menggunakan lebih banyak Agent", melainkan "bagaimana merancang ulang alur kerja berdasarkan perhatian manusia". Di era Agent, kemampuan kunci bukan hanya mampu bertanya atau mendistribusikan tugas, tetapi juga mengetahui tugas-tugas mana yang dapat diserahkan ke mesin untuk diproses secara paralel, dan tugas-tugas mana yang harus tetap diserahkan pada penilaian manusia; kapan harus melakukan review secara massal, dan kapan harus menghentikan pengaturan serta kembali fokus pada satu masalah inti.

AI sedang memperluas kapasitas paralel dalam produksi perangkat lunak, tetapi perhatian manusia tetap menjadi sumber daya paling langka dan paling tidak dapat direplikasi dalam sistem. Alur kerja Agent yang benar-benar matang bukanlah menyerahkan semua tugas ke mesin, melainkan merancang arsitektur perhatian Anda sendiri dengan serius, seperti merancang sistem produksi.

Berikut adalah teks aslinya:

Sekarang, memulai lebih banyak AI Agent menjadi jauh lebih mudah. Namun, lebih banyak Agent yang berjalan secara bersamaan tidak berarti «Anda» juga bertambah. Lebar pita kognitif Anda tidak dapat diparalelkan. Semua penilaian yang benar-benar diperlukan untuk membimbing mereka, menilai hasil, serta menggabungkan dan memodifikasi semuanya akhirnya harus melewati satu prosesor serial yang sama—yaitu diri Anda sendiri.

Yang disebut "pajak pengaturan" pada dasarnya adalah harga yang harus Anda bayar setelah melupakan hal ini. Satu-satunya solusi sejati adalah mulai merancang perhatian Anda sendiri, seperti merancang sistem konkuren apa pun.

Saya sebelumnya mengikuti diskusi panel di Google I/O bersama Richard Seroter, Aja Hammerly, dan Ciera Jaspan membahas tentang seperti apa rekayasa perangkat lunak saat ini, serta bagaimana kemungkinan perkembangannya di masa depan. Mendekati akhir, Richard bertanya kepada kami: Apa satu hal paling penting yang harus dibawa pulang dan diubah oleh para pengembang setelah mendengarkan?

Saya mengatakan satu hal yang telah saya renungkan berulang-ulang selama beberapa bulan ini: merasa sibuk tidak sama dengan benar-benar menghasilkan sesuatu. Anda bisa menjalankan 20 Agent sekaligus dan merasa sangat sibuk, tetapi itu tidak berarti Anda telah menyelesaikan volume kerja yang sesuai dengan 20 Agent tersebut.

Di bagian awal percakapan itu, Richard memberi nama pada pertanyaan ini. Ia berkata: "Yang baru saja Anda bahas sebenarnya adalah pengaturan pajak. Anda tidak mungkin berhasil mengelola 20 Agent hanya dalam pikiran Anda."

Dia benar sekali. Saya ingin menjelaskan konsep ini secara lebih lengkap, karena ini bukan masalah disiplin diri, melainkan masalah arsitektur.

Dalam diskusi meja bundar itu, ada satu kalimat yang hampir saja saya ucapkan secara asal, tetapi terus menghantui pikiran saya: menjalankan beberapa Agent tidak berarti ada tambahan diri Anda di dunia ini.

Asimetri yang tidak diperhitungkan oleh orang-orang

Ada ketidakseimbangan tersembunyi dalam alur kerja agen.

Mengaktifkan sebuah Agent sangat murah. Anda hanya perlu mengetik satu kali di keyboard, atau menulis satu Prompt. Namun, menyelesaikan siklus tertutup Agent sama sekali tidak murah. Pasti ada seseorang yang harus memeriksa apakah hasil yang dikembalikannya benar, serta menyelaraskan kembali perubahan yang dilakukan oleh Agent lain.

Orang ini adalah kamu. Dan kamu hanya satu.

Bulan lalu, saya telah membahas sebagian dari masalah ini di "Batas Agent Paralel Anda", terutama membahas kecemasan lingkungan: Anda tidak tahu jalur paralel mana yang sedang gagal diam-diam. Artikel ini ingin membahas struktur di balik biaya tersebut.

Ketika Anda mulai melihat pengembangan Agent sebagai sistem konkuren, Anda akan menyadari bahwa manusia sendiri hanyalah satu komponen dalam sistem ini. Sebuah komponen serial yang sangat lambat.

Kamu adalah sumber daya single-threaded itu

Jika Anda pernah menulis kode konkuren, Anda sebenarnya sudah memiliki intuisi untuk memahami masalah ini. Hanya saja, Anda sebelumnya salah mengarahkan intuisi ini.

Python memiliki Global Interpreter Lock, atau GIL. Anda dapat membuat sebanyak mungkin thread, tetapi hanya satu thread yang dapat mengeksekusi byte code Python pada satu waktu, karena semua thread harus terlebih dahulu mendapatkan kunci ini.

Kamu adalah GIL dari AI Agent-mu.

Mereka semua dapat berjalan secara bersamaan. Namun, selama pekerjaan mereka memerlukan pemahaman nyata terhadap arsitektur sistem, atau memerlukan penyelesaian konflik merge, mereka harus terlebih dahulu mengambil kunci ini. Dan kunci ini hanya ada satu, yang dipegang oleh Anda.

Hukum Amdahl menyatakan hal ini dengan sangat tepat: batas kecepatan yang dapat dicapai melalui paralelisasi bergantung pada bagian pekerjaan yang masih harus diselesaikan secara serial. Jika sebagian besar proses Anda tidak dapat diparalelkan, maka seberapa banyak core yang Anda gunakan sekalipun, Anda akhirnya akan mencapai batas keras.

Dalam pengembangan Agent, bagian serial ini adalah keputusan.

Mengaktifkan 8 Agent tidak akan mempercepat waktu penilaian Anda. Itu hanya akan membuat antrian yang menunggu pemrosesan Anda menjadi lebih panjang.

Ini adalah fakta lama dalam rekayasa kinerja, tetapi banyak orang tetap terkejut dengannya: mengoptimalkan bagian yang bukan bottleneck tidak akan meningkatkan throughput keseluruhan. Anda hanya menumpuk lebih banyak pekerjaan yang belum selesai di depan bottleneck.

Agen yang dioptimasi meningkatkan bagian yang sebenarnya bukan kendala. Kendala sejati adalah tahap review, dan throughput keseluruhan sistem justru sama dengan throughput tahap ini.

Taxation of scheduling adalah celah struktural antara kapasitas produksi agen dan konten yang sebenarnya dapat Anda gabungkan. Ini terjadi ketika Anda meminta sumber daya single-threaded untuk mengelola sistem konkuren.

Menahan tidak dapat menyelesaikan batas struktural

Di meja bundar itu, saya mengatakan satu kalimat: Saya belum pernah merasa alat saya seefisien ini, tetapi saya juga belum pernah selelah ini.

Kedua perasaan ini sama-sama nyata, dan keduanya berasal dari penyebab yang sama.

Kelelahan ini memiliki sumber yang sangat spesifik: itu adalah perasaan terus-menerus membebani prosesor serial hingga 100% tanpa memberikan sedikit pun ruang cadangan.

Setiap kali Anda kembali memeriksa sebuah Agent yang telah keluar dari fokus Anda, Anda harus membayar biaya peralihan konteks. Anda harus mengosongkan pikiran Anda, lalu memuat ulang konteks lainnya dari awal.

CPU dapat menyelesaikan hal ini dalam mikrodetik, meskipun demikian, arsitek tetap berusaha menghindari peralihan yang sering. Sementara itu, Anda membutuhkan beberapa menit untuk menyelesaikannya, dan tidak pernah dapat memulihkan konteks secara sempurna.

5 agen bukanlah beban kerja 1 kali yang diulang 5 kali. Ini adalah 5 kali pemuatan konteks seperti cold start, ditambah proses otak yang berjalan terus-menerus di latar belakang, terus-menerus khawatir agen mana yang seharusnya Anda periksa sekarang.

Anda tidak bisa menyelesaikan batasan struktural dengan "berusaha lebih keras". Pajak ini selalu harus dibayar.

Jika Anda mencoba memaksakan diri, pada akhirnya ia akan muncul dalam bentuk lain: baik itu tinjauan kode menjadi semakin dangkal, atau Anda memasuki keadaan "menyerah secara kognitif"—karena membentuk penilaian sendiri terlalu menguras perhatian, Anda langsung menerima kode yang ditulis oleh Agent.

Anda harus membayar pajak ini secara aktif, atau biarkan ia perlahan menghancurkan pemahaman Anda terhadap sistem Anda dari balik layar.

Desain perhatian Anda seperti sistem desain

Jadi, Anda harus memperlakukan perhatian Anda sebagai sumber daya serial yang langka.

Anda tidak akan merancang sistem terdistribusi tanpa mempertimbangkan bottleneck sama sekali. Maka, berikan pula penghormatan yang sama kepada otak Anda.

Berikut adalah beberapa metode yang benar-benar efektif bagi saya:

Sistem paralel yang baik akan menggunakan mekanisme backpressure untuk mencegah antrian tumbuh tanpa batas. Produsen harus memperlambat kecepatannya agar sesuai dengan kapasitas konsumen.

Jumlah Agent Anda adalah produsen, kemampuan review Anda adalah konsumen. Jumlah paralel Agent yang tepat seharusnya sesuai dengan jumlah yang dapat Anda review dengan serius. Bagi kebanyakan orang, ini biasanya hanya angka satuan yang sangat rendah.

Alat AI tentu akan dengan senang hati memungkinkan Anda menjalankan 20 Agent, tetapi itu hanyalah fitur antarmuka, bukan berarti Anda benar-benar mampu mengelolanya.

Saat Richard bertanya kepada saya bagaimana menangani hal ini, saya menyebutkan metode ini. Saya akan membagi tugas menjadi dua kelompok.

Tumpukan pertama adalah pekerjaan yang relatif independen, yang saya bersedia serahkan kepada Agent yang berjalan di latar belakang cloud. Tugas-tugas ini dapat dieksekusi secara asinkron, dan biasanya hanya memerlukan satu kali pemeriksaan terakhir dari saya.

Tumpukan kedua adalah tugas kompleks, di mana pekerjaan sejatinya adalah penilaian. Misalnya, bug yang sangat aneh, atau desain arsitektur.

Kesalahan terbesar adalah mencoba memparalelkan tugas kelas kedua. Memproses secara paralel beberapa tugas kompleks tidak akan meningkatkan output Anda, tetapi hanya akan membuat kunci itu terus-menerus diperebutkan, sehingga semua hasil akhirnya menjadi lebih buruk.

Setiap peralihan konteks akan menimbulkan biaya tinggi. Duduk sekaligus untuk meninjau hasil 4 Agent jauh lebih hemat daripada melihat satu, melakukan hal lain, lalu memulai kembali untuk melihat yang lain.

Berikan agen tali yang lebih panjang. Biarkan pekerjaan sedikit menumpuk, lalu selesaikan sebagai satu batch.

Jangan buang otakmu untuk hal-hal yang bisa diverifikasi sendiri oleh mesin. Biarkan Agent menulis tes yang lulus, atau hasilkan tangkapan layar.

Biarkan mereka membuktikan sendiri 80% bagian yang membosankan tapi dapat diverifikasi. Dengan begitu, perhatian langka Anda hanya perlu dihabiskan untuk 20% yang benar-benar membutuhkan penilaian manusia.

Bottleneck membutuhkan waktu terbaikmu, bukan waktu sisa yang terpecah-pecah di antara beberapa pemeriksaan Agent.

Kadang-kadang, tindakan leverage tertinggi justru adalah berhenti sepenuhnya dari penataan: matikan komputer yang penuh dengan Agent, fokus hanya pada satu pertanyaan, dan pegang erat kunci itu sepanjang prosesnya.

Penjadwalan bukanlah pekerjaan yang sebenarnya. Itu hanya biaya overhead yang timbul dari pekerjaan.

Aja menunjukkan bahwa kemampuan arsitektur kini menjadi keterampilan paling mendesak: Anda perlu tahu tugas apa yang cocok dimasukkan ke dalam Agent, dan tugas apa yang terlalu besar untuknya.

Saya juga ingin menambahkan: Anda sendiri adalah salah satu komponen dalam sistem ini. Perhatian Anda memiliki throughput serial yang diketahui sangat rendah. Sistem either menghormati angka ini, atau akan melewatkannya dengan secara diam-diam menurunkan standar Anda.

Sibuk tidak sama dengan produktif

Ini sangat penting, karena kegagalan model ini hampir tidak terlihat oleh Anda sendiri.

20 agen yang sedang berjalan akan memberi Anda perasaan “produktivitas meledak-ledak”. Dasbor penuh sesak, semuanya bergerak. Tetapi perasaan ini sudah terpisah dari benar-benar menggabungkan kode berkualitas tinggi ke dalam cabang utama.

Anda bisa sibuk sampai batas maksimal, tetapi hampir tidak menghasilkan apa-apa. Dari perspektif internal, keduanya hampir identik.

Ciera menyebut penelitian Margaret-Anne Storey tentang utang. Kami membahas utang teknis, juga utang kognitif.

Tanpa pembayaran pajak pengaturan, Anda akan secara bersamaan menumpuk kedua utang ini.

Anda menggabungkan hal-hal yang tidak pernah Anda baca dengan serius. Model mental Anda terhadap kode base sudah sangat ketinggalan zaman. Masalah-masalah ini tidak akan muncul di dashboard hari ini. Mereka akan muncul saat terjadi kegagalan di lingkungan produksi—ketika Anda melihat sistem dan tiba-tiba menyadari bahwa Anda sudah tidak lagi tahu bagaimana cara kerjanya.

Jadi, kesimpulan sebenarnya adalah: meluncurkan Agent bukanlah kemampuan. Siapa pun bisa menjalankan 20.

Kemampuan sejati adalah merancang sistem di sekitar sumber daya serial yang tidak dapat dikloning atau diparalelkan.

Sumber ini adalah perhatian Anda.

Desainlah seperti merancang komponen kritis yang bergantung pada lingkungan produksi.