eSimphony'yi beş kişilik bir mühendislik ekibi kuruyor. Ürün 150'den fazla ülkeyi kapsıyor, yerel iOS ve Android uygulamaları çıkarıyor, çok bölgeli bir operatör entegrasyon yığını işletiyor, uçtan uca beş dili destekliyor ve her hafta ürün değişikliği yayınlıyor. Bin kişilik bir telekom şirketi değiliz. Bilinçli bir kaldıraçla çalışan küçük bir ekibiz.

Kaldıraç, son 18 ayda içselleştirdiğimiz belirli bir mühendislik yaklaşımından geliyor. Biz buna AI-native geliştirme diyoruz. Pratikte gerçekte şöyle görünüyor.

Ekibin şekli

Beş mühendis. Bir ürün tasarımcısı. Ürün spesifikasyonlarının bir kısmını hâlâ kendisi yazan bir CEO. Resmî bir ürün müdürü yok — spesifikasyonlar CEO'dan, Moza destekli taslaklardan ve mühendislik muhakemesinden çıkıyor. Ayrı bir test ekibi yok — test, geliştirme döngüsünün bir parçası. Ayrı bir DevOps yok — altyapının sahibi, özelliği çıkaran kişi.

Bu bir övünme değil. Bir kısıt. Bu ekip büyüklüğüyle eSimphony ölçeğinde bir ürün çıkarmanın tek yolu, her mühendisin çıktısını çarpanla büyütmek. Yaslandığımız çarpan yapay zekâ.

Beş aşamalı iş akışı

eSimphony'deki her değişiklik — bir metin düzeltmesinden yeni bir operatör entegrasyonuna kadar — aynı beş aşamadan geçiyor. Her aşama yapay zekâ destekli; her aşamada döngüde bir insan var.

1. Keşif (teknik engel yok)

Yeni bir gereksinim düştüğünde ("Mısır kapsaması için X operatörünü entegre etmemiz lazım"), mühendisin ilk hamlesi bilmediği şeyi varsaymak olmuyor. 2 gün yerine 20 dakikada bilinmeyen araziyi keşfetmek için yapay zekâyı kullanmak oluyor.

Pratikte: daha önce hiç Mısırlı bir MVNO entegre etmemiş bir mühendis, operatörün API belgeleriyle bir yapay zekâ asistanını yönlendirebiliyor, entegrasyon yüzeyinin yapılandırılmış bir özetini alabiliyor, uç durumlar hakkında ek sorular sorabiliyor ("bu pazarda tipik eKYC akışı nedir?") ve öğle yemeğinden önce efor, risk ve bilinmezleri içeren tek sayfalık bir değerlendirme çıkarabiliyor.

Değişen şu: darboğaz artık "bu alanı bilen bir mühendisimiz var mı?" değil. "Elimizdeki mühendis, yapay zekâyla güçlendirildiğinde bu alanda birkaç saat içinde yeterince yetkin olabilir mi?" Neredeyse her zaman, evet.

2. Spesifikasyon (haftalar değil, saatler)

Çoğu şirkette ürün spesifikasyonları 1-3 hafta sürüyor: ürün müdürü taslak yazıyor, paydaşlar inceliyor, uç durumlar ekleniyor, kabul kriterleri rafine ediliyor, sonra mühendislik kapsamı yeniden belirliyor. Bir spesifikasyon "bitti" dendiğinde asıl fırsat çoktan kaymış oluyor.

Bizim yaklaşımımız: mühendis (ya da özelliğe göre CEO) tek satırlık bir ürün fikri yazıyor. Yapay zekâ bunu yapılandırılmış bir PRD'ye açıyor — kullanıcı akışı, uç durumlar, başarı ölçütleri, kabul kriterleri, açık sorular. Ekip 45 dakikalık bir çalışma oturumunda rafine ediyor. Spesifikasyon aynı gün mühendisliğe geçiyor.

Takas: bu süreçten çıkan spesifikasyonlar, ürün müdürünün yönettiği geleneksel 2 haftalık spesifikasyonlardan biraz daha ham oluyor. Bunu kabul ediyoruz. İlk uygulamaya geçiş süresindeki sıkışma, ek belirsizliğe değiyor; o belirsizlik de öncesinde değil, geliştirme sırasında çözülüyor.

3. Tasarım (hızlı geri bildirim döngüsü)

Arayüzü ağır basan özelliklerde tasarımcımız, mühendisle birlikte günlerle değil dakikalarla ölçülen bir "tasarla-yap-geri bildir" döngüsünde çalışıyor. Yapay zekâ üretimi maketler (Figma eklentileri + görsel üreticiler) varyantları hızla tarıyor. Mühendis birkaç saatte bir prototip çıkarıyor. Tasarımcı gerçek donanımda inceliyor. Yineleme aynı gün içindeki döngülerle ölçülüyor.

Sonuç şu: tasarım ve mühendislik ardışık değil — eşzamanlı. Tasarım "nihai" hale geldiğinde uygulama zaten üretime giden yolun çoğunu almış oluyor.

4. Geliştirme (kodu yapay zekâ yazıyor; insanlar her diff'i inceliyor)

Bu, işin en görünür AI-native parçası. eSimphony'de bugünkü mühendislik süreci:

Yeni kodun yaklaşık %90'ını yapay zekâ üretiyor (Cursor, Claude, GitHub Copilot; çoğu zaman birlikte)
Mühendisler mimari kararları, entegrasyon sınırlarını ve derin sistem bilgisi gerektiren zorlu iş mantığını yazıyor
Kodun %100'ü birleştirilmeden önce insan tarafından inceleniyor. Her diff. Her PR. İstisnasız.

Bu son madde kritik ve sıklıkla yanlış anlaşılıyor. "Kodu yapay zekâ yazıyor", "koda hiçbir insan bakmıyor" demek değil. Mühendisin rolünün uygulamayı yazmaktan uygulamayı incelemeye kayması demek. Bilişsel iş — bu spesifikasyona uyuyor mu, uç durumları karşılıyor mu, mimariye oturuyor mu, ölçekleniyor mu — hâlâ mühendisin. Mekanik iş — niyeti sözdizimsel olarak doğru, deyimsel koda çevirmek — devrediliyor.

eSimphony'deki tipik bir PR şöyle:

200-800 satır kod değişikliği (2024 dönemi ekiplerdeki geleneksel ~100-200'e karşılık)
Ayrıntılı inceleme yapan 1 mühendis
Çoğu zaman yeni kodda %80'in üzerinde kapsama sağlayan, yapay zekânın ürettiği birim testler
Sözdizimine değil mimariye odaklanan inceleme yorumları

5. Yayın (dakikalar içinde uyum)

Yayın kademeli ilerliyor: riskli değişiklikler için özellik bayrakları, arka uç servisleri için kanarya dağıtımları, dağıtımdan sonraki dakikalar içinde anormallikleri yüzeye çıkaran yapay zekâ izlemeli telemetri. Bir yayın bir şeyi bozduğunda geri alma saatlerle değil dakikalarla ölçülüyor.

"Yapay zekâ izlemeli telemetri" kısmı bir cümleyi hak ediyor: dağıtım sonrasında bir yapay zekâ ajanı hata oranlarında, gecikmede, kullanıcı bildirimlerinde ve dönüşümde anormallik arıyor. Anormallikler eşiği aştığında nöbetçi mühendise olası kök nedenlerin özetiyle çağrı gidiyor. Bu, tespit süresini "kullanıcı sabah 9'da hata bildiriyor"dan "uyarı 09.03'te düşüyor"a sıkıştırıyor.

Rakamlar

Son 12 aya ait yaklaşık ölçütler:

Sprint döngüsü: 1 hafta. Yeni özellikler haftalık çıkıyor; küçük düzeltmeler günlük.
Üründe tam zamanlı çalışan 5 mühendis. Ek olarak yarı zamanlı sözleşmeli bir mühendis.
Yeni kodun %90'ından fazlası yapay zekâ üretimi (ağırlıklı olarak Cursor + Claude).
Birleştirilen kodun %100'ü insan incelemesinden geçti.
Özellik spesifikasyonundan üretime medyan süre: 5-10 gün.
Çeyrek başına üretim olayı: 1-2. Kapsamımız için sektör ortalamasının altında.
Mühendisliğe yükseltilen müşteri destek talebi: haftada ~5. Çoğu aynı gün içinde çözülüyor.

Bu rakamlar teorik değil. Ekibimizin gerçek çalışma temposu.

Bu ne değil

eSimphony'de AI-native geliştirmenin ne anlama gelmediğini açıkça söylemeye değer.

"Vibe coding" değil. Kod satır satır inceleniyor. Mimari kararları insanlar veriyor. Yapay zekâ yazmayı hızlandırıyor, düşünmeyi değil.

"Test yok" değil. Yapay zekâ üretimi testlerin belirli zayıflıkları var (mutlu yolları uç durumlardan daha ayrıntılı test etme eğilimindeler), bu yüzden mühendisler uçlar için elle yazılmış testler ekliyor. Yeni kodda test kapsaması istikrarlı biçimde %80'in üzerinde.

"Kıdemli mühendise gerek yok" değil. Tam tersi. Yapay zekâ, kıdemli muhakemenin değerini dramatik biçimde artırıyor; çünkü kıdemli mühendisler yapay zekâ çıktısını sıfırdan yazabileceklerinden 5-10 kat hızlı inceleyip rafine edebiliyor. Kıdemli incelemesi olmadan yapay zekâ kullanan genç mühendisler, derlenen ama yapısal olarak kırılgan kod üretme eğiliminde.

"Tasarım ya da ürün düşüncesi yok" değil. Net spesifikasyonlar ve iyi düşünülmüş kullanıcı akışları olmadan yapay zekâ işe yaramaz. "Ne inşa etmeliyiz, neden, kimin için" sorusunun bilişsel işi insanda kalıyor.

Bunun gerektirdikleri

Önem sırasıyla üç şey.

1. Sert insan incelemesi

Yapay zekânın ürettiği her satır, birleştirilmeden önce kıdemli bir mühendisin incelemesinden geçiyor. "Bariz doğru" küçük değişikliklerde incelemeyi atlama isteği gerçek ve tehlikeli. %100 inceleme çizgisini koruduk.

2. Sıkı mimari korkuluklar

Yapay zekâ kod ürettiğinde yerel kuralları izliyor. Güçlü kurallar = güçlü yapay zekâ çıktısı. Net modül sınırlarına, tutarlı adlandırmaya, iyi tiplenmiş arayüzlere ve "biz burada işleri nasıl yaparız" belgelerine ağır yatırım yaptık ki yapay zekâ deseni temiz eşleştirebilsin.

3. Yapay zekânın varsayılan olduğuna dair kültürel kabul

Ekip, her iş akışında yapay zekâ desteğinin varsayılan olduğunda açıkça hemfikir oldu. Yeni mühendisler bu varsayılana göre işe alıştırılıyor. İtirazlar ("ama ben kendim yazmayı tercih ederim") dinleniyor ve tartışılıyor; ama ekip normu, aksini gerektiren özel bir neden yoksa mekanik işi yapay zekânın yapması.

Yapay zekâyı kullanmadığımız yerler

Yapay zekânın ürettiği kodu incelemek (taze insan gözü istiyoruz)
Ne inşa edeceğimize karar vermek (ürün stratejisi insana ait)
Doğrudan müşteri destek yükseltmeleri (zor vakaları insanlar üstleniyor)
Performans değerlendirmeleri ve ekip geri bildirimi (yalnızca insan)
İşe alım kararları (yalnızca insan; aday bulma ve ön eleme yapay zekâ destekli)

Desen şu: yapay zekâ uygulamayı güçlendirir; kararların sahibi insanlardır.

Bunun ürün için önemi

Bu iş akışının çıktısı üründe görünüyor. Çıkardıklarımız:

Ömürlük eSIM mimarisi (çoğu şirkette birkaç çeyreklik bir proje)
Beş dilde yapay zekâ seyahat arkadaşı Moza
Üç bölgede yapay zekâ Dinamik Paketler
Otomatik onarımlı yapay zekâ sorun giderme
Haftalık sürümlerle yerel iOS ve Android uygulamaları
%99,9+ çalışma süresine sahip çok bölgeli arka uç
Ürünün tamamında 5 dilli yerelleştirme

Bu liste normalde 30-50 mühendis ve 3+ yıl gerektiriyor. Biz onu 5 mühendisle 18 ayda çıkardık.

İşe alım üzerine bir not

Ekibi dikkatle büyütüyoruz. Burada iyi iş çıkaran mühendisler üç özelliği paylaşıyor:

Yüksek çıktı yerine yüksek muhakeme. Yazmayı yapay zekâ üstleniyor; biz inceleme, karar verme ve biçimlendirmede parlayan mühendisler istiyoruz.
Yapay zekâyı bir meslektaş gibi görmek. Yapay zekâya ne sihirli bir kâhin ne de kimliğine yönelik bir tehdit gibi değil, bir iş arkadaşı gibi davranan (ona iş devreden, onu inceleyen, ona itiraz eden) mühendisler.
Kullanıcıyı önemsemek. AI-native iş akışları, derlenen ama önemi olmayan bol miktarda kod üretecek kadar hızlı. Her PR'ı "bu kullanıcıya yarıyor mu" sorusuna oturtabilen mühendisler en iyi işi çıkarıyor.

Bu sizseniz, işe alıyoruz. Kariyer sayfasından bize ulaşın ya da doğrudan Trung'a yazın.

Sırada ne var

Mevcut ürünü kuran aynı iş akışı, yol haritasını da çıkarıyor:

Çoklu eSIM yönetimi (Mayıs 2026)
Aile paketleri (Haziran 2026)
Sadakat ve ödüller (Ağustos 2026)
Dünya çapında doğrudan operatör kapsaması (2027)

Bunların her biri geleneksel bir telekom şirketinde aylar süren bir proje. İç tahminlerimize göre dördü de aynı beş kişilik ekiple zamanında çıkıyor.

Kaldıraç bu. Bahis bu. Küçük bir ekip, koca bir sektörün ataletine karşı böyle üretiyor.

eSimphony'yi iş başında görün, konumlanmamızı okuyun ya da MVNO Nation Americas sunumumuza bakın.

5 Kişilik Ekip Nasıl 10× Hızda Üretiyor: eSimphony'de AI-Native Mühendislik