Lelucon ini berhasil karena sebenarnya bukan cuma lelucon
Sebut saja Meteor development: tujuan diumumkan dulu, halte berubah di tengah jalan, anggaran dianggap akan “diselesaikan nanti”, dan engineering tetap diminta memasang rel saat keretanya katanya sudah “hampir berangkat”.
Meme ini lucu karena pola itu benar-benar terjadi terus-menerus di tim nyata.
Seorang pendiri menjanjikan feature sebelum edge case-nya ada. Tim produk menggambar ulang onboarding flow ketika design sudah bergerak ke depan. Pimpinan melihat AI bisa membuat screen sebelumnya dengan cepat lalu menyimpulkan bahwa “tinggal tambah satu integration lagi” pasti murah. Rute terus berubah; tenggat waktu tidak.
Kabar buruknya, tidak ada pattern arsitektur yang bisa mencegah manusia punya ekspektasi tidak realistis.
Kabar baiknya, ekspektasi tidak realistis itu tidak harus lagi otomatis berubah menjadi engineering paralysis.
Rasa sakit yang sebenarnya bukan cuma soal ekspektasi
Perencanaan yang buruk memang menjengkelkan. Ia membakar waktu, menambah tekanan, dan memaksa negosiasi ulang. Tapi sendirian, itu belum menghancurkan delivery.
Yang benar-benar merusak tim adalah saat setiap perubahan produk yang terlambat berubah menjadi risiko untuk seluruh sistem.
Itulah failure mode klasik dari codebase AI-generated yang bergerak cepat. Version one meluncur terlalu cepat, lalu semua orang mulai menganggap setiap perubahan berikutnya juga seharusnya cepat. Lalu realitas datang:
- auth provider harus diganti
- analytics harus dijadikan optional
- satu deep link path salah
- satu keputusan styling menyebar ke 40 screen
- satu feature “kecil” menjangkau tiga module yang seharusnya tidak saling bersentuhan
Pada titik itu, tim bukan hanya berhadapan dengan ekspektasi tidak realistis. Tim juga terjebak dengan codebase yang tidak bisa menyerap perubahan secara lokal.
Itulah pajak ganda. Masalah organisasional saja sudah berat. Masalah teknis hanya membuatnya makin buruk.
Meteor development lebih dulu merusak codebase yang rapuh
Itulah sebabnya meme ini terasa sangat akurat bagi para engineer.
Kita semua pernah melihat pattern yang sama:
- Rute diumumkan sebelum petanya benar-benar ada.
- Cakupan terus membesar saat implementation sudah berjalan.
- Tenggat waktu yang sama tetap menempel di halaman presentasi.
- Engineering diminta untuk “tinggal menyesuaikan”.
Kalau sistem punya boundaries yang lemah, “menyesuaikan” sebenarnya berarti:
- melakukan reverse engineering atas abstraksi AI-generated yang tak pernah benar-benar dirancang
- mengurai module yang menyentuh implementation internal satu sama lain
- memperbaiki regression di bagian app yang tidak ingin disentuh siapa pun
- menghabiskan seminggu untuk mempertahankan implementation yang salah
Pada tahap itu tim sudah bukan sedang membangun produk. Tim sedang melakukan arkeologi di bawah tekanan tenggat waktu.
Bagian itulah yang tidak perlu lagi kita terima.
Autotomy mengubah failure mode-nya
Autotomy tidak membuat estimasi penuh fantasi menjadi realistis. Ia melakukan sesuatu yang lebih berguna: menjaga sistem tetap replaceable.
Gagasan intinya sederhana. Saat sebuah module salah, terlambat, atau tidak lagi cocok dengan rute yang sekarang, Anda seharusnya bisa memotongnya, menggantinya, lalu tetap melaju.
Untuk itu, ada beberapa hal yang tidak bisa ditawar:
- interface di sekitar service yang mudah berubah seperti auth, analytics, storage, dan notifications
- satu composition root yang menentukan implementation mana yang benar-benar dipakai app
- dependency boundaries yang mencegah screen mengimpor vendor details secara langsung
- contract tests dan deterministic checks untuk memverifikasi perilaku saat module ditukar
- dependency tiers agar tools optional tidak berperilaku seperti infrastruktur kritis saat launch
Kalau semua ini ada, target yang terus bergerak tetap menyebalkan. Tapi ia tidak lagi bersifat eksistensial.
Perubahan provider menjadi replacement di balik interface. Belokan produk menjadi rewrite lokal, bukan refactor seluruh sistem. Module AI-generated yang buruk menjadi sesuatu yang Anda hapus, bukan sesuatu yang Anda jaga mati-matian.
Saat rute berubah, development tetap bisa lanjut
Itulah perubahan praktis yang paling penting.
Tanpa Autotomy, Meteor development terdengar seperti ini:
“Onboarding plan diubah lagi, jadi sekarang kita harus menyentuh auth, profile state, analytics, styling, dan navigation. Beri kami seminggu untuk mencari tahu apa yang akan rusak.”
Dengan Autotomy, nadanya lebih seperti ini:
“Ekspektasinya masih tidak realistis, tetapi perubahannya terlokalisasi. Kita perlu menegosiasikan ulang cakupan atau tanggal, bukan membangun ulang app.”
Itu mode kegagalan yang jauh lebih baik.
Anda mungkin tetap harus mendorong balik janji delivery. Anda mungkin tetap harus membelah launch, memotong satu halte dari rute, atau mengatakan tidak pada branch line menit terakhir. Tapi organisasi engineering tidak perlu menderita dua kali. Masalah manusia tetap masalah manusia. Masalah software tetap bisa dikelola.
Kecepatan AI membuat ini semakin penting, bukan kurang penting
AI coding adalah salah satu alasan Meteor development sekarang lebih sering muncul.
Ketika Cursor atau Claude Code bisa menghasilkan first version sebuah feature dalam hitungan jam, pimpinan mulai menganggap setiap iterasi berikutnya juga seharusnya berjalan seperti draft pertama. Mereka melihat kecepatan di permukaan lalu mengira perubahan murah sampai ke dasar sistem.
Tidak demikian.
AI sangat bagus dalam mengisi implementation. AI tidak bertanggung jawab menjaga sistem tetap aman secara struktural ketika realitas produk berubah. Jika codebase tidak punya boundaries, AI speed hanya membuat Anda tiba lebih cepat ke fragility.
Karena itu saya terus kembali ke poin yang sama: respons yang tepat terhadap AI-native development bukan lebih banyak optimisme. Melainkan lebih banyak replaceability.
Generate cepat. Tegakkan boundaries. Validasi secara deterministik. Hapus module yang buruk saat rute berubah. Jaga radius dampak tetap lokal.
Bagian fantasinya tetap harus Anda tangani sendiri
Tidak ada framework yang akan masuk ke rapat perencanaan dan memberi tahu seseorang bahwa tanggal peluncurannya imajiner.
Autotomy tidak menyelesaikan prioritas. Ia tidak memperbaiki roadmap penuh angan-angan. Ia juga tidak mencegah pemangku kepentingan menggambar stasiun baru di peta saat pembangunan sudah berjalan.
Bagian itu tetap harus Anda tangani sebagai engineer dan sebagai orang dewasa.
Tapi seharusnya itu satu-satunya bagian yang sulit.
Pekerjaan ini seharusnya tidak sekaligus mencakup menghidupkan lagi codebase yang runtuh setiap kali rencananya bergerak.
Kalau Meteor development memang akan tetap menjadi cuaca organisasi yang permanen, tidak masalah. Biarkan ia tetap menjadi meme tentang pengelolaan ekspektasi.
Dengan Autotomy, ia tidak perlu lagi menjadi meme tentang penderitaan engineering.