- HashiCorp’tan exit yaptıktan sonra Ghostty’yi geliştiren Mitchell Hashimoto, yapay zeka araçlarını gerçek iş akışına entegre edene kadar geçen süreci özetliyor
- Bunu verimsizlik → uyum → üretkenlik artışı şeklindeki üç aşamada ele alıyor; her aşamadaki deneme-yanılmaları ve öğrenme sürecini somut biçimde kaydediyor
- Sohbet botu tabanlı kodlamanın sınırlarını fark ettikten sonra ajan tabanlı araçlara geçerek asıl değeri keşfediyor
- Daha önce manuel olarak tamamladığı commit’leri ajanlarla yeniden üretme alıştırmaları üzerinden, işi parçalara ayırma, planlama/uygulamayı ayırma, otomatik doğrulama konularının kilit olduğunu içselleştiriyor
- Günlük işinin son 30 dakikasını kullanarak gece otomasyon işleri yürütüyor ve tekrar edilebilir basit işleri ajanlara devrederek gerçek bir üretkenlik artışı sağlıyor
- Şu anda her zaman bir ajan çalıştırma yaklaşımını benimsiyor ve hata önlemek için “harness engineering” ile birlikte ilerleyerek yapay zeka ile insan iş birliğinin verimini en üst düzeye çıkarıyor
Benimseme arka planı ve yaklaşım
- Her yeni araç benimsenirken verimsizlik → uyum → yenilik şeklindeki üç aşamadan geçmek gerekir
- Mevcut iş akışına alışık olunduğu için ilk kullanım rahatsız edici olabilir, ancak uzun vadede üretkenlik artışına yol açar
- Yapay zeka araçlarına yönelik aşırı beklenti ya da eleştiri yerine, gerçek kullanım deneyimine dayanan dengeli bir bakış sunuyor
Adım 1: Sohbet botundan uzaklaşmak
- ChatGPT, Gemini gibi sohbet botu arayüzleri üzerinden kod yazmak, önceden edinilmiş bilgiye dayanır; hata düzeltme de insanın tekrarlayan geri bildirimine bağlı olduğu için verimsizdir
- Zed’in komut paleti ekran görüntüsünü Gemini’ye yapıştırıp bunu SwiftUI ile yeniden üretmesi ilk “şaşırtıcı an” oldu ve Ghostty macOS komut paletinin temelini oluşturdu
- Ancak brownfield projelerde (mevcut kod tabanı), sohbet botları sık sık kötü sonuçlar üretti; kod ve çıktıyı kopyalayıp yapıştırma süreci de işi doğrudan yapmaktan daha verimsizdi
- Değer elde etmek için mutlaka ajanlar kullanmak gerekir; burada ajan, LLM’in dış eylemleri tekrar tekrar çağırabildiği bir araçtır ve en azından dosya okuma, program çalıştırma, HTTP isteği gönderme yeteneklerine sahip olmalıdır
Adım 2: Kendi işini ajanla yeniden üretmek
- Claude Code’u ilk kullandığında ortaya çıkan sonuçtan memnun kalmadı ve düzeltme işi, bunu doğrudan yapmaktan daha uzun sürdü
- Vazgeçmek yerine, manuel commit’leri ajanla birebir yeniden üretme alıştırmasını tekrar tekrar yaptı
- Aynı işi iki kez yapmak (manuel + ajan) acı vericiydi, ancak yeni bir araç benimsenirken sürtünme yaşanması doğaldır
- Bu süreçte kendi kendine keşfettiği 3 temel ilke:
- Oturumları net ve uygulanabilir alt görevlere bölmek
- Belirsiz isteklerde planlama oturumu ile uygulama oturumunu ayırmak
- Ajana işi doğrulama araçları vermek; böylece kendi hatalarını düzeltebilir ve regresyonu önleyebilir
- Ajanın iyi yapamadığı alanları anlayıp ne zaman kullanmamak gerektiğini bilmek de büyük bir verimlilik artışı sağladı
- Bu aşamada net bir verim artışı hissetmese de, ajanı bir araç olarak tatmin edici biçimde benimsedi
Adım 3: Günün sonunda ajan kullanımı
- Her günün son 30 dakikasını ajan işlerini başlatmaya ayıran bir düzen kurdu
- Çalışmadığı saatlerde ajan ilerleme kaydederse verim kazanılabileceği varsayımından hareket etti
- Etkili olan 3 iş türü:
- Derin araştırma oturumları: Belirli bir dilde, belirli lisanslara sahip kütüphaneleri incelemek; artılar-eksiler, geliştirme faaliyeti, topluluk tepkileri gibi başlıklarda çok sayfalı özetler üretmek
- Paralel ajanlarla belirsiz fikir keşfi: Çıkışa hazır bir sonuç üretmek için değil, ertesi günkü çalışmada bilinmeyen değişkenleri keşfetmek için kullanmak
- Issue ve PR sınıflandırma/inceleme:
gh (GitHub CLI) kullanarak paralel ajanlarla issue triage yapmak; ajanlar doğrudan yanıt yazmak yerine ertesi gün referans alınacak raporlar oluşturur
- Ajanları tüm gece boyunca döngüde çalıştırmadı; çoğu iş 30 dakika içinde tamamlandı
- Günün sonlarındaki yorgun saatleri ajan işlerine kaydırarak ertesi sabah için “warm start” etkisi elde etti
Adım 4: Net işleri güvenle devretmek
- Ajanın neredeyse kesin olarak iyi yapabildiği işleri belirledikten sonra, bunları arka plan ajanlarına devredip kendisi başka işlere odaklandı
- Her sabah, önceki geceki triage sonuçlarını manuel olarak filtreleyip ajana uygun issue’ları seçiyor ve bunları birer birer çalıştırıyor
- Bu süre boyunca sosyal medya ya da video tüketmek yerine, yapay zeka öncesi dönemin derin düşünme işlerini doğrudan kendisi yapıyor
- Ajan masaüstü bildirimlerini kapatmak kritik: bağlam değiştirme maliyeti yüksek olduğundan, ajanın insanı bölmesi yerine doğal mola anlarında kontrol etmek daha verimli
- Anthropic’in beceri oluşumu araştırma makalesine karşılık yaklaşımı şu: ajana devredilen işlerde beceri oluşumundan vazgeçiyor, ancak manuel yapmaya devam ettiği işlerde bu doğal olarak sürüyor
- Bu aşamada “geri dönülemez” bir seviyeye ulaştı; en büyük avantaj, sevdiği işlere odaklanabilir hale gelmesi oldu
Adım 5: Harness engineering
- En yüksek verim, ajanın ilk denemede doğru sonucu verdiği ya da yalnızca çok küçük düzeltmeler gerektirdiği durumlarda elde ediliyor
- Ajan her hata yaptığında, aynı hatayı bir daha yapmamasını sağlayacak çözümü mühendislikle kurmak “harness engineering” kavramını oluşturuyor
- Bunun iki biçimi var:
- Örtük prompt iyileştirmesi (
AGENTS.md): Ajan yanlış komut çalıştırıyor ya da yanlış API buluyorsa, bunu AGENTS.md dosyasına yazarak çözmek — Ghostty deposunda gerçek örnekler bulunuyor
- Programlanmış araçlar: Ekran görüntüsü alma, filtrelenmiş test çalıştırma gibi script’ler yazmak ve
AGENTS.md içinde bu araçların varlığını ajana bildirmek
- Şu anda bu aşamada ve ajanın kötü davranışlarını önlemeye, iyi davranışlarını doğrulamaya aktif olarak yatırım yapıyor
Adım 6: Her zaman bir ajan çalışır durumda tutmak
- Adım 5 ile paralel biçimde, arka planda her zaman bir ajanın çalıştığı bir durum hedefliyor
- Amp’in deep mode’u (GPT-5.2-Codex tabanlı) gibi, 30 dakikadan uzun süren ama yüksek kaliteli sonuçlar veren yavaş modelleri tercih ediyor
- Şu anda birden fazla ajanı paralel çalıştırmıyor; bir ajan ile manuel iş arasındaki dengenin uygun olduğunu düşünüyor
- Pratikte çalışma saatlerinin yalnızca %10–20 kadarında arka plan ajanı çalışıyor; bu oranı artırmaya çalışıyor
- Amaç sırf ajan çalıştırmak değil; gerçekten yardımcı olacak bir iş olduğunda çalıştırılmalı ve devredilebilir yüksek kaliteli iş akışları kurmak, yapay zeka olsun ya da olmasın önem taşıyor
Mevcut durum ve bakış açısı
- Yapay zeka araçlarıyla sonuç alıyor ve konuya gerçekliğe dayalı dengeli bir bakışla yaklaşıyor
- Herhangi bir yapay zeka şirketinde çalışmıyor, yatırım yapmıyor ya da danışmanlık vermiyor; yapay zekanın sürüp sürmemesinden bağımsız olarak temel motivasyonu bir yazılım zanaatkârı olarak bir şeyler üretmekten keyif almak
- Temeli zayıf junior geliştiricilerdeki beceri oluşumu sorunu konusunda derin endişe duyuyor
- Model yeniliklerinin hızı yüksek olduğu için, ajanların yapamadığı alanlara dair değerlendirmesini sürekli yeniden gözden geçirmek gerektiğini düşünüyor
- Yapay zeka kullanıp kullanmamak kişisel bir tercih; bu yazının amacı araç keşfi ve kullanım biçimine dair kişisel bir örnek paylaşmak
1 yorum
Hacker News görüşleri
Oturumu net ve uygulanabilir iş birimlerine bölmek kilit nokta
Fazla ayrıntılı talimat verirsen LLM kullanmanın anlamı kalmıyor; tersine, “köpekler için Facebook uygulaması yap” gibi fazla geniş olursa da sadece işe yaramaz prototipler çıkıyor
Sonuçta kod için LLM’leri başarılı şekilde kullanmak, bu uygun kapsamı bulma işi
Hangi işi verdiğinde iyi sonuç çıktığını hissetmek ve buna göre kapsamı ayarlamak, programlamadaki modülerleştirmeye benzer bir keyif veriyor
Lovable’da onboarding’den itibaren başarısızlığa sürüklüyormuş gibi hissettirdi; buna karşılık Claude Code ile küçük parçalara bölerek ilerlemek çok daha başarılı oldu
forsözdizimi örneği bulmak için kullanırsan bağlam değişimini azaltabildiği için kullanışlıBaşlarda bu tür basit kod yazma yardımları için sık kullanıyordum
print(output)eklediDoğal dille kod arasında gidip gelerek çalışmak ise aksine psikolojik olarak daha rahat hissettiriyor
2025, yapay zeka kodlama araçlarının gerçekten pratik aşamaya girdiği yıl oldu
Eskiden GPT-3 gibi ilk modeller sadece olasılığı gösteriyordu; bu da aşırı hype ve şüphecilik üretti
Ama şimdi birçok geliştirici yapay zekayı gerçek iş akışına entegre ediyor
Hâlâ şüpheci olan geliştiricilere Mitchell’ın yazısını okumalarını ve Claude Code’u bizzat denemelerini öneririm
Bir zamanlar sürekli “veri sınırı” konuşuluyordu ama Claude Code, Sonnet 4.5 ve Opus 4.5 çıkınca hava tamamen değişti
İki model benzer görünüyordu; ama Claude’un tarife kullanım limitinin hızla tükenmesiyle ilgili laflar yüzünden henüz denemedim
Yöneticilerin sadece hız ve miktara odaklanıp sürdürülemez kod yığınları üretmesinden korkuyorum
“Don’t draw the owl” yaklaşımı benim deneyimimle de örtüşüyor
Sorun, LLM’nin giderek gerçek dünya kısıtlarından kopup drift etmesiydi
Bu yüzden sohbeti tasarım tartışmaları için, ajanı ise yalnızca dar ve doğrulanabilir diff işleri için ayırdım
Bu döngü oturunca oyuncak olmaktan çıkıp gerçek bir kaldıraç haline geldi ve gerçek proje özelliklerini birkaç kez yayına aldım
Son zamanlarda bu tür kalıplaşmış cümle yapılarının insanlar arasında da artması ilginç
Opus 4.5 hakkındaki tartışmalar artınca ben de doğrudan denedim; ajan paradigmasının belirgin biçimde işe yarar hale geldiğini hissettim
Şimdilik daha çok basit işler için ama memnun kaldım
LLM bana göre değil
İnsanın düşünme gücü ve yaratıcılığı bizi ayıran şey; bunu makinelere devredince kendimizi zayıflattığımızı düşünüyorum
Bir Rails geliştiricisi olarak Zed ile Claude Sonnet 4.x ve Opus kullandım ama zamanla RSpec yazma becerimin azaldığını fark ettim
Sonunda neovim’e dönüp ajansız çalışmaya başladım
Kolaylık eninde sonunda düşünme becerisinin körelmesine yol açabilir
LLM, insanlığın ürettiği en iyi kolaylık araçlarından biri ama ben kendi becerimi ve düşünme biçimimi korumayı seçiyorum
Bu yazı, ön sayfadaki diğer yazılara göre çok daha pratik ve daha az abartılı hissettiriyor
“Vibe coding ile OS yaptım” tarzı abartılar yerine gerçekçi bir yaklaşım sunuyor
Herkesin benzer bir yapay zeka kullanım yolculuğundan geçiyor olması ilginç
Birden fazla modeli paralel kullanıp kod tabanının farklı kısımlarına uyguluyor, modellerin birbirini çapraz doğrulamasını sağlıyorlar
Hâlâ sık sık git reset atıyorum ama bunu daha verimli biçimde önlemenin yollarını yavaş yavaş öğreniyorum
Sanki beyin otomatik tamamlama çağında yaşıyormuşuz gibi geliyor
“Ajanın dosya okuyabilmesi, program çalıştırabilmesi ve HTTP isteği atabilmesi gerekir” diyenler vardı;
bu neredeyse Simon Willison’ın dediği ‘ölümcül üçlü’ ile aynı seviyede
Ajana sürekli neyi iyileştirmesi gerektiğini söylemek sinir bozucu
Her seferinde agent.md dosyasını düzenleyip geri bildirim vermek gerekiyor; keşke kendi kendine öğrenip gelişse
AGENTS.md’ye birkaç satır eklemek o kadar da büyük bir iş değil
/fixkomutu yapıp otomatik düzeltme ve belgeleme sağlarsan epey zaman kazandırıyorBana mühendislikte kontrolün bende olduğu hissini veriyor
Özellikle yeni özellik araştırmasıyla uygulamayı hızlıca yineleyebilmek güzel
Bunun pratikte nasıl göründüğünü merak ediyorsanız,
OP’nin önceki blog yazısı “Non-trivial Vibing” ile
ona dair HN tartışmasına bakmaya değer