Sudut pandang seorang frontend engineer tentang alur kerja product-engineering baru di era AI
Angka yang Seharusnya Tidak Masuk Akal
12 hari. Dua orang: seorang product designer dan seorang frontend engineer. Satu pembangunan ulang platform yang lengkap.
Bukan sekadar prototipe. Bukan MVP. Penggantian penuh sebuah aplikasi produksi, yang berpuncak pada satu PR yang menghapus 26.000 baris kode lama. Setiap halaman, setiap route, setiap interaksi, dibangun ulang dari nol dan dirilis ke pengguna nyata.
Dalam alur kerja pengembangan produk tradisional mana pun, lini masa ini terdengar mustahil. Proyek dengan cakupan sebesar ini biasanya memakan waktu berbulan-bulan: berminggu-minggu eksplorasi desain di Figma, beberapa putaran review pemangku kepentingan, ritual serah terima, perencanaan sprint, lalu proses lambat penggarapan implementasi yang pixel-perfect. Yang terjadi di sini secara fundamental berbeda. Bukan karena kami bekerja lebih keras, tetapi karena cara kami bekerja sama berubah.
Ini adalah kisah tentang bagaimana kami merilis platform Zero di VM0, dan apa yang kisah itu ajarkan kepada saya tentang masa depan kolaborasi product-engineering.
Hambatan Lama
Setiap frontend engineer tahu alur pipeline tradisional:
- Designer membuat mockup di Figma
- Review desain, iterasi, persetujuan
- Spesifikasi beranotasi dengan spacing, warna, breakpoint
- Engineer menerjemahkan spesifikasi visual menjadi kode
- Bolak-balik: "Bisa geser ini 4px ke kiri?"
- Akhirnya, menyambungkan lapisan API
- Pengujian integrasi, lebih banyak bolak-balik
Hambatannya tidak pernah ada pada satu langkah pun. Hambatannya ada di celah antarlangkah: penantian, kehilangan makna saat penerjemahan, perpindahan konteks. Model mental seorang designer tentang sebuah interaksi, begitu diratakan menjadi frame Figma statis dan dianotasi dengan redline, tiba di meja engineer dalam keadaan sudah merosot kualitasnya. Engineer membangun ulang versi dari apa yang dibayangkan designer, tetapi mau tak mau hasilnya adalah salinan yang berkurang kualitasnya.
Kami sudah terlalu terbiasa dengan gesekan ini sampai berhenti menyadarinya. Itu sekadar "begitulah cara kerjanya".
Eksperimen: Bagaimana Jika Designer yang Merilis Kode?
Pada 5 Maret 2026, Ming, product designer kami, membuka PR #3685: feat(platform): add zero app with shell, pages and polish. PR itu menambahkan 4.146 baris kode React yang berfungsi.
Bukan file Figma. Bukan ekspor design token. Sebuah aplikasi yang berjalan.
PR itu berisi app shell yang lengkap: navigasi sidebar, struktur routing, kerangka halaman untuk chat, schedule, activity, manajemen tim, dan settings, semuanya bergaya sesuai design system kami, semuanya ter-render di browser. Datanya masih mock, tetapi UI-nya nyata. Anda bisa npm run dev dan mengeklik setiap halaman.
Ming tidak menulis kode ini dari nol dalam pengertian tradisional. Ia menggunakan tool coding AI (mula-mula Cursor, kemudian Claude Code) untuk menerjemahkan visi desainnya langsung menjadi komponen React. AI menangani penerjemahan mekanis (struktur JSX, properti CSS, komposisi komponen), sementara Ming mengarahkan keputusan visual dan interaksi yang tidak bisa diambil oleh AI mana pun: ritme tata letak, hierarki informasi, nuansa transisi.
Selama empat hari berikutnya, tiga PR lagi mendarat:
| Tanggal | PR | Yang Dirilis Ming |
|---|---|---|
| 5 Mar | #3685 | App shell, sidebar, semua kerangka halaman (+4.146 baris) |
| 6 Mar | #3825 | Halaman schedule, pemolesan UI (+2.650 baris) |
| 9 Mar | #3993 | Alur onboarding, dialog konfigurasi Slack (+1.146 baris) |
| 9 Mar | #4050 | Halaman about, kartu navigasi mengambang |
Pada 9 Maret, seluruh permukaan frontend platform baru kami sudah ada dalam bentuk kode yang berjalan. Setiap halaman yang nantinya Anda lihat di produksi sudah bisa diklik di lingkungan dev. Hanya saja, semua itu belum melakukan apa pun yang nyata.
Di situlah peran saya masuk.
Tugas Baru Saya: Menyuntikkan Jiwa
Ketika saya membuka basis kode pada 9 Maret, saya tidak menghadapi tantangan biasa berupa menerjemahkan desain datar menjadi kode. Kodenya sudah ada di sana. Tugas saya adalah mengganti setiap mock dengan kenyataan, menyambungkan setiap permukaan yang dirancang dengan indah ke backend yang hidup dan bernapas di bawahnya.
Ini mengubah pekerjaan saya secara fundamental. Alih-alih memikirkan pixel, saya memikirkan aliran data. Alih-alih bertanya "apakah ini sesuai mockup?", saya bertanya "panggilan API apa yang dibutuhkan halaman ini, dan apa yang terjadi ketika gagal?"
Beginilah minggu pertama saya:
Hari 1 (9 Maret): Auth dan pergantian org. Saya menyambungkan shell buatan Ming ke autentikasi Clerk, menambahkan redirect lintas domain, dan membuat pengalih org benar-benar mengganti org. Dua PR, keduanya di-merge pada hari yang sama.
Hari 2 (10 Maret): Connector dan schedule. Saya mengganti grid connector mock dengan data API nyata, menyambungkan tab schedule ke cron job sungguhan, dan menghubungkan editor instruksi ke backend. Empat PR.
Hari 3 (11 Maret): Hari penyambungan besar. Halaman team mendapat data subagent nyata (+3.271 baris). Halaman activity mendapat log nyata. Dan mahkotanya: halaman chat tersambung ke pipeline agent run yang sebenarnya, menggantikan ~1.200 baris kode demo dengan antarmuka percakapan AI yang berfungsi. Pada hari yang sama, saya memperkenalkan FeatureSwitchKey.Zero, sebuah feature flag yang memungkinkan kami menjalankan platform lama dan baru berdampingan.
Hari 4-5 (12-13 Maret): Lampiran file, manajemen sesi, chat multi-agent, persistensi settings. Setiap halaman yang Ming bangun kini melakukan pekerjaan nyata.
Ritmenya nyaris seperti musik. Setiap pagi saya memilih satu halaman dari scaffold Ming, mempelajari struktur komponennya, mengidentifikasi data apa yang diharapkannya, membangun integrasi API, menangani status error, lalu push. Menjelang sore, satu halaman lagi sudah hidup.
Feature Switch: Dunia Paralel
Feature flag FeatureSwitchKey.Zero layak disebut tersendiri, karena inilah yang membuat migrasi ini aman, bukan sembrono.
Sejak 11 Maret dan seterusnya, aplikasi produksi kami menjalankan dua UI lengkap secara paralel. Pengguna di sistem lama melihat route lama. Penguji internal di sistem baru melihat Zero. Setiap halaman yang saya sambungkan bisa diuji dalam konteks produksi tanpa membahayakan alur kerja seorang pengguna pun.
Ini bukan hal revolusioner. Feature flag adalah praktik standar. Tetapi kombinasi feature flag dengan alur kerja design-as-code menciptakan sesuatu yang istimewa: kami bisa memvalidasi seluruh UX platform baru (karena Ming telah membangun UI yang lengkap dan bisa dijelajahi) sambil secara bertahap membuat setiap halaman berfungsi (karena saya menyambungkannya satu per satu). Kapan pun, jika ada yang salah, kami bisa menjepret sakelar itu kembali.
Tidak ada yang salah.
Hari ke-12: Sakelar Besar
Pada 17 Maret, saya membuka PR #5095: refactor: remove all non-zero platform pages and feature flag.
Diff-nya: +456 baris, -26.041 baris.
Sebelum: VM0 Platform lama. Tabel, run ID, dan data sesi mentah.
Sesudah: Zero yang baru. Ruang kerja AI percakapan dengan agent yang dipin dan kartu use case.
Dalam satu merge, setiap route lama dihapus. Feature flag dihilangkan. Zero bukan lagi sebuah opsi; ia satu-satunya mode. PR lanjutan (#5155) menanggalkan prefiks URL /zero sepenuhnya: yang tadinya /zero/chat menjadi cukup /chat.
Mengapa saya merasa yakin melakukan pemotongan ini? Karena:
- Setiap halaman telah berjalan di bawah feature flag selama setidaknya 5 hari
- Setiap integrasi API telah diuji terhadap data produksi
- Sistem lama dan baru berbagi backend yang sama. Ini adalah pertukaran frontend, bukan migrasi data
- Kami memiliki pengguna nyata di sistem baru yang memberi umpan balik sepanjang prosesnya
26.000 baris itu tidak dihapus dengan rasa cemas. Mereka dihapus dengan rasa lega.
Pola yang Berulang
Yang paling mengejutkan saya bukanlah migrasinya. Melainkan bahwa alur kerja yang kami temukan menjadi mode default kami untuk setiap fitur yang menyusul. Ming membangun shell UI dengan bantuan AI, saya menyambungkan logika dan memperluas arsitektur. Pola design-as-code yang sama, dalam skala fitur:
Sistem Permission (19 Maret → 7 April)
Ming merilis PR #5467, sebuah UI drawer permission dengan komponen Sheet dan kontrol toggle. Tiga commit, UI yang rapi.
Saya menambahkan 13 commit ke PR yang sama: migrasi database untuk firewall_access_requests, endpoint API, tes integrasi, perbaikan lint. Lalu selama dua minggu berikutnya, 10+ PR lanjutan membangun lapisan permission secara penuh: desain ulang kartu persetujuan, notifikasi Slack untuk permintaan akses, perintah CLI doctor untuk mendiagnosis masalah permission, dan akhirnya mengganti nama seluruh konsep dari "firewall" menjadi "permission" di seluruh basis kode.
Drawer Ming adalah benihnya. Sistem permission adalah pohonnya.
Sistem Schedule (23 Maret → 13 April)
Ming merancang route detail schedule dan UX kalender (#6155). Tiga commit pekerjaan UI yang rapi.
Saya menambahkan 14 commit: pengeditan deskripsi dengan auto-generation, pemilihan channel Slack untuk notifikasi, dialog konfirmasi perubahan yang belum disimpan, penyatuan tampilan kalender/list, dan tes yang menyeluruh. Lalu 15+ PR lanjutan memperluasnya menjadi sistem tugas berulang yang lengkap dengan riwayat run, penanganan zona waktu, dan dukungan ekspresi cron.
Integrasi Telegram (27 April → 28 April)
Pada titik ini, polanya sudah begitu terlatih sehingga kami merilis sebuah integrasi platform utuh dalam 48 jam. Ming membangun UI Settings (#11196) dan alur Onboarding (#11399). Saya membangun API multi-bot, pengiriman/penerimaan pesan, upload/download file, konteks pesan yang kaya, pembaruan real-time Ably, dan tes E2E. Keesokan harinya, fitur itu diaktifkan untuk semua pengguna.
Di Mana Posisi AI
Saya ingin presisi soal peran AI di sini, karena mudah sekali untuk melebih-lebihkan atau meremehkannya.
AI memungkinkan designer untuk menulis kode. Ming adalah seorang product designer, bukan software engineer. Ia berpikir dalam tata letak, hierarki, dan interaksi, bukan dalam React hooks dan TypeScript generics. Tool AI (Cursor, lalu Claude Code) menjembatani celah itu dengan menangani penerjemahan mekanis dari niat desain menjadi kode yang berfungsi. Ming mengarahkan; AI mengetik. Hasilnya adalah kode yang ditulis seorang designer tetapi bisa dibangun lebih lanjut oleh seorang engineer.
AI mempercepat siklus review. Pada PR kolaboratif, agent AI saya akan mereview kode Ming, mengklasifikasikan isu berdasarkan prioritas (P0/P1/P2), dan langsung mendorong commit perbaikan. PR #5060 melewati lima putaran review dalam 38 menit. PR #5467 menyelesaikan tiga putaran dalam 20 menit. Ini bukan "AI menggantikan code review". Saya tetap membaca setiap perubahan. Tetapi pekerjaan mekanis mengidentifikasi isu lint, tipe yang hilang, dan celah tes kini diotomatiskan.
AI tidak mengambil keputusan desain. Arsitektur informasi setiap halaman, pola interaksi, hierarki visual: semua ini lahir dari insting produk Ming, yang diperkaya riset pengguna dan keahlian domain. AI bisa menghasilkan halaman settings, tetapi tidak bisa memutuskan apa yang sebaiknya menjadi toggle versus dropdown, atau kapan sebuah dialog konfirmasi layak ditampilkan versus kapan itu hanya menjadi gesekan.
AI tidak mengambil keputusan arsitektur. Pilihan untuk memakai feature flag demi deployment paralel, strategi pemisahan lapisan API, keputusan untuk menyambungkan halaman secara bertahap alih-alih sekaligus: semua ini adalah pertimbangan rekayasa. AI membantu saya menulis kode lebih cepat, tetapi pengurutan dan manajemen risiko tetap di tangan manusia.
Ringkasan jujurnya: AI menghapus lapisan penerjemahan antara desain dan rekayasa. Ia tidak menggantikan salah satu disiplin; ia menghilangkan celah di antara keduanya.
Apa yang Berubah dari Peran Saya
Setelah hidup dalam alur kerja ini selama tiga bulan, saya melihat peran saya sebagai frontend engineer secara berbeda.
Saya bukan lagi penerjemah visual. Masa-masa menerima file Figma dan menghabiskan berjam-jam mencocokkan nilai spacing sudah berlalu. Bukan karena saya lebih cepat dalam hal itu, tetapi karena itu bukan lagi tugas saya. Niat designer tiba sebagai kode, bukan sebagai gambar dari kode.
Saya adalah perluas arsitektur. Nilai utama saya adalah mengambil permukaan UI yang sudah berfungsi dan membangun infrastruktur tak kasatmata di bawahnya: integrasi API, validasi data, penanganan error, pemeriksaan permission, pembaruan real-time, tes. Rasio pada sebagian besar PR kolaboratif menceritakan kisahnya. Ming menyumbang 3 commit UI, saya menyumbang 13 commit untuk segala hal lainnya.
Saya adalah penjaga gerbang kualitas. Dengan siklus review berbantuan AI, saya bisa menjaga kualitas kode di area yang jauh lebih luas dari sebelumnya. Review otomatis menangkap isu-isu mekanis; saya fokus pada perhatian arsitektur, kasus tepi, dan memastikan fitur benar-benar berfungsi dari ujung ke ujung.
Saya adalah ahli strategi pengiriman. Feature flag, penyambungan bertahap, deployment paralel: pengurutan bagaimana sebuah fitur berjalan dari kode ke produksi kini menjadi bagian inti pekerjaan saya, bukan renungan belakangan.
Angka-Angkanya
Tiga bulan. Dua orang. Berbantuan AI sepanjang prosesnya.
- 914 PR yang di-merge (679 milik saya, 235 milik Ming)
- 12 hari dari scaffold pertama hingga penggantian platform secara penuh
- 48 jam untuk integrasi Telegram yang lengkap (fitur tercepat kami)
- 26.000 baris dihapus dalam satu merge yang penuh keyakinan
- 88% PR saya dan 66% PR Ming membawa co-authorship AI
Ini bukan metrik kerja mati-matian. Tak satu pun dari kami bekerja di akhir pekan atau begadang semalaman. Kecepatannya berasal dari menghilangkan waktu mati: rapat serah terima, salah paham spesifikasi, bolak-balik "bisa geser ini 4px". Ketika niat desain mengalir langsung menjadi kode, dan rekayasa memperluas kode itu di tempat, pemborosannya jadi lebih sedikit.
Apa Artinya Ini bagi Tim
Saya tidak mengklaim setiap tim harus bekerja seperti ini. Alur kerja ini muncul dari konteks spesifik kami: tim kecil, peluang pembangunan ulang dari nol, dan akses awal ke tool coding AI yang mumpuni. Hasilnya bisa berbeda bagi Anda.
Tetapi saya memang percaya pergeseran mendasarnya bersifat universal: batas antara desain dan rekayasa sedang melebur, dan AI adalah pelarutnya. Seiring tool AI makin baik dalam menerjemahkan niat menjadi kode, makin banyak designer akan merilis kode secara langsung. Seiring itu terjadi, engineer akan menghabiskan lebih sedikit waktu untuk penerjemahan dan lebih banyak waktu untuk arsitektur, kualitas, dan pengiriman.
Pekerjaan frontend engineer tidak akan lenyap. Ia sedang berubah bentuk. Dan sejujurnya? Bentuk barunya lebih menarik.
Yuma adalah seorang frontend engineer di VM0, tempat ia membangun platform yang menggerakkan Zero, sebuah sistem operasi agent AI. Ia telah menghapus lebih banyak kode lama secara massal daripada yang ingin ia akui.
