Cara Tim 5 Orang Merilis 10× Lebih Cepat: Rekayasa AI-Native di eSimphony

eSimphony dibangun oleh tim rekayasa beranggotakan lima orang. Produknya mencakup 150+ negara, merilis aplikasi native iOS dan Android, menjalankan tumpukan integrasi operator multiwilayah, mendukung lima bahasa dari ujung ke ujung, dan merilis perubahan produk tiap pekan. Kami bukan perusahaan telko beranggotakan seribu orang. Kami tim kecil yang beroperasi dengan daya ungkit yang disengaja.

Daya ungkit itu datang dari pendekatan rekayasa spesifik yang kami serap selama 18 bulan terakhir. Kami menyebutnya pengembangan AI-native. Beginilah wujudnya dalam praktik.

Bentuk timnya

Lima insinyur. Satu desainer produk. Satu CEO yang masih ikut menulis sebagian spesifikasi produk. Tanpa manajer produk formal — spesifikasi datang dari CEO + draf berbantuan Moza + pertimbangan tim rekayasa. Tanpa tim QA khusus — pengujian adalah bagian dari siklus pembangunan. Tanpa DevOps terpisah — infrastruktur dimiliki oleh siapa pun yang merilis fiturnya.

Ini bukan pamer. Ini batasan. Dengan ukuran tim seperti ini, satu-satunya cara merilis produk sebesar cakupan eSimphony adalah melipatgandakan keluaran tiap insinyur. AI adalah pengali yang kami andalkan.

Alur kerja lima tahap

Setiap perubahan di eSimphony — dari perbaikan kalimat sampai integrasi operator baru — bergerak melewati lima tahap yang sama. Tiap tahap dibantu AI; tiap tahap ada manusia di dalamnya.

1. Discover (tanpa penghalang teknis)

Ketika kebutuhan baru datang ("kita perlu mengintegrasikan operator X untuk cakupan Mesir"), langkah pertama seorang insinyur bukanlah berasumsi tentang hal yang tidak ia ketahui. Melainkan memakai AI untuk menjelajahi wilayah asing itu dalam 20 menit alih-alih 2 hari.

Dalam praktik: seorang insinyur yang belum pernah mengintegrasikan MVNO Mesir bisa memberi asisten AI dokumentasi API operator itu, memperoleh ringkasan terstruktur soal permukaan integrasinya, mengajukan pertanyaan lanjutan tentang kasus tepi ("seperti apa alur eKYC yang lazim di pasar ini?"), dan menghasilkan penilaian satu halaman tentang usaha, risiko, dan hal yang belum diketahui sebelum jam makan siang.

Yang berubah: hambatannya bukan lagi "apakah kita punya insinyur yang paham domain ini?" melainkan "bisakah insinyur yang kita punya, dibantu AI, jadi cukup kompeten di domain ini dalam beberapa jam?" Hampir selalu, bisa.

2. Spec (hitungan jam, bukan pekan)

Sebagian besar spesifikasi produk di kebanyakan perusahaan butuh 1–3 pekan: PM membuat draf, para pemangku kepentingan meninjau, kasus tepi ditambahkan, kriteria penerimaan dihaluskan, lalu tim rekayasa mengukur ulang cakupannya. Begitu spesifikasi "selesai", peluang awalnya sudah bergeser.

Pendekatan kami: insinyur (atau CEO, tergantung fiturnya) menulis draf ide produk satu baris. AI mengembangkannya menjadi PRD terstruktur — alur pengguna, kasus tepi, metrik keberhasilan, kriteria penerimaan, pertanyaan terbuka. Tim menghaluskannya dalam sesi kerja 45 menit. Spesifikasinya diserahkan ke tim rekayasa hari itu juga.

Tukarannya: spesifikasi dari proses ini sedikit lebih kasar ketimbang spesifikasi tradisional dua pekan yang dipimpin PM. Kami menerima itu. Pemadatan waktu menuju implementasi pertama sepadan dengan tambahan ambiguitasnya, yang toh diselesaikan saat membangun, bukan sebelumnya.

3. Design (siklus umpan balik cepat)

Untuk fitur dengan UI yang signifikan, desainer kami bekerja berdampingan dengan insinyur dalam siklus "desain-bangun-umpan balik" yang diukur dalam hitungan menit, bukan hari. Mockup buatan AI (plugin Figma + generator gambar) menjelajahi berbagai varian dengan cepat. Insinyur merilis prototipe dalam beberapa jam. Desainer meninjaunya di perangkat sungguhan. Iterasinya diukur dalam siklus hari yang sama.

Hasilnya, desain dan rekayasa tidak berurutan — keduanya berjalan bersamaan. Begitu desainnya "final", implementasinya sudah nyaris siap produksi.

4. Build (AI menulis kodenya; manusia meninjau tiap diff)

Inilah bagian AI-native yang paling terlihat. Proses rekayasa di eSimphony hari ini:

• AI menghasilkan ~90% kode baru (Cursor, Claude, GitHub Copilot, sering dikombinasikan)
• Insinyur menulis keputusan arsitektur, batas integrasi, dan logika bisnis rumit yang menuntut pemahaman sistem yang dalam
• 100% kode ditinjau manusia sebelum digabungkan. Setiap diff. Setiap PR. Tanpa pengecualian.

Poin terakhir ini krusial dan sering disalahpahami. "AI menulis kodenya" bukan berarti "tak ada manusia yang melihat kodenya". Artinya peran insinyur bergeser dari mengetik implementasi menjadi meninjau implementasi. Kerja kognitifnya — apakah ini sesuai spesifikasi, apakah ini menangani kasus tepi, apakah ini cocok dengan arsitekturnya, apakah ini bisa berskala — tetap milik insinyur. Kerja mekanisnya — menerjemahkan maksud menjadi kode yang benar secara sintaksis dan idiomatis — didelegasikan.

Satu PR khas di eSimphony punya:

• 200–800 baris kode yang berubah (dibanding ~100–200 secara tradisional di tim era 2024)
• 1 insinyur yang meninjau secara rinci
• Sering ada unit test buatan AI dengan cakupan >80% pada kode baru
• Komentar peninjau yang berfokus pada arsitektur, bukan sintaksis

5. Ship (beradaptasi dalam hitungan menit)

Perilisan berlangsung bertahap: feature flag untuk perubahan berisiko, deployment canary untuk layanan backend, telemetri yang dipantau AI dan memunculkan anomali dalam hitungan menit setelah peluncuran. Ketika satu rilis merusak sesuatu, rollback-nya diukur dalam hitungan menit, bukan jam.

Bagian "telemetri yang dipantau AI" layak dijelaskan sekalimat: seusai deploy, sebuah agen AI mengawasi anomali pada tingkat kesalahan, latensi, laporan masalah dari pengguna, dan konversi. Ketika anomali melewati ambang tertentu, insinyur yang sedang piket dipanggil dengan ringkasan kemungkinan akar penyebabnya. Ini memadatkan waktu deteksi dari "pengguna melaporkan bug pukul 9 pagi" menjadi "peringatan berbunyi pukul 09.03".

Angka-angkanya

Perkiraan metrik dari 12 bulan terakhir:

• Siklus sprint: 1 pekan. Fitur baru dirilis tiap pekan; perbaikan kecil dirilis tiap hari.
• 5 insinyur bekerja penuh waktu di produk. Satu insinyur tambahan berkontrak paruh waktu.
• >90% kode baru dihasilkan AI (terutama Cursor + Claude).
• 100% kode yang digabungkan sudah ditinjau manusia.
• Median waktu dari spesifikasi fitur ke produksi: 5–10 hari.
• Insiden produksi per kuartal: 1–2. Di bawah rata-rata industri untuk cakupan kami.
• Tiket dukungan pelanggan yang naik ke tim rekayasa: ~5/pekan. Sebagian besar selesai di hari yang sama.

Angka-angka ini bukan teori. Inilah tempo operasional tim kami yang sesungguhnya.

Apa yang bukan ini

Layak dijelaskan secara gamblang apa yang bukan arti pengembangan AI-native di eSimphony.

Ini bukan "vibe coding". Kode ditinjau baris demi baris. Keputusan arsitektur dibuat manusia. AI mempercepat pengetikannya, bukan pemikirannya.

Ini bukan "tanpa pengujian". Tes buatan AI punya kelemahan spesifik (cenderung menguji jalur mulus lebih tuntas ketimbang kasus tepi), jadi insinyur menambahkan tes tulisan tangan untuk bagian tepinya. Cakupan pengujian konsisten di atas 80% pada kode baru.

Ini bukan "tak butuh insinyur senior". Justru sebaliknya. AI menaikkan nilai pertimbangan senior secara dramatis, karena insinyur senior bisa meninjau dan menghaluskan keluaran AI 5–10× lebih cepat dari kalau harus menulisnya dari nol. Insinyur junior yang memakai AI tanpa tinjauan senior cenderung menghasilkan kode yang bisa dikompilasi tapi rapuh secara struktural.

Ini bukan "tanpa pemikiran desain atau produk". AI tak berguna tanpa spesifikasi yang jelas dan alur pengguna yang dipikirkan matang. Kerja kognitif "apa yang harus kita bangun, kenapa, untuk siapa" tetap milik manusia.

Apa yang dibutuhkan

Tiga hal, berdasarkan urutan kepentingannya.

1. Tinjauan manusia yang ketat

Setiap baris kode buatan AI melewati tinjauan insinyur senior sebelum digabungkan. Godaan untuk melewatkan tinjauan pada perubahan kecil yang "jelas-jelas benar" itu nyata dan berbahaya. Kami bertahan pada tinjauan 100%.

2. Pagar arsitektur yang ketat

Ketika AI menghasilkan kode, ia mengikuti konvensi setempat. Konvensi kuat = keluaran AI kuat. Kami berinvestasi besar pada batas modul yang jelas, penamaan yang konsisten, antarmuka bertipe rapi, dan dokumentasi eksplisit tentang "beginilah cara kami bekerja di sini" supaya AI bisa mencocokkan polanya dengan bersih.

3. Penerimaan budaya bahwa AI adalah bawaannya

Tim sudah sepakat, secara eksplisit, bahwa bantuan AI adalah bawaan di setiap alur kerja. Insinyur baru dikenalkan pada bawaan ini. Keberatan ("tapi saya lebih suka menulisnya sendiri") tetap didengar dan didiskusikan, tapi norma tim adalah AI menangani kerja mekanisnya kecuali ada alasan spesifik untuk tidak.

Untuk apa kami tidak memakai AI

• Meninjau kode buatan AI (kami ingin mata manusia yang segar)
• Memutuskan apa yang dibangun (strategi produk itu urusan manusia)
• Eskalasi dukungan pelanggan langsung (manusia menangani kasus sulitnya)
• Penilaian kinerja dan umpan balik tim (manusia saja)
• Keputusan perekrutan (manusia saja, dibantu AI untuk penjaringan dan penyaringan)

Polanya: AI memperkuat eksekusi; manusia memiliki keputusan.

Kenapa ini penting bagi produknya

Keluaran alur kerja ini terlihat di produknya. Kami sudah merilis:

• Arsitektur eSIM seumur hidup (proyek yang butuh beberapa kuartal di kebanyakan perusahaan)
• Moza, sang pendamping perjalanan AI, dalam lima bahasa
• Paket Dinamis AI di tiga kawasan
• Pemecahan Masalah AI dengan penyembuhan otomatis
• Aplikasi native iOS dan Android dengan rilis mingguan
• Backend multiwilayah dengan uptime 99,9%+
• Pelokalan 5 bahasa di seluruh permukaan produk

Daftar ini biasanya butuh 30–50 insinyur dan 3+ tahun. Kami merilisnya dengan 5 insinyur dalam 18 bulan.

Catatan soal perekrutan

Kami menumbuhkan tim dengan hati-hati. Insinyur yang berkembang di sini punya tiga sifat yang sama:

1. Pertimbangan tinggi di atas keluaran tinggi. AI menangani pengetikan; kami ingin insinyur yang unggul dalam meninjau, memutuskan, dan membentuk.
2. Nyaman menjadikan AI sebagai rekan. Insinyur yang memperlakukan AI sebagai rekan kerja (mendelegasikan padanya, meninjaunya, membantahnya) alih-alih sebagai peramal ajaib atau ancaman bagi identitasnya.
3. Peduli pada pengguna. Alur kerja AI-native cukup cepat untuk menghasilkan banyak kode yang bisa dikompilasi tapi tak berarti. Insinyur yang bisa mendasarkan tiap PR pada "apakah ini membantu pengguna" menghasilkan karya terbaik.

Kalau itu Anda, kami sedang merekrut. Hubungi kami lewat halaman karier atau kirim pesan langsung ke Trung.

Apa yang dirilis berikutnya

Alur kerja yang sama yang membangun produk saat ini juga merilis peta jalan kami:

• Pengelolaan multi-eSIM (Mei 2026)
• Paket keluarga (Juni 2026)
• Loyalitas dan imbalan (Agustus 2026)
• Cakupan operator langsung sedunia (2027)

Masing-masing adalah proyek berbulan-bulan di perusahaan telko tradisional. Estimasi internal kami menyebut keempatnya rilis sesuai jadwal, dengan tim lima orang yang sama.

Itulah daya ungkitnya. Itulah taruhannya. Begitulah cara tim kecil merilis melawan inersia satu industri penuh.

Lihat eSimphony beraksi, baca soal posisi kami, atau cek pitch deck kami dari MVNO Nation Americas.