Article

Analisis SonarQube Terhadap Kepribadian LLM Terkenal

5 min Read

Pemanfaatan Large Language Model (LLM) dalam pengembangan perangkat lunak semakin umum digunakan untuk mempercepat proses penulisan kode. Namun, kecepatan tidak selalu berbanding lurus dengan kualitas. Kode yang dihasilkan AI tetap berpotensi mengandung bug, security issue, atau technical debt jika tidak melalui evaluasi yang tepat.
Melalui pendekatan code quality analysist menggunakan SonarQube, artikel ini mengeksplorasi bagaimana karakteristik kode dari beberapa LLM terkenal dapat dianalisis secara objektif. Tujuannya bukan untuk membandingkan mana yang “paling pintar”, melainkan memahami bagaimana SonarQube membantu menjaga kualitas kode di era pengembangan berbasis AI.

Latar Belakang

Penggunaan Large Language Models (LLM) seperti GPT-4o, Claude, dan Llama kini telah menjadi bagian yang tak terpisahkan dari Software Development Life Cycle (SDLC). AI kini mempercepat penulisan kode, membantu memecahkan masalah dalam programing, serta meningkatkan produktivitas developer secara signifikan.
Namun menurut laporan “The Code Personalities of Leading LLMs” (Sonar, Oktober 2025) menunjukan fakta penting yang sering diabaikan.
LLM memang mampu menulis working code, tetapi secara konsisten gagal dalam menulis kode yang secure, compliance, dan maintainable.
Disinilah perlu lapisan kontrol yang wajib dalam pengembangan Software Modern.

Pendekatan

Berbeda dengan evaluasi AI biasanya yang hanya mengandalkan Benchmark fungsional, dalam laporan tersebut Sonar menggunakan pendetakan yang jauh lebih dalam.
Disini Sonar melakukan analisis pada kode yang dihasilkan oleh setiap model AI dengan menggunakan SonarQube enterprise static analysis engine, yang telah dikembangkan selama lebih dari 16 tahun untuk mendeteksi:

  • Bug
  • Vulnerabilities
  • Security Hotpots
  • Code Smells
  • Technical Debt

Analisis dilakukan pada model AI dengan mengerjakan 4.442 Java programming assignments dari sumber terkenal, termasuk MultiPL-E-mbpp-java, MultiPL-E-humaneval-java, dan ComplexCodeEval.

MultiPL-E benchmarks GPT-5-minimal Claude Sonnet 4 Claude 3.7 Sonnet GPT-4o Llama 3.2 90B OpenCoder-8B
HumanEval (158 tasks) 91.77% 95.57% 84.28% 73.42% 61.64% 64.36%
MBPP  (385 tasks) 68.13% 69.43% 67.62% 68.13% 61.40% 58.81%
Weighted test Pass@1 avg 75.37% 77.04% 72.46% 69.67% 61.47% 60.43%

Tabel 1: Performa LLM pada MultiPL-E Java benchmarks (source: The Coding Personalities of Leading LLMs).

Metrik Penilaian yang Digunakan

Sonar tidak menilai “apakah kode dapat berjalan”, tetapi apakah kode layak dijalankan, dengan menggunakan beberapa metrik yaitu:

  • Bug Density
  • Vulnerabilities (BLOCKER, CRITICAL, MAJOR)
  • Code Smell Density
  • Cycle & Cognitive Complexity
  • Comment Density
  • Code Volume (LOC)
LLM Model BLOCKER % CRITICAL % MAJOR % MINOR %
GPT-5-minimal 35.00 31.67 3.33 30.00
Claude Sonnet 4 59.57 28.37 5.67 6.38
Claude 3.7 Sonnet 56.03 28.45 5.17 10.34
GPT-4o 62.50 23.21 5.36 8.93
Llama 3.2 90B 70.73 22.76 1.63 4.88
OpenCoder-8B 64.18 26.87 1.49 7.46

Tabel 2: Distribusi tingkat kerentanan (source: The Coding Personalities of Leading LLMs).

LLM % Bugs % Vulnerabilities % Code smells
GPT-5-minimal 4.67% 0.46% 94.87%
Claude-Sonnet-4 5.85% 1.95% 92.19%
Claude-3.7-Sonnet 5.35% 1.76% 92.88%
GPT-4o 7.41% 2.05% 90.54%
Llama 3.2 90B 7.71% 2.38% 89.90%
OpenCoder-8B 6.33% 1.72% 91.95%

Tabel 3: Distribusi dari tipe issue yang dihasilkan oleh LLM (source: The Coding Personalities of Leading LLMs).
Laporan ini menunjukkan bahwa semua model LLM yang di tes, memiliki kelemahan dan kelebihan yang sama, yaitu:

Kelebihan:

  • Mampu menghasilkan kode yang valid secara syntax
  • Cukup mampu dalam memecahkan masalah algoritma
  • Sangat efektif untuk mempercepat masa awal development

Kelemahan:

  • Lemah dalam regulasi software development
  • Meninggalkan banyak celah keamanan
  • Sering gagal menutup resource (file, stream, connection)
  • Menghasilkan hardcodded secrets
  • Sering menghasilkan messy code

Setiap LLM Mempunyai “Kepribadian” yang Unik

Sama seperti developer pada umumnya, Sonar menemukan bahwa setiap model AI memiliki kepribadian yang berbeda, disebut juga sebagai coding personality. Kepribadian ini diukur berdasarkan sifat-sifat seperti:

  • Kevokalan: Seberapa banyak kode yang ditulis
  • Kompleksitas: Seberapa rumit struktur dan logika kode
  • Komunikasi: Seberapa banyak komentar yang menjelaskan isi kode

LLM Model Lines of Code (LOC) Comments (%) Cyclomatic Complexity Cognitive Complexity
GPT-5-minimal 490,010 2.10% 145,099 111,133
Claude-Sonnet-4 370,816 5.10% 81,667 47,649
Claude-3.7-Sonnet 288,126 16.40% 55,485 42,220
GPT-4o 209,994 4.40% 44,387 26,450
Llama 3.2 90B 196,927 7.30% 37,948 20,811
OpenCoder-8B 120,288 9.90% 18,850 13,965

Tabel 4: Komparasi metrik dari kode yang dihasilkan masing-masing LLM (source: The Coding Personalities of Leading LLMs).

Tipe “Kepribadian” Model AI

Berdasarkan laporan “The Code Personalities of Leading LLMs”, Sonar mengelompokkan model LLM menjadi beberapa archetypes:

LLM Coding archetype Functional skill (pass rate %) Issue density (Issues/KLOC) Verbosity (LOC) Cognitive complexity Dominant flaw type (% of total issues)
GPT-5minimal The baseline performer 75.37% 26.65 490,010 111,133 94.87% code smells
Claude Sonnet 4 The senior architect 77.04% 19.48 370,816 47,649 92.2% code smells
Claude 3.7 Sonnet The balanced predecessor 72.46% 22.82 288,126 42,220 92.9% code smells
GPT-4o The efficient generalist 69.67% 26.08 209,994 26,450 90.5% code smells
Llama 3.2 90B The unfulfilled promise 61.47% 26.20 196,927 20,811 89.9% code smells
OpenCoder-8B The rapid prototyper 60.43% 32.45 120,288 13,965 92.0% code smells

Tabel 4: LLM archetypes (source: The Coding Personalities of Leading LLMs).

1. Developer Senior – Claude Sonnet 4

  • Kode yang dibuat memiliki kevokalan dan kompleksitas yang tinggi
  • Banyak lapisan proteksi
  • Risiko tinggi di bug concurrency dan resource leak

Perlu diperhatikan:
Kode yang dihasilkan terlihat “enterprise-ready“, tetapi justru menyembunyikan critical bug yang sulit dideteksi.

2. Model Awal yang Seimbang – Claude Sonnet 3.7

  • Dokumentasi terbaik (16,7% komentar)
  • Kode mudah dibaca oleh developer
  • Menghasilkan sejumlah besar kerentanan tingkat BLOCKER

Perlu diperhatikan:
Kode yang terlihat rapi dan terdokumentasi dengan baik, tidak otomatis menjadi kode yang aman.

3. Model Umum yang Efisien – GPT-4o

  • Kompleksitas sedang
  • Cocok untuk penggunaan umum
  • Sangat sering membuat kesalahan alur logika (48% bug)

Perlu diperhatikan:
Terdapat bug “halus” yang mungkin lolos di testing awal namun dapat muncul di lingkungan Production.

4. Ekspektasi yang Tidak Terpenuhi – Llama 3.2 90B

  • Dengan Skala dan didukung oleh perusahaan besar, namun hasilnya biasa
  • 70% kerentanan yang dihasilkan tergolong BLOCKER
  • Hasil keamanan paling buruk dari semua model yang di uji coba

Perlu diperhatikan:
Walaupun dari segi skalanya yang besar dan mendapat dukungan dari perusahaan besar, penggunaan model ini untuk Production sangat berisiko.

5. Rapid Prototyper – OpenCoder-8B

  • Kode yang paling sedikit (LOC rendah)
  • Cocok untuk tahap awal Development atau PoC
  • Banyak menghasilkan technical debt

Perlu diperhatikan:
Menghasilkan 42% code smell yang berasal dari dead & unused code.

6. Model Penalaran – GPT-5 (minimal mode)

  • Akurasi fungsional terbaik
  • Kompleksitas ekstrem
  • Keamanan tertinggi

Perlu diperhatikan:
Walaupun kode yang dihasilkan memiliki keamanan tertinggi, namun tingkat kompleksitasnya yang tinggi juga membuat kode lebih sulit untuk di-maintain oleh developer. Jika dibandingkan dengan model lainnya yang menghasilkan kerentanan yang umum dan sederhana, model yang lebih canggih justru menghasilkan kerentanan yang kompleks dan sulit dideteksi oleh manusia.

Metric Claude 3.7 Sonnet (Older) Claude Sonnet 4 (Newer) GPT-5-minimal
Benchmark pass rate 72.46% 77.04% 75.37%
% of Vulnerabilities that are ‘BLOCKER’ 56.03% 59.57% 35.00%
% of Bugs from ‘Concurrency/Threading’ 1.44% 9.81% 20.00%

Tabel 5: LLM archetypes (source: The Coding Personalities of Leading LLMs).

Mengapa SonarQube Menjadi Solusi di Era AI?

“AI mempercepat penulisan kode, tetapi membuat risiko dari bug sederhana ke bug kompleks yang sulit dideteksi manusia.” Di sinilah SonarQube hadir untuk:

  • Menyediakan verifikasi objektif
  • Menjaga standar konsistensi
  • Mengontrol risiko keamanan (Vulnerabilities)
  • Menekan Technical Debt sejak awal

Pendekatan yang tepat bukan “percaya pada AI”, melainkan:
“Trust, but verify”
Di masa depan, sebagian besar kode akan ditulis dengan bantuan AI. Namun artikel ini menegaskan satu hal penting:
“Tanpa SonarQube, AI bukan sumber inovasi melainkan sumber dari risiko tersembunyi”
Kenapa demikian? Karena SonarQube memastikan bahwa:

  • Kecepatan tidak mengorbankan Security
  • Inovasi tidak menciptakan Technical Debt
  • Kode AI tetap layak digunakan di Production

Hasil analisis ini memperlihatkan bahwa meskipun LLM mampu mempercepat proses development, kualitas kode tetap memerlukan kontrol yang konsisten. Tanpa pengukuran yang jelas, risiko maintainability dan keamanan dapat meningkat seiring bertambahnya penggunaan AI dalam penulisan kode.

Pendekatan berbasis SonarQube memberikan visibilitas yang dibutuhkan untuk menilai kualitas kode secara objektif, baik yang ditulis oleh developer maupun dihasilkan oleh AI.

Mari diskusikan dengan tim i3 mengenai praktik code quality dan penerapannya di lingkungan pengembangan modern dapat menjadi langkah awal untuk memastikan standar kualitas tetap terjaga seiring evolusi teknologi.

Written by: Masagus Rayhan Bayhaqi, Consultant DevOps
Edited by: Pipit Pirda Damayanti, Marketing

Table of Contents

Share this article
Scroll to Top