Compound Engineering: Filosofi Rekayasa Native AI

• Semua unit kerja engineering harus membuat pekerjaan berikutnya menjadi lebih mudah, sebagai metodologi pengembangan software berbunga majemuk yang menata kolaborasi dengan agen AI secara sistematis dengan loop 4 tahap (rencana → eksekusi → ulasan → compound) sebagai inti
• Dalam loop berulang, 80% waktu engineer harus dialokasikan untuk perencanaan dan ulasan, sementara 20% untuk eksekusi dan compound
• Didistribusikan dalam bentuk plugin yang mencakup 26 agen spesialis, 23 perintah workflow, dan 13 skill, serta dapat dipasang di Claude Code, OpenCode, dan Codex
• Delapan anggapan umum dalam pengembangan software lama (kode harus ditulis dengan tangan, setiap baris harus ditinjau manual, dan sebagainya) diajukan sebagai keyakinan yang harus ditinggalkan, dan perlu mengadopsi prinsip baru untuk mengenkode preferensi ke dalam sistem
• Membedakan tingkat adopsi AI oleh developer dari Level 0 (pengembangan manual) hingga Level 5 (eksekusi cloud paralel), serta menawarkan framework komprehensif yang mencakup cara naik level di tiap tahap dan perluasan ke kolaborasi tim, desain, riset, hingga pemasaran

---

Filosofi inti

• Prinsip utamanya adalah bahwa setiap unit kerja engineering harus membuat pekerjaan berikutnya lebih mudah
• Codebase tradisional makin kompleks setiap kali fitur ditambahkan, sehingga setelah 10 tahun lebih banyak waktu habis untuk berjuang melawan sistem
• Dalam Compound Engineering, fitur mengajarkan kemampuan baru kepada sistem, perbaikan bug menghapus seluruh kategori bug di masa depan, dan pola diubah menjadi alat sehingga codebase makin mudah dipahami, diubah, dan dipercaya seiring waktu

Loop utama: Plan → Work → Review → Compound

• Tim Every mengoperasikan 5 produk (Cora, Monologue, Sparkle, Spiral, Every.to) terutama dengan tim engineering satu orang, dan yang memungkinkan hal itu adalah loop 4 tahap ini
• Tiga tahap pertama (perencanaan, eksekusi, ulasan) bersifat umum, tetapi tahap Compound ke-4 adalah pembeda utama tempat manfaat majemuk terakumulasi
• Baik itu perbaikan bug 5 menit maupun pengembangan fitur beberapa hari, loop yang digunakan tetap sama, hanya waktu yang dialokasikan per tahap yang disesuaikan

• Tahap 1: Plan (Rencana)

  • Memahami requirement: memahami apa yang akan dibuat, mengapa dibuat, dan batasannya
  • Meneliti codebase: menganalisis cara kerja fitur serupa dan pola yang sudah ada
  • Riset eksternal: memeriksa dokumentasi framework dan best practice industri
  • Merancang solusi: menentukan pendekatan dan file yang akan diubah
  • Memvalidasi rencana: memastikan kelengkapan dan konsistensi keseluruhan rencana

• Tahap 2: Work (Eksekusi)

  • Menyiapkan lingkungan terisolasi: memisahkan pekerjaan dengan Git worktree (salinan repositori yang terisolasi) atau branch
  • Menjalankan rencana: agen mengimplementasikan langkah demi langkah
  • Menjalankan validasi: setelah setiap perubahan, lakukan test, linting (pemeriksaan kode otomatis), dan type check
  • Melacak progres dan merevisi rencana bila muncul isu
  • Jika percaya pada rencana, tidak perlu mengawasi setiap baris kode

• Tahap 3: Review (Ulasan)

  • Beberapa agen meninjau kode secara paralel
  • Temuan diprioritaskan menjadi P1 (wajib diperbaiki), P2 (disarankan diperbaiki), P3 (peningkatan)
  • Agen memperbaiki isu berdasarkan feedback ulasan dan memverifikasi hasil perbaikannya
  • Mencatat pola: mendokumentasikan apa yang salah untuk mencegah terulang

• Tahap 4: Compound — tahap paling penting

  • Pengembangan tradisional berhenti di tahap 3, tetapi pada tahap Compound perbaikan sistem terus terakumulasi
  • Jika tiga tahap pertama menghasilkan fitur, tahap ke-4 menghasilkan sistem yang membuat fitur dengan lebih baik
  • Pekerjaan yang dilakukan:
    • Menangkap apa yang efektif, apa yang tidak, dan insight apa yang bisa dipakai ulang
    • Menambahkan metadata, tag, dan kategori dengan YAML frontmatter agar bisa dicari
    • Menambahkan pola baru ke CLAUDE.md dan membuat agen baru bila perlu
    • Memverifikasi, “Apakah sistem bisa menangkap masalah ini secara otomatis lain kali?”

Struktur plugin

• 26 agen spesialis: ulasan (14), riset, desain, workflow, dokumentasi, dan lain-lain, masing-masing dikhususkan untuk tugas tertentu
• 23 perintah workflow: loop utama + utilitas
• 13 skill: menyediakan keahlian domain seperti arsitektur native agen dan style guide
• Dapat dipasang dengan zero configuration di Claude Code, OpenCode (eksperimental), dan Codex (eksperimental)

• Struktur file

  • CLAUDE.md: file terpenting yang dibaca agen saat memulai setiap sesi, menyimpan preferensi, pola, dan konteks proyek
  • docs/solutions/: masalah yang sudah diselesaikan diakumulasikan sebagai dokumen yang dapat dicari untuk membangun institutional knowledge
  • docs/brainstorms/: menyimpan output perintah brainstorm
  • docs/plans/: menyimpan output perintah plan
  • todos/: melacak item pekerjaan berdasarkan prioritas dan status

Perintah inti

• /workflows:brainstorm

  • Perintah yang digunakan saat belum jelas apa yang akan dibuat
  • Setelah riset repo ringan, sistem mengklarifikasi satu per satu tujuan, pengguna, batasan, dan edge case melalui pertanyaan
  • AI mengusulkan pendekatan, dan hasilnya disimpan di docs/brainstorms/ lalu di-handoff ke /workflows:plan

• /workflows:plan

  • Menjelaskan apa yang diinginkan akan menghasilkan rencana implementasi
  • Menjalankan 3 agen riset paralel: repo-research-analyst (pola codebase), framework-docs-researcher (dokumentasi), best-practices-researcher (standar industri)
  • Agen spec-flow-analyzer menganalisis alur pengguna dan edge case
  • Saat mode ultrathink diaktifkan, /deepen-plan berjalan otomatis dan mengaktifkan lebih dari 40 agen riset paralel

• /workflows:work

  • Tahap ketika agen benar-benar menulis kode
  • 4 fase: quick start (membuat Git worktree dan menyiapkan branch) → execute (implementasi per tugas sambil melacak progres) → quality check (opsional menjalankan lebih dari 5 agen reviewer) → ship it (menjalankan linting, membuat PR)

• /workflows:review

  • PR ditinjau serentak secara paralel oleh lebih dari 14 agen spesialis
  • Mencakup keamanan (security-sentinel), performa (performance-oracle), arsitektur (architecture-strategist), integritas data (data-integrity-guardian), kualitas kode (code-simplicity-reviewer), reviewer khusus framework (DHH-rails, Kieran-rails/python/typescript), verifikasi deployment, race condition frontend, hingga reviewer native agen
  • Output berupa satu daftar prioritas yang diklasifikasikan menjadi P1 (kritis), P2 (penting), P3 (minor)
  • Perintah /resolve_pr_parallel secara otomatis memperbaiki temuan (mengutamakan P1, setiap perbaikan dieksekusi secara terisolasi)
  • Perintah /triage memungkinkan temuan difilter dengan menyetujui/melewati/mengkustomisasi satu per satu

• /workflows:compound

  • Mendokumentasikan masalah yang telah diselesaikan untuk referensi masa depan
  • Menjalankan 6 sub-agen paralel: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Menghasilkan Markdown yang dapat dicari dengan YAML frontmatter

• /lfg

  • Jika fitur dijelaskan, agen akan melakukan semuanya dari perencanaan, implementasi, hingga ulasan dan mengajukan PR siap merge
  • Merangkai seluruh pipeline plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Setelah persetujuan rencana, proses berjalan otonom dengan lebih dari 50 agen aktif di seluruh tahap

8 keyakinan yang harus ditinggalkan

• "Kode harus ditulis dengan tangan"

  • Kebutuhan sebenarnya adalah menulis kode yang baik, mudah dipelihara, dan menyelesaikan masalah yang tepat; siapa yang mengetik tidaklah penting

• "Setiap baris harus ditinjau secara manual"

  • Review manual per baris hanyalah salah satu cara menjamin kualitas; sistem otomatis yang menangkap isu yang sama juga valid
  • Jika hasilnya belum bisa dipercaya, jangan menutupinya dengan mengerjakan sendiri; sistemnya yang harus diperbaiki

• "Solusi harus datang dari engineer"

  • Karena AI bisa meneliti pendekatan, menganalisis trade-off, dan merekomendasikan opsi, peran engineer adalah menambahkan taste — menilai solusi mana yang cocok untuk codebase ini, tim ini, dan konteks ini

• "Kode adalah output utama"

  • Sistem yang menghasilkan kode lebih bernilai daripada kode individual
  • Yang penting bukan satu implementasi hebat, melainkan proses yang secara konsisten menghasilkan implementasi yang baik

• "Menulis kode adalah pekerjaan inti"

  • Pekerjaan developer adalah mengirimkan nilai (ship value), dan kode hanyalah salah satu inputnya
  • Perencanaan, review, dan melatih sistem juga termasuk pekerjaan

• "Percobaan pertama harus bagus"

  • Tingkat cacat pada percobaan pertama adalah 95%, bahkan yang kedua pun 50%
  • Ini bukan kegagalan, melainkan proses; fokusnya harus pada iterasi cepat agar percobaan ketiga selesai lebih cepat daripada percobaan pertama

• "Kode adalah ekspresi diri"

  • Kode adalah milik tim, produk, dan pengguna; jika tidak melihat kode sebagai ekspresi diri, menerima masukan, melakukan refactor, dan berdebat soal kualitas menjadi lebih mudah

• "Semakin banyak mengetik, semakin banyak belajar"

  • Saat ini, pemahaman lebih penting daripada memori otot
  • Developer yang me-review 10 implementasi AI akan memahami lebih banyak pola daripada developer yang mengetik sendiri 2 implementasi

Tantangan psikologis dalam proses transisi

• Saat mengetik berkurang, terasa seperti bekerja lebih sedikit: padahal memberi instruksi ke agen menuntut lebih banyak pemikiran daripada implementasi langsung
• Kecemasan terhadap eksekusi otonom: ini bukan soal melepaskan kontrol, tetapi mengenkodekan kontrol ke dalam constraint, aturan, dan proses review
• Pertanyaan "apakah ini benar-benar buatan saya?": merencanakan, me-review, dan memastikan standar kualitas itulah pekerjaannya; AI hanya melakukan penulisan

Keyakinan yang perlu diadopsi

• Mengekstrak taste ke dalam sistem

  • Taste developer seperti aturan penamaan, pola penanganan error, dan pendekatan testing biasanya tidak terdokumentasi dan hanya ada di kepala engineer senior
  • Preferensi ini perlu dicatat di CLAUDE.md atau AGENTS.md, lalu membangun agen dan skill khusus untuk review, testing, dan deployment agar AI bisa langsung menghasilkan kode yang layak disetujui

• Aturan 50/50

  • 50% waktu engineering dialokasikan untuk pengembangan fitur, 50% untuk perbaikan sistem
  • Secara tradisional pembagiannya 90% fitur/10% lainnya, tetapi membuat agen review, mendokumentasikan pola, dan membangun generator test adalah investasi yang mempermudah fitur di masa depan
  • Investasi 1 jam pada agen review bisa menghemat 10 jam waktu review selama 1 tahun

• Percayai proses dan bangun jaring pengaman

  • Agar bantuan AI bisa diskalakan, manusia tidak mungkin me-review setiap baris, jadi yang penting adalah membangun guardrail seperti test, review otomatis, dan monitoring
  • Jika output belum bisa dipercaya, jangan kembali ke review manual; tambahkan sistem yang membuat tahap tersebut dapat dipercaya

• Susun lingkungan yang agent-native

  • Apa pun yang bisa dilihat atau dilakukan developer juga harus bisa dilakukan agen: menjalankan test, memeriksa log production, debugging dengan screenshot, membuat PR, dan sebagainya
  • Setiap tugas yang tidak diizinkan untuk agen akan harus dilakukan manual

• Manfaatkan paralelisasi

  • Bottleneck di masa lalu adalah perhatian manusia (satu tugas dalam satu waktu), sedangkan bottleneck baru adalah compute (berapa banyak agen yang bisa berjalan bersamaan)
  • Jalankan banyak agen dan banyak fitur secara bersamaan, serta lakukan review, testing, dan dokumentasi secara paralel

• Perencanaan adalah kode baru

  • Dokumen rencana kini menjadi output terpenting
  • Daripada menulis kode dulu lalu mendokumentasikannya belakangan, tulis rencana lebih dulu agar agen dapat memakainya sebagai source of truth untuk menghasilkan, menguji, dan memverifikasi kode
  • Merevisi ide di atas kertas lebih murah daripada merevisinya di dalam kode

• Ringkasan prinsip inti

  • Setiap unit kerja harus membuat pekerjaan berikutnya lebih mudah
  • Taste harus ditanamkan ke dalam sistem, bukan ke review
  • Jangan bekerja sendiri secara langsung; ajari sistemnya
  • Bangun jaring pengaman, bukan proses review
  • Strukturkan lingkungan agar agent-native
  • Terapkan compound thinking di semua tempat
  • Terima ketidaknyamanan dalam delegasi, dan pilih hasil yang tidak sempurna tetapi dapat diskalakan daripada hasil yang sempurna tetapi tidak bisa diskalakan
  • Tulis lebih sedikit kode dan kirimkan lebih banyak nilai
  • Prinsip-prinsip ini dapat meluas melampaui engineering ke desain, riset, penulisan, dan bidang apa pun yang terbantu oleh pengodean taste dan konteks

Tahap pertumbuhan developer (tangga 5 tahap)

• Stage 0: Pengembangan manual

  • Menulis kode baris demi baris tanpa AI, meneliti lewat dokumentasi dan Stack Overflow, debugging dengan print statement
  • Selama puluhan tahun cara ini menghasilkan software yang baik, tetapi di tahun 2025 ini tidak lagi cukup cepat

• Stage 1: Bantuan berbasis chat

  • Bertanya ke ChatGPT, Claude, Cursor, dan lainnya untuk mendapatkan potongan kode, lalu menyalin-tempel yang berguna
  • AI mempercepat riset dan pembuatan boilerplate, tetapi setiap baris tetap direview langsung sambil mempertahankan kontrol penuh

• Stage 2: Tool agentic + review per baris

  • Tool agentic seperti Claude Code, Cursor Composer, dan Copilot Chat membaca file dan langsung mengubah codebase
  • Berperan sebagai gatekeeper yang menyetujui/menolak semua yang diusulkan agen
  • Sebagian besar developer mandek di tahap ini sehingga tidak mendapatkan manfaat delegasi ke AI

• Stage 3: Rencana dulu, review setingkat PR

  • Ini tahap ketika semuanya berubah: rencana rinci yang mencakup kebutuhan, pendekatan, dan edge case ditulis bersama AI
  • Setelah perencanaan selesai, AI mengimplementasikan tanpa pengawasan, lalu outputnya direview sebagai PR
  • Compound Engineering dimulai di sini — perencanaan, implementasi, dan review di tiap siklus melatih sistem sehingga siklus berikutnya menjadi lebih cepat dan mudah

• Stage 4: Ide → PR (satu mesin)

  • Cukup berikan ide, lalu agen menangani seluruh proses: riset codebase, perencanaan, implementasi, testing, self-review, perbaikan isu, hingga membuat PR
  • Keterlibatan menyusut menjadi 3 langkah: memberi ide, me-review PR, lalu merge
  • Namun semuanya masih berjalan satu per satu di satu komputer

• Stage 5: Eksekusi cloud paralel (multi-device)

  • Eksekusi dipindahkan ke cloud untuk berjalan paralel
  • Tiga agen bisa dikerahkan sekaligus untuk tiga fitur, lalu PR direview saat selesai
  • Agen juga bisa memantau masukan dan secara proaktif mengusulkan perbaikan
  • Perannya bukan lagi sebagai kontributor individual, melainkan memimpin armada agen

Panduan Naik Level

• 0 → 1: Mulai berkolaborasi

  • Pilih satu alat (Cursor with Opus 4.5 atau Claude Code, dll.) dan gunakan setiap hari
  • Sebelum menulis kode, minta AI menjelaskan kode yang sudah ada untuk memeriksa pemahaman
  • Delegasikan boilerplate terlebih dahulu, seperti test, file konfigurasi, dan fungsi berulang
  • Tinjau setiap baris untuk belajar
  • Pekerjaan compounding: terus catat prompt yang bekerja dengan baik

• 1 → 2: Izinkan akses agen

  • Beralih ke mode agentic dan berikan agen hak akses ke file system
  • Mulai dari perubahan sempit pada satu file dengan satu tujuan, seperti "tambahkan test untuk fungsi ini"
  • Bangun intuisi kepercayaan dengan menyetujui/menolak tiap aksi
  • Tinjau diff untuk fokus pada bagian yang berubah
  • Pekerjaan compounding: buat file CLAUDE.md, tambahkan catatan saat agen melakukan kesalahan

• 2 → 3: Percayai rencana (peralihan inti)

  • Tulis requirement, pendekatan, dan edge case sebagai rencana yang eksplisit
  • Izinkan AI membaca codebase, menemukan pola, dan mengusulkan pendekatan
  • Setelah rencana ditulis, serahkan implementasi ke agen dan tinggalkan sampai selesai
  • Lakukan review pada level PR, bukan pada tiap langkah atau baris kode
  • Pekerjaan compounding: setelah tiap implementasi, dokumentasikan bagian yang terlewat dari rencana

• 3 → 4: Sajikan hasil, bukan instruksi

  • Berikan hasil (outcome) seperti "tambahkan notifikasi email untuk komentar baru", dan biarkan agen menentukan cara implementasinya
  • Karena agen memahami codebase dan melakukan riset, rencana juga menjadi tanggung jawab agen
  • Tinjau pendekatan sebelum implementasi untuk menghentikan arah yang salah lebih awal
  • Pekerjaan compounding: bangun pustaka instruksi berbasis hasil yang terbukti efektif

• 4 → 5: Paralelkan semuanya

  • Pindahkan eksekusi ke cloud untuk menghilangkan bottleneck mesin lokal
  • Tugaskan 3 fitur ke 3 agen secara bersamaan
  • Susun ide, bug, dan perbaikan sebagai queue agar agen memprosesnya satu per satu
  • Aktifkan agar agen memantau feedback pengguna dan secara proaktif mengusulkan fitur
  • Pekerjaan compounding: bedakan dan dokumentasikan tugas yang bisa dijalankan paralel dan yang secara inheren serial

Tiga pertanyaan sebelum menyetujui output AI

• "Apa keputusan paling sulit di sini?" — mendorong AI mengungkap bagian rumit dan titik pertimbangannya
• "Alternatif apa yang ditolak, dan mengapa?" — memeriksa opsi yang dipertimbangkan untuk menangkap pilihan yang keliru
• "Bagian mana yang paling tidak kamu yakini?" — membuat LLM mengakui kelemahannya sendiri, tetapi ia hanya akan menjawab jika ditanya langsung

Arsitektur agent-native

• Kuncinya adalah memberi agen kapabilitas yang sama seperti developer
• Jika agen tidak bisa menjalankan test, Anda harus menjalankannya sendiri; jika tidak bisa melihat log, Anda harus debug sendiri, jadi setiap kapabilitas yang tidak diizinkan berubah menjadi pekerjaan manual

• Checklist agent-native

  • Lingkungan pengembangan: menjalankan aplikasi lokal, menjalankan test suite, menjalankan linter dan type checker, DB migration, seed data pengembangan
  • Pekerjaan Git: membuat branch, commit, push ke remote, membuat PR, membaca komentar PR
  • Debugging: melihat log lokal/production (read-only), screenshot UI, memeriksa network request, akses ke error tracking (seperti Sentry)

• Penerapan agent-native secara bertahap

  • Level 1 (pengembangan dasar): akses file, menjalankan test, Git commit — memungkinkan Compound Engineering dasar
  • Level 2 (lokal penuh): akses browser, log lokal, pembuatan PR — memungkinkan Stage 3~4
  • Level 3 (visibilitas production): log production (read-only), error tracking, dashboard monitoring — memungkinkan agen melakukan debugging proaktif
  • Level 4 (integrasi penuh): sistem tiket, kapabilitas deployment, integrasi layanan eksternal — memungkinkan Stage 5

• Mindset agent-native

  • Saat membangun fitur: "Bagaimana agen akan berinteraksi dengan ini?"
  • Saat debugging: "Apa yang perlu bisa dilihat agen?"
  • Saat mendokumentasikan: "Bisakah agen memahami ini?"

Skip Permissions

• Flag --dangerously-skip-permissions di Claude Code menonaktifkan permintaan izin yang biasanya muncul pada setiap aksi
• Namanya sengaja terdengar menakutkan agar mendorong pertimbangan matang sebelum digunakan

• Kapan digunakan

  • Disarankan: saat ada sistem rencana dan review yang baik, saat bekerja di lingkungan sandbox, saat butuh kecepatan
  • Sebaiknya dihindari: saat masih belajar (permintaan izin membantu pemahaman), saat mengerjakan kode production, saat tidak ada mekanisme rollback

• Mekanisme keamanan saat melewati izin

  • Git sebagai jaring pengaman: pekerjaan agen tercatat di Git dan bisa dipulihkan dengan git reset --hard HEAD~1
  • Test menangkap kesalahan: jalankan test sebelum merge
  • Review sebelum merge: izin bisa dilewati selama implementasi, tetapi review akhir wajib dilakukan
  • Isolasi risiko dengan Worktree: eksperimen pekerjaan berisiko di direktori terisolasi

• Perhitungan produktivitas

  • Tanpa melewati izin, prompt muncul sekitar setiap 30 detik, dan harus mengetik "y" setiap kali sehingga fokus terpecah
  • Dengan melewati izin, flow state tetap terjaga, memungkinkan iterasi 5~10x lebih cepat dan penghematan waktu ini jauh melampaui risiko rollback sesekali

Workflow desain

• Pendekatan Baby App

  • Buat proyek sekali pakai (baby app) yang memungkinkan iterasi bebas tanpa khawatir soal test, arsitektur, atau perubahan yang breaking
  • Jika desainnya memuaskan, ekstrak warna, spacing, tipografi, dan pola komponen lalu pindahkan ke proyek utama

• Loop eksplorasi UX

  • Buat beberapa versi, lakukan click-through, dan bagikan prototipe fungsional ke pengguna untuk mengumpulkan feedback
  • Tidak seperti mockup Figma, ini benar-benar bisa diklik
  • Prototipe digunakan untuk belajar, lalu dibangun ulang dari nol dengan rencana yang tepat

• Kolaborasi dengan desainer: alur Compound

  • Alur tradisional: mockup desainer → interpretasi developer → revisi berulang
  • Alur Compound: mockup Figma desainer → kirim link Figma ke /plan → AI mengimplementasikan → agen figma-design-sync memeriksa apakah implementasi sesuai dengan mockup → desainer me-review versi live, bukan screenshot

• Mengodekan selera desain

  • Bekerja bersama desainer pada beberapa fitur, lalu catat pola yang ditemukan (warna favorit, layout form, dll.) ke dalam file skill
  • AI dapat menghasilkan desain yang sesuai selera desainer bahkan tanpa kehadiran desainer

• Agen desain

  • design-iterator: menganalisis screenshot desain saat ini dan mengulang perbaikan untuk pemurnian bertahap
  • figma-design-sync: mengambil desain dari Figma, membandingkannya dengan implementasi, lalu memperbaiki perbedaannya secara otomatis
  • design-implementation-reviewer: memeriksa apakah implementasi sesuai dengan spesifikasi Figma untuk menangkap bug visual sebelum sampai ke pengguna

Vibe Coding

• Pendekatan untuk orang yang hanya menginginkan hasil, bukan kode itu sendiri: product manager, desainer, proyek pribadi, dll.
• Lewati tangga dan langsung ke Stage 4: jelaskan yang diinginkan → agen menangani rencana, kode, test, review, dan PR
• Cocok untuk: proyek pribadi, prototipe, eksperimen, investigasi "apakah ini mungkin?", alat internal, eksplorasi UX
• Tidak cocok untuk: sistem production dengan pengguna, kode yang akan dipelihara orang lain, aplikasi sensitif keamanan, sistem yang kritis terhadap performa

• Paradoks Vibe Coding

  • Vibe Coding justru dapat meningkatkan kemampuan perencanaan
  • Saat belum tahu apa yang akan dibuat, buat prototipe untuk mengumpulkan feedback pengguna, lalu hapus semuanya dan mulai lagi dengan rencana yang tepat
  • Distribusi optimal: temukan lewat vibe coding, bangun dengan spec — dalam implementasi akhir, spec selalu menang

Kolaborasi tim

• Dinamika tim baru

  • Tradisional: orang A menulis kode → orang B me-review → diskusi komentar PR → merge setelah disetujui
  • Compound: orang A membuat rencana → AI mengimplementasikan → agen AI me-review → orang B me-review ulasan AI → merge setelah persetujuan manusia

• Standar tim

  • Persetujuan rencana: diam bukan berarti setuju, jadi perlu sign-off eksplisit sebelum implementasi
  • Kepemilikan PR: terlepas dari siapa yang menulis kode, orang yang memulai pekerjaan memiliki PR, dan bertanggung jawab atas kualitas rencana, review, revisi, serta dampak setelah merge
  • Fokus review manusia: pada PR yang sudah dianalisis oleh agen review AI, manusia me-review bukan pada error sintaks, keamanan, performa, atau style, melainkan berpusat pada intent — "Apakah ini sesuai dengan yang telah disepakati?", "Apakah pendekatannya masuk akal?", "Apakah ada isu business logic?"

• Pola komunikasi

  • Asinkron sebagai default: tidak perlu rapat untuk membuat, me-review, dan menyetujui rencana, "Saya sudah membuat dokumen rencana, mohon komentarnya hari ini"
  • Handoff eksplisit: mencakup status, apa yang sudah selesai, pekerjaan yang tersisa, konteks, dan cara melanjutkan

• Pola skalasi

  • Kepemilikan yang jelas + update asinkron: untuk setiap fitur utama, satu pemilik menangani rencana, monitoring, review, merge, dan update ke tim
  • Feature flag + PR kecil: semakin cepat semua orang melakukan deploy, semakin banyak konflik merge; deploy dalam unit kecil, sering merge ke main, dan selesaikan konflik seketika
  • Dokumen Compound = pengetahuan yang sebelumnya tersimpan di kepala orang tertentu: alih-alih "tanya Sarah, dia paham auth", Sarah menjalankan /compound untuk mendokumentasikan solusi sehingga siapa pun bisa mencarinya

Riset pengguna

• Kesenjangan riset-pengembangan

  • Tradisional: researcher melakukan wawancara → menulis laporan → dibiarkan di Google Drive → developer tidak membaca laporan → fitur tidak mencerminkan kebutuhan pengguna
  • Compound: riset menghasilkan insight terstruktur → insight digunakan sebagai konteks rencana → AI merujuk insight saat membuat rencana → data penggunaan memvalidasi insight → insight terakumulasi secara majemuk

• Menstrukturkan riset

  • Mengubah catatan wawancara mentah menjadi Markdown terstruktur agar bisa dimanfaatkan AI: mencakup informasi partisipan, insight utama, kutipan, implikasi, dan tingkat keyakinan (n/5 partisipan)

• Dokumen persona

  • Membuat dokumen persona yang mencakup tujuan, keluhan, dan kutipan agar dapat dirujuk AI

• Perencanaan berbasis riset

  • Saat menjalankan /workflows:plan, sertakan konteks riset (hasil wawancara, pola persona, pain point saat ini) agar insight riset terhubung langsung ke fitur

Ekstraksi pola data

• Cara pengguna memakai produk adalah petunjuk untuk mengetahui apa yang harus dibangun

• Jenis pola yang perlu diperhatikan

  • Pola penggunaan berlebihan: fitur yang dipakai jauh lebih sering dari perkiraan, kunjungan berulang ke halaman yang sama
  • Pola kesulitan: waktu tinggal tinggi di halaman sederhana, upaya berulang untuk aksi yang sama, loop error → coba lagi → error
  • Pola workaround: mengekspor data dari satu tempat lalu mengimpornya kembali ke tempat lain, copy-paste antar layar, membuka banyak tab sekaligus untuk membandingkan
  • Pola drop-off: keluar dari flow, fitur yang dimulai tetapi tidak pernah diselesaikan

• Dari pola menjadi fitur

  • Pengguna copy-paste data antar tabel 50 kali per minggu → dijadikan fitur tombol "Sync ke tabel B"
  • Pengguna membuat proyek "template" lalu menduplikasinya → dijadikan fitur dukungan template kelas satu

Copywriting

• Sertakan copy dalam rencana

  • Kebanyakan tim memperlakukan copy sebagai prioritas belakangan yang diisi setelah fitur dibangun, padahal copy adalah bagian dari pengalaman pengguna
  • Jika sejak tahap perencanaan sudah mencakup copy yang dilihat pengguna seperti subjek email, pesan sukses, dan pesan error, maka copy sudah siap saat AI mengimplementasikan

• Mengodekan voice

  • Tulis prinsip (berbicara seperti manusia, pesan error harus membantu, kalimat singkat, kata yang jelas) dan kata yang harus dihindari (Invalid → didn't work, Error → jelaskan apa yang terjadi, dll.) dalam file skill

• Review copy

  • Tambahkan review copy ke proses /workflows:review: agen copy-reviewer yang memeriksa berdasarkan 4 kriteria, yaitu kejelasan, seberapa membantu, tone, dan konsistensi

Product marketing

• Alur Compound

  • Engineer membuat rencana yang mencakup product value proposition → AI mengimplementasikan fitur → AI membuat release notes dari rencana → dari release notes AI membuat post media sosial → Playwright mengambil screenshot secara otomatis → engineer me-review lalu merilis semuanya sekaligus
  • Karena semuanya mengalir di satu tempat, tidak perlu handoff dan tidak ada celah

• Pembuatan release notes

  • Karena AI memiliki rencana, perubahan kode, dan test, AI dapat mengetahui dengan tepat apa yang dibangun
  • Utamakan manfaat bagi pengguna, sertakan 1 contoh spesifik, sebutkan breaking change, maksimal 200 kata

• Pembuatan changelog

  • Dengan perintah /changelog, periksa merge terbaru ke main, lalu baca setiap rencana/PR untuk membuat changelog yang menarik

• Screenshot otomatis

  • Gunakan Playwright untuk mengambil screenshot pemasaran secara otomatis, tidak perlu meminta screenshot ke tim engineering, dan mengatasi masalah screenshot yang kedaluwarsa