Rekayasa di Era LLM

• Tulisan yang merangkum 1,5 tahun refleksi di Reindeer tentang bagaimana membangun produk dan organisasi pengembangan di era LLM, dengan semua wawasan berangkat dari pengakuan bahwa konteks manusia (human context) adalah sumber daya yang paling langka
• Volume produksi konten meningkat secara eksplosif, tetapi kecepatan konsumsi manusia tetap sama, dan kesenjangan itu menjadi bottleneck baru — perlu memutus lingkaran setan slop memberi makan slop (slop feeds slop)
• Keputusan struktural seperti pemodelan dan perancangan API tetap menjadi ranah manusia, dan dibutuhkan orang yang bisa mengatakan "tidak" pada keluaran yang dihasilkan LLM
• Karena tidak mungkin mengalahkan LLM hanya dengan code review, perlu membangun lapisan pertahanan berbasis otomasi dan disiplin seperti linter, LLM judges, dan PR kecil
• Kompetensi inti developer bukan lagi pengetahuan teknis yang mendalam, melainkan context switching dan ukuran context window mereka sendiri; developer yang beradaptasi menjadi sangat produktif, sedangkan yang gagal beradaptasi menjadi net negative bagi tim

---

Konteks manusia adalah sumber daya langka

• Fakta yang tidak berubah selama 25 tahun di industri ini — sumber daya termahal adalah konteks manusia; manusia juga seperti LLM, punya context window terbatas dan attention mask
• Perubahan yang terjadi sekarang adalah slop dari LLM mengalir dari segala arah — rasio antara kecepatan produksi dan kecepatan konsumsi manusia menjadi bottleneck baru
• Masalahnya adalah slop memberi makan slop
  • Komentar kode yang digembungkan LLM, penjelasan PR yang bertele-tele, dokumentasi yang memaparkan histori alih-alih hasil
  • LLM berikutnya membaca itu, konteksnya terisi noise, lalu melanjutkan dengan cara yang sama
• Konten teks di dalam organisasi harus terkompresi, dan hanya memuat hal-hal yang tidak jelas dari kode dan perilakunya

Area yang tidak bisa digantikan manusia

• Pemodelan adalah pekerjaan manusia
  • Pekerjaan menerjemahkan CUJ (Critical User Journey) ke dalam alur API, menentukan apa itu komponen, serta di mana concern dan batas masing-masing berada
  • Karena LLM dapat mengeluarkan kode dengan cepat, pemodelan yang buruk juga menyebar dengan cepat, menciptakan dependensi yang bengkok dan tidak bisa diperbaiki belakangan
  • Semakin murah biaya eksekusi, semakin besar porsi keputusan manusia tentang struktur dalam nilai akhir
  • Pemodelan adalah kebenaran nyata organisasi, dan harus hidup di satu tempat yang dapat diakses
• Definisi API membutuhkan disiplin manusia yang ketat
  • LLM cenderung terus menambahkan field yang nyaman untuk task tertentu, padahal tiap field itu mengotori API secara permanen
  • API adalah kontrak publik (public contract), bukan scratch pad — harus ada manusia yang berkata "tidak"

Pertahanan skala besar terhadap slop

• Tidak mungkin mengalahkan LLM dengan human code review — tidak skalabel dan pada akhirnya akan berujung pada kondisi semua orang menutup mata lalu approve
• Reindeer berujung pada lapisan enforcement otomatis
  • Linter: aturan logika absolut seperti dependensi terlarang antar-layanan dan batas arsitektur
  • LLM judges: hal-hal yang sulit dikodekan tetapi bisa diperiksa model, misalnya kontrak implisit
• Namun, ketika menyentuh API atau terjadi perubahan pemodelan, human review sungguhan tetap wajib
• Aturan tingkat keseharian adalah "jangan melempar slop ke satu sama lain"
  • PR kecil, atau stacked PR bila perlu
  • Harus melawan godaan melempar PR slop 2.000 baris dan kemungkinan reviewer menutup mata lalu approve
  • PR adalah satuan dasar perhatian (attention) — jika melampaui context window manusia, PR mungkin disetujui tetapi tidak benar-benar dibaca

Padded rooms — area untuk melepas LLM

• Dengan struktur di atas, kita bisa mengidentifikasi area tempat LLM dapat bergerak bebas, yaitu "padded rooms" (ruang penyangga)
  • Tidak memengaruhi pemodelan dan tidak memiliki dependensi jangka panjang
  • Walau slop muncul, area ini mudah diganti dan tidak menyebar ke seluruh codebase
  • Bisa jadi mencakup sebagian besar kode perusahaan, tetapi tidak load bearing
• Di sinilah juga ada jawaban untuk kustomisasi pelanggan
  • Kustomisasi harus hidup 100% di dalam padded rooms
  • Begitu bocor ke core, core akan retak dan setiap pelanggan baru membawa risiko
  • Padded rooms adalah infrastruktur yang memungkinkan berkata "ya" dengan cepat kepada pelanggan tanpa harus membayar harga di level arsitektur

Pembalikan ekonomi utang teknis

• Pemisahan antara area load bearing dan area padded juga mengubah hubungan dengan utang teknis
• Dulu: saat menemukan masalah pemodelan di tengah development, orang menundanya untuk diri sendiri di masa depan; karena biaya rewrite tinggi, utang sering ditelan selama pekerjaan besar
• Sekarang: biaya rewrite mendekati nol
  • Investasi yang sesungguhnya ternyata bukan pada pengetikan, melainkan pada pemodelan
  • Membuang, memperbaiki pemodelan, lalu menulis ulang itu murah
  • Menunda justru jadi sangat mahal — setiap LLM yang melewati kode yang salah akan mengadopsinya, slop memberi makan slop, sehingga kesalahan pemodelan yang tidak segera diperbaiki akan berubah menjadi utang yang beberapa kali lebih rumit dalam waktu singkat

PM di era ini

• Peran PM berubah — perlu bekerja sangat dekat dengan pihak yang menangani pemodelan agar CUJ tidak rusak saat diterjemahkan menjadi API dan komponen
• Jika PM dan pemodel tidak sinkron
  • hasilnya bisa berupa produk yang secara teknis berjalan tetapi gagal memenuhi CUJ, atau
  • CUJ yang rapi tetapi tidak masuk akal untuk dibangun
• Di Reindeer, PM membangun MVP langsung di repo terpisah
  • Dengan asumsi bahwa kode ini tidak akan pernah menyentuh production
  • Ini memberi kebebasan untuk bergerak cepat bersama LLM dan menunjukkan sesuatu ke pelanggan
  • Hal yang berhasil atau perlu bertemu pelanggan harus melewati proses pemodelan dan development formal
  • Dengan begitu, demo bisa dibangun cepat dan divalidasi ke pelanggan sebelum berinvestasi ke core — keseimbangan antara kecepatan menguji ide dan ketegasan bedah terhadap apa yang boleh masuk ke produk

Infrastruktur yang membebaskan dari loop

• Perbedaan antara memandu agen secara manual dan menjalankan banyak task secara paralel lalu pergi tidur adalah reward function yang baik
  • Tanpanya, LLM akan pergi ke perjalanan yang tidak bisa membawanya kembali
  • Dengannya, model bisa menilai sendiri kapan ia dekat dan kapan ia melenceng
• Dalam development, reward function yang baik diterjemahkan menjadi testing yang baik
  • Termasuk E2E test untuk platform
  • Melepaskan LLM dari kebiasaan buruk bergantung pada mock yang tidak benar-benar menguji apa pun
  • Evals untuk keluaran berbasis LLM
  • LLM judges dengan konteks bersih menjalankan loop review otomatis — agar judge tidak jatuh ke halusinasi yang sama dengan agen yang menulis kode
• Di level organisasi, infrastruktur ini perlu dibagikan
  • Reindeer memiliki repo pusat skill marketplace yang dibagi per kategori dan memuat semua skill internal
  • Didukung otomatis di semua harness seperti Claude Code, Codex, dan juga pi.dev bagi mereka yang sangat unhinged seperti dirinya
  • Developer baru langsung mendapatkan seluruh skill organisasi (termasuk skill yang menjalankan onboarding dan setup)

Developer masa depan

• Kemampuan paling menentukan bagi developer di era ini bukan pengetahuan mendalam, melainkan context switching dan ukuran context window/attention mask mereka sendiri
  • Yang menang adalah orang yang bisa mempertahankan konteks besar, berpindah antar-task tanpa kehilangan fokus, dan mengelola banyak agen secara paralel
  • Kedalaman teknis yang tajam menjadi kurang penting karena LLM dapat mengisinya
• Kemampuan tambahan yang penting adalah kemampuan pemodelan, pemahaman yang baik tentang arsitektur sistem, serta insting tentang apa yang harus diwaspadai pada tahap desain
• Alasan dunia baru ini membelah developer menjadi dua
  • Orang yang beradaptasi menjadi super-productive
  • Orang yang tidak beradaptasi bukan sekadar netral, tetapi net negative bagi tim
  • LLM adalah multiplier — bagi yang tahu cara menggunakannya, ia meningkatkan produktivitas; bagi yang tidak, ia mempercepat kerusakan
  • Dari sisi kompensasi, gaji tipe developer kedua menjadi nol — karena tidak akan ada pekerjaan
• Dengan jumlah orang yang jauh lebih sedikit, kita bisa mengerjakan jauh lebih banyak, tetapi bertumbuh tetap sangat sulit, sehingga harus sangat selektif

Tentang biaya token

• Pertanyaan yang terus muncul: apa yang terjadi jika biaya token naik 5–10x
• Seiring waktu, kekhawatiran ini tidak realistis
  • Di AI ada hukum Moore yang dipercepat, kualitas per dolar terus meningkat
  • Ada cukup banyak open model sehingga kartel tidak mungkin terbentuk
• Alasan token murah adalah karena jika Claudex tiba-tiba menjadi terlalu mahal secara tidak masuk akal, semua orang akan pindah ke Qwen milik semacam neocloud