Metode Human in the Loop: Pendekatan Black Box untuk AI-Assisted Coding

AI-assisted coding dapat mempercepat proses pengembangan software, tetapi hasilnya sangat bergantung pada cara kita berinteraksi dengan AI. Dalam artikel ini, kami membagikan metode yang kami gunakan sehari-hari di Tonjoo untuk memanfaatkan AI-assisted coding dalam pengembangan Next.js, Laravel, maupun WordPress. Pendekatan ini bersifat framework-agnostic, sehingga prinsipnya dapat diterapkan pada hampir semua tech stack.

Kenapa Menggunakan Metode Ini?

Penting untuk menentukan seberapa besar kendali yang diberikan kepada AI selama proses development. Secara umum, terdapat tiga pendekatan yang dapat digunakan ketika bekerja dengan coding agent.

• Full Otomatis (Human Outside the Loop): Cukup berikan PRD (Product Requirement Document), AI mengerjakan semuanya dari awal hingga akhir. Cocok untuk task sederhana, tetapi kurang ideal untuk proyek yang kompleks.
• Semi Otomatis (Human in the Loop): AI mengerjakan task, sementara developer melakukan review pada setiap checkpoint (antar commit). Pendekatan inilah yang akan kita gunakan.
• Assisted: Developer menyetujui setiap aksi AI satu per satu. Pendekatan ini memberikan kontrol penuh, tetapi prosesnya menjadi lebih lambat.

Di antara ketiga pendekatan tersebut, kami memilih Human in the Loop sebagai sweet spot yang tetap memberikan kontrol di setiap checkpoint.

Pendekatan Black Box

Ilustrasi berikut menggambarkan bagaimana pendekatan Black Box diterapkan dalam workflow AI-assisted coding.

Dalam dunia software engineering, Black Box Testing adalah teknik pengujian pada kegunaan perangkat lunak tanpa perlu melihat bagaimana kode di dalamnya diimplementasikan. Dengan kata lain, seorang penguji tidak perlu mengetahui struktur kode, algoritma, maupun logika internal aplikasi. Cukup berikan suatu input, amati output yang dihasilkan, lalu tentukan apakah hasilnya sudah sesuai dengan kebutuhan.

Prinsip seperti itu kami adaptasi ke dalam workflow AI-assisted coding. Perbedaannya, “black box” yang dimaksud bukan lagi aplikasi yang sedang diuji, melainkan proses implementasi yang dilakukan oleh AI agent.

Jadi, selama AI sedang mengerjakan sebuah task, kita tidak perlu langsung memeriksa setiap baris kode yang ditulisnya. Sebaliknya, kita memperlakukannya seperti sebuah sistem yang menerima input dan menghasilkan output.

Secara sederhana, alurnya seperti ini:

1. Developer memberikan input kepada AI, misalnya berupa deskripsi task, error log, API response, screenshot, atau konteks proyek.
2. AI mengolah informasi tersebut dan melakukan implementasi pada codebase.
3. Developer menjalankan aplikasi, menguji fitur yang dibuat, lalu mengevaluasi apakah output yang dihasilkan sudah sesuai dengan ekspektasi.

Jika hasilnya belum sesuai, proses review belum perlu dilakukan secara mendalam. Developer cukup mengumpulkan informasi yang relevan, seperti pesan error, screenshot terbaru, atau hasil yang ditampilkan oleh aplikasi yang tidak sesuai, kemudian memberikannya kembali kepada AI sebagai input baru. AI pun akan memperbaiki implementasinya, lalu proses validasi diulang kembali.

Siklus ini akan terus berlangsung hingga output yang dihasilkan sesuai dengan kebutuhan. Dengan mengimplementasikan metode ini, developer akan lebih banyak menghabiskan waktu untuk mengevaluasi hasil daripada mengawasi setiap langkah yang dilakukan AI selama proses implementasi. Kerja pun jadi lebih efektif dan efisien, sehingga produktivitas turut meningkat.

Langkah-Langkah Implementasi Human in the Loop

Setup Agent Standards

Langkah pertama sebelum menggunakan Coding Agent untuk mengerjakan kode adalah memastikan Coding Agent memiliki pemahaman yang cukup tentang proyek yang sedang dikerjakan.

Berbeda dengan developer yang dapat mempelajari struktur proyek secara bertahap, Coding Agent hanya mengetahui informasi yang diberikan kepadanya. Tanpa konteks yang jelas, Coding Agent cenderung menghasilkan implementasi yang tidak konsisten, menggunakan pola yang berbeda dengan codebase, atau bahkan melanggar standar yang telah ditetapkan oleh tim developer.

Untuk mencegah hal tersebut terjadi, kami selalu memulai dengan membuat AGENTS.md beserta dokumentasi pendukung di dalam repository. File ini berfungsi sebagai panduan bagi Coding Agent mengenai aturan, konvensi, dan karakteristik proyek sehingga Coding Agent dapat menghasilkan implementasi yang lebih konsisten.

Sebagian besar coding agent modern, seperti Claude Code, Codex, maupun OpenCode, sudah dapat membuat file AGENTS.md secara otomatis. Umumnya, proses ini dapat dilakukan menggunakan perintah seperti /init di dalam sesi coding agent.

Claude Code secara default membaca file CLAUDE.md. Agar konfigurasi tetap dapat digunakan oleh coding agent lain, Tim Tonjoo biasanya menambahkan instruksi berikut ke dalam CLAUDE.md:

always read AGENTS.md

Lewat teknik tersebut, AGENTS.md menjadi sumber dokumentasi utama, sedangkan CLAUDE.md hanya berfungsi untuk mengarahkan Claude agar selalu menggunakan dokumentasi tersebut.

Perlu diketahui bahwa is AGENTS.md sebaiknya disesuaikan dengan teknologi yang digunakan dalam proyek. Tujuannya bukan untuk menjelaskan seluruh codebase, melainkan untuk memberikan aturan-aturan penting yang harus dipatuhi AI selama proses development.

Sebagai contoh, berikut beberapa hal yang biasa kami cantumkan.

Next.js:

• Aturan penggunaan environment variable
• Larangan menggunakan NEXT_PUBLIC_* untuk kebutuhan tertentu (lihat artikel kami mengenai pitfall NEXT_PUBLIC_* di production)
• Struktur folder
• Konvensi data fetching

Laravel:

• Standar penggunaan Artisan command
• Struktur Service dan Repository
• Konvensi migration

WordPress:

• Standar pengembangan plugin dan theme
• Aturan escaping dan sanitasi data
• Konvensi penamaan hook

Selain itu, AGENTS.md tidak harus sempurna sejak awal. File ini dapat terus diperbarui seiring bertambahnya kebutuhan proyek. Bahkan, file AGENTS.md yang dihasilkan secara otomatis oleh coding agent biasanya sudah cukup baik sebagai langkah awal atau permulaan.

Selain menjelaskan konvensi teknis, AGENTS.md juga menjadi tempat yang tepat untuk mendokumentasikan engineering policy yang berlaku di dalam perusahaan atau tim.

Engineering policy merupakan sekumpulan aturan dan keputusan teknis yang telah disepakati agar seluruh developer maupun AI agent menghasilkan kode yang konsisten. Dengan memasukkan kebijakan tersebut ke dalam AGENTS.md, Coding Agent tidak hanya memahami cara membuat kode yang benar secara sintaks, tetapi juga sesuai dengan standar engineering yang berlaku pada proyek.

Sebagai contoh, pada pengembangan aplikasi Next.js, Tonjoo memiliki kebijakan untuk meminimalkan penggunaan variabel NEXT_PUBLIC_*. Alasannya, variabel dengan awalan tersebut akan diekspos ke sisi client dan memiliki karakteristik build-time yang dapat menimbulkan berbagai kendala saat aplikasi dijalankan di lingkungan production.

Karena itu, Coding Agent perlu mengetahui kebijakan tersebut sejak awal agar tidak secara otomatis menggunakan NEXT_PUBLIC_* ketika menghasilkan implementasi baru. Sebagai gantinya, Coding Agent diarahkan untuk mengikuti pola yang telah menjadi standar di proyek.

Semakin banyak engineering policy yang terdokumentasi dengan baik, semakin kecil kemungkinan Coding Agent menghasilkan kode yang bertentangan dengan standar internal perusahaan. Dengan kata lain, AGENTS.md tidak hanya berfungsi sebagai dokumentasi proyek, tetapi juga sebagai media untuk menerjemahkan sekaligus mentransfer ide-ide maupun cara berpikir tim engineering kepada Coding Agent. 

Susun Rencana Implementasi (Gunakan Plan Mode)

Setelah AI memahami standar proyek melalui AGENTS.md, langkah berikutnya adalah meminta AI menyusun rencana implementasi terlebih dahulu.

Hindari langsung meminta AI menulis kode. Sebaliknya, gunakan Plan Mode agar AI terlebih dahulu menganalisis kebutuhan, memahami codebase, mengidentifikasi file yang akan diubah, serta menyusun langkah-langkah implementasi.

Sebagai contoh, Anda dapat menggunakan prompt seperti berikut.

Ingat, AI tidak mengetahui seluruh informasi mengenai proyek Anda. AI hanya dapat mengambil keputusan berdasarkan konteks yang diberikan melalui prompt maupun dokumentasi pendukung. Oleh karena itu, semakin lengkap informasi yang disediakan, semakin besar peluang AI menghasilkan implementasi yang sesuai dengan kebutuhan.

Di Tonjoo, kami bahkan memiliki Technical Analyst yang secara khusus membantu menyusun dokumentasi seperti Entity Relationship Diagram (ERD), swimlane diagram, user stories, serta berbagai dokumen teknis lainnya.

Dalam pendekatan Black Box, dokumentasi tersebut menjadi salah satu sumber informasi utama saat menyusun prompt. Developer tidak perlu menjelaskan seluruh kebutuhan dari awal pada setiap percakapan. Cukup lampirkan dokumentasi yang relevan agar AI memahami konteks proyek, batasan implementasi, serta standar yang harus dipenuhi.

Dengan dokumentasi yang baik, proses prompting menjadi lebih terarah, hasil implementasi lebih konsisten, dan developer lebih mudah memvalidasi apakah pekerjaan AI telah sesuai dengan kebutuhan maupun standar engineering yang berlaku. Semakin kaya konteks yang diberikan, umumnya semakin baik pula kualitas output yang dihasilkan AI.

Namun, bukan berarti seluruh informasi harus dimasukkan ke dalam satu prompt. Jika sebuah fitur memiliki cakupan yang besar atau melibatkan banyak perubahan, sebaiknya dikelompokkan menjadi beberapa task yang lebih kecil. Tujuannya agar AI dapat tetap fokus pada satu tujuan dalam setiap iterasi sehingga hasilnya lebih mudah ditinjau dan diperbaiki apabila diperlukan.

Tinjau dan Validasi Rencana Implementasi

Tahap ini merupakan checkpoint terpenting dalam pendekatan Human in the Loop. Sebelum AI mulai melakukan perubahan pada codebase, luangkan waktu untuk membaca dan mengevaluasi rencana implementasi yang telah disusun. Tujuannya untuk memastikan bahwa AI benar-benar memahami kebutuhan dan memilih pendekatan yang tepat.

Beberapa hal yang perlu diperhatikan antara lain:

• Apakah rencana tersebut sudah sesuai dengan tujuan (goals) yang ingin dicapai?
• Apakah perubahan yang diusulkan berpotensi merusak fitur yang sudah ada?
• Apakah pendekatan yang dipilih masuk akal dan sesuai dengan arsitektur proyek?

Jika ada bagian yang kurang tepat, jangan ragu untuk mendiskusikannya dengan AI. Berikan masukan, ajukan pertanyaan, atau tantang alasan di balik pendekatan yang dipilih hingga AI menghasilkan rencana yang lebih baik.

Bahkan, jika diperlukan, Anda juga dapat meminta coding agent lain untuk melakukan review terhadap rencana tersebut sebelum implementasi dimulai. Pendekatan ini memberikan sudut pandang tambahan dan membantu menemukan potensi masalah yang mungkin terlewat.

Jalankan Implementasi (Gunakan Auto Accept)

Setelah rencana implementasi disetujui, buatlah branch baru agar seluruh perubahan AI terisolasi dari branch utama, sehingga hasil implementasi dapat ditinjau, diuji, atau bahkan dibuang tanpa memengaruhi codebase utama.

Selanjutnya, jalankan coding agent menggunakan Auto Accept. Mode ini memungkinkan AI untuk mengeksekusi rencana yang telah disetujui tanpa harus meminta konfirmasi pada setiap aksi yang dilakukan.

Hingga artikel ini dipublikasikan (07/26), sebagian besar coding agent modern sudah mampu melakukan berbagai aktivitas development secara sistematis, antara lain:

• Menulis dan memperbarui kode
• Menjalankan proses build atau linting untuk memvalidasi implementasi
• Menjalankan server lokal
• Membuat maupun memperbarui test sesuai kebutuhan.

Pada tahap keempat ini, tujuan utama bukan memastikan seluruh kebutuhan bisnis telah terpenuhi, melainkan memastikan implementasi dapat berjalan dengan baik dari sisi teknis. AI diharapkan menghasilkan kode yang dapat dikompilasi, tidak mengalami compile error, serta bebas dari runtime error yang menghambat proses development.

Verifikasi terhadap alur bisnis (business process) tetap dilakukan oleh developer pada tahap berikutnya melalui pengujian manual. Pendekatan ini sejalan dengan konsep Black Box, yaitu mengevaluasi hasil implementasi berdasarkan hasil yang ditampilkan oleh aplikasi, bukan hanya berdasarkan kode yang dihasilkan AI.

Verifikasi Manual dengan Pendekatan Black Box

Tahap kelima merupakan inti dari pendekatan Human in the Loop. Setelah AI menyelesaikan implementasi yang dijalankan, Anda perlu menjalankan aplikasi dan menguji hasilnya secara langsung.

Buka browser, jalankan skenario yang berkaitan dengan fitur yang baru diimplementasikan, lalu pastikan hasilnya benar-benar sesuai dengan kebutuhan. Fokuskan pengujian pada aspek yang paling penting, seperti:

• Apakah fitur berjalan sesuai dengan tujuan awal?
• Apakah ada error atau perilaku yang tidak diharapkan?
• Apakah perubahan tersebut memengaruhi fitur lain yang sebelumnya sudah berjalan dengan baik?

Inilah esensi dari Human in the Loop. AI bertugas mengimplementasikan solusi, tetapi keputusan apakah hasil tersebut sudah benar tetap berada di tangan developer.

Jika ditemukan masalah, jangan langsung memperbaikinya secara manual. Kumpulkan informasi yang relevan, seperti error log, screenshot, response API, atau langkah-langkah untuk mereproduksi masalah tersebut. Selanjutnya, berikan informasi tersebut kepada AI sebagai konteks baru agar AI dapat melakukan iterasi berikutnya.

Dalam praktiknya, hasil implementasi AI tidak selalu langsung berjalan dengan sempurna. Saat membuka browser dan menguji fitur yang baru dibuat, Anda mungkin masih menemukan runtime error, tampilan yang tidak sesuai, atau alur bisnis yang belum berjalan sebagaimana mestinya.

Hal tersebut merupakan bagian yang wajar dari proses Human in the Loop. Tugas developer pada tahap ini bukan langsung memperbaiki kode secara manual, melainkan memberikan umpan balik (feedback) yang jelas kepada AI agar AI dapat melakukan iterasi berikutnya.

Dari pengalaman kami, metode ini sering kali lebih cepat dibandingkan dengan langsung mengandalkan automated testing setelah AI selesai menulis kode. Error yang muncul saat pengujian manual biasanya memberikan konteks yang lebih spesifik mengenai masalah yang terjadi, sehingga AI dapat memperbaikinya dengan lebih tepat.

Sebagai contoh, misalkan Anda meminta AI membuat halaman Report. Setelah implementasi selesai, Anda membuka browser dan mencoba mengakses halaman tersebut. Ternyata aplikasi menampilkan pesan berikut:

error di halaman report:

Transform failed with 1 error:
app/composables/useAuth.ts:103:8: ERROR: Expected "finally" but found "else"

Hal yang sama juga berlaku pada framework lain. Misalnya, pada proyek Laravel, cukup salin (copy) stack trace yang muncul seperti di bawah ini, lalu berikan kepada AI sebagai konteks untuk melakukan perbaikan.

error saat buka /admin/report:

SQLSTATE[42S02]: Base table or view not found: 1146
Table 'app.spend_logs' doesn't exist

Setelah menerima umpan balik, AI akan menganalisis penyebab error, memperbaiki implementasi, lalu meminta Anda melakukan pengujian kembali. Siklus ini akan terus berulang hingga hasil implementasi sesuai dengan yang diharapkan.

Namun, ada satu hal yang menurut kami penting: jangan biarkan AI melakukan commit secara otomatis selama proses iterasi ini.

Pada tahap ini, perubahan yang dilakukan AI masih bersifat eksperimen untuk memperbaiki error atau menyempurnakan implementasi. Jika setiap perbaikan langsung dibuat menjadi commit, riwayat Git akan dipenuhi oleh commit-commit kecil yang sebenarnya tidak memiliki nilai dokumentasi, seperti “fix error”, “fix again”, atau “final fix”.

Akibatnya, riwayat perubahan menjadi sulit ditelusuri dan proses rollback ketika terjadi masalah juga menjadi lebih rumit.

Karena itu, di workflow kami, commit tetap menjadi tanggung jawab developer. Commit baru dilakukan setelah implementasi berhasil diverifikasi secara manual dan benar-benar siap untuk disimpan sebagai satu perubahan yang utuh.

Satu hal lagi yang sangat penting saat memberikan feedback ke AI, yakni jangan hanya copy-paste error log mentah. Gunakan prinsip Black Box dengan menyertakan input (kondisi saat ini) dan expected output (hasil yang seharusnya terjadi) agar AI memahami konteks permasalahannya. Contohnya seperti berikut:

Input (error sekarang):
- Buka halaman /admin/report
- Muncul error:
  Transform failed with 1 error:
  app/composables/useAuth.ts:103:8: ERROR: Expected "finally" but found "else"

Expected output:
- Halaman report tampil dengan tabel User Usage
- Bisa filter berdasarkan tanggal dan model

(lampirkan screenshot error)

Dengan format tersebut, AI memiliki konteks yang lebih lengkap: apa yang sedang terjadi (input) dan apa yang ingin dicapai (expected output). Tanpa expected output, AI mungkin saja berhasil menghilangkan error, tetapi menghasilkan implementasi yang berbeda dari kebutuhan Anda.

Jika memungkinkan, sertakan juga screenshot. Dalam banyak kasus, informasi visual dapat membantu AI memahami masalah lebih cepat daripada hanya membaca puluhan baris log.

Lanjutkan siklus ini hingga hasil implementasi benar-benar sesuai dengan ekspektasi. Setelah fitur berjalan dengan baik dan telah diverifikasi secara manual, barulah lakukan commit.

Pendekatan Black Box Loop memang bersifat iteratif, tetapi setiap loop harus memiliki exit. Jangan sampai AI terus mengulang proses yang sama tanpa menghasilkan kemajuan.

Aturan praktisnya, jika setelah dua atau tiga loop AI masih gagal memperbaiki error yang sama, sebaiknya hentikan iterasi tersebut. Hindari terus memberikan error yang sama, dengan harapan AI akan menemukan solusi pada percobaan berikutnya.

Dalam pengalaman kami, kondisi ini biasanya menunjukkan bahwa akar masalah bukan lagi pada proses debugging, melainkan pada ruang lingkup task yang terlalu besar atau plan yang kurang tepat. Akibatnya, AI cenderung berputar pada masalah yang sama tanpa menghasilkan solusi yang berarti. Kalau hal ini terjadi, kami biasanya melakukan reset pada branch ke kondisi yang bersih, memecah task menjadi beberapa bagian yang lebih kecil, lalu memulai loop baru dengan plan yang lebih spesifik dan terarah.

Langkah tersebut jauh lebih efektif daripada mempertahankan loop yang sama dan berharap AI akan memberikan solusi setelah berkali-kali mencoba.

Commit Setelah Verifikasi Selesai

Sebelum melakukan commit, pastikan implementasi sudah sesuai dengan spesifikasi aplikasi yang dibutuhkan. Developer dapat merujuk dokumen teknis yang telah disusun oleh System Analyst, seperti user stories, ERD, maupun dokumentasi pendukung lainnya. Langkah ini penting untuk memastikan setiap loop yang dijalankan AI tetap mengarah pada tujuan yang benar.

Jika fitur sudah berjalan tanpa runtime error dan alur bisnisnya telah terverifikasi, saatnya membuka black box.

Membuka black box bukan berarti melakukan review pada setiap baris kode. Fokuskan perhatian pada bagian-bagian yang memiliki risiko tinggi, misalnya:

• Migration database: pastikan perubahan skema sesuai dengan ERD karena kesalahan pada database akan lebih sulit diperbaiki setelah masuk ke production.
• Authentication dan security: periksa bagian yang berkaitan dengan RBAC, session, maupun validasi input, karena masalah di area ini sering kali tidak terlihat dari pengujian di browser.
• Code smell: pastikan struktur kode tetap modular dan mudah dipelihara. Jika AI menghasilkan implementasi yang terlalu besar atau berulang, minta AI melakukan refactoring, misalnya dengan membuat helper, base class, atau pola yang dapat digunakan kembali.

Setelah seluruh perubahan memenuhi standar teknis dan kebutuhan bisnis, lakukan commit, kemudian lanjutkan ke proses Pull Request (PR).

Human in the Loop dalam Black Box

Black Box Loop yang telah dibahas sebelumnya merupakan bagian dari tahap awal. Di Tonjoo, prinsip Human in the Loop tidak berhenti setelah kode berhasil dibuat, tetapi terus diterapkan hingga fitur benar-benar siap masuk ke production.

1. Analyst Menyiapkan Dokumen Teknis

Sebelum development dimulai, Analyst menyiapkan dokumen teknis seperti ERD, user stories, swimlane, dan dokumentasi pendukung lainnya. Dokumen ini menjadi source of truth yang digunakan developer untuk menyusun prompt dan memvalidasi hasil implementasi AI.

2. Pull Request Direview oleh Manusia

Setelah Pull Request (PR) dibuat, proses code review dilakukan oleh developer lain, bukan oleh AI. Fokus review bukan membaca setiap baris kode, melainkan memeriksa area yang berisiko tinggi seperti migration, security, dependency, dan kesesuaian dengan arsitektur aplikasi.

3. Manual Test oleh QA/Tester

Fitur yang telah di-merge kemudian diuji kembali secara manual oleh QA / Tester berdasarkan acceptance criteria. Tahap ini membantu menemukan kasus yang mungkin terlewat saat developer melakukan pengujian sendiri.

4. UAT Sebelum Production

Sebelum masuk ke production, fitur melewati User Acceptance Testing (UAT) bersama klien atau stakeholder. Tujuannya adalah memastikan hasil implementasi benar-benar memenuhi kebutuhan bisnis, bukan hanya lolos validasi teknis.

Dengan demikian, terdapat lima lapis validasi oleh manusia, yakni Analyst (dokumen teknis), Developer (Black Box Loop), Reviewer (Pull Request), QA/Tester (acceptance criteria), dan User Acceptance Testing (UAT). AI dapat membantu menghasilkan sebagian besar implementasi, tetapi setiap perubahan tetap melewati proses validasi manusia sebelum masuk ke production. Inilah yang kami maksud dengan Human in the Loop di Tonjoo: AI berperan sebagai pendamping developer, bukan penggantinya.

Bangun Aplikasi Berkualitas dan Siap untuk Production Bersama Tonjoo

Metode Human in the Loop bukan sekadar tentang membuat AI bekerja lebih cepat, melainkan menempatkan manusia pada titik-titik yang paling menentukan dalam proses development.

Di Tonjoo, keterlibatan manusia dimulai sejak penyusunan dokumen teknis, perencanaan implementasi, validasi hasil, code review, pengujian berdasarkan acceptance criteria, hingga User Acceptance Testing (UAT) sebelum fitur benar-benar masuk ke production. AI dapat membantu menulis ribuan baris kode di dalam black box, tetapi arah pengembangan, kualitas implementasi, dan keputusan akhir tetap berada di tangan manusia.

Menurut pengalaman kami, kombinasi inilah yang memberikan hasil terbaik. AI mempercepat pekerjaan yang bersifat operasional, sementara manusia tetap berperan dalam pengambilan keputusan, validasi, dan pengendalian kualitas.

Updated on July 24, 2026 by Anisa K.