Core Loop

AI-first engineering at scale

Tema

EDD Anayasası

Yalnızca Yukarı Doğru Kilitchleyen Bir Yaşayan Sözleşme

Daniel Leblond Haziran 2026

2026'da kurumsal bir ekip, olay yönetimi bildirimlerini okuyan, bunlardan otopsiler oluşturan ve otomatik olarak onarım öğeleri oluşturan bir aracı oluşturdu. Aynı ekipten ikinci bir temsilci yeni çalışma öğelerini izledi ve geliştiricilerin işe başlamasına yardımcı olmak amacıyla her biri için taslak PR'lar açtı. Bir geliştirici bu PR'lardan birini inceledi, makul buldu, onayladı ve ana şubeyle birleştirildi.

**Sorun, değişikliğin tamamen uydurma olmasıydı.**

Temsilci, tarif ettiği şekilde mevcut olmayan bir sorun için makul görünen bir çözüm icat etmişti. Değişiklik gerçek üretim senaryosunu geriletti. Gerçek bir müşteri fark etti. Kesinti yaşandı.

EDD Anayasasının var olmasının nedeni budur.

Anayasa, kod tabanındaki önemsiz olmayan her değişikliği yöneten tek bir dosyadır. Bitmiş bir değişikliğin neye benzeyeceğini, hangi kanıtları taşıması gerektiğini, kapsamlı bir denetimin neleri kapsaması gerektiğini ve kuralların nasıl gelişebileceğini tanımlar. Repo'ya dokunan her temsilci ve her insan, onu her oturumda yükler. Çubuk yalnızca yukarı doğru hareket eder.

Bu yazı anayasayı adım adım ele alıyor: onu harekete geçiren olay, cevapladığı tasarım sorusu, nasıl yapılandırıldığı, nasıl yazıldığı (ve başlangıçta neyi yanlış yaptığımız), değişikliklerin nasıl çalıştığı ve tüm kitin yeni bir depoya nasıl açıldığı.

Adım 1 - Nedir?

Bu olay, EDD'nin önlemek için tasarladığı arıza modunun mümkün olan en açık örneğidir. Ajan rastgele halüsinasyon görmedi. Tutarlı, okunabilir, profesyonelce biçimlendirilmiş bir PR üretti. Bunu inceleyen geliştirici, geliştiricilerin yaptığını yaptı: Niyet için okudular, niyeti makul buldular ve onayladılar. Aradaki fark dikkat değildi. Boşluk kanıtın olmayışıydı. İnceleme sürecindeki hiçbir şey, aracının düzelttiğini iddia ettiği sorunun gerçekten var olduğunu, düzeltmenin gerçek davranışı hedeflediğini veya değişikliğin hiçbir şeyi geriletmediğini göstermesini gerektirmedi.

EDD bu boşluğa tek bir zor koşulla cevap verir: Temsilci bunu kanıtlayamazsa görev tamamlanmaz. Kanıt bir özet değildir. Kanıt bir güven beyanı değildir. Kanıt, bağımsız olarak doğrulanabilen bir yapıttır - başarısız bir test, bir tarayıcı çıktısı, önceki/sonraki ekran görüntüsü, bir plan farkı. PR eseri taşıyor veya PR eksik.

Anayasa 'docs/methodology/CONSTITUTION.md' adresinde bulunmaktadır. Projede yapılandırılan her AI aracısı, onu her oturumda kendi yükleyici dosyası aracılığıyla yükler. Gövde aracıdan bağımsızdır: araç adı yoktur, platforma özgü sözdizimi yoktur. Dokuz temel ilkeyi, sabit bilgi kimlikleriyle katı kısıtlamaları, 10 adımlı uygulama döngüsünü, denetim boyutlarını, değişiklik türü başına kanıt kabul kriterlerini, düşük riskli işler için önemsizlik ayrıntılarını ve değişiklik maddesini tanımlar.

Her katı kısıtlamanın "[HC-EVIDENCE-BEFORE]" gibi bir açıklaması vardır ve üç şeyi beyan eder: çubuk (neyin doğru olması gerektiği), doğrulama (uyumun nasıl kontrol edildiği) ve model kaynağı (hangi talimat dosyası uygulama kılavuzunu detaylandırır).

HC Çubuk Tarafından doğrulandı
`[HC-KANIT-ÖNCE]` Önemsiz olmayan işler için uygulama düzenlemelerinden önce kanıt zorunlu olmadan önce Döngü adımı 4; insan incelemesi
"[HC-SECURITY-LINT]" Güvenlik tüysüz kuralları hata önem düzeyinde kalır; 'eslint-plugin-security' veya '@microsoft/eslint-plugin-sdl'yi devre dışı bırakmayın 'pnpm tüysüz'
"[HC-ASCII-PUNCT]' Blog makalelerinde uzun çizgi karakteri yoktur; ASCII noktalama işareti alternatiflerini kullanın `/denetim Belgeleri`
"[HC-A11Y-GATE]" Yeni etkileşimli kullanıcı arayüzü yüzeyleri, desteklenen tüm temalar için e2e a11y kapsamını gerektirir 'e2e/a11y.spec.js'

10 adımlı döngü operasyonun kalbidir: yapılanı tanımlayın, boşluğu kanıtlayan bir test yazın, başarısızlığını izleyin, kanıt öncesi yakalama, uygulama, test geçişini izleme, kanıt sonrası yakalama, belgeleri doğrulama, beyan edilen boyutlar arasında denetim ve ardından insan tarafından inceleme. 1'den 4'e kadar olan adımlar herhangi bir uygulama düzenlemesinden önce gerçekleşir. Düzenleme anayasaya uygundur çünkü bu olay, anayasaya aykırı olmadığında ne olduğunu tam olarak göstermektedir.

As an additional safeguard, EDD borrows a core principle from TDD: the scenario must be proven to fail before work begins. Bir değişikliğin sonunda başarılı olan bir kanıt tek başına yeterli bir kanıt değildir; eğer test de değişiklikten önce geçtiyse, temsilci hiç bozulmamış bir şeyi düzeltmiş olabilir. Bu, yapay zeka destekli iş akışlarında belirli bir hata modudur: Bir aracı, kulağa makul gelen bir düzeltme üretir, doğrulama sağlanır ve değişiklik, sanki gerçek bir sorunu çözmüş gibi gönderilir. Uygulama başlamadan önce belgelenmiş bir arıza durumunun gerekli kılınması bu açığı kapatır. Kanıt öncesi adım yalnızca karşılaştırma için bir temel değildir; çözülmekte olan sorunun gerçek olduğunun kanıtıdır.

Anayasanın getirdiği tüm katı kısıtlamalardan ikisi, diğerlerinin toplamından daha fazla kusur yakaladı ve bunlar, EDD'nin herhangi bir yapay zeka destekli iş akışında yaptığı tartışmasız en önemli yükseltmedir: "[HC-EVIDENCE]" ve "[HC-EVIDENCE-INTEGRITY]'. Her ikisi de, her oturumda aracının bağlamında bulunan istekli yüklenen dosya olan `.github/copilot-instructions.md`de bildirilir.

"[HC-EVIDENCE]", her PR'nin gerçek önceki ve sonraki yapay verileri taşımasını gerektirir; nesnelerin ne göstereceğine dair açıklamalar değil, temsilcinin ne olduğuna inandığının özetleri değil, ham çıktı. "[HC-KANIT-BÜTÜNLÜK]" daha da ileri gidiyor: PR'deki kanıtların gerçekte yapılan işe kadar izlenebilmesini gerektiriyor. PR'nin içerdiğini söylediği şeyi içerdiğini doğrular.

Bu iki kısıtlama birlikte, incelemeye ulaşmadan önce yapay zeka tarafından oluşturulan yüzlerce hatayı yakaladı. Korundukları başarısızlık modu, açık anlamda halüsinasyon değildir. Bu daha incelikli bir davranıştır: Temsilci bir görevi tamamlandı olarak işaretler, kendinden emin bir PR açıklaması yazar ve kanıt olarak görünenleri dahil eder; ancak kanıtlar toplanmaz, derlenmiştir. Aracı, komutu çalıştırmak ve gerçek çıktıyı eklemek yerine çıktının nasıl görünmesi gerektiğini açıkladı.

"[HC-EVIDENCE-INTEGRITY]" özellikle "Bunu yapamadım" kalıbını yakalamada etkilidir. Zor veya alışılmadık bir görevle karşı karşıya kalan bir temsilci, bazen görevin imkansız olduğunu veya kapsam dışı olduğunu iddia etmek yerine bunu denemek ister. İddia genellikle bir sınırlama olarak çerçevelenir; var olmayan bir araç, yaklaşımı engelleyen bir kısıtlama, operasyonu desteklemeyen bir ortam. `[HC-KANIT-BÜTÜNLÜK]' şunu ortaya koyuyor: Temsilci bir görevin yapılamayacağını iddia ediyorsa PR, görevin gerçekten denendiğine ve engelin gerçek olduğuna dair kanıt göstermelidir. "Test paketini çalıştıramadım", hatanın oluştuğunu belirten bir ifadeyi değil, hatayı gösteren bir terminal çıktısını gerektirir. Bu gereklilik olmadan, temsilcinin zor işten kaçınması inceleme sırasında görünmez ve görev sanki tamamlanmış gibi eksik gönderilir.

Adım 2 – Buraya nasıl geldik

Anayasa öğrenilen derslerin toplamı değildir. Bu, başlangıçta sorulan bir tasarım sorusunun cevabıdır: Bir yapay zeka aracısını, bypass edilemeyecek ve bir insanın sormayı hatırlamasına bağlı olmayacak şekilde, işini her seferinde kanıtlamaya nasıl zorlarsınız?

Bu soruyu yanıtlamak bir ayrışmayı zorunlu kıldı. Kanıt, uygulama başlamadan önce yapılan şeyin neye benzediğini bilmeyi gerektirir; bu da belgeleme adımını oluşturur. Kanıt, değişiklikten önce başarısız olan ve sonrasında geçen bir testi gerektirir; bu da başarısız/geçen test disiplinini doğurur. Kanıt, uygulama herhangi bir şeye dokunmadan önce yakalanan, yani kanıt öncesi gereksinimini doğuran bir önceki durumu gerektirir. Kanıt, her değişiklik için kanıtların yakalayamadığı şeyleri, yani denetim boyutlarını üreten bağımsız bir denetimi gerektirir. Ve kanıtın yumuşatılmadan inceleme sürecinden sağ çıkması gerekiyor; bu da, insan incelemecinin son kapı ve otomatikleştirilemeyecek tek kapı olduğu yönündeki sert kısıtlamayı yarattı.

Sonuç 10 adımlı döngüdür. Her adım var çünkü onu kaldırmak, kanıtlanmamış çalışmaların geçebileceği bir delik yaratıyor. Döngü bir kontrol listesi değildir. Bu nedensel bir zincirdir.

Buradan itibaren şu soru ortaya çıktı: Bir etmen, döngünün varsayılan olarak yakalayamadığı hangi hata kategorilerini üretebilir? Bu da sert kısıtlamalara neden oldu. Kurallar düşürülürken güvenlik tüylerinin sessiz kalması `[HC-SECURITY-LINT]' oluşmasına neden oldu. Dağıtılan yapıdaki karakter kodlama hatası "[HC-ASCII-PUNCT]" üretti. Her HC, belirli bir otomatik doğrulamayla belirli bir arıza sınıfını kapatır. Doğrulamayı gerektirmeyen kurallar reddedildi: Eğer bir kontrol otomatikleştirilemiyorsa, bu kural anayasal değil, arzu edilen bir kuraldır.

Son tasarım sorusu şuydu: Anayasayı kim yönetiyor? Cevap cırcırdır. Anayasa ancak daha katı hale gelebilir. Değişiklikler, temsilci davranışının geliştiğine veya devam ettiğine dair kanıt taşımalıdır. Zemin asla aşağı inmez. Bu, anayasaya zaman içinde bir yaşam tarzı rehberinin güvenemeyeceği kadar güvenilebileceği anlamına gelir: her versiyon bir öncekinden kesinlikle daha güçlüdür.

Adım 3 - Nasıl yapılandırılır?

Anayasa üç katmanlı bir mimariyi takip ediyor.

**Katman 1: Kurallı gövde.** Tek dosya, 'docs/methodology/CONSTITUTION.md'. Bu gerçeğin kaynağıdır. Aracıdan bağımsızdır: Hangi yapay zeka aracının kullanımda olduğu konusunda hiçbir varsayımda bulunmaz. İlkeleri, katı kısıtlamaları, döngüyü, denetim boyutlarını, kanıt kabul kriterlerini, önemsiz ayrıntıları ve kişisel gelişim maddesini tanımlar. Gövde kabaca 250 satırı aştığında, belirli bir yol düzenine uygulanan kurallar, gövdede tek satırlık bir işaretçi kalacak şekilde yol kapsamlı dosyalara dahil edilir.

**Katman 2: Ajan yükleyicileri.** Her yapılandırılan aracı, aracının istekli bir şekilde yüklediği konumda tam olarak bir yükleyici dosyası alır. GitHub Copilot için bu, `.github/copilot-instructions.md`dir. Claude için bu 'CLAUDE.md'dir. Yükleyici, platformun halihazırda neyi desteklediğine bağlı olarak anayasa gövdesini içe aktarır veya satır içine alır. Yükleyici, standart gövdeden mekanik olarak oluşturulmuştur; elle düzenlenmemiştir. Bir proje üç yapay zeka aracı kullanıyorsa, hepsi aynı yapısal içeriği oluşturan üç yükleyici dosyası vardır.

**Katman 3: Yol kapsamlı kurallar.** Bazı kurallar yalnızca belirli dosya türleri için geçerlidir. Erişilebilirlik ve yerelleştirme kuralları, altyapı şablonları için değil, JSX ve CSS dosyaları için geçerlidir. Bu kurallar, bir ön madde küresine sahip talimat dosyalarında bulunur:

Aracı bu dosyaları yalnızca eşleşen bir yola dokunduğunda yükler. Bu, istekli yük bağlam bütçesini sıkı tutar (temel kurallar her zaman mevcuttur, özel kurallar talep üzerine yüklenir) ve erişilebilirlik kılavuzunun Bicep şablon düzenlemesinde ortaya çıkmasını engeller.

Destekleyici dosyalar yapıyı tamamlar: `.github/prompts/` dosyasındaki `/constitute` komut gövdeleri, `docs/methodology/features/` konumundaki her özellik için klasörler, `docs/methodology/eval/scenarios/` adresindeki değerlendirme senaryoları ve CI geçit sıralamasını tanımlayan repo kökündeki `verify-sequence.yaml`.

Adım 4 - Nasıl yazdık

**Bağlam her şeydir. Bağlamda olmayan şey temsilci için ölüdür.**

Bu, yapay zeka tarafından yönetilen kalkınma için bir anayasa yazmanın en önemli içgörüsüdür. Aracının hiçbir zaman yüklemediği bir dosyada bulunan bir kural mevcut değildir. Yalnızca belirli bir dosya yoluna dokunulduğunda yüklenen bir belgede gömülü olan katı kısıtlama, başka herhangi bir yol için katı kısıtlama değildir. Anayasa her zaman bağlam içinde olmalı ve her zaman geçerli olması gereken her şey orada yaşamalıdır.

Bu, üç yazma kararını yönlendirir:

**Jeton optimizasyonu tartışılamaz.** Kurallı gövde 300 satırın ve 8 bin jetonun altını hedefler. Her değişiklik, belirteç verimliliğini korumalı veya geliştirmelidir; kısa ve öz kuralları yerine getiren ayrıntılı kurallar, yalnızca bu gerekçelerle reddedilir. Bu bir tarz tercihi değil. Bu bir yük kısıtlamasıdır. Anayasa bütçeyi aşarsa, daha küçük bağlam pencerelerindeki aracılar bütçeyi kısaltmaya başlar ve kısaltılmış kurallar kural değildir.

**Ön madde yoluyla koşullu yükleme.** Yalnızca belirli dosya türleri için geçerli olan kurallar, standart gövdeden çıkarılır ve bir ön madde glob bildirimine sahip yol kapsamlı talimat dosyalarına dahil edilir. Erişilebilirlik ve yerelleştirme kılavuzu yalnızca aracı JSX veya CSS'ye dokunduğunda yüklenir. Altyapı yönlendirmesi yalnızca temsilci Bicep'e dokunduğunda yüklenir. Kanonik gövde tek satırlık bir işaretçiyi tutar. Aracı, yol kapsamlı dosyayı yalnızca ilgili olduğunda yükler. Bu sadece verimlilik değildir; erişilebilirlik kılavuzunun, aracıyı bunu görmezden gelmeye eğiten bir altyapı düzenlemesinde dikkat dağıtıcı bir unsur olarak ortaya çıkmasını engeller.

Bu proje, ön maddeyle ayrılmış kural dosyalarını kullanmaz çünkü anayasa tamamen bağlam içinde yüklenecek kadar küçüktür - tek bir geliştirici, odaklanmış bir kapsam, yalın bir kural kümesi. Daha büyük takımlar için hesaplar değişir. Şu anda EDD'yi çalıştıran kurumsal ölçekli bir projede güvenlik, uyumluluk, erişilebilirlik ve platforma özel gereksinimler açısından 75 katı kısıtlama bulunmaktadır. 75'in tamamını tek bir istekli yükleme dosyasında sıralamak, çoğu aracı için anayasayı bağlam bütçesinin çok ötesine itecektir. Ön madde bölme, kanonik gövdeyi 250 satırın altında tutar (etki alanı başına bir özet işaretçisi) ve tam kural ayrıntısını yalnızca aracı eşleşen yollara dokunduğunda tembel olarak yükler. Anayasa hızlı ve yalın kalıyor. Kurallar eksiksiz kalır. Token maliyeti sınırlı kalır.

**Değişiklik birimleri olarak değişiklikler.** Anayasa değişikliği, bir indirim dosyasındaki kelime değişikliği değildir. Bu, üç bileşenden oluşan bir pakettir: kesin kural deltası, gelecekteki ihlalleri tespit edecek doğrulama mekanizması ve temsilci davranışının iyileştiğini kanıtlayan bir davranışsal değerlendirme senaryosu. Üçü de aynı PR'da birlikte gönderilir. Değişiklik atomiktir. Doğrulamayı daha sonra eklemeyi vaat eden kısmi değişiklikler reddedilir - daha sonra gelmez ve doğrulanamayan bir kural dekorasyondur.

**Değerlendirmeleri ve değerlendirme listelerini, ihtiyacınız olduğunu düşünmeden önce yazın.** Değerlendirme, çark mandalıdır. Bu olmadan, değişiklikler iyi niyetle kabul edilir ve anayasa sapar. Değerlendirme tablosu, gerçekçi senaryolarda temsilci davranışını puanlar. Her yeni kural en az bir senaryo üretir. Değerlendirme tablosu sayısal bir puan üretir. Değişiklik yalnızca çalışma ağacı puanının taban çizgisini karşılaması veya aşması durumunda geçerli olur.

**Neleri yapabileceğinizi ve neleri kapsayamayacağınızı belgeleyin. Kapsama alanıyla ilgili kendinize yalan söylemeyin.**

Başlangıçta, erişilebilirlik katı kısıtlaması, yeni etkileşimli kullanıcı arayüzü yüzeylerinin balta çekirdeği kullanılarak e2e a11y kapsama alanı gerektirdiğini ilan etti. Bu kapsamlı hissettirdi. Uygulamada bu saflıktı. axe-core, WCAG'in anlamlı bir alt kümesini yönetir; DOM'un tamamen işlendiği ve renklerin çözümlendiği durumlarda eksik etiketleri, yer işareti yapısını, odak sırasını ve kontrastı yakalar. Hesaplanan rengin çözülemediği ekran okuyucu duyuru mantığını, bilişsel yük modellerini, karmaşık widget klavye sözleşmelerini veya degradeler ve SVG görüntü düğümlerini içeren kontrast sorunlarını yakalamaz.

Doğrulamada axe-core ile "[HC-A11Y-GATE]"'in bulunması a11y hatalarının sıfır olduğu anlamına gelmez. Bu, belirli bir eksen-çekirdek kural kümesinin oluşturulan DOM'a karşı çalıştığı anlamına gelir. PR kapsamı iddialarında fark çok büyük önem taşıyor.

Çözüm ayrışmaydı. "Balta çekirdeği temizliği" yerine doğrulama, balta çekirdeği kural setinin deterministik olarak hangi WCAG başarı kriterlerini kapsadığını (metin dışı içerik için 1.1.1, bilgi ve ilişkiler için 1.3.1, çözülebilir olduğunda kontrast için 1.4.3, ad/rol/değer için 4.1.2) ve sıfır otomatik kapsama sahip (1.3.3 duyusal özellikler, 2.4.6 başlıklar ve etiketler) numaralandırmak için yeniden yazıldı. anlambilim, tümü 3.x Anlaşılabilir ölçütler). Denetim boyutunun bilinen boşluklar bölümü artık açıkça şunu belirtiyor: balta çekirdeği bu kriterleri yönetiyor; bunlar için manuel tarama gereklidir. Halkla ilişkiler incelemecileri sahte güven özetini değil, gerçek kapsamı görüyor.

Daha geniş prensip: Her doğrulama için neyi yakalayıp neyi yakalamadığını belgeleyin. "Güvenlik tüysüz geçişleri" kod tabanının güvenli olduğu anlamına gelmez. "axe-core clean", WCAG 2.2 AA uyumlu olduğu anlamına gelmez. Boşluğa isim verin. Bunu denetim boyutuna kaydedin. Boşluk yüzeyi için manuel taramayı zorunlu kılın. Otomatik kontrolün, yerini alamayacağı insan yargısının yerine geçmesine izin vermeyin.

Adım 5 - Değişiklikleri nasıl yazıyoruz

Değişiklikler neredeyse hiçbir zaman değişiklik teklifi olarak başlamaz. Böcek olarak başlarlar.

Bir hata ortaya çıktı. Düzeltme uygulandı. Sevkıyattan önce, `/relect' bir soru sorar: Bu tek seferlik bir durum mu, yoksa anayasada bu türden bir başarısızlığı yakalayabilecek bir şey mi eksik? Cevap bir defaya mahsussa düzeltme gönderilir ve bu da son olur. Cevap bir şeyin eksik olduğuysa, bu, '/constitution' çağrıldığı zamandır.

**/reflect -> boşluk -> değişiklik yolu.** `/reflect' düzeltmeyi inceler ve sınıflandırır: anayasa boşluğu (bu başarısızlık sınıfını kapsayan hiçbir kural yok) veya doğrulama açığı (bir kural vardı ancak bunu zorunlu kılan bir otomatik kontrol yok). Her iki yol da '/constitution'a gider. Bir anayasa boşluğu yeni bir HC üretir. Doğrulama boşluğu, mevcut bir HC üzerinde daha sıkı bir doğrulamaya (tipik olarak yeni bir denetim boyutu alt bölümü, yeni bir tarama kuralı veya yeni bir değerlendirme senaryosu) neden olur.

**Gerekli üç yapıt.** `/constitute' aynı PR'de üçü de olmadan ilerlemeyi reddediyor:

  • **Kural deltası.** Sınıflandırılmış tam metin değişikliği: yeni kural, değiştirilmiş ifadeler, yer değiştirme (eskiyi değiştirin ve kaldırın), yerine geçme (eskiyle çıtayı taban olarak yükseltin) veya yer değiştirme. Kopyalar görüldüğü anda reddedilir.
  • **Doğrulama mekanizması.** Gelecekteki bir ihlali tespit edecek spesifik geçit - test adı, tüy bırakmayan kural kimliği, denetim boyutu alt bölümü, tarayıcı çıkış kodu kontrolü veya davranışsal değerlendirme senaryosu. Taahhüt zamanında var olması gerekir. Tespit edilebilir ihlallerin olmadığı kurallar dekoratiftir.
  • **Değerlendirme senaryosu.** "docs/methodology/eval/scenarios/<id>.md" konumunda saklanır. Eski kuralın yanlış temsilci davranışı ürettiği ve yeni kuralın puanlanabilir doğru yanıt ürettiği gerçekçi bir durumu açıklar.

**Cırcır.** Her üç eser de onaylandıktan sonra değişiklik bir şubeye uygulanır. Değerlendirme ana dal kurallarına ve çalışma ağacı kurallarına aykırıdır. Dereceli puanlama anahtarı her ikisini de puanlar. Geçiş, her senaryoda çalışma ağacı >= ana gerektirir. Regresyon, ifadeler sabitlenene kadar değişikliği engeller. Açık değişiklikler için mandal isteğe bağlı değildir: Hala ince gerilemeler üretebilirler ve değerlendirme, onları yere inmeden önce yakalayan tek mekanizmadır.

**Geriye dönük tarama.** Bir değişiklik, yeni kod kuralını anında düzeltir: `/audit`in fark kapsamı, değişikliğin yapıldığı andan itibaren yeni çalışmanın yeni çıtayı karşıladığı anlamına gelir. Yeni kuralı ihlal eden önceden var olan kod, '/rollout' aracılığıyla sıraya alınan ayrı bir tarama PR'si tarafından ele alınır. Düzeltme sitesinin önceden var olan her örneği satır içi olarak düzeltmesi gerekmez. Bu, değişiklikleri fahiş derecede pahalı hale getirecektir. Bunun yerine: yeni kod yeni çubukla hemen tanışır, eski kod kullanıma sunma kuyruğundadır ve tarama PR, önceden var olan örneklerin çözümlendiğine dair kendi kanıtını taşır.

'/constitution' için dört geçerli tetikleyici şunlardır: bir hata, bir olay, bir otopsi ve yeni bir sözleşme standardı. Dört tetikleyiciden hiçbirinin olmadığı "muhtemelen yapmalıyız..." şeklindeki teklifler reddedilir ve bunun yerine "/reflect"e yönlendirilir.

Adım 6 - Nasıl açarız

Taşınabilir Metodoloji Kiti ('EDD - Taşınabilir Metodoloji Kiti.md'), '/begin' komutunu çalıştırma talimatıyla birlikte herhangi bir AI temsilcisine verdiğiniz bağımsız bir belgedir. Aracı depoyu inceler, bir keşif geçişi çalıştırır, tespit edilen değerleri tek bir tabloda sizinle birlikte onaylar, yalnızca hangi keşfin cevaplayamayacağını sorar ve projeniz için minimum uygulanabilir iskeleyi ortaya çıkarır. Tam EDD altyapısının kurulması için tek oturum.

Bunu nasıl açacağınız tamamen yeni bir başlangıç ​​mı yaptığınıza yoksa onu mevcut bir kod tabanına mı getirdiğinize bağlıdır. İki yol ayrı ayrı ele alınabilecek kadar farklıdır.

**Greenfield.** Yeni bir projede, anayasada aklınıza gelebilecek her kuralı ilk günden koyun. Denetlemeniz gereken önceden var olan bir kodunuz yok, korumanız gereken ekip uygulamaları yok, büyükbabaya yönelik mevcut PR'larınız yok. İlk gün katılığın maliyeti neredeyse sıfırdır. Tüm katı kısıtlamaları, tüm denetim boyutlarını, tüm yol kapsamlı kuralları ekleyin. Daha sonra döngüyü çalıştırın. Hızlı bir şekilde keşfedeceğiniz şey, anayasanın nerede sürtünme yarattığıdır: her değişiklik tam bir denetimi tetiklediği için balonlaşan zamanlar oluşturun, kapsam çubuğu mevcut karmaşıklık için çok yüksek ayarlandığından test paketleri yavaştır, token bütçeleri sıkıdır çünkü kanonik gövde çok ayrıntılıdır. İlk günkü katılık, bu sorunları üretimde değil, geliştirme aşamasında ortaya çıkarıyor. Daha sonra optimizasyon yaparsınız: Yapı sınırlarını sıkılaştırın, kapsama kurallarını ayarlayın, anayasal yapıyı minimuma indirin. Hiçbir müşteri etkilenmeden, hiçbir ekip aksamadan her şeyi aynı anda dengelersiniz. Kısa vadeli maliyet, ilk sprintin biraz daha yavaş olmasıdır. Uzun vadeli kazanç, ilk taahhütten itibaren stres testine tabi tutulmuş bir anayasadır.

**Brownfield.** Mevcut bir kod tabanında, EDD'yi takip etmeyen mevcut bir ekip, mevcut uygulamalar ve mevcut PR'ler bulunur. Buradaki açılma artımlıdır ve yıkıcı değil, katkı sağlayıcı olmalıdır. İlk ayın amacı, geçmişteki her kararı yenilemek değil; EDD'yi güvenilir kılan teminatı oluşturmaya başlamaktır: gerçek bir şeyi yakalayan bir denetim boyutu, ekibin halihazırda manuel olarak yaptığı inceleme kontrolünü otomatikleştiren bir katı kısıtlama, uçtan uca bir değişiklik döngüsü. Ekibin mevcut kalite sinyallerini hammadde olarak kullanın. Ekibin güvenlik için zaten bir tüysüz kuralı varsa, "[HC-SECURITY-LINT]" ekleyin ve onu mevcut kapıya yönlendirin; geliştiriciler için hiçbir şey değişmez, ancak artık anayasal kayıt, kapının gerçekte ne uyguladığını yansıtıyor.

Brownfield'ın temel kuralı şudur: Tartışmaları kazanmadan önce müttefikleri kazanın. İlk hafta kod tabanının her alanına dokunan tam bir anayasayı zorlamayın. Ekibin halihazırda en çok önem verdiği boyutla başlayın; genellikle güvenlik veya güvenilirlik. Değişiklik sürecinin daha önce gördükleri gerçek bir açığı kapattığını gösterin. Cırcır bileşiğini oradan bırakın. EDD'nin mevcut süreçlerinde gözden kaçan gerçek bir hatayı yakaladığını gören bir ekip, bir sonraki kurala yer açacaktır. EDD'yi kendilerine her şeyi yanlış yaptıklarını söyleyen bir belge olarak gören bir ekip, bunun etrafından dolaşacaktır.

**Neyin kilidini açar?** İster yeşil alan ister kahverengi alan olsun, açılmadan geçmenin nedeni anayasa belgesi değildir. Doğrulama mekanizması çalışmaya başladığında anayasanın mümkün kıldığı şey budur.

Üretim kodu kalitesi ve teslimat hızı, görmediyseniz gerçekten mantığa aykırı olacak şekilde bir araya geliyor. Mühendisler, döngünün yakalayabileceği gerilemelerdeki hataları ayıklamak için bağlam değiştirmeyi durdurur. İnceleme döngüleri kısalır çünkü PR'ler açıklamalar yerine kanıt taşır. Denetim otomatik olarak gerçekleştirilir ve en deneyimli incelemecinin yakalayabileceği sorunları işaretleyerek, incelemecinin gerçekten kendi muhakemesini gerektiren mimari kararlara odaklanmasını sağlar.

Bunun en açık kanıtı: Ekibe katılan, yapıya, özellik spesifikasyonlarına ve döngüye tam erişime sahip yeni bir mühendis, üretim kalitesindeki bir özellik katkısını ilk günden itibaren 48 saat içinde ana kontrol edebilir. Oyuncak değişimi değil. Bir dokümantasyon güncellemesi değil. Tam denetimden geçen, kanıtları olan gerçek bir özellik. Bu bir tesadüf değil ve özellikle sıra dışı bir mühendis değil. Korkuluklar, herhangi bir vasıflı geliştiricinin ilk günden itibaren ekibin kalite standardında çalışmasını mümkün kılar; çünkü kalite standardı, en uzun süre etrafta olan kişilerin kafasında kurumsal bilgi olarak taşınmak yerine yazılıdır, doğrulanabilir ve otomatik olarak uygulanır.

Ulaştığı şekil budur: Yapay zekanın doğrulama çalışmalarını yaptığı, korkulukların, aksi takdirde kod incelemesinden kaçabilecek arıza sınıflarını yakaladığı ve mühendislerin, aslında mühendislik muhakemesi gerektiren problemler üzerinde düşünme zamanlarını harcadığı bir ekip.

Bu, farklı ölçeklerde doğrulandı; önce solo projeler, ardından orta ölçekli ekipler, ardından kurumsal ölçekli organizasyonlar. Mekanikler üçünü de koruyor. Açığa çıkarma maliyeti farklıdır (tek başına bir geliştirici, gereksinim kayıtlarını ve satıcılar arası rekabet incelemesini atlayabilir; kurumsal bir ekibin bunlara ihtiyacı vardır). Değişiklik temposu farklıdır (kişisel bir proje '/constitute' çağrıları arasında haftalarca sürebilir; birden fazla katkıda bulunan aracıya sahip bir kurumsal ekip bunları haftalık olarak yürütür). Ancak çekirdek döngü, çark ve kanıt gerekliliği, ekibin büyüklüğü ne olursa olsun aynı şekilde davranır. Kalite tabanı yalnızca yükselir ve doğrulama mekanizması, o hafta odadaki en deneyimli incelemecinin kim olduğuna bağlı kalmadan kaliteyi orada tutar.

Yapay Zeka Kancaları

Anayasa, aracı davranışını yüklü bağlam aracılığıyla yönetir. Kancalar, eylem anında, iş bitmeden ve PR açık olmadan önce bunu uygular. Kancalar olmadığında, bir ihlal inceleme sırasında yakalanır: temsilci kodu zaten yazmıştır, PR mevcuttur ve bunu düzeltmek işin yeniden yapılması anlamına gelir. Kancalarda, müdahale herhangi bir tuşa basılmadan önce gerçekleşir.

**Hem Claude Code hem de GitHub Copilot, anında gönderildiğinde bir kanca çalıştırır.** Yeni bir görev geldiğinde, aracı herhangi bir şey yapmadan önce kanca etkinleşir. Görevi: Görevin önemsiz olup olmadığını kontrol etmek, ardından görev listesini "/wow" döngüsüne (acentenin herhangi bir şeyi göndermeden önce izlemesi gereken 10 adımlı EDD dizisi) yeniden bağlamak.

Adım Tanım
1 Göreve ilişkin dokümanları güncelleyin
2 Testleri yazın veya güncelleyin (E2E veya birim)
3 Hedeflenen testleri çalıştırın - FAIL'i onaylayın
4 Kanıttan ÖNCE yakalayın
5 Görevi uygula
6 Hedeflenen testleri çalıştırın - PASS + tam paket yeşilini onaylayın
7 Kanıttan SONRA yakalayın
8 Dokümanların eşleşme uygulamasını doğrulayın
9 '/audit' komutunu çalıştırın - Kritik/Yüksek bulguları düzeltin
10 Özetleyin ve gerçek kişilerin incelemesini bekleyin

1-4 arasındaki adımları tamamlamadan 5. adıma ulaşan bir temsilci döngüyü ihlal etmiştir. Kanca, sırayı oturum başlangıcında değil, oturum başlangıcında belirler.

**Claude Code** ayrıca herhangi bir dosya yazma, terminal komutu veya git işleminden önce bir araç öncesi çağrı kancasını harekete geçirir. Döngü adımları karşılanmadıysa bir taahhütte bulunulamaz.

**GitHub Copilot** ayrıca bir Halkla İlişkiler oluşturma kancasını harekete geçirir. Halkla İlişkiler açıklaması sonlandırılmadan önce kanca, kendi kendini inceleme modunda "/audit"i çalıştırır; boyut ihlallerini, eksik kanıtları ve boş test planlarını, bir insan incelemeci taslağı görmeden önce yakalar. İncelemeciye ulaşan şey zaten ön elemeden geçmiştir.

**Codex ve diğer aracıların** bu yazının yazıldığı an itibarıyla yerel bir kanca yüzeyi yoktur. Yedek, PR'ler oluşturulduktan hemen sonra yorum yapan ve ihlalleri işaretleyen bir CI izleme botudur. Bu bir ilk yüzey kapısı değil, bir geri döndürmez kilittir; ateşlendiğinde iş zaten bitmiş olur, dolayısıyla kancaların ortadan kaldırdığı yeniden işlemeyi engellemez.

Aktif kancaların olduğu bir projede ihlaller oturum sırasında satır içi olarak düzeltilir. Temsilci boşluğu yakalar, kanıtı üretir ve en başından itibaren onu dahil eder. İnceleme süresi düşer. Yeniden çalışma ortadan kalkar. Anayasa, aracının okuduğu bir belgeden, aracının içinde gerçek zamanlı olarak çalıştığı bir kısıtlamaya doğru hareket eder.

Ek – Tam Anayasa

Aşağıda bu projenin asıl `CONSTITUTION.md`si yer almaktadır; tek bir geliştiriciye ait, tamamen özerk, yapay zeka destekli bir geliştirme projesi. Bu kod tabanında yapılan her önemsiz değişikliği yönetir. Bu bir şablon veya illüstrasyon değildir. Bu, her oturumda her temsilci tarafından yüklenen canlı belgedir.

Ana sayfaya don

Kaynaklar