Google telah menambahkan perintah baru bernama /boost ke lingkungan pengembangan Antigravity miliknya. Menjalankannya akan memulai pipeline penalaran multi-agen, bukan satu asisten pemrograman tunggal: sebuah orkestrator membaca masalah dan memecahnya menjadi tugas-tugas, membagikannya kepada agen-agen khusus yang bekerja dalam lingkup terisolasi, lalu membawa hasilnya melalui putaran verifikasi independen yang benar-benar menjalankan pengujian sebelum apa pun sampai kepada Anda. Berita utamanya bukan bahwa AI menulis kode lebih cepat. Melainkan bahwa alat pemrograman mulai membangun verifikasi ke dalam alat itu sendiri.

Apa yang sebenarnya diumumkan Google

Menurut dokumentasi resmi Antigravity, /boost dirancang khusus untuk rekayasa perangkat lunak yang sulit: bug konkurensi dan race condition, optimasi algoritmik, regresi halus yang muncul lalu menghilang, serta refaktor rumit yang mencakup banyak file. Inilah persis masalah yang membuat asisten konvensional satu giliran gagal, karena menyelesaikannya membutuhkan eksperimen dan langkah mundur, bukan generasi langsung.

Perintah ini berjalan dalam tiga fase yang jelas:

  • Perencanaan: orkestrator utama menerima prompt Anda, memeriksa konteks workspace, menyusun strategi eksekusi, dan menguraikan tantangan menjadi subtugas yang terpisah dan dapat diverifikasi.
  • Eksekusi terdistribusi: orkestrator membagikan subtugas tersebut kepada agen-agen khusus. Alur kerja implementasi menulis kode dan unit test. Alur kerja investigasi melakukan debugging akar masalah dan menelusuri grafik pemanggilan tanpa mengubah file apa pun. Agen verifikasi lokal menjalankan target build dan rangkaian pengujian untuk memvalidasi hipotesis sebelum melapor.
  • Verifikasi sebelum penyerahan: orkestrator menggabungkan temuan dan menjalankan pemeriksaan regresi terhadap rangkaian pengujian lengkap dan kasus-kasus tepi. Jika sebuah asersi gagal, diagnostik galat diumpankan ke iterasi berikutnya untuk koreksi otomatis, dan Anda hanya menerima ringkasan perubahan yang terverifikasi setelah semuanya lolos.

Semua ini berjalan di dalam worktree sementara yang terisolasi, artinya agen tidak bereksperimen pada salinan kerja proyek Anda.

Tiga mode, bukan satu

Google mendokumentasikan tiga mode eksekusi yang berbeda, dan perbedaan di antara ketiganya adalah bagian yang berguna secara praktis:

  • Agen default: pemrograman interaktif, navigasi basis kode, dan refaktor umum. Rentang tugas dari hitungan detik hingga menit, loop agen tunggal, verifikasi satu kali jalan. Tersedia di semua paket.
  • /boost: penalaran mendalam dan bug yang membandel. Rentang tugas dari hitungan detik hingga jam, hierarki tiga fase, verifikasi independen beberapa putaran. Tersedia di paket berbayar.
  • /teamwork-preview: tim agen yang bekerja selama berhari-hari pada migrasi besar atau pembangunan seluruh subsistem, dengan peran bernama seperti Explorer, Worker, Critic, dan Auditor, ditambah gerbang verifikasi yang sengaja mencoba merusak kode sebelum sebuah tonggak pencapaian disetujui.

Perhatikan gradasinya: semakin besar tugasnya, semakin banyak investasi yang diarahkan ke peninjauan alih-alih kecepatan. Ini sinyal yang patut diperhatikan oleh siapa pun yang menjalankan proyek perangkat lunak.

Mengapa ini penting bagi pemilik bisnis, bukan hanya pengembang

Selama dua tahun terakhir, pembicaraan tentang AI dalam pemrograman adalah pembicaraan tentang kecepatan: berapa baris yang dihasilkan per menit. Masalahnya, kecepatan bukanlah hambatan dalam proyek nyata. Hambatannya adalah kepercayaan. Apakah kode ini benar-benar berfungsi dalam kasus-kasus yang belum pernah dicoba siapa pun?

Yang secara tersirat dikatakan arsitektur /boost adalah bahwa industri telah sampai pada kesimpulan yang sama. Kode yang datang lebih cepat tidak ada nilainya jika menghabiskan dua minggu debugging setelah diserahkan. Karena itu alat ini dibangun di sekitar tiga aturan yang berlaku untuk tim teknis mana pun, dengan atau tanpa AI:

  • Penulis tidak menilai pekerjaannya sendiri: pihak yang memverifikasi terpisah dari pihak yang mengimplementasikan. Itulah prinsip di balik peninjauan kode selama puluhan tahun. Kini prinsip itu ditegakkan di dalam alat.
  • Bukti berarti eksekusi, bukan klaim: pengujian benar-benar dijalankan dan keluaran nyatanya diperiksa, alih-alih menerima klaim bahwa pengujian telah lolos.
  • Isolasi melindungi yang asli: eksperimen dilakukan di salinan terpisah, sehingga percobaan yang gagal tidak pernah bocor ke dalam proyek.

Jika Anda membeli jasa pengembangan perangkat lunak, inilah tepatnya tiga pertanyaan yang perlu diajukan kepada vendor Anda: siapa yang meninjaunya, apa buktinya bahwa pengujian lolos, dan di mana eksperimen dilakukan?

Apa yang tidak berubah

Mudah untuk membaca berita seperti ini sebagai pengumuman bahwa insinyur tidak lagi dibutuhkan. Dokumentasinya justru menyatakan sebaliknya dengan cukup gamblang: agen mewarisi aturan akses file dan kebijakan izin perintah yang dikonfigurasi untuk workspace Anda, dan setiap perintah yang dilindungi atau pengeditan di luar lingkup tepercaya akan memunculkan permintaan otorisasi kepada pengguna. Ada manusia yang bertanggung jawab di ujung rantai.

Dan izin hanyalah separuh yang lebih kecil. Agen menyelesaikan masalah yang Anda jelaskan. Agen tidak bisa tahu bahwa deskripsi itu sendiri salah. Agen tidak tahu bahwa siklus penagihan Anda ditutup pada tanggal 25 dan bukan tanggal 30, bahwa kolom ini tidak boleh pernah terlihat oleh tenaga penjualan, atau bahwa ketika pelanggan Anda mengatakan "pesanan", yang mereka maksud berbeda dari yang Anda maksud. Mendefinisikan kebutuhan, memahami domain, dan memikul keputusan tetap sepenuhnya merupakan pekerjaan manusia.

Bagaimana kami di Origami melihatnya

Kami memperlakukan alat multi-agen seperti kami memperlakukan alat produktivitas apa pun: alat ini mempercepat eksekusi, tetapi tidak memindahkan tanggung jawab. Proyek di sini tetap melewati spesifikasi tertulis, peninjauan manusia, rangkaian pengujian, dan lingkungan staging sebelum produksi, baik kodenya ditulis oleh orang maupun dihasilkan oleh agen. Alat yang menjalankan pengujiannya sendiri adalah tambahan yang disambut baik dalam rantai tersebut, tetapi ia hanyalah satu mata rantai, bukan penggantinya.

Pelajaran praktis bagi pemilik bisnis: harapkan jadwal penyerahan menjadi lebih singkat, khususnya untuk pekerjaan yang kompleks, tetapi jangan terima serah terima tanpa pengujian, tanpa dokumentasi, dan tanpa penanggung jawab manusia. Alat yang meninjau dirinya sendiri menaikkan batas atas kualitas yang dapat dicapai. Alat itu tidak menghilangkan kebutuhan Anda akan seseorang yang menjamin bahwa apa yang dibangun adalah apa yang Anda minta.

Sumber