- İç beta yazılım ürünü, elle yazılmış 0 satır kodu sabit kısıt olarak benimseyip Codex'in uygulama mantığını, testleri, CI yapılandırmasını, dokümantasyonu, gözlemlenebilirliği ve iç araçları yazdığı bir deney örneği
- Boş bir git deposundan başlayan kod tabanı, yaklaşık 5 ay sonra yaklaşık 1 milyon satırlık ölçeğe ulaştı; üç mühendis Codex'i çalıştırarak yaklaşık 1.500 PR açıp birleştirdi ve bu da yüksek bir PR iş hacmi ortaya koydu
- Mühendislerin temel işi artık kod yazmak değil; ortam tasarımı, niyetin tanımlanması ve ajanların güvenilir biçimde çalışmasını sağlayan geri bildirim döngüleri kurmak
- Depo bilgisi, kısa bir
AGENTS.md, yapılandırılmışdocs/, yürütme planları, linter'lar ve CI ile yönetiliyor; UI, loglar, metrikler ve izler ise Codex'in doğrudan okuyup doğrulayabildiği uygulama okunabilirliğine dönüştürülüyor - Artan iş hacmi nedeniyle merge kapıları en aza indirildi ve takip eden çalıştırmalarla düzeltme yapmak pratik bir tercih haline geldi; ancak uzun vadeli mimari tutarlılık ve insan yargısının kodlanması hâlâ öğrenilen konular
Elle yazılmış 0 satır kodla oluşturulan iç beta
- Son 5 ay boyunca, elle yazılmış 0 satır kod ile bir iç beta yazılım ürünü inşa edip yayımlamaya yönelik bir deney yürütüldü
- Ürünün günlük iç kullanıcıları ve dış alfa test kullanıcıları bulunuyor; yayınlama, dağıtım, kesinti ve düzeltme akışlarını gerçek koşullarda yaşıyor
- Uygulama mantığından testlere, CI yapılandırmasından dokümantasyona, gözlemlenebilirlikten iç araçlara kadar tüm kod satırlarını Codex yazdı ve bunun elde yazmaya kıyasla yaklaşık onda bir sürede gerçekleştiği tahmin ediliyor
- İnsan yönlendiriyor, ajan uyguluyor
- Birkaç hafta içinde nihayetinde 1 milyon satır ölçeğine ulaşan çıktının yayımlanması gerekiyordu; bunun için mühendislik ekibinin ana işi kod yazmaktan, ortam tasarımına, niyet tanımlamaya ve geri bildirim döngüleri kurmaya kaydı
Boş bir git deposundan başlamak
- Boş deponun ilk commit'i 2025 Ağustos sonlarında atıldı
- Başlangıç iskeleti olan depo yapısı, CI ayarları, biçimlendirme kuralları, paket yöneticisi ayarları ve uygulama çatısı; GPT-5 kullanan Codex CLI tarafından, mevcut bazı şablonların yönlendirmesiyle oluşturuldu
- Ajanın depoda nasıl çalışacağını yönlendiren ilk
AGENTS.mddosyası da Codex tarafından yazıldı - Sistemi taşıyan, önceden var olan insan yazımı kod yoktu; depo baştan itibaren ajan tarafından şekillendirildi
- 5 ay sonra depo; uygulama mantığı, altyapı, araçlar, dokümantasyon ve iç geliştirici yardımcıları genelinde yaklaşık 1 milyon satır ölçeğine ulaştı
- Üç mühendis Codex'i çalıştırarak yaklaşık 1.500 PR açıp birleştirdi; bu da mühendis başına günde ortalama 3,5 PR iş hacmi anlamına geliyor
- Ekibin bugün yedi mühendise çıkmasına rağmen iş hacmi artmaya devam etti
- Ortaya çıkan sonuç yalnızca çıktı üretmek için çıktı değil; ürün, iç power user'lar dahil yüzlerce iç kullanıcı tarafından kullanılıyor
- Geliştirme süreci boyunca insanlar doğrudan koda katkı vermedi ve elle yazılmış kod olmaması ekibin temel felsefesi oldu
Mühendis rolünün yeniden tanımlanması
- İnsanların doğrudan kod yazmaması kısıtı; sistemlere, iskelet kurmaya ve kaldıraç yaratmaya odaklanan farklı bir mühendislik iş türünü beraberinde getirdi
- İlk ilerleme beklenenden yavaştı; ancak bunun nedeni Codex'in yetersizliği değil, ortamın yeterince tanımlanmamış olmasıydı
- Ajanlar, üst düzey hedeflere ilerlemek için gereken araçlardan, soyutlamalardan ve iç yapıdan yoksundu
- Mühendislik ekibinin ana işi, ajanların faydalı işler yapabilmesini sağlamak haline geldi
- Gerçek çalışma; büyük hedefleri tasarım, kod, inceleme ve test gibi daha küçük yapı taşlarına bölmek, ajanlara bu blokları oluşturmaları için prompt vermek ve bunları daha karmaşık işlerin dayanağı yapmak şeklindeki derinlik öncelikli bir yaklaşımdı
- Başarısızlıkta çözüm “daha çok çabalamak” değil, Codex'in işi yapmasını sağlayacak hangi yeteneğin eksik olduğunu bulmak ve bunu ajanın okuyup izleyebileceği hale getirmekti
- İnsanlar çoğunlukla sistemle prompt'lar üzerinden etkileşime giriyor; mühendis işi açıklıyor, ajanı çalıştırıyor ve ardından PR açtırıyor
- PR tamamlama sürecinde Codex; kendi değişikliklerini yerelde inceliyor, yerelde ve bulutta ek ajan incelemeleri istiyor, insan veya ajan geri bildirimine yanıt veriyor ve tüm ajan inceleyiciler tatmin olana kadar bunu yineleyerek Ralph Wiggum Loop'a yakın bir yöntem izliyor
- Codex;
gh, yerel script'ler ve depoya gömülü beceriler gibi standart geliştirme araçlarını doğrudan kullanarak, insanın kopyala-yapıştır yapmasına gerek kalmadan bağlam topluyor - İnsanlar PR inceleyebilir ama bu zorunlu değil; zamanla inceleme işinin neredeyse tamamı ajanlar arası işleme kaydı
Uygulama okunabilirliğini artırmak
- Kod iş hacmi arttıkça darboğaz insan QA kapasitesine kaydı
- Sabit kısıt insan zamanı ve dikkat olduğu için, uygulama UI'ı, loglar ve uygulama metrikleri Codex'in doğrudan okuyabileceği hale getirilerek ajanın kapasitesi genişletildi
- Uygulama, her git worktree için ayağa kalkabilecek şekilde yapılandırıldı; böylece Codex her değişiklik için bir instance çalıştırıp onunla etkileşime girebiliyor
- Chrome DevTools Protocol ajan çalışma zamanına bağlandı ve DOM snapshot'ları, ekran görüntüleri ve gezinme görevleri için beceriler oluşturuldu
- Codex bu sayede hataları yeniden üretebiliyor, düzeltmeleri doğrulayabiliyor ve UI davranışını doğrudan çıkarım yoluyla anlayabiliyor
- Loglar, metrikler ve izler; belirli bir worktree için geçici olarak var olan yerel bir gözlemlenebilirlik stack'i üzerinden Codex'e açılıyor
- Codex, loglar ve metrikler dahil tamamen izole bir uygulama sürümünde çalışıyor; iş tamamlandığında ilgili loglar ve metrikler de kaldırılıyor
- Ajan logları LogQL ile, metrikleri ise PromQL ile sorguluyor
- “Servis başlangıcının 800 ms altında tamamlandığını garanti et” veya “dört temel kullanıcı yolculuğundaki hiçbir span'in 2 saniyeyi aşmamasını sağla” gibi prompt'lar uygulanabilir görevlere dönüşüyor
- Tek bir Codex çalıştırmasının bir görevi 6 saatten uzun süre yürüttüğü durumlar sık görülüyor; bu zamanın önemli kısmı çoğu kez insanlar uyurken geçiyor
Depo bilgisini sistem kaydı haline getirmek
- Büyük ve karmaşık işlerde ajanları etkili kılmanın temel zorluklarından biri bağlam yönetimi
- Codex'in 1.000 sayfalık bir talimat kitabına değil, bir haritaya ihtiyacı var
- Bağlam kıt bir kaynaktır ve dev talimat dosyaları; görevleri, kodu ve ilgili belgeleri iterek ajanın temel kısıtları kaçırmasına veya yanlış kısıtları optimize etmesine yol açabilir
- Aşırı yönlendirme artık yönlendirme olmaktan çıkar; her şey önemli hale geldiğinde hiçbir şey önemli olmaz ve ajan kasıtlı keşif yerine yerel örüntü eşleştirmeye sıkışır
- Tek ve devasa bir kılavuz hızla eskiyebilir, eskimiş kurallar mezarlığına dönüşebilir ve insanların bakımını yapmadığı cazip bir dikkat dağıtıcı olabilir
- Tek parça bir dosyada kapsam, güncellik, sahiplik ve çapraz bağlantılar gibi unsurların mekanik doğrulanması zor olduğundan sapma kaçınılmaz hale gelir
AGENTS.md, bir ansiklopedi değil içindekiler tablosu olarak ele alınıyor- Depo bilgi tabanı, sistem kaydı sayılan yapılandırılmış bir
docs/dizininde bulunuyor - Yaklaşık 100 satırlık kısa bir
AGENTS.mdbağlama enjekte ediliyor ve daha derindeki gerçek kaynakları gösteren bir harita görevi görüyor - Tasarım belgeleri, doğrulama durumunu ve ajan öncelikli işletim ilkelerini tanımlayan temel inançlar kümesiyle birlikte kataloglanıp indeksleniyor
- Mimari belgeleri, alan ve paket katmanlarının üst düzey haritasını sunuyor
- Kalite belgeleri, her ürün alanını ve mimari katmanı derecelendiriyor ve zaman içindeki boşlukları takip ediyor
- Planlar birinci sınıf çıktı kabul ediliyor; küçük değişikliklerde geçici hafif planlar kullanılıyor, karmaşık işler ise ilerleme durumu ve karar günlüklerini içeren yürütme planları olarak depoya commit ediliyor
- Aktif planlar, tamamlanmış planlar ve bilinen teknik borçların tamamı sürüm kontrolünde ve aynı yerde tutuluyor; böylece ajan dış bağlama bağımlı olmadan çalışabiliyor
- Bu yapı kademeli açılmayı mümkün kılıyor; ajan baştan bunaltılmak yerine küçük ve istikrarlı bir giriş noktasından başlayıp sonra nereye bakması gerektiğini öğreniyor
- Özel linter'lar ve CI işleri, bilgi tabanının güncelliğini, çapraz bağlantılarını ve yapısal doğruluğunu doğruluyor
- Düzenli çalışan dokümantasyon bahçıvanı ajanlar, gerçek kod davranışını yansıtmayan eski veya obsolete belgeleri bulup düzeltme PR'ları üretiyor
Hedef ajan okunabilirliği
- Tüm kod tabanı ajan üretimi olduğu için en öncelikli optimizasyon hedefi Codex'in okunabilirliği
- Nasıl ki yeni bir mühendisin kodu keşfetmesi kolaylaştırılırsa, insan mühendislerin hedefi de ajanın tüm iş alanını doğrudan deponun içinden çıkarım yaparak anlayabilmesini sağlamak
- Ajan açısından, çalışma bağlamı içinde erişilemeyen şey fiilen yoktur
- Google Docs, sohbet dizileri ya da insanların kafasındaki bilgi sistem tarafından erişilebilir değildir; ajanların görebildiği tek şey depoda yerel ve sürüm kontrollü çıktılar olan kod, Markdown, şema ve yürütme planlarıdır
- Ekip bir mimari örüntü üzerinde Slack tartışmasıyla anlaşmış olsa bile ajan bunu keşfedemiyorsa, bu bilgi üç ay sonra gelen yeni bir ekip üyesinin bilmediği bilgiyle aynı durumdadır
- Codex'e daha fazla bağlam vermek, rastgele talimatlar yığmak değil; ajanın akıl yürütebilmesi için doğru bilgiyi düzenleyip görünür kılmaktır
- Bir yeni ekip üyesini ürün ilkeleri, mühendislik normları, ekip kültürü ve hatta emoji tercihleriyle onboard etmek nasıl daha uyumlu sonuçlar doğuruyorsa, ajana da bu bilgileri vermek daha hizalı çıktılar sağlar
- Bağımlılıklar ve soyutlamalarda, deponun içinde tamamen içselleştirilebilen ve üzerinde akıl yürütülebilen seçenekler tercih ediliyor
- Sıkça “sıkıcı” görülen teknolojiler; birleştirilebilirlik, API kararlılığı ve eğitim verisindeki temsilleri sayesinde ajanların modellemesi için daha kolay olma eğiliminde
- Bazı durumlarda, açık bir kütüphanenin opak üst davranışını baypas etmeye çalışmak yerine ajanın işlevin bir kısmını yeniden uygulaması daha ucuz olabiliyor
- Genel amaçlı bir
p-limittarzı paket getirmek yerine kendi map-with-concurrency helper'ı uygulandı; bu helper OpenTelemetry enstrümantasyonuyla sıkı şekilde entegre, %100 test kapsamına sahip ve çalışma zamanı beklentileriyle tam uyumlu davranıyor - Sistemin daha büyük kısmı, ajanın doğrudan inceleyebileceği, doğrulayabileceği ve düzeltebileceği biçimde içeri alındıkça; yalnızca Codex'in değil, aynı kod tabanında çalışan Aardvark gibi diğer ajanların da kaldıracı artıyor
Mimarinin ve tercihlerin zorlanması
- Yalnızca dokümantasyon, tamamen ajan üretimli bir kod tabanında tutarlılığı korumaya yetmiyor
- Uygulamayı mikroyönetmek yerine değişmez koşulları zorlayarak, ajanların temeli zayıflatmadan hızlı teslimat yapabilmesi sağlanıyor
- Codex'ten veri biçimlerini sınırda parse etmesi isteniyor; ancak bunun nasıl yapılacağı ayrıntılı biçimde dayatılmıyor
- Ajanlar katı sınırlar ve öngörülebilir yapı olan ortamlarda en iyi çalıştığı için uygulama, sağlam bir mimari model etrafında kuruluyor
- Her iş alanı sabit bir katman kümesine ayrılıyor; bağımlılık yönleri ve izin verilen bağlantılar sıkı biçimde doğrulanıyor
- Bu kısıtlar, Codex'in oluşturduğu özel linter'lar ve yapı testleriyle mekanik olarak zorlanıyor
- Her iş alanında kod yalnızca
Types → Config → Repo → Service → Runtime → UIsabit katmanları boyunca ileri yönde bağımlı olabiliyor - Kimlik doğrulama, connector'lar, telemetry ve feature flag gibi yatay kesen konulara yalnızca
Providersadlı tek bir açık arayüz üzerinden girilebiliyor - Bunun dışındaki bağımlılıklara izin verilmiyor ve bunlar mekanik olarak engelleniyor
- Bu tür bir mimari normalde yüzlerce mühendise ulaşana kadar ertelenir; ancak kodlama ajanı ortamında hız korunurken çürümeyi ve mimari sapmayı önlemek için erken bir önkoşul haline geliyor
- Pratikte kurallar; özel linter'lar, yapı testleri ve küçük bir “tercih değişmezleri” kümesiyle uygulanıyor
- Yapılandırılmış loglama, şema ve tip adlandırma kuralları, dosya boyutu sınırları ve platforma özgü güvenilirlik gereklilikleri özel lint ile statik olarak zorlanıyor
- Özel lint hata mesajları, ajan bağlamına düzeltme talimatları enjekte edecek şekilde yazılıyor
- İnsan öncelikli iş akışlarında bu tür kurallar aşırı titiz veya kısıtlayıcı görünebilir; ancak ajan ortamında bir kez kodlanan kural, her yere aynı anda uygulanan bir çarpan etkisi yaratıyor
- Merkezde sınırlar, doğruluk ve yeniden üretilebilirlik sıkı biçimde yönetilirken, bu sınırların içinde ekip veya ajan çözümü nasıl ifade edeceği konusunda geniş özgürlüğe sahip oluyor
- Ortaya çıkan kod her zaman insanların stil tercihleriyle tam örtüşmeyebilir; ancak doğru, bakımı yapılabilir ve gelecekteki ajan çalıştırmaları tarafından okunabilir olduğu sürece ölçüt karşılanmış sayılıyor
- İnsan tercihleri; inceleme yorumları, refactoring PR'ları ve kullanıcıya yansıyan hatalar aracılığıyla sürekli olarak dokümantasyon güncellemelerine veya araçlara geri besleniyor
- Dokümantasyon yetersiz kalırsa kural koda yükseltiliyor
İş hacminin merge felsefesini değiştirmesi
- Codex iş hacmi arttıkça, mevcut mühendislik normlarının önemli bir kısmı ters etki üretmeye başladı
- Depo, minimum engelleyici merge kapısıyla işletiliyor
- PR'lar kısa tutuluyor
- Test flake'leri, ilerlemeyi süresiz engellemek yerine çoğu zaman takip eden çalıştırmalarla ele alınıyor
- Ajan iş hacminin insan dikkatini büyük ölçüde aştığı sistemlerde düzeltme maliyeti düşük, bekleme maliyeti ise yüksek oluyor
- Düşük iş hacimli bir ortamda bu yaklaşım sorumsuz görünebilir; ancak bu ortamda çoğu zaman doğru trade-off bu oluyor
“Ajan üretimi”nin gerçek kapsamı
- Kod tabanının Codex ajanı tarafından üretildiği söylendiğinde, bu deponun içindeki her şeyi kapsıyor
- Ajanın ürettiği şeyler
- Ürün kodu ve testler
- CI yapılandırması ve release araçları
- İç geliştirici araçları
- Dokümantasyon ve tasarım geçmişi
- Değerlendirme harness'leri
- İnceleme yorumları ve yanıtları
- Deponun kendisini yöneten script'ler
- Production dashboard tanım dosyaları
- İnsanlar her zaman döngünün içinde, ancak eskisinden daha yüksek bir soyutlama katmanında çalışıyor
- İnsanlar iş önceliklerini belirliyor, kullanıcı geri bildirimini kabul kriterlerine çeviriyor ve sonuçları doğruluyor
- Ajan zorlandığında bu, araçlar, guardrail'ler veya dokümantasyonda neyin eksik olduğunu gösteren bir sinyal sayılıyor; bu düzeltme de yine Codex tarafından yazılmak üzere depoya geri besleniyor
- Ajanlar standart geliştirme araçlarını doğrudan kullanıyor, inceleme geri bildirimini alıyor, satır içi yanıt veriyor, güncellemeleri push'luyor ve çoğu zaman kendi PR'larını squash edip merge ediyor
Özerklik seviyesini yükseltmek
- Test, doğrulama, inceleme, geri bildirim işleme ve kurtarma sistemin içine daha fazla kodlandıkça, Codex'in yeni bir özelliği baştan sona ilerletebildiği eşiğin yakın zamanda aşıldığı belirtiliyor
- Ajanın yalnızca tek bir prompt ile yapabildiği işler
- Kod tabanının mevcut durumunu doğrulamak
- Bildirilmiş hatayı yeniden üretmek
- Hatanın görüldüğü bir video kaydı oluşturmak
- Düzeltmeyi uygulamak
- Uygulamayı doğrudan kullanarak düzeltmeyi doğrulamak
- Çözümü gösteren ikinci bir video kaydı oluşturmak
- PR açmak
- Ajan ve insan geri bildirimine yanıt vermek
- Build hatalarını tespit edip düzeltmek
- Yalnızca yargı gerektiğinde insana eskalasyon yapmak
- Değişikliği merge etmek
- Bu davranış, ilgili deponun özel yapısına ve araçlarına büyük ölçüde bağlı; benzer yatırım olmadan genelleşeceği varsayılmamalı
Entropi ve garbage collection
- Tam ajan özerkliği yeni sorunları da beraberinde getiriyor
- Codex, depoda zaten var olan örüntüleri kopyalıyor; bu örüntüler düzensiz veya optimal olmasa bile tekrar ediyor
- Zamanla bu tekrarlar sapmaya yol açıyor
- Başlarda insanlar bunu manuel olarak ele aldı ve ekip her cuma, yani haftanın %20'sini “AI slop” temizliğine ayırdı
- Bu yaklaşım ölçeklenmeyince, “altın ilkeler” doğrudan depoya kodlandı ve tekrarlayan bir temizlik süreci kuruldu
- Altın ilkeler, kod tabanını gelecekteki ajan çalıştırmaları için okunabilir ve tutarlı tutmayı amaçlayan, güçlü görüş içeren mekanik kurallardır
- Örnek bir ilke, değişmez koşulları merkezileştirmek için el yapımı helper'lar yerine paylaşılan utility paketlerini tercih etmektir
- Bir diğer örnek, veriyi “YOLO usulü” keşfetmek yerine sınırları doğrulamak veya tipli SDK'lara dayanmak; böylece ajan tahmin ettiği biçimlerin üzerine tesadüfen sistem kuramaz
- Düzenli arka plan Codex işleri sapmaları tarıyor, kalite derecelerini güncelliyor ve hedefli refactoring PR'ları üretiyor
- Refactoring PR'larının çoğu 1 dakikadan kısa sürede incelenebiliyor ve otomatik merge edilebiliyor
- Bu süreç garbage collection gibi çalışıyor
- Teknik borç, yüksek faizli krediye benziyor; birikmesine izin verip sonra acı verici biçimde topluca ödemektense, küçük parçalar halinde sürekli ödemek neredeyse her zaman daha iyi
- İnsan tercihleri bir kez yakalandıktan sonra tüm kod satırlarına sürekli uygulanabiliyor
- Kötü örüntüler, kod tabanına günler veya haftalar boyunca yayılmadan önce her gün yakalanıp çözülebiliyor
Hâlâ öğreniliyor
- Bu strateji şimdiye kadar OpenAI içindeki yayın ve benimseme aşamalarına kadar iyi çalıştı
- Gerçek kullanıcılar için gerçek ürünler inşa etmek, yatırımları gerçeğe bağlı tutuyor ve uzun vadeli bakım yapılabilirliğe yöneltiyor
- Tamamen ajan üretimli sistemlerde mimari tutarlılığın yıllar içinde nasıl değişeceği hâlâ bilinmiyor
- İnsan yargısının nerede en büyük kaldıracı sağladığı ve bunun nasıl kodlanarak birikimli etki yaratabileceği de öğrenilmeye devam ediyor
- Modeller zamanla daha yetkin hale geldikçe bu sistemin nasıl evrileceği de henüz belirsiz
- Netleşen şey, yazılım geliştirmenin hâlâ disiplin gerektirdiği; ancak bu disiplinin koddan çok iskelet kurmada daha belirgin hale geldiği
- Kod tabanı tutarlılığını koruyan araçların, soyutlamaların ve geri bildirim döngülerinin önemi artmaya devam ediyor
- Şu anda en zor görev, ajanların büyük ölçekte karmaşık ve güvenilir yazılımlar üretip sürdürmesine yardımcı olacak ortamları, geri bildirim döngülerini ve kontrol sistemlerini tasarlamak
- Codex gibi ajanlar yazılım yaşam döngüsünün daha büyük bir bölümünü üstlendikçe bu sorular daha da önemli hale geliyor
- İlk öğrenimler, çabanın nereye yatırılması gerektiğini ve bir şeyi doğrudan inşa edip edemeyeceğinizi değerlendirmeye yardımcı olan materyal sunuyor
1 yorum
Hacker News yorumları
Verim akıl almaz seviyede. Referans çizgisini neye göre almak gerektiğini merak ediyorum. Ajan tabanlı kodlamadan önce bir mühendisin normalde ne kadar PR açması beklenirdi? Günde 2~10 arası mı?
Son 6 ayda yazılımın daha iyi hale geldiğini hissedip hissetmediğimizi de merak ediyorum. Mühendis sayısı benzerse, büyük yazılım uygulamalarının yineleme döngüsünün yaklaşık 5 kat hızlanmış olması gerekirdi, ama pek öyle görünmüyor. Yapay zeka uygulamaları çok hızlı değişiyor ama bu zaten çok yeni bir alan olduğu için beklenebilir; onun dışında bunu pek hissetmiyorum
Burada ise 1.500 PR'a 1 milyon satır düşüyor, yani PR başına net artış yaklaşık 650 satır. Bu, PR'ın toplamının 650 satır olduğu anlamına gelmiyor; eklenenlerden silinenler çıkarıldığında net artışın +650 olduğu anlamına geliyor
Dikkatli okurlar için bazı sorular var. Bir yılda Firefox kod tabanı kadar satır eklenen bir proje 10 yıl sonra nasıl görünür? Satır sayısı, araçların gevezeliği hakkında bize ne söyler ve projenin amacının net biçimde açıklanmamış olması sonuçlar hakkında ne söyler? İnsanların kodu doğrudan yazmadığı bir dünyada satır sayısını önemsemek için bir neden kalır mı? Kod tabanı çok daha büyürse token kullanımı ne olur? LLM kullanımının satır sayısını patlattığı doğrulanırsa, birkaç ay kullandıktan sonra maliyet yüzünden yeniden manuel kodlamaya dönmek isteyen bir kod tabanı için bunun anlamı ne olur?
Garip olan şu ki “ajan”ların kullanım alanlarının çoğu yine başka bir yapay zeka ürünü yapmak için kullanılıyor. Sonsuz kaplumbağa düzeni gibi. Belki de bu, “ajan”ların gücünden çok Harness'in alanı hakkında daha fazla şey söylüyordur
MS Office'e bakınca son dönemde bir sürü küçük değişiklik görüyorum ama çoğu sinir bozucu. Mesela Word yorumlarında bir iş arkadaşını @ ile etiketleyince odağın kaybolması, Outlook arama kutusuna yazmak için iki kez tıklamak gerekmesi ya da Outlook mobilde tarih seçicinin benim uygun saatimi ve katılımcıların uygunluğunu gösteren özelliği kaybetmiş gibi görünmesi gibi
Yani verim yüksek görünüyor ama ne yazık ki önceden düzgün çalışan özellikler bozuluyor. Ya da OneDrive arama durum çubuğunun giriş alanının etrafında dönüp durması gibi önemsiz şeylere zaman harcanıyor
Yazılan kodun çoğunda direksiyonda benim oturmamı ve kontrolü elimde tutmamı, yapay zekayı ise akış durumunu güçlendirmek ve tıkanan noktaları açmak için kullanmayı tercih ediyorum. Aracın gerçek kod üretimini mümkün olduğunca sınırlı tutmak istiyorum
Son 5 aydır tsz[1] içinde aynı deneyi yapıyoruz ve çok benzer sonuçlara vardık. İyi bir mimari ayrımı zorunlu kılmak için çok fazla harness gerekiyor; ayrıca çok sayıda test ve CI da gerekiyor
tsz'yi yapma amacımız, yapay zekayla çok büyük projelerin nasıl yapılacağını öğrenmek. Sonuçta aynı iş akışı ve yaklaşım, arayüzü olan müşteri odaklı ürün uygulamaları yaparken de kullanılabilir. OpenAI'nin otomatik tarayıcı testlerini ve hatta videoları bile iş akışının bir parçası olarak kullandığı görülüyor. Model ne kadar gelişirse bu tür bir yazılım üretim yönü sonunda mantıklı hale gelecek gibi, ama bence henüz orada değiliz. Yine de OpenAI'nin muğlak iddialarının aksine burada çıktıyı paylaşıyorlar, yani doğrudan görebiliyorsunuz
Lovable gibi çok yüksek seviyede otomasyon sunan çözümler bana biraz fazla iyimser geliyor ve çok sayıda otomatik testle sıkı biçimde entegre değiller
[1] https://github.com/tsz-org/tsz
Bu, benim yaptığım şeyle birebir örtüşüyor. Claude/Codex kendi işini doğrulayabileceği araçlara sahip oluyor. Tarayıcı, smoke test'ler, uçtan uca testler, yüksek doğruluklu yerel ortam gibi şeyler
Tüm bağlamı, yani issue takibi, dokümantasyon, fikirler, planlar ve çalışma günlüklerini depo içinde tutuyorum(https://github.com/shepherdjerred/monorepo/tree/main/package...)
Claude/Codex'e Grafana, Prometheus, Tempo, PagerDuty gibi gözlemlenebilirlik araçlarına erişim veriyorum ve hızlı başarısız olma, tip güvenliği, sınır noktalarında parse etme gibi iyi mühendislik ilkelerine uymasını sağlıyorum
Yalnız, homelab'de maliyet ve CI yükü yüzünden henüz tam özerkliğe ulaşamadım
Kısa süre önce e-sigara fabrikası işçileriyle ilgili bir video izledim. Konveyör banttan bir paket e-sigara alıyorlar, ağızlarına götürüp 5 saniye kadar güçlüce çekiyorlar, sonra bir sonraki paketi test ediyorlar. Yapay zekanın yazdığı PR'lardaki yüzlerce satırlık değişikliği insanın gözden geçirmesi de çok farklı değil
PR'larda durum böyle değil. Kötü bir PR işletme için ölümcül olabilir ama kötü bir e-sigara genelde öyle değildir
Ayrıca yazılım mühendisleri yapay zeka çıktısını örnekleyerek baktığında, mevcut kalitenin ürün için istenen standardı tutarlı biçimde karşılamadığını görüyor. Bu yüzden tüm PR'ları incelemek ve önemli bir kısmını düzeltmek gerekiyor
Değişikliğin etki alanı sınırlandırılabilirse ve çıktı genel olarak gözetimsiz kabul edilebilir hale gelip fabrikada sadece regresyon olmadığını iki kez kontrol etmenin yeterli olduğu bir seviyeye gelirse, örnekleme yaklaşımı işe yarayabilir
Bu yazıyı yazan üç mühendisten biriyim. Sorunuz varsa yanıtlayabilirim.
Yapay zeka şüphecisi değilim ama bu yazının niyetinden şüpheliyim. Gerçek bir ürün, gerçek kullanıcılar, büyüyen gerçek bir ekip üzerinden ajan öncelikli mühendislik hakkında büyük iddialar ortaya atıyor ve bunu gerçek bir vaka gibi sunuyor, ama ne yaptığınızı ne söylüyor ne de gösteriyorsunuz. Diğer tüm yapay zeka abartı yazılarıyla aynı.
Bu ancak sonsuz hesaplama kaynağı ve sonsuz token olduğunda çalışabilir
$20 planını kullanmış biri olarak, böyle saf ajan tarzı bir yaklaşım mümkün değil. Çok çabuk limite takılıyor ve sonuç da daha az oluyor.
Bende çok iyi çalışan yöntem, insan tarafından yazılmış kodu referans olarak verip onu genişletmesini istemek oldu. Genel yapıyı kuruyor, mimariyi tasarlıyor, controller, service, model, component, veritabanı şeması, kimlik doğrulama yöntemi gibi örnek kodlardan birkaçını yazarak LLM'in dikkatini odaklayacağı bir başlangıç noktası sağlıyorum.
Genelde uygulama yöntemini ayrıntılı anlatan stub'lar yazıyorum. Daha yüksek soyutlama seviyesinde bir sözde kod gibi oluyor. Sonra LLM'den bunu implemente etmesini istiyorum.
Başarısız olursa tüm değişikliği geri almak, sonra önceki hatayı yakalayabilecek şekilde stub'ı düzenleyip yeniden denemek çoğu zaman daha iyi oluyor.
Ya da değişikliği commit edip yeni bağlam içinde sadece yanlış giden kısmı ele almasını sağlıyorum.
En baştan ajan tarzı yaklaştığınızda hem sonuçta hem limitlerde hep hayal kırıklığı yaşıyorsunuz. Bazen bir saat geçmeden limite takılıyor.
Aylık $200'a yükseltince daha fazla kullanabiliyorsunuz ama benim gibi yoğun kullanan biri için bile kullanım hâlâ hep yetersiz.
Sırf OpenAI partisine RSVP yaptıkları için 200 kat kullanım alan insanları hâlâ kıskanıyorum.
Yine nefes nefese yazılmış bir satış metni. Maden işçilerine kazma satmak gibi; peki altın nerede? Git üzerinde birbiriyle konuşan chatbot'ların ürettiği kod satırları yığınından doğmuş gerçekten şaşırtıcı ürünler nerede? Hiç görünmüyor.
Keşke bu heyecanlı blog yazıları biraz daha öğretici olsa.
Mesela bu kadar güçlü olduğu söylenen workflow'nun pratikte tam olarak nasıl kurulduğunu adım adım gösterip somut şekilde sergileseler iyi olurdu.
Yapay zeka şüphecisi değilim. Hatta gerçekten bir süper güç varsa onu kaçırmak istemem.
Yeni özellikler için Gherkin feature spec'leri yazıyorum, iyileştirmelerde bunları güncelliyorum, refactor işlerinde ise dokunmuyorum. PR'ları da bu isimlerle etiketliyorum.
Push öncesi hook ile type check, lint, unit test ve hızlı çalıştırılabilen diğer script tabanlı doğrulamaları çalıştırıyorum.
Repo içinde bir VitePress alt sitesi oluşturup bunu ajanın bakımına bırakıyorum. Önemli ilkeleri, mimariyi ve benzeri şeyleri burada belgeliyorum.
Tüm sayfaları ve YAML frontmatter açıklamalarını listeleyen bir CLI komutu yapıyorum ki ajan context window'u patlatmadan neyi okuyacağını seçebilsin.
Domain-driven design ve monorepo kullanıyorum. Mantığı headless katmanlarda yazıyor, katmanları uygulamalara birleştiriyorum. Ajan katmanlar arasında gezinmede çok başarılı.
zod ya da ilgili dildeki eşdeğeriyle contract-first API geliştirme kullanıyorum. Kişisel olarak en sevdiğim kısım bu ve
orpckullanıyorum.Sadece “code” adlı tek bir skill oluşturdum ve yaşam döngüsünü anlattım. Worktree açmak, diğer ajanlarla çakışmaması için
.envayarlamak, kullanılmayan portları seçmek gibi şeyleri burada tanımladım; Docker bunun için iyi. Feature dosyasını yazıyor ya da güncelliyor, burada spec'i netleştiriyor, sonra implemente ediyor,playwright mcpgibi araçlarla doğruluyor, push öncesi kontrolleri çalıştırıyor, push sonrası review bekliyor, temizliyor vemain'e fast-forward merge yapıyor.Birden fazla ajanın çakışmadan test çalıştırmasını garanti etmek için testcontainers iyi iş görüyor.
Cidden tek bir skill var. Geri kalan her şey dokümantasyonda. Kod satırı sayısı anlamında değil, “iyi yazılım üretmek” anlamında çok üretken hissettiriyor.
Bunun için ajan bir sorunla karşılaştığında, doğrulama araçları ya da script'ler yazarak bunu nasıl çözmesi gerektiğini ona sordum. Denetim sürecinde bu araçları da bizzat ona kodlattım. Sonuç olarak şimdi commit doğrulaması için 30'dan fazla kural var[2] ve oldukça iyi çalışıyor.
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (“demo” modunu görmek için zamanlayıcının bitmesini bekleyin)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Bunu ilk başta denedik. Kod yazmadan önce ChatGPT’yi bir “proje yöneticisi” gibi kullanıp tüm harness’i kurmasını sağladık. Bir hafta sonra elimizde 140’tan fazla kural, mimari ve framework dokümanı vardı, ama kod satırı sayısı 0’dı
Daha sonra bunu başka bir araçla incelettiğimizde verilen hüküm şuydu: “mükemmel derecede güvenli boş bir kasa.” Harness kusursuzdu ama içinde hiçbir şey yoktu
Harness önemlidir, ama kodu yayına almakla paralel gitmiyorsa sadece kurgu yazıyor olursunuz