8 tingkat pengembangan agen cerdas

作者：Bassim Eledath

编译：宝玉

Kemampuan pemrograman AI sedang melampaui kemampuan kita untuk mengendalikannya. Inilah sebabnya mengapa semua usaha keras untuk meningkatkan skor SWE-bench tidak sejalan dengan indikator produktivitas yang benar-benar diperhatikan oleh pimpinan rekayasa. Tim Anthropic meluncurkan Cowork dalam 10 hari, sementara tim lain menggunakan model yang sama tetapi bahkan tidak mampu membuat POC (bukti konsep) — perbedaannya adalah satu tim sudah menjembatani kesenjangan antara kemampuan dan praktik, sementara yang lain belum.

Kesenjangan ini tidak akan hilang dalam semalam, melainkan secara bertahap menyusut dalam tingkatan. Ada total 8 tingkatan. Kebanyakan orang yang membaca artikel ini mungkin sudah melewati beberapa tingkatan awal, dan kamu harus sangat ingin mencapai tingkatan berikutnya — karena setiap kenaikan level berarti lonjakan besar dalam output, dan setiap peningkatan kemampuan model akan semakin memperbesar manfaat tersebut.

Alasan lain yang perlu kamu perhatikan adalah efek kolaborasi tim. Outputmu jauh lebih bergantung pada tingkat rekan satu tim daripada yang kamu bayangkan. Misalnya, kamu adalah level 7 ahli, dan saat tidur malam, agen cerdas di belakang layar membantumu dengan beberapa PR. Tapi jika repositori kode kamu membutuhkan persetujuan dari rekan untuk menggabungkan, dan rekan tersebut masih di level 2, dan masih melakukan review PR secara manual, maka throughput-mu akan terhambat. Jadi, membantu rekan untuk naik level juga menguntungkan dirimu sendiri.

Dengan berinteraksi dengan banyak tim dan individu mengenai praktik mereka menggunakan AI untuk pemrograman, berikut adalah jalur peningkatan tingkatan yang saya amati (urutan ini tidak mutlak):

Delapan Tingkat Engineering Agen

Level 1 dan 2: Penyelesaian Otomatis Tab dan IDE Agen

Dua tingkatan ini akan saya bahas singkat, mainly untuk pencatatan lengkap. Kamu bisa melewatinya dengan bebas.

Penyelesaian otomatis Tab adalah titik awal segala hal. GitHub Copilot memulai gerakan ini — tekan satu tombol Tab, otomatis melengkapi kode. Banyak orang mungkin sudah lupa tentang tahap ini, bahkan yang baru memulai mungkin langsung melewatinya. Ini lebih cocok untuk pengembang berpengalaman, yang bisa membangun kerangka kode terlebih dahulu, lalu membiarkan AI mengisi detailnya.

IDE khusus AI yang diwakili oleh Cursor mengubah permainan, menghubungkan obrolan dan repositori kode, membuat pengeditan lintas file jauh lebih mudah. Tapi batasannya tetap pada konteks. Model hanya bisa membantu dengan apa yang dilihatnya, dan yang menyebalkan adalah, kadang tidak melihat konteks yang benar, atau malah melihat terlalu banyak konteks yang tidak relevan.

Sebagian besar orang di tingkatan ini juga mencoba pola perencanaan dari agen pemrograman pilihan mereka: mengubah ide kasar menjadi rencana terstruktur langkah demi langkah untuk LLM, mengulang-ulang rencana tersebut, lalu memicu eksekusi. Pada tahap ini, hasilnya cukup baik dan merupakan cara yang masuk akal untuk tetap mengendalikan. Tapi kita akan lihat di tingkatan berikutnya, ketergantungan pada pola perencanaan ini akan semakin berkurang.

Level 3: Engineering Konteks

Sekarang masuk ke bagian yang menarik. Engineering Konteks (Context Engineering) menjadi istilah populer tahun 2025, karena model akhirnya mampu mengikuti sejumlah instruksi yang masuk akal secara andal, dengan konteks yang tepat. Konteks yang berisik sama buruknya dengan konteks yang tidak cukup, jadi pekerjaan inti adalah meningkatkan densitas informasi setiap token. “Setiap token harus berjuang untuk posisi dirinya dalam prompt” — ini adalah prinsip saat itu.

Informasi yang sama, dengan lebih sedikit token — densitas informasi adalah raja (sumber: humanlayer/12-factor-agents)

Dalam praktiknya, engineering konteks mencakup lebih dari yang disadari kebanyakan orang. Termasuk prompt sistem dan file aturan (.cursorrules, CLAUDE.md). Termasuk cara kamu mendeskripsikan alat, karena model membaca deskripsi ini untuk memutuskan alat mana yang akan dipanggil. Termasuk pengelolaan riwayat percakapan, agar agen cerdas yang berjalan lama tidak kehilangan arah setelah sepuluh putaran. Termasuk juga pengambilan keputusan tentang alat apa yang akan diekspos setiap putaran, karena terlalu banyak pilihan bisa membuat model kewalahan — seperti manusia.

Sekarang, istilah engineering konteks ini jarang terdengar lagi. Tren lebih condong ke model yang mampu mentolerir konteks yang lebih berisik dan tetap mampu melakukan inferensi dalam skenario yang lebih kacau (ukuran jendela konteks yang lebih besar juga membantu). Tapi, perhatikan bahwa konsumsi konteks tetap penting. Beberapa skenario berikut ini tetap menjadi bottleneck:

Model kecil lebih sensitif terhadap konteks. Aplikasi suara biasanya menggunakan model yang lebih kecil, dan ukuran konteks juga terkait dengan delay token pertama, mempengaruhi kecepatan respons.

Token yang banyak dikonsumsi. Protokol konteks model seperti Playwright MCP dan input gambar akan cepat menghabiskan token, membuat kamu lebih cepat masuk ke mode “percakapan terkompresi” di Claude Code daripada yang diharapkan.

Agen yang terintegrasi dengan puluhan alat, menghabiskan lebih banyak token untuk parsing definisi alat daripada untuk pekerjaan nyata.

Secara makro, intinya adalah: engineering konteks tidak hilang, melainkan berevolusi. Fokusnya beralih dari menyaring konteks buruk ke memastikan konteks yang benar muncul di waktu yang tepat. Perubahan ini membuka jalan ke tingkatan 4.

Level 4: Engineering Komposit

Engineering konteks memperbaiki sesi saat ini. Sedangkan engineering komposit (Compounding Engineering, dikemukakan oleh Kieran Klaassen) memperbaiki setiap sesi berikutnya. Konsep ini menjadi titik balik bagi saya dan banyak orang — menyadarkan bahwa “pemrograman berdasarkan feeling” jauh lebih dari sekadar prototipe.

Ini adalah siklus “perencanaan, penugasan, evaluasi, dan sedimentasi”. Kamu merencanakan tugas, memberi LLM konteks yang cukup agar berhasil. Kamu menugaskan tugas tersebut. Kamu mengevaluasi hasilnya. Dan langkah penting — kamu menyerap pelajaran: apa yang efektif, apa yang bermasalah, pola apa yang harus diikuti di masa depan.

Siklus komposit: rencana, penugasan, evaluasi, sedimentasi — setiap putaran membuat yang berikutnya lebih baik

Kekuatan utamanya terletak pada langkah “sedimentasi”. LLM bersifat stateless. Jika kemarin dia memperkenalkan dependensi yang secara eksplisit kamu hapus, besok dia akan melakukannya lagi — kecuali kamu beri tahu agar tidak. Solusi paling umum adalah memperbarui CLAUDE.md (atau file aturan setara), mengkonsolidasikan pengalaman ke dalam setiap sesi mendatang. Tapi hati-hati, keinginan untuk memasukkan semuanya ke dalam aturan bisa berbalik arah (terlalu banyak instruksi sama dengan tidak ada instruksi). Pendekatan yang lebih baik adalah menciptakan lingkungan di mana LLM bisa dengan mudah menemukan konteks yang berguna — misalnya, dengan memelihara folder docs/ yang selalu diperbarui (akan dijelaskan lebih detail di level 7).

Praktisi engineering komposit biasanya sangat peka terhadap konteks yang diberikan ke LLM. Saat LLM melakukan kesalahan, reaksi alami mereka adalah memeriksa apakah konteks kurang, bukan menyalahkan model. Insting ini memungkinkan tingkatan 5 sampai 8.

Level 5: MCP dan Skill

Level 3 dan 4 menyelesaikan masalah konteks. Level 5 menyelesaikan masalah kemampuan. MCP dan skill kustom memungkinkan LLM mengakses database, API, pipeline CI, sistem desain, serta alat seperti Playwright untuk pengujian browser dan Slack untuk notifikasi. Model tidak lagi hanya memikirkan kode kamu — sekarang bisa langsung beroperasi.

Sudah banyak sumber berkualitas tentang MCP dan skill, jadi saya tidak akan mengulang apa itu. Tapi saya akan beri beberapa contoh penggunaannya: tim kami berbagi skill review PR, dan secara iteratif memperbaikinya (masih berlangsung). Skill ini secara kondisional memicu sub-agen berdasarkan sifat PR. Ada yang memeriksa keamanan integrasi dengan database, yang melakukan analisis kompleksitas untuk menandai redundansi atau overengineering, dan yang lain memeriksa kesehatan prompt untuk memastikan mereka mengikuti standar tim. Mereka juga menjalankan linter dan Ruff.

Mengapa berinvestasi banyak di skill review? Karena saat agen mulai menghasilkan PR secara massal, review manual menjadi bottleneck, bukan kualitas. Latent Space menyampaikan argumen meyakinkan: review kode yang kita kenal sudah mati. Yang tersisa adalah otomatisasi, konsistensi, dan review berbasis skill.

Dalam hal MCP, saya menggunakan Braintrust MCP agar LLM bisa mengakses log evaluasi dan langsung melakukan perubahan. Saya juga pakai DeepWiki MCP agar agen bisa mengakses dokumentasi repositori open source apa pun tanpa harus memasukkan dokumen secara manual ke konteks.

Ketika banyak orang dalam tim mulai menulis skill serupa, saatnya menggabungkannya ke registry bersama. Block (dengan hormat) menulis artikel bagus tentang ini: mereka membangun pasar skill internal dengan lebih dari 100 skill, dan merancang paket skill untuk peran dan tim tertentu. Skill dan kode diperlakukan sama: pull request, review, riwayat versi.

Ada tren menarik lainnya: LLM semakin banyak menggunakan alat CLI daripada MCP (dan tampaknya setiap perusahaan merilis versi mereka sendiri: Google Workspace CLI, dan Braintrust juga akan segera meluncurkan). Alasannya adalah efisiensi token. Server MCP setiap putaran akan menyuntikkan definisi alat lengkap ke dalam konteks, terlepas dari apakah agen menggunakannya. CLI sebaliknya: agen menjalankan perintah yang spesifik, dan hanya output relevan yang masuk ke jendela konteks. Saya banyak menggunakan agent-browser daripada Playwright MCP karena alasan ini.

Sebelum melanjutkan, mari berhenti sebentar. Level 3 sampai 5 adalah fondasi dari segala hal berikutnya. LLM sangat luar biasa dalam beberapa hal, dan sangat buruk di hal lain. Kamu perlu mengembangkan intuisi tentang batas-batas ini, agar bisa menumpuk otomatisasi lebih banyak di atasnya. Jika konteksmu berisik, prompt tidak cukup lengkap atau akurat, dan deskripsi alat kabur, maka tingkatan 6 sampai 8 hanya akan memperbesar masalah ini.

Level 6: Harness Engineering

Roket benar-benar mulai lepas landas.

Engineering konteks berfokus pada apa yang dilihat model. Harness Engineering (Rekayasa Harness) berfokus pada membangun seluruh lingkungan — alat, infrastruktur, dan siklus umpan balik — agar agen cerdas dapat bekerja secara andal tanpa intervensi. Bukan hanya editor, tetapi seluruh siklus umpan balik lengkap.

Tim OpenAI dengan Codex-nya — sebuah sistem observabilitas lengkap yang memungkinkan agen untuk menelusuri, mengaitkan, dan menyimpulkan outputnya sendiri (sumber: OpenAI)

Tim Codex OpenAI mengintegrasikan Chrome DevTools, alat observabilitas, dan navigasi browser ke dalam runtime agen, memungkinkan mereka untuk mengambil screenshot, mengendalikan UI, menelusuri log, dan memverifikasi perbaikan sendiri. Berikan prompt, agen bisa mereproduksi bug, merekam video, dan melakukan perbaikan. Kemudian, melalui manipulasi aplikasi, mereka memverifikasi, mengajukan PR, menanggapi umpan balik review, dan menggabungkan — hanya melibatkan manusia saat diperlukan pengambilan keputusan. Agen tidak hanya menulis kode, mereka bisa melihat apa yang dihasilkan kode, lalu melakukan iterasi seperti manusia.

Tim saya mengerjakan agen suara dan obrolan untuk troubleshooting teknis, jadi saya buat alat CLI bernama converse, yang memungkinkan LLM berinteraksi dengan backend kami dalam percakapan berputar. Setelah LLM mengubah kode, mereka menguji percakapan di sistem live, lalu iterasi. Kadang, siklus perbaikan diri ini berjalan berjam-jam. Ketika hasilnya dapat diverifikasi, ini sangat kuat: percakapan harus mengikuti proses ini, atau memanggil alat tertentu dalam kondisi tertentu (misalnya, transfer ke layanan pelanggan manusia).

Inti dari semua ini adalah mekanisme backpressure — sistem umpan balik otomatis (sistem tipe, pengujian, linter, hook pre-commit) yang memungkinkan agen mendeteksi dan memperbaiki kesalahan tanpa intervensi manusia. Jika kamu menginginkan otonomi, kamu harus memiliki backpressure, jika tidak, yang kamu dapatkan hanyalah mesin produksi sampah. Ini juga berlaku dalam keamanan. CTO Vercel menunjukkan bahwa agen, kode yang mereka hasilkan, dan kunci rahasia harus berada di domain kepercayaan berbeda, karena serangan injeksi prompt di log bisa memancing agen mencuri kredensialmu — jika semuanya berbagi konteks keamanan yang sama. Batas keamanan adalah backpressure: mereka membatasi apa yang bisa dilakukan agen saat tidak terkendali, bukan hanya apa yang seharusnya dilakukan.

Dua prinsip yang memperjelas konsep ini:

Desain untuk throughput, bukan kesempurnaan. Ketika setiap pengiriman harus sempurna, agen akan terjebak dalam bug yang sama berulang kali, saling menutupi. Lebih baik toleransi terhadap kesalahan kecil yang tidak menghambat, dan melakukan pemeriksaan akhir sebelum rilis. Kita lakukan hal yang sama terhadap rekan manusia.

Pembatasan lebih baik daripada instruksi. Memberikan petunjuk langkah demi langkah (“buat A dulu, lalu B, lalu C”) sudah usang. Berdasarkan pengalaman saya, mendefinisikan batas lebih efektif daripada daftar perintah, karena agen akan fokus pada daftar dan mengabaikan di luar daftar. Petunjuk yang lebih baik adalah “Ini hasil yang saya inginkan, lakukan terus sampai semua tes ini lolos.”

Separuh dari Harness Engineering adalah memastikan agen dapat menavigasi repositori kode secara mandiri tanpa bantuanmu. Pendekatan OpenAI adalah membatasi AGENTS.md sekitar 100 baris, sebagai indeks menuju dokumen terstruktur lainnya, dan memasukkan ke dalam CI agar selalu mutakhir, bukan bergantung pada update sementara yang cepat usang.

Setelah semua ini terbangun, muncul pertanyaan alami: jika agen bisa memverifikasi pekerjaannya sendiri, menavigasi repositori secara mandiri, dan memperbaiki kesalahan tanpa kamu, mengapa kamu masih harus duduk di kursi?

Perlu diingat, untuk mereka yang masih di level awal, konten berikut mungkin terdengar seperti fiksi ilmiah (tapi tidak apa-apa, simpan dulu, nanti kembali lagi).

Level 7: Agen Backend

Komentar pedas: pola perencanaan sedang hilang.

Boris Cherny, pencipta Claude Code, saat ini masih memulai 80% tugas dengan pola perencanaan. Tapi seiring munculnya generasi model baru, tingkat keberhasilan sekali jalan setelah perencanaan terus meningkat. Saya percaya kita mendekati titik kritis: pola perencanaan sebagai langkah intervensi manusia yang terpisah akan perlahan menghilang. Bukan karena perencanaannya tidak penting, tetapi karena model sudah cukup pintar untuk membuat rencana sendiri. Tapi syarat utamanya adalah kamu sudah menyelesaikan pekerjaan di level 3 sampai 6. Jika konteksmu bersih, batasan jelas, deskripsi alat lengkap, dan siklus umpan balik tertutup, model bisa merencanakan secara andal tanpa perlu review. Jika tidak, kamu harus tetap mengawasi.

Perjelas, pola perencanaan sebagai praktik umum tidak akan hilang, hanya berubah bentuk. Untuk pemula, pola ini tetap jalan masuk yang benar (seperti level 1 dan 2). Tapi untuk fitur kompleks di level 7, “perencanaan” tidak lagi sekadar membuat outline langkah demi langkah, melainkan eksplorasi: menjelajah repositori, membuat prototipe di worktree, memahami ruang solusi. Dan semakin sering, eksplorasi ini dilakukan oleh agen latar belakang secara asinkron.

Ini penting karena inilah yang membuka kunci agen latar belakang. Jika agen mampu membuat rencana yang andal dan mengeksekusinya tanpa perlu tanda tanganmu, maka dia bisa berjalan secara asinkron saat kamu melakukan hal lain. Ini adalah perubahan kunci — dari “saya berganti-ganti tab” menjadi “pekerjaan berjalan tanpa saya”.

Ralph loop adalah metode populer: siklus agen mandiri yang dijalankan berulang kali, menjalankan CLI pemrograman sampai semua item dalam PRD selesai, setiap iterasi memulai instance baru dengan konteks segar. Dalam pengalaman saya, menjalankan Ralph loop tidak mudah, karena setiap deskripsi yang tidak lengkap atau tidak akurat di PRD akan berbalik. Ini agak terlalu “dilempar dan lupa”.

Kamu bisa menjalankan beberapa Ralph loop secara paralel, tapi semakin banyak agen yang dijalankan, semakin banyak waktu yang dihabiskan untuk koordinasi, penjadwalan, pemeriksaan output, dan kemajuan. Kamu tidak lagi menulis kode — kamu menjadi manajer tingkat menengah. Kamu membutuhkan orchestrator agen untuk mengatur penjadwalan, agar bisa fokus pada niat, bukan logistik.

Dispatch menjalankan 5 worker secara paralel di 3 model — menjaga sesi tetap ringkas, agen bekerja

Alat yang baru saya gunakan secara luas adalah Dispatch, yang saya buat sebagai skill Claude Code, mengubah sesi kamu menjadi pusat komando. Kamu tetap di sesi bersih, sementara worker menyelesaikan pekerjaan berat di konteks terisolasi. Penjadwal bertanggung jawab atas perencanaan, penugasan, dan pelacakan, sementara jendela konteks utama kamu digunakan untuk orkestrasi. Jika worker terhenti, mereka akan mengeluarkan pertanyaan klarifikasi daripada gagal diam saja.

Dispatch berjalan lokal, cocok untuk pengembangan cepat yang membutuhkan feedback cepat, debugging mudah, tanpa biaya infrastruktur. Ramp’s Inspect adalah solusi pelengkap untuk pekerjaan jangka panjang dan lebih mandiri: setiap sesi agen dijalankan di sandbox VM cloud lengkap dengan lingkungan pengembangan. Seorang PM menemukan bug UI, menandainya di Slack, dan Inspect akan mengambil alih dan memperbaiki saat kamu menutup laptop. Biayanya adalah kompleksitas operasional (infrastruktur, snapshot, keamanan), tapi kamu mendapatkan skala dan reprodusibilitas yang tidak bisa dicapai agen lokal. Saya sarankan gunakan keduanya (lokal dan cloud).

Di level ini, ada pola yang sangat kuat: menggunakan model berbeda untuk tugas berbeda. Tim terbaik bukanlah kumpulan klon. Anggota tim memiliki cara berpikir berbeda, latar belakang pelatihan berbeda, keunggulan berbeda. Demikian juga, model-model ini telah dilatih ulang secara berbeda dan memiliki karakteristik yang berbeda. Saya sering menugaskan Opus untuk implementasi, Gemini untuk eksplorasi, Codex untuk review, dan hasil gabungan ini jauh lebih kuat daripada satu model tunggal. Bisa dianggap sebagai kecerdasan kolektif, tapi diterapkan pada kode.

Yang sangat penting, kamu juga harus memisahkan pelaksana dan evaluator. Pengalaman saya banyak belajar dari ini: jika satu instance model bertanggung jawab untuk implementasi dan evaluasi sendiri, dia akan bias. Dia akan mengabaikan masalah dan mengklaim semua tugas selesai — padahal sebenarnya tidak. Ini bukan karena niat buruk, melainkan karena alasan yang sama seperti kamu tidak memberi nilai ujianmu sendiri. Lebih baik gunakan model lain (atau instance berbeda dengan prompt evaluasi) untuk melakukan review. Sinyal kualitasmu akan meningkat secara signifikan.

Agen latar belakang juga membuka pintu untuk integrasi CI dan AI. Setelah agen bisa berjalan tanpa pengawasan manusia, mereka bisa dipicu dari infrastruktur yang ada. Sebuah robot dokumentasi akan memperbarui dokumentasi dan mengajukan PR untuk memperbarui CLAUDE.md setiap kali ada merge. Robot review keamanan akan memeriksa PR dan mengajukan perbaikan. Robot manajemen dependensi tidak hanya menandai masalah, tetapi benar-benar memperbarui paket dan menjalankan suite pengujian. Dengan konteks yang baik, aturan yang terus diperbarui, alat yang kuat, dan siklus umpan balik otomatis — semuanya berjalan otomatis.

Level 8: Tim Agen Cerdas Mandiri

Saat ini, belum ada yang benar-benar menguasai level ini, meskipun beberapa sedang menuju ke sana. Ini adalah frontier saat ini.

Di level 7, kamu memiliki orkestrasi LLM yang mendistribusikan tugas ke agen kerja secara pusat dan menyebar. Level 8 menghilangkan hambatan ini. Agen berkoordinasi langsung — mengklaim tugas, berbagi temuan, menandai dependensi, menyelesaikan konflik — semuanya tanpa perlu satu pengatur utama.

Fitur Agent Teams eksperimental dari Claude Code adalah implementasi awal: beberapa instance bekerja paralel di repositori yang sama, rekan-rekan beroperasi di konteks mereka sendiri dan berkomunikasi langsung. Anthropic membangun compiler Linux dari nol dengan 16 agen paralel selama berminggu-minggu. Cursor menjalankan ratusan agen secara bersamaan selama berminggu-minggu, membangun browser dari nol dan memigrasi kode dari Solid ke React.

Tapi, jika dilihat lebih dekat, ada masalah. Tanpa struktur hierarki, agen menjadi takut-takut, berputar-putar tanpa kemajuan. Agen Anthropic sering merusak fitur yang sudah ada sampai mereka menambahkan pipeline CI untuk mencegah regresi. Semua yang melakukan eksperimen di level ini sepakat: koordinasi multi-agen adalah masalah yang sangat sulit, dan belum ada solusi optimal.

Sejujurnya, saya tidak yakin model sudah cukup pintar untuk otomatisasi tingkat ini di sebagian besar tugas. Bahkan jika mereka cukup cerdas, untuk proyek sebesar pengembangan compiler dan browser, mereka masih terlalu lambat dan boros token, secara ekonomi tidak layak (mengagumkan, tapi jauh dari matang). Untuk pekerjaan sehari-hari kita, level 7 adalah leverage utama. Saya tidak akan terkejut jika level 8 akhirnya menjadi arus utama, tapi saat ini saya fokus di level 7 (kecuali kamu Cursor — inovasi adalah bisnis kamu).