Mengapa software factory gagal: rekayasa harness saja tidak cukup

 (github.com/humanlayer)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Software factory tanpa awak (lights-off), di mana manusia tidak membaca atau menulis kode, memang meningkatkan kecepatan pembuatan, tetapi juga menyingkirkan manusia yang menilai keterpeliharaan jangka panjang sehingga sulit bekerja pada codebase produksi yang kompleks
  • Reinforcement learning untuk model coding mengoptimalkan imbalan yang cepat dan jelas seperti lolos tes, tetapi tidak bisa memberi penalti pada biaya desain buruk yang baru terlihat beberapa bulan kemudian
  • Keluarga SWE-bench menilai perbaikan bug dan pelestarian tes yang ada, tetapi tidak dapat menyaring perubahan yang perlahan menurunkan kualitas kode seperti try/catch sembarangan, type cast, dan shotgun surgery
  • Saat ini manusia tetap harus menangani code review, dan kebutuhan produk, arsitektur sistem, desain program, serta vertical slice perlu ditinjau sebelum implementasi agar rework dan review kode AI skala besar bisa dikurangi
  • Jika kita mengakui keterbatasan model, alih-alih memaksakan otomasi 10–100x, kita bisa mengembangkan 2–3x lebih cepat sambil menjaga kualitas mendekati tingkat manusia; penilaian inti dan membaca kode masih belum bisa dialihdayakan

Janji dan realitas software factory yang berpusat pada loop

  • Dalam persaingan adopsi AI coding ke produksi, makin meluas anggapan bahwa cukup menambah harness dan agent loop
  • Pendekatan ini berangkat dari asumsi bahwa manusia adalah bottleneck, model sudah cukup bagus, dan biaya pembuatan kode nyaris nol sehingga solusinya adalah merilis lebih banyak
  • Tujuannya adalah meraih kecepatan 10–100x, kualitas tinggi, dan menghilangkan code review manusia sekaligus
    • Ada pandangan bahwa dengan menambah linter dan menyuruh bot review PR melakukan pemeriksaan yang agresif, software bisa dibuat aman dengan sendirinya
  • Di lapangan, justru muncul kasus insiden akibat kesalahan coding agent dan codebase yang cepat rusak
  • Laporan Faros AI mengamati perubahan berikut setelah adopsi alat AI coding
    • Jumlah dan panjang komentar review meningkat, tetapi PR yang digabung tanpa review juga bertambah
    • Insiden dan bug per developer meningkat
    • Namun ini lebih merupakan sinyal korelasi, bukan hubungan sebab-akibat yang sudah terverifikasi
  • Sulit menemukan data konklusif yang menunjukkan hasil StrongDM, dan pembaruan publik dari Februari hingga Juni juga tergolong jarang

Codebase kompleks adalah masalah yang berbeda dari vibe coding

  • Side project yang dipakai sedikit orang dan tim yang memelihara sistem enterprise berusia 10 tahun hampir tidak berbagi kendala yang sama
  • Yang dibahas bukan vibe coding itu sendiri, melainkan masalah sulit pada codebase kompleks dan pemeliharaan produksi
  • Dulu brownfield merujuk pada sistem Java lama dan semacamnya, tetapi codebase yang dibuat agent pun bisa mulai sulit diubah setelah sekitar 3–6 bulan karena kecepatan pengembangannya tinggi
  • Jika hasilnya buruk, sering muncul saran bahwa masalahnya ada pada kurangnya token atau teknologi, tetapi masalah intinya bukan pada harness melainkan pada cara model dilatih

Evolusi software factory

  • Dari 1968 hingga sebelum adopsi AI

    • Istilah “software factory” bisa ditelusuri hingga konferensi NATO tahun 1968, tempat ungkapan “software engineering” juga muncul
    • Factory tipikal sekitar tahun 2022 memiliki siklus berikut
      • Manusia memutuskan apa yang akan dibuat dan mencatatnya di pelacak seperti Linear atau Jira
      • Penanggung jawab mengerjakan implementasi dan pengujian
      • Setelah pemeriksaan otomatis dan code review manusia, jika ada masalah proses kembali ke tahap implementasi
      • Setelah deploy ke produksi, sistem dipantau dan insiden serta masukan pengguna dimasukkan lagi ke pelacak
    • Karena implementasi dan review masing-masing memakan waktu berjam-jam atau berhari-hari, tim menaruh perencanaan, usulan arsitektur, dan sprint planning di awal agar ada kesepakatan terlebih dahulu
    • Kesepakatan sebelum implementasi mengurangi rework, dan PR matang yang sudah dekat dengan arah yang diputuskan bisa ditinjau cepat meskipun setiap baris dibaca

  • Factory berbasis agent

    • Ramp, Stripe, WorkOS, Brex, dan lainnya mengatakan factory berbasis agent mengirim sekitar 75% kode mereka
    • Tahap implementasi yang sebelumnya dikerjakan manusia diganti agent, lalu digabung dengan orkestrasi, harness, sandbox, model, dan penggunaan komputer
    • Waktu implementasi turun dari hitungan jam atau hari menjadi menit atau jam, tetapi membaca kode dan pengujian oleh manusia tetap sama sehingga review menjadi bottleneck
    • Untuk mengurangi bottleneck ini, berbagai loop tambahan ditambahkan
      • Agent code review untuk memeriksa style, bug, dan keamanan
      • Regression test yang memeriksa perilaku eksternal lewat browser dan penggunaan komputer
      • Alur yang otomatis menghubungkan insiden ke PR agar penanggung jawab menerima kandidat perbaikan
      • Alur yang langsung menghubungkan umpan balik pengguna ke task queue
    • Pada akhirnya, masalah operasional menyempit menjadi berapa banyak pekerjaan yang bisa dimasukkan ke task queue, dan seberapa cepat hasilnya bisa direview serta dites

  • Factory tanpa awak

    • Factory tanpa awak yang dinamai Dan Shapiro menghapus tahap di mana manusia membaca setiap perubahan
    • Sebagai pengganti code review, investasi diarahkan ke area berikut
      • Pengujian mandiri agent
      • Sandbox dan orkestrasi
      • Review otomatis dan monitoring
      • Rilis bertahap serta pengumpulan sinyal umpan balik pengguna
    • Jika penilaian manusia dihilangkan, yang tersisa hanya berapa banyak tugas yang bisa diberikan ke agent, tetapi pendekatan ini tidak bekerja pada codebase produksi yang kompleks

Kegagalan pendekatan tanpa awak yang diterapkan langsung

  • Sejak Juli 2025, diterapkan pendekatan tanpa awak penuh yang hanya membaca spesifikasi dan tiket lalu menyerahkan pekerjaan kecil hingga menengah ke background agent
  • Beberapa bulan kemudian, muncul masalah kompleks yang tidak bisa dipecahkan bahkan dengan prompt dan workflow tingkat lanjut
    • Konteks yang diperlukan dikumpulkan dan diberikan ke model
    • Agent mencoba mereproduksi masalah dengan sekitar 10 cara
    • Pada akhirnya manusia harus masuk langsung ke codebase yang tidak dibaca selama 3 bulan untuk menemukan akar penyebabnya
  • Selama itu situs sempat down, pengguna mengalami gangguan, dan manusia harus membaca akumulasi kode berkualitas rendah
  • Pada kegagalan pertama, risiko itu dinilai layak demi kecepatan, tetapi sekitar masalah ketiga di bulan November, menulis ulang dari awal justru lebih mudah
    • Salah satu co-founder mengimplementasikan ulang polanya sendiri di VS Code selama 2 minggu

Mengapa model menurunkan kualitas codebase

  • Model saat ini belum mampu menjaga dan meningkatkan kualitas codebase dalam jangka panjang tanpa pengarahan manusia yang signifikan
  • Yang dimaksud dengan keterpeliharaan di sini adalah kemampuan menghindari kondisi shotgun surgery, ketika perubahan di satu bagian merusak bagian lain dan perubahan yang sama harus diterapkan di banyak tempat
  • Model memang sangat maju untuk menyelesaikan masalah satu kali atau membuat situs marketing baru, tetapi kemampuan memperbaiki kualitas kode seiring waktu belum terlihat meningkat secara jelas
  • Karena belum ada benchmark yang baik untuk mengukur kemampuan pemeliharaan, sulit juga membuktikan atau membantah perbedaan ini
  • Bahkan jika model seperti GPT-5.5 xhigh mampu melakukan refactor yang hebat, masalah factory tanpa awak tetap tidak terselesaikan jika manusia masih harus memahami codebase dan memberi instruksi rinci tentang pekerjaan yang dibutuhkan

Claude Code dan reinforcement learning di dalam harness

  • Sebelum Claude Code pun sudah ada agent CLI seperti aider, cline, dan codebuff yang menyediakan alat baca, tulis, edit, pencarian, shell, serta context engineering
  • Agent generasi sebelumnya kadang kurang stabil dalam penggunaan alat, misalnya gagal berulang kali pada edit yang sama
  • Makalah SWE-Agent menganalisis bahwa perbedaan kecil dalam desain alat—misalnya menambahkan nomor baris pada hasil ReadFile atau mengganti Edit dari find/replace menjadi edit berbasis rentang baris—juga memengaruhi performa
  • Salah satu alasan utama Claude Code tumbuh cepat adalah karena Anthropic melakukan reinforcement learning pada model di dalam harness nyata yang benar-benar akan dirilis
    • Bobot model disetel agar memanggil kumpulan alat yang tepat di dalam agent loop
    • Berbeda dari developer eksternal yang harus menyesuaikan definisi alat dan evaluasi dengan preferensi model, pemilik model bisa mengubah model itu sendiri agar cocok dengan alat
  • Tim yang memiliki sekaligus harness dan bobot model berada dalam posisi lebih unggul dibanding tim yang hanya bisa membuat harness tanpa bisa menyetel bobot

Batas imbalan dalam reinforcement learning untuk coding agent

  • Reinforcement learning untuk model coding pada umumnya mengulang prosedur berikut jutaan kali
    1. Membuat execution trace agent untuk menyelesaikan masalah seperti memperbaiki tes
    2. Menilai execution trace itu dengan validator
    3. Memperbarui bobot model agar peluang execution trace yang baik naik dan yang buruk turun
  • Masalahnya, skor evaluasi bisa terlalu satu dimensi

  • Kasus SWE-bench Multilingual

    • SWE-bench Multilingual menggunakan tugas sekitar 15 menit yang diambil dari repositori open source seperti Redis, jq, dan Django
    • Imbalannya bernilai 0 atau 1, dan memeriksa dua kondisi
      • FAIL_TO_PASS: apakah masalah yang diminta sudah diperbaiki
      • PASS_TO_PASS: apakah perilaku yang ada tidak dirusak
    • Tugas fastlane__fastlane-19304 adalah bug yang gagal karena memanggil .empty? pada nil ketika parameter opsional include dan exclude tidak ada
    • Perbaikan manusia yang sebenarnya adalah perubahan dua baris yang mengatur default nil menjadi array kosong
    • Tepat sebelum perbaikan, model hanya menerima commit dasar dan laporan bug, tanpa melihat patch jawaban maupun patch tes untuk penilaian
    • Evaluasi berjalan dalam urutan berikut
      1. Patch buatan model disimpan
      2. Perubahan yang dilakukan model pada file tes dihapus
      3. Patch tes rahasia dari benchmark diterapkan
      4. Tes lama dan tes baru dijalankan bersama
    • Perubahan tes dibuang karena model kadang meloloskan diri dengan menonaktifkan tes yang gagal atau menambahkan mock yang tidak bermakna
    • Benchmark dan validator reinforcement learning tidak identik dan harus dipisahkan, tetapi keduanya menunjukkan keterbatasan struktural dalam menilai kualitas execution trace untuk coding

  • Tidak ada penalti untuk memburuknya desain

    • Selama tes lolos, proses mencapai solusi dan kualitas strukturalnya tidak tercermin dalam skor
    • Membungkus semua hal dengan try/catch atau melakukan type cast longgar yang merusak manfaat type system pun bisa dihitung sebagai jawaban benar
    • Kerusakan keterpeliharaan tidak diberi penalti selama tes lama dan tes baru tetap lolos

Verifikasi kualitas lebih sulit daripada meloloskan tes

  • Tes memberi sinyal sukses/gagal yang jelas dalam hitungan detik, sehingga reinforcement learning bisa diulang jutaan kali
  • Biaya arsitektur yang buruk baru terlihat beberapa minggu, bulan, atau tahun kemudian saat perubahan kecil harus diterapkan di banyak tempat
  • Benchmark saat ini belum bisa menilai biaya desain jangka panjang seperti ini
  • Reinforcement learning dan benchmark memang tidak sama, tetapi jika keterpeliharaan benar-benar sudah dipecahkan dalam reinforcement learning, ada kemungkinan kemampuan itu juga akan tampak dalam desain benchmark
  • Karena itu, peningkatan skor pada benchmark yang ada tidak bisa dijadikan bukti bahwa model sudah tidak lagi mengotori codebase

Upaya baru untuk menilai keterpeliharaan

  • Garis depan kualitas model memang terus membaik, tetapi ekspektasi dan promosi bergerak lebih cepat daripada disiplin teknis
  • Contoh upaya yang mencoba mendekati evaluasi keterpeliharaan antara lain
    • SWE-Marathon: menggunakan tugas sekitar 400 jam seperti mereplikasi seluruh fitur Excel, serta kanal imbalan majemuk alih-alih hanya sukses/gagal tunggal
    • DeepSWE: menggunakan tugas open source besar yang belum benar-benar diimplementasikan di dunia nyata untuk mengurangi kontaminasi data pelatihan, tetapi tidak menyelesaikan masalah kualitas itu sendiri
    • Frontier Code: menilai pekerjaan yang berlangsung di banyak PR, dan memberi penalti bila menulis tes yang bahkan tidak gagal pada kode sebelum patch
      • Validitas tes diperiksa secara deterministik dengan pendekatan mirip mutation testing
      • Juga dijalankan model penilai yang memeriksa diff berdasarkan aturan kualitas kode
  • Ada keterbatasan bahwa jika model penilai benar-benar bisa membedakan kualitas dengan andal, mungkin sejak awal ia juga bisa menghasilkan kode yang baik
  • Reinforcement learning membutuhkan oracle yang cepat dan andal, tetapi untuk keterpeliharaan tidak ada oracle seperti itu
  • Review agent dan token tambahan bisa menangkap kesalahan yang jelas dan menaikkan batas kualitas terendah, tetapi tidak bisa mendorong kualitas tertinggi melampaui tingkat yang berhasil diajarkan ke model melalui reinforcement learning
  • SWE-Marathon, DeepSWE, dan Frontier Code adalah upaya awal untuk menilai keterpeliharaan melampaui sekadar sukses/gagal, tetapi belum pada tingkat yang layak untuk menyerahkan seluruh codebase

Empat tahap untuk memasukkan manusia kembali ke dalam loop

  • Karena penilai kualitas yang andal saat ini masih manusia, code review harus dipulihkan
  • Gunakan perencanaan awal yang sudah dipakai sejak sebelum AI untuk mengurangi kemungkinan review panjang dan rework
  • Leverage AI dimanfaatkan pada empat tahap: kebutuhan produk, arsitektur sistem, desain program, dan vertical slice

  • 1. Tinjauan produk

    • Ubah kalimat pendek atau voice memo panjang menjadi dokumen semi-terstruktur untuk menetapkan apa yang dibuat dan mengapa
    • Mulailah dengan mendefinisikan masalah yang harus dipecahkan dalam bahasa pengguna, lalu tetapkan kriteria untuk menilai keberhasilan setelah rilis
      • Mempercepat waktu penyelesaian workflow
      • Lebih cepat mencapai milestone onboarding
      • Memperbaiki tingkat error atau latensi
      • Mengurangi tiket dukungan tertentu
    • Fokus pada pengalaman pengguna, bukan detail teknis; jika keputusan teknis menghambat keputusan produk, simpan dokumen saat ini lalu lanjut ke tinjauan arsitektur atau prototipe kelayakan
    • Untuk perilaku layar, menyamakan persepsi lewat mockup HTML kasar sering lebih efektif daripada penjelasan panjang
    • Proses ini tidak diterapkan pada revisi copy, script sekali pakai, atau bug dengan langkah reproduksi yang jelas; hal seperti itu langsung diserahkan ke agent
    • Hanya perubahan yang biayanya besar bila agent salah memahami niat yang masuk kategori tinjauan produk
    • Reviewer PR juga meninjau spesifikasi produk dan teknis lebih dulu, dan bisa memakai komentar dokumen asinkron atau GitHub, Notion, dan sebagainya

  • 2. Arsitektur sistem

    • Sepakati cara layanan, endpoint, skema, queue, dan storage berkomunikasi, tanpa turun sampai implementasi internal program
    • Untuk meningkatkan bandwidth komunikasi antara manusia dan agent, gunakan representasi berikut
      • Sequence diagram antara UI, API, layanan, dan storage
      • Kontrak API yang menunjukkan request dan response
      • Model data yang menampilkan tabel baru dan bentuk query
    • Mermaid berguna, tetapi jika dipakai berlebihan bisa memberi rasa percaya diri palsu seolah kesepakatan nyata sudah tercapai
    • Tinjauan arsitektur efektif mencegah kebiasaan buruk model sejak dini, tetapi belum cukup untuk menjamin kode berkualitas tinggi

  • 3. Desain program

    • Sebelum implementasi, putuskan bentuk kode yang berada satu tingkat di bawah arsitektur
      • Tipe
      • Method signature
      • Tata letak program
      • Call stack
    • Visualisasi pseudocode yang ringan lebih mudah dibaca daripada Mermaid yang rumit
    • Untuk perubahan orkestrasi atau control flow, gunakan pohon call stack; jika yang penting adalah bagian yang berubah, terapkan sintaks diff
    • Gunakan diff file tree untuk memeriksa lokasi dan peran file baru maupun file yang diubah
    • Dengan menentukan tipe dan method signature fungsi inti lebih dulu, kemungkinan agent memilih desain internal yang salah bisa dikurangi
    • Model bisa membuat draf awal lalu manusia menyempurnakannya; ini memindahkan keputusan yang biasanya diambil diam-diam saat code review ke titik waktu yang lebih murah

  • 4. Vertical slice

    • Model cenderung menyukai rencana horizontal yang menumpuk dari database migration → service layer → API → frontend
    • Rencana horizontal membuat solusi nyata sulit disentuh dan diverifikasi lewat browser atau curl selama pekerjaan berlangsung
    • Sebelum AI, developer biasanya tidak menulis 500 atau 2.000 baris sekaligus, tetapi memperluas dari tengah ke luar sambil terus memeriksa hasil
      1. Membuat kontrak API dan mock data lalu memeriksanya dengan curl
      2. Mengonsumsi mock data di frontend dan menyempurnakannya di browser
      3. Menghubungkan API ke service layer
      4. Menambahkan database migration dan koneksi repository
      5. Menambahkan business logic
      6. Menambahkan error handling
    • Vertical slice atau tracer bullets memungkinkan setiap tahap diuji dan diperbaiki pada perilaku nyata
    • Di area yang kualitasnya sangat penting, meninjau 100–200 baris per tahap dan mengoreksi arah lebih murah daripada memperbaiki lebih dari 2.000 baris di belakang hari
    • Bahkan model terbaru masih sulit membuat rencana seperti ini tanpa pengarahan manusia, dan juga sulit melakukan generalisasi lintas codebase serta tugas, sehingga manusia harus tetap berada di dalam loop

Cara penerapan menurut ukuran pekerjaan

  • Dengan 30 menit perencanaan awal, review berjam-jam setelah implementasi bisa dihemat
  • Untuk menjaga kualitas mendekati tingkat manusia, manusia perlu terlibat dalam desain produk, arsitektur sistem, desain program, dan vertical slice
  • Tidak semua pekerjaan menjalani seluruh proses
    • Sekitar 40% bisa selesai dalam satu kali generasi atau dengan 1–2 kali umpan balik ringan
    • Untuk pekerjaan menengah, desain produk dan sistem digabung menjadi satu dokumen rencana, dan tahap implementasi tidak dipecah
    • Untuk pekerjaan besar, keempat tahap dijalani semua, tetapi tahap yang tidak cocok—seperti tinjauan produk pada refactor besar-besaran—dilewati
  • Biasanya model diberi 1–3 slice sekaligus, lalu kode yang sedang dikerjakan ditinjau selama proses berjalan
  • Membetulkan struktur internal atau fungsi sejak awal lebih mudah daripada menghasilkan dalam jumlah besar lalu mencari apa yang salah

Bottleneck bukan jumlah PR, melainkan kualitas PR

  • Bottleneck bukan karena PR terlalu banyak, melainkan karena PR buruk terlalu banyak
  • PR yang bersih, mengikuti desain yang diputuskan dan konvensi tim, bisa ditinjau cepat meski semua file dibaca
  • Jika 20% PR saja perlu rework, itu sudah menimbulkan beban kognitif dan emosional bagi pengirim maupun reviewer
  • PR yang dihasilkan AI sekaligus sering memiliki tingkat rework yang mendekati 50%
  • Meski pengirimnya AI, tetap ada orang yang memulai pekerjaan dan harus merapikan atau bertanggung jawab atas hasilnya, jadi biaya rework tidak hilang

Kecepatan pengembangan yang menerima keterbatasan

  • Kendala utamanya saat ini adalah model punya batas yang jelas antara hal yang dikuasai dan yang tidak, dan untuk sementara manusia tetap harus membaca kode
  • Daripada mengejar kecepatan 10–100x dengan asumsi kualitas kode tidak penting, sistem bisa dioptimalkan dalam batasan ini untuk memperoleh kecepatan 2–3x dengan aman
  • Prinsip kerja praktiknya ada empat
    1. Bekerja cukup banyak dengan model untuk menumbuhkan intuisi terhadap keterbatasannya
    2. Mengoptimalkan sistem pengembangan di dalam keterbatasan itu
    3. Menemukan titik dengan leverage tinggi
    4. Benar-benar membaca kode
  • Harness dan loop adalah alat untuk mengurangi kesalahan yang jelas, tetapi tidak bisa menggantikan penilaian keterpeliharaan dan pemikiran desain

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Opini Hacker News

  • Ini disebut masalah niat-implementasi-kualitas
    Pabrik perangkat lunak bisa mengimplementasikan aplikasi, fitur, perbaikan bug, perubahan desain, hingga refactoring hanya dari kebutuhan satu baris, tetapi apakah ia juga bisa menghasilkan secara akurat niat manusia di balik kebutuhan itu dan arah perkembangan produk adalah persoalan lain
    Cara implementasi meledak secara kombinatorial, dan cara yang “benar” yang konsisten dengan sistem, dapat diperluas, mudah dipahami, serta aman mendukung jutaan pengguna bersifat subjektif tergantung orang dan masalahnya. Tes dan bukti pekerjaan dapat meningkatkan sebagian kualitas, tetapi tidak ada loop umpan balik untuk memverifikasi dan mengoreksi kualitas subjektif seperti ini

    • Meski pelanggan berkata “saya ingin X”, bisa jadi ia memang menginginkan X, bisa jadi ia tidak membutuhkan X, atau sebenarnya menginginkan Y tetapi tidak mampu mengungkapkannya. Pelanggan lain mungkin tidak menginginkan X, atau bisa saja menggoyahkan developer tanpa alasan jelas
    • Pabrik perangkat lunak cocok untuk perangkat lunak personal/hobi yang hampir tidak punya pengguna dan pendapatan, serta bugnya bisa diperbaiki dengan satu prompt Claude, atau startup sebelum product-market fit
      Ada juga keseimbangan yang mungkin dicapai tanpa melihat kode sama sekali dan hanya menjadikan keberhasilan kebutuhan sebagai umpan balik, tetapi untuk perangkat lunak lain, masalah niat dan kualitas subjektif belum terselesaikan
    • Asumsi bahwa hanya ada satu cara memindahkan kebutuhan ke implementasi saja sudah tidak benar

  • Tulisan ini memuat hal-hal bagus, tetapi sulit menggeneralisasi eksperimen operasi tanpa awak pada Juli 2025 sebagai batasan agen saat ini
    Kegunaan model melonjak besar sekitar musim gugur 2025 atau musim semi 2026, dan sejak itu saya juga bisa menyerahkan seluruh fitur kepada agen. Tulisan ini menyebut peningkatan model tetapi pada dasarnya mengabaikannya, dan itu tidak sesuai dengan pengalaman saya

    • Baik tulisan maupun situs produknya tampak masih berada di tahun 2025. Khususnya tulisan “konteks panjang bukan jawabannya” terlihat seperti mengekstrapolasi kinerja masa lalu begitu saja ke model terbaru
      Model setelah Opus 4.6 cukup stabil hingga pada 700 ribu–900 ribu token pun penurunan kecerdasan sulit terasa; efisiensi biayanya sangat rendah, tetapi memang berfungsi
    • Minggu lalu saya mendengarkan podcast yang menghadirkan Dex Horthy, dan perusahaannya, Humanlayer, terus mendorong batas agen serta menggunakannya secara aktif
      Karena ia sangat memahami kemampuan model saat ini, jika ia menilai pabrik perangkat lunak tanpa awak kini memungkinkan, ia pasti sedang mencobanya lagi
    • Opus 4.5 jelas merupakan lompatan besar. Penilaian orang yang belum mencoba model-model setelahnya jadi kurang bernilai, meski model belum sempurna, tetap sangat berguna
    • Kalau begitu, akan lebih jelas jika ditulis “kami menerapkannya penuh pada 2025, dan pada 2026 pun secara fundamental tidak ada yang membaik”
      Saya melihat model frontier terbaru pun tidak menangani kehilangan konteks atau shotgun surgery dengan lebih baik. Untuk membantah, jangan sekadar mengabaikan; berikan dasar konkret dan pengalaman penggunaan yang berbeda
    • Mungkin kontroversial, tetapi dalam engineering yang kompleks, saya merasa Opus 4.1 lebih cerdas daripada 4.5
      4.5 lebih cepat dan lebih baik membaca prompt sederhana serta niat implisit, sehingga lebih menguntungkan untuk cepat menarik pengguna baru

  • Saya telah membangun dan mengoperasikan pabrik perangkat lunak saya selama 8 bulan; pengumpulan tugas otomatis dan pengajuan PR memang belum ada, tetapi setelah kebutuhan ditetapkan, sebagian besar proses berjalan sendiri hingga deployment. Setelah evaluasi sistem, selama 4 bulan terakhir saya berhenti melakukan code review
    Alih-alih prompt satu baris, saya memakai proses wawancara untuk lebih dulu menyelesaikan pertanyaan terbuka dan ambiguitas, serta menggunakan tinjauan rencana, quality assurance berbasis browser, tinjauan adversarial, unit test, linter, type checker, post-commit hook, dan pelacakan metode formal sebagai pengaman
    Jika kesalahan berulang muncul, area yang mulai berantakan dapat terdeteksi bahkan tanpa melihat kode. Ketika kebutuhan bertambah dan variabel status saling bertumpuk, saya me-refactor-nya menjadi satu sum type, dan jika rumit, saya membuat model formal dan pelacakan dengan Quint lalu menjalankannya sebagai unit test
    Codebase terdiri dari frontend dan backend yang sudah berusia lebih dari 1 tahun. Agen menyalin pola yang ada apa adanya, jadi prinsip yang jelas penting; saat membagi batas sistem baru, model sekelas Sonnet sering salah menilai, sementara Opus lebih baik

    • Ini bukan pabrik yang sepenuhnya lengkap, tetapi saya juga merasakan hal serupa pada beberapa proyek vibe coding yang matang
      Penurunan kualitas umumnya bisa terdeteksi, dan sejauh ini belum pernah ada kasus saya membuka kode untuk menemukan masalah lalu gagal merapikannya dengan agen. Saya juga belum melihat situasi ketika engineer rata-rata tidak bisa lagi membalikkan pencemaran codebase
    • Yang membuat penasaran bukan pabrik kodenya sendiri, melainkan apa yang dibuat. Perlu hasil yang memvalidasi bahwa produk selain alat coding AI juga bisa dibuat
    • Saya ingin melihat jika Anda memublikasikan konfigurasi dan alur kerja konkret dalam bentuk tulisan panjang atau repositori

  • Entah Anda harus memahami cara kerja codebase, atau tidak perlu memahaminya
    Claude bisa menuliskan kode untuk Anda, tetapi tidak bisa memahaminya untuk menggantikan Anda, dan proses itu tetap berjalan dengan kecepatan manusia. Ada kasus ketika tidak semua hal perlu dipahami, tetapi dibutuhkan pembedaan yang lebih halus, dan fakta ini tidak berubah meskipun Claude menulis kode sempurna

    • Claude dapat menjelajahi codebase spaghetti jauh lebih cepat daripada manusia. Jika pemahaman proyek dialihdayakan ke Claude, justru masalahnya adalah kita bisa terus bekerja bahkan setelah codebase sudah tidak dapat digunakan oleh manusia
    • Alih-alih melihat pemahaman secara biner, kita juga bisa melihatnya sebagai seberapa banyak pemahaman yang dibutuhkan untuk bekerja efektif pada codebase tertentu
      Bahkan sebelum LLM, tidak ada orang yang memahami seluruh codebase besar, tetapi setidaknya mereka umumnya memahami PR yang mereka buat dan area yang mereka tangani
    • Pengalaman saya kebalikannya. Pada dua codebase besar yang sebagian besar saya tulis sendiri dan konsepnya juga saya rancang, saya membuat Claude memahaminya jauh lebih dalam daripada saya, dan sekarang saya meminta Claude menjelaskan hal-hal yang sudah lama saya lupakan

  • Merasa lega karena ini sangat mirip dengan pengalaman saya. Saya teringat pada selera dan daya penilaian yang belakangan sering dibahas
    Kualitas arsitektur, seperti fesyen, mungkin tidak punya jawaban objektif yang benar; setelah menyerahkan nalar dan rasionalitas kepada mesin, manusia mungkin perlu mempelajari estetika
    Ini melelahkan karena kita harus terus menilai kompromi di antara pilihan-pilihan yang hampir setara, tanpa jeda yang dulu diberikan oleh proses implementasi; bahkan pada model sekelas Fable atau GPT-5.6, peninjauan kode tetap diperlukan. Cacat kecil diingat dulu, lalu diperbaiki sekaligus ketika masalah serupa sudah cukup menumpuk
    Agen juga harus memilih: berkolaborasi erat dengan segelintir orang yang sangat unggul, atau menjalankan banyak sub-agen skala besar lalu otomatis memilah yang baik dan buruk. Selera saya adalah tim kecil yang sangat terselaraskan, tetapi waktu yang akan membuktikan apakah itu jawaban yang benar

    • Saat bekerja di Netflix, Jake Nations pernah berkata bahwa “pola buruk bisa langsung dikenali begitu melihatnya, karena saya pernah men-debug-nya pukul 2 pagi”
      Selera adalah intuisi yang lahir dari susah payah setelah membangun software dan meledakkan sendiri semua antipola serta ranjau yang pernah ditemui
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • Orang ini punya riwayat mengakui bahwa dulu ia pernah membuat dan menyebarkan hal tanpa dasar hingga merugikan orang lain, dan kali ini pun sama sekali tidak ada bukti bahwa gagasannya bagus. Perlu ada alasan untuk memercayainya lagi

    • Pada akhirnya ini hanya iklan panjang untuk mempromosikan produknya, Humanlayer

  • Masalah yang paling menonjol saat ini adalah pengalaman pengguna dalam peninjauan PR
    Saya selalu tidak suka tampilan PR GitHub, jadi saya biasa mengunduh branch dan melihat diff dengan $EDITOR; sekarang tidak ada alasan lagi untuk tetap senyaman itu. Linear, yang bahkan bukan perusahaan peninjauan kode, memakai model kecil untuk mengelompokkan file yang berubah berdasarkan topik, menambahkan penjelasan dan urutan kepentingan, lalu menyediakan fitur dasar yang lebih baik daripada GitHub
    Beban kognitif turun drastis tanpa kerja tambahan dari peninjau maupun peminta review, dan fitur lanjutan seperti visualisasi juga sangat mungkin dibuat. Saya penasaran apakah pendekatan ini keliru, atau apakah ada alternatif yang sudah luas dipakai
    https://linear.app/docs/diffs#guides

    • Tim terbaik tidak melakukan peninjauan PR. Mereka mendiskusikan desain dan arsitektur bersama saat perubahan sedang dibuat, mengotomatiskan pemeriksaan kecil seperti linting dan format, serta secara ketat menjaga aturan agar build tidak rusak lewat banyak tes dan pemeriksaan
      Dengan prosedur rollback yang kuat, gerbang PR menjadi proses tidak perlu yang tidak menangkap masalah berguna, dan anggota tim bisa langsung merge
    • Kebijakan yang menjadikan code review sebagai gerbang integrasi itu tidak bermakna. Agen saya bisa menjawab permintaan review dan melakukan review atas nama saya, bahkan bisa melewati kebijakan perusahaan yang mewajibkan review manusia
      Yang perlu ditinjau adalah software yang benar-benar berjalan, dan kita butuh sistem yang bisa segera mendemonstrasikan perubahan. Porsi kode dan spesifikasi akan berkurang, dan produksi software di masa depan akan lebih mirip Replit daripada GitHub
    • Bahkan sebelum agen, peninjauan PR sudah berat; sekarang jauh lebih buruk karena PR yang harus ditinjau juga bertambah
    • Rasanya peran mengelompokkan perubahan file berdasarkan topik dan menjelaskannya itu bukankah semestinya tugas commit?
    • Saya rasa kemampuan LLM untuk menilai tingkat kepentingan atau merangkum kode tidak terlalu bagus
      Saya mencoba pendekatan berbasis Tree-sitter, https://github.com/0x007BA7/codebook, dan menyukainya. Memang belum layak untuk lingkungan produksi, tetapi ada ruang untuk memprodukkan pendekatan serupa

  • Saya punya perasaan ambivalen terhadap pabrik software
    Produk inti berukuran besar sehingga setiap perubahan memerlukan input manusia, tetapi otomatisasi untuk refactoring ringan, penulisan tes, dan perubahan UI berjalan baik. Sebaliknya, dalam eksperimen kecil, meski kode hasilnya tidak istimewa, terlihat kemungkinan untuk diperluas ke depan; saya pikir kita bisa merancang strategi dan arsitektur baru dengan asumsi sejak awal bahwa agenlah yang akan menulisnya
    Eksperimen publik tanpa campur tangan arah sama sekali saya dokumentasikan di https://relentless.works/. Saya juga sedang mengamati agen trading tanpa intervensi; kerugiannya sekitar 3%, tetapi tidak kehilangan seluruh dana dan baru-baru ini juga membuka posisi baru
    Pabrik software tampak mungkin, tetapi membutuhkan konsep baru, perubahan cara berpikir, dan kesabaran menunggu AI

  • Ada masalah mendasar sejak dari pertanyaan apa artinya membuat software
    Jika kita hanya menugaskan tiket GitHub ke agen AI lalu beristirahat, besar kemungkinan abstraksi dan lapisan tidak langsung akan terus menumpuk. Saat coding, muncul sudut pandang seperti “bagaimana kalau pakai Redis di sini?”, “bukankah API sudah memberi data yang dibutuhkan?”, atau “keluarkan pelanggan yang tidak aktif selama setahun terakhir dari laporan”; pada titik tertentu manusia harus menilai hal-hal itu

    • Ini terkait dengan sudut pandang pemrograman adalah pembangunan teori, yang mudah hilang dalam coding oleh agen
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • Sepenuhnya setuju. Alur kerja agen coding dan kumpulan teknik yang banyak dipakai dirancang untuk menarik wawasan dan intuisi manusia dalam proses perencanaan maupun penulisan kode
      Mode perencanaan Claude Code, mattpocock/skills, obra/superpowers, serta alur riset-rencana-implementasi termasuk di dalamnya
    • Kalau yang berpikir seperti itu adalah developer 1% teratas, mungkin benar; tetapi dibandingkan dengan sebagian besar developer yang saya temui selama puluhan tahun, model saat ini lebih unggul daripada manusia kecuali kelompok teratas
    • Mesin akan membuat persis apa yang diminta, bahkan hal yang sebenarnya belum ada. Yang lebih penting daripada otomatisasi penuh adalah kemampuan meminta dengan benar, menggunakan teori informasi, teori pengambilan keputusan, dan teori kreativitas
      Ingatan model tidak terintegrasi seperti manusia yang tidur lalu menanamkannya ke bobot; ini lebih mirip memberikan catatan kepada orang yang tidak mengingat hari kemarin. Tidak mengherankan jika sistem berentropi tinggi menambahkan entropi ke proyek seiring waktu
    • Masalah “API sudah mengembalikan data yang dibutuhkan” sangat besar. Saya beberapa kali melihat model paling canggih menyelesaikan hal yang cukup diubah satu baris dengan data yang sudah ada di klien, tetapi malah meniru pola client-server yang ada dan menyelesaikannya dengan kode serta token yang sangat banyak
      Proyek vibe coding penuh pemborosan seperti ini, tetapi orang yang menulis prompt mungkin tidak menyadarinya. Bagus bahwa alat ini menghemat waktu setiap hari, tetapi implementasi berlebihan adalah masalah serius

  • Membahas pabrik perangkat lunak tanpa awak sambil mengukur produktivitas dengan jumlah PR atau commit itu terasa konyol. Kalau arahnya begitu, unit kode seharusnya sudah disebut bos (bunch of shit)

    • Mereka mengulangi kesalahan lama: mengoptimalkan utilisasi alih-alih throughput keseluruhan. Ini masalah yang sudah dibahas Eli Goldratt sejak 1970-an, tetapi tampaknya masih belum dipelajari
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • Jika ingin menjalankan konsep ini secara serius, metrik semu atau ketidaktahuan terhadap kode tidak bisa ditoleransi. Semakin banyak otomatisasi, standarnya bukan makin rendah, melainkan makin tinggi, dan membutuhkan jauh lebih banyak matematika serta upaya
      Ini lebih mirip pertukaran ala startup ekstrem: menghemat modal, tetapi sebagai gantinya menginvestasikan bertahun-tahun hidup