Değişikliği fark olarak göster

Kullanıcı asistana dört sayfalık bir teklif metni veriyor ve tek bir şey istiyor: biraz kısalt. Asistan metni baştan yazıp geri veriyor. Yeni metin daha kısa, daha akıcı. Kısaltma dışında başka neyin değiştiğini ise söylemiyor. Kullanıcının önünde iki yol kalıyor. Ya iki sürümü yan yana koyup satır satır okuyacak ya da yeni metne güvenip gönderecek.

İlk yol işin kendisinden uzun sürüyor. Dört sayfayı kısaltmak için asistana gidilmişti, şimdi aynı dört sayfa iki kez okunuyor. İkinci yol riskli. Model metni yeniden yazarken yalnız istenen yere dokunmaz. Bir koşulu düşürür, bir süreyi yuvarlar, bir adı “düzeltir”. Bunların hepsi akıcı cümlelerin içinde durduğu için göze batmaz. Teklifteki teslim süresi kısalır ve kimse fark etmez, ta ki müşteri o tarihi hatırlatana kadar.

Kodda aynı şey daha sessiz yaşanır. Ajan bir fonksiyonu onarırken komşu fonksiyondaki bir koşulu da toparlar. Testler o koşulu kapsamıyorsa değişiklik canlıya kadar gider.

Değişikliği bulmak kullanıcının işi olduğu sürece kullanıcı ya zaman kaybeder ya da kontrolü bırakır.

Sohbet arayüzü cevabı yeni bir mesaj olarak verir ve onu eski metne bağlamaz. Model de yeniden yazmayı tek parça üretir. İkisi birleşince farkı hesaplamak kimsenin işi olmaz, o iş kullanıcıya kalır.

Laban ve arkadaşları bu boşluğu adıyla tarif ediyor. Sohbet arayüzünde model yeniden yazma isteğine baştan sona yenilenmiş bir taslakla¹ cevap veriyor ve iki taslağı zihinde karşılaştırma yükü yazara kalıyor.

İkinci neden ürün baskısı. Tek bir “Uygula” düğmesi demoda hızlı görünür. Değişiklikleri tek tek gösteren bir ekran ise tıklama ekler, parçalara bölme kodu ister ve büyük değişikliklerde dağınık görünür. Ekip ilk sürümde yeni metni bir kutuda gösterip geçer. Kabul oranını ölçen bir panoda da tek düğme her zaman daha iyi bir sayı verir.

Üçüncü neden modelin kendi özeti. Asistan cevabın sonuna “dili resmîleştirdim, tekrarları çıkardım” yazar ve bu bir fark listesi gibi okunur. Oysa o cümle de bir üretim. Model neyi değiştirdiğini sayarken de unutabilir ve en çok, isteğin dışında kalan değişikliği unutur. Kullanıcı özeti okuyup farkı gördüğünü sanır.

AI var olan bir içeriği değiştirdiğinde kullanıcının önüne önce aradaki farkı koy. Yeni metin, kabul edilen farkların toplamı olarak sonra gelir.

1. Farkı kod hesaplasın. Model yeni içeriği üretir, eski ile yeni arasındaki farkı bir diff algoritması çıkarır: metinde kelime ya da cümle düzeyinde, kodda satır düzeyinde. Modelin değişiklik özeti bu hesabın yerine geçmez.
2. Değişikliği parçala ve yerini söyle. Her parça eski hâlini, yeni hâlini ve yerini taşır: bölüm, paragraf, dosya, satır. Üstte kaç değişiklik olduğu yazar.
3. Her parçayı ayrı kabul ettir. Kabul ve ret parça başına çalışır. Bir parçayı geri almak ötekileri bozmaz. “Hepsini uygula” bir kolaylık olarak kalır, tek yol olmaz.
4. Anlamı değiştireni öne al. Sayı, tarih, tutar, ad, olumsuzluk ve koşul değişiklikleri ayrıca işaretlenir ve listenin başına çıkar. Kullanıcının isteği dışında kalan her değişiklik de öyle.
5. Biçimi anlamdan ayır. Boşluk, noktalama ve sıra değişiklikleri ayrı bir grupta durur. Yüz biçim düzeltmesinin arasında tek bir anlam değişikliği kaybolmaz.
6. Kabulden sonra da izi tut. Kabul edilen parça ne zaman kabul edildiğini taşır ve sonradan tek başına geri alınabilir.

Bu kuralların ortak işi okuma yükünü değişikliğin boyuna indirmek. Kullanıcı yalnız değişen yerleri okur ve okuma süresi değişikliğin boyuyla büyür.

Aynı kısaltma isteği, iki ayrı cevapla. Soldaki asistan yeni metni tek blok olarak veriyor ve tek düğmeyle uyguluyor. Sağdaki her değişikliği yeriyle, eski ve yeni hâliyle listeliyor, teslim süresini değiştiren parçayı en üste alıp ayrıca işaretliyor.

Visual Studio Code'da yerel ajan oturumları dosyaya yazılan düzenlemeleri bekleyen değişiklik olarak işaretliyor. Kullanıcı editördeki oklarla düzenlemeler arasında geziyor, her birini Keep ya da Undo ile kapatıyor. Satır içindeki tek bir değişikliğin üstüne gelip onu dosyadaki öteki düzenlemelere dokunmadan² tutabiliyor ya da geri alabiliyor. Aynı belge, bekleyen düzenlemeleri bir süre sonra kendiliğinden kabul eden bir ayar da tanımlıyor ve bu ayar açıksa değişiklikleri commit'ten önce gözden geçirmeyi öneriyor.

Claude Code'un VS Code eklentisi elle onay modunda bir dosyayı değiştirmeden önce özgün ve önerilen hâli yan yana gösteriyor. Kullanıcı farkın içindeki her değişikliğin altındaki kabul ve ret düğmeleriyle³ tek tek karar veriyor. Reddedilen değişiklik önerilen içerikten geri alınıyor. Belgedeki bir ayrıntı desenin sınırını da gösteriyor. Yüzden fazla değişiklik içeren bir fark parça başına düğmeler olmadan açılıyor ve dosya bütün olarak inceleniyor.

Microsoft Nisan 2026'da Word'deki Copilot için izlenen değişiklikleri duyurdu. Duyuruya göre Copilot'un düzenlemeleri kelime düzeyinde ve varsayılan olarak görünür⁴ geliyor, kullanıcı izlemeyi Copilot'un içinden açabiliyor. Bu yaklaşım yeni bir arayüz icat etmiyor, Word'ün kendi izlenen değişiklikler görünümünü AI'ın düzenlemelerine de uyguluyor. Duyuru gününde özellik yalnız Windows masaüstünde, Frontier programı üzerinden açıktı.

Laban ve arkadaşlarının bilgi çalışanlarıyla yaptığı 64 kişilik ankette katılımcıların %80'i belge düzenlerken sohbet tabanlı bir LLM kullanıyordu, %86'sı önerileri belgelerine elle taşıyordu, %17'si ise yeni sürümü olduğu gibi kopyalıyordu¹. Yazarlar elle taşımanın bedelini de yazıyor: yazar ilk taslağı modelin önerisiyle zihninde hizalıyor, farkları kendisi buluyor ve istediklerini taslağa geri işliyor. Kopyalayanlar bu yükü atlıyor ama farkı hiç görmeden kabul ediyor.

Aynı çalışmanın kullanılabilirlik deneyinde öneriyi doğrudan belgenin içinde, tek tıkla kabul ya da ret edilebilen düzenleme olarak veren bütün arayüzler elle düzenlemeden daha hızlı ilerledi¹. En yavaş koşul, önerilerin bir sohbet bölmesinde gelip belgeye elle taşındığı koşuldu.

Farkı göstermek de tek başına yetmiyor, farkın nasıl okunduğu da önemli. Ekran okuyucuyla kod yazan programcılarla yapılan bir çalışmada bir katılımcı, fark görünümünde değişmeyen, silinen ve eklenen kodun iç içe geçmesinin değişiklikleri izlemeyi zorlaştırdığını⁵ söyledi. Göz gezdiremediği için duyduğunu aklında tutmak zorundaydı.

Bu ölçümler kısa e-posta düzenleme görevlerinde ve küçük örneklemlerle yapıldı, senin ürünündeki süreyi söylemez. Yön yine de açık: farkı kullanıcı aradığında iş uzuyor, aramadığında fark kontrolsüz geçiyor.

• Kabulden sonra geri alma. Kabul edilen değişikliklerin ne kadarı sonradan elle geri alınıyor ya da düzeltiliyor? Farkı göremeyen kullanıcı hatayı kabulden sonra bulur. Desen yerindeyse bu pay düşer, ret anına taşınır.
• Parça başına karar. Kullanıcıların ne kadarı bir parçayı reddedip ötekileri kabul ediyor? Sıfıra yakınsa ya parça başına ret zor ya da kullanıcı farka bakmıyor.
• İnceleme süresi neyle büyüyor. Gözden geçirme süresini değişen sözcük ya da satır sayısıyla karşılaştır. Süre belgenin boyuyla büyüyorsa kullanıcı hâlâ bütün metni okuyor.
• İşaretli parçanın kaderi. Anlamı değiştiriyor diye işaretlenen parçaların ne kadarı reddediliyor? Hiçbiri reddedilmiyorsa işaret ya fazla sık çıkıyor ya da görünmüyor.
• İşaretlenmeyen istenmeyen değişiklik. Örneklenen düzenlemelerde isteğin dışında kalan değişiklikleri elle say ve kaçının işaretlendiğine bak. Hedef hepsinin işaretlenmesi.

Üç metin var. Denetim promptu ürününde AI'ın var olan içeriği değiştirdiği yerleri bulur, değişikliğin fark olarak gösterilip gösterilmediğini ve parça başına kabul ile ret olup olmadığını tarar, yalnız rapor yazar. Uygulama promptu farkı kodla hesaplatır, parça başına kararı ve anlam değiştiren parçaların işaretlenmesini ekler. Önce planı gösterir, onayınla uygular ve modelin istenmeden bir tarihi değiştirdiği bir test yazar. Kural kodlama ajanının kendi çalışması için. Senin dosyalarını değiştirdiğinde o da değişikliği yeriyle, fark olarak göstersin.

Bu depoda AI'ın var olan bir içeriği değiştirdiği bir özellik var: metni yeniden yazma, kısaltma, düzeltme, kod düzenleme ya da kullanıcı adına dosya değiştiren bir ajan. Görevin, AI'ın yaptığı değişikliklerin kullanıcıya fark olarak gösterilip gösterilmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. AI çıktısının var olan içeriğin yerine geçtiği her yeri bul: "uygula", "değiştir", "replace", "apply", "accept" düğmeleri, editöre yazan fonksiyonlar, dosya yazan araç çağrıları.
2. Her biri için bak: kullanıcı değişikliği uygulamadan önce eski ve yeni hâli birlikte görüyor mu? Kodda bir fark hesabı var mı (diff kütüphanesi, kelime ya da satır düzeyinde karşılaştırma), yoksa yeni metin tek blok olarak mı gösteriliyor?
3. Fark gösteriliyorsa ayrıntısına bak: değişiklik parçalara (hunk) bölünüyor mu, her parçanın yeri (bölüm, paragraf, dosya, satır) yazıyor mu, toplam değişiklik sayısı görünüyor mu?
4. Kullanıcı tek bir parçayı kabul edip ötekini reddedebiliyor mu? Yoksa tek seçenek "hepsini uygula" ya da "hepsini reddet" mi?
5. Anlamı değiştiren değişiklikler (sayı, tarih, tutar, ad, olumsuzluk, koşul, kodda davranış) ve kullanıcının isteği dışında kalan değişiklikler ayrıca işaretleniyor mu? Biçim değişiklikleri anlam değişikliklerinden ayrılıyor mu?
6. Değişiklik kendiliğinden kabul ediliyor mu (zamanlayıcı, varsayılan "uygula", sessiz kaydetme)? Kabul edilmiş bir değişiklik sonradan nerede görülüyor ve tek başına geri alınabiliyor mu?
7. Fark görünümü klavyeyle parça parça gezilebiliyor mu, ekran okuyucunun okuyabileceği bir metin hâli var mı?
8. Kullanıcıya gösterilen "şunları değiştirdim" özeti kodun hesapladığı farktan mı geliyor, yoksa modelin kendi beyanı mı?

Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, kullanıcıya etkisi (örnek: asistan teklifi kısaltırken teslim süresini de değiştiriyor, kullanıcı fark etmeden belgeyi gönderiyor) ve önerdiğin düzeltme. Önce farkı hiç göstermeden içeriği değiştiren yerleri yaz.

Bu depodaki AI düzenleme özelliğine "değişikliği fark olarak göster" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. AI var olan bir içeriği değiştirdiğinde yeni metni tek blok olarak gösterme. Eski hâlle karşılaştırılmış farkı göster: metinde kelime ya da cümle düzeyinde, kodda satır düzeyinde.
2. Farkı değişiklik parçalarına böl. Her parça yerini (bölüm, paragraf, dosya, satır), eski hâlini ve yeni hâlini taşısın. Üstte toplam değişiklik sayısı yazsın.
3. Her parça ayrı ayrı kabul ve reddedilebilsin. Reddedilen parça eski hâline döner, ötekiler etkilenmez. "Hepsini uygula" ikincil bir kolaylık olarak kalsın.
4. Anlamı değiştiren parçaları (sayı, tarih, tutar, ad, olumsuzluk, koşul, kodda davranış) ve kullanıcının isteği dışında kalan parçaları ayrıca işaretle, listenin başına koy. Boşluk ve noktalama gibi biçim değişikliklerini ayrı bir grupta topla.
5. Kabul edilen parçaların izini sakla: hangi parça, ne zaman, kim tarafından kabul edildi. Kabulden sonra da tek bir parça geri alınabilsin.
6. Fark görünümü klavyeyle parça parça gezilebilsin. Her parçanın "yer, eski, yeni" sırasıyla okunan bir metin hâli olsun.

Uygularken:
- Fark hesabını modele bırakma. Model yalnız yeni içeriği üretsin, farkı bir diff kütüphanesi hesaplasın. Modelin "şunları değiştirdim" özeti farkın yerine geçmesin.
- İçeriğin büyük kısmı değiştiyse parça listesi okunmaz hâle gelir. Bir eşik belirle, eşiğin üstünde bunu kullanıcıya söyle ve iki sürümü yan yana göster.
- Bir test ekle: içinde bir tarih ve bir tutar olan metni "kısalt" isteğiyle değiştir, modelin tarihi de değiştirdiği bir cevabı taklit et. Arayüzün o parçayı ayrı ve işaretli gösterdiğini, yalnız o parçanın reddedilebildiğini ve reddin öteki parçaları bozmadığını doğrula.

## Değişikliği fark olarak göster
- Var olan bir dosyayı ya da metni değiştirdiğinde dosyanın tamamını yeniden basma. Değişikliği fark olarak göster: yer, eski hâl, yeni hâl.
- İstenenin dışında bir şeyi değiştirdiysen (sayı, tarih, ad, davranış, biçim) bunu ayrıca ve en başta söyle.
- Büyük bir değişikliği küçük ve gözden geçirilebilir parçalara böl. Biçim değişikliklerini anlam değişikliklerinden ayrı tut.
- "Birkaç küçük düzeltme yaptım" diye geçme. Her değişikliği yeriyle say.
- Kullanıcı bir parçayı reddederse yalnız o parçayı geri al, ötekilere dokunma.

Yeni bir şey üretildiğinde fark yoktur. Boş sayfaya yazılan ilk taslak, sıfırdan bir görsel ya da yeni bir dosya için bu desen gerekmez. Desen, var olan bir içeriğin değiştiği her yerde gerekir.

Değişiklik metnin çoğunu kapsıyorsa parça listesi okunmaz hâle gelir. Claude Code'un yüz değişiklik eşiği bunun bir örneği. Böyle bir durumda iki sürümü yan yana göster ve metnin büyük kısmının değiştiğini açıkça söyle.

Silinen ve eklenen satırları renkle ayıran bir fark görünümü, ekran okuyucu kullanıcısına iç içe geçmiş bir döküm olarak ulaşabilir. Farkın bir de metin hâli olmalı: yer, eski, yeni. Bunun ayrıntısı “Öneriyi ve değişikliği ekran okuyucuya duyur” deseninde.

Fark kararı kullanıcıya bırakır ama kararın dikkatle verildiğini garanti etmez. Yüz parçayı tek tek onaylatan bir ekran okunmadan geçilen bir tıklama dizisine dönebilir. Biçim değişikliklerini topla, anlam değişikliklerini öne al ve kullanıcının dikkatini sayısı az olan yere harcat.