Tugas Anda adalah menyerahkan kode yang terbukti berfungsi

• Di lingkungan pengembangan berbantuan AI, semakin banyak kasus engineer yang belum berpengalaman mengirimkan PR besar yang belum tervalidasi
• Tugas inti developer bukan sekadar menulis kode, melainkan menyediakan kode yang terbukti berfungsi
• Untuk itu, dua tahap yaitu pengujian manual dan pengujian otomatis wajib dilakukan
• Coding agent juga harus dikonfigurasi agar memverifikasi sendiri perubahan yang dibuatnya
• Pada akhirnya, tanggung jawab ada pada developer manusia, dan hanya kode yang disertai bukti verifikasi yang benar-benar bernilai

---

Masalah mengirimkan kode yang belum tervalidasi

• Disebutkan adanya kasus engineer junior yang memanfaatkan alat LLM lalu mengirimkan PR besar yang belum diuji dan bergantung pada code review
  • Ini dinilai tidak sopan, tidak efisien, dan merupakan bentuk pengabaian tanggung jawab sebagai developer
• Peran software engineer bukan sekadar menghasilkan kode, tetapi menyediakan kode yang terbukti berfungsi
  • Kode yang belum tervalidasi dianggap sebagai tindakan memindahkan beban ke reviewer

Dua tahap untuk membuktikan bahwa kode berfungsi

• Tahap pertama adalah pengujian manual, yaitu harus memeriksa sendiri bahwa kode benar-benar bekerja dengan semestinya
  • Perlu melalui proses menyiapkan sistem ke kondisi awal, menerapkan perubahan, lalu memverifikasi hasilnya
  • Perintah terminal dan hasil output dapat dilampirkan pada komentar code review atau dibuktikan dengan video rekaman layar
  • Setelah dipastikan berjalan normal, perlu menelusuri masalah lewat pengujian edge case
• Tahap kedua adalah pengujian otomatis, yang ditekankan sebagai prosedur wajib berkat kemajuan alat LLM
  • Pengujian otomatis harus disertakan bersama perubahan, dan jika implementasinya dibalik maka pengujian harus gagal
  • Penulisan pengujian mengikuti prosedur yang sama dengan pengujian manual, dan kemampuan integrasi test harness sangat penting
  • Menganggap pengujian otomatis saja sudah cukup lalu melewatkan pengujian manual disebut sebagai pendekatan yang keliru

Peran dan verifikasi coding agent

• Arus utama di ranah LLM pada 2025 adalah pertumbuhan pesat coding agent, dengan Claude Code dan Codex CLI sebagai contoh representatif
  • Mereka dapat menjalankan kode dan memperbaiki masalah sendiri
• Coding agent juga harus membuktikan perubahannya sendiri, serta melakukan pengujian manual dan otomatis
  • Untuk alat CLI, agent dapat dilatih agar mengeksekusinya langsung, atau diotomatisasi dengan sistem seperti CLIRunner dari Click
  • Untuk perubahan CSS, hasilnya dapat diperiksa dengan mengatur pengambilan screenshot
• Jika proyek sudah memiliki pengujian yang ada, agent akan memperluasnya atau menggunakan ulang polanya
  • Struktur dan kualitas kode pengujian secara langsung memengaruhi kualitas pengujian yang dihasilkan agent
  • Sense estetika terhadap kode pengujian disebut sebagai kemampuan inti yang membedakan engineer senior

Tanggung jawab manusia dan nilai kode

• Komputer tidak bisa dimintai tanggung jawab, dan manusialah yang harus mengambil peran itu
  • Fakta bahwa LLM dapat menghasilkan patch besar bukan lagi hal yang bernilai
• Nilai yang sesungguhnya ada pada penyediaan kode yang terbukti berfungsi
  • Saat mengirim PR, wajib menyertakan bukti bahwa kode benar-benar bekerja dengan benar

[tested]

Vibe Engineering

[ethanhur]

Sangat setuju. Saat ini, tanggung jawab atas kode berbasis PR dialihkan kepada maintainer dan reviewer. Tidak ada kerugian bagi orang yang mengirimkan kode LLM tanpa meninjaunya.

Kalau melihat kontribusi ke codebase Google, mereka tampaknya mengukur hal-hal seperti credit kontributor; saya rasa open source / perusahaan lain juga akan mulai mengadopsi hal seperti ini. Saya merasa kepercayaan akan menjadi aset yang semakin penting.

[roxie]

Oh, jadi Google menggunakan konsep seperti itu.

[GN⁺]

Komentar Hacker News

• Belakangan ini sering terlihat anekdot yang menyedihkan. Insinyur junior yang dipersenjatai alat LLM melempar PR besar yang tidak diuji ke rekan kerja atau maintainer open source, lalu berharap code review akan membereskan sisanya. Yang lebih buruk, perilaku seperti ini bukan hanya dari junior, tetapi juga dari developer senior

  • Kemarin dan hari ini aku persis melakukan hal itu. Tim kami menerima laporan bug dan menilainya sebagai masalah dari vendor eksternal. Namun vendor mengembalikannya dan bilang ini masalah di pihak kami. Jadi aku menyuruh Codex memeriksanya, lalu ia menemukan masalahnya dan menyiapkan PR. Aku tidak meninjau atau mengujinya sendiri, dan menyerahkan verifikasinya ke tim. Proses itu membantu melatih tim agar memanfaatkan LLM sebagai alat kerja
  • Dalam dua hari terakhir, dua anggota tim non-developer menanyakan ke agen AI cara memperbaiki bug mobile, lalu mengunggah jawabannya sebagai isi utama tiket. Pada akhirnya aku harus membaca semuanya dan memahami ulang kebutuhan yang sebenarnya
  • Banyak orang yang menyandang gelar “senior” tetapi bertindak seperti junior. Sepertinya ini terjadi karena sekarang orang yang baru 2 tahun sejak lulus pun sudah disebut senior
  • Developer yang bisa mengabaikan atau menyiasati aturan adalah yang paling berbahaya. Ini mengingatkanku pada para developer 10x yang pernah kutemui. Jika mereka mengabaikan aturan dan hanya memuntahkan fitur, pada akhirnya orang lain yang harus membereskannya
  • Saat code review, aku jadi bertanya-tanya di mana para developer junior. Jika mereka tidak ikut dalam review, sulit bagi mereka untuk merasa bertanggung jawab atas kualitas kode mereka

• Cara membuat PR yang baik berlaku bukan hanya untuk kode buatan AI, tetapi untuk semua kasus. Saat menulis deskripsi PR, aku menyusun secara berurutan bagaimana perilaku saat ini, alasan perubahan, dan apa yang diubah. Aku juga menyertakan cara pengujian, screenshot, bahkan perintah E2E test untuk mengurangi beban reviewer. Ini juga membantu kolaborasi asinkron atau tim dengan perbedaan zona waktu

  • Sebelum meminta review, aku meninjaunya sekali lagi sendiri. Jika typo kecil atau penghapusan log bisa dibereskan lebih dulu, itu bisa menghemat waktu reviewer. Review Copilot juga cukup bagus dalam menangkap hal-hal seperti ini
  • Meski deskripsinya ditulis teliti, sering kali tidak ada yang membacanya. Tetap saja aku terus menulisnya karena itu bagian dari rasa tanggung jawabku
  • Entah PR itu dibantu AI atau tidak, harus ada bukti pengujian dan verifikasi
  • Dulu aku menulis penjelasan panjang, tetapi kemudian sadar tidak ada yang membacanya. Merangkum poin inti dengan bullet point ternyata lebih efektif
  • Template PR tim kami mencakup nomor tiket, deskripsi permintaan, status saat ini, status setelah perubahan, dan bahkan ‘mood gif’

• Hakikat seorang engineer adalah memahami requirement, mengubahnya menjadi alur logis, menyeimbangkan trade-off, dan bertanggung jawab atas hasilnya. Pembuatan kode atau pengiriman PR acak hanyalah gejala dari hilangnya dasar-dasar ini. Agen coding justru menjadi pemicu untuk kembali mengingatkan hakikat engineering

  • Tulisan ini menunjukkan kasus di mana 1 baris kode menyebabkan kerugian 60 juta dolar. PR 10 ribu baris buatan AI tanpa pemahaman atas kodenya adalah bencana yang menunggu terjadi
  • Secara realistis, perusahaan lebih mementingkan pemasaran dan profitabilitas daripada kualitas. Produk berlabel ‘premium’ lebih laku daripada produk berkualitas tinggi. Pada akhirnya, yang diprioritaskan bukan engineering, tetapi ‘yang bisa dijual’
  • Namun masalahnya, jika organisasi menekan dengan pola “pakai AI dan selesaikan fitur dalam 3 hari, kalau tidak wawancara dengan HR”, akan sulit mempertahankan prinsip engineering yang ideal

• Testing itu perlu, tetapi tidak cukup. Kode juga harus divalidasi secara logis. Testing hanya membuktikan bahwa ia berjalan normal pada input dan lingkungan tertentu

  • Aku juga setuju. Kode yang berjalan baik pun tetap bisa saja buruk
  • Daripada “prove”, istilah “demonstrate” lebih tepat. Testing hanyalah bukti untuk kasus tertentu
  • Aku tidak sekadar percaya pada testing; aku juga mencoba merusak aplikasinya sendiri dengan berbagai cara. Dalam proses itu, kodenya pun jadi bisa diperbaiki menjadi lebih baik
  • Karena sebagian besar kode tidak bisa dibuktikan secara formal, pendekatan seperti property-based testing tampaknya berguna
  • Mencapai 100% test coverage pun tidak ada artinya jika kodenya sendiri tidak kokoh

• Aku tidak mewajibkan testing. Aku melakukannya hanya karena ingin melihat kodenya benar-benar bekerja. Kalau melihat kode berjalan tidak membuatmu bersemangat, mungkin pekerjaan ini bukan untukmu

• Aku mendengar cerita bahwa berkat LLM, junior melempar PR raksasa, tetapi di organisasi kami hal seperti itu belum ada

  • Memang bukan PR raksasa, tetapi kode buatan LLM yang tidak dipahami developer cukup sering kulihat
  • Di organisasi kami juga ada kasus seperti itu. Masalahnya seperti berikut
    • Agen membatalkan feedback sebelumnya
    • Tidak mengikuti standar codebase
    • Menemukan kembali solusi yang sudah ada
    • Menanggapi feedback PR dengan output agen
    • Perubahan yang seharusnya cukup 10~20 baris malah diajukan sebagai PR 50 ribu baris
    • Kurang testing, penanganan error buruk
  • Orang-orang yang sejak dulu mengirim PR berkualitas rendah kini hanya mengirimkannya lebih cepat berkat LLM
  • Jika melihat WireGuard Android PR #82, #80, jawaban AI yang disalin-tempel masih tertinggal begitu saja. Jika membuka tab “files changed”, hasilnya membingungkan
  • Temanku bekerja di startup beranggotakan 11 orang, dan CTO-nya langsung push 10 ribu baris kode ke main pada pukul 3 pagi. Itu mungkin oke di tahap eksplorasi, tetapi di tahap stabilisasi itu adalah risiko yang mengerikan

• Aku tidak setuju dengan pernyataan “tugasmu adalah menyerahkan kode dalam keadaan terbukti”. Pekerjaan yang sebenarnya adalah menyelesaikan masalah bisnis. Tentu dalam kebanyakan kasus itu berujung pada kode, tetapi pembedaan ini penting

  • Tetapi membuktikan ketepatan kode juga merupakan bagian dari penyelesaian masalah bisnis. Itu bukan pekerjaan yang terpisah
  • Kamu tidak bisa menyelesaikan masalah bisnis jika menyerahkan kode yang tidak memenuhi requirement
  • Yang penting adalah menyelesaikan masalah tanpa menciptakan masalah baru. Karena itu keamanan dan keandalan diperlukan
  • Mungkin karena pengalamanku masih singkat, aku tidak mengerti bagaimana mungkin masalah bisa diselesaikan dengan kode yang belum diverifikasi
  • Pada akhirnya semua pekerjaan bertujuan menyelesaikan masalah. Hanya saja kita melakukannya melalui komputer

• Di tempat kerja lamaku, aku bekerja di produsen hardware berkualitas tinggi dari Jepang, dan jika departemen QA menemukan bug, peluncuran produk akan dihentikan. Karena itu tiap departemen pengembang membentuk tim QC sendiri untuk memperkuat pengujian sebelumnya. Hasilnya, software diverifikasi dengan sangat menyeluruh

  • Aku penasaran apa arti “get dinged”. Struktur seperti ini justru bisa membuat orang takut melakukan perubahan

• Belakangan ini hakikat pekerjaan berubah menjadi menutup tiket. Kualitas kode tidak tercatat dalam statistik, jadi dianggap tidak penting. Aku tidak mau ikut dalam sistem seperti ini. Sekarang craftsmanship sudah hilang, dan semua orang hanya menginginkan triplek murah dan lem

  • Saat LLM diadopsi penuh dan semua orang diharapkan memakainya, software engineering tidak lagi menjadi disiplin engineering yang serius
  • Ada juga yang menanggapi kritik terhadap sikap seperti itu dengan bertanya, “Kalau begitu Anda hidup dari subsidi pemerintah?”

• Masalahnya terletak pada arti “kode yang terbukti”. Ada juga kasus orang menempelkan test buatan LLM lalu mengajukan PR besar. Aku sendiri melakukan vibe coding untuk proyek pribadi, tetapi melakukannya di level tim adalah kebiasaan buruk. Alasan kita mempekerjakan engineer adalah untuk membeli keahlian mereka

  • Karena itu aku menekankan manual testing. Hanya dengan menunjukkan perilaku nyata lewat screenshot atau video pun, kita sudah bisa memberi rasa percaya yang besar