---
title: En İyi Kod Bazen Sildiğiniz Koddur
description: Yazdığımız her satırın yıllarca yaşamaya devam etmesi gerekmiyor. Özellikle yapay zeka destekli geliştirme araçları sayesinde, yalnızca bir problemi anlamak veya tek seferlik bir işi tamamlamak için küçük araçlar üretmek artık çok daha ucuz. Ben bu noktada kodu yalnızca ürünün bir parçası olarak değil, bazen geçici bir mühendislik aracı olarak da düşünmek gerektiğini düşünüyorum. Asıl mesele, hangi parçanın kalıcı olacağını ve hangisinin görevini tamamladıktan sonra silinmesi gerektiğini doğru ayırabilmek.
author: Burak Kaşıkcı
date: 2026-09-28
updated: 2026-09-27
tags:
  - ai
  - yazılım geliştirme
  - debugging
  - clean code
  - code review
  - teknik borç
  - "c#"
  - sql server
canonical: https://burakkasikci.com/blog/en-iyi-kod-bazen-sildiginiz-koddur
slug: en-iyi-kod-bazen-sildiginiz-koddur
---

# En İyi Kod Bazen Sildiğiniz Koddur

Uzun yıllardır yazılım geliştirirken kod kalitesinin önemini konuşuyoruz.
Okunabilir olsun, test edilebilir olsun, naming düzgün olsun, bir başkası altı ay sonra açtığında ne olduğunu anlayabilsin...
Bunlara itirazım yok. Ben de özellikle production'a girecek bir kodda mümkün olduğunca bu çizgiyi korumaya çalışıyorum.
Ama son dönemde, özellikle AI destekli geliştirme araçlarını daha fazla kullandıkça başka bir şeyi daha sık düşünmeye başladım:
**Yazdığım her şey gerçekten kalıcı olmak zorunda mı?**
Çünkü bazen kodun kendisi değil, bana verdiği cevap değerli oluyor.
Ve o cevabı aldıktan sonra geriye kalan yüzlerce satırın hiçbir anlamı kalmayabiliyor.
Böyle durumlarda en iyi kod, belki de gönül rahatlığıyla Shift+Delete yaptığınız kod oluyor.

## Her Kod Ürünün Bir Parçası Olmak Zorunda Değil

Yıllarca geliştirme yapınca insan ister istemez her şeyi düzenli hale getirme refleksi kazanıyor.
Bir servis yazdıysanız klasör yapısına otursun.
Bir yardımcı sınıf oluşturduysanız generic olsun.
Bir script yazdıysanız belki ileride lazım olur diye saklayın.
Hatta küçük bir Console uygulaması bile yazsanız bir noktada dependency injection eklerken bulabiliyorsunuz kendinizi.
Ben bunu birkaç kez yaptım.
Aslında tek seferlik kullanacağım küçücük bir araç için önce birkaç class açıp, sonra config yapısı ekleyip, ardından logging koyup işi büyüttüğüm oldu.
Bir noktada şunu fark ediyorsunuz:
Ben problemi çözmeye çalışıyordum, farkında olmadan yeni bir proje geliştirmeye başlamışım.
Halbuki bazı durumlarda ihtiyaç bundan çok daha basit.
Bir şeyi öğren.
Bir çıktıyı doğrula.
Problemi bul.
İşin bittiyse kodu sil.
Bu kadar.

## Kodun Değil, Sonucun Değerli Olduğu Durumlar

Diyelim ki production ortamında zaman zaman yaşanan bir performans problemi var.
Elinizde yüz binlerce log kaydı bulunuyor.
Normal şartlarda bu kayıtları SQL ile inceleyebilirsiniz. Birkaç query yazarsınız, belirli endpoint'leri gruplayıp süreleri karşılaştırırsınız.
Ama veri farklı dosyalara dağılmışsa işler biraz daha tatsız hale gelebiliyor.
Örneğin elinizde şöyle dosyalar olsun:

```
app-20260920.log
app-20260921.log
app-20260922.log
app-20260923.log
```

Her birinde yüz binlerce satır var.
Aradığınız şey ise oldukça basit:

* En yavaş endpoint'ler hangileri?
* Timeout hangi saatlerde artıyor?
* Aynı exception hangi servislerde tekrar ediyor?
* Problem belirli bir sunucuda mı yoğunlaşıyor?

Bunu elle yapmak istemezsiniz.
Bu noktada AI'ya küçük bir Python script'i veya C# Console uygulaması hazırlatmak gayet mantıklı.
Script dosyaları okur, regex ile gerekli alanları çıkarır, gruplayıp size bir çıktı verir.
Sonuç örneğin şöyle olabilir:

```
/api/payment   Avg: 1850 ms   Error: 142
/api/customer  Avg: 320 ms    Error: 12
/api/report    Avg: 4100 ms   Error: 87
```

Aradığınız cevap burada.
Belki problemin `/api/report` tarafında olduğunu gördünüz.
Sonra başka bir sorgu çalıştırdınız, DB tarafını kontrol ettiniz ve sorunun nedenini buldunuz.
Peki o küçük analiz uygulamasını ne yapacaksınız?
Büyük ihtimalle hiçbir şey.
Çünkü görevi tamamlandı.
Burada ortaya çıkan kod bir ürün değildi.
Bir çeşit büyüteçti.
İşiniz bittiğinde masada bırakmanız gerekmiyor.

## Disposable Code Aslında Yeni Bir Şey Değil

Bu yaklaşım genellikle **disposable code** veya **throwaway code** olarak adlandırılıyor.
Türkçede tam oturan bir karşılığı yok ama ben "kullan-at kod" veya "geçici kod" demeyi daha anlaşılır buluyorum.
Aslında fikir yeni de değil.
Özellikle veritabanı tarafında çalışan biriyseniz yıllardır bunu yapıyoruz.
Bir problem çıktığında şu tarz sorgular yazıyorsunuz:

```
SELECT
    Path,
    COUNT(*) AS RequestCount,
    AVG(DurationMs) AS AvgDuration,
    MAX(DurationMs) AS MaxDuration
FROM ApplicationLogs
WHERE LogDate >= DATEADD(HOUR, -2, GETDATE())
GROUP BY Path
ORDER BY MaxDuration DESC;
```

Sonra bir tane daha.

```
SELECT
    ServerIp,
    COUNT(*) AS ErrorCount
FROM ApplicationLogs
WHERE LogLevel = 'Error'
GROUP BY ServerIp
ORDER BY ErrorCount DESC;
```

Bunlar bazen o kadar spesifik oluyor ki bir daha çalıştırmanızın hiçbir anlamı olmuyor.
Benim günlük işlerde de sık yaptığım bir şey bu.
Bir datayı anlamak için query yazıyorum, sonucu kontrol ediyorum, başka bir yere geçiyorum. O sorguyu saklamak için ekstra çaba göstermiyorum.
Çünkü onun amacı gelecekte tekrar kullanılmak değil.
O anda doğru soruya cevap vermek.
Bence AI'nın değiştirdiği şey tam olarak burada başlıyor.

## AI, Yazmaya Değmeyecek Kodları Yazılabilir Hale Getirdi

Eskiden küçük bir analiz için bazen şu hesabı yapardım:

> Buna özel tool yazsam güzel olur ama uğraştığıma değmez.

Çünkü birkaç saatlik bir iş için yarım saat altyapı hazırlamak istemiyorsunuz.
Dosya okuyacaksınız.
Parse edeceksiniz.
Model oluşturacaksınız.
Output hazırlayacaksınız.
Sonra belki bir bug çıkacak.
Bütün bunlar sonunda yalnızca bir kere kullanacağınız bir şey için yapılacak.
Doğal olarak çoğu zaman vazgeçiyorsunuz.
AI coding araçları bu hesabı değiştirdi.
Bugün örneğin şöyle bir şey söyleyebiliyorsunuz:

> Bu klasördeki tüm JSON dosyalarını oku. `customerId` bazında grupla. Aynı müşteriye ait farklı response'ları karşılaştır. Farklı olan alanları CSV olarak çıkar.

Birkaç dakika sonra elinizde çalışan küçük bir araç olabiliyor.
Burada bence asıl devrim "kod daha hızlı yazılıyor" değil.
**Daha önce ekonomik olmayan küçük araçları üretmenin maliyeti düşüyor.**
Bu bana daha önemli geliyor.

## Her Şeyi Elle İncelemek Zorunda Değiliz

Geliştiricilikte zaman zaman garip bir alışkanlığımız oluyor.
Bir problemi çözmek için veri önümüzdeyse, saatlerce gözümüzle incelemeyi normal kabul ediyoruz.
Örneğin iki API response'u karşılaştırıyoruz.
Önümüzde yüzlerce JSON var.
Bir noktadan sonra ekranın karşısında şunları aramaya başlıyorsunuz:

```
{
  "status": "Active",
  "amount": 123.45,
  "currency": "TRY"
}
```

Yeni servis aynı sonucu üretiyor mu?
Bir yerde `null` yerine boş string mi dönmüş?
Decimal format değişmiş mi?
Bir property kaybolmuş mu?
On tane response'ta bunu yapmak kolay.
Bin tane response'ta değil.
Böyle bir durumda tek seferlik karşılaştırma aracı yazdırmak çok daha mantıklı.
Örneğin:

```
foreach (var testCase in testCases)
{
    var oldResponse = await oldClient.GetAsync(testCase);
    var newResponse = await newClient.GetAsync(testCase);

    if (!JsonNode.DeepEquals(oldResponse, newResponse))
    {
        Console.WriteLine($"Difference: {testCase.Id}");
    }
}
```

Bu kodun Clean Architecture'a uygun olmasına ihtiyacım yok.
MediatR kullanmasına da gerek yok.
Interface yazmam da gerekmiyor.
Bana farklılıkları doğru şekilde göstermesi yeterli.
Ama burada önemli bir çizgi var.
Bu araç yarın CI/CD pipeline içerisine girecekse, ekip düzenli olarak kullanacaksa veya regression test haline gelecekse artık disposable değildir.
O zaman baştan değerlendirmek gerekir.

## Production Code ile Investigation Code'u Ayırmak

Ben burada kodu yaşam süresine göre düşünmenin faydalı olduğunu düşünüyorum.
Mesela üç kategori üzerinden gidelim.

### Production Code

Bu kategori için konu net.
Authentication, ödeme sistemi, müşteri işlemleri, background worker, API endpoint'leri...
Bunlar yıllarca yaşayabilir.
Dolayısıyla:

* Test
* Logging
* Exception handling
* Security
* Performance
* Maintainability
* Observability

gibi konuların tamamı önemlidir.
AI yazmış veya insan yazmış fark etmez.
Repository'ye giriyorsa sorumluluk artık sizdedir.

### Internal Tooling

Bir de ekip içerisinde kullanılacak küçük yardımcı araçlar var.
Migration uygulamaları, import araçları, rapor üreticiler, test data generator'lar gibi.
Bunlarda production koduna göre biraz daha esnek olabilirsiniz ama sonuçta başkaları da kullanacaktır.
Bir süre sonra siz projeden ayrılsanız bile başka biri açacaktır.
Dolayısıyla belli bir düzen yine gerekir.

### Investigation Code

Benim bu yazıda asıl kastettiğim alan burası.
Tek bir soruya cevap vermek için yazılır.
Örneğin:

```
Bu CSV dosyasında duplicate kayıt var mı?

Bu iki API aynı sonucu mu üretiyor?

Son iki saatte hangi endpoint daha fazla timeout üretmiş?

Bu migration sonrası kaç kayıt değişmiş?

Eski sistem ile yeni sistem arasında fark var mı?
```

Cevabı aldığınızda kodun görevi tamamlanmış olur.
Bu kategoride reusable olmak çoğu zaman bir hedef değildir.

## Geçici Kodun En Büyük Riski: Geçici Kalmaması

Burada yıllardır gördüğüm klasik bir yazılım problemi var.
"Şimdilik böyle yapalım."
Bu cümle kadar çok teknik borç üretmiş başka bir cümle var mı bilmiyorum.
Geçici kodla ilgili problem de tam burada başlıyor.
Bir script yazıyorsunuz.
Birisi bunu kullanıyor.
Sonra başka biri "bunu her gece çalıştıralım" diyor.
Bir cron job ekleniyor.
Ardından bir dosyaya çıktı vermesi isteniyor.
Sonra mail atması gerekiyor.
Altı ay sonra bakıyorsunuz, tek seferlik yazdığınız script şirketin önemli operasyonlarından birini yürütüyor.
Akış aşağı yukarı şöyle oluyor:

```
Tek seferlik script
        ↓
İşe yaradı
        ↓
Birileri kullanmaya başladı
        ↓
Schedule edildi
        ↓
Production sürecine bağlandı
        ↓
Kimse dokunmaya cesaret edemiyor
```

İşte burada problem var.
Çünkü kod artık disposable değil ama hâlâ disposable code kalitesinde.
Bu yüzden bana göre geçici kod yazarken teknik kaliteden önce **niyeti netleştirmek** gerekiyor.
Bu şey yaşayacak mı?
Yoksa işi bitince gerçekten silinecek mi?

## AI'nın Gizli Tehlikesi: Kod Çok Kolay Çoğalıyor

AI ile geliştirme yaparken beni daha fazla düşündüren konu aslında üretilen kodun kalitesinden ziyade miktarı.
Eskiden birkaç yüz satırlık bir geliştirme yaparken o kodun nasıl büyüdüğünü adım adım görüyordunuz.
Bir class açıyordunuz.
Sonra başka bir service ekliyordunuz.
Bir method değişiyordu.
Test yazıyordunuz.
Kod yavaş yavaş şekilleniyordu.
Şimdi ise süreç bazen şöyle:
Bir prompt.
600 satır değişiklik.
Bir prompt daha.
350 satır.
"Şunu da düzelt."
Beş dosya daha değişti.
Sonra agent başka bir refactor yaptı.
Bir süre sonra Git diff ekranında binlerce satır var.
İşte burada ben şu soruyu çok önemli buluyorum:
**Bu kodun tamamının neden orada olduğunu gerçekten biliyor muyum?**
Production tarafında bunun cevabı "evet" olmalı.
"AI yazdı, çalışıyor" benim için yeterli değil.
Çünkü üç ay sonra production incident olduğunda prompt geçmişi sistemi düzeltmeyecek.
Koda bakacak olan yine biziz.

## Code Review'da Yeni Bir Soru

Code review yaparken genelde benzer şeylere bakıyoruz.
Naming doğru mu?
Null kontrolü var mı?
Hata yönetimi nasıl?
Query performansı iyi mi?
Test kapsamı yeterli mi?
Security açısından sorun var mı?
Bence AI ile birlikte bunların yanına yeni bir soru eklemek gerekiyor:
**Bu kod gerçekten repository'de olmak zorunda mı?**
Bazen farkında olmadan problemin çözümünü değil, çözüm sırasında kullandığımız araçları da ürüne dahil ediyoruz.
Halbuki bazı şeyler scaffolding gibidir.
Binayı yaparken kullanırsınız.
Bina tamamlandığında sökersiniz.
Kimse iskeleyi binanın kalıcı mimarisinin bir parçası olarak bırakmaz.
Kod tarafında da benzer düşünmek mümkün.

## Kod Yazmak Ucuzladı, Bakım Yapmak Ucuzlamadı

Bence AI destekli geliştirmede gözden kaçırılan en önemli noktalardan biri bu.
Kod üretme maliyeti ciddi şekilde düştü.
Ama code ownership maliyeti aynı hızda düşmedi.
Bir dosyayı repository'ye eklediğinizde ileride birileri onu:

* okuyacak,
* değiştirecek,
* test edecek,
* debug edecek,
* framework güncellemesinde düzeltecek,
* security issue çıktığında inceleyecek,
* dependency değişiminde adapte edecek.

Yani bugün beş dakikada yazdırdığınız 1.000 satır kod, önümüzdeki beş yıl boyunca size maliyet çıkarabilir.
Bunun için benim artık kendime sormaya çalıştığım soru şu:

> Bu kodu üretmek kolay olabilir ama gerçekten sahip olmak istiyor muyum?

İkisi aynı şey değil.

## Clean Code Her Yerde Aynı Anlama Gelmiyor

Disposable code konuşurken yanlış anlaşılmasını istemediğim bir konu var.
"Nasıl olsa sileceğim" diyerek kontrolsüz bir şey çalıştırmak doğru değil.
Özellikle production verisine dokunan bir script için bu oldukça tehlikeli olabilir.
Örneğin veri temizlemek için AI'ya bir SQL script yazdırdınız.

```
DELETE FROM Orders
WHERE Status = 'Cancelled';
```

Bu kod geçici olabilir ama yanlış çalışırsa sonuç geçici olmayacaktır.
Dolayısıyla disposable code için de bazı kurallar geçerli.
Ben önceliği kabaca şöyle koyarım:

1. Doğru sonuç üretmeli.
2. Sisteme zarar vermemeli.
3. Güvenli olmalı.
4. Ne yaptığını anlayabilmeliyim.
5. Problemi hızlı çözmeli.
6. Uzun vadeli bakım kalitesi en son gelir.

Yani mimariyi basitleştirebilirim.
Ama doğruluktan taviz veremem.

## Bazı Kodlar Tornavida Gibidir

Ben bu yaklaşımı en çok buna benzetiyorum.
Evde bir dolap kapağını sıkmak için tornavida kullanırsınız.
İş bittikten sonra tornavidayı dolabın üzerine yapıştırmazsınız.
Araç görevini tamamlar ve kenara gider.
Investigation sırasında yazdığımız bazı scriptler de tam olarak böyle.
Kod ürünün kendisi değil.
Ürünü anlamak için kullandığımız araç.
Bu ayrımı yaptığınız anda gereksiz abstraction'lardan kurtulmak da kolaylaşıyor.
Çünkü artık her şeyi geleceğe hazırlamak zorunda hissetmiyorsunuz.

## AI'yı Sadece Kod Üreten Bir Şey Olarak Görmemek

AI coding konusunda çok sık şu açıdan konuşuyoruz:
"Bu işi kaç dakika hızlandırdı?"
Bence daha ilginç soru şu:
**Daha önce hiç yapmayacağım hangi şeyi artık yapabiliyorum?**
Örneğin normalde yazmayacağınız küçük araçlar:

```
500 MB log dosyasını analiz et.

İki veritabanındaki kayıtları karşılaştır.

50 farklı JSON çıktısındaki schema farklarını bul.

Eski API ile yeni API'nin response'larını kıyasla.

Migration öncesi ve sonrası veri farklarını raporla.

Bir klasördeki SQL dosyalarında hangi tabloların kullanıldığını çıkar.
```

Bunların her biri küçük işler.
Ama gerçek hayatta geliştirici zamanının önemli bölümü tam olarak böyle işlerde gidiyor.
AI burada size yeni bir ürün yazmaktan çok daha fazla değer sağlayabilir.
Bazen yalnızca yarım saatlik bir problemin on dakikaya düşmesini sağlar.
Ve o işi yapan kodu bir daha hiç görmezsiniz.
Bence bunda kötü bir şey yok.

## Silmek de Geliştirmenin Bir Parçası

Yazılım geliştirirken üretmek insana daha somut geliyor.
Yeni endpoint.
Yeni feature.
Yeni servis.
Yeni repository.
Ama yıllar geçtikçe benim daha fazla değer verdiğim şeylerden biri kod silebilmek oldu.
Çünkü repository'deki her satır aslında gelecekte ödenecek küçük bir bakım faturası.
Bir satır tek başına önemsiz.
Ama yüz binlerce satıra ulaştığında sistemin karmaşıklığını belirliyor.
Bu nedenle bazen iyi mühendislik daha fazla kod yazmak değil, mevcut kapsamı küçültmek oluyor.
AI ile kod üretmenin bu kadar kolaylaştığı bir dönemde bunun daha da önemli hale geldiğini düşünüyorum.
Artık en kıt kaynak kod yazma kapasitesi değil.
Dikkat.
Anlama.
Bakım.
Ve teknik sorumluluk.

## Sonuç

Yapay zeka yazılım geliştirme biçimimizi sadece daha hızlı kod üretmemizi sağlayarak değiştirmiyor.
Bence daha önemli değişim, daha önce uğraşmaya değmeyecek kadar küçük gördüğümüz araçları birkaç dakikada oluşturabilmemiz.
Bir log parser.
Bir JSON comparer.
Bir migration validator.
Bir veri analiz script'i.
Bunların hiçbiri kalıcı olmak zorunda değil.
Görevini tamamlar, size ihtiyacınız olan cevabı verir ve ortadan kalkar.
Burada asıl dikkat edilmesi gereken nokta geçici kod ile production kodunu birbirine karıştırmamak.
Production'a giren her satır uzun vadeli bir sorumluluk.
Ama yalnızca bugünkü problemi çözmek için yazılmış bir araç aynı yükü taşımak zorunda değil.
Ben artık yeni bir kod parçasına bakarken sadece "Bu düzgün yazılmış mı?" diye düşünmenin yeterli olmadığını düşünüyorum.
Bir soru daha var:
**Bu kod gerçekten yaşamaya devam etmeli mi?**
Cevap hayırsa, bazen yapılabilecek en temiz refactoring gerçekten Shift+Delete'tir.