AI coding agent paling terasa berguna bukan saat lu kosong ide, tapi saat lu punya konteks yang jelas. Contoh paling menarik minggu ini datang dari Terence Tao: ia memakai coding agent modern untuk menghidupkan lagi applet matematika lama dan membuat visualisasi baru yang dulu terlalu mahal dicoba secara waktu.
Artikel ini ngebahas pelajaran praktis dari cerita itu buat developer dan builder: AI agent bukan pengganti skill, melainkan pengungkit buat orang yang sudah punya arah, taste, dan batas risiko. Kalau lu pakai AI cuma buat “bikin sesuatu yang keren”, hasilnya gampang melebar. Tapi kalau lu datang dengan problem spesifik, contoh output, dan definisi risiko, AI bisa nurunin biaya eksperimen secara nyata.
Apa yang sebenarnya dilakukan Terence Tao?
Terence Tao menulis di blognya bahwa sejak 1999 ia tertarik memakai komputer untuk membantu mengajar dan mengeksplorasi matematika. Dulu ia membuat beberapa applet Java untuk materi complex analysis, linear algebra, dan visualisasi objek matematika. Masalahnya, applet seperti itu memakan waktu untuk dibuat, lalu makin lama makin sulit dipertahankan karena standar web berubah.
Dengan coding agent modern, Tao mulai mem-porting applet lama ke format web yang lebih modern. Ia juga mencoba membuat app baru, termasuk visualisasi special relativity yang sudah ia bayangkan sejak lama. Bagian yang paling penting: ia tidak memosisikan AI sebagai pembukti matematika formal. Ia memakainya untuk visualisasi edukatif dan eksplorasi ide, area yang risikonya relatif rendah kalau dibandingkan sistem produksi atau bukti formal.
Di titik ini, pelajarannya bukan “AI sekarang bisa menggantikan ahli matematika”. Menurut gua, pelajaran yang lebih waras adalah: expert bisa memakai AI untuk menurunkan biaya membuat artefak pendukung. Skill manusia tetap menentukan problem mana yang layak dibuat, output mana yang masuk akal, dan bug mana yang masih bisa diterima.
Definisi singkat: coding agent itu apa?
Coding agent adalah tool AI yang bukan cuma menjawab chat, tapi bisa membaca file, mengedit kode, menjalankan command, dan membantu menyelesaikan task di codebase. Contohnya termasuk Claude Code, Codex-style agent, Copilot agent mode, dan tool sejenis yang bekerja di terminal atau editor.
Bedanya dengan autocomplete biasa: coding agent bisa melakukan rangkaian kerja. Ia bisa mencari file relevan, mengubah beberapa bagian, menjalankan test, lalu mencoba memperbaiki error. Karena itu, ia lebih kuat, tapi juga lebih berisiko. Kalau instruksi dan boundary-nya kabur, agent bisa membuat perubahan yang terlihat produktif tapi susah direview.
Kenapa konteks lebih penting daripada prompt panjang?
Banyak orang mengira masalah utama AI coding adalah prompt kurang panjang. Padahal seringnya masalahnya bukan panjang prompt, tapi minim konteks kerja. Prompt panjang tanpa arah tetap bisa menghasilkan solusi generik.
Dalam kasus Tao, konteksnya kuat:
- Ia tahu konsep matematika yang ingin divisualisasikan.
- Ia punya applet lama sebagai referensi fungsi dan bentuk output.
- Ia tahu targetnya edukatif, bukan sistem kritikal.
- Ia bisa menilai apakah visualisasi yang muncul masuk akal atau menyesatkan.
Ini beda jauh dari prompt seperti “buatkan app matematika yang bagus”. Agent butuh pegangan. Semakin jelas contoh, constraint, dan definisi selesai, semakin kecil kemungkinan AI ngarang struktur yang terlihat rapi tapi tidak menjawab problem.
Risk boundary: kapan vibe coding masuk akal?
Istilah vibe coding sering dipakai buat menggambarkan workflow saat developer membiarkan AI menulis banyak kode berdasarkan arahan natural language. Buat gua, vibe coding tidak otomatis buruk. Yang bahaya adalah vibe coding tanpa risk boundary.
Risk boundary adalah batas jelas tentang seberapa besar kerusakan yang bisa terjadi kalau output AI salah. Untuk prototype visual, demo internal, app edukasi, script sekali pakai, atau eksplorasi UI, risiko biasanya lebih mudah dikendalikan. Kalau ada bug, lu bisa review manual, buang hasilnya, atau pakai sebagai bahan belajar.
Tapi untuk auth, payment, migrasi database, security-sensitive code, data user, dan infrastruktur produksi, standar review harus jauh lebih ketat. Di area itu, AI boleh membantu, tapi tidak boleh jadi satu-satunya pihak yang “memutuskan” bahwa perubahan aman.
Checklist sebelum kasih task ke AI coding agent
Kalau lu mau memakai AI coding agent dengan lebih waras, mulai dari checklist sederhana ini:
- Tulis output yang diharapkan. Jangan cuma “fix bug”. Jelaskan perilaku sebelum dan sesudah.
- Kasih file atau area kerja yang relevan. Batasi scope supaya agent tidak keliling repo tanpa arah.
- Tentukan risk level. Prototype, internal tool, atau production-critical?
- Minta perubahan kecil dulu. Diff kecil lebih gampang direview daripada rewrite besar.
- Wajib ada verifikasi. Test, screenshot, command output, atau checklist manual.
- Review jejak kerja, bukan cuma summary. Summary AI bisa manis. Diff dan hasil test lebih jujur.
Checklist ini terdengar sederhana, tapi sering dilupakan karena AI terasa cepat. Padahal kecepatan tanpa review cuma memindahkan biaya ke masa depan.
Apa yang bisa dipelajari developer pemula?
Buat developer pemula, cerita Terence Tao bisa disalahbaca. Jangan sampai kesimpulannya jadi “skill teknis tidak penting lagi”. Justru sebaliknya: semakin banyak AI menulis kode, semakin mahal kemampuan untuk mengevaluasi hasilnya.
Lu tidak harus jadi expert dunia untuk dapat manfaat dari AI agent. Tapi lu tetap perlu membangun mental model: struktur project, cara membaca error, dasar testing, security basic, dan rasa terhadap kode yang mudah dirawat. Tanpa itu, AI bisa terasa seperti senior yang membantu, padahal lu belum punya alat untuk membedakan bantuan yang benar dan bantuan yang menambah utang teknis.
Apa yang bisa dipelajari creator dan builder?
Angle ini juga relevan buat creator tech. AI membuat biaya eksperimen turun. Lu bisa lebih cepat bikin demo, visual, prototype, script, atau draft konten. Tapi pembeda utamanya tetap taste: ide mana yang layak dicoba, mana yang harus dipotong, dan mana yang belum pantas dipublish.
Di rafli.dev, gua melihat AI paling berguna saat dipakai sebagai multiplier workflow: bantu riset, bantu draft, bantu bikin struktur carousel, bantu cek variasi angle. Tapi keputusan akhir tetap harus datang dari pengalaman nyata sebagai builder. Kalau tidak, output gampang berubah jadi generik: terlihat rapi, tapi tidak punya sudut pandang.
Takeaway praktis
- AI coding agent paling efektif saat lu punya konteks, contoh, dan constraint.
- Vibe coding masuk akal untuk eksplorasi low-risk, bukan untuk semua area produksi.
- Expert judgment tetap penting karena AI bisa menghasilkan output yang tampak benar.
- Developer perlu review diff, test, dan boundary risiko, bukan cuma percaya summary AI.
- Untuk personal branding tech, cerita seperti ini bagus karena menunjukkan cara pakai AI tanpa hype berlebihan.
FAQ singkat
Apakah ini berarti AI bisa menggantikan programmer?
Tidak. Contoh ini lebih tepat dibaca sebagai AI yang menurunkan biaya eksperimen untuk orang yang punya konteks kuat. Skill review, desain sistem, dan judgment tetap penting.
Apakah vibe coding selalu buruk?
Tidak selalu. Vibe coding bisa berguna untuk prototype, visualisasi, dan eksplorasi. Masalahnya muncul saat workflow itu dipakai di area high-risk tanpa test, review, dan batas akses.
Apa langkah pertama yang bisa lu coba hari ini?
Ambil satu task kecil di project sampingan, tulis definisi selesai dalam 5 bullet, batasi file yang boleh disentuh agent, lalu review diff-nya pelan-pelan. Jangan mulai dari rewrite besar.
Penutup
Menurut gua, cerita Terence Tao menarik bukan karena “AI bisa ngoding”. Kita sudah dengar klaim itu terlalu sering. Yang menarik adalah cara pakainya: problem jelas, konteks kuat, risiko dibatasi, dan manusia tetap memegang taste.
Kalau lu developer, creator, atau builder, ini cara baca yang lebih sehat: jangan jadikan AI sebagai pengganti arah berpikir. Jadikan dia alat untuk mempercepat eksperimen yang sudah lu desain dengan sadar. Simpan checklist-nya, lalu coba di task kecil sebelum mempercayakannya ke workflow yang lebih besar.
