Agentic engineering: ketika engineer mengarahkan agent, tetapi tetap memiliki hasilnya

Agent mengambil porsi implementation, manusia tetap memiliki spec, eval, permission, dan outcome. Dua scope istilah, studi kasus OpenAI, dan tangga kematangan yang bisa diukur.

17 Jul 2026 18 menit baca

Agentic Engineering Coding Agent SDLC

Pada Februari 2026, Andrej Karpathy memakai istilah "agentic engineering" untuk membedakan pekerjaan profesional dengan coding agents dari vibe coding. Framing-nya sederhana: engineer semakin jarang menulis setiap baris secara langsung, lebih sering mengarahkan agent dan bertindak sebagai oversight, tetapi proses itu tetap memiliki art, science, dan expertise yang dapat dipelajari. Addy Osmani dan Simon Willison kemudian memakai istilah yang sama untuk menekankan planning, code review, testing, dan tanggung jawab manusia.

Istilah tersebut cepat melebar. Dalam satu penggunaan, agentic engineering berarti cara software engineer bekerja dengan Claude Code, Codex, atau Gemini CLI. Dalam penggunaan lain, istilah itu mencakup design dan operation sistem otonom yang terdiri dari agents, humans, tools, memory, policy, dan observability. Artikel ini mempertahankan kedua makna tersebut agar istilahnya tidak berubah menjadi label kabur untuk semua hal yang memakai LLM.

Loop engineering menjadi jembatan di antara keduanya. Loop mengatur bagaimana agent menemukan pekerjaan, mencoba, menerima feedback, menyimpan state, dan berhenti. Agentic engineering mengatur mengapa loop itu ada, siapa yang berwenang, evidence apa yang diterima, bagaimana perubahan masuk ke SDLC, dan siapa yang bertanggung jawab ketika hasilnya salah.

Istilah baru muncul karena "vibe coding" terlalu luas

Vibe coding pada definisi awalnya sengaja santai. Pengguna mendeskripsikan sesuatu, menerima kode, menjalankannya, dan lebih peduli pada hasil langsung daripada memahami setiap detail implementation. Pola ini sangat berguna untuk prototype, personal script, exploration, dan pekerjaan sekali pakai. Masalah muncul ketika istilah yang sama dipakai untuk payment system, infrastructure, atau product code yang memiliki pengguna nyata.

Addy Osmani menarik garis yang tegas. Vibe coding membiarkan code quality dan comprehension berada di belakang kecepatan, sedangkan agentic engineering memakai agent di dalam proses yang masih memiliki plan, review, test, version control, CI, documentation, dan production ownership. Agent boleh menghasilkan mayoritas diff, tetapi engineer tidak boleh melepaskan kewajiban memahami risiko dan memeriksa hasil.

Simon Willison memberi definisi yang lebih operasional. Coding agent berbeda dari text generator karena ia dapat menulis dan menjalankan kode. Kemampuan execution memungkinkan agent menguji hipotesis, melihat error, lalu mengulang tanpa menunggu arahan manusia pada setiap langkah. Agentic engineering adalah praktik mendapatkan hasil profesional dari kemampuan tersebut.

Perbedaan itu tidak ditentukan oleh persentase kode buatan AI. Repository yang 90 persen ditulis agent masih dapat dikelola secara disiplin. Sebaliknya, diff kecil dari agent tetap berbahaya bila tidak ada review, test, atau owner yang memahami konsekuensinya.

Dua definisi yang perlu dipisahkan

Percakapan industri menggunakan "agentic engineering" untuk dua scope. Keduanya berhubungan, tetapi tidak identik. Tanpa pemisahan ini, pembaca dapat mengira bahwa agentic engineering selalu membutuhkan swarm, atau sebaliknya mengira bahwa istilahnya hanya tentang coding assistant.

Scope	Fokus	Unit kerja	Contoh artifact
Agentic engineering untuk software development	Engineer membangun software dengan coding agents	Feature, issue, refactor, migration, test, release	Spec, task, branch, test, review, PR
Engineering of agentic systems	Tim merancang dan mengoperasikan sistem yang memiliki goal-directed autonomy	Agent workflow, policy, tool boundary, memory, deployment	Agent graph, eval, permission model, trace, monitoring, incident process

Karpathy, Osmani, dan Willison terutama membahas scope pertama. Workshop AGENT 2026 di ICSE memakai scope kedua yang lebih luas, yaitu design, development, dan operation sistem dengan goal-directed autonomy. Sebuah research agenda pada Mei 2026 bahkan membagi bidang menjadi dua arah: agents yang membantu software engineering, serta software engineering yang dibutuhkan untuk membangun agent systems.

Dalam produk nyata, kedua scope sering bertemu. Tim dapat memakai coding agent untuk membangun customer-support agent. Agentic engineering pertama mengatur cara codebase dibuat dengan bantuan agent. Agentic engineering kedua mengatur bagaimana customer-support agent menggunakan tools, menjaga data, meminta approval, dan beroperasi setelah deployment.

Artikel ini memakai istilah secara luas, tetapi memberi label saat membahas coding workflow atau runtime agent system. Multi-agent bukan syarat dasar. Satu coding agent dengan tools, tests, dan loop yang baik sudah cukup untuk praktik agentic engineering pada scope software development.

Peran engineer bergeser dari implementation ke outcome ownership

Menulis kode tidak pernah menjadi seluruh pekerjaan software engineer. Engineer juga memilih trade-off, membentuk architecture, menerjemahkan kebutuhan yang ambigu, menjaga security, membaca incident, dan mempertahankan system selama bertahun-tahun. Ketika agent mengambil porsi implementation, pekerjaan tersebut tidak hilang. Pusat gravitasinya justru berpindah ke decision quality.

Dalam agentic workflow, engineer harus membuat intent terbaca oleh mesin. Spec yang biasanya cukup untuk rekan manusia mungkin perlu acceptance criteria, source of truth, forbidden actions, test commands, data constraints, dan terminal state yang lebih eksplisit. Kualitas task definition menjadi leverage karena satu instruksi dapat memicu banyak tool call dan banyak perubahan.

Engineer juga menjadi designer environment. OpenAI menjelaskan bahwa ketika Codex gagal, perbaikannya sering bukan meminta model mencoba lebih keras, tetapi menambahkan capability, abstraction, test, atau repository rule yang sebelumnya tidak terlihat oleh agent. Perubahan seperti itu meningkatkan semua run berikutnya. Nilai engineering bergeser dari menyelesaikan satu task menjadi memperbaiki sistem yang menyelesaikan banyak task.

Outcome ownership tidak dapat didelegasikan kepada model. Agent tidak menanggung biaya incident, kewajiban regulatory, reputasi, atau maintenance jangka panjang. Manusia dan organisasi yang memberi permission tetap menjadi pihak yang harus menentukan apakah evidence cukup untuk merge, deploy, atau mengambil tindakan dunia nyata.

Loop adalah execution primitive di dalam agentic engineering

Artikel sebelumnya membahas loop engineering sebagai desain trigger, goal, executor, verifier, memory, budget, dan stop condition. Dalam agentic engineering, loop tersebut menjadi cara pekerjaan dilaksanakan. Namun, workflow profesional memerlukan lapisan sebelum dan sesudah loop.

Sebelum loop berjalan, manusia menentukan masalah, architecture boundary, risk class, dan acceptance criteria. Selama loop berjalan, harness membatasi tools dan permissions, verifier mengumpulkan evidence, serta observability mencatat tindakan. Setelah loop berhenti, hasil masuk ke review, release, monitoring, dan learning process organisasi.

Tahap	Tanggung jawab utama	Peran agent
Intent	Menentukan masalah, user impact, constraint, dan non-goal	Membantu eksplorasi dan merapikan spec
Design	Memilih architecture, interface, data flow, dan risk boundary	Membandingkan opsi, membuat prototype, mencari dependency
Execution	Mengubah code, config, docs, dan test	Bekerja melalui tools dalam loop
Verification	Membuktikan correctness sesuai risk class	Menjalankan test, static analysis, review, dan evidence collection
Integration	Menggabungkan perubahan ke repository dan pipeline	Menyiapkan PR, menjawab review, memperbaiki conflict
Operation	Memantau production, incident, drift, cost, dan user outcome	Membantu triage, diagnosis, dan remediation terkontrol
Learning	Mengubah failure menjadi test, skill, policy, atau harness improvement	Menganalisis trace dan mengusulkan perbaikan

Agentic engineering tidak berhenti ketika test lokal hijau. Perubahan masih harus cocok dengan architecture, release plan, security posture, dan kebutuhan pengguna. Loop menyelesaikan task; engineering memastikan task itu memang layak diselesaikan dengan cara tersebut.

Studi kasus besar menunjukkan potensi sekaligus batas generalisasi

OpenAI melaporkan satu product repository yang dibangun tanpa human-written code, dengan sekitar satu juta baris, sekitar 1.500 pull request dalam lima bulan, dan estimasi waktu sekitar sepersepuluh dibanding implementasi manual. Tim tersebut tidak sekadar memberi prompt ke model yang lebih kuat. Mereka membentuk repository agar agent dapat membaca aturan, menjalankan test, meminta review, dan memperbaiki perubahan dalam loop.

Kasus berikutnya menghasilkan Symphony, orchestrator yang mengubah issue tracker menjadi control plane untuk always-on agents. OpenAI melaporkan peningkatan landed pull requests hingga 500 persen pada beberapa tim. Namun, halaman yang sama juga menjelaskan alasan sistem itu dibutuhkan: engineer mulai kewalahan mengelola tiga sampai lima sesi agent interaktif dan kehilangan context tentang sesi mana yang sedang mengerjakan apa.

Dua angka tersebut adalah first-party case studies, bukan benchmark netral. Repository greenfield, kualitas model, tooling internal, dan kebijakan tanpa human-written code membuat konteksnya berbeda dari tim lain. Pelajarannya bukan bahwa setiap perusahaan harus menyalin target satu juta baris, tetapi bahwa productivity bergantung pada environment, test, control plane, dan human attention.

Output volume bahkan dapat menjadi metric yang menyesatkan. Lebih banyak pull request dapat berarti progress, tetapi juga dapat meningkatkan review queue, merge conflict, dan cognitive load. Metrik yang lebih sehat menghubungkan throughput dengan defect rate, lead time, rollback, user outcome, security finding, dan maintenance cost.

Satu agent atau swarm bukan keputusan ideologis

Sebuah guest post praktisi Cisco di blog LangChain memakai "agentic engineering" untuk arsitektur multi-agent yang meniru engineering team. Worker agents menangani development, testing, debugging, atau operation, sedangkan leader layer mengoordinasikan state, visibility, dan workflow lintas tim. Pilot pada sumber itu melaporkan penghematan waktu yang besar, tetapi tetap merupakan hasil dari arsitektur dan workload tertentu.

Swarm berguna ketika pekerjaan dapat dipecah dan interface antar bagian cukup jelas. Agent explorer dapat mencari root cause, agent implementer membuat perubahan, agent tester menjalankan skenario, dan agent reviewer memeriksa security. Parallelism mengurangi elapsed time jika setiap agent tidak saling menunggu atau mengubah source yang sama.

Satu agent sering lebih baik untuk masalah yang membutuhkan pemahaman kausal panjang. Debugging numerik, migration kompleks, dan refactor architecture dapat kehilangan coherence bila terlalu cepat dibagi. Coordination overhead, duplicate context, dan compositional error dapat lebih mahal daripada tambahan concurrency.

Keputusan jumlah agent seharusnya mengikuti bentuk task. Mulai dengan satu agent dan verifier terpisah. Tambahkan specialist agent ketika trace menunjukkan bottleneck yang jelas, bukan karena diagram swarm terlihat lebih maju.

Specification menjadi executable management surface

Dalam workflow tradisional, spec sering dianggap dokumen yang dibaca sekali sebelum implementation. Dalam agentic engineering, spec menjadi input aktif yang berulang kali dibaca oleh model, planner, reviewer, dan verifier. Ambiguitas kecil dapat diperbanyak menjadi puluhan keputusan yang konsisten tetapi salah arah.

Spec yang agent-friendly memuat outcome, constraint, non-goal, interface, sample, test command, source of truth, dan kondisi yang mengharuskan escalation. Ia juga menjelaskan apa yang tidak boleh diubah. Instruksi seperti "perbaiki test" terlalu lemah bila agent dapat menurunkan assertion atau menghapus scenario yang gagal.

Specification tidak harus panjang. Task sempit dapat memiliki contract singkat jika system context sudah tersimpan pada repository skills. Sebaliknya, agent tidak seharusnya menerima satu kalimat untuk pekerjaan yang menyentuh schema, permission, dan backward compatibility.

Engineer perlu memperlakukan perubahan spec seperti perubahan code. Versioning, review, dan history membantu menjelaskan mengapa agent mengambil keputusan tertentu. Ketika hasil buruk, pertanyaan pertama bukan hanya "model mana yang dipakai?", tetapi "intent dan boundary apa yang sebenarnya terlihat oleh model saat itu?"

Test dan eval adalah bahasa kepercayaan

Addy Osmani menyebut testing sebagai pembeda terbesar antara vibe coding dan agentic engineering. Coding agent yang dapat menjalankan code memiliki kesempatan memperbaiki dirinya berdasarkan feedback. Tanpa test, model dapat menyatakan selesai berdasarkan plausibility. Dengan test yang tepat, system dapat mengikat progress pada evidence.

Unit test dan integration test tetap penting, tetapi agentic system membutuhkan eval yang lebih luas. Tool selection, permission compliance, hallucinated citation, recovery dari failure, cost, latency, dan frequency of escalation dapat menjadi bagian quality model. Untuk agent yang berinteraksi dengan pengguna, eval juga perlu mengukur intent alignment dan kemungkinan tindakan yang tidak dapat dibatalkan.

Evals tidak identik dengan satu benchmark publik. Mereka harus mewakili distribusi task organisasi dan failure mode yang pernah terjadi. Incident, review finding, dan rejected output sebaiknya diubah menjadi regression case. Dengan cara itu, pengalaman manusia menjadi artifact yang meningkatkan agent berikutnya.

LLM judge dapat membantu menilai kualitas yang subjektif, tetapi perlu calibration dan sampling manusia. Properti mekanis harus diperiksa dengan mekanisme deterministik. Sistem tidak boleh dinyatakan terpercaya hanya karena satu model reviewer menyukai output model implementer.

Autonomy harus diukur, bukan diasumsikan

Anthropic menganalisis jutaan interaksi Claude Code dan API untuk melihat seberapa lama agent bekerja dan seberapa banyak keputusan didelegasikan. Pada sesi terpanjang, durasi kerja sebelum berhenti hampir dua kali lipat dalam tiga bulan, dari kurang dari 25 menit menjadi lebih dari 45 menit. Anthropic juga menekankan bahwa data tersebut berasal dari periode, produk, dan metode sampling tertentu.

Durasi lebih panjang bukan otomatis hasil lebih baik. Agent dapat bekerja lama karena task memang sulit, karena environment lambat, atau karena ia tersesat. Ukuran autonomy perlu dipasangkan dengan completion quality, intervention rate, rollback, cost, dan severity dari tindakan.

Autonomy juga bukan satu switch. Tim dapat memberi kebebasan penuh untuk membaca repository dan menjalankan test, tetapi meminta approval untuk dependency baru, migration, deployment, atau data access. Permission dapat bertingkat berdasarkan risk class dan environment.

Pola yang sehat adalah autonomy bertahap. Mulai dari read-only analysis, naik ke draft diff, lalu PR otomatis, dan terakhir tindakan produksi pada scope yang sangat sempit. Setiap kenaikan membutuhkan evidence bahwa monitoring, rollback, dan escalation sudah bekerja.

Agentic security dimulai dari boundary tool

Agent yang hanya menulis jawaban memiliki blast radius terbatas. Agent yang dapat membaca email, menjalankan shell, mengubah database, dan deploy service membawa risiko yang berbeda. Kemampuan tool perlu dipandang sebagai permission, bukan feature list.

Anthropic menyoroti prompt injection sebagai serangan yang dapat disembunyikan dalam content yang dibaca agent. Issue, web page, email, document, atau log dapat membawa instruksi berbahaya yang mencoba mengalihkan tujuan sistem. Tidak ada satu filter yang menjamin keamanan, sehingga pertahanan perlu berada pada model, tool, permission, environment, monitoring, dan human approval.

Principle of least privilege harus diterapkan per task. Agent dokumentasi tidak membutuhkan production credential. Agent yang menganalisis database tidak harus memiliki permission menulis. Temporary credential, sandbox, network allowlist, secret isolation, dan immutable audit log membuat tindakan dapat dibatasi dan diperiksa.

Ambiguity juga merupakan masalah keselamatan. Ada trade-off antara agent yang terlalu sering berhenti dan agent yang selalu menebak intent. Engineering yang baik menentukan kategori keputusan yang dapat diselesaikan sendiri, kategori yang memerlukan research tambahan, dan kategori yang harus kembali ke manusia.

Observability harus menangkap keputusan, bukan hanya error

Log aplikasi tradisional mencatat request, latency, dan exception. Agentic workflow perlu melihat prompt version, context source, model, tool call, permission, state transition, verifier result, retry, cost, dan human intervention. Tanpa trace seperti itu, tim hanya mengetahui bahwa agent gagal, bukan mengapa ia memilih tindakan tersebut.

Observability juga menjadi dasar improvement. Failure yang berulang dapat menunjukkan tool description buruk, context tidak lengkap, verifier lemah, atau task decomposition salah. Perbaikan yang tepat mungkin berada pada harness, bukan prompt. Trace memungkinkan tim membandingkan perubahan tersebut pada eval yang sama.

Data agent dapat memuat source code, user content, dan secret. Karena itu observability tidak boleh berarti menyimpan semua context tanpa kontrol. Redaction, retention policy, access control, dan privacy review tetap diperlukan.

AgentOps pada framing workshop AGENT 2026 mencakup monitoring, evaluation, intervention, dan oversight setelah deployment. Ini memperluas software operations klasik karena behavior agent probabilistik dan dapat berubah ketika model, prompt, tools, atau data source diperbarui.

Keahlian manusia tidak berkurang, tetapi berubah bentuk

Agent membuat implementation lebih murah. Simon Willison menulis bahwa tantangan utamanya adalah bagaimana intuisi engineering berubah ketika initial working code dapat dihasilkan hampir tanpa biaya. Code yang murah dapat mendorong lebih banyak experiment, tetapi juga lebih banyak code yang perlu dibaca, diuji, dan dipelihara.

Senior engineer sering memperoleh leverage besar karena memiliki model mental untuk mengevaluasi architecture, security, dan trade-off. Mereka dapat mengenali output yang terlihat benar tetapi melanggar invariant. Junior engineer berisiko menghasilkan lebih banyak code sebelum memiliki kemampuan debug dan review yang cukup.

Solusinya bukan melarang agent, melainkan mengubah pembelajaran. Engineer tetap perlu membaca code, menjelaskan behavior, membangun test, melakukan incident analysis, dan memahami system design. Agent dapat dipakai sebagai tutor atau pair, tetapi pemahaman tidak boleh diganti dengan acceptance tanpa evaluasi.

Skill baru muncul di sekitar task decomposition, context design, tool contract, eval design, trace analysis, permission architecture, dan orchestration. Skill lama seperti debugging, data modeling, security, dan distributed systems menjadi semakin berharga karena agent memperbesar dampak keputusan yang benar maupun salah.

Agentic engineering di luar application coding

Repository autoresearch milik Karpathy memberi contoh agentic workflow untuk AI research. Agent mengubah train.py, menjalankan training selama lima menit, memeriksa apakah metric membaik, mempertahankan atau membuang perubahan, lalu mengulang. Manusia lebih banyak mengubah program.md, yaitu context dan aturan organisasi riset, daripada menyentuh training code secara langsung.

Contoh tersebut menunjukkan bahwa artifact utama dapat bergeser. Engineer tidak hanya membuat program akhir, tetapi membuat system yang menghasilkan rangkaian experiment. Output pentingnya mencakup code, metric, log, failed attempt, dan aturan seleksi.

Pola serupa dapat dipakai untuk data pipeline, security triage, infrastructure optimization, dan scientific computing. Namun, verifier harus sesuai domain. Metric training yang naik tidak menjamin model lebih aman atau lebih berguna. Cost turun tidak berarti latency tail dan reliability tetap baik.

Agentic engineering karena itu bukan sinonim coding automation. Ia adalah cara mengelola delegated execution pada domain yang memiliki tools, feedback, dan evidence. Semakin jauh agent bergerak dari repository ke dunia nyata, semakin penting governance dan domain expertise.

Tingkat kematangan yang lebih berguna daripada label

Organisasi tidak perlu menyatakan dirinya "agentic" hanya karena memakai coding assistant. Tingkat kematangan dapat dinilai dari scope delegasi dan quality control yang benar-benar berjalan. Label tanpa evidence cenderung menyembunyikan manual work dan risk yang belum diselesaikan.

Tingkat	Bentuk kerja	Quality control
0. Suggestion	Model memberi snippet atau jawaban	Human menyalin dan memeriksa seluruhnya
1. Interactive agent	Agent mengubah file dan menjalankan tools dalam satu sesi	Human mengarahkan setiap task dan review diff
2. Verified loop	Agent mengulang sampai deterministic gates lulus	Budget, state, test, dan terminal state tersedia
3. Orchestrated workflow	Issue, event, atau schedule memulai beberapa task	Control plane, isolation, ownership, dan audit trail
4. Operational agent system	Agent bekerja pada production workflow	Continuous eval, permission tiers, monitoring, rollback, incident process
5. Learning system	Trace digunakan untuk memperbaiki prompt, tool, memory, atau model	Held-out eval, versioning, approval, dan governance perubahan

Naik tingkat bukan selalu tujuan. Banyak tim akan mendapatkan nilai terbaik pada tingkat 1 atau 2. Tingkat lebih tinggi menambah coordination, cost, security surface, dan operational burden. Maturity berarti memilih autonomy yang sepadan dengan evidence dan risk, bukan mengejar automation maksimum.

Tabel tersebut juga membantu memisahkan demo dari capability produksi. Agent yang berhasil menyelesaikan satu issue belum tentu siap menerima event tanpa supervisi. Sistem yang dapat membuka PR otomatis belum tentu siap deploy atau menangani data sensitif.

Yang bukan agentic engineering

Menghasilkan code besar dari satu prompt tanpa review bukan agentic engineering profesional. Itu dapat menjadi prototype yang valid, tetapi tidak memiliki discipline yang membuat hasilnya dapat dipertanggungjawabkan. Menambahkan kata "agent" pada script otomatis juga tidak cukup bila script tersebut tidak memiliki goal-directed decision, feedback, atau tool-mediated iteration.

Menggunakan banyak agent juga bukan bukti kematangan. Lima agent yang saling mengulang pendapat dapat lebih buruk daripada satu agent dengan test yang kuat. Diagram kompleks tidak menggantikan source of truth, ownership, dan verifier.

Agentic engineering juga bukan alasan menghapus classical software engineering. Version control, modularity, testability, observability, secure design, dan incident response tetap menjadi fondasi. Agent mempercepat eksekusi di atas fondasi tersebut, bukan menghapus kebutuhan untuk memilikinya.

Terakhir, agentic engineering bukan pengalihan tanggung jawab. Model dapat membuat keputusan lokal, tetapi organisasi tetap menentukan permission, acceptability, dan release. Ketika system gagal, "agent yang melakukannya" bukan postmortem yang cukup.

Penutup

Loop engineering menjelaskan cara agent bekerja berulang sampai mencapai kondisi tertentu. Agentic engineering memperluas pertanyaan itu ke seluruh lifecycle: siapa yang menentukan intent, bagaimana tools dibatasi, bukti apa yang diterima, bagaimana perubahan diintegrasikan, dan siapa yang memiliki outcome. Karena itu menempatkan artikel ini setelah loop engineering masuk akal secara konseptual, meskipun istilah agentic engineering muncul lebih dahulu pada awal Februari 2026.

Agentic engineering yang matang tidak dinilai dari seberapa sedikit manusia mengetik. Ia dinilai dari seberapa baik manusia mengubah expertise menjadi spec, tests, tools, policy, eval, dan review yang dapat digunakan agent. Agent mengambil lebih banyak tindakan, tetapi manusia tetap menentukan arti benar, aman, dan layak dirilis.

Pergeseran tersebut membuat software engineering lebih sedikit tentang kecepatan menghasilkan syntax dan lebih banyak tentang kualitas keputusan yang dikalikan oleh automation. Tim yang hanya mengejar output akan menghasilkan lebih banyak perubahan. Tim yang membangun evidence, boundary, dan learning loop memiliki peluang menghasilkan sistem yang benar-benar lebih baik. Mulailah dari task sempit dengan test dan owner yang jelas, ukur outcome dan cost per accepted task, beri permission berdasarkan risk, dan ubah failure menjadi regression eval atau harness improvement.