Yazılım Mühendisliği Ölmüyor: Vibe Coding’den Agentic Engineering’e

1878’de Sir William Preece telefonu reddetti. Bugün aynı hikâye yazılımda tekrarlanıyor.

1878’den Bir Ders

1878’de İngiliz Posta İdaresi’nin Baş Mühendisi Sir William Preece, bir parlamento komisyonu önünde şu soruyla karşılaştı:

“Telefon gelecekte halk tarafından yaygın olarak benimsenecek mi?”

Verdiği cevap tarihin en kötü teknoloji tahminlerinden biri oldu:

“Amerikalıların telefona ihtiyacı var, bizim yok. Postayı dağıtacak bol miktarda ulak çocuğumuz var.”

İşin ironik yanı şu: Telefonu İngiltere’ye getiren kişi Preece’in ta kendisiydi. Teknolojiye yabancı değildi. Sadece dünyanın değiştiğini kabul etmeyi reddetti.

147 yıl sonra, yazılım mühendisliğinde birebir aynı sahnenin yaşandığını izliyorum.

“Kodumu Kendim Yazarım, AI’a İhtiyacım Yok”

Son zamanlarda bunu giderek daha sık duyuyorum. AI araçlarını kullanan mühendisleri “tembel” ya da “gerçek geliştirici değil” diye etiketleyen, giderek büyüyen bir grup var. Her yeniliği test etmeden, denemeden ya da anlamaya çalışmadan reddediyorlar.

Diğer uçta ise başka bir aşırılık var: bir prompt yazmanın kusursuz bir ürün ortaya çıkaracağına inananlar. “Vibe coding” tam olarak budur — hisle kod yazmak. Temel bilgi yok, çıktıyı sorgulamak yok, sadece üretmek var.

Geçenlerde Lex Fridman’ın podcast’inde Peter Steinberger (OpenClaw’ın yaratıcısı) iki uca da doğrudan değindi. Mesajı netti: AI agent kullanmak “vibe coding” değil. Bu bir mühendislik disiplini. O buna Agentic Engineering diyor.

Körü körüne reddetmek değil. Körü körüne güvenmek değil. Agent’ları mühendislik titizliğiyle yönetmek.

Neden “Prompt Yazmak” Yetmiyor

Bir AI agent size 30 saniyede çalışan bir endpoint verebilir. Ama “çalışıyor” ile “production’a hazır” arasında dağlar kadar fark var. Bunu somut örneklerle açayım.

Frontend: Div Üretmek Deneyim Tasarlamak Değildir

AI’dan bir login formu isteyin. Çalışan bir form alırsınız. Peki gerçekten denetlediğinizde ne bulursunuz?

Erişilebilirlik (a11y): aria-label var mı? role attribute’ları doğru mu? Klavye ile gezinme çalışıyor mu? Tab sırası mantıklı mı? Bir ekran okuyucu bu formu doğru şekilde okuyabiliyor mu?

AI, WCAG standartlarını rutin olarak atlıyor. <button> yerine <div onClick> kullanır. Görsel olarak aynı -- ama ekran okuyuculara görünmez ve klavyeyle erişilemez.

Design System Tutarlılığı: AI’ın mevcut design system’inizden haberi yok. Spacing ölçeğinizin 4px tabanlı mı 8px tabanlı mı olduğunu bilmiyor. Typography token’larınızı tanımıyor. Semantik renklerinizi (success, warning, destructive) ayırt edemiyor. Size, ürününüzün geri kalanına hiç benzemeyen, çalışan bir component veriyor.

Performans: AI’ın ürettiği bir React component’i gereksiz re-render’lara yol açabilir. useMemo ya da useCallback olmadan yazılmış bir liste component’i her state değişikliğinde tüm child’ları yeniden render eder. Bundle boyutu şişebilir. Core Web Vitals (LCP, CLS, INP) hiçbir zaman AI'ın önceliği değildir.

Gerçek bir örnek: AI’dan bir e-ticaret ürün sayfası isteyin. Alırsınız. Ama o hero görseli lazy-load ediliyor mu? LCP optimize edildi mi? CLS kaymalarını önleyen bir font yükleme stratejisi var mı? Bunları sorgulayabilmek için önce Core Web Vitals’ın ne olduğunu bilmek gerekir.

Backend: Çalışan Kod Güvenli Kod Değildir

AI bir CRUD endpoint’i yazdığında genellikle “happy path”i çözer. Peki ya edge case’ler?

Güvenlik:

• SQL Injection: AI parameterized query mi kullandı, yoksa string birleştirme mi?
• Rate limiting: Bu endpoint’e saniyede 10.000 istek geldiğinde ne olur?
• Authentication/Authorization: JWT doğrulaması doğru mu? Token süresinin dolması ele alınıyor mu? Rol tabanlı erişim kontrolü düzgün yapılandırılmış mı?

State Management Kararları: AI’dan bir state management çözümü isteyin. Bir seferinde Redux önerir, başka bir seferinde Zustand, bir diğerinde React Context. Projenize hangisinin uyduğuna karar veren AI değil — sizsiniz. 50 component’li bir uygulamada Context ya da 5 component’li bir formda Redux kullanmak — ikisi de yanlış kararlar. Bu kararı verebilmek trade-off’ları anlamayı gerektirir.

Hata Yönetimi: AI genellikle her şeyi genel bir try/catch ile sarar. Production’da bu, debug etmeyi neredeyse imkânsız hale getirir. Structured logging, error boundary’ler, graceful degradation -- bunlar hiçbir zaman AI'ın önceliği değildir.

Mimari: Prompt’larla Sistem Kuramazsınız

Bu en kritik katman. Ve çoğu insanın gözden kaçırdığı katman.

Bağlam Sağlamak: AI agent’lar ancak onlara sağladığınız bağlam kadar güçlüdür. Bu sadece “şu dosyayı oku” demek değil. Repo’nuzun yapısını bilmek, hangi servislerin birbiriyle konuştuğunu anlamak, tech debt’in nerede biriktiğini fark etmek — ve bunları AI’a beslemek demek. Çünkü bunu kendi başına çözemez.

MCP (Model Context Protocol) Entegrasyonu: 2025–2026’nın en önemli gelişmelerinden biri. MCP, AI agent’ların harici kaynaklarla — veritabanları, API’ler, dosya sistemleri — yapılandırılmış şekilde etkileşim kurmasını sağlıyor. Ama bunu projenize doğru şekilde entegre etmek, sisteminiz hakkında derin bilgi gerektirir. Hangi tool’ları tanımlayacaksınız? Hangi resource’ları açacaksınız? Güvenlik sınırları neler?

Skill Dosyaları ve Repo Gerçekliği: AI agent’ların etkili çalışabilmesi için iyi yapılandırılmış SKILL.md dosyalarına, düzgün .cursorrules’a, iyi organize edilmiş README’lere ihtiyaçları var. Bu dosyaları yazmak projenizi çok yakından tanımayı gerektirir. AI’ın ürettiği kodun kalitesi, bu dosyaların kalitesiyle doğru orantılıdır.

Doğru Aracı Seçmek: Her hafta yeni bir AI aracı, yeni bir framework, yeni bir paradigma çıkıyor. Her şeyi stack’inize tıkıştırmak yerine gerçekten değer katanı ayıklamak — bu bir mühendislik olgunluğu meselesi. “Bu nasıl yapılır” diye sormadan önce “bu hiç yapılmalı mı” diye sormanız gerekir.

Otopilot Benzetmesi

Otopilot sistemleri 1930’lardan beri uçaklarda var. 90 yılda pilotluk mesleği “ölmedi.” Olan şuydu: pilotun rolü evrildi. Artık kumanda kolunu elle tutmuyorlar. Karmaşık sistemleri yönetiyorlar. Anormallikleri tespit ediyorlar. Kriz anlarında müdahale ediyorlar.

Aynısı hesap makineleri için de geçerli. Hesap makinesi icat edildiğinde matematikçiler gereksiz hale gelmedi. Aritmetikle vakit kaybetmeyi bıraktılar ve daha karmaşık teorik problemlere odaklanma özgürlüğü kazandılar.

AI agent’lar tam olarak bu: yeni nesil araçlar. Ama bir aracı etkili kullanmak, nereye gittiğinizi bilmeyi gerektirir. Rotayı bilmeyen bir pilota otopilotun hiçbir faydası yoktur.

Üç Grup

Bugün yazılım dünyasında üç grup var:

1. Direnenler: Her yeniliği reddederler. Eski iş akışlarına tutunurlar. “Benim yöntemim çalışıyor” derler. Evet, çalışıyor — şimdilik. Sir William Preece’in ulak çocukları da “çalışıyordu.”

2. İnananlar: AI’ın her şeyi çözdüğüne inanırlar. Temelleri öğrenmeyi gereksiz görürler. Prompt yazarlar ve çıktıyı asla sorgulamazlar. Altı ay sonra o üretilmiş kodun bakımını yapmaları gerektiğinde gerçekle yüzleşecekler.

3. Uyum Sağlayanlar: Temelleri bilirler. Yenilikleri seçici şekilde benimserler. AI agent’ları mühendislik disipliniyle yönetirler. Her aracı almazlar — doğru olanları seçerler. Araçları insan uzmanlığını büyütmek için kullanır, bir çarpan etkisi yaratırlar.

Preece’in hatası telefonu anlayamamak değildi. Onu İngiltere’ye getiren kişi oydu. Hatası, dünyanın değiştiğini kabul etmeyi reddetmekti.

Sonuç: Evrilme Zamanı

Agentic engineering kodlamanın ölümü değil. Kodlamanın evrimi.

Soru AI kullanıp kullanmamak değil. Soru onu nasıl kullandığınız. Mühendislik disipliniyle mi, yoksa “bir prompt yaz, bakalım ne olacak” zihniyetiyle mi?

Temellerde ustalaşın. Yenilikleri entegre edin — ama hepsini değil, yalnızca doğru olanları. Karşılaştığınız problemleri daha hızlı ve daha etkili çözün.

Uyum sağlamak her zaman direnmeyi yener.

Lex Fridman — Peter Steinberger podcast bölümünün tamamının linki yorumlarda.