Praktik: Panduan Langsung Menggunakan 7 Agen untuk Meningkatkan Vibe Coding Menjadi Proses Pengembangan Tingkat Ahli

Penulis @sairahul1 membongkar revolusi alur kerja dari "Vibe Coding" ke "Pabrik Perangkat Lunak": memecah percakapan AI tunggal menjadi 7 agen khusus: Peneliti, Penulis Cerita, Penulis Spesifikasi, Pembuat Backend, Pembuat Frontend, Verifikator Pengujian, Validator Implementasi, masing-masing hanya memiliki satu tanggung jawab, konteks bersih, dan batasan yang ketat.
（Prakata: Apakah MCP yang menghubungkan segala sesuatu ditambah Web3, bisa menjadi gelombang AI narasi seratus kali lipat berikutnya?）
（Tambahan latar: Master investasi terkuat membantu Anda bekerja! Mengumpulkan Buffett, Munger, Cathie Wood… 19 AI Agent membantu analisis pasar Anda）

Daftar Isi Artikel

Toggle

• Masalah yang Tidak Dibicarakan Orang
• Peralihan: dari Vibe Coding ke Pabrik Perangkat Lunak
• Tujuh Agen
  • Agen 1: Peneliti Basis Kode (Codebase Researcher)
  • Agen 2: Penulis Cerita (Story Writer)
  • Agen 3: Penulis Spesifikasi (Spec Writer)
  • Agen 4: Pembuat Backend (Backend Builder)
  • Agen 5: Pembuat Frontend (Frontend Builder)
  • Agen 6: Verifikator Pengujian (Test Verifier)
  • Agen 7: Validator Implementasi (Implementation Validator)
• Bagaimana seluruh rantai berjalan
• Dasar: Sebelum agen dapat berfungsi, Anda membutuhkan ini
  • CLAUDE.md — Memori yang hidup di setiap percakapan
  • Drift Konteks — Pembunuh diam-diam itu
• Hasil: Apa yang benar-benar berubah
  • Sebelum pabrik:
  • Setelah pabrik:
  • Perubahan sejati:
• Buat versi Anda sendiri akhir pekan ini
  • Daftar 8 langkah pengaturan:
• Tujuh Agen — Referensi Cepat

Saya kira saya menggunakan AI untuk menulis kode. Sebenarnya, saya hanya mengetik lebih cepat saja.

Artikel ini akan membahas perbedaan keduanya — dan sistem "7 Agen" yang benar-benar mengubah segalanya.

Simpan artikel ini. Ini akan menghemat beberapa bulan kerja Anda.

Masalah yang Tidak Dibicarakan Orang

Siklus yang tampaknya produktif tapi sebenarnya tidak:

→ Minta Claude buatkan sebuah fitur → Ia keluarkan kode → Ada yang rusak → Tempelkan pesan error kembali → Ia perbaiki → Ada bagian lain yang rusak → Tanya lagi

Hari ke-1: Ini seperti sihir.

Hari ke-30: Waktu yang Anda habiskan untuk mengawasi AI, lebih banyak daripada menulis kode sendiri sebelumnya.

Logika yang sama muncul di tiga tempat berbeda. Claude lupa kebiasaan yang Anda buat dua minggu lalu. Fitur baru merusak fitur lama. Pengujian kurang atau terlalu dangkal.

Suatu hari Anda sadar:** Bukan AI yang gagal, tapi alur kerja Anda yang gagal.**

Inti masalahnya bersifat struktural.

Ketika Anda memasukkan "Bantu saya buat fitur ini" di Claude Code, sebenarnya Anda meminta AI berbicara sekaligus menjalankan peran:

→ Analis Produk → Arsitek → Pengembang Backend → Pengembang Frontend → Insinyur Pengujian → Peninjau Kode

Semua sekaligus dalam satu percakapan yang kacau.

Asumsi yang salah dalam rencana akan menjadi model basis data yang salah. Model basis data yang salah akan menjadi API yang salah. API yang salah akan menjadi UI yang salah.

Ketika Anda menyadarinya, kesalahan sudah menyebar ke mana-mana.

Ini disebut vibe coding (menulis kode berdasarkan feeling).

Ada batas keras yang sangat tinggi.

Peralihan: dari Vibe Coding ke Pabrik Perangkat Lunak

Kunci yang benar-benar mengubah segalanya:

Tim engineering yang sesungguhnya tidak bekerja dalam satu percakapan besar.

Orang berbeda memiliki tugas berbeda:

→ Ada yang memperjelas masalah pengguna → Ada yang memikirkan arsitektur → Ada yang menulis API → Ada yang menulis UI → Ada yang memikirkan batasan dan kondisi ekstrem → Ada yang melakukan review

Ketika semua ini diringkas menjadi satu percakapan AI, kesalahan akan diam-diam menumpuk.

Solusinya adalah memecah pekerjaan ke agen-agen yang berspesialisasi.

Setiap agen akan mendapatkan:

→ Tugas yang fokus → Konteks bersih sendiri → Hanya alat yang benar-benar dibutuhkan → Aturan ketat tentang "wilayah yang tidak boleh disentuh"

Hasilnya:Sebuah pabrik perangkat lunak.

Seorang pengembang + tujuh agen fokus = satu tim yang terkoordinasi.

Berikut adalah tujuh agen yang membuat ini berjalan.

Tujuh Agen

Agen 1: Peneliti Basis Kode (Codebase Researcher)

Kesalahan terbesar pengembang saat menggunakan AI?

Menganggap "minta kode" sebagai langkah pertama.

AI menerima prompt, menebak, mengisi kekosongan, lalu mulai menghasilkan. Desain yang buruk diam-diam masuk di sini.

Peneliti membenahi hal ini.

Tugas utamanya:Memeriksa basis kode dan menjelaskan kondisi saat ini — sebelum satu baris kode ditulis.

Apa yang dilakukan:

• Menandai file terkait dan perannya
• Mencatat pola yang sudah ada
• Menemukan fungsi serupa yang sudah dibuat
• Menandai risiko (zona waktu, multi-penyewa, logika retry)
• Menyusun daftar pengujian yang perlu diperbarui

Apa yang tidak bisa dilakukan:

• Mengedit file (hanya baca)
• Menjalankan perintah yang mengubah status
• Membuat asumsi — harus bertanya

Alat: Read, Grep, Glob, hanya itu.

Aturan: Sebelum mulai, selalu eksplorasi terlebih dahulu.

Peneliti selalu yang pertama jalan.

Agen 2: Penulis Cerita (Story Writer)

Kebanyakan kegagalan fitur bukan karena kode salah.

Tapi karena masalahnya tidak pernah didefinisikan dengan jelas.

Penulis cerita mengubah gambaran kasar menjadi sebuah cerita pengguna yang nyata — sebelum keputusan teknis diambil.

Input:

• Deskripsi fitur kasar Anda
• Hasil investigasi peneliti

Output:

• Cerita pengguna: "Sebagai [peran], saya ingin [tindakan], sehingga [hasil]."
• Kriteria penerimaan: Pernyataan yang bisa langsung diuji. Happy path, jalur gagal, aturan bisnis.
• Kondisi batas: Batas, retry, pertimbangan multi-penyewa.
• Di luar ruang lingkup: Apa yang secara tegas "tidak akan dilakukan".
• Pertanyaan yang belum terjawab: Hal yang benar-benar tidak diketahui — jangan tebak sembarangan.

Apa yang tidak bisa dilakukan:

• Menciptakan aturan bisnis
• Menulis kode atau desain teknis
• Melanjutkan jika ada hal yang benar-benar tidak jelas

Alat: Read, hanya itu.

Aturan: Setelah Anda membaca dan menyetujui cerita ini, baru proses berikutnya berjalan.

Ini adalah kunci agar semua hal di hilir berjalan tanpa kesalahan — Titik review manusia 1.

Agen 3: Penulis Spesifikasi (Spec Writer)

Setelah cerita disetujui, penulis spesifikasi mengubahnya menjadi dokumen teknis.

Dokumen ini menjadi blueprint yang diikuti semua agen pembangunan.

Input:

• Cerita pengguna yang disetujui
• Hasil investigasi peneliti
• Aturan CLAUDE.md proyek Anda

Output:

• Perubahan model data (kolom, tipe, migrasi)
• Alur proses / alur penanganan
• Perubahan API (endpoint, format request/response)
• Perubahan frontend (komponen, halaman, hooks)
• Pengujian yang diperlukan (berhasil, gagal, batas)
• Risiko dan pertanyaan yang belum terjawab
• Daftar file yang akan diubah

Apa yang tidak bisa dilakukan:

• Mengedit file apapun
• Menciptakan infrastruktur baru — harus jelas disebutkan
• Mengabaikan pertimbangan multi-penyewa atau zona waktu
• Meninggalkan pertanyaan tanpa jawaban

Alat: Read, Grep, Glob, hanya itu.

Aturan: Dokumen ini adalah Titik review manusia 2.

Anda harus membacanya dan menyetujuinya, baru file bisa diproses.

Kalau Anda melihat "Simpan ID di memori" — itu bendera merah.

Langsung tangkap sekarang. Jangan tunggu 10 file selesai diubah.

Agen 4: Pembuat Backend (Backend Builder)

Sekarang saatnya membangun.

Pembuat backend mengimplementasikan "setengah bagian belakang" dari fitur — dan hanya itu.

Input:

• Dokumen teknis yang disetujui
• Hasil investigasi peneliti
• CLAUDE.md proyek Anda

Ia membangun:

• Routing API
• Service dan logika bisnis
• Akses basis data dan migrasi
• Tugas background
• Unit test dari apa yang ditulisnya

Apa yang tidak bisa dilakukan:

• Menyentuh komponen React, halaman, hooks client-side (itu tugas Agen 5)
• Menciptakan dependensi baru tanpa instruksi
• Mengubah file di luar scope
• Berhenti tanpa menjalankan typecheck, lint, dan test suite

Setelah selesai, ia mengembalikan ringkasan: file yang ditambah/diubah, pola helper yang digunakan kembali, observasi terkait CLAUDE.md.

Alat: Read, Edit, Write, Bash — hanya di folder backend.

Intinya adalah pemisahan itu sendiri.

Pembuat backend tidak pernah secara tidak sengaja merusak frontend.

Agen 5: Pembuat Frontend (Frontend Builder)

Pembuat frontend mengimplementasikan UI — dan hanya itu.

Ia akan membaca ringkasan dari pembuat backend terlebih dahulu.

Ini penting.

Ia akan mengikuti bentuk API yang dihasilkan backend. Tidak akan menciptakan endpoint baru.

Kalau bentuk API salah untuk UI,akan laporkan ketidaksesuaian — bukan memperbaiki sendiri.

Input:

• Dokumen teknis yang disetujui
• Hasil investigasi peneliti
• Ringkasan API dari backend (kontrak API)

Ia membangun:

• Komponen React dan halaman
• Hooks dan state di sisi klien
• Status loading dan error
• Pengujian komponen dan unit dari apa yang dibuat

Apa yang tidak bisa dilakukan:

• Menyentuh service, routing API, worker, atau migrasi (itu tugas Agen 4)
• Menciptakan endpoint atau format response baru
• Menambahkan dependensi tanpa instruksi
• Berhenti tanpa menjalankan typecheck, lint, dan test suite

Alat: Read, Edit, Write, Bash — hanya di folder frontend.

Dua pembuat ini. Dua konteks bersih. Tidak mungkin satu merusak yang lain.

Agen 6: Verifikator Pengujian (Test Verifier)

Kedua pembuat sudah menulis unit test sendiri.

Tapi itu tidak cukup.

Verifikator pengujian hanya melakukan satu hal:** Membuktikan bahwa fitur benar-benar melakukan apa yang dikatakan cerita pengguna.**

Ia menulis "pengujian acceptance" (penerimaan), bukan unit test.

Pengujian acceptance menguji fungsi dari luar — seperti pengguna nyata yang mengalaminya.

Input:

• Cerita pengguna yang disetujui (termasuk semua kriteria penerimaan)
• Dokumen teknis yang disetujui
• Ringkasan dari kedua agen

Output:

• File pengujian acceptance yang mencakup semua kriteria
• Laporan: mana yang lolos, mana yang gagal, mana yang tidak bisa diliputi dengan bersih

Apa yang tidak bisa dilakukan:

• Mengubah kode backend atau frontend
• Membuat solusi bypass untuk standar yang tidak bisa diuji
• Menandai standar yang tidak tercakup sebagai sudah tercakup

Kalau ada pengujian gagal: fitur tidak memenuhi cerita.

Ia melaporkan "standar mana yang gagal".Tidak memperbaiki kode.

Perbaikan dikembalikan ke pembuat yang benar.

Alat: Read, Edit, Write (hanya file pengujian), Bash.

Aturan: Sebelum pengujian acceptance lolos, Anda belum punya fitur ini.

Agen 7: Validator Implementasi (Implementation Validator)

Ini agen yang menemukan apa yang terlewatkan.

Validator membandingkan implementasi saat ini dengan cerita dan dokumen yang disetujui,melaporkan gap-nya.

Ia tidak pernah memperbaiki apa pun. Ia hanya jujur.

Setiap kali ia berjalan, ia memeriksa:

• Apakah ada standar acceptance yang belum diimplementasikan
• Jalur gagal yang tidak tertutup pengujian
• Isu keamanan: kekurangan izin, celah isolasi penyewa, kunci di log, error mentah bocor ke klien
• File yang diubah di luar scope
• Pola yang tidak sesuai CLAUDE.md atau kode yang sudah ada
• Penggunaan helper yang seharusnya di-reuse tapi dibuat duplikat
• Pertimbangan zona waktu atau multi-penyewa yang diabaikan

Output selalu dikelompokkan berdasarkan tingkat keparahan:

• Critical — wajib sebelum penggabungan
• Important — harus diperbaiki sebelum penggabungan
• Minor — saran, tergantung peninjau

Setiap temuan disertai path file dan nomor baris.

Kalau tidak ada masalah, ia langsung bilang "Tidak ada masalah".Tidak mengada-ada masalah hanya demi terlihat serius.

Alat: Read, Grep, Glob, hanya itu.

Agen ini adalah alasan pabrik ini layak dipercaya.

Laporan penilaian diri tidak bernilai. Validator yang hanya melihat "apa di disk" tanpa memahami "bagaimana itu dibuat" adalah yang jujur.

Bagaimana seluruh rantai berjalan

Proses lengkap — satu prompt memulai semuanya:

Anda buka Claude Code, ketik:

"Bantu saya buat fitur 'Pengingat faktur yang belum dibayar lebih dari 7 hari'."

Lalu Anda tidak perlu mengetik apa pun lagi, ini yang akan terjadi:

Langkah 1 → Peneliti memeriksa faktur, pembayaran, dan kode email Anda. Mengembalikan file terkait, pola yang ada, dan risiko.

Langkah 2 → Penulis cerita menghasilkan cerita pengguna dan kriteria penerimaan.

⏸ Jeda: Anda membaca dan menyetujui cerita.

Langkah 3 → Penulis spesifikasi mengubah cerita yang disetujui menjadi dokumen teknis.

⏸ Jeda: Anda membaca dan menyetujui dokumen. (Di sini temukan kesalahan "Simpan ID di memori".)

Langkah 4 → Pembuat backend mengimplementasikan service, routing API, tugas BullMQ, dan unit test. Mengembalikan: perubahan file, pola reuse, semua pengujian hijau.

Langkah 5 → Pembuat frontend membaca ringkasan API dari backend, membuat UI admin dan tombol pengingat, menulis test komponen. Semua hijau.

Langkah 6 → Verifikator pengujian menulis pengujian acceptance untuk 6 standar. Melaporkan: 7 lolos, 1 gagal — manual trigger tanpa cek kepemilikan penyewa.

Langkah 7 → Validator menemukan masalah. Melaporkan dengan tingkat Critical, lampirkan path file dan nomor baris.

→ Kembali ke pembuat backend. Perbaiki. 8 pengujian lolos semua. Validator jalankan lagi. Bersih.

⏸ Jeda: Anda review dan buat PR.

Tiga review manusia. Sisanya otomatis.

Dasar: Sebelum agen bisa berfungsi, Anda membutuhkan ini

CLAUDE.md — Memori yang hidup di setiap percakapan

Setiap kali Anda membuka Claude Code, ia mulai dari "memori nol".

CLAUDE.md memperbaiki hal ini.

Ini adalah file Markdown di root repo, otomatis dimuat setiap awal percakapan.

Ini adalah tempat "fakta proyek permanen":

• Tumpukan teknologi Anda (Next.js App Router, Node.js, Prisma, BullMQ, Resend)
• Perintah Anda (npm run dev, npm test, npx prisma migrate dev)
• Aturan arsitektur ("Logika bisnis di service. Routing API tetap tipis.")
• Hal yang tidak dilakukan ("Jangan tambahkan cron — pakai BullMQ. Jangan tulis payload pembayaran asli ke log.")
• Indikator dokumentasi mendalam (docs/billing.md, docs/architecture.md)

Jaga tetap di 100–300 baris.

Setiap kali AI melakukan kesalahan mengejutkan, tanyakan: "Kalau CLAUDE.md punya aturan ini, bisa dihindari kali ini?"

Tambah aturan itu.

Beberapa minggu kemudian, CLAUDE.md Anda akan menjadi catatan "semua asumsi yang pernah salah AI" — percakapan Anda akan jauh lebih baik.

Drift Konteks — Pembunuh diam-diam itu

Sebagian besar percakapan Claude Code tidak gagal secara dramatis.

Mereka akan drift.

Sebuah asumsi salah masuk ke konteks. Model terus menumpuk di atasnya.

Anda ingin Claude mengelola "Manajemen Langganan". Ia desain: User → Subscription.

Lalu Anda ingat: langganan milik "perusahaan", bukan "pengguna".

Kalau Anda cuma bilang "Tidak, langganan milik perusahaan" — Claude akan memperbaiki.

Sekarang Anda punya user.subscriptionId dan company.subscriptionId yang keduanya melayang.

Aturan:

• Kesalahan kecil? Perbaiki langsung di inline.
• Asumsi arsitektur salah?** Buang seluruh percakapan, mulai dari awal, dan masukkan asumsi yang benar di prompt pertama.**

Percakapan bersih dengan model yang benar akan selalu lebih baik daripada yang hanya dipasang patch.

Hasil: Apa yang benar-benar berubah

Sebelum pabrik:

• Siklus vibe coding: prompt → generate → error → patch → ulangi
• Konteks percakapan penuh noise
• Asumsi salah menumpuk menjadi fitur rusak
• Seorang engineer hanya bisa melakukan satu hal sekaligus
• Setiap fitur menunggu orang yang tepat punya waktu

Setelah pabrik:

• Rantai terstruktur: Research → Story → Brief → Build → Verify → Confirm
• Setiap agen punya konteks bersih, hanya berisi yang dibutuhkan
• Asumsi salah terdeteksi saat "brief approval" — bukan setelah 10 file
• Seorang engineer bisa mengeluarkan satu potongan lengkap: backend, frontend, pengujian, verifikasi
• Pengetahuan terbaik tim tersimpan di agen — tidak terjebak di "seseorang"

Perubahan sejati:

Seorang ahli pembayaran membuat agen payments-integration. Sejak saat itu, setiap engineer tim bisa mengeluarkan fitur yang melibatkan pembayaran.Tanpa menunggu, tanpa transfer.

Model komponen lead frontend, tinggal di frontend-builder. Insinyur DevOps, cek CI, tinggal di hook. Lead QA, pertimbangan batas, tinggal di aturan test-verifier.

Pengetahuan pakar dibagikan sebagai agen. Tidak terjebak di "siapa yang punya waktu".

Buat versi Anda sendiri akhir pekan ini

Daftar 8 langkah pengaturan:

2. Pasang Claude Code → code.claude.com
3. Buat struktur folder:
   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/
4. Tulis CLAUDE.md Anda (100–300 baris: tumpukan teknologi, perintah, aturan arsitektur, daftar hal yang tidak dilakukan)
5. Gunakan perintah /agents di Claude Code untuk buat 7 agen. Deskripsikan peran masing-masing. Claude buat file. Anda review dan commit.
6. Buat skill orchestrator feature-factory. Minta Claude buatkan — ia akan baca file 7 agen dan sambungkan seluruh rantai.
7. Buat skill build-with-tests. Deskripsikan cara tim Anda membangun: sesuai pola, sambil menulis kode dan tes, lalu jalankan typecheck.
8. Tambahkan hook pre-commit. Blok commit file .env, .key, .pem, secrets.json. 5 menit, hindari bencana besar.
9. Jalankan fitur nyata lengkap. Pilih yang kecil. Amati di mana macet. Tambahkan aturan.Pabrik akan otomatis menyesuaikan.

Total waktu: 2–3 jam.

Jalankan beberapa fitur. Setelah 3–4, pabrik akan mengenal kode Anda.

Anda akan lebih sedikit mengawasi, lebih banyak memutuskan "apa yang berikutnya harus dilakukan".

Tujuh Agen — Referensi Cepat

• Peneliti (Researcher) — Sebelum apapun dibuat, scan kode (hanya baca)
• Penulis Cerita (Story Writer) — Ubah ide kasar jadi cerita pengguna dan kriteria penerimaan (hanya baca)
• Penulis Spesifikasi (Spec Writer) — Ubah cerita jadi dokumen teknis (hanya baca)
• Pembuat Backend (Backend Builder) — Bangun API, service, jobs, unit test (hanya di folder backend)
• Pembuat Frontend (Frontend Builder) — Bangun komponen, halaman, hooks, UI test (hanya di folder frontend)
• Verifikator Pengujian (Test Verifier) — Tulis acceptance test dari cerita pengguna (hanya file test)
• Validator (Validator) — Bandingkan implementasi dengan cerita dan dokumen, laporkan gap (hanya baca)

3 review manusia:

→ Setujui cerita → Setujui dokumen → Setujui PR

Sisanya otomatis.

Sebagian besar pengembang Claude Code masih vibe coding. Prompt → generate → patch → doakan.

Itu tidak salah.Tapi ada batasnya.

Pabrik bukan mengeluarkan Anda dari proses.Ini mengeluarkan Anda dari bagian "tidak perlu penilaian".

Anda tetap di bagian "yang benar-benar penting untuk penilaian Anda":

Apakah ini masalah yang tepat? Apakah ini desain yang benar? Apakah ini aman untuk rilis?

Semua hal di tengah, agen yang bertanggung jawab.

Ini adalah perbedaan antara "menggunakan AI sebagai keyboard lebih cepat" dan "menggunakan AI sebagai tim koordinasi".

Penulis asli: @sairahul1