Kodlama ajanı kullandığım tüm framework'lerin yerini aldı
(blog.alaindichiappari.dev)> "Yazılım mühendisliği geri döndü"
- Frontier yapay zeka modelleri ve kodlama ajanlarındaki ilerlemelerle birlikte otomatik programlama çağı başladı; kodu satır satır elle yazma işi ortadan kalkarken yazılım mühendisleri yeniden özündeki tasarım ve düşünmeye odaklanabiliyor
- Geçen yılın sonundan bu yana araçların ve modellerin olgunluğu dramatik biçimde arttı; iyi kurgulanmış bir ortamda mimar rolüne odaklanırken gerektiğinde doğrudan müdahale edip düzeltme yapabilen bir çalışma tarzı mümkün hale geldi
- Web, mobil ve masaüstü geliştirmede biriken gereksiz framework'ler ve soyutlama katmanları, gerçek karmaşıklığı çözemedikleri gibi sorunları daha da artırdı
- Framework'lerin çözdüğünü iddia ettiği üç sorun — basitleştirme, otomasyon, iş gücü maliyetini düşürme — içinde yalnızca otomasyon meşru bir değer sunuyordu; ancak yapay zeka otomasyonu artık onun da yerini alabiliyor
- Google, Meta, Vercel gibi hyperscaler'ların tasarladığı sistemlerin operatörüne dönüşmek yerine, kendi tasarımını ve ürününü doğrudan üreten gerçek mühendisliğe geri dönmek gerekiyor
Otomatik programlamanın yükselişi
- Antirez'in adlandırdığı "automated programming" çerçevesi, "vibe coding" ifadesine göre meselenin özünü çok daha iyi yakalıyor
- Matbaa, dokuma tezgâhı ve montaj hattında olduğu gibi otomasyon tarihsel yeniliklerin çekirdeği oldu; bugünkü değişim de bunun devamı niteliğinde
- 2025 yılının Aralık ayından sonra frontier modellerin ve kodlama ajanlarının yetenekleri dramatik biçimde değişti; dikkatle bakanlar için bu seviye artık açıkça görülebiliyor
Mühendisin rolünün değişimi
- Mimari, trade-off'lar, ürün kararları, edge case'ler gibi derin düşünme gerektiren işler hâlâ varlığını sürdürüyor
- Ortadan kalkan şey, her kod satırını bizzat yazmayı gerektiren yorucu ve tüketici el işi oldu
- Temiz ve özenle kurulmuş bir ortamda model ve araçları kullanarak, tuğlaları tek tek dizmeden mimar rolünü üstlenmek mümkün
- Bunun arkasında 20 yıllık doğrudan kod yazma deneyimi olmalı; bir şey hoşunuza gitmezse içine girip anlayabilir, düzeltebilir ve ardından yapılandırmayı güncelleyebilirsiniz
- İhtiyaç duyulan araçlar anında üretilebildiği için, tasarlanan teknolojiyi hayata geçirmeye daha fazla zaman ayrılabiliyor
Framework'ler ve gereksiz karmaşıklık
- Web, mobil ve masaüstü geliştirmede yıllar boyunca framework, kütüphane ve tooling kaynaklı devasa bir kirlilik birikti
- Anlamlı hiçbir şeyi soyutlamayan soyutlama katmanları üst üste yığıldı; bir sorunu çözdüğünü söylerken on yeni sorun ürettiler
- Tüm sektör, yazılım geliştirmenin gerçek karmaşıklığı karşısında düşüncesini keskinleştirmek yerine, hazır paket düşünceyi satın alma yolunu seçti
- Bu durum kırık bir bacağı ipekle sarmaya benziyor; dışarıdan hoş görünüyor ama bacak hâlâ kırık
Framework'lerin çözdüğünü iddia ettiği üç sorun
- "Basitleştirme (Simplification)": Mühendislerin kendi tasarımlarını yapmaktan çekinip başkalarının yapısını körü körüne benimsemesi
- Hedeften geriye doğru tasarlamak yerine, herkese uyan tek tip (one-size-fits-all) tasarımı her yere uygulamak
- Bu basitleştirme değil, entelektüel teslimiyet (intellectual surrender)
- Otomasyon (Automation): Boilerplate kodu ortadan kaldırma yönüyle gerçekten makul görülebilecek tek değer
- ORM, CRUD yönetimi, kod üretimi, API dokümantasyonu gibi tekrarlı ama gerekli işlerin otomasyonu
- Ancak yapay zeka tam da bu noktada her şeyi değiştiriyor
- İş gücü maliyetini düşürme (Labour cost): Konferans slaytlarında görünmeyen sessiz neden
- Google, Meta ve Vercel ürün geliştirme ile kod dağıtım biçimini belirlediğinde, yazılım mühendisi yerine "React geliştiricisi" işe almak mümkün oluyor
- Eğitim gerektirmeyen, tak-çalıştır, kolayca değiştirilebilen dişli(cog) benzeri iş gücü
- Bu mühendislik değil, operasyon yürütmek (operating)
Yeni çalışma biçiminin pratiği
- Bu yöntemle 2 yılı aşkın süredir neredeyse kusursuz biçimde geliştiriyorum; asıl devrim ise geçen yılın Aralık ayından itibaren yaşandı
- Gereksiz karmaşıklığı atıp fikir odaklı karmaşıklığa yoğunlaşma fırsatı doğdu
- Boilerplate'i kaldırmanın maliyeti neredeyse sıfıra indi, aynı kodu iki kez yazmaya gerek kalmadı
- Probleme tam uyan amaca özel küçük araçlar anında kurulabiliyor
- Gösterişli bir monorepo yöneticisine gerek olmadan basit bir Makefile, kullanım senaryolarının %99'unu karşılıyor
- Sorun gerçekten çok karmaşık hale gelirse o zaman düşünmek; ama ondan önce asla peşinen çözmeye çalışmamak mühendisliğin özüdür
- Konferans sahnesinde birinin bir gün yaşayacağını söylediği problemi değil, şu anda elinizde olan problemi çözmeniz gerekir
Bash ve temel araçların yeniden keşfi
- Ajanlar, onlarca yıldır var olan temel araçlar (basic tools) konusunda son derece yetkin
- Bash 1989'da ortaya çıktı ve bugün en sıradan model bile Bash'i dünyadaki herhangi bir insandan daha iyi biliyor
- Kodlama ajanlarında eğilim, karmaşık ve pahalı MCP yapılandırmalarından Bash tabanlı basit ajan döngülerine geçiş yönünde
- En eski araçlar, aynı zamanda geleceğe en dayanıklı araçlar (most future proof)
Framework bağımlılığının maliyeti
- Çoğu kullanım senaryosunda işlevlerin yalnızca %10'unu kullandığınız, pahalı ve kusurlu framework'lere ve yan kütüphanelere ihtiyaç yok
- Bakım, güvenlik güncellemeleri, tasarım kısıtları gibi görünmeyen maliyetler yüksektir ve geliştiricinin özgürlüğünü sınırlar
- Bu trade-off'u kabul etmeyi sürdürmek, onlarca yılın en büyük fırsatını kaçırmak anlamına gelir
- Google, Meta, Vercel gibi büyük şirketlerin tasarım felsefesine bağımlı hale gelen yapılara karşı dikkatli olunmalı
- Geliştiriciler kendi düşüncelerine ve estetik anlayışlarına güvenmeli, kendi araçlarını ve ürünlerini inşa etmeli
> “Kırık bir bacağı ipekle sarmayın; gerçekten size ait olan şeyi inşa edin”
- Geliştiriciler kendi düşüncelerine ve estetik anlayışlarına güvenmeli, kendi araçlarını ve ürünlerini inşa etmeli
5 yorum
Bu tam da bakımını zorlaştırarak geliştirme yapmanın gerçek metodolojisi gibi duruyor; yapay zeka çağına uygun şekilde yeni dönemde ömür boyu kendi yerini korumanın yolunu uygulayan biri.
“Çoğu kullanım senaryosunda işlevlerin yalnızca %10’unu kullandığınız pahalı ve kusurlu framework’ler ile yan kütüphaneler” sözüne gerçekten katılamıyorum.. Projeye uygun ölçekte bir ortamı iyi seçmek erdem değil miydi? Çok fazla özellik geliştirmeyeceksek express gibi hafif bir şey kullanırız. Express’in yerine geçecek bir şeyi en baştan özellikle yapmak gerekir mi..
Özellikle çok özelliği olup da az kullanılan bir şey aranacaksa, aslında Apache ya da nginx gibi web sunucuları buna daha çok uyuyor; ama onlar ağır diye web sunucusunu sıfırdan mı yapıyoruz, hayır, sadece yapılandırıp kullanıyoruz işte
Framework'ler gibi iyi düzenlenmiş ve yapay zekanın bolca öğrendiği kaynaklar varken, ille de bana özgü yeni bir şey üretmek gerekli mi; hatta bu, üretkenliği düşüren bir iş gibi görünüyor.
Mimari kurma maliyetini azaltıp asıl şeye (hizmete) odaklanmamızı sağlayan şeyi yeniden çöpe atmaya gerek olmadığını düşünüyorum.
Hmm... bu tür pratikler, Cursor kullanım sınırı olmadan sunulurken geçerli olan şeyler değil mi... Hatta asıl soru, en azından bir süre daha bundan sonraki yönün token’ları nasıl daha tasarruflu kullanıp yapay zekayı en iyi şekilde desteklemek olacağı gibi görünüyor.
Pahalı token fiyatları olmadan da tekrarlar ortadan kaldırılabiliyorken, framework kullanmamak için sebep ne olabilir ki?
Hacker News görüşleri
Yakın gelecekte birçok geliştirici ve şirket AI gösterişi yüzünden büyük bir şok yaşayacak gibi görünüyor
Şu anda AI ile bir şeyler yapmak mümkün, ama asıl sorun doğrudan içine girmeden fark edilmeyen kısımlar
Sonuçta sadece ‘vibe coding’ yapanlar gerçek dünyadaki sınırlara çarpacak ve yalnızca sistemin gerçekten nasıl çalıştığını anlayanlar ayakta kalacak
Hata 2 dakika içinde düzeltilip merge edilebildi; “sistemi anlamak” ile “kodu doğrudan yazmamak” birbiriyle çelişmek zorunda değil
AWS bu yöne devasa bir bahis oynuyor ve deterministik olmayan araçlar giderek daha istikrarlı hale geldikçe insan seviyesini aşan kaliteye ulaşmaları çok olası
Anlamadan devredersen ortaya çıkan işin doğruluğunu, bakım yapılabilirliğini ya da ölçeklenebilirliğini garanti edemezsin
Ama böyle insanlarla çalışıyorsam, neden onlara yüz binlerce dolar ödeyip bir de LLM abonelik ücretini karşılayayım diye düşünüyorum
Elbette ‘vibe coding’ ile yapılmış uygulamaların bozulduğu örnekler olacak, ama test, versiyon kontrolü ve dokümantasyonu birlikte yürüten ekipler tam tersine daha da başarılı olacak
Sonuçta önemli olan dengeli bir yaklaşım
Belki bir gün ‘de-slopper bot’ da çıkar
Framework kullanmamın nedeni, onları tasarlayan kişilerin benim yaşadığımdan daha fazla sorun ve ölçek problemi yaşamış olması
Projenin başında kolay geliyor ama ölçek büyüdüğünde yeniden tasarlamak acı veriyor
Böyle yazıları okuyunca bazen yazının kendisi de LLM tarafından yazılmış gibi geliyor
‘Tuğlayı kesip dikip birleştirmek’ türü benzetmeler bu çelişkiyi daha da gösteriyor
Tüm stack’i sıfırdan kurmak hâlâ verimsiz ve bakım maliyeti yüksek
Ama artık fark şu: probleme uygun özelleştirilmiş bileşenleri çok daha kolay yapabiliyoruz
Yeni bir şey öğrenmeye gerek kalmadan alışık olduğum framework’lerle devam etmek yeterli
Benim problemim, platformun problemi ve framework’ü dolanma problemi
Kod yazmanın acısından söz eden yazılar bana tuhaf geliyor. Kodlama aslında işin kolay kısmı
Eğer Tolkien AI kullansaydı, muhtemelen promptları düzeltmekle zaman kaybederdi
Özellikle zor kısımlarda AI yardımı faydadan çok zarar veriyor
AI yazılarında “AI kodu benim yerime yazıyor, ben de düşünmeye odaklanıyorum” deniyor
Aynı kişiler söylüyorsa bu çelişkili
Bugünlerde Claude Code’a bırakınca çoğunu birkaç dakika içinde çözüyor
Ama ben kendi yazdığım koda daha çok güveniyorum. Sonuçta hızdan çok anlayış derinliği önemli
Warhol gibi yeni araçları iyi kullanan biri için bu da sanattır
LLM sadece yaratımın ilk aşamalarına yardımcı olan bir araç; deha hâlâ insandan geliyor
Node.js güvenlik yamalarından şikâyet etmek bir yanlış anlama
Bu bir ayrıcalık. Kendi yaptığın çözümün ne bir güvenlik topluluğu olur ne de daha az açığı
React geliştiricisi bulmak kolay ama “AI’nin yaptığı özgün framework” geliştiricisi yok
Pek de olağanüstü bir şey değil
Kodlama ajanları ile framework’ler arasında bir orta nokta var
Ben hâlâ aynı araçları kullanıyorum ama tekrar eden işleri ajan yapıyor
Ben ise mimariye ve edge case’lere odaklanıyorum
Ajanları yok saymak da onlara körü körüne inanmak da uç nokta
Asıl beceri, direksiyonu ne zaman eline alacağını bilmek
Bu yazının sorunu, framework’ler ile ‘gerçek mühendisliği’ karşı karşıya koyması
Vercel, Next.js, Firebase gibi platformlar anında deployment ve CI/CD sağlıyor
Eskiden Jenkins ile her şeyi elle kurduğumuz günleri düşününce bu devrim gibi
Gerçek mühendislik ‘yeniden icat etmek’ değil, müşteriye hızlı teslim etmek
AI’nin mevcut framework’leri savaşta test edilmeden yeniden uygulaması verimsiz
Ekosistem ve ortak kalıplar olmayınca iş birliği zorlaşıyor
Deneyimsiz geliştiricilerin AI’yi yanlış kullanması geçmiştekinden farklı değil
Kendin yapınca dokümantasyonu, middleware’i ve bakımı da kaybediyorsun
“API’leri birbirine bağlayabiliyormuşuz” diye yeniden fark ediyorlar
Ama bu tür keşifler trade-off’ları anlama düzeyini beraberinde getirmiyor
Son 6 aydır Cursor + Opus 4.x ile embedded geliştirme yapıyorum
LLM yalnızca yazılımda değil, devre tasarımı, CAD, CNC işlerinde de yardımcı oluyor
Örneğin ST7789 tabanlı bir ekran için wrapper fonksiyonunu üç promptta tamamladım
Artık LVGL, TinyUSB, sıkıştırma ve şifreleme dışında neredeyse hiç kütüphane kullanmıyorum
LLM’nin ürettiği amaca yönelik fonksiyonlar küçük, hızlı ve gereksiz soyutlamalar içermiyor
Bence birçok kütüphane için artık sahneyi terk etme zamanı geldi
.NET gibi şeylerin yerini doldurmak mümkün değil ama genel amaçlı fonksiyon paketleri rahatlıkla değiştirilebilir
Hatta çift frame buffer içeren tamamlanmış kodu hemen verdi
Kodlamanın yorucu kısmı yazı yazmak değil, insanlarla iş birliği, test ve tasarım düşüncesi
Son dönemde en zorlandığım iş lock-free veri yapıları tasarlamaktı
LLM çağında framework’lerin değeri daha da artıyor
LLM’ler eğitim verileri sayesinde React gibi tanıdık kalıplarda güçlü
İnsanın devreye girip debug yapabilmesi de önemli
AGI gelse bile verimli framework’leri yeniden öğrenmemek için bir neden yok
Böyle bir konuşmanın kendisi bile ilginç bir deney