Pelajari pola prompting terbukti yang mengarahkan AI ke persyaratan lebih jelas, desain modular, dan kode yang mudah diuji—mengurangi refactor dan siklus penulisan ulang.
“Arsitektur yang lebih bersih” dalam tulisan ini bukan berarti kerangka kerja tertentu atau diagram yang sempurna. Maksudnya adalah Anda dapat menjelaskan sistem dengan sederhana, mengubahnya tanpa merusak bagian yang tidak terkait, dan memverifikasi perilaku tanpa pengujian luar biasa.
Kejelasan berarti tujuan dan bentuk sistem terlihat dari deskripsi singkat: apa yang dilakukannya, siapa yang menggunakannya, data apa yang dikelola, dan apa yang tidak boleh dilakukan. Dalam pekerjaan yang dibantu AI, kejelasan juga berarti model bisa mengulang persyaratan kembali kepada Anda dengan cara yang Anda setujui.
Modularitas berarti tanggung jawab memiliki batas yang bersih. Setiap modul memiliki tugas, input/output, dan pengetahuan minimal tentang internal modul lain. Ketika AI menghasilkan kode, modularitas mencegahnya menyebarkan aturan bisnis ke controller, UI, dan akses data.
Keterujian berarti arsitektur membuat "membuktikan ia bekerja" menjadi murah. Aturan bisnis bisa diuji tanpa sistem penuh, dan tes integrasi fokus pada beberapa kontrak daripada setiap jalur kode.
Penulisan ulang biasanya bukan disebabkan oleh “kode buruk”—melainkan oleh keterbatasan yang hilang, ruang lingkup yang samar, dan asumsi tersembunyi. Contoh:
AI dapat mempercepat mode kegagalan ini dengan menghasilkan keluaran yang meyakinkan dengan cepat, sehingga mudah membangun di atas fondasi yang goyah.
Pola berikut adalah template untuk diadaptasi, bukan prompt ajaib. Tujuan sebenarnya adalah memaksa percakapan yang tepat lebih awal: mengklarifikasi keterbatasan, membandingkan opsi, mendokumentasikan asumsi, dan mendefinisikan kontrak. Jika Anda melewatkan pemikiran itu, model akan dengan senang hati mengisi kekosongan—dan Anda akan membayar nanti.
Anda akan menggunakannya sepanjang siklus delivery:
Jika Anda menggunakan workflow vibe-coding (sistem dihasilkan dan diiterasi via chat), checkpoint ini semakin penting. Misalnya, di Koder.ai Anda bisa menjalankan loop “planning mode” untuk mengunci kebutuhan dan kontrak sebelum menghasilkan kode React/Go/PostgreSQL, lalu memakai snapshot/rollback untuk iterasi aman ketika asumsi berubah—tanpa mengubah setiap perubahan menjadi penulisan ulang.
Pola prompting paling bernilai ketika mereka mengurangi churn keputusan. Triknya adalah menggunakan pola sebagai checkpoint singkat yang bisa diulang—sebelum menulis kode, saat mendesain, dan selama review—agar AI menghasilkan artefak yang dapat digunakan ulang, bukan teks tambahan yang harus Anda saring.
Sebelum coding: jalankan satu loop “alignment” untuk mengonfirmasi tujuan, pengguna, keterbatasan, dan metrik keberhasilan.
Saat desain: gunakan pola yang memaksa trade-off eksplisit (mis. alternatif, risiko, batas data) sebelum mulai implementasi.
Saat review: gunakan prompt bergaya checklist untuk menemukan celah (kasus tepi, monitoring, keamanan, performa) saat perubahan masih murah.
Anda akan mendapat keluaran lebih baik dengan bundel input kecil dan konsisten:
Jika Anda tidak tahu sesuatu, katakan secara eksplisit dan minta AI mencantumkan asumsi.
Daripada “jelaskan desain”, minta artefak yang bisa Anda tempel ke dokumen atau tiket:
Lakukan loop 10–15 menit: prompt → skim → rapikan. Selalu sertakan acceptance criteria (apa yang harus benar agar desain dapat diterima), lalu minta AI untuk self-check melawannya. Itu mencegah proses berubah menjadi redesign tanpa akhir dan membuat pola berikutnya cepat diaplikasikan.
Kebanyakan “penulisan ulang arsitektur” bukan disebabkan oleh diagram buruk—melainkan membangun hal yang tepat untuk masalah yang salah (atau tidak lengkap). Saat Anda memakai LLM awal, jangan minta arsitektur terlebih dulu. Minta ia mengekspos ambiguitas.
Gunakan model sebagai pewawancara kebutuhan. Tujuan Anda adalah spes singkat yang diprioritaskan yang bisa Anda konfirmasi sebelum siapa pun mendesain komponen, memilih database, atau commit ke API.
Berikut template copy-paste yang bisa Anda gunakan:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
Anda mau pertanyaan yang memaksa keputusan (bukan sekadar “ceritakan lebih banyak”), plus daftar must-have yang benar-benar bisa diselesaikan dalam timeline Anda.
Perlakukan pengulangan “10 butir” sebagai kontrak: tempelkan ke tiket/PRD, minta ya/tidak cepat dari pemangku kepentingan, dan hanya setelah itu lanjut ke arsitektur. Langkah ini mencegah penyebab paling umum refactor terlambat: membangun fitur yang sebenarnya tidak pernah benar-benar diperlukan.
Saat Anda mulai dari alat (“Haruskah kita pakai event sourcing?”) seringkali Anda mendesain untuk arsitektur bukan untuk pengguna. Jalan yang lebih cepat ke struktur bersih adalah meminta AI menggambarkan user journeys dulu dalam bahasa biasa, lalu menerjemahkannya ke komponen, data, dan API.
Gunakan ini sebagai titik mulai copy-paste:
Lalu minta:
“Describe the step-by-step flow for each action in plain language.”
“Provide a simple state diagram or state list (e.g., Draft → Submitted → Approved → Archived).”
“List non-happy-path scenarios: timeouts, retries, duplicate requests, cancellations, and invalid inputs.”
Setelah alur jelas, Anda bisa meminta AI memetakan ke pilihan teknis:
Barulah kemudian minta sketsa arsitektur (layanan/modul, batasan, dan tanggung jawab) yang terkait langsung ke langkah alur.
Akhiri dengan meminta AI mengubah setiap journey menjadi acceptance criteria yang bisa diuji:
Pola ini mengurangi penulisan ulang karena arsitektur tumbuh dari perilaku pengguna—bukan dari asumsi tentang teknologi.
Kebanyakan pengerjaan ulang bukan karena “desain buruk”—melainkan asumsi tersembunyi yang ternyata salah. Saat Anda meminta LLM untuk arsitektur, ia sering mengisi celah dengan tebakan yang masuk akal. Log asumsi membuat tebakan itu terlihat lebih awal, saat perubahan masih murah.
Tujuan Anda adalah memaksa pemisahan bersih antara fakta yang Anda berikan dan asumsi yang ia buat.
Gunakan pola prompt ini:
Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
Buat singkat supaya orang benar-benar menggunakannya:
Tambahkan satu baris yang membuat model menyebutkan tipping point-nya:
Pola ini mengubah arsitektur menjadi kumpulan keputusan bersyarat. Anda tidak hanya mendapat diagram—melainkan peta hal-hal yang harus dikonfirmasi sebelum commit.
Alat AI hebat dalam menghasilkan satu desain “terbaik”—tetapi itu sering hanya opsi pertama yang masuk akal. Arsitektur yang lebih bersih biasanya muncul ketika Anda memaksa perbandingan lebih awal, saat perubahan masih murah.
Gunakan prompt yang mengharuskan beberapa arsitektur dan tabel tradeoff terstruktur:
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
Perbandingan memaksa model (dan Anda) mengungkap asumsi tersembunyi: di mana state tinggal, bagaimana layanan berkomunikasi, apa yang harus sinkron, dan apa yang bisa ditunda.
Tabel kriteria penting karena menghentikan perdebatan seperti “microservices vs monolith” menjadi sekadar opini. Ia menambat keputusan ke apa yang benar-benar Anda pedulikan—mengirim cepat, mengurangi overhead operasional, atau meningkatkan reliabilitas.
Jangan terima jawaban “tergantung.” Minta rekomendasi jelas dan keterbatasan spesifik yang dioptimalkan.
Juga tekankan “apa yang tidak kami bangun.” Contoh: “Tidak ada failover multi-region,” “Tidak ada sistem plugin,” “Tidak ada notifikasi real-time.” Ini menjaga arsitektur agar tidak meluas diam-diam untuk mendukung fitur yang belum Anda komit—dan mencegah penulisan ulang kejutan saat ruang lingkup berubah nanti.
Sebagian besar penulisan ulang terjadi karena batas-batas samar: segala sesuatu “menyentuh segala sesuatu,” dan perubahan kecil beriak ke seluruh basis kode. Pola ini memakai prompt yang memaksa kepemilikan modul yang jelas sebelum ada debat framework atau diagram kelas.
Minta AI mendefinisikan modul dan tanggung jawab, serta apa yang secara eksplisit tidak termasuk dalam setiap modul. Lalu minta antarmuka (input/output) dan aturan dependensi, bukan rencana build atau detail implementasi.
Gunakan ini saat Anda merancang fitur baru atau merombak area berantakan:
List modules with:
For each module, define interfaces only:
Dependency rules:
Future change test: Given these likely changes: <list 3>, show which single module should absorb each change and why.
Anda menginginkan modul yang dapat Anda jelaskan ke rekan dalam kurang dari satu menit. Jika AI mengusulkan modul “Utils” atau menaruh aturan bisnis di controller, dorong balik: “Pindahkan logika keputusan ke modul domain dan jaga adapter tetap tipis.”
Saat selesai, Anda punya batasan yang bertahan terhadap kebutuhan baru—karena perubahan punya rumah yang jelas, dan aturan dependensi mencegah coupling tak sengaja.
Pekerjaan ulang integrasi sering bukan karena “kode buruk”—melainkan kontrak yang tidak jelas. Jika model data dan bentuk API diputuskan terlambat, setiap tim (atau modul) mengisi kekosongan berbeda-beda, dan Anda menghabiskan sprint berikutnya menyelaraskan asumsi yang tidak cocok.
Mulai dengan meminta kontrak sebelum bicara framework, database, atau microservices. Kontrak jelas menjadi referensi bersama yang menjaga UI, backend, dan pipeline data tetap selaras.
Gunakan prompt awal ini dengan asisten AI Anda:
Lalu segera ikuti dengan:
Anda mau artefak konkret, bukan prosa. Contoh:
Subscription
Dan sketsa API:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
Minta AI menyatakan aturan seperti: “Field tambahan boleh tanpa bump versi; penggantian nama memerlukan /v2; klien harus mengabaikan field yang tidak dikenal.” Langkah tunggal ini mencegah perubahan diam-diam yang merusak—dan penulisan ulang yang menyusul.
Arsitektur dirombak ketika desain jalur bahagia bertemu trafik nyata, dependensi fluktuatif, dan perilaku pengguna tak terduga. Pola ini membuat reliabilitas menjadi keluaran desain eksplisit, bukan perjuangan pasca-rilis.
Gunakan ini pada deskripsi arsitektur pilihan Anda:
List failure modes; propose mitigations; define observability signals.
Untuk setiap mode kegagalan:
- Apa pemicunya?
- Dampak ke pengguna (apa yang pengguna alami)
- Mitigasi (desain + operasional)
- Retries, idempotency, rate limits, timeouts pertimbangan
- Observability: logs/metrics/traces + ambang alert
Fokuskan respons dengan menyebut antarmuka yang bisa gagal: API eksternal, database, antrean, penyedia auth, dan job background. Lalu minta keputusan konkret:
Akhiri prompt dengan: “Kembalikan checklist sederhana yang bisa kami tinjau dalam 2 menit.” Checklist yang baik mencakup: timeout dependensi diset, retry dibatasi, idempotency untuk aksi create/charge, backpressure/rate limiting ada, jalur degradasi yang anggun didefinisikan.
Minta event sekitar momen pengguna (bukan hanya intern sistem): “user_signed_up”, “checkout_submitted”, “payment_confirmed”, “report_generated”. Untuk tiap event, minta:
Ini mengubah reliabilitas menjadi artefak desain yang bisa Anda validasi sebelum kode ada.
Salah satu cara umum desain yang dibantu AI menghasilkan penulisan ulang adalah mendorong arsitektur “lengkap” terlalu dini. Perbaikannya sederhana: paksa rencana dimulai dengan irisan paling kecil yang berguna—yang memberikan nilai, menguji desain, dan menjaga opsi masa depan tetap terbuka.
Gunakan ini saat solusi terasa berkembang lebih cepat daripada kebutuhan:
Template: “Propose the smallest usable slice; define success metrics; list follow-ups.”
Minta model menjawab dengan:
Tambahkan instruksi kedua: “Berikan roadmap bertahap: MVP → v1 → v2, dan jelaskan risiko apa yang dikurangi tiap fase.” Ini menjaga ide-ide nanti terlihat tanpa memaksanya masuk rilis pertama.
Contoh hasil yang diinginkan:
Baris paling kuat dalam pola ini adalah: “List what is explicitly out of scope for MVP.” Pengecualian melindungi keputusan arsitektur dari kompleksitas prematur.
Contoh pengecualian:
Akhirnya: “Ubah MVP menjadi tiket, masing-masing dengan acceptance criteria dan dependensi.” Ini memaksa kejelasan dan mengungkap coupling tersembunyi.
Rincian tiket yang sehat biasanya mencakup:
Jika Anda mau, tautkan ini langsung ke alur kerja Anda dengan meminta model mengeluarkan dalam format tim (mis. field gaya Jira) dan simpan fase berikutnya sebagai backlog terpisah.
Cara sederhana mencegah arsitektur melenceng adalah memaksa kejelasan lewat tes sebelum Anda minta desain. Ketika Anda prompt LLM untuk menulis acceptance tests dulu, ia harus menamai perilaku, input, output, dan kasus tepi. Itu secara alami mengungkap persyaratan yang hilang dan mendorong implementasi ke batas modul yang bersih.
Gunakan ini sebagai prompt “gerbang” setiap kali Anda akan mendesain sebuah komponen:
Tindak lanjuti dengan: “Group the tests by module responsibility (API layer, domain logic, persistence, external integrations). For each group, specify what is mocked and what is real.”
Ini mendorong LLM menjauhi desain kusut tempat segala sesuatu saling menyentuh. Jika ia tidak bisa menjelaskan di mana tes integrasi mulai, arsitektur Anda kemungkinan belum jelas.
Minta: “Propose a test data plan: fixtures vs factories, how to generate edge cases, and how to keep tests deterministic. List which dependencies can use in-memory fakes and which require a real service in CI.”
Seringkali Anda menemukan bahwa fitur "sederhana" sebenarnya membutuhkan kontrak, dataset seed, atau ID stabil—lebih baik menemukan itu sekarang daripada saat penulisan ulang.
Akhiri dengan checklist ringan:
Review desain tidak harus terjadi hanya setelah kode ada. Dengan AI, Anda bisa menjalankan “pre-mortem review” pada draf arsitektur (meskipun hanya beberapa paragraf dan diagram-in-words) dan mendapatkan daftar kelemahan konkret sebelum menjadi penulisan ulang.
Mulai dengan sikap reviewer yang blak-blakan dan paksakan spesifisitas:
Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can’t evaluate something, say what information is missing.”
Tempelkan ringkasan desain Anda, keterbatasan (anggaran, timeline, keterampilan tim), dan non-functional requirements (latensi, ketersediaan, kepatuhan).
Review gagal jika umpan balik samar. Minta set perbaikan yang diprioritaskan:
Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”
Ini menghasilkan tugas siap-keputusan daripada debat.
Fungsi pemaksa yang berguna adalah skor sederhana:
Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”
Anda tidak mengejar presisi; Anda ingin mengungkap asumsi paling rentan terhadap penulisan ulang.
Terakhir, cegah review memperluas ruang lingkup:
Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”
Ketika Anda mengulangi pola ini tiap iterasi, arsitektur Anda berkembang melalui langkah kecil yang dapat dibalik—sementara masalah besar terdeteksi lebih awal.
Gunakan paket ini sebagai alur kerja ringan yang dapat Anda ulang untuk setiap fitur. Ide utamanya adalah rantai prompt sehingga setiap langkah menghasilkan artefak yang dapat dipakai langkah berikutnya—mengurangi "konteks hilang" dan kejutan penulisan ulang.
Dalam praktik, tim sering mengimplementasikan rantai ini sebagai “feature recipe” yang dapat diulang. Jika Anda membangun dengan Koder.ai, struktur yang sama terpetakan dengan rapi ke proses build berbasis chat: simpan artefak di satu tempat, hasilkan irisan kerja pertama, lalu iterasi dengan snapshot sehingga eksperimen tetap dapat dibalik. Ketika MVP siap, Anda bisa mengekspor kode sumber atau deploy/host dengan domain kustom—berguna saat Anda ingin kecepatan delivery dibantu AI tanpa terkunci pada satu lingkungan.
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
Jika Anda menginginkan pendamping yang lebih mendalam, lihat /blog/prompting-for-code-reviews. Jika Anda mengevaluasi tooling atau rollout tim, /pricing adalah langkah praktis berikutnya.
"Arsitektur yang lebih bersih" di sini berarti Anda bisa:
Dalam pekerjaan yang dibantu AI, ini juga berarti model dapat mengulang kembali persyaratan dengan cara yang Anda siap setujui.
AI dapat menghasilkan kode dan desain yang meyakinkan dengan cepat, sehingga mudah membangun di atas dasar yang kurang jelas—yaitu keterbatasan yang hilang dan asumsi tersembunyi. Kecepatan itu bisa memperkuat pemicu penulisan ulang seperti:
Solusinya bukan “kurangi AI”, melainkan menggunakan prompt yang memaksa keterbatasan, kontrak, dan asumsi muncul lebih awal.
Gunakan pola sebagai checkpoint singkat yang menghasilkan artefak yang bisa dipakai ulang (bukan prosa berlebih):
Pertahankan iterasi 10–15 menit: prompt → skim → rapikan → self-check terhadap acceptance criteria.
Siapkan paket input kecil dan konsisten:
Jika ada yang tidak diketahui, sebutkan dan minta model secara eksplisit daripada menebak diam-diam.
Minta artefak yang bisa Anda tempel ke dokumen, tiket, dan PR:
Ini menjaga keluaran AI agar bersifat aksi dan mengurangi kerja ulang akibat “konteks hilang.”
Gunakan model sebagai pewawancara kebutuhan. Suruh ia:
Mulai dari peran dan aksi, lalu minta:
Setelah alur jelas, peta ke keputusan teknis seperti di mana validasi berakhir dan aturan bisnis dimulai, di mana idempotency diperlukan, dan apa yang harus disimpan vs diturunkan. Ubah alur menjadi acceptance criteria Given/When/Then yang dapat diuji.
Karena LLM akan mengisi celah dengan tebakan yang masuk akal kecuali Anda memaksa pemisahan antara:
Minta log asumsi yang menandai setiap item sebagai terverifikasi atau tidak diketahui, plus:
Paksakan model untuk mengusulkan 2–3 arsitektur yang layak dan bandingkan dalam tabel (kompleksitas, reliabilitas, waktu untuk kirim, skalabilitas, biaya). Lalu minta:
Ini mencegah opsi pertama yang masuk akal menjadi default dan mengurangi perluasan ruang lingkup tersembunyi (penyebab umum penulisan ulang).
Pendekatan contract-first membuat bentuk data dan aturan kompatibilitas menjadi eksplisit. Minta:
/v2; klien mengabaikan field yang tidak dikenal)Ketika UI, backend, dan integrasi berbagi artefak kontrak yang sama, Anda menghabiskan lebih sedikit waktu menyesuaikan asumsi yang mismatch nanti.
Anggap pengulangan 10-butir itu sebagai kontrak yang Anda validasi dengan pemangku kepentingan sebelum memulai desain.
Juga minta “apa yang akan mengubah jawaban Anda?” (mis. volume, latensi, kepatuhan, retensi) agar desain menjadi kondisional dan lebih tahan penulisan ulang.