Yapay zeka açık kaynak geliştiricilerini yavaşlatıyor. Peter Naur bunun nedenini açıklayabilir

• Son araştırmalara göre açık kaynak geliştiricileri iyi bildikleri bir kod tabanında AI araçlarını kullandığında çalışma süresi aksine %19 artıyor
• Geliştiriciler AI'ın kendilerini daha hızlı yaptığını düşünse de, gerçekte daha yavaşlıyorlar; yani algı ile gerçeklik arasında bir fark var
• Bunun temel nedeni, geliştiricinin sahip olduğu gelişmiş mental model (anlama yapısı) ile AI arasındaki bilgi aktarımı sınırları
• Peter Naur'un teorisine göre programlamadaki en önemli şey, geliştiricinin zihnindeki "zihinsel model"
  • Danimarkalı bilgisayar bilimi öncüsü ve 2005 Turing Ödülü sahibi. Programlama dili sözdizimini açıklamakta kullanılan Backus-Naur biçimi (BNF) gösterimine katkıda bulundu
• Uzun vadeli bakış açısından, bir projeyi derinlemesine anlamak için doğrudan kod yazarak mental model kurmak önemli

---

AI'ın açık kaynak geliştiricilerini yavaşlatması

• Metr'in araştırmasına göre AI araçları kullanıldığında problem çözme hızının aksine %19 yavaşladığı görüldü
• Geliştiriciler işten önce AI'ın %24 daha hızlı yardımcı olacağını bekledi ve işten sonra da gerçekte olduğundan %20 daha hızlı olduğunu düşündü
• Bu araştırma, derinlemesine anladıkları açık kaynak projeleri bizzat yöneten deneyimli geliştiriciler üzerinde yapıldı
• Sonuçlar tüm geliştiricilere genellenemese de, bu grupta AI araçlarının üretkenlik üzerinde ters etki yaptığını gösteriyor
• Kurumsal ortamlarda ya da yeni bir kod tabanına uyum sağlamak zorunda olan genel geliştiriciler için AI araçları üretkenliği artırmada daha olumlu bir rol oynayabilir

AI neden deneyimli açık kaynak geliştiricilerini yavaşlatıyor

• Peter Naur'un “Programming as Theory Building” makalesine göre programlamanın asıl çıktısı kod değil, geliştiricinin ‘projeye dair mental modeli’dir
• Bu mental model, sistemi anlama, sorun teşhis etme ve etkili iyileştirme yapmanın merkezindedir
• LLM tabanlı AI, geliştiricinin mental modeline doğrudan erişemez; bazı bilgiler verilse bile bilgi aktarım sürecinde kaçınılmaz kayıplar yaşanır
  • Örneğin birine bebeği uyutma işini verdiğinizde, açıkça anlatsanız bile çoğu zaman gerçekte niyetinizden farklı davranabilir
• Mental modelin aktarımı son derece karmaşıktır ve AI'ın bunu yalnızca metinle içselleştirmesi neredeyse imkânsızdır
• Bu nedenle derinlemesine anladığınız bir projede işi AI'a devretmek aksine üretkenliği düşürür
• Geliştiricinin zengin bağlam bilgisi ve sezgisel kavrayışı AI tarafından kolayca ikame edilemez

İş hayatında AI araçları yasaklanmalı mı?

• Şart değil. Bu durum yalnızca “kendi iyi bildiği, iyi anladığı projede çalışan kişi” için geçerlidir
• Birçok şirket geliştiricisi, çoktan ayrılmış kıdemli birinin kodunu bakımda tutar ya da sistemin genel yapısını derinlemesine anlamadan çalışır
• Böyle ortamlarda AI, kod tabanını hızlıca kavrayıp değişiklikleri otomatik üretmesiyle kısa vadeli üretkenlik artışına katkı sağlayabilir
• Kısa vadeli iş değeri üretimi ve anlık verimlilik açısından bakılırsa AI araçları üretkenlikte olumlu bir rol oynayabilir

Mental model kurma ve AI

• Projeye dair bir mental modeliniz yoksa, LLM üretkenlik artışına yardımcı olabilir
• Ancak yazılım geliştirmenin özü ‘mental model kurmak’ ise, AI'a aşırı bağımlılık bu yeteneği zayıflatabilir
• Uzun vadede projeyi derinlemesine anlamak ve onu etkin biçimde dönüştürmek istiyorsanız bizzat kod yazma deneyimi gerekir
• Buna karşılık, iş sadece ‘çalışsın yeter’ yaklaşımındaysa AI kullanımı verimli olabilir

Ek tartışma ve sonuç

• Mevcut düzeydeki AI araçlarıyla yeterli mental modele sahip geliştiricilerin üretkenliğini artırmak zor
• AI'ın mental modeli gerçekten destekleyebilmesi ya da deneyimli geliştiricilerin üretkenliğini çarpıcı biçimde artırabilmesi için hâlâ araştırma ve gelişim gerekiyor
• Gelecekte modeller ilerlerse, insan geliştiricilerin mental modele ille de sahip olması gerekmeyen bir gün gelebilir; ancak bugünkü seviyede doğrudan anlama ve öğrenme şart
• Sonuç olarak AI, ‘ne yaptığımı derinlemesine anlıyorum’ denilen ortamlarda engel olabilirken, ‘hızlı çıktıların önemli olduğu’ ortamlarda bir üretkenlik aracı olabilir

[paruaa]

> Geliştiriciler, yapay zekanın kendilerini daha hızlı hale getirdiğine inanıyor, ancak
Yapay zeka destekli araştırma hızlandıkça kaliteyi daha yüksek seviyeye çıkarmak mümkün oluyor; bu yüzden aynı işte bile ortaya çıkan kalitenin biraz daha yükselmesi söz konusu değil mi? Geliştiriciler, işi bitirdikten sonra ortaya çıkan sonucun kalitesine uygun şekilde geliştirme yapmaya çalışırken, tek başına ulaşmaktansa yapay zekanın yardımıyla o noktaya daha hızlı ulaşabileceklerini düşünüyor olabilirler.
En başta yapay zekayı hiç kullanmamış olsalardı, sadece daha fazla bildikleri şeylerle uygulama geliştirirlerdi; acaba mesele bundan kaynaklanıyor olabilir mi diye düşünüyorum.

[tested]

> Tersine, iş ‘sadece çalışsın yeter’ yaklaşımıyla yapılacak türdense, yapay zekadan yararlanmak verimli olabilir.

Bu sadece geliştiricilere özgü değil ama farklı eğilimlere sahip insanlar olduğu için, tesadüfen geliştiricilik yapıyor olup kod yazmaktan ya da koda bakmaktan hoşlanmayan veya bundan çekinen, sistematik yapı ya da bakım perspektifli yorumlardan ziyade sadece çalışmasının yeterli olduğunu düşünen kişilerde yapay zekaya bağımlılığın ya da körü körüne güvenin daha güçlü olduğu hissine kapılıyorum. Ya da değildir.

[xguru]

Deneyimli açık kaynak geliştiricilerinin üretkenliği üzerindeki "yapay zekanın etkisini" ölçmek

[GN⁺]

Hacker News görüşleri

• HN millet, ben makalenin yazarlarından biriyim.
  İlgili blog yazısının, yapay zekanın geliştirme hızını yavaşlatmasına katkıda bulunabilecek somut bir etkeni ilginç biçimde ele aldığını düşünüyorum.
  Makalede de (Bölüm C.1.5) geliştirici alıntıları var, bakabilirsiniz.
  Pek çok kişi makaleyi okuyup kendine yakın gelen bir etken bulunca, “Yavaşlamanın sebebi yalnızca bu tek sorun” sonucuna varmaya meyilli oluyor.
  Ama gerçekte birden fazla unsur var (en az 5 güçlü aday var, en fazla 9'a kadarı da dışlanamıyor; bkz. s.11'deki etken tablosu).
  Tek bir neden varsaymaktansa çok yönlü bir neden analizi daha isabetli olur.
  Kendi başına deney yapmayı planlayan varsa, sonuçları mutlaka makaledeki e-posta üzerinden paylaşmasını isterim.
  Ayrıca başlığın “AI slows down open source developers. Peter Naur can teach us why” şeklinde yazılmış olmasıyla ilgili olarak, daha doğru bir ifade bence şu olurdu: “2025'in başlarında yapay zeka, deneyimli açık kaynak geliştiricilerini yavaşlatıyor. Peter Naur belirli bir etken hakkında daha fazla bağlam sunabilir.”
  Belki daha az sansasyonel duruyor ama doğruluğun önemli olduğunu düşünüyorum.
  Bir kez daha harika yazı için teşekkürler; yorumları da okumaya devam ediyorum
  Önceki ilgili tartışma
  Makalenin tamamı
  • Kişisel bir merakım var: Araştırmada, yapay zeka kullanmadan önce ve sonra gerçek harcanan sürenin ne kadar değiştiği nasıl güvenilir biçimde ölçüldü? Geliştiricilerden önce yapay zeka kullandıktan sonra ne kadar zaman kazanacaklarını tahmin etmeleri istenip sonra gerçek süre ölçülerek fark mı görüldü, merak ediyorum. Ayrıca bir meselenin zorluğunu ya da çözüm için gereken süreyi tahmin etmek zor olduğunda, araştırma ekibi bunu nasıl kontrol etti, onu da bilmek isterim. Bu tür ölçümlerin gerçekten karmaşık olduğuna katılıyorum
  • Sonuçlara katıldığımı ve yanıt için teşekkür ettiğimi belirtmek isterim. Başlığı daha çarpıcı bir üslup sevdiğim için değiştirmeyi düşünmüyorum, ama yazıda yanlış ifade olduğunu açıkça düzelteceğim. Kendi yazımda da araştırma sonuçlarının başlıca katkı etkenleri olan “depoya yüksek geliştirici aşinalığı”, “büyük ve karmaşık depolar”, “örtük depo bağlamı” gibi unsurlarla araştırmayla paralel gittiğimi belirtiyorum. Ben de bunu kendi üzerimde deney yapmak isterdim ama iş gerekliliklerini sürdürürken kontrollü bir ortam kurmak çok zor geliyor. Kısa sürede tamamlanabilecek, net görevlerden oluşan bir liste de elimde yok
  • İyi bildiğim bir projede optimize edilmiş iş akışını değiştirmenin başlangıçta yavaşlatmasını beklerim. Asıl önemli olan, bu geliştiricilerin 6 ay ya da 1 yıl sonra nasıl olacağını görmek. Bu çalışma uzun vadeli eğilimi göstermiyor; umarım ileride aynı geliştiricilerin araca alıştıktan sonra performanslarının nasıl değiştiğini görebiliriz. Ben de yapay zekayla, daha önce otomatikleştirmesi zor olan pek çok işi script'leyebildiğimi gördüm. Her zaman “Bu, harcanan zamana değer mi?” diye sormak gerek
    xkcd zaman yönetimi karikatürü
  • “2025'in başlarında yapay zeka deneyimli açık kaynak geliştiricilerini yavaşlatıyor” ifadesinin de fazla genelleyici olduğunu belirtiyorum. Yapay zekanın zaman kazandırabildiği belirli görevler de var; yani etki yapılan işe göre değişiyor
  • Yavaşlamak illa kötü bir şey değil; yavaş programlamanın (literate programming/Knuth yaklaşımı) teorileştirmeye daha çok yardımcı olabileceğini düşünüyorum. Fast-food usulü programlama yerine, yeterli düşünce ve soyutlamayı içeren yavaş geliştirmenin önemli olduğu da savunulabilir
• “Araç gerçekten beni hızlandırdı mı yoksa yavaşlattı mı, geliştirici bunu fark etmiyor” olgusuna katılıyorum. Bunu, teknenin rüzgar ve akıntı yüzünden hedeften sapması örneğiyle açıklayabiliriz: İnsan yalnızca etrafındaki anlık harekete bakarak ilerlediğini sanıyor ama hedefe yaklaşıp yaklaşmadığını sezgisel olarak anlaması zor. Bu yüzden de “ilerliyormuş hissi” veren stratejileri seçmeye yatkınız; bu da verimsiz ya da gerçekte daha yavaş rotaların seçilmesine yol açabiliyor (örneğin araba kullanırken sürekli sağa dönmek gibi)
  • AI araçlarını ilk kullanırken takılma yaşamadan sürekli ilerliyormuş hissi güzeldi. Ama gerçekte bazen bir satırı kendim düzeltmek daha hızlıyken bile alışkanlıkla AI çağırdığım oluyordu. Bu da, bir yol tıkanınca sizi tekrar tekrar eski rotaya yönlendiren GPS benzetmesine benziyor
  • Waze gibi navigasyon uygulamalarının gerçekte daha uzun bir rota önermesine rağmen, girift kestirmeler yüzünden insana “hareket halindeyim” hissi verip daha hızlı gidiyormuş gibi düşündürmesine benziyor. AI araçları da programlamayı daha kolay hissettirebilir ama gerçek üretkenliği düşürebilir. İnsan zihni, acısız ilerleme deneyimini daha kolay hatırlar; zorlanmadığı için de ilerleme kaydettiğini sanır
  • Sonuçta insanlar içgüdüsel olarak greedy algorithm tercih ediyor
  • Linux/Unix kullanıcıları klavye denetimi ve CLI araçlarının en verimli yöntem olduğunu düşünür ama çoğu görevde farenin daha hızlı olduğunu gösteren araştırmalar var. Klavyenin daha hızlı hissettirmesinin nedeni, saniye başına yapılan işlem sayısının daha yüksek olması
  • AI tarafından üretilen kod neredeyse hiç gözden geçirilmiyor ve birçok geliştirici code review işini zaten yorucu bulduğu için okumaktan kaçınıyor. Bu yüzden yeni framework'lerin ya da code rewrite'ların popüler olması gibi bir durum ortaya çıkıyor
    Joel on Software: Things you should never do, part I
    AI'nin ürettiği kodların çoğu sadece yazılıyor, basit birkaç testten geçiyor ve orada kalıyor. Hatta kişinin kendisinin bile tüm bağlamı ya da nedenleri yeterince anlamadığı kodlar çoğalıyor
• Bu araştırmanın özeti bence şu: “Yapay zeka, üretkenlik artışının gerçekte olduğundan büyük olduğu yanılsamasını yaratıyor.” Yalnızca bazı katılımcılarda küçük bir üretkenlik artışı vardı; çoğunda ise belirgin bir düşüş görüldü. Yapay zeka sayesinde üretkenliğinin patladığını söyleyen çok kişi var ama araştırmanın, bu etkinin kendisinin bir yanılsama olabileceğine dair içgörüsü göz ardı ediliyor. AI, kullanıcının “Bu ürünü kullanmalıyım, faydalı” diye düşünmesini sağlayacak şekilde optimize edilmiş bir ürün. Kişisel değer, algılanan gerçeklik olduğu için bu tamamen geçersiz sayılmaz; ama AI'ya güçlü biçimde bağımlı olanların, öz-farkındalık çarpılması, sahte başarı hissi ve araç bağımlılığı konusunda gerçekten dikkatli olması gerekir. AI bazen optimize edilmiş token akışlarıyla yanıt veriyor ama asıl optimizasyon hedefinin ne olduğunu da bir kez düşünmek gerek
  • LLM'ler bir şey öğrenirken faydalı olabiliyor ama o anlayış çok soyut ve biraz da LLM tarzı bir anlayış gibi geliyor. Öğrenirken farklı yöntemleri karıştırmak daha iyi bence
  • AI araçları geliştiriciye “hızlı” olmaktan çok “anlık olarak çevik” olduğu hissini veriyor. Sanki beynin yükü azalmış gibi bir yanılsama var; farklı geri bildirim döngülerinde hissin kendisi değişiyor ve hafıza oluşum mekanizması da değişiyor, bu da ilginç bir algı yanılsaması yaratıyor
• “Deneyimli açık kaynak geliştiricileri kendi projelerinde AI kullandığında yavaşlıyor” araştırması tartışılırken, ben tamamen başkasının yazdığı 3 aylık bir codebase ve alışık olmadığım bir framework üzerinde çalışıyordum. Buna rağmen Claude Code kullanarak, geçmişte başka projelerde 1-2 gün hatta en fazla 2 hafta sürecek işleri (örneğin veri senkronizasyonu) sadece birkaç saatte bitirdim; bu benim için muazzam bir jump-start oldu. Karmaşıklık arttıkça muhtemelen yavaşlar ama aracı kullanarak başlangıcın bu kadar hızlı olması şaşırtıcıydı
  • Benzer bir deneyimim var ama bu araştırmanın söylediği şey, bizim yaşadığımız ramp-up dönemi değil; zaten çok aşina olan açık kaynak geliştiricilerinin AI ile görev yapması. LLM'ler yeni bir codebase'e uyumu kesinlikle hızlandırıyor ama bir noktadan sonra, aşinalık kazanınca, bende tersine engelleyici olmaya başladı
  • “2 hafta sürecek PR'ı birkaç saatte bitirdim” iddiasıyla üretkenlik artışı anlatıları hep birlikte geliyor ama gerçekte geliştirme süresi tahminlerimizin ne kadar doğru olduğunu pek denetlemiyoruz. Ayrıca böyle acele çıkarılmış bir PR'ın kalitesinin başlangıçtaki beklentiyle aynı olup olmadığına, ya da yalnızca hızlı olmak uğruna önemli sistem bağlamlarının atlanıp hata olasılığının artırılıp artırılmadığına bakmak gerekir. AI olmasa da kaliteyi feda ederseniz daha hızlı olursunuz
  • AI sayesinde codebase ve sistem hâkimiyetimizin ortalama olarak gerçekten arttığı da şüpheli. LLM ile öğrenme etkisi, yeni bir dili okuyabilmek ama sıfırdan konuşamamak gibi. C++ örneğinde olduğu gibi, okuyup mevcut şeyi değiştirebilirsiniz ama sıfırdan nereden başlayacağınızı bilmek daha zordur
  • AI araçları sayesinde çok büyük bir jump-start yaşadığımı söylemek istedim; araştırmaya, yazıya ya da makaleye yönelik eleştirel bir niyetim yoktu. Sadece belirli bağlamlarda AI'nın gerçekten yardımcı olabildiğini belirtmek istedim. Üstelik mesele yalnızca kod yazmak değil; örneğin Claude Code, proje içindeki container üzerinden doğrudan AWS cluster bağlantısı denemeleri de yapabiliyor ve bu, tüm altyapıyı ve yapıyı anlamama çok yardımcı oldu. Benim deneyimimde vakaların %80-90'ında kod kalitesinden çok “iş değeri” öncelikli. Kod kalitesinin gerçekten kritik olduğu işlerde ya da özel algoritmalar, veri yapıları gereken alanlarda ne kadar işe yarar emin değilim. Ama iyi örnekler ve net bağlam verildiğinde gayet kullanılabilir kod yazdığını da gördüm. Bu araçlar her hafta ya da ay çok hızlı gelişiyor. Sonuçta AI sihir değil, bir araç; ürün ve sonuç üzerindeki sorumluluk yine kişide
  • Makalenin (TFA) çok aşina olunan projelerdeki vakaları ele aldığını unutmamak gerek. Benim yaşadığım durum ise bunun tam tersi; AI daha çok aşina olunmayan koşullarda öne çıkıyor
• “Agentic AI araçları (Claude Code, Amp, Gemini CLI vb.), programlama için masa testeresinin marangozlukta ortaya çıkmasına benziyor” benzetmesini alıntılayarak, kullanmayı öğrenirseniz bazı işleri daha hızlı ve daha iyi yapabileceğinizi, ama alışık değilseniz parmağınızı da kesebileceğinizi savunan bir görüş var. Ben de agentic AI sayesinde daha iddialı projelere girişebildiğimi, yapmak istemediğim ya da tekrarlı işleri AI'ya verince düşünmeye daha çok alan kaldığını hissediyorum. Öte yandan AI her şeyi yapsın diye bırakıp hiçbir şey anlamadan commit atmanın doğru olmadığını da özellikle vurguluyorum. Sonuçta bir araç gibi, onu daha iyi kullanmayı öğrenmek için çaba gerek
  • Masa testeresi benzetmesinin uygun olmadığını düşünüyorum. Masa testeresi el aletlerine kıyasla hassas bir araçtır; agentic AI ise hassasiyetten oldukça uzak
  • “AI'yi yanlış kullanıyorsun” argümanı, AI ortada yokken bütün açık kaynak yığınını kurmuş geliştiricilere hakaret gibi geliyor. Ayrıca AI kullanılarak değerli yazılım üretildiğine dair henüz bir kanıt da yok
• Bu çalışmada Cursor deneyimi 50 saatin üzerinde olan geliştirici yalnızca bir kişiydi (araştırma sırasında geçirilen zaman dahil) ve bu kişi %25 hızlanma yaşadı. Geri kalanların hepsi yeniydi; yeni bir araç kullanan acemilerin yavaşlaması da son derece doğal. Bu araştırmadan yola çıkarak AI'nın üretkenliğine dair kesin sonuç çıkarmanın zor olduğunu düşünüyorum
  • Makaledeki ayrıntılara bakarsanız, benzer (hatta daha az) araç deneyimine sahip kişilerle yapılan önceki çalışmalarda tersine hız artışı rapor edilmişti. Çoğu kişinin LLM prompt deneyimi zaten yeterliydi; ayrıca Cursor'ın VSCode'a benzer olması nedeniyle ayrı bir öğrenme eğrisi de çok büyük sayılmaz. Eğer tüm geliştiriciler AI araçlarına aşırı alışırsa, AI olmadan çalışma becerileri düşebilir; bu durumda AI ile çalışırken görülen hız artışı, aslında yalnızca taban düzeyin daha kötü hale gelmiş olmasından kaynaklanabilir. Burada önemli olan hangi aracın kullanıldığı değil, üretkenlik öz-değerlendirmesinin gerçeğe kıyasla aşırı iyimser çıkmış olması. Gerçek etkiyi anlamak için somut ölçümler gerekir
    (Makalenin C.2.7 “Ortalamanın altında AI araç kullanımı” bölümünde daha ayrıntılı ele alınıyor)
  • Yıllardır kendi IDE'sini (Vim/Neovim vb.) kullanan bir geliştirici için, Cursor gibi yeni bir araca geçmek üretkenliği aylarca ciddi şekilde düşürebilir
  • Ben de aynı fikirdeyim. Alışık olmadığı bir araç kullanan geliştirici doğal olarak yavaşlar. AI da bunun istisnası değil
• Şu anda Burn'ün (Rust tabanlı derin öğrenme framework'ü) düzenli code reviewer'larından biriyim. Yakın zamanda, tamamen bir AI agent tarafından yazılmış gibi görünen bir bugfix PR'ını kapatmak zorunda kaldım. PR, sorunun kök nedenini çözmek yerine hatayı sadece görmezden geliyor, gereksiz yere uzun savunmacı kod ekliyor ve hatta hatayı yoksayan testler içeriyordu. Sanki sadece commit geçmişine bir şey yazılmış olsun diye yapılmış gibiydi. Bu tür AI kötüye kullanımının giderek yaygınlaşması endişe verici
  • LLM'lerin doğru cevabı bilmediğinde alakasız yanıtlar üretip, sonra yanlış olduğu söylenince “Haklısınız, düzelteyim” tavrına geçmesi gerçekten tuhaf. Deneyimsiz kişilerin sorunları ayırt edememesi ya da zamanla koda dikkat etmeyi bırakması ihtimali ürkütücü. Ciddi güvenlik açıkları ve istismar örneklerinin gelmesinden endişe ediyorum
  • Bir iş arkadaşımın MR'ını incelerken, AI tarafından üretildiği çok belli olan test case'lerle karşılaştım (thing1, thing2 gibi sadece değişken adı değişmiş, içeriği tekdüze örnekler). Geri bildirim olarak daha ayırt edici isimler önerdim; bu kez de AI, her case'in özelliğini tek tek sayan gereksiz uzun değişken adları üretmişti ve sonuç olarak kod bir bakışta okunamaz hale gelmişti. Yazarı muhtemelen yazma hızını çok artırdığını düşündü ama pratikte geri bildirim, review ve düzeltmelere harcanan sürede tüm verim kazancı silinip gitti
  • “Rust ile derin öğrenme framework'ü -> AI ile ilgili kısır döngü” minvalinde şakacı bir yorum da vardı
  • Aslında commit kaydı oluşturmak için AI kullanılması havası epey zamandır vardı. AI, basit spam üretimini de kolaylaştırıyor
    Bkz.: eski bir AI spam meselesi
  • LLM'lerin try:catch bloklarını fazla geniş kullanarak sorunun kaynağını bulmayı zorlaştırdığına dikkat çekiliyor. Ben ise sorunun hızlı ve sert biçimde ortaya çıkmasını, yani fail fast olmasını isterim ki hemen düzeltebileyim
• Kendi izlenimimi paylaşayım: AI ile programlama, odak akışımı daha sık bölüyor ve daha kolay yoruyor. Gün boyu kesintisiz kod yazmak zaten bir efsane; normal olan 1-3 saat odaklanıp aralarda mola vermek. Hatta ekip arkadaşının kodunu ya da değişikliklerini okumak bile işin bir parçası ama gerçek ilerleme hissi yaratmıyor. Agentic AI küçük refactoring işlerinde yararlı olabilir ama devasa bir üretkenlik artışı sağladığını düşünmüyorum. Kod otomatik tamamlama (örneğin ilk Copilot dönemi) ise bana daha çok gereksiz gürültü gibi geliyor
  • İnsan gün içinde ne yaptığını kaydetse ortaya oldukça moral bozucu bir görüntü çıkabilir. Özellikle olgun bir codebase söz konusuysa, bir saatlik gerçek odak bile abartı olabilir
• Yabancı bir codebase'te tricky bir bug'ı (örneğin race condition) debug ederken, logging eklemek, kütüphane fonksiyonlarını değiştirmek, yapıyı iyileştirmek gibi adımlar şart oluyor. Eğer AI kısa vadeli olarak sadece “Burada race condition var, şöyle düzelt” diye çözüm verirse, kod yapısını ve mantığını gerçekten anlama sürecine zarar verebilir. Uzun vadede AI güdümlü kod düzenleme sürerse, kod tabanı öyle bozulabilir ki bir süre sonra AI'nın kendisi bile artık sağlıklı tepki veremez hale gelebilir
  • “AI kullanarak bilmediğim bir dilde, bilmediğim bir codebase'e katkı yaptım” türü deneyimleri duyduğumda, kısa vadede iyi olabilir ama insan gerçekten ne öğrendi diye soruyorum. Bu tür katkılar küçük işler için işe yarayabilir ama uzun vadeli bakım tarafında pek örnek duymadım
• Yakın zamanda AI araçlarını yoğun kullandığım ilk projemin retrospektifinde şu sonuca vardım: 1) Hızlanmadım, 2) hatta muhtemelen yavaşladım, 3) ama ortaya çıkan ürünün kalitesi daha iyiydi. Yavaşlama ile kalite artışı birbirine bağlıydı; çünkü AI'yı daha çok fikir doğrulama ve alternatif keşfi gibi yardımcı rollerde kullandım. AI sayesinde yabancı olduğum alanlarda öğrenme deneyimi de iyiydi; kendi asıl uzmanlık alanımda ise ister benim ister AI'nın fikirleri olsun, onları rafine ettikçe sonuç daha kaliteli hale geldi. Hız tek başına her şey değil; kaliteyi nicelleştirmek zor olsa da bunun yeterince değerli olduğunu düşünüyorum
  • AI'nın kaliteyi artırmaya katkı sunabildiğini düşündüğüm için, son zamanlarda daha çok itiraz eden ve her şeye hemen katılmayan AI'ları tercih ediyorum. AI'dan fikir isteyip sonra o fikirleri eleştirmesini ya da benim fikirlerimdeki açıkları bulmasını istemek verimli oluyor. Uygulamayacak olsam bile, daha önce aklıma gelmeyen farklı açılar düşünmemi sağlıyor. Bu, alan hakkında makul düzeyde fikir yürütebilen bir çalışma arkadaşıyla konuşmaya biraz benziyor

[eususu]

Ben de benzer bir düşünceye sahiptim ama bunu nasıl ifade edeceğim biraz belirsizdi.
Mental model gerçekten yerinde bir adlandırma. Ara sıra kullanmam gerekecek.