Lewati ke konten
Riset & Model

Studi pracetak: asisten kode otomotif menaruh verifikasi di tangan pengembang

Makalah pracetak merancang asisten kode C/C++ otomotif dengan alat verifikasi yang dipicu pengembang. Dalam pilot dua minggu, alat itu paling sering dipakai.

Makalah pracetak di arXiv menguji kolaborasi manusia dan agen AI dalam rekayasa perangkat lunak otomotif yang kritis keselamatan. Menurut penulisnya, riset tentang agen pemrograman selama ini terpusat pada mutu generasi kode. Perangkat lunak otomotif, kata mereka, menuntut lebih dari itu.

Masalah: kode yang bagus belum tentu bisa dipertanggungjawabkan

Tuntutan tambahannya adalah verifikasi. Setiap perubahan kode harus ditinjau, ditelusuri ke persyaratan tertentu, dan diperiksa terhadap standar industri seperti MISRA, pedoman pengkodean C untuk keandalan sistem otomotif, serta AUTOSAR, standar arsitektur perangkat lunak otomotif, sebelum boleh dimasukkan ke basis kode. Karena itu, pertanyaannya bukan hanya apakah model bisa menulis kode yang patuh, tetapi bagaimana agen bekerja bersama pengembang agar kepatuhan itu bisa diperiksa, diaudit, dan dipercaya.

Tuntutan kedua adalah kecocokan domain. Menurut makalah, kode otomotif harus menjamin eksekusi deterministik di bawah batasan waktu nyata, mengikuti pola arsitektur tertentu yang jarang muncul saat pelatihan awal, dan bekerja dengan memori serta sumber daya yang ketat. Konvensi antarmuka yang khas bagi tiap organisasi juga jarang ada di data pelatihan model umum.

Penulis mengacu pada studi lain yang menemukan bahwa model bahasa populer kesulitan menghasilkan kode patuh MISRA secara bawaan. Mereka juga menyebut halusinasi model menimbulkan risiko keselamatan yang nyata.

Rancangan: tiga alat dan pemeriksaan sesuai permintaan

Asisten yang diusulkan dibangun di atas Model Context Protocol (MCP), protokol untuk menghubungkan model bahasa dengan alat eksternal. Sistem ini menyediakan tiga alat bagi pengembang: generate untuk membuat isi fungsi dari tanda tangan dan dokumentasinya, edit untuk merevisi fungsi, dan verify untuk memeriksa kode berdasarkan aturan otomotif.

Bagian yang paling ditekankan adalah verify. Pengembang dapat menjalankannya pada kode apa pun, kapan pun, tanpa bergantung pada agen untuk memeriksa keluarannya sendiri. Penulis berargumen bahwa pemeriksaan yang bisa dilewati agen bukanlah pemeriksaan yang andal, sehingga pemicunya harus berada di tangan manusia.

Untuk menyesuaikan model dengan domain, tim membangun kumpulan data dari kode produksi otomotif milik AUMOVIO. Setiap fungsi dipasangkan dengan teks persyaratan yang harus dipenuhinya serta perilaku yang dimodelkan dalam Unified Modeling Language (UML), bahasa pemodelan standar untuk menggambarkan struktur dan perilaku sistem.

Model yang disesuaikan dan hasil pilot

Makalah membandingkan dua strategi kustomisasi. Pertama, prompt engineering dengan model API umum, yakni konteks yang dirakit dan aturan dimasukkan secara lengkap saat inferensi. Kedua, fine-tuning, yaitu melatih ulang model pada data khusus domain. Menurut penulis, perbedaannya terletak pada kapan informasi domain sampai ke model, bukan pada isinya.

Dalam pilot dua minggu pada proyek produksi yang aktif, pengembang melaporkan verify sebagai alat yang paling sering dipakai. Mereka juga mengonfirmasi memakainya pada kode tulisan sendiri, tidak hanya pada keluaran agen. Sebanyak 75 persen lebih memilih konfigurasi prompt engineering yang lebih cepat.

Hasil pemeriksaan pola tidak sepenuhnya searah. Prompt engineering menghasilkan lebih sedikit pelanggaran aturan bergaya MISRA dan AUTOSAR pada kode C. Sebaliknya, fine-tuning lebih sesuai dengan pola arsitektur pada kode C++.

Keterbatasan dan status pracetak

Makalah ini berstatus pracetak. Versi pertamanya diunggah ke arXiv pada 26 Oktober 2026 dalam kategori Software Engineering dan Artificial Intelligence. Halaman arXiv mencatat makalah ini diterima di lokakarya REALM pada konferensi EMNLP 2026; ini tidak sama dengan telaah sejawat jurnal penuh.

Pemeriksa yang dipakai adalah pencocok pola terinspirasi standar, sehingga penulis menyebut hasilnya kesesuaian pola, bukan kepatuhan standar. Abstrak tidak merinci jumlah pengembang dalam pilot maupun jumlah pelanggaran yang tercatat. Angka 75 persen adalah preferensi peserta, bukan pengukuran produktivitas.

Apa berikutnya

Makalah tidak merinci rencana lanjutan, seperti evaluasi yang lebih luas atau penerapan di proyek lain. Pergeseran fokus yang diusulkan jelas: dari seberapa baik model menulis kode ke bagaimana kode itu bisa diverifikasi, ditelusuri, dan dipertanggungjawabkan oleh manusia.

#perangkat lunak otomotif#verifikasi kode#agen pemrograman#keselamatan fungsional#arxiv

Terkait