10 poin oleh flamehaven01 2026-02-24 | 2 komentar | Bagikan ke WhatsApp

Inti keseluruhan

  • Ini bukan “vonis mati bagi sistem PR” itu sendiri, melainkan membahas realitas bahwa di era AI, PR tidak lagi berfungsi sebagai ‘alat penyampai pemahaman’.
  • Masalah utamanya, bahkan sebelum soal kualitas kode, adalah semakin besarnya kondisi di mana konteks, niat, dan pertimbangan yang seharusnya menyertai kode tidak tersampaikan melalui PR.
  • Kesimpulannya, esensi PR tetap valid, tetapi jika cara pengoperasiannya (syarat gate) tidak diubah, PR tidak akan lagi mampu berperan sebagai garis pertahanan.

1. Mengangkat masalah: mengapa PR goyah

  • Jika penyebab kegagalan PR dilihat sebagai “reviewer menjadi malas”, maka masalahnya dipahami secara keliru.
  • Penyebab sebenarnya adalah akumulasi fenomena bahwa PR review tidak lagi menyampaikan pemahaman. Artinya, reviewer (developer) tidak memahami niat dan konteks dari PR tersebut.
  • AI secara drastis menurunkan biaya pembuatan PR, tetapi memperbesar asimetri yang sudah ada (pembuatan cepat, peninjauan lambat).

2. Peran asli PR: bukan prosedur persetujuan kode, melainkan kontrak pemindahan tanggung jawab

  • PR sejak awal bukan sekadar prosedur untuk melihat sintaks kode atau kelulusan tes.
  • Ada struktur berupa janji implisit bahwa penulis “mampu menjelaskan mengapa ini dibuat seperti ini”.
  • Reviewer berperan meninjau bukan hanya kode itu sendiri, tetapi juga penilaian dan niat desain di baliknya.
  • Dengan kata lain, tombol merge bukan sekadar tombol persetujuan kode, tetapi keputusan atas kesepakatan sosial bahwa tim akan bersama-sama menanggung tanggung jawab atas perubahan tersebut.

3. Sebelumnya pun gate sudah rapuh

  • Open source sejak awal merupakan lingkungan yang paling memperlihatkan kerentanan struktur PR.
  • Karena kelelahan mental dan fisik maintainer, kesenjangan konteks, serta keragaman kontributor, PR memang memiliki struktur yang mudah bergeser menjadi persetujuan formalitas.
  • Insiden backdoor xz Utils menunjukkan bukan kegagalan otomatisasi, melainkan cara gate manusia yang kelelahan dapat menjadi permukaan serangan.
    Dengan kata lain, bahkan sebelum AI, gate PR sudah fragile (rapuh), dan sinyal keterbatasannya telah lama menumpuk.
    • Insiden backdoor xz Utils: serangan supply chain open source di mana seorang kontributor yang membangun kepercayaan selama lebih dari 2 tahun menyisipkan backdoor melalui PR.

4. Perubahan yang dibawa AI: ledakan banjir PR dan asimetri review

  • Berkat tool coding AI, kecepatan dan volume pembuatan PR meningkat tajam.
  • Sementara itu, review tetap bergantung pada waktu, fokus, dan pemahaman konteks manusia.
  • Akibatnya, muncul pola berupa lebih banyak kode, PR yang lebih besar, waktu review yang lebih panjang, dan lebih banyak incident.
  • Ini bukan penolakan terhadap “peningkatan produktivitas” itu sendiri, melainkan peringatan bahwa percepatan tanpa governance justru bisa menjadi racun.

5. Masalah yang lebih dalam: kode yang berjalan, tetapi tak seorang pun bisa menjelaskannya

  • Risiko dari kode AI bukan hanya “kode yang langsung rusak”.
  • Bahkan setelah lolos tes dan kompilasi berhasil, masalah yang lebih besar adalah menumpuknya kode yang kosong dari penjelasan mengapa ditulis seperti itu.
  • Ketika gangguan muncul di kemudian hari, tim tidak lagi memperbaiki, melainkan menebak-nebak dan menafsirkan kode tanpa niat yang jelas.
  • Ini lebih berbahaya daripada bug biasa, karena tidak ada jejak pertimbangan desain maupun subjek yang bertanggung jawab.

6. Konsep inti yang tersembunyi: AI mengisi kekosongan informasi dengan sesuatu yang tampak meyakinkan

  • AI cenderung tidak menampakkan hal yang tidak diketahuinya, melainkan mengisi celah dengan kode yang tampak masuk akal.
  • Masalahnya, celah ini (asumsi tersembunyi, batasan yang belum terverifikasi) sulit terlihat pada tahap PR.
  • Karena itu, “kode berjalan/dokumen tampak meyakinkan/check lolos” saja tidak lagi dapat menjamin keamanan.
  • Pada akhirnya, yang perlu diverifikasi di gate PR bukan apakah kode dapat dikompilasi, melainkan apakah reasoning dari perubahan ini (mengapa/apa/dengan batasan apa) benar-benar ada.

7. Apa yang ditunjukkan kasus OpenClaw: skala dan kecepatan yang tak mampu ditangani PR

  • Tulisan ini menyebut OpenClaw sebagai contoh representatif di mana fenomena runtuhnya PR diputar dalam bentuk yang sangat terkonsentrasi.
  • OpenClaw (nama awal Clawdbot) adalah proyek eksperimen/playground yang bersifat personal dan dimulai sekitar November 2025 oleh Peter Steinberger.
  • Dalam waktu singkat (sekitar 10 minggu), proyek ini tumbuh secara eksplosif dan menarik banyak pengguna, kontribusi, serta perhatian eksternal.
  • Dalam proses itu, isu keamanan, skill/kontribusi berbahaya, dan meningkatnya beban review bertumpuk hingga sistem maintenance pribadi/skala kecil sulit menanganinya.
  • Setelah itu (Februari 2026), ia menulis refleksi terkait proyek tersebut dan menyebut bahwa untuk membuatnya lebih aman dibutuhkan lebih banyak struktur, sumber daya, dan akses ke riset terbaru.
  • Lalu ia menyerahkan proyek tersebut dan bergabung dengan OpenAI.
  • Tulisan ini menafsirkan titik itu bukan sebagai kritik personal, melainkan sebagai gambaran jurang antara “kesuksesan prototipe yang hebat” dan “operasi infrastruktur umum yang aman”.
  • Selain itu, intinya bukan satu kesalahan implementasi, melainkan struktur di mana skala, kecepatan, dan keragaman niat kontribusi telah melampaui kemampuan review manusia.
  • Bahkan jika maintainer terus meningkatkan keamanan, kecepatan paparan dan kecepatan pemulihan bukanlah perlombaan yang setara.
  • Artinya, penyebab kegagalannya bukan karena “dibuat dengan buruk”, tetapi karena gate yang sejak awal dirancang untuk model kepercayaan personal/lokal tidak mampu bertahan pada skala global.

8. Makna perubahan pengaturan GitHub: bukan penambahan fitur, melainkan sinyal peringatan

  • GitHub secara resmi mengumumkan penambahan opsi untuk menonaktifkan PR pada 13 Februari 2026.
  • Namun penulis menafsirkan ini bukan sekadar penambahan fitur kenyamanan, melainkan pengakuan diam-diam atas kenyataan bahwa di sebagian repository, PR itu sendiri telah menjadi risiko operasional.
  • Artinya, perlu dilihat sebagai sinyal bahwa bahkan platform pun semakin sulit mempertahankan premis bahwa “PR selalu baik”.

9. Kesimpulan praktis tulisan ini: bukan membuang PR, melainkan mendefinisikan ulang gate

  • Ini bukan argumen untuk menghentikan pengembangan tool kode AI.
  • Justru pertanyaannya bukan “apakah memakai AI”, melainkan “apakah akan memakainya tanpa gate yang benar-benar berfungsi”.
  • Yang dibutuhkan bukan sekadar daftar aturan, melainkan prinsip operasional seperti kemampuan menjelaskan, desain yang didahulukan, penandaan hal-hal yang belum terverifikasi, hak maintainer untuk menolak, dan jaminan keterlacakan.
  • PR yang alasannya tidak bisa ditelusuri bukanlah aset intelektual yang dimiliki tim, melainkan utang yang pada akhirnya akan menguasai tim.

10. Ringkasan satu kalimat

  • Tujuan PR bukan meloloskan kode, melainkan menyerahkan pemahaman dan tanggung jawab secara bersamaan.
  • Pertanyaan kunci di era AI: bukan “apakah kodenya berjalan?”, tetapi “apakah kode ini bisa dijelaskan?”
  • Pertanyaan ini bukan penghambat produktivitas, melainkan syarat minimum untuk menjaga garis pertahanan terakhir perangkat lunak

2 komentar

 
jdjdjd 2026-02-26

Reviewee tinggal klik, sementara reviewer saja yang harus memeras otak; ini sudah melampaui pelimpahan tanggung jawab dan menjadi sarana untuk benar-benar melemparkan pekerjaan ke orang lain.

 
gaorida 2026-02-25

Ini tulisan yang sangat saya setujui.

Selama beberapa bulan terakhir, saya sangat tersiksa melihat kode yang dibuat AI diajukan oleh anggota tim sebagai PR, dan saya sedang mencoba menerapkan banyak cara untuk memperbaikinya.

Selain membatasi cakupan PR seperti yang dibahas dalam artikel, saya juga memikirkan apa yang seharusnya direview.
Saya sedang memikirkan code review yang bukan meninjau kodenya, melainkan meninjau niat atau maksud di baliknya.