Arka Plan
Her şey, takım liderimle yaptığım birkaç birebir görüşmeyle başladı. AI araçlarını nasıl kullandığım, kişisel Harness'lerimi nasıl oluşturduğum ve AI Coding iş akışımı nasıl yapılandırdığım oldukça ilgisini çekmişti. Bunun temel nedeni, gereksinimleri hem hızlı hem de kaliteli bir şekilde teslim etmem ve şimdiden bazı projelerin ana sorumluluğunu üstlenmiş olmamdı. Ben de bu fırsatı değerlendirerek günlük AI iş akışımı düzenlemeye karar verdim. Şu anda ekibimde ağırlıklı olarak Agent geliştirme yapıyor, bir yandan da mevcut backend iş mantığının bakımını sürdürüyorum.
Daha önce benzer iş akışlarını Xiaohongshu'da paylaşmıştım. O dönemdeki genel kanı, GPT-5.4 ve Opus 4.6'nın doğru bağlam ve makul kısıtlamalar verildiğinde görevleri gayet iyi tamamlayabildiği yönündeydi. Harness Engineering kavramının yükselişi herkese şu gerçeği gösterdi: Kısıtlamalar ekleyerek güçlü modelleri çok daha iyi kontrol edebilirsiniz.
Örneğin Superpowers gibi Skill'ler, ağırlıklı olarak Spec ve TDD etrafında şekillenen nispeten ağır bir uygulama sunar ve insanların görevleri daha kolay organize edip ilerletmesine yardımcı olur.
Ancak bu yaklaşımın bazı dezavantajları var. En bariz hissedilen şey: Token tüketiminin inanılmaz hızlı olması. Superpowers gibi Skill'ler, modelin bir sonraki adımını kısıtlamak için kullanılan birçok Workflow içerir. Küresel perspektiften bakıldığında belirli bir adım artık gereksiz olsa bile —örneğin bağlam zaten yeterli olduğunda ve doğrudan geliştirmeye başlanabilecekken— model yine de önceden belirlenmiş süreci takip etmeye devam edebilir.
Yeni modellerin piyasaya sürülmesiyle birlikte, birçok geliştiricinin bu tür ağır Skill'leri artık neredeyse hiç kullanmadığını paylaştığını görüyorum. Bunun en büyük nedenlerinden biri, model yetenekleri arttıkça eskiden faydalı olduğunu düşündüğümüz bazı kısıtlama ve süreçlerin artık model için "gürültü" haline gelmesi. Örneğin OpenAI, Astra'yı yayınladığında, model kullanım deneyimini iyileştirmek amacıyla gereksiz Skill'lerin ve sistem promptlarının nasıl temizleneceğini anlatan özel bir blog yazısı yayımladı.
Bu nedenle bu yazıda, son birkaç aydaki kendi deneyimlerimden yola çıkarak şu an benim için işe yarayan bazı yöntemleri paylaşacak ve günlük geliştirme verimliliğini artırmak için çeşitli Agent'ların nasıl daha iyi kullanılabileceğini ele alacağım.
1. Sık Kullandığım Skill'ler ve Prompt'lar
Mevcut araç dağılımım şu şekilde:
Şu anda kodlama ve implementasyon için ağırlıklı olarak Codex + GPT-5.6 Sol, planlama için ise Astra kullanıyorum. Astra yayınlanmadan önce planlama işlerini genellikle GPT-5.6 Sol Max'e devrediyordum.
Basit gereksinimler için pi + DeepSeek V4 Flash ile implementasyon yapıyorum; çözümlerin adversarial incelemesi ve Code Review işleri ise ağırlıklı olarak Claude 5 Fable tarafından yürütülüyor. Kişisel projelerimde ana çözüm tasarımı için web tabanlı GPT-6 Pro'yu da kullanıyorum.
Sık Kullandığım Skill'ler
- think: tw93'ün Skill'i, ağırlıklı olarak çözüm hizalaması ve beyin fırtınası için kullanılır.
- grill me / grill with docs: Temelde gereksinimleri netleştirmek için kullanılır. Sürekli sorular sorarak hedefleri, kısıtlamaları ve ödünleşimleri (trade-off) açıklığa kavuşturur, ardından geliştirme sürecinin ihtiyaçlarına göre bunları ADR veya CONTEXT.md dosyalarına aktarır. İlk aşamadaki hizalama sırasında gözden kaçırdığım detayları ortaya çıkarmama çok yardımcı oluyor.
- implement: Grill ile birlikte kullanılır, Matt Pocock'un Skills paketinin bir parçasıdır ve netleştirilmiş planları ya da Issue'ları hayata geçirmek için kullanılır.
- ponytail: AI'ın aşırı tasarım (over-design) yapmasını temizlemek ve Review zorluğunu azaltmak için kullanılır. Bunu sıkça kullanıyorum çünkü GPT-5.6 Sol sıklıkla işi fazla karmaşıklaştırabiliyor.
- handoff: Mevcut bağlamı dosyalara dönüştürerek yeni oturumlarda göreve kaldığınız yerden devam etmenizi sağlar. Genellikle işi Codex'ten Claude Code'a veya pi agent'a devretmek için kullanıyorum.
- check: Kod incelemesi için kullanılır, genellikle MR gönderirken başvuruyorum.
- İş ve kişisel geliştirme süreçlerinden damıttığım Skill'ler: Bunlar çoğunlukla uçtan uca testler gibi yeniden kullanılabilir süreç SOP'larıdır. Tavsiyem şudur: Günlük çalışmanızda bir süreci üç kez tekrarlıyorsanız, bunu bir Skill haline getirip ileride doğrudan kullanmak üzere Codex'ten yardım almayı düşünün.
Sık Kullandığım Prompt'lar
Artık kendim uzun uzun Prompt yazmıyorum. İhtiyaç duyduğumda genellikle Codex'in bunları derlemesini sağlıyorum. Örneğin, birden fazla tartışma turunun ardından mevcut bağlamı çözüm tasarımı için GPT Pro'ya devretmek istediğimde, önce Codex'ten eksiksiz bir handoff Prompt'u oluşturmasını istiyorum.
Bunun dışında, aşağıdaki gibi çok kısa Prompt türlerini sıkça kullanıyorum.
Bunlar bazen "tek cümleyle bin kelime" etkisi yaratıyor. Onları modelin "düşünme kısayolları" olarak tanımlıyorum.
Bunlar sihirli sözler değil, insan bilgisinde yüksek oranda standartlaşmış metodolojilerdir. Model eğitim sürecinde bu konularla ilgili sayısız makale, kod, tasarım dokümanı ve tartışma gördüğü için genellikle yüzlerce satırlık Workflow'u elle yazmanıza gerek kalmaz; sadece hangi düşünme yöntemini benimsemesi gerektiğini söylemeniz yeterlidir. İşte pratikte çok etkili bulduğum bazı promptlar:
- Birinci İlkeler (First Principles): Mevcut çözüm üzerinden iyileştirme yapmaya devam etmeyin, bu problemin aslında nasıl çözülmesi gerektiğini baştan sorun. Örneğin bir arayüz yavaşsa şöyle diyebilirsiniz:
"Redis önbelleği ekleme" şeklindeki yerleşik çözüm üzerinden tasarımı sürdürme. Birinci ilkelerden yola çıkarak bu arayüzün neden yavaş olduğunu ve minimum gerekli çözümün ne olacağını analiz et.
Modelin odağı "Redis nasıl tasarlanmalı" sorusundan şuna kayar:
Darboğaz SQL'de mi, ağda mı, serileştirmede mi, kilit çekişmesinde mi yoksa tekrarlayan hesaplamalarda mı? SQL'e bir indeks eklemek sorunu çözecekse neden Redis ekleyelim ki?
Bu tür bir Prompt, "sorunun kendisinin yanlış olabileceğinden" şüphelendiğiniz durumlarda idealdir.
- Adversarial Review: Çözümüm için haklı sebepler arama, onun yanlış olduğunu kanıtlamaya çalış.
Klasik sorma şekli şöyledir:
Bu teknik çözümde herhangi bir sorun olup olmadığına bakar mısın?
Bunu şu şekilde değiştirebilirsiniz:
Bu çözümün adversarial review'ını yap ve önceliğini temel varsayımları çürütebilecek karşı örnekleri bulmaya ver.
Çözümünüzün "tekrarlanan istekleri çözmek için distributed lock eklemek" olduğunu varsayalım. Bu durumda model size sadece lock timeout süresini nasıl ayarlayacağınızı söylemekle kalmaz, şu soruları sormaya başlar:
Tekrarlanan istekler gerçekten mutual exclusion gerektiriyor mu? Arayüz idempotency'si sorunu çözebilir mi? Lock servisi çökerse ne olur? Lock süresi dolmasına rağmen iş mantığı çalışmayı bitirmediyse ne olacak? Yerel bir sorunu çözmek için yeni bir distributed hata noktası mı ekledik?
Bu tür Prompt'lar özellikle çözüm incelemeleri ve Code Review'lar için biçilmiş kaftandır.
- Ablasyon Deneyleri: Sistemin iyileşmesi, eklediğiniz her şeyin işe yaradığı anlamına gelmez.
Örneğin tek seferde üç optimizasyon yaptınız:
İndeksler, Redis önbelleği ve toplu sorgular eklendikten sonra arayüz gecikmesi 800ms'den 100ms'ye düştü.
Bu noktada doğrudan şunu sorabilirsiniz:
Gerçek faydanın nereden geldiğini belirlemek için bu üç optimizasyona yönelik ablasyon deneyleri tasarla.
Model, Baseline'dan başlayarak farklı kombinasyonlar etrafında kontroller tasarlayacak; yalnızca indeks ekleme, indeks + önbellek, indeks + önbellek + toplu sorgular gibi senaryoları karşılaştıracaktır.
Sonunda şu sonucu bulabilir:
Sadece indeks eklemek gecikmeyi 800ms'den 120ms'ye düşürmüş, kalan iki karmaşık çözümün katkısı yalnızca 20ms olmuş.
Böylece hangi kodun tutulmaya değer olduğunu ve hangi karmaşıklığın gereksiz olabileceğini çok daha net görürsünüz.
- Occam'ın Usturası: Sonuçlar benzer olduğunda, daha az varsayıma ve daha düşük karmaşıklığa sahip çözümleri tercih et.
Örneğin Agent şöyle bir çözüm tasarladı:
Kafka + Redis + Distributed Lock + State Machine + Zamanlanmış Telafi (Timed Compensation).
Şu cümleyi ekleyebilirsiniz:
Gereksinimleri karşılama ön koşuluyla, tüm zorunlu olmayan mekanizmaları silerek bu tasarımı Occam'ın Usturası ile yeniden incele.
Genellikle sonunda şu sonuca varır:
Mevcut senaryo yalnızca tek veritabanı yazımlarını içeriyor; bir transaction ve bir unique index yeterli.
Bu cümle günümüz Coding Agent'ları için özellikle hayat kurtarıcıdır, çünkü modeller "bütünlük" uğruna kolayca aşırı tasarıma kaçabiliyor.
- Yüksek Bağlılık, Düşük Bağımlılık (High Cohesion, Low Coupling): Kod sorumluluklarını ve sınırlarını yeniden kontrol et.
Örneğin bir OrderService'in 2000 satıra ulaştığını fark ettiyseniz şöyle sorabilirsiniz:
OrderService'in sorumluluk sınırlarını yüksek bağlılık ve düşük bağımlılık ilkelerine göre incele; sırf bölmek için bölme.
Model genellikle şunları kontrol etmeye başlar:
Sipariş servisi neden aynı anda envanter, kupon, SMS, ödeme ve raporlama işlerini yürütüyor? Hangi mantık sipariş alanının kendisine ait, hangileri kararlı arayüzler aracılığıyla diğer modüllere devredilmeli?
Bu, basit bir "dosya bölme" işlemini değil; modülerlik, bilgi gizleme, bağımlılık yönü ve sorumluluk dağılımına dair bütünsel bir değerlendirme mekanizmasını tetikler.
Bu yüzden artık nadiren şunu yazıyorum:
Adım 1 gereksinimleri analiz et, Adım 2 varsayımları kontrol et, Adım 3 alternatifleri bul, Adım 4...
Birçok olgun metodolojiyi model zaten öğrenmiş durumda. Ben ona doğrudan şunu söylemeyi tercih ediyorum:
Birinci ilkelerden yeniden analiz et, mevcut çözüm üzerinde adversarial review uygula; temel mekanizmalar ablasyon deneyleriyle doğrulanmalıdır; çözüm Occam'ın Usturası'na uymalı, kod yüksek bağlılık ve düşük bağımlılık prensiplerini korumalıdır.
Bu birkaç düzine kelimenin ardında aslında beş farklı bilişsel eylem belirtilmiştir:
Problemi yeniden tanımla → Varsayımlara saldır → Katkıları doğrula → Karmaşıklığı sil → Sistem sınırlarını düzenle.
Benim anladığım kadarıyla yeni model çağında Prompt Engineering'deki değişim de tam olarak bu: Model için eksiksiz ve sabit bir düşünme süreci yazmak yerine, doğru metodolojiler kullanarak ona "nasıl düşünmesi gerektiğini" söylemek ve ardından o göreve özgü gerçekten gerekli olan kısıtlamaları eklemek çok daha etkili.
2. Günlük Geliştirme İş Akışım
Bir gereksinimi aldığımda, genellikle önce PRD, toplantı notları, sohbet kayıtları ve kullanıcı geri bildirimleri gibi ilgili bağlamı Agent'a aktarırım, ardından gereksinimleri netleştirmek için grill kullanırım.
Bu materyaller çoğu zaman eksiksiz ve tutarlı bir gereksinim seti oluşturmaz. PRD güncellenmemiş olabilir, bazı kısıtlamalar toplantılarda eklenmiş, öncelikler sohbetlerde değiştirilmiş olabilir. Gereksinimlere dair kendi anlayışım bile bazı söylenmemiş varsayımlar içerebilir.
Agent'ın bu materyalleri takım Wiki'si ve mevcut kodla harmanlayarak anlamasını sağlarım; ardından sürekli sorular sorarak hedefleri, sınırları ve implementasyonu etkileyen ödünleşimleri netleştiririm. Bazı soruları anında yanıtlayabilirim, bazıları için ise ürün yöneticisine veya ilgili ekip arkadaşlarıma dönüp teyit almam gerekir.
Burada bir denge kuruyorum: Kalan sorular implementasyon yönünü ve kabul kriterlerini köklü bir şekilde değiştirmeyecek noktaya geldiğinde geliştirmeye başlanabilir.
Tüm implementasyon detaylarını önceden planlamasını beklemiyorum, aksi takdirde gereksinim hizalamasının kendisi çok ağır bir sürece dönüşüyor.
Hizalama sonrası elde edilen sonuçlar Spec veya CONTEXT.md dosyasına aktarılır; burada ağırlıklı olarak çözülecek problem, kapsam, kritik kararlar ve kabul kriterleri kayıt altına alınır. Bu sayede implementasyon ve incelemeden sorumlu sonraki Agent'lar da aynı bağlamı paylaşır, geçmişteki tüm konuşmaları yeniden okumalarına gerek kalmaz.
Çözüm netleştikten sonra, ana Agent'ın görev karmaşıklığına göre nasıl ilerleyeceğine karar vermesini sağlarım. Basit gereksinimler doğrudan hayata geçirilir; karmaşık olanlar ise net sınırları olan ve bağımsız olarak test edilebilen Issue'lara bölünür. Yalnızca bağımsız olarak ilerleyebilecek kısımlar, farklı worktree'lerde paralel geliştirme yapmaları için subagent'lara devredilir ve nihayetinde ana Agent tarafından entegre edilir.
Coding Agent önce testleri tamamlar. Teslime hazır olduğunu düşündüğünde, görevin karmaşıklığına göre cross-adversarial review için diğer Agent'ları devreye sokarım. Tespit edilen sorunlar toplu halde ana coding Agent'a, yani Codex'e iletilir; o da düzeltmeleri yapıp yeniden doğrular.
Kendi Review sürecimden önce ayrıca uçtan uca testler gerçekleştiririm.
Şu anda üretilen tüm kodu satır satır okumuyorum, ağırlıklı olarak test sonuçlarına ve temel iş mantığına odaklanıyorum. Burada önemli bir ön koşul var: Her MR kapsamı yeterince küçük olmalı ve geliştirme ilerledikçe eksiksiz iş akışları kademeli olarak doğrulanmalıdır.
Küçük MR'lar, her seferinde anlaşılması ve değerlendirilmesi gereken değişiklikleri kontrol edilebilir sınırlar içinde tutar; uçtan uca testler ise bu değişikliklerin gerçek iş süreçlerine entegre edildiğinde dayanıklı olup olmadığını kontrol etmeye yardımcı olur. Manuel Review sırasında enerjimi iş mantığını doğrulamaya ve mevcut test sonuçlarının bu teslimatı desteklemek için yeterli olup olmadığını değerlendirmeye harcıyorum.
3. Agent Dostu Uçtan Uca Test Ortamı Nasıl Kurulur?
AI artık test senaryosu yazmakta çok başarılı; çoğu zaman bir Bugfix için yüzlerce satırlık test yazabiliyor (özellikle 5.6 sol). Genellikle çok fazla test yazmak başlı başına bir sorun değildir, ancak deployment ve canlıya alma sonrasında yine de beklenmedik hatalarla karşılaşırız.
Deneyimlerime göre bunun temel nedeni şudur: Agent'a uçtan uca bir test ortamı sunmamak, yani kodlama ve öz-test aşamalarında bu sorunları keşfetmesi için ona fırsat tanımamak.
Eğer böyle bir ortam kurulabilirse ve Agent'ın test ortamının gerçek giriş noktasından görevleri rahatça çalıştırıp kullanıcıya ulaşması gereken sonuçlara kadar her şeyi kontrol etmesi sağlanırsa, AI tarafından yazılan kodun gerçek sistemlerde çalışmasına güvenle izin verebiliriz.
Günlük geliştirmede, iş kolumuz için bir uçtan uca geliştirme test ortamı kurdum. Agent artık veritabanı tablolarını ve logları rahatça sorgulayabiliyor, sorun gidermek için makinelere bağlanabiliyor.
Bu kurulum sürecinin özü aslında Agent'ın günlük geliştirme ve öz-test süreçlerimi çıkarıp dağınık araç ve yetenekleri entegre etmesidir: Araçsallaştırılabilen yetenekler MCP veya CLI haline getirilir; yeniden kullanılabilir süreçler ise Skill'lere dönüştürülür.
Bu başlangıçta biraz efor gerektirir ama zahmetten korkmayın. Bir kez kurulduğunda geliştirmeyi ciddi şekilde hızlandırır, yeniden çalışmayı ve canlı ortam sorunlarının olasılığını azaltır; ayrıca gün boyu "AI'ın yazdığı kod bir kazaya yol açar mı" diye endişelenmenize gerek kalmaz.
Agent dostu uçtan uca testler etrafında ağırlıklı olarak dört şey yaptım:
- Agent'ın ortama alışmasını sağlamak: Test ortamlarının tek tıkla başlatılmasını desteklemek, test verisi oluşturmak, mevcut sürümleri, test hesaplarını ve yetkileri netleştirmek, temizleme ve sıfırlama yetenekleri sunmak.
- Agent'ın iş sistemlerini yönetebilmesi: Tarayıcılar, API'ler veya CLI'lar aracılığıyla gerçek iş süreçlerini çalıştırmak.
- Agent'ın veritabanı tablolarını ve logları rahatça sorgulaması: Salt okunur veritabanı MCP'si ile depolama sonuçlarını doğrulamak, log sistemi Skill'leri ve Trace sorguları ile sorunları tespit etmek.
- Sıkıcı ama kararlı süreçleri yeniden kullanmak: Kararlı operasyonları script'lere yazmak, giriş noktalarını ve sorun giderme yöntemlerini Skill'lere dönüştürerek tekrarlayan manuel müdahaleleri ve diyalogları azaltmak.
Bu çalışmalar ışığında, şu an benim için etkili olan birkaç yöntemi paylaşayım:
- Tarayıcı Otomasyonu: İş sistemleri tarayıcı işlemleri gerektirdiğinde açık kaynaklı ego lite tarayıcısını öneriyorum. Kullanımı pratik ve hızlı. pi agent + DeepSeek V4 Flash ile eşleştirildiğinde testler nispeten hızlı tamamlanarak zamandan tasarruf sağlanıyor.
- Operasyonları CLI'da Birleştirmek: Yeniden kullanılabilir Skill'leri, yapılandırılmış MCP'leri ve yazılmış script'leri tek bir test CLI'ında toplamak; ortam kontrolleri, veri hazırlığı, senaryo çalıştırma, sonuç sorgulama ve temizleme yetenekleri sunmak. Bu aynı zamanda dahili bir verimlilik aracına da dönüşebilir. Şu anda bu seti bir CLI haline getirdim ve bir sorunla karşılaşıldığında sorun gidermeyi de oldukça kolaylaştırıyor.
- Araçları Doğrudan Kabul Sürecine Hizmet Ettirmek: DB sorguları durumu doğrulamak, loglar ve Trace'ler hataları açıklamak için kullanılır, ancak beklenen sonuçlar yine de iş sözleşmelerinden (business contracts) gelmelidir. Agent'ın sistemin döndürdüğü değeri gördüğü için neyin doğru olduğunu varsaymasına izin vermeyin. Karmaşık iş mantıklarında sistem, mantıklı görünen ama aslında uyumsuz olan bir sonuç döndürebilir. Araçlar bize kanıt toplamamızda yardımcı olur, bizim yerimize doğru cevapları tanımlamaz.
- Ürünün Kendisi Bir Agent'sa Yanıt Kalitesini de Kontrol Edin: Test edilen ürünün kendisi bir Agent'sa, iş süreçlerinin sorunsuz çalışmasının yanı sıra yanıt kalitesi de dikkate alınmalıdır. Buna genellikle Agent Eval diyoruz, bu yazıda detayına girmeyeceğim.
4. AI Tarafından Yazılan Kod Nasıl İncelenir?
Önceki bölümlerde AI'a nasıl yüksek kaliteli kod yazdırılacağını paylaştım, ancak nihayetinde iş gereksinimlerinin birincil sorumlusu geliştirici olmaya devam ediyor.
Review olmadan büyük sistemlerde sorun yaşama ihtimaliniz çok yüksektir.
Gecenin bir yarısı On-call için aranan kişinin siz olmasını ve sorunun AI tarafından yazılan koddan kaynaklandığını öğrenmek istemezsiniz.
Review konusunda şu an uyguladığım temel pratikler şunlar:
- Önce kabul kriterlerine, sonra test sonuçlarına bakın: Önce Agent'ın sunduğu kabul kriterlerini kontrol edin, ardından beklentilerin karşılanıp karşılanmadığını ve atlanan bir şey olup olmadığını görmek için önceki uçtan uca test sonuçlarıyla karşılaştırın. Sadece kaç testin geçtiğine değil, bu testlerin gereksinimin asıl önem verdiği şeyleri doğrulayıp doğrulamadığına da bakın.
- Enerjinizi yüksek riskli kısımlara odaklayarak iş akışlarını takip edin: Ağırlıklı olarak yetkilendirmeleri, durum değişikliklerini, eşzamanlılığı, yeniden denemeleri, veri tutarlılığını ve migration/rollback gibi yüksek riskli alanları kontrol ediyorum. Kararlı pattern'lere sahip CRUD işlemlerine daha az zaman ayrılabilir; hatta artık bunların bir kısmına hiç bakmıyorum.
- Yeni eklenen soyutlamaları ve mekanizmaları özel olarak inceleyin: Yeni eklenen soyutlamalar ve mekanizmalar için Occam'ın Usturası gibi yaklaşımları kullanarak AI'dan tekrar inceleme yapmasını istiyorum: Gerçekten gerekli miydiler, daha basit bir implementasyon mümkün müydü, yerel bir sorun için çok fazla karmaşıklık mı eklediler?
- MR Sayısı Fazlaysa Özel Review Bot'ları Kurmayı Değerlendirin: Ekipte çok fazla MR varsa, cross-review'ları yönetmek için özel bir Review Bot tasarlanabilir. Daha önce bahsettiğim pi agent / Claude Code'u doğrudan adversarial review için çağırmaktan farklı olarak bu yaklaşım, Git değişiklik bilgilerini önceden tasarlanmış inceleme süreçleriyle birleştirmeye ve yalnızca MR'lara hizmet eden tekrarlanabilir bir inceleme yeteneği oluşturmaya odaklanır.
5. Bazı Özetler ve Düşünceler
Mevcut geliştirme sürecimdeki en belirgin darboğazım Review hızı.
Agent'lar aynı anda birden fazla görevi ilerletebiliyor, ancak benim işi anlama, çözümleri değerlendirme ve teslimatları onaylama hızım aynı oranda artmıyor. Sadece daha fazla kod yazmasına izin verirseniz, büyük ihtimalle sadece incelenmeyi bekleyen daha fazla kod biriktirmiş olursunuz.
Bu yüzden bundan sonra geliştirmek istediğim şey, tekrarlayan sorunların bana ulaşmadan önce tespit edilip düzeltilmesini sağlamak.
Tip kontrolü, testler ve iş assertion'ları aracılığıyla bulunabilecek sorunlar mümkün olduğunca geliştirme aşamasında Agent'ın kendisi tarafından çözülmeli; benim değerlendirmeme ihtiyaç duyanlar ise gereksinimlerin doğru anlaşılıp anlaşılmadığı, kritik iş mantığının sağlam olup olmadığı ve bu değişiklikle ilgili hangi doğrulanmamış risklerin kaldığı konularında yoğunlaşmalı.
Özel Review Bot'ları bu işleri yapmaya yardımcı olabilir, ancak değerleri sadece kaç yorum yaptıklarıyla değil, geçerli sorunların gözden kaçmasını ve manuel yükü gerçekten azaltıp azaltmadıklarıyla ölçülmelidir.
Bu durum Harness anlayışımı da giderek somutlaştırdı: Agent'lara doğru bağlamı vermenin yanı sıra, görevleri yürütebilecekleri ortamlara ve sonuçları değerlendirebilecekleri temellere de ihtiyaçları var.
Günlük öz-testlerde defalarca tekrarladığım işlemleri CLI'lara, script'lere ve Skill'lere dönüştürdüm; böylece sistemleri kendisi çalıştırabiliyor, sonuçları kontrol edebiliyor ve hata kanıtlarını kendi başına bulabiliyor. Gelecekteki benzer görevlerde bu yetenekler kullanılmaya devam edebilir ve kademeli olarak diğer ekip arkadaşlarının da yeniden kullanımına sunulabilir.
Aynı zamanda bu iş akışının da düzenli olarak budanması gerekiyor.
Bazı adımlar belirli bir model neslinin eksikliklerini telafi etmek içindir. Modeller değiştikçe bu adımların faydası yeniden değerlendirilmelidir. Basit görevler doğrudan yapılır, karmaşık görevlere planlama, bölme ve cross-review eklenir. Örneğin Astra güncellemelerinden sonra AGENTS.md dosyasındaki aşırı katı bazı kısıtlamaları kaldırdım. Modeller gelişiyor ve iş akışlarımızın da buna ayak uydurması gerekiyor.
Elbette test ve Review belirsizliği azaltabilir, ancak doğru kabul kriterlerini yine de insanlar belirlemelidir. Kod ve testler birbiriyle eşleşse bile, ikisi birlikte gereksinimleri yanlış anlamış olabilir. Uçtan uca testler yalnızca seçilen ortamlardaki ve senaryolardaki davranışları kapsar; production ortamındaki trafik, eşzamanlılık ve veri dağılımı yine de yeni sorunlar getirebilir.
Benim gibi iş hayatına yeni başlamış bir geliştirici için, iş yoluyla alanında daha fazla profesyonel bilgi edinmeyi umuyorum. Ancak AI, bazı tuzaklara bizzat düşme fırsatlarını gerçekten de azalttı. Eskiden sorunlar yaşayarak ve nedenlerini araştırarak kazanılan değerli deneyimler, şimdi bir AI'ın şu cümlesine dönüşebiliyor:
"Hatalıydım, şimdi düzeltiyorum."
Bu yüzden,
Artık günlük geliştirme zamanımın bir kısmını öğrenmeye ve düşünmeye ayırırken şu soruyu soruyorum: AI çağında R&D çalışanları için gerçekten hangi yetenekler gerekli?
Bu makale, işe başladığım ilk aylarda kendi iş kolumda kademeli olarak keşfettiğim bir dizi yöntemi kayıt altına alıyor. Uygulama kapsamını ve eksikliklerini hâlâ keşfetmeye devam ediyorum.
Herkes, sıkça yaptığı bir öz-test yolunu seçerek işe başlayabilir; Agent'ın bunu bağımsız olarak çalıştırmasını deneyip kanıtları saklayabilir ve ardından işe yarayan adımları bir Skill'e dönüştürebilir.
Şirketin gizlilik politikaları nedeniyle birçok detayı makaleye dahil edemedim. Umarım bu yazı fikirlerinizi tetikler; gerçek geliştirme süreçlerinizdeki iyi uygulamaları duymayı çok isterim~
