Memperluas LLM ke Codebase Skala Besar

 (blog.kierangill.xyz)
9 poin oleh GN⁺ 2025-12-24 | 1 komentar | Bagikan ke WhatsApp
  • Untuk memanfaatkan LLM secara efektif dalam codebase skala besar, investasi pada ‘guidance’ dan ‘oversight’ adalah kuncinya
  • Guidance menyediakan konteks dan lingkungan agar LLM dapat membuat pilihan yang lebih baik, sementara oversight berperan memverifikasi hasil dan memberi arahan
  • Penting untuk membangun prompt library agar LLM dapat memahami aturan, dokumentasi, dan best practice dalam codebase
  • Pengelolaan technical debt serta kesederhanaan struktur kode, modularisasi, dan konsistensi terhubung langsung dengan peningkatan pemahaman kode dan produktivitas LLM
  • Sistem oversight dan verifikasi otomatis untuk membantu LLM menghasilkan kode yang aman dan konsisten adalah kunci skalabilitas jangka panjang

Konsep inti untuk penskalaan LLM

  • Cara menerapkan LLM pada codebase skala besar masih belum sepenuhnya mapan, tetapi investasi pada guidance dan oversight diajukan sebagai pendekatan yang paling efektif
  • Guidance berarti konteks dan lingkungan yang membantu LLM membuat pilihan yang tepat, sedangkan Oversight bertugas memverifikasi hasil yang dihasilkan dan menyesuaikan arah

Investasi pada guidance

  • Agar LLM dapat mencapai ‘one-shotting’ yaitu menghasilkan kode berkualitas tinggi dalam satu percobaan, dibutuhkan guidance yang jelas
    • Sebaliknya, jika hasilnya tidak memadai dan perlu diperbaiki secara manual, itu menjadi rework yang tidak efisien
  • Karena LLM menghasilkan semua pilihan di dalam kode—seperti nama variabel, struktur fungsi, tech stack, dan lain-lain—maka kondisi idealnya adalah prompt hanya memuat kebutuhan bisnis, sementara sisanya dapat diinferensikan atau sudah terenkode

Membangun prompt library

  • Prompt library adalah kumpulan konteks untuk LLM yang mencakup dokumentasi codebase, best practice, dan peta struktur
    • Setiap kali output LLM melenceng, tinjau “apa yang seharusnya diperjelas” lalu tambahkan ke library
    • Keseimbangan antara cakupan dan keringkasan itu penting
    Iklan
  • Dalam contoh, dokumen seperti @prompts/How_To_Write_Views.md, @prompts/The_API_File.md, dan lainnya diberikan ke LLM untuk memandu pengembangan fitur
  • Prompt harus cukup spesifik, tetapi setiap baris kode yang dihasilkan tetap harus ditinjau

Lingkungan dan kualitas kode

  • Codebase dengan banyak technical debt akan menurunkan efisiensi pemanfaatan LLM
    • Dalam kasus Meta, disebutkan bahwa technical debt membuat target otomasi sulit dicapai
  • Kode yang bersih, modularisasi, penamaan yang jelas, dan struktur yang sederhana meningkatkan pemahaman dan akurasi LLM
  • Dalam contoh Django, titik masuk tiap app ditempatkan di file _api.py agar LLM dapat dengan cepat menemukan fungsionalitas yang dibutuhkan
    • Contoh: visit_api.handoff_to_doctor(user) untuk menyatukan akses eksternal
    • Pola _api dinyatakan di prompt library agar LLM diarahkan merujuk ke lokasi yang benar

Investasi pada oversight

  • Otomasi dengan LLM harus dipandang sebagai cara memperkuat tim, bukan menggantikan engineer
  • Oversight berarti investasi pada tim, alignment, dan workflow
    • Di tingkat tim, peningkatan kemampuan desain sangat penting dan terhubung langsung ke kualitas arsitektur
  • Cara untuk memperkuat kemampuan desain mencakup membaca buku, blog, dan kode, mereplikasi masterwork, serta berlatih implementasi langsung
    • Contoh: memperluas insting desain dengan menganalisis kode TLDraw dan SerenityOS Jakt
    Iklan

Oversight otomatis

  • Sebagian verifikasi desain dapat diotomatisasi secara programatik
    • Contoh: memberi umpan balik langsung di lingkungan saat terjadi type error atau pelanggaran aturan
  • ‘Safety’ berarti melindungi abstraksi
    • Menurut definisi Pierce, bahasa yang aman menjamin programmer tidak secara tidak sengaja merusak abstraksi
  • Contoh: aturan yang melarang akses langsung ke file internal antar app Django dapat diotomatisasi dengan skrip pemeriksaan berbasis AST
    • Mendeteksi akses ilegal dalam bentuk from visit import logic.internal_file
Iklan

Verification

  • Selain desain dan implementasi, tahap verifikasi seperti code review dan QA juga penting untuk menjaga kualitas
  • Ketika volume kerja meningkat, kecepatan peninjauan menjadi bottleneck, sehingga diusulkan beberapa perbaikan berikut
    • Menurunkan hambatan agar QA bisa dilakukan bahkan tanpa environment development
    • Membangun environment yang memudahkan penulisan test, seperti pembuatan test data
    • Mendokumentasikan feedback PR yang berulang agar LLM dapat mengotomatiskan sebagian review
    • Menanamkan aturan keamanan sebagai default framework

Kesimpulan dan pengamatan tambahan

  • LLM bekerja sangat baik terutama pada proyek greenfield
    • Karena tidak ada konteks lama dan tuntutan konsistensinya lebih rendah
  • Semakin besar proyek, konsistensi dan modularisasi semakin menentukan produktivitas
    • Struktur modular yang menggunakan kembali komponen yang sudah tervalidasi adalah inti dari pengembangan yang efisien

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-24
Komentar Hacker News

  • Seiring model makin membaik, kini model bisa menangani codebase yang kompleks atau file yang panjang
    Jadi saya membuat framework loop sederhana yang saya pakai berulang kali

    1. Research: minta model menjelaskan fitur saat ini lalu memuat file-file terkait ke dalam konteks
    2. Plan: minta model melakukan brainstorming praktik terbaik untuk implementasi fitur baru atau refactoring. Hasilnya lalu ditulis ke file md
    3. Clear: reset konteks sepenuhnya. Hasilnya lebih baik daripada sekadar kompresi
    4. Execute plan: muat ulang hanya rencananya lalu jalankan. Jika perlu, ulangi pertanyaan
    5. Review & test: reset lagi konteksnya lalu tinjau apakah rencana sudah tercermin dengan baik. Pada tahap ini tambahkan kode pengujian, lint, type check, dan semacamnya
      Jika loop ini dijalankan selama 20~30 menit, hasilnya cukup berguna. Pada akhirnya inti utamanya adalah mengelola konteks dan membuat loop umpan balik pengujian
    • Per Desember 2025, model seperti Sonnet/Opus dan GPTCodex sudah punya fitur penjelajahan subagent bawaan
      Jika memulai eksplorasi dengan kata kunci “explore”, tahap Research bisa dilakukan tanpa perlu menulis rencana terpisah atau me-reset konteks
      Namun model ini cenderung mengasumsikan bahasa kode adalah C atau Python, sehingga kadang menghasilkan kode tak terstruktur seperti membagi logika menjadi lima fungsi alih-alih mengenkapsulasi state sebagai objek
      Selain itu, claude sering mengabaikan CLAUDE.md, jadi lebih stabil jika file itu dibaca dulu lalu baru menjalankan “explore”
      Model terbaru cukup pandai membuang konteks yang tidak berguna, tetapi pada model lama pendekatan berbasis dokumen rencana masih sering lebih baik
    • Jika model gagal pada kemampuan penalaran dasar, workflow apa pun tidak akan membantu
      Ada banyak kasus ketika model menjalankan rencana dan pedoman secara kebalikan, atau membaca ulang kalimat yang sama tetapi tetap menarik kesimpulan yang berlawanan
      Dulu saya percaya bisa membangun proses yang berpusat pada LLM, tetapi sekarang keyakinan itu berkurang
      Saat model sedang dalam “kondisi bagus” memang lumayan, tetapi membuatnya berada di kondisi itu masih sangat bergantung pada keberuntungan
    • Saya juga memakai pendekatan serupa. Saya terinspirasi oleh pedoman Advanced Context Engineering dari HumanLayer
      Saya menambahkan perintah kustom seperti /research_codebase, /create_plan, /implement_plan ke Claude Code
      Jika ditinjau dan diperbaiki dengan teliti, hasilnya bekerja sangat baik, tetapi belum berhasil menyebar ke seluruh tim
    • Saya hampir tidak pernah memakai prosedur seperti ini. Dengan GitHub Copilot dan Claude Sonnet 4.5, instruksi yang jelas saja sudah cukup agar hasilnya bagus
      Saya hanya me-reset konteks saat membuat fitur yang benar-benar baru. Di Codespaces masih lumayan, tetapi fitur Tasks hampir tidak berguna
      Jika diberi pekerjaan besar, model kadang malah melenceng ke arah aneh, jadi harus selalu diawasi
    • Saya juga memakai workflow yang hampir sama. File rencana md disimpan di repositori agar bisa dirujuk saat menambahkan fitur baru
      Ini juga berguna untuk re-priming konteks, jadi sering saya manfaatkan

  • Agar pustaka prompt benar-benar berguna, dibutuhkan perbaikan berulang
    Setiap kali LLM sedikit melenceng, saya bertanya pada diri sendiri, “apa yang seharusnya saya jelaskan lebih jelas?” lalu menambahkan jawabannya ke prompt
    Jika hanya menekan enter atau menyetujui otomatis, itu cuma membuang token. Sebaliknya, amati di mana LLM tersendat lalu catat singkat di CLAUDE.md
    Jika file konteks membesar, pisahkan berdasarkan jenis pekerjaan
    Use case utama saya adalah menjelajahi codebase, melacak jalur eksekusi, dan memberi ringkasan file yang dibutuhkan. Jika cara penyampaian hasil ditentukan per jenis pertanyaan, efisiensinya jauh lebih tinggi

    • Metode yang lebih baik daripada “apa yang seharusnya saya jelaskan lebih jelas?” adalah membiarkan LLM menanyakannya sendiri
      Saya menyebutnya “Student Pattern (Fresh Eyes)”. Subagent membaca dokumen atau kode dengan sudut pandang pemula lalu menemukan titik kebingungan, kontradiksi, dan informasi yang hilang
      Ini sangat bagus untuk menangkap pengetahuan implisit yang sering terlewat oleh developer. Berguna sebagai tahap awal sebelum meninjau dokumen baru atau mengevaluasi prompt
    • Saya juga melakukan itu, tetapi Claude Code sering sekali mengabaikan prompt atau dokumen
      Meski sudah berkali-kali disuruh membaca CLAUDE.md, sering tetap diabaikan, bahkan tepat setelah sesi dimulai pun kadang terlewat secara acak
      Walau dokumen dan perintah sudah disiapkan, model masih sering “lupa”

  • Saya sedang bereksperimen menyusun codebase besar agar ramah untuk agent
    Proyek dipecah menjadi graf berarah berbasis nix flakes, dan tiap node memiliki lingkungan pengembangan yang independen
    Jika Claude Code dijalankan di flake devshell, ia hanya mengenali cakupan itu sehingga mencegah kelebihan beban konteks
    Antar-flakes lalu bekerja sama lewat input/output, saling mengirim permintaan fitur dan pengujian
    Saya rasa pembagian konteks seperti ini adalah kunci untuk mengurangi masalah ledakan token

    • Pendekatan ini menarik. Saya juga sedang memikirkan korelasi antara struktur perangkat lunak dan propertinya
      Daripada sekadar memperbaiki workflow yang ada, kita perlu merancang struktur baru yang mudah diskalakan oleh LLM
      Saya sedang mengeksplorasi hubungan antara struktur kode dan sifat-sifat seperti “kemudahan diuji, skalabilitas, dan keamanan”
    • Ini menarik bukan hanya dari sisi pembagian konteks, tetapi juga dari sisi reproducibility dan pinning dependency
      Saya juga pernah mencoba eksperimen serupa di proyek berbasis Docker, dan akan bagus jika ada alat yang bisa mengotomatisasikannya

  • LLM sangat bagus menjelaskan topik yang tidak terlalu saya kuasai, tetapi pada bidang yang saya tekuni, model sering salah dengan penuh percaya diri

    • Ini terasa seperti efek Gell-Mann Amnesia
    • Perbedaannya besar tergantung topik. Di ranah web hasilnya cukup akurat, tetapi pada bahasa langka seperti Hare hasilnya berantakan
    • Mungkin ini terasa begitu karena pada bidang yang tidak kita kuasai, kita mengajukan pertanyaan sederhana, sedangkan pada bidang yang kita kuasai, kita mengajukan pertanyaan yang jauh lebih sulit
    • Bisa juga sebenarnya pada bidang yang tidak kita kuasai, kita cuma tidak bisa membedakan omong kosong

  • Saya punya sudut pandang lain. Cara terbaik meningkatkan performa LLM adalah menanamkan makna ke dalam codebase itu sendiri
    Artinya, kode yang distrukturkan seperti DDD(Domain-Driven Design) juga lebih mudah dipahami oleh LLM
    Memaksa menangani kode kompleks dengan alat bantu hanyalah pemborosan uang
    Pada akhirnya, yang dibuktikan LLM adalah bahwa filosofi DDD yang menekankan “bahasa dan makna” memang benar
    Tulisan terkait: DDD & the Simplicity Gospel

    • Saya juga mengelola dua codebase besar, dan yang lebih terstruktur jauh lebih mudah dipahami oleh LLM

  • Untuk pertanyaan “mengapa LLM bekerja baik pada proyek greenfield?”, pengalaman saya justru sebaliknya
    Jika sebuah pola di codebase diulang 2~3 kali, LLM akan mempelajarinya dan menirunya secara konsisten
    Namun “konsistensi” tidak sama dengan “kualitas”. Jika hanya mengejar konsistensi tanpa standar, hasilnya akan menjadi kode yang tidak bisa dipelihara

  • Pernyataan “kode yang tidak bisa dipahami engineer juga tidak bisa dipahami LLM” memang benar, tetapi kebalikannya tidak berlaku
    Ada banyak kasus ketika manusia bisa paham tetapi agent tidak
    Membuat codebase agar lebih mudah dipahami agent daripada manusia justru lebih sulit
    Ada juga klaim bahwa “jika umpan balik dipindahkan ke komputer, tingkat keberhasilan one-shot akan naik”, tetapi itu mirip dengan mengklaim P=NP
    Fakta bahwa verifikasi itu mudah tidak berarti menemukan jawabannya juga mudah
    Bahasa seperti ATS atau Idris memungkinkan bukti kebenaran ditulis bersama kodenya
    Jika klaim itu benar, maka LLM seharusnya menunjukkan performa terbaik pada bahasa-bahasa seperti itu
    Namun kenyataannya tidak begitu. Pada akhirnya, saat ini saya merasa lebih baik menunggu modelnya membaik

  • Karena masalah-masalah seperti ini, saya melihat framework yang opinionated akan meningkatkan produktivitas coding dengan AI
    Karena LLM sudah memahami aturan framework tersebut, pedoman tambahan jadi tidak diperlukan

    • Saya bekerja pada codebase berukuran 1,6 juta baris, dan di area dengan ketidakcocokan pola yang parah, LLM hampir tidak berguna
    • Saya pernah membuat aplikasi yang sama dalam beberapa bahasa, dan Rails hampir selesai seketika, sementara Bun juga cukup bagus
      Sebaliknya, Go, Rust, Elixir, dan C# membutuhkan jauh lebih banyak dependency dan instruksi
      Hasil Rust memang bagus, tetapi model menarik lebih dari 200 paket sehingga bebannya besar

  • Prinsip “Garbage in, garbage out” memang benar, tetapi tidak sepenuhnya berlaku untuk LLM
    Model dilatih dengan data internet yang penuh noise, tetapi tetap bekerja cukup baik
    Halusinasi (hallucination) lebih sering muncul karena konteks yang tidak akurat daripada sekadar noise
    Bahkan codebase yang strukturnya berantakan tetap bisa memberi konteks yang berguna jika kandungan informasinya banyak

  • Pada akhirnya orang-orang sedang belajar ulang prinsip-prinsip dasar
    Mereka kembali menyadari bahwa dokumentasi (= pustaka prompt) dan struktur kode yang rapi memang mempercepat pengembangan

    • Tetap saja, kalau berkat ini lebih banyak orang mulai menulis pengujian, menurut saya itu bukan hal yang buruk