8 Yıllık Özlem, 3 Aylık Tamamlanış - Yapay zekanın yan projelerin formülünü nasıl değiştirdiği
(lalitm.com)- Uzun süredir eksikliği hissedilen SQLite için yüksek kaliteli geliştirme araçları, yapay zekanın yardımıyla kısa sürede tamamlandı
- Resmî sözdizimi belirtiminin olmaması ve karmaşık C kod tabanı nedeniyle parser oluşturmak en büyük engeldi
- Claude Code gibi yapay zeka kodlama ajanları kullanılarak ilk uygulama hızla ilerletildi, ancak spagetti kod sorunu nedeniyle Rust tabanlı yeniden yazım yapıldı
- Yapay zeka, kod üretimi·refaktöring·öğrenme desteği·UX iyileştirmesi alanlarında büyük verim sağladı; ancak tasarımın ertelenmesi·kod tabanından kopma·bağımlılık benzeri alışkanlık gibi yan etkiler de ortaya çıktı
- Sonuç olarak yapay zeka, uygulama hızını artıran bir araç; ancak tasarım ve yazılımın yönünden insan sorumlu olmalı
SQLite geliştirme araçlarını yapay zeka ile inşa etmenin 3 aylık kaydı
- SQLite için yüksek kaliteli geliştirme araçları uzun zamandır isteniyordu, ancak mevcut açık kaynak araçlar güvenilirlik, hız ve esneklik açısından yetersizdi
- PerfettoSQL bakımı sırasında formatter, linter, editör eklentisi gibi özelliklere ihtiyaç vardı, ancak uygun araç bulunmuyordu
- Yeni bir aracı kişisel proje olarak yapmak istense de, zorluk seviyesi ve tekrar eden iş yükü nedeniyle yıllarca ertelendi
Projenin zorlukları
- SQLite için resmî bir sözdizimi belirtimi veya kararlı bir parser API'si yok
- İçeride parse tree üretmediği için parser mantığını doğrudan kaynak koddan çıkarmak gerekti
- 400'den fazla dilbilgisi kuralını tek tek eşlemek gerekiyordu ve test yazımı ile hata ayıklama son derece tekrarlı ve yorucuydu
- SQLite'ın C kod tabanı karmaşık ve yoğun olduğu için anlaşılması zordu
- Sanal tablo API'sini ve uygulamasını kavramak bile günler sürecek kadar yapısı giriftti
Yapay zeka ile geçen geliştirme süreci
- 2025 sonlarından itibaren Claude Code gibi yapay zeka kodlama ajanları aktif biçimde kullanılmaya başlandı
- Başlangıçta tasarım ve uygulamanın büyük kısmı yapay zekaya bırakıldı ve süreç “vibe-coding” yaklaşımıyla ilerledi
- Ortaya çıkan sonuç çalışıyordu, ancak kod tabanı spagettiye dönüştü ve sürdürülemez hale geldi
- Ardından her şey Rust ile yeniden yazılarak yapı baştan kuruldu
- C yerine Rust kullanılarak doğrulayıcı, dil sunucusu gibi üst seviye bileşenlerin geliştirilmesi kolaylaştı
- Yapay zeka “güçlendirilmiş otomatik tamamlama aracı” seviyesinde tutuldu; tasarım, inceleme ve testler ise doğrudan insan tarafından yönlendirildi
- Linting, doğrulama ve test otomasyonu gibi yapay zeka çıktısını doğrulamak için iskelet yapı kuruldu
Yapay zekanın mümkün kıldığı şeyler
-
Ataleti aşmak
- Yapay zeka, işi somut problem birimlerine bölerek başlamayı kolaylaştırdı
- “SQLite parsing'i anlamam gerekiyor” yerine “yapay zekanın önerdiği yaklaşımı gözden geçiriyorum” düşüncesine geçildi ve uygulama hızı arttı
-
Kod üretimi ve refaktöring hızı
- Gereksinimler net olduğunda yapay zeka standart ve tutarlı kodu hızlıca yazabiliyordu
- Standart dışı tasarımlarda (parser yapısı gibi) ise tersine engel oldu ve doğrudan elle yazmak gerekti
- Büyük ölçekli kod üretiminden sonra sürekli refaktöring zorunluydu; kalite bu sayede korundu
-
Öğrenme yardımcısı rolü
- Yapay zeka, Wadler-Lindig formatting algoritması gibi yeni kavramları gerçek zamanlı olarak açıklayabildi
- Rust, VS Code eklentisi gibi çok aşina olunmayan alanlara da hızlı giriş yapılabildi
- Proje bağlamı kaybolduğunda “bu bileşeni açıkla” gibi sorgularla bağlam anında geri kazanılabildi
-
Tamamlanmışlık düzeyini artırmak
- Editör eklentisi, Python binding'leri, WASM playground'u, dokümantasyon sitesi gibi ek özelliklerin geliştirme maliyetini düşürdü
- Uygulama yükü azaldığı için UX iyileştirmelerine odaklanmak mümkün oldu; hata mesajları ve CLI tasarımı gibi kullanıcı deneyimi güçlendirildi
Yapay zeka kullanımının yan etkileri
-
Bağımlılık yapıcılık
- “Bir prompt daha”yı tekrar ettiren slot makinesi benzeri ödül yapısı oluşuyor
- Yorgunluk arttıkça prompt kalitesi düşüyor, sonuçlar kötüleşiyor ve bir kısır döngü doğuyor
-
Kod tabanından kopma
- Yapay zeka tarafından üretilen kod arttıkça ince yapıya dair sezgi kaybı yaşanıyor
- Bağlam kaybolduğunda yapay zeka ile yapılan diyalog da uzuyor ve verimsizleşiyor
- Çözüm olarak, kod üretildikten hemen sonra onu bizzat okuyup “bunu ben farklı nasıl yazardım?” diye kontrol etme alışkanlığı edinildi
-
Tasarımın ertelenmesi ve aşınması
- Refaktöring kolaylaştığı için temel tasarım kararlarını erteleme eğilimi oluşuyor
- Çok sayıda test olsa bile kök tasarım hatalarını gizlemek zor, sonunda tümden yeniden yazmak gerekebiliyor
-
Zaman hissinin yokluğu
- Yapay zeka kodun zamansal bağlamını veya evrim sürecini anlayamıyor
- Geçmişteki hataları yinelemek ya da zaten çözülmüş sorunları yeniden araştırmak gibi verimsizlikler ortaya çıkıyor
- Bu durum dokümantasyonla kısmen telafi edilebilse de, tasarım niyetini tamamen kayda geçirmek zor
Yapay zeka kullanımının göreceli doğası
- Derinlemesine anlaşılan alanlarda yapay zeka son derece güçlü; hızlı inceleme ve tekrar mümkün
- Örnek: parser kuralı üretimi, çünkü net bir doğru cevap var
- Kısmen bilinen alanlarda öğrenme aracı olarak faydalı, ancak sürekli dikkat gerektiriyor
- Örnek: formatter algoritmasını öğrenmek
- Ne yapılacağının henüz bilinmediği aşamada ise tersine zararlı olabiliyor
- Örnek: mimari tasarım aşamasında üretken olmayan döngüler oluşması
- Doğrulanabilir problemlerde (derleme, test geçme) yapay zeka güçlü;
tasarım ve API kalitesi gibi tek bir doğru cevabı olmayan problemler karşısında ise zayıf
Sonuç
- 8 yıldır tasarlanan SQLite aracının 3 ayda hayata geçirilebilmesi yapay zeka sayesinde mümkün oldu
- Ancak süreç yalnızca basit bir başarı hikâyesi değildi; yapay zekaya bağımlılığın sınırları ve bedeli de bu sürece eşlik etti
- Yapay zeka uygulamayı hızlandıran bir çarpan, ama tasarımın yerine geçen bir şey değil
- Teknik sorulara doğru yanıt verebilir, ancak tarih, zevk ve kullanıcı hissi ondan yoksun
- Asıl ders şu: Yapay zeka sayesinde duvara daha hızlı çarpsak bile,
tasarımın yönü ve “yazılımın ruhu”nun sorumluluğu insanda kalmalı - Bundan sonra ihtiyaç duyulan şey, gerçek kullanıcılar ve bakım yükü karşısında ayakta kalan proje örneklerinin paylaşılması
- Yalnızca deneysel değil, gerçekçi ve sürdürülebilir yapay zeka destekli ortak geliştirme deneyimlerinin birikmesi
1 yorum
Hacker News görüşleri
AI ile kodlama hakkında dengeli bir bakış görmek ferahlatıcı
Ciddi geliştiricilerin çoğunun empati kurabileceği bir deneyim bu — başta AI’ın iyi kod yazmasına şaşırıyorsun, ama sonra bakınca kod tabanı spagetti koda dönmüş oluyor
Kimileri kod incelemesi bile yapmadan “artık manuel kodlama bitti” diye konuşuyor, kimileri de “AI ile kodlama işe yaramaz” diye kestirip atıyor
Ama gerçek bunların arasında bir yerde. AI büyük bir üretkenlik hızlandırıcısı olabilir, ama iş akışına doğru şekilde entegre edilmeli ve insan sürece dahil olmaya devam etmeli
Başta bir prototipti ama kısa sürede gerçek bir hizmete dönüştü. Sonrasında refactor ederken gereksiz kodları temizlemek için epey uğraştım
Yine de o hızlı prototip sayesinde bugünkü ürün var. Claude, kodu düzenlerken adeta bir elektrikli testere gibi faydalı oldu
Yakın zamanda pre-commit hook ile bir type checker ekledim ve 90 hatayı 2 saatte düzelttim.
AI ile kodlama etkileyici, ama production code için insan incelemesi ve muhakemesi hâlâ şart
Yalnız bu örnek, tek kişinin yürüttüğü bir greenfield proje olduğu için bunu genel takım geliştirmesine doğrudan uygulamak zor
Yine de prototipin “atılacağı varsayımıyla” yapılıyorsa spagetti kodun da sorun olmadığını düşünüyorum.
Sorun, yazarın bunu gerçek bir ürüne dönüştürebileceğini sanmasıydı.
Ama o başarısızlık sayesinde daha iyi bir tasarım öğrenmiş olmalı
Önce şaşırıyor, sonra hayal kırıklığı yaşıyor, sonunda da dengeyi buluyor.
Adeta AI versiyonu bir Kübler-Ross modeli gibi görünüyor
Elbette kalite önemli, ama artık kod kalitesinin kendisi daha az önemli hâle geliyor
Kişisel uygulamalar gibi bakım gerektirmeyen kodlar artıyor ve AI’ın tasarım yeteneği de hızla gelişiyor
Sonuçta “AI ile kodlamanın gerçeği” sürekli değişiyor ve bu akış durmayacak
Birincisi, çoğu geliştirici sessizce %2~50 üretkenlik artışının keyfini çıkarıyor ve bunu özellikle dillendirmiyor
İkincisi, gerçek AI ile kodlama sıkıcı ve görsel olarak etkileyici değil.
Sonuçta LLM sadece “boilerplate’i ezberlemek zorunda bırakmayan bir araç”; kodlamanın özü aynı kalıyor
Ben de AI ile test üretiminde aynı sorunu yaşadım
Test sayısı artınca insan rahatlıyor ama gerçekte edge case’leri ele alamıyor
Özellikle testsiz legacy kodu refactor ederken AI’ın ürettiği testler sadece çalıştığını doğruluyor, davranış tutarlılığını garanti etmiyor
React uygulamalarında bu sorun daha ciddiydi. Bu yüzden BDD + spesifikasyon tabanlı geliştirme yaklaşımını AI ile birleştirmeyi düşünüyorum
Unit testlerde yaratıcı mock tasarımı, integration testlerde veri manipülasyonu, e2e testlerde ise selector kararlılığı kritik
Bu tür yaratıcı muhakemeyi AI’ın henüz yakalaması zor
%97 coverage olsa bile mantıksal girdi uzayında çok fazla boşluk vardı.
Son dönemde equivalence partitioning gibi klasik teknikleri AI agent ile otomatikleştirip 60 modele uyguladım
Esas nokta, saf fonksiyonları mümkün olduğunca ayırıp girdi-çıktı eşlemesini eksiksiz test etmek
Uzun vadede AI’ın asıl değerinin anlama kapasitesini artıran bir araç olması olduğunu düşünüyorum
Örneğin karmaşık C kodundaki kuralları analiz edip yapıyı dokümante etmek gibi
Böyle bir bilgi çıkarımı mümkün hâle gelirse API dokümantasyonu, kural eşleme, bug analizi ve mimari optimizasyon bile otomatikleşebilir
Sonuçta kod üretmekten çok bağlamı yapılandırma yeteneği daha önemli hâle gelecek
① Yalnızca gereksinimleri verip tüm uygulamayı üretmesini isteyen her şeyi bilen kahin tipi
② IDE içinde satır satır gözden geçirerek kullanan yardımcı araç tipi
Sürdürülebilir bir hizmet üretmek için ② çok daha gerçekçi
“Mimari, yerel parçaların etkileşime girmesiyle ortaya çıkar” sözü etkileyiciydi
AI yerel yürütmede güçlü ama belirsiz tasarım aşamalarında zayıf
Aslında bu insan geliştiriciler için de geçerli. Çünkü tasarım, doğru cevabı olmayan trade-off’ların art arda geldiği bir süreç
Özellikle ClickHouse SQL tasarımında çok yardımcı oldu
AI’ın önerdiği template tabanlı SQL include yöntemi sayesinde tekrar azaldı ve performans da iyileşti
Böyle bir yaklaşım zaten vardı belki, ama AI olmadan bulmak zor olurdu
Bu yazının güven vermesinin nedeni, içinde 250 saatlik gerçek emek olması
Bu ölçekte bir projenin gerçek bir AI destekli sistem programlama modeli olduğunu düşünüyorum
“AI ile kodlama slot machine gibi” sözüne çok katılıyorum
Ben de iş yerinde sınırsız AI agent erişimi aldım; “bir prompt daha” derken
bir bakmışsın 12 saat geçmiş oluyor. Derin odak bağımlılığı çok güçlü
Muhtemelen şu an AI ile kodlamanın en zor dönemi
6 ay önce hayal bile edilemeyen şeyler artık mümkün
Farklı dillerde projeler yürütüyorum ve AI kodu o kadar hızlı üretiyor ki
artık darboğaz inceleme hızı oluyor
Belirli bir seviyede test geçince “bu kadarı yeterli mi?” diye düşünmeye başlıyorsun
Prompt’larda SOLID ilkeleri, coupling, cohesion gibi kalite niteliklerini özellikle belirtiyorum
AI’a refactor fikirleri soruyorum, makulse “tamam, uygula” diyorum
Sonuçta önemli olan prompt tasarım sanatı
Ama çok geçmeden AI’ın bu kalite korkuluklarını varsayılan olarak uygulayacağını düşünüyorum
Dilin kendisi performans darboğazı değil ama yeni dilleri denemek öğrenmeye yardımcı oluyor
Fred Brooks’un “birini çöpe at” felsefesi akla geliyor
AI, ilk sürümü (throwaway) hızlıca yapmak için ideal
Doğrudan production kalitesi beklemek akılsızca bir yaklaşım
Hızlıca yapıp öğrenmek, sonra da refactor etmek doğru yöntem
İnsan yorgunken prompt’ların muğlaklaşması ve sonuçların kötüleşmesi kısmına da katılıyorum
SQLite’ın SQL parser’ının lemon ile üretilmemiş olması şaşırtıcıydı
pikchr’ı Go’ya port ederken önce lemon’ı taşımıştım ama SQLite parser tree bile oluşturmuyor
lemon dokümantasyonu incelendiğinde bunun tasarım aşamasındaki problem tanımı eksikliğine işaret ettiği görülüyor
Ben de bu yazının sonucuna tamamen katılıyorum
AI ile kodlamanın gerçeğini abartmadan ve dürüstçe gösteren iyi bir örnek