Devart’tan Anton Onufriienko, Genel Müdür – Röportaj Serisi

Anton Onufriienko, Devart’ın Genel Müdürü, derin bir şekilde yazılım işlerini ölçeklendiren, gelir büyümesini sağlayan ve SaaS, entreprise yazılımı ve finansal hizmetler gibi sektörlerde büyük çaplı çapraz fonksiyonel ekipleri yöneten bir teknoloji yöneticisi ve operatördür. Kariyeri boyunca, satış organizasyonları kurmaktan ve startup’ları başlatmaktan, büyük iş birimleri için tam P&L operasyonlarını denetlemeye kadar ilerlemiştir. Devart’ın en büyük bölümünün başında 130’dan fazla çalışanı yönetmiştir. Genel Müdür olmadan önce, Devart’ın Chief Revenue Officer ve Satış Başkanı olarak görev yaptı ve burada pazara girme stratejisi, fiyat dönüşümü ve uluslararası büyüme girişimlerini yönetti. Ayrıca, hizmet odaklı işletmelerin operasyonel netlik kazanmasına yardımcı olan bir zaman takip ve karlılık platformu olan TMetric’in CEO’sudur.

Devart bir yazılım şirketidir ve veritabanı geliştirme, veri bağlantısı, entegrasyon ve geliştiriciler, DBA’lar, analistler ve entreprise ekipleri için üretkenlik araçları konusunda uzmanlaşmıştır. 1997 yılında kurulan şirket, SQL Server, MySQL, Oracle (ORCL ) ve PostgreSQL gibi büyük veritabanı sistemlerini destekleyen dbForge veritabanı yönetim araçları seti ile bilinir. Devart ayrıca, ODBC, ADO.NET, Python ve Delphi bağlayıcıları gibi veri bağlantısı çözümleri geliştirir ve Skyvia adlı bulut tabanlı, kod gerektirmeyen bir veri entegrasyonu platformunu sunar. Şirket, Fortune 100 organizasyonlarının büyük bir kısmını da içeren 500.000’den fazla kullanıcıya hizmet vermektedir ve ürünlerine AI özelliklerini entegre etmeye odaklanmıştır.

Satış organizasyonları kurmaktan ve yönetmekten, tam P&L operasyonlarını yönetmeye ve şimdi de Devart’ın en büyük iş birimini yönetmeye kadar nasıl bir yolculuk geçirdiniz? Bu yolculuk, ürün stratejisi ve karar alma sürecinde AI entegrasyonuna yaklaşımınızı nasıl şekillendirdi?

Satış, her şeyin ROI’sini ölçmemi öğretti. CRO rolüne geçiş yaptığımda, bu disiplini fonksiyonlar boyunca ölçekledim. İş birimi yöneticisi olarak, AI itself için de bunu uyguladım.

AI’ye pratik bir bakış açısına sahibim. Şüpheci değilim, dört ürünümüzün üçü 2026 için AI-yerli. Ancak hype, gerçek ve kalıcı sonuçların önüne geçiyor.

Endüstrinin genellikle nerede yanlış gittiğini özetleyen bir meme var. Şirketler, 400 dolarlık SaaS aboneliklerini, API ücretleri için 1000 dolar ayda maliyeti olan ve sürekli düzeltme gerektiren yerli araçlarla değiştiriyor. Bu, gerçek bir değişiklik değil, sadece pahalı bir gösteri.

Satışta öğrendiğim ders basit: Her girişim, kendi yolunu ödemeli veya ölmalı. AI dağıtımını da aynı şekilde yönetiyorum, từng satış bölgesini yönettiğim gibi. Her akış için açık ROI hipotezi, üç dalga dağıtımı ve ölçeklendirmeden önce ölçülen etki.

Kuzey Yıldızı metriğimiz, Çalışan Başına Gelir’dir ve 2028 yılı sonuna kadar bunu ikiye katlamak hedefimiz. Bu açığı kapatmak için işe alımlar yapılmaz, işin niteliği değiştirilir ve AI, bu büyüklükte gerçekçi bir mekanizmadır.

AI girişimlerine karşı filtre, aynı: Ölçülen değer nedir, kim öder, ve nasıl çalıştığını biliriz? Bu üç soruya cevap veremeyenler üretim için uygun değildir. Yanlış gidenlerin maliyeti nhanh bir şekilde birikir ve çoğu şirket, pahalı bir şekilde öğrenecektir.

Devart, veritabanı araçları ve geliştirici üretkenliği konusunda güçlü bir üne sahiptir. Bu ürünleri, yüzey düzeyinde otomasyondan ziyade gerçek değer sunan bir şekilde AI ile nasıl entegre ediyorsunuz?

Kullanıcılarımız, hardcore teknik uzmanlarıdır: DBA’lar, senior mühendisler, veri mimarları. Yüzey düzeyinde otomasyonu saniyeler içinde tespit eder ve pazarlama oyuncakları gibi inovasyon olarak satılan şeylere karşı tepki gösterir. İki yıl önce, AI hype zirve yaptığı ve rakiplerinin her UI unsuruna sohbet panellerini eklemeye çalıştığı zaman, bu kalıba uymak için bir teşvik vardı. Ancak mobil, bulut, düşük kod gibi önce gördüğüm kalıpları tekrar etmekten kaçındım.

Disiplin basittir: Müşteri değeri önce. Talep edilmeyen AI özelliklerini inşa etmek, gerçek değeri sunmayan, sınırlı mühendislik kaynaklarının en kötü kullanımıdır. Bu özellikle teknik uzmanların hemen fark edebileceği bir kitle için geçerlidir.

2026’da neler değişti? AI, hype’den gerçek bir teknik devrime geçti. 2023’te bu sistemlerin yapabildiği şeyler ile bugün yapabildikleri arasındaki fark, artımsal değil. Tamamen farklı bir yetenek kategorisidir. Artık önceden çözülemeyen sorunları çözebiliriz: AI ajanları için güvenli entreprise veri erişimi, geliştiricinin IDE’si içindeki bağlamsal veritabanı zekası ve ayrı bir analiste gerek kalmayan otomatik iş analitiği.

Bunlar, AI sayesinde çözülebilen temel sorunlara dayanan yeni ürün hatlarıdır. Endüstrinin, iki yıl boyunca sohbet panellerini “AI ürünleri” olarak adlandırdığını görüyoruz. Bunlar, özellikler, ürünler değil.

Uzun sürdü, çünkü doğru yapmak istedik. Sonraki on iki ay, disiplininin ödendiğini gösterecektir.

AI, giderek daha fazla kod yazıyor, optimize ediyor ve hataları düzeltiyor. Veritabanları ile çalışan geliştiricilerin rolünü, önümüzdeki birkaç yıl içinde nasıl değiştirecektir?

SQL sözdizimi bilmenin değeri hızlı bir şekilde azalıyor. AI, karmaşık çoklu tablo JOIN’lerini saniyeler içinde oluşturabiliyor ve günlüklerden eksik indeksleri dakikalar içinde tanımlayabiliyorsa, bir mühendisin değeri artık SQL yazmakla ölçülmez. Bu işin bir kısmı artık bir komodite haline geliyor.

Ancak burada kritik bir nuans var ki, total otomasyonun savunucuları bunu her zaman atlar. Bir AI hatası, ön tarafta yanlış hizalanmış bir düğme olabilir, ancak veritabanında bir AI hatası, üretim ortamının silinmesi, PII sızıntısı veya tüm işin işlemsel olarak durması olabilir.

Veritabanları durum tutar. Hallüsinasyonlara müsamaha göstermezler.

Bu asimetri, rolü tamamen yeniden tanımlar. Önümüzdeki iki veya üç yıl içinde, veritabanı geliştiricileri ve DBA’lar, kod yazarlardan mimarlara ve denetçilere dönüşecekler. Birincil işleri, AI’nin kendi başına akıl yürütemediği güvenilir mimarileri tasarlamak, üretim sistemlerine dokunan AI ajanları için sert sınırlar ve güvenlik politikaları ayarlamak ve makinelerin ürettiği kodu gözden geçirmek ve denetlemek olacaktır.

• İş bağlamından yoksun olduğu için yapay zekânın tek başına akıl yürütemeyeceği güvenilir mimariler tasarlamak.
• Üretim sistemlerinde yapay zekânın yapabileceklerini ve yapamayacaklarını belirleyen katı koruyucu sınırlar ve güvenlik politikaları oluşturmak.
• Yapay zekânın ürettiği değişiklikleri gerçek veriye ulaşmadan önce denetlemek, doğrulamak ve onaylamak.

Mental modelim: Mühendisler, AI asistanlarının ordularını yönetecekler. Araçlar gibi dbForge, geleneksel IDE’lerden komut ve denetim merkezlerine dönüşecek. İş, SQL yazmaktan ziyade AI’nin ürettiği kodu gözden geçirmek, doğrulamak ve AI’nin güvenli bir şekilde geçemeyeceği sınırları uygulamaya dönüşecek.

Profesyonel fırsat burada önemli. Mimarlık ve denetime doğru seviye atan geliştiriciler, piyasa değerlerini katlayacaklar. AI üretkenliği ve üretim güvenliği arasındaki kritik katman olacaklar. Veritabanı uzmanlığının primi kaybolmayacak, ancak tasarım, yönetim ve yargıya doğru kayacak, ki AI burada tek başına çalışamaz.

Şu anda veritabanı yönetiminde AI araçlarının en büyük sınırlamaları nelerdir ve anlamlı atılımlar nereden gelecektir?

Şu anda AI, yüzey düzeyinde otomasyonda takılmış durumda. Temel bir SELECT sorgusunu veya kalıp kodunu üretmek artık etkileyici değil. Daha büyük sorun, AI sistemlerinin hala kör bir daktilo gibi davranması, yani sentaksı üretebilmesi ancak çevrelerini gerçekten anlamaması. Gerçek atılım, AI’nin birlikte bağlam, bağımlılık, durum ve iş mantığını akıl yürütebildiğinde gerçekleşir.

Şu anda, veritabanı ortamlarında AI’yi engelleyen üç büyük sınırlama görüyorum.

İlk olarak, bağlam problemi var. Büyük dil modelleri, şemaları, DDL’leri ve sütun isimlerini görebilir, ancak yürütme planlarını, indeks parçalanma kalıplarını, veri dağıtım kalıplarını veya veri arkasındaki gerçek iş mantığını anlamazlar. Bu daha derin anlayış olmadan, birçok optimizasyon tavsiyesi istatistiksel tahminlere dönüşür.

İkinci olarak, hayaller problemi var ve entreprises, veritabanı katmanında neredeyse sıfır toleransa sahiptir. Bir JOIN’u yavaşlatabilir veya kritik kayıtları silebilecek bir hata, çok pahalı olabilir. Bu düzeyde, küçük doğruluk hataları bile çok hızlı bir şekilde pahalı hale gelebilir.

Üçüncü sorun, güvenlik ve yönetim. Ciddi bir entreprise, üretim şemalarını veya PII’yi bir AI aracına yapıştırmadan önce, güçlü veri izolasyonu ve kontrol garantileri isteyecektir. AI benimsenmesi, bu sorun çözülmeden sınırlı kalacaktır.

Anlamlı atılımlar, AI’nin sentaks üretmekten öte, bir arka plan mimarı veya analisti gibi çalışmaya başladığında gerçekleşecektir.

Bir kısmı, anlamsal katmandır: Ham tablo isimlerinden gerçek iş anlamlarına geçmek. Sadece “table_users” değil, müşteri kohortları, terk riski veya Q3 LTV trendleri gibi kavramlar.

Diğer bir değişim, AI’nin bir senior DBA gibi arka planda çalışmasıdır. Sürekli olarak iş yüklerini analiz etmek, darboğazları tanımlamak, indeksleri önermek, riskli sorguları tespit etmek ve sistemlerin bozulmasından önce sorunları yakalamak.

Son olarak, makine-makine operasyonları var: Özerk ajanlar, veritabanı yükünü izler, optimize stratejilerini izole edilmiş ortamlarda test eder ve insan denetimi altında geliştirmeleri dağıtırlar.

Bu gelişmeler, veritabanı araçlarının gelecek beş yılını şekillendirecektir.

Gelir ve pazara açılma stratejisine liderlik etme deneyiminize göre yapay zekâ, yazılım şirketlerinde fiyatlandırma modellerini, ürün paketlemeyi ve müşteri edinimini nasıl yeniden şekillendiriyor?

Geleneksel pazara açılma yöntemi artık işlemiyor. Bunu hem kendi rakamlarımızda hem de geliştirici araçları kategorisinin tamamında görüyoruz.

Klasik müşteri ediniminin sonu. 2026’da ürünlerimizin arama sıralamalarında anlamlı iyileşmeler elde etmemize rağmen sıfır tıklama gerçeğiyle karşı karşıyayız. Yapay zekâ destekli arama, yanıtları doğrudan sonuç sayfasında veriyor ve web sitelerini trafikten mahrum bırakıyor. Güçlü sıralamalar artık iki yıl önceki gibi potansiyel müşteriye dönüşmüyor.

Beş yıl önce güçlü bir içerik stratejisi büyümeyi sağlamak için yeterliydi. Bugün bu yalnızca temel bir gereklilik. LLM’ler yanıt oluştururken marka gücünü, olumlu anılmaları ve topluluk yoğunluğunu tartıyor. Markanız görünür ve güvenilir değilse yapay zekâ sistemleri sizi düzenli olarak göstermeyi bırakıyor. Yalnızca trafiği kaybetmiyorsunuz; satın alma yolculuğundan bütünüyle siliniyorsunuz. Daha da kötüsü, tüm pazar panikle ücretli reklamlara yöneldi; bu da tıklama başı maliyetleri akıl almaz düzeylere çıkarıp çoğu SaaS şirketinin birim ekonomisini sessizce yok ediyor.

Bu değişim geleneksel geliştirici araçları şirketlerini özellikle sert vuruyor. Bir B2B SaaS kuşağını finanse eden SEO odaklı edinim kanalları hızla verim kaybediyor. Bunları hâlâ başlıca büyüme aracı olarak kullanan herkes şimdiden alternatifler geliştirmeli: ekosistem dağıtımı, topluluk ve ortaklıklar.

Fiyatlandırmanın evrimi: kullanıcı başına modelden PLG 3.0’a. Ürün odaklı büyümenin bir sonraki aşamasına giriyoruz. Tek bir yapay zekâ ajanı birden fazla çalışanın işini yapabildiğinde kullanıcı başına fiyatlandırma bozulmaya başlar. Böyle bir ortamda çalışan sayısına göre ücretlendirme anlamını yitirir. Ürünlerini çalışan sayısı yerine değer etrafında yeniden paketlemeyen şirketler önümüzdeki 24 ayda aylık yinelenen gelirlerini hızla kaybedecek.

Bir sonraki adım PLG 3.0’dır: kurumsal yazılımı bir insanın değil, özerk bir yapay zekâ ajanının değerlendirdiği, test ettiği ve satın aldığı an. Bu kalıbın kitlesel benimsenmesine birkaç yıl var; ancak ürünleri ve fiyatlandırmayı makine alıcı için tasarlamak 2028’in değil, 2026’nın işidir.

Birçok kuruluş yapay zekâ denemelerinden üretimde gerçek etkiye geçmekte zorlanıyor. Yapay zekâ girişimlerinin gerçekten başarılı olup olmayacağını belirleyen temel etkenler nelerdir?

Çoğu yapay zekâ özelliği daha inşa edilmeden başarısız olur. Başarısızlık, kullanıcılar talep ettiği için değil, yönetim kurulu bir yapay zekâ hikâyesi istediği veya pazarlama yeni bir kitle çekeceğini düşündüğü için birinin “bu üründe yapay zekâya ihtiyacımız var” dediği odada başlar. Çoğu yapay zekâ girişiminin ilk günahı budur ve sonrasında gelen her şeyi şekillendirir.

Yapay zekâyı deneme aşamasından üretimde gerçek etkiye taşıyamayan şirketlerde aynı hataların tekrarlandığını görüyorum.

İlk hata, kimsenin istemediği yapay zekâ özellikleri geliştirmektir. Gerçek bir kullanıcı ihtiyacı olmadan bir yapay zekâ özelliği zorunlu kılındığında ekip, bir kullanım alanı uydurmak için teknolojiden geriye doğru çalışır. Sonuç tahmin edilebilir: mevcut arayüze eklenmiş bir sohbet paneli, işi zorlaştıran bir otomatik tamamlama veya kullanıcının kendi yazabileceğinden daha kötü çıktı üreten bir “özetle” düğmesi. Bu özellikler yayımlanır, basın bülteni alır ve tüm benimsenme tahminlerinin sessizce altında kalır. Daha derin zarar ise kullanıcıların gerçekten istediği özelliklere ayrılması gereken mühendislik kapasitesini tüketmeleridir.

İkinci sorun, ekiplerin temiz demo verisiyle gerçek üretim verisi arasındaki farkı büyük ölçüde küçümsemesidir. Yapay zekâ demoları temiz ve seçilmiş örneklerle çalışır. Üretim ise müşteri verilerinin gerçek karmaşasıyla çalışır: yinelenen kayıtlar, eksik alanlar, aynı ürün adının on farklı yazılışı ve on beş yıllık eski uç durumlar. Değerlendirmede etkileyici doğruluğa ulaşan bir model, canlı veride ciddi biçimde bozulabilir; çoğu ekip bunu ancak kullanıcılar şikâyet ettiğinde fark eder. Üretim güveni açısından bu keşfin maliyeti nadiren telafi edilebilir.

Bir diğer yaygın başarısızlık noktası kullanıcı araştırmasıdır. Standart ürün görüşmeleri yapay zekâ özelliklerinde işe yaramaz. Kullanıcılar yapay zekâdan ne istediklerini ifade edemez, çünkü neyin mümkün olduğunu bilmezler. “X’i yapmak için yapay zekâ kullanır mıydınız?” sorusu, benimsemeyi öngörme değeri taşımayan nazik evet yanıtları üretir. Etkili yapay zekâ ürün araştırması prototip göstermeyi, gerçek kullanımı gözlemlemeyi ve yenilik etkisi geçtikten sonra kullanıcıların geri dönüp dönmediğini ölçmeyi gerektirir. Çok az ürün ekibi araştırma uygulamalarını buna göre yeniden kurdu; 2026 sorunlarına hâlâ 2019 yöntemleri uyguluyorlar.

Son olarak birçok şirket iş etkisi yerine yapay zekâ etkinliğini ölçüyor. “Bu hafta iki yüz kişi yapay zekâ özelliğini kullandı” bir benimsenme metriğidir, etki metriği değil. Gerçek etki; döngü süresinin kısalması, kalitenin artması, gelir üretilmesi veya maliyetin ortadan kaldırılmasıdır. Yapay zekâ özelliğinden gelir tablosundaki bir rakama düz bir çizgi çekemiyorsanız üretim etkisine değil, pahalı bir etkinliğe sahipsiniz.

Giderek daha kritik hâle gelen ve çoğu ürün ekibinin bütünüyle gözden kaçırdığı beşinci bir etken daha var.

Uyumluluk ve yapay zekâsız geliştirme yolu. Finans, sağlık, kamu, savunma ve hukuk alanlarındaki kurumsal kullanıcıların önemli bir bölümü, tedarikçi yazılımlarında yapay zekâ özelliklerini yasaklayan veya sınırlayan politikalar altında çalışıyor. Ürününüz yapay zekâyı devre dışı bırakma ya da atlama yolu olmadan temel deneyime sıkıca bağlıyorsa yapay zekâ ekleyerek kitlenizi genişletmez, mevcut kitlenizin bir bölümünü kaybedersiniz.

AI Connectivity ile çözdüğümüz sorun tam olarak budur. Düzenlemeye tabi sektörlerdeki uyumluluk ekipleri yapay zekânın kendisine karşı çıkmıyor; verinin kendi güvenlik sınırlarının dışına çıkmasına karşı çıkıyor. Çözüm yapay zekâyı kaldırmak değil, bu kuruluşlara kısıtlarına uyan bir yapay zekâ mimarisi sunmaktır. AI Connectivity bu nedenle şirket içinde kurulur: yapay zekâ yeteneği korunur, veri müşterinin altyapısından hiç çıkmaz ve satın alma süreci üçüncü tur yerine ilk incelemede onaylanır.

Bunu doğru yapan ekipler ilk günden uyumluluğu gözeterek mimari kurar. Yanlış yapanlarsa sorunu, anlaşma zaten kaybedildikten sonra satın alma incelemesinde keşfeder.

Devart, birden fazla veritabanı ekosisteminde çalışıyor. AI, farklı platformlar arasındaki veri yönetimini nasıl basitleştirebilir?

Ağrı gerçek. Bir tipik Fortune 500, aynı anda sekiz ila on iki farklı veritabanı motorunu çalıştırır: Finans için miras Oracle, yeni hizmetler için PostgreSQL, operasyonlar için SQL Server, analitik için Snowflake veya BigQuery ve artan olarak bir vektör deposu için gömme. Her birinin kendi lehçesi, kendi araçları ve kendi yönetim rejimi vardır. Bir geliştiricinin bu ortama katılması, sadece veri nerede yaşadığını ve kimin dokunmasına izin verildiğini öğrenmek için üç ay sürebilir.

AI, bu karmaşıklığı tek başına çözmez. Verilen bağlamı amplifiye eder. Sekiz bağlantısız veritabanı, sekiz bağlantısız öneri seti üretir. Bu, entreprise AI dağıtımlarında gördüğümüz başarısızlık modudur.

Fırsat, AI ajanları ve altındaki veritabanları arasındaki bir bağlam katmanıdır. Bu, tümüne hitap eder, meta verileri normalize eder, birleşik yönetim politikalarını uygular ve her AI ajanının, iç veya dış, tüm mülke tutarlı kurallarla çalışmasını sağlayan temiz bir MCP arabirimi sunar.

Bu, AI Bağlantısı ile inşa etmeye çalıştığımız mimaridir: Çoklu veritabanı desteği olan bir ön uç MCP sunucusu, AI ajanlarının hepsinin öğrenmesi yerine iş tanımlarını bir kez yakalayan anlamsal bir katman, SQL işlemi düzeyinde rol tabanlı erişim kontrolü ve tam denetim günlükleri.

Basitleştirme ücretsiz değil. Birisi hala semantik katmanı modellemeli ve politikaları ayarlamalıdır. Ancak bu iş bir kez yapılır, her AI ajanı için değil.

Büyük çaplı çapraz fonksiyonel ekipleri yönettin. AI, ürün, mühendislik, pazarlama ve satış arasındaki iç işbirliği ve karar alma süreçlerini nasıl değiştiriyor?

Çapraz fonksiyonel sürtüşmenin çoğu, aslında insanların diğer ekiplerden bilgi beklemesinden kaynaklanıyordu. AI, bu sürtüşmeyi daha hızlı bir şekilde çözer.

Değişimler pratiktir ve hemen gerçekleşir.

Ürün ve mühendislikte: Bir ürün yöneticisi, iş terimleriyle bir veritabanı sorusu sorar, “en iyi üç fiyatlandırma katmanımızdaki LTV varyansı nedir?” ve hemen eyleme geçirilebilir bir cevap alır, yerine analitik bir Jira bileti açıp üç gün beklemeye gerek kalmaz.

Pazarlama ve veride: Kohort analizi, istek sırasına göre değil, aynı anda gerçekleşir. Pazarlama yöneticisi, sayıları alır, kampanyayı oluşturur, tüm bunları aynı sabah içinde yapar.

Satış ve mühendislikte: Teknik cevaplar, artık senior bir mühendis ile görüşme ayarlamak gerekmez. Satış temsilcisi, gerçek bir teknik cevap alır ve satış döngüsü daralır.

Kararlar, konuşma içine girer, takip eden toplantılara girmez. “Bunu size döneceğim” kalıbı ölür. Toplantılar kısalır, çünkü AI, önceden okunacakları ve özetleri, her oturumun ilk yarısında tüketilen şeyleri ele alır.

Bu sürtüşme çöküşü, daha derin bir yönetim değişimi zorlar ve bu, çoğu liderlik ekibinin olduğundan daha fazla.

Her şirket, sonuç odaklı olduğunu iddia eder, ancak altına bakıldığında, çoğu hala vekil ölçütlere göre çalışır: Hikaye noktaları, kod satırları, kapatılan biletler, kayıtlı saatler. Etki alanı, gerçek değeri ölçmek zordu, bu yüzden faaliyeti değer yerine bir vekil olarak kullandık. AI, bu vekil’i kalıcı olarak bozar. Bir ajan, 10.000 satır kod yazabilir veya bir dakikada 500 destek bileti kapatabilir, faaliyeti ölçmek tehlikeli bir şekilde yanıltıcı hale gelir.

Açıkça Gerçek Sonuç Odaklı Yönetime geçiyoruz; burada performans yalnızca sonuç ve muhakemeyle ölçülüyor. Uygulamada acımasızdır, çünkü çoğu performans sistemi bunun için kurulmamıştır. Daha önce yüksek etkinliğin arkasına saklanan insanlar hemen görünür hâle gelir ve liderliğin bu görünürlüğe göre hareket etmeye istekli olması gerekir.

Yapısal sonuç, daha düz örgü şemalarıdır. Koordinasyon ve bilgi yönlendirme katmanları daralır. Uyum sağlayan organizasyonlar, yapısal olarak daha az insanla daha yüksek bir etkiye sahip olacaktır.

AI destekli geliştirme ve kod gerektirmeyen araçların yükselişi ile, veritabanı yönetimine erişimi olmayan kullanıcılar için bir gelecek mi inşa ediyoruz?

Endüstride şu anda tehlikeli bir karışıklık var. İnsanlar, küçük bir yeşil alan projesinin veritabanını ve bir entreprise’nin miras veritabanını aynı şey gibi ele alıyorlar. Değiller.

Küçük yeşil alan projeleri için, demokratikleşme zaten burada. Kişisel olarak, derin veritabanı yönetim becerilerine sahip olmadan küçük uygulamalar inşa ettim. Şema, bir LLM’nin bağlam penceresine sığıyorsa, AI gibi bir sihir gibi çalışır. İç araçlar inşa eden vatandaş geliştiriciler, küçük ölçekte bir gerçek ve büyüyen kategori olacaktır.

Enterprise gerçekliği tamamen farklı. Büyük miras veritabanları, büyük monolitik kod tabanları ile aynı problema sahiptir: Bağlam duvarı. On beş yıllık şema evrimi, veritabanları arası bağımlılıklar ve özel tetikleyici mantığını bir promotifte yakalamak mümkün değildir. Büyük bir veritabanında AI, bağlamı kaybettiğinde, hallüsinasyonlar güzel bir şekilde bozulmaz, üssel olarak çoğalır.

Altı çizilen risk, büyük ölçekte yanlış güven. Doğal dil arayüzleri, inandırıcı ancak nüanslı olarak yanlış cevaplar üretmeye özellikle iyidir. Bir SQL sorgusunda bir sözdizimi hatası varsa, bir hata mesajı alırsınız. Bir doğal dil arayüzü, “etkin müşteriler” gibi altı farklı tanımının olduğunu veri nedeniyle yanlış yorumlarsa, bir sayı alırsınız. Sayı güzel görünür, ancak %30 yanlış olabilir. Kullanıcı, bunu bilmeyecektir.

Öyleyse, entreprise veritabanı yönetimi, büyük ölçekte veritabanı yönetimine erişimi olmayan kullanıcılar için bir oyun alanı haline gelmeyecek.

Citizen DBA, büyük ölçekte bir efsanedir.

Gelecek, uzman veri mimarlarına aittir, bunlar AI’nin güvenli bir şekilde çalışmasını sağlayan altyapıyı inşa eden profesyonellere aittir. Bu, Insightis’e inşa ettiğimiz temel mimaridir. Bunu yapmadan, erişilebilirlik bir yük haline gelecektir.

Yapısal çözüm semantik katmandır: iş tanımlarının bir kez sabitlendiği ve her yapay zekâ etkileşiminde yeniden kullanıldığı kontrollü bir sözlük. Bu katman, doğal dil erişimini üretim verisine karşı güvenli hâle getiren koruyucu sınırdır. Bunu profesyonel araçlar olmadan kuramazsınız ve koruyamazsınız.

İleriye bakıldığında, bir “AI-yerli” geliştirme aracı seti nasıl görünür ve ekipler bu değişime bugün nasıl hazırlanmalıdır?

Gerçek bir AI-yerli araç seti, bir IDE’ye takılan bir sohbet arayüzü değil. Bugün pazarlanan “AI-yerli” olanın çoğu, bir sohbet arayüzü ve bir otomatik tamamlama modelidir. Bu, temel gereksinimler, değil, varış noktası.

Bana göre, gerçekten AI-yerli bir araç seti, üç şeye ihtiyaç duyar.

İlk olarak, AI’ye derin bağlam gerekir. Kod tabanınızı, altyapınızı, geçmiş kararlarınızı ve veri ortamınızı sürekli olarak anlamalıdır, sadece sohbet penceresine yapıştırılan promotifler aracılığıyla değil. Şu anda çoğu araç, bu testi geçemez. Bağlamı, her oturumda yeniden inşa etmek zorunda kalırlar ve kullanıcı, bunu sürekli olarak ödemek zorundadır.

İkincisi, araçlar birbirleriyle düzgün bir şekilde iletişim kurmalıdır. IDE’niz, veritabanınıza, veritabanınız observability yığınına, CI/CD’niz AI incelemesine konuşmalıdır. Model Context Protocol, burada standart bir katman haline geliyor, 2026’nın ilk çeyreğinde 97 milyon SDK indirme sayısı ile, 2024’ün sonlarında 100.000’den 15 ayda 970 kat artış.

Üçüncüsü, üretim sınıfı AI, ciddi güvenlik sınırlarına ihtiyaç duyar. Yıkıcı operasyonlardan önce patlama yarıçapı önizlemesi. Bağımlılık analizi. Otomatik geri alma planları. Denetim günlükleri varsayılan olarak. AI’nin bu olmadan üretimde tehlikeli olacağını unutmamak önemlidir.

Nasıl hazırlanılır, somut olarak.

Yığınınızı, bu üç bileşen karşılaştırarak denetleyin. Her araç, API’lerini ve MCP’yi ortaya koyar mı, yoksa bir kulenin içinde mi kalır? Güvenlik kontrolleri var mı? İki şartı karşılamayan araçlar, kısa vadeli varlıklardır.

Bağlam altyapısını şimdi inşa edin. Şemayı, iş tanımlarını ve mimari kararlarını makine tarafından okunabilir formatlarda belgeleyin. Zengin bağlam, bir çeyrekte inşa edilmez. 2027’de AI’nin buna sahip olan ekipler, bugün belgeleyenlerdir.

Üretimde AI’yi, hazır olmadan önce çalıştırın. Resmi bir “AI stratejisi” olmadan önce gemi yapan ekipler, already öğrenen ekiplerden 18 ay geride kalacaktır. Düşük riskli bir kullanım durumu seçin. Gemiyi çalıştırın. Kasları inşa edin.

Bugün bu kararları veren ekipler, yazılımın inşa edilişinin gelecek on yılını tanımlayacaktır. Pencere dar ve şu anda açıktır.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Devart ziyaret edebilir.