Berhenti Melawan LLM: Prinsip Software Engineering untuk Coding Agentic
TL;DR: Coding dibantu AI yang efektif membutuhkan transisi dari sekadar “vibe coding” ke penerapan prinsip engineering inti: task sizing yang cerdas, kontrol konteks aktif, dan perencanaan sistematis. Dengan memperlakukan LLM sebagai agen kolaboratif dengan batasan tertentu, developer dapat menjaga kualitas codebase dan menghindari jebakan “mega-prompt”.
Kita semua pernah melihat demo “vibe coding”: seorang developer meminta LLM untuk “buatkan tiruan Twitter,” dan beberapa menit kemudian, muncul sebuah aplikasi yang penuh bug dan sulit dipelihara. Ini memang terlihat mengesankan selama lima menit, tapi akan hancur saat Anda perlu mengubah skema database atau memperbaiki race condition yang halus.
Realitas di tahun 2026 adalah agen AI seperti Antigravity, Claude Code, dan GitHub Copilot sudah menjadi alat standar. Namun, jika Anda memperlakukannya seperti tongkat sihir, Anda akan menabrak “tembok bata stokastik.” Untuk benar-benar merilis software produksi dengan AI, Anda harus berhenti sekadar “ngobrol” dan mulai melakukan engineering.
Apa Itu AI Stack Engineering?
AI Stack Engineering adalah praktik menerapkan batasan software engineering tradisional—seperti modularitas, perencanaan, dan manajemen state—ke dalam interaksi antara developer manusia dan agen coding AI.
Ini adalah jalan tengah antara “coding manual” dan “kotak hitam otonom penuh.” Anda tidak hanya menulis kode; Anda mengelola aliran informasi dan dekomposisi tugas untuk sebuah agen yang sangat ahli dalam sintaksis, tetapi cenderung kehilangan arah jika konteksnya terlalu berat.
Task Sizing: Akhir dari Era Mega-Prompt
Kesalahan terbesar developer saat menggunakan LLM adalah meminta terlalu banyak hal sekaligus. Kami menyebutnya “Jebakan Mega-Prompt.” Saat Anda meminta LLM untuk “Refactor seluruh sistem auth dan tambahkan dashboard baru,” Anda praktis sedang mengundang halusinasi.
Dalam istilah engineering, ini adalah pelanggaran terhadap Prinsip Tanggung Jawab Tunggal (Single Responsibility Principle).
Solusinya: Tugas Kecil dan Atomik. Pecah kebutuhan Anda menjadi potongan-potongan kecil yang sesuai dengan jendela penalaran optimal sang agen. Jika sebuah tugas membutuhkan lebih dari 50 baris kode untuk dijelaskan, kemungkinan besar itu terlalu besar.
- Salah: “Implementasikan seluruh alur penagihan (billing flow).”
- Benar: “1. Buat skema customer Stripe. 2. Implementasikan handler webhook untuk pembayaran sukses. 3. Update UI profil user untuk menampilkan lencana ‘Premium’.”
Kontrol Konteks: Mengelola “Working Memory” Agen
Sebuah LLM hanya sebagus konteks yang dipegangnya saat ini. Jika Anda memasukkan 50 file yang tidak dibutuhkannya, Anda hanya menambah “noise” yang mengaburkan perhatiannya. Sebaliknya, jika Anda tidak memberikan file schema.ts saat ia menulis query database, ia akan berhalusinasi tentang nama-nama field.
Solusinya: Pemilihan File Strategis. Anda harus menjadi kurator konteks bagi sang agen.
- Gunakan tool seperti
view_filehanya pada file yang relevan. - Bersihkan konteks lama di antara tugas-tugas besar.
- Berikan “Anchor Files” (seperti
DESIGN.mdatauARCHITECTURE.md) yang memberikan peta tingkat tinggi tentang sistem tanpa membebaninya dengan detail implementasi.
Perencanaan Sistematis: Mengapa Konsep Desain Itu Penting
Kebanyakan kegagalan AI terjadi karena agen mulai menulis kode sebelum ia benar-benar memahami niat (intent) Anda.
Solusinya: Alur Kerja “Plan First” (Rencana Dulu). Sebelum agen menyentuh satu pun file .ts, paksa ia untuk menghasilkan rencana implementasi (implementation plan). Ini berfungsi untuk dua hal:
- Verifikasi: Anda dapat menangkap kesalahan desain sebelum agen menulis 500 baris kode yang buruk.
- Penyelarasan: Ini memastikan agen telah “memikirkan” dependensi yang ada (misalnya, “Saya perlu memperbarui API sebelum memperbarui frontend”).
Jika agen Anda tidak mengeluarkan daftar TODO sebelum mulai mengetik, Anda hanya sedang melakukan vibe-coding.
Perbandingan: Vibe Coding vs. Engineering-Driven AI
| Fitur | Vibe Coding | Engineering-Driven AI |
|---|---|---|
| Input | Permintaan besar dan samar (“Buat agar jalan”) | Tugas atomik dan spesifik (“Update X untuk melakukan Y”) |
| Konteks | Semuanya atau tidak sama sekali | Hanya file yang relevan dan terkurasi |
| Perencanaan | Implementasi langsung | Rencana Implementasi -> Review -> Daftar Tugas |
| Hasil | “Terlihat oke” (Rapuh) | Secara teknis solid, terdokumentasi, dan dapat diuji |
FAQ: Menguasai Alur Kerja Agentic
Q: Apakah ini berarti saya harus bekerja lebih keras? A: Awalnya, ya. Perencanaan memakan waktu. Tapi ini menghemat berjam-jam waktu debugging “bug halusinasi” yang muncul dari prompt yang terlalu besar dan konteks yang berantakan.
Q: Bukankah AI bisa membuat rencana sendiri? A: Ia bisa membuat draf, tetapi Anda harus meninjaunya. Anda adalah Arsiteknya; AI adalah Senior Engineer-nya. Jangan pernah melewatkan peninjauan Arsitek.
Q: Berapa “Ukuran Tugas” terbaik untuk LLM? A: Targetkan tugas yang bisa diselesaikan dalam 5-15 menit waktu coding manusia. Jika Anda tidak bisa menjelaskan tugas tersebut dalam 3 kalimat, pecahlah.
Q: Bagaimana cara mengelola konteks untuk repo yang besar? A: Gunakan file map.md atau agents.md yang menjelaskan struktur direktori dan poin-poin logika utama. Arahkan agen ke file ini terlebih dahulu.
Q: Mengapa AI saya terus mengulangi kesalahan yang sama? A: Ini biasanya masalah polusi konteks. Kesalahan tersebut ada dalam “history” (riwayat). Bersihkan sesi atau koreksi agen secara eksplisit dan minta ia memperbarui rencana internalnya.
Berhenti mengobrol, mulai merilis. #AIEngineering #SoftwareEngineering #AgenticWorkflow #MattPocock #Antigravity