AI ile Üretim ve Katkı: Hız mı, Yük mü?

AI (yapay zeka) ile bir tarayıcı eklentisi, bir CLI (command-line interface) aracı ya da küçük bir web uygulaması yazmanın eşiği belirgin biçimde düştü. Hem kendi deneyimimde hem de geliştiricilerin LinkedIn ve X’te paylaştığı deneyimlerde, haftalarca sürebilecek geliştirme süreçlerinin kapsamına göre günlere, hatta saatlere kadar indiğini görüyorum. Bu, özellikle fikri olup kod yazma becerisi olmayanlar için gerçek bir kazanım. Öte yandan bu kolaylık bir yan etki de üretiyor: aynı problemi çözen, birbirine benzeyen ve bakımı tek bir kişiye kalan çok sayıda proje ve bu projelerin üreticiler ile geliştiriciler üzerinde oluşturduğu ek bilişsel yük ve darboğaz. Oysa ihtiyaç duyulan çözüm bir başkası tarafından yazılmış olabilir ve o projeye eklenecek bir özellik, sıfırdan açılacak yeni bir repodan daha uzun yaşayabilir, daha fazla fayda sağlayabilir ve iş yükünü en aza indirebilir.

Bu yazı AI ile ürün geliştirme sürecini üç eksende ele alıyor: üretim ucuzladığında kısıtın nereye kaydığı, yeni yazılan bir ürünün ya da aracın bulunabilirliği ve bu ürünün ya da aracın bakım maliyetinin ve gelir yönetiminin nasıl ele alınacağı. Referans gösterilen rakamların tamamı dış kaynaklardan edinildi; her birinin kaynağı dipnotta yer alıyor.

Üretim Ucuzladı, Kısıt Yer Değiştirdi

Kısıtlar teorisi (Theory of Constraints, TOC), bir sistemin çıktısını en zayıf halkasının belirlediğini söyler.¹

Lean Production’ın özetine göre kısıt olmayan adımları optimize etmek anlamlı bir fayda sağlamaz ve bir kısıt çözüldüğünde sıradaki kısıt hemen ele alınmalıdır.¹ Ürün geliştirmede kısıtlardan biri, genel anlamda bir fikri çalışan bir ürüne dönüştürmek için gereken zaman ve beceridir. Fiziksel ve dijital ürün geliştirme süreçlerinde temel parametreler aynı olsa da gereken becerinin kapsamı değişiyor. Dijital bir ürün geliştirmede ise uzun süre kısıtlardan biri kodlama becerisiydi.

Vibe coding olarak anılan yaklaşım ve AI kodlama agent’ları ile dijital ürün geliştirmede kodlama adımı ucuzladı. Dolayısıyla, TOC bağlamında değerlendirildiğinde beklenen sonuç, kısıtın başka bir yere kayması olacaktır. Faros AI’ın iki telemetri raporu, geliştirici başına birleştirilen PR (pull request) sayısıyla birlikte değişen diğer metrikleri de gösteriyor.²

Metrik (geliştirici başına)	2025 raporu, 10.000+ geliştirici	2026 raporu, 22.000 geliştirici
Tamamlanan görev	+%21	+%33.7
Birleştirilen PR	+%98	+%16.2
PR boyutu	+%154	+%51.3
PR review’da geçen süre	+%91	+%441 (medyan)
Bug	+%9	+%54

Faros’un kendi telemetrisine ait bu rakamlar, şirketin DORA 2025 raporunu özetleyen yazısında yer alıyor.²

Evet, kod üretimi hızlandı. Ancak üretilen kodun okunması, anlaşılması ve doğrulanması bu hıza eşlik edemedi. 2026 verisinde review süresindeki artışın birleştirilen PR artışından çok daha büyük olması, kısıtın review’a kaydığına işaret ediyor. Bu bir nedensellik kanıtı değil elbette. Telemetri, bu değişimin sebebini değil, AI kullanımı ile review süresi arasındaki ilişkiyi gösteriyor.

Aynı rapor, düşük AI kullanımından yüksek AI kullanımına geçen ekiplerde bilişsel yüke işaret eden metrikleri de ölçüyor. Geliştiricinin gün içinde dokunduğu PR sayısı %67.4, geçiş yaptığı görev sayısı %17.7 arttı. Başka bir aşamadan yeniden in-progress durumuna dönen işler %13.8, 7 gün ya da daha uzun süredir PR ya da aktivite görmeyen işler %26 yükseldi.²

“The picture is of a development environment where it is easy to begin and hard to finish.”²

Algı ile Ölçüm Arasındaki Fark

DORA’nın 2025 raporu ile Faros’un 2026 raporu bu noktada ayrışıyor. DORA, yaklaşık 5.000 teknoloji profesyoneliyle yaptığı ankete dayanarak AI’ı yüksek performanslı organizasyonların güçlü yanlarını, zorlanan organizasyonların aksaklıklarını büyüten bir amplifier olarak tanımlıyor. Rapora göre AI kullanımı artık delivery throughput’u iyileştiriyor, ama delivery instability’yi hâlâ artırıyor.³ Faros ise DORA’nın güçlü mühendislik temellerinin AI’ın olumsuz etkilerine karşı koruma sağladığı yönündeki sonucunu kendi telemetrisinin desteklemediğini, yüksek performanslı organizasyonların da review ve production aşamalarında aynı bozulmayı yaşadığını söylüyor. Farkı da yönteme bağlıyor: anket geliştiricilerin ne hissettiğini ölçüyor, review kuyruklarında ve production’da biriken etki ise bu hisse ancak aylar sonra yansıyor.² İki rapor throughput’un arttığı ve stabilitenin bozulduğu konusunda aynı yönü gösteriyor, ayrıştıkları nokta güçlü ekiplerin bundan korunup korunmadığı. Bu soruyu yanıtlayan bağımsız bir veri bulamadım; DORA’nın kanıtı ankete, Faros’unki kendi platformundaki ekiplerin telemetrisine dayanıyor.

METR tarafından 2025 başında yürütülen randomize kontrollü çalışmada 16 deneyimli açık kaynak geliştirici, ortalama 22.000’den fazla yıldızlı ve 1 milyondan fazla satır kod içeren, yıllardır katkı verdikleri projelerde 246 gerçek issue üzerinde çalıştı. AI araçlarına izin verilen görevler %19 daha uzun sürdü. Geliştiriciler önceden %24 hızlanma bekliyordu, çalışma bittikten sonra da %20 hızlandıklarını düşünüyordu.⁴

Bu sonucun güncel AI araçları için de geçerli olduğunu söylemek pek mümkün değil. Nitekim METR, Şubat 2026’da yeni deneyinin verisini güncel etkiye dair “güvenilmez bir sinyal” olarak nitelendirdi:

“we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools.”⁵

Geliştiricilerin %30 ile %50’si bazı görevleri AI kullanmadan yapmak istemedikleri için göndermediklerini bildirdi ve METR bu seçilimin hızlanma tahminini muhtemelen aşağı çektiğini belirtiyor.⁵

Çalışmadan ders olarak bir hızlanma oranı değil, geliştiricinin kendi hızına dair algısı ile ölçüm arasındaki fark alınabilir. Bu duruma dair yorumum, büyük ve olgun bir kod tabanında bağlamı kurmanın ve çıktıyı doğrulamanın maliyetinin kod yazımının önüne geçebildiği yönünde.

Herkes Yazınca Kim Buluyor?

Kısıtın kaydığı ikinci yer dağıtım. Amit Prakash Sharma’nın Ocak 2026’da yayımlanan ön baskısında, 2025 Product Hunt sıralamasının ilk 500’ünden seçilen 112 girişim için ChatGPT’ye (gpt-4o-mini) ve Perplexity’ye (sonar) toplam 2.240 sorgu gönderildi.⁶ Sonuçlar:

• Ürün adıyla sorulduğunda iki LLM (Large Language Model) de ürünleri neredeyse her seferinde tanıdı: ChatGPT %99.4, Perplexity %94.3.
• “Bu yıl çıkan en iyi AI araçları” türünden açık uçlu keşif sorularında oran ChatGPT’de %3.32’ye, Perplexity’de %8.29’a indi.
• GEO (Generative Engine Optimization) puanları ile keşfedilme oranı arasında korelasyon bulunmadı.
• Perplexity’de referans veren alan adı sayısı ve Product Hunt sıralaması görünürlükle ilişkili çıktı; Reddit verisindeki yanlış eşleşmeler temizlendikten sonra topluluk varlığı da anlamlı hale geldi.

Bu, tek bir ön baskıya, iki modele ve gözlemsel veriye dayanan bir çalışma. Dış referansların LLM önerisine doğrudan yol açtığını göstermiyor.

Product Hunt’ın ilk 500’ündeki bir ürün bile genel bir keşif sorusunda nadiren öne çıkıyorsa, yeni açılmış ve topluluğu olmayan bir repo için durumun daha zor olduğunu düşünüyorum. Doğrulamadım ama tahmin yürütürsem, aktif bir projeye eklenen bir özellik o projenin referanslarını, dokümantasyonunu ve kullanıcı topluluğunu hazır bulur. Bu açıdan katkı vermek aynı zamanda bir dağıtım kararı.

Katkı vermeyi bir prestij olarak görmek de mümkün. LinkedIn ve X’te ara ara büyük projelere yapılan katkıları onaylanan geliştiricilerin sevinçlerini görüyorum. Elbette geliştiricinin kendi adına öne çıkma isteğini de anlayabiliyorum ama soru şu: bedeli ne olacak?

Darboğaz Maintainer’da

Üretimin ucuzlaması, açık kaynakta yükü katkı verenden maintainer’a taşıyor. Dagster ekibi Nisan 2026’daki yazısında durumu şöyle özetliyor: değişiklikler kapsamlı biçimde review edilmekten daha kolay üretilir hale geliyor, ama bir PR’yi review etmek hâlâ bağlam, muhakeme ve koordinasyon gerektiriyor.⁷ Yazıda sayılan sürtünme noktaları şöyle:

• CI’ın (continuous integration) geçmesi, değişikliğin kod tabanının konvansiyonlarına ve kalite çıtasına uyduğunu göstermiyor.
• İşlevsel olarak doğru PR’ler bile repo konvansiyonlarına uymak için birkaç review turu gerektirebiliyor.
• Geniş kapsamlı AI prompt’ları büyük ve bağlamı zayıf diff’ler üretiyor.
• Çekirdek framework değişiklikleri daha fazla tasarım bağlamı ve koordinasyon istiyor.

AI ile üretilen kodun hangi kalıpları taşıdığına dair veri de review yükünün nereden geldiğini gösteriyor. InfoQ’nun aktardığı OX Security raporu “Army of Juniors”, AI üretimi kodda tekrar eden anti-pattern’leri görülme sıklığıyla listeliyor.⁸

Anti-pattern	Raporda verilen sıklık
Comments Everywhere	%90-100
Avoidance of Refactors	%80-90
By-the-Book Fixation	%80-90
Over-Specification	%80-90
Bugs Déjà-Vu	%80-90

Katkı veren kişi bu kalıpları göndermeden önce ayıklamadığında, her biri maintainer’ın review’da yakalaması gereken bir işe dönüşüyor. Bu konuya dair geliştiriciler tarafından paylaşılan pek çok X gönderisine sık sık denk geliyorum.

Maintainer’ın Zamanını Koruyan Bir Katkı

Dagster’ın PR biçimine dair önerileri:⁷

• Tek PR, tek ve açık bir problem.
• Az dosya; birden fazla ekibin alanına yayılmayan bir değişiklik.
• Doğru alanı seçmek: dokümantasyon, örnekler ve topluluk entegrasyonları birleştirilmenin en hızlı yolu, çekirdek framework değişiklikleri daha uzun sürüyor.

Bunlara ek olarak, AI ile çalışan ve bir projeye katkı sunmayı düşünenler için kendi deneyimlerim bağlamında naçizane önerilerim şöyle olurdu:

• Diff’i göndermeden önce satır satır okumak. Gönderenin açıklayamadığı bir satır, review’da maintainer’ın sorusuna dönüşür.
• Büyük bir değişiklikten önce bir issue ya da tartışma açıp yönü maintainer ile netleştirmek. GitHub tarafında bunun pek hızlı ilerleyen bir süreç olmadığını, kimi zaman bir issue’ya hiç yanıt gelmeyebildiğini söyleyebilirim.
• Projenin contributing rehberini ve varsa agent talimat dosyasını AI aracına bağlam olarak vermek.

Yazmadan Önce: Bu Problem Zaten Çözülmüş mü?

Tekrar eden gerçek bir sürtünmeden çıkan araçlara bir örnek MyWorks. Acquire.com’daki yazıya göre kurucusu Peter Leonard, WooCommerce siteleri kuran bir ajans işletiyormuş. İş büyüdükçe muhasebe ve satış sistemlerini eşleştirmek giderek daha fazla saat almış ve tam zamanlı bir işe dönüşmüş.⁹

“We started building the software for ourselves, but after months of listening to customers, we realized this would be a huge time-saver for them, too. We began to plan our roadmap around their needs and not our own.”⁹

Yazılımı önce kendi ekipleri için yazmışlar, müşterileri aylarca dinledikten sonra aynı sorunun onlarda da olduğunu fark etmişler.⁹ Aynı yazıda bir ayrım daha var: Leonard, rakiplerin uygulamalarını geliştiriciler için yapmış göründüğünü, kendilerinin ise sorunu yaşayan insanlar için yaptığını söylüyor. Leonard’ın hikayesini kendi anlatımından dinlemek isteyenler için iki röportaj var: satış sürecini anlattığı saas.unbound bölümü (Nisan 2023) ve satış sonrasını konuştuğu Sounds Good bölümü (Eylül 2026).

Leonard’ın anlattıklarındaki iki nokta, yeni bir araç yazma kararının iki meşru gerekçesini veriyor: ihtiyaç gerçek ve mevcut çözümler farklı bir kullanıcıya hitap ediyor. İkisi de yoksa yeni bir repo açmanın gerekçesi zayıflıyor. Ekibi ürünü geliştirirken Leonard da benzer bir ürünün pazarda olup olmadığını görmek için e-ticaret uygulama mağazalarını incelemiş.⁹ Başlamadan önce bakılabilecek yerler:

• Paket ve eklenti dizinlerinde (npm, PyPI, Chrome Web Store) ve GitHub’da, aracın adıyla değil çözdüğü işle arama.
• İlgili awesome listeleri ve ekosistemin kendi dizinleri.
• Aday projelerin issue takipçisinde aynı özellik talebi. Açık bir talep varsa katkının yeri hazır demektir.
• Son commit ve release tarihi, açık PR’lere verilen yanıt süresi.
• Lisans: katkıya, fork’a ve ticari kullanıma ne ölçüde izin verdiği.

Bu kontrollerin bir kısmını otomatikleştiren servisler var:

• Open Source Insights (deps.dev): Google’ın geliştirdiği servis; Cargo, Go, Maven, npm, NuGet, PyPI ve RubyGems paketleri için bağımlılık grafiğini, lisansları, bilinen güvenlik açıklarını ve sürüm geçmişini gösteriyor.¹⁰
• OpenSSF Scorecard: Bir repoyu bakım, lisans ve güvenlik pratiklerine dair bir dizi kontrolle 0 ile 10 arasında puanlıyor. Maintained kontrolü son 90 gündeki haftalık commit’lere ve maintainer’ların issue aktivitesine bakıyor; 90 günden genç projeler bu kontrolden geçemiyor. Düzenli taranan projelerin sonuçları kurulum gerektirmeden görüntülenebiliyor.¹¹
• ecosyste.ms: 110 kaynaktan 15 milyonu aşkın paketin ve 349 milyon reponun meta verisini açık veri seti olarak sunuyor.¹²

Scorecard’ın dokümantasyonu bir uyarı da içeriyor: aktif bakımın olmaması her zaman sorun değil; özellikle küçük yardımcı kütüphaneler normalde bakım gerektirmeyebilir.¹¹ Bunu ben yakın zamanda Inspect Signals eklentisi için kullanmayı değerlendirdiğim d3-sankey reposu ile deneyimledim. Yani son commit tarihi tek başına bir eleme ölçütü değil, daha yakından bakma işareti.

Bu servisler aday bir projenin sağlığını ölçüyor, ama adayı bulmuyor. İhtiyacı çözen projeyi bulmak hâlâ dizinlerde ve issue takipçilerinde işe göre arama yapmayı gerektiriyor. Bir AI aracına sormak da bir yol, ama Discovery Gap çalışmasında ürünler açık uçlu sorularda nadiren önerildi. Aynı sınırın küçük açık kaynak projeler için de geçerli olduğunu varsayıyorum; bunu ölçen bir veri bulamadım.

Bulunabilir Bir Proje için Ne Yapılabilir?

Soru tersinden de sorulabilir: yeni bir araç yazıldıysa ya da mevcut bir proje katkı bekliyorsa, katkı verecek geliştiricinin ve bir arama motoru ya da AI aracıyla arama yapan kullanıcının onu bulması için ne yapılabilir? Discovery Gap çalışması bu soruya kısmen yanıt veriyor. Perplexity’de görünürlükle ilişkisi ölçülen sinyallerden bazıları:⁶

Sinyal	Perplexity görünürlüğüyle korelasyon (r)
Farklı subreddit sayısı (temizlenmiş)	+0.405
Reddit’te anılma (temizlenmiş)	+0.395
Referans veren alan adı sayısı	+0.319
Dofollow link oranı	+0.238
GEO puanı	Anlamlı ilişki yok
GitHub yıldızı ve Hacker News	Anlamlı ilişki yok

Reddit satırları, genel isimleri yüzünden yanlış eşleşme üreten 52 ürün çıkarıldıktan sonra kalan 60 ürünle hesaplandı. ChatGPT’de ise bu sinyallerin hiçbiri anlamlı çıkmadı; yazara göre ChatGPT’de keşif “esasen rastgele” görünüyor. Yazar GEO’nun etkisizliğini, var olan bir görünürlük tabanı olmadan işe yaramayan bir çarpan olarak yorumluyor ve doğrudan AI keşfi için optimize etmek yerine önce SEO (Search Engine Optimization) temelini kurmayı öneriyor.⁶

Bu bulguları okurken iki sınırı akılda tutmak gerekiyor. Çalışma açık kaynak repoları değil, Product Hunt ürünlerini ölçüyor. GitHub yıldızının anlamlı çıkmaması bir repo için aynı sonucu vermeyebilir. AEO (Answer Engine Optimization) için de ayrı bir ölçüm yok. Bir landing page ya da dokümantasyon sitesi, başka sitelerin link verebileceği ve projenin çözdüğü işle aranabilecek bir adres sağlıyor; ama bunun keşfe etkisini ölçen bir veri bulamadım, bu bir yorum.

Kısır döngü sorusunun yanıtı da aynı çalışmada var. Yazar, eğitim verisinin yerleşik oyuncuları fazla temsil ettiğini ve bunun AI görünürlüğünde zenginin daha da zenginleştiği bir “otorite yoğunlaşması” yarattığını söylüyor.⁶ Benim yorumum şu: referansı ve topluluğu olmayan yeni bir proje önerilmiyor, önerilmediği için de referans ve topluluk kazanması zorlaşıyor. Korelasyonlar bu döngünün mümkün olduğunu gösteriyor, varlığını kanıtlamıyor. Mevcut bir projeye katkı vermek ise bu döngünün dışından başlamak anlamına geliyor.

Projeyi katkı verecek geliştiricinin bulması tarafında ise maintainer’ın yapabileceği işler daha net:

• Konu etiketleri: GitHub, repoya topic eklemeyi başkalarının projeyi bulup katkı vermesine yardım eden bir yol olarak sunuyor.¹³
• good first issue etiketi: Etiketle arama yapanların bu issue’ları bulmasını sağlıyor; GitHub’a göre etiket, issue’ların platformda öne çıkarılma olasılığını da artırıyor.¹⁴
• Katkı rehberi ve araçlar: Dagster kod ve dokümantasyon için ayrı katkı rehberleri tutuyor, PR’lere repodaki mevcut kalıplara dayalı öneriler veren Greptile gibi otomatik review araçları ekliyor ve AI ile çalışan katkı verenlere daha tutarlı ve review edilebilir değişiklik üretmeleri için Dignified Python adlı bir skill öneriyor.⁷
• Güncel README, ADR ve spec: Bu madde kaynaktan değil, yorumumdan geliyor. Neyin neden böyle yapıldığını anlatan güncel bir README, ADR’ler (Architecture Decision Record) ve spec’ler, projeye dışarıdan gelen birinin ve onun kullandığı AI aracının bağlamı kurmasını kolaylaştırıyor. Bu dokümantasyonu AI agent’ları için yapılandırmanın bir yolunu Living Architecture yazısında, karar kayıtlarını ise ADR ve OpenSpec yazısında anlatmıştım.

Karar Tablosu

Durum	Yol	Gerekçe
Aktif bir proje ihtiyacın büyük kısmını karşılıyor, bir özellik eksik	Katkı	Özellik projenin kullanıcılarına ve dağıtımına eklenir, bakım paylaşılır
Proje aktif, ama istenen değişiklik projenin yönüyle uyuşmuyor	Plugin ya da ayrı küçük bir araç	Maintainer’ın kapsamı dışındaki iş için PR yükü yaratmamak
Proje terk edilmiş, lisans fork’a izin veriyor	Fork	Bakım artık fork’u alanın üzerinde; bu yük baştan kabul edilmeli
Mevcut çözümler farklı bir kullanıcıya hitap ediyor	Yeni araç	MyWorks örneğindeki ayrım: geliştirici için yazılmış araç ile sorunu yaşayan kişi için yazılmış araç
İhtiyaç tek bir iş akışına özgü	Yayınlanmayan yerel bir script	Yayınlanan her araç bir bakım ve destek taahhüdü

Gelir ve Sürdürülebilirlik

Bence yeni bir aracın maliyeti zaman içerisinde netleşerek bir zemine oturuyor. AI yazım maliyetini düşürdü (aylık kahve tüketimine eşdeğer bir abonelik ücreti), ama issue’lara yanıt vermek, bağımlılıkları güncel tutmak, güvenlik açıklarını kapatmak ve kullanıcıya destek vermek hâlâ zaman istiyor ve bilişsel bir yük oluşturuyor. On küçük proje, on ayrı bakım taahhüdü demek ve solo bir geliştiricide bu taahhütlerin hepsi aynı kişinin üzerinde birikiyor. Bunlara gelir edinme stresi ve sabit maliyetler de ekleniyor.

Açık kaynağın gelir ürettiği örneklerde ortak bir desen görünüyor:

• Langfuse: ClickHouse’un Ocak 2026’daki satın alma duyurusuna göre çekirdek özellikler MIT lisanslı ve bu lisans production ölçeğinde self-hosting’e izin veriyor. Projenin 20.000’den fazla GitHub yıldızı ve Langfuse Cloud müşterileri var.¹⁵ Satın almada Langfuse’a danışmanlık veren Orrick, şirketin 2.000’den fazla ödeme yapan müşterisi olduğunu belirtiyor.¹⁶
• Dagster: Açık kaynak projeyi ve ticari Dagster+ ürününü tek bir monorepo ve tek bir geliştirme modeli altında topladı.⁷

İki örnekte de çekirdek açık. Barındırma, yönetilen servis ve kurumsal kullanım ise ücretli. Bu desen bir ekip, bir şirket yapısı ve kurumsal müşteri gerektiriyor. Tek kişinin bakımını yaptığı bir tarayıcı eklentisinin ya da CLI aracının bu yapıyı kurmasının istisna olduğunu varsayıyorum; bunu ölçen bir veri bulamadım.

Katkı veren geliştirici için getiri doğrudan bir gelir değil. Discovery Gap çalışmasında görünürlükle ilişkili çıkan sinyaller referans veren alan adları ve topluluk varlığıydı. Bilinen bir projenin commit geçmişinde yer almak, keşfedilmeyen yeni bir repodan daha görünür bir referans olabilir. Bu da bir yorum. Katkının iş ya da müşteri getirdiğini gösteren bir kaynak, bu yazının dayandığı veriler içinde yok.

Kullanıcı tarafında da bir pay var. Kullanılan açık kaynak bir aracın yaşamasına katkı vermenin yolu varsa ücretli planını kullanmak, hata bildirmek ya da projeyi doğrudan desteklemek; onu yeniden yazmak değil.

Karar Sırası

1. İhtiyacı aracın adıyla değil, çözdüğü işle tanımlamak.
2. Paket ve eklenti dizinlerinde, GitHub’da ve aday projelerin issue takipçilerinde aramak.
3. Aktif bir proje varsa issue açmak, yönü maintainer ile netleştirmek ve küçük bir PR göndermek.
4. Proje terk edilmişse fork’un bakım yükünü baştan hesaplamak.
5. Yeni bir araca ancak ihtiyaç farklı bir kullanıcıya ya da farklı bir probleme aitse başlamak ve dağıtımı kodla birlikte planlamak.

AI’ın kod yazımını herkese açması, yazılımın etrafındaki işleri de görünür kıldı: review, dağıtım, bakım ve gelir. Kısıt artık bu alanlarda olduğuna göre, bir sonraki araç fikrinde ilk soru “bunu nasıl yazarım” değil, “bu zaten var mı ve ona nasıl katkı verebilirim” olabilir.

İlgili Yazılar

• Decision Gate: Vibe Coding’in Eksik Parçası
• AI Coding Agent’lar İçin Context Engineering: Statik Dokümanlardan Yaşayan Ekosisteme
• AI Destekli Codebase Audit: Solo Girişimci İçin Production-Grade Yaklaşım

Footnotes

1. Theory of Constraints (Lean Production). “spending time optimizing non-constraints will not provide significant benefits” ve “once a constraint is resolved the next constraint should immediately be addressed.” ↩ ↩²
2. Key Takeaways from the DORA Report 2025 (Faros AI). 2025 rakamları Faros’un 10.000’den fazla geliştiriciyi kapsayan “The AI Productivity Paradox” telemetri analizinden, 2026 rakamları 22.000 geliştiriciyi kapsayan AI Engineering Report 2026: The Acceleration Whiplash (Faros AI) raporundan geliyor; bilişsel yük rakamları ve alıntı raporun 8-9. sayfalarında. DORA ile ayrıştığı bölüm 5. sayfada: “Our telemetry data, drawn from engineering systems across thousands of teams, does not support that as a protective factor.” “Median time in PR review is up 441%, compared to 91% in our 2025 dataset.” DORA raporu için: “arrived with survey data from nearly 5,000 developers worldwide to complement the picture.” ↩ ↩² ↩³ ↩⁴ ↩⁵
3. 2025 DORA State of AI-assisted Software Development (Google Cloud). Alıntılar raporun 3-4. sayfalarında. “AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” ve “AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability.” ↩
4. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR). 10 Temmuz 2025. ↩
5. We are Changing our Developer Productivity Experiment Design (METR). 24 Şubat 2026. “we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools.” ↩ ↩²
6. The Discovery Gap: How Product Hunt Startups Vanish in LLM Organic Discovery Queries (arXiv:2601.00912). Amit Prakash Sharma, 1 Ocak 2026, ön baskı. ↩ ↩² ↩³ ↩⁴
7. Making Dagster Easier to Contribute to in an AI-Driven World (Dagster). 1 Nisan 2026. “reviewing a PR still takes context, judgment, and coordination.” ↩ ↩² ↩³ ↩⁴
8. AI-Generated Code Creates New Wave of Technical Debt, Report Finds (InfoQ). Patrick Farry, 18 Kasım 2025. Yazı, OX Security’nin “Army of Juniors: The AI Code Security Crisis” raporunu aktarıyor. ↩
9. How I Got Acquire’d: Listen to Customers Inside and Outside of Your Business, Says Founder of MyWorks (Acquire.com). “Our competitors seemed to build their apps for developers, not the people suffering the problem.” ve “Meanwhile, he researched ecommerce app stores to see if anything like it existed in the market.” ↩ ↩² ↩³ ↩⁴
10. Frequently Asked Questions (Open Source Insights). “Open Source Insights is a service developed and hosted by Google to help developers better understand the structure, security, and construction of open source software packages.” ↩
11. OpenSSF Scorecard (GitHub) ve kontrol tanımları için Scorecard Checks. “However, a lack of active maintenance is not necessarily always a problem.” ↩ ↩²
12. ecosyste.ms. “Tools and datasets to support, sustain, and secure critical digital infrastructure.” ↩
13. Classifying your repository with topics (GitHub Docs). “To help other people find and contribute to your project, you can add topics to your repository” ↩
14. Encouraging helpful contributions to your project with labels (GitHub Docs). “Adding the good first issue label can increase the likelihood that your issues are surfaced.” ↩
15. ClickHouse welcomes Langfuse (ClickHouse). 16 Ocak 2026. “Langfuse remains 100% open-source under its existing MIT license for core features.” ↩
16. Open source LLM Observability Langfuse Acquired by ClickHouse Inc (Orrick). 26 Ocak 2026. “more than 2,000 paying customers.” ↩

Önemli Noktalar

• 01 Kısıtlar teorisine göre kısıt olmayan bir adımı hızlandırmak sistemin çıktısını artırmaz; AI ile kod üretimi hızlandıkça kısıt review, doğrulama ve bakıma kayıyor.
• 02 Faros AI'ın telemetri raporlarında geliştirici başına birleştirilen PR sayısıyla birlikte PR boyutu ve review süresi de arttı; 2026 verisinde medyan review süresi %441 yükseldi.
• 03 Product Hunt'ın ilk 500'ünden 112 ürünle yapılan bir çalışmada ChatGPT bu ürünleri açık uçlu keşif sorularında yalnızca %3.32 oranında önerdi; Perplexity'de topluluk varlığı ve referans veren alan adları görünürlükle ilişkili çıktı, GEO puanı çıkmadı.
• 04 Katkı vermek, PR açmaktan çok maintainer'ın review zamanını korumaktır: tek problem, az dosya, repo konvansiyonlarına uyum.
• 05 Açık kaynağın gelir ürettiği Langfuse ve Dagster örneklerinde çekirdek açık, barındırma ve kurumsal kullanım ücretli kalıyor.

Sık Sorulan Sorular (FAQ)

+ AI ile kendi aracımı yazmak mı, mevcut bir projeye katkı vermek mi daha mantıklı?

Aktif bir proje ihtiyacın büyük kısmını karşılıyor ve yalnızca bir özellik eksikse katkı vermek genellikle daha az maliyetlidir; özellik projenin kullanıcılarına ve dağıtımına eklenir, bakım paylaşılır. Mevcut çözümler farklı bir kullanıcıya hitap ediyorsa ya da proje terk edilmişse yeni bir araç veya fork daha uygun olabilir. Yazıdaki karar tablosu bu durumları ayırıyor.

+ AI ile üretilmiş bir PR'yi açık kaynak bir projeye göndermek sorun mu?

Tek başına sorun değil. Sorun review maliyeti: Dagster'ın belirttiği gibi değişiklikler kapsamlı biçimde review edilmekten daha kolay üretilir hale geliyor. Tek bir problemi çözen, az dosyaya dokunan, repo konvansiyonlarına uyan ve gönderen kişinin satır satır okuduğu bir PR, maintainer'ın yükünü belirgin biçimde artırmaz.

+ Yeni yazdığım araç neden bulunmuyor?

Discovery Gap çalışmasında Product Hunt'ın ilk 500'ündeki ürünler bile açık uçlu keşif sorularında ChatGPT'de yalnızca %3.32 oranında önerildi. Perplexity'de görünürlükle ilişkili çıkan sinyaller referans veren alan adları ve topluluk varlığıydı, GEO puanı ise ilişkili çıkmadı. Yeni bir repo bu sinyallere sıfırdan başlar; mevcut bir projeye eklenen özellik ise o projenin referanslarını ve topluluğunu hazır bulur.

+ Açık kaynak bir araçtan gelir elde etmek mümkün mü?

Mümkün, ama örneklerde belirli bir desen var. Langfuse çekirdek özelliklerini MIT lisansıyla açık tutarken Langfuse Cloud üzerinden ücretli müşterilere hizmet veriyordu ve Orrick'e göre 2.000'den fazla ödeme yapan müşterisi vardı. Dagster açık kaynak projeyi ticari Dagster+ ürünüyle aynı geliştirme modelinde yürütüyor. Bu desen bir ekip ve kurumsal müşteri gerektiriyor; tek kişilik küçük bir eklentide aynı yapıyı kurmak zor.

+ Bir açık kaynak projenin bakımının sürüp sürmediğini nasıl anlarım?

OpenSSF Scorecard'ın Maintained kontrolü son 90 gündeki haftalık commit'lere ve maintainer'ların issue aktivitesine bakıyor; Google'ın Open Source Insights (deps.dev) servisi ise paketlerin lisanslarını, bilinen güvenlik açıklarını ve sürüm geçmişini gösteriyor. Scorecard dokümantasyonu aktif bakımın olmamasının her zaman sorun olmadığını da belirtiyor; küçük yardımcı kütüphaneler bakım gerektirmeyebilir.

+ Projemi katkı verecek geliştiricilerin bulması için ne yapabilirim?

GitHub, repoya topic eklemeyi ve good first issue etiketini kullanmayı projenin bulunmasını kolaylaştıran yollar olarak sunuyor. Dagster ise kod ve dokümantasyon için ayrı katkı rehberleri tutuyor ve AI ile çalışan katkı verenlere repodaki kalıplara uygun değişiklik üretmeleri için bir skill öneriyor.