Keunggulan Antigravity: Flow yang Menjaga Correctness Tanpa Mengorbankan Kecepatan AI

Andrej Karpathy pernah menggambarkan vibe coding dengan kalimat yang jadi viral: “forget the code exists”. Idenya sederhana — biarkan AI menulis, kamu cuma menerima, menjalankan, dan kalau errornya muncul, tempel saja ke AI lagi sampai jalan. Ini menarik di awal karena terasa cepat. Tapi siapa pun yang pernah membersihkan codebase hasil vibe coding tahu bahwa kecepatan itu punya tagihan yang datang belakangan — bug yang tidak jelas asalnya, arsitektur yang tidak konsisten, dan developer yang tidak lagi punya model mental tentang sistem yang dia “buat” sendiri. Tulisan ini membahas satu pola kerja spesifik di Antigravity yang saya pakai belakangan ini — implementation plan, review ketat, eksekusi, lalu walkthrough yang di-review lagi — dan kenapa pola ini, kalau dijalankan dengan benar, bukan vibe coding, meski tetap memanfaatkan kecepatan AI secara penuh.

Apa Itu Vibe Coding, dan Kenapa Ini Masalah

Definisi vibe coding sering disalahpahami sebagai “menulis kode menggunakan AI”. Itu keliru. Batas sebenarnya bukan pada alat yang dipakai, tapi pada apakah developer masih memegang kontrol dan pemahaman terhadap apa yang sedang dibangun.

Ciri vibe coding yang sebenarnya:

• Accept-all tanpa membaca. Diff yang dihasilkan AI langsung diterima karena “biasanya benar”, bukan karena sudah dievaluasi.
• Kriteria kebenaran yang kabur. Kode dianggap “selesai” kalau terlihat jalan saat dicoba sekali, bukan karena developer paham kenapa itu benar.
• Ownership yang hilang. Ketika bug muncul minggu depan, developer tidak bisa menjelaskan keputusan desain yang diambil, karena keputusan itu sebenarnya tidak pernah benar-benar diambil olehnya — cuma disetujui secara pasif.
• Model mental yang tidak terjaga. Developer kehilangan gambaran utuh tentang bagaimana bagian-bagian sistem saling berhubungan, karena dia tidak pernah benar-benar berpikir melalui implementasinya.

Masalahnya bukan kecepatan itu sendiri. AI memang jauh lebih cepat menulis boilerplate, migrasi, atau implementasi yang polanya sudah jelas. Masalahnya adalah ketika kecepatan itu dibeli dengan cara mengorbankan correctness — dan correctness itu baru terasa harganya belakangan, saat sistem sudah kompleks dan developer sudah kehilangan jejak.

Ini yang coba dijawab oleh flow kerja seperti yang ditawarkan Antigravity: bagaimana caranya tetap dapat kecepatan penuh dari AI, tapi tidak kehilangan correctness dan model mental yang jadi korban dalam vibe coding.

Lima Checkpoint dalam Flow Antigravity

Flow ini punya lima titik yang masing-masing adalah kesempatan bagi manusia untuk mengambil keputusan — bukan sekadar menonton AI bekerja.

1. Implementation Plan

Sebelum satu baris kode pun dieksekusi, agent menyusun dokumen implementation plan. Dokumen ini berisi pendekatan yang akan diambil, file-file yang akan disentuh, urutan langkah, dan asumsi yang dipakai. Ini adalah representasi dari “niat” AI sebelum niat itu berubah jadi kode yang harus dibaca baris per baris.

Poin pentingnya di sini bukan sekadar “ada dokumen plan”. Ini soal memindahkan titik keputusan ke fase yang jauh lebih murah untuk dikoreksi. Mengoreksi satu paragraf di plan yang salah arah jauh lebih murah — secara waktu dan secara kognitif — daripada mengoreksi implementasi yang sudah menyebar ke sepuluh file.

Bayangkan skenario sederhana: task-nya adalah menambahkan caching ke satu endpoint yang lambat. Tanpa plan, agent bisa langsung memilih pendekatan apa pun yang menurutnya masuk akal — bisa in-memory cache yang tidak akan bertahan lintas instance server, bisa juga caching di layer yang salah sehingga invalidasi jadi rumit di kemudian hari. Developer baru sadar pilihan itu keliru setelah membaca kode jadi, kalau sempat membaca sama sekali.

Dengan implementation plan, pendekatan itu tertulis eksplisit sebelum kode ditulis: “akan menggunakan Redis dengan TTL 5 menit, invalidasi manual dipicu dari endpoint update terkait, key menggunakan hash dari parameter query”. Developer bisa langsung melihat apakah pendekatan ini cocok dengan infrastruktur yang sudah ada, apakah TTL 5 menit masuk akal untuk use case ini, dan apakah strategi invalidasi itu akan menimbulkan stale data di skenario tertentu — semua ini dievaluasi sebelum satu baris kode pun ditulis.

2. Review Ketat terhadap Plan

Ini titik krusial pertama. Developer membaca plan itu bukan untuk mengecek “apakah ini terdengar masuk akal”, tapi mencocokkannya dengan prinsip arsitektur dan pengalaman yang sudah dia pegang. Apakah pendekatan ini konsisten dengan pola yang sudah ada di codebase? Apakah ada trade-off yang tidak disebutkan AI tapi sebenarnya penting? Apakah scope-nya pas, atau AI diam-diam memperluas perubahan ke area yang tidak diminta?

Review di titik ini adalah bentuk paling murni dari menjaga kontrol — developer masih menjadi pengambil keputusan arsitektural, AI cuma mengusulkan. Kalau plan-nya salah, developer meminta revisi sebelum eksekusi dimulai, bukan setelah.

Melanjutkan contoh caching di atas: kalau developer punya prinsip bahwa semua data yang berhubungan dengan sesi user tidak boleh di-cache lebih dari satu menit karena alasan konsistensi, tapi plan yang diajukan AI menetapkan TTL 5 menit, ini adalah momen untuk push back. Developer tidak perlu menulis ulang plan-nya sendiri — cukup menyatakan batasan itu, dan meminta agent merevisi plan sebelum lanjut. Ini jauh lebih murah dibanding menemukan masalah konsistensi data setelah fitur sudah live dan user mulai melaporkan data yang tidak sinkron.

Review yang efektif di titik ini biasanya mengajukan beberapa pertanyaan tetap: Apakah pendekatan ini konsisten dengan keputusan arsitektural yang sudah pernah dibuat di bagian lain sistem? Apakah ada dependency baru yang diperkenalkan, dan apakah itu proporsional dengan masalah yang dipecahkan? Apakah plan ini mengasumsikan sesuatu tentang data atau infrastruktur yang sebenarnya tidak benar? Pertanyaan-pertanyaan ini yang membuat review menjadi evaluasi genuine, bukan sekadar membaca lalu mengangguk.

3. Eksekusi

Setelah plan disetujui, agent baru mulai menulis kode sesuai rencana yang sudah divalidasi. Di titik ini, kecepatan AI benar-benar dipakai maksimal — karena arah sudah jelas dan sudah divalidasi, agent bisa bergerak cepat tanpa developer perlu mengawasi setiap keystroke.

Ini bagian yang sering disalahpahami sebagai “sama saja dengan vibe coding karena AI tetap yang menulis semua kode”. Bedanya terletak pada apa yang terjadi sebelum dan sesudah fase ini — eksekusi bukan titik keputusan, dia cuma pelaksanaan dari keputusan yang sudah diambil di checkpoint sebelumnya.

Analoginya mirip dengan tim engineering yang sudah matang: seorang senior engineer menyetujui design doc dari juniornya, lalu junior itu menulis kodenya sendiri tanpa perlu senior mengawasi setiap baris yang diketik. Kepercayaan itu valid justru karena arah sudah disepakati lebih dulu, bukan karena senior tidak peduli dengan detail implementasi. Eksekusi AI di flow ini berperan serupa — cepat karena arahnya sudah jelas, bukan cepat karena tidak ada yang mengawasi sama sekali.

4. Walkthrough

Setelah eksekusi selesai, Antigravity memberikan walkthrough — ringkasan apa yang sudah dilakukan, file mana yang berubah, dan bagaimana perubahan itu memenuhi plan yang disepakati. Walkthrough ini adalah representasi hasil, sama seperti plan adalah representasi niat.

Fungsinya menjembatani gap antara “apa yang direncanakan” dan “apa yang benar-benar terjadi”. Tanpa walkthrough, developer harus membaca ulang seluruh diff dari nol untuk tahu apa yang berubah — walkthrough memberi peta supaya review berikutnya bisa fokus dan efisien.

Melanjutkan contoh caching: walkthrough yang baik akan menyebutkan bahwa implementasi Redis sudah selesai di file tertentu, TTL sudah disesuaikan dengan angka yang disepakati setelah revisi, dan ada catatan bahwa satu edge case ditemukan selama eksekusi — misalnya request konkuren yang bisa menyebabkan cache stampede saat TTL habis bersamaan. Agent yang baik akan melaporkan temuan seperti ini secara eksplisit, bukan menyembunyikannya karena “di luar scope plan awal”. Walkthrough yang jujur soal penyimpangan dari plan justru menambah kepercayaan pada prosesnya, bukan mengurangi.

5. Review Walkthrough

Checkpoint kedua yang sama pentingnya dengan checkpoint pertama. Developer mencocokkan walkthrough dengan plan yang sudah disetujui — apakah eksekusi benar-benar sesuai rencana, atau ada penyimpangan yang perlu dipertanyakan? Apakah klaim AI (“test sudah pass”, “sudah menangani edge case X”) benar-benar diverifikasi, bukan cuma dipercaya?

Di titik ini, developer kembali mengambil peran sebagai verifier, bukan penerima pasif. Kalau ada yang janggal, developer bisa meminta revisi lagi — siklus ini bisa berulang sampai hasilnya benar-benar sesuai standar.

Untuk kasus cache stampede yang disebutkan di atas, review walkthrough adalah momen developer memutuskan apakah edge case itu cukup penting untuk ditangani sekarang, atau bisa dicatat sebagai technical debt yang disengaja untuk fitur berikutnya. Yang penting, ini adalah keputusan sadar yang diambil dengan informasi lengkap — bukan risiko yang tidak diketahui yang baru muncul saat production sudah menerima trafik nyata. Verifikasi juga tidak selalu berarti membaca ulang seluruh diff baris per baris; untuk perubahan yang berisiko rendah dan pola yang sudah familiar, cukup memastikan klaim di walkthrough konsisten dengan file yang disebutkan. Untuk perubahan yang menyentuh area kritis — autentikasi, pembayaran, atau data sensitif — verifikasi harus lebih dalam, termasuk menjalankan test secara manual, bukan sekadar percaya laporan bahwa “test sudah pass”.

Diagram Alur

Yang penting dipahami dari flow ini adalah bahwa dia bukan garis lurus satu arah. Di kedua checkpoint review, ada jalur revisi yang mengembalikan proses ke tahap sebelumnya.

flowchart TD
    A[Developer memberi task] --> B[Agent menyusun Implementation Plan]
    B --> C{Review Ketat oleh Developer}
    C -- Plan ditolak / revisi --> B
    C -- Plan disetujui --> D[Agent eksekusi kode]
    D --> E[Agent menyusun Walkthrough]
    E --> F{Review Walkthrough oleh Developer}
    F -- Tidak sesuai plan / ada penyimpangan --> D
    F -- Sesuai dan terverifikasi --> G[Kode diterima]

Dua gerbang keputusan ini — bukan satu — yang membedakan flow ini secara struktural dari alur vibe coding yang biasanya cuma: prompt, terima, jalankan, ulangi kalau error.

Kenapa Ini Bukan Vibe Coding

Argumen intinya bukan soal “pakai tool yang lebih canggih”, tapi soal di mana letak titik keputusan manusia dalam siklus kerja. Berikut kontrasnya secara eksplisit:

Perbedaan yang paling mendasar ada di baris pertama tabel ini: di mana letak titik keputusan. Vibe coding menempatkan satu-satunya titik evaluasi di ujung — kalau sempat, kalau ingat, kalau ada waktu. Flow ini menempatkan dua titik evaluasi wajib yang keduanya terjadi sebelum kode itu dianggap selesai, satu di level niat (plan) dan satu di level hasil (walkthrough).

Ini juga menjawab kritik yang sering dilontarkan ke pendekatan agentic secara umum — bahwa developer jadi “pengawas pasif” AI. Dengan dua checkpoint yang benar-benar dievaluasi, developer tetap menjadi pihak yang menentukan arah proyek. AI menangani throughput implementasi, tapi intelligence — dalam artian keputusan tentang apa yang benar dan apa yang tidak — tetap ada di tangan manusia.

Ini sebenarnya prinsip yang sama dengan yang mendasari spec-driven development: spesifikasi dan intent datang dari manusia, AI mengeksekusi sesuai spesifikasi itu, bukan menggantikannya. Bedanya, di spec-driven development spesifikasi itu biasanya ditulis sekali di awal dan relatif statis selama implementasi berjalan. Flow plan-review-eksekusi-walkthrough ini membawa prinsip yang sama tapi membuatnya berulang di level yang lebih granular — setiap task, betapapun kecilnya, punya siklus spesifikasi-dan-verifikasi sendiri. Ini penting karena spesifikasi tingkat tinggi di awal proyek jarang cukup detail untuk menangkap semua keputusan kecil yang muncul saat implementasi sebenarnya berjalan — plan per-task inilah yang mengisi celah itu.

Aspek ownership juga layak dibahas lebih dalam. Dalam vibe coding, ketika bug ditemukan, pertanyaan “kenapa kode ini seperti ini?” sering tidak punya jawaban yang jelas dari developer — jawabannya cuma “AI yang menulis begitu”. Ini bukan cuma masalah psikologis soal siapa yang disalahkan, tapi masalah praktis: kalau developer tidak bisa menjelaskan keputusan desain, dia juga tidak bisa memprediksi konsekuensi dari keputusan itu di bagian lain sistem. Dengan flow yang punya dua checkpoint eksplisit, developer punya jejak keputusan yang bisa ditelusuri — plan mana yang disetujui, alasan apa yang mendasarinya, dan penyimpangan apa yang muncul saat eksekusi. Jejak ini bukan sekadar dokumentasi administratif; ini adalah bukti bahwa keputusan itu benar-benar diambil, bukan disetujui secara pasif.

Kecepatan yang Tetap Terjaga

Kritik yang wajar muncul: kalau ada dua lapis review, bukankah ini jadi lambat, sama seperti code review manual yang berat?

Jawabannya ada pada apa yang direview, bukan berapa banyak yang direview. Review terhadap implementation plan jauh lebih ringan daripada review terhadap ribuan baris diff — plan biasanya berupa beberapa paragraf dan daftar langkah, bukan kode lengkap. Membaca dan mengevaluasi niat jauh lebih cepat daripada membaca dan mengevaluasi hasil jadi.

Review terhadap walkthrough juga lebih efisien dibanding membaca diff mentah dari nol, karena walkthrough sudah memberi peta — developer tahu file mana yang paling penting untuk dicek lebih dalam, dan mana yang cukup dipercaya karena polanya sudah familiar dan rendah risiko.

Yang dikorbankan bukan kecepatan implementasi — itu tetap didelegasikan penuh ke AI. Yang “dikorbankan” hanyalah beberapa menit tambahan di dua titik krusial, ditukar dengan kepastian bahwa arah dan hasilnya benar. Dibandingkan biaya debugging berjam-jam ketika kesalahan arsitektural baru ketahuan setelah fitur berikutnya dibangun di atasnya, ini pertukaran yang jelas menguntungkan.

Di Mana Flow Ini Masih Bisa Gagal

Struktur flow ini punya bentuk yang benar — dua checkpoint review yang eksplisit. Tapi bentuk yang benar tidak otomatis menjamin substansi yang benar. Flow ini bisa diam-diam berubah kembali jadi vibe coding kalau review di kedua checkpoint itu jadi superfisial — terlihat seperti evaluasi, tapi sebenarnya bukan.

Beberapa bentuk konkret dari review superfisial ini:

• Skim, bukan baca. Mata melewati teks plan atau walkthrough, tapi tidak benar-benar diproses terhadap pertanyaan “apakah ini sesuai prinsip yang saya pegang?” Yang terjadi lebih ke mencari kepastian visual bahwa “ada dokumennya”, bukan mengevaluasi isinya secara aktif.
• Approval by fatigue. Setelah beberapa kali plan AI terlihat masuk akal, developer mulai menyetujui lebih cepat dan makin jarang push back. Review yang tadinya kritis, lama-lama jadi formalitas — sebuah checklist yang dicentang, bukan keputusan yang benar-benar diambil.
• Tidak punya kriteria eksplisit. Kalau developer tidak tahu persis apa yang membuat sebuah plan itu “benar” — prinsip arsitektur atau trade-off yang dia pegang — maka reviewnya cuma jadi cek “apakah ini terdengar masuk akal”, bukan “apakah ini sesuai standar saya”. Plan yang ditulis dengan percaya diri tapi salah arah gampang lolos dari review semacam ini.
• Walkthrough dipercaya mentah-mentah. Kalau AI melaporkan “sudah diimplementasikan, test sudah pass, edge case sudah ditangani”, tapi developer tidak benar-benar memverifikasi klaim itu — tidak membaca diff, tidak menjalankan test sendiri — maka checkpoint kedua ini secara efektif kosong. Ini sama saja dengan trust blind terhadap output AI, hanya dibungkus dengan langkah tambahan yang terasa aman padahal tidak.

Titik kritisnya: proses dua-checkpoint ini punya bentuk yang anti-vibe-coding, tapi kalau reviewnya berubah jadi ritual dan bukan evaluasi genuine, substansinya tetap vibe coding — hanya dengan langkah ekstra yang memberi ilusi kontrol. Disiplin untuk benar-benar mengevaluasi, bukan sekadar melewati langkah-langkahnya, adalah bagian yang tidak bisa digantikan oleh tool secanggih apa pun.

Bagaimana Mencegahnya

Beberapa kebiasaan praktis membantu menjaga agar review ini tetap genuine, bukan sekadar formalitas:

• Tulis kriteria review secara eksplisit, bukan implisit. Kalau developer punya daftar prinsip arsitektur yang dipegang — misalnya “semua akses database harus lewat repository layer, tidak ada raw query di controller” — kriteria ini sebaiknya benar-benar dituliskan, bukan cuma diingat secara samar di kepala. Kriteria yang eksplisit lebih mudah dijadikan checklist nyata saat membaca plan, dibanding kriteria yang cuma jadi perasaan “kayaknya kurang pas”.
• Perlakukan plan yang “terlihat rapi” dengan kecurigaan yang sama seperti plan yang berantakan. Justru plan yang ditulis dengan percaya diri dan terstruktur rapi yang paling mudah lolos dari review superfisial, karena secara visual sudah terlihat meyakinkan. Kerapian penulisan tidak berkorelasi dengan kebenaran pendekatan.
• Verifikasi sebagian klaim di walkthrough secara acak, bukan seluruhnya, tapi juga bukan tidak sama sekali. Untuk task berisiko rendah, memeriksa sebagian kecil dari klaim yang dilaporkan — apakah file yang disebut benar-benar berubah sesuai deskripsi — sudah cukup untuk mendeteksi pola walkthrough yang tidak akurat sebelum jadi kebiasaan yang dipercaya buta.
• Sadari kapan fatigue mulai muncul. Kalau developer merasa mulai menyetujui plan lebih cepat dari biasanya tanpa alasan yang jelas, itu sinyal untuk berhenti sejenak, bukan tanda bahwa AI-nya semakin bisa dipercaya.

Ringkasan

• Vibe coding bukan soal “pakai AI”, tapi soal hilangnya kontrol dan pemahaman manusia terhadap kode yang dibangun.
• Flow Antigravity — plan, review, eksekusi, walkthrough, review walkthrough — menempatkan dua titik keputusan wajib sebelum kode dianggap selesai.
• Review terhadap plan mengoreksi kesalahan arah di titik paling murah, sebelum kode ditulis.
• Review terhadap walkthrough memverifikasi hasil, bukan menerimanya mentah-mentah.
• Kecepatan AI tetap didelegasikan penuh untuk eksekusi — yang berubah hanyalah di mana developer menaruh perhatiannya.
• Bentuk dua-checkpoint ini bisa gagal kalau reviewnya jadi superfisial — skim tanpa evaluasi, approval by fatigue, atau walkthrough yang dipercaya tanpa verifikasi.
• Yang membedakan flow ini dari vibe coding bukan tool-nya, tapi disiplin manusia untuk benar-benar mengevaluasi di setiap checkpoint yang tersedia.