Cara Jitu Keluar dari "Dumb Zone" AI agar Produktivitas Coding Tetap Konsisten dan Akurat

Pernahkah Anda merasa bahwa di awal percakapan, AI tampak sangat jenius, namun setelah diskusi panjang, ia mulai memberikan saran yang tidak masuk akal? Rasanya seperti bekerja dengan rekan setim yang perlahan-lahan kehilangan fokus hingga akhirnya melakukan kesalahan-kesalahan konyol.

Banyak orang menganggap AI sebagai paradigma baru yang akan menghapus cara lama kita bekerja. Namun, realitanya justru sebaliknya: di era AI ini, fundamental software engineering—hal-hal yang kita pelajari untuk bekerja secara efektif dengan manusia—menjadi jauh lebih krusial. Masalahnya bukan pada kecerdasan AI itu sendiri, melainkan pada cara kita mengelola konteks dan instruksi. Untuk benar-benar menguasai AI coding, kita harus kembali ke dasar-dasar rekayasa perangkat lunak yang pragmatis.

1. Memahami "Smart Zone" vs. "Dumb Zone": Batas Kritis 100k Token

Dex Hy dari Human Layer memperkenalkan konsep yang sangat relevan: LLM memiliki "Smart Zone" dan "Dumb Zone". Saat Anda memulai percakapan baru, perhatian AI masih tajam. Namun, seiring bertambahnya token, performanya akan menurun secara signifikan.

Mengapa ini terjadi? Ini masalah quadratic scaling pada beban atensi. Bayangkan sebuah liga sepak bola; setiap kali Anda menambah satu tim baru ke dalam liga, jumlah pertandingan yang harus dikelola melonjak drastis karena setiap tim harus bertemu dengan tim lainnya. Hal yang sama terjadi pada token di dalam jendela konteks (context window). Hubungan atensi antar setiap token membuat beban kerja AI meningkat secara eksponensial.

Batas kritisnya biasanya berada di sekitar 100k token. Tidak peduli apakah Anda menggunakan model dengan context window 1 juta atau 200k token, AI akan mulai bertingkah "bodoh" setelah melewati batas tersebut karena perhatiannya terlalu tersebar. Kuncinya sederhana: jangan biarkan AI kewalahan dengan scope yang terlalu lebar. Jaga agar tugas-tugas tetap kecil dan spesifik agar Anda tetap berada di dalam "Smart Zone".

2. Berhenti Sekadar Memberi Spesifikasi, Mulailah Teknik "Grill Me"

Ada tren yang disebut "Specs to Code" atau Vibe Coding, di mana pengembang memberikan dokumen spesifikasi dan berharap AI langsung menghasilkan aplikasi utuh. Percayalah, ini sering kali berakhir berantakan. Anda akan kehilangan kendali atas kode dan tidak benar-benar memahami apa yang sedang dibangun.

Alih-alih memberikan instruksi satu arah, coba gunakan teknik "Grill Me". Frederick P. Brooks dalam bukunya The Design of Design menekankan pentingnya Shared Design Concept—sebuah pemahaman desain bersama yang harus dimiliki oleh semua pihak yang terlibat dalam proyek. Teknik ini memaksa AI untuk berada di gelombang yang sama dengan Anda melalui beberapa tahap:

• Wawancara Relentless: Perintahkan AI untuk mewawancarai Anda secara agresif tentang setiap detail rencana sebelum satu baris kode pun ditulis.
• Rekomendasi Balik: AI tidak hanya bertanya, tapi juga memberikan rekomendasi jawaban untuk Anda validasi guna menyempurnakan design tree.
• Resolusi Dependensi: Proses ini memastikan semua asumsi divalidasi di awal, mencegah misalignment yang membuang-buang token dan waktu.

3. Mengapa Arsitektur "Deep Modules" adalah Sahabat Terbaik AI

Struktur kode Anda menentukan seberapa baik AI dapat bekerja. Mengacu pada John Ousterhout dalam The Philosophy of Software Design, kita harus berusaha membangun Deep Modules daripada Shallow Modules.

• Shallow Modules (Musuh AI): Struktur dengan banyak file kecil yang memiliki ketergantungan rumit. AI kesulitan menavigasi grafik dependensi yang luas dan sering bingung saat harus melacak logika di banyak tempat.
• Deep Modules (Sahabat AI): Modul yang memiliki antarmuka (interface) sederhana di luar, namun menyimpan banyak fungsionalitas di dalamnya.

Ingat, bad codebases make bad agents. AI bekerja jauh lebih efektif dengan modul yang besar dan mandiri karena batasan pengujiannya menjadi lebih jelas. Sebagai engineer, tugas Anda adalah mendesain interface yang kuat dan mendelegasikan implementasi "isi" modul tersebut kepada AI.

4. Memberi "Penglihatan" pada AI melalui TDD dan "Ralph Loop"

AI sering kali "buta" jika hanya diminta menulis kode tanpa menjalankannya. Inilah mengapa Test-Driven Development (TDD) menjadi sangat krusial bagi agen AI. Melalui siklus Red-Green-Refactor, kita memberikan AI umpan balik instan. Tanpa tes, AI cenderung "curang" atau membuat kode yang tampak benar tetapi gagal saat dijalankan.

Di sinilah konsep Ralph Loop bermain. Anda tidak perlu memberikan rencana langkah-demi-langkah yang kaku. Cukup tentukan tujuan akhirnya (misalnya melalui PRD), lalu biarkan AI melakukan perubahan-perubahan kecil yang terus-menerus mendekatkan kode ke tujuan tersebut, divalidasi oleh tes di setiap langkahnya.

5. Gunakan Strategi "Vertical Slices" dan "Tracer Bullets"

AI memiliki bias alami untuk menulis kode secara horizontal: membuat skema database dulu, lalu API, baru kemudian UI. Masalahnya, Anda tidak akan tahu apakah sistem tersebut benar-benar bekerja sampai lapisan terakhir selesai.

Gunakan teknik Vertical Slices atau Tracer Bullets dari buku The Pragmatic Programmer. Bangunlah fitur yang memotong semua lapisan sistem sekaligus (dari DB hingga UI) dalam satu potongan fungsionalitas tipis. Dengan cara ini, AI mendapatkan feedback instan apakah integrasi antar lapisan berjalan lancar dan mencegahnya tersesat dalam fase perencanaan yang terlalu panjang.

Kesimpulan: Masa Depan Engineer yang Memiliki "Taste"

Masa depan pengembangan perangkat lunak akan terbagi menjadi dua peran: Day Shift (Manusia) yang melakukan perencanaan, desain arsitektur, dan menjaga standar kualitas, serta Night Shift (Agen AI) yang melakukan implementasi secara mandiri.

Meskipun implementasi bisa didelegasikan, perencanaan dan Quality Assurance (QA) tetap membutuhkan sentuhan manusia. Di sinilah "rasa" (taste) dan standar kualitas engineer diuji. Kita tidak sedang memproduksi "slop" (kode sampah berkualitas rendah); kita menggunakan AI untuk membangun perangkat lunak berkualitas tinggi dengan lebih cepat.

Bagaimana dengan Anda? Apakah Anda akan terus terjebak dalam "Dumb Zone", atau mulai merestrukturisasi kode Anda agar lebih "ramah agen"?

Referensi Utama:

• Dex Hy (Human Layer): Konsep Smart Zone dan Dumb Zone pada LLM.
• Frederick P. Brooks (The Design of Design).
• John Ousterhout (The Philosophy of Software Design).
• Andrew Hunt & David Thomas (The Pragmatic Programmer).
• Kriteria Utama untuk SEO Website Article.pdf.
• Kriteria Konten Natural & Otentik Seperti Manusia Asli.