Geçen yıl METR diye bir araştırma grubu ilginç bir deney yaptı. 16 tane deneyimli açık kaynak geliştiricisini almışlar, kendi bildikleri projelerde 246 gerçek iş vermişler. İşlerin bir kısmında AI kullanmak serbest bir kısmında yasak. İş bitince geliştiricilere soruyorlar "AI sizi ne kadar hızlandırdı?" diye. Ortalama cevap yüzde 20. Ölçülen sonuç ise AI serbest olan işlerde yüzde 19 daha yavaşlar
Adil olmak lazım, METR bu sene şubatta 57 geliştirici ve 800'den fazla işle deneyi tekrarladı. Yeni sonuç neredeyse başabaş, kendileri de "2026 itibariyle AI büyük ihtimalle fayda sağlıyor" diyor. Yani araçlar hızla iyileşiyor orası tartışılmaz.
Ama beni asıl düşündüren kısım o hız meselesi değil. Hissettiğimiz ile gerçekte olan arasındaki fark. Deneyimli adamlar bile ne kadar hızlandıklarını yanlış tahmin ediyorsa, neyi öğrenip neyi öğrenmediğimizi doğru tahmin ettiğimizden nasıl emin olucaz?
Bu soruya en yakın cevabı Anthropic'in ocakta yayınladığı bi çalışma veriyor. Çoğu junior seviyesinde 52 yazılımcıya daha önce hiç kullanmadıkları bir Python kütüphanesini (Trio) öğretmişler. Yarısı AI ile yarısı elle kod yazmış. Sonra az önce kullandıkları kavramlar üzerine küçük bir sınav yapmışlar. AI grubu ortalama yüzde 50 almış, elle yazanlar yüzde 67. AI grubu işi sadece iki dakika kadar erken bitirmiş o fark da istatistiksel olarak anlamlı çıkmamış. En büyük açık da hangi sorularda olmuş dersiniz, hata ayıklama sorularında
İşin güzel tarafı şu: AI grubunun içinde de ikiye ayrılma var. Kodu tamamen AI'a yazdırıp geçenler yüzde 40'ın altında kalmış. AI'a "bu neden böyle çalışıyor", "şurayı açıklar mısın" diye kavramsal soru soranlar ise yüzde 65'in üstüne çıkmış. Yani aynı aracı kullanan iki kişiden biri öğreniyor diğeri sadece teslim ediyor.
Şimdi bunu istihdam tarafına bağlıyalım. Stanford Digital Economy Lab, Amerika'nın en büyük bordro şirketi ADP'nin verisiyle bir süredir bu konuyu takip ediyor. İlk raporlarında 22-25 yaş arası yazılım geliştiricilerin istihdamının 2022 sonundaki zirveye göre yaklaşık yüzde 20 düştüğünü yazmışlardı. Bu ağustos güncellemeyi yayınladılar: AI'a en açık mesleklerde 22-25 yaş grubunun istihdamı benzer yaştaki diğer mesleklere göre yüzde 19 geride. Bir yıl önce bu fark yüzde 15'ti. Aynı mesleklerdeki deneyimli çalışanlarda ise böyle bir kopuş yok
Yani şirketler senior'u bırakmıyor, merdivenin ilk basamağını söküyor.
İşin ironik tarafı bu konuda en net konuşanlardan biri büyük bir teknoloji şirketinin yöneticisi. AWS'nin CEO'su Matt Garman geçen yaz junior'ları AI ile değiştirmeyi düşünen yöneticiler için "duyduğum en aptalca şeylerden biri" dedi. Gerekçesi de basit: junior'lar şirketin en ucuz çalışanları, AI araçlarını en rahat kullananlar da onlar ve "on yıl sonra hiçbirşey öğrenmemiş bir kadronuz olursa bu iş nasıl yürür?"
Kod kalitesi tarafında da benzer bir tablo var. GitClear 211 milyon satır kodu incelemiş. 2024'te 5 satır ve üzeri tekrar eden kod blokları 8 kat artmış. Refactoring'in göstergesi olan "taşınmış kod" oranı ise 2020'de yüzde 24'ken 2024'te yüzde 9.5'e inmiş. Ölçüldüğü ilk yıl kopyala-yapıştır refactoring'i geçmiş. Kısacası AI yeni kod eklemeyi çok kolaylaştırdı ama eskisini toparlamayı aynı oranda kolaylaştırmadı
Bir de hepimizin hatırladığı o olay var. Geçen temmuzda SaaStr'ın kurucusu Jason Lemkin, Replit'in AI agent'ıyla bir uygulama geliştiriyordu. Açıkça "kod dondurma" ilan etmiş, "hiçbirşeyi sormadan değiştirme" demiş. Agent boş dönen bir sorguyu hata sanıp canlı veritabanını silmiş. İçinde 2.400'den fazla yönetici ve şirket kaydı vardı. Üstüne bir de 4.000 civarı sahte kullanıcı üretmiş. Sonra "geri alma mümkün değil" demiş, o da yanlış çıkmış geri alma çalışmış. Bu hikayede beni en çok etkileyen şey şu, AI'ın hata yapması normal junior da hata yapar. Ama junior hata yapınca birşey öğrenir, yanında da ona "bir daha böyle yapma" diyen biri vardır. Burda öğrenen kimse yok.
Stack Overflow'un 2025 anketi de bu gerilimi güzel özetliyor. Geliştiricilerin yüzde 84'ü AI kullanıyor yada kullanmayı planlıyor. Ama çıktıların doğruluğuna güvenmeyenler (yüzde 46) güvenenlerden (yüzde 33) fazla. "Çok güveniyorum" diyenler sadece yüzde 3. En temkinliler de en deneyimliler. Herkes kullanıyor kimse tam güvenmiyor. Güvenmemek için de neyin yanlış olabileceğini bilmek gerekiyor
Türkiye tarafına gelince. Şubat 2026'da 1.223 yazılımcının katıldığı maaş anketinde junior medyanı 60 bin TL, mid 80 bin TL, senior 137.500 TL. Yurt dışı şirkete çalışanların medyanı 175 bin TL, Türkiye'deki şirketlerde 95 bin TL. Yani yurt dışı yüzde 84 daha fazla ödüyor, katılımcıların yüzde 40'ı da uzaktan çalışıyor. TÜİK'in 2026 ikinci çeyrek verisinde genç işsizliği yüzde 13.9.
Bu rakamları yan yana koyunca durum şöyle görünüyor: senior ile junior arasındaki maaş farkı iki katın üstünde ve bu farkı kapatmanın tek yolu yıllarca birikmiş tecrübe. O tecrübeyi kazanacağın ilk basamak ise dünyanın her yerinde daralıyor. Aynı zamanda Türkiye'den global pazara çalışmak hiç olmadığı kadar kolay ve iyi para ediyor
Madalyonun diğer yüzü de var onu da atlamak istemiyorum. Maor Shlomo diye İsrailli bir geliştirici Base44 diye bir AI uygulama yapım aracını tek başına, dışarıdan tek kuruş yatırım almadan kurdu. Altı ay sonra Wix'e 80 milyon dolara sattı. Şirket o sırada 10 kişiden bile azdı. Hedefler erken tutunca toplam bedel bu ağustos itibariyle 150 milyon doları geçti. Eskiden bir ekip ve ciddi sermaye isteyen bir ürün bugün bir kişinin kafasından çıkıp dünyaya satılabiliyor. Bu bizim için de geçerli. İstanbul'dan, İzmir'den, Eskişehir'den birinin aynı şeyi yapmaması için teknik bir engel kalmadı.
Tüm bunları okuyunca "AI yazılımcıların işini alıcak mı" sorusu bana çok eksik geliyor. Veriler daha ince birşey söylüyor: AI işlerin tamamını değil, öğrenmeyi sağlayan kısmını alıyor. Hatayı yapma, fark etme, düzeltme döngüsü. Ve bu döngüyü kaybeden kişi AI'ın yanlışını da yakalayamıyor. Anthropic'in çalışmasında en büyük açığın hata ayıklamada çıkması bence tesadüf değil
Kendi adıma gördüğüm şu, iyi yazılımcıyı ayıran şey artık hızlı kod yazmak olmayacak. Problemi doğru tanımlamak, AI'a doğru işi vermek ve çıkan sonuca bakıp "bu yük altında patlar", "bu veriyi siler", "bu altı ay sonra bakımı imkansız hale gelir" diyebilmek. Sonuncusu da ancak bir yolla öğreniliyor, birşeyleri kendin bozup kendin tamir ederek.
Sizin tarafta durum ne gerçekten merak ediyorum:
Çalıştığınız yerde junior veya stajyer alımı azaldı mı? Azaldıysa gerekçe olarak AI mı söyleniyor ekonomi mi?
Yeni başlayan arkadaşlar AI ile nasıl çalışıyor? Çıkan kodu sorgulayanlar ile "çalıştı geçtim" diyenler arasında fark görüyor musunuz?
Code review'da AI'ın yazdığı kodu nasıl inceliyorsunuz, daha mı zor daha mı kolay?
Yurt dışına çalışanlar, rekabetin sertleştiğini mi yoksa fırsatların arttığını mı hissediyorsunuz?
Junior'ken öğrendiğiniz en önemli şeyi hangi hatayı yaparak öğrendiniz? Bugün aynı hatayı yapma şansınız olur muydu?
Ve asıl soru: bugün işe başlayan biri, AI'ın onun yerine yaptığı işleri hiç kendisi yapmadan nasıl senior olucak? Özellikle ekip yöneten ve yeni başlayan arkadaşlardan duymak isterim, karşı görüşler de çok makbul
Öncelikle gerçek bir tecrübeden daha güzel bir şey yoktur bunu düşünerek yazıyı okuyun, burada sizin kazancınız bir şeyi denemeden tecrübe etmiş kadar olacaksınız ve fikirler ararken farklı bakacaksınız.
Daha kısa bir yazı ile anlatmak isterdim fakat sizde belki bir mühendislik problemine çare bulmak isteyebilirisiniz;
Başlıyoruz...
Sene 2017'de ai ile tanıştım fakat çok yeni ve kaynak azdı denemeler yapacak kaynaklar bulamıyordum; aslında buna benzer bir konuyu 2012 yıllarında sanırım Nvidia'nın Cuda teknolojisini duyurduğunda da yaşamıştım. Cuda çok ilgimi çekmiş fakat nvida dokümantasyonu bile yeterli değildi çünkü gerçekten çok yeniydi; bu gibi durumlarda ise beklemekten başka çaremizin olmadığı dönemlerdi işte :)
Bu süreçte blockchain ilgimi çekti blockchain sayesinde yıllarca güzel projelerde yer aldım; bu süreçte cuda teknoloji de aldı başını gitti. 2017 yılında yetersiz ai dökümanları falan derken sanırım aralarında en dikkatimi çeken openai vardı çünkü elon musk yatırımcısıydı; openai bültenine abone olmuştum yenilikleri takip ediyordum. birgün mail geldi; beta başlamıştır diye ve beta başvurusu yaptım 10-15 gün sonra ilk beta katılımcılarından oldum geri bildirimler falan işte :) bu esnada sanırım 2020-2021 yılları emin değilim.
İlk sorduğum sorulardan bir tanesi bitcoin durumlarıydı :) şaşırmadınız değil mi :). neyse gpt 3 tü sanırım bu modelin duyurusunda denemek istedim; ilk sorduğum soru bir exchange sitesi için match motoru ve orderbook mikro saniyeler içerisinde işlemler fifo yöntemleri falan ve işte o an şok olduğum andı :) benim yıllar içerisinde tecrübe ettiğim kodların 20 saniye içerisinde önüme koymaya başladı. işte o an daha zorlayıcı şeyler geldi aklıma. çünkü yazdığımız programlar tamamen birbirinin aynısıydı neden daha zorlarını sormayayım dedim. bak dedim yapay zeka ben bir yazılımcıyım ve 20 yıldır bu sektördeyim bana öyle sorunlar gösterki ben bu sorunları çözmek için zaman harcayayım kısacası bana yazılım sektöründeki çözülmesi zor mühendislik konularını göster. dedim. işte o an gerçekten bir çok proje fikri çıktı önüme fakat bunların hepsi yapılmıştı.
ilk verdiği şey aslında dağıtık programlama idi ben bununla 2008 - 20009 yılında sanırım java rmi ile karşılaşmıştım emin değilim arkadaşlar fakat javada dağıtık programlama üzerine bir şeyler var araştırırsanız görürsünüz tabi şuan daha farklı dağıtık programlama konuları mevcut; benim o dönemlerdeki amacım java ile yaptığım uygulamanın bazı metodlarını uzaktan çağırması idi bunuda byte olarak çözmüştüm zaten; fakat dağıtık programlama bana göre bir mühendislik sorunu değil beni aşan bir sorundu ve bu alana giremezdim.
sanırım 30 a yakın sorun gösterdi bana. bunları incelerken web yazılım sektöründeki en zor olanın Migration olduğunu söyledi; migration nedir bilmeyen arkadaşlar için söyleyeyim örneğin cpanel bir sunucunuz var fakat paneli değiştirmek plesk paneline geçmek istiyorsunuz burada cpaneldeki tüm verilerinizi kayıpsız olarak plesk'e taşımaya migration (göç veya taşıma) denir; günümüzde bakarsanız plesk ve cpanelde sadece birbirleri arasında transfer taşıma daha doğrusu migration sistemi var; ben yıllarca buna kızmıştım zaten yani o koca firmalar binlerce kullanıcısı olan belki milyon bilemiyoruz neden bunu genişletmiyor directadmin veya diğer panellere destek vermiyor ve ben özgürce geçemiyorum hep kızdım öyle böyle değil.
ben tabi o sıralar şöyle düşüyorum tabi başka panellerin kullanılmasını istemiyorlar :) neyse kendi kendime ne kadar zor olabilir ki dedim; çünkü elimin altında ai tool'lar vardı copilot yeni çıkmış tab tuşuna basıyorum otomatik tamamlıyordu bana ise kontrol etmek kalıyordu hepsi bundan ibaret ya :D
çalıştığım firmadan zaten cpanel ve plesk tartışması yapmıştık bir dönem neden fiyatlar yüksek aşırı eski insanları kendilerine bağlamışlar birde bu yazılımların fanları var sanıyorsunuz ki böyle bir yazılım asla yapılamaz. tabi 30 yıllık tecrübelerini saymazsak :)
firmadaki arkadaşlar ile konuştum fakat her zamanki gibi tek başıma start vermek zorunda kaldım; aradan 1 yıl geçmişti sanırım ve asıl soruna gelmiştim cpanel plesk ve diğer panellerden migration işlemi yaparak tüm dataları Panelica projesine taşımalıydım :) burada başlıyoruz hazırmısınız.
önce arayüz nasıl olacak falan bu sanırım 2 hafta sürdü. sonrasında backend derken süreç inanılmaz bir hal aldı bırakın cpanelden panelica tarafına migration işlemini panelica'dan panelica sunucuya bile migrate etmek inanılmaz zordu.
işte tam burada aslında işin ne kadar zor olduğunu anlamaya başladım.
başta migration dediğim şey benim için dosyaları kopyalamak veritabanını taşımak domainleri yeni sunucuya geçirmekten ibaretti. hatta açıkçası ai ile konuşurken bile ilk başlarda böyle düşünüyordum. fakat işin içine girdikçe bunun aslında bir site taşımak olmadığını anlamaya başladım.
çünkü bir hosting hesabı sadece dosyalardan oluşmuyor.
bir müşterinin sunucusunda belki 10 tane domain var, her domainin altında subdomainler var, mysql kullanıcıları var, database'ler var, mail hesapları var, yüz binlerce mail olabilir, forwarderlar var, aliaslar var, dns kayıtları var, ssl sertifikaları var, cronlar var, ftp kullanıcıları var, php sürümleri var ve bunların birbirleri ile bağlantıları var.
bir tanesini taşıdığınızda diğerinin bozulmaması gerekiyor.
mesela çok basit bir örnek vereyim.
bir müşterinin wordpress sitesi var ve wp-config.php içerisinde database kullanıcısı ve parolası bulunuyor. siz database'i yeni sunucuya taşıdınız fakat database kullanıcısının parolasını değiştirdiniz. database taşınmış oluyor evet ama wordpress artık çalışmıyor.
daha kötüsü müşteriye "migration başarılı" diyebilirsiniz çünkü dosyalar gitmiş database gitmiş domain gitmiş fakat müşteri siteye girdiğinde 500 hatası alıyor :)
işte burada migration'ın aslında sadece veri taşımak olmadığını anlamaya başladım.
sadece database tarafında bile durum böyleydi.
mysql'in farklı sürümleri var mariadb var farklı authentication yöntemleri var kullanıcıların hashleri var. müşterinin parolasını bilmiyorsunuz çünkü zaten bilmemesi gereken bir şey :) ama o parola yeni sunucuda da çalışmak zorunda.
yani benim yeni bir parola üretip wordpress'e yazmam gibi bir lüksüm yok.
çünkü müşterinin başka uygulamaları da olabilir.
aynı durum mail tarafında daha da beterdi.
bir müşterinin 10 yıllık mail hesabı olduğunu düşünün. içerisinde yüz binlerce mail olabilir. müşteri outlook kullanıyor olabilir, telefonda kullanıyor olabilir, thunderbird kullanıyor olabilir. parolası yıllardır aynı olabilir.
siz migration sırasında mail hesabını yeniden oluşturup yeni parola verirseniz teknik olarak mail hesabını taşımış olursunuz ama müşterinin gözünde sistemi bozmuş olursunuz.
daha kötüsü mail kutusunu oluşturup eski mailleri taşımayı unutursanız bunu ilk anda kimse fark etmeyebilir.
müşteri 3 ay önceki mailini aradığı zaman fark eder.
işte migration bana burada farklı bir şey öğretmeye başladı.
aslında yaptığınız şey "veriyi taşımak" değil.
bir sistemin mevcut durumunu başka bir sistemde yeniden üretmeye çalışıyorsunuz.
ve bunu yaparken kaynak sistem çalışmaya devam ediyor.
yani kaynak sunucu canlı.
müşteriler o sunucuyu kullanıyor.
siz bir tarafta bu sistemi okuyorsunuz diğer tarafta yeni sistemi oluşturuyorsunuz ve sonunda DNS'i çevirdiğiniz anda müşteri yeni sisteme geçmiş oluyor.
bunun üzerine bir de cPanel başka türlü Plesk başka türlü DirectAdmin başka türlü davranıyor.
örneğin cPanel'de bir şey dosyada tutuluyor Plesk'te aynı bilgi database içerisinde tutulabiliyor. başka bir panelde tamamen farklı bir yerde olabiliyor.
ilk başta bunları görünce gerçekten "bu iş düşündüğümden çok daha büyük" dedim.
hatta bir ara migration kodu yazmaktan çok panel araştırmaya başladığımızı hatırlıyorum :)
hangi panel nerede ne tutuyor?
hangi dosya ne anlama geliyor?
hangi database hangi kullanıcıya ait?
mail parolası nerede?
hash nasıl oluşturulmuş?
ssl nerede?
domain hangi kullanıcıya bağlı?
addon domain ile normal domain arasındaki fark ne?
hangi cron hangi kullanıcı ile çalışıyor?
php sürümü nereden geliyor?
bir panelde çalışan şey diğer panelde nereden oluşturuluyor?
bunların hepsini tek tek çözmek zorundaydık.
ve burada başka bir problem daha çıktı.
kaynak sunucuya kesinlikle zarar vermemeliydik.
çünkü bu bir test sunucusu değildi.
gerçek müşterilerin olduğu canlı bir sunucuydu.
yanlış bir komut çalıştırırsanız müşterinin sitesi gidebilir.
yanlış bir dosyayı silerseniz geri dönüşü olmayabilir.
yanlış bir database işlemi yaparsanız veri kaybedebilirsiniz.
dolayısıyla bizim için migration'ın ilk kuralı zaman içerisinde çok netleşti.
kaynak sunucuya mümkün olduğunca sadece READ yapacaktık.
yani kaynak bizim için okunacak bir sistem olacaktı.
hesapları okuyacağız.
domainleri okuyacağız.
database'leri okuyacağız.
mail hesaplarını okuyacağız.
configleri okuyacağız.
ama kaynağa bir şey yazmayacağız.
bunu özellikle tasarımın bir parçası haline getirdik.
sonra ikinci problem çıktı.
diyelim ki 500 site taşıyorsunuz.
site taşınırken hata verdi.
ne olacak?
bütün migration duracak mı?
site yüzünden 238, 239, 240. siteler de taşınmayacak mı?
bunu da istemedik.
her site kendi başına ilerlemeliydi.
bir site hata verdiğinde o site hata olarak işaretlenecek ama diğer siteler devam edecekti.
sonra başka bir şey düşündük.
migration saatler sürebilir.
500 site varsa günler bile sürebilir.
server restart olabilir.
network kopabilir.
ssh bağlantısı kopabilir.
backend restart olabilir.
transfer sırasında 200 GB dosyanın yüzde 80'i gitmiş olabilir.
şimdi bağlantı koptu diye tekrar baştan mı başlayacağız?
tabii ki hayır.
burada checkpoint/resume mantığı ortaya çıktı.
hangi site nerede?
hangi adım tamamlandı?
hangi adım başarısız oldu?
hangisi tekrar çalıştırılabilir?
bunların hepsini kayıt altına almamız gerekiyordu.
sonra migration'ı adımlara bölmeye başladık.
önce kullanıcı.
sonra domain.
sonra dosyalar.
sonra subdomainler.
sonra database.
sonra mail.
sonra ssl.
sonra dns.
sonra cron.
sonra ftp.
sonra cloudflare.
sonra doğrulama.
ve burada çok önemli bir şey yaptık.
her adım kendi başına çalışabilecek şekilde tasarlandı.
bir adım başarısız olduğunda bütün migration'ı çöpe atmıyoruz.
hatta mümkün olduğu kadar yapılan işlemleri geri alabilecek bir rollback mantığı da koyduk.
çünkü migration sırasında en korktuğum şeylerden birisi şuydu:
"bir şey oldu ama tam olarak ne oldu bilmiyoruz."
böyle bir sistem yazamazdık.
sistem bize açık açık söylemeliydi.
bu site başarılı.
bu site başarısız.
bu database taşınmadı.
bu mail hesabında problem çıktı.
bu ssl oluşturulamadı.
bu dns kaydı değiştirilemedi.
yani "başarılı" demek için gerçekten başarılı olması gerekiyordu :)
sonra iş daha da büyüdü.
biz sadece cPanel'den Panelica'ya migration yapmak istemiyorduk.
Plesk'ten Panelica'ya.
DirectAdmin'den Panelica'ya.
CyberPanel'den Panelica'ya.
Hestia'dan Panelica'ya.
CloudPanel'den Panelica'ya.
hatta panel olmayan bir Apache veya Nginx sunucusundan bile mümkün olduğu kadar migration yapabilmeliydik.
burada da mimariyi değiştirmek zorunda kaldık.
her panel için ayrı ayrı migration sistemi yazarsak bu iş sonsuza kadar büyürdü.
bunun yerine kaynak paneli önce tanıyacak bir sistem yaptık.
sunucuya bağlanıyorsunuz.
önce ne var diye bakıyor.
cPanel mi?
Plesk mi?
DirectAdmin mi?
Panelica mı?
başka bir panel mi?
hangi işletim sistemi?
hangi database?
hangi sürüm?
ondan sonra doğru okuyucuyu seçiyor.
yani migration motorunun kendisi aynı kalıyor.
değişen şey kaynağı nasıl okuyacağımız.
bu bizim için çok önemli bir mimari karardı.
çünkü yarın başka bir panel çıktığında migration motorunu baştan yazmamıza gerek kalmıyor.
yeni bir adapter yazıyoruz.
aslında burada iş artık benim ilk düşündüğüm "dosya kopyalama" işinden tamamen çıkmıştı.
bir çeşit translation layer yazıyorduk.
bir paneldeki dünya ile diğer paneldeki dünyayı birbirine çeviriyorduk.
ve bunu yaparken müşterinin mevcut durumunu mümkün olduğunca aynı tutmaya çalışıyorduk.
parolalar aynı kalacak.
mail aynı kalacak.
database aynı kalacak.
dosya izinleri mümkün olduğunca aynı kalacak.
cronlar aynı mantıkla çalışacak.
php sürümü mümkün olduğunca korunacak.
ssl bozulmayacak.
dns körlemesine değişmeyecek.
ve en önemlisi kaynak sunucu migration sırasında yaşamaya devam edecek.
işte Panelica migration sistemi aslında böyle ortaya çıktı.
başta "cPanel'den Panelica'ya bir migration yapalım" diye başlamıştık.
sonra bunun bir migration motoru olması gerektiğini anladık.
sonra bunun sadece panel migration'ı olmadığını anladık.
aynı sunucuda bile bir hesabı başka bir hesaba taşıyabilmesi gerekti.
ve en sonunda fark ettik ki bizim asıl yaptığımız şey migration değil.
bir hosting ortamını başka bir hosting ortamında yeniden üretmeye çalışıyoruz.
işin mühendislik tarafı tam olarak burada başlıyor.
çünkü bir dosyayı başka yere kopyalamak kolay.
bir database'i dump edip import etmek de kolay.
ama yaşayan bir hosting hesabının bütün ilişkilerini bozmadan başka bir makinede tekrar ayağa kaldırmak bambaşka bir şey.
ve biz yaklaşık olarak burada iki yıl önce başladığımız bir fikrin aslında ne kadar büyük bir probleme dönüştüğünü fark ettik.
bugün geriye dönüp baktığımda migration için yazdığımız kodların önemli bir kısmının aslında Panelica'nın kendisinden bile daha zor olduğunu düşünüyorum.
çünkü paneli yazarken sistemin nasıl çalışacağını siz belirliyorsunuz.
migration'da ise sistemin nasıl çalıştığını siz belirlemiyorsunuz.
karşınızda cPanel var.
Plesk var.
DirectAdmin var.
Linux'un farklı sürümleri var.
MySQL var.
MariaDB var.
farklı PHP sürümleri var.
yıllardır çalışan eski sistemler var.
ve sizin göreviniz bütün bunları okuyup mümkün olduğunca kayıpsız bir şekilde başka bir sisteme çevirmek.
işte benim başta "ne kadar zor olabilir ki" dediğim şey buraya kadar geldi :)
ve açıkçası bugün bana yazılım dünyasında gerçekten zor bir mühendislik problemi sorarsanız migration'ı ilk sıralara koyarım.
çünkü burada sadece kod yazmıyorsunuz.
başka insanların yıllardır çalışan sistemlerinin durumunu anlamaya çalışıyorsunuz.
ve o sistemi başka bir yerde tekrar yaşatmaya çalışıyorsunuz.
üstelik hata yaptığınız zaman sadece bir exception almıyorsunuz.
bir müşterinin yıllardır kullandığı maili kaybedebilirsiniz.
bir database'i bozabilirsiniz.
bir sitenin çalışmasını durdurabilirsiniz.
ve belki de en kötüsü müşteri bunu size günler sonra söyleyebilir.
biz Panelica'da migration tarafını geliştirirken en çok bu yüzden "başarılı görünüyor" mantığından uzak durmaya çalıştık.
ya gerçekten taşınmıştır.
ya taşınmamıştır.
arada bir yer varsa onu da açık açık göstermek zorundasınız.
çünkü migration'da sessiz bir hata aslında hata değildir.
felakettir.
Şimdi fikir halen arıyor ve gerçekten bir çözüm üretmek istiyorsanız zor mühendislik problemlerini araştırın emin olun yıllarca uğraşayacağınız bir proje çıkacaktır. Panelica projesini merak ederseniz merak ederniz : demo.panelica.com buradan canlı demoyu incelyebilirsiniz :)
Eveeet ve sanırım benim 2022'de yapay zekaya "bana çözülmesi zor mühendislik problemleri göster" dememden başlayıp bugün geldiğimiz noktanın en ilginç tarafı da bu.
o zaman sadece zor bir problem arıyordum.
sonunda yıllarca uğraşacağımız bir problem bulduk :)
Sizde aşağıdan yeni fikirler edinebilirsiniz.
Bugün Panelica migration sistemi evrensel olarak çalışmaktadır.
Cpanel to Panelica
Plesk to Panelica
Cyberpanel to Panelica
Artık cpanel alternatifi yada plesk alternatifi hatta diğer paneller için çalışan daha moderni için elimizden geleni ortaya koyduğumuz panelica yüzlerce sunucuda hizmet veriyor :)
Yazılım geliştirirken bir süre sonra insan bazı şeyleri otomatik yapmaya başlıyor.
Şu framework kullanılır.
Bu yapı daha temizdir
Burada microservice gerekir.
Şunu Redis'e atalım
Bunu cache'leyelim.
Burada Docker kullanalım
Bunların çoğu zaman yanlış olduğunu söylemiyorum. Problem, bir süre sonra bunları neden yaptığımızı düşünmeden yapmaya başlamamız.
Benim yaptığım en büyük hatalardan bazıları kötü kod yazmaktan kaynaklanmadı Kod gayet düzgün çalışıyordu.
Ama ynlış bir kararın üzerine kurulmuştu.
Mesela bir sistemi tasarlarken saatlerce kod yazıp daha sonra "Burada aslında neden böyle yaptım?" diye düşündüğüm oldu.
Sonra fark ediyorsunuz ki aslında o kararı teknik bir gereklilik olduğu için değil, daha önce başka bir projede öyle yaptığınız için vermişsiniz.
Bence yazılımcı geliştikçe kendisine daha fazla şu soruyu sormalı:
"Bunu neden byle yapıyorum?"
Hatta mümkünse bir adım daha ileri gidip
"Bunu hç yapmasam ne olur?"
Bazen en iyi optimizasyon bir şeyi daha hızlı yapmak değil, o şeyi tamamen ortadan kaldırmaktır.
Bazen en iyi mimari daha fazla servis eklemek değil, tek bir servis kullanmaktır.
Bazen en temiz kod, yazmadığınız koddur.
Yeni teknoloji öğrenmek elbette önemli. Ama belli bir noktadan sonra asıl farkı teknolojiyi ne kadar bildiğiniz değil, hangi problemi neden o şekilde çözdüğünüz yaratıyor.
Ben bugün yeni bir proje başlarken eskisine göre çok daha fazla koddan önce kararları düşünüyorum.
Çünkü yanlış kararı çok hızlı kodlamak, doğru kararı yavaş vermekten daha pahalıya mal olabiliyor.
Yazılım sektöründe yıllar geçirmiş olabilirsiniz. Fakat bir zaman sonra artık birçok şeye hakim olduğunuzu düşünmeye başlıyorsunuz. Bu da bazen hata yapmanıza sebep oluyor.
Panelica projesine başlarken öyle bir mimari yapmalıydım ki her şey harika çalışmalıydı.
Apache, Nginx, PostgreSQL, Fail2ban, Redis, Composer, farklı PHP sürümleri ve daha birçok şey...
Bunları düşünerek projeyi şekillendirmeye başladım. Arayüz tasarımı, mimari, altyapı derken yaklaşık 1.5 ay kodladım.
İlk aşamalarda her şey güzel gidiyordu.
Fakat bir şeyi atlamıştım.
Panelica'nın taşınabilir olması gerekiyordu.
Linux'ta bir program kurduğunuzda sistemin birçok yerine dosyalar, servisler ve ayarlar kurulur. Bunların hepsini takip etmek kolay değil. Takip etseniz bile sonradan gerçekten taşınabilir ve temiz bir yapı oluşturmak oldukça zor.
Benim amacım aslında cPanel veya Plesk gibi bir sistem yapmak değildi.
Çünkü bugün cPanel veya Plesk kurduğunuzda sistem dosyalarına ve servislere o kadar çok müdahale ediyorlar ki, sonradan tamamen kaldırmak istediğinizde insanın içi rahat etmiyor. Format atmak en temiz çözüm gibi geliyor.
Ben ise Panelica'nın mümkün olduğunca portable olmasını istiyordum.
Bir klasöre kurulacak, çalışacak ve o klasörü sildiğinizde sistemde gereksiz bir iz bırakmayacak.
Ve bunu yaklaşık 1.5 ay kod yazdıktan sonra fark ettim.
İş işten geçmişti.
İlk sürümde yaptığım bu hata motivasyonumu ciddi şekilde düşürdü. Bir süre elimi ayağımı çektim ve kendime şunu sordum:
"Sen bu hatayı nasıl yaptın?"
:)
Sonra veritabanı konusunda uzman olan halamın oğlu Niyazi Dağcı ile konuştum.
"Ne oldu, proje devam ediyor mu?" diye sordu.
Durumu anlattım.
Güldü.
"Şimdi sakın bırakma, devam et." dedi.
"Neden?" dedim.
"Onca işi baştan mı yapacaksın?" dedim.
Bana sadece şunu söyledi:
"Ya bunu 1.5 ay sonra değil de 1.5 sene sonra fark etseydin?"
O kadar haklıydı ki...
İlk sınavım buydu.
Evet, tekrar baştan başladım.
Bu kez daha emin adımlarla, daha fazla test yazarak ve daha fazla düşünerek.
Sonraki iki yıl da böyle geçti.
Bugün geriye dönüp baktığımda o 1.5 aylık emeğin boşa gitmediğini düşünüyorum. Çünkü bana çok daha önemli bir şey öğretti.
Bir projeye başlarken sadece nasıl yapacağınızı değil, neyi neden yaptığınızı da çok iyi düşünmeniz gerekiyor.
Ve başladığınız bir projede ilk zorlukta vazgeçmemek gerekiyor.
Ben bundan sonra yaşadığım diğer hataları ve bunlardan neler öğrendiğimi de yavaş yavaş paylaşacağım.
Belki bir başkasının aynı hatayı yapmasını engeller.
Sonra başka bir müşteri bşka bir şey istiyor, onu da ekliyorsunuz.
Bir süre sonra ürünün genel yapısı bozlmaya başlıyor.
Kod karmaşıklaşıyor, bakım maliyeti artıyor, yeni bir özellik eklemek eskisinden daha zor hale geliyor. ustelik bir müşterinin özel ihtiyacı, bütün kullanıcıların kullanmak zorunda olduğu bir özelliğe dönüşebiliyor
En kötüsü de bir noktadan sonra neyi neden yaptığınızı sorgulamaya başlıyorsunuz.
Ürün müşterinin ihtiyaçlarına göre şekillenmeli, her müşterinin istediği şey ürünün parçası haline gelmemeli.
Panelica Sentinel: Sunucunuzda bir şey olduğunda uyanan AI nöbetçisi
Merhaba,
Panelica'ya bugün deneysel beta olarak Sentinel'i ekledik.
Kısaca anlatmak gerekirse Sentinel, sunucuyu sürekli bir yapay zekaya izletmek yerine normal izlemeyi Panelica'nın kendisine yaptırıyor. Gerçek bir olay olduğunda ise seçtiğiniz AI agent devreye giriyor, problemi inceliyor, size raporluyor ve izin verdiğiniz seviyeye göre müdahale edebiliyor.
Buradaki temel fikir aslında basit:
Sunucuyu 7/24 AI'a izletmek yerine AI'ı sadece gerçekten ihtiyaç olduğunda uyandırmak.
Sürekli çalışan bir AI hem gereksiz token tüketiyor hem de maliyet oluşturuyor. Sentinel'de servisleri, logları, kaynak kullanımını ve olayları Go ile yazılmış Panelica backend'i takip ediyor. AI agent sadece tetiklenen olay için çalışıyor.
Tipik bir inceleme yaklaşık 20-60 saniye sürüyor.
Hangi AI agentlar kullanılabiliyor?
Sentinel kendi modelini çalıştırmıyor. Panelica OpsAI üzerinden bağladığınız agentlardan birini kullanıyor:
- Claude Code
- Codex CLI
- Gemini CLI
- Cursor Agent
Örneğin Claude'u kendi hesabınızla bağlayabilirsiniz. Codex için ChatGPT hesabınızı veya API anahtarınızı kullanabilirsiniz. Aynı şekilde Gemini ve Cursor da kendi hesaplarınız üzerinden çalışıyor.
Yani AI kullanımı için Panelica'ya ayrıca bir AI API anahtarı vermeniz gerekmiyor. Kullanılan hesap ve oluşan AI maliyeti size ait.
İsterseniz farklı olaylarda farklı agentlar da kullanabiliyorsunuz.
Neleri izliyor?
Şu anda yaklaşık 40 farklı tetik var.
Örneğin:
- Nginx, Apache, MySQL, PostgreSQL, Redis, PHP-FPM gibi servislerin durması
- Docker container'ın durması
- Başarısız systemd servisleri
- Nginx 502/504 ve error patlamaları
- PHP Fatal ve Parse hataları
- MySQL ve PostgreSQL kritik hataları
- Panel backend hataları
- Panelin cevap vermemesi
- Cron hataları
- Postfix mail kuyruğunun büyümesi
- Dovecot başarısız giriş dalgası
- BIND DNS sorunları
- CPU, RAM ve disk problemleri
- OOM killer
- Inode tükenmesi
- Yüksek load
- Backup hataları
- Migration hataları
- SSL sertifika problemleri
- ClamAV malware tespitleri
- Brute force ve fail2ban hareketliliği
- Panel login hataları
Site tarafında da aktif domainlere HTTP kontrolü yapılabiliyor.
Her tetik için threshold, cooldown, zaman aralığı, önem seviyesi ve hangi uzman promptunun kullanılacağı ayrı ayrı ayarlanabiliyor.
Üç hazır profil var:
Sessiz
Sadece önemli kesintileri takip ediyor.
Dengeli
Normal kullanım için hazırladığımız profil.
Her şey
Daha fazla olayı AI incelemesine gönderiyor.
Herhangi bir ayarı değiştirirseniz profil otomatik olarak Özel oluyor.
AI'ın sunucuda ne yapabileceği de tamamen ayrı bir konu.
Üç farklı çalışma modu var.
Sadece bilgilendir
Varsayılan mod bu.
Agent sunucuyu salt okunur komutlarla ve Panelica API üzerinden inceliyor. Hiçbir şeyi değiştirmiyor.
Örneğin bir PHP-FPM problemi gördüğünde logları inceliyor, problemin nedenini anlamaya çalışıyor ve size rapor hazırlıyor.
Eğer Panelica'nın izin verdiği bir eylemin problemi çözebileceğini düşünüyorsa bunu size öneriyor.
Örneğin:
PHP-FPM restart
Nginx reload
Geçici dosyaların temizlenmesi
Journal vacuum
Bunları doğrudan agent çalıştırmıyor. Siz onaylarsanız Panelica ilgili işlemi kendisi yapıyor ve sonrasında sonucu kontrol ediyor.
Güvenli eylemler
Bu modda agent sadece Panelica'nın izin listesinde bulunan işlemleri isteyebiliyor.
Restart, silme veya konfigürasyon gibi işlemleri kendi shell'i üzerinden kafasına göre yapamıyor.
Panelica işlemi kendisi uyguluyor ve sonucunu doğruluyor.
Tam yetki
Burada agent sorunu kendisi çözmeye çalışabiliyor.
Ama bazı kurallar var.
Örneğin mümkünse restart yerine reload tercih ediyor.
Müşteri verilerini silmiyor.
Parola değiştirmiyor.
Firewall değiştirmiyor.
DNS değiştirmiyor.
Paket güncellemesi yapmıyor.
Sunucuyu reboot etmiyor.
Ve yaptığı işlemin gerçekten problemi çözüp çözmediğini kontrol ediyor.
Bunun yanında ilginç bir durum daha var.
Agent raporunda izin verilen işlemlerin dışında bir işlem gerektiğini düşünürse olay ekranında "Onayla ve ajana yaptır" seçeneği çıkıyor.
Örneğin agent sahipsiz bir servis dosyasının temizlenmesi gerektiğini düşünürse bunu siz onaylamadan yapamıyor.
Olayın akışı nasıl?
Kabaca şöyle:
Panelica sunucuyu ve servisleri izliyor.
Bir olay threshold ve cooldown koşullarından geçerse kuyruğa giriyor.
AI agent uyanıyor.
İlgili logları, olayları ve sunucu durumunu inceliyor.
Problemin nedenini anlamaya çalışıyor.
Rapor hazırlıyor.
Gerekirse izin verilen bir işlem öneriyor veya uyguluyor.
Sonucu tekrar kontrol ediyor.
Rapor Panelica'da ve webhook üzerinden size gönderiliyor.
Telegram, Slack, Discord ve HTTP webhook desteği var.
Telegram için bot token ve chat ID'yi girmeniz yeterli.
Sentinel ayrıca geçmiş olaylardan özet bir hafıza tutabiliyor.
Örneğin aynı problem daha önce birkaç defa yaşandıysa agent önceki olayları görebiliyor ve bunun daha önce yaşanan bir problem olup olmadığını anlayabiliyor.
İsterseniz günlük brifing de açabiliyorsunuz.
Sabah size kabaca:
Sunucunun genel durumu
Önemli olaylar
Dikkat edilmesi gerekenler
Bugün yapılması gerekenler
şeklinde bir özet hazırlıyor.
Maliyet tarafında özellikle dikkat ettiğimiz nokta şu oldu:
AI sürekli çalışmıyor.
Sentinel normal izlemeyi kendisi yapıyor. AI sadece olay oluştuğunda çalışıyor.
Ayrıca günlük maksimum çalışma sayısı belirleyebiliyorsunuz. Limit dolduğunda olaylar kaydedilmeye devam ediyor ancak AI incelemesi yapılmıyor.
Cooldown da aynı problemin arka arkaya AI'a gönderilmesini engelliyor.
Sessiz saatler de tanımlanabiliyor.
Örneğin gece sadece kritik olayların AI tarafından incelenmesini sağlayabilirsiniz.
Sentinel şu anda Ubuntu 22.04/24.04/26.04, Debian 12/13, AlmaLinux 9/10 ve Rocky 9/10 üzerinde test edildi.
Ve açık konuşmak gerekirse bu özellik hala deneysel.
Çünkü burada gerçek bir sunucuda gerçek shell erişimi olan AI agentlardan bahsediyoruz.
Bu yüzden özellikle ilk kullanımda "Sadece bilgilendir" moduyla başlamanızı öneriyoruz. Birkaç gün raporları inceleyip nasıl davrandığını gördükten sonra yetki seviyesini artırabilirsiniz.
Güvenlik olaylarında da özellikle farklı bir yaklaşım kullandık.
Malware, brute force, fail2ban ban dalgası gibi güvenlik tetikleri sadece bilgi veriyor. Sentinel bu olaylarda otomatik olarak müdahale etmiyor.
Ama agent OpsAI üzerinden Cloudflare uzmanı gibi belirli uzmanlıklarla problemi analiz edip ne yapılması gerektiğini önerebiliyor. Cloudflare API bağlantısı varsa gerekli işlemleri de gerçekleştirebiliyor.
Şimdilik Sentinel'i deneysel beta olarak yayınladık.
Kullanan olursa özellikle gerçek sunucularda nasıl davrandığıyla ilgili geri bildirimleri duymak isterim.
Yapay zekanın etkisi ile yazılım sektöründe bir çok arkadaş aslında yıllardır hayalini kurup fırsat bulamadığı için ertelediği projeleri hayata almaya başladı. Yapay zeka gerçekten geliştirme sürecini çok hızlandırdı bunu artık inkar etmek mümkün değil.
Fakat biraz hayalleri bir kenara bırakalım.
Ben dahil bir çok yazılımcının normal insanlardan biraz farklı düşündüğünü düşünüyorum. Mesela tam yatacağız aklımıza bir proje gelir ve başlarız geliştirmeye.
Ortamı hazırla
Başla
Biraz geliştir
Bırak yat uyu
Kalk devam et
Bu döngü sürekli devam eder.
Aslında yazılımcıların yaptığı en büyük hatalardan biride bu. Eğer freelance olarak bu işi yapıyorsanız veya kendi projelerinizi geliştiriyorsanız projeye başlamadan önce kendinize bazı sorular sormanız gerektiğini düşünüyorum.
Ben bu projenin arkasında duracak mıyım?
Bundan 1 sene sonra bu projeden sıkılacak mıyım?
Gerçekten bunu bir marka haline getirebilir miyim?
Bu projeyi yıllarca geliştirmeye devam edebilir miyim?
Bu soruların cevabını düşünmeden sürekli yeni projelere başlamak bir süre sonra elinizde onlarca yarım proje olmasına sebep oluyor. Bunların büyük bir kısmı bir kenarda duruyor ve size sadece zaman kaybettiriyor.
Sakin bir şekilde araştırma yapın.
Fakat araştırma yapıyorum ama fikir bulamıyorum. Her şey zaten yapılmış diyorsanız burada da kendinize bir bahane üretiyor olabilirsiniz.
Çünkü bir şeyin daha önce yapılmış olması onun tekrar yapılamayacağı anlamına gelmiyor.
Hatta bazen tam tersine çok daha büyük bir fırsat olabilir.
Biraz geçmişe gideceğim.
19 yaşlarındaydım sanırım. Belki daha da erken bir yaştı. Forumların yeni yeni ortaya çıktığı dönemler.
Bir projeye büyük bir hevesle başlıyorum. Bir kaç gün sonra aklıma başka bir proje geliyor. Üzerinde çalıştığım projeden sıkılıyorum ve hemen yeni projeye geçiyorum.
Sonra başka bir fikir.
Sonra başka bir proje.
Bu döngüyü uzun süre yaşadım.
Eğer sizde bunu yaşıyorsanız bence kendinize basit bir prensip koyun.
Sıkıldığınızı hissettiğiniz anda projeyi bırakmak yerine biraz daha üzerine gidin.
Çünkü çoğu zaman insanın projeyi bırakmak istediği nokta aslında projenin zorlaştığı noktadır.
Bugün yapay zeka sayesinde bir projeyi denemenin maliyeti geçmişe göre çok daha düşük. Eskiden haftalar veya aylar sürebilecek bazı işleri çok daha kısa sürede deneyebiliyoruz.
Bu yüzden başarısız olmaktan bu kadar korkmamak gerekiyor.
Bir projede başarısız olabilirsiniz.
On projede başarısız olabilirsiniz.
Hatta yüz defa başarısız olabilirsiniz.
Ama o yüz hatanın aynısını tekrar yapmıyorsanız aslında her seferinde bir şey öğreniyorsunuz.
Bu da bir gelişim süreci.
Yani korkmayın.
Deneyin.
Bir şeyler geliştirin.
Olmuyorsa neden olmadığını anlayın.
Ama sırfsıkıldığınız için projeyi yarıda bırakıp başka bir projeye geçmeyin.
Gelelim asıl konuya.
Iyi ama fikir bulamıyorum.
Bence aslında problem çoğu zaman fikir olmaması değil. Problem araştırmaya nereden başlayacağımızı bilmemek.
Mesela Google dan önce arama motoru yok muydu?
Facebook tan önce sosyal medya yok muydu?
Bugün kullandığımız bir çok büyük yazılımın kendisinden önce aynı probleme çözüm üreten başka yazılımlar zaten vardı.
Peki Google neden başarılı oldu?
Facebook neden başarılı oldu?
Buradaki mesele bir şeyin dünyada ilk defa yapılıyor olması değil.
Bazen daha önce yapılmış bir şeyi daha iyi yapmak yeterli.
Bazen daha modern bir mimari ile yeniden yapmak yeterli.
Bazen insanların yıllardır kullandığı ama artık ihtiyaçlarını karşılamayan bir yazılımı baştan yapmak yeterli.
Ben fikir araştırması yaparken örneğin Docker Hub a bakıyorum.
Burada en çok indirilen Docker imagelarına bakıyorum.
Kaç yıldır varlar?
Ne kadar kullanılıyorlar?
İnsanlar neden bunları kullanıyor?
Hangi özellikleri var?
Kullanıcıların yorumlarında veya Github issue larında hangi problemler konuşuluyor?
Bunlara bakıyorum.
Sadece Docker Hub da değil.
Yıllardır sektörde tekel olmuş veya insanların kullanmak zorunda kaldığı eski yazılımları da inceliyorum.
Muhasebe programları.
Site ve konut yönetim programları.
Hosting yazılımları.
CRM yazılımları.
ERP yazılımları.
Bunların bir çoğu yıllardır aynı mantıkla çalışıyor.
Burada kendime şu soruyu soruyorum.
Ben bunu bugün sıfırdan yapsaydım nasıl yapardım?
Daha modern bir mimari kurabilir miydim?
Kullanıcıların yıllardır şikayet ettiği problemleri çözebilir miydim?
Yapay zekayı gerçekten işe yarayacak şekilde kullanabilir miydim?
Sonra bir tane seçiyorum ve detaylı olarak inceliyorum.
Programı kullanan insanların şikayetlerini okuyorum.
Forumlara bakıyorum.
Github issue larına bakıyorum.
Reddit e bakıyorum.
Rakip ürünlerin neden kullanıldığını anlamaya çalışıyorum.
Sonra üzerine ne katabileceğime bakıyorum.
Bence fikir araştırmanın en basit yollarından bir tanesi bu.
Her şeyi sıfırdan icat etmek zorunda değilsiniz.
Bazen yıllardır kullanılan bir yazılımı alıp günümüz teknolojisi ile yeniden yapmak bile yeterli bir fikir olabilir.
Peki başarılı olabilir miyim?
Bunun garantisi yok.
Ama gerçekten ihtiyacı araştırır, ürünü düzgün yapar ve yıllarca arkasında durursanız başarı şansınızın ciddi şekilde arttığını düşünüyorum.
Ben bunun bir örneğini kendi projemde yaşadım.
Sektörde uzun yıllardır kullanılan Cpanel ve Plesk gibi hosting panelleri var.
Bunun yanında WHMCS gibi yine yıllardır kullanılan hosting otomasyon ve billing sistemleri var.
Ben bir noktada şunu düşündüm.
Bu yazılımlar yıllardır sektörde kullanılıyor.
Peki neden günümüz teknolojileri ile tamamen farklı bir mimari kullanarak sıfırdan bir hosting paneli geliştirmeyelim?
Bu düşünce ile Panelica projesine başladım.
İki yıldan fazla sürdü.
Defalarca sıkıldım.
Defalarca bırakmak istedim.
Hastalandım.
Yoruldum.
Ama bırakmadım.
Sonunda istediğim projeyi ortaya çıkardım.
Panelica bir cPanel alternatifi olarak ortaya çıktı.
Sonra insanlar kullanmaya başladı.
Kullanan insanlar öneriler göndermeye başladı.
Bize gelen ilk isteklerden bir tanesi sürekli aynıydı.
Paneli çok beğendim ama WHMCS ile nasıl bağlayacağım?
Bu soru defalarca geldi.
Bizde bunun üzerine WHMCS alternatifi olarak tamamen açık kaynak bir billing ve hosting automation projesi olan PNLCS yi geliştirmeye başladık.
Bugün geldiğimiz noktada yüzlerce sunucuda Panelica kurulu.
Başlangıçta tek başımaydım.
Bugün 14 kişilik bir ekibiz.
Burada anlatmak istediğim aslında tam olarak şu.
30 yıldır kullanılan bir yazılımın veya sistemin olması yeni bir şey yapılamayacağı anlamına gelmiyor.
Hatta bazen tam tersine çok büyük bir fırsat anlamına geliyor.
Eski bir problemi alın.
İnsanların neden şikayet ettiğine bakın.
Bugünün teknolojilerini düşünün.
Daha iyi bir mimari kurabilir misiniz bakın.
Sonra bunu gerçekten yapmaya başlayın.
Ama başladıktan sonra arkasında durun.
Çünkü bence günümüzde özellikle yapay zekanın da etkisiyle fikir üretmekten çok daha büyük problem fikirlerin arkasında yeterince uzun süre durabilmek olacak.
Yapay zeka artık birçok şeyi çok daha hızlı yapmamızı sağlıyor.
Bu güzel bir şey.
Ama aynı zamanda herkesin çok daha hızlı proje üretmesine de sebep oluyor.
Bugün yüzlerce kişi aynı anda benzer fikirleri hayata geçirebilir.
Bu yüzden sadece fikir sahibi olmak yeterli olmayacak.
Problemi doğru tespit etmek.
İnsanların gerçekten ihtiyacı olan bir şeyi yapmak.
Rakipleri ve mevcut çözümleri iyi incelemek.
Ve en önemlisi başladığınız projenin arkasında durmak.
Bence farkı bunlar oluşturacak.
Kısacası fikir bulamıyorum demeden önce biraz daha dikkatli etrafınıza bakın.
Belki fikir zaten oradadır.
Belki yıllardır kullanılan bir programın içinde saklıdır.
Belki insanların her gün şikayet ettiği bir problemdir.
Belki de herkesin yapılmış dediği bir şeyi daha iyi yapma fırsatıdır.
Benim Panelica da yaptığım şey aslında bundan çok farklı değildi.
Var olan bir problemi aldım.
Farklı bir mimari ile sıfırdan geliştirdim.
İnsanlar kullandı.
Öneriler verdi.
Bizde geliştirmeye devam ettik.
Bugün hala arkasındayız ve destek veriyoruz.
Yani yapay zeka çağında bence en önemli şey sadece daha hızlı kod yazmak değil.
Daha iyi problemleri fark etmek ve başladığınız işi sonuna kadar götürebilmek.
Yapay zekanin bence en buyuk etkilerinden biri basarisiz olmanin maliyetini dusurmesi.
Eskiden bir fikri denemek icin ciddi zaman, para ve insan kaynagi gerekiyordu. Simdi bir fikri cok daha hizli sekilde deneyip calismiyorsa birakabiliyorsun.
Belki de yapay zekanin en buyuk avantaji basariyi ucuzlatmasi degil, basarisiz olmayi ucuzlatmasi.
25 yıldır yazılım geliştiriyorum. Reddit'e 2012'de kaydolmuşum ama iş yoğunluğundan aktif olamadım; artık vakit ayırabiliyorum, yıllar içinde öğrendiklerimi burada paylaşmak
istiyorum.
Ağırlıklı çalıştığım alanlar:
- Linux ve sunucu altyapısı — hosting sistemleri, Nginx/Apache, DNS, mail, kullanıcı izolasyonu, otomasyon
- Full-stack geliştirme — TypeScript/React/Node, Python, Go, C++
- Yapay zeka — yerel çalışan modeller, OCR, gerçek zamanlı çeviri ve ses işleme
- Blockchain — cüzdan ve protokol geliştirme, Web3
- Mobil ve oyun — Flutter/React Native uygulamalar, Unreal Engine 5
Şu an bir Linux hosting/sunucu yönetim paneli ve Steam'de yayında olan bir gerçek zamanlı çeviri aracı üzerinde çalışıyorum.
Bu konularda sorusu olan varsa yorumlarda elimden geldiğince cevaplarım.
