- Büyük prodüksiyon kod tabanlarında en yeni dil modelleriyle sonuç almak için bağlam mühendisliği ilkeleri ve pratik iş akışları sunan bir yazı
- Temel fikir Frequent Intentional Compaction; geliştirme süreci boyunca bağlamı yapılandırıp sıkıştırarak ajanın karar kalitesini ve ilerleme trajektorisini istikrara kavuşturuyor
- Araştırma → planlama → uygulama şeklindeki 3 aşamada ön araştırma çıktıları ve plan belgeleri oluşturuluyor, insan incelemesi yüksek kaldıraçlı noktalara yerleştirilerek slop ve yeniden iş azaltılıyor
- Gerçekte Rust tabanlı 300 bin LOC’lik BAML üzerinde bug düzeltme ile iptal/WASM desteği gibi karmaşık görevlerin kısa sürede tamamlandığı örneklerle bunun brownfield ortamlarında da geçerli olduğu gösteriliyor
- Sonuç olarak AI ile kod yazmak bir oyuncak değil, incelikli bir mühendislik zanaati; ekip düzeyinde süreç/kültür dönüşümü rekabet avantajının anahtarı
Arka plan: Karmaşık kod tabanlarında AI sınırları ve sorun tanımı
- Çoğu geliştirici, AI kodlama araçlarının gerçek prodüksiyon kod tabanlarında beklendiği kadar iyi çalışmadığını zaten biliyor
- AI kodlama araçlarının büyük kod tabanlarında ve karmaşık görevlerde üretkenliği düşürdüğünü gösteren araştırmalar bulunuyor
- Stanford araştırmasına göre, AI araçlarının eklediği kodun önemli bir bölümü daha önce AI’ın ürettiği yetersiz kodun tekrar düzeltilmesine giderek tekrarlı işe yol açıyor
- AI kodlama ajanları yeni projelerde veya küçük değişikliklerde etkili olsa da, büyük kod tabanlarında geliştirici üretkenliğini tersine düşürebiliyor
- Bu yüzden sahadaki yaygın tepki, “şimdilik zor, biraz daha akıllı modeller çıkınca” şeklinde temkinli bir yaklaşım oluyor
- Ancak gerçek bir 300.000 LOC büyüklüğündeki Rust kod tabanında bağlam mühendisliği uygulandığında, mevcut modellerle bile hem üretkenlikte hem kalitede piyasa seviyesinin üzerine çıkılabildiği görülmüş
- Buradaki anahtar, geliştirme süreci boyunca AI’a verilen bağlamı yapılandırılmış ve yönetilen bir forma sokan sık ve kasıtlı sıkıştırma (frequent intentional compaction)
- Sonuçta ‘AI ile kodlama’, teknik ustalık gerektiren bir alan
Düşünsel temel: “Specs are the new code” ve üretkenlik araştırmaları
- AI Engineer 2025’teki iki sunum, düşünce biçimini değiştirmiş
- Sean Grove’un "Specs are the new code" sunumunda, “sohbet tarzı prompt’ları bırakıp spesifikasyonları kod gibi saklayın” deniyor
- Prompt’ları atıp sadece ortaya çıkan kodu commit etme pratiği, kaynak kod olmadan yalnızca binary check-in etmek ile kıyaslanıyor
- Stanford’un AI’ın geliştirici üretkenliği üzerindeki etkisine dair araştırması, AI kısa vadeli çıktıyı artırsa bile kalite düşüşü ve yeniden iş nedeniyle net etkinin azalabileceğini ima ediyor
- 100 bin geliştiricinin commit’lerinin analizinde, AI araçlarının yeniden işi artırarak üretkenlik kazanımını dengelediği gözlenmiş
- Greenfield’da etkili olsa da brownfield ve yüksek zorluktaki işlerde ters etkinin sık görüldüğüne dair içgörü sunuluyor
İlke: Frequent Intentional Compaction kavramı
- Bağlam penceresini her zaman %40–60 düzeyinde tutup içerik fazlalığı, eksik bilgi ve yanlış bilgiyi en aza indiren sürekli sıkıştırma stratejisi benimseniyor
- Sıkıştırılan şeyler arasında dosya arama log’ları, kod akışı takibi, değişiklik geçmişi, test/build log’ları, büyük JSON gibi gürültüler var
- Her aşamanın çıktısı, bir sonraki turdaki giriş kalitesini güvenceye almak için yapılandırılmış artefaktlar olarak bırakılıyor
- Örneğin ilerleme özeti, hedef ve yaklaşım, tamamlanan adımlar, mevcut hata noktası gibi bilgileri içeren bir progress belgesi oluşturuluyor
İş akışı: Research → Plan → Implement
- Research aşamasında ilgili dosyalar, akışlar ve neden hipotezleri incelenip özet araştırma belgesi üretiliyor
- Gerektiğinde alt ajanlar kullanılarak taze bağlam içinde kapsam keşfi ve özetleme yapılıyor
- Plan aşamasında değiştirilecek dosyalar, değişiklik yöntemi ve doğrulama/test prosedürlerini ayrıntılı anlatan bir uygulama planı yazılıyor
- Plan, kod incelemesinden daha yüksek kaldıraçlı bir inceleme noktası olarak kullanılıyor
- Implement aşamasında plan adım adım uygulanıyor ve her adımdaki doğrulamanın ardından durum plan belgesine yeniden sıkıştırılarak biriktiriliyor
- Karmaşık görevlerde, aşamalar birleşirken bağlam yeniden hizalama yapılıyor
Anti-pattern’ler ve kademeli olgunlaşma
- Naif yaklaşım, sohbet akışında bağlamın kirlenmesi yüzünden özür döngülerine veya raydan çıkmaya yol açabiliyor
- Biraz daha iyi yöntem, oturumu sıfırlamak ve “ek talimat prompt’ları” vermek; ancak temel gürültü kontrolü hâlâ zayıf kalıyor
- Kasıtlı sıkıştırma, ilerleme özeti dosyaları ve commit mesajları kullanarak bağlamı yeniden kuran daha iyi bir yöntem
- İdeal sıkıştırma çıktısının formatına dair örnekler veriliyor; hedef olarak doğruluk/tamlık/boyut/trajektori optimizasyonu belirleniyor
Bağlam optimizasyonuna teknik açıdan bakış
- LLM’ler durumsuz işlevler olduğu için kalite tamamen girdi bağlamına bağlı
- En kötü durum sıralaması yanlış bilgi > eksik bilgi > aşırı gürültü şeklinde
- Bağlam küçüldükçe avantaj artıyor; bu yüzden minimum girdiyle maksimum tutarlılık sağlayan sıkıştırma kilit önemde
- Basit döngüsel bir ajan çalıştırma stratejisine dair alternatif bakışlar da anılıyor (ör. “Ralph” süreci)
Alt ajanların rolü: İnsan rolü yapmak değil, bağlam kontrolü
- Alt ajanlar, arama/özetleme/düzenleme işlerini bağımsız bağlamlarda yaparak ana ajanın penceresini temiz tutuyor
- İdeal yanıt, hedef/durum/yol bilgilerini yapılandırılmış sıkıştırılmış çıktı halinde döndürüyor
- Alt ajanlar sayesinde keşif maliyeti yerelleştiriliyor, asıl iş bağlamının odak düzeyi yükseliyor
Vaka 1: BAML bug düzeltmesinin tek seferde geçmesi
- 300 bin LOC’lik Rust tabanlı BAML içinde, projeye yeni giren bir kişinin bug fix PR hazırlayıp birkaç saat içinde onay alması örnek olarak veriliyor
- Araştırma belgesi birkaç kez döndürülerek kalitesi artırılmış, ardından son plan temel alınarak uygulamada ilk geçişte başarı sağlanmış
- Bu yaklaşım, brownfield’e uygunluk, slop’un giderilmesi ve hizalamanın korunması gibi hedeflerin çoğunu karşılıyor
Vaka 2: BAML’ye iptal/WASM desteği, 35k LOC
- İki kişinin 7 saat içinde iptal özelliği ve WASM derleme desteği eklediği büyük bir değişiklik çalışması gösteriliyor
- Ekip tahminine göre kişi başı 3–5 günlük iş, research/plan/implement hattıyla kısaltılmış
- Bazı PR’lar hemen merge edilmiş, bazıları ise çalışan demo düzeyinde açık bırakılmış; böylece yüksek zorluktaki görevlerin çözülebileceği gösterilmiş
Sınırlardan ve başarısızlıklardan öğrenmek
- Parquet Java’da Hadoop bağımlılığını kaldırma girişimi, bağımlılık ağacının yeterince derinine inilmediği için bir başarısızlık örneği olarak kalmış
- Sonuç: Her problem 7 saatlik prompting ile çözülmüyor; alan uzmanlarının katılımı gerekiyor
- İnsan incelemesinin kaldıraç etkisi, araştırma > plan > kod sırasıyla artıyor; araştırmadaki yanlış tek bir satırın binlerce satır hataya büyüme riski var
Ekip hizalaması için belge öncelikli yaklaşım
- Kod incelemesinin özünün zihinsel hizalamayı (mental alignment) korumak olduğu görüşü ortaya konuyor
- Büyük PR zincirleri, ekipte ürün anlayışının kaybına ve kaygıya yol açabildiği için, spesifikasyon/plan/araştırma ile hizalama maliyeti düşürülüyor
- Mühendisler 2 bin satır koddan ziyade 200 satırlık bir plan belgesini daha sık ve daha doğru okuyabiliyor
- Tanıdık olmayan bir alandaki sorunlara müdahalede bile araştırma prompt’u hızlı bir rehber görevi görüyor
Genel değerlendirme ve maliyet yapısı
- Tüm hedeflerin karşılandığı belirtiliyor: brownfield uyumluluğu, karmaşık problem çözümü, slop’un en aza indirilmesi ve ekip hizalamasının korunması
- İşletme maliyeti açısından 3 kişilik ekip, aylık yaklaşık $12k Opus token maliyeti ile çalışıyor
- İstisnalar olsa da bunun genel olarak işe yarayan bir metodoloji haline geldiği vurgulanıyor
Gelecekteki değişim ve ürünleşme
- Kodlama ajanları emtialaşacak; asıl zorluk organizasyon ve iş akışı dönüşümü olacak
- AI’ın kodun %99’unu yazdığı bir dünyada, işbirliği biçiminin baştan aşağı yeniden kurulması rekabetçiliğin kırılma noktası olacak
- Bunu desteklemek için CodeLayer adlı bir “post-IDE” aracı private beta olarak açılmış
- Claude Code için Superhuman olmayı hedefliyor ve spec-first ajan tabanlı geliştirmeyi hızlandırıyor
3 yorum
Reklam bitişi...
CodeLayeradlı bir hizmetin tanıtımıyla sona eriyor...Hacker News görüşleri
İlgi çekici bir yazıydı ve özgün fikirler de vardı. Ama bu tür iddiaların sorunlu olduğunu düşünüyorum. Sean, yapay zekanın gelişmesiyle birlikte gelecekte spec dokümanlarının gerçek kod haline geleceğini öngörmüş. Önümüzdeki 2 yıl içinde insanların IDE’de Python dosyalarını kontrol etme sıklığının, bugün insanların assembly görmek için hex editor açma sıklığına ineceğini söylüyor. Başta rahatsız edici gelse de, PR’lardaki kodu tek tek okumak yerine testlere odaklanmayı ve spec’i gerçek kaynak olarak görmeyi benimsediğini anlatıyor. Ancak LLM’lerin non-determinism sorunu yüzünden, prompt ne kadar iyi olursa olsun her zaman makul bir implementasyon beklenemez. Compiler’lar deterministiktir; hata olsa bile yeniden üretilebilir ve debug edilebilir, ama LLM’ler öyle değil
Junior geliştiricilerle çalışırken bile implementasyon belli ölçüde deterministiktir. Ama AI modellerinde, açık talimat verseniz bile tekrar tekrar tamamen farklı implementasyonlar çıkabiliyor
İlginç olan şu ki aslında spec dokümanının kendisi de zaten non-deterministic. Requirements’ı kimsenin yanlış anlayamayacağı şekilde İngilizce yazmaya çalışırsanız, sonunda ortaya bir programlama dili çıkıyor
“Prompt kusursuz olabilir ama LLM’in bunu makul bir implementasyona çevireceğinin garantisi yok” endişesine katılıyorum. Hatta doğal dille yazılmış prompt’lar çoğu zaman doğası gereği belirsiz ve eksik oluyor. Bu yüzden yaratıcı çıktı gereken yerlerde iyi bir yön olabilir, ama yazılım gereksinimlerini tanımlamak için doğal dil uygun olsaydı, yazılım mühendisliği bunu onlarca yıl önce çözmüş olurdu. LLM’ler beni heyecanlandırdı ama bununla her sorunu çözmeye çalışmak fazla iddialı geliyor. Gereksinim spesifikasyonu açısından, eski formal sistemler ve matematiksel doğrulama girişimlerine benziyor ama tam zıt uçta duruyor. Bu da kısmen başarısız olsa bile yazılım geliştirme hakkında yeni içgörüler verecek bir deney gibi geliyor. Bazı alanlarda gerçek değer üretecek, bazılarında ise tamamen terk edilebilir. İlginç zamanlar
Aslında insanların açık ve ayrıntılı teknik spec ya da dokümanları iyi yazdığı durumlar da pek yok. Olsa bile bunun 2 yıl içinde yaygınlaşacağını sanmıyorum. Yazılım mühendisliğini gerçekten derinlemesine anlayan bir teknik yazar, gerçekten koda bakmadan sadece AI ajanına iyi prompt vererek tatmin olur mu? Buna katılmıyorum. Bu daha çok tipik bir “mühendislerin insanları makine gibi görmesi” yaklaşımı gibi
“Compiler sayesinde her build’de assembly görmek için hex editor açmak zorunda değiliz” iddiası da, elbette araçlar iyileştiği için doğru; ama HPC bilimsel araştırma alanında compiler’ın kritik loop’ları doğru vectorize edip etmediğini kontrol etmek için Intel VTune gibi araçlarla assembly’yi doğrudan incelemek sık görülen bir şeydi
Bu deseni iki farklı codebase’de kullandım. Biri 500 bin satırlık büyük, monolitik bir apache airflow repo’suydu; diğeri ise flutter ile sıfırdan yaptığım kişisel bir side project’ti. flutter ve dart benim gerçekten hiç bilmediğim alanlardı. Buna rağmen bu yöntemin işe yaradığını hissettim. Greenfield projede neredeyse sadece
/create_plançalıştırmak yetiyordu ve ajanın tüm desteğinden yararlanabiliyordum. Önemli olan, AI’ın ürettiği dokümanları dikkatle review etmek. Benim kaçırdığım ve endişelendiğim edge case’leri ele alıp almadığını, teknik tercihlerin yerinde olup olmadığını kendiniz kontrol ediyorsunuz. Örneğin sqlite desenini bozup postgres önermesi gibi hatalı kararları hemen fark edebilirsiniz. Genelde ajanla doğrudan chat ederek planı anında düzeltebiliyorsunuz. Şirkette GitHub Copilot kullanmak zorunda olduğum için prompt’ları biraz farklı yazmam gerekiyordu ama adımlar arasında bilinçli compaction hâlâ yapıyorum. Copilot, Claude Code gibi sub-agent desteklemiyor ama yine de verimlilik korunuyor.Bir kişisel deneyim de paylaşmak istiyorum. AI kodlama desteği çağından hemen önce, işimin fazla sıkıcı hâle geldiğini düşündüğüm için ciddi şekilde depresiftim. Birden çok repo, takım ve farklı insan karakterleri yüzünden büyük codebase’lerde çalışmak hep angarya doluydu. AI coding’in benim için en iyi tarafı, bu küçük ama yorucu işleri akıcı şekilde halletmesiydi. Ben iyi çalışan bir şey inşa etmekten büyük tatmin duyuyorum ama sürekli bu ufak işlerde tıkanıp kalınca o keyif kayboluyordu. Şimdi ise düzenli olarak iyi sonuçlar çıkarıyorum ve kendimle gurur duyuyorum
Büyük codebase’lerde çalışırken kullandığım bir paket yaptım: [GitHub.com/iambateman/speedrun]. Önce
/featureile özellik açıklamasını giriyorsunuz; sonra codebase analizi başlıyor ve size sorular soruyor. Ben cevaplayınca planı markdown formatında yazıyor. Bu süreçte 8-10 markdown dosyası oluşuyor ve içinde ne yapılacağıyla birlikte örnek kodlar da yer alıyor. Sonra “code critic” aşaması geliyor; hataları bulmaya çalışıyor ama aslında %60’ında yanılıyor. Ben de bu geri bildirimden alakasız hataları ayıklıyorum. Bu noktada elimde, istediğim değişiklikleri ve özellik açıklamasını içeren temiz bir klasör oluyor. Ardından Claude Code’a sadece “devam et” demem yeterli oluyor, o da işi adım adım yürütüyor. Bu yöntem yönün sapmasını engelliyor ve sonuca güven duymamı sağlıyor. Bu workflow’u her gün birkaç kez büyük işlerde kullanıyorum; daha nispeten somut işler içinse normal Claude code kullanıyorum. Bence oldukça verimli bir workflowİnsanların neden bu kadar karmaşık bir süreçten geçmek istediğini hiç anlamıyorum. LLM’den biraz destek alan normal kodlamanın bundan daha üretken olduğunu düşünüyorum
LLM’leri büyük codebase’lerde kullanırken en büyük sorun, aynı hataları tekrar etmeleri. Her görevde mimariyle ilgili kararları bağlam içinde nasıl sürekli izlediğinizi merak ediyorum
Gerçekten harika görünüyor. Arada bir pseudo code aşaması var; önceden workflow veya süreç tanımı yapmanın gerçekten yardımcı olup olmadığını merak ediyorum. Bir de her dosyayı 100 satırın altında tutmanın önemli olduğuna dair şeyler duydum, siz de benzer şekilde düşünüyor musunuz merak ediyorum
Bu yazı sanki Claude code’da context yönetiminden tamamen vazgeçtiğim anın bir zaman kapsülü gibi. Kodun her parçası için klasörler içinde ayrı spec’ler oluşturdum ve özellik bazlı log’lar tuttum. Python ile API server’ın birden fazla alt sistemini yönetiyordum: hesaplar, bildirimler, abonelikler vb. Durum karmaşıklaştıkça Claude business logic’i düzgün kavrayamaz oldu ve context yönetimi aşırı zorlaştı. Örneğin basit bir RBAC sistemi kurmaya çalışırken, hesap-profil ilişkisini anlatan UML diyagramını ve örnekleri bile vermem gerekiyordu ki ancak o zaman beklediğim gibi çalışsın
research_codebase.mdoluşturmamızın kritik neden olduğunu düşünüyorum. En büyük soru şu: “Bu codebase bize emanet edildiyse, yapısını bilmiyorsak modele nasıl iş yaptırabiliriz?” Ağırlıklı olarak AI tarafından yazılmış kodda iki sorun var. 1) Koda aşina değilseniz akışı ve işlevleri hızlı anlamak için bir research aşaması gerekiyor 2) Devasa PR review’ları çok acı verici; plan ise değişen şeyleri ve nedenlerini yapılandırılmış biçimde özetliyor. Bu arada Mitchell’in ampcode’un thread paylaşım özelliğini çok övdüğünü gördüm; bu da #2 için iyi bir çözüm [https://x.com/mitchellh/status/1963277478795026484]AI kullanımı hakkında her yerde türlü türlü beyanlar ve iddialar var ama gerçek, somut süreçlerini ya da prompt’larını paylaşan pek yok. Lafla kulağa etkileyici gelmek kolay; gerçekten faydalı olması için prompt log’larının bırakılması lazım. AI tarafından üretilen commit’lerde hangi prompt’ların kullanıldığına dair log’lar da olmalı; tıpkı commit log’una bakar gibi prompt log’unu da izleyip kodun nasıl yazıldığını anlayabilmeliyiz
Yazar, 35K satır kodu 7 saatte araştırıp implemente ettiğini övünerek söylüyor ama gerçekte 7 güne yayılmış 40 commit var. Günde bir saat mi çalıştı acaba diye düşündürüyor. Ayrıca son commit’lerden birinin “bazı testleri ignore et” olması da komik
“Birkaç hafta sonra @hellovai ile birlikte BAML’e 35k LOC ekleyip cancellation support ve WASM compilation gibi yeni özellikler getirdik. Mevcut ekip her bir özelliğin 3-5 gün süreceğini tahmin etmişti” diye bir cümle vardı. O zaman kıdemli mühendislerin günde 4-6KLOC yazacağını mı düşünüyorlardı? (genAI öncesinde?)
Burada eksik olan gerçek şu: kıdemli bir mühendis muhtemelen bunu gerçekte sadece 2KLOC ile çözerdi
Ve aslında yazar başka bir yerde bu işin gerçekte bir hafta sürdüğünü kabul ediyor https://news.ycombinator.com/item?id=45351546
“Başta rahatsız ediciydi ama PR’daki tüm kodu okumaktan vazgeçtim, onun yerine sadece testleri dikkatle kontrol etmeye başladım. Spec gerçek kaynak oldu” kısmına tamamen katılıyorum. Rolümüzün, implementasyon detaylarını bizzat yazmaktan çok davranışı tanımlama ve doğrulama tarafına kaydığını hissediyorum. Yakın zamanda S3-to-SFTP Python operator’üne recursive upload eklememiz gerekti ve karmaşık path flag’leri vardı. Sürecim şöyleydi: 1) Mevcut davranışı açık bir spec olarak çıkarmak, yani unit test’leri geçirerek 2) Spec’i yeni özellik için genişletmek 3) Sorunu ve testleri coding agent’a vermek. Sonunda fark ettim ki eski kodu hiç anlamam gerekmiyormuş. Benim odaklandığım tek şey yeni kodun spec’e uyup uymamasıydı. Gelecekte değerimiz, doğruluğu doğrulamakta olacak; gerçek kod ise agent’ların halledeceği bir ayrıntıya dönüşecek
“Rolümüzün implementasyon detaylarını yazmaktan davranışı tanımlama ve doğrulamaya kayması” fikrine katılıyorum. Hatta bunun zaten esas işimiz olduğunu da düşünebiliriz. Yüksek seviyeli diller, compiler’lar ve diğer soyutlamalar sayesinde implementasyon detayı yazmaya harcanan zaman zaten sürekli azalıyordu
“Benim odak noktam yeni kodun spec’e göre davranıp davranmadığıydı” kısmı bana Postel yasasını (Postel's Law) hatırlattı. Yaygın kullanılan bir sistemin gözlemlenen davranışı, hataları ve implementasyon kusurlarıyla birlikte fiilen onun public interface’i ve spec’i hâline gelir. Kodun client tarafının spec’e gerçekten uyup uymadığını test etmek ve sapma varsa bunu tespit edip ele almak da gerekebilir
Claude Plays Pokemon da aynı şeyi gösterdi. AI, bir şeyin gerçekten iyi çalışıp çalışmadığını değerlendirmede zayıf. Hatta çoğu zaman aynı yerde dönüp duruyor. Ama insan araya girip yön verdiğinde çok güçlü bir kombinasyon ortaya çıkabiliyor
Eğer davranışın her yönünü tanımlamaya gerçekten çalışırsanız, sonunda neredeyse kodun tamamını yazmış olursunuz. PR’daki tek bir satırın bile anlamı hemen anlaşılmıyorsa, muhtemelen genel davranışı yeterince tanımlamamışsınızdır
“Önümüzdeki birkaç yıl içinde spec dokümanları gerçek kod olacak ve Python dosyalarını açmaya neredeyse gerek kalmayacak” iddiası vardı. Bunun gerçekleşmesi için AI kod üretiminin %99,9 doğrulukta olması ve hallucination’ın neredeyse sıfır olması gerekir. Compiler’lara güvenip assembly koduna bakmıyorsak, bunun sebebi çıktının her zaman aynı olması ve hatasız olduğuna güvenmemizdir (nadiren bug veya optimization sorunu olur ama genelde tek seferde düzeltilir). Şu an ise AI’ın ürettiği kod spec’ten, yani asıl koddaki niyetten saparsa, dönüp bunu yine insanın düzeltmesi gerekiyor
Implementasyonu bölüp iş birimleri hâlinde ele alma veya review etme önerisi çok etkileyiciydi.
ARCHITECTURE.md, büyük modüllerde iseDESIGN.mdtutulmasını öneririmCLAUDE-feature.mddiye bir dosya oluşturup implementasyon planını ve destek bilgilerini (codebase içinde erişilebilen ögeler gibi) oraya yazıyor. Dosyada eksik gördüğüm veya açıklaması karışık olan yerleri ek prompt’larla düzeltiyorum. Nispeten büyük prompt’lar arasında/resetyapıyorum, dokümana tekrar baktırıyorum ve yinelemeli olarak geliştiriyorum. Gerçek implementasyona geçerken de bir kez daha/resetyapıyor, planın her aşamasında checkpoint’lerde tekrar/resetyaptırıp ilerlemeyi dokümana güncelletiyorum. Genel olarak yeterince iyi çalışıyor ama iş yerinde buna ne kadar güvenirim emin değilim