Şubat 2025'te Andrej Karpathy, vibe coding'i niyeti doğal dilde tanımlama, bir LLM'in değişikliklerini minimum incelemeyle kabul etme ve kodun normal anlayışınızın ötesine geçmesine izin verme pratiği olarak tanımladı. Bu, kişisel projeler ve prototipler için etkileyici bir hız sağladı.
Bir yıl sonra, ajan yeteneklerinin ilerlediğini gözlemledi ve mimari ile süreç üzerinde güçlü bir insan denetimi sağlarken ajanları orkestre etmenin gelişmiş pratiği için "ajanik mühendislik"i tercih ettiği isim olarak önerdi. Onun ifadesiyle amaç, yazılım kalitesinden ödün vermeden ajanların kaldıracını elde etmektir.
Ayrım önemlidir. Vibe coding, düşük riskli kişisel işlerde tek bir kullanıcı için iyi çalışır, ancak sonuca başkaları bağımlı hale geldiği anda hızla gizli borç, güvenlik açıkları ve bakım sorunları biriktirir. Ajanik mühendislik, modern ajanların hızını ve kaldıracını korur, ancak her şeyi net yapı, izlenebilir yapıtlar ve insan sorumluluğuna bağlar.
Ajanik Mühendislik İş Akışı
Kaba bir niyetle başlayın ve AI ile tasarım konuşmaları yaparken işlevselliği, onu bileşen parçalarına ayıran tasarım toplantı notlarına belgeleyin. Tasarım sağlam hissettirdiğinde, üst düzey görünümü ve bileşen haritasını bir tasarım hiyerarşisinde yakalayın (insanların bir obsidian "beyin" gösterirken gösterdikleri şey budur), size ve ajana çevredeki bağlama, ilgili kararlara ve bağımlılıklara hazır erişim sağlayan gezilebilir bir yapı. UML (evrensel modelleme dili), kod veya kullanıcı etkileşim akışları gibi tasarım diyagramlarının yanı sıra, bileşenlerin nasıl ilişkili olduğunu açıklığa kavuşturdukları yerde mimari karar kayıtlarına (ADR) bağlantılar da burada yaşar.
Her modül veya en küçük işlevsellik bloğu için, LLD içinde kesin davranışı, fonksiyon imzalarını, uç durumları, test beklentilerini ve entegrasyon noktalarını tanımlayan odaklanmış bir spec.md oluşturun. Tüm yapıyı bir tasarım bağlamı olarak kullanarak AI'ya, wiki sayfalarına ve spec'lere doğrudan izlenebilirlik sağlayan bir bilet tarzı hiyerarşi oluşturması için komut verin. Ajana ilgili spec.md'yi sözleşmesi olarak vererek bilet bilet uygulayın. Ardından doğrulama geçitlerini çalıştırın, dağıtın, gözlemleyin ve gereksinimler geliştikçe canlı yapıtları güncelleyin.
Gerçek Örnek: Günlük Yedekleme Doğrulayıcı
Günlük S3 yedeklemelerini doğrulayan ve başarısızlık durumunda Slack uyarıları gönderen, üretim kalitesinde küçük bir CLI aracı düşünün.
Kaba hedefle başlayın: "Yedeklemelerimin her gün sağlıklı olup olmadığını kontrol eden güvenilir bir şeye ihtiyacım var." Ardından AI ile gereksinimleri ve uç durumları ortaya çıkarmak için mimari konuşmalar yapın:
- S3 yedeklemeleri için pratikteki gerçekçi başarısızlık modları nelerdir?
- Tam olarak neyi doğrulamalıyız (yaş, dosya sayısı, boyut, başarı oranı) ve hangi eşikler mantıklı?
- Yerel geliştirme ve üretim IAM rolleri arasında yapılandırma ve sırlar nasıl ele alınmalı?
- Günlük kullanımda hangi CLI komutları ve çıktı formatları faydalı olur?
- Zamanlanmış günlük bir araç için hangi işlevsel olmayan gereksinimler en önemlidir?
Bu konuşmalar kapsamı netleştirir ve aracı temel bileşenlerine ayırmaya yardımcı olur: yeniden deneme mantığı ile S3 meta veri getirme, bir doğrulama kuralları motoru, bir bildirim sistemi, bir yapılandırma yükleyici, bir CLI arayüzü, yapılandırılmış günlük kaydı ve hata yönetimi.
Tasarım netleştiğinde, her sayfanın sürümlendirildiği ve bağlanabilir olduğu tasarım hiyerarşisi wiki'sinde üst düzey görünümü ve bileşen haritasını belgelersiniz.
Wiki, gelecekteki okuyuculara düz bir belgenin sağlayamayacağı çevresel bağlamı verir. Aynı tasarım çalışmasının bir parçası olarak, her modül için alt-LLD düzeyinde odaklanmış bir spec.md oluşturursunuz. İşte S3 meta veri getirici için sözleşme.
Bu spec.md, ajana verdiğiniz sözleşmedir, örneğin: "s3_client/ dizininde spec.md'ye tam olarak uygun şekilde uygula, proje standartlarını takip et ve kapsamlı testler ekle." Wiki ve modül spec'leri yerindeyken, AI'ya doğrudan bunlardan bilet hiyerarşisi oluşturması için komut verirsiniz. Her öğe, işlevsel bir gereksinime ve sözleşmesini tanımlayan spec'e kadar izlenebilir.
Uygulama daha sonra bilet bilet ilerler, her biri ajana eşleşen spec.md'si sözleşme olarak verilir. İşte pratikte ürettiği şey: kısa bir yedekleme setini yakalayan ve uyarıyı tetikleyen zamanlanmış bir çalıştırma.
Çalıştırma sıfırdan farklı bir kodla çıkar, böylece cron işi fark eder ve Slack'e düşen uyarıyı tetikler.
Uyarı, nöbetçi mühendisin harekete geçmesi için ihtiyaç duyduğu kural bağlamını taşır: hangi kontrol başarısız oldu, ne bulundu, ne bekleniyordu ve hangi yedekleme seti.
Bu Katmanlı Yaklaşımın Faydaları
- Ajanlar uygulama hacmini hallederken, insanlar her katmanda mimari ve kalitenin sahibidir.
- Wiki, proje düzeyinde bulunabilirlik ve kararlar sağlarken, spec.md dosyaları üst düzey tasarımı şişirmeden kesin modül düzeyinde sözleşmeler sağlar.
- Gereksinimler ve kararlar doğrudan wiki sayfalarından ve spec'lerden biletlere ve koda akar.
- Değişiklikler, kod tabanını tersine mühendislik yapmaktan ziyade canlı tasarım yapıtlarından başlar.
- Net sorumluluk ayrımı, paralel çalışmayı, işe alımı ve denetimleri destekler.
- T-şekilli profesyoneller genişlikle gezinir ve kesinlikle sorgular; ajan, kimseyi tüm sistemi kafasında tutmaya zorlamadan talep üzerine derinlik sağlar.
Vibe coding, keşif ve hızlı kişisel prototipleme için mükemmel bir mod olmaya devam ediyor. Ajanik mühendislik, bu aynı konuşma gücünü diğer insanların güvenebileceği ve bakımını yapabileceği sistemlere kanalize etme şeklinizdir.
T-Şekilli Profesyonelin Rolü
Bu iş akışı, özellikle T-şekilli profesyoneller için güçlüdür: uygulama alanında geniş bilgiyi koruyan ve gerektiğinde derinleşme kapasitesine sahip mühendisler.
Çünkü her an tüm uygulamanın nasıl çalıştığına dair eksiksiz, güncel bir zihinsel modele sahip olmanız gerekmez. Ajan bu derinliği taşıyabilir ve wiki'den, spec.md dosyalarından ve konuşma geçmişinden doğru bağlama sahip olduğu sürece herhangi bir parçayı talep üzerine yeniden açıklayabilir.
İhtiyacınız olan şey, neye bakacağınızı ve nereye bakacağınızı bilme yeteneği, artı üzerinde çalışılan belirli öğeyi anlayana kadar kesin sorular sorma disiplinidir. T'nin geniş kısmı size sistemin haritasını verir; AI ajanı, tam şu anda önemli olan modül, uç durum veya entegrasyon noktasına inmek için gereken becerileri destekler. Ajan, sorduğunuzda kapsamlı ayrıntıyı sağlar.
Bu, insan rolünü "Her şeyi her zaman anlamalıyım"dan "Doğru irtifada nasıl gezineceğimi, sorgulayacağımı ve doğrulayacağımı biliyorum"a kaydırır. Ajanik mühendisliğin gerçek becerisi budur.
