Alur kerja Codex
Token Codex Terlalu Boros? Cara Saya Menguji Alur “Verifikasi di Akhir”
Saya melihat bahwa menyelesaikan satu kelompok perubahan yang saling terkait sebelum menjalankan seluruh pengujian dapat mengurangi keluaran berulang. Ini hipotesis alur kerja, bukan trik universal.
- Diamati
- Pada perubahan yang jelas dan saling terkait, satu pengujian penuh di akhir tampak mengurangi percakapan bolak-balik dan log berulang.
- Terverifikasi
- Dokumentasi OpenAI menjelaskan bahwa compaction mengurangi ukuran konteks sambil mempertahankan keadaan yang relevan.
- Batas
- Belum ada persentase penghematan universal; model, tingkat penalaran, ukuran repositori, kegagalan, dan log memengaruhi hasil.
Poin utama
- Menunda pengujian penuh berulang bukan berarti melewati verifikasi.
- Bandingkan panggilan alat, volume log, pengerjaan ulang, waktu, dan pemakaian pada kondisi tugas yang sama.
- Logika berisiko tinggi tetap memerlukan pengujian terarah sejak awal.
Dua ritme pengujian
- 01Perubahan terkait
- 02Cek terarah
- 03Suite penuh
- 04Catat hasil
Mengapa urutan pengujian perlu diukur
Setiap pengujian penuh menambahkan keluaran yang harus dibaca dan dibawa ke konteks berikutnya. Jika suite dijalankan setelah setiap perubahan parsial, keluaran sukses dan peringatan yang sama dapat diproses berulang.
Saat batas penerimaan sudah jelas, menyelesaikan perubahan koheren terlebih dahulu dapat mengurangi panggilan alat, log duplikat, dan diagnosis terhadap keadaan yang memang belum selesai.
Perbandingan A/B yang dapat diulang
Gunakan dua tugas serupa atau dua worktree dari commit yang sama. Pertahankan model, tingkat penalaran, instruksi repositori, dependensi, dan perintah penerimaan.
Alur A menjalankan suite penuh setelah setiap perubahan. Alur B memakai pemeriksaan statis dan tes terarah untuk risiko tinggi, lalu suite penuh yang sama setelah implementasi selesai.
- Catat waktu dan jumlah panggilan alat.
- Hitung eksekusi suite serta volume keluarannya.
- Catat pemakaian input, cached input, dan output jika tersedia.
- Hitung kegagalan dan pengerjaan ulang.
Aturan praktis saya
Migrasi data, autentikasi, pembayaran, konkurensi, dan API bersama perlu umpan balik terarah lebih awal. Perubahan salinan, komponen berdekatan, dan tipe dalam satu fitur lebih cocok untuk suite penuh di akhir.
Instruksi yang lebih tepat adalah menyelesaikan perubahan terkait, menjalankan pemeriksaan cepat untuk risiko utama, lalu menjalankan tes penuh dan build sampai hijau.
Menilai hasil dengan jujur
Perasaan lebih cepat tidak membuktikan token lebih sedikit. Laporkan pemakaian, waktu, jumlah tes, dan pengerjaan ulang bersama-sama.
Jika kesalahan ditemukan terlambat dan memerlukan debugging panjang, keuntungan dapat hilang. Kesimpulan saya saat ini hanya bahwa frekuensi pengujian layak diperlakukan sebagai variabel desain.
Kesimpulan rootchen saat ini
Nilai utama instruksi ini adalah memaksa batas hasil kerja menjadi jelas sebelum bukti dibuat.
Sampai datanya cukup, saya akan menyebutnya pengamatan, bukan angka penghematan.