GitHub CEO, AI patlamasında bile “manuel kodlama hâlâ temel”
(techinasia.com)- GitHub CEO'su Thomas Dohmke, AI araçlarının yaygınlaşmasına rağmen manuel kodlama becerisinin önemini vurguladı
- AI kod üretse bile, bunun verimli olabilmesi için geliştiricinin kodu bizzat düzenleyip incelemesi gerektiğini savundu
- Yalnızca otomasyona bel bağlamanın, gerçek anlamda verimsizlik ve üretkenlik kaybı riski taşıdığı; "Vibe coding" gibi AI kodunun aşırı kullanımında kalite ve güvenlik risklerinin arttığı belirtildi
- AI ile insan geliştiricilerin hibrit yaklaşımının en etkili yöntem olduğu, sektör eğilimleri ve örneklerle desteklenerek açıklandı
- Geliştirici rolünün ortadan kalkmadığı, AI ile iş birliği içinde stratejik problem çözme ve tasarım yetkinlikleri gerektiren bir yöne evrildiği ifade edildi
GitHub CEO, AI çağında da manuel kodlamanın önemini vurguluyor
GitHub CEO'su Thomas Dohmke, yazılım geliştirme sahasında AI araçlarının kullanımı yaygınlaşsa da, manuel kodlama becerisini korumanın önemini vurguladı
- “The MAD Podcast with Matt Turck” programına katılarak, geliştiricilerin AI'nin ürettiği kodu doğrudan düzenleyebilme yetkinliğine sahip olması gerektiğini, bunun üretkenlik düşüşünü önlemek için önemli olduğunu anlattı
- Etkili bir iş akışında, AI aracının kod üretip Pull Request göndermesi, ardından geliştiricinin kendi becerilerini kullanarak bunu hemen düzeltmesi yaklaşımının öne çıktığını söyledi
- Sadece otomasyon ajanlarına bağımlı kalındığında, basit düzenlemeleri doğal dille tarif etmek için gereksiz zaman harcanabileceği ve bunun verimsizlik riski doğurabileceği belirtildi
- Dohmke, “Programlama diliyle zaten doğrudan yapabildiğiniz bir işi gereksiz yere doğal dille anlatmaya çalışmak, en verimsiz seçimdir” değerlendirmesinde bulundu
- OpenAI kurucu ortaklarından Andrej Karpathy'nin dile getirdiği “vibe coding”, AI tarafından üretilen koda aşırı bağımlılığı anlatan bir terim olarak öne çıkarken, Dohmke bu konuda da dikkatli olunması gerektiğini vurguladı
İçgörüler ve sektör eğilimleri
1. AI ile kodlamada en iyi çözüm hibrit strateji
- Dohmke'nin bakış açısı, AI otomasyonu ile insan programlama becerilerinin birleşiminin en iyi yaklaşım olduğunu savunan sektör konsensüsüyle örtüşüyor
- Deloitte araştırmasına göre geliştiriciler AI araçlarını çoğunlukla boilerplate kod yazımı için kullanıyor; ancak nihai insan incelemesini sürdürerek 10 ila 20 dakikalık üretkenlik artışı elde ediyor
- AI'nin ürettiği kodun yaklaşık yarısında kısmi hatalar bulunduğundan, “güven ama doğrula” stratejisi sektörde standart haline geliyor
- Google, toplam kodun %25'inden fazlasını AI'nin ürettiğini belirtse de, insan geliştiricilerin aktif inceleme ve iyileştirme sürecinin hâlâ vazgeçilmez olduğunu deneyimledi
- Bu dengeli yaklaşım, AI'nin sınırlarının kabul edilmesiyle birlikte geliştirici uzmanlığının yerini almak yerine güçlendirildiği bir olgunlaşma sürecini yansıtıyor
2. Geliştirici rolü değişiyor, ortadan kalkmıyor
- AI nedeniyle programlama mesleklerinin yok olmasından ziyade, geliştirici rolü saf kod yazardan AI tabanlı geliştirme süreci yöneticisine dönüşüyor
- Uzmanlar, geliştirici işlerinin AI kullanan ürün mühendisleri ile ileri düzey sistem kalite/güvenlik güvencesi sağlayan mimarlar arasında ayrışacağını öngörüyor
- Bu değişim, AI'yi etkili kullanma becerisi, stratejik problem çözme yeteneği ve üst düzey tasarım kapasitesi gibi yeni yetkinliklere ihtiyaç duyulduğu anlamına geliyor
- Yazılım mühendisi açığı ile birlikte AI araçlarının junior geliştiricileri destekleme etkisi kanıtlanmış durumda; bu da deneyimli geliştiriciler için de yeni büyüme fırsatları sunuyor
- Bu tablo, geçmişte geliştirme araçları ve soyutlama teknolojileri ortaya çıktığında olduğu gibi, insan yaratıcılığına hâlâ ihtiyaç duyulduğunu gösteriyor
3. “Vibe coding”in üretkenlik-kalite ikilemi
- “Vibe coding” olgusu, AI'nin ürettiği kodun üretkenlik avantajlarıyla kalite/güvenlik sınırlarını aynı anda ortaya koyan bir eğilim
- AI araçları hızlı prototipleme ve yinelemeli geliştirmeyi destekliyor; ancak bunun yanında kod kalitesinde düşüş ve güvenlik riskleri konusundaki kaygıları da artırıyor
- Gerçek vakalarda, AI kodunun doğrulanmadan kullanılması sonucunda güvenlik açıkları ortaya çıkabildi
- Teknik geçmişi olmayan kurucuların ağırlıkta olduğu girişimlerde AI kodunun aşırı kullanımı, teknik borç biriktirerek uzun vadeli büyümeyi sekteye uğratabilir
- Büyük teknoloji şirketlerinin deneyimine göre, otomasyon ile sıkı kalite kontrolü arasındaki denge AI benimsemesinin anahtarı ve bu ders girişimler için de önemli
1 yorum
Hacker News görüşleri
İnsanların neden sistemlerin özsel karmaşıklığı hakkında artık konuşmadığını gerçekten merak ediyorum
Fred Brooks'un No Silver Bullet yazısında da belirtildiği gibi, yazılım mühendisliğinin asıl zorluğu temel problem alanını anlamaktan, netleştirmekten ve modellemekten gelir. Araçların sınırlılığı gibi arızi karmaşıklık ise ikincildir
Son dönemde AI ajanlarının mühendislerin yerine doğal dil prompt'larıyla tüm kod tabanını üreteceğine dair çok konuşuluyor. Ama bu varsayım, specification sorununu zaten çözmüşüz gibi davranan bir yanılgı. Gerçekte belirsiz fikirleri ayrıntılı ve sağlam sistemlere dönüştürmek hâlâ mühendisin temel rolü
Eğer biri ayrıntılı spesifikasyon verip AI ile yinelemeli şekilde çalışarak yazılım üretiyorsa, aslında yaptığı şey AI ile arızi karmaşıklığı ortadan kaldırmak. Bu, geliştiricilerin assembly'den yüksek seviyeli dillere geçmesine benziyor. Mühendisin yerini almak değil, yalnızca üretkenliği artırmak anlamına geliyor. Tekrarlayan işlerin maliyetini düşürür ve daha geniş etki alanı yaratma fırsatı verir
Eğer bir ajan yalnızca prompt'larla ürün yapabiliyorsa, bunun nedeni birilerinin sistemi zaten açık biçimde tanımlamış olmasıdır. Ve AI ile mevcut ürünleri yalnızca kopyalıyorsanız, bu artık teknik problem çözmek değil; dağıtım ya da maliyet rekabetidir, yani mühendislik inovasyonu değil iş inovasyonudur.
Acaba benim gözden kaçırdığım bir şey mi var?
İşin özü, specification çalışmalarının AI ortaya çıkmadan çok önce de ihmal edilmiş olması
Paydaşlar (müşteriler, yöneticiler) uzun zamandır zaten kabaca bir şeyler tarif edip birilerinin buna göre kod yazmasını istiyordu. Kabataslak anlatıyorlar, sonra biri mucizevi şekilde buna uyan bir çözüm çıkarıyor. Çözümün gerçekten tam çalışıp çalışmadığını da kimse bilmiyor. Çoğu zaman "eh, galiba çalışıyor" deyip geçiliyor
Çoğu durumda programcı bunu alan bilgisi ile somutlaştırıyor (örneğin doğru bir form gönderim sayfasının nasıl görünmesi gerektiğini içgüdüsel olarak bildiği için)
Şimdi sadece karşı tarafta insan yerine AI var; bu yaklaşımın aynı şekilde sürüp sürmeyeceğini zaman gösterecek
Özsel/arızi karmaşıklık ayrımı, AI'ın yazılım geliştirmede ne kadarını üstlenebileceğini düşünmek için çok önemli bir içgörü
Pek çok geliştirici neden AI ile ikame edilmeyeceğini sözle iyi açıklayamasa da içgüdüsel olarak hissettiği nokta tam burası
Ben de gerçekten Claude gibi ajanlara, dış iş mantığıyla örülmüş son derece karmaşık büyük kod tabanlarındaki problemleri çözdürmeyi denedim. Ama AI iş gereksinimlerini ya da bağlamı doğru sezmediği için iş tarafına dönük kod değişikliklerini yapamıyor. En fazla bağlamı dar olan kod değişikliklerinde yardımcı olabiliyor. Yani yalnızca arızi karmaşıklığı ele alabiliyor; gerçek geliştiricinin rolü olan, gerçek ihtiyaçları sisteme çevirmede sınırları var
Ek olarak, pratikte birçok geliştiricinin çözdüğü şey teknik değil, dağıtım/pazar problemi de olabilir. AI ile junior'ları değiştirmek hâlâ riskli görünüyor. En büyük sorun, AI'ın kendi kendini düzeltememesi. Yine de AI tabanlı işletmelerin mevcut işlerin maliyetini düşürmeye çalışması sürecek. Bu değişimin iyi mi kötü mü olduğu, işini kaybeden biri açısından pek anlam taşımıyor
"Ben bir şeyi mi kaçırıyorum?" sorusunun bir cevabı var
Gerçekten yazılım kullanmayı bilmeyen geliştiriciler çok fazla. Bunlar AI ile kolayca ikame edilecek
Önceki kariyerimde JavaScript ile çalışıyordum ve gerçekten etkileyici işler yapanlar sadece hobi olarak da geliştirme yapan insanlardı. Şirketteyse çoğu kişi ekrana metin bastırmakta bile zorlanıyordu. Şaka değil
Birçok insan devasa framework'lere girişiyor ama sonunda yaptıkları şey sadece kopyala-yapıştır ile bir şeyi zor bela çalıştırmak oluyor. Güya ileri düzey karmaşıklığı çözüyorlar ama yapılan işin çoğu ya gereksiz ya da kod gösterişi
Orijinal uygulama geliştirme, dokümantasyon yazma, gerçek kullanılabilirliği ölçme gibi yetkinlikler neredeyse yok
Bunu nasıl çözersiniz? Avukatlıkta baro sınavı gibi yüksek standartlar getirip, bu çıtayı geçemeyenleri elemek ve onları yalnızca junior ya da çırak olarak almak gerekir ki geliştirici kuşakları sağlıklı biçimde yetişsin
'Kaçırılan nokta' için kolay cevap şu: sektörde kimse "No Silver Bullet" okumamış
Teknik borç ve sistem mimarisi üzerine yazanlar, ekipleri ve işi gerçekten yönlendiren karar vericiler değil; ayrıca bu tür kitaplar da mühendisler için ancak opsiyonel
AI ile kodlamanın yerini alma söylemini öne süren kişiler, MVP yapmayı 10 yıl boyunca bir kod tabanını büyütmekten ve legacy'yi iyileştirmekten ayıramıyor
Örneğin bir yönetici, günde 3 projeye ayrı ayrı %33 zaman ayıralım gibi tipik şekilde yanlış bir öneri sunmuştu. Personel ataması ve zamanın yapılandırılması yöneticinin işi olmalı, ama bunu düzgün yürütmek yine mühendisin sırtına kalıyor
Şimdi de bu yöneticiler "tüm teknik borcu/testleri AI'a çözdürelim" diyor; düzgün olmayınca da nedenini açıklamak yine mühendise düşüyor
Karmaşıklık tartışması aslında kötü yönetim sorununun tekrarı sadece. Zaten çoğu deneyimli mühendis, işinin basit prompt'larla ikame edileceğine inanmıyor
Asıl konuşmamız gereken şey şu: "yazılım mühendisliğinde ciddi bir yönetim sorunu var ve AI bunu daha görünür kılıyor"
Birçok geliştirici olmayan kişi ya da öğrenci, yazılım geliştirmenin karmaşık araçları öğrenmeyi gerektirdiğini düşünüyor ve "specification'ı iyi kurarsan herkes yazılım yapabilir" vaadine kapılıyor (specification üretmenin kendisinin çok zor olduğu ve destekleyici teknikler gerektirdiği kısmı atlanıyor)
Eskiden no-code da böyleydi; gerçekte no-code araçları sınırlıydı ve ne kadar güçlü hale gelirlerse o kadar karmaşıklaşıp uzmanlık gerektiriyorlardı
LLM ile SWE'nin yerini alma söylemi de sonuçta "sistemi öğrenmek yerine doğal dille prompt ver, model araçları senin yerine kullansın" yaklaşımının bir versiyonu
Bu açıdan bakınca bugün konuşulan vibe coding bunun neredeyse uç noktası gibi (gerçi bakım yapılabilirlik gibi somut zayıflıkları var)
Bana göre yöneticilerin SWE'yi ortadan kaldırmak istemesinin nedenlerinden biri, SWE ile düzgün iletişim kuramamaları
LLM kullanınca "inekler (geliştiriciler)" olmadan da makineyle konuşabileceklerini düşünüyorlar; yani sorunun çözüldüğünü sanıyorlar
Programlama dilleri, istenen programın kesin specification'ı için uygun bir ortamdır. Doğal dil hiçbir zaman bu düzeyde açıklığa sahip olamaz
Bu yüzden AI'ın ürettiği sonucu gözden geçirmek ve düzenlemek gayet doğaldır. Hatta bazen değişikliği anlatmaktan ziyade doğrudan kendin düzeltmek daha kolay olur
Copilot'un hata oranını artırdığına dair bağımsız araştırmaların, doğal olarak daha temkinli bir yaklaşımın yayılmasına katkı sağlayıp sağlamadığını merak ediyorum
AI satanlar ise insan yazarların yakında gereksiz olacağını sık sık iddia ediyor
Transformer'lar otomatik test, specification genişletme, yeni proje hızlandırma, bilinmeyen API'leri keşfetme, ilk özellik inşası ve code review gibi çok çeşitli işlere uygulanabilir
Kod gerçekten specification için doğru ortam olsa bile, Transformer doğal dil ile o medium (kod) arasında otomatik bir arayüz işlevi görüyor
Son dönemde Transformer'ların muazzam bilgi birikimi sayesinde kod üretmekte sorun yaşamadığı görülüyor
İnsan programlamada otomasyon peşindeyse, Transformer büyük bir sıçrama
Gelecekte bir noktada AI nedeniyle programcıların ikame edilmesi gerçek olabilir (tıpkı geçmişte otomatik dokuma tezgâhı, matbaa ve elektronik hesap makinelerinin insan emeğinin yerini alması gibi)
Ama bunun hemen şimdi ya da 10 yıl içinde olacağı da kesin değil; halüsinasyon, doğruluk, araçlaştırma ve altyapı kurma gibi sorunlar duruyor
Programlama işlerinin varlığı ya da yokluğu; alan, beceri ve ücret beklentisine göre değişebilir
AI araçlarını ciddiye almak ve uyum sağlamak önemli. Aksi halde kişisel bilgisayar ya da internetin benimsenmesi dönemlerinde olduğu gibi geride kalınabilir
AI'ın sözde yaratıcılığının sınırları olduğunu düşünüyorum
Eğer tüm LLM eğitiminin çıktıları tekrar yalnızca LLM girdisi olarak dolaşıma girerse, yeni fikirlerin alanı asla genişlemez
İnsanlar ise sürekli bunun dışına taşan bir yaratıcılık sergiliyor
Gelecekte LLM'ler bu duvarı aşabilir belki, ama bugün için durum çok da 'sonsuz maymun' düşünce deneyinden farklı görünmüyor
Benim deneyimime göre LLM, scaffolding aracı olarak kullanıldığında en etkili
Yapmak istediğim özelliği adeta zihnimdekini boşaltır gibi aktarıyorum, sonra modelle birlikte o modelin ihtiyaç duyduğu temel controller'ları oluşturmasını istiyorum
Geriye sadece view ve gerçek iş mantığına odaklanmak kalıyor; iş bölümü de netleşmiş oluyor
Geçmişte yüksek seviyeli diller ilk çıktığında, en başlarda bugünkü LLM ya da doğal dil üzerinden kod yazma eleştirilerine benzer şekilde "belleği doğrudan kontrol etmek zor, o yüzden yeterince kesin değil" türü eleştiriler olduğunu biliyorum
Sorun doğal dilin kesinliğe ulaşamaması değil; çoğu insanın taleplerini zaten kesin ifade etmemesi ya da ne istediğini bilse de bilgisayarın gerçekten ne yapması gerektiğini doğru anlatamaması
Sonuç olarak mühendis iş gereksinimlerini çevirirken çok fazla tahmin yürütüyor ya da LLM aynı rolü üstlenmeye çalışırken daha da az bağlamla hareket ediyor
AI'ın en iyi kullanım şekli, daha önce görmediğim bir API ya da yapmaya üşendiğim bir özellik yüzünden takılmadan flow durumunu koruyabilmek
AI, kodun tamamına ortak kalıpları hızlı ve verimli şekilde uygulayabilir ama özünde 'ne yaptığını kendisi bilmiyor'
Yakın zamanda yaşadığım bir deneyimi paylaşayım: popup boyutu hesaplama ve konum belirleme kodunu LLM ile refactor etmeye çalıştım
Bir yerde "if", başka bir yerde "switch" kullanılmıştı; LLM iki yaklaşım arasındaki farkı esnek biçimde ele alamadı ve ben açıkça anlatsam da iki tarafı da ya if ya da switch yapısına çevirdi
LLM, önceki token'ların desenini sürdürmeye eğilimli
Burada bu büyük bir problem değildi ama biraz daha karmaşık senaryolarda ayrıntıları göz ardı edip yüzeyde makul görünen kod üretmeye başlıyor
Buna karşılık küçük parçalara bölüp açık komut verirseniz, LLM oldukça verimli olabiliyor. Örneğin "boyutu m_StateStorage'a kaydet ve render aşamasında uygula" gibi bir talimatı rahatlıkla yerine getiriyor
Özellikle Cerebras gibi birkaç kilobaytlık kodu bile hızla işleyebilen modellerle birlikte, düşüncemi doğrudan gerçek koda dökmekten çok daha hızlı olabiliyor
Sonuçta bugün eleştirdiğimiz şey, aslında transformer modellerin mevcut performansına yönelik bir eleştiri
Bu alan o kadar hızlı değişiyor ki bugünün sınırları bir ay sonra anlamsız hale gelebilir
"LLM" de teknik olarak belirsiz bir ifade. En yeni transformer modeller multimodal; yalnızca metin değil, birçok veri türüyle çalışıyor
O yüzden eleştiri yapılacaksa, hangi modelin/aracın/paradigmanın hedef alındığını somut söylemek tartışmayı daha verimli kılar
“Yazılım mühendisi açığı” ve “AI özellikle junior geliştiricilere yardımcı oluyor” yönündeki araştırmalar hakkında
Benim yaşadığım gerçeklikte teknoloji iş piyasası berbat durumda ve AI, junior'ların büyümesi gereken yerlerden deneyimi çekip alarak onlara zarar veriyor
Geçenlerde Claude ile ilginç bir deneyim yaşadım. Zed içinde "71. satırdaki hatayı düzelt" dedim, gidip 91. satırdaki gereksiz formatlamayı değiştirdi
Sanki LLM ile kulaktan kulağa oyunu oynuyormuşum gibi hissettirdi
Böyle basit bir değişikliği bile kendim yapmak daha hızlı. Bu da bana bir kez daha “LLM gerçekten düşünmüyor” hissini verdi
LLM'lerin satır numarası algısı çok kötü
Böyle deneyimlerden çıkan ders şu: “LLM satır numarası sayamıyor”
Bir dahaki sefere “XYZ fonksiyonundaki hatayı düzelt” demek ya da ilgili satırı doğrudan yapıştırmak daha iyi olur
Ve evet, elbette LLM düşünmüyor. Yalnızca devasa bir denklem
Bu başlıkta AI ile ilk kez kodlayan çok kişi var gibi görünüyor
Bu biraz da operatör hatası olabilir
LLM'e doğru bağlamı vermek gerekir. Satır numarası iyi bir bağlam değil
Benim için yazılım mühendisinin rolü gereksinimleri yazılıma dönüştürmektir
Yazılım sadece koddan ibaret değildir; gereksinimler de yalnızca doğal dil cümleleri olarak gelmez
Şu anki durumda AI ile birlikte çalışsam bile hızım AI'dan yüksek olmuyor (basit işler ve küçük yazılımlar hariç)
Şu anki AI bana göre junior/mid seviye geliştirici kıvamında
Son 2 yılda AI'ın hissedilir biçimde çığır açacak kadar iyileştiğini düşünmüyorum
Çoğu gereksinim açık biçimde dokümante edilmiş halde gelmez
İş mantığının ne olduğunu bilen insan da çoğu zaman yoktur
Bu yüzden yazılım mühendisinin gidip bizzat sorması gerekir
Yazılımın hangi yönde büyüyeceği ve bunu destekleyecek biçimde nasıl tasarlanacağı konusunda deneyim ve sezgi gerekir
LLM'lerin bunun küçük bir kısmını bile üstlenebileceğini hayal edemiyorum
Hayatımda tek bir kez bile gereksinimleri net verilmiş bir yazılım projesi görmedim
Projenin yarısı zaten ‘aslında ne istendiğini anlama işi’
LLM daha junior seviye bile değil
Eğer mevcut AI gerçekten şirketinizdeki mid seviye geliştirici düzeyindeyse, bu şirketin işe alım sorunu demektir
Bilgisayarların en büyük avantajlarından biri güvenilir ve tekrarlanabilir otomasyon sağlamalarıdır
Programlama dilleri gibi biçimsel diller, istenen otomasyon gereksinimlerini belirsizlik olmadan açıkça ifade etmeyi sağlar
Doğal dil bu kadar kesin değildir
Bir programın gerçek dayanağı nihayetinde koddur
İnsan bir programın davranışını gerçekten denetlemek istiyorsa, en önemli şey kodu anlayıp değiştirebilme yeteneğidir
“Manual” kelimesinin olumsuz bir çağrışımı var
O haberde kastedilen şey "insan kodlaması hâlâ merkezde" olmalı
GitHub CEO'sunun gerçekten "manual" kelimesini kullanıp kullanmadığından emin değilim. Daha nötr ya da daha doğru bir ifade kullanan bir kaynak metin olsa iyi olurdu
İnsan kodlamasını “manual” diyerek küçümsemek doğru değil. İnsan geliştiriciler de AI dışında pek çok otomasyon araç seti kullanıyor
“manuel düşünme” kadar olumsuz gelebilir
“manual”ın olumsuz çağrışımını yeni öğrenmiş oldum
Bugünlerde insanlar manuel işe gerçekten bu kadar mı tepki duyuyor diye merak ediyorum
“manual coding” ile “human coding” arasındaki ayrım tam olarak ne?
“Yalnızca AI ajanlarına güvenmek verimsiz olabilir”
Örneğin basit bir değişikliği doğal dille uzun uzun anlatmak yerine, kodu doğrudan düzenlemek çoğu zaman çok daha hızlıdır
Bu yüzden AI ajanlarıyla aktif etkileşim en iyi iş akışı olabilir
Değişikliği doğal dille düşünmeye başlayınca, daha yazmadan kafamda doğrudan gerekli düzenleme beliriveriyor
Bağlamı yoğun değişikliklerde agent'tan daha hızlı davrandığımı fark ediyorum
Ne kadar aktif etkileşimin makul olduğunu merak ediyorum
Yakın zamanda ajan araçları geliştiren bir startup'a katıldım ve içeride bunu çok tartışıyoruz
Agente sürekli “açıkçası bunu iyi yapmıyorsun!” diye geri bildirim vermek bence kabul edilebilir, ama bir noktadan sonra yorucu da olabilir
Bu konuda ne düşündüğünüzü, iş akışına dair başka hayal ya da geri bildiriminiz olup olmadığını merak ediyorum
AI henüz beklendiği kadar olgunlaşmadı
Örneğin ben sık sık yanlış referans materyaller ya da specification'lar yüzünden zorlanıyorum. Bunun nedeni AI'ın eski verilerle eğitilmiş olması ve gerçek zamanlı güncelleme yeteneğinin sınırlı kalması olabilir
Mevcut LLM ve GI çözümleri, tüm aşamaları (n-step) tek seferde çözmeye çalıştığı için yarardan çok zarar veriyor
Aslında 1. adımdan i. adıma kadar olan kısmı düzgün halletse bile insan için çok daha yararlı olurdu
Hâlâ istediğim türden tam modüler bir AI çözümü görmedim (örneğin benim GitHub tarzımı yansıtıp yalnızca a, b, c kaynaklarına bakarak x problemini çözmesi gibi)
Ayrıca problemi adım adım keşfeden, aralarda daha fazla soru soran ve diyalog kuran bir kodlama AI'ı görmeyi umuyorum
AI ve kodlama konusunda biraz farklı yönde konuşan bir CEO görmek etkileyiciydi
Genelde CEO'lar ya da yatırımcılar “kodun %30'undan fazlasını AI yazıyor” diyerek geliştirici rolünün küçüleceğini öngörüyor; burada ise aslında olan şeyin, aynı geliştiricilerin kodu daha hızlı yazmak için araç kullanması olduğu söyleniyor
Kod yazmanın, yazılım geliştirme işinin sadece bir parçası olduğu özellikle vurgulanıyor