Yapay zeka ile bağımlılık güncelleme: build’i bozmadan

Yapay zeka ile bağımlılık güncellerken okumayı ve tekrarlayan düzenlemeleri ajana bırak, güvenlik kurallarını ise kendinde tut: her major güncelleme ayrı dalda, kod değişmeden önce geçiş rehberi okunmuş ve işe yaradığının tek kanıtı test paketi. Claude Code, Codex ve Gemini CLI gibi kodlama ajanları güncellemelerin sıkıcı kısmında iyidir: seksen dosyada bir API’yi yeniden adlandırmak, test kurulumunu yeni çalıştırıcıya uyarlamak, anlaşılmaz bir peer dependency hatasını açıklamak. Burada çok önemli olan bir konuda ise kötüdürler: kütüphanenin eski sürümünü hatırlarlar.

Bu rehber küçük bir uygulamada da büyük bir monorepoda da işleyen bir akışı anlatıyor: envanter, sınıflandırma, kolay güncellemeleri toplu yapmak, zorları ayırmak, codemod’lar, lock dosyaları, doğrulama, bot PR’ları ve güvenlik uyarıları. Örnekler npm ve pnpm ile; farklı olduğu yerlerde Python karşılıkları da var.

Bağımlılık güncellemeleri ajanlarla neden ters gider?

Güncellemeler basit görünür, ters gitmelerinin sebebi de budur. Sık görülen hatalar:

• Eskimiş bilgi. Modelin eğitim verisi bir noktada durur. Ondan sonra çıkmış bir sürüme geçmesini istersen, bildiği sürüm için kendinden emin kod yazar.
• Kapsam kayması. “React’i güncelle” bir anda React, router, test kütüphanesi, ESLint ve üç eklentiye dönüşür, hepsi tek farkta.
• Kaleyi kaydırmak. Güncellemeden sonra bir test kırılır; ajan snapshot’ı günceller, assertion’ı gevşetir ya da testi atlar.
• Kurucuyu susturmak. Peer dependency çakışması, gerçekten uyumlu sürümleri bulmak yerine --force ya da --legacy-peer-deps ile “çözülür”.
• Lock dosyası kaosu. Ajan bir kurulum hatasını gidermek için lock dosyasını siler ve yüzlerce dolaylı paket aynı anda değişir.

Aşağıdaki her adım bunlardan birini engellemek için var.

Adım 1: envanter çıkar

“Her şeyi güncelle” gibi bir istemle değil, gerçeklerle başla. Her ekosistemin geride kalanları listeleyen yerleşik bir komutu var:

npm outdated            # Current, Wanted (highest in your range) and Latest
pnpm outdated           # add -r in a workspace
pip list --outdated     # for the active Python environment

Güvenlik görünümünü de ekle:

npm audit
pip-audit               # PyPA tool: pip install pip-audit

Sonra çıktıyı ajana ver ve değişiklik değil, sınıflandırma iste:

İşte npm outdated ve npm audit çıktısı. Henüz hiçbir şeyi değiştirme.
Şu sütunlarla bir tablo yap: paket, mevcut, wanted, latest, güncelleme türü
(patch/minor/major), doğrudan mı yoksa dev bağımlılığı mı olduğu ve
changelog ya da sürümler sayfasının linki. Güvenlik uyarısı olanları işaretle.
Sonra bir sıra öner: neler toplu yapılabilir, neler kendi dalını istiyor.

Bu salt okunur bir iş, yani planlama modunda ya da salt okunur izinle çalıştırmak güvenli. Tablo planın olur ve hangi güncellemelerin gerçekten büyük olduğunu erkenden gösterir.

Adım 2: kolay güncellemeleri topla

Patch ve minor sürümlerin geriye uyumlu olması beklenir. Pratikte genelde öyledirler, kalanı da test paketi yakalar. Hepsini tek dalda birlikte yap:

git switch -c deps/minor-patch
npm update              # stays inside the ranges in package.json

pnpm’de pnpm update aynı işi yapar, pnpm update --interactive seçmeni sağlar, pnpm update --latest ise major sürümleri de geçer; onu Adım 3’e sakla. Ardından:

Tüm test paketini, tip kontrolünü ve build'i çalıştır. Bir şey kırılırsa
hangi paketin sebep olduğunu bul ve testleri değil kodu düzelt. Bir düzeltme
birkaç satırdan fazlasını gerektiriyorsa o paketi önceki sürümüne geri al ve
ayrı bir güncelleme için listele.

Son cümle önemli. Topluyu küçük ve sıkıcı tutar, sürpriz çıkaran her şeyi kendi dalına taşır.

Adım 3: her major güncellemeye bir dal

Major sürüm tanımı gereği kırıcı değişiklik demektir. Her birine kendi dalını ver; birkaçını aynı anda yürütmek istiyorsan bir git worktree ile kendi klasörünü de:

git worktree add ../app-vite -b deps/vite-major
git worktree add ../app-eslint -b deps/eslint-major

Artık bir ajan build aracını, diğeri linter’ı güncelliyor ve ana klasörüne dokunulmuyor. Bir güncelleme bataklığa dönerse o worktree’yi ve dalı silersin, başka hiçbir şey kaybetmezsin. Kurulumun ayrıntıları git worktree ile paralel geliştirme yazısında.

Major’lar için iki kural:

• Her seferinde bir major adım. 3’ten 6’ya tek hamlede gitmek üç kırıcı değişiklik setini tek farka yığar. 3 → 4 yap, yeşile getir, commit’le, sonra 4 → 5.
• İlişkili paketleri birlikte güncelle, başka hiçbir şeyi değil. Bir framework ve resmi eklentileri çoğu zaman birlikte ilerlemek zorundadır. Bu sorun değil. İlgisiz paketler bekler.

Adım 4: koda dokunmadan önce geçiş rehberini oku

Eskimiş bilgi sorununu çözen adım bu. Ajan herhangi bir şeyi düzenlemeden önce geçtiğin sürümün gerçek dokümanını okumalı:

eslint'i 8'den 9'a yükseltiyoruz. Herhangi bir dosyayı düzenlemeden önce:
1. Resmi geçiş rehberini ve 9.0.0 changelog'unu oku.
2. Bu depoya uyan her kırıcı değişikliği, etkilediği dosyalarla listele
   (doğrulamak için kodda ara).
3. Her biri için ne yapacağını söyle.
Eski sürümler hakkında hatırladıklarını değil, kurulu paketin dokümanını ve
tip tanımlarını doğru kabul et. Onayımı bekle.

Ajanın internete erişimi varsa rehberi kendisi çeker; yoksa ilgili kısımları yapıştır ya da paket bir changelog getiriyorsa onu node_modules/<package>/CHANGELOG.md içinde göster. Bir MCP doküman sunucusu da burada işe yarar; bkz. en iyi MCP sunucuları.

Çıkan liste aynı zamanda sonraki inceleme kontrol listendir: her madde farktaki bir değişikliğe karşılık gelmeli.

Adım 5: önce codemod çalışsın

Pek çok framework codemod sunar: kodu yeni sürüm için mekanik olarak yeniden yazan betikler. Codemod deterministiktir, ajan değildir; o yüzden codemod yapabildiği her şeyi yapsın, kalanı ajana kalsın.

Bilinen iki örnek:

# Next.js: upgrades Next.js, React and React DOM and runs the codemods
npx @next/codemod upgrade major

# Angular: updates packages and runs their migrations
ng update @angular/core @angular/cli

Ekim 2026 itibarıyla Next.js dokümanı, @next/codemod upgrade komutunun stdin bir terminal değilken (ajan çalıştırdığında durum budur) etkileşimsiz çalıştığını ve tüm varsayılanları kabul ettiğini belirtiyor. Hangi codemod’ların uygulanacağını seçmek istiyorsan önce kendin çalıştır, sonucu ajana ver.

Codemod’dan sonra commit’le, ardından ajandan Adım 4’teki kalan maddeleri halletmesini iste: codemod’un işaretlediği ya da atladığı durumlar, eski API etrafındaki kendi sarmalayıcıların, test kurulumu ve yapılandırma dosyaları. Codemod çıktısını ve ajanın düzenlemelerini ayrı commit’lerde tutmak incelemeyi çok kolaylaştırır. Aynı fikir daha büyük geçişlerde de geçerli; yapay zeka ile eski kodu refactor etmek ve yapay zeka ile JavaScript’ten TypeScript’e geçiş adım adım geçişleri daha derin anlatıyor.

Adım 6: lock dosyasını değişikliğin parçası say

“Benim makinemde çalışıyor” cümlesini anlamlı kılan şey lock dosyasıdır. AGENTS.md ya da CLAUDE.md içine koymaya değer birkaç kural:

## Bağımlılıklar
- Kurulum hatasını gidermek için package-lock.json / pnpm-lock.yaml dosyasını asla silme.
- Sormadan --force ya da --legacy-peer-deps kullanma.
- CI'da npm ci ile kur; lock dosyasını package.json değişikliğiyle birlikte commit'le.
- Güncelleme görevi sırasında yeni bağımlılık ekleme.

Kurulum peer dependency yüzünden kırılırsa ajandan çakışmayı zorlamak yerine açıklamasını iste. npm explain <package> (diğer adı npm why) bir paketin ağaçta neden olduğunu ve kimin hangi sürümü istediğini gösterir; npm ls <package> tüm kopyalarını listeler. Gerçek çözüm çoğu zaman eski peer’i sabitleyen eklentiyi güncellemektir ve bu da aynı dala aittir.

İncelerken lock dosyasının farkına da bak. Tek bir doğrudan bağımlılığın minor güncellemesi üç yüz dolaylı kaydı değiştiriyorsa bir soru sormayı hak eder.

Adım 7: kendi kontrollerinle doğrula

“Kuruluyor” bitti demek değildir. “Bitti”yi istemde, ajanın kontrol edebileceği şekilde tanımla:

Bitti demek: npm ci başarılı, npm test geçiyor, tsc --noEmit geçiyor,
npm run build geçiyor ve geçiş rehberinin gerektirdiği yerler dışında hiçbir
mevcut test dosyası değişmedi (her birini açıkla).

Güncellediğin kütüphane etrafında test paketin zayıfsa önce, eski sürümdeyken birkaç test ekle ve güncelleme boyunca yeşil tut. Arayüz kütüphanelerinde gerçek bir tarayıcıda hızlı bir kontrol birim testlerinin kaçırdığını yakalar: tarayıcısı olan bir ajan ana sayfaları açıp konsol hatalarını raporlayabilir. Build araçlarında öncesi ve sonrası build çıktısının boyutunu karşılaştır; iki katına çıkmış bir bundle, tüm testler geçse bile bir hatadır.

Farkı üç soruyla incele: herhangi bir test değişti mi, dışarıdan görünen bir davranış değişti mi ve her düzenleme kırıcı değişiklik listesindeki bir maddeye karşılık geliyor mu?

Bot PR’ları: Dependabot ve Renovate artı bir ajan

Dependabot ve Renovate düzenli aralıklarla güncelleme PR’ı açmakta iyidir. Yapamadıkları şey, güncelleme bir şeyi bozduğunda kodu düzeltmektir. Ajanın üstlenebileceği kısım bu.

Kolay güncellemeleri tek PR’da toplayan minimal bir Dependabot yapılandırması:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"

Renovate karşılığı önerilen ön ayarla başlar:

{
  "extends": ["config:recommended"],
  "packageRules": [
    { "matchUpdateTypes": ["minor", "patch"], "groupName": "minor and patch" }
  ]
}

Bir bot PR’ı kırmızıya döndüğünde döngü şöyle:

gh pr checkout 123
gh pr checks 123              # find the failing run
gh run view <run-id> --log-failed   # the log of its failed jobs

Bu, zod'u bir sonraki major sürüme yükselten bir Dependabot PR'ı. CI aşağıdaki
logla kırılıyor. Kök nedeni bul, yeni sürümün sürüm notlarını oku ve kodumuzu
yeni sürümle çalışacak şekilde düzelt. Eski sürüme sabitleme ve hatayı
gizlemek için testleri değiştirme. Testleri yerelde çalıştır, push etmeden
önce değişikliği özetle.

Bir ayrıntı: Dependabot dalına kendi commit’lerini push ettiğinde Dependabot o PR’ı otomatik rebase etmeyi bırakır ve @dependabot recreate düzeltmeni silip atar. Ya kısa sürede birleştir ya da rebase’i kendin yap. Bu döngünün genel hali için CI hatasını yapay zeka düzeltsin yazısına bak.

Güvenlik uyarıları

npm audit ağacındaki bilinen açıkları listeler. Onu işe yarar tutan birkaç şey:

• Yayına çıkana odaklan. npm audit --omit=dev dev bağımlılıklarını dışarıda bırakır; --audit-level=high komutun yalnızca high ya da critical seviyede hata vermesini sağlar, bu da CI için mantıklı bir kapıdır.
• npm audit fix ile --force farkı. Düz audit fix tanımlı aralıklarında kalır. --force ile semver-major sürümler kurabilir; bunu hızlı bir düzeltme değil, Adım 3’teki gibi bir major güncelleme say.
• Dolaylı paketler. Açıklı paket ağacın derinlerindeyse ve üst paketi düzeltme yayınlamadıysa package.json içindeki npm overrides alanı (ya da pnpm’in pnpm.overrides alanı) yamalı bir sürümü zorlayabilir. Ajandan nedenini açıklayan bir yorum ya da issue eklemesini iste ki override sonra kaldırılsın.
• Erişilebilir mi diye sor. Ajana kodunun açıklı fonksiyonu gerçekten kullanıp kullanmadığını kontrol ettir. Bu düzeltmeyi atlayacağın anlamına gelmez ama bugün mü acil, yoksa haftalık topluya mı girebilir, onu söyler.

Python’da pip-audit bir ortam ya da requirements.txt için aynı tür bulguları raporlar; pip-audit --fix etkilenen paketleri yükseltmeyi dener. Ajanların kendisinin neleri kurmasına izin verilmeli konusu ise yapay zeka kodlama ajanı güvenliği yazısında.

Sık yapılan hatalar

• Tek istemde “tüm bağımlılıkları en sona güncelle”. Tek dev bir fark alırsın ve bisect etmenin yolu yoktur.
• Geçiş rehberini atlamak. Ajan hatırladığı sürüm için kod yazar.
• Testlerin sessizce değişmesine izin vermek. Rehber değişikliği açıklıyorsa güncellenmiş snapshot sorun değil; açıklamıyorsa bir regresyonu saklıyordur.
• Kurucuyu zorlamak. Bugünkü --force, sonraki kişi için bozuk bir kurulumdur.
• Paralel güncelleme dallarını birlikte test etmeden birleştirmek. İki yeşil dal birleşince kırmızı olabilir; bir birleştirme kuyruğu her birini en güncel main’in üstünde test eder.

AgentVera’da nasıl yapılır?

AgentVera; Claude Code, Codex ve Gemini CLI gibi kodlama ajanı CLI’larını yan yana çalıştıran, git’i içinde barındıran bir masaüstü uygulaması. Birkaç özelliği bu akışa doğrudan oturuyor:

• Her major güncellemeye bir worktree. Git panelinden bir worktree oluştur ve tek tıkla içinde bir ajan başlat; Vite güncellemesini bir panede, ESLint güncellemesini diğerinde yürüt.
• Haftalık bağımlılık kuralı. Otomasyonlar (Pro) cron zamanlamasıyla kendi worktree’sinde bir ajan başlatabilir. Hazır oyun kitaplarından biri “bağımlılıkları güncelle (yalnızca minor ve patch)”; sonuç PR olarak gelebilir ya da birleştirme kuyruğuna girebilir.
• Kırmızı CI’dan ajana. CI/CD merkezi GitHub Actions, GitLab CI ve Jenkins çalıştırmalarını listeler; başarısız bir çalıştırmada “Ajanla düzelt”, çalıştırma ayrıntıları ve en fazla üç başarısız işin log sonuyla bir Claude ajanı açar. Bir otomasyon da seçtiğin dallarda CI kırmızıya döndüğünde ajan başlatabilir.
• “Bitti” tanımına göre Verify. Mesajına “testler, tip kontrolü ve build geçiyor; hiçbir test dosyası değişmedi” yaz. Verify bunu kriterlere çevirir ve tur bittiğinde dosya düzenleyemeyen ayrı bir doğrulayıcı her birini kanıtıyla kontrol eder.
• İnceleme ve birleştirme kuyruğu. Kod incelemesi ajanın değiştirdiklerini ikinci bir modelle okur; birleştirme kuyruğu güncelleme dallarını en güncel hedefin üstüne tek tek indirir ve kontrol komutunu birleşmiş sonuçta çalıştırır.

Sonuç

Yapay zeka ile bağımlılık güncelleme, işin şeklini küçük tuttuğunda işe yarar: önce envanter, kolay güncellemeler tek toplu dalda, her major kendi dalında, ilk düzenlemeden önce okunmuş geçiş rehberi, ajandan önce codemod ve hakem olarak testler. Ajan seni okumaktan ve yüz küçük düzenlemeden kurtarır; süreç de o düzenlemeleri dürüst tutar. Güncelleme bittiğinde uygulamayı hızlandırmak da istersen yapay zeka ile performans optimizasyonu yazısını oku.

Kendi deponda denemek için AgentVera’yı indir.