Model bahasa besar atau Large Language Model (LLM) sering kali dipromosikan melalui berbagai tajuk berita sebagai teknologi yang mampu mengoptimalkan kode serta mengidentifikasi masalah performa secara otomatis. Berangkat dari klaim tersebut, muncul inisiatif untuk memanfaatkan kecerdasan buatan dalam menangani permasalahan pada layanan mikro Go lama bernama legacyAuthService tanpa harus menghabiskan waktu berhari-hari melakukan analisis pprof untuk membuktikan setiap dugaan teknis yang muncul.
Pendekatan Awal dan Keterbatasan Respons AI Generik
Pendekatan awal yang diterapkan tergolong sederhana, yaitu dengan menanyakan langkah peningkatan kinerja layanan mikro Go secara langsung kepada instansi GPT-4. Jawaban yang dihasilkan terbukti sangat umum dan mendasar, seperti anjuran untuk mengoptimalkan kueri basis data, menggunakan goroutine secara efisien, serta menerapkan penyimpanan cache pada data yang sesuai. Walaupun petunjuk tersebut benar secara konsep dasar ilmu komputer, saran yang diberikan sama sekali tidak dapat diterapkan secara langsung pada kode riil.
Layanan legacyAuthService merupakan komponen inti yang menangani autentikasi dan otorisasi untuk hampir seluruh sistem, telah beroperasi selama bertahun-tahun, dikembangkan oleh banyak tim berbeda, serta memiliki berbagai keunikan implementasi. Layanan ini diketahui mengalami penurunan kecepatan di bawah pola beban tertentu, namun tantangan utamanya adalah menentukan titik lokasi masalah serta cara memperbaikinya tanpa merusak fungsionalitas yang sudah ada. Saran untuk sekadar mengoptimalkan basis data dinilai tidak memadai mengingat arsitektur di dalamnya menggabungkan tiga Object-Relational Mapping (ORM) berbeda serta panggilan langsung database/sql yang tersebar di belasan layanan internal. Dibutuhkan rincian spesifik yang dapat segera diinvestigasi oleh pengembang pada tingkat baris kode atau pola fungsi tertentu.
Menyertakan Konteks Teknis dan Data Profiling
Menyadari bahwa instruksi umum tidak memberikan hasil yang berguna, langkah berikutnya dilakukan dengan menyertakan lebih banyak data teknis ke dalam model. Potongan kode dari fungsi yang dicurigai berat, seperti legacyAuthService.verifyTokenAndFetchUserPermissions, disalin ke dalam prompt. Respons model kecerdasan buatan mampu menemukan potensi masalah minor seperti pencarian peta yang berulang atau potensi penunjuk bernilai nihil (nil pointer), namun poin-poin tersebut terbukti bukan merupakan akar masalah dari penurunan performa utama.
Eksperimen dilanjutkan dengan memasukkan data pemrofilan mentah yang diambil dari perintah go tool pprof -http=:8080 myapp.cpu.pprof. Potongan teks keluaran pprof, khususnya sepuluh fungsi teratas pemakan sumber daya, dimasukkan ke dalam pertanyaan untuk menanyakan letak hambatan terbesar berdasarkan profil CPU tersebut. Model AI mampu membaca nama-nama fungsi yang tertera, tetapi saran yang dihasilkan tetap berada di tataran teoritis, seperti meminta refaktorisasi fungsi terkait demi mengurangi penggunaan CPU tanpa menyajikan cara perbaikan teknis.
Pengujian kemudian diperluas ke berbagai model lain seperti Gemini Advanced dan Claude 3 Opus, termasuk mencoba rekayasa prompt peran seperti instruksi untuk bertindak sebagai insinyur performa Go senior. Meskipun beberapa model menunjukkan kemampuan pembacaan kode yang lebih baik, tidak ada satupun yang menghasilkan saran taktis yang tepat sasaran. Proses eksplorasi bertahap ini menghabiskan waktu sekitar tiga hingga empat jam selama dua sore, diiringi pencetakan diagram flame graph dan berbagai draf prompt yang belum optimal.
Strategi Efektif Melalui Kerangka Context-Data-Goal
Solusi efektif akhirnya ditemukan dengan mengubah cara interaksi terhadap LLM, yaitu memperlakukannya bukan sebagai peramal serba tahu, melainkan seperti insinyur junior yang cerdas, berpikir harfiah, dan membutuhkan panduan terstruktur. Pola pendekatan ini dirumuskan dalam kerangka Context-Data-Goal (Konteks, Data, dan Tujuan). Tahap pertama adalah memaparkan konteks, yang mencakup lingkungan sistem dengan Go 1.21.3 di kluster Kubernetes, gejala lonjakan CPU serta kenaikan latensi pada beban moderat sekitar 500 permintaan per detik, disertai kecurigaan adanya perebutan sumber daya atau pemrosesan data yang tidak efisien.
Tahap kedua adalah menyajikan data terpilah secara terarah. Alih-alih menempelkan seluruh data pprof secara acak, disajikan cuplikan profil CPU yang menunjukkan fungsi myproject/internal/auth.heavyPermissionsCheck memakan 60,15 persen CPU (12,3 detik), runtime.scanobject sebesar 15,20 persen (3,1 detik), dan pelacakan OpenTelemetry sebesar 8,00 persen (1,6 detik). Data tersebut digabungkan langsung dengan kode fungsi heavyPermissionsCheck(ctx context.Context, userID string, resource string) ([]Permission, error) beserta logika internalnya, termasuk inisialisasi make([]Permission, 0, 100) dan perulangan userRoles yang memanggil metode evaluasi akses p.HasAccess(resource).
Tahap ketiga adalah menetapkan tujuan secara spesifik. Model diminta menganalisis baris atau pola di dalam fungsi heavyPermissionsCheck yang memicu 60 persen konsumsi CPU, lalu mengajukan usulan refaktorisasi konkret atau algoritma alternatif untuk memangkas siklus CPU tanpa memerlukan perubahan arsitektur besar maupun penambahan pustaka eksternal. Perintah terstruktur ini, terutama saat dijalankan pada Claude 3 Opus, langsung menghasilkan rekomendasi teknis yang jelas, yakni melakukan memoisasi hasil p.HasAccess(resource) di dalam perulangan atau melakukan pra-penyaringan userRoles apabila parameter sumber daya bernilai konstan.
Hasil Analisis Terarah dan Kesimpulan Praktis
Hasil tersebut memberikan hipotesis terukur yang siap diuji dalam kode program. Pengalaman ini menunjukkan bahwa model bahasa besar bukanlah solusi mandiri yang instan, melainkan alat bantu analisis kode yang sangat bertenaga jika pengguna memahami sistemnya dengan baik, menyusun pertanyaan terarah, serta menyertakan data teknis yang relevan untuk menghemat waktu investigasi manual.