Minggu lalu, salah satu manajer produk (PM) kami berhasil membangun dan merilis fitur baru. Bukan hanya sekadar dokumen spesifikasi atau tiket yang diajukan, dia langsung membangunnya, mengujinya, dan mengirimkannya ke produksi dalam satu hari!
Beberapa hari sebelumnya, desainer kami menyadari tampilan visual dari plugin IDE kami sudah tidak sesuai dengan sistem desain. Di dunia yang lama, hal ini akan memerlukan tangkapan layar, tiket JIRA, percakapan untuk menjelaskan niat, dan slot sprint. Alih-alih, dia membuka agen, menyesuaikan tata letak sendiri, bereksperimen, dan memperbaiki semuanya secara langsung, lalu melakukan pengiriman dengan hasil perbaikan tersebut. Orang dengan intuisi desain terkuat langsung memperbaiki desain, tanpa memerlukan penerjemah.
Tentunya, semua ini bukan hal baru dalam teori. Vibe coding telah membuka gerbang penciptaan perangkat lunak untuk jutaan orang. Itu adalah aspirasi. Ketika saya berbagi data tentang bagaimana para insinyur kami menggandakan produktivitas, beralih dari pengkodean menjadi validasi, dan menghadirkan desain lebih awal untuk eksperimen yang cepat, kisah ini tetap dalam konteks rekayasa. Namun, yang berubah adalah teori ini menjadi praktik. Mari kita bahas lebih dalam bagaimana ini terjadi.
Hambatan berpindah
Ketika kami mengadopsi pendekatan berbasis AI pada 2025, biaya implementasi pun merosot. Agen-agen mengambil alih pekerjaan yang berulang, pengujian, dan kode penghubung yang selama ini menghabiskan separuh waktu sprint. Waktu siklus pun menyusut dari minggu menjadi hari, dari hari menjadi jam. Para insinyur mulai berpikir kurang dalam hal file dan fungsi, tetapi lebih kepada arsitektur, batasan, dan rencana eksekusi.
Namun, begitu kapasitas rekayasa bukan lagi hambatan, kami menyadari satu hal: Kecepatan keputusan menjadi masalah utama. Semua mekanisme koordinasi yang kami bangun untuk melindungi waktu rekayasa (spesifikasi, tiket, pengalihan, pengelolaan backlog) kini menjadi bagian paling lambat dari sistem. Kami optimasi untuk kendala yang sudah tidak ada.
Ketika membangun lebih murah daripada koordinasi
Kami mulai bertanya pertanyaan yang berbeda: Bagaimana jika orang-orang yang paling dekat dengan niat bisa langsung mengirimkan perangkat lunak?
PM sudah berpikir dalam spesifikasi. Desainer mendefinisikan struktur, tata letak, dan perilaku. Mereka tidak memikirkan dalam hal sintaks. Mereka fokus pada hasil. Ketika biaya untuk mengubah niat menjadi perangkat lunak kerja menurun, peran ini tidak perlu “belajar coding.” Biaya implementasi cukup turun sampai level mereka.
Saya menanyakan kepada salah satu PM kami, Dmitry, tentang perubahan dari sudut pandangnya. Dia bercerita, “Saat agen menghasilkan tugas di Zenflow, ada beberapa menit waktu kosong. Hanya ada keheningan. Saya ingin membangun sebuah game kecil, sesuatu untuk mengisi waktu sambil menunggu.”
Jika kamu pernah menjalankan tim produk, kamu pasti familiar dengan ide-ide seperti ini. Ini tidak mempengaruhi KPI. Sulit untuk dijustifikasi di rapat prioritas. Rencananya menjadi tertunda selamanya. Namun ide ini memberi karakter. Ini membuat produk terasa seperti ada yang memperhatikan detail-detail kecil. Hal-hal inilah yang biasanya dihilangkan dari setiap sesi pengelolaan backlog, tetapi justru menjadi kenangan bagi pengguna.
Dia menyelesaikannya dalam satu hari.
Di masa lalu, ide ini mungkin sudah mati dalam spreadsheet prioritas. Bukan karena jelek, tetapi karena biaya implementasi membuatnya tidak rasional untuk dikejar. Ketika biaya itu turun mendekati nol, perhitungannya pun berubah total.
Mengirim menjadi lebih murah daripada menjelaskan
Seiring semakin banyak orang yang mulai membangun langsung, seluruh lapisan proses secara perlahan menghilang. Lebih sedikit tiket. Lebih sedikit pengalihan. Lebih sedikit percakapan “bisakah kamu menjelaskan maksudmu…” Lebih sedikit momen hilang dalam terjemahan.
Untuk tugas-tugas tertentu, lebih cepat untuk langsung membangun daripada menjelaskan apa yang diinginkan dan menunggu orang lain menyelesaikannya. Pikirkan sejenak. Setiap organisasi perangkat lunak modern dibangun dengan asumsi bahwa implementasi adalah bagian yang mahal. Ketika asumsi itu runtuh, organisasi harus mengikuti perubahan itu.
Contoh sempurna adalah desainer kami yang memperbaiki UI plugin. Alur kerja lama (mengambil tangkapan layar masalah, mengajukan tiket, menjelaskan kesenjangan antara niat dan implementasi, menunggu slot sprint, meninjau hasil, dan meminta penyesuaian) ada sepenuhnya untuk melindungi kapasitas rekayasa. Ketika orang dengan intuisi desain bisa bertindak langsung, semua proses tersebut menghilang. Bukan karena kami menghilangkan proses demi proses, tetapi karena proses itu menyelesaikan masalah yang sudah tidak ada.
Dampak yang berlipat ganda
Ini yang paling mengejutkan: Dampaknya berlipat ganda.
Ketika PM membangun ide mereka sendiri, spesifikasi mereka menjadi lebih tajam, karena mereka sekarang memahami apa yang dibutuhkan agen untuk mengeksekusi dengan baik. Spesifikasi yang lebih tajam menghasilkan output agen yang lebih baik. Hasil yang lebih baik berarti siklus iterasi yang lebih sedikit. Kami melihat peningkatan kecepatan yang terus berlipat ganda dari minggu ke minggu, bukan hanya karena model yang lebih baik, tetapi juga karena orang-orang yang menggunakannya semakin dekat dengan pekerjaan mereka.
Dmitry menjelaskan dengan baik: Loop umpan balik antara niat dan hasil kini dari minggu menjadi menit. Ketika kamu bisa melihat hasil spesifikasimu dengan segera, kamu belajar seberapa tepat sistem ini perlu, dan kamu mulai menyediakannya secara insting.
Ada efek tingkat kedua yang lebih sulit diukur tetapi mustahil untuk dilewatkan: Kepemilikan. Orang-orang berhenti menunggu. Mereka berhenti mengajukan tiket untuk hal-hal yang bisa mereka perbaiki sendiri. “Builder” berhenti menjadi gelar pekerjaan. Ini menjadi perilaku default.
Apa artinya bagi industri
Banyak narasi “semua orang bisa coding” tahun lalu bersifat teoritis atau fokus pada pendiri solo dan tim kecil. Namun, apa yang kami alami berbeda. Kami memiliki sekitar 50 insinyur yang bekerja di basis kode yang kompleks: Berbagai permukaan dan bahasa pemrograman, integrasi perusahaan, seluruh beban sistem produksi yang nyata.
Saya rasa kami bukanlah yang unik. Kami percaya kami berada di fase awal. Dengan setiap generasi model baru, kesenjangan antara siapa yang bisa membangun dan siapa yang tidak semakin menyempit lebih cepat dari yang disadari kebanyakan organisasi. Setiap perusahaan perangkat lunak akan segera menyadari bahwa PM dan desainer mereka menyimpan kapasitas pembangunan yang tidak termanfaatkan, terhalang bukan oleh keterampilan, tetapi oleh biaya implementasi. Ketika biaya ini terus menurun, implikasi organisasi akan sangat mendalam.
Kami memulai dengan niat untuk mempercepat rekayasa perangkat lunak. Apa yang sedang kami bangun adalah sesuatu yang berbeda: Sebuah perusahaan di mana setiap orang bisa mengirimkan hasil kerjanya.
