Saya tidak suka berbicara dengan robot

Saya mempunyai telefon Android, tetapi saya telah melumpuhkan perintah suara. Saya tidak pernah memiliki Alexa. Saya tidak pasti apa yang Siri lakukan, sebenarnya, kerana saya telah berjaya menjalani kehidupan tanpa ia mencari senarai main untuk saya. Jadi, apabila alat pengkodan AI menjadi sukar untuk diabaikan, saya perlahan-lahan menerimanya. Untuk sementara, saya melakukan apa yang sesetengah orang panggil “pendekatan satu tembakan”: bekerja seperti biasa, sekali-sekala mendelegasikan sebahagian kerja kepada AI, kemudian menunggu untuk melihat apa yang kembali. Ia adalah pendekatan yang sangat hebat untuk orang yang suka berjudi.

Bagi saya, sebahagian geseran adalah antara muka sembang itu sendiri. Idea untuk berbual dengan model terasa bodoh. Saya membina perkara. Saya tidak berunding dengan kotak teks.

Tetapi pembangunan berasaskan spesifikasi tidak berfungsi dengan cara itu. Anda menentukan masalah dengan tepat, memberitahu model AI fail yang perlu dipertimbangkan, menggambarkan hasil yang diinginkan, berbalas-balas bercakap tentang rancangan sebelum AI menjana sebaris kod. Model AI hari ini pantas dalam pengkodan tetapi masih bahaya tidak konsisten dalam pembuatan keputusan peringkat tinggi. Apabila anda bekerja dengan AI, tugas anda ialah mengubah pertimbangan reka bentuk anda menjadi spesifikasi bertulis, supaya anda boleh memberikan AI senarai langkah keputusan rendah yang sepadan dengan apa yang akan anda lakukan, jika anda sendiri akan menaip kod. Untuk mendapatkan spesifikasi itu betul, anda perlu berunding.

Saya telah mempelajari ini dalam tempoh enam bulan yang lalu. Dan saya sudah cukup mahir dengannya. Saya jarang/tidak pernah menulis kod secara manual, tetapi saya menghasilkan lebih banyak ciri daripada yang pernah saya lakukan sebelum ini. Dan memandangkan saya tidak menyerahkan reka bentuk perisian kepada model, saya mengekalkan piawaian kualiti yang sama yang telah saya pelajari untuk pertahankan dalam kerjaya 25 tahun saya membina produk digital.

Apa yang tidak saya jangkakan ialah betapa sukarnya untuk mengajar ini.

Adakah Saya Sudah Jadi Picasso?

Ada tanggapan (di kalangan pengurusan kanan?) bahawa Alat Model Bahasa Besar akan meningkatkan produktiviti semua jurutera. Dalam praktik, saya tidak melihat ini. Apa yang saya lihat ialah jurutera berpengalaman dan mudah menyesuaikan diri mencapai gandaan daripada apa yang mereka pernah hasilkan, manakala yang lain menghasilkan sama atau kurang.

Ini bukan situasi yang baik untuk orang yang baru bermula. Alat pengekodan AI kelihatan mudah kerana antara mukanya hanya kotak teks. Tetapi anda tidak menjadi Picasso dengan sewenang-wenangnya meleburkan cat pada kanvas kosong.

Sindrom pelaksanaan selari

Saya mengambil berat tentang jurutera junior atas banyak sebab, salah satu yang paling penting ialah mereka adalah orang kegemaran saya untuk bekerjasama! Keterbukaan fikiran mereka belum lagi mengecut, dan mereka membantu saya melihat perkara secara berbeza. Baru-baru ini, saya menempuh perjalanan pembelajaran AI dengan seorang jurutera muda yang bijak, bersemangat tentang alat AI, bersedia untuk terjun, dan langsung tidak teragak-agak untuk berbual dengan robot.

Namun, entah bagaimana ia tidak berfungsi.

Tanda pertama adalah sistem pengesahan. Dia perlu menambah OAuth kepada perkhidmatan yang sedia ada, dan dia meminta model untuk membina seluruh aliran pengesahan dalam satu spesifikasi besar. Log masuk, penyegaran token, pengurusan sesi, akses berasaskan peranan, dan aliran log keluar. Semuanya. Model itu dengan senang hati mematuhi. Ia menghasilkan beberapa ratus baris kod yang kelihatan lengkap dengan liputan kod 100% dan ujian yang lulus.

Tetapi apabila saya mengkaji semula, masalahnya adalah struktur. Model telah mencipta simpanan sesi baharu dan bukannya menggunakan yang sudah kita ada. Ia memperkenalkan corak penyegaran token yang bercanggah dengan pintu masuk API kami. Logik akses berasaskan peranan menduplikasi peraturan perniagaan yang sudah wujud dalam perisian pertengahan kongsi. Dari segi teknikal, tiada satu pun daripada ini salah—ia berfungsi. Secara seni bina, semuanya salah.

Saya duduk bersamanya dan bertanya soalan yang mudah: “Sebelum anda memulakan ini, adakah anda tahu bagaimana kami mengendalikan sesi hari ini?” Dia terdiam. “Tidak tepat.” Itulah jurangnya. Dia belum memetakan wilayah sebelum meminta model membina di atasnya.

Cubaan berikutnya berlaku secara berbeza, tetapi tidak cukup. Dia meminta model untuk mengubah suai aliran log masuk untuk menyokong penyedia baru. Kali ini, dia mengecilkan skop, yang bagus. Tetapi dia menerangkan perubahan berdasarkan apa yang dia ingin UI lakukan, bukan berdasarkan apa yang kod sedia ada sudah kendalikan. Model itu, tanpa sebab untuk mengetahui tentang abstraksi penyedia sedia ada kami, menulis pelaksanaan selari dari awal. Hasil yang sama: kod berfungsi, seni bina salah.

Kami berbincang tentang apa yang telah berlaku. Saya memberitahunya untuk memikirkan model itu seperti dia memikirkan seorang kontraktor sementara baru dalam pasukan. Bert bakat, pantas, tiada pengalaman dengan pangkalan kod kami. Anda tidak akan menyerahkan projek ini kepada seorang kontraktor sementara dan pergi begitu saja. Anda akan berkata: ini simpanan sesi kami, ini perisian perantara kami, ini corak untuk menambah penyedia baru. Sesuaikan kerja anda dengan ini.

Dia faham konsepnya. Tetapi beberapa pusingan berikutnya menunjukkan kepada saya bahawa konsep itu adalah bahagian yang mudah. Dia akan mendapat satu pelan daripada model dan meluluskannya tanpa mendesak untuk alternatif. Dia melihat kesediaan model untuk membuat perubahan kod yang luas sebagai teliti; saya melihatnya sebagai risiko yang tidak perlu. Dia belum mempunyai naluri untuk mengatakan 'tidak, itu terlalu banyak luas permukaan untuk perubahan ini.'

Seorang jurutera berpengalaman mungkin telah mengendalikan tugas OAuth yang sama itu dalam enam atau tujuh pusingan fokus, setiap satu berlingkup pada sebahagian sistem yang telah difahaminya.

Kemahiran insaniah adalah kemahiran teknikal yang baru

Ini mungkin kedengaran seperti beban tambahan yang akan menghapuskan keuntungan produktiviti pengkodan AI. Tetapi ini bukan kemahiran baru. Jurutera berpengalaman telah melakukan ini dalam kepala mereka sepanjang masa. Perbezaannya ialah pembangunan berasaskan spesifikasi mengeluarkan perancangan reka bentuk perisian bagi semua tugas. Rundingan yang dahulu berlaku secara dalaman, antara anda dan penilaian sendiri anda, kini berlaku dalam tetingkap sembang.

Sebelum anda membuka sembang, anda perlu tahu apa yang anda mahukan. Bukan pelaksanaannya, tetapi tingkah laku, kekangan, bentuknya. Anda perlu tahu basis kod anda dengan cukup baik untuk memberitahu model di mana kerjanya perlu sesuai. Apabila model kembali dengan jawapan, ia mungkin berjalan. Itu tidak cukup. Anda perlu tahu sama ada ia benar-benar sesuai dengan sistem yang sudah anda miliki.

Terkadang, anda menyedari bahawa model itu betul dan anda salah, dan anda memerlukan kerendahan hati untuk menilai hal itu dengan adil.

Sepanjang keseluruhan proses, apa yang membezakan orang yang menggunakan alat-alat ini dengan baik daripada orang yang menggunakannya dengan cepat ialah kesabaran: kesanggupan untuk berulang-alik lima atau enam kali berbanding menerima sesuatu yang sederhana pada pusingan kedua. Terdapat juga kemahiran menulis secara tepat tentang kod tanpa menulis kod, menerangkan aliran data dan kes tepi, serta mod kegagalan dalam bahasa biasa. Dan terdapat citarasa kejuruteraan, yang lebih sukar untuk ditakrifkan tetapi mudah untuk dikenali: rasa tentang bagaimana perisian yang baik dirasakan dari perspektif penyelenggaraan jangka panjang, bukan sekadar sama ada ia berjalan.

Dan kemudian ada aspek yang tidak selesa. Kebanyakan kemahiran ini adalah pengenalan corak yang dibina setelah bertahun-tahun membuat kesilapan. Anda mengenal pasti keputusan seni bina yang buruk kerana anda telah mengalami akibatnya. Anda menolak jawapan pertama model kerana anda telah melaksanakan idea pertama anda dahulu dan menyesalinya.

Jurutera junior diletakkan dalam situasi di mana mereka perlu melakukan perundingan reka bentuk pada tahap tinggi, tetapi nampaknya tidak ada kurikulum untuk itu. Sudah tiba masanya untuk beralih dari “LeetCode” kepada perundingan reka bentuk, dan ini akan menjadi topik untuk siaran masa depan dalam siri ini.

Tambahan

Kemahiran Insaniah untuk Merundingkan Spesifikasi Teknikal dengan Kecerdasan Buatan (AI)

Semasa Perundingan

• Kefasihan membaca kod: Imbas apa yang dihasilkan model untuk struktur yang kukuh, bukan sekadar sintaks. Anda membaca untuk kesesuaian, bukan untuk pepijat. Mengapa penting: Model boleh menghasilkan kod yang sah tetapi tidak sesuai untuk sistem anda. Anda perlu menangkapnya dengan cepat.

• Citarasa seni bina: Kenal pasti bila sesuatu penyelesaian sah secara teknikal tetapi salah untuk sistem ini. Mengapa ia penting: Model tidak tahu maksud 'salah untuk kita'. Anda tahu.

• Panduan kreatif: Cari kerangka alternatif apabila model tersekat. Nyatakan semula masalah, tawarkan analogi, hadkan dengan cara berbeza. Mengapa ia penting: Model bertindak balas kepada cara anda mengkerangkakan perkara, dan kerangka yang lebih baik menghasilkan hasil yang lebih baik.

• Mengetahui bila untuk mengambil pendirian: Model menyajikan pilihan secara neutral. Anda membuat keputusan, dan mengartikulasikan mengapa satu pendekatan lebih baik untuk konteks anda. Mengapa ia penting: Itu adalah pertimbangan kejuruteraan, dan ia mengambil masa bertahun-tahun untuk membina.

• Keraguan produktif: Anggap jawapan pertama model sebagai draf, bukan penyelesaian. Bukan sikap sinis, tetapi tabiat menjalani ujian tekanan sebelum menerima. Mengapa ia penting: Output lulusan pertama adalah menggoda kerana ia lancar. Kelancaran bukanlah ketepatan.

• Mengetahui apa yang tidak diketahui: Mengakui apabila model mungkin betul dan anda mungkin salah. Mengapa ia penting: Rundingan berlaku dua hala. Kadang-kadang ia mendedahkan pendekatan yang anda belum pertimbangkan, dan anda perlu kerendahan hati untuk menilainya dengan adil.

Di Seluruh Proses

• Kesabaran: Berulang-alik lima atau enam kali daripada menerima sesuatu yang sederhana pada pusingan kedua. Mengapa ia penting: Ini membezakan orang yang menggunakan alat dengan baik dengan orang yang menggunakannya dengan cepat.

• Komunikasi teknikal: Tulis dengan tepat tentang kod tanpa menulis kod. Terangkan aliran data, perubahan keadaan, kes tepi, dan mod kegagalan dalam bahasa yang mudah. Mengapa ia penting: Ini lebih sukar daripada yang difikirkan oleh kebanyakan jurutera, dan ia adalah antara muka utama antara anda dan model.

• Memegang kerumitan dalam fikiran: Memantau bagaimana keputusan semasa berinteraksi dengan tiga bahagian lain sistem yang tidak diketahui model. Mengapa ia penting: Model tidak mempunyai konteks seni bina berterusan. Anda adalah ingatan kerja.

• Citarasa: Suatu rasa tentang bagaimana perisian yang baik terasa dari perspektif pengguna. Bukan sekadar 'adakah ia berfungsi' tetapi 'adakah ini pengalaman yang betul, tingkah laku yang betul, tahap kerumitan yang betul.' Mengapa ia penting: Tanpanya, anda akan menerima penyelesaian yang berfungsi tetapi salah.

• Mengetahui bila untuk berhenti: Kenal pasti bila spesifikasi cukup baik untuk diserahkan kepada pelaksanaan, dan bila anda melakukan penghalusan berlebihan. Mengapa ia penting: Hasil berkurangan adalah nyata. Pada satu titik, perundingan lanjut mengorbankan lebih daripada yang diperbaiki.