Cara menggunakan Codex dan batasannya dalam proyek nyata

Situasi yang umum adalah menanyakan “bagaimana cara menggunakan Codex”. Secara default, ia menanyakan tentang tombol pintas, templat kata cepat, dan cara membuatnya menulis lebih banyak kode.

Saya kemudian menemukan bahwa pertanyaan ini ditanyakan ke arah yang salah.

Nilai terbesar Codex adalah memungkinkan tim untuk memulai perubahan lebih sering dan lebih murah. Risiko sebenarnya juga ada di sini: setelah meningkatkan frekuensi perubahan, mekanisme check-in awal tim mungkin tidak cukup.

Jadi saya tidak akan membahas tentang “Sepuluh Teknik Kata Prompt” di artikel ini. Saya hanya akan berbicara tentang satu jalur utama: Hubungkan Codex ke dalam jalur perubahan yang dapat diterima, dibatalkan, dan dilacak.

1. Pertama pilih “unit kerja yang cocok untuk Codex”

Penggunaan yang paling mudah dibatalkan adalah dengan memberikan persyaratan yang tidak jelas langsung ke Codex:

• “Perbaiki modul ini”
• “Optimalkan kinerja”
• “Jadikan tempat ini lebih elegan”

Ini tentu saja memberikan banyak perubahan, dan semuanya terlihat baik-baik saja. Masalahnya adalah tidak ada cara untuk menerima atau meninjaunya.

Saya telah memadatkan tugas-tugas yang sesuai untuk Codex menjadi tiga kategori, masing-masing dengan “kondisi penyelesaian” yang jelas.

A. Perubahan perilaku yang dapat dituliskan sebagai pernyataan

Ciri-cirinya adalah: apakah input dan outputnya dapat dijelaskan dalam satu kalimat.

• Tambahkan pemrosesan batas ke suatu fungsi
• Memperbaiki bug yang pasti
• Migrasikan sepotong logika ke antarmuka baru tetapi pertahankan semantiknya tidak berubah

Cara terbaik untuk melakukan penerimaan adalah dengan menulis tes secara langsung, atau setidaknya menulis skrip pernyataan yang dapat dijalankan.

B. Perubahan Mekanis yang Banyak Sekali

Ciri-cirinya adalah: aturan yang jelas dan cakupan yang terkendali.

• Penggantian nama batch
• Tingkatkan panggilan API
• Penanganan nullability / error yang lengkap

Codex sangat berguna untuk pekerjaan semacam ini, tetapi harus diperbolehkan untuk menampilkan “daftar modifikasi” dan “cakupan perubahan yang dapat dicari”, jika tidak maka akan cenderung meleset.

C. Optimasi lokal dengan indikator keras

Ciri-cirinya adalah: kemampuan menentukan metode pengukuran.

• Kurangi IO satu kali selama fase startup
• Kurangi serialisasi satu kali untuk link tertentu
• Mengurangi penataan ulang halaman tertentu yang tidak perlu

Jangan optimalkan tanpa metrik. Codex akan salah mengira “kelihatannya lebih cepat” sebagai “sangat cepat”.

2. Tulis persyaratan sebagai “kriteria penerimaan” dan kemudian tulis kata-kata petunjuknya

Situasi yang umum adalah menulis kata-kata cepat seperti menulis keinginan:

• “Tolong tulislah dengan elegan”
• “Silakan ikuti praktik terbaik”

Hal ini tidak dapat diterima.

Saya mengharuskan setiap kali sebelum mengizinkan Codex mengambil tindakan, saya terlebih dahulu menulis kriteria penerimaan dan menuliskannya dalam deskripsi tugas yang sama:

• Perilaku apa yang akan diubah oleh perubahan ini?
• Perilaku apa yang tidak boleh diubah?
• Bagaimana berperilaku ketika Anda gagal
• Cara memutar kembali

Anda akan menemukan bahwa setelah kriteria penerimaan ditulis dengan jelas, kata-kata cepatnya menjadi lebih pendek.

Struktur yang sering saya gunakan adalah:

1. Latar Belakang (dua atau tiga kalimat, jangan bicara tentang sejarah)
2. Tujuan (hanya menulis perilaku, bukan implementasi)
3. Kendala (apa yang tidak dapat dipindahkan)
4. Penerimaan (titik tes atau skrip)
5. Format keluaran (berikan rencana terlebih dahulu, lalu tempelkan)

3. Minta Codex untuk memberikan “rencana perubahan” terlebih dahulu, daripada memberikan kode akhir secara langsung.

Hal yang paling mahal dalam proyek nyata adalah “menemukan bahwa semantik telah berubah setelah penggabungan”.

Jadi saya membuat keluaran default Codex menjadi proses dua langkah:

• Langkah 1: Buat daftar file mana yang akan diubah, mengapa diubah, dan risiko setiap perubahan
• Langkah 2: Terapkan patch lagi

Jika ia mengeluarkan seluruh bagian kode segera setelah muncul, saya akan memanggilnya kembali dan membiarkannya membuat rencananya.

Alasannya sederhana:

• Tahap perencanaan dapat mengungkapkan apakah memahami batasan
• Apakah perubahan yang berlebihan dapat dihentikan pada waktunya selama tahap perencanaan

4. Biarkan Codex menampilkan “tambalan yang dapat ditinjau” dan bukan hanya sekumpulan teks

Menyalin dan menempelkan ratusan baris kode ke IDE mengubah peninjauan menjadi pekerjaan manual.

Pendekatan yang benar adalah: biarkan keluaran Codex dalam bentuk diff/patch, atau biarkan hanya membuat perubahan terkecil yang dapat digabungkan.

Saya akan mematuhi dua batasan dalam tim:

• Satu PR tidak mencakup dua maksud yang tidak berhubungan
• Perbedaan inti dari satu PR adalah dalam 200 baris (jika tidak maka harus dipecah)

Sangat mudah untuk menulis lebih banyak kodeks, dan harus “ditutup dalam kotak kecil” dengan batasan PR.

5. Biarkan tes menjadi “keluaran pertama”, bukan “tambahan terakhir”

Kesalahan paling umum dari Codex adalah penerapannya telah ditulis secara lengkap dan pengujiannya tampak ada, namun pengujian tersebut hanya memvalidasi implementasi yang ditulisnya.

Jadi saya memintanya untuk menampilkannya secara berurutan:

1. Daftar kasus uji (yang batasannya tercakup)
2. Kode uji kunci
3. Menerapkan tambalan

Jika tidak dapat memberikan nilai uji, berarti persyaratannya tidak tertulis dengan jelas, atau perubahan ini tidak sesuai untuk dilakukan.

6. Tulis “jalur rollback” ke dalam perubahan

Orang yang melakukan perubahan secara manual sering kali secara tidak sadar meninggalkan jalur mundur.

Sangat mudah bagi orang yang melakukan perubahan untuk melupakannya.

Saya mengharuskan setiap perubahan build untuk memenuhi setidaknya satu kebijakan rollback:

-fitur bendera

• Sakelar konfigurasi
• Pertahankan jalur lama untuk sementara waktu (double run)

Perubahan besar tanpa jalur pengembalian, tidak peduli siapa yang menulisnya, tidak boleh ditayangkan. Codex memudahkan untuk membuat “perubahan besar”.

7. Perlakukan ketertelusuran sebagai “item biaya” dalam penggunaan Codex

Jika Anda hanya menghitung “berapa banyak waktu pengembangan yang dihemat”, Anda akan sering terdorong untuk menulis lebih banyak lagi Codex.

Yang lebih saya pedulikan adalah: apakah masalahnya dapat terulang kembali.

Jadi dalam prosesnya saya akan dengan paksa mencatat tiga hal:

• Deskripsi tugas Codex kali ini (termasuk kriteria penerimaan)
• Ubah rencana yang diberikan oleh Codex
• Patch akhir dan hasil tes

Ketiga item ini adalah rangkaian bukti selama peninjauan kecelakaan.

Tanpa logging, semakin sering Anda menggunakan Codex, Anda akan merasa seperti menjalankan sistem yang tidak dapat direproduksi.

8. Kumpulan kerangka kata prompt yang dapat digunakan secara langsung

Paragraf berikut adalah perubahan minimum agar keluarannya online.

Anda dapat menyalinnya langsung dan mengganti tanda kurung siku:

Perubahan perlu dilakukan dalam proyek nyata.

Latar Belakang: [Dua atau tiga kalimat yang menggambarkan situasi dan permasalahan saat ini] Sasaran (tingkat perilaku):

• Harus dilakukan: [Daftar 2-4 item]
• Tidak pernah berubah: [Daftar 2-4] Kendala:
• Tidak boleh memperkenalkan dependensi baru/tidak boleh mengubah API publik/harus kompatibel dengan data lama (pilih sesuai kebutuhan) Penerimaan:
• memberikan daftar poin tes
• Berikan setidaknya [N] kode kasus uji kunci Format keluaran:

1. Berikan rencana perubahan terlebih dahulu (daftar dokumen + poin risiko)
2. Berikan patch terkecil (diff), jangan sertakan teks penjelasan yang panjang

Batasan yang berlaku

Skenario di mana Codex tidak cocok juga sudah jelas:

• Aku bahkan tidak tahu perilaku apa yang kuinginkan, jadi aku hanya bisa “mencobanya dulu”
• Ini adalah perubahan berisiko tinggi yang melibatkan migrasi data, izin, dan pendanaan, namun belum ada lingkungan penerimaan yang lengkap
• Ketergantungan pada pengetahuan diam-diam (peralihan online, strategi skala abu-abu, kejadian bersejarah) tanpa dokumentasi

Dalam skenario ini, Codex akan memperkuat ketidakpastian secara langsung ke dalam kode.

Ringkasan

Jawaban untuk “cara menggunakan Codex” adalah serangkaian kendala teknis.

Menganggapnya sebagai penulisan yang lebih cepat menempatkan tanggung jawab pada peninjauan dan online.

Perlakukan ini sebagai bagian dari jalur pipa, gunakan kriteria penerimaan, pengujian, rollback, dan kemampuan penelusuran untuk menahan perubahan, dan ini akan menjadi alat efisiensi yang nyata.