32 poin oleh GN⁺ 15 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Agen coding adalah sistem yang terdiri dari control loop dan software harness yang berpusat pada LLM, yang berulang kali melakukan penulisan kode, eksekusi, dan umpan balik
  • Agent harness menangani manajemen konteks, akses alat, penyusunan prompt, dan kontrol status; coding harness yang dikhususkan untuk tugas coding mengelola repositori, pengujian, dan pemeriksaan error
  • Agen coding bekerja dengan enam komponen: live repo context, prompt cache, tool access, context management, session memory, dan delegation ke subagent
  • Bahkan dengan LLM yang sama, performa dan pengalaman pengguna dapat sangat berbeda tergantung kualitas desain harness, dan harness yang dirancang dengan baik menyediakan lingkungan pengembangan yang persisten dan sadar konteks
  • Mini Coding Agent adalah contoh minimal yang diimplementasikan sepenuhnya dalam Python murni untuk struktur ini, dan berbeda dari OpenClaw dalam hal spesialisasi coding dan cakupan operasional

Komponen Penyusun Agen Coding

  • Agen coding adalah sistem yang terdiri dari control loop yang berpusat pada LLM dan software harness yang membungkusnya, dengan struktur yang berulang kali melakukan penulisan, modifikasi, eksekusi, dan umpan balik kode
  • LLM adalah model dasar prediksi token berikutnya, sedangkan reasoning model adalah LLM yang dilatih untuk melakukan lebih banyak penalaran dan verifikasi di tahap perantara
  • Agen adalah control loop yang berulang kali melakukan pemanggilan model, penggunaan alat, pembaruan status, dan penentuan kapan harus berhenti demi mencapai tujuan
  • Agent harness adalah struktur perangkat lunak yang membungkus loop tersebut dan menangani manajemen konteks, akses alat, penyusunan prompt, dan kontrol status
  • Coding harness adalah bentuk yang dikhususkan untuk pekerjaan kode, mengelola konteks repositori, eksekusi kode, pengujian, dan pemeriksaan error

Hubungan LLM, Reasoning Model, dan Agen

  • LLM dapat dianalogikan sebagai mesin, reasoning model sebagai mesin yang diperkuat, dan agent harness sebagai sistem yang mengendalikan mesin tersebut
  • LLM dan reasoning model dapat melakukan tugas coding sendiri, tetapi di lingkungan pengembangan nyata diperlukan manajemen konteks yang kompleks seperti menjelajahi repo, mencari fungsi, menjalankan tes, dan menganalisis error
  • Coding harness memaksimalkan performa model dan memberikan pengalaman coding yang jauh lebih kuat dibanding antarmuka chat sederhana

Peran Coding Harness

  • Sebagai lapisan perangkat lunak yang membungkus model, ia melakukan perakitan prompt, eksposur alat, pelacakan status file, eksekusi perintah, manajemen izin, cache, dan penyimpanan memori
  • Bahkan dengan LLM yang sama, performa dan pengalaman pengguna bisa sangat berbeda tergantung desain harness
  • Misalnya, model open-weight seperti GLM-5 juga dapat menghasilkan performa serupa jika diintegrasikan ke harness setingkat Codex atau Claude Code
  • OpenAI memiliki contoh mempertahankan model pascapemrosesan terpisah per harness, seperti GPT-5.3 dan GPT-5.3-Codex

6 Komponen Inti Agen Coding

  • 1. Konteks Repositori Langsung (Live Repo Context)

    • Agen harus memahami status Git saat ini, branch, dokumentasi, dan perintah tes
    • Instruksi seperti “perbaiki tes” bisa berubah tergantung struktur dan konteks repo, sehingga informasi ringkasan repo dikumpulkan sebelum bekerja
    • Dengan ini, agen tidak selalu mulai dari kondisi nol dan bisa memperoleh landasan kerja yang stabil (stable facts)
  • 2. Struktur Prompt dan Penggunaan Ulang Cache (Prompt Shape and Cache Reuse)

    • Ringkasan repo, deskripsi alat, dan instruksi umum jarang berubah, sehingga disimpan sebagai stable prompt prefix
    • Alih-alih menyusun ulang seluruh prompt setiap kali, hanya bagian yang berubah yang diperbarui
    • Dalam sesi berulang, ini mengurangi pemborosan komputasi dan menjaga konsistensi respons
  • 3. Akses dan Penggunaan Alat (Tool Access and Use)

    • Alih-alih model hanya menyarankan perintah, harness memungkinkan eksekusi nyata melalui kumpulan alat yang didefinisikan
    • Setiap alat memiliki format input-output dan batasan yang jelas, serta melalui validasi dan persetujuan sebelum eksekusi
    • Contoh verifikasi: “Apakah ini alat yang dikenal?”, “Apakah argumennya valid?”, “Apakah path kerja berada di dalam workspace?”
    • Ini meningkatkan keamanan dan keandalan; kebebasan model berkurang, tetapi kepraktisannya meningkat
  • 4. Meminimalkan Pembengkakan Konteks (Minimizing Context Bloat)

    • Dalam sesi panjang, pembacaan file berulang, log, dan output alat dapat menyebabkan masalah panjang prompt yang berlebihan
    • Harness mengelolanya dengan dua strategi
      • Clipping: meringkas teks panjang, log, dan memo ke panjang tertentu
      • Summarization: merangkum dan memadatkan riwayat percakapan lama
    • Peristiwa terbaru dipertahankan secara detail, sementara informasi lama dihilangkan duplikasi dan dikompresi
    • Akibatnya, dibanding kualitas model, kualitas konteks sering lebih besar pengaruhnya terhadap performa nyata
  • 5. Memori Sesi Terstruktur (Structured Session Memory)

    • Agen memisahkan status menjadi working memory dan full transcript
    • Rekaman penuh mencakup semua permintaan, respons, dan output alat sehingga sesi bisa dilanjutkan kembali
    • Working memory menyimpan ringkasan informasi penting saat ini seperti tugas aktif, file utama, dan catatan terbaru
    • Compact transcript digunakan untuk menyusun ulang prompt model, sementara working memory digunakan untuk menjaga kesinambungan pekerjaan
  • 6. Delegasi ke Subagent dengan Batasan (Delegation With Bounded Subagents)

    • Agen utama membuat subagent untuk memproses tugas pendukung secara paralel
    • Contoh: memisahkan tugas seperti mencari lokasi definisi simbol tertentu, isi file konfigurasi, atau penyebab kegagalan tes
    • Subagent hanya mewarisi konteks yang diperlukan dan dibatasi dengan aturan seperti read-only dan batas kedalaman rekursi
    • Claude Code dan Codex sama-sama mendukung subagent, dengan batas yang ditentukan oleh cakupan tugas dan kedalaman konteks

Ringkasan Komponen

  • Keenam komponen saling terhubung erat, dan kualitas desain harness menentukan efisiensi pemanfaatan model
  • Coding harness yang dirancang dengan baik menyediakan lingkungan dukungan pengembangan yang jauh lebih sadar konteks dan berkelanjutan dibanding chat LLM biasa
  • Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) adalah contoh minimal yang mengimplementasikan struktur ini dalam Python murni

Perbandingan dengan OpenClaw

  • OpenClaw lebih dekat ke platform agen umum daripada asisten khusus coding
  • Kesamaan:
    • Menggunakan file prompt dan instruksi dalam workspace (AGENTS.md, TOOLS.md, dll.)
    • Menyertakan fitur file sesi JSONL, kompresi percakapan, dan manajemen sesi
    • Dapat membuat sesi bantuan dan subagent
  • Perbedaan:
    • Agen coding dioptimalkan untuk menjelajahi repo, mengedit kode, dan menjalankan alat lokal
    • OpenClaw berfokus pada operasi agen jangka panjang lintas banyak channel dan workspace

Lampiran: Info Buku Baru

  • Build A Reasoning Model (From Scratch) telah selesai ditulis dan saat ini tersedia dalam versi Early Access
  • Penerbit sedang mengerjakan layout dengan target terbit pada musim panas
  • Buku ini berfokus pada pendekatan untuk memahami mekanisme penalaran LLM dengan mengimplementasikannya secara langsung

1 komentar

 
GN⁺ 15 hari lalu
Komentar Hacker News
  • context yang panjang tetap mahal, dan jika terlalu banyak informasi yang tidak perlu akan menimbulkan noise
    Karena itu saya merasa generasi berbasis spec lebih baik daripada coding interaktif berbasis percakapan
    Ossature yang saya buat mengambil pendekatan sebaliknya. Pertama menulis spec yang menjelaskan perilaku, lalu sebelum menghasilkan kode ia mengaudit kekurangan atau kontradiksi, dan membuat build plan TOML yang menyatakan setiap tugas merujuk ke bagian spec dan file mana
    LLM hanya melihat bagian yang diperlukan, tanpa akumulasi riwayat percakapan. Semua prompt dan respons disimpan ke disk sehingga keterlacakan terjamin secara otomatis
    Belakangan saya bahkan membuat emulator CHIP-8 sepenuhnya hanya dari spec dengan cara ini, dan ada juga proyek-proyek contoh

    • Akhir-akhir ini saya sering merasa coding agent zaman sekarang tidak punya sumber kebenaran pusat
      Dulu semua orang di tim tahu apa yang sedang dibangun, tapi sekarang agent selalu mulai dari nol setiap kali
      Karena itu saya melihat alur chat → spec → code sebagai masa depan. Tahap spec → code seharusnya bisa berjalan tanpa campur tangan manusia
      Jika spesifikasinya ambigu, agent harus bertanya dengan jelas kepada manusia, lalu menghasilkan kode berdasarkan itu
      Sekarang permintaan ambigu hanya berulang terus, dan manusia pun tidak belajar kenapa itu terjadi. “memory” atau file agent hanyalah solusi sementara
    • Saya juga sedang membuat sesuatu yang mirip. Belum dirilis, tapi ini workflow engine berpusat pada spec
      Alih-alih percakapan, saya memberi LLM projected context dari kode dan spec, dan menyusun context berbeda untuk tiap tahap
      Ini mencegah drift akibat context yang menumpuk, dan kode saya, bukan LLM, yang mengendalikan workflow
      Ide memakai TOML sebagai artifact yang diteruskan antar tahap menarik, jadi mungkin akan saya adaptasi
    • Saya juga berpikir sama. Agent A hanya mengubah spec, dan Agent B membangun hanya dengan melihat spec
      Pengguna cukup meninjau diff yang dibuat Agent A, sehingga terbebas dari verifikasi kode yang berulang
      Kuncinya adalah selalu mempertahankan intent. Spesifikasi dan konteks harus disimpan apa adanya
      Biayanya mungkin 2~3 kali lipat, tapi dalam jangka panjang rasanya akan lebih efisien
    • Workflow berbasis chat melelahkan dan banyak kehilangan informasi
      Saya rasa pendekatan berbasis spec jauh lebih baik. Saya penasaran bagaimana keterlibatan manusia dilakukan — apakah edit spec dan audit berjalan bersamaan, bagaimana tingkat keberhasilan generasi kode, dan apakah ada rencana menerapkannya ke kode yang sudah ada
    • Saya juga mencoba memulai dari spec lalu mengiterasi perbaikan kode dengan kombinasi Claude Code + Cucumber
      Saya penasaran apa bedanya Ossature dengan pendekatan itu
  • Menakjubkan bahwa potensi LLM bisa dimaksimalkan hanya dengan pendekatan state machine sederhana dan bash

    • Karena itu saya sedang membuat coding agent terisolasi sendiri
      Ekosistem agent belakangan ini penuh fitur berlebihan dan keputusan buruk
      Sepuluh tahun lalu orang berkata alat seperti ini membutuhkan rasa tanggung jawab, tapi sekarang ini masa kacau yang mencampur ketakutan dan hype
    • Pada akhirnya inti utamanya adalah prompt/context engineering
      Model sebenarnya sudah punya pengetahuan, tetapi untuk mengarahkannya ke tindakan yang nyata, desain context sangat penting
      Pendekatan yang menjanjikan adalah menerjemahkan permintaan pengguna ke tingkat langkah-langkah developer berpengalaman lalu menghubungkan tool yang diperlukan
      Menurut saya, model open source pun bisa cukup kompetitif dengan agent yang dioptimalkan dengan baik dan sedikit tuning
    • Kalau melihat Claude Code leak, strukturnya tidak sesederhana itu
      Dibutuhkan harness yang kompleks, tetapi justru karena itu LLM bisa bekerja secara deterministik sebagai tool
    • Banyak agent CLI menganggap akses bash saja tidak cukup, lalu memaksakan berbagai fitur ke dalam JavaScript TUI
    • Dibanding bash, memakai Python terasa lebih berguna
      Kita bisa menyusun logika sesuka hati, bukan hanya mengandalkan pipeline
  • Contohnya ringkas dan jelas
    Saya tidak memakai coding agent, tapi tulisan ini membantu memahami hakikat coding agent
    Ini menunjukkan dengan baik bagaimana kode berguna 1k LOC bisa berubah menjadi kekacauan 500k LOC

  • Sudah banyak orang menghubungkan model terbuka seperti GLM-5 ke Claude Code atau Codex CLI untuk dipakai
    Dokumentasi resmi GLM juga merekomendasikan hal itu

    • Memang belum setingkat Opus, tetapi kombinasi GLM dan Qwen3.5-plus sudah sangat bagus untuk proyek pribadi
  • Tulisannya mengesankan. Saya membuat agent non-coding berbasis email, dan prinsipnya mirip
    Pada tiap loop email, context dimulai ulang sehingga masalah akumulasi context terselesaikan secara alami
    Yang penting adalah keseimbangan antara context yang dimasukkan ke prompt awal dan context yang dipisahkan sebagai tool
    Caching dan biaya token juga perlu dipertimbangkan
    Detailnya saya rangkum di tulisan blog saya

  • Saya kurang suka kata “harness”. Apakah tidak ada istilah yang lebih baik?

    • Kata itu sering dipakai dalam arti shim yang mengelola program, seperti pada “test harness” atau “fuzzing harness”
    • Ironisnya sekarang semua hal disebut “app”, tapi justru aplikasi untuk menjalankan LLM tidak disebut “app”
    • Pada akhirnya “harness” hanyalah cara keren untuk menyebut scaffolding
    • Lalu ada juga tanggapan yang menantang untuk mengusulkan istilah alternatif kalau memang begitu
  • tool output truncation sangat efektif untuk mengurangi pembengkakan context
    Saya merakit context berbasis SQLite, dan bila perlu memulihkan kembali pemanggilan tool yang terpotong lewat ID pesan
    Eksperimen terkait dirangkum di dokumen

  • Menjalankan Claude Code dengan model lain adalah hal yang umum
    Dokumen contoh juga menunjukkan itu
    Tapi dari pengalaman saya, hasilnya belum menyamai model Anthropic

    • Tergantung proyeknya, model murah seperti MiMo V2 Pro bisa mencapai 70~80%, tetapi dalam banyak kasus Sonnet jauh lebih unggul
      Opus hanya terasa sepadan dengan biayanya dalam sekitar 5% kasus
      Saya merasa OpenCode jauh lebih baik daripada Claude Code, jadi saya membeli kredit API OpenRouter
      OpenCode sudah cukup kuat hanya dengan perintah kustom dan definisi agent sederhana
      Mendefinisikan workflow dengan AGENTS.md, ROADMAP.md, dan sejenisnya sudah cukup untuk kebanyakan proyek
      Dibanding harness yang kompleks, saya rasa struktur yang fleksibel lebih mampu beradaptasi dengan perubahan model terbaru
    • Saya penasaran apakah model Anthropic lebih baik semata karena kualitas modelnya, atau karena optimisasi harness
  • Kemajuan coding agent lebih banyak datang dari perbaikan struktur pendukung (scaffolding) daripada model itu sendiri
    Begitu tool, repository context, dan state machine sederhana tersedia, bottleneck-nya bergeser ke kualitas context

  • Tulisannya kuat. Saya juga sering menjelaskan coding agent dengan analogi mesin/mobil
    Jika ingin bereksperimen dengan komponen dasarnya, OpenHands software-agent-sdk layak dilihat