Kembali ke artikel
Dari Terima Tiket ke Agentic Engineering

Dari Terima Tiket ke Agentic Engineering

SDLC berbasis tiket kewalahan oleh AI. Dengan konteks sebagai infrastruktur, fokus beralih dari menulis kode ke merancang sistem yang memproduksinya.

29 Juni 2026 · 7 mnt baca
Jadikan sumber pilihan di Google

Saya ingat gesekan yang terjadi saat kami menskalakan transformasi otomatisasi AI kami hingga mencapai 33 inisiatif produksi dalam satu tahun. Awalnya, saya berasumsi bahwa batasannya ada pada kemampuan model AI. Ternyata bukan. Gesekan sebenarnya berasal dari bagaimana kami memberikan instruksi kepada model dan bagaimana kami memverifikasi hasil kerjanya. Kami memperlakukan AI seperti junior developer yang hanya menerima tiket, dengan harapan ia akan langsung menuliskan kode yang kami minta. Namun, model itu runtuh ketika dihadapkan pada skala pembuatan kode dengan AI. Untuk benar-benar menghemat sekitar 29.000 jam kerja per tahun seperti yang akhirnya kami capai, kami harus berhenti bertindak sebagai debugger manusia dan mulai memperlakukan AI sebagai mesin yang membutuhkan kerangka kerja (scaffolding) yang sangat terstruktur.

Asumsi di banyak organisasi adalah bahwa Software Development Life Cycle (SDLC) berbasis tiket adalah bentuk permanen dari pekerjaan software engineering. Kamu menulis tiket, developer mengimplementasikannya, dan seorang reviewer memeriksanya. Tapi ketika implementasi hanya memakan waktu beberapa menit, bukan berminggu-minggu, SDLC tradisional ini kewalahan. Kita sedang bergerak dari dunia sintaks ke dunia intensi, dan pergeseran itu menuntut perombakan total pada cara tim memproduksi perangkat lunak.

Key takeaways

  • Struktur bisa diskalakan, vibe tidak: Prompt kasual cocok untuk membuat prototipe, tetapi sistem produksi membutuhkan disiplin agentic engineering, spesifikasi formal, tes deterministik, dan batasan yang ketat.
  • Desain pabriknya, bukan barangnya: Peran developer berubah dari sekadar menulis sintaks boilerplate menjadi merancang sistem, konteks, alat, dan orkestrasi, yang menghasilkan kode tersebut.
  • Selesaikan masalah 80 persen dengan evaluasi: Model bisa dengan cepat menghasilkan 80% fitur, tetapi edge cases butuh konteks yang dalam. Suite evaluasi otomatis adalah satu-satunya cara berkelanjutan untuk mencapai garis akhir.
  • Kelola konteks sebagai tuas finansial: Dalam ekonomi token, membuang seluruh repositori ke dalam prompt sangat tidak masuk akal secara finansial. Konteks dinamis dan perutean model cerdas wajib digunakan untuk mengendalikan biaya operasional.

Mind map of the factory model concept in agentic engineering.

Spektrum dari vibe coding ke engineering

Transisi dari sekadar menulis sintaks ke mengekspresikan intensi sudah terjadi saat ini. Menurut laporan industri 2026 oleh Index.dev dan GetPanto, 85% professional developer kini rutin menggunakan agen coding AI, dengan perkiraan 41% dari semua kode baru dihasilkan oleh AI. Namun, bagaimana kode itu dihasilkan sangatlah menentukan.

Seperti yang dijabarkan Addy Osmani, Shubham Saboo, dan Sokratis Kartakis dalam laporan tahun 2026 mereka, The New SDLC With Vibe Coding, ada spektrum luas dalam pengembangan berbantuan AI. Di satu sisi ada “vibe coding.” Dalam mode ini, developer menulis prompt kasual, menerima output, dan mengecek manual apakah kode itu bekerja. Saat error, mereka tinggal menyalin pesannya kembali ke chat. Cepat, tidak terstruktur, dan sangat bergantung pada manusia di dalam loop untuk menangkap kesalahan.

Di sisi lain dari spektrum adalah agentic engineering. Pendekatan ini mewajibkan spesifikasi formal, suite tes otomatis, gerbang CI/CD, dan tinjauan arsitektur yang menyeluruh. Ketika kami meluncurkan inisiatif otomatisasi, kami cepat belajar bahwa vibe coding tidak akan bertahan saat masuk ke tahap produksi. Kamu tidak bisa melakukan vibe coding pada sistem yang memproses data pengguna nyata atau transaksi keuangan. Agentic engineering memperlakukan AI sebagai mesin implementasi bertenaga tinggi yang beroperasi ketat dalam batas-batas yang dirancang manusia.

Merancang model pabrik

Terobosan sesungguhnya terjadi saat kamu berhenti mencoba menulis kode dan mulai membangun sistem yang membangun kode. Osmani dan timnya memperkenalkan “model pabrik” untuk menjelaskan perubahan ini. Developer modern bukanlah lagi buruh perakitan yang memasang komponen secara manual; mereka adalah manajer pabrik yang merancang jalur perakitan dan memastikan kontrol kualitas.

Jika developer adalah manajer pabrik, model AI hanyalah mesin mentah di lantai pabrik. Sebuah mesin tidak bisa memproduksi mobil sendirian. Ia butuh sabuk, roda gigi, dan sensor keamanan. Dalam agentic engineering, mesin pendukung inilah yang disebut scaffolding.

Dalam implementasi kami, pergeseran inilah yang persis harus kami lakukan. Kami tidak mungkin meninjau manual setiap baris kode yang dihasilkan di puluhan workflow yang berbeda. Kami harus menginvestasikan waktu teknis kami pada scaffolding itu sendiri: instruksi dan file aturan (seperti AGENTS.md), alat spesifik yang bisa dipanggil agen, sandbox eksekusi yang terisolasi, serta logika orkestrasi. Scaffolding inilah yang menjaga agen tetap fokus, aman, dan produktif. Tanpa scaffolding yang kuat, kamu sekadar mengandalkan kemampuan dasar model, yang sering berujung pada output yang tidak terduga dan utang teknis yang menumpuk.

Hierarchy diagram comparing the ticket-driven SDLC to agentic engineering.

Masalah 80 persen dan bottleneck verifikasi

Ada satu jebakan umum dalam pengembangan berbantuan AI: masalah 80 persen. Agen bisa dengan sangat cepat menghasilkan 80% kode untuk suatu fitur, tetapi sisa 20%-nya, kasus pinggiran, penanganan error, titik integrasi, dan kebenaran detail yang penting, membutuhkan konteks mendalam yang jarang dimiliki model saat ini.

Bahkan, studi tahun 2026 oleh METR menemukan bahwa developer berpengalaman yang menggunakan asisten AI justru membutuhkan waktu 19% lebih lama untuk beberapa tugas. Keterlambatan ini sebagian besar berasal dari waktu yang dihabiskan untuk memverifikasi, melakukan debugging, dan mengoreksi output AI. Sifat error AI telah berevolusi dari sekadar kesalahan sintaks sederhana menjadi kegagalan konseptual yang lebih halus: salah asumsi logika bisnis, gagal meminta klarifikasi, dan keputusan arsitektur yang menambah beban pemeliharaan jangka panjang. Kesalahan-kesalahan ini sulit dideteksi justru karena kodenya “terlihat benar” dan sering kali lolos uji dasar.

Kami melihat langsung dampak ini. Untuk mencapai target 33 deployment produksi, kami harus berhenti bertindak sebagai lapisan debugging utama untuk agen. Solusinya adalah menanamkan tes dan evaluasi langsung ke dalam feedback loop. Pengujian dalam alur kerja agenik sangat bergantung pada scaffolding untuk memfasilitasi koreksi mandiri yang otomatis. Saat agen menulis sebuah fungsi, scaffolding menyediakan lingkungan eksekusi untuk menjalankan tes otomatis. Jika tes gagal, logika orkestrasi menangkap pesan error dan mengirimkannya kembali ke model untuk mencoba lagi.

Kami harus berpindah dari peran “konduktor”, memberikan arahan real-time langsung di dalam editor, menjadi “orkestrator”, yang beroperasi di tingkat abstraksi yang lebih tinggi. Kami mendefinisikan tujuan, menyusun kriteria evaluasi, dan meninjau hasil akhir yang telah diverifikasi. Seperti yang diulas dalam Scaling AI From Experiment to Infrastructure Inside a Product Org, pergeseran postur inilah yang memungkinkan tim kecil mempertahankan kecepatan tinggi tanpa mengorbankan kualitas.

Flowchart showing how scaffolding and automated tests solve the 80 percent problem.

Mengubah peran manusia di era AI

Penurunan hambatan untuk menciptakan perangkat lunak akan terus berlanjut, dan peran manusia berevolusi secara langsung menjadi salah satu penilaian dan pengarahan. Kemampuan untuk merumuskan spesifikasi yang presisi, mengevaluasi hasil akhir dengan kritis, dan mendesain sistem pembatas yang efektif menjadi jauh lebih berharga dibandingkan sekadar kemampuan implementasi mentah.

Saat kami memetakan arsitektur untuk 33 inisiatif tersebut, kami harus menghadapi kenyataan bahwa proses generation AI memang cepat, tetapi proses verifikasinya akan sangat lambat jika hanya diserahkan pada manusia. Setiap pull request yang dihasilkan agen harus diperiksa untuk melihat adanya ketergantungan yang berhalusinasi, penanganan error yang tidak memadai, dan celah-celah halus yang sepintas terlihat benar. Kami membangun aturan deterministik spesifik untuk menangkap isu-isu ini sebelum sampai ke meja peninjau manusia. Sebagai contoh, setiap kode yang memodifikasi skema database kami wajib lulus linter migrasi ketat sebelum ditinjau manusia.

Hal ini membutuhkan pergeseran budaya dalam tim engineering. Kami harus berhenti menganggap pengembangan dengan AI sebagai fitur produktivitas belaka dan mulai memperlakukannya sebagai investasi teknis murni. Kamu harus membangun substrat produksi sebelum mencoba melakukan skala. Artinya, patokan keberhasilan harus ditetapkan pada tahap evaluasi, bukan sekadar demo yang berjalan. Demo yang berhasil hanya membuktikan bahwa sebuah agen bisa sukses satu kali. Suite evaluasi yang lolos membuktikan agen tersebut sukses secara konsisten. Dengan memperlakukan scaffolding sebagai aset bersama tim, memelihara system prompt, pustaka alat, dan pipeline evaluasi di dalam version control, kami mampu melipatgandakan dampak positif kami ke seluruh organisasi.

Rekayasa konteks sebagai strategi finansial

Dalam ekonomi token, rekayasa konteks bukan sekadar syarat teknis; ini adalah inti dari strategi finansial. Setiap kali kamu berinteraksi dengan Large Language Model, kamu dikenakan biaya berdasarkan token input dan output. Dokumen Google tahun 2026 menekankan bahwa biaya operasional dari vibe coding sangat masif dan cepat membengkak. Developer sering memasukkan puluhan file besar tak terstruktur ke dalam jendela konteks dan terus-menerus meminta model memperbaiki kesalahannya yang belum diverifikasi. Praktik ini menciptakan prompting loop mahal dengan tingkat keberhasilan lemparan pertama yang sangat rendah.

Agentic engineering membalikkan model ekonomi ini. Pendekatan ini membutuhkan investasi awal yang sengaja disiapkan oleh tim sebelum sebaris kode produksi pun dibuat. Kamu rela mengeluarkan capital expenditure yang lebih tinggi di awal untuk merancang skema API, membangun suite tes deterministik, dan menstrukturkan konteks dinamis.

Daripada membuang 100.000 token dari repositori ke dalam setiap prompt, yang jelas tidak berkelanjutan untuk skala besar, kamu menggunakan konteks dinamis. Agen memanggil kemampuan spesifik hanya ketika tugas tersebut membutuhkannya. Kamu memanfaatkan intelligent model routing, mengirimkan tugas arsitektur rumit ke model-model raksasa, sementara mendelegasikan pembuatan tes deterministik dan peninjauan kode ke model-model yang lebih kecil, lebih cepat, dan secara signifikan lebih murah.

Generasi kode sebagian besar sudah terpecahkan. Keahlian baru yang dibutuhkan sekarang adalah verifikasi, penilaian, dan arahan.

Referensi

  • Osmani, A., Saboo, S., & Kartakis, S. (2026). The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering. Google.
  • Index.dev & GetPanto. (2026). AI Coding Assistant Statistics 2025-2026.
  • METR. (2026). Uplift Update: Measuring the Impact of AI Coding Tools.

Pertanyaan umum

Apa bedanya vibe coding dan agentic engineering?

Vibe coding mengandalkan prompt kasual, kode sekali pakai, dan pengujian manual, yang membuat manusia terus berada dalam siklus coba-coba. Agentic engineering memperlakukan AI sebagai mesin implementasi yang dibatasi oleh spesifikasi formal, tes otomatis, dan aturan deterministik.

Bagaimana AI mengubah siklus hidup pengembangan perangkat lunak (SDLC)?

AI menekan fase implementasi dari berminggu-minggu menjadi hanya hitungan jam, sehingga menggeser bottleneck utama ke tahap pengumpulan kebutuhan, arsitektur, dan verifikasi. Peran developer pun bergeser dari sekadar menulis sintaks menjadi desainer sistem dan kriteria evaluasi yang menghasilkan kode tersebut.

Apa yang dimaksud masalah 80% dalam AI development?

Masalah 80% merujuk pada realitas bahwa agen AI bisa dengan sangat cepat menghasilkan 80% dari sebuah fitur, namun sering kesulitan dengan sisa 20%, seperti edge cases, error handling, dan logika bisnis yang rumit. Solusinya membutuhkan investasi di awal pada suite evaluasi otomatis, bukan sekadar melakukan debugging manual.

Mengapa rekayasa konteks dianggap sebagai strategi finansial?

Setiap token yang dikirim ke LLM memakan biaya. Daripada membuang keseluruhan repositori ke setiap prompt (yang mahal dan penuh noise), rekayasa konteks menggunakan pemuatan dinamis dan rute cerdas antar model untuk mengirimkan hanya informasi yang relevan, sehingga menekan biaya operasional secara drastis.