- Para software engineer umumnya terbagi ke dalam dua kubu besar terkait LLM
- Sebagian percaya ini adalah teknologi revolusioner yang mengguncang industri
- Sementara yang lain memandangnya hanya sebagai fatamorgana yang dibesar-besarkan
- Penulis merasa secara pribadi menggunakan LLM dengan cukup bermanfaat, dan memperkenalkan cara memakainya secara efektif
Menulis kode produksi
- Selalu memanfaatkan fitur autocompletion Copilot saat menulis kode
- Sebagian besar saran autocompletion berupa boilerplate berulang seperti argumen fungsi atau input tipe
- Di area kerja utama (misalnya Ruby on Rails), ia menilai kode yang ditulis sendiri lebih baik
- Di area yang tingkat keahlian kerjanya lebih rendah, ia lebih banyak menerima logika yang disarankan Copilot
- Contoh: saat harus melakukan perubahan taktis kecil dalam bahasa seperti Golang atau C
- Dengan bantuan Copilot, ia bisa cepat memahami sintaks atau gaya kode idiomatis dalam bahasa yang kurang familier
- Karena kurang memiliki keahlian khusus, ia selalu meminta review dari ahli di bidang tersebut
- Dengan cara ini, pekerjaan pada level “intern pintar” masih cukup bisa dilakukan, tetapi proses verifikasi tetap wajib
Menulis kode sekali pakai
- Ia jauh lebih agresif memanfaatkan LLM saat menulis kode sekali pakai yang tidak akan dideploy ke produksi
- Untuk kode yang hanya dijalankan sekali demi keperluan riset lalu dibuang, kebutuhan maintenance sangat rendah
- Contoh: mengambil data publik dari API, mengelompokkannya, lalu menerapkan regex untuk validasi sederhana
- Dalam kasus seperti ini, ia merasa bisa bekerja 2–4 kali lebih cepat lewat bantuan LLM
- LLM sangat efisien untuk menulis kode yang dipakai sekali lalu dibuang
Mempelajari area baru
- Ini disebut sebagai kasus penggunaan yang paling bernilai, yaitu memakai LLM seperti tutor privat on-demand
- Contoh: saat pertama kali belajar Unity, ia terus mengajukan pertanyaan ke model seperti ChatGPT-4o
- Bukan hanya “bagaimana X bekerja?”, tetapi juga pertanyaan lanjutan seperti “apa hubungan X dengan Y?”
- Juga dipakai untuk memeriksa pemahamannya, misalnya dengan bertanya “apakah yang saya pahami ini benar?”
- Ia menggunakan LLM dengan menyalin-tempel catatan yang ditulis selama proses belajar untuk ditinjau
- Kekhawatiran tentang halusinasi (hallucination)
- Sejak GPT-3.5, ia merasa halusinasi umumnya tidak terlalu menonjol
- Sebagian besar area yang dipelajari sehari-hari sudah merupakan bidang yang mapan, sehingga risiko jawaban salah rendah
- Sampai sekarang, ia belum pernah merasa mempelajari informasi yang salah melalui LLM
Perbaikan bug sebagai upaya terakhir
- Saat benar-benar buntu, ia menunjukkan seluruh file dan pesan error ke Copilot atau Claude untuk meminta bantuan
- Dalam kebanyakan kasus, LLM bingung dan gagal memberi solusi yang tepat
- Meski begitu, ada beberapa kali LLM sempat menunjuk hal yang terlewat dan menghemat waktu
- Karena performanya tidak sebaik yang diharapkan, ia tidak mencoba berkali-kali dan biasanya hanya bertanya sekali
Koreksi salah ketik dan kesalahan logika
- Untuk tulisan (ADR, ringkasan teknis, dokumen internal, dan sebagainya), ia tidak sepenuhnya menyerahkan penulisan kepada LLM
- Ia menilai dirinya bisa menulis dengan lebih jelas, dan tidak menyukai gaya khas LLM
- Terkadang ia memasukkan draf ke LLM untuk peninjauan tata bahasa atau koreksi typo dan menerima feedback
- LLM cukup baik dalam menemukan kesalahan ejaan, dan kadang juga menawarkan sudut pandang yang menarik
- Daripada meminta saran revisi berulang kali, ia biasanya hanya memeriksa feedback satu kali pada “gambaran besar”
Ringkasan
- Cakupan pemanfaatan LLM
- “Autocompletion cerdas” dengan Copilot
- Perubahan taktis singkat di area yang kurang dikuasai (wajib review ahli)
- Menulis kode riset yang dipakai sekali lalu dibuang
- Terus bertanya saat mempelajari teknologi atau domain baru
- Mencoba menyelesaikan bug sebagai upaya terakhir saat buntu
- Mengoreksi ejaan/typo dan kesalahan logika secara umum pada draf dokumen berbahasa Inggris
- Bagian yang masih belum memakai LLM
- Menyerahkan penulisan seluruh Pull Request di area yang sudah sangat dikuasai
- Menulis penuh dokumen teknis seperti ADR
- Memahami arsitektur kompleks di dalam codebase berskala besar
6 komentar
Ini.. staff engineer..?
Memang staff engineer GitHub.
Menurut saya ini juga tidak terlihat setara dengan staff engineer... rasanya lebih tepat di level asisten, bukan?
Ada salah terjemahan pada judul; seharusnya bukan “seperti staff engineer”, melainkan “sebagai staff engineer”.
👍!!
Opini Hacker News
Sebagai seorang "staff engineer", LLM sangat buruk dalam menulis atau mengajarkan kode yang idiomatis, dan justru membuat lebih banyak waktu habis untuk code review. Menggunakan LLM untuk menulis kode berisiko membuat orang mempelajari praktik buruk serta bergantung pada jumlah kode yang besar, boilerplate, dan hasil yang tidak deterministik. LLM bisa berguna untuk menghasilkan ide atau menjelajahi informasi yang tidak dapat sepenuhnya dipercaya, tetapi mengandalkan LLM untuk menghasilkan kode adalah kegilaan.
Saat memperbaiki bug, ada cara menggunakan Copilot dengan melampirkan seluruh file dan menempelkan pesan error untuk meminta bantuan. Model "reasoning" memberikan hasil yang jauh lebih baik daripada ini; jika seluruh codebase ditempelkan dan pesan error dijelaskan, model tersebut sering kali dapat menemukan akar masalahnya.
LLM berguna untuk kode boilerplate atau autocomplete, tetapi memiliki keterbatasan pada tugas yang kompleks. Itu karena LLM tidak memahami business logic. Namun, LLM sangat berguna untuk menulis dokumen perusahaan dengan cepat.
Pernah bekerja di GitHub dan terlibat langsung dengan Copilot.
Jika menggunakan bahasa bertipe statis dan IDE yang bagus, fitur "smart auto complete" bisa jadi kurang berguna. Fitur autocomplete di Intellij terasa seperti bisa membaca pikiran hampir dalam sebagian besar kasus.
Refleksi tentang alasan para software engineer memiliki sentimen negatif terhadap LLM. Banyak orang cenderung menilainya dengan standar yang absolut, dan ini membatasi kemampuan mereka untuk memanfaatkan alat tersebut secara efektif.
Cara menggunakan AI untuk memelihara proyek Python. AI membantu mengonversi cara dari bahasa lain ke Python.
Pengalaman menggunakan ChatGPT untuk menulis utility code cukup baik. Dalam code review, AI sering menunjukkan masalah-masalah sepele, tetapi tetap bernilai ketika berhasil menemukan hal yang bisa diperbaiki.
Setelah beralih dari VSCode ke Cursor, agent mode dengan Sonnet terasa mengesankan. Jika diarahkan oleh developer berpengalaman, ini bisa sangat membantu meningkatkan produktivitas.
Menggunakan LLM untuk membantu memperbaiki typo dan kesalahan logika dalam dokumen. Menggunakan Graphite Reviewer dan menyesuaikannya agar fokus pada bug serta kesalahan yang nyata. AI tidak sempurna, tetapi berguna sebagai alat koreksi kode.