Bitaksi CTO'su Engin Tanrıkulu ile yazılım ekiplerinin geleceği ve yapay zekanın ekipler, organizasyonlar ve üretkenlik üzerine etkileriyle ilgili bir söyleşi gerçekleştirdik. İşte sorularımız ve Engin Tanrıkulu'nun yanıtları.
Bir CTO olarak zamanınızın ne kadarını teknolojiye, ne kadarını insanlara ve organizasyona ayırıyorsunuz? CTO rolünün günümüzde artık daha az teknik, en çok insan ve yönetim odaklı hale geldiğini düşünüyor musunuz?
Benim zamanımın artık büyük kısmı doğrudan kod yazmaktan ziyade insanlar, organizasyon, ürün ve teknoloji stratejisi arasında geçiyor. Ama CTO rolünün daha az teknik hale geldiği fikrine tam katılmıyorum. Bence teknik olmanın şekli değişiyor.
Artık her pull request'i veya her mimari kararı sizin vermeniz gerekmiyor. Hatta vermemeniz gerekiyor. Ama hangi teknolojik yatırımı neden yaptığınızı, organizasyonun nerede teknik borç biriktirdiğini, bir sistemin neden ölçeklenmediğini veya AI'ın gerçekten şirkete değer üretip üretmediğini anlayabilecek teknik derinliğinizin olması gerekiyor.
Ben biraz bunu, teknolojiyi yapmak yerine teknolojinin doğru yapılabileceği organizasyonu kurmak olarak görüyorum. İyi CTO'nun görevi bütün cevapları vermek değil; doğru insanları, doğru ownership modelini ve doğru teknik standartları kurmak.
Genç yaşta büyük bir teknoloji ekibinin CTO’su olmak nasıl bir tecrübe? CTO olduğunuzda sizi en çok zorlayan konu ne oldu ve bugün olsa neyi farklı yapardınız?
CTO olduğumda en çok zorlandığım şey teknik problemlerden çok, organizasyonun nasıl çalışması gerektiğini doğru okumaktı.
Engineering geçmişinden geldiğinizde birçok iyi pratiği biliyorsunuz; global teknoloji şirketlerinin nasıl organize olduğunu, tribe modellerini, platform ekiplerini, engineering management yapılarını takip ediyorsunuz. Ama zaman içerisinde şunu daha net gördüm; bir şirkette çok iyi çalışan modeli alıp başka bir şirkete doğrudan uygulamak doğru değil. Şirketin büyüklüğü, ürünün yapısı, ekipteki seniority dağılımı, işin ne kadar operasyonel olduğu, şirket kültürü ve o dönemde çözmeye çalıştığınız problem tamamen farklı olabiliyor.
Bugün yeniden başlasam önce modeli tasarlamak yerine problemi daha uzun süre anlamaya çalışırdım. “Dünyada iyi engineering organizasyonları nasıl çalışıyor?” sorusundan önce, “bizim organizasyonumuzun şu anda neye ihtiyacı var?” diye sorardım.
Çünkü organizasyon tasarımı bence bir best practice uygulama işi değil. Sürekli değişen bir sisteme doğru yapıyı kurma işi.
Ve hâlâ en önemli ölçülerden biri benim için şu: Çünkü iyi bir CTO'nun başarısı, ekibin ona ne kadar bağımlı olduğuyla değil, ona ihtiyaç duymadan ne kadar doğru karar alabildiğiyle ölçülmeli.
50 kişilik bir engineering organizasyonunda “hız” ile “kalite” arasında nasıl bir denge kuruyorsunuz? Özellikle startup kültüründen daha büyük bir organizasyona geçerken hangi engineering pratiklerinin mutlaka oturması gerektiğini düşünüyorsunuz?
Ben hız ve kaliteyi birbirinin alternatifi olarak görmüyorum. Kısa vadede kaliteyi düşürerek hızlanabilirsiniz ama bunu birkaç ay yaptığınızda teknik borç nedeniyle aslında daha yavaş bir organizasyona dönüşüyorsunuz.
Organizasyon büyüdükçe bazı şeylerin kişilere bağlı olmaktan çıkması gerekiyor. Code review standardı, CI/CD, observability, incident management, post-mortem kültürü, test stratejisi ve servis ownership'i gibi konuların oturması gerekiyor.
Biz özellikle ownership tarafına önem veriyoruz. Bir takım sadece özellikler geliştirip başka bir ekibe atmamalı; geliştirdiği şeyin production performansından, latency'sinden, hata oranından da sorumlu olmalı.
Ama burada başka bir risk de var: süreç koyacağım diye organizasyonu yavaşlatmak. Ben mümkün olduğunca guardrail koyup bürokrasi koymamaya çalışıyorum. Standartlar güçlü olsun ama ekiplerin hareket alanı da geniş kalsın.
"Developer productivity" sizin için ne ifade ediyor? AI'ın kod yazma ve okuma gibi konularda birçok görevi otomatize ettiği bu yeni dönemde developer productivity anlamında neler artık daha önemli hale geliyor
Developer productivity, CTO olarak en yakından takip ettiğim konulardan biri. Çünkü bir engineering organizasyonunda “verimliyiz” demek kolay; asıl önemli olan bunu mümkün olduğunca somut sinyallerle görebilmek ve zaman içindeki gelişimi takip edebilmek.
Burada tek bir sihirli metriğe inanmıyorum. Commit veya yazılan kod satırı gibi metrikler tek başına developer productivity’yi anlatmaz. Biz PR lead time, code review akışı, throughput, katkı trendleri ve darboğazlar gibi farklı sinyallere birlikte bakıyoruz. Ancak bunların hiçbirini tek başına performans sonucu olarak kullanmıyoruz.
Bu metrikleri öncelikle takım ve organizasyon seviyesinde iş yapış biçimimizi iyileştirmek için kullanıyoruz. Bireysel seviyede ise kişinin performansına otomatik bir not vermek yerine; gelişim görüşmelerine, görünmeyen katkıların konuşulmasına ve yönetici değerlendirmesine veri sağlayan yardımcı sinyaller olarak ele alıyoruz.
Üstelik bunlar kapalı kapılar arkasında takip edilen metrikler değil. Kendi geliştirdiğimiz Developer Productivity Dashboard şirket içerisinde şeffaf şekilde açık; ekipler kendi metriklerini, trendlerini ve iyileştirebilecekleri alanları görebiliyor.
AI ile birlikte buraya yeni bir katman daha eklendi: AI adoption ve bunun engineering sürecine nasıl yansıdığı. Hangi araçların kullanıldığını ve AI kullanımının lead time, review akışı ve genel delivery çıktılarıyla nasıl bir ilişki gösterdiğini takip ediyoruz.
Bence son bir yıldaki değişim çok net: 2025’te soru “Developer’larınız AI kullanıyor mu?” idi. 2026’da soru artık “AI kullanımı ölçülebilir bir verim ve iş etkisi yaratıyor mu?”. AI adoption tek başına başarı değil. Önemli olan adoption’ın daha hızlı ve daha iyi sonuçlara dönüşüp dönüşmediğini görebilmek. Burada da korelasyonla nedenselliği birbirine karıştırmamak gerekiyor.
Çünkü AI kod üretmenin maliyetini ciddi şekilde düşürüyor. Daha fazla kod üretmek artık tek başına değerli değil; hatta yanlış kullanıldığında review ve bakım yükünü artırabilir. Bu nedenle önümüzdeki dönemde developer productivity açısından daha önemli hale gelecek konular; doğru problemin seçilmesi, teknik karar kalitesi, code review kalitesi, production ownership ve ortaya çıkan işin gerçek etkisi olacak.
Bitaksi’de taksi/ulaşım gibi gerçek zamanlı ve yüksek trafik alan bir uygulamada teknoloji ekibinin karşılaştığı en ilginç teknik problemler neler?
Mobility'nin ilginç tarafı, dijital bir ürün geliştiriyorsunuz ama sistemin diğer yarısı gerçek dünyada hareket ediyor. Örneğin sürücünün konumu sürekli değişiyor, trafik değişiyor, supply-demand dengesi birkaç dakika içerisinde değişebiliyor. Bir yolcu taksi istediğinde hangi sürücülere hangi sırayla teklif göndereceğiniz bile oldukça kompleks bir optimizasyon problemi.
Burada sadece backend'in hızlı olması yetmiyor. Teklif backend'den çıktıktan sonra sürücünün telefonunda görünmesine kadar geçen süre bizim için önemli. Bunun P95'ini ölçmek gibi uçtan uca metriklere bakıyoruz.
Bir diğer konu location accuracy. Haritada birbirine 20 metre yakın görünen yolcu ve sürücü gerçek hayatta yolun farklı taraflarında veya farklı seviyelerde olabiliyor. Ödeme, retry mekanizmaları, fraud, anlık trafik artışları ve sistemin bazı parçaları problem yaşarken yolculuk akışının devam edebilmesi de işin diğer tarafı.
Bu yüzden mobility bence distributed systems problemlerinin gerçek dünya ile birleştiği oldukça güzel bir engineering alanı.
“Yapay zeka sayesinde daha az developer'a ihtiyaç duyacağız” söylemine katılıyor musunuz?
Kısmen katılıyorum ama cümleyi biraz farklı kurarım. Bence aynı işi yapmak için daha az developer’a ihtiyaç duyacağız. Ama bu, dünyada daha az software developer olacak anlamına gelmek zorunda değil.
Bir özelliği eskiden beş kişiyle üç ayda yapıyorsanız, AI ile belki üç kişiyle bir ayda yapabileceksiniz. Şirket burada iki şey yapabilir: ekibi küçültür veya aynı ekiple çok daha fazla problem çözer.
Ben ikinci tarafın birçok teknoloji şirketinde daha güçlü olacağını düşünüyorum. Çünkü yazılım üretmenin maliyeti düştükçe yazılımla çözmeye değer problem sayısı da artıyor. Ama özellikle sadece verilen task’ı koda çevirmek üzerine kurulu developer profilinin ciddi baskı altında kalacağını düşünüyorum.
Developer’dan beklenen katma değer yukarı doğru çıkacak. Problem çözme, product thinking, system design, karar kalitesi ve ownership daha önemli hale gelecek.
Önümüzdeki 2–3 yıl içinde AI'ın software engineering ekiplerini nasıl değiştireceğini düşünüyorsunuz? Sizce bugünkü developer rollerinden hangileri ciddi şekilde dönüşecek, ne gibi farklı konularda çalışan ihtiyaçları doğabilir?
Bence en büyük değişiklik developer’ın “code writer” olmaktan çıkması olacak. Kod yazmak engineering işinin giderek daha küçük bir parçası haline geliyor. Developer daha fazla problemi tanımlayan, sistemi tasarlayan, AI’ın ürettiği işi değerlendiren ve production sonucunu yöneten kişi olacak.
Özellikle junior seviyedeki tekrarlı development işleri, manuel QA ve basit implementation işleri ciddi şekilde dönüşecek. Buna karşılık architecture, product thinking, debugging, security ve system design daha değerli hale gelecek.
Yeni roller de göreceğiz. AI platform engineering, agent ve model evaluation, AI observability ve AI security gibi bugün daha niş olan alanların büyümesini bekliyorum.
Bir diğer önemli değişim de takım yapılarında olacak. Uzun yıllardır teknoloji dünyasında “two-pizza team” kavramını konuşuyoruz; yani iki pizzayla doyabilecek kadar küçük ve otonom ekipler. Ben AI ile birlikte bunun daha da küçüleceğini düşünüyorum.
Bizim sektör üzerinden söylemek gerekirse, belki artık “bir taksiye sığabilecek takımlar” göreceğiz. Bu takımların içinde sadece developer da olmayacak. Product, growth, design ve engineering arasındaki sınırlar daha geçirgen hale gelecek. Üç-dört kişilik, farklı yetkinlikleri olan bir ekip AI araçlarıyla bugün çok daha büyük ekiplerin yaptığı işi uçtan uca yapabilecek.
Dolayısıyla önümüzdeki dönemin güçlü organizasyonlarının daha büyük değil, daha küçük ama çok daha yüksek leverage’a sahip takımlardan oluşacağını düşünüyorum.
Önümüzdeki 5 yıla bir CTO olarak baktığınızda sizi en çok heyecanlandıran ve en çok düşündüren konu ne?
Beni en çok heyecanlandıran şey AI’ın artık sadece kullanılan bir araç olmaktan çıkıp şirketlerin operating modelinin bir parçası haline gelmesi. Bugün şirket sistemlerine bağlanan ve belirli işleri uçtan uca yapabilen agent’ları görmeye başladık. Önümüzdeki birkaç yılda asıl fark, bunların daha güvenilir, daha otonom ve günlük iş akışlarının doğal bir parçası haline gelmesi olacak.
CTO açısından bence önemli değişim şu: sadece müşteriye yönelik ürün geliştirmeyeceğiz, şirketin kendi çalışma biçimini de giderek daha fazla software’e çevireceğiz.
Beni düşündüren tarafı ise kontrol ve bağımlılık. AI ne kadar fazla karar verir ve aksiyon alırsa; security, observability, yetkilendirme ve governance o kadar kritik hale gelecek. Bir yandan da organizasyonun kendi engineering judgement’ını kaybetmemesi gerekiyor. Benim için önümüzdeki beş yılın temel sorusu şu: Bir şirketi ne kadar AI-native hale getirebiliriz ve bunu yaparken kontrolü ve teknik muhakemeyi nasıl koruruz?
Değerli görüşleri için sayın Engin Tanrıkulu'na teşekkürlerimizi sunuyoruz.