Saat memakai AI untuk ngoding, kita sering masih jadi penghubung antara chat dan aplikasi. Salin kode dari jawaban AI, tempel ke editor, jalankan, lalu kirim pesan error-nya kembali. Begitu terus sampai hasilnya sesuai.

Google Antigravity memungkinkan kita menyerahkan rangkaian pekerjaan itu kepada agent. Kita menjelaskan tugasnya, lalu agent bisa mencari file, mengubah kode, menjalankan perintah, dan mencoba hasilnya lewat browser.

Google memperkenalkan Antigravity pada 18 November 2025. Pada 19 Mei 2026, Google merilis Antigravity 2.0, aplikasi desktop terpisah untuk bekerja dengan agent. Dari cara kerjanya, ada lima perubahan yang menarik buat developer.

1. Instruksi Bisa Langsung Berupa Masalah yang Ingin Dibereskan

Bayangkan pengguna gagal mendaftar dengan alamat email yang sudah pernah dipakai. Kalau bekerja lewat chat biasa, kita mungkin harus mencari file terkait, menyalin kodenya, lalu menjelaskan error yang muncul.

Dengan agent yang punya akses ke proyek, kita bisa memberi tugas: “Cek kenapa pendaftaran gagal saat email sudah terdaftar. Perbaiki penanganannya dan tambahkan tes untuk kondisi itu.” Agent bisa menelusuri kode dan menyiapkan perbaikannya dari sana.

Instruksi seperti ini tetap perlu menjelaskan hasil yang diharapkan. Apakah pengguna harus mendapat pesan bahwa email sudah dipakai? Apakah mereka perlu diarahkan untuk masuk? Keputusan itu perlu dibuat sebelum kita menilai perbaikannya.

Kalau kebutuhannya kabur, kode bisa berjalan sesuai pemahaman agent, tetapi meleset dari kebutuhan pengguna.

2. Beberapa Pekerjaan Bisa Berjalan Bersamaan

Saat menyiapkan fitur, ada pekerjaan yang bisa dipisah. Misalnya, memeriksa tampilan halaman dan meninjau tes pada bagian aplikasi yang berbeda.

Antigravity 2.0 mendukung subagent untuk mengerjakan tugas yang lebih kecil. Pekerjaan yang bisa dipisah dapat berjalan bersamaan, sementara kita mengikuti perkembangannya.

Bagian yang perlu dipikirkan adalah pembagian tugasnya. Kalau dua agent mengubah file yang sama, perubahan mereka bisa bentrok. Kalau satu tugas membutuhkan hasil tugas lain, menjalankan keduanya sekaligus justru bisa membuat pekerjaan diulang.

Sebelum membagi pekerjaan, tentukan bagian mana yang bisa dikerjakan sendiri-sendiri dan bagian mana yang harus menunggu. Banyaknya agent belum tentu menentukan cepatnya pekerjaan selesai.

3. Laporan “Selesai” Bisa Dicek Lewat Hasil Kerjanya

Kalimat “bug sudah diperbaiki” belum menjawab apa yang berubah dan bagaimana perbaikannya diuji. Kita tetap perlu melihat buktinya.

Antigravity menyediakan Artifacts, seperti rencana pengerjaan, catatan hasil kerja, tangkapan layar, dan rekaman pengujian browser. Bahan ini membantu kita memeriksa pekerjaan agent dan memberi masukan pada bagian yang perlu diperbaiki.

Misalnya, tangkapan layar bisa menunjukkan bahwa pesan error sudah muncul. Tapi kita masih perlu mengecek apakah pesan itu muncul pada kondisi yang tepat, apakah data tetap tersimpan dengan benar, dan apakah pengguna bisa melanjutkan prosesnya.

Saat membaca laporan agent, pertanyaan yang berguna adalah: apa yang sudah diuji, apa hasilnya, dan apa yang belum dicoba?

4. Kita Bisa Bekerja dengan Agent di Luar Editor

Antigravity 2.0 merupakan aplikasi desktop tersendiri. Kita bisa mengatur tugas dan meninjau hasil kerja agent di sana. Google juga menyediakan CLI dan SDK sebagai cara lain untuk memakai Antigravity.

Ini memberi pilihan tempat bekerja. Kita bisa mengikuti pekerjaan agent lewat aplikasinya, lalu membuka editor ketika perlu menelusuri kode atau melakukan perubahan langsung.

Jadi, apakah developer perlu meninggalkan IDE? Google sendiri masih menyarankan penggunaan Antigravity 2.0 bersama IDE pilihan developer.

Buat pekerjaan sehari-hari, pilihannya bisa mengikuti tugas. Perubahan kecil mungkin lebih cepat kita lakukan sendiri. Pekerjaan yang melibatkan pencarian banyak file, perbaikan, dan pengujian bisa kita serahkan kepada agent dengan arahan yang cukup.

5. Menentukan Hasil yang Benar Jadi Bagian Besar dari Pekerjaan

Agent bisa membantu menghasilkan kode, tetapi kita tetap perlu menentukan seperti apa hasil yang bisa diterima.

Ambil contoh fitur pendaftaran tadi. Tes yang hanya memeriksa apakah akun baru berhasil dibuat belum mencakup email yang sudah terdaftar, input yang tidak valid, atau gangguan koneksi. Kalau skenario penting tidak diperiksa, laporan tes yang lolos bisa membuat kita terlalu cepat merasa aman.

Hal serupa berlaku saat meninjau kode. Fitur mungkin berjalan, tetapi membawa dependensi yang tidak diperlukan atau membuat alurnya lebih sulit dipahami. Kita perlu menilai dampak perubahan itu terhadap aplikasi dan pekerjaan tim berikutnya.

Dasar pemrograman, debugging, pengujian, dan arsitektur tetap membantu kita mengambil keputusan tersebut. Semakin banyak pekerjaan yang diserahkan kepada agent, semakin kita membutuhkan cara yang jelas untuk memeriksa hasilnya.

Kalau ingin mencoba cara kerja ini, mulai dari satu bug yang penyebab dan hasil perbaikannya mudah diperiksa. Jelaskan masalahnya, tentukan skenario yang harus lolos, lalu bandingkan hasil agent dengan kriteria itu. Dari situ, kita bisa menilai bagian mana yang terbantu dan bagian mana yang masih perlu ditangani sendiri.

Referensi