Bir proje geliştirirken GitHub’da 56.000 yıldızlı bir kütüphane buluyorsunuz. Tam ihtiyacınız olan mimariyi çözmüş. Ama Python’da yazılmış, siz Java kullanıyorsunuz. Lisansı AGPL, projeniz ticari. Dependency olarak ekleyemezsiniz. Kodu olduğu gibi kopyalayamazsınız.
Ne yaparsınız?
Cevap: Semantic Copy-Paste.
Yazılım geliştirmede üç temel yeniden kullanım stratejisi var.
Birincisi literal copy-paste. Kodu olduğu gibi kopyalayıp yapıştırmak. Hızlı çözüm gibi görünür ama teknik borç üretir, bakım kabusu yaratır, lisans ihlali riski taşır.
İkincisi dependency olarak eklemek. Kütüphaneyi npm veya maven ile projeye dahil etmek. Standart yol budur ve çoğu durumda doğru tercihtir. Ama beraberinde versiyon uyumsuzluğu, aşırı bağımlılık ve dependency hell riski getirir.
Üçüncüsü ise semantic copy-paste. Kaynak koddaki pattern’i, mimari kararı, çözüm stratejisini anlayıp kendi bağlamına, kendi diline, kendi ihtiyaçlarına göre yeniden yazmak.
Shadcn/ui bu yaklaşımı popülerleştirdi: “Beni dependency olarak ekleme, kodumu kopyala ve sahiplen.” Semantic copy-paste bunun bir adım ötesi. Kodu bile kopyalamıyorsunuz, arkasındaki fikri alıp kendi ortamınıza taşıyorsunuz.
Neden Gerekli?
Semantic copy-paste’in vazgeçilmez olduğu dört durum var.
Birincisi dil uyumsuzluğu. Kaynak proje Python’da, sizin projeniz Java’da. Kodu kopyalayamazsınız ama pattern’i taşıyabilirsiniz.
İkincisi aşırı bağımlılık riski. Binlerce yıldızlı bir projeyi dependency olarak eklemek, onun tüm alt bağımlılıklarını ve lisansını da projenize çekmek demektir. Bazen bu kabul edilemez.
Üçüncüsü özelleştirme ihtiyacı. Kaynak proje farklı bir domain için tasarlanmış. Aynı pattern, sizin domain’inizde tamamen farklı kavramlarla çalışacak.
Dördüncüsü genişletme özgürlüğü. Dependency aldığınızda kütüphanenin API sınırlarına mahkumsunuz. Semantic copy-paste yaptığınızda pattern’in üzerine istediğiniz özelliği ekleyebilirsiniz.
Beşincisi ve belki de en kritik olanı: legacy migrasyon. Bu konuyu ayrı bir bölümde derinlemesine ele alacağım çünkü finans sektöründe çalışan herkes bu gerçeklikle yüzleşiyor.
Gerçek Örnek: MiroFish → FINGATEWAY
Bu yaklaşımı somutlaştırmak için gerçek bir vaka üzerinden gidelim.
MiroFish, multi-agent teknolojisiyle çalışan bir yapay zeka tahmin motoru. Python ve Vue.js ile yazılmış. Haber, rapor veya politika dökümanlarından entity çıkarıp, knowledge graph oluşturup, binlerce AI agent’ı bu graph üzerinde simüle ediyor. Sonuçta bir tahmin raporu üretiyor.
FINGATEWAY ise benim üzerinde çalıştığım finansal mesaj akış yönetim platformu. Java ve React ile geliştiriliyor. Farklı bankalar, ödeme sistemleri ve finansal kuruluşlar arasındaki mesaj trafiğini tek bir merkezden yönetiyor. SWIFT MT, ISO 20022, EFT gibi birbirinden farklı formatlardaki mesajları alıyor, dönüştürüyor, yönlendiriyor ve izliyor. Amacı, her entegrasyon kanalı için ayrı ayrı yazılan bağlantı kodlarını ortadan kaldırıp, mesaj akışını standart bir pipeline üzerinden geçirmek. Şu an üzerine eklemeyi planladığım özellik, bu mesaj akışlarının veri modelini görsel olarak tanımlayıp yönetebileceğimiz bir modelleme katmanı.
İki proje tamamen farklı domainlerde. Ama MiroFish’in mimarisinde FINGATEWAY’e taşınabilecek beş somut pattern tespit ettim.
Pattern 1: Seed → Ontology Pipeline
MiroFish’te ham metin (haber, rapor) graph_builder.py üzerinden işleniyor. Metin önce entity extraction’a giriyor, sonra entity’ler arası ilişkiler çıkarılıyor, ardından bir ontoloji oluşturuluyor ve graph store’a yazılıyor.
FINGATEWAY’e taşınan hali: MessageSchemaExtractor sınıfı. Ham finansal mesajı (SWIFT MT103, ISO 20022 pacs.008) alıyor, finansal entity’leri (banka, hesap, tutar, döviz, tarih) çıkarıyor, ilişkileri belirliyor (gönderen→alıcı, hesap→banka) ve bir FinancialOntology oluşturup schema registry’ye kaydediyor.
Aynı akış, tamamen farklı domain kavramlarıyla. MiroFish’te “kişi, kurum, olay” olan entity’ler, FINGATEWAY’de “banka, hesap, işlem” oluyor. Ama pipeline’ın yapısı aynı: ham girdi → entity çıkarma → ilişki belirleme → ontoloji → persist.
Pattern 2: Agent Persona → Channel Profile
MiroFish’te her simülasyon agent’ına bağımsız bir persona veriliyor. Kişilik özellikleri, hafıza, tepki hızı, etki seviyesi, görüş eğilimi ve davranış kuralları. Her agent bu profille karar veriyor.
FINGATEWAY’e taşınan hali: ChannelProfileGenerator. Her entegrasyon kanalını (SWIFT, EFT, FAST, API) bir “profil” olarak modelliyor. Kanalın “kişiliği” işlem karakteristikleri (max TPS, ortalama gecikme, retry stratejisi). Kanalın “hafızası” son 1000 işlemin sliding window kaydı. Kanalın “tepki hızı” SLA parametreleri. Kanalın “davranış kuralları” routing engine kuralları.
MiroFish’te “empatik vatandaş” veya “rasyonel analist” olan persona tipleri, FINGATEWAY’de “yüksek hacimli düşük gecikmeli SWIFT kanalı” veya “SLA kritik EFT kanalı” oluyor. Kavramsal dönüşüm var ama mimari yapı korunuyor.
Pattern 3: GraphRAG Hybrid Search → Message Flow Graph
MiroFish knowledge graph üzerinde hibrit arama yapıyor. Yüzde 70 ağırlıkla vektör benzerliği, yüzde 30 ağırlıkla BM25 keyword search kullanıp Reciprocal Rank Fusion ile birleştiriyor.
FINGATEWAY’e taşınan hali: MessageFlowGraph. Mesaj akış grafiği üzerinde aynı hibrit aramayı kullanarak benzer pattern’leri buluyor. Üzerine eklenen özellik: anomali tespiti. Eğer bir mesaj akışının hibrit arama skoru belirli bir eşiğin altına düşüyorsa, bu akış bilinen pattern’lerden sapıyor demektir. Bilinmeyen pattern olarak işaretleniyor.
Bu, semantic copy-paste’in genişletme gücünü gösteren bir örnek. MiroFish’te olmayan anomali tespiti, aynı arama altyapısı üzerine doğal bir eklenti olarak geldi.
Pattern 4: Vue Wizard → React Data Modeler
MiroFish’in Vue frontend’i adım adım bir wizard kullanıyor. Upload → Graph Build → Simulation Config → Report View. Her adımda farklı bir bileşen render ediliyor, ileri-geri navigasyon var, adım göstergesi var.
FINGATEWAY’e taşınan hali: React ile yazılmış Data Modeler Wizard. Schema Import → Entity Map → Flow Design → Validate → Deploy. Beş adımlı, aynı wizard pattern’i.
Vue’dan React’e geçiş sadece sözdizimi değişikliği. v-if yerine conditional rendering, @event yerine onClick handler, reactive state yerine useState. Pattern aynı, framework farklı.
Pattern 5: Simulation Timeline → Message Flow Timeline
MiroFish simülasyon sonuçlarını D3.js ile timeline olarak görselleştiriyor. Her simülasyon round’u bir node, node boyutu aktivite yoğunluğuna, rengi sentiment’e göre değişiyor.
FINGATEWAY’e taşınan hali: Mesaj akışı timeline’ı. Her node bir finansal mesaj, boyut işlem tutarına, renk işlem durumuna (başarılı, beklemede, hatalı) göre değişiyor. Tıklanınca detay açılıyor.
Aynı görselleştirme pattern’i, farklı veri kaynağı.
En Zor Vaka: Mainframe’den Semantic Copy-Paste
Şimdiye kadar açık kaynak bir projeden pattern taşımaktan bahsettim. Ama bir de bunun çok daha zorlu bir versiyonu var. Düşünün ki elinizde GitHub repository’si yok, README yok, test suite yok. Elinizde olan şey: 30 yıldır bir mainframe üzerinde COBOL veya PL/1 ile çalışan bir core banking sistemi. Ve bu sistemi yeni bir platforma taşımanız gerekiyor.
Bu, semantic copy-paste’in en saf ve en zorunlu hali.
Bir bankanın EFT ödeme işleme modülünü düşünün. COBOL’da yazılmış. Onlarca yıldır kesintisiz çalışıyor. İçinde gömülü olan iş mantığı hiçbir yerde dokümante edilmemiş. Kurallar kodun kendisinde yaşıyor: hangi durumda işlem reddedilir, komisyon nasıl hesaplanır, hangi sırayla hangi kontroller yapılır, gün sonu mutabakatı nasıl çalışır.
Bu kodun literal copy-paste ile taşınması imkansız. COBOL’un PERFORM THRU paragrafları, WORKING-STORAGE değişkenleri, REDEFINES yapıları Java’ya birebir çevrilemez. PL/1’in ON şartları, BASED değişkenleri, AREA kavramı modern dillerde doğrudan karşılığı olmayan yapılar.
Dependency olarak eklemek zaten söz konusu değil çünkü ortada bir kütüphane yok. Olan şey, mainframe üzerinde çalışan bir monolitik program.
Geriye kalan tek yol: kodun içindeki iş mantığını anlamak, o mantığı soyutlamak ve yeni sistemde kendi dilinizle, kendi mimarinizle yeniden ifade etmek. Yani semantic copy-paste.
Somut bir örnek vereyim. Bir COBOL programında EFT komisyon hesaplama mantığı şöyle gömülü olabilir: işlem tutarı belirli bir eşiğin altındaysa sabit komisyon uygula, üstündeyse oransal komisyon uygula, ama müşteri segmenti kurumsal ise farklı oran kullan, yurt dışı işlemse ek masraf ekle, gün sonu işlemlerinde farklı kur uygula. Bu kurallar COBOL’da iç içe geçmiş IF bloklarında, EVALUATE yapılarında, bazen de farklı paragraflar arasında dağılmış durumda.
Semantic copy-paste ile bu mantığı taşırken yapmanız gereken: önce tüm iş kurallarını koddan çıkarmak, sonra bu kuralları domain kavramlarıyla ifade etmek (CommissionRule, CustomerSegment, TransactionType), ardından yeni sistemde bir rule engine yapısıyla modellemek. COBOL’daki spaghetti IF blokları, Java’da bir Strategy Pattern’e veya bir Rule Engine’e dönüşür. Mantık aynı, yapı tamamen farklı ve daha iyi.
PL/1 tarafında durum daha da ilginç. PL/1’in pointer aritmetiği ve BASED değişkenleri, düşük seviyeli bellek yönetimiyle iç içe geçmiş iş mantığı barındırır. Bir PL/1 programında mesaj parsing işlemi, pointer ile byte byte ilerleyerek belirli pozisyonlardan alan okuma şeklinde yapılıyor olabilir. Semantic copy-paste ile bunu taşırken, düşük seviyeli bellek işlemlerini değil, arkasındaki “sabit formatlı mesajdan alan çıkarma” pattern’ini taşırsınız. Yeni sistemde bu, bir MessageParser sınıfı ve field definition tablosu olur.
Bu yaklaşımın bir de gizli faydası var: modernizasyon fırsatı. Mainframe kodundaki iş mantığını olduğu gibi değil, anladıktan sonra daha iyi bir yapıyla taşıyabilirsiniz. COBOL’da tek bir 5000 satırlık programda yaşayan mantık, Java’da ayrı servisler, ayrı rule engine kuralları ve ayrı validation katmanları olarak modellenebilir. Legacy’deki teknik borcu taşımak zorunda değilsiniz, sadece iş mantığını taşırsınız.
Bankacılıkta, sigortacılıkta, telekomünikasyonda, kamu kurumlarında hâlâ mainframe üzerinde çalışan milyonlarca satır COBOL ve PL/1 kodu var. Bu sistemlerin modernizasyonu sektörün en büyük teknik borcu. Ve bu borcun ödenmesinde semantic copy-paste, literal dönüşüm araçlarından çok daha güvenilir bir yol.
Yöntem: 4 Adımda Semantic Copy-Paste
Bu beş örneğin hepsinde uyguladığım süreç aynı.
Birinci adım, kaynak kodu okumak ve anlamak. Repository’yi klonlayın, dosya yapısını inceleyin, temel akışı takip edin. MiroFish’te graph_builder.py → entity_extractor.py → simulation_runner.py → report_agent.py akışını izledim.
İkinci adım, pattern’i çıkarmak. Spesifik implementasyonu soyutlayın. “Python’da Zep Cloud’a entity yazıyor” ifadesini “Ham veriden entity çıkarıp bir graph store’a persist eden pipeline” olarak genelleyin.
Üçüncü adım, kendi bağlamınıza uyarlamak. Domain kavramlarını değiştirin. “Agent Persona” yerine “Channel Profile”, “Seed Text” yerine “Financial Message”, “Social Simulation” yerine “Message Flow Routing” koyun.
Dördüncü adım, genişletmek. Orijinalde olmayan özellikleri ekleyin. MiroFish’te olmayan ama FINGATEWAY’e eklediğimiz özellikler: anomali tespiti, SLA profilleri, schema validation, deploy pipeline’ı.
Ne Zaman Yapılmamalı?
Semantic copy-paste her zaman doğru tercih değil.
Standart kütüphaneler için yapmayın. JSON parsing, HTTP client, date formatting gibi iyi çözülmüş problemler için mevcut kütüphaneleri dependency olarak ekleyin.
Kriptografi ve güvenlik için asla yapmayın. Kendi crypto implementasyonunuzu yazmayın. Bu domain’de kanıtlanmış kütüphaneleri kullanmak her zaman doğrudur.
Kaynak proje yeterince olgunlaşmadıysa yapmayın. Proje v0.1’deyse ve API’si sürekli değişiyorsa, pattern’i çıkarmak için erken olabilir. Yapı oturana kadar bekleyin.
Tek seferlik kullanım için yapmayın. Pattern’i sadece bir yerde, bir kez kullanacaksanız, uyarlama maliyeti dependency ekleme maliyetinden yüksek olabilir.
Yapay Zekayı Semantic Copy-Paste Ajanı Olarak Kullanmak
Buraya kadar anlattığım sürecin her adımı manuel yapılabilir. Ama yapay zekayı bu işin ajanı olarak kurduğunuzda, süreç saatlerden dakikalara iner.
Burada kastettiğim şey “AI’a kodu çevirt” değil. Otomatik kod çevirisi literal copy-paste’in makineleştirilmiş hali, semantic copy-paste değil. Kastettiğim şey, AI’ı pattern çıkarma, bağlam uyarlama ve genişletme adımlarında bir düşünce ortağı olarak kullanmak.
Bunu üç aşamada kurabilirsiniz.
Birinci aşama: Pattern Çıkarma Ajanı. AI’a kaynak projenin kodunu verip, içindeki mimari pattern’leri soyutlamasını istersiniz. Burada önemli olan, AI’a “bu kodu Java’ya çevir” dememek. Bunun yerine şöyle bir yönerge vermek:
“Bu Python dosyasını oku. Kodun spesifik implementasyonunu değil, arkasındaki mimari kararları çıkar. Her karar için şunları belirt: hangi problemi çözüyor, hangi alternatifler varmış ama neden bu tercih edilmiş, bu kararın başka bir domain’e taşınabilir genel formu ne.”
Bu yönergeyle AI, graph_builder.py’yi okuyup “ham veriden yapısal bilgi çıkarma pipeline’ı” pattern’ini çıkarır. Zep Cloud’a özgü detayları değil, pipeline’ın adımlarını ve her adımın neden o sırada olduğunu açıklar.
İkinci aşama: Bağlam Uyarlama Ajanı. Çıkarılan pattern’i kendi domain’inize uyarlatırsınız. Yönerge şöyle olabilir:
“Bu pattern’i FINGATEWAY bağlamına uyarla. FINGATEWAY bir finansal mesaj akış yönetim platformu. Entity’ler banka, hesap, işlem, döviz, tutar. Mesaj formatları SWIFT MT ve ISO 20022. Pattern’deki her soyut kavramı bu domain’in somut kavramlarıyla eşleştir ve Java 17+ ile nasıl implemente edileceğinin iskeletini çıkar.”
Burada AI, “Agent Persona” kavramını “Channel Profile” ile eşleştirir, “Seed Text” kavramını “Financial Message” ile eşleştirir. Ama bunu mekanik bir find-replace olarak değil, domain bilgisiyle yapar. Örneğin “reaction_speed” alanını “SLA response time” olarak uyarlarken, bunun sadece isim değişikliği değil kavramsal bir dönüşüm olduğunu bilir.
Üçüncü aşama: Genişletme Ajanı. Uyarlanan pattern’in üzerine orijinalde olmayan özellikleri eklettirirsiniz:
“Bu MessageFlowGraph yapısına anomali tespiti ekle. Hibrit arama skorunu kullanarak, bilinen pattern’lerden sapan mesaj akışlarını tespit eden bir metot yaz. Eşik değerini konfigüre edilebilir yap.”
Bu adımda AI, mevcut yapının üzerine yeni bir yetenek ekler. Kaynak projede bu özellik yoktu ama altyapı zaten uygundu.
Bir de mainframe tarafında nasıl çalışır, ona bakalım. COBOL kodunu AI’a verip pattern çıkarttığınızda, yönerge şöyle olabilir:
“Bu COBOL programı bir EFT komisyon hesaplama modülü. İç içe geçmiş EVALUATE ve IF bloklarından iş kurallarını çıkar. Her kuralı şu formatta ifade et: koşul, aksiyon, istisna. Kurallar arasındaki öncelik sırasını belirle. COBOL’a özgü teknik detayları (WORKING-STORAGE layout, PERFORM paragrafları) dahil etme, sadece iş mantığını çıkar.”
AI, 500 satırlık COBOL spaghetti’sinden şöyle bir çıktı üretir: “Kural 1: İşlem tutarı 10.000 TL altındaysa sabit 2.50 TL komisyon uygula. Kural 2: İşlem tutarı 10.000 TL ve üstüyse binde 3 oranında komisyon uygula. Kural 3: Müşteri segmenti kurumsal ise Kural 2’deki oranı binde 1.5 olarak uygula. Kural 4: Yurt dışı işlemlerde ek 15 TL masraf ekle. Kural 5: Saat 16:00 sonrası işlemlerde bir sonraki iş günü kuru uygula.”
Bu çıktıyı aldıktan sonra ikinci aşamada Java’da bir CommissionRuleEngine olarak modelletirsiniz. Üçüncü aşamada üzerine COBOL’da olmayan özellikleri eklersiniz: kural versiyonlama, A/B test desteği, geriye dönük hesaplama.
Önemli uyarı: AI’ı bu süreçte bir otomasyon aracı olarak değil, bir düşünce ortağı olarak konumlandırın. AI’ın çıkardığı pattern’leri doğrulamanız, domain bilginizle filtrelemeniz ve genişletme kararlarını kendiniz vermeniz gerekiyor. AI süreci hızlandırır ama kararı siz verirsiniz.
Sonuç
Semantic copy-paste, açık kaynak ekosistemindeki deneyim ve bilgi birikimini kendi projenize taşımanın en esnek yolu. MiroFish gibi 56.000+ yıldızlı bir projenin Python mimarisini FINGATEWAY gibi bir Java/React projesine uyarlamak, literal olarak tek satır kod kopyalamadan, mümkün ve değerli. Aynı şekilde, 30 yıllık bir COBOL programındaki iş mantığını modern bir Java servisine taşımak da semantic copy-paste ile yapılır.
İster GitHub’daki bir açık kaynak projeden, ister mainframe’deki bir legacy sistemden taşıyor olun, önemli olan kodu değil kararı taşımak. “Neden bu şekilde yapılmış?” sorusunun cevabını çıkarmak, o cevabı kendi bağlamınıza uyarlamak ve üzerine yeni yetenekler eklemek. Budur semantic copy-paste.
Açık kaynak dünyasının gerçek değeri GitHub’daki dosyalarda değil, o dosyaların arkasındaki mimari kararlarda. Legacy sistemlerin gerçek değeri mainframe’deki COBOL satırlarında değil, o satırların arkasındaki onlarca yıllık iş bilgisinde. Semantic copy-paste, her iki değere de ulaşmanın yoludur.
https://claude.ai/public/artifacts/b5a15228-1631-4c9c-ba27-4e849bbc1f4d
