Ouroboros Optimasi: Developer dan Jebakan Efisiensi

Di suatu sore di Warsaw, seorang engineer menyadari bahwa pipeline riset AI-nya telah membakar seluruh kuota langganan Claude Max dalam waktu tiga puluh menit. Tujuannya sederhana: memahami ekonomi token AI dan menemukan cara menghematnya. Ironinya, dia harus mengoptimalkan alat optimasi sebelum alat itu bisa mengoptimalkan apa pun. Ini bukan sekadar anekdot lucu dari tim Quesma. Ini adalah manifestasi dari sebuah pola yang jauh lebih dalam dalam psikologi developer modern: kecenderungan untuk terus-menerus memperbaiki alat perbaikan, sebuah ouroboros yang memakan ekornya sendiri.

Fenomena ini punya nama yang lebih familiar bagi kita: yak shaving dan bikeshedding. Kita tidak sekadar menggunakan alat. Kita terobsesi untuk mengoptimalkannya hingga titik di mana optimasi itu sendiri menjadi beban yang lebih berat daripada tugas asli yang ingin diselesaikan.

Dari Bikeshedding hingga Token Burning

Poul-Henning Kamp, kolumnis legendaris di ACM Queue, baru-baru ini menutup kolom "Bikeshed" yang telah berjalan hampir dua dekade. Dalam tulisan perpisahannya, ia mencermati bagaimana komunitas open source dan software engineering secara kolektif terus-menerus memperdebatkan hal-hal remeh-temeh sementara isu struktural yang fundamental dibiarkan membusuk. Fenomena bikeshedding ini, yang ia sebut sebagai gejala kronis industri kita, sebenarnya lebih dekat dengan keseharian developer daripada yang kita sadari.

Kamp menunjukkan bahwa industri teknologi beroperasi dalam siklus gelembung yang mudah diprediksi. Setiap kali muncul alat baru, kita mengalami fase euforia: ini akan mengubah segalanya. Lalu datang fase koreksi, di mana kita menyadari bahwa sebagian besar manfaatnya adalah ilusi. Ia mencatat pola berulang dengan alat kualitas kode, dari lint hingga static analysis Clang, dan kini LLM-assisted code review: hari pertama penuh kegembiraan, minggu kedua mulai meragukan, dan tak lama kemudian kita menyadari bahwa daftar bug terburuk yang ditemukan sudah tidak banyak lagi.

Tapi bukankah AI code review berbeda? Bukankah model-model terbaru lebih cerdas? Kamp menawarkan sudut pandang yang menenangkan sekaligus menggelisahkan: LLM memang mampu mengeksplorasi pohon kemungkinan lebih lebar dan dalam daripada otak manusia, mirip dengan komputer bermain catur. Namun kemampuan itu tidak serta-merta berarti ekonomi di baliknya berkelanjutan. Artifak hasil training mungkin muat di saku, tetapi biaya training-nya mencapai ratusan juta dolar. Gelembung ini, seperti gelembung sebelumnya, akan pecah. Dan yang tersisa hanyalah kita, dengan dekorasi bikeshed yang baru saja kita cat ulang.

Arsitektur Kerja Sama yang Memakan Diri

Tim Quesma menggambarkan bagaimana mereka akhirnya membangun sebuah harness yang mengorkestrasikan Claude, Codex, dan Antigravity sebagai subagent. Solusi ini memungkinkan riset berjalan sepuluh kali lebih lama tanpa biaya tambahan. Tetapi berhenti sejenak dan renungkan: untuk menghemat token, mereka harus terlebih dahulu membangun sistem orkestrasi multi-model dengan shared memory, fallback otomatis, dan aturan verifikasi silang.

Diagram: Arsitektur multi-agent yang dibangun untuk mengoptimalkan riset tentang penghematan token. Sumber: Quesma.

Ini adalah metafora yang sempurna. Kita membangun infrastruktur kompleks untuk mengoptimalkan infrastruktur yang sudah ada. Kita menulis skrip otomasi yang membutuhkan waktu lebih lama daripada tugas yang diootomasi. Kita mempelajari alat produktivitas baru yang menguras lebih banyak attention daripada alat lama yang digantikannya. Setiap lapisan optimasi menambahkan kompleksitas tersembunyi yang pada akhirnya harus dioptimalkan lagi.

Mengapa Kita Terus Melakukan Ini?

Ada beberapa kekuatan psikologis yang bekerja secara bersamaan, menciptakan loop yang hampir mustahil diputus.

Biaya Tenggelam dan Obsesi Konfigurasi

Ketika kita sudah menghabiskan empat jam mengkonfigurasi terminal atau AI agent, ada tekanan irasional untuk melanjutkan. Sudah terlalu banyak waktu yang diinvestasikan untuk berhenti sekarang. Ini adalah sunk cost fallacy dalam wujudnya yang paling halus. Kita bukan lagi mengoptimalkan alat untuk pekerjaan; kita memperjuangkan keputusan awal kita untuk menggunakan alat tersebut. Ego teknis kita terikat pada hasilnya.

Ilusi Kontrol

Di dunia yang semakin kompleks dan tidak pasti, mengutak-atik konfigurasi memberikan perasaan kontrol yang instan. Mengubah threshold compaction atau men-tuning hyperparameter memberikan dopamine hit yang cepat. Padahal, seperti yang didokumentasikan dalam riset tokenomics, context compaction yang seharusnya menghemat biaya justru bisa melipatgandakan tagihan ketika model terus-menerus harus merangkum ulang history dan membaca ulang file yang ter-evict. Dalam satu kasus yang terdokumentasi, perubahan threshold compaction menyebabkan penggunaan token melonjak dari 89 juta menjadi 160-185 juta untuk tugas yang identik.

Novelty Bias Industri

Industri teknologi dibangun di atas novelty bias. Kita dibombardir dengan rilis baru setiap minggu: model AI terbaru, framework tercepat, editor paling minimalis. Otak kita secara evolusioner diprogram untuk mencari stimulus baru, dan industri tech dengan cermat memanfaatkan ini. Hasilnya: kita terus-menerus researching how to save tokens sambil membakar tokens lebih banyak dari sebelumnya. Kita menjadi hamba dari treadmill inovasi yang kita sendiri biayai.

Harga Tersembunyi yang Tidak Pernah Diukur

Biaya terbesar dari ouroboros optimasi bukanlah uang. Biaya terbesarnya adalah attention dan cognitive overhead.

Setiap kali Anda beralih dari editor utama ke eksperimen konfigurasi baru, Anda membayar context switching tax. Setiap kali Anda menulis skrip otomasi untuk tugas yang sebenarnya bisa diselesaikan dalam lima menit manual, Anda menukar deep work dengan shallow tinkering. Dan yang paling berbahaya: setiap kali Anda mulai meragukan stack yang sudah berjalan baik hanya karena ada rilis lebih cepat lima belas persen, Anda merusak kepercayaan diri teknis yang sudah Anda bangun selama bertahun-tahun.

Tim Quesma menemukan bahwa harness bisa membuat perbedaan 66 kali lipat dalam konsumsi token untuk model yang sama. Artinya, masalahnya seringkali bukan pada alatnya, melainkan pada cara kita menggunakan alat itu. Tetapi alih-alih memperlambat dan mengoptimalkan harness, reaksi default kita adalah: ganti model, ganti tool, ganti stack. Kita mencari silver bullet di luar, sementara masalahnya ada di dalam cara kita bekerja.

Menerima Ketidakefisienan sebagai Keberanian

Jalan keluarnya bukanlah anti-teknologi atau kemunduran ke cara kerja tahun sembilan puluhan. Jalan keluarnya adalah selective inefficiency: kemampuan untuk dengan sengaja membiarkan beberapa bagian dari workflow tetap cukup baik agar kita bisa menyimpan energi kognitif untuk masalah yang benar-benar penting.

Ini adalah seni yang dilupakan. Konsep worse is better yang dipopulerkan oleh Richard Gabriel bukanlah pengecutan teknis; itu adalah pengakuan bahwa trade-off ada, dan bahwa kesederhanaan yang diawasi dengan baik seringkali mengalahkan optimalitas yang rapuh. Kamp, setelah dua dekade mengamati siklus ini, memilih untuk mengakhiri kolomnya dengan mempertanyakan masa depan FOSS sendiri. Itu adalah bentuk keberanian intelektual: mengakhiri sesuatu yang sudah tidak lagi konstruktif.

Mungkin kita juga perlu belajar see ourselves out dari ruang-ruang optimasi tanpa ujung. Biarkan konfigurasi tetap standar selama seminggu. Gunakan AI agent tanpa men-tuning prompt template selama sebulan. Tulis kode secara manual untuk tugas kecil tanpa memikirkan reusability. Rasakan ketidaknyamanan itu. Lalu sadari bahwa dunia tidak runtuh. Bahkan, Anda mungkin menyelesaikan lebih banyak pekerjaan bermakna.

Refleksi Akhir

Teknologi adalah amplifikasi. Ia memperkuat niat baik menjadi hasil luar biasa, tetapi ia juga memperkuat obsesi menjadi spiral tanpa akhir. Ouroboros optimasi bukanlah musuh yang bisa dikalahkan dengan alat yang lebih baik; ia adalah musuh yang bisa dikalahkan hanya dengan kesadaran diri dan keberanian untuk berkata: cukup. Ini sudah cukup baik.

Jadi, pertanyaan yang ingin saya tinggalkan: di area mana dalam pekerjaan Anda saat ini yang sebenarnya sudah cukup baik, tetapi Anda terus-menerus merasa perlu dioptimalkan lagi? Dan siapa yang sebenarnya Anda coba tolong dengan optimasi itu: diri Anda, atau hanya ego teknis Anda?