Kenapa Ya AI Sekarang Tuh Selain Mahal, Juga Pelit Token? Benarkah Demikian? Sebuah POV Dari Engineer

05 Jul, 2026

Sebuah Fenomena yang Saya Amati Akhir-akhir Ini

Beberapa minggu terakhir, saya cukup sering mendengar pertanyaan yang hampir serupa. Terutama dari teman-teman yang mulai merambah dunia automation, trading bot, atau bahkan membangun AI agent di ekosistem Web3.

"Bang, saya sudah langganan AI Pro, tapi kok rasanya token cepat sekali habis, ya? Padahal saya lihat orang lain bikin agent tiap hari, revisi berkali-kali, tokennya masih sisa banyak."

Awalnya, saya pikir jawabannya sederhana.

• Mungkin mereka pakai model yang berbeda.
• Mungkin mereka berlangganan paket yang lebih mahal.
• Atau mungkin mereka memang rela merogoh kocek lebih dalam demi produktivitas.

Namun setelah sekian lama mengamati cara kerja para engineer—baik yang membangun trading infrastructure, bot, hingga AI agent—saya mulai menyadari satu pola yang menarik.

Mereka semua memiliki satu kebiasaan yang sama.

Mereka tidak banyak berbicara dengan AI.

Kedengarannya kontradiktif, bukan?

Bukankah AI dibuat agar kita bisa ngobrol panjang lebar dengannya?

Benar. Tapi justru di situlah letak perbedaannya.

Vibe Coding: Revolusi yang Saya Dukung Sepenuhnya

Saya ingin meluruskan satu hal sejak awal.

Saya bukan orang yang menganggap vibe coding sebagai musuh. Justru sebaliknya—saya melihat ini sebagai salah satu revolusi terbesar dalam dunia software development.

Bayangkan: lima tahun lalu, jika seseorang ingin membuat trading bot di Solana tanpa pernah belajar Rust atau JavaScript, kemungkinan besar jawabannya hanya satu:

"Belajar dulu satu atau dua tahun."

Hari ini? Seseorang bisa memulai di hari yang sama.

• Membuat dashboard.
• Menyambungkan RPC.
• Mengambil data on-chain.
• Membuat alert Telegram.
• Bahkan menjalankan agent sederhana.

Semua itu hanya dengan berdiskusi bersama AI.

Kalau dipikir-pikir, ini benar-benar luar biasa. AI telah menghilangkan salah satu hambatan terbesar dalam dunia teknologi. Lebih banyak orang akhirnya berani membangun. Dan saya pribadi menganggap ini sebagai perkembangan yang sangat positif.

Ilusi Terbesar di Era AI

Setiap teknologi baru selalu membawa ilusi baru. Dan ilusi terbesar dari AI adalah membuat kita percaya bahwa ia bisa menggantikan proses berpikir.

Padahal, jika kita mau jujur, AI hanya mampu mempercepat proses berpikir yang sudah ada. Ia tidak pernah menciptakan pola pikir baru—ia hanya menjalankan dan mengoptimalkan apa yang sudah kita berikan.

Pola yang Saya Temukan dari Para Engineer Senior

Ada momen menarik ketika saya mulai memperhatikan bagaimana para engineer yang sudah lama berkecimpung di dunia software menggunakan AI.

Saya awalnya mengira mereka akan membuka ChatGPT setiap lima menit. Bertanya ini-itu. Ternyata, kenyataannya justru sebaliknya.

Mereka membuka AI, memberikan instruksi yang sangat spesifik, menerima hasilnya, lalu kembali bekerja. Percakapannya pendek. Kadang hanya beberapa kali balasan.

Saya sempat bertanya-tanya,

"Kenapa singkat banget?"

Jawabannya sederhana:

Karena sebagian besar pekerjaan sudah selesai sebelum prompt pertama dikirim.

Mereka sudah tahu:

• Sistem apa yang ingin dibuat.
• Bagaimana data mengalir.
• Modul apa saja yang dibutuhkan.
• Bagian mana yang berpotensi gagal.

AI hanya membantu menerjemahkan semua itu menjadi kode—bukan mengambil keputusan.

Dan di sinilah, menurut saya, banyak orang salah memahami fungsi AI.

AI sebagai Programmer vs AI sebagai Rekan Kerja

Perbedaannya tipis, tapi dampaknya besar.

Bayangkan dua orang yang sama-sama ingin membuat AI agent untuk memonitor pool baru di Solana.

Orang pertama membuka AI dan berkata:

"Buat service Rust yang subscribe ke websocket, filter event pool baru, simpan ke SQLite, expose API, dan tambahkan retry mechanism."

Selesai. Instruksinya jelas. Ruang interpretasi AI sangat kecil.

Orang kedua membuka AI dan berkata:

"Aku ingin bikin AI agent."

Lalu percakapan berkembang ke mana-mana:

• Framework apa yang bagus?
• Database apa yang cocok?
• Kenapa muncul error ini?
• Kalau pakai yang lain gimana?
• Struktur foldernya kayak apa?

Tanpa sadar, AI bukan lagi diminta membantu implementasi—ia diminta mengambil hampir semua keputusan.

Semakin banyak keputusan yang harus diambil AI, semakin panjang percakapannya. Semakin panjang percakapan, semakin banyak konteks yang harus diproses. Dan tentu saja…

Semakin banyak token yang digunakan.

Perbandingan Biaya Token: Studi Kasus

Mari kita lihat data sederhana berdasarkan simulasi penggunaan model GPT-4o (biaya ±$5 per 1M input token).

Perbedaan biaya mencapai 5–7x lipat per bulan. Dalam setahun, itu artinya selisih $360–$432 hanya dari kebiasaan penggunaan.

Dan yang menarik: hasil yang didapat tidak selalu lebih baik.

Masalah Terbesar Bukan pada Coding

Saya rasa kesalahan terbesar bukan karena seseorang belum bisa menulis syntax. Syntax hari ini bisa ditulis AI dengan sangat baik. Masalah sebenarnya terjadi ketika seseorang belum memiliki gambaran jelas tentang sistem yang sedang ia bangun.

Misalnya: ingin membuat trading agent.

Pertanyaan pertama yang lebih penting bukanlah:

"Framework apa yang bagus?"

Melainkan:

• Bagaimana data masuk?
• Setelah data masuk, bagaimana data diproses?
• Kapan agent mengambil keputusan?
• Bagaimana cara executor bekerja?
• Bagaimana jika RPC mati?
• Bagaimana jika transaksi gagal?

Semua pertanyaan di atas bukan pertanyaan coding. Itu adalah pertanyaan desain.

Dan bagian desain inilah—menariknya—yang paling menentukan efisiensi penggunaan AI.

Error Tidak Pernah Mahal

Yang mahal adalah ketika kita tidak tahu ke mana harus melihat.

Saya sering melihat seseorang mengirimkan ratusan baris log ke AI. Padahal masalahnya hanya satu. Sementara itu, para engineer senior biasanya hanya membaca beberapa baris pertama—dan mereka sudah bisa menebak sumber masalahnya.

Bukan karena mereka lebih pintar. Tetapi karena mereka sudah mengenali polanya.

Pengalaman membuat mereka tahu di mana harus mencari, bukan apa yang harus dicari.

Perbedaan ini penting, karena:

AI tidak pernah keberatan membaca seribu baris log, tapi setiap kali ia membaca ulang konteks yang tidak diperlukan, kita membayar dengan token. Sedikit demi sedikit, tanpa terasa.

Prompt Engineering vs Thinking Engineering

Ini mungkin bagian yang paling menarik.

Banyak orang mengira kemampuan menggunakan AI ditentukan oleh kemampuan membuat prompt. Saya justru mulai percaya sebaliknya.

Prompt yang baik lahir dari desain sistem yang baik. Bukan sebaliknya.

Semakin jelas arsitektur di kepala kita, semakin pendek prompt yang dibutuhkan. Semakin pendek prompt, semakin sedikit AI harus menebak. Dan semakin sedikit AI menebak, semakin baik hasil yang diberikan.

Jadi mungkin masalahnya bukan pada prompt engineering.

Melainkan pada thinking engineering.

Perbandingan Pendekatan: Pemula vs Engineer Senior

Contoh Konkret: Membangun Monitor Pool Baru di Solana

Pendekatan 1 (Vibe Coding, Biaya Tinggi)

1. "Aku mau bikin monitor pool baru di Solana, gimana caranya?"
2. "Oh pake framework apa?"
3. "Terus database-nya pake apa?"
4. "Ini errornya kenapa ya?" (kirim 200 baris log)
5. "Coba jelasin lagi dong arsitekturnya?"
6. Token terpakai: ~15.000–20.000 per sesi

Pendekatan 2 (Engineer Senior, Efisien)

1. "Buat service Rust dengan tokio-tungstenite untuk subscribe ke program ID X, filter event pool_created, simpan ke SQLite dengan skema ini, dan tambahkan retry mechanism dengan exponential backoff."
2. Token terpakai: ~3.000–5.000 per sesi

Hasilnya sama. Biayanya berbeda 4x lipat.

Arsitektur Pola Pikir: Cara Engineer Senior Bekerja

┌─────────────────────────────────────────────────────────────┐
│                    SEBELUM PROMPT                          │
│  ┌────────────┐  ┌──────────────┐  ┌───────────────────┐  │
│  │  Tujuan     │  │  Modul       │  │  Potensi          │  │
│  │  Sistem     │→ │  Breakdown   │→ │  Failure Point    │  │
│  └────────────┘  └──────────────┘  └───────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                    SAAT PROMPT                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Instruksi Spesifik + Konteks Relevan               │   │
│  │  (tanpa eksplorasi berlebihan)                      │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                    SETELAH PROMPT                          │
│  ┌────────────┐  ┌──────────────┐  ┌───────────────────┐  │
│  │  Review    │  │  Testing     │  │  Iterasi          │  │
│  │  & Filter  │→ │  Terarah     │→ │  Minimal          │  │
│  └────────────┘  └──────────────┘  └───────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Definisi "Jago Coding" Mulai Berubah

Dulu, kita menganggap programmer hebat adalah orang yang mampu menghafal syntax. Hari ini? AI bisa menulis syntax lebih cepat daripada siapa pun.

Maka, nilai seorang builder mulai bergeser:

• Bukan lagi tentang siapa yang paling cepat mengetik.
• Melainkan siapa yang paling cepat memahami masalah.
• Siapa yang mampu menyusun sistem yang rapi.
• Siapa yang tahu informasi mana yang penting dan mana yang hanya menjadi gangguan.

Kemampuan-kemampuan itu justru akan menjadi semakin berharga di era AI.

Tips Praktis: Bagaimana Menggunakan AI Secara Efisien

1. Tulis dulu di kertas — Ya, kertas. Buat diagram alur data sebelum membuka AI.
2. Gunakan prompt yang terstruktur — Format: "Buat [fungsi] dengan [spesifikasi teknis]. Gunakan [library X]. Output yang diharapkan: [Y]."
3. Batch pertanyaan Anda — Daripada bertanya 10 kali, kumpulkan semua pertanyaan dalam satu prompt.
4. Jangan kirim seluruh log error — Cukup kirim 5–10 baris pertama dan terakhir.
5. Gunakan sistem — Jangan mulai dari nol setiap sesi. Buat template prompt untuk tugas yang berulang.

Penutup: Berpikir Sebelum Meminta AI Menulis

Saya tidak percaya bahwa masa depan software akan dipenuhi oleh orang-orang yang tidak perlu belajar apa pun. Saya juga tidak percaya bahwa semua orang harus menjadi software engineer profesional.

Yang saya percaya justru berada di tengah.

AI membuat proses membangun menjadi jauh lebih mudah. Tapi pemahaman tetap menjadi pembeda.

Karena pada akhirnya, AI hanyalah sebuah mesin yang sangat pandai menjawab. Ia tetap membutuhkan seseorang yang mampu mengajukan pertanyaan yang tepat.

Dan mungkin, itulah keterampilan yang paling mahal di era ketika hampir semua orang bisa menghasilkan ribuan baris kode hanya dalam hitungan menit.

Bukan kemampuan menulis program.

Melainkan kemampuan berpikir sebelum meminta AI menuliskan program tersebut.

"Kemampuan terbesar di era AI bukanlah seberapa cepat kamu mengetik prompt, tapi seberapa jernih kamu berpikir sebelum mengetiknya."

Semoga bermanfaat. Tetap bangun, tetap berpikir, dan gunakan AI dengan bijak.