Saya tidak suka berbicara dengan robot

Saya punya ponsel Android, tapi saya telah menonaktifkan perintah suara. Saya tidak pernah memiliki Alexa. Saya tidak yakin apa sebenarnya fungsi Siri, karena saya sudah bisa hidup tanpa itu menemukan daftar putar untuk saya. Jadi ketika alat coding AI menjadi sulit diabaikan, saya perlahan-lahan mulai menerimanya. Untuk sementara waktu, saya melakukan apa yang disebut "metode satu tembak": bekerja seperti biasanya, sesekali mendelegasikan sebagian pekerjaan ke AI, lalu menunggu untuk melihat hasilnya. Ini adalah pendekatan yang sangat keren untuk orang-orang yang suka berjudi.

Bagi saya, sebagian dari gesekan adalah antarmuka obrolan itu sendiri. Gagasan untuk berbicara dengan model terasa konyol. Saya membangun sesuatu. Saya tidak bernegosiasi dengan kotak teks.

Tapi pengembangan berbasis spesifikasi tidak bekerja seperti itu. Anda mendefinisikan masalah dengan tepat, memberi tahu model AI file mana yang perlu dipertimbangkan, menggambarkan hasil yang diinginkan, berkomunikasi bolak-balik tentang rencana sebelum AI menghasilkan satu baris kode. Model AI saat ini cepat dalam menulis kode tetapi masih sangat tidak konsisten dalam pengambilan keputusan tingkat tinggi. Ketika Anda bekerja dengan AI, tugas Anda adalah mengubah pertimbangan desain menjadi spesifikasi tertulis, sehingga Anda dapat memberikan AI daftar langkah-langkah keputusan rendah yang sesuai dengan apa yang akan Anda lakukan, jika Anda akan mengetik kode sendiri. Untuk mendapatkan spesifikasi itu dengan benar, Anda harus bernegosiasi.

Saya telah mempelajari ini selama enam bulan terakhir. Dan saya menjadi cukup mahir dalam hal itu. Saya jarang/tidak pernah menulis kode secara manual, namun saya menghasilkan lebih banyak fitur daripada yang pernah saya hasilkan sebelumnya. Dan karena saya tidak menyerahkan desain perangkat lunak kepada model, saya menerapkan standar kualitas yang sama yang telah saya pelajari untuk dipertahankan dalam karier 25 tahun saya membangun produk digital.

Yang tidak saya sangka adalah betapa sulitnya ini untuk diajarkan.

Sudahkah Saya Seperti Picasso?

Ada anggapan (di antara manajemen senior?) bahwa alat-alat LLM akan meningkatkan produktivitas semua insinyur. Dalam praktiknya, saya belum melihat ini. Yang saya lihat adalah insinyur berpengalaman dan adaptif mencapai kelipatan dari apa yang biasa mereka hasilkan, sementara yang lain menghasilkan hal yang sama atau lebih sedikit.

Ini bukan situasi yang baik bagi orang yang baru memulai. Alat pengkodean berbasis AI terlihat sederhana karena antarmukanya hanya kotak teks. Tapi Anda tidak menjadi Picasso hanya dengan asal mencoret cat di kanvas kosong.

Sindrom implementasi paralel

Saya peduli dengan insinyur junior untuk banyak alasan, yang tidak kalah pentingnya adalah bahwa mereka adalah orang yang paling saya sukai untuk bekerja bersama! Keterbukaan pikiran mereka belum memudar, dan mereka membantu saya melihat hal-hal dengan cara yang berbeda. Baru-baru ini, saya melakukan perjalanan pembelajaran AI dengan seorang insinyur muda yang cerdas, antusias terhadap alat AI, ingin segera terlibat, dan sama sekali tidak ragu untuk berbicara dengan robot.

Namun, entah bagaimana, itu tidak berfungsi.

Tanda pertama adalah sistem autentikasi. Dia perlu menambahkan OAuth ke layanan yang sudah ada, dan dia meminta model untuk membangun seluruh alur autentikasi dalam satu spesifikasi besar. Login, pembaruan token, manajemen sesi, akses berbasis peran, dan alur logout. Semuanya. Model itu dengan senang hati mematuhi. Itu menghasilkan beberapa ratus baris kode yang terlihat lengkap dengan cakupan kode 100% dan uji yang lulus.

Tetapi ketika saya meninjau ulang, masalahnya adalah struktural. Model telah membuat penyimpanan sesi baru alih-alih menggunakan yang sudah kita miliki. Itu memperkenalkan pola penyegaran token yang bertentangan dengan gerbang API kami. Logika akses berbasis peran menduplikasi aturan bisnis yang sudah ada di middleware bersama. Secara teknis, tidak ada yang salah dari semua ini—semuanya berfungsi. Secara arsitektural, semuanya salah.

Saya duduk dengannya dan mengajukan pertanyaan sederhana: “Sebelum kamu meminta ini, apakah kamu tahu bagaimana kita menangani sesi hari ini?” Dia berhenti sejenak. “Tidak persis.” Itulah celahnya. Dia belum memetakan wilayah sebelum meminta model untuk membangun di atasnya.

Percobaan berikutnya berjalan berbeda, tetapi tidak cukup. Dia meminta model untuk memodifikasi alur login untuk mendukung penyedia baru. Kali ini, dia membatasi ruang lingkup, dan itu bagus. Tetapi dia mendeskripsikan perubahan berdasarkan apa yang dia inginkan dari UI, bukan berdasarkan apa yang sudah ditangani oleh kode yang sudah ada. Model, yang tidak punya alasan untuk tahu tentang abstraksi penyedia kita yang sudah ada, menulis implementasi paralel dari nol. Hasil yang sama: kode yang berfungsi, arsitektur yang salah.

Kami membicarakan apa yang telah terjadi. Saya bilang padanya untuk memikirkan model seperti memikirkan kontraktor sementara baru di tim. Berbakat, cepat, tanpa pengalaman dengan basis kode kita. Kamu tidak akan menyerahkan proyek ini kepada kontraktor sementara dan pergi begitu saja. Kamu akan bilang: ini penyimpan sesi kita, ini middleware, ini pola untuk menambahkan penyedia baru. Sesuaikan pekerjaanmu dengan ini.

Dia memahami konsepnya. Namun, beberapa putaran berikutnya menunjukkan bahwa konsep itu adalah bagian yang mudah. Dia akan menerima satu rencana dari model dan langsung menyetujuinya tanpa mendorong alternatif lain. Dia memandang kesediaan model untuk membuat perubahan kode yang luas sebagai ketelitian; saya melihatnya sebagai risiko yang tidak perlu. Dia belum memiliki insting untuk mengatakan, 'tidak, itu terlalu banyak luas permukaan untuk perubahan ini.'

Seorang insinyur berpengalaman akan menangani tugas OAuth yang sama itu dalam enam atau tujuh putaran yang terfokus, setiap putaran terbatas pada lingkup bagian sistem yang sudah dia pahami.

Keterampilan lunak adalah keterampilan keras yang baru

Hal ini mungkin terdengar seperti beban tambahan yang dapat menghilangkan keuntungan produktivitas dari pengkodean AI. Tapi ini bukan keterampilan baru. Insinyur berpengalaman telah melakukannya dalam pikiran mereka selama ini. Perbedaannya adalah bahwa pengembangan berbasis spesifikasi meng-eksternalisasi perencanaan desain perangkat lunak dari semua tugas. Negosiasi yang dulu terjadi secara internal, antara Anda dan penilaian Anda sendiri, sekarang terjadi di jendela obrolan.

Sebelum Anda membuka obrolan, Anda perlu tahu apa yang Anda inginkan. Bukan implementasinya, tetapi perilaku sistem, batasan, dan bentuknya. Anda perlu mengenal basis kode Anda dengan cukup baik untuk memberi tahu model di mana pekerjaannya harus cocok. Ketika model memberikan jawaban, mungkin itu akan berjalan. Itu tidak cukup. Anda perlu tahu apakah itu benar-benar cocok dengan sistem yang sudah Anda miliki.

Terkadang kamu menyadari bahwa model itu benar dan kamu salah, dan kamu perlu kerendahan hati untuk mengevaluasinya dengan adil.

Sepanjang seluruh proses, apa yang membedakan orang yang menggunakan alat-alat ini dengan baik dari orang yang menggunakannya dengan cepat adalah kesabaran: kemauan untuk bolak-balik lima atau enam kali alih-alih menerima sesuatu yang biasa-biasa saja di putaran kedua. Ada juga keterampilan menulis dengan tepat tentang kode tanpa menulis kode, mendeskripsikan aliran data dan edge cases, serta moda kegagalan dalam bahasa yang sederhana. Dan ada rasa, yang lebih sulit untuk didefinisikan tetapi mudah dikenali: sebuah rasa tentang seperti apa perangkat lunak yang baik dari perspektif pemeliharaan jangka panjang, bukan hanya apakah ia berjalan.

Dan kemudian ada bagian yang tidak nyaman. Sebagian besar keterampilan ini adalah pengenalan pola yang dibangun dari tahun-tahun melakukan kesalahan. Anda mengenali keputusan arsitektur yang buruk karena Anda telah mengalami konsekuensinya. Anda menolak jawaban pertama model karena Anda telah meluncurkan ide pertama Anda sebelumnya dan menyesalinya.

Insinyur junior ditempatkan dalam situasi di mana mereka perlu melakukan negosiasi desain pada tingkat tinggi, tetapi tampaknya tidak ada kurikulum untuk itu. Sudah waktunya untuk beralih dari “LeetCode” ke negosiasi desain, dan ini akan menjadi subjek postingan mendatang dalam seri ini.

Tambahan

Keterampilan Lunak untuk Merundingkan Spesifikasi dengan Kecerdasan Buatan (AI)

Selama Negosiasi

• Kelancaran membaca kode: Pindai apa yang dihasilkan model untuk kelayakan struktural, bukan hanya sintaks. Anda membaca untuk kecocokan, bukan untuk bug. Mengapa ini penting: Model dapat menghasilkan kode yang valid tetapi tidak sesuai dengan sistem Anda. Anda perlu menangkapnya dengan cepat.

• Rasa Arsitektur: Mengenali saat suatu solusi secara teknis valid tetapi salah untuk sistem ini. Mengapa itu penting: Model tidak tahu apa artinya 'salah bagi kita'. Anda yang tahu.

• Pengarah kreatif: Temukan kerangka alternatif ketika model terjebak. Nyatakan ulang masalahnya, tawarkan analogi, batasi dengan cara berbeda. Mengapa ini penting: Model merespons bagaimana Anda mengkerangkakan hal-hal, dan kerangka yang lebih baik menghasilkan hasil yang lebih baik.

• Mengetahui kapan harus mengambil sikap: Model ini menyajikan opsi secara netral. Anda yang memutuskan, dan jelaskan mengapa satu pendekatan lebih baik untuk konteks Anda. Mengapa ini penting: Itu adalah pertimbangan rekayasa, dan membutuhkan bertahun-tahun untuk mengembangkannya.

• Skeptisisme produktif: Asumsikan jawaban pertama model itu adalah draft, bukan solusi. Bukan sinisme, tetapi kebiasaan melakukan pengujian ketat sebelum menerima. Mengapa ini penting: Output draft pertama itu menarik karena kelancarannya. Kelancaran bukan ketepatan.

• Mengetahui apa yang tidak Anda ketahui: Kenali saat model mungkin benar dan Anda mungkin salah. Mengapa ini penting: Negosiasi berjalan dua arah. Terkadang hal ini mengungkapkan pendekatan yang belum pernah Anda pertimbangkan, dan Anda perlu kerendahan hati untuk mengevaluasinya dengan adil.

Di Seluruh Proses

• Kesabaran: Kembali dan maju lima atau enam kali alih-alih menerima sesuatu yang biasa-biasa saja pada putaran kedua. Mengapa penting: Ini memisahkan orang yang menggunakan alat dengan baik dari orang yang menggunakannya dengan cepat.

• Komunikasi teknis: Tulis dengan tepat tentang kode tanpa menulis kode. Deskripsikan aliran data, perubahan status, kasus tepi, dan mode kegagalan dalam bahasa yang mudah dipahami. Mengapa ini penting: Ini lebih sulit daripada yang dipikirkan kebanyakan insinyur, dan ini adalah antarmuka utama antara Anda dan model.

• Memegang kompleksitas dalam pikiran: Pantau bagaimana keputusan saat ini berinteraksi dengan tiga bagian lain dari sistem yang tidak diketahui oleh model. Mengapa ini penting: Model tidak memiliki konteks arsitektur yang persisten. Anda adalah memori kerja.

• Rasa: Perasaan tentang bagaimana perangkat lunak yang baik terasa dari perspektif pengguna. Bukan hanya "apakah ini bekerja" tetapi "apakah ini pengalaman yang tepat, perilaku yang tepat, tingkat kompleksitas yang tepat." Mengapa ini penting: Tanpa ini, Anda akan menerima solusi yang fungsional tetapi salah.

• Mengetahui kapan harus berhenti: Mengenali kapan spesifikasi sudah cukup baik untuk diserahkan ke eksekusi, dan kapan Anda melakukan perbaikan berlebihan. Mengapa penting: Hasil yang semakin berkurang adalah nyata. Pada titik tertentu, negosiasi lebih lanjut lebih mahal daripada peningkatannya.