- Tulisan ini memaparkan prinsip context engineering dan workflow praktis untuk menghasilkan performa dengan model bahasa terbaru di codebase production skala besar
- Intinya adalah Frequent Intentional Compaction, yaitu menstrukturkan dan memadatkan konteks sepanjang proses pengembangan agar kualitas penilaian agen dan trajektori progresnya tetap stabil
- Dengan 3 tahap research → plan → implement, dibuat artefak riset awal dan dokumen rencana, lalu review manusia ditempatkan pada titik berleverage tinggi untuk mengurangi slop dan pengerjaan ulang
- Artikel ini membuktikan pendekatan tersebut efektif bahkan di lingkungan brownfield melalui contoh nyata pada BAML berbasis Rust dengan 300 ribu LOC, termasuk perbaikan bug serta tugas kompleks seperti dukungan cancel/WASM yang diselesaikan dalam waktu singkat
- Kesimpulannya, AI coding bukan mainan melainkan kerajinan rekayasa yang presisi, dan perubahan proses/budaya di tingkat tim menjadi kunci keunggulan kompetitif
Latar belakang: keterbatasan AI dan masalah utama di codebase kompleks
- Sebagian besar developer sudah paham bahwa alat AI coding tidak bekerja sebaik yang diharapkan pada codebase production yang nyata
- Ada hasil riset yang menunjukkan alat AI coding justru menurunkan produktivitas pada codebase besar dan tugas kompleks
- Menurut riset Stanford, porsi besar kode yang ditambahkan oleh alat AI pada akhirnya menjadi pekerjaan berulang karena harus memperbaiki kembali kode kurang matang yang sebelumnya juga dibuat AI
- Agen AI coding efektif untuk proyek baru atau perubahan kecil, tetapi pada codebase besar justru bisa menurunkan produktivitas developer
- Karena itu, respons di lapangan sering kali hati-hati: “untuk saat ini masih sulit, mungkin setelah model yang lebih pintar muncul”
- Namun, ketika context engineering diterapkan pada codebase Rust besar berukuran 300.000 LOC, ternyata model yang ada saat ini pun bisa melampaui standar pasar dalam hal produktivitas dan kualitas
- Kuncinya adalah frequent intentional compaction, yaitu membuat konteks yang diberikan ke AI tetap terstruktur dan terkelola selama seluruh proses pengembangan
- Pada akhirnya, ‘AI coding’ adalah ranah yang memerlukan keahlian teknis ala perajin
Landasan pemikiran: “Specs are the new code” dan riset produktivitas
- Dua presentasi di AI Engineer 2025 mendorong perubahan cara berpikir
- Dalam presentasi Sean Grove "Specs are the new code", ia mengatakan untuk meninggalkan prompt percakapan dan menyimpan spesifikasi sebagai kode
- Kebiasaan membuang prompt dan hanya meng-commit hasil kode diibaratkan seperti check-in binary tanpa source code
- Riset Stanford tentang dampak AI terhadap produktivitas developer mengisyaratkan bahwa meski AI menambah output jangka pendek, penurunan kualitas dan pengerjaan ulang dapat mengurangi dampak bersihnya
- Dari analisis commit 100 ribu developer, terlihat bahwa alat AI memicu kenaikan pengerjaan ulang yang meniadakan keuntungan produktivitas
- Efektif di greenfield, tetapi pada brownfield dan pekerjaan berkesulitan tinggi sering menimbulkan efek sebaliknya
Prinsip: konsep Frequent Intentional Compaction
- Context window dikelola selalu di kisaran 40–60%, dengan strategi pemadatan berkelanjutan untuk meminimalkan kelebihan isi, kekurangan isi, dan misinformasi
- Yang dipadatkan adalah noise seperti log pencarian file, pelacakan alur kode, riwayat perubahan, log test/build, JSON besar, dan sebagainya
- Hasil setiap tahap disimpan sebagai artefak terstruktur untuk menjamin kualitas input pada giliran berikutnya
- Misalnya, dibuat dokumen progress yang mencatat ringkasan progres, tujuan dan pendekatan, tahap yang sudah selesai, serta titik kegagalan saat ini
Workflow: Research → Plan → Implement
- Pada tahap Research, file terkait, alur, dan hipotesis penyebab diteliti untuk menghasilkan dokumen riset ringkas
- Jika perlu, sub-agent dipakai untuk menjelajahi cakupan dan membuat ringkasan dalam konteks yang segar
- Pada tahap Plan, disusun rencana implementasi yang menjelaskan secara rinci file target perubahan, cara perubahan, serta prosedur verifikasi dan pengujian
- Rencana ini dimanfaatkan sebagai titik review berleverage tinggi alih-alih hanya review kode
- Pada tahap Implement, rencana dijalankan bertahap, dan setelah tiap langkah diverifikasi, statusnya dipadatkan ulang ke dokumen rencana agar terakumulasi
- Untuk tugas kompleks, dilakukan penyelarasan ulang konteks setiap kali bergabung pada tiap tahap
Anti-pattern dan peningkatan bertahap
- Pendekatan naif memperlihatkan masalah ketika konteks dalam alur chat tercemar, lalu berujung pada loop permintaan maaf atau keluar jalur
- Cara yang sedikit lebih baik adalah reset sesi dan “prompt tambahan instruksi”, tetapi tetap lemah dalam pengendalian noise secara mendasar
- Pemadatan yang disengaja adalah pendekatan yang lebih baik dengan memakai ringkasan progres (file) dan pesan commit untuk membangun ulang konteks
- Artikel ini juga memberi contoh format artefak pemadatan yang ideal, dengan target optimasi akurasi/kelengkapan/ukuran/trajektori
Sudut pandang teknis tentang optimasi konteks
- Karena LLM adalah fungsi stateless, kualitasnya sepenuhnya ditentukan oleh konteks input
- Urutan kondisi terburuk adalah misinformasi > kekurangan informasi > noise berlebihan
- Semakin kecil konteks, semakin menguntungkan; karena itu inti utamanya adalah pemadatan untuk mendapatkan konsistensi maksimum dari input minimum
- Disebutkan juga sudut pandang alternatif seperti strategi eksekusi agen berbentuk loop sederhana (misalnya proses “Ralph”)
Peran sub-agent: bukan roleplay manusia, melainkan kontrol konteks
- Sub-agent melakukan pencarian/ringkasan/penataan dalam konteks terpisah agar jendela agen utama tetap bersih
- Respons yang ideal dikembalikan dalam bentuk artefak pemadatan terstruktur berisi tujuan/status saat ini/jalur
- Dengan sub-agent, biaya eksplorasi bisa dilokalisasi dan fokus konteks pekerjaan utama bisa ditingkatkan
Kasus 1: perbaikan bug BAML lolos dalam sekali jalan
- Diperlihatkan contoh seorang pendatang baru pada BAML dengan 300 ribu LOC Rust yang berhasil mengajukan dan mendapatkan persetujuan PR perbaikan bug dalam hitungan jam
- Dokumen riset diulang beberapa kali untuk meningkatkan kualitas, lalu implementasi berbasis rencana final berhasil lolos pada percobaan pertama
- Ini memenuhi banyak target dari sisi kesesuaian brownfield, penghilangan slop, dan menjaga alignment
Kasus 2: dukungan cancel/WASM 35k LOC di BAML
- Didemonstrasikan perubahan besar ketika dua orang menambahkan fitur cancel dan dukungan kompilasi WASM hanya dalam 7 jam
- Estimasi tim sebelumnya adalah masing-masing 3–5 hari, tetapi dipersingkat lewat pipeline research/plan/implement
- Sebagian PR langsung di-merge, sementara sebagian lain tetap dibuka pada level demo yang berfungsi, membuktikan kemungkinan menyelesaikan tugas berkesulitan tinggi
Belajar dari keterbatasan dan kegagalan
- Upaya menghapus dependensi Hadoop di Parquet Java menjadi contoh kegagalan karena pendalaman pohon dependensi kurang memadai
- Kesimpulannya: tidak semua masalah bisa diselesaikan dengan prompting selama 7 jam, dan keterlibatan pakar domain tetap diperlukan
- Leverage review manusia meningkat dalam urutan research > plan > code, dan satu baris riset yang salah berisiko berkembang menjadi ribuan baris kesalahan
Dokumentasi sebagai prioritas untuk alignment tim
- Disampaikan pandangan bahwa esensi code review adalah menjaga mental alignment
- Rangkaian PR besar dapat memicu hilangnya pemahaman produk dan kecemasan dalam tim, sehingga spec/plan/research menurunkan biaya alignment
- Engineer bisa membaca dokumen rencana 200 baris lebih sering dan lebih akurat dibanding 2.000 baris kode
- Bahkan saat menangani isu di area asing, prompt riset dapat berfungsi sebagai panduan cepat
Ringkasan akhir dan struktur biaya
- Semua target utama terpenuhi: kompatibel dengan brownfield, menyelesaikan masalah kompleks, meminimalkan slop, dan menjaga alignment tim
- Dari sisi biaya operasional, tim beranggotakan 3 orang menjalankannya dengan biaya token Opus sekitar $12k per bulan
- Meski ada pengecualian, ditekankan bahwa secara keseluruhan ini telah menjadi metodologi yang bekerja
Perubahan ke depan dan produk
- Agen coding akan menjadi komoditas, dan transformasi organisasi serta workflow adalah tantangan sebenarnya
- Di dunia ketika AI menulis 99% kode, perombakan total cara kolaborasi menjadi titik pembeda daya saing
- Untuk mendukung hal ini, alat “post-IDE” bernama CodeLayer dirilis dalam private beta
- Alat ini mengusung visi Superhuman for Claude Code dan mempercepat pengembangan agentic yang spec-first
3 komentar
Iklan berakhir...
Diakhiri dengan pengenalan layanan bernama CodeLayer...
Komentar Hacker News
Bacaan yang menarik dan ada beberapa ide yang segar. Tapi menurut saya ada masalah dengan klaim seperti ini. Sean memprediksi bahwa AI akan berkembang sehingga dokumen spesifikasi nantinya akan menjadi kode yang sesungguhnya. Klaimnya adalah bahwa dalam 2 tahun ke depan, orang akan membuka file Python di IDE sesering orang saat ini membuka hex editor untuk melihat assembly. Katanya, awalnya dia merasa tidak nyaman, tetapi akhirnya menerima cara kerja yang berfokus pada pengujian dan menganggap spesifikasi sebagai sumber yang sebenarnya alih-alih membaca kode di PR satu per satu. Namun, karena masalah non-determinism pada LLM, sebaik apa pun prompt disusun, kita tidak bisa selalu mengharapkan implementasi yang masuk akal. Compiler itu deterministik, dan meski ada bug, bug-nya bisa direproduksi dan di-debug, sedangkan LLM tidak demikian
Bahkan saat bekerja dengan developer junior, implementasi tetap cukup deterministik. Tapi pada model AI, meskipun instruksinya jelas, implementasi yang benar-benar berbeda bisa terus muncul berulang kali
Yang menarik, dokumen spesifikasi itu sendiri sebenarnya sudah non-deterministik. Kalau kita mencoba menulis requirements dalam bahasa Inggris supaya tidak mungkin disalahpahami siapa pun, pada akhirnya itu akan berubah menjadi bahasa pemrograman
Saya setuju dengan kekhawatiran bahwa "prompt bisa saja sempurna, tapi tidak ada jaminan LLM akan mengubahnya menjadi implementasi yang masuk akal". Justru prompt yang ditulis dalam bahasa alami pada dasarnya sering ambigu dan tidak lengkap. Jadi itu bagus untuk area yang membutuhkan hasil kreatif, tetapi jika bahasa alami memang cocok untuk mendefinisikan kebutuhan perangkat lunak, software engineering pasti sudah menyelesaikannya puluhan tahun lalu. Saya sempat sangat antusias pada LLM, tapi rasanya berlebihan jika berharap semua masalah bisa diselesaikan dengannya. Untuk spesifikasi kebutuhan, ini terasa mirip dengan sistem formal dan upaya verifikasi matematis di masa lalu, tetapi berada di ujung yang sangat berlawanan. Walau ini juga mungkin berakhir sebagai kegagalan parsial, saya melihatnya sebagai eksperimen yang memberi wawasan baru tentang pengembangan perangkat lunak. Di sebagian domain, ini akan benar-benar bernilai, dan di tempat lain bisa saja ditinggalkan sepenuhnya. Zaman yang menarik
Sebenarnya, jarang juga ada orang yang menulis spesifikasi teknis atau dokumentasi yang jelas dan rinci. Kalaupun ada, saya juga tidak merasa itu akan menjadi arus utama dalam 2 tahun. Apakah penulis teknis yang benar-benar memahami software engineering secara mendalam akan puas hanya dengan memberi prompt ke agen AI tanpa melihat kode sama sekali? Saya tidak setuju. Ini terasa dekat dengan pola pikir khas "engineer menganggap manusia seperti mesin"
Klaim bahwa "berkat compiler, kita tidak perlu membuka assembly di hex editor setiap kali build" memang benar karena alatnya makin bagus, tetapi di bidang riset ilmiah HPC, dulu sering kali orang tetap membedah assembly secara langsung dengan Intel VTune dan sejenisnya untuk memastikan compiler benar-benar melakukan vectorization pada loop-loop penting
Saya sudah mencoba pola seperti ini di dua codebase yang berbeda. Salah satunya repo monolitik besar apache airflow dengan 500 ribu baris kode, dan yang satunya lagi proyek sampingan pribadi yang dibangun dari nol dengan flutter. Flutter dan dart benar-benar bidang yang tidak saya kuasai. Meski begitu, saya merasa pendekatan ini efektif. Untuk proyek greenfield, hampir cukup menjalankan
/create_plansaja, dan saya bisa memanfaatkan semua bantuan agen. Yang penting adalah meninjau dokumen yang dihasilkan AI dengan cermat. Saya cukup memeriksa sendiri apakah edge case yang saya khawatirkan sudah ditangani, dan apakah pilihan teknisnya masuk akal. Misalnya, saya bisa langsung tahu jika ada keputusan yang salah seperti merekomendasikan postgres sambil merusak pola sqlite. Biasanya saya juga bisa langsung merevisi rencana sambil chat dengan agen. Di kantor saya harus memakai github copilot, jadi prompt-nya perlu sedikit berbeda, tetapi ringkasan yang disengaja (compaction) antar tahap tetap saya lakukan. copilot memang belum mendukung sub-agent seperti claude code, tetapi produktivitasnya tetap lumayan terjaga.Saya juga ingin berbagi satu pengalaman pribadi. Tepat sebelum era bantuan coding AI, saya sangat depresi karena merasa pekerjaan saya makin membosankan. Karena harus berurusan dengan banyak repo, tim, dan karakter orang, pekerjaan di codebase besar selalu penuh tugas remeh. Hal terbaik dari AI coding adalah dia menangani pekerjaan kecil seperti itu dengan mulus. Saya merasa sangat puas saat berhasil membuat sesuatu yang bekerja dengan baik, tetapi berkali-kali kesenangan itu hilang karena terhalang urusan remeh semacam ini. Sekarang saya bisa terus menghasilkan hasil yang baik, dan bahkan merasa bangga pada diri sendiri
Saya membuat paket yang saya gunakan saat bekerja pada codebase besar [GitHub.com/iambateman/speedrun]. Mula-mula saya memasukkan deskripsi fitur dengan
/feature, lalu ia mulai menganalisis codebase dan mengajukan pertanyaan. Setelah saya menjawab, ia menulis rencana dalam format markdown. Di proses ini terbentuk 8–10 file markdown yang berisi apa yang akan dikerjakan dan bahkan contoh kode. Setelah itu ada tahap "code critic", yang mencoba menemukan kesalahan, walaupun sebenarnya 60% salah juga. Saya menyaring error ngawur dari umpan balik itu. Pada titik ini, saya sudah punya folder rapi berisi perubahan yang saya inginkan dan deskripsi fiturnya. Lalu saya tinggal bilang ke Claude Code, “lanjutkan”, dan pekerjaan dimulai langkah demi langkah. Cara ini membantu mencegah arah kerja melenceng, dan membuat saya lebih yakin pada hasil akhirnya. Saya memakai workflow seperti ini beberapa kali sehari untuk pekerjaan besar, dan untuk tugas yang relatif spesifik saya cukup pakai Claude code biasa. Menurut saya ini workflow yang cukup efisienSaya benar-benar tidak paham kenapa orang ingin melalui proses serumit ini. Menurut saya coding biasa dengan sedikit bantuan LLM jauh lebih produktif daripada cara seperti ini
Masalah besar saat memakai LLM pada codebase besar adalah ia mengulang kesalahan yang sama. Saya penasaran bagaimana Anda terus melacak keputusan arsitektur untuk tiap tugas dalam konteks yang berbeda-beda
Kelihatannya keren sekali. Ada tahap pseudo code di tengah, dan saya penasaran apakah mendefinisikan workflow atau proses lebih dulu memang membantu. Saya juga pernah dengar bahwa menjaga tiap file tetap di bawah 100 baris itu penting, dan penasaran apakah Anda merasakan hal serupa
Tulisan ini terasa seperti kapsul waktu dari saat saya benar-benar menyerah pada pengelolaan context di Claude code. Saya membuat spesifikasi terpisah dalam folder untuk tiap bagian kode, berisi log per fitur. Saya mengelola beberapa subsistem server API dengan Python, seperti akun, notifikasi, langganan, dan lain-lain. Saat situasinya makin rumit, Claude jadi tidak bisa memahami business logic dengan baik dan pengelolaan context menjadi sangat sulit. Misalnya, saat saya ingin membuat sistem RBAC sederhana, saya tetap harus memberinya diagram UML dan contoh yang menjelaskan relasi akun-profil agar hasilnya kurang lebih sesuai harapan
research_codebase.mdterlebih dahulu. Kekhawatiran terbesar kami adalah, "kalau codebase ini baru diserahkan ke kami dan kami belum tahu strukturnya, bagaimana kami bisa menyuruh model mengerjakannya?" Dalam kode yang banyak ditulis AI, ada dua masalah. 1) Kalau kita belum familier dengan kodenya, perlu tahap riset agar alur dan fungsinya cepat dipahami 2) Review PR yang sangat besar itu sangat menyakitkan, sedangkan rencana (plan) merangkum secara terstruktur apa yang berubah dan alasannya. Sebagai catatan, Mitchell sangat memuji fitur berbagi thread dari ampcode, dan ini solusi yang bagus untuk poin #2 [https://x.com/mitchellh/status/1963277478795026484]Ada begitu banyak deklarasi dan klaim soal pemanfaatan AI, tetapi hampir tidak ada yang benar-benar membuka proses atau prompt secara konkret. Bicara seolah-olah meyakinkan itu mudah, tetapi agar benar-benar berguna, log prompt harus disimpan. Commit yang dihasilkan AI juga seharusnya menyertakan log prompt apa saja yang diterapkan, sehingga seperti menelusuri log commit, kita juga bisa mengikuti log prompt untuk memahami proses penulisan kodenya
Penulis tulisan ini membanggakan bahwa dia menyelidiki dan mengimplementasikan 35K baris kode dalam 7 jam, padahal kenyataannya ada 40 commit selama 7 hari. Jadi saya bertanya-tanya apakah sebenarnya dia cuma mengerjakannya satu jam per hari. Dan lucunya, salah satu commit terbaru adalah "ignore some tests"
Ada kalimat, "Beberapa minggu kemudian, bersama @hellovai saya menambahkan 35k LOC ke BAML untuk menghadirkan dukungan pembatalan dan kompilasi WASM, serta fitur-fitur baru lainnya. Tim yang sudah ada memperkirakan tiap fitur akan butuh 3–5 hari." Kalau begitu, apakah mereka mengira engineer senior bisa menulis 4–6KLOC per hari? (sebelum genAI?)
Fakta yang hilang di sini adalah bahwa engineer senior kemungkinan sebenarnya akan menyelesaikannya hanya dengan 2KLOC
Dan sebenarnya penulisnya juga mengakui di tempat lain bahwa pekerjaan ini pada praktiknya memakan waktu seminggu https://news.ycombinator.com/item?id=45351546
Saya sangat setuju dengan bagian, "Awalnya tidak nyaman, tapi akhirnya saya berhenti membaca semua kode di PR, dan hanya memeriksa test dengan cermat. Spesifikasi menjadi source yang sebenarnya." Saya merasa peran kita sedang bergeser dari menulis detail implementasi secara langsung menjadi mendefinisikan dan memverifikasi perilaku. Baru-baru ini saya perlu menambahkan recursive upload ke operator Python S3-to-SFTP, dan ada banyak flag jalur yang rumit. Proses saya seperti ini - 1) mengekstrak perilaku yang ada menjadi spesifikasi yang jelas (yakni sambil membuat unit test lolos) 2) memperluas spesifikasi agar sesuai dengan fitur baru 3) memberikan masalah dan test itu ke coding agent. Pada akhirnya, saya sadar bahwa saya sama sekali tidak perlu memahami kode lamanya. Fokus saya hanya pada apakah kode baru mengikuti spesifikasi dengan benar. Di masa depan, nilai kita akan berada pada memverifikasi kebenaran, sedangkan kode aktual akan menjadi detail yang ditangani agen
Saya setuju bahwa "peran kita bergeser dari menulis detail implementasi ke mendefinisikan dan memverifikasi perilaku". Bahkan saya merasa memang itulah pekerjaan utamanya sejak dulu. Berkat bahasa tingkat tinggi, compiler, dan abstraksi lain, waktu yang dipakai untuk menulis detail implementasi terus berkurang
Bagian "fokus saya hanya pada apakah kode baru bekerja sesuai spesifikasi" mengingatkan saya pada Hukum Postel (Postel's Law). Ketika sebuah sistem dipakai luas, perilaku yang teramati pada praktiknya menjadi antarmuka publik dan spesifikasi sistem itu, termasuk semua kekeliruan dan bug implementasinya. Sisi klien dari kode itu juga perlu diuji apakah benar-benar mengikuti spesifikasi, dan kalau ada penyimpangan, penyimpangan itu perlu dideteksi dan ditangani
Claude Plays Pokemon juga menunjukkan hal yang sama. AI lemah dalam menilai apakah sesuatu benar-benar berjalan baik. Ia justru cenderung terus berputar di tempat yang sama. Tetapi jika manusia sesekali meluruskan arahnya, itu bisa menjadi kombinasi yang kuat
Kalau kita benar-benar mencoba mendefinisikan semua aspek perilaku, pada akhirnya kita hampir seperti menulis seluruh kodenya juga. Jika ada satu baris pun di PR yang maknanya tidak langsung bisa dipahami, mungkin berarti perilaku keseluruhannya belum didefinisikan dengan cukup baik
Ada klaim bahwa "dalam beberapa tahun ke depan, dokumen spesifikasi akan menjadi kode yang sebenarnya, dan kita hampir tidak akan pernah membuka file Python lagi". Agar ini terwujud, AI code generation harus 99,9% akurat dan hampir tidak boleh berhalusinasi. Alasan kita mempercayai compiler dan tidak melihat assembly adalah karena kita yakin hasilnya selalu sama dan bebas kesalahan — meskipun sesekali ada bug atau masalah optimisasi, biasanya segera diperbaiki. Saat ini, jika kode yang dihasilkan AI bekerja berbeda dari spesifikasi (yakni, kode aslinya), pada akhirnya manusia tetap harus memperbaikinya lagi
Saya sangat terkesan dengan tips untuk memecah implementasi menjadi unit kerja yang bisa diproses atau ditinjau satu per satu.
ARCHITECTURE.md, dan untuk modul besarDESIGN.mdCLAUDE-feature.md, yang juga merangkum rencana implementasi dan informasi pendukung, seperti elemen apa saja yang bisa diakses dari codebase. Kalau menurut saya ada yang kurang di file itu, atau penjelasannya membingungkan, saya lengkapi dengan prompt tambahan. Di antara prompt yang cukup besar, saya melakukan/reset, lalu menyuruhnya merujuk kembali ke dokumen itu dan memperbaikinya secara iteratif. Saat implementasi yang sebenarnya dimulai, saya/resetsekali lagi, lalu pada setiap checkpoint dalam rencana saya minta/resetlagi sambil memperbarui progres di dokumen. Secara umum ini cukup berjalan lumayan, tetapi saya rasa saya tidak akan terlalu mempercayainya untuk pekerjaan kantor