İlk Denemede Doğru Bir Özellik Belirtimi Yazamazsınız, Fable ile Bile
Anthropic
Makale, bilinmeyen bilinmezler kavramını kullanarak özellik belirtimlerinin neden baştan doğru olamayacağını tartışıyor. Özellik belirtimlerinin, aracı ve geliştirici uygulama yolunu kat ettikçe gelişmesi gerektiğini ve yalnızca kod yazıldıktan sonra doğru hale geldiğini savunuyor. SpecBuddy gibi araçlar, belirtimleri dinamik tutarak bu konuda yardımcı oluyor.
Makale, Anthropic'ten Thariq Shihipar'ın, bir ajanın Bilinmeyen Bilinmeyenler'i bulmasıyla ilgili bir blog yazısına atıfta bulunuyor. Harita ve arazi metaforunu kullanarak bilinmeyenleri dört türe ayırıyor: bilinen bilinenler, bilinen bilinmeyenler, bilinmeyen bilinenler ve bilinmeyen bilinmeyenler. Tek oturuşta yazılan bir spesifikasyon yalnızca bilinen bilinenleri kapsar; geri kalanı ancak araziyi kat ettikten sonra ortaya çıkar. Yazar, spesifikasyonların taslak olarak hazırlanması, ajan tarafından keşfedilmesi (kod okuma, MCP üzerinden bilgi tabanları) ve ardından yeni ayrıntılar ortaya çıktıkça yeniden çizilmesi gerektiğini savunuyor. Bu yinelemeli süreç, spesifikasyonun sonunda gerçekle uyumlu olmasını sağlar. Makale, OpenCode, Claude Code ve Codex ile çalışan ve gelecekte OpenSpec desteği sunacak olan ücretsiz bir JetBrains eklentisi olan SpecBuddy'yi tanıtıyor.
Kaynak: Habr — хаб ИИ —
orijinal