Pertanyaan wawancara harness engineering: 22 pertanyaan dengan jawaban untuk AI engineer

Cara bersiap

Pertanyaan wawancara harness engineering biasanya bergerak dari yang umum ke yang spesifik: apa itu harness, apa saja isinya, bagaimana Anda mendiagnosis masalah, bagaimana Anda mengukur dampaknya. Pewawancara mencari cara berpikir rekayasa: kemampuan membedakan masalah model dari masalah lingkungan, dan kemampuan mengusulkan solusi yang bisa diverifikasi. Berikut 22 pertanyaan dengan jawabannya, dikelompokkan per topik.

Dasar-dasar

1. Apa itu harness agen?

Harness adalah seluruh lingkungan tempat agen AI bekerja, di luar model itu sendiri: instruksi, alat, lingkungan eksekusi, penyimpanan status, dan lingkaran umpan balik. Model mengambil keputusan, sedangkan harness menentukan apa yang diketahui model, apa yang bisa dilakukannya, dan bagaimana ia tahu hasil tindakannya. Model yang sama di harness berbeda menunjukkan kualitas yang sangat berbeda.

2. Apa bedanya harness engineering dengan prompt dan context engineering?

Prompt engineering bekerja pada rumusan satu permintaan, context engineering bekerja pada apa yang masuk ke jendela model di setiap langkah. Harness engineering mencakup keduanya dan menambahkan hal yang tidak bisa diselesaikan dengan teks: akses ke alat, lingkungan yang dapat direproduksi, status antarsesi, dan pemeriksaan mesin atas hasil.

3. Sebutkan lima subsistem harness.

Instruksi (AGENTS.md, CLAUDE.md, skills, dokumen), alat (shell, tes, linter, browser, MCP), lingkungan (dependensi, runtime, Docker, worktree), status (PROGRESS.md, daftar fitur, keputusan), dan umpan balik (make check, E2E, hook, penilai). Ketiadaan satu subsistem tidak membuat hasil «sedikit lebih buruk», tetapi menghasilkan kelas kegagalan yang sistematis.

4. Mengapa mengganti model dengan yang lebih kuat sering tidak membantu?

Karena banyak kegagalan tidak berasal dari kecerdasan model. Model yang kuat tidak akan mendapatkan akses ke perintah yang tidak tersedia, tidak akan mengingat sesi kemarin tanpa file status, dan tidak akan tahu migrasi rusak jika tidak ada yang menjalankannya. Konvensi khusus sebuah tim juga tidak bisa ditebak oleh model.

Diagnostik

5. Agen melanggar aturan yang tertulis di CLAUDE.md. Apa yang Anda lakukan?

Pertama periksa apakah agen bisa menemukan aturan itu: file panjang dengan puluhan butir mengaburkan yang penting. Pangkas file masukan menjadi daftar isi, dan pindahkan rincian ke dokumen yang dimuat berdasarkan kondisi. Jika aturannya kritis, ubah menjadi pemeriksaan yang bisa dijalankan — linter, tes, guard grep, atau hook — sehingga pelanggarannya terlihat secara mesin dan tidak bergantung pada perhatian model.

6. Bagaimana mengenali subsistem mana yang rusak dari gejalanya?

Konvensi yang sudah diketahui dilanggar — instruksi. Agen «ingin tetapi tidak bisa» — alat. Setiap sesi dimulai dengan memperbaiki lingkungan — lingkungan. Sesi baru tidak tahu di mana pekerjaan berhenti — status. «Selesai» tidak sesuai kenyataan — umpan balik.

7. Dengan subsistem apa harness sebaiknya dimulai, dan mengapa?

Dengan umpan balik. Selama belum ada perintah yang secara mesin menjawab «berfungsi atau tidak», dampak perubahan lain tidak bisa diukur. Berikutnya biasanya instruksi, status, lingkungan, dan alat, tetapi urutannya bersifat empiris dan bergantung pada apa yang paling rusak.

8. Bagaimana mengukur kontribusi satu komponen harness?

Dengan ablasi: model dan kumpulan tugas dipertahankan, lalu satu subsistem dimatikan bergantian dan penurunannya diamati. Namun lebih baik mulai dari log kegagalan dengan penandaan per lapisan, karena itu lebih cepat menunjukkan hambatan. Penurunan nol tidak berarti komponen itu tidak berguna: mungkin tugas-tugas ini tidak menggunakannya, atau ia bersifat redundan.

Instruksi dan konteks

9. Bagaimana menyusun AGENTS.md yang baik?

Sebagai router, bukan buku pelajaran: apa proyeknya, cara menjalankannya, cara memeriksanya, Definition of Done, dan daftar pendek batasan wajib. Rincian ditempatkan di dokumen terpisah dengan tautan berbentuk «baca ketika tugas menyentuh pembayaran». File menetapkan invarian («data divalidasi di batas»), bukan mendikte implementasi atau pustaka baris demi baris.

10. Untuk apa subagen?

Untuk isolasi konteks. Subtugas sampingan — pencarian di basis kode, review, pemeriksaan — dijalankan di konteks tersendiri dan hanya mengembalikan keluarannya. Alur utama tidak tercemar, dan subagen penilai tidak mewarisi penalaran pelaksana, yang penting untuk penilaian yang jujur.

11. Apa itu utang harness?

Selisih yang menumpuk antara harness dan kenyataan: aturan usang, perintah yang sudah tidak berfungsi, dokumen tentang modul yang sudah tidak ada. Ia berperilaku seperti utang teknis — menumpuk tanpa terlihat dan dibayar dengan kegagalan agen. Harness perlu ditinjau secara berkala, bukan hanya dikonfigurasi sekali.

Status dan sesi

12. Bagaimana mengatasi amnesia agen antarsesi?

Simpan status di repositori: PROGRESS.md (kondisi, yang sudah selesai, hambatan, langkah berikutnya), DECISIONS.md (keputusan, alasan, opsi yang ditolak), daftar fitur dengan status, dan commit yang sering. Di instruksi tetapkan urutan awal: baca progres, jalankan skrip pemeriksaan lingkungan, ambil fitur yang aktif.

13. Untuk apa aturan WIP=1?

Ketika agen memulai beberapa fitur sekaligus, status menjadi kabur: tidak ada yang selesai, perubahan saling bercampur, dan rollback sulit. Satu fitur aktif memberi titik pemeriksaan yang jelas, commit yang bersih, dan pemulihan yang sederhana setelah kegagalan.

14. Apa itu tes cold start?

Pemeriksaan apakah sesi baru, tanpa petunjuk dari manusia, bisa menjawab pertanyaan dasar: ini proyek apa, sudah sampai mana, fitur mana yang aktif, bagaimana memastikan semuanya baik-baik saja. Jika agen menjawab dari file tanpa menebak, subsistem status berfungsi.

Verifikasi

15. Mengapa tes unit yang hijau tidak membuktikan bahwa fitur berfungsi?

Tes unit mengisolasi modul dan me-mock dependensi, sehingga tidak melihat sambungan: ketidakcocokan antarmuka, perambatan status (skema berubah, cache masih lama), kebocoran sumber daya, serta masalah konfigurasi dan lingkungan. Cacat yang ditangkap tes unit adalah himpunan bagian dari cacat yang ditangkap tes integrasi, dan yang terakhir adalah himpunan bagian dari yang bisa ditangkap E2E.

16. Apa itu verification gap dan bagaimana menghitungnya?

Proporsi tugas yang dinyatakan selesai oleh agen tetapi tidak dikonfirmasi pemeriksaan independen. Ambil 10 tugas berturut-turut dan catat kedua fakta untuk masing-masing. Metrik ini memberi garis dasar: setelah perubahan harness, hitung ulang pada kumpulan tugas yang serupa.

17. Bagaimana menulis Definition of Done untuk agen?

Di AGENTS.md, sebagai daftar poin yang bisa diverifikasi: perintah pemeriksaan selesai dengan kode 0, ada E2E untuk skenario, migrasi diterapkan, progres diperbarui. Berguna juga untuk secara eksplisit menyebutkan apa yang tidak dianggap selesai: «terlihat benar», «tes unit lulus», «di komputer saya berjalan».

18. Mengapa agen tidak boleh menetapkan status «selesai» sendiri?

Model cenderung melebih-lebihkan penilaian atas pekerjaannya sendiri, dan penilaian diri terjadi dalam konteks yang sama tempat keputusan dibuat. Status passing harus ditetapkan oleh skrip verifikasi berdasarkan hasil menjalankan pemeriksaan, dengan mencatat hash commit sebagai bukti.

19. Bagaimana membangun penilai independen?

Agen atau sesi terpisah yang hanya melihat persyaratan, diff, dan hasil pemeriksaan, tetapi tidak melihat penalaran pelaksana. Ia menilai berdasarkan rubrik (kebenaran, arsitektur, tes, penanganan kesalahan), dan setiap penilaian merujuk ke file, baris, atau log. Idealnya gunakan model yang berbeda, agar titik buta keduanya tidak sama.

20. Bagaimana membuat aturan arsitektur menjadi pemeriksaan yang bisa dijalankan?

Ada tiga tingkat: guard grep (cepat, berdasarkan pola), aturan linter yang memahami graf impor (import-linter, dependency-cruiser), dan tes arsitektur di CI. Semuanya dimasukkan ke make check, gagal dengan kode bukan nol, dan mencetak WHY serta FIX agar agen bisa memperbaiki pelanggaran sendiri. Pemicu untuk pemeriksaan baru adalah komentar yang sama pada review untuk kedua kalinya.

Kerja otonom

21. Apa yang dibutuhkan agar agen bisa bekerja berjam-jam?

Tujuan yang tidak ambigu, metrik kemajuan yang monoton (misalnya jumlah fitur berstatus passing), anggaran waktu dan percobaan per fitur, rollback otomatis saat terjadi regresi, dan daftar tindakan yang membutuhkan manusia: migrasi, infrastruktur, uang. Ditambah isolasi: sandbox atau git worktree terpisah, agar kesalahan tidak menyentuh lingkungan kerja.

22. Kapan satu siklus agen tidak cukup, dan bagaimana menyusun graf peran?

Ketika pelaksana mulai memeriksa dirinya sendiri dan macet. Maka tugas dipecah menjadi peran: implementasi, review, tes, dan merge. Review mendapat konteks bersih dan rubrik, merge dilakukan kode ketika review == pass. Jika review gagal, fitur kembali ke implementasi, dan setelah beberapa kegagalan dimulai ulang dengan konteks bersih — artinya masalahnya ada pada pemahaman tugas, bukan pada kodenya.

Kesimpulan

Dalam wawancara harness engineering, jawaban terkuat adalah yang berbicara tentang hal yang bisa diverifikasi: file apa, perintah apa, metrik apa. Pegang di kepala lima subsistem, verification gap, dan aturan «status ditetapkan oleh skrip». Semua topik ini menyatu menjadi satu harness utuh pada proyek contoh di kursus harness engineering.