Eksekusi AI Agent 1 Juta Token Adalah Masalah Review, Bukan Soal Kecepatan

Gemini 4 Argon telah tersedia secara umum sejak 13 Oktober 2026, dan model ini menaikkan batas output Google dari 64 ribu token menjadi sekitar 1 juta token, sehingga model ini dapat “menghasilkan ratusan ribu token dalam satu trajektori.” Panduan pengembang Google menjelaskan caranya. Secara default, permintaan standar masih berhenti pada 65.536 token output. Jika Anda mengatur max_output_tokens lebih tinggi pada Interactions API dengan background: true, server akan terus menghasilkan output bertahap hingga 64 ribu token per loncatan sampai mencapai batas maksimal, yaitu hingga 1.048.576 token dikurangi input Anda. Google mengingatkan bahwa prompt yang kompleks membutuhkan waktu beberapa menit.

Bagian yang patut dibaca ulang dalam postingan peluncuran tersebut bukanlah soal batasannya, melainkan apa yang dilakukan Google dengan ukuran output sebesar itu. Google menyatakan telah menggunakan Argon secara internal untuk migrasi dari C/C++ ke Rust, mulai dari “puluhan ribu baris pada library inti seperti re2, libgav1 hingga lebih dari 800 ribu baris untuk kernel Fuchsia Zircon,” dan penulisan ulang tersebut sedang “menjalani audit otomatis dan manual yang ketat, pengujian emulasi, serta tinjauan sebelum diluncurkan ke tahap produksi.” Laboratorium yang melatih model tersebut pun tetap melakukan peninjauan sebelum merilisnya ke publik. Tim yang agennya kini dapat menghasilkan output dengan batasan enam belas kali lebih tinggi jelas membutuhkan rencana peninjauan sebelum membutuhkan model itu sendiri.

TL;DR

Batas output satu juta token menggeser titik hambat (bottleneck) dari pembuatan kode ke proses persetujuan dan penerimaannya. Kini, saat satu eksekusi dapat menghasilkan kode sebanyak itu, bagilah pekerjaan menjadi Tasks yang dapat ditinjau oleh seseorang dalam satu sesi kerja. Lengkapi setiap Task dengan definisi selesai (definition of done) tertulis serta batas waktu (timeout) per Task, wajibkan bukti pengujian pada setiap Task, dan hitung kapasitas peninjauan terlebih dahulu. Agen bertugas meriset, mengeksekusi, menguji, dan melapor. Manusia yang menentukan arah, memberikan kewenangan, serta menyetujui hasilnya.

Apa yang berubah ketika satu eksekusi dapat menghasilkan output sebesar ini

Kapasitas peninjauan adalah jumlah hasil kerja agen yang telah selesai yang mampu dibaca, dinilai, dan disetujui oleh sebuah tim dalam sehari—dan batasan ini ditentukan oleh manusia, bukan oleh model. Batas output yang lebih tinggi hanya menambah volume pekerjaan yang dapat masuk secara bersamaan.

Batas lama sebelumnya berfungsi sebagai pembatas cakupan tanpa disengaja: karena sebuah respons memiliki batasan panjang, pekerjaan kembali dalam bagian-bagian kecil dengan titik henti di antaranya. Alasan yang disampaikan Google terkait batas baru ini justru sebaliknya, yakni memberikan ruang lebih leluasa untuk “menyelesaikan masalah sulit sekaligus dalam sekali jalan.” Bagi seorang peninjau, “sekaligus dalam sekali jalan” berarti satu hasil utuh, satu keputusan, dan tanpa titik pemeriksaan (checkpoint) di mana seseorang bisa memperingatkan “arahnya salah.”

Batas tersebut juga dibagi bersama. Jendela 1.048.576 token pada Argon mencakup input, proses penalaran (thinking), dan output sekaligus. Jadi, eksekusi yang membaca 300 ribu token kode hanya menyisakan sekitar 748 ribu token untuk berpikir dan menulis. Jumlah tersebut tetap jauh lebih banyak daripada yang sanggup dibaca baris demi baris oleh siapa pun dalam satu sesi duduk.

Lalu ada faktor kualitas. Saat pengumuman peluncuran, Bloomberg melaporkan pernyataan anonim karyawan Google yang menyebutkan bahwa performa Argon kurang memuaskan pada beberapa tugas pengodean dan front-end dibandingkan dengan tolok ukurnya (benchmark); Google membantah hal tersebut dan menyebutnya tidak akurat. Tabel perbandingan resmi dari Google sendiri menunjukkan Argon tertinggal pada dua dari empat metrik agentic coding (perbandingan kami membahasnya secara terperinci). Tolok ukur hanyalah klaim terhadap serangkaian data uji. Sementara diff Anda adalah klaim nyata terhadap basis kode Anda sendiri, dan klaim tersebut baru dapat diterima berdasarkan bukti pengujian, model mana pun yang menulisnya.

Batasi cakupan Task, bukan anggaran tokennya

Unit kerja yang Anda kendalikan adalah Task, bukan jumlah token. Jika Anda membiarkan batas model menentukan ukuran pekerjaan, Anda akan menerima hasil sebesar mungkin yang sanggup dihasilkannya. Sebaliknya, tentukan sendiri batasannya agar menghasilkan luaran yang sanggup diterima manusia. Panduan Google sendiri sependapat: pertahankan nilai default 65.536 untuk tugas standar, serta gunakan mode background pada 131.072 atau 262.144 token untuk penalaran kompleks dan pengodean, alih-alih menggunakan batas maksimumnya.

Deskripsi Google sendiri sudah membagi pekerjaan berdasarkan library dan kernel. Bagilah proses porting dengan cara yang sama: satu Task per modul yang dapat diselesaikan seorang peninjau dalam satu sesi kerja. Di Sharkly, ini diwujudkan sebagai parent Task dengan sub-task untuk setiap modul, ditambah relasi “blocks / is blocked by” jika ada modul yang harus diselesaikan terlebih dahulu. Tujuan, cakupan, dan kriteria penerimaan dituliskan langsung pada deskripsi Task, baik sebagai panduan bagi Agent maupun bagi peninjau:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

Dua pengaturan Agent mendukung pendekatan ini. Batas waktu (timeout) per Task harus disesuaikan dengan kebutuhan Task tersebut, bukan batas model: tentukan durasi di atas estimasi wajar eksekusi terlama satu modul, tetapi tetap di bawah durasi eksekusi yang akan Anda sesali biayanya. Batas konkurensi maksimum (assigned tasks) membatasi jumlah modul yang sedang berjalan secara bersamaan, karena empat puluh sub-task yang berjalan serentak akan menghasilkan empat puluh luaran yang menumpuk di antrean peninjau yang sama.

Pedoman keputusannya sederhana: serahkan seluruh pekerjaan ke dalam satu kali eksekusi jika pemeriksaan otomatis dapat mencakup seluruh hasilnya secara tuntas, seperti refactor penggantian nama mekanis yang diverifikasi oleh kompilator dan rangkaian pengujian lengkap. Sebaliknya, pecahlah pekerjaan jika manusia perlu menilai bagian mana pun di dalamnya—yang pada migrasi bahasa pemrograman mencakup hampir seluruh bagian. Eksekusi yang berjalan melampaui jam kerja harian Anda membutuhkan prasyarat yang sama: kondisi henti, status menunggu, dan seseorang yang siap meninjaunya keesokan pagi.

Sertakan bukti pengujian pada Task

Hasil pekerjaan berskala besar tanpa bukti bukanlah bahan tinjauan. Itu sama saja dengan pengujian ulang yang dijalankan manual oleh manusia—dengan lambat.

Contoh pada libgav1 menunjukkan seperti apa wujud bukti pengujian yang baik. Google menjelaskan bahwa Argon menggantikan 32 ribu baris kode SIMD pada porting Rust yang sudah ada, dan hasilnya “berjalan 2,7 kali lebih cepat daripada porting Rust sebelumnya, dengan output video yang identik.” Paruh kedua dari kalimat itulah yang membuat 32 ribu baris kode tersebut layak ditinjau: input yang sama dijalankan pada kode lama dan baru, dan output keduanya cocok. Itulah pengujian diferensial (differential testing), yang membebaskan peninjau untuk fokus pada aspek yang tidak dapat dijangkau oleh perbandingan otomatis semata: unsafe code, alur penanganan galat (error paths), serta apakah peningkatan performa tersebut tetap konsisten pada beban kerja nyata.

Setiap eksekusi harus menyertakan empat hal ke dalam Task:

Alur kerja di Sharkly dirancang dengan skema seperti itu: Agent menjalankan typecheck, pengujian, dan build, kemudian melampirkan ringkasan perubahan, hasil verifikasi, serta batasan yang diketahui; selanjutnya, manusia yang memutuskan untuk menerima, meminta revisi, atau melanjutkan ke tahap merge dan rilis. Respons akhir Agent tersimpan pada Task dan log eksekusi tercatat di tab Executions, sehingga seluruh bukti tersaji langsung pada Task, alih-alih di terminal. Panduan meninjau dengan bukti tingkat task memaparkan urutan pembacaannya, dan templat serah terima (handoff templates) memberikan struktur laporan yang baku.

Lolos pemeriksaan otomatis bukan berarti pekerjaan disetujui, begitu pula proses merge: di Sharkly, melakukan merge pada pull request yang ditautkan tidak akan mengubah status Task. Pemeriksaan otomatis hanya memverifikasi apa yang bisa diuji mesin, dan ulasan agen peninjau kode AI mengulas batasan kemampuan tersebut. Pada akhirnya, manusialah yang menentukan apakah perubahan tersebut sudah memenuhi apa yang diminta oleh Task.

Hitung kapasitas peninjauan sebelum memulai eksekusi

Proses peninjauan menyerupai antrean: hasil pekerjaan masuk, peninjau menyelesaikannya, dan jika volume hasil masuk melebihi kecepatan penyelesaian, antrean akan menumpuk. Batas output yang lebih besar hanya mengubah sisi volume yang masuk. Berikut contoh kalkulasi dengan angka hipotesis, bukan dari proyek nyata:

Jika hanya melihat diff, migrasi tersebut membutuhkan 80 jam kerja peninjau, atau sekitar 27 hari kerja. Namun dengan menyertakan bukti pengujian pada setiap Task, waktu yang dibutuhkan berkurang menjadi 20 jam, atau sekitar tujuh hari kerja. Baik dijalankan dalam satu eksekusi masif maupun empat puluh eksekusi kecil, beban kerja dari sisi peninjau sebenarnya bernilai sama.

Perbedaannya terletak pada pengambilan keputusan. Empat puluh Task masuk dengan ritme yang dapat Anda kendalikan, dan masing-masing menerima putusannya sendiri. Sebaliknya, satu hasil yang mencakup keempat puluh modul sekaligus hanya mendapatkan satu putusan akhir; masalah pada modul ke-31 akan ikut menenggelamkan 39 modul lainnya. Dengan sistem sub-task, catatan pada modul yang gagal bisa memicu eksekusi lanjutan khusus untuk Task tersebut, sementara modul lainnya dapat terus berjalan.

Selanjutnya, perhitungkan biaya pengeluarannya. Satu eksekusi maksimal menghasilkan sekitar 1 juta token output: biayanya sekitar $10 berdasarkan tarif $10 per satu juta token hingga 30 November, dan sekitar $20 mulai 1 Desember. Pada proyek Tier 1, batas pengeluaran berbasis kuota Google adalah $10 per rentang 10 menit bergulir. Artinya, satu eksekusi maksimal akan menghabiskan seluruh batas kuota rentang tersebut pada tarif saat ini, dan dua kali lipat melampaui batas tersebut mulai 1 Desember. Pastikan pengaturan Max concurrency tetap rendah untuk Agent mana pun yang diizinkan menjalankan eksekusi sepanjang itu.

Hitung estimasi angka Anda sendiri sebelum memulai eksekusi besar pertama, bukan setelah antrean terlanjur menumpuk. Artikel perhitungan kapasitas peninjauan mengulas kalkulasi serupa di tingkat tim, dan artikel mengenai tinjauan manusia sebagai titik hambat membahas alur status serta gerbang persetujuan yang membuat antrean terpantau dengan jelas.

Daftar periksa sebelum eksekusi satu juta token pertama Anda

• [ ] Pekerjaan dipecah menjadi Tasks yang dapat diselesaikan oleh peninjau dalam satu sesi, lengkap dengan sub-task dan tautan ketergantungan “blocked by”.
• [ ] Setiap deskripsi Task memuat definisi selesai yang jelas serta hal-hal yang berada di luar cakupan (out of scope).
• [ ] Batas waktu (timeout) per Task disesuaikan dengan kebutuhan Task (permintaan background yang panjang memerlukan waktu beberapa menit), bukan mengikuti batas output model.
• [ ] Eksekusi maksimal tidak melampaui batas pengeluaran (spend limit) tingkat API Anda.
• [ ] Batas Max concurrency Agent untuk Task yang ditugaskan selaras dengan kecepatan peninjau memproses hasil, bukan semata-mata kapasitas Computer untuk menjalankannya.
• [ ] Setiap eksekusi mengembalikan ringkasan perubahan, output pemeriksaan, hal-hal yang diverifikasi, dan batasan yang diketahui.
• [ ] Pekerjaan yang mempertahankan perilaku kode lama disertai pengujian diferensial terhadap kode awal tersebut.
• [ ] Setiap Task memiliki peninjau yang ditunjuk, dan persetujuan ditandai melalui perubahan status oleh peninjau tersebut, bukan efek samping otomatis dari proses merge.

Semua hal di atas tidak bergantung pada Argon semata—yang kini dapat diakses dengan kunci API Gemini berbayar mana pun. Pola yang diterapkan Google menjadi rujukan utama: hasil output besar, disusul audit, pengujian emulasi, serta peninjauan menyeluruh, barulah masuk ke tahap produksi. Laboratorium riset mana pun yang merilis lompatan kapasitas output berikutnya, rencana kerja tetap bertumpu pada Task, bukan pada modelnya. Sharkly tidak menentukan model tertentu: merujuk pada dokumentasi Agents, Agent akan mengikuti model default dari Runtime-nya, yang dapat disesuaikan melalui Custom arguments atau konfigurasi alat terkait. Ketika model berkapasitas lebih besar hadir pada Runtime yang Anda gunakan, parameter tersebut tinggal diperbarui, sementara pengelolaan Task, bukti pengujian, dan gerbang peninjauan tetap berjalan stabil. Konteks, progres, hambatan, hasil akhir, hingga peninjauan manusia tetap transparan dari awal permintaan hingga rilis.

Jika Anda sudah menjalankan beberapa agen, Sharkly menyediakan satu platform terpusat untuk mengelola tugas dan hasil kerja mereka.