Siapa Menyemak Kod Janaan AI Apabila Ejen Yang Menulisnya?

Bayangkan seorang ketua kejuruteraan di sebuah syarikat fintech di Kuala Lumpur pada pagi Isnin. Sepanjang hujung minggu, tiga ejen pengekodan telah membuka 40 pull request. Hanya dua orang dalam pasukan boleh meluluskannya, dan kedua-duanya ada kerja sendiri.

Jadi, siapa menyemak kod AI apabila ejen menulis lebih pantas daripada manusia mampu membaca? Satu susunan semakan melakukan sebahagian besar pembacaan, dan setiap satu menangkap jenis kesilapan yang berbeza. Seorang manusia meluluskannya di hujung.

Setiap lapisan di bawah menamakan produk Sonar yang melakukan kerja itu dan pelan yang diperlukan, setakat Oktober 2026. Jika anda mengetuai kejuruteraan di Malaysia atau Singapura, termasuk di bank atau fintech, inilah susunan yang kami cadangkan untuk semakan kod janaan AI.

Ejen kini menulis lebih pantas daripada manusia mampu menyemak

Dalam tinjauan Sonar sendiri pada 2026 terhadap 1,149 pembangun yang pernah menggunakan AI di tempat kerja dalam setahun yang lalu, AI menyumbang 42% daripada kod yang di-commit. Tinjauan itu menjangkakan bahagian itu mencecah 65% menjelang 2027. Tinjauan yang sama mendapati 96% "do not fully trust AI-generated code" (tidak mempercayai sepenuhnya kod janaan AI), dan "only 48% always verify it before committing" (hanya 48% sentiasa mengesahkannya sebelum commit).

Semakan ialah tempat kerja bertimbun. Dalam tinjauan itu, 38% berkata menyemak kod AI memerlukan lebih banyak usaha berbanding menyemak kod rakan sekerja. GitHub melaporkan pada Mei 2026 bahawa "More than one in five code reviews on GitHub now involve an agent" (lebih satu daripada lima semakan kod di GitHub kini melibatkan ejen).

Banyak pull request ejen langsung tidak menunjukkan tanda disemak. Satu kajian 2026 tentang pull request yang ditulis ejen dalam repositori GitHub popular mendapati 61.38% mempunyai "no recorded review activity" (tiada aktiviti semakan yang direkodkan). Daripada komen semakan yang wujud, 71.58% datang daripada ejen.

Laporan Octoverse 2025 GitHub menunjukkan corak yang sama. Pull request yang di-merge meningkat 23% dalam setahun, manakala komen pada isu dan pull request kekal "essentially flat" (hampir mendatar). GitHub menyifatkannya sebagai isyarat pemerhatian, bukan bukti sebab-akibat.

Apa yang terlepas apabila tiada siapa membaca diff

Empat jenis masalah paling penting apabila ejen yang menulis kod.

• Kebergantungan (dependency) yang ditarik masuk oleh ejen. Sonar memberi amaran bahawa "agents may autonomously install packages without manual vetting" (ejen mungkin memasang pakej sendiri tanpa disaring). Satu kajian 2025 mendapati model AI mereka nama pakej yang tidak wujud: secara purata sekurang-kurangnya 5.2% daripada pakej yang dicadangkan bagi model komersial, dan 21.7% bagi model sumber terbuka.
• Suntikan (injection). Sonar mengesyorkan kod AI disemak untuk "eliminate injection vulnerabilities" (menghapuskan kelemahan suntikan), contohnya input pengguna yang ditampal terus ke dalam pertanyaan pangkalan data. Ejen juga berdepan jenis kedua, iaitu prompt injection.
• Rahsia (secrets). Laporan GitGuardian 2025 mendapati repositori awam yang menggunakan GitHub Copilot mempunyai kadar kebocoran rahsia 6.4%. Kadar itu 40% lebih tinggi berbanding purata repositori awam.
• Kelemahan logik perniagaan dan kawalan akses. Kawalan akses yang rosak berada di tempat pertama dalam OWASP Top 10 2025, senarai risiko aplikasi web yang digunakan secara meluas daripada Open Worldwide Application Security Project. Dalam data di sebalik senarai itu, 100% aplikasi yang diuji mempunyai sejenis kelemahan ini.

Nama pakej rekaan ialah laluan serangan sebenar. Penulis kajian itu menggelarnya "a novel form of package confusion attack" (satu bentuk baharu serangan kekeliruan pakej): sesiapa yang mendaftarkan nama itu dahulu menentukan apa yang dipasang oleh build anda.

Prompt injection ialah risiko yang ditambah oleh ejen di atas kelemahan kod biasa. OWASP memberi amaran bahawa prompt injection tidak langsung berlaku apabila model bahasa besar (LLM) "accepts input from external sources, such as websites or files" (menerima input daripada sumber luar, seperti laman web atau fail). Pada pandangan kami, ini bermakna ejen yang membaca isu atau README yang telah dicemari boleh dipandu ke arah yang salah.

Bagi kami, kelemahan kawalan akses ialah yang paling sukar antara keempat-empatnya. Kod itu melakukan tepat seperti yang tertulis dan lulus ujiannya. Cuma ia membenarkan orang yang salah melakukannya.

Semakan kod janaan AI: enam semakan, mengikut susunan kod ejen melaluinya

Kami kumpulkan susunan ini kepada enam semakan. Rangka kerja Sonar sendiri menyusun produknya kepada tiga gelung:

• Semasa ejen menulis (gelung agentik).
• Pada pull request, sebelum apa-apa di-merge (gelung pengesahan CI, atau integrasi berterusan).
• Merentas kod asas, selepas merge (gelung penyelenggaraan kod).

Anda boleh menampung sesetengah lapisan dengan alat lain. Contohnya, branch protection dalam platform Git anda mengendalikan kelulusan. Kami memetakan enam semakan ini kepada Sonar kerana satu vendor meliputi setiap satunya, dan kerana kami menjual semula produknya.

Kembali kepada 40 pull request tadi. Inilah yang dilakukan oleh setiap lapisan terhadapnya, dan pelan yang diperlukan.

1. Semasa ejen menulis: Sonar Vortex

Sonar Vortex memberi ejen pengekodan konteks projek anda "before they write a line of code, then verifies their output in real time" (sebelum ejen menulis sebaris kod, kemudian mengesahkan hasilnya secara masa nyata). Ia berfungsi dengan Claude Code (Claude, dikuasakan oleh Anthropic), Codex, GitHub Copilot CLI, Cursor dan Antigravity, antara lain. Sonar menyatakan ia "works alongside your existing CI" (berfungsi bersama CI sedia ada anda), bukan menggantikannya.

Inilah tempat paling awal untuk menangkap kesilapan, sebelum mana-mana daripada 40 pull request itu wujud. Dalam ujian Sonar sendiri dengan satu ejen pengekodan, Vortex mengurangkan isu yang dihasilkan ejen sebanyak 92%. Angka itu daripada Sonar sendiri; kami belum melihat ujian bebas.

Pelan. Pada SonarQube Cloud, Vortex disertakan dalam Sonar Agent Essentials, yang memerlukan pelan Enterprise atau pelan Team tahunan. Pada SonarQube Server, ia langganan berasingan untuk edisi Enterprise, versi 2026.5 ke atas.

2. Pada pull request: Gitar, penyemak AI

Gitar ialah penyemak pull request AI yang diambil alih oleh Sonar pada 21 Mei 2026. Apabila pull request dibuka, ia "automatically reviews the code and posts inline review comments along with suggested fixes" (menyemak kod secara automatik dan menyiarkan komen semakan sebaris berserta cadangan pembetulan). Pada hari Isnin itu, setiap daripada 40 pull request sudah mempunyai semakan pusingan pertama sebelum seorang manusia membukanya.

Apabila larian CI gagal, Gitar mencari puncanya dan "suggests a fix, which it can commit automatically or on demand" (mencadangkan pembetulan, yang boleh di-commit secara automatik atau atas permintaan). Halaman harga Sonar menyenaraikan gelung yang "iterates until CI passes" (berulang sehingga CI lulus) sebagai ciri pelan Pro.

Ini mengubah siapa yang menulis pull request itu. Sebaik sahaja Gitar membuat commit, perubahan itu mempunyai dua pengarang AI: ejen dan penyemak. Seorang manusia masih perlu meluluskannya.

Pelan. Gitar ialah produk Sonar berasingan yang "can be purchased separately" (boleh dibeli secara berasingan). Harganya dikira setiap pengguna pada pelan Core dan Pro, dan harga Enterprise ditetapkan secara khusus. Semasa Sonar membeli Gitar, Sonar menyatakan Gitar juga boleh dibeli bersama SonarQube dan SonarQube Advanced Security.

3. Semasa merge: quality gate

Penyemak AI memberi pendapat. Quality gate pula ialah semakan lulus atau gagal dengan syarat bertulis, dan ia boleh menyekat merge.

SonarQube AI Code Assurance mengenakan gate yang dibina khas untuk projek yang ditulis AI. Panduan kami tentang SonarQube AI Code Assurance dan quality gate untuk kod janaan AI menerangkan enam syarat dan cara menyediakannya, jadi kami tidak mengulanginya di sini. Daripada 40 itu, mana-mana pull request yang melanggar syarat gate boleh ditahan daripada di-merge, setelah gate ditetapkan sebagai semakan wajib.

Pelan. Pada SonarQube Server, analisis pull request, sekatan merge dan AI Code Assurance bermula pada edisi Developer. Community Build percuma hanya menganalisis cabang utama (main).

4. Kebergantungan: SonarQube Advanced Security

Advanced Security menyemak pakej sumber terbuka yang digunakan oleh kod anda. Ia menandakan kelemahan yang diketahui, dan analisis kebolehcapaian (reachability) meletakkan yang "your code actually calls" (benar-benar dipanggil oleh kod anda) di tempat teratas.

Ia juga menyemak kebergantungan "against known malicious packages" (berbanding pakej berniat jahat yang diketahui). Polisi lesen turut diliputi. Untuk audit, ia mengeksport SBOM (software bill of materials, iaitu senarai setiap komponen yang anda hantar) dalam format CycloneDX dan SPDX, dua format yang digunakan secara meluas.

Bagi 40 pull request itu, inilah lapisan yang menyemak setiap pakej yang ditambah ejen berbanding senarai kelemahan dan perisian hasad, serta polisi lesen anda. Pakej berniat jahat yang baru muncul mungkin belum ada dalam mana-mana senarai, jadi seorang manusia masih patut mempersoalkan mana-mana kebergantungan yang tiada siapa minta. Tanpa Advanced Security, syarat kebergantungan dalam AI quality gate Sonar menjadi kelabu dan dilangkau.

Pelan. Langganan berasingan pada pelan SonarQube Cloud Team dan Enterprise, dan pada SonarQube Server Enterprise.

5. Merentas kod asas: SonarQube Hunter Agent

Hunter Agent mencari "broken access control, business logic, and authentication flaws that traditional analysis misses" (kelemahan kawalan akses, logik perniagaan dan pengesahan identiti yang terlepas oleh analisis tradisional). Pengumuman pelancaran Sonar menyatakan ia berjalan di latar belakang, mengikut jadual atau atas permintaan, jadi ia "never blocks a pull request" (tidak pernah menyekat pull request).

Dokumentasi Sonar jelas bahawa ia "doesn't fix the issues it finds" (tidak membetulkan isu yang ditemuinya). Ia mengimbas kod asas yang telah di-merge, jadi ia melihat 40 pull request itu bersama-sama selepas semuanya masuk. Seseorang masih perlu memutuskan maksud setiap penemuan bagi perniagaan anda.

Pelan. Langganan berasingan. Pada SonarQube Cloud, ia memerlukan pelan Enterprise. Pada SonarQube Server, ia memerlukan edisi Enterprise, versi 2026.5 ke atas.

6. Membetulkan secara besar-besaran: AI CodeFix dan Remediation Agent

AI CodeFix menggunakan LLM untuk mencadangkan pembetulan bagi isu yang ditemui SonarQube. Pembangun melihat cadangan itu dalam SonarQube atau editor mereka dan memilih sama ada mahu menggunakannya.

SonarQube Remediation Agent pergi lebih jauh: ia mencadangkan pembetulan dan membuka pull request baharu untuk disemak oleh pasukan anda. Ia bekerja pada backlog anda dan pada pull request yang gagal quality gate.

Pada SonarQube Cloud, bahagian pull request hanya berfungsi untuk projek yang disambungkan ke GitHub. Bagi 40 pull request pada hari Isnin, pull request yang ditahan oleh gate mungkin menerima cadangan pembetulan sebagai pull request baharu, jika bahasanya disokong dan pembetulan itu lulus semakan semula Sonar.

Pembetulan yang gagal semakan semula Sonar tidak ditunjukkan kepada anda. Dan ia tidak pernah membuat merge: "Your developers do" (pembangun anda yang melakukannya).

Satu perincian penting bagi pasukan yang dikawal selia. Sonar menyatakan menjalankan SonarQube Server pada infrastruktur anda sendiri "does not keep code within your network when you use the agent" (tidak mengekalkan kod dalam rangkaian anda apabila anda menggunakan ejen itu). Kod dihantar kepada penyedia LLM yang ditetapkan oleh pentadbir anda, seperti Azure AI Foundry atau AWS Bedrock.

Pelan. AI CodeFix tersedia pada SonarQube Server Enterprise serta pelan SonarQube Cloud Team dan Enterprise. Pada SonarQube Cloud, Remediation Agent disertakan dalam Sonar Agent Essentials, dengan pelan Team tahunan atau pelan Enterprise. Pada SonarQube Server, anda membelinya secara berasingan untuk edisi Enterprise, versi 2026.5 ke atas.

Apa yang masih memerlukan manusia

Setiap lapisan di atas mengecilkan apa yang perlu dibaca oleh manusia. Tiada satu pun yang memiliki keputusan untuk menghantar kod ke produksi.

Kelulusan

Setakat Oktober 2026, dokumentasi GitHub menyatakan pull request daripada Copilot cloud agent "must be reviewed and merged by a human" (mesti disemak dan di-merge oleh manusia). Ejen itu "cannot approve or merge a pull request" (tidak boleh meluluskan atau merge pull request). GitHub juga menghalang orang yang meminta ejen membuat perubahan daripada meluluskannya.

Dokumentasi Anthropic untuk Claude Code GitHub Actions menasihati: "review Claude's changes before merging" (semak perubahan Claude sebelum merge). Panduan kami untuk menggunakan Claude Code sebagai pasukan menerangkan persediaan itu. Walau apa pun, layan mana-mana penyemak AI, termasuk Gitar, sebagai penyemak yang memberi komen, bukan yang meluluskan.

Peraturan yang sama terpakai kepada ejen yang bekerja di luar kod. Contohnya, dots OpenAI yang sentiasa aktif dalam ChatGPT boleh ditetapkan supaya meminta kelulusan sebelum bertindak; panduan kami tentang OpenAI dots dan peraturan kelulusannya menerangkan caranya.

Pengasingan tugas

Tuliskan peraturan ini. Sesiapa yang meluluskan pull request ejen mestilah orang lain: bukan ejen yang menulisnya, dan bukan orang yang memintanya.

Bagi bank dan syarikat insurans di Malaysia, polisi Risk Management in Technology (RMiT) Bank Negara Malaysia meminta prosedur "to independently review and approve system changes" (untuk menyemak dan meluluskan perubahan sistem secara bebas). Ia juga meminta "appropriate segregation of duties throughout the SDLC" (pengasingan tugas yang sewajarnya sepanjang SDLC), iaitu kitaran hayat pembangunan perisian. Panduan semakan kod sumber RMiT kami memetakan klausa tersebut kepada bukti yang diminta juruaudit.

Di Singapura, Monetary Authority of Singapore (MAS) menerbitkan Technology Risk Management Guidelines (Januari 2021). Garis panduan itu meminta institusi kewangan "adopt standards on secure coding, source code review and application security testing" (menggunakan piawaian untuk pengekodan selamat, semakan kod sumber dan ujian keselamatan aplikasi). Ia juga menyatakan isu utama "should be remediated before production deployment" (patut dibetulkan sebelum dilancarkan ke produksi). Halaman SonarQube Singapura kami memetakan perenggan Technology Risk Management (TRM) yang berkaitan kepada ciri SonarQube yang menyokongnya.

Jika anda mengendalikan pembayaran kad, Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 membenarkan anda menyemak kod "using either manual or automated processes" (sama ada secara manual atau automatik) (keperluan 6.2.3). Sama ada penilai menerima penyemak AI sebagai semakan automatik itu masih belum muktamad, jadi tanya penilai anda dahulu. Anggap bahagian ini sebagai titik permulaan untuk pasukan pematuhan anda, bukan nasihat undang-undang.

Semakan reka bentuk

Tiada alat dalam susunan ini yang tahu sama ada perubahan itu patut wujud langsung. Semakan reka bentuk ringkas sebelum tugasan ejen yang besar bermula patut menjawab soalan seperti ini:

• Adakah perubahan ini sepadan dengan apa yang diminta pelanggan?
• Adakah ia menambah cara kedua untuk melakukan sesuatu yang sudah dilakukan oleh kod asas?
• Patutkah bayaran balik melebihi RM 50,000 memerlukan pelulus kedua?

Tanya soalan ini sebelum 40 pull request itu tiba, bukan selepasnya.

Cara bermula: pelan mana, dan senarai semak

Kebanyakan pasukan tidak memerlukan setiap lapisan pada hari pertama. Inilah susunan yang munasabah untuk semakan kod janaan AI.

1. Hidupkan analisis pull request dan sekatan merge. Pada SonarQube Server, ini memerlukan edisi Developer atau lebih tinggi; perbandingan edisi kami menunjukkan apa yang ditambah oleh setiap edisi. Pada SonarQube Cloud, pelan Team menganalisis setiap pull request. Tanpa ini, kod ejen sampai ke main sebelum SonarQube menyemaknya.
2. Labelkan projek yang ditulis AI dan gunakan AI quality gate. Ikut senarai semak persediaan dalam panduan AI Code Assurance kami.
3. Wajibkan kelulusan manusia, dan sekat kelulusan sendiri. Orang yang meminta ejen membuat perubahan tidak patut meluluskan pull request tersebut.
4. Tambah Advanced Security jika ejen dibenarkan menambah pakej.
5. Tambah Gitar jika penyemak tenggelam dalam pull request, supaya semakan pusingan pertama dan pembetulan CI berlaku sebelum manusia melihatnya.
6. Tambah ejen Sonar apabila backlog mewajarkannya. Setakat Oktober 2026, ia ialah tambahan berbayar. Pada SonarQube Cloud, ia memerlukan pelan Team tahunan atau pelan Enterprise, dan Hunter Agent memerlukan Enterprise. Pada SonarQube Server, ia memerlukan edisi Enterprise, versi 2026.5 ke atas. Untuk cara harga SonarQube sendiri dikira, lihat panduan kami tentang harga SonarQube mengikut baris kod.
7. Tentukan ke mana kod anda boleh pergi. SonarQube Cloud menyimpan data di EU atau US sahaja. Jika kod mesti kekal dalaman, gunakan Server, dan semak endpoint LLM mana yang akan dipanggil oleh Remediation Agent dan mana-mana ciri lain yang bergantung pada LLM.
8. Semak semula selepas sebulan. Tag pull request ejen mengikut pengarang atau label supaya anda boleh mengiranya. Kemudian kira berapa banyak yang di-merge tanpa sebarang komen manusia. Angka itu sepatutnya menurun.

Ringkasnya, siapa menyemak kod AI? Mesin membaca dahulu, tetapi seorang manusia yang bebas daripada penulisnya masih memberi kata putus.

Soalan lazim

Sumber

• Dokumentasi Sonar: Agent Centric Development Cycle (Vortex, Remediation Agent, Hunter Agent, AI CodeFix), disemak 7 Oktober 2026.
• Sonar: Sonar acquires Gitar, 21 Mei 2026, dan halaman pelan Gitar.
• GitHub Docs: Copilot cloud agent risks and mitigations, disemak 7 Oktober 2026.
• Spracklen et al., package hallucinations by code-generating LLMs, USENIX Security 2025.
• Bank Negara Malaysia, Risk Management in Technology, dikeluarkan 25 September 2026.

Lihat SonarQube di Malaysia, termasuk Gitar dan ejen AI, atau SonarQube di Singapura jika anda membeli di sana.