Build'ler kendilerini nasıl doğrular

0:00 — bir build tamamlanır. Ajan "bitti" der, ki bu kodun yazıldığına dair bir iddiadır, çalıştığına dair değil. Bir AI builder'ın her kullanıcısı en az bir kez bu iki iddia arasındaki farkı hissetmiştir: önizleme açılır, üçüncü düğmeye tıklanır, hiçbir şey olmaz. Tam o anda bir demo odasının sessizleştiğini gördüm. Bu yüzden herhangi bir insan bir build'i görmeden önce, yaklaşık altı dakika boyunca kendisiyle tartışan bir zincirden geçer. İşte bu, ters giden ve sonra düzeltilen izlediğimiz bir build üzerinden, gerçekte nasıl görünüyor.

0:02 — kod incelemesi başlar. Kodu yazan ajanın kendi ödevini yeniden okuması değil — farklı bir prompt'a sahip, build'in geçmesinde hiçbir çıkarı olmayan ayrı bir ajan. Bu ayrım göründüğünden daha önemli. Saat 14:14'te hata yönetimi olmayan bir fetch çağrısının sorun olmadığına karar veren bir ajan, kendi işini kontrol etmesi istendiğinde saat 14:15'te de aynı şeyi düşünür. "Neyin bozuk olduğunu bul, dosyayı belirt" denen taze bir inceleyici, aslında bu görevde istediğiniz huysuz kıdemli mühendis gibi davranır. Geçmiş bir build'de sessizce hiç güncellenmeyen bir sepet toplamı yakaladı — `updateTotal`, `Cart.jsx` içinde tanımlanmıştı ama miktar değişikliği işleyicisine hiç bağlanmamıştı, yani fonksiyon vardı ve basitçe hiç çalışmıyordu. Kod incelemesinin var olduğu kategori budur: bir derleyicinin omuz silktiği şeyler.

0:04 — güvenlik denetimi. Kulağa geldiğinden daha dar, bilinçli olarak — bu bir pentest değil, AI tarafından üretilen kodda gerçekten ortaya çıkan bir avuç hatayı arayan bir kalıp avıdır. Dize birleştirmeli SQL. Sanki hikayenin tamamıymış gibi güvenilen, yalnızca istemci tarafı doğrulama. Ve ev özel: sabit kodlanmış bir API anahtarı, çünkü özelliği yazan ajanın önünde bir ortam değişkeni kuralı yoktu ve işe yarayan şeye uzandı. Bunu artık şaşırtıcı sayılmayacak kadar sık görüyoruz.

0:07 — bağlantılar ve SEO. Göz alıcı değil, ve bir müşteri fark edene kadar kimsenin fark etmediği şeyleri yakalıyor: bir gezinme bağlantısı şuraya işaret ediyor /pricing oysa sayfa aslında şurada üretildi /price, 404 veren bir sayfa için site haritası girdisi, hâlâ şablon yer tutucu metnini taşıyan bir meta açıklama. Bunların hiçbiri derlemeyi bozmaz. Ama hepsi, kullanıcılarımızın çoğunun siteyi kurma amacını sessizce baltalar — bulunmak, tıklanmak.

0:09 — erişilebilirlik. Bu otomatik bir axe-core geçişi, tam bir manuel denetim değil, ve bu değiş tokuşun size ne sağladığı konusunda dürüst olmakta fayda var. axe-core kontrast oranlarını, eksik alt metinleri, etiketlenmemiş form girdilerini, sekme sırası tuzaklarını yakalar — mekanik katman, tam bir WCAG incelemesinin işaretleyeceğinin yaklaşık %30-40'ı. Teknik olarak uyumlu ama kullanımı gerçekten kafa karıştırıcı olan bir ekran okuyucu deneyimini yakalamayacaktır. Sadece otomatik olanı seçtik çünkü saniyeler içinde çalışıyor ve burada üretilenlerin çoğu pazarlama siteleri ve küçük araçlar, kısmi bir denetimin biri için gerçek bir risk oluşturduğu türden uygulamalar değil.

0:11 — uygunluk. Bu katman "bu iyi mi" diye sormuyor, "vaat edilenle eşleşiyor mu" diye soruyor. Plan dört sayfa dedi, build üç sayfa gönderdi — uygunluk bunu fark eden şeydir. Plan çalışan bir iletişim formu vaat etti, gönderilen ise gönderme eylemi olmayan bir form — aynı katman, aynı yakalama. Kullanıcının doğrudan sorumlu tuttuğu kontroldür, çünkü soyut bir kalite kavramına değil, kullanıcının belirttiği amaca göre ölçüm yapar.

0:13 — tarayıcı içi kontrol, ve bizim build'in gerçekte bozulduğu yer burası. Bu katman taklit etmesi en zor olanı, çünkü kod okumaz, gerçek bir tarayıcı sürer — tıklar, yazar, bekler, DOM'un gerektiği gibi değiştiğini kontrol eder. Söz konusu build bir idle oyundu, ve oyunlar burada ekstra bir geçiş alır çünkü bir oyun piksel mükemmel render edebilir ve yine de oynanamaz olabilir — skor göstergesi kusursuz görünürken skor mantığından tamamen kopuk olabilir. Doğrulayıcı oynadı. Skor düzgün güncellendi. Ses hiç çıkmadı.

Üç tur, sonra bir yükseltme

Bulgu bize bir hata raporu olarak gelmedi — doğrudan bir düzeltme geçişine gitti, ve zincir yeniden doğruladı, build içinde üç tura kadar. Birinci tur: düzeltme, zaten iyi olan mikser başlatmasına dokundu, bu yüzden ses sessiz kaldı. İkinci tur: yakın görünen farklı bir yükleme durumu kenar durumunu ele alan farklı bir düzeltme — bu beklediğinizden daha sık oluyor — orijinali çözmezken küçük yeni bir sorun ortaya çıkardı. Üçüncü tur: hala sessiz, ve bu noktada genellikle ya gerçekten zor bir şeye ya da yanlış alarma bakıyorsunuzdur, ve bu zor türdendi.

Bu yüzden platform kendiliğinden yükseltti. Kalan bulguya tamamen odaklanmış bir takip düzeltme çalışması sıraya koydu, build'in kendisi üzerinde değil bir kopyası üzerinde çalışarak — yani yükseltme çalışması, zaten sahip olduğumuz çalışan sürüme mal olmadan başarısız olabilirdi. Bu çalışma gerçek nedeni buldu: önceki bir hata ayıklama geçişinde ayarlanmış ve hiç geri döndürülmemiş bir sessize alma bayrağı, önceki iki düzeltmenin dokunduğundan tamamen farklı bir dosyada duruyordu. Bayrağı temizledi, yeniden doğruladı, geçti. Bu build zaten çalışana kadar kimse ona bakmadı.

Bir dahaki sefere atlayacağım şey

O idle oyun çalışmadan birkaç ay önce, tüm sistemin daha yumuşak bir sürümünü denedik — doğrulayıcıların herhangi bir endişeyi, nasıl ifade edilirse edilsin dile getirmesine izin verildi. "Bunu bir yardımcı fonksiyona çıkarmayı düşünün" ve "bu değişken adı daha açık olabilir" gibi bulgular üretti, ki bunlar titizlik gibi okunuyordu ve hiçbir şeyi düzeltmiyordu. Düzeltme geçişleri, gerçekten bozuk olanı düzeltmek yerine düzyazıyı parlatarak tüm turları harcadı. Kuralı sıkılaştırdık: bir dosya belirtin, bir hatayı tanımlayın, ya da hiçbir şey söylemeyin. Doğrulayıcı çıktısı kabaca yarı yarıya düştü ve kalanların neredeyse hepsi eyleme geçirilebilirdi. Bunu sıfırdan yeniden kuruyor olsaydım, yumuşak sürümü tamamen atlar ve doğrudan kanıt kuralına giderdim — bu dersi pahalı yoldan öğrenmemiz gerekmiyordu, sadece öyle yaptık.

Kuralın gerçek bir maliyeti var, ve bunu inkar etmeyeceğim: "bu API tasarımı altı ay içinde birini ısıracak" gibi belirsiz ama doğru bir endişe artık göz ardı ediliyor, çünkü bir doğrulayıcı bunu somut bir hataya bağlayamaz. Bu değiş tokuşla barıştık. Aynı zamanda mimari inceleme de yapan bir zincir, her tek build'de çalışacak kadar hızlı değildir, ve hız, bunu bir insana sordurmak yerine otomatik çalıştırmanın tüm amacıdır.

Sorulursa, dördüncü bir tur eklemeyi de atlardım. Tur sayısını gerçek build'lere karşı ayarladık, ve üçüncü turdan sonraki marjinal değer sertçe düşüyor — birinci tur çoğu düzeltilebilir bulguyu çözer, ikinci tur çoğunlukla birinci turun yarattığı sorunları temizler, ve üçüncü turda kalan şey ya gerçekten zordur ya da hiç bozuk değildi. Dördüncü bir tur çoğunlukla aynı sonuç için daha uzun bekleme süreleri satın alır.

Bunların hiçbiri bedava değil, ve hiçbiri hatasız değil. Altı katman artı ne kadar düzeltme turu gerekiyorsa, her build'e gerçek zaman ekler — bir dakikadan kısa sürede bitirmekle birkaç dakikada bitirmek arasındaki fark. Kendi müşterilerinizin önüne koymak üzere olduğunuz her şey için bunun doğru değiş tokuş olduğunu düşünüyoruz, ama "hızlı" ve "doğrulanmış" zıt yönlere çeker, ve biz doğrulanmışı seçtik. Doğrulayıcılar da LLM'dir, bu yüzden bazen gerçekte bozuk olmayan bir şeyi işaretlerler ya da bozuk olan bir şeyi kaçırırlar. Kanıt kuralı ve çok turlu döngü buna karşı bir garanti değil, bir önlemdir.

Sonunda elde ettiğiniz bir kayıttır: hangi katmanların çalıştığı, ne bulduğu, ne düzeltildiği ve kendi takdirinize bırakılan her şey. Bu kayıt, koddan daha gerçek ürüne yakındır — bitmiş görünmesi nedeniyle bir build'e güvenmek ile, düşmanca bir şey onu bozmaya çalışıp başarısız olduğu için güvenmek arasındaki farktır.