Pengekodan vibe telah mengubah siapa yang boleh menghasilkan aplikasi yang kelihatan berfungsi. Satu prom boleh menjana skrin, menyambungkan API dan memasang aliran kerja yang munasabah sebelum pasukan kejuruteraan tradisional selesai membuat semakan reka bentuk pertama.

Kelajuan itu mewujudkan masalah baharu dalam pengambilan pekerja dan penyampaian: demo bukan lagi bukti kukuh bahawa perisian itu baik. Majikan akan semakin kerap bertanya soalan yang lebih sukar: bolehkah sistem yang dibina AI ini berfungsi dengan betul apabila input bercelaru, kebergantungan gagal, pengguna mengulangi tindakan dan model asas berubah?

Jawapannya akan datang daripada piawaian kualiti yang lebih menyerupai pengesahan perisian berdisiplin daripada penggilapan visual. Mereka yang menonjol bukan sekadar menunjukkan hasil alat pengekodan AI. Mereka akan menunjukkan cara mereka mengujinya, perkara yang tidak boleh dilakukannya dengan selamat dan cara mereka tahu bahawa sesuatu perubahan tidak merosakkan perkara lain.

Penanda aras ialah bukti, bukan skor papan pendahulu

Penanda aras ejen pengekodan sumber terbuka menawarkan titik permulaan yang berguna, tetapi mengukur kebolehan yang berbeza. SWE-bench menggunakan isu GitHub sebenar dan petikan repositori, menjadikannya relevan untuk kerja penyelenggaraan. Terminal-Bench menguji interaksi baris perintah. Penanda aras lain yang disenaraikan, termasuk SlopCodeBench dan ProgramBench, menyasarkan aspek berbeza kod yang dijana dan tingkah laku ejen.

Penanda aras tersebut boleh membantu membandingkan alat atau menetapkan garis dasar, tetapi majikan harus berhati-hati daripada menganggap mana-mana skor tunggal sebagai bukti kesediaan untuk pengeluaran. Model yang menyelesaikan isu repositori masih boleh menghasilkan logik kebenaran yang tidak selamat. Ejen yang menyelesaikan tugasan terminal mungkin gagal mengekalkan keadaan sepanjang aliran kerja yang panjang. Aplikasi web yang kemas mungkin melepasi demo laluan biasa tetapi tersalah mengendalikan percubaan semula atau pembayaran pendua.

Oleh itu, portfolio atau semakan dalaman yang boleh dipercayai harus merangkumi set penilaian khusus tugasan. Set itu mungkin mengandungi laporan pepijat yang mewakili keadaan sebenar, perjalanan pengguna biasa, input tidak sah, sempadan kebenaran, kegagalan kebergantungan dan regresi yang telah diperbaiki sebelum ini. Setiap kes harus mempunyai hasil jangkaan yang jelas, bukan sekadar tangkap layar yang kelihatan betul.

Pakej ujian minimum untuk perisian yang dibina AI

Untuk aplikasi kecil, pakej kualiti yang berguna boleh dibina tanpa makmal penyelidikan yang rumit:

  • Ujian penerimaan: sahkan tingkah laku yang dapat dilihat pengguna untuk aliran kerja paling penting, termasuk hasil yang berjaya dan tidak berjaya.
  • Ujian unit dan integrasi: semak peraturan perniagaan secara berasingan dan sahkan bahawa pangkalan data, API, baris gilir dan pengesahan berfungsi bersama seperti yang dimaksudkan.
  • Ujian negatif: hantar input yang hilang, tidak sah, terlalu besar, pendua dan tidak dibenarkan. Kod yang dijana AI sering kelihatan paling kukuh pada laluan yang ditunjukkan dalam prom, jadi laluan yang tidak diminta juga penting.
  • Ujian regresi: jadikan setiap kecacatan yang ditemui sebagai ujian kekal. Demo hijau selepas pembaikan tidak mencukupi jika kegagalan yang sama boleh kembali dalam perubahan yang dijana seterusnya.
  • Pemeriksaan keselamatan: uji kawalan akses, pengendalian rahsia, pertahanan terhadap suntikan, kerentanan kebergantungan dan sama ada kandungan tidak dipercayai boleh mempengaruhi panggilan alat atau tindakan istimewa.
  • Pemeriksaan operasi: sahkan tamat masa, percubaan semula, keidempotenan, pengelogan, amaran dan tingkah laku selamat apabila kebergantungan tidak tersedia.

Ini hampir sama dengan pemikiran kejuruteraan QA yang dihuraikan dalam laporan Stack Overflow tentang kitar hayat pembangunan perisian berasaskan ejen. Perubahan penting itu bersifat budaya: jaminan kualiti bukan pemeriksaan akhir selepas AI menulis kod. Ia ialah struktur yang menjadikan penjanaan pantas cukup selamat untuk digunakan.

Uji penyelarasan, bukan output sahaja

Apabila perisian merangkumi ejen AI, ujian aplikasi biasa diperlukan tetapi tidak mencukupi. Sistem mungkin gagal kerana model salah memahami permintaan, tetapi ia juga mungkin gagal kerana penyelarasan di sekelilingnya kehilangan konteks, memanggil alat dua kali, menerima output berstruktur yang tidak sah atau tidak pernah berhenti.

Bidang regresi prapelancaran yang disyorkan dalam ringkasan tersebut ialah senarai semak praktikal: kehilangan konteks, keidempotenan alat, suntikan prom, output berstruktur, ketidakberhentian, pembumian dapatan dan penghidupanan semula keadaan. Semua ini ialah sifat kejuruteraan yang boleh diuji.

Sebagai contoh, ujian boleh menjalankan permintaan yang sama dua kali dan mengesahkan bahawa percubaan kedua tidak mencipta pesanan pendua. Ujian lain boleh mengganggu ejen di tengah-tengah aliran kerja, memulakannya semula dan mengesahkan bahawa ia menyambung dari keadaan yang sah dan bukannya mengulangi tindakan yang tidak boleh dibuat asal. Ujian dapatan boleh menghendaki sistem memetik atau mengembalikan hanya maklumat daripada set sumber yang diluluskan. Ujian output berstruktur boleh membekalkan respons tidak sah dan mengesahkan bahawa aplikasi menolaknya dengan selamat dan bukannya menganggapnya sebagai data sah secara senyap.

Sistem yang berjalan lama dan berbilang ejen memerlukan rekod kegagalan yang amat jelas. Penyelidik sedang mengusahakan atribusi kegagalan automatik kerana sukar untuk mengenal pasti ejen yang menyebabkan kegagalan dan pada titik mana dalam rantaian interaksi yang panjang. Dari segi praktikal, pasukan harus mengekalkan panggilan alat, input, output, versi model, cap masa, peralihan keadaan dan keputusan akhir dalam jejak audit yang mengambil kira privasi. Tanpa bukti itu, ujian merah memberitahu anda bahawa sesuatu gagal tetapi bukan dari mana hendak memulakan pembaikan.

Kebolehulangan akan menjadi kelebihan kerjaya

Kod yang dijana AI tidak tetap. Pelaksanaan semula boleh menghasilkan pelaksanaan yang berbeza; kemas kini model boleh mengubah tingkah laku; gangguan penyedia boleh mengubah penghalaan atau kependaman. Oleh itu, majikan akan menghargai calon yang boleh menjadikan penilaian boleh diulang.

Ini bermaksud menetapkan snapshot model jika boleh, merekod prom dan konfigurasi, mengawal kerawakan apabila platform membenarkannya dan menjalankan pelbagai percubaan untuk tugasan yang keputusannya berubah-ubah. Ringkasan tersebut secara khusus menunjuk kepada snapshot yang ditetapkan, suhu rendah atau sifar jika tersedia dan pintu gerbang CI/CD bersempadan keyakinan sebagai perlindungan yang berguna.

Laporan praktikal harus membezakan sekurang-kurangnya tiga hasil:

  1. Kadar lulus: berapa banyak kes yang berjaya.
  2. Ketekalan: kekerapan kes yang sama berjaya dalam larian berulang.
  3. Keterukan: sama ada kegagalan bersifat kosmetik, menyusahkan, merosakkan data, berkaitan keselamatan, atau mampu menyebabkan tindakan luaran yang tidak selamat.

Sistem yang lulus 19 daripada 20 pemeriksaan pemformatan berisiko rendah tidak semestinya lebih baik daripada sistem yang lulus 18 daripada 20 kes tetapi tidak pernah melangkaui sempadan kebenaran. Piawaian kualiti mesti memberi wajaran kepada kegagalan berdasarkan akibatnya.

Semakan manusia harus menyasarkan risiko, bukan setiap baris

Tujuan automasi yang lebih baik bukanlah untuk memaksa seseorang membaca semula setiap token yang dihasilkan oleh AI. Tujuannya adalah untuk mengarahkan perhatian manusia kepada keputusan yang tidak dapat diselesaikan sepenuhnya oleh ujian.

Penyemak harus menumpukan perhatian pada pengesahan dan kebenaran, pengekalan data, tindakan kewangan atau kontrak, privasi, migrasi, pemulihan ralat, kebenaran pihak ketiga, serta perubahan yang mempengaruhi rangka kerja penilaian sistem itu sendiri. Bagi ejen, mereka juga harus menyemak alat yang boleh dipanggil, data yang boleh diakses oleh setiap alat, dan sama ada kelulusan diperlukan sebelum tindakan yang tidak boleh diterbalikkan.

Perbezaan yang jelas, aliran kerja kelulusan, perbualan yang diarkibkan, dan log audit—ciri-ciri yang diketengahkan dalam penerangan Slack Code tentang pengekodan AI secara kolaboratif—menunjukkan satu jangkaan yang lebih luas: sejarah cara perisian dihasilkan akan menjadi penting. Penyemak seharusnya dapat memahami permintaan, memeriksa perubahan yang dijana, melihat bukti ujian, dan mengenal pasti pihak yang meluluskan pelancaran.

Rekod itu bukan birokrasi semata-mata. Rekod itu membezakan demonstrasi yang mengagumkan daripada perubahan terkawal yang boleh diselenggara oleh orang lain.

Perkara yang perlu dimasukkan dalam portfolio atau temu duga

Bagi calon, demonstrasi yang paling kukuh ialah sistem kecil dengan kisah kualiti yang sengaja dibuat jelas. Sertakan repositori, arahan persediaan, nota seni bina, arahan ujian, kes ujian yang mewakili, had yang diketahui, dan laporan kegagalan ringkas. Tunjukkan satu atau dua pepijat yang ditemui dan ditukar menjadi ujian regresi. Terangkan model atau ejen pengekodan yang digunakan tanpa mengemukakan alat itu sebagai pengarang keputusan kejuruteraan.

Jika aplikasi menggunakan ejen, dokumentasikan kebenaran alat, model keadaan, dasar percubaan semula, syarat penamatan, dan titik kelulusan manusia. Jika aplikasi menggunakan pengambilan semula, tunjukkan cara sumber dipilih dan perkara yang berlaku apabila bukti tiada. Jika aplikasi memanggil perkhidmatan luaran, tunjukkan tingkah laku apabila tamat masa dan apabila permintaan pendua dibuat.

Jangan mendakwa kebolehpercayaan berdasarkan satu rakaman yang berjaya. Dakwaan yang boleh disemak lebih kurang berbunyi: “Merentasi 30 larian yang dirakam bagi 12 senario ini, sistem memenuhi kriteria penerimaan dalam 28 larian; dua kegagalan melibatkan input tarikh yang samar, dan kedua-duanya didokumentasikan.” Angka itu sendiri kurang penting berbanding kaedah, batasan, dan kejujuran tentang perkara yang masih belum diuji.

Takrif baharu tentang pantas

AI mengurangkan kos menghasilkan versi pertama. AI tidak menghapuskan kos untuk mengetahui sama ada versi itu layak dipercayai. Malah, penjanaan yang lebih pantas boleh menjadikan penilaian lebih penting kerana lebih banyak perubahan yang belum disemak boleh terkumpul antara pelancaran.

Profesional pasca-pengekodan berasaskan intuisi akan dinilai melalui gelung ini: takrifkan tingkah laku, jana atau ubah suai kod, uji kes yang realistik dan adversarial, periksa keputusan berisiko tinggi, rekodkan kegagalan, dan tingkatkan sistem tanpa kehilangan bukti. Penanda aras boleh membantu membandingkan keupayaan. Amalan QA menentukan sama ada keupayaan itu menjadi perisian yang boleh diharap.

Oleh itu, piawaian kualiti bukanlah “Bolehkah anda membuat aplikasi dengan AI?” Sebaliknya, “Bolehkah anda membuktikan perkara yang dilakukan oleh aplikasi itu, mengesan apabila aplikasi itu berhenti melakukannya, dan mereka bentuk had yang menghalang kegagalan daripada menjadi insiden?”