Alur kerja Codex dan multi-agen: bekerja dengan agen tanpa kehilangan kendali

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Pertama 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?".
3~
4Di 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.
5~
6Intinya 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.
7~
8## Perubahan kebiasaan
9~
10Dengan 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.
11~
12Hal ini memang ampuh, namun dapat mengalihkan permasalahan. Pertanyaannya bukan lagi sekedar “dapatkah model diprogram?”. Pertanyaannya menjadi:
13~
14- Apakah saya memberinya ruang lingkup yang cukup kecil?
15- apakah kamu tahu cara memeriksa hasilnya?
16- Apakah saya bekerja di lingkungan yang terisolasi?
17- Apakah peninjauan akhir masih manusiawi dan hati-hati?
18~
19Alur kerja yang sehat lebih terlihat seperti ini daripada tongkat ajaib:
20~
21```mermaid
22flowchart LR
23    Idea[Tugas manusia] --> Scope[Tujuan kecil dan dapat diverifikasi]
24    Scope --> Agent[Agen di pohon kerja terisolasi]
25    Agent --> Checks[Uji, lint, buat, browser]
26    Checks --> Review[Tinjauan manusia]
27    Review --> Merge[Penggabungan atau iterasi baru]
28    Review --> Iterate[Komentar yang tepat tentang perbedaan tersebut]
29    Iterate --> Agent
30```
31~
32Kedengarannya 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.
33~
34## Perintah yang bagus hampir merupakan tiket yang bagus
35~
36Perintah 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.
37~
38Perintah 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`.
39~
40Kemudian 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`.
41~
42Jenis 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.
43~
44## Tiga pekerjaan yang ingin saya delegasikan
45~
46Yang 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.
47~
48Yang 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.
49~
50Yang 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.
51~
52## Tiga pekerjaan yang saya pertahankan sebagai manusia
53~
54Keputusan produk tetap bersifat manusiawi. Jika perubahan mengubah cara pengguna membayar, menghapus data, melihat harga, atau memahami izin, saya menginginkan orang yang bertanggung jawab.
55~
56Batasan 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.
57~
58Akhirnya, 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.
59~
60## Peninjauan ini bukan suatu pilihan
61~
62Godaannya, ketika seorang agen bagus, adalah memercayai warna hijau dari CI. Itu bisa dimengerti. Itu juga saat masalah dimulai.
63~
64Saya selalu melihat setidaknya lima hal:
65~
661. Apakah patch hanya menyelesaikan tugas yang diminta?
672. Apakah dia menyentuh file yang tidak ada hubungannya dengan itu?
683. Apakah tes tersebut mencakup perilaku baru atau hanya kebetulan saja?
694. Apakah kode tersebut mengikuti pola lokal?
705. Apakah kesalahan ditangani seperti pada proyek lainnya?
71~
72Ketika 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.
73~
74Agen merespons komentar kecil dan dapat diverifikasi dengan lebih baik. Anehnya, begitu pula masyarakatnya.
75~
76## Pagar pembatas sepadan dengan usahanya
77~
78Jika agen dapat membaca file, menulis kode, dan menjalankan perintah, ini harus diperlakukan sebagai proses yang kuat. Tidak perlu paranoia, Anda perlu kebersihan.
79~
80Gunakan pohon kerja atau cabang terpisah. Jadi Anda dapat membandingkan perbedaannya, membuang eksperimen yang gagal, dan tidak mencampurkan pekerjaan agen dengan apa yang Anda lakukan.
81~
82Batasi 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.
83~
84Kurangi 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.
85~
86Lacak 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.
87~
88## Cara mudah untuk memulai sebagai sebuah tim
89~
90Jika saya memperkenalkan agen ke dalam tim kecil, saya akan memulainya tanpa revolusi besar.
91~
92Saya 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.
93~
94Setelah 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.
95~
96Ini 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.
97~
98## Bagian yang paling manusiawi
99~
100Lucunya, 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.
101~
102Jadi 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.
103~
104Agen dapat menjadi kolega asinkron yang hebat. Namun rekan kerja yang tidak sinkron, agar berguna, memerlukan konteks, batasan, dan tinjauan. Sama seperti orang lain.
105~
106## Sumber yang bermanfaat
107~
108- [Codex untuk (hampir) semuanya - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Menjalankan Codex dengan aman di OpenAI](https://openai.com/index/running-codex-safely/)
110- [Memperkenalkan Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Apa yang baru dengan agen pengkodean GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Pertama 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?".

4Di 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.

6Intinya 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.

8## Perubahan kebiasaan

10Dengan 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.

11~

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

13~

14- Apakah saya memberinya ruang lingkup yang cukup kecil?

15- apakah kamu tahu cara memeriksa hasilnya?

16- Apakah saya bekerja di lingkungan yang terisolasi?

17- Apakah peninjauan akhir masih manusiawi dan hati-hati?

18~

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

20~

21```mermaid

22flowchart LR

23 Idea[Tugas manusia] --> Scope[Tujuan kecil dan dapat diverifikasi]

24 Scope --> Agent[Agen di pohon kerja terisolasi]

25 Agent --> Checks[Uji, lint, buat, browser]

26 Checks --> Review[Tinjauan manusia]

27 Review --> Merge[Penggabungan atau iterasi baru]

28 Review --> Iterate[Komentar yang tepat tentang perbedaan tersebut]

29 Iterate --> Agent

30```

31~

32Kedengarannya 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.

33~

34## Perintah yang bagus hampir merupakan tiket yang bagus

35~

36Perintah 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.

37~

38Perintah 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`.

39~

40Kemudian 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`.

41~

42Jenis 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.

43~

44## Tiga pekerjaan yang ingin saya delegasikan

45~

46Yang 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.

47~

48Yang 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.

49~

50Yang 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.

51~

52## Tiga pekerjaan yang saya pertahankan sebagai manusia

53~

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

55~

56Batasan 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.

57~

58Akhirnya, 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.

59~

60## Peninjauan ini bukan suatu pilihan

61~

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

63~

64Saya selalu melihat setidaknya lima hal:

65~

661. Apakah patch hanya menyelesaikan tugas yang diminta?

672. Apakah dia menyentuh file yang tidak ada hubungannya dengan itu?

683. Apakah tes tersebut mencakup perilaku baru atau hanya kebetulan saja?

694. Apakah kode tersebut mengikuti pola lokal?

705. Apakah kesalahan ditangani seperti pada proyek lainnya?

71~

72Ketika 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.

73~

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

75~

76## Pagar pembatas sepadan dengan usahanya

77~

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

79~

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

81~

82Batasi 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.

83~

84Kurangi 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.

85~

86Lacak 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.

87~

88## Cara mudah untuk memulai sebagai sebuah tim

89~

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

91~

92Saya 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.

93~

94Setelah 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.

95~

96Ini 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.

97~

98## Bagian yang paling manusiawi

99~

100Lucunya, 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.

101~

102Jadi 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.

103~

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

105~

106## Sumber yang bermanfaat

107~

108- [Codex untuk (hampir) semuanya - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Menjalankan Codex dengan aman di OpenAI](https://openai.com/index/running-codex-safely/)

110- [Memperkenalkan Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Apa yang baru dengan agen pengkodean GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~