AI çağında yeni ürün-mühendislik iş akışına bir frontend mühendisi bakışı
Anlamsız Olması Gereken Bir Rakam
12 gün. İki kişi: bir ürün tasarımcısı ve bir frontend mühendisi. Tam bir platformun yeniden inşası.
Bir prototip değil. Bir MVP değil. Üretimdeki bir uygulamanın tam anlamıyla yerine geçen, 26,000 satır eski kodun silindiği tek bir PR ile sonuçlanan bir yeniden inşa. Her sayfa, her rota, her etkileşim sıfırdan yeniden yapıldı ve gerçek kullanıcılara sunuldu.
Geleneksel bir ürün geliştirme iş akışında bu zaman çizelgesi saçma olurdu. Bu kapsamda bir proje genellikle aylar sürerdi: Figma'da haftalarca süren tasarım keşfi, paydaş inceleme turları, devir teslim töreni, sprint planlaması ve ardından piksellerin mükemmel şekilde uygulanmasının yavaş ilerleyişi. Burada olan ise temelde farklıydı. Daha çok çalıştığımız için değil, birlikte çalışma şeklimiz değiştiği için.
Bu, VM0'da Zero platformunu nasıl yayına aldığımızın ve bunun bana ürün-mühendislik iş birliğinin geleceği hakkında ne öğrettiğinin hikayesi.
Eski Darboğaz
Her frontend mühendisi geleneksel süreci bilir:
- Tasarımcı Figma'da taslaklar oluşturur
- Tasarım incelemesi, yineleme, onay
- Boşluklar, renkler, kırılma noktalarıyla açıklamalı teknik çizimler
- Mühendis görsel teknik çizimleri koda çevirir
- Gidip gelmeler: "Bunu 4px sola kaydırabilir misin?"
- Sonunda, API katmanını bağlama
- Entegrasyon testi, daha fazla gidip gelme
Darboğaz hiçbir zaman tek bir adımda değildi. Adımlar arasındaki boşluklardaydı: bekleme, çeviri kaybı, bağlam değişimi. Bir tasarımcının bir etkileşime dair zihinsel modeli, statik bir Figma karesine indirgenip kırmızı çizgilerle açıklanınca, mühendisin masasına zaten bozulmuş olarak ulaşır. Mühendis, tasarımcının hayal ettiğinin bir versiyonunu yeniden inşa eder ama bu kaçınılmaz olarak kayıplı bir kopyadır.
Bu sürtünmeye o kadar alışmıştık ki artık fark etmiyorduk. Sadece "işler böyle yürür" diyorduk.
Deney: Ya Tasarımcı Kodu Yayına Alırsa?
5 Mart 2026'te, ürün tasarımcımız Ming, PR #3685'ü açtı: feat(platform): add zero app with shell, pages and polish. 4,146 satır çalışan React kodu ekledi.
Bir Figma dosyası değil. Bir tasarım token'ı dışa aktarımı değil. Çalışan bir uygulama.
PR, tam bir uygulama kabuğu içeriyordu: yan menü navigasyonu, yönlendirme yapısı, sohbet, takvim, etkinlik, ekip yönetimi ve ayarlar için sayfa iskeletleri; hepsi tasarım sistemimizle stillendirilmiş, tarayıcıda çalışan. Veriler sahteydi ama arayüz gerçekti. npm run dev yapıp her sayfada gezinebiliyordunuz.
Ming bu kodu geleneksel anlamda sıfırdan yazmadı. Tasarım vizyonunu doğrudan React bileşenlerine çevirmek için AI kodlama araçlarını (önce Cursor, sonra Claude Code) kullandı. AI, mekanik çeviriyi (JSX yapısı, CSS özellikleri, bileşen kompozisyonu) üstlendi; Ming ise hiçbir AI'nın karar veremeyeceği görsel ve etkileşimsel kararları verdi: düzenin ritmi, bilgi hiyerarşisi, geçişlerin hissi.
Sonraki dört günde üç PR daha geldi:
| Tarih | PR | Ming'in Yayına Aldığı |
|---|---|---|
| Mar 5 | #3685 | Uygulama kabuğu, yan menü, tüm sayfa iskeletleri (+4,146 satır) |
| Mar 6 | #3825 | Takvim sayfaları, arayüz iyileştirmeleri (+2,650 satır) |
| Mar 9 | #3993 | Onboarding akışı, Slack yapılandırma diyaloğu (+1,146 satır) |
| Mar 9 | #4050 | Hakkında sayfası, yüzen navigasyon kartı |
Mart 9 itibarıyla, yeni platformumuzun tüm frontend yüzeyi çalışan kod olarak mevcuttu. Üretimde göreceğiniz her sayfa, geliştirme ortamında tıklanabilir durumdaydı. Sadece henüz gerçek bir iş yapmıyordu.
İşte burada devreye ben girdim.
Yeni İşim: Ruha Hayat Vermek
9 Mart'ta kod tabanını açtığımda, düz bir tasarımı koda çevirmek gibi alışık olduğum bir zorlukla karşılaşmadım. Kod zaten oradaydı. Benim işim, her sahte veriyi gerçeğiyle değiştirmek, her güzelce tasarlanmış yüzeyi arka plandaki canlı backend'e bağlamaktı.
Bu, işimi kökten değiştirdi. Pikselleri düşünmek yerine veri akışlarını düşünüyordum. "Bu makete uyuyor mu?" diye sormak yerine, "Bu sayfanın hangi API çağrısına ihtiyacı var ve başarısız olursa ne olur?" diye soruyordum.
İlk haftam şöyle geçti:
Gün 1 (9 Mart): Kimlik doğrulama ve organizasyon değiştirme. Ming'in kabuğunu Clerk kimlik doğrulamasına bağladım, alanlar arası yönlendirmeler ekledim ve organizasyon değiştiriciyi gerçekten çalışır hale getirdim. İki PR, ikisi de aynı gün birleştirildi.
Gün 2 (10 Mart): Bağlayıcılar ve takvim. Sahte bağlayıcı ızgarasını gerçek API verisiyle değiştirdim, takvim sekmesini gerçek cron işlerine bağladım ve talimat düzenleyiciyi backend'e entegre ettim. Dört PR.
Gün 3 (11 Mart): Büyük bağlantı günü. Ekip sayfası gerçek alt ajan verisi aldı (+3,271 satır). Etkinlik sayfası gerçek loglara kavuştu. Ve en önemlisi: sohbet sayfası gerçek ajan çalıştırma hattına bağlandı, ~1,200 satır demo kodu çalışan bir AI sohbet arayüzüyle değiştirildi. Aynı gün, eski ve yeni platformları yan yana çalıştırmamızı sağlayan FeatureSwitchKey.Zero adlı bir özellik bayrağı ekledim.
Günler 4-5 (12-13 Mart): Dosya ekleri, oturum yönetimi, çoklu ajan sohbeti, ayarların kalıcılığı. Ming'in inşa ettiği her sayfa artık gerçek iş yapıyordu.
Ritim neredeyse müzikseldi. Her sabah Ming'in iskeletinden bir sayfa seçiyor, bileşen yapısını inceliyor, beklediği veriyi belirliyor, API entegrasyonunu kuruyor, hata durumlarını yönetiyor ve gönderiyordum. Öğleden sonra bir sayfa daha hayata geçiyordu.
Özellik Anahtarı: Paralel Dünyalar
FeatureSwitchKey.Zero özellik bayrağı özel bir anı hak ediyor, çünkü bu geçişi tehlikeli değil güvenli yapan oydu.
11 Mart'tan itibaren, üretim uygulamamız iki tam arayüzü paralel çalıştırdı. Eski sistemi kullananlar eski rotaları görüyordu. Yeni sistemi test eden dahili kullanıcılar ise Zero'yu görüyordu. Bağladığım her sayfa, tek bir kullanıcının iş akışını riske atmadan üretim bağlamında test edilebiliyordu.
Bu devrim değil. Özellik bayrakları standart bir uygulama. Ama özellik bayraklarının design-as-code iş akışıyla birleşimi özel bir şey yarattı: Ming tam, gezilebilir bir arayüz inşa ettiği için yeni platformun tüm kullanıcı deneyimini doğrulayabildik; ben de her sayfayı tek tek işlevsel hale getirdim. Herhangi bir anda bir sorun çıkarsa, anahtarı eskiye çevirebilirdik.
Hiçbir sorun çıkmadı.
Gün 12: Büyük Anahtar
17 Mart'ta PR #5095'ü açtım: refactor: remove all non-zero platform pages and feature flag.
Fark: +456 satır, -26,041 satır.
Önce: eski VM0 Platformu. Tablolar, çalıştırma kimlikleri ve ham oturum verisi.
Sonra: yeni Zero. Sabitlenmiş ajanlar ve kullanım kartlarıyla sohbet tabanlı bir AI çalışma alanı.
Tek bir birleştirmeyle tüm eski rotalar silindi. Özellik bayrağı kaldırıldı. Zero artık bir seçenek değil, tek moddu. Takip eden PR (#5155) /zero URL önekini tamamen kaldırdı: /zero/chat olan şey artık sadece /chat oldu.
Bu kesintiyi neden güvenle yaptım? Çünkü:
- Her sayfa en az 5 gündür özellik bayrağı altında çalışıyordu
- Her API entegrasyonu üretim verisiyle test edilmişti
- Eski ve yeni sistemler aynı backend'i paylaşıyordu. Bu sadece bir frontend değişimiydi, veri geçişi değildi
- Yeni sistemde gerçek kullanıcılar vardı ve sürekli geri bildirim alıyorduk
26,000 satır kaygıyla değil, rahatlıkla silindi.
Desen Tekrar Ediyor
Beni en çok şaşırtan şey geçişin kendisi değil, keşfettiğimiz iş akışının sonraki her özellikte varsayılan modumuz haline gelmesiydi. Ming, AI yardımıyla arayüz kabuğunu inşa ediyor, ben mantığı bağlıyor ve mimariyi genişletiyorum. Aynı design-as-code deseni, özellik ölçeğinde:
Yetki Sistemi (Mart 19 → Nisan 7)
Ming, Sheet bileşenleri ve anahtar kontrolleriyle bir yetki çekmecesi arayüzü olan PR #5467'yi yayına aldı. Üç commit, temiz arayüz.
Aynı PR'a 13 commit ekledim: firewall_access_requests için veritabanı geçişi, API uç noktaları, entegrasyon testleri, lint düzeltmeleri. Sonraki iki haftada 10+ takip PR'ı tam yetki katmanını inşa etti: onay kartı yeniden tasarımı, erişim istekleri için Slack bildirimleri, yetki sorunlarını teşhis için CLI doctor komutları ve sonunda kod tabanında tüm "firewall" kavramının "permission" olarak yeniden adlandırılması.
Ming'in çekmecesi tohumdu. Yetki sistemi ağaç oldu.
Takvim Sistemi (Mart 23 → Nisan 13)
Ming, takvim detay rotasını ve takvim arayüzünü (#6155) tasarladı. Üç commitlik temiz arayüz çalışması.
Ben 14 commit ekledim: otomatik oluşturmalı açıklama düzenleme, bildirimler için Slack kanal seçimi, kaydedilmemiş değişiklikler için onay diyaloğu, takvim/liste görünümü birleştirme ve kapsamlı testler. Sonra 15+ takip PR'ı ile tam bir yinelenen görev sistemi, çalıştırma geçmişi, zaman dilimi yönetimi ve cron ifadesi desteği eklendi.
Telegram Entegrasyonu (Nisan 27 → Nisan 28)
Bu noktada desen o kadar oturmuştu ki, tüm bir platform entegrasyonunu 48 saatte yayına aldık. Ming, Ayarlar arayüzünü (#11196) ve Onboarding akışını (#11399) inşa etti. Ben çoklu bot API'si, mesaj gönder/al, dosya yükle/indir, zengin mesaj bağlamı, Ably gerçek zamanlı güncellemeler ve uçtan uca testleri yaptım. Ertesi gün, tüm kullanıcılara açıldı.
AI Nerede Devreye Giriyor
Burada AI'nın rolünü net anlatmak istiyorum; çünkü abartmak da küçümsemek de kolay.
AI, tasarımcının kod yazmasını sağladı. Ming bir ürün tasarımcısı, yazılım mühendisi değil. O, düzenler, hiyerarşiler ve etkileşimler üzerine düşünür; React hook'ları ve TypeScript jenerikleriyle değil. AI araçları (Cursor, ardından Claude Code) tasarım niyetini çalışan koda mekanik olarak çevirdi. Ming yönlendirdi; AI yazdı. Sonuç, bir tasarımcının yazdığı ama bir mühendisin üzerine inşa edebileceği koddur.
AI, inceleme döngüsünü hızlandırdı. Ortak PR'larda, AI ajanım Ming'in kodunu inceler, sorunları önceliğe göre (P0/P1/P2) sınıflandırır ve doğrudan düzeltme commit'leri gönderirdi. PR #5060 beş inceleme turunu 38 dakikada tamamladı. PR #5467 üç turu 20 dakikada bitirdi. Bu "AI kod incelemesini devraldı" değil. Her değişikliği yine ben okudum. Ama lint hatalarını, eksik tipleri ve test boşluklarını bulma işi otomatikleşti.
AI, tasarım kararlarını vermedi. Her sayfanın bilgi mimarisi, etkileşim desenleri, görsel hiyerarşisi: bunlar Ming'in ürün sezgisinden, kullanıcı araştırmasından ve alan bilgisinden geldi. AI bir ayarlar sayfası üretebilir ama neyin anahtar, neyin açılır menü olacağına ya da ne zaman onay diyaloğu gerektiğine karar veremez.
AI, mimari kararları vermedi. Paralel dağıtım için özellik bayrağı kullanma tercihi, API katmanı ayrım stratejisi, sayfaları topluca değil kademeli bağlama kararı: bunlar mühendislik yargısıydı. AI kodu daha hızlı yazmamı sağladı ama sıralama ve risk yönetimi insana aitti.
Dürüst özet: AI, tasarım ve mühendislik arasındaki çeviri katmanını ortadan kaldırdı. Hiçbirini ikame etmedi; aradaki boşluğu kaldırdı.
Rolümde Ne Değişti
Bu iş akışında üç ay geçirdikten sonra, frontend mühendisi olarak rolümü farklı görüyorum.
Artık görsel bir çevirmen değilim. Figma dosyası alıp saatlerce boşluk değerlerini eşleştirme günleri bitti. Daha hızlı olduğum için değil, artık işim bu olmadığı için. Tasarımcının niyeti kod olarak geliyor, kodun resmi olarak değil.
Bir mimari genişleticiyim. Asıl değerim, çalışan bir arayüz yüzeyini alıp altındaki görünmez altyapıyı inşa etmek: API entegrasyonları, veri doğrulama, hata yönetimi, yetki kontrolleri, gerçek zamanlı güncellemeler, testler. Çoğu ortak PR'daki oran bunu gösteriyor. Ming 3 commit arayüz, ben 13 commit geri kalan her şeyi ekliyorum.
Bir kalite bekçisiyim. AI destekli inceleme döngüleriyle, eskisinden çok daha geniş bir yüzeyde kod kalitesini koruyabiliyorum. Otomatik inceleme mekanik sorunları yakalıyor; ben mimari konulara, uç durumlara ve özelliğin uçtan uca çalıştığına odaklanıyorum.
Bir teslimat stratejistiyim. Özellik bayrakları, kademeli bağlantı, paralel dağıtımlar: bir özelliğin koddan üretime nasıl geçtiğinin sıralaması artık işimin temel parçası, sonradan düşünülen bir şey değil.
Rakamlar
Üç ay. İki kişi. Süreç boyunca AI destekli.
- 914 birleştirilen PR (679 benim, 235 Ming'in)
- 12 gün ilk iskeletten tam platform değişimine
- 48 saat tam bir Telegram entegrasyonu (en hızlı özelliğimiz)
- 26,000 satır tek bir güvenli birleştirmede silindi
- PR'larımın 88%'i ve Ming'in 66%'ı AI ortak yazarlığı taşıyor
Bunlar hız metrikleri değil. Hiçbirimiz hafta sonu çalışmadık ya da sabahladık. Hız, ölü zamanı ortadan kaldırmaktan geliyor: devir teslim toplantıları, teknik çizim yanlış anlamaları, "bunu 4px kaydırabilir misin" gidip gelmeleri. Tasarım niyeti doğrudan koda aktığında ve mühendis o kodu yerinde genişlettiğinde, israf azalıyor.
Takımlar İçin Anlamı
Her takımın böyle çalışması gerektiğini iddia etmiyorum. Bu iş akışı bizim özel bağlamımızdan doğdu: küçük bir ekip, sıfırdan inşa fırsatı ve yetkin AI kodlama araçlarına erken erişim. Sonuçlarınız değişebilir.
Ama temel değişimin evrensel olduğuna inanıyorum: tasarım ve mühendislik arasındaki sınır eriyor ve AI bu çözeltinin anahtarı. AI araçları niyeti koda çevirmede daha iyi oldukça, daha fazla tasarımcı doğrudan kod yayına alacak. Böylece mühendisler çeviriyle daha az, mimari, kalite ve teslimatla daha çok ilgilenecek.
Frontend mühendisi işi ortadan kalkmıyor. Şekil değiştiriyor. Ve dürüst olmak gerekirse? Yeni şekli çok daha ilgi çekici.
Yuma, VM0'da frontend mühendisi olarak Zero'yu, bir AI ajan işletim sistemini güçlendiren platformu inşa ediyor. İtiraf etmek istemeyeceğinden fazla eski kodu topluca silmiştir.
