Pertama kali agen pengkodean memperbaiki bug untuk Anda, reaksinya hampir selalu sama: campuran antara antusiasme dan kecurigaan. Bagus, tentu saja. Namun kemudian Anda melihat perbedaannya dan bertanya pada diri sendiri: "Oke, tapi sebenarnya apa yang dia sentuh? Bisakah saya memercayainya? Apakah dia akan melakukannya lagi dengan cara yang sama besok?".

Di situlah menurut saya bagian yang menarik dimulai. Bukan ketika agen menulis suatu fungsi, tetapi ketika ia sudah cukup mampu untuk melakukan seluruh pekerjaan: membaca repositori, membuat patch, menjalankan tes, membuka PR, kembali lagi setelah komentar ulasan. Codex bergerak tepat ke arah itu: pekerjaan latar belakang, pohon kerja terpisah, browser terintegrasi, otomatisasi, plugin, memori, dan kontrol izin yang lebih eksplisit.

Intinya adalah jangan membayangkan masa depan di mana tidak ada lagi yang membaca kode. Ini akan menjadi masa depan yang buruk, dan juga cukup naif. Intinya adalah mencari cara bekerja dengan agen yang dapat melakukan banyak hal tanpa membiarkan mereka melakukan segalanya.

Perubahan kebiasaan

Dengan pelengkapan otomatis tradisional, Anda selalu berada di belakang kemudi. AI menyarankan sebuah garis, Anda memutuskan. Namun, dengan seorang agen, hubungannya berubah: Anda memberinya tujuan dan dia melakukan beberapa langkah sendiri.

Hal ini memang ampuh, namun dapat mengalihkan permasalahan. Pertanyaannya bukan lagi sekedar “dapatkah model diprogram?”. Pertanyaannya menjadi:

• Apakah saya memberinya ruang lingkup yang cukup kecil?
• apakah kamu tahu cara memeriksa hasilnya?
• Apakah saya bekerja di lingkungan yang terisolasi?
• Apakah peninjauan akhir masih manusiawi dan hati-hati?

Alur kerja yang sehat lebih terlihat seperti ini daripada tongkat ajaib:

Kedengarannya kurang romantis dibandingkan "agen yang membangun segalanya", tetapi cara kerjanya jauh lebih baik. Begitu pula dengan cara kerja tim yang baik dalam menangani manusia: tugas yang jelas, umpan balik yang cepat, akuntabilitas yang jelas.

Perintah yang bagus hampir merupakan tiket yang bagus

Perintah yang paling berbahaya adalah perintah yang tidak jelas namun pasti: "perbaiki halaman faktur", "perbaiki arsitektur", "bersihkan modul autentikasi". Ini adalah permintaan yang terdengar produktif dan menghasilkan perbedaan besar. Tapi kemudian Anda mendapati diri Anda melakukan arkeologi.

Perintah yang bermanfaat lebih membosankan. Misalnya: menerapkan ekspor CSV untuk halaman faktur, mengetahui bahwa tabelnya ada di app/(dashboard)/invoices/page.tsx, kuerinya ada di src/server/invoices.ts dan sudah ada pola serupa di app/(dashboard)/reports.

Kemudian tambahkan batasan yang jelas: jangan mengubah skema database, jangan menambahkan dependensi jika utilitas kecil sudah cukup, pertahankan gaya UI yang ada. Dan ditutup dengan verifikasi: npm test -- invoices dan npm run build.

Jenis pengarahan ini bukan untuk "menjelaskan dengan lebih baik kepada AI". Hal ini terutama berfungsi untuk memperjelas bagi Anda apa yang Anda delegasikan. Jika Anda tidak bisa menuliskannya secara konkrit, mungkin tugas agen belum siap.

Tiga pekerjaan yang ingin saya delegasikan

Yang pertama adalah pekerjaan yang berulang namun dapat diverifikasi: menambahkan pengujian, memigrasikan panggilan ke API internal baru, memperbarui impor, mengganti komponen yang tidak digunakan lagi, memperbaiki kesalahan TypeScript. Di sini agen dapat menghemat waktu dan risiko dapat dikendalikan.

Yang kedua adalah pekerjaan eksplorasi: "temukan di mana total ini dihitung", "jelaskan kepada saya mengapa tes ini rapuh", "reproduksi bug dan beri tahu saya file mana yang tampaknya terpengaruh". Meskipun tidak langsung menghasilkan tambalan, ia dapat melakukan pengintaian yang berguna.

Yang ketiga adalah pekerjaan pemeliharaan berulang: pembaruan ketergantungan kecil, pembersihan tanda fitur lama, ringkasan PR yang diblokir, pemeriksaan TODO yang terlupakan. Memang tidak glamor, tapi justru jenis pekerjaan yang cenderung menumpuk.

Tiga pekerjaan yang saya pertahankan sebagai manusia

Keputusan produk tetap bersifat manusiawi. Jika perubahan mengubah cara pengguna membayar, menghapus data, melihat harga, atau memahami izin, saya menginginkan orang yang bertanggung jawab.

Batasan keamanan juga patut mendapat perhatian manusia: autentikasi, peran, token, pencatatan data sensitif, migrasi basis data. Seorang agen dapat membantu penerapannya, namun tidak harus menjadi satu-satunya pengambil keputusan.

Akhirnya, saya menyimpan segala sesuatu yang membutuhkan selera arsitektur manusia. Seorang agen dapat mengusulkan refactor, tetapi memahami apakah abstraksi benar-benar diperlukan atau apakah kita hanya menyelesaikan masalah yang tidak ada masih merupakan pekerjaan.

Peninjauan ini bukan suatu pilihan

Godaannya, ketika seorang agen bagus, adalah memercayai warna hijau dari CI. Itu bisa dimengerti. Itu juga saat masalah dimulai.

Saya selalu melihat setidaknya lima hal:

1. Apakah patch hanya menyelesaikan tugas yang diminta?
2. Apakah dia menyentuh file yang tidak ada hubungannya dengan itu?
3. Apakah tes tersebut mencakup perilaku baru atau hanya kebetulan saja?
4. Apakah kode tersebut mengikuti pola lokal?
5. Apakah kesalahan ditangani seperti pada proyek lainnya?

Ketika ada sesuatu yang salah, umpan balik harus spesifik. "Perbaiki" itu malas. Lebih baik: utilitas ini menduplikasi parseMoney menjadi src/lib/money.ts; gunakan kembali fungsi itu, tambahkan pengujian untuk kasus EUR dan jangan ubah API publik modul penagihan.

Agen merespons komentar kecil dan dapat diverifikasi dengan lebih baik. Anehnya, begitu pula masyarakatnya.

Pagar pembatas sepadan dengan usahanya

Jika agen dapat membaca file, menulis kode, dan menjalankan perintah, ini harus diperlakukan sebagai proses yang kuat. Tidak perlu paranoia, Anda perlu kebersihan.

Gunakan pohon kerja atau cabang terpisah. Jadi Anda dapat membandingkan perbedaannya, membuang eksperimen yang gagal, dan tidak mencampurkan pekerjaan agen dengan apa yang Anda lakukan.

Batasi izin. Perintah seperti rg, git diff, npm test dan npm run build bisa jadi gratis. Penerapan, migrasi basis data, akses terhadap rahasia, dan perintah destruktif harus tetap eksplisit.

Kurangi akses jaringan saat Anda tidak membutuhkannya. Untuk banyak tugas, dokumentasi resmi, registrasi paket, dan layanan internal tertentu sudah cukup. Lebih sedikit luas permukaan, lebih sedikit kejutan.

Lacak tindakan. Saat patch tiba dalam peninjauan, Anda seharusnya dapat merekonstruksi prompt, perintah yang dijalankan, pengujian yang berhasil, dan file yang dimodifikasi. Bukan untuk menciptakan birokrasi, tapi untuk bisa memahami apa yang terjadi jika terjadi kesalahan.

Cara mudah untuk memulai sebagai sebuah tim

Jika saya memperkenalkan agen ke dalam tim kecil, saya akan memulainya tanpa revolusi besar.

Saya akan membuat label agent-ready untuk masalah dengan cakupan yang jelas. Saya akan menambahkan templat dengan konteks, batasan, dan perintah verifikasi. Saya akan meminta PR kecil, idealnya di bawah beberapa ratus baris. Saya memerlukan pengujian atau tangkapan layar untuk melihat perubahan. Dan yang terpenting, saya akan meminta orang yang bertanggung jawab atas penggabungan tersebut.

Setelah dua minggu, saya akan melihat datanya: tugas mana yang benar-benar dipercepat, tinjauan mana yang berat, perintah mana yang membingungkan, bagian mana dari basis kode yang terlalu rapuh untuk didelegasikan.

Ini adalah pendekatan yang kurang spektakuler dibandingkan "mulai hari ini kami akan melakukan segalanya dengan agen", tetapi pendekatan inilah yang memungkinkan Anda memasuki minggu ketiga tanpa penyesalan.

Bagian yang paling manusiawi

Lucunya, semakin otonom agen, semakin penting lagi keterampilan klasiknya: menulis tiket yang bagus, membuat potongan kecil, membuat tes, membaca perbedaan, mengomunikasikan trade-off. Agen mempercepat mereka yang sudah tahu cara bekerja dengan baik. Hal ini juga memperbesar kekacauan bagi mereka yang melakukan delegasi dengan buruk.

Jadi tidak, saya tidak melihat alur kerja multi-agen sebagai jalan pintas untuk berhenti melakukan rekayasa. Saya melihatnya sebagai cara untuk mengalihkan lebih banyak energi ke bagian-bagian yang penting: memutuskan apa yang akan dibangun, memastikan sistem berfungsi, menjaga sistem tetap dapat dimengerti.

Agen dapat menjadi kolega asinkron yang hebat. Namun rekan kerja yang tidak sinkron, agar berguna, memerlukan konteks, batasan, dan tinjauan. Sama seperti orang lain.

Sumber yang bermanfaat

• Codex untuk (hampir) semuanya - OpenAI
• Menjalankan Codex dengan aman di OpenAI
• Memperkenalkan Codex - OpenAI
• Apa yang baru dengan agen pengkodean GitHub Copilot