FRAME-12, Jawaban Mengapa AI Coding Sering Keluar Jalur?

Beberapa waktu lalu saya membagikan sebuah postingan Ai Coding sederhana di media sosial tentang bagaimana saya biasanya memulai sebuah project ketika menggunakan AI Coding.

Workflow yang saya bagikan saat itu sebenarnya sangat sederhana.

Problem
↓
PRD
↓
Architecture
↓
Database
↓
Flow
↓
Decision
↓
Coding

Di luar dugaan, postingan tersebut memancing diskusi yang sangat menarik.

Banyak programmer senior, software engineer, software architect, hingga developer yang sudah berpengalaman bertahun-tahun ikut memberikan masukan.

Bahkan beberapa di antaranya membagikan pengalaman membangun ERP, SaaS, marketplace, hingga payment gateway.

Yang menarik, hampir tidak ada yang mengatakan workflow tersebut salah.

Sebaliknya, mereka justru menyempurnakannya berdasarkan pengalaman masing-masing.

Ada yang menyarankan Domain Driven Design (DDD), ada yang mengingatkan pentingnya Business Rules, ada yang menyebut Architecture Decision Record (ADR), ada yang menjelaskan Functional Specification Document (FSD), hingga pentingnya Task Breakdown sebelum AI mulai menulis satu baris kode.

AI Coding Bukan Dimulai dari Coding, Tapi dari Dokumentasi Yang RAPI

Saya justru senang membaca seluruh komentarnya.

Karena dari situlah saya menyadari satu hal yang sangat penting.

AI Coding ternyata tidak membuat software engineering menjadi lebih sederhana.

Justru sebaliknya.

Semakin pintar AI, semakin penting pula kita menyiapkan pondasi yang benar sebelum mulai coding.

Kalau dulu programmer menghabiskan sebagian besar waktunya untuk menulis kode, sekarang AI mampu menghasilkan ribuan baris kode hanya dalam hitungan menit.

Masalahnya, AI hanya akan menghasilkan kode yang baik apabila memahami konteks project dengan benar.

Di sinilah letak kesalahan yang sering dilakukan banyak orang, termasuk saya yang masih terus upgrade diri guna maksimal belajar ngoding dengan AI dari waktu ke waktu.

Daftar Isi

1. Mengapa AI Coding Sering Melenceng dari Rencana?
2. AI Tidak Membutuhkan Prompt Panjang, AI Membutuhkan Blueprint
3. Apa yang Saya Pelajari dari Diskusi Para Programmer Senior?
4. Lahirnya FRAME-12 Blueprint AI Coding
5. Domain Driven Design, Apa Lagi Ini?
   1. Domain Driven Design (DDD): Kapan Dibutuhkan dan Kapan Tidak
   2. Jangan Langsung Coding, Buat Blueprint Dulu
   3. Flow Saja Tidak Cukup. AI Juga Harus Tahu Aturan Mainnya
   4. Jangan Langsung Membuat Database. Pahami Datanya Terlebih Dahulu
   5. Catat Keputusan Penting. Jangan Mengandalkan Ingatan
   6. Mengapa AI Harus Diberi Pekerjaan Kecil?
   7. Tidak Semua Project Membutuhkan Dokumentasi Tebal
6. AI Tidak Membutuhkan Prompt yang Lebih Panjang, AI Membutuhkan Cara Berpikir yang Lebih Baik
7. Disclaimer

Mengapa AI Coding Sering Melenceng dari Rencana?

Kalau Anda baru mulai menggunakan Windsurf, Cursor, Claude Code, Gemini CLI, atau AI Coding lainnya, mungkin pernah mengalami pengalaman seperti ini.

Awalnya Anda hanya meminta AI membuat halaman login.

Beberapa menit kemudian AI mulai membuat sistem role yang tidak pernah diminta.

Menambahkan library baru.

Mengubah struktur folder.

Membuat helper tambahan.

Bahkan mengubah kode lama yang sebenarnya masih berjalan dengan baik.

Semakin lama project berjalan, AI justru terasa semakin sulit diarahkan.

Prompt yang tadinya menghasilkan kode rapi, sekarang mulai menghasilkan implementasi yang berbeda-beda.

Nama function berubah.

Struktur folder berubah.

Cara validasi berubah.

Bahkan kadang AI membuat ulang fitur yang sebenarnya sudah ada.

Banyak orang langsung menyimpulkan bahwa AI sedang berhalusinasi.

Menurut saya, tidak selalu demikian.

Sering kali AI hanya sedang berusaha mengisi bagian-bagian yang tidak pernah kita jelaskan.

Bayangkan Anda menyuruh seorang tukang membangun rumah.

Anda hanya mengatakan, “Bangunkan saya rumah dua lantai.”

Tukang tersebut tentu bisa mulai bekerja.

Namun hasil akhirnya bisa sangat jauh dari bayangan Anda.

• Jumlah kamar mungkin kurang.
• Garasi terlalu kecil.
• Posisi dapur tidak nyaman.
• Jalur listrik berantakan.
• Saluran air harus dibongkar ulang.

Sekarang bandingkan jika Anda datang membawa gambar kerja lengkap.

Di dalamnya sudah ada denah ruangan, ukuran bangunan, posisi pintu, jalur listrik, saluran air, jenis atap, sampai daftar material yang akan digunakan.

Tukang yang sama akan menghasilkan rumah yang jauh lebih sesuai dengan keinginan Anda.

AI bekerja dengan cara yang hampir sama.

AI bukan sekadar membutuhkan prompt.

AI membutuhkan konteks.

AI membutuhkan blueprint.

Semakin jelas blueprint yang kita berikan, semakin sedikit asumsi yang harus dibuat AI.

Sebaliknya, semakin kabur requirement yang kita berikan, semakin banyak keputusan yang akan diambil AI sendiri.

Di sinilah project mulai kehilangan arah.

AI sebenarnya tidak salah.

AI hanya sedang menebak apa yang tidak pernah kita jelaskan.

AI Tidak Membutuhkan Prompt Panjang, AI Membutuhkan Blueprint

Selama beberapa bulan terakhir saya melihat banyak konten yang membahas cara membuat prompt AI Coding.

• Ada yang mengatakan prompt harus panjang.
• Ada yang mengatakan cukup satu kalimat.
• Ada yang membuat prompt ribuan kata.

Menurut saya, semuanya kurang tepat jika hanya berhenti di prompt.

Prompt hanyalah cara kita berbicara kepada AI.

Yang jauh lebih penting adalah apakah kita sendiri sudah memahami aplikasi yang ingin dibangun.

Kalau kita sendiri masih bingung, AI juga akan bingung.

Kalau kita sendiri belum tahu fitur apa saja yang harus dibuat, aturan bisnisnya bagaimana, siapa penggunanya, data apa yang harus disimpan, sampai bagaimana alur prosesnya, maka AI akan mulai mengambil keputusan sendiri.

Inilah penyebab mengapa banyak orang merasa AI Coding awalnya sangat hebat, tetapi semakin lama project berjalan justru semakin sulit dikendalikan.

Bukan karena AI semakin bodoh.

Tetapi karena kompleksitas project terus bertambah sementara dokumentasi tidak ikut berkembang.

Semakin besar project, semakin banyak konteks yang harus dipahami AI.

Semakin sedikit konteks yang diberikan, semakin besar peluang AI membuat asumsi sendiri.

Apa yang Saya Pelajari dari Diskusi Para Programmer Senior?

Setelah membaca komentar – komentar dari para programmer dan software engineer yang jauh lebih berpengalaman, saya menyadari bahwa hampir semua masukan mereka sebenarnya mengarah pada satu tujuan yang sama.

Mereka tidak sedang memperdebatkan AI Vs Programmer.

Mereka sedang memperkuat proses berpikir sebelum coding dimulai.

Ada yang terbiasa membangun sistem ERP.

Ada yang setiap hari mengembangkan SaaS.

Ada yang menangani payment gateway.

Ada pula yang membangun aplikasi sederhana untuk UMKM.

Masing-masing memiliki workflow yang sedikit berbeda.

Namun semuanya memiliki satu kesamaan.

• Mereka tidak langsung menulis kode.
• Mereka memahami masalahnya terlebih dahulu.
• Mereka mendokumentasikan aturan bisnisnya.
• Mereka menyusun struktur aplikasinya.
• Mereka memikirkan data yang akan disimpan.

Baru setelah semuanya cukup jelas, proses coding dimulai.

Di sinilah saya mulai menyadari bahwa AI sebenarnya tidak mengubah proses software engineering.

AI hanya mempercepat proses implementasi.

Kalau pondasinya kuat, AI bisa menjadi akselerator yang luar biasa.

Sebaliknya, kalau pondasinya lemah, AI justru akan mempercepat kekacauan.

Lahirnya FRAME-12 Blueprint AI Coding

Dari seluruh diskusi tersebut saya kemudian mencoba merangkum berbagai masukan menjadi sebuah alur kerja yang lebih mudah dipahami oleh orang awam, founder, UMKM, webcoder, maupun programmer yang baru mulai menggunakan AI (tentu terutama buat saya sendiri).

Saya memberi nama alur ini FRAME-12 Blueprint AI Coding.

FRAME saya pilih karena kata tersebut identik dengan kerangka, blueprint, atau pondasi sebelum pembangunan dimulai.

Sedangkan angka 12 menunjukkan dua belas tahapan yang menurut saya perlu dipersiapkan sebelum meminta AI mulai menulis kode.

Framework ini bukan standar resmi software engineering.

Bukan pula satu-satunya cara membangun software.

FRAME-12 hanyalah cara saya menyederhanakan berbagai praktik software engineering menjadi bahasa yang lebih mudah dipahami oleh pengguna AI Coding (versi saya).

Tujuannya bukan membuat orang menjadi software architect.

Tujuannya agar AI memiliki konteks yang cukup sehingga hasil coding menjadi lebih konsisten, lebih mudah direview, dan lebih mudah dikembangkan di kemudian hari.

Domain Driven Design, Apa Lagi Ini?

Kembali ke postingan saya di threads, beberapa netizen mengingatkan mengenai DDD.

Tapi apakah DDD ini selalu wajib ada untuk project vibecoding sederhana?

Mengapa Domain Driven Design tidak selalu wajib?

Kapan Business Rules menjadi sangat penting, mengapa ADR layak digunakan, apa fungsi FSD, serta bagaimana semua masukan tersebut akhirnya membentuk FRAME-12 Blueprint AI Coding.

Oke, mari kita bahas.

1. Domain Driven Design (DDD): Kapan Dibutuhkan dan Kapan Tidak

Masukan pertama yang paling banyak muncul adalah tentang Domain Driven Design atau yang biasa disingkat DDD.

Jujur, dulu saya juga menganggap DDD hanya cocok untuk perusahaan besar.

Bahasanya terdengar rumit, istilahnya banyak, dan sekilas seperti teori yang sulit diterapkan.

Namun setelah membaca berbagai komentar dari para software engineer, saya mulai memahami bahwa inti DDD sebenarnya mungkin jauh lebih sederhana daripada istilahnya.

DDD bukan tentang membuat diagram yang rumit.

DDD adalah cara berpikir sebelum mulai membuat database.

Mayoritas orang yang baru belajar AI Coding biasanya berpikir seperti ini.

Buat tabel user.

Buat tabel invoice.

Buat tabel payment.

Buat tabel produk.

Padahal pertanyaan yang lebih penting justru bukan tabel apa yang akan dibuat.

Tetapi, bisnis apa yang sedang kita bangun?

Misalnya Anda ingin membuat aplikasi klinik.

Kalau langsung berpikir database, kemungkinan besar Anda akan mulai membuat tabel pasien, tabel dokter, tabel jadwal, tabel pembayaran, dan seterusnya.

Padahal cara berpikir yang lebih sehat adalah memulai dari aktivitas bisnisnya.

Pasien datang.

↓

Pendaftaran.

↓

Pemeriksaan.

↓

Terapi.

↓

Pembayaran.

↓

Riwayat Kunjungan.

Setelah alur bisnis tersebut jelas, barulah kita mulai menentukan data apa saja yang dibutuhkan.

Dengan kata lain, database lahir dari proses bisnis.

Bukan sebaliknya.

Contoh lain yang lebih dekat dengan project yang baru saja saya kerjakan adalah Payment Hub.

Banyak orang akan langsung membuat seperti ini.

invoice
payments
products
customers
transactions

DDD mengajak kita berhenti sebentar.

Tanyakan dulu.

Apa sebenarnya dunia bisnis yang sedang dibangun?

Mungkin jawabannya adalah seperti ini.

Customer

Product

Invoice

Payment

Empat kata tersebut bukan nama tabel.

Empat kata tersebut adalah empat bagian bisnis yang berbeda.

Masing-masing memiliki aturan sendiri.

Invoice memiliki status.

Payment memiliki proses pembayaran.

Customer memiliki identitas.

Product memiliki harga.

Kalau cara berpikir ini sudah benar, database biasanya ikut menjadi jauh lebih rapi.

Lalu muncul pertanyaan.

Apakah semua project harus menggunakan DDD?

Menurut saya, tidak.

Kalau Anda hanya membuat company profile, landing page, sistem absensi sederhana, aplikasi kasir kecil, atau CRUD internal, DDD justru bisa menjadi beban.

Waktu habis untuk membuat diagram, tetapi manfaatnya belum terasa.

Namun ketika project mulai berkembang menjadi ERP, CRM, marketplace, payment gateway, aplikasi rumah sakit, atau SaaS yang memiliki banyak aturan bisnis, DDD mulai menunjukkan manfaatnya.

Yang menarik, ternyata inti DDD sebenarnya sudah sering kita lakukan tanpa sadar.

Misalnya sebelum membangun rumah.

Kita tidak pernah memulai dari jumlah batu bata.

Kita mulai dari pertanyaan yang jauh lebih sederhana.

Rumah ini untuk siapa?

Berapa anggota keluarganya?

Butuh berapa kamar?

Apakah ada garasi?

Apakah ada ruang kerja?

Baru setelah itu kita menghitung semen, besi, keramik, dan material lainnya.

Software seharusnya juga seperti itu.

Jangan mulai dari tabel.

Mulailah dari masalah yang ingin diselesaikan.

Mulailah dari proses bisnisnya.

Mulailah dari kebutuhan penggunanya.

Barulah AI akan jauh lebih mudah memahami aplikasi yang sedang kita bangun.

Menurut saya, inilah pelajaran pertama yang saya dapatkan dari diskusi tersebut.

AI tidak peduli apakah kita menggunakan istilah DDD atau tidak.

Yang penting AI memahami dunia bisnis yang sedang kita bangun.

Semakin jelas dunia bisnisnya, semakin sedikit asumsi yang dibuat AI.

Dan semakin sedikit asumsi yang dibuat AI, semakin konsisten pula kode yang dihasilkannya.

2. Jangan Langsung Coding, Buat Blueprint Dulu

Masukan kedua yang menurut saya sangat menarik adalah tentang Architecture.

Ada salah satu programmer yang berkomentar bahwa architecture sebaiknya dibuat setelah flow bisnis dipahami.

Semakin saya pikirkan, semakin saya setuju.

Masalah terbesar orang yang baru menggunakan AI Coding adalah terlalu cepat membuka editor, lalu langsung mengetik.

“Buatkan aplikasi CRM.”

atau.

“Buatkan sistem inventory.”

AI tentu akan mulai bekerja.

Tetapi AI juga mulai menebak.

CRM seperti apa?

Inventory untuk toko kecil atau gudang nasional?

Apakah ada approval?

Apakah ada multi-user?

Apakah ada histori perubahan?

Apakah ada cabang?

Karena tidak ada jawaban, AI mulai membuat keputusan sendiri.

Semakin lama project berjalan, keputusan-keputusan kecil tersebut akan menumpuk.

Inilah yang membuat banyak orang berkata, “Kok AI saya lama-lama ngaco?”

Padahal sebenarnya AI hanya sedang melanjutkan asumsi yang dibuatnya sendiri sejak awal project.

Di sinilah blueprint menjadi sangat penting.

Saya sengaja menggunakan kata Blueprint, bukan Architecture.

Kenapa?

Karena kata blueprint jauh lebih mudah dipahami oleh siapa saja.

Semua orang tahu bahwa sebelum rumah dibangun, pasti ada gambar kerjanya.

Begitu pula software.

Sebelum AI mulai menulis kode, kita perlu menjelaskan gambaran besarnya terlebih dahulu.

Blueprint tidak perlu rumit.

Tidak perlu diagram yang penuh kotak dan panah.

Cukup menjawab beberapa pertanyaan sederhana.

• Aplikasi ini terdiri dari fitur apa saja?
• Bagaimana alur pengguna dari awal sampai selesai?
• Siapa saja yang bisa mengakses setiap fitur?
• Bagaimana hubungan antar modul?
• Apa yang terjadi ketika pengguna menekan tombol tertentu?

Misalnya Anda ingin membuat aplikasi pendaftaran pelatihan.

Daripada langsung meminta AI membuat database peserta, jauh lebih baik membuat blueprint sederhana seperti berikut.

Landing Page

↓

Form Pendaftaran

↓

Pembayaran

↓

Verifikasi

↓

Member Area

↓

Sertifikat

Hanya dengan alur sederhana seperti itu, AI sudah memiliki gambaran besar mengenai aplikasi yang akan dibangun.

Blueprint juga membantu kita menemukan masalah sejak awal.

Misalnya setelah digambar ternyata muncul pertanyaan.

• Kalau pembayaran gagal bagaimana?
• Kalau peserta mendaftar dua kali bagaimana?
• Kalau admin salah verifikasi bagaimana?
• Kalau peserta meminta refund bagaimana?

Semua pertanyaan tersebut jauh lebih murah dijawab sebelum coding dimulai daripada setelah aplikasi selesai dibuat.

Inilah alasan mengapa banyak software engineer menghabiskan waktu cukup lama untuk berdiskusi sebelum mulai coding.

Bukan karena mereka lambat.

Tetapi karena mereka sedang mengurangi kemungkinan salah arah.

Ada satu pelajaran yang menurut saya sangat penting dari diskusi para senior programmer.

• Blueprint bukan dokumen yang dibuat sekali lalu selesai.
• Blueprint ikut berkembang bersama project.

Misalnya awalnya aplikasi hanya memiliki alur seperti ini.

Checkout

↓

Payment

↓

Invoice

Kemudian bisnis berkembang.

Pemilik usaha ingin menambahkan voucher.

Ingin menambahkan poin reward.

Ingin menambahkan affiliate.

Blueprint pun berubah.

Checkout

↓

Voucher

↓

Reward

↓

Payment

↓

Invoice

↓

Affiliate

Kalau blueprint berubah, biasanya struktur aplikasi juga ikut berubah.

Karena itulah architecture sering disebut sebagai sesuatu yang evolving, artinya ikut berkembang seiring berkembangnya kebutuhan bisnis.

Menurut saya, kesalahan terbesar saat menggunakan AI Coding adalah menganggap blueprint tidak penting.

Padahal blueprint bukan dibuat untuk AI.

Blueprint dibuat untuk kita sendiri.

Supaya kita tahu ke mana project ini akan dibawa.

AI hanya mengikuti arah yang kita berikan.

Kalau arah kita berubah setiap hari, jangan heran kalau AI juga menghasilkan kode yang berubah-ubah setiap hari.

Jadi sebelum mulai berbicara tentang database, framework, bahasa pemrograman, atau library yang akan digunakan, berhentilah sejenak.

Gambarkan dulu rumah yang ingin dibangun.

Karena AI bisa menjadi tukang yang sangat cepat.

Tetapi tetap manusialah yang harus menjadi arsiteknya.

3. Flow Saja Tidak Cukup. AI Juga Harus Tahu Aturan Mainnya

Setelah blueprint selesai dibuat, saya kembali mendapatkan masukan yang menurut saya sangat membuka wawasan.

Salah satu programmer mengatakan bahwa flow saja tidak cukup.

Awalnya saya berpikir, bukankah kalau alur aplikasi sudah jelas, AI tinggal mengubahnya menjadi kode?

Ternyata tidak sesederhana itu.

Mari kita lihat contoh flow yang sangat sederhana.

User klik tombol Bayar

↓

Invoice dibuat

↓

Payment Gateway dipanggil

↓

Menunggu Callback

↓

Status menjadi Lunas

Sekilas tidak ada masalah.

Kalau kita berikan flow tersebut kepada AI, kemungkinan besar AI juga bisa membuat implementasinya.

Namun coba kita berpikir sedikit lebih dalam.

Lalu muncul pertanyaan-pertanyaan baru.

• Kalau invoice sudah kedaluwarsa bagaimana?
• Kalau pengguna membayar kurang bagaimana?
• Kalau pengguna membayar lebih bagaimana?
• Kalau callback dari payment gateway datang dua kali bagaimana?
• Kalau callback palsu bagaimana?
• Kalau pengguna meminta refund bagaimana?
• Kalau admin membatalkan transaksi bagaimana?

Semua pertanyaan tersebut tidak terlihat di flow.

Tetapi semuanya adalah kejadian yang sangat mungkin terjadi di dunia nyata.

Di sinilah saya mulai memahami apa yang dimaksud para software engineer ketika mereka berbicara tentang Business Rules.

Saya sendiri lebih suka menyebutnya dengan istilah yang lebih sederhana, yaitu Aturan Main.

Kalau blueprint menjelaskan jalannya cerita, maka Business Rules menjelaskan aturan permainannya.

Analogi paling mudah adalah permainan sepak bola.

Flow permainannya sangat sederhana.

Kick Off

↓

Oper Bola

↓

Menyerang

↓

Menembak

↓

Gol

Tetapi pertandingan sepak bola tidak mungkin berjalan hanya dengan flow tersebut.

Masih ada banyak aturan.

• Offside.
• Handsball.
• Kartu kuning.
• Kartu merah.
• Penalty.
• Pergantian pemain.
• Tambahan waktu.

Tanpa aturan tersebut, pertandingan akan menjadi kacau.

Software juga sama.

Flow hanyalah cerita besarnya.

Business Rules adalah aturan yang membuat cerita tersebut tetap berjalan dengan benar.

Sayangnya, bagian inilah yang paling sering dilewatkan ketika menggunakan AI Coding.

Kita hanya berkata.

“Buatkan sistem pembayaran.”

Tetapi kita tidak pernah menjelaskan aturan mainnya.

Akhirnya AI mulai menebak sendiri.

Dan ketika AI mulai menebak, di situlah hasil coding mulai berbeda dengan harapan kita.

Menurut saya, inilah salah satu penyebab terbesar mengapa banyak orang mengatakan AI sering “halusinasi”.

Padahal sering kali AI tidak sedang berhalusinasi.

AI hanya sedang mengisi bagian yang kosong.

Semakin banyak bagian yang kosong, semakin banyak pula asumsi yang dibuat AI.

Kalau kita ingin AI menghasilkan kode yang konsisten, maka jangan hanya memberikan flow.

Berikan juga aturan mainnya.

Misalnya seperti ini.

Invoice berlaku 24 jam.

Invoice yang sudah lunas tidak boleh diubah.

Callback harus diverifikasi menggunakan Signature.

Status hanya boleh berubah melalui Callback.

Refund hanya dapat dilakukan oleh Admin.

Lima aturan sederhana seperti itu sering kali jauh lebih berharga daripada prompt sepanjang ribuan kata.

Karena AI akhirnya memahami batasan-batasan yang harus dipatuhi.

Saya bahkan mulai menyadari bahwa banyak revisi coding sebenarnya bukan disebabkan AI yang kurang pintar.

Melainkan karena kita baru memikirkan aturan bisnis setelah aplikasi selesai dibuat.

Akibatnya AI harus mengubah kode berkali-kali, menyesuaikan logika baru, bahkan kadang membongkar struktur yang sebelumnya sudah dibuat.

Kalau aturan main sudah ditulis sejak awal, perubahan seperti ini biasanya jauh lebih sedikit.

Di sinilah saya mulai mengubah urutan berpikir saya.

Dulu saya berpikir seperti ini.

Problem

↓

PRD

↓

Architecture

↓

Database

↓

Coding

Sekarang saya lebih nyaman dengan urutan seperti ini.

Problem

↓

PRD

↓

Blueprint

↓

Aturan Main

↓

Data

↓

Coding

Karena AI bukan hanya perlu tahu apa yang harus dibuat.

AI juga perlu tahu apa yang boleh dan tidak boleh dilakukan.

Menurut saya, inilah salah satu pelajaran paling berharga dari diskusi para programmer senior tersebut.

Semakin jelas aturan main yang kita tuliskan, semakin kecil kemungkinan AI keluar dari jalur yang sudah direncanakan.

4. Jangan Langsung Membuat Database. Pahami Datanya Terlebih Dahulu

Masukan berikutnya juga cukup menarik.

Ada beberapa software engineer yang mengatakan bahwa sebenarnya database adalah bagian dari architecture.

Secara teori, saya setuju.

Dalam dunia software engineering, architecture biasanya memang mencakup banyak hal, mulai dari pembagian modul, API, komunikasi antar layanan, deployment, hingga struktur database.

Namun untuk AI Coding, saya justru lebih suka memisahkan pembahasannya.

Bukan karena teorinya salah.

Tetapi karena cara berpikir manusia dan AI sedikit berbeda.

Kalau semuanya dicampur dalam satu dokumen besar, sering kali AI kehilangan fokus.

Saya lebih memilih menjelaskan database sebagai topik tersendiri.

Alasannya sederhana.

Database bukan sekadar kumpulan tabel.

Database adalah tempat aplikasi menyimpan ingatannya.

Coba bayangkan Anda ingin membuka sebuah perpustakaan.

Apakah hal pertama yang Anda pikirkan adalah membeli rak buku?

Tentu tidak.

Anda pasti bertanya terlebih dahulu.

• Buku apa saja yang akan disimpan?
• Siapa yang akan meminjam?
• Bagaimana proses peminjaman?
• Apakah ada denda?
• Apakah ada kategori buku?

Baru setelah semua itu jelas, Anda membeli rak yang sesuai.

Database juga seperti itu.

Jangan mulai dari membuat tabel.

Mulailah dari memahami informasi apa saja yang benar-benar dibutuhkan aplikasi.

Kesalahan yang sering saya lihat ketika menggunakan AI Coding adalah langsung meminta seperti ini.

“Buatkan database untuk aplikasi CRM.”

AI tentu bisa membuatnya.

Tetapi AI tidak tahu CRM seperti apa yang Anda inginkan.

Akhirnya AI mulai membuat banyak tabel berdasarkan asumsi.

Misalnya.

customers

contacts

companies

activities

notes

pipelines

tasks

reminders

deals

campaigns

Padahal belum tentu semua tabel tersebut benar-benar dibutuhkan.

Bisa jadi aplikasi yang ingin Anda bangun ternyata hanya membutuhkan empat data utama.

• Pelanggan.
• Produk.
• Invoice.
• Pembayaran.

Semakin sedikit asumsi yang dibuat AI, biasanya semakin sederhana struktur databasenya.

Saya sekarang lebih suka memulai dengan pertanyaan yang jauh lebih sederhana.

Data apa saja yang benar-benar harus diingat oleh aplikasi ini?

Misalnya aplikasi pendaftaran pelatihan.

Mungkin jawabannya hanya seperti ini.

• Data peserta.
• Data kelas.
• Data pembayaran.
• Data sertifikat.

Setelah itu baru kita bertanya lagi.

• Hubungannya bagaimana?
• Satu peserta bisa ikut berapa kelas?
• Satu kelas memiliki berapa peserta?
• Satu pembayaran untuk satu kelas atau beberapa kelas?

Dengan cara berpikir seperti ini, AI tidak lagi menebak-nebak.

AI tinggal menerjemahkan hubungan antar data menjadi struktur database.

Menurut saya, inilah alasan mengapa database sebaiknya dibuat setelah blueprint dan aturan main selesai disusun.

Karena database bukan penentu bisnis.

• Database hanyalah cerminan dari bisnis yang sudah kita pahami.
• Kalau proses bisnis berubah, biasanya database juga ikut berubah.
• Kalau aturan main berubah, relasi data pun sering ikut berubah.

Karena itu saya tidak lagi memulai project dengan pertanyaan.

“Tabel apa saja yang harus dibuat?”

Saya lebih suka memulai dengan pertanyaan.

“Informasi apa saja yang benar-benar harus diingat oleh aplikasi ini?”

Perbedaannya mungkin terdengar sederhana.

Tetapi cara berpikir inilah yang menurut saya membuat AI menghasilkan struktur database yang jauh lebih relevan dengan kebutuhan project.

5. Catat Keputusan Penting. Jangan Mengandalkan Ingatan

Salah satu masukan yang paling saya sukai adalah tentang Architecture Decision Record atau biasa disingkat ADR.

Awalnya saya hanya menulis file bernama DECISIONS.md.

Isinya sederhana.

• Mengapa memilih PostgreSQL.
• Mengapa menggunakan Laravel.
• Mengapa memilih Nginx.
• Mengapa memakai Repository Pattern.

Ternyata di dunia software engineering sudah ada istilah resminya, yaitu Architecture Decision Record (ADR).

Semakin saya pelajari, semakin saya menyadari bahwa idenya sangat masuk akal.

Bayangkan Anda sedang membangun rumah.

Suatu hari Anda memutuskan menggunakan rangka baja ringan, bukan kayu.

Anda juga memilih genteng beton dibandingkan genteng tanah liat.

Lima tahun kemudian rumah tersebut direnovasi oleh kontraktor lain.

Kalau semua keputusan itu tidak pernah dicatat, kemungkinan besar mereka akan bertanya lagi.

• Kenapa dulu memakai baja ringan?
• Kenapa bukan kayu?
• Kenapa memilih material ini?

Akhirnya diskusi yang sama terulang kembali.

Software juga demikian.

Semakin lama sebuah project berjalan, semakin banyak keputusan yang diambil.

Misalnya.

• Kenapa memakai PostgreSQL?
• Kenapa tidak MySQL?
• Kenapa menggunakan Queue?
• Kenapa memakai Cloudflare?
• Kenapa API dibuat seperti ini?

Kalau semua keputusan hanya disimpan di kepala, suatu saat pasti akan terlupakan.

Terlebih jika project dikerjakan oleh beberapa orang.

Karena itulah saya sekarang mulai membiasakan diri menuliskan setiap keputusan penting.

Tidak perlu panjang.

Cukup menjawab empat pertanyaan sederhana.

1. Keputusan apa yang diambil?
2. Mengapa keputusan itu dipilih?
3. Apa alternatifnya?
4. Apa konsekuensinya?

Misalnya.

Keputusan

Menggunakan PostgreSQL.

Alasan

Membutuhkan transaksi yang konsisten.

Alternatif

MySQL.

SQLite.

Konsekuensi

Tim harus memahami PostgreSQL.

Kelihatannya sederhana.

Tetapi beberapa bulan kemudian, ketika AI atau developer lain kembali membaca project tersebut, mereka tidak perlu menebak-nebak lagi.

Mereka langsung memahami alasan di balik keputusan yang pernah diambil.

Menurut saya, AI Coding bukan hanya soal menghasilkan kode.

AI juga harus memahami sejarah keputusan yang membentuk project tersebut.

Semakin lengkap konteks yang kita berikan, semakin sedikit keputusan yang harus ditebak oleh AI.

6. Mengapa AI Harus Diberi Pekerjaan Kecil?

Kalau ada satu pelajaran yang paling mengubah cara saya menggunakan AI Coding, mungkin inilah jawabannya.

Jangan pernah meminta AI mengerjakan project besar dalam satu perintah.

Ada pemula yang membuat prompt seperti ini.

Buatkan aplikasi CRM lengkap menggunakan Laravel.

atau.

Buatkan aplikasi LMS lengkap dengan pembayaran, sertifikat, email, dashboard admin, dan API.

AI memang akan mulai bekerja.

Bahkan hasil awalnya sering kali terlihat sangat mengesankan.

Namun beberapa jam kemudian mulai muncul masalah.

• Struktur project berubah.
• Library bertambah tanpa alasan yang jelas.
• Kode yang sudah benar ikut diubah.
• Logika lama ditimpa logika baru.
• Fitur yang tidak diminta ikut dibuat.

Akhirnya saya menyadari bahwa kesalahannya bukan pada AI.

Kesalahannya ada pada cara saya memberikan pekerjaan.

Bayangkan Anda baru merekrut seorang karyawan.

Pada hari pertama bekerja Anda berkata seperti ini.

Tolong bangun perusahaan ini sampai sukses.

Kira-kira apa yang akan dilakukan karyawan tersebut?

Ia pasti bingung.

Bukan karena tidak mampu.

Tetapi karena pekerjaannya terlalu besar.

Sekarang bandingkan dengan instruksi seperti ini.

1. Siapkan meja kerja.
2. Install komputer.
3. Buat akun email.
4. Masukkan data pelanggan.
5. Buat laporan harian.

Tiba-tiba pekerjaan yang sama menjadi jauh lebih mudah dikerjakan.

AI bekerja dengan cara yang hampir sama.

Semakin kecil tugas yang kita berikan, semakin konsisten hasil yang dihasilkan.

Karena itulah penting belajar bagaimana tidak meminta AI langsung membuat aplikasi secara utuh.

Tetapi kita perlu memecahnya menjadi tugas-tugas kecil.

Misalnya seperti ini.

Task 1

Buat struktur project Laravel.

Task 2

Buat migration tabel users.

Task 3

Buat migration tabel products.

Task 4

Buat halaman login.

Task 5

Buat CRUD Product.

Task 6

Buat API Invoice.

Task 7

Buat Unit Test.

Perhatikan perbedaannya.

AI tidak lagi diminta berpikir tentang keseluruhan aplikasi.

AI hanya fokus menyelesaikan satu pekerjaan pada satu waktu.

Hasilnya jauh lebih stabil.

Review menjadi lebih mudah.

Kalau ada kesalahan, kita juga tahu letaknya di task yang mana.

Saya bahkan mulai memperlakukan AI seperti anggota tim.

Bukan sebagai mesin ajaib yang bisa langsung menyelesaikan semuanya.

Semakin jelas pekerjaan yang saya berikan, semakin baik pula hasil yang saya terima.

Di sinilah saya memahami mengapa banyak software engineer membagi project menjadi sprint, milestone, backlog, atau task kecil.

Ternyata bukan hanya agar developer manusia lebih mudah bekerja.

AI juga jauh lebih efektif jika bekerja dalam unit pekerjaan yang kecil.

7. Tidak Semua Project Membutuhkan Dokumentasi Tebal

Satu lagi masukan yang menurut saya sangat realistis datang dari beberapa programmer senior.

Mereka mengingatkan agar jangan sampai dokumentasi lebih lama dibuat daripada aplikasinya.

Saya setuju.

Kalau target Anda hanya membuat landing page sederhana dalam satu hari, tentu tidak perlu membuat dokumen setebal seratus halaman.

Begitu pula jika hanya membuat aplikasi CRUD sederhana untuk kebutuhan internal.

Yang penting adalah menyesuaikan proses dengan skala project.

Semakin kecil project, semakin sederhana dokumentasinya.

Semakin besar project, semakin lengkap dokumentasinya.

Jangan sampai kita terjebak membuat dokumentasi yang indah tetapi aplikasinya tidak pernah selesai.

Sebaliknya, jangan pula terlalu bersemangat coding sampai lupa mendokumentasikan hal-hal penting.

Menurut saya, keseimbangan inilah yang perlu dijaga.

FRAME-12 bukan berarti setiap project harus memiliki dua belas dokumen lengkap.

FRAME-12 adalah cara berpikir.

Pada project kecil mungkin cukup tiga atau empat bagian saja.

Pada project besar, seluruh bagian bisa digunakan.

Yang terpenting bukan banyaknya dokumen.

Yang terpenting adalah AI memiliki konteks yang cukup sebelum mulai bekerja.

FRAME-12 Blueprint AI Coding

Setelah membaca berbagai komentar para software engineer, menggabungkannya dengan pengalaman pribadi menggunakan AI Coding, serta mencoba menerapkannya pada berbagai project, akhirnya saya mencoba merangkum semuanya menjadi sebuah alur sederhana yang saya beri nama FRAME-12 Blueprint AI Coding.

Saya sengaja menggunakan bahasa yang sederhana agar bisa dipahami oleh founder, UMKM, webcoder, maupun programmer pemula seperti saya.

FRAME-12 bukan standar resmi software engineering.

FRAME-12 hanyalah kerangka berpikir agar manusia dan AI memiliki arah yang sama sebelum coding dimulai.

FRAME-12

1. Problem
Masalah apa yang ingin diselesaikan?

↓

2. User
Siapa yang akan memakai aplikasi ini?

↓

3. Scope
Apa yang wajib dibuat sekarang?
Apa yang bisa ditunda?

↓

4. Rules
Apa aturan mainnya?

↓

5. Blueprint
Bagaimana gambaran besar aplikasinya?

↓

6. Decisions
Keputusan penting apa yang sudah dipilih?

↓

7. Data
Data apa saja yang akan disimpan?

↓

8. Integrations
Aplikasi ini terhubung ke layanan apa saja?

↓

9. Security
Apa yang harus diamankan?

↓

10. Tasks
Pecah menjadi pekerjaan kecil.

↓

11. Build & Test
AI mulai coding dan hasilnya diuji.

↓

12. Release
Deploy, monitor, dan terus diperbaiki.

Kalau diperhatikan, sebenarnya FRAME-12 bukan sesuatu yang benar-benar baru.

Sebagian besar isinya merupakan praktik yang selama ini sudah dilakukan oleh para software engineer berpengalaman.

Yang saya coba lakukan hanyalah menyederhanakannya menjadi bahasa yang lebih mudah dipahami oleh pengguna AI Coding pemula.

Karena menurut saya, AI tidak membutuhkan prompt yang semakin panjang.

AI membutuhkan manusia yang berpikir lebih terstruktur.

AI Tidak Membutuhkan Prompt yang Lebih Panjang, AI Membutuhkan Cara Berpikir yang Lebih Baik

Kalau ada satu kesimpulan terbesar yang saya dapatkan dari seluruh diskusi ini, mungkin kalimatnya sederhana.

Masalah terbesar AI Coding bukan pada AI.

Masalah terbesar justru sering kali ada pada manusia yang belum benar-benar memahami apa yang ingin dibangun.

Kita sering menyalahkan AI karena hasil codingnya berubah-ubah.

Kita mengatakan AI halusinasi.

Kita mengatakan AI suka menambahkan fitur yang tidak diminta.

Kita mengatakan AI mengubah struktur folder seenaknya.

Padahal setelah saya refleksikan kembali, banyak kejadian tersebut sebenarnya berawal dari satu hal.

Kita langsung meminta AI coding, padahal rencana project kita sendiri masih belum jelas.

AI akhirnya mengisi bagian-bagian kosong dengan asumsi terbaik menurutnya.

Semakin banyak bagian kosong yang kita tinggalkan, semakin banyak pula keputusan yang diambil AI tanpa kita sadari.

Akibatnya, project mulai bergeser sedikit demi sedikit dari tujuan awal.

Awalnya hanya berbeda satu folder.

Kemudian berbeda satu model.

Lalu berbeda satu alur.

Beberapa minggu kemudian kita baru sadar bahwa aplikasi yang sedang dibangun ternyata sudah jauh berbeda dengan yang ada di kepala kita.

Saya sendiri pernah mengalaminya.

Mungkin Anda juga pernah.

Karena itulah saya mulai mengubah cara menggunakan AI.

Saya tidak lagi berlomba membuat prompt paling panjang.

Saya tidak lagi mencari model AI yang katanya paling pintar.

Saya justru lebih banyak menghabiskan waktu untuk merapikan cara berpikir sebelum AI mulai bekerja.

Semakin jelas masalahnya.

Semakin jelas tujuan bisnisnya.

Semakin jelas batasan fiturnya.

Semakin jelas aturan mainnya.

Semakin jelas blueprint aplikasinya.

Maka hasil AI biasanya juga semakin konsisten.

Inilah alasan mengapa saya akhirnya merangkum seluruh pembelajaran tersebut menjadi sebuah kerangka sederhana yang saya sebut FRAME-12 Blueprint AI Coding.

Bukan untuk menggantikan software engineering.

Bukan pula untuk mengklaim bahwa inilah satu-satunya cara membangun software.

FRAME-12 hanyalah pengingat bahwa sebelum AI mulai menulis ribuan baris kode, manusianya harus lebih dulu memiliki kerangka berpikir yang jelas.

Saya percaya AI akan terus berkembang.

Tahun depan model AI akan lebih pintar daripada hari ini.

Lima tahun lagi mungkin AI mampu membangun aplikasi yang jauh lebih kompleks.

Tetapi ada satu hal yang menurut saya tidak akan berubah.

AI tetap membutuhkan arah.

Dan arah tersebut tidak berasal dari model AI.

Arah tersebut berasal dari manusia yang menggunakannya.

Kalau manusianya berpikir dengan jelas, AI akan menjadi akselerator yang luar biasa.

Sebaliknya, kalau manusianya masih bingung, AI hanya akan mempercepat kebingungan tersebut.

Jadi, kalau hari ini Anda merasa AI Coding sering keluar jalur, jangan buru-buru menyalahkan AI.

Coba berhenti sejenak.

Tanyakan kembali kepada diri sendiri.

Apakah saya sudah benar-benar tahu apa yang ingin saya bangun?

Kalau jawabannya belum, mungkin yang perlu diperbaiki bukan prompt-nya.

Mungkin yang perlu diperbaiki adalah blueprint-nya.

Disclaimer

Artikel ini lahir dari sebuah diskusi yang menurut saya sangat menyenangkan.

Saya berterima kasih kepada banyak programmer, software engineer, software architect, dan para praktisi yang telah meluangkan waktu memberikan masukan melalui kolom komentar.

Masing-masing datang dengan pengalaman yang berbeda, sehingga saya mendapatkan banyak sudut pandang baru yang sebelumnya belum saya pikirkan.

Saya juga menyadari bahwa FRAME-12 masih akan terus berkembang.

Seiring semakin sering digunakan pada project nyata, mungkin akan ada bagian yang diperbaiki, disederhanakan, atau bahkan ditambahkan.

Kalau Anda memiliki pengalaman menggunakan AI Coding, pernah mengalami AI yang tiba-tiba “keluar jalur”, atau memiliki workflow yang menurut Anda lebih efektif, saya juga sangat terbuka untuk berdiskusi.

Bukan tidak mungkin versi FRAME-12 beberapa tahun ke depan akan jauh lebih baik daripada versi yang Anda baca hari ini.

Karena pada akhirnya, tujuan kita bukan membuat AI terlihat pintar.

Tujuan kita adalah membangun software yang lebih cepat, lebih rapi, lebih mudah dipelihara, dan benar-benar menyelesaikan masalah.

Dan menurut saya, semua itu selalu dimulai dari satu hal yang sama.

Berpikir dengan benar sebelum mulai coding.

Makasih

Anjrah Ari Susanto, S.Psi.