İlk Göz Ağrısı: Turkuaz CSS

Her şey Bootstrap ve Materialize gibi devlerin kaynak kodlarında kaybolduğum günlerde başladı. Amacım onlarla yarışmak değil, bir UI kütüphanesinin arka planda nasıl nefes aldığını anlamaktı. Bu merakın ilk somut çıktısı Turkuaz oldu. Turkuaz sayesinde CSS’in teknik derinliklerini keşfettim ve zorluklarını bizzat deneyimledim. Bugün artık modern standartlar (Tailwind CSS, shadcn/ui) yerleştiği için bu projeyi rafa kaldırmış olsam da Turkuaz, bana bugünkü vizyonumu kazandıran ilk göz ağrım olarak kaldı.

İsimlerin Ruhu ve Karşılaşılan Bariyerler

Turkuaz’dan sonra her projeye karakterini yansıtan Türkçe isimler verdim. Next.js mimarisini disipline eden Nizam, yapay zekayı bir asistan gibi eğiten mimari kurallar seti Kaide ve React Hook Form için geliştirdiğim hafif maskeleme paketi Beti bu dönemin ürünleriydi. Bu isimler kısa, akılda kalıcı ve ASCII standartlarına uygun olsa da; zayıf keşfedilebilirlik ve dokümantasyonu incelemeden projenin amacının anlaşılamaması gibi sorunları da beraberinde getirdi.

@omergulcicek/beti gibi bireysel isim-soyisim içeren paketler, geliştiricilerde "kişisel bir deneme" algısı yaratıyor ve güven bariyeri oluşturuyordu. Bu durum, nitelikli bir mühendislik çalışmasının hak ettiği ilgiyi görmesini engelliyordu. Ayrıca bu derin Türkçe isimlerin global arenasinda telaffuzu zor, SEO karşılığı zayıf ve domain erişilebilirliği kısıtlıydı. Profesyonel bir büyüme için bireysel repolardan, topluluk odaklı ve ölçeklenebilir bir organizasyon yapısına geçmek zorundaydım.

ViraStack: Bir Ekosistemin Doğuşu

Zanaatkarlıktan mühendisliğe geçiş, stratejik bir karar gerektiriyordu. İsim arayışımda Türkçe kökenli, fonetik olarak güçlü ve yabancıların da kolayca telaffuz edebileceği bir kelime aradım. Sonunda Vira isminde karar kıldım. Bana Karadeniz’in o mücadeleci ruhunu, balıkçıların “Vira Bismillah” diyerek yola çıkışını çağrıştırıyordu. Hem kısa hem de Meta, Vite veya Vue gibi teknolojik bir tınısı vardı. Vira ismi tek başına dolu olduğu için, bu yapıyı bir “stack” disipliniyle birleştirerek ViraStack organizasyonunu kurdum.

Peki, Bunlarla Neden Uğraşıyorum?

ViraStack sadece bir isim değişikliği değil, bir vizyon değişikliği. Bu benim öğrenme biçimim; bir işin mutfağına girip detaylara ve kaliteye en uç noktada hakim olmayı seviyorum. Her projeyi markalaştırarak o fikri benimsiyor, böylece sadece kod yazmakla kalmayıp bir standart inşa ediyorum. Eskiden Turkuaz ile CSS dünyasını araştırırken; bugün ViraStack çatısı altında React mimarileri, Hook yapıları ve Yapay Zeka protokolleri gibi konularda en güncel standartları keşfetmeye itiliyorum. Tüm paketleri birbirine kenetli, tutarlı ve üst kalite bir alet çantası olarak kurgulamaya özen gösteriyorum. SEO dostu isimlendirmeler ve organizasyonel yapı sayesinde, artık bireysel bir çabanın ötesinde, topluluğa ait ve güven veren bir ekosistem inşa ediyorum.

Sonuç: Geleceğe Vira!

Frontend ekosistemi inşa etmek benim için sadece kod yazmak değil; her parçası özenle düşünülmüş, tutarlı bir düzen kurmaktır. ViraStack ile sadece bir ekosistem inşa etmekle kalmıyor; bu yapının hangi kurallar (AI Rules) üzerine kurulacağını ve hangi standart başlangıç yapılarıyla (Boilerplate) ayağa kaldırılacağını uçtan uca tasarlıyorum. Bu yolculuğun teknik mimarisini, geliştirdiğim paketlerin derinliklerini ve ekosistemin işleyişini bir sonraki makalede kapsamlı bir şekilde ele alacağım.

ViraStack ekosistemi, topluluktan gelen geri bildirimlerle büyümeye devam ediyor. Projeleri GitHub üzerinden yıldızlayarak ve sosyal medyada takip ederek bu açık kaynak yolculuğuna destek olabilirsiniz:

• GitHub: github.com/virastack (Yıldızlayarak destek olun ⭐)
• X (Twitter): x.com/virastack
• LinkedIn: linkedin.com/virastack

Yeni proje fikirleriniz veya teknik sorularınız için bana her zaman bu kanallar üzerinden ulaşabilirsiniz. Geleceğe vira!

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/frontend-ekosistemi-insa-etmek/
X (Twitter): @omergulcicek

Makaleyi alkışlayarak destek olabilirsiniz 🌹

Frontend Ekosistemi İnşa Etmek: Zanaattan Mühendisliğe Bir Yolculuk was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

2023 başları, o dönem çalıştığım şirkette haftada bir kısa bir sunum oluyor. Her seferinde farklı birisi diğerlerine yararı olacağını düşündüğü bir konuda kısa bir eğitim, peşine de soru-cevap yapıyor.

O dönem bir ekip arkadaşım Github Copilot’tan bahsetti, nasıl kullanıldığını, nasıl kod önerileri yaptığını anlattı. O dönem çok ilgimi çekmedi açıkçası, belki arkadaşımın verdiği örneklerden, belki de o dönem Copilot’un kapasitesinin gerçekten o kadar olduğundan bilmiyorum, aa bir de ben deneyeyim demedim. Daha da dürüst olmak gerekirse, yakın zamanda bunun pek de bir yere gideceğini düşünmedim. Ama aklımda bir köşede kaldı bu.

2025 başları, bu sefer bir bankaya çalışıyorum. Banka kendi “Copilot”unu üretmeye çalışıyor çünkü dışarıdan bu şekilde bir araç kullanılırsa güvenlik zaafiyeti yaratabilir düşüncesi hakim. Yüklettikleri araç 2023'te gördüğüm Copilot’un bile daha gerisinde. Heh diyorum, tam da düşündüğüm gibi. Pek de ilerleme yok. Ama nasıl yanılıyorum.

2025 ortalarında, şirkette bir yapay zekâ eğitimi oluyor. Bir düzine yapay zeka aracı tanıtılıyor, ama aklımda Claude ve NotebookLM kalıyor. NotebookLM başka bir yazının konusu olacak, burada Claude’dan bahsedeceğim. Claude MCP sunucuları kullanıyor, MCP sunucularının listesinin olduğu GitHub reposu kaydırdıkça bitmiyor, tüm bunların yapay zekâ tarafından kullanılabilir hale geldiğine inanamıyorum. İleride çok işime yarayacağını düşünüyorum fakat o an pek de kullanım alanı bulamadığımdan Claude’a geçmiyorum. Fakat Claude aklımda yer ediyor.

2025 devam ediyor, bense kodlama sorularım için direkt olarak ChatGPT ile sohbet ediyorum. Bankaya çalışmaya devam ettiğim için herhangi bir kodu alıp da ChatGPT’ye atmam mümkün değil, o yüzden hâlâ tam olarak bir kodlama asistanı olarak kullanamıyorum ama aldığım cevaplardan yapay zekâ destekli kodlamanın geldiği seviyeleri yavaş yavaş anlamaya başlıyorum.

2026 başı, en sonunda X’te gördüğüm bazı twitlerden sonra Cursor’a bir şans vermeye karar veriyorum. Üzerinde çalıştığım repoyu Cursor’da açıyorum. Eklemek istediğim deneyi prompt ile yazıyorum. Biraz deneme yanılma sonrasında tek satır kod yazmadan deneyimin koda eklenip çalıştırıldığını, sonuçlarının kaydedildiğini ve yorumlandığını görüyorum. Hemen aylık Cursor üyeliği alıyorum. Artık hem ChatGPT hem de Cursor kullanıyorum.

Cursor’u keşfetmeye devam ederken Copilot olayının ne kadar mesafe kat ettiğine hayret ediyorum, X’te bu konuda daha fazla içerik takip etmeye başlıyorum. En sonunda Claude Code ile ilgili twitler görmeye başlıyorum. Tam o sıralarda başka bir arkadaşım da Claude Code ile oyun geliştirmekte olduğunu, sonlarına yaklaştığını söylüyor.

Aynı anda hem Cursor, hem ChatGPT, hem de Claude’a para vermek biraz gözümde büyüyor fakat Claude’un vaat ettikleri beni çok cezbediyor, Claude Pro alıyorum. İlk birkaç günün sonunda Cursor ve ChatGPT üyeliklerimi sona erdiriyorum, çünkü Claude ikisini birden karşılıyor.

Cowork ve Code beni hem iş tarafında hem de doktora tarafında defalarca saatler sürebilecek eforlardan kurtarıyor; hem ben memnun kalıyorum hem de çalıştığım insanlar çıktılardan memnun oluyor. Hızlı bir şekilde prototipler, POC’ler yapabiliyorum, makaleleri topluca verip analiz ettirebiliyorum, sunulmaya neredeyse hazır sunumlar hazırlatabiliyorum. Öyle ki, aylardır kangren olmuş bazı kodlama sorunlarımı birkaç promptta çözüyor, senelerdir yapmak istediğim hobi projelerimi bile yapabilir hale geliyorum.

Sorumluluk almaktan kaçınmıyorum, çünkü artık kodlama eforu neredeyse fikri üretme eforuyla benzer seviyelere geliyor.

Şu anda tek problem usage limit gibi duruyor. Bunun için de alternatif çözümler arıyorum; bu limit olayı çözülse Claude’dan çıkmam gibi geliyor.

Günümüzde hâlâ Claude kullanmaktayım. Ne yazık ki özelleştirilmiş, MCP’ler ile güçlendirilmiş versiyonları hâlâ çok başarılı değil, fakat eskisi gibi başarılamaz, çözülemez diye bakmıyorum. Ayrıca Office eklentileri de hoş, fakat çok token harcadığından çok gerekmedikçe kullanmamaya çalışıyorum. Onun haricinde hem işte hem akademide elim ayağım oldu diyebilirim. 3 ayda, özellikle Claude kullandığım bu kısa sürede bu araçları neden daha önce kullanmadığımı düşünüp hayıflanıyorum, geç olsun güç olmasın diyorum.

Sizden ricam, eğer bu yazıyı okuduysanız ve henüz bu araçlardan birini bile kullanmadıysanız, sadece sohbet ile yetiniyorsanız, biraz daha derinlere inmeniz, biraz daha elinizi kirletmeniz. İnanın, verdiğiniz efor aldığınız ödül yanında çok ufak kalacak. Eğer halihazırda bu araçları kullanıyorsanız ve anlattıklarımdan da fazla yararlanabiliyorsanız, lütfen bunu yorumlarda paylaşın.

O halde bir sonraki yazıda görüşmek üzere :)

Claude Alışkanlıklarımı Nasıl Değiştirdi? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern yönetim dünyası, yirminci yüzyılın ortalarında şekillenen ve günümüzde dijital dönüşümle evrilen iki devasa düşünce okulunun gerilimi üzerine kurulu görünüyor. Ancak bu gerilim, sandığınız gibi dengeli bir mücadele değil; zemindeki levhalar kaymış bir bina gibi, temelleri çürük bir zaferin hikayesi.

Bir yanda modern yönetimin babası sayılan Peter Drucker ve onun “Hedeflerle Yönetim” (MBO) felsefesinin güncel maskeli balosu olan OKR sistemleri; diğer yanda ise kalite devriminin mimarı, Japonya’nın savaş sonrası mucizesinin arkasındaki isim W. Edwards Deming ve onun “Derin Bilgi Sistemi” (SoPK) duruyor.

Peki, Batı dünyası neden Drucker’ı bir kahraman gibi kucaklarken, Deming’i neredeyse bir sürgüne mahkum etti? Cevap, iş dünyasının en karanlık sırrında saklı: Kolay olanın, doğru olanı her zaman yenmesi.

Bu makalede, panellerdeki gösterge tablolarının (dashboard) arkasında yatan boşluğu, OKR hırslarının bitirdiği ruhları ve yöneticilerin kendilerine kurdukları en büyük yalanı masaya yatırıyoruz.

İki Dev, İki Farklı Evren

Peter Drucker ve W. Edwards Deming, 20. yüzyılın yönetim anlayışını inşa eden iki temel figür olarak tarihe geçmiştir. Ancak bu iki ismin organizasyonel karmaşıklığa yaklaşımı, birbirinden tamamen farklı iki evreni temsil eder.

Peter Drucker’ın dünyası:1954 yılında yayımlanan The Practice of Management eseriyle Drucker, yöneticilerin kantitatif hedeflere sahip olmasının gerekliliğini vurguladı. Ona göre bir yöneticiye hedefi vermek, enerjisini odaklaması için yeterliydi.

Yani:

• “Nereye gideceğini söyle, nasıl gideceğini sen bilirsin.”
• Kontrol basit ve doğrusaldır.
• Sorumluluk, hedefi alan bireydedir.

W. Edwards Deming’in dünyası:Deming ise bu yaklaşımı sert bir dille eleştirdi. Ona göre hedeflerle yönetim, “ne yapılacağını bilmeden yönetme girişimi”ydi ve yönetimin “ölümcül hastalıklarından” biriydi.

• “Sistemi anla, süreci iyileştir, sonuçlar kendiliğinden gelecektir.”
• Kontrol istatistiksel ve bütünseldir.
• Sorumluluk %94 oranında sistemi tasarlayan yönetimdedir.

Bu ayrım, günümüzde hâlâ geçerlidir. Amerikan ve Batılı şirketlerin büyük çoğunluğu, Deming’in sistem düşüncesini görmezden gelerek Drucker’ın hedef odaklı kontrol sistemlerini tercih etmektedir. Peki neden?

Termostat Yanılsaması: Neden Kontrol Ettiğimizi Sanıyoruz?

Yönetim yaklaşımlarını anlamak için en etkili metaforlardan biri “termostat” örneğidir. Drucker’ın hedef odaklı sistemi, klasik bir geri besleme kontrol sistemi olan termostata benzer.

Bir yönetici, istenen bir “sıcaklık” (hedef) belirler. Sistem bu hedefe ulaşmak için çıktı üretir. Eğer hedef ile mevcut durum arasında bir fark (varyans) varsa, sistem bu farkı kapatmak için zorlanır.

Bu model size güven verir mi? Vermeli. Çünkü bu model:

• Yöneticinin sınırlı bilişsel kapasitesini korur.
• Karmaşık dünyayı “hedef” ve “gerçek” ikilemine indirger.
• Yöneticiye sürekli bir “aksiyon alma” yetkisi verir.

Ancak Deming’in yaklaşımı bu noktada devreye girer ve oyunu bozar. Deming, istatistiksel kontrolü savunur. Ona göre bir sistemin “kontrol altında” olup olmadığını anlamak için değişkenliğin doğasını gözlemlemek gerekir.

Deming’in ünlü Huni Deneyi (Funnel Experiment), istikrarlı bir sisteme yapılan müdahalelerin (tampering), sistemi iyileştirmek yerine aslında değişkenliği artırarak performansı kötüleştirdiğini kanıtlamıştır.

Yani termostatı sürekli kurcaladığınızda, odayı ısıtmazsınız; sadece sistemi yorar ve dengesizleştirirsiniz.

Yöneticinin Konfor Alanı: Bilişsel Tasarruf Tuzağı

Modern iş dünyasında yöneticiler, zamanlarının neredeyse tamamını toplantılarda geçiren ve aşırı bilgi yüklemesine maruz kalan aktörlerdir. İşte Drucker’ın fikirlerinin ve OKR gibi sistemlerin baskın hale gelmesinin altında yatan gerçek neden budur: Bilişsel Tasarruf.

Bir organizasyon, doğası gereği karmaşık ve kaotik bir yapıdır. Drucker’cı yaklaşım, yöneticilerin bu karmaşıklığı basit metriklerle (Key Results) filtreleyerek “kontrol yanılsaması” (illusion of control) elde etmesini sağlar.

Bu durum, yöneticinin kendisini yetkin ve kontrol sahibi hissettiği bir “konfor alanı” yaratır. İki yol olduğunu düşünelim:

1. Kolay Yol (Drucker):

• Hedefleri belirle.
• Dashboard’u izle.
• Sapma olduğunda hesap sor.

2. Doğru Yol (Deming):

• Sistemin neden bu sonucu ürettiğini anlamak için derinlemesine araştırma yap.
• Çalışanların psikolojisini ve süreçlerin birbirine bağımlılığını analiz et.
• Sabırla sistemin kapasitesini artır.

Psikolojik araştırmalar, insanların belirsiz ve karmaşık sistemleri anlamaya çalışmak yerine, basit ve doğrusal (A sebep olur B) modelleri tercih etme eğiliminde olduğunu göstermektedir.

Yönetim dünyasında, yöneticinin hayatını kolaylaştıran (fakat sistemi iyileştirmeyen) yöntemler, kurumsal birer standart haline gelmiştir. Bu, “Başarı Çukuru” (Pit of Success) kavramıyla açıklanabilir: Sistemler, doğru olanı zor yapacak şekilde tasarlanmıştır, ancak insanlar kolay olanı seçtiği için çukurun içinde kalırlar.

Deming’in “Derin Bilgi Sistemi”: Neden Bu Kadar Zor?

Deming’in yönetim felsefesi, uygulanması oldukça zor olan dört temel sütun üzerine inşa edilmiştir. Bu sütunlar arasındaki etkileşim, organizasyonun “derin bilgisini” oluşturur. Peki, neden bu kadar kaçınılıyor?

1. Sistem Anlayışı (Appreciation for a System)

Deming, bir organizasyonu ortak bir amaç doğrultusunda çalışan birbirine bağımlı bileşenler ağı olarak tanımlar. Bir sistemin parçalarını optimize etmek, sistemin bütününü genellikle alt-optimize eder.

Drucker’ın MBO ve OKR sistemleri ise, doğası gereği birimleri kendi hedeflerine odakladığı için departmanlar arası silolar ve çatışmalar yaratma eğilimindedir. Yönetici, “Benim departmanım hedefine ulaştı” diyebilir ama şirket batmış olabilir.

2. Varyasyon Bilgisi (Knowledge about Variation)

Her sistemde değişkenlik vardır. Deming, bu değişkenliği “genel nedenler” (sistemin kendisinden kaynaklanan) ve “özel nedenler” (dışsal müdahaleler) olarak ikiye ayırmıştır.

Batılı yöneticiler genellikle genel nedenli varyasyonlara (sistemin doğal dalgalanmalarına) birer özel nedenmiş gibi tepki vererek sistemi kurcalarlar. Bu da hataların artmasına yol açar.

3. Bilgi Teorisi (Theory of Knowledge)

“Bildiğimizi nasıl biliyoruz?” sorusunu sorar. Deming’e göre yönetim bir tahmin işidir ve tahmin için teori gereklidir. Drucker’ın modeli yöneticilerin halihazırda bu bilgiye sahip olduğunu varsayar, Deming sürekli bir test ve doğrulama süreci talep eder.

4. Psikoloji Bilgisi

İnsanlar işlerinden gurur duymak ve bir anlam bulmak ister. Deming, sayısal hedeflerin, sıralama sistemlerinin ve performans primlerinin içsel motivasyonu öldürdüğünü ve yerine korkuyu getirdiğini savunur. Korku ise verilerin manipüle edilmesine ve gerçek sorunların gizlenmesine neden olur.

MBO ve OKR’lerin Gizli Maliyeti: Sistemi Oyunlaştırmak

Drucker’ın MBO sisteminin en büyük eleştirisi, süreçten bağımsız olarak hedefe odaklanmanın etik olmayan davranışları teşvik etmesidir. Deming’in uyarısı nettir:

“Eğer yönetici sayısal hedefler koyar ve insanların işini buna bağlarsa, insanlar o hedeflere ulaşacaklardır — gerekirse şirketi mahvetmek pahasına.”

Wells Fargo Örneği: Sistemsel Bir Patoloji

Wells Fargo bankasında yaşanan skandal, Deming’in teorilerinin acı bir kanıtıdır. Banka yönetimi, “Eight is Great” (Her müşteriye sekiz ürün satma) hedefi koymuş ve bu hedefe ulaşamayan çalışanları işten çıkarmakla tehdit etmiştir.

Sonuçlar ortadadır:

• Sayısal Hedeflerin Baskısı: Çalışanlar, sadece kotaları dörmak için müşterilerden habersiz milyonlarca sahte hesap açmıştır.
• Metrik Takıntısı: Üst yönetim, satış rakamlarındaki patlamayı kutlarken, bu rakamların nasıl elde edildiğine dair “yöntem” bilgisini tamamen görmezden gelmiştir.
• Korku Kültürü: Uyarıda bulunan çalışanlar susturulmuş veya cezalandırılmıştır.

Bu durum, Drucker’ın “yöneticiler ne yapacaklarını bilir” varsayımının çöküşüdür. Yöntem belirtilmeden verilen hedefler, sistemi iyileştirmek yerine sistemi oyunlaştırmaya (gaming) zorlar.

OKR’lerin Çıkmazı: Yeni Bir İsim, Eski Bir Sorun mu?

Günümüzde OKR (Objectives and Key Results) sistemleri, özellikle teknoloji dünyasında MBO’nun daha modern ve çevik bir versiyonu olarak pazarlanmaktadır. Ancak Deming perspektifinden bakıldığında, OKR’ler de aynı temel hataları barındırmaktadır.

OKR’lerin uygulanmasında karşılaşılan temel sorunlar şunlardır:

• Hiyerarşik Kaskat Yanılgısı: Hedeflerin tepeden tırnağa “kaskat” şeklinde indirilmesi, organizasyonel hiyerarşiyi dondurur ve esnekliği yok eder.
• Stratejik Boşluk: Çoğu zaman OKR’ler, gerçek bir stratejik seçimden ziyade sadece “yapmak istediğimiz şeylerin listesi” haline gelir.
• Bant Genişliği Sorunu: Çok fazla OKR belirlenmesi, odaklanmayı artırmak yerine kaynakların dağılmasına ve stagnasyona yol açar.
• Psikolojik Güvenlik Eksikliği: Hedeflere ulaşamama korkusu, ekiplerin “güvenli” ve sönük hedefler belirlemesine (sandbagging) neden olur.

Bazı uzmanlar, OKR’lerin yerine süreç odaklı olan SLO (Service Level Objectives) ve SLI (Service Level Indicators) kullanımını önermektedir. Bu yaklaşım, çıktıyı değil, sistemin sağlığını ölçtüğü için Deming’in felsefesine daha yakındır.

“Management by Means” (MBM): Toyota Yolu ve Deming’in Zaferi

Drucker’ın MBO felsefesi Batı’da hüküm sürerken, Toyota gibi şirketler Deming’in ilkelerini “Management by Means” (Yöntemlerle Yönetim — MBM) adı altında kurumsallaştırmıştır.

Bu iki yaklaşım arasındaki fark, gece ile gündüz kadardır:

Management by Results (MBR/Drucker):

• Öncelik: Finansal hedefler ve kotalar.
• Yöntem: Sayıları zorlamak (Manipülasyon riski).
• İnsan Rolü: Hedefe ulaşmak için kullanılan bir araç.

Management by Means (MBM/Deming/Toyota):

• Öncelik: Süreç istikrarı ve çalışan gelişimi.
• Yöntem: Sistemin kapasitesini sürekli iyileştirmek.
• İnsan Rolü: Sistemi iyileştiren aktif bir problem çözücü.

Toyota, hedeflerini belirlerken “Gemba”da (işin yapıldığı yer) vakit geçiren ve sistemin gerçek kapasitesini bilen liderleri sürece dahil eder. Bu, Drucker’ın merkeziyetçi hedef koyma modeline kıyasla çok daha yavaş ancak çok daha dirençli bir yapı inşa eder.

Neden Hâlâ Drucker’ı Seçiyoruz?

Deming’in yöntemlerinin daha başarılı sonuçlar verdiği (Toyota ve Scania örneklerinde olduğu gibi) açıkken, neden modern yöneticiler hâlâ Drucker’cı yöntemlere sadık kalmaktadır?

Cevap sadece psikolojik değil, aynı zamanda nörolojik ve kurumsal faktörlerde gizlidir.

1. Nöral Yollar ve Alışkanlıklar

Sınıf temelli yönetim eğitimi, beynin belirli bölüllerini (kodlanmış ve açık bilgi) çalıştırır. Deming’in önerdiği “Toyota Kata” gibi yöntemler ise pratik ve sürekli uygulama gerektiren yeni nöral yollar inşa etmeyi gerektirir. Bu da biyolojik olarak zahmetli bir süreçtir.

2. Sorumluluğun Devri

Yöneticiler, sayısal hedefler koyarak başarısızlığın sorumluluğunu çalışanlara devredebilirler (“Hedefi tutturamadılar”). Deming’in sisteminde ise başarısızlık %94 oranında yöneticinin sorumluluğundadır çünkü sistemi o tasarlamıştır. Bu sorumluluk duygusu, çoğu yönetici için dayanılmaz bir strese neden olur.

3. Kısa Vadeli Beklentiler

Finans piyasaları ve hissedarlar, üç aylık (quarterly) sonuçlar bekler. Deming’in sistemik iyileştirmesi ise zaman alır. “Kolay olan”, bir sonraki toplantıya kadar sayıları “parlatmak” iken; “doğru olan”, sistemin temelini yeniden inşa etmektir.

Sonuç: Kolay Olanın Doğru Olanı Yenmesi Bir Kader mi?

W. Edwards Deming’in “sürgünde” kalması ve Peter Drucker’ın hakimiyeti, yönetim biliminin bir zaferi değil, insan doğasının karmaşıklıktan kaçma ve kısa vadeli konforu arama eğiliminin bir sonucudur.

Drucker, yöneticilere bir “termostat” ve bir “kontrol paneli” sunarak onlara modern dünyanın karmaşasında bir güvenlik hissi vermiştir. Deming ise onlara bir “laboratuvar” ve “bitmek bilmeyen bir sorumluluk” teklif etmiştir.

Ancak Wells Fargo skandalı ve benzeri kurumsal facialar göstermektedir ki, “kolay olanın” maliyeti uzun vadede “doğru olanın” zorluğundan çok daha yüksektir. Geleceğin organizasyonları, Drucker’ın sağladığı “odaklanma” ve “hizalanma” yeteneklerini, Deming’in “sistem bilinci” ve “değişkenlik bilgisi” ile harmanlamak zorundadır.

Aksi takdirde, sadece hedeflere ulaşan ama bu süreçte ruhunu ve dayanıklılığını kaybeden “mekanik” yapılar olarak kalmaya mahkum olacaklardır.

“Doğru olan yöntem” zor olsa da, organizasyonun hayatta kalması için tek gerçek yoldur; çünkü Deming’in de dediği gibi:

“Değişmek zorunda değilsiniz, hayatta kalmak zorunlu değildir.”

Kısaca Özet (TL;DR)

• İki Farklı Dünya: Drucker “sonuçlara”, Deming “sisteme” odaklanır. Drucker kolay ve konforludur, Deming zor ama sürdürülebilirdir.
• Termostat Yanılsaması: Yöneticiler, hedefleri sürekli kurcalayarak (termostat gibi) kontrol ettiklerini sanırlar, ancak bu genellikle sistemi daha da bozar (Huni Deneyi).
• Bilişsel Konfor: OKR ve MBO sistemleri, yöneticinin karmaşıklığı basit metriklerle filtreleyip “kontrol yanılsaması” yaşamasını sağladığı için tercih edilir.
• Sistemsel Patoloji: Wells Fargo örneğinde görüldüğü gibi, süreçten bağımsız hedefler (MBO/OKR), çalışanları sistemi manipüle etmeye ve etik dışı davranışlara iter.
• Gelecek: Drucker’ın odaklanma yeteneği ile Deming’in sistem bilincinin birleşimi gereklidir. Kolay yolu seçmek, uzun vadede şirketin ruhunu öldürür.

Peki ya siz?

Çalıştığınız veya yönettiğiniz organizasyonda “hedef takıntısı” yüzünden sistemsel sorunlar görüyor musunuz? Sizce bir yönetici, kısa vadeli “parlak sonuçlar” yerine uzun vadeli “sistem sağlığı”nı seçebilir mi?

Düşüncelerinizi yorumlarda belirtin, bu önemli tartışmayı büyütelim.

#YönetimBilimi

#DruckerVsDeming

#SistemDüşüncesi

Modern Yönetimin Büyük Yanılsaması: Neden “Kolay” Her Zaman Kazanır? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kaide, modern React uygulamaları için geliştirilmiş, yapay zekâ (AI) odaklı bir mimari kitidir. Özellikle Cursor gibi yapay zekâ destekli editörler ve LLM’ler ile çalışırken, modelin proje bağlamını kaybetmesini önlemek, halüsinasyonları azaltmak ve yüksek disiplinli bir kod yapısı oluşturmak amacıyla tasarlanmıştır.

İsmin Hikayesi

Projelerimde genellikle tek kelimelik, Türkçe ve projenin amacını doğrudan çağrıştıran isimler seçmeye dikkat ediyorum. Tıpkı Nizam projemde olduğu gibi, bu mimari kit için de anlamlı bir isim arayışındaydım.

“Kaide” kelimesi; kural, temel ve esas anlamına geldiği için projenin vaadiyle birebir örtüşüyordu. Ancak asıl karar vermemi sağlayan detay, kelimenin tam ortasında gizli olan “ai” (kaide) vurgusuydu. Hem yapay zekâ odaklı bir temel sunması hem de npm’de bu ismin henüz alınmamış olması, onu bu proje için en doğru tercih haline getirdi.

Yapay Zekâ Mimari Kurallara İhtiyaç Duyar?

Yapay zekâ ile kod yazarken karşılaşılan en büyük sorunlardan biri, doğru bağlamın ve kısıtlamaların sağlanamamasıdır. Çoğu geliştirici, prompt girerken modele bir persona atamayı, neyi yapması gerektiğinin yanı sıra neleri yapmaması gerektiğini belirtmeyi atlar. Oysa kaliteli bir çıktı alabilmek için bu detaylar kritiktir. Eksik yönergelerle çalışan yapay zekâ, boşlukları kendi yorumlarıyla doldurmaya çalışır; bu da genellikle halüsinasyonlara, proje standartlarına uymayan kodlara veya istenenin çok dışında sonuçlara yol açar.

Kaide, tam bu noktada devreye girerek sizi uzun ve karmaşık prompt yazma yükünden kurtarır. Projenize entegre edildiğinde; persona, mimari kurallar, kod standartları ve yasaklar zaten tanımlı haldedir.

Doğru Prompt Stratejisi

Kaide ile çalışırken en sık yapılan hata, yapay zekaya “nasıl” kod yazması gerektiğini (kütüphane seçimleri, dosya yapısı, test kuralları vb.) dikte etmektir; oysa Kaide’nin temel amacı bu teknik yükü sizin omuzlarınızdan almaktır. Doğru bir prompt stratejisinde, halihazırda AGENTS.md içerisinde tanımlı olan "Staff Architect" personasına veya .mdc dosyalarında mühürlenmiş mimari yasalara atıf yapmanıza gerek yoktur; çünkü bu kurallar yapay zekanın işlem çekirdeğine zaten entegre edilmiştir. Yapmanız gereken tek şey, teknik detaylarda boğulmadan doğrudan "ne yapılacağına" odaklanmak ve görevi tanımlamaktır.

Örneğin; “Bana Next.js 16 ile Zod doğrulamalı, shadcn bileşenleri kullanan, features yapısına uygun, server action’lı ve Vitest testleri yazılmış bir kullanıcı kayıt formu yap”. Bu kadar teknik detayı tek tek hatırlatmak, yapay zekâyı basit bir “bot” seviyesine indirger. Oysa siz teknik detayları bırakıp sadece iş hedefine odaklanmalısınız.

Bunun yerine sadece; “Kullanıcı listesini görüntülemek için bir Users sayfası oluştur. Veriler /api/users endpoint'inden çekilecek ve bir tablo içerisinde gösterilecek." komutunu vermek, tüm çarkları doğru sırayla hareket ettirir. Bu süreçte siz sadece vizyonu sunarsınız, yapay zekâ ise anayasadaki kuralları uygulayarak bu vizyonu teknik bir gerçeğe dönüştürür.

Teknoloji Yığını

Kaide, modern web geliştirme standartlarını benimser:

• Framework: Next.js ya da TanStack Start
• Server State: TanStack Query
• Client State: Zustand
• Validasyon: Zod
• Test: Vitest + RTL
• Stil: Tailwind CSS

Kurulum

Kaide’yi kullanmaya başlamak oldukça basittir. CLI aracı sayesinde saniyeler içinde projenize entegre edebilirsiniz:

npx kaide init

Bu komut, gerekli konfigürasyon dosyalarını ve kuralları projenize otomatik olarak ekler.

Sonuç

Kaide, yapay zekâyı basit bir kod üreteci olmaktan çıkarıp, projenizin kurallarını bilen ve uygulayan yetkin bir ekip arkadaşına dönüştürmeyi hedefler. Eğer siz de yapay zekâ ile kod yazarken kontrolü elden bırakmak istemiyor ve mimari bütünlüğü korumak istiyorsanız, Kaide’ye bir şans verin.

⭐ GitHub: github.com/omergulcicek/kaide

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/kaide-yapay-zeka-odakli-mimari-kit/
X (Twitter): @omergulcicek

Makaleyi alkışlayarak destek olabilirsiniz 🌹

Kaide: Yapay Zekâ Odaklı Mimari Kit was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Problem Senaryosu: Sayfa Patladı, Konsol Kıpkırmızı

Supabase kullanarak geliştirdiğim sayfada bir anda her şey bozuldu. Sayfa yüklenirken konsolda şu hata belirdi:

[vite]: Rollup failed to resolve import "tanstack-start-injected-head-scripts:v"
from ".../node_modules/@tanstack/start-server-core/dist/esm/loadVirtualModule.js"

Bazen Pre-transform error olarak da görünüyordu: Failed to resolve import "tanstack-start-injected-head-scripts:v". Geliştirme ortamında bazen sessiz kalıyor, vite build ile production build alırken kesin şekilde patlıyordu. Hata mesajı, @tanstack/start-server-core içindeki sanal modül çözümlemesiyle ilgiliydi ve ilk bakışta framework veya Vite/Rollup tarafında bir bug gibi görünüyordu.

AI ile Çatışma: Halının Altına Süpürmek

Sorunu çözmek için AI asistanlarına (ChatGPT, Gemini ve Cursor) danıştım. Öneriler genelde şu yöndeydi:

• Hata mesajını gizle: build.rollupOptions.external veya Vite config içinde bu import'u external yap, uyarıyı kapat.
• Hydration / script hatalarını yok say: “Bu tür hatalar bazen olur, suppress edebilirsin” tarzı yorumlar.

Bu “çözümler” sorunu çözmek yerine halının altına süpürmekti. Bir kez external / suppress yoluna girdiğimde site inanılmaz yavaşladı ve davranışlar tutarsız hale geldi. Demek ki sorun, mesajı gizlemekle değil, kök nedeni bulmakla çözülecekti.

Bu deneyim şunu netleştirdi: Dokümantasyonu okumak ve elle debug yapmak, AI’ın hazır cevaplarından çoğu zaman daha üstün. AI hızlı bir başlangıç noktası sunabilir ama kök neden analizi ve mimari kararlar için yetersiz kalabiliyor.

Sorunun Asıl Kaynağı: Yanlış Context, Yanlış Instance

Bu hata mesajı bazen farklı sebeplerden de çıkabilir; burada anlattığım çözüm, Supabase (veya benzeri bir client) ile server/client sınırının karıştığı senaryoya özgü.

Hata mesajı “injected head scripts” ve “virtual module” diye görünse de, asıl problem framework değildi. Problem, Supabase (veya Clerk vb) client’ı ile sunucu tarafı (server-side) bir sayfada aynı fonksiyonun veya client örneğinin (instance) yanlış context içinde kullanılmasıydı.

Yani:

• Server tarafında çalışması gereken bir şey (veritabanı, Supabase admin/client) client bundle’ına karışıyor veya client’tan doğrudan çağrılıyordu.
• Ya da tam tersi: client-only bir instance, sunucu render path’inde kullanılıyordu.

Bu karışıklık, TanStack Start’un sanal modül ve script enjeksiyonu mekanizmasını tetikliyor; Rollup/Vite da “tanstack-start-injected-head-scripts:v” modülünü beklenen yerde bulamayınca build kırılıyordu. Yani semptom “injected head scripts”, kök neden ise server/client ayrımının ihlali idi.

Hatalı Kullanım

Aynı Supabase client örneğini veya veritabanı çağrılarını hem sunucu hem istemci tarafında kullanmak:

// ❌ Hatalı: Client ve server'da aynı instance / aynı fonksiyon
// Bu dosya client bundle'a da giriyor, server context'i karışıyor
import { createClient } from "@supabase/supabase-js";
 
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);
 
export async function getGameData(id: string) {
  const { data } = await supabase.from("games").select("*").eq("id", id).single();
  return data;
}

Bu fonksiyon veya client, client tarafında da import edilip kullanılıyorsa (örneğin bir sayfa bileşeninde veya loader’da yanlış yerde), TanStack Start’un server/client ayrımı bozuluyor ve “injected head scripts” benzeri çözümleme hataları ortaya çıkabiliyor.

Gerçek Çözüm: Server/Client Arayüzünü Net Ayır

Client tarafında, sunucu fonksiyonlarını veya veritabanı client’ını doğrudan import edip çağırmayın. Bunun yerine:

1. API / veritabanı işlemlerini yalnızca server-side bir dosyada tanımlayın (örneğin createServerFn veya sadece sunucuda çalışan modüller).
2. Client tarafına sadece temiz bir arayüz sunun: örneğin server fonksiyonlarını import edip kullanın; Supabase client’ı sadece sunucu kodunda oluşturulup kullanılsın.

Böylece client bundle’a server-only kod ve Supabase instance’ı karışmaz; TanStack Start’un sanal modülleri de doğru context’te çözülür.

Doğru Kullanım

// ✅ Doğru: Sadece server tarafında çalışan modül
// Örn: app/utils/db.server.ts veya server-only bir modül
import { createClient } from "@supabase/supabase-js";
 
function getSupabaseServer() {
  return createClient(
    process.env.SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  );
}
 
export async function getGameData(id: string) {
  const supabase = getSupabaseServer();
  const { data } = await supabase.from("games").select("*").eq("id", id).single();
  return data;
}

// ✅ Doğru: Client tarafı sadece server fonksiyonunu çağırır
// createServerFn ile sarılı bir arayüz kullanın
import { createServerFn } from "@tanstack/start";
import { getGameData } from "./db.server";
 
export const fetchGameData = createServerFn().handler(async ({ data: { id } }) => {
  return getGameData(id);
});

Client bileşenleri yalnızca fetchGameData gibi server fn'leri çağırır; Supabase client'ı ve getGameData implementasyonu yalnızca sunucuda çalışır. Bu ayrım hem tanstack-start-injected-head-scripts hatasını çözer hem de güvenlik ve performans açısından doğru mimariyi kurar.

Topluluk Etkisi

Bu analiz ve çözümü GitHub’daki ilgili issue (#5196) altında yorum olarak paylaştım. Aynı hatayı yaşayan birçok geliştirici beğeni bıraktı. Bu da gösteriyor ki sorun sadece “config’de bir satır” değil; server/client sınırını doğru kurmak birçok TanStack Start + Supabase (veya benzeri backend) projesi için kritik.

Özetle: TanStack Start ile çalışırken “tanstack-start-injected-head-scripts” benzeri hatalar gördüğünüzde, önce server ve client tarafında hangi instance’ın nerede kullanıldığını kontrol edin. Supabase (veya başka bir client) yalnızca sunucu tarafında kullanılmalı, client’a sadece server fonksiyonları üzerinden temiz bir arayüz sunulmalı. Bu hem hatayı çözer hem de mimarinizi sağlamlaştırır.

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/tanstack-start-injected-head-scripts-hatasi-cozumu/
Instagram: @omerilekesfet

Makaleyi alkışlayarak destek olabilirsiniz 🌹

TanStack Start: tanstack-start-injected-head-scripts Hatası ve Çözümü was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yapay zekâ, kod yazma şeklimizi değiştirdi ve sessizce bir kazanan seçti. 2025 Stack Overflow Developer Survey’e göre, profesyonel geliştiricilerin %51'i artık AI araçlarını günlük olarak kullanıyor. AI’dan bir UI oluşturmasını istediğinizde, neredeyse her zaman React’e yöneliyor. Bunun sebebi milyonlarca GitHub deposunda eğitilen LLM’ler için React bu veri setinde baskın durumda.

Çekirdek: React + TypeScript

TypeScript, JavaScript’e tip güvenliği ekleyerek hataları çalışmadan önce yakalamanı, refactoring’i kolaylaştırmanı ve büyük kod tabanlarını daha güvenle yönetmeni sağlar. Tipler aynı zamanda AI asistanlarına da net bir yol haritası sunar.

Framework: Next.js veya TanStack Start

İhtiyacınıza göre iki sağlam seçenek var.

Next.js olgun ve yaygın seçenek. En geniş ekosisteme sahip, tam React Server Components desteği sunuyor ve Vercel tarafında partial pre-rendering gibi özelliklerle gelişmeye devam ediyor. RSC, streaming ve savaşta test edilmiş bir framework arıyorsanız, Next.js doğru adres.

TanStack Start ise daha az sihir, daha fazla kontrol vaat ediyor. Verinin nasıl yükleneceği, nerede çalışacağı ve neyin render edileceği sizin elinizde. Tip güvenliği çok güçlü ve TanStack ekosisteminin geri kalanıyla (Query, Router, Table, Form vb.) kusursuz uyumlu.

2025'in sonlarından itibaren ben de kişisel tercihimi Next.js yerine TanStack Start’tan yana kullandım ve ilk günden beri memnunum. Next.js’in bol kod örneği ve ekosistemi sayesinde AI araçları onu daha iyi “anlıyor”; TanStack tarafında bu konuda bazen zayıf kaldığını hissettiğim oldu. Dokümantasyonun da biraz daha olgunlaşması gerektiğini düşünüyorum. Buna rağmen DX (developer experience) açısından esnekliği ve sunduğu özellikler beni cezbediyor. Performanstan da oldukça memnunum; kişisel projelerimde TanStack Start’ı ilk tercih olarak kullanmaya devam etmeyi planlıyorum. Tüm TanStack ekosistemini birlikte kullanmak (Start, Query, Router, Table, Form vb.) bana Apple ekosistemini (MacBook, iPhone, Watch hepsi birbirine entegre ve tek dil konuşuyor) kullanmak gibi hissettiriyor.

Stil: Tailwind CSS

Tailwind CSS utility-first CSS tartışmasını kazandı. AI araçları Tailwind sınıflarını rahatça üretebiliyor, ölçeklenmesi iyi ve projelerde gereksiz CSS şişkinliğini azaltıyor.

İlk çıktığında Tailwind’e mesafeliydim, adeta inline CSS yazıyormuşum gibi geliyordu. Zamanla vazgeçilmezim oldu ve bir anlamda Bootstrap’ın tahtını aldı. Artık yeni bir proje kurduğumda boilerplate’e Tailwind eklemek ilk yaptığım işlerden biri.

UI Bileşenleri: shadcn/ui

shadcn/ui bileşenleri paket olarak değil, doğrudan projenize kopyalıyor, yani koda tam sahipsiniz ve istediğiniz gibi değiştirebiliyorsunuz. Arada soyutlama katmanı olmadığı için AI araçları da bu dosyaları okuyup düzenleyebiliyor. Yeni npx shadcn create akışıyla özelleştirme bir adım öteye taşındı. Yakın zamanda ise Radix UI olan bileşent tabanına Base UI desteği de eklendi.

shadcn/ui’nin gelişimi beni heyecanlandırıyor; yeni özellikler ve iyileştirmeler için merakla takip ediyorum.

Veri Çekme: TanStack Query

TanStack Query sunucu state için de facto standart. Cache, arka plan refetch, stale ve error state’leri tek yerde topluyor; zihinsel model oturduktan sonra senkronizasyon kaynaklı hataları büyük ölçüde eliyor. React ile veri çekiyorsanız ilk bakmanız gereken yer burası.

Routing: TanStack Router

TanStack Router rotalar, params ve search params için gördüğüm en güçlü tip güvenliğini sunuyor; hatalar runtime’a düşmeden TypeScript tarafında yakalanıyor. Next.js kullanıyorsanız App Router yeterli ve RSC ile uyumlu. Vite tabanlı veya TanStack Start stack’inde ise TanStack Router net seçim.

Durum Yönetimi: Zustand

Zustand minimal boilerplate ile hook tabanlı, Redux karmaşası olmadan client state yönetimi sunuyor; basit başlıyor, ihtiyaç arttıkça ölçekleniyor.

Formlar: React Hook Form

React Hook Form Zod vb. doğrulama kütüphaneleriyle sorunsuz entegre ve temiz bir API ile form state’ini yönetmek için hâlâ en sağlam seçeneklerden biri.

Yıllardır React Hook Form kullanıyorum ve memnunum. Kişisel projelerimde TanStack ekosisteminde olduğum için TanStack Form’a geçtim; her iki kütüphane de AI araçlarıyla çok uyumlu çalışıyor.

Test: Vitest + React Testing Library + Playwright

Vitest ES modules ile sorunsuz çalışan, Vite pipeline ile uyumlu ve hızlı bir test runner; birim ve entegrasyon testleri için günlük kullanımda rahat. React Testing Library bileşenleri kullanıcı davranışına göre sorgulamanızı sağlayarak testleri sürdürülebilir kılıyor ve erişilebilirlik problemlerini yan ürün olarak ortaya çıkarıyor. Playwright ise çoklu tarayıcı, görsel ve mobil emülasyon desteğiyle E2E katmanını kararlı ve tekrarlanabilir şekilde kapatıyor.

AI SDK: Vercel AI SDK veya TanStack AI

Vercel AI SDK streaming, tool calling ve chat UI için hazır hook’lar sunuyor; OpenAI, Anthropic ve diğer sağlayıcılarla out-of-the-box çalışıyor. AI Elements ile mesaj thread’leri, reasoning panelleri ve ses arayüzleri için shadcn/ui tabanlı 20+ bileşen geliyor, LLM destekli ürünlerde hızlı prototipleme ve production UI için ciddi zaman kazandırıyor.

TanStack AI daha yeni; sağlayıcıdan bağımsız tek arayüz ve tam TypeScript tip güvenliği vaat ediyor. TanStack ekosistemine geçiş yaptım fakat TanStack AI’ı henüz deneyimleyemedim. TanStack ekibinin Query ve Router’daki siciline bakınca, zamanla bu alanda da referans olma ihtimali yüksek.

Tip Güvenli API’ler: tRPC

tRPC, frontend’inizin sunucu fonksiyonlarını tam TypeScript tip güvenliğiyle doğrudan çağırmasına izin verir. Dokümante edilecek REST endpoint’leri yok. Manuel olarak senkronize edilecek tipler yok. Mantığınızı bir kez tanımlarsınız ve her iki tarafta da kullanırsınız. Tam stack TypeScript uygulaması oluşturuyorsanız, tRPC bir kategori hatayı ortadan kaldırır ve geliştirmeyi hızlandırır.

Doğrulama: Zod

Zod, TypeScript doğrulaması için güvenli seçim. En büyük ekosisteme, en çok öğreticiye sahip ve her şeyle entegre oluyor. React Hook Form, TanStack Form, tRPC, API route’ları. Zod hepsiyle çalışır. Bundle boyutu kritikse daha hafif alternatifler var, ancak çoğu proje için Zod’un ekosistem avantajı ekstra kilobaytları ağır basar.

Backend Servisleri: Supabase veya Convex

Supabase PostgreSQL üzerine inşa edilmiştir. Auth, storage, gerçek zamanlı abonelikler ve otomatik oluşturulmuş API’ler elde edersiniz. AI özellikleri için, pgvector vektör benzerlik aramasını halleder ve ilişkisel verilerinizin yanında embedding’leri saklayabilirsiniz.

Kişisel oyun projemde ilk kez Supabase kullandım ve çok memnun kaldım. Arayüzü ve performansı beni tatmin etti; kişisel projelerimde kullanmaya devam edeceğim. Backend derdimi büyük ölçüde ortadan kaldırdı, özellikle Auth katmanının hazır gelmesi büyük dertten kurtarıyor ve doğrudan SQL ile frontend’e odaklanmamı sağlıyor.

Convex, reaktivite-öncelikli bir yaklaşım benimser. Sorgular, veriler değiştiğinde otomatik olarak React bileşenlerinize senkronize olur. TypeScript entegrasyonu yerel gibi hissettirir. Yerleşik vektör araması, bir RAG bileşeni ve AI agent iş akışları, LLM destekli uygulamalar için zaten orada.

Animasyon: Motion

Motion (eski adıyla Framer Motion) declarative API ile karmaşık ve layout animasyonlarını yönetir; CSS geçişleri yeterli gelmediğinde React tarafında ilk bakılacak kütüphane.

Tablo: TanStack Table

TanStack Table headless ve tam tip güvenli; sıralama, filtreleme ve sayfalama mantığını sağlar, UI kararlarını size bırakır. Veri ağırlıklı ekranlarda kendi markup ve stillerinizle kullanılacak standart seçenek.

Bileşen Geliştirme: Storybook

Storybook bileşenleri izole geliştirme, görsel test ve otomatik dokümantasyon için kullanılır; geliştirici ve tasarımcıların uygulamayı ayağa kaldırmadan UI üzerinde çalışmasını sağlar.

AI Destekli Geliştirme

Claude Code, Anthropic’in agentic kodlama aracıdır. Terminalde, VS Code’da bir uzantı olarak veya doğrudan web’de çalışır. Codebase’inize işaret edin ve değişiklikleri planlayabilir, kod yazabilir, testleri çalıştırabilir ve saatlerce görevler üzerinde döngü yapabilir. Yalnız çalışmayı veya yalnızca geliştirici ekiplerinde çalışmayı tercih ediyorsanız, bu harika bir seçenektir.

Cursor, geleneksel IDE iş akışını tercih ediyorsanız başka bir harika seçenektir.

MCP (Model Context Protocol) ile AI asistanları harici veri kaynaklarına, API’lere ve araçlara güvenli şekilde bağlanabiliyor. Frontend geliştirmede ben Figma, Context7, Next.js, shadcn ve Supabase MCP’lerini kullanıyorum; tasarım token’ları, dokümantasyon ve backend kaynaklarına doğrudan erişim sağlıyor.

VS Code kullanırken Cursor’a geçtim ve bir yılı aşkındır kullanıyorum. Son dönemde aşırı token tüketimi ve sürekli değişen -bazılarına alışmakta zorlandığım- UI güncellemeleri can sıkmaya başladı. Yakın vadede farklı bir arayüze veya araca yönelebilirim.

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/react-ai-stack-2026/
Instagram: @omerilekesfet

Makaleyi alkışlayarak destek olabilirsiniz 🌹

2026 için React ve AI Stack’i was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

corner-shape: Köşeleri Şekillendirme

CSS’in yeni corner-shape özelliği, border-radius ile birlikte kullanılarak köşeleri farklı şekillerde şekillendirmemize olanak tanıyor. Bu özellik sayesinde artık sadece alıştığımız rounded (yuvarlatılmış köşeler) değil, bevel (kesik köşeler), scoop (içe çekilmiş köşeler), notch (çentikli köşeler) ve squircle gibi modern köşe şekilleri oluşturabiliyoruz.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

clip-path: Görsel Kırpma

CSS’in clip-path özelliği, bir elementin hangi bölümünün görünür olacağını belirleyen bir kırpma bölgesi oluşturur. Bu özellik sayesinde elementleri çeşitli geometrik şekillerle kırpabilir, modern ve yaratıcı tasarımlar oluşturabiliriz.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

::picker-icon: Dropdown İkonunu Özelleştirme

CSS’in yeni ::picker-icon pseudo-element'i, özelleştirilebilir <select> elementlerinin dropdown ikonunu stillendirmemize olanak tanıyor. Bu özellik sayesinde varsayılan üçgen ikon yerine checkmark, plus, arrow veya herhangi bir özel ikon kullanabiliyoruz.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

::picker-icon özelliği kullanmak için <select> elementinin appearance: base-select olarak ayarlanması gerekiyor. Bu özellik ile birlikte, özelleştirilebilir select elementleri için birçok yeni CSS seçicisine de erişebiliyoruz:

• select:open - Dropdown açık olduğunda select elementini stillendirme
• select:open::picker-icon - Dropdown açık olduğunda picker icon'unu stillendirme (örneğin rotasyon animasyonu için)
• option:checked - Seçili option elementini stillendirme
• option::checkmark - Option'lardaki checkmark ikonunu özelleştirme

width/height: stretch: Taşmayı Önleme

CSS’in yeni stretch değeri, width ve height özelliklerinde kullanılarak elementlerin padding ve margin'i hesaba katarak taşmasını önler. 100% değeri, padding ve margin'i hesaba katmadığı için taşmaya neden olabilir, ancak stretch değeri bu sorunu çözer.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

text-box: Metin Hizalaması

CSS’in yeni text-box özelliği, metin elementlerinin block-start ve block-end kenarlarındaki fazla boşluğu (leading) kırparak, görsellerle metinlerin daha iyi hizalanmasını sağlar. Bu özellik özellikle görsel ve metin yan yana olduğunda, line-height'tan kaynaklanan boşlukların neden olduğu hizalama sorunlarını çözer.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

sibling-index(): Sıralı Animasyonlar

CSS’in yeni sibling-index() fonksiyonu, her elementin kardeş elementler arasındaki pozisyonunu döndürür (1'den başlar). Bu fonksiyon sayesinde JavaScript veya Framer Motion gibi kütüphaneler olmadan, sadece CSS ile sıralı animasyonlar oluşturabilirsiniz.

İnteraktif olarak test etmek için kişisel sitem üzerinden önizleyebilirsiniz.

sibling-index() fonksiyonu özellikle animation-delay ile birlikte kullanıldığında güçlü bir kombinasyon oluşturur. calc(sibling-index() * 100ms) gibi bir değerle, her element sırayla animasyonlu şekilde görünebilir. Bu sayede kart listeleri, grid layout'lar ve diğer sıralı UI elementleri için JavaScript'e ihtiyaç duymadan animasyonlar oluşturabilirsiniz.

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/2026da-hayatimiza-girecek-yeni-css-ozellikleri/
Instagram: @omerilekesfet

Makaleyi alkışlayarak destek olabilirsiniz 🌹

2026'da Hayatımıza Girecek Yeni CSS Özellikleri was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Geçmişten Günümüze Frontend Rolü

Geçmişte Frontend; HTML, CSS ve temel JavaScript ile sayfa düzenlemekten ibaretti. Statik yapılar, sınırlı etkileşimler ve küçük ekiplerle yürüyen işler, geliştiriciye mimari veya sistemsel sorumluluk pek yüklemezdi. Bugün ise tablo tamamen farklı: performans optimizasyonu, UX kurgusu, güvenlik, API cache stratejileri, server–client hibrit mimariler, ölçeklenebilir React yapıları ve çok katmanlı veri yönetimi gibi konular işin merkezinde. Frontend artık sadece ekran oluşturan bir rol değil; ürünün davranışını tasarlayan, kullanıcı deneyiminin tamamını yöneten bir teknik mimari alanı.

AI ve Otomasyon: Rakip Değil Performans Hızlandırıcısı

AI’nın yükselişi özellikle tekrarlayan işleri otomatikleştirdi. Formlar, basit component’ler, CSS düzenlemeleri artık saniyeler içinde üretilebiliyor. Bu durum geliştiriciyi değersizleştirmek yerine ona zaman kazandırıyor: daha iyi testler yazmak, edge-case senaryolarını düşünmek, performansı artırmak veya yeni özellikleri denemek için alan açıyor. Basit işler otomatikleşiyor, ancak değer üreten işlerin önemi katlanıyor.

Prompt Odaklı Frontend Geliştirici

Burada belirleyici olan şey, yapay zekayı nasıl kullandığın. Bazıları karşısında bir insan varmış gibi basit bir cümle kurarken, bazıları bir makineyle konuştuğunun bilincinde olup teknik, tutarlı ve bağlama uygun komutlar veriyor. Bu fark, çıktının kalitesini de geliştiricinin seviyesini de açık şekilde ortaya koyuyor. Aşağıdaki JSON prompt örneği, modern bir login sayfasının AI’a nasıl talep edilmesi gerektiğine dair daha kapsamlı ve hataya kapalı bir iskelet sağlıyor:

{
  "task": "Create an enterprise-grade, production-ready login page.",
  "stack": "Next.js 16 App Router, React 19, TypeScript, shadcn/ui, React Hook Form + Zod, Edge compatible",
  "features": [
    "email + password fields with shared Zod schema (client + server)",
    "disabled + loading state on submit, Enter key submit",
    "show backend error messages as toast + field-level errors",
    "password show/hide toggle"
  ],
  "ux": "Fully accessible, mobile-first, clear and concise error/success messages.",
  "structure": "Feature-based architecture.",
  "output": "Single TSX code block, all imports included, minimal comments.",
  "constraints": "No inline styles, no any, follow TypeScript best practices."
}

Bu ayrım, gelecekteki rol tanımlarını da değiştirecek. Dün “junior–mid–senior frontend” ayrımı varken, yarın “Prompt-Oriented Frontend Developer (Entry/Advanced)” veya “Frontend Prompt Engineer” gibi roller görmemiz şaşırtıcı olmayacak. Çünkü artık farkı yaratan, kodu yazmak değil; kodu yapay zekaya nasıl yazdıracağını bilmek olacak.

Liderlik, Stres Yönetimi ve İnsan Faktörü

Elbette teknik dönüşüm tek boyutlu değil. Yapay zeka tekrarlayan işleri çözse de sektörde “stres yönetimi” diye bir gerçek var. Eskiden junior’ların üzerinde senior’lar, onların üzerinde mimari kararları veren lead’ler olurdu. Yeni dönemde ise AI ile çalışan geliştiricilerin üzerinde, AI’yı daha iyi kullanan, doğru prompt stratejilerini belirleyen, mimaride son sözü söyleyen ve deadline baskısını yöneten güçlü liderlere ihtiyaç duyulacak. İnsan faktörü, organizasyonel yük ve psikolojik dayanıklılık hâlâ geliştirici rolünün en kritik parçaları.

Şirketler Açısından Yeni Denge

Şirketler açısından da benzer bir tablo var: Daha az kişiyle daha fazla ürün çıkarabilecekler, bütçenin bir kısmı çalışan yerine yapay zeka araçlarına kayacak. Ancak bu, nitelikli geliştirici ihtiyacını azaltmıyor. Aksine, artık sadece UI çizmek veya CSS bug çözmek gibi günü kurtaran işler devrin sonuna geldi. Beklenti; yapay zekayı aktif şekilde kullanarak daha hızlı, daha temiz ve daha mükemmel kod üretmek.

Veri Ne Diyor? AI İş İlanları ve Yeni Roller

AI’nın yazılımı “bitirmediğini” görmek için rakamlara bakmak yeterli. OpenAI’nin Eylül 2025 tarihli “Jobs in the Intelligence Age” raporunda, AI becerisi gerektiren ilanların hem sayısının hem de ücret primlerinin belirgin şekilde arttığı vurgulanıyor. Örneğin PwC’nin 2025 Global AI Jobs Barometer verisine atıfla, AI becerisi isteyen rollerin ortalama %56 ücret primi taşıdığı, buna karşılık toplam ilan sayısı düşerken AI becerili ilanların yıllık %7,5 artış gösterdiği belirtiliyor.

AWS ve Access Partnership tarafından hazırlanan “Accelerating AI Skills: Preparing the Workforce for Jobs of the Future” raporu da benzer bir tablo çiziyor: Rapora göre işverenlerin %73'ü AI becerisine sahip çalışanları işe almayı önceliklendiriyor. Aynı çalışma, AI becerisi kazanan çalışanlar için departmana göre değişmekle birlikte ortalama %35 ve üzeri maaş artışı beklendiğini, ayrıca işverenlerin büyük çoğunluğunun AI’nın önümüzdeki yıllarda iş gücü verimliliğini ciddi biçimde artıracağını düşündüğünü gösteriyor.

Benzer şekilde, çeşitli işveren araştırmalarında şirketlerin çok büyük bir çoğunluğunun önümüzdeki dönemde çalışanlarının AI yetkinliğine yatırım yapmak istediği, hatta bunun işletmenin geleceği için kritik görüldüğü aktarılıyor. Kısacası şirketler daha az ama çok daha yetkin, AI destekli geliştiricilerle ilerlemek istiyor.

Yani toplam pasta daralsa bile, AI ile çalışabilen geliştiriciler için hem talep hem de maaş seviyesi yükseliyor; bu da “iş bitti” yerine, “rol yeniden tanımlanıyor” sonucuna işaret ediyor.

Sonuç: Kabuk Değiştiren Bir Meslek

Sonuç olarak Frontend ölmedi; yalnızca kabuk değiştiriyor. Basit işler otomatikleşirken, uzmanlık gerektiren alanların değeri arttı. Kapsam genişledi, rol derinleşti ve gelişmeye devam ediyor. Bu dönüşümün merkezinde ise hâlâ kaliteli, vizyoner ve üretken geliştiriciler bulunuyor.

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/ai-caginda-frontend-bitti-mi/
Instagram: @omerilekesfet

Makaleyi alkışlayarak destek olabilirsiniz 🌹

AI Çağında Frontend Bitti mi? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mustafa Vahit Keskin hocamızın mükemmel anlatımıyla takip ettiğim Makine Öğrenmesi 201 dersinden aldığım notlarla hazırlanan bu yazı dizisinde, klasik regresyonun en büyük zorluğu olan aşırı öğrenme (overfitting) sorununu ele alıyoruz. Model katsayılarına “ceza” uygulayarak genellemeyi artıran ve istikrar sağlayan Düzenleme (Regularizasyon) Yöntemleri devreye girer. Bu yazıda, bu güçlü tekniklerin en önemlilerini; Ridge (L2), Lasso (L1) ve ikisinin hibriti olan ElasticNet regresyonlarını hem teorik temelleri hem de pratik kod uygulamaları üzerinden derinlemesine inceleyeceğiz. Kendisine, bu karmaşık konuları anlaşılır kıldığı için teşekkür ederim.

Ridge Regresyon : Cezalandırma Yöntemi

Bu modelin ana amacı, klasik En Küçük Kareler (EKK) yönteminin (Normal Regresyon) zayıf noktalarını gidermektir. Klasik EKK sadece hatayı en aza indirmeye odaklanırken, Ridge Regresyon bu hedefe bir ceza ekler.

1. Ridge Regresyonun Amacı (Yeni Hata Fonksiyonu)

Ridge Regresyon, normal hata karesi toplamına (SSE) yeni bir terim ekleyerek, katsayıları (beta) çok büyük seçen modelleri cezalandırır. Bu, modelin ezberleme (overfitting) yapmasını engeller.

• Tahmin Hatası (SSE): Modelin yaptığı yanlış tahminlerin karesel toplamıdır.
• Ceza Terimi: Bu kısım, tüm katsayıların beta karesini toplar. Katsayılar ne kadar büyükse, ceza o kadar artar. Büyük katsayılar = Aşırı Karmaşıklık.

Temel Amacı: Amaç, toplam hatayı minimum yapan katsayıları bulmaktır. Model hem doğru tahmin yapmaya çalışır hem de katsayıları küçük tutarak ceza almamayı hedefler.

2. Lambda Ayar Parametresi

Formülün en kritik kısmı Lambda’dır.

• Tanımı: lambda, cezanın şiddetini belirleyen bir hiperparametredir (kullanıcı tarafından belirlenir).
• Rolü: lambda ne kadar büyükse, ceza teriminin etkisi o kadar fazla olur ve model, katsayıları o kadar çok sıfıra yaklaştırmak zorunda kalır.
• Kontrol: lambda bu iki terimin (tahmin hatası ve ceza) birbirine göreceli etkilerini kontrol etmeyi sağlar.

3. Ridge Regresyonun Avantajları ve Güçlü Yönleri

Ridge Regresyon, normal OLS regresyonunun çözemediği sorunlara çözüm getirir:

• Aşırı Öğrenmeye Karşı Direnç: Katsayıları küçülttüğü için modelin genelleme yeteneği artar ve veriyi ezberlemez.
• Çoklu Bağlantı Çözümü: Bağımsız değişkenler birbiriyle çok ilişkili olduğunda bile (TV ve Radyo gibi), modelin katsayılarını istikrarsız hale getirmek yerine, onları kontrollü bir şekilde küçülterek daha güvenilir sonuçlar verir.
• İlgisiz Değişkenler: İşe yaramayan değişkenlerin katsayılarını modelden tamamen çıkarmaz, ancak sıfıra çok yaklaştırarak etkilerini neredeyse yok eder.

4. Lambda Değerini Belirleme Süreci

Lambda’yı doğru seçmek hayati önem taşır, çünkü modelin ne kadar cezalandırılacağına karar verir.

• Yöntem: lambda için rastgele bir değer seçilmez. Genellikle belirli bir lambda değer kümesi seçilir ve her bir değer için K-Katlı Çapraz Doğrulama (CV) testi yapılır.
• Seçim: Çapraz doğrulama testi sırasında en küçük test hatasını veren lambda değeri, modelin ayar parametresi olarak seçilir ve model bu nihai lambda ile tüm veriye tekrar eğitilir.

Ridge Regresyon Uygulaması: Lambda Optimizasyonu

Bölüm 1: Veri Hazırlığı ve Ön İşleme

Bu ilk aşama, regresyon için verinizi hazırlama, temizleme ve kategorik değişkenleri modele sokmak için dönüştürme adımlarını içerir.

1. import numpy as np: NumPy, sayısal ve matematiksel işlemler (karekök, ortalama, dizi işlemleri) için dahil edildi.
2. import pandas as pd: Pandas, verileri tablo (DataFrame) halinde okumak, temizlemek ve işlemek için dahil edildi.
3. from sklearn.linear_model import Ridge: Ridge Regresyon modelini kurmak için gerekli araç dahil edildi.
4. from sklearn.metrics import mean_squared_error, r2_score: Modelin başarısını ölçmek için hata metrikleri (MSE, R2) dahil edildi.
5. from sklearn.model_selection import train_test_split: Veriyi eğitim ve test kümelerine ayırmak için gerekli araç dahil edildi.
6. from sklearn.linear_model import RidgeCV: En iyi lambda (alpha) değerini otomatik bulmak için özel Ridge aracı dahil edildi.

Bu aşama, ham veriyi modelin anlayacağı formata dönüştürme sürecidir.

https://www.kaggle.com/datasets/serdargurler/hitterscsv

Kullanılan veri setine yukarıdaki url’den ulaşabilirsiniz.

1. df = pd.read_csv(...): Veri setiniz olan 'Hitters.csv' dosyasını okuyarak df adlı tabloya yüklüyorsunuz.
2. df = df.dropna(): Tablodaki eksik değer içeren tüm satırları siliyorsunuz. (Veri temizliği).
3. dms = pd.get_dummies(df[['League', 'Division', 'NewLeague']]): Modelin anlayamayacağı kategorik (metinsel) değişkenleri (League, Division, NewLeague) alıp, onları sayısal 0/1 değişkenlerine (dummy) dönüştürüyorsunuz.
4. y = df["Salary"]: Tahmin etmeye çalıştığınız bağımlı değişkeni (Maaş/Salary) belirliyorsunuz.
5. X_ = df.drop(['Salary', 'League', 'Division', 'NewLeague'], axis=1).astype('float64'): Maaş ve az önce dönüştürdüğünüz eski kategorik sütunları tablodan atarak, sayısal bağımsız değişkenlerin iskeletini oluşturuyorsunuz.
6. X = pd.concat([X_, dms], axis=1): Sayısal değişkenleriniz ile yeni oluşturduğunuz dummy (0/1) değişkenleri birleştirerek, modelin kullanacağı son girdi kümesini (X) hazırlıyorsunuz.
7. X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=42): Tüm veriyi, aşırı öğrenmeyi kontrol etmek için %25 test ve %75 eğitim olacak şekilde ikiye ayırıyorsunuz.

Model Eğitimi

ridge_model = Ridge(alpha=0.1).fit(X_train, y_train):

• Ridge Regresyon modelini, 0.1 gibi rastgele bir lambda (alpha) değeri ile başlatıyorsunuz.
• .fit(X_train, y_train): Modeli, ayırdığınız eğitim verisi ile eğitiyor ve modelin tüm katsayılarını hesaplamasını sağlıyorsunuz.

Modelin Katsayıları ve Kesişim Noktası

ridge_model.coef_ (Satır 19):

• Modelin, veriyi inceleyerek bulduğu tüm katsayıları görüntülediniz.

ridge_model.intercept_ (Satır 30):

• Modelin öğrendiği kesişim noktasını görüntülediniz.

Lambda Değer Aralığının Oluşturulması

Bu kısım, Ridge Regresyon’un en kritik adımıdır. Doğru cezalandırma şiddetini (Lambda) bulmak için bir arama listesi oluşturuluyor.

np.linspace(10, -2, 100)

• NumPy kütüphanesi kullanılarak 10² (yani 100) ile 10^-2 (yani 0.01) arasında, logaritmik olarak eşit aralıklarla dağılmış 100 farklı sayısal değerden oluşan bir dizi oluşturuldu.
• Anlamı: Bu, modelin test edeceği güçlü ve zayıf ceza şiddetleri (Lambda değerleri) listesinin taslağıdır.

lambdalar = 10**np.linspace(10, -2) * 0.5

• Yukarıdaki taslak değerlerin her biri 10’un üssü alınarak (logaritmik ölçekte) gerçek lambda değerleri listesi (lambdalar) oluşturuldu.
• Anlamı: Bu nihai lambdalar dizisi, modelinizin en uygun cezalandırma miktarını bulmak için K-Katlı Çapraz Doğrulama yapacağı 100 farklı lambda değerini içerir.

Bu kodlar, Ridge Regresyon modelinizi alıp, aşırı öğrenmeyi önlemek için gereken en iyi cezalandırma miktarı (lambda) nedir, sorusunun cevabını otomatik olarak aramaktadır.

İlk olarak, lambdalar adlı uzun bir dizi görüyorsunuz. Bu dizi, modelin test edeceği lambda'nın tüm olası ceza şiddetlerini içerir. Bu değerler, hem çok küçük (0.01 gibi) hem de çok büyük (10.000.000 gibi) cezaları içerir ve her biri eşit öneme sahip olacak şekilde logaritmik olarak düzenlenmiştir.

Kodun kalbi, for i in lambdalar: ile başlayan döngüdür. Bu döngü, arka planda şu talimatı verir:

• “Al bu 100 farklı lambda değerini ve her bir lambda için şu adımları yap:”
• Ayarı Değiştir: ridge_model.set_params(alpha = i) komutuyla, modelin mevcut ceza şiddetini, o anki yeni lambda değeriyle değiştirir.
• Yeniden Eğit: ridge_model.fit(X_train, y_train) komutuyla modeli, bu yeni ceza ile tekrar eğitir.
• Katsayıları Sakla: katsayilar.append(ridge_model.coef_) komutuyla, modelin bu yeni ceza ile bulduğu beta katsayılarını bir listeye kaydeder.

Kaydettiğiniz bu katsayıları burada katsayilar yazarak çağırıyoruz.

Bu grafik, lambda (Lambda) değeri değiştikçe, modelinizdeki tüm bağımsız değişkenlerin katsayılarının (beta) nasıl tepki verdiğini gösterir.

Eksenlerin Anlamı

• Y Ekseni (Dikey): Katsayı Değerleri (beta): Modelinizdeki her bir özelliğin aldığı sayısal ağırlık değeridir.
• X Ekseni (Yatay): Lambda Değerleri : Bu, Ridge modelinin ceza şiddetini gösterir. Eksen logaritmik ölçektedir (ax.set_xscale("log")), yani küçük değerlerden (10^-1) çok büyük değerlere (10^9) kadar uzanır.

Grafiğin Yorumu (Ridge’in Çalışma Mantığı)

Grafikte gördüğünüz her bir renkli çizgi, bir bağımsız değişkenin lambda’ya karşı aldığı katsayı değerini temsil eder.

Sol Taraf (lambda Düşük, Cezalandırma Zayıf)

• Durum: Sol tarafta lambda değerleri çok küçüktür. Ceza etkisi zayıftır.
• Gözlem: Katsayı çizgileri çok dağınık ve büyük değerler alır (bazıları +100’e, bazıları -100’e yakındır). Bu durum, modelin olduğu gibi (OLS gibi) çalıştığını ve verideki küçük gürültüleri bile yakalamak için katsayıları şişirdiğini gösterir.

Sağ Taraf (lambda Yüksek, Cezalandırma Şiddetli)

• Durum: Sağ tarafa (10⁵, 10⁷) doğru ilerledikçe lambda değerleri çok büyür. Cezalandırma şiddeti artar.
• Gözlem: Tüm renkli çizgiler (beta katsayıları), merkeze doğru (sıfıra) hızla yaklaşır ve nihayetinde sıfırda buluşur.
• Anlamı: Model, büyük ceza almamak için tüm katsayılarını küçültmek zorunda kalmıştır. Bu, modelin aşırı öğrenme eğilimini bastırdığını ve gereksiz karmaşıklıktan kurtularak sadeleştiğini gösterir.

Ridge Regresyon: Performans Ölçümü ve Doğrulama

Bu kod bloğu, daha önce teorisini öğrendiğiniz Ridge Regresyon modelini kullanarak, modelinizin eğitimdeki başarısını, testteki genelleme yeteneğini ve çapraz doğrulama ile istikrarını ölçtüğünüz en kritik aşamanın kodlarıdır. Şimdi tek tek kodalrı daha yakından inceleyelim:

Model Eğitimi ve Tahminler

ridge_model = Ridge().fit(X_train, y_train)

• Ridge Regresyon modeli kuruldu ve eğitim verileri (X_train, y_train) kullanılarak eğitildi. (Bu aşamada lambda varsayılan bir değerle başlar.)

y_pred = ridge_model.predict(X_train)

• Eğitilmiş model, kendi gördüğü (X_train) verileri kullanarak tahminler (y_pred) yaptı. Bu tahminler, modelin ne kadar iyi ezberlediğini görmemizi sağlar.

y_train[0:10] ve Çıktıları :

• Gerçek maaş değerleri (y_train) ile modelin bu maaşlar için yaptığı tahminler (y_pred) ilk 10 satırda karşılaştırıldı.

Eğitimin Başarısını Ölçme (Train Error)

RMSE = np.sqrt(mean_squared_error(y_train, y_pred))

• Modelin eğitim hatası (RMSE) hesaplandı. Gerçek eğitim değerleri (y_train) ile modelin bu veriler için yaptığı tahminler (y_pred) arasındaki farkın karekökü alındı.
• Mantık: Bu değer, modelin eğitim setini ezberleme (veya öğrenme) başarısını gösterir. Bu değerin düşük olması beklenir.

Model İstikrarını Ölçme (K-Katlı Çapraz Doğrulama)

from sklearn.model_selection import cross_val_score (Satır 76):

• K-Katlı Çapraz Doğrulama (CV) aracını programa dahil ederiz.

np.sqrt(np.mean(-cross_val_score(...)))

• Modelin eğitim verisini 10 eşit parçaya bölerek (cv=10) 10 farklı test yaptıktan sonra, elde edilen hataların (MSE) ortalamasının karekökü alındı.
• Mantık: Bu, modelin tek bir test setine bağımlı olmadan, verinin farklı parçalarında ne kadar istikrarlı çalıştığını gösteren en güvenilir hata ölçütüdür.

Genelleme Yeteneğini Ölçme (Test Error)

y_pred = ridge_model.predict(X_test)

• Modelden, daha önce hiç görmediği (X_test) test verilerini kullanarak tahmin yapması istendi.

RMSE = np.sqrt(mean_squared_error(y_test, y_pred))

• Modelin test hatası (RMSE) hesaplandı. Gerçek test değerleri (y_test) ile modelin bu veriler için yaptığı tahminler arasındaki hata ölçüldü.
• Mantık: Bu değer, modelin gerçek dünya genelleme yeteneğini gösterir. Bu skorun, eğitim hatasına çok yakın olması beklenir. Arada büyük fark varsa, model aşırı öğrenmiş (overfitting) demektir.

Model Tuning Nedir?

Model Tuning (Model Ayarlama), bir makine öğrenimi modelinin performansını optimize etmek için kullanılan bir süreçtir.

Kısaca, modelin öğrenme sürecini kontrol eden ve veri setinden otomatik olarak öğrenilemeyen hiperparametreler adı verilen ayarların en iyi kombinasyonunu bulma işlemidir.

Temel Kavramlar

• Model Parametreleri: Modelin eğitim sırasında verilerden öğrendiği değerlerdir (Örn: Doğrusal regresyondaki eğim ve kesme noktası, veya sinir ağlarındaki ağırlıklar).
• Hiperparametreler: Modelin kendisinin değil, öğrenme algoritmasının davranışını kontrol eden dışsal ayar değerleridir. Model tuning, bu değerleri bulmaya odaklanır.

Model Tuning kodları:

Temel Ridge Modeli ve Performans

Amaç: Hiperparametre ayarına başlamadan önce basit bir Ridge modelinin (varsayılan ayarlarla) performansını görmek.

• ridge_model = Ridge(1).fit(X_train, y_train): alpha=1 (varsayılan) ile bir Ridge modeli eğitilir.
• y_pred = ridge_model.predict(X_test): Test seti üzerinde tahmin yapılır.
• np.sqrt(mean_squared_error(y_test, y_pred)): Modelin performansı, Kök Ortalama Karesel Hata (RMSE) ile değerlendirilir.
• Sonuç: 356.808.... Bu, modelin ortalama hata miktarını gösterir.

alpha Adaylarının Oluşturulması

Ridge regresyonunda ayarlanması gereken ana hiperparametre alpha’dır (düzenleme kuvveti). RidgeCV (Çapraz Doğrulamalı Ridge) modelinin deneyeceği alpha (düzenleme) değerlerinin bir listesi oluşturuluyor.

• np.random.randint(0, 1000, 100)
• 0 ile 1000 arasında rastgele 100 adet tam sayı seçilir.
• lambdalar1 = np.random.randint(0, 1000, 100)
• 0 ile 1000 arasında rastgele 100 adet tamsayı içeren bir alpha adayı listesi oluşturulur.
• lambdalar2 = 10**np.linspace(10, -2, 100)*0.5
• Bu, genellikle daha iyi sonuç veren bir yaklaşımdır. 10^-2’den 10^10’a kadar logaritmik olarak eşit aralıklarla 100 adet alpha değeri oluşturulur ve 0.5 ile çarpılır.

Hiperparametre Ayarı: RidgeCV Kullanımı

• ridgecv = RidgeCV(alphas=lambdalar2, scoring="neg_mean_squared_error", cv=10)
• RidgeCV modeli, en iyi alpha değerini bulmak için 10 katmanlı (10-fold) çapraz doğrulama yapar.
• Parametreler:
• alphas=lambdalar2: Denenecek alpha adayları listesi (lambdalar2 kullanılıyor).
• scoring="neg_mean_squared_error": Performans metriği olarak Negatif Ortalama Karesel Hata (Negative MSE) kullanılır. (Pozitif değere dönüştürüldüğünde MSE elde edilir.)
• cv=10: 10 katmanlı çapraz doğrulama kullanılır.
• ridgecv.fit(X_train, y_train): Model, bu alpha adaylarını kullanarak eğitim verisi üzerinde en iyi alpha'yı bulmak için eğitilir.

En İyi alpha Değeri ve Final Model

• ridgecv.alpha_
• RidgeCV eğitimi tamamlandıktan sonra, çapraz doğrulama ile bulunan en iyi alpha (düzenleme) değeri bu öznitelikte saklanır.
• Sonuç: 1526927.7544167063. Bu, modelin bulduğu en iyi alpha değeridir.

Final Modelin Eğitilmesi ve Değerlendirilmesi

• ridge_tuned = Ridge(alpha=ridgecv.alpha_).fit(X_train, y_train): Bulunan en iyi alpha değeri (ridgecv.alpha_) kullanılarak son Ridge modeli eğitilir.
• y_pred = ridge_tuned.predict(X_test): Test seti üzerinde tahmin yapılır.
• np.sqrt(mean_squared_error(y_test, y_pred)): Performans (RMSE) tekrar hesaplanır.
• Sonuç: 385.864....

kodlara Kaynakça kısmındaki github reposundan ulaşabilirsiniz.

Lasso Regresyon Modeli

Lasso Regresyonunun temel amacı, tıpkı standart regresyonda olduğu gibi, hata kareler toplamını (SSE) en aza indirmektir.

Ancak, bunu yaparken bir kural ekler: katsayılara (yani modeldeki değişkenlerin ağırlıklarına) bir ceza uygular.

1. Amaç Fonksiyonu

Lasso’nun minimize etmeye çalıştığı denklem şudur:

• İlk Kısım: Tahminlerimiz ile gerçek değerler arasındaki hatayı minimum yapmaya çalışır.
• İkinci Kısım (Ceza Terimi): Modelin katsayılarının beta_j mutlak değerlerinin toplamını (L1 normu) ceza olarak ekler ve bu ceza Lambda ile çarpılır.

Lasso Regresyonu, ceza teriminde mutlak değerleri kullandığı için L1 Regresyonu olarak da adlandırılır.

Lasso’nun Özel Gücü: Değişken Seçimi

Lasso’yu Ridge Regresyonundan ayıran en önemli özellik, otomatik değişken seçimi yapabilmesidir.

Ridge Regresyonunun Dezavantajı

Ridge Regresyonu da ceza terimi kullanır (L2 normu), ancak ilgisiz değişkenlerin katsayılarını sıfıra yaklaştırır, ama asla tam olarak sıfır yapmaz. Bu, modelde hala yüzlerce hatta binlerce değişkenin kalmasına neden olabilir.

Lasso’nun Çözümü

Lasso’da, lambda (ayarlama parametresi) yeterince büyük seçildiğinde:

1. Model, hatayı ve cezayı aynı anda düşürmek ister.
2. Bunu başarmanın en iyi yolu, modelin performansına hiç katkı sağlamayan veya çok az katkı sağlayan değişkenlerin katsayılarını TAM OLARAK SIFIR beta_j = 0 yapmaktır.
3. Bir katsayı sıfır olduğunda, o değişken modelden otomatik olarak çıkarılmış olur.

Böylece Lasso, en önemli değişkenleri bırakarak değişken seçimi (feature selection) yapmış olur, bu da daha basit ve yorumlanabilir modeller oluşturur.

lambda (Lambda) Ayar Parametresinin Belirlenmesi

lambda’nın model üzerindeki etkisi çok kritik olduğu için, doğru lambda değerini bulmak anahtar adımdır.

• lambda = 0 ise: Ceza terimi ortadan kalkar ve Lasso, Standart En Küçük Kareler (EKK) yöntemine eşdeğer olur.
• lambda > 0 ise: lambda büyüdükçe ceza artar ve katsayılar sıfıra yaklaşır.

En İyi lambda’yı Bulma Süreci (Çapraz Doğrulama — CV)

1. Aday Kümesi Seçimi: lambda için geniş bir aralıkta (genellikle logaritmik olarak) birden fazla aday değer içeren bir küme belirlenir.
2. Çapraz Doğrulama (Cross Validation — CV): Bu aday lambda değerlerinin her biri için çapraz doğrulama testi hatası hesaplanır. (Bu, modelin yeni veriler üzerindeki genelleme yeteneğini ölçer.)
3. En İyi lambda Seçimi: En küçük cross validation hatasını veren lambda değeri, optimal ayar parametresi olarak seçilir.
4. Final Model: Son olarak, bu seçilen en iyi lambda kullanılarak model tüm eğitim verisi üzerinde yeniden eğitilir.

Lasso Regresyon Uygulaması:

Bu kısımdaki kodlar daha önceki Ridge Regresyonu uygulamasında gördüğünüz veri hazırlama, eğitim ve test verisi ayırma, temel model fit etme adımları büyük ölçüde aynı kalmaktadır. Bu nedenle, tekrar eden kod bloklarını ve temel süreçleri atlayarak, yalnızca Lasso Regresyonuna özgü olan adımlara, özellikle hiperparametre optimizasyonu ($\lambda$ seçimi) ve katsayıların (coefficients) sıfırlanması gibi kritik noktalara değinilecektir.

Temel kodların işlevini anlamakta zorlandığınız yerler olursa, lütfen Ridge Regresyonu açıklamalarına başvurarak Lasso’ya uyarlayabilirsiniz.

Katsayıların lambda’ya Göre Görselleştirilmesi

Bu kısım, farklı lambda değerleri için katsayıların nasıl değiştiğini gösteren grafiği çizer.

lasso = Lasso():

• Düzenleme parametresi lambda (alpha) ayarlanacak olan Lasso sınıfından bir model nesnesi oluşturulur.

coefs = []:

• Her lambda değeri için bulunacak olan katsayıları (coef_) depolamak amacıyla boş bir liste tanımlanır.

alphas = 10**np.linspace(10, -2, 100)*0.5:

• Bu geniş aralık, en iyi lambda’yı bulmak için önemlidir.

for a in alphas: lasso.set_params(alpha = a):

• Oluşturulan her bir $ambda adayı (a) için döngü başlatılır ve bu değer, lasso modelinin alpha parametresine atanır.

lasso.fit(X_train, y_train):

• Model, o anki lambda değeri kullanılarak eğitim verisi (X_train, y_train) üzerinde eğitilir.

coefs.append(lasso.coef_):

• Eğitilen modelin bulduğu tüm katsayılar (coef_), coefs listesine eklenir.

ax = plt.gca():

• Grafik çizmek için mevcut çizim eksenlerine erişilir.

ax.plot(alphas, coefs):

• X ekseninde lambda değerleri (alphas) ve Y ekseninde bu lambda'lara karşılık gelen katsayı değerleri (coefs) kullanılarak grafik çizilir.

ax.set_xscale("log"):

• lambda aralığı çok geniş olduğu için X ekseninin logaritmik ölçekte gösterilmesi sağlanır.

Temel Model Tahmini ve Performansı

Bu kısım, genellikle varsayılan bir lambda ile eğitilmiş modelin test verisindeki tahmin yeteneğini değerlendirir.

lasso_model:

• Kullanılan lasso_model nesnesinin detaylarını gösterir.

lasso_model.predict(X_train)[0:5]:

• Modelin, eğitim verisinin ilk 5 gözlemi için yaptığı tahminler gösterilir.

lasso_model.predict(X_test)[0:5]:

• Modelin test verisinin (modelin hiç görmediği veri) ilk 5 gözlemi için yaptığı tahminler gösterilir.

y_pred = lasso_model.predict(X_test):

• Modelin tüm test verisi üzerindeki tahminleri yapılır ve sonuçlar y_pred değişkenine atanır.

np.sqrt(mean_squared_error(y_test, y_pred)):

• Tahminlerin gerçek y_test değerlerine göre Kök Ortalama Karesel Hatası (RMSE) hesaplanır (356.097).

r2_score(y_test, y_pred):

• Modelin test verisindeki R-kare (R²) skoru hesaplanır (0.414).

Optimal lambda ile Model Ayarlama ve Final Katsayılar

Bu kısım, Çapraz Doğrulama kullanarak en iyi lambda’yı bulur ve nihai modeli bu değerle eğitir.

lasso_cv_model = LassoCV(cv = 10, max_iter = 100000).fit(X_train, y_train):

• LassoCV (Çapraz Doğrulamalı Lasso) modeli oluşturulur. 10 katmanlı (cv=10) çapraz doğrulama kullanarak en iyi lambda değeri bulunur ve model eğitilir.

lasso_cv_model.alpha_:

• Çapraz doğrulama sonucunda modelin bulduğu en iyi lambda (alpha) değeri gösterilir (563.467).

lasso_tuned = Lasso().set_params(alpha = lasso_cv_model.alpha_).fit(X_train, y_train):

• Final Model Eğitimi: Yeni bir Lasso modeli oluşturulur, lasso_cv_model.alpha_ ile bulunan optimal lambda değeri atanır ve model tüm eğitim verisi üzerinde son kez eğitilir.

y_pred = lasso_tuned.predict(X_test):

• Ayarlanmış modelin test verisindeki tahminleri yapılır.

np.sqrt(mean_squared_error(y_test, y_pred)):

• Ayarlanmış modelin RMSE değeri hesaplanır (373.595).

pd.Series(lasso_tuned.coef_, index=X_train.columns):

• Final Katsayıları: Ayarlanmış modelin bulduğu katsayılar (coef_), ilgili değişken adları ile birlikte liste halinde gösterilir. Bu çıktı, Lasso'nun yaptığı değişken seçimi sonucu bazı katsayıların tam olarak 0.000000 olduğunu gösterir.

ElasticNet Regresyonu:

ElasticNet Regresyonu, temelde, daha önce gördüğünüz Ridge Regresyonu (L2) ve Lasso Regresyonu (L1) yöntemlerinin en iyi yönlerini birleştiren bir düzenleme (regularizasyon) tekniğidir.

Temel Amaç

Standart regresyonda olduğu gibi, amaç hata kareler toplamını minimum yapan katsayıları bulmaktır. Ancak ElasticNet, bu katsayılara iki farklı türde ceza uygulayarak bunu gerçekleştirir.

ElasticNet, L1 ve L2 yaklaşımlarını birleştirdiği için, her iki yöntemin avantajlarından da faydalanır.

ElasticNet’in Matematiksel Yapısı

ElasticNet’in minimize etmeye çalıştığı fonksiyon (maliyet fonksiyonu) üç ana bileşenden oluşur, tıpkı görselde gördüğünüz gibi:

1. Hata Kareler Toplamı: Modelin tahmini ile gerçek değerler arasındaki farkın karesidir.
2. L2 Ceza Terimi (Ridge Kısmı): Katsayıların karesini (beta_j²) ceza olarak ekler. lambda_1 bu cezanın gücünü kontrol eder.
3. L1 Ceza Terimi (Lasso Kısmı): Katsayıların mutlak değerini (|beta_j|) ceza olarak ekler. lambda_2 bu cezanın gücünü kontrol eder.

Neden L1 ve L2 Birleştirilir?

ElasticNet, her iki yöntemin avantajlarını aynı anda sunar:

1. Değişken Seçimi (Lasso/L1 Etkisi): lambda_2 sayesinde, Lasso’daki gibi önemsiz değişkenlerin katsayıları tam olarak sıfır yapılabilir. Bu, modelin basitleşmesini ve yorumlanabilirliğini sağlar.
2. Korelasyon Sorunlarının Çözümü (Ridge/L2 Etkisi): Eğer veri setinde birbiriyle yüksek derecede ilişkili (korelasyonlu) çok sayıda değişken varsa, Ridge Regresyonu bu gruplanmış değişkenlerin katsayılarını eşit olarak dağıtmada daha başarılıdır. ElasticNet, bu özelliği sayesinde Ridge’den daha kararlı sonuçlar verir.

Özetle, ElasticNet hem değişken seçimi yapmak ister (Lasso gibi), hem de yüksek korelasyonlu değişkenler kümesiyle karşılaştığında daha stabil davranmak ister (Ridge gibi). Bu iki gücü birleştirerek güçlü bir düzenleme yöntemi oluşturur.

Bu kısımdaki uygulama kodları diğer kodlara çok benzediğinden dolayı ekstra açıklamaya girilmeyecektir. Tüm kodlara ulaşmak için kaynaklar kısmındaki github reposu ile ulaşabilirisiniz.

Sonuç

Bu detaylı analizde, regresyon modellerinin genelleme yeteneğini artırmanın yollarını inceledik.

• Ridge Regresyonu (L2): Modelin aşırı öğrenmesini (overfitting) önlemek için katsayıları sıfıra yaklaştırarak modeli istikrarlı hale getirmeyi öğrendik. Yüksek korelasyonlu değişkenlerde kararlılık sağlar.
• Lasso Regresyonu (L1): lambda parametresi yeterince büyük olduğunda, ilgisiz değişkenlerin katsayılarını TAM OLARAK SIFIR yaparak otomatik değişken seçimi yapmanın gücünü gördük.
• ElasticNet Regresyonu: L1 ve L2'nin en iyi yönlerini birleştirerek, hem değişken seçimi yapar hem de yüksek korelasyonlu veri setlerinde daha stabil sonuçlar verir.

Tüm bu süreçte, Çapraz Doğrulama (CV) ile en uygun lambda (alpha) değerini bularak modellerimizin gerçek dünya başarısını maksimize etmenin kritik önemini anladık.

Bu düzenleme yöntemleri, daha güvenilir tahminler yapmak ve modelin karmaşıklığını kontrol altında tutmak için elinizdeki en güçlü araçlardır. Bir sonraki yazıda görüşmek üzere…

Kaynakça

• Makine Öğrenmesi 201 | Geleceği Yazanlar
• GitHub - Safiye-alaca/ML_Basics: This repository contains foundational data science and machine learning projects implemented as part of the courses I completed on the Turkcell Geleceği Yazanlar platform. The projects aim to translate theoretical knowledge into practical skills using libraries such as Python, Pandas, Scikit-learn, and Matplotlib/Seaborn.

Makine Öğrenmesi 201- part2 was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern web uygulamalarını hızlı, güvenli ve zevkli şekilde inşa etmek için hazırladığım yeni Next.js 16 boilerplate’imi tanıtıyorum: Nizam.

Neden “Nizam”?

“Nizam” Türkçe’de düzen, yapı ve uyum anlamına geliyor. Tam da bir boilerplate’ten beklediğimiz gibi: iyi organize edilmiş, anlaşılır ve ölçeklenebilir bir temel. Ayrıca yabancı geliştiricilerin de kolayca telaffuz edebileceği, akılda kalıcı bir isim. Projenin adıyla felsefesi birebir örtüşüyor.

Neden yenilendi?

Önceki sürüm (Next.js 15) deneyiminden sonra, Next.js 16’nın getirdiği yenilikler ve React 19 ile birlikte mimariyi sıfırdan, daha yalın ve odaklı olacak şekilde yeniden kurdum. Storybook ve Sentry gibi her projede gerekmeyebilecek bağımlılıkları çekirdekten çıkardım; artık opsiyonel. Böylece boilerplate, çoğu projeye “direkt uygun” bir hafif çekirdek sunuyor, ihtiyaç duyanlar ise kolayca entegre edebiliyor.

Nizam ile gelenler

• Next.js 16 App Router: Dosya tabanlı yönlendirme, server-first desenler, concurrency dostu mimari.
• Tip güvenliği ve env doğrulama: TypeScript 5, Zod ve @t3-oss/env-nextjs ile runtime doğrulamalı ortam değişkenleri.
• Veri katmanı: TanStack Query 5 ile akıllı önbellekleme, arka planda yeniden doğrulama ve güçlü mutasyon akışları.
• Uluslararasılaştırma (i18n): next-intl ile locale-aware routing ve çeviri dosyaları.
• Tema ve UI: Tailwind CSS v4 + shadcn/ui ile erişilebilir ve hızlı arayüzler; next-themes ile açık/koyu tema.
• Durum yönetimi: Hafif global state için Zustand.
• Geliştirici deneyimi: ESLint 9, Prettier 3, Husky, lint-staged, Knip; absolute importlar (@/), paket analizörü ve SEO yardımcıları.

Bu özelliklerin detaylarını hem canlı demoda hem de README’de görebilirsiniz.

Önceki sürüme göre neler farklı?

• Güncel yığın: Next.js 16 + React 19, Tailwind CSS v4, TanStack Query 5 ve modern araç setleri.
• Env ve güvenlik: @t3-oss/env-nextjs + Zod ile env değişkenleri tip-güvenli ve runtime doğrulamalı.
• Standartlar ve kurallar: Yeni alias kullanımı, dosya adlandırmaları ve kod yazım konvansiyonlarını netleştirdim; .cursor/rules ile editör/AI akışını da standardize ettim.
• Sürdürülebilir repo hijyeni: Conventional Commits, Knip ve otomasyonlarla temiz, izlenebilir bir sürümleme ve bakım deneyimi.
• Sıfırdan kurulan daha yalın bir çekirdek: Storybook/Sentry gibi "her FE projesinde olmayabilecek" parçalar çekirdekten çıkarıldı; isteyenler kolayca ekleyebilir.

Neden Nizam’ı kullanmalısınız?

• Hızlı başlangıç, minimum uğraş: Çoğu projeye uygun, görüş bildiren ama dayatmacı olmayan bir çekirdek.
• Güçlü ama sade: Performans, a11y ve DX’i önceleyen, gereksiz bağımlılıklardan arınmış bir temel.
• Net kurallar, tutarlı kod: İsimlendirme, alias ve konvansiyonlar projeye disiplin kazandırır; ekip büyüdükçe değerini artırır.
• Gerçek dünyaya hazır: i18n, tema, SEO ve veri katmanı gibi “genelde gereken” bloklar hazır gelir.

Hızlı başlangıç

git clone --depth=1 https://github.com/omergulcicek/nizam my-project
cd my-project
npm install
npm run dev

Varsayılan .env örnekleri ve env şeması için src/env.ts dosyasına bakabilirsiniz.

Bağlantılar

• Canlı Demo: nizam-boilerplate.vercel.app
• GitHub: omergulcicek/nizam

README’de tüm teknik detaylar, proje yapısı, isimlendirme önerileri ve ipuçları yer alıyor. İnceleyin, klonlayın ve kendi ihtiyaçlarınıza göre özelleştirin.

Destek olun

Projeyi beğendiyseniz GitHub reposuna ⭐ vererek destek olabilirsiniz. Görüş ve katkılarınız için issue veya PR açmaktan çekinmeyin. Teşekkürler!

Kişisel Sitem: omergulcicek.com
Blog: https://omergulcicek.com/blog/nizam-nextjs-16-boilerplate/
Instagram: @omerilekesfet

Makaleyi alkışlayarak destek olabilirsiniz 🌹

Nizam — Next.js 16 Boilerplate was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.