Uzun süre bu sitenin gerçekten bir bloga ihtiyacı olup olmadığından emin değildim.
Zaten çalışma zamanımın büyük bölümünü problem çözerek geçiriyorum. Bunların bazıları sıradan frontend veya backend işleri. Bazılarıysa çok daha dar alanlara iniyor: görüntü kodlama, tarayıcı davranışları, SEO deneyleri, altyapı arızaları, AI destekli geliştirme, medya işleme ya da basit bir soruyla başlayıp birkaç günlük araştırmaya dönüşen garip bir production problemi.
Bütün bunlardan sonra birkaç bin kelime daha yazmak gereksiz gelebiliyor.
Bunu kim okuyacak?
Bundan ne elde edeceğim?
Problemi çözüp yoluma devam etsem olmaz mı?
Sonunda benim için yeterince iyi bir cevap buldum: bu çalışmaların bir kısmı çöpe atılmayacak kadar pahalıya mal oluyor.
Zor bir problem, ben fark etmeden bütün bir makaleye dönüşebiliyor
Makalelerim genellikle “Bu hafta bir blog yazısı yazmam lazım” düşüncesiyle başlamıyor.
Bir problemle başlıyor.
Bazen işten geliyor. Bazen kendi projelerimden. Bazen de anlamadığım bir şey ilgimi çekiyor ve onu çok daha iyi anlayana kadar kazmaya devam ediyorum.
Görüntü işleme benim için bu türden pek çok derin araştırmaya dönüştü.
Başlangıçta görev neredeyse saçma derecede basit görünebilir:
Bu görüntüleri al ve daha küçük hale getir.
Bir AI modelinden bunun için bir script isteyebilir ve neredeyse anında bir tane alabilirsiniz.
Bu, elinizde iyi bir görüntü işleme pipeline'ı olduğu anlamına gelmez.
İlk sürüm JPEG, PNG, WebP ve animasyonlu içerikler arasındaki farkları görmezden gelebilir. Her şey için tek bir kalite değeri kullanabilir. Görüntüleri gereksiz yere büyütebilir. Şeffaflığı kötü işleyebilir. Silmek istediğiniz metadata'yı koruyabilir ya da tutmak istediğiniz metadata'yı yok edebilir. Görsel bozulmayı ölçmeden yalnızca dosya boyutuna odaklanabilir. On test dosyasında kusursuz çalışıp çok daha büyük ölçekte son derece pahalı bir hataya dönüşebilir.
Başarıyla çalışan bir script ile güvendiğim bir sistem aynı şey değil.
Makalelerimin önemli bir kısmı tam olarak bu ayrımdan doğuyor.
Benim AI çalışma sürecim “ChatGPT'ye sor ve cevabı al”dan çok daha yavaş
Bu tür problemler üzerinde çalışırken ücretli ChatGPT hesabımı yoğun biçimde kullanıyorum.
Tek bir konuşma günlerce, hatta haftalarca devam edebiliyor. Sorular soruyorum, önerileri test ediyorum, sonuçları geri gönderiyorum, varsayımları sorguluyorum, kodu inceliyorum, yeni bir edge case buluyorum, implementasyonu değiştiriyorum, tekrar çalıştırıyorum, sonuçları karşılaştırıyorum ve aynı döngüyü yeniden yapıyorum.
Özellikle derin araştırmalarda aynı genel problem etrafında 100 saatin üzerinde çalışma biriktirdiğim oldu.
Bu, 100 saat boyunca bir AI modelinin sihirli biçimde cevabı bulmasını beklediğim anlamına gelmiyor.
Süreç iteratif.
Tipik bir akış daha çok şöyle görünüyor:
- Problemi açıklıyorum.
- Model ilk çözümü öneriyor.
- Onu gerçek veriler üzerinde çalıştırıyorum.
- Bir şey zayıf, verimsiz ya da düpedüz yanlış çıkıyor.
- Kanıtı tekrar konuşmaya getiriyorum.
- Yaklaşımı değiştiriyoruz.
- Tekrar test ediyorum.
- Başka bir edge case ortaya çıkıyor.
- Tekrar.
Bu döngü birçok kez tekrarlanabiliyor.
Faydalı sonuç çoğu zaman ilk script değil. Onun etrafında biriken başarısızlıklar, ölçümler, düzeltmeler ve kararlar bütünü.
AI başlangıç noktası üretmeyi ucuzlattı. Doğrulamayı ucuzlatmadı
AI ile yazılmış teknik içerik hakkındaki yaygın tartışmaları fazla basit bulmamın nedenlerinden biri bu.
Evet, bir AI modeli çok kısa sürede makul görünen bir tutorial üretebilir.
Aynı model, tamamen mantıklı görünen ama tam da önemli olan durumlarda yanlış çalışan kod da üretebilir.
Dar ve teknik problemlerde nadiren ilk makul cevabı isterim. Onu gerçekten çalıştırdığımda ne olduğunu bilmek isterim.
Bir görüntü pipeline'ı kuruyorsam çıktı boyutlarını ve görsel kaliteyi incelemek isterim. Farklı kaynak formatlarında ne olduğunu görmek isterim. Sıra dışı boyutları, alpha kanalını, animasyonları ve bozuk girdileri test etmek isterim. Implementasyonun hangi varsayımlara dayandığını anlamak isterim.
Script sonunda çok büyük bir koleksiyona uygulanacaksa bu çalışma daha da önemli hale gelir.
On milyon görüntü bilinçli olarak uç bir örnektir; belirli bir veri setimin on milyon görüntü içerdiği iddiası değildir. Ama problemi iyi anlatıyor: küçük ve sistematik bir hata on milyon kez tekrarlandığında artık küçük bir hata değildir.
Kod üretmenin maliyeti dramatik biçimde düştü.
O kodun büyük ölçekte çalıştırılmayı hak edip etmediğini belirlemenin maliyeti düşmedi.
Chat araştırma malzemesidir, bitmiş makale değil
Bu uzun araştırmalardan birinin sonunda sohbet geçmişinde absürt miktarda bilgi birikebilir.
İçinde şunlar olabilir:
- başarısız olmuş yaklaşımlar;
- daha sonra değiştirilmiş kodlar;
- yararlı benchmark sonuçları;
- loglar;
- yanlış anlamalar;
- düzeltmeler;
- az bilinen davranışların açıklamaları;
- alternatifler arasındaki karşılaştırmalar;
- başlangıçta düşünmediğim edge case'ler;
- ve sonunda güvenmeye başladığım kurallar.
Bütün bunları özel bir konuşmanın içinde bırakmak bana israf gibi geliyor.
Bu yüzden yararlı parçaları çıkarıp bir makaleye dönüştürüyorum.
Makale konuşmanın transkripti değil. Konuşmanın büyük bölümü zaten hiçbir zaman makaleye dönüşmemeli.
Faydalı bir teknik makalenin ikinci bir aşamaya ihtiyacı var: hiçbir şey öğretmeyen çıkmazları atmak, önemli bir şeyi açıklayan çıkmazları korumak, iddiaları doğrulamak, kronolojiyi yeniden kurmak, gözlemi açıklamadan ayırmak ve sonucu başka bir geliştiricinin gerçekten kullanabileceği hale getirmek.
Bu editoryal aşama önemli.
AI buna yardım edebilir, ama kanıt hâlâ yapılan işten gelir.
Görüntü işleme bana “basit” bir problemin ne kadar derine gidebildiğini öğretti
Görüntü optimizasyonu muhtemelen kendi çalışmalarım içindeki en net örnek.
Üzerinde yeterince zaman geçirdim ve başlangıçta birkaç encoder ayarı gibi görünen şey zamanla çok daha büyük bir sistem problemine dönüştü.
Sorular hızla çoğalıyor.
Hangi kaynak formatıyla uğraşıyorum?
Animasyonlu mu?
Boyutları değiştirmeli miyim?
Kaliteyi nasıl seçmeliyim?
Kalite kaybının kabul edilebilir olup olmadığını hangi metrik belirlemeli?
Tek bir kalite eşiği tamamen farklı görüntülerde işe yarar mı?
Upscaling'den nasıl kaçınırım?
Hangi metadata kalmalı?
Şeffaflığa ne olacak?
Çıktı nasıl doğrulanmalı?
Daha küçük dosya gerçekten ek encoding maliyetine değer mi?
Girdi dağılımı değiştiğinde ne olur?
Beş satırlık “nihai görüntü optimizasyonu” scriptlerine bu yüzden şüpheyle yaklaşıyorum.
Bir görüntüyü gayet iyi işleyebilirler.
Bu, ödünlerini gerçekten anladığınız bir pipeline kurmaktan farklıdır.
Şu anki görüntü ağırlıklı iş yüklerimde genellikle ilk tercih etmek istediğim format AVIF oluyor. Bu, çalıştığım proje türlerine dayanan bir kural; dünyadaki her sitenin yarın bütün eski formatları silmesi gerektiği iddiası değil. Uyumluluk gereksinimleri, kaynak materyal, latency, encoder maliyeti ve delivery mimarisi cevabı değiştirebilir.
İlginç olan bir formatı kazanan ilan etmek değil.
İlginç olan, bilinçli karar verecek kadar iş yükünü anlamak.
Video işleme konusunda da aynı derinliğe inmeyi istiyorum. Henüz orada değilim. Bu konuları ilginç yapan şeylerden biri de bu: bir problemin dibine ulaştığımı düşündüğüm her seferde başka bir katman çıkıyor.
Sonra Japon bir site blogu buldu
Bu makaleleri yayımlamaktan belirli bir karşılık beklemiyordum.
Bu blogun benim için anlamlı bir finansal getirisi yok. Süreci sevdiğim için ve yararlı çalışmaların eski sohbetlerde ya da terminal geçmişinde kaybolmasını istemediğim için yapıyorum.
Sonra gerçekten beklemediğim bir şey oldu.
17 Eylül 2026'da Japon Levtech Freelance sitesi, kabaca “Kendini Geliştirmek İsteyen Mühendisler İçin Önerilen Bloglar” şeklinde çevrilebilecek bir seçki yayımladı.
Levtech Freelance makalesi, JSVar'ı birkaç başka mühendislik bloguyla birlikte listeledi.
Levtech, Japonya'daki geniş bir IT kariyer ekosisteminin parçası; Levtech Freelance ise freelance IT mühendislerini desteklemeye ve projelerle eşleştirmeye odaklanıyor. Benim için ilginç olan yalnızca bir backlink almak değildi. Dışarıdaki bir editoryal ekibin çalışmalarımın hangi kısımlarını anlatmaya değer bulduğunu görmekti.
JSVar hakkındaki bölümlerinde özellikle üç makaleyi öne çıkardılar.
Bunlardan biri, production geliştirmede Codex ile TypeScript'in neden birlikte iyi çalıştığını düşündüğüm hakkındaydı; özellikle de TypeScript'in tipleri ve compiler geri bildiriminin üretilen koddaki hataları erken ortaya çıkarabilmesi nedeniyle.
Bir diğeri, blogu ChatGPT ile 20 dile çevirmem ve farklı ülkelerden arama ziyaretçilerinin doğrudan lokalize sayfalara gelmeye başlaması hakkındaydı.
Üçüncüsü ise 10.000 AI tarafından üretilmiş SEO sayfası yayımlama deneyimdi; sonunda kolay büyümeden çok bir başarısızlık hikâyesine dönüştü.
Bu seçim beni eğlendirdi çünkü üçü de çok farklı makaleler, ama aynı ortak yapıya sahipler.
Gerçekten yaptığım bir şeye dayanıyorlar.
Levtech'in beni tam olarak nasıl bulduğunu bilmiyorum
Burada anlatılması çok cazip olan temiz bir hikâye var.
Japonca bilmiyorum.
Sitemin Japonca sürümü var.
Japon bir mühendislik yayını siteyi buldu.
Öyleyse blogu Japoncaya çevirmek Levtech'in beni bulmasına neden oldu.
Bunu kanıtlayamam.
Belki Japonca sayfalar yardımcı oldu.
Belki arama onları İngilizce bir makaleye götürdü.
Belki biri bir bağlantı paylaştı.
Belki siteyi tamamen başka bir yoldan buldular.
Bu attribution verisine sahip değilim; dolayısıyla bundan temiz ve kusursuz bir SEO case study uydurmayacağım.
Doğrulayabildiğim şey çok daha basit: blogu birden fazla dilde yayımladım ve daha sonra Japon bir yayın onu editoryal bir seçkiye dahil edecek kadar ilginç buldu.
Bu zaten iyi bir sonuç.
Üstelik lokalizasyon da başlangıçta çok emek isteyen ve getirisi belirsiz görünen başka bir deneydi; bu yüzden sonuç benim için daha da tatmin edici.
Bu seçkide yer almak benim için bağımsız bir doğrulama olduğu için önemliydi
Buradaki “doğrulama” ile Levtech'in yazdığım her şeyin doğru olduğunu kanıtladığını kastetmiyorum.
Kod tabanımı denetlemediler ve her deneyimi yeniden üretmediler.
Önemli olan daha mütevazı bir şeydi.
Dünyanın öbür tarafındaki, kendi dilinde doğrudan hitap edemeyeceğim bir kitle için yazan biri, çalışmalarımda okuyucularına özetlemeye değer yeterince değer buldu.
Onlara teklif göndermedim.
O ilk makaleleri Levtech için yazmıyordum.
Japon bir seçkide yer almayı beklemiyordum.
Sonucu benim için anlamlı yapan şey bu.
Bu, çok dar bir teknik makalenin yayımlanmaya değer olması için mutlaka dev bir kitleye ihtiyaç duymadığını düşündürüyor.
Doğru okuyucu için yararlı olması yeterli olabilir.
Bir geliştirici 2026'da blog açmalı mı?
Benim için cevap evet — ama önemli bir şartla.
Gerçekten yazıya dökmek istediğiniz bir şeyiniz olmalı.
Birileri her geliştiricinin “kişisel marka” oluşturması gerektiğini söyledi diye teknik blog açmanızı önermem.
Pasif gelir beklediğiniz için de başlamazdım.
Zaten daha iyi dokümantasyonu bulunan teknolojiler hakkında genel açıklamalarla doldurmak için de blog açmazdım.
Ama yaptığınız iş sürekli olarak, işe başladığınızda keşke bulabilseydim dediğiniz türden bilgiler üretiyorsa durum farklı.
Onları yazın.
Garip production arızasını yazın.
Beklediğinizden üç gün daha uzun süren optimizasyonu yazın.
Varsayımınızla çelişen benchmark'ı yazın.
Zarif görünen ama başarısız olan yaklaşımı yazın.
Son implementasyonu yazın; ama aynı zamanda neden ilk akla gelen implementasyonun yeterli olmadığını da açıklayın.
Genel bilgiden taklit edilmesi zor olan kısımlar bunlar.
AI bana yazacak daha az değil, daha fazla malzeme veriyor
AI teknik blogların artık gereksiz olduğunu düşündürmedi.
Benim için neredeyse tam tersi oldu.
İlk implementasyonu veya açıklamayı elde etmek eskisinden daha hızlı olduğu için daha fazla fikri araştırabiliyorum.
Ama daha hızlı iterasyon aynı zamanda daha fazla kanıt üretiyor: daha fazla varyant, daha fazla log, daha fazla benchmark, daha fazla başarısız deneme ve kontrol edilmesi gereken daha fazla şey.
Bu ham malzeme ancak biri neyin doğru ve neyin önemli olduğuna karar verme işini yaptıktan sonra değer kazanıyor.
500 mesaj içeren bir AI konuşması otomatik olarak bilgi değildir.
Gerçek testlerden sonunda sağ çıkan bir script ve başarısız olan 20 sürümün neden başarısız olduğunun açıklaması ise bilgiye dönüşebilir.
Blogda yakalamak istediğim fark bu.
Yayımlamak, yararlı çalışmaların kaybolmasını engelleme biçimim
Teknik çalışmaların şaşırtıcı derecede büyük bir kısmı geçici.
Zor bir bug düzeltiliyor.
Terminal kapanıyor.
Deployment başarılı oluyor.
Chat geçmişte aşağı doğru kayıyor.
Altı ay sonra nihai implementasyonun neden o şekilde göründüğünü ben bile hatırlamayabilirim.
Yazmak bunu değiştiriyor.
Kanıt hâlâ ortadayken düşünce sürecini yeniden kurmaya zorluyor.
Aranabilir bir şey oluşturuyor.
Kendi gelecekteki çalışmalarım için bir referans sağlıyor.
Ve görünüşe göre bazen hiç beklemediğim birine de ulaşıyor — konuşamadığım bir dilde yayın yapan bir mühendislik yayını dahil.
Bu blogu sürdürmek için hâlâ sofistike bir gerekçem yok.
Öğrenmeyi seviyorum.
Bir şeyler üretmeyi seviyorum.
Başlangıçta basit görünen problemlerin gereğinden fazla derinine inmeyi seviyorum.
Ve faydalı bir cevaba ulaşmak için onlarca, bazen yüz saatin üzerinde zaman harcadıktan sonra artık o cevabın bir chat penceresinin içinde ölmesini istemiyorum.
Benim için yayımlamak adına bu yeterli bir neden.
Sizin çalışmalarınız da aynı türden zor kazanılmış bilgi üretiyorsa, sizin için de yeterli bir neden olabilir.