Cara Oxide Memanfaatkan LLM

• Large language model (LLM) secara fundamental mengubah cara kerja, dan Oxide mendefinisikan dengan jelas bagaimana teknologi ini akan digunakan di dalam organisasi
  • Oxide adalah startup infrastruktur komputasi on-demand yang membangun perangkat keras dan perangkat lunak terintegrasi untuk data center on-premises
• Sebagai prinsip inti dalam pemanfaatan LLM, Oxide menekankan keseimbangan antara tanggung jawab, ketelitian, empati, kerja tim, dan urgensi
• LLM berguna untuk ringkasan dan pemahaman dokumen, code review, debugging, dan lainnya, tetapi penilaian serta tanggung jawab manusia tetap esensial saat menulis atau membuat kode
• Hasil yang dihasilkan LLM harus selalu berada dalam struktur di mana manusia meninjau dan bertanggung jawab atas hasil tersebut
• Oxide mendorong penggunaan LLM, tetapi dengan prasyarat rasa tanggung jawab terhadap produk, pelanggan, dan rekan kerja

---

Standar nilai untuk penggunaan LLM

• Oxide mengevaluasi penggunaan LLM berdasarkan nilai-nilai inti organisasi
  • Tanggung jawab (Responsibility) : LLM hanyalah alat, dan tanggung jawab atas hasil sepenuhnya berada pada manusia
  • Ketelitian (Rigor) : Jika digunakan dengan hati-hati, LLM dapat mempertajam cara berpikir, tetapi jika ceroboh justru dapat menurunkan kualitas pemikiran
  • Empati (Empathy) : Baik penerima maupun penulis bahasa adalah manusia, sehingga komunikasi harus tetap berpusat pada manusia
  • Kerja tim (Teamwork) : Penggunaan LLM tidak boleh merusak kepercayaan antarrekan kerja, dan pengungkapan bahwa LLM digunakan tidak boleh terlihat sebagai pengalihan tanggung jawab
  • Urgensi (Urgency) : Meskipun dapat meningkatkan kecepatan, nilai-nilai lain tidak boleh dikorbankan

Berbagai cara memanfaatkan LLM

LLMs as Readers

• LLM sangat unggul dalam merangkum dokumen dan menjawab pertanyaan, sehingga dapat membantu memahami materi dalam jumlah besar dengan cepat
• Namun, privasi data harus dijamin, dan perlu dipastikan bahwa dokumen yang diunggah tidak digunakan untuk pelatihan model
• Berguna sebagai alat bantu memahami dokumen, tetapi tidak boleh menggantikan situasi yang menuntut pembacaan langsung

LLMs as Editors

• Efektif untuk memperbaiki struktur dan gaya dokumen yang sudah selesai, dan bermanfaat jika digunakan pada tahap akhir
• Namun, LLM cenderung memberikan respons yang terlalu positif, sehingga bisa kurang dalam analisis kritis
• Jika digunakan pada tahap draf awal, ada risiko kehilangan suara khas penulis

LLMs as Writers

• Tulisan yang dihasilkan LLM sering kali terasa klise atau jelas memperlihatkan jejak auto-generated
• Tulisan yang dibuat secara otomatis dapat merusak keaslian pemikiran dan kepercayaan pembaca
• Pembaca biasanya mengasumsikan bahwa penulis memahami isi tulisan, tetapi tulisan buatan LLM meruntuhkan asumsi tersebut
• Dengan asumsi bahwa semua anggota Oxide memiliki kemampuan menulis, LLM tidak digunakan sebagai pelaku utama dalam penulisan
• Namun, LLM masih dapat digunakan secara terbatas untuk merapikan ide atau sebagai alat bantu

LLMs as Code Reviewers

• LLM berguna untuk mendeteksi jenis masalah kode tertentu, tetapi tidak dapat menggantikan review oleh manusia
• Karena sarannya bisa tidak logis atau melewatkan konteks, LLM hanya digunakan sebagai alat bantu

LLMs as Debuggers

• LLM dapat dimanfaatkan sebagai ‘rubber duck’ untuk memancing ide dalam proses debugging
• Kemampuan menyelesaikan masalah secara nyata terbatas, tetapi berguna sebagai pemicu untuk memunculkan pendekatan baru

LLMs as Programmers

• LLM memiliki kemampuan menghasilkan kode yang sangat baik, sehingga cocok untuk penulisan kode eksperimental atau pendukung
• Semakin dekat kode tersebut ke kode produk, semakin penting verifikasi dan tanggung jawab
• Kode yang ditulis LLM harus ditinjau langsung oleh penulisnya (self-review), dan wajib diperiksa sebelum review oleh rekan kerja
• Saat code review, menanggapi dengan meregenerasi seluruh kode dilarang, karena membuat peninjauan berulang menjadi tidak mungkin
• Bahkan saat menghasilkan kode, tanggung jawab, ketelitian, empati, dan kerja tim harus tetap dijaga

Operasional dan panduan

• Detail teknis dan pedoman internal penggunaan LLM dirangkum dalam dokumentasi internal di GitHub
• Oxide mendorong penggunaan LLM, tetapi dengan syarat pemanfaatannya dilakukan secara bertanggung jawab
  • Kesadaran tanggung jawab terhadap kualitas produk, kepercayaan pelanggan, dan kolaborasi antarrekan kerja ditempatkan sebagai prioritas utama

[GN⁺]

Komentar Hacker News

• Tulisan Bryan menunjukkan sudut pandang yang seimbang dan realistis
  Saya rasa RFD tidak membahas hal itu karena Oxide tidak merekrut engineer junior
  Bryan adalah engineer yang sudah lebih dari 30 tahun menangani software dan hardware yang sulit, dan punya pengalaman menuntaskan “program yang benar-benar sulit (OS)”
  Cara dia menggunakan LLM sangat berbeda dengan engineer junior pada 2025
  Engineer junior sekarang tampaknya hampir tidak pernah coding tanpa bantuan LLM

  • Dulu ada masa ketika di perusahaan saya hanya membuat model untuk ingest data selama berbulan-bulan
    Begitu membosankan sampai rasanya berat untuk masuk kerja, tetapi sekarang sepertinya bisa selesai dalam hitungan menit dengan LLM
    Waktu yang dulu dihabiskan untuk itu sekarang terasa hampir seperti kegilaan
  • Saya ingat di kelas desain web pertama, pengajar menghabiskan satu semester penuh mengajarkan “prinsip dasar” HTML, CSS, dan JS dengan Notepad
    Baru setelah itu Dreamweaver diperkenalkan, dan produktivitas naik sepuluh kali lipat
  • Ketegangan antara “craftsmanship vs pragmatisme” pada LLM itu menarik
    Di bidang seperti riset keamanan, yang hasilnya jelas, LLM sangat unggul, tetapi lemah untuk masalah yang membutuhkan penilaian yang halus
    Jadi idealnya bagian yang repetitif dan sistematis diserahkan ke LLM, sementara bagian yang membutuhkan penilaian tetap ditangani manusia
  • Saya sudah memrogram lebih dari 20 tahun, dan ada semacam penolakan tak terlihat terhadap penggunaan LLM
    Tetapi sekarang saya menerima bahwa ini adalah “cara pemrograman yang baru”, dan setelah menyadarinya malah terasa seperti menjadi lebih muda
  • Lucu juga bahwa tepat setelah frasa “orang-orang yang bisa mengenali jejak LLM” muncul em-dash (—) dalam kalimat itu
    Agak menjengkelkan bahwa sekarang memakai em-dash bisa membuat tulisan disangka hasil AI

• Saat membaca RFD Oxide, saya mengangguk setuju pada sebagian besar isinya, tetapi saya tidak setuju dengan bagian yang menyiratkan bahwa “LLM menulis kode dengan baik sejak awal”
  LLM memang bagus untuk mengatasi “sindrom halaman kosong”, tetapi saya rasa kode yang benar-benar layak deploy masih jauh dari hasil yang diberikannya
  Ini mungkin semacam “ilusi kemajuan”

  • Menulis adalah ekspresi pribadi, tetapi kode adalah alat pemecahan masalah
    LLM belajar dari “solusi yang baik” yang sering muncul di dataset, sehingga kuat dalam menyelesaikan masalah
    Sebaliknya, ekspresi manusia pada dasarnya beragam, jadi ekspresi yang rata-rata justru jadi tidak menarik
    Pada akhirnya, LLM bisa membatasi kemampuan untuk memecahkan masalah yang belum terpecahkan
    Saya melihat kualitas kode yang rendah terutama berasal dari keterbatasan context window
  • Tulisan yang klise itu buruk, tetapi kode yang klise justru bagus
  • Sanggahan “coba pakai model lain” sekarang terasa seperti “No True Scotsman” di dunia LLM
    Generasi di tingkat fungsi masih oke, tetapi jika disuruh menangani satu fitur penuh, struktur dan antarmukanya jadi berantakan
    Kalau dianalogikan ke menulis, yang pas itu seperti hanya memberi kalimat pertama dan terakhir sebuah paragraf lalu membiarkannya mengisi sisanya
  • Ini mirip dengan fenomena bahwa kita mudah menangkap kesalahan pada berita di bidang yang kita kuasai, tetapi cenderung langsung percaya pada bidang yang tidak kita kenal
    Programmer bisa menilai kualitas kode, tetapi untuk tulisan tidak selalu begitu
  • Kualitas LLM memang berbeda-beda tergantung modelnya
    Banyak orang punya kesan buruk karena memakai model lama atau model murah

• Saya ragu dengan klaim bahwa “LLM pandai membedakan tulisan buatan LLM”
  Saya penasaran apakah itu benar-benar dibuktikan dengan data

  • Bryan dari Oxide menjelaskannya langsung
    Proses rekrutmen mereka sangat berpusat pada tulisan, sehingga belakangan ini aplikasi kerja yang ditulis dengan LLM melonjak tajam
    Mereka sudah memperingatkan soal itu di RFD 0003 dan halaman karier, tetapi tetap saja terus terjadi
    Episode podcast juga membahas kasus-kasus terkait
    LLM memang tidak bisa menangkap semua tulisan AI, tetapi berguna sebagai alat bantu deteksi untuk kasus yang mencurigakan
  • Sebagai cara membedakan tulisan buatan LLM, ada usulan untuk memasukkan setengah teks ke LLM lalu memintanya memprediksi sisanya, kemudian membandingkan probabilitas n-token
    Saya belum pernah mencobanya, tetapi pendekatannya menarik
  • Karena sulit mendeteksi sejauh mana LLM terlibat dalam penulisan—apakah menulis penuh, merangkum, atau hanya mengoreksi—
    saya rasa dengan teknologi saat ini penilaian yang sempurna masih mustahil

• Saat memakai kode hasil LLM, tanggung jawab ada pada engineer
  Kode yang belum ditinjau sendiri tidak layak masuk review
  Prosedur saya seperti ini:

  1. masukkan kode yang relevan → 2) jelaskan tujuan → 3) telaah desain → 4) hasilkan kode → 5) uji dan perbaiki → 6) baca ulang seluruh kode dengan saksama lalu edit manual
     Tahap terakhir yang paling sulit, dan secara emosional paling ingin dilewati
     Cara ini membantu mempertahankan pemikiran di level arsitektur sambil mengurangi pekerjaan berulang
     Tetapi LLM itu nondeterministik, jadi berbeda dari alat yang bisa diprediksi seperti compiler
  • Dalam praktiknya, tahap 6 memakan sebagian besar waktu keseluruhan
    Kalau kodenya tidak berjalan dengan baik, perlu lebih banyak perbaikan lagi
    Karena itu saya belum yakin LLM benar-benar menghemat waktu
  • Sebelum tahap 4, akan bagus jika ditambahkan langkah untuk lebih dulu menghasilkan kode uji, lalu membuat implementasinya gagal dulu sebelum akhirnya lolos
  • Jika alih-alih edit manual kita membiarkan LLM memimpin semua perubahan, ia bisa mempertahankan konsistensi pengetahuan dalam satu sesi
  • Namun cara itu terasa merusak harga diri dan rasa kepemilikan engineer
    Sulit terlibat secara emosional dalam merapikan kode yang dibuat mesin

• Aneh bahwa kemungkinan pelanggaran hak cipta pada kode buatan LLM tidak disebutkan
  Kode GitHub bisa saja tersalin mentah-mentah, dan ini isu penting bagi perusahaan open source

  • Jika hasil buatan LLM tidak termasuk objek hak cipta, maka status hukum kode berlisensi Copyleft menjadi kabur
    Hak cipta hanya berlaku jika kontribusi manusia cukup signifikan, tetapi batasnya tidak jelas
  • Saya penasaran apakah isu seperti ini pernah dibahas di pengadilan
  • Saya juga bertanya-tanya apakah LLM terbaru masih menimbulkan masalah seperti ini, atau malah lebih sering daripada manusia

• Dokumennya tersusun rapi, tetapi bagian yang mengatakan “memakai LLM sebagai bantuan membaca tidak masalah” terasa kontradiktif
  Jika hasilnya sempurna, tidak ada bedanya dengan membaca teks asli, dan jika tidak sempurna, ada risiko salah paham
  Saya sering melihat LLM tidak benar-benar membaca dokumen, melainkan hanya menebak dari daftar isi
  Ada risiko munculnya lapisan terjemahan di antara konten dan pembaca

  • Saya rasa RFD itu bukan soal “membaca”, melainkan soal ekspektasi sosial terhadap “menulis”
  • Jika Anda menyuruhnya membandingkan tiga buku teknis lalu hasilnya salah, itu adalah kegagalan dalam penggunaan alat
    Seluruh teks harus dimasukkan langsung ke context window
    Hanya saja, isi tiga buku penuh mungkin memang melampaui batas LLM

• Saya setuju dengan pernyataan bahwa “tulisan buatan LLM bahkan merusak keaslian pemikiran”
  Tulisan yang benar-benar ditulis manusia punya nilai, sedangkan tulisan LLM terasa seperti salinan yang nilainya sudah diencerkan
  Kesan bahwa lebih baik membaca prompt-nya langsung terasa sangat mengena

  • Seni manusia mengekspresikan dunia batin individu, sedangkan LLM adalah hasil rata-rata kolektif
    Gagasan yang menarik dan orisinal justru berada di titik yang menyimpang dari rata-rata
    Saya bisa memahami penggunaan LLM untuk membantu non-native speaker mengekspresikan pikirannya dengan lebih baik, seperti dalam penerjemahan,
    tetapi penerima tetap bisa meragukan apakah ekspresi itu benar-benar pikiran pribadi penulisnya
  • Ini mengingatkan pada “Programming as Theory Building” dari Naur
    Komentar adalah upaya mengekspresikan konteks teoretis yang tidak tertuang dalam kode
    Karena LLM tidak bisa memiliki “teori” seperti itu, ia tidak dapat menghasilkan komentar yang benar-benar bernilai
  • Saya tidak suka “gaya tulisan AI” yang khas LLM, tetapi banyak orang tidak menyadarinya
    Misalnya, sebagian besar posting /r/SaaS terasa seperti ditulis LLM,
    tetapi tetap berhasil memancing respons pembaca lewat storytelling yang emosional
    Saya sendiri juga memakai LLM untuk menulis dokumentasi dan benchmark
    Ini juga membantu non-native speaker saat menulis dokumen teknis, meski kualitasnya sangat bervariasi
    Pada akhirnya, untuk tulisan yang bertujuan menyampaikan informasi, LLM makin lama makin berguna
  • Ucapan “saya ingin membaca prompt-nya” juga muncul saat melihat headline berita
    Bukan hanya apa yang ditulis, tetapi mengapa itu ditulis yang membuat penasaran
  • LLM pandai memprediksi kalimat yang rata-rata, tetapi hampir tidak pernah bisa menebak kalimat yang kreatif
    Jadi walaupun pikiran saya mungkin tidak orisinal, setidaknya ada hiburan bahwa secara statistik ia cukup jarang muncul

• Saya rasa tulisan yang dibuat dengan LLM tidak layak dibaca
  Bagus bahwa Oxide menetapkan prinsip tegas untuk tidak memakai LLM pada hasil non-kode
  Dalam code review pun sama, kode yang dihasilkan harus ditinjau dulu oleh penulisnya
  Apakah budaya seperti ini benar-benar bisa dipertahankan masih harus dilihat, tetapi arahnya bijak

• Persepsi bahwa LLM dilatih dari data hasil pencurian sangat kuat,
  dan saya rasa persepsi publik seperti ini seharusnya ikut dipertimbangkan
  Entah sebagai isu etika atau risiko merek, saat ini itu jelas faktor penting

  • Saya melihat dokumen ini bukan untuk publik umum, melainkan sebagai dokumen teknis internal
    Tujuannya lebih untuk memberikan pedoman teknis daripada menyatakan posisi etis
  • “Runtuhnya kepercayaan” yang dibahas dalam tulisan itu tampaknya menangani masalah yang sama dengan ungkapan berbeda
    Tulisan buatan LLM kehilangan keaslian, dan pembaca bisa merasa bahkan pemikirannya pun sudah diotomatisasi
    Pada akhirnya ini bisa merusak kepercayaan antarmanusia

• Pernyataan bahwa “menulis adalah kerja intelektual yang lebih besar daripada membaca” terasa menarik
  Tetapi untuk kode, saya justru merasa kebalikannya

  • Tulisan yang buruk itu tidak berguna, tetapi kode yang buruk pun, selama masih jalan, setidaknya bisa menutup tiket Jira
    Karena itu jumlah kode buruk jauh lebih banyak
    Sebaliknya, kode yang ditulis dengan baik punya nilai pembelajaran yang besar dan, seperti tulisan, membutuhkan wawasan
  • Mengutip Hukum Kernighan
    “Debugging dua kali lebih sulit daripada menulis kode.
    Jadi kalau saat menulis Anda berusaha secerdas mungkin, debugging menjadi mustahil.”
    tautan laws-of-software.com