Yaklaşık altı ay önce TaterTOS64 adında bir x86_64 çekirdeği geliştirmeye başladım. C, Assembly ve bağlayıcı komut dosyalarının 10 bin satırdan fazla bir hacme ulaştığı sistem programlama projelerinde, mimari detayların dokümantasyonu neredeyse imkansız hale geliyor. Özellikle kesme vektörlerinin zamanlayıcıya aktarımından, sayfalama mantığının fiziksel bellek haritasıyla ilişkisine kadar karmaşık bağıntıları insan hafızasına kaydetmek mümkün değildi.
Modern yaklaşıma güvenerek ilk adım olarak kodları büyük dil modellerine (LLM) verdim. Ancak sonuç tam bir hayal kırıklığıydı. Üç temel sorunla karşılaştım:
- Bağlam Körlüğü: Tek bir
.cdosyasını anlıyor, ancak#includezincirlerini takip edemiyordu. Örneğinpaging.hdosyasındaki sabitlerin aslında hangi konumda tanımlandığını tahmin etmek yerine uyduruyordu.
- Varsayım Döngüsü: Zamanlayıcının "mantıksal akışını" anlatırken, gerçekte var olmayan fonksiyonları referans gösteriyor ya da Assembly giriş noktalarını C fonksiyon imzalarıymış gibi yorumluyordu.
- SaaS Maliyeti: Yerel bir çekirdek inşa ederken, kendi koduma ait dokümantasyonu oluşturmak için aylık 20 dolarlık bulut hizmetlerine bağımlı kalmak istemedim.
Dokümantasyon İçin İki Haftalık Mola: TaterBookBuilder
İki hafta boyunca çekirdek geliştirmeyi durdurdum ve aslında ihtiyacım olan dokümantasyon derleyicisini inşa etmeye odaklandım. Buna TaterBookBuilder adını verdim.
Bu araç basit bir metin-girdi çıktı aracı olmaktan çok öte, deterministik bir analiz motoruna sahip. İşleyiş mantığı şu şekilde:
- Fiziksel İçerme Grafiği: Büyük dil modeline herhangi bir soru yöneltilmeden önce, araç proje dizinindeki tüm
#include(C) ve%include(Assembly) ifadelerini doğrudan kaynak kodundaki konumlarına eşleştiriyor. Böylece tip tanımlarının nereden geldiğini otomatik olarak izliyor.
- AST-İşlemeli Veri Toplama: Roslyn ve özel regex tabanlı parseller kullanarak sistemin mantıksal hiyerarşisini oluşturuyor. Dizindeki konumlandırma ve sistem çağrı giriş noktaları gibi sinyallerden yola çıkarak "Çekirdek Sınırları" ile "Kullanıcı Alanı"nı ayırt ediyor.
- Kanıt Haritası (Anahtar Yenilik): Dokümantasyonun sunduğu her iddia doğrudan koddaki belirli bir satır aralığına referansla destekleniyor. Örneğin, "Zamanlayıcı Yuvarlak Robin algoritmasını kullanır" ifadesi,
src/kernel/sched.c:L45-L120konumuna doğrudan bir dipnotla ilişkilendiriliyor. Bu sayede doğruluk sorunu ortadan kalkıyor.
Yerel ve Sürekli Dokümantasyon Felsefesi
Dokümantasyon kalıcı bir varlıktır; bulut aboneliklerine bağımlı olmamalıdır. Bu nedenle TaterBookBuilder Linux için hazırlanan 77 MB'lık bir AppImage paketi olarak sunuluyor. Araç içinde yerleşik olarak Pandoc statik ikilisi de bulunuyor, böylece kullanıcılar bağımlılık kurulumu yapmak zorunda kalmıyor.
Fiyatlandırma modeli olarak JetBrains yaklaşımını benimsedim: Tek seferlik satın alma ile aracın o versiyonu sonsuza kadar sahipliğinde kalıyor. Bir yıl boyunca bakım desteği sunuluyor; yenileme yapılmazsa bile dokümantasyon aracı eski halinde çalışmaya devam ediyor.
Dokümantasyon, tanımladığı kod kadar sağlam ve yerel olmalıdır.
Başka sistem geliştiricileriyle görüşmek istiyorum: AI destekli mimari haritalarla ilgili güven sorununu nasıl çözüyorsunuz?
Yapay zeka özeti
6 ayda sıfırdan x86_64 çekirdek inşa eden geliştirici, AI dokümantasyon araçlarının yetersiz kaldığını fark etti ve yerel, otomatik bir çözüm üretti. TaterBookBuilder nasıl çalışıyor?