Tinjauan Sonar 2026 menunjukkan 88% pembangun menyatakan bahawa kod yang dijana AI meningkatkan hutang teknikal, dan penyokong pembangunan berasaskan spesifikasi (spec-driven development) berhujah bahawa langkah spesifikasi yang berdisiplin dapat menghentikan penyimpangan tersebut.
Mengapa masalah ini penting
Apabila manusia menerima tiket yang samar, mereka akan bertanya soalan untuk penjelasan. Sebaliknya, ejen AI mengisi kekosongan tersebut dengan tekaan terbaiknya dan menyerahkan kod yang kelihatan munasabah. Ilusi ketepatan ini membawa kos yang tinggi: tinjauan Sonar yang sama melaporkan bahawa lebih separuh daripada responden telah melihat kod yang melepasi semakan asas namun menyembunyikan kecacatan halus. Kecacatan tersebut terkumpul sebagai hutang teknikal, memaksa proses penstrukturan semula (refactor) kemudian hari, melambatkan penghantaran ciri, dan meningkatkan bajet penyelenggaraan.
Bagaimana rupa pembangunan berasaskan spesifikasi
Pembangunan berasaskan spesifikasi (SDD) mengubah urutan semasa. Daripada memberikan arahan (prompt) kepada model AI dengan cerita pengguna (user story) yang ringkas, pasukan akan menulis spesifikasi terperinci yang boleh dilaksanakan oleh ejen dan disimpan dalam sistem kawalan versi yang sama dengan kod. Spesifikasi tersebut menjadi satu-satunya sumber kebenaran—ia merekodkan niat, kes pinggir (edge cases), jangkaan prestasi, dan sebarang kekangan yang mesti dipatuhi oleh model AI.
Proses ini tidak menggantikan kerja reka bentuk manusia; ia mengkodifikasikannya. Dengan memindahkan keputusan daripada ingatan pembangun ke dalam dokumen konkrit, kedua-dua manusia dan ejen AI masa hadapan dapat menjejaki mengapa sesuatu kod berkelakuan dengan cara tertentu. Merangka spesifikasi memerlukan usaha di peringkat awal, tetapi menyahpepijat (debugging) output AI yang samar menelan kos yang jauh lebih tinggi kemudian hari.
Mengubah aliran kerja
Product backlog – Pastikan item ringkas, hanya merangkumi niat dan kriteria penerimaan tahap tinggi. Senarai ini terus memacu keutamaan.
Sprint planning – Pasukan membincangkan matlamat menyeluruh dan bersetuju dengan Matlamat Sprint (Sprint Goal), tetapi mereka menangguhkan pelaksanaan terperinci sehingga spesifikasi sedia.
Semasa sprint – Individu yang mengambil tugasan akan menulis spesifikasi yang tepat dan boleh dibaca oleh mesin. Spesifikasi tersebut menyenaraikan format input, output yang dijangkakan, pengendalian ralat, dan sebarang keperluan bukan fungsian. Oleh kerana spesifikasi tersebut dikawal versi, penyemak boleh memberi komen, mencadangkan suntingan, dan meluluskan perubahan sama seperti kod.
Definition of Done – Tambahkan “Spesifikasi disemak dan diluluskan” ke dalam pintu kualiti (quality gate). Tiada kod dianggap selesai sehingga spesifikasi melepasi piawaian semakan yang sama dengan pelaksanaan.
Adaptasi Kanban – Masukkan dua lajur baharu: “Spec Drafted” dan “Spec Approved.” Item kerja kini mengalir daripada backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done. Perubahan visual ini menjadikan langkah penyelarasan yang sebelum ini tidak kelihatan menjadi nyata.
Alatan yang sudah menguatkuasakan spesifikasi
Platform seperti GitHub Spec Kit dan AWS Kiro telah menambah pintu kawalan yang memerlukan dokumen keperluan sebelum sebarang penjanaan kod AI bermula. Ia tidak menggantikan model AI; ia menyelaraskan ejen yang berfikiran literal dengan niat manusia. Dengan menjadikan spesifikasi sebagai prasyarat, alatan ini mengautomasikan peralihan tersebut tanpa merosakkan saluran paip (pipeline) CI/CD sedia ada.
Potensi tentangan
Pengkritik mengatakan penulisan spesifikasi menambah geseran kepada rentak agile yang sudah sedia pantas. Hujah balasnya: masa yang dihabiskan untuk merangka spesifikasi biasanya hanyalah sebahagian kecil daripada masa yang akan dihabiskan kemudian untuk menyahpepijat kod terhasil AI yang berpunca daripada arahan yang samar.
Kebimbangan lain adalah spesifikasi boleh menjadi lapuk apabila keperluan berkembang. Integrasi kawalan versi menyelesaikan masalah ini: sebarang perubahan pada spesifikasi akan mencipta komit (commit) baharu, mencetuskan semakan, dan memaksa pasukan untuk menilai semula kod yang berkaitan. Dalam praktiknya, melayan spesifikasi seperti kod memastikan dokumentasi sentiasa terkini.
Apa yang perlu diperhatikan seterusnya
Penerimaan masih di peringkat awal, tetapi momentumnya jelas kelihatan. Apabila penjana kod AI menjadi lebih berkemampuan, keperluan untuk niat yang tepat dan boleh dibaca oleh mesin akan terus meningkat.
Kesimpulannya: Menukarkan arahan yang samar kepada spesifikasi konkrit yang telah disemak mungkin terasa seperti langkah tambahan, tetapi ia menukarkan tekaan kepada keputusan yang boleh dipertanggungjawabkan.