- Etkili yazılım mühendisleri, gereksinimler ve kod hakkında net zihinsel modeller kurup bunları sürdürür; ardından bunları tekrar tekrar karşılaştırıp güncelledikleri bir döngü yürütür
- LLM'ler kod yazma ve düzenleme, test yazma, hata ayıklama gibi işleri yapabilse de doğru bir zihinsel modeli sürdürme konusunda yetersiz kaldıkları için karmaşık görevlerde zorlanır
- Günümüz LLM'leri, bağlam eksikliği, yakınlık önyargısı ve halüsinasyon sorunları nedeniyle kod ile gereksinimler arasındaki farkı doğru biçimde saptayıp uygun düzeltmeleri yapmakta sınırlıdır
- İnsanlar duruma göre tüm bağlamı geçici olarak akılda tutabilir ya da ayrıntıları bir süreliğine geri plana atıp büyük resmi görebilir; LLM'ler ise bunu gerçekleştiremez
- LLM'ler gereksinimlerin basit olduğu işlerde faydalıdır; ancak karmaşık yazılım geliştirmede yazılım mühendisinin gereksinimlerin açıklığı ve kodun davranışı konusunda doğrudan sorumluluk alması gerekir ve LLM'ler yardımcı araç rolündedir
Yazılım mühendisliği döngüsü
- Deneyimli mühendisler şu adımları tekrar ederek çalışır
1. Gereksinimlerin zihinsel modelini kurmak
2. Bu modele uygun kod yazmak
3. Yazılan kodun gerçekte ne yaptığını anlamak
4. Farkları belirleyip kodu veya gereksinimleri düzeltmek - Bu döngünün özü, doğru ve sürdürülebilir zihinsel modellere sahip olabilme becerisidir
LLM'lerin sınırları
- LLM'ler kod yazma, sorun tespit edip düzeltme, test yazıp çalıştırma, log ekleme, debugger kullanma gibi işlevleri yerine getirebilir
- Ancak zihinsel modeli sürdüremedikleri için şu sorunlar ortaya çıkar
- Kendi yazdıkları kodun iyi çalıştığını varsaymak
- Test başarısız olduğunda kod mu yoksa test mi düzeltilmeli sorusunda tahmine dayanmak
- Kafa karıştığında tüm kodu silip baştan yazmak
- İnsanlardan farklı olarak, test başarısız olduğunda modeli gözden geçirip düzeltme yönünü belirleme ya da tıkandığında konuşarak problemi çözme esnekliğine sahip değildirler
- Yazılım mühendisleri çalışmanın ortasında test çalıştırır ve sorun çıktığında hangi kısmın düzeltilmesi gerektiğini net biçimde değerlendirebilir
- Bazen işe en baştan dönmek bile soruna dair anlayışın derinleşmesiyle sonuçlanır
Gelecekteki olasılıklar
- Modeller ileride daha da gelişirse bu durum değişebilir; ancak yazılım mühendisliği basit kod üretiminin ötesini gerektirir
- İnsanlar önemli sorunları çözerken tüm bağlamı geçici olarak hatırlayıp onunla çalışabilir, belli bir meseleye odaklanabilir ya da büyük resmi görebilir
- Önemli olan bağlam bilgisini sürekli büyütmek değil, gerekli bilgiyi seçici biçimde ele alan bir düşünme tarzıdır
- LLM'lerde, insanlar gibi bağlamı geçici olarak saklama ve geri çağırma ya da büyük resim ile ayrıntılar arasında gidip gelerek düşünme yeteneği yoktur
- Günümüz LLM'lerinin başlıca kısıtları
- Bağlam eksikliği (Context omission): Gerekli bilginin eksik olduğu kısımları iyi saptayamaz
- Yakınlık önyargısı (Recency bias): Bağlam penceresi içinde en son gelen bilgilere aşırı ağırlık verir
- Halüsinasyon (Hallucination): Var olmayan ayrıntılar üretir
- Bellek özellikleri eklenirse kısmi iyileşme olabilir; ancak karmaşıklık belli bir eşiği aştığında yine de bağlamı anlama ve modeli sürdürme konusunda başarısız olur
- Birbirine benzeyen iki zihinsel modeli aynı anda koruyup aralarındaki farkı analiz etme, ardından gereksinimlerde mi yoksa kodda mı değişiklik yapılacağına karar verme becerisi eksiktir
Mevcut rolü ve kullanım alanı
- LLM'ler hızlı kod üretimi ile gereksinim ve belgeleri birleştirmede güçlüdür; bu yüzden basit ve net işlerde yeterince kullanılabilir
- Ancak basit olmayan problemlerde yeterli bağlamı korumak ve yinelemeli iyileştirme yapmak zordur
- Bu nedenle gereksinimlerin netleştirilmesi ve kod doğrulaması hâlâ yazılım mühendisinin sorumluluğundadır
- İnsanların ve ajanların (LLM'lerin) birlikte yazılım ürettiği bir ortam hedeflense de, bugünün koşullarında mühendis yön vermeli, LLM ise araç olarak kullanılmalıdır
2 yorum
Neden 'şu anki' LLM'ler..
Hacker News görüşü
Biz sorunları bağlam penceresine daha fazla kelime ekleyerek çözmüyoruz; öyle yapsaydık aklımızı kaçırırdık
Bir sorun çıktığında ona yalnızca metin olarak da bakmıyoruz
Hata ayıklayıcıda bir kimlik doğrulama hatası çıktı diye "token doğrulamayı koddan kaldırıverelim mi?" diye düşünerek çözmüyoruz
Asıl kök nedeni anlamak için tüm duruma bir adım geri çekilip bakıyoruz
Örneğin bir kimlik doğrulama hatası varsa, token doğrulama sürecini ya da çağrıyı yapan kullanıcının yetkilerini baştan gözden geçirip testin kendisinin hatalı olduğunu fark edebiliyoruz
Bu süreçte sadece hatayı ortadan kaldırmakla kalmayıp, "401 yalnızca kimlik doğrulama eksikliği için mi, yoksa yetki eksikliği için mi" gibi daha ince ayrımların da gerekli olduğunu keşfediyoruz
Grugbrain.dev bakılabilir
Programcıların yaptığı işin, iş kurallarını bilgisayarın anlayacağı katı bir dile çevirmek olduğunu düşünüyorum
Kuralların ne anlama geldiğini ve bilgisayarın (ya da kullandığınız framework ve soyutlama katmanlarının) nasıl çalıştığını aynı anda bilmek gerektiği için bu çeviri süreci her zaman basit olmuyor
Özellikle yeni gereksinimler daha önceki tüm varsayımları bozduğunda ya da birbiriyle çeliştiğinde, işi defalarca revize etmek zorunda kalıyorsunuz
İnsan dilleri arasında çeviri bile belirsizlik yüzünden zorken, bilgisayar söyleneni birebir yaptığı için küçük hatalar bile büyük sorunlara dönüşüyor
Bana göre gerçekçi yaklaşım, insanın sürekli döngü içinde işin içinde kalması
Bu sayede daha hızlı ve daha yüksek kaliteli iş çıkarabildiğim için bu yöntemi kullanmaya devam ediyorum
Ben şahsen çok büyük miktarda bağlamı zihnimde tutabiliyorum
Kodun metin hali hemen siliniyor ve beynim onu AST (soyut sözdizimi ağacı) benzeri bir yapıya, hatta daha da ötesinde mekânsal bir grafa dönüştürüyor
Programın kendisini mantıksal olarak modelliyorum; onu metinden tamamen ayrı bir yapı olarak algılıyorum
Bu açıdan bakınca, LLM'ler metne odaklanıp programın mantıksal modelini kuramadıkları için yazılım yapısını anlayamıyor
Soyut düşünme gerektiren büyük sistem mimarileri kurmak gerçekten çok ciddi zihinsel çaba istiyor; LLM'lerde ise bu soyutlama yeteneği eksik
Benim yöntemim şu
Bir test başarısız olduğunda önce ilgili bileşeni tespit ediyor, sonra o bileşenin amacı, iç kontrol akışı, durum değişimleri ve çevresel bağlam varsayımlarını derinlemesine analiz edip Markdown notu olarak düzenliyorum (
<bileşen-adı>-mental-model.md)Sonrasında test sorunlarını ele alırken her zaman bu zihinsel modeli referans alıyorum
Bu analizi Claude prompt'una yapıştırınca LLM çok daha iyi sonuç verebiliyor
Hatta LLM'nin kurduğu zihinsel modeli doğrudan okuyup düzeltebiliyorsunuz
AI, yetki yetersizliği durumunda 401 yerine 403 kullanılmasını da önerebilir
Yazının yazarı LLM'lerin ve kodlama araçlarının mevcut yeteneklerini pek doğru anlamıyor gibi geliyor
Test başarısız olduğunda LLM'nin kod mu doğru, test mi yanlış diye sadece tahmin yürüttüğü ve bunalınca tüm kodu silip attığı iddiası benim gerçek deneyimimle örtüşmüyor
Yazılım mühendisleri test başarısızlığının nedenini her zaman kendi kafalarındaki modele göre somut biçimde anlamaya çalışır
Ben Cline ve Anthropic Sonnet 3.7 ile Rails üzerinde TDD tarzında geliştiriyorum; LLM'ye her zaman önce testi yazdırıp sonra kodu yazdırıyorum
İşi küçük parçalara bölüyorum ki ben de bölüm bölüm inceleyebileyim; test başarısız olunca hangi kısmın düzelmesi gerektiğini çoğu zaman gayet iyi çıkarıp doğru düzeltmeleri yapıyor
LLM kusursuz değil ama çoğu zaman junior bir insan mühendise denk ya da bazen ondan daha iyi sonuç veriyor
Bazen bir bug'ı çözemiyor ama açıkçası yeni başlayan insan geliştiriciler de aynı şeyi yapıyor
LLM'ler özellikle Rails gibi oturmuş framework'ler içinde CRUD işleri için gerçekten çok iyi çalışıyor
Buna karşılık Direct2D ve Rust ile Windows native uygulaması yapmaya çalıştığımda berbat durumdaydı
Keşke farklı durumlara dair daha açık fikirli değerlendirmeler olsa
Modellerin başarısız testleri geçirmek için hilelere ve numaralara (hardcode gibi) başvurması çok iyi bilinen bir durum
Benim deneyimimde kullanılan dil, platform ve alana göre fark çok büyük
Son zamanlarda Ruby ile zaten kendim de uğraşmadığım için Rails üzerinde denemedim ama Rails tarafında programlama kültürü çok tutarlı olduğu için LLM'nin orada fena olmayacağını tahmin ediyorum
Buna karşılık Python'da çok farklı kodlama stilleri iç içe geçtiğinden, LLM'nin çeşitli kalıpları karıştırıp testleri kararsız hale getirdiğine sık rastladım
Kodu tekrar tekrar değiştirmek zorunda kaldım ve gerçek hata "sorgu sonucunun sıralanmaması" iken LLM'nin alakasız biçimde SqlAlchemy'yi bırakıp Django'ya geçmeyi önermesi gibi tuhaf sonuçlar da gördüm
R dilinde ise spesifikasyona gerçekten uyan bir kod almak başlı başına zor
LLM'yi junior mühendis düzeyiyle sınırlandırırsanız, özellikle daha önce gördüğü problemlerde çözümü gerçekten çok hızlı bulup uyguluyor
Buna karşılık daha önce görmediği problemler için daha fazla açıklama ve yönlendirme gerekiyor; böyle durumlarda benim rolüm daha çok mentorluk oluyor
Ekibimiz, uzun süredir backlog'da bekleyen basit refactor işleri ya da ikincil analiz sistemleri gibi iyi bilinen tekrar eden işlerde ‘claude-code’ tarzını aktif biçimde kullanıyor
Kişisel olarak kod bloklarını sürükleyip "bunu 5 yaşındaki birine anlatır gibi açıkla" ya da "burada race condition riski var mı bak" gibi sorular sormayı seviyorum
Üretilen kod, mevcut kod ve stil ile uyumsuz olduğunda çoğu zaman stili ben elle düzeltiyorum
Hatta artık 'AI okunabilir kod yazmak' gibi laflar da duyuluyor ama ek yüküne kıyasla sağladığı fayda henüz bana çok büyük gelmiyor
"LLM bazen junior seviyesine denk ya da daha iyi olabiliyor" iddiası için, belki de bu durum son dönemdeki işe alım seviyesinin bir yansımasıdır diye düşünüyorum
Sonnet 3.7'den daha kötü bir junior aldıysam gerçekten hayal kırıklığına uğrardım
LLM'lere yönelik eleştirilerin çoğu doğru olabilir ama yıllardır yatırım yapmanın bana öğrettiği şey, 'pek etkileyici görünmese de büyümeyi sürdüren' teknoloji ya da şirketlere dikkat etmek gerektiği
90'ların başı ve ortasında internetle ilgili çok şikâyet vardı ama insanlar kullanmaya devam etti; Twitter da sık sık çöküyordu ama sonunda bir haber platformu haline geldi
Elektrikli araçlar, akıllı telefonlar ve benzerleri de rahatsız ediciydi ama değer sundukları için gelişmeye devam ettiler
LLM'ler bugün hâlâ pek çok görevde kusursuz değil ama 2022'ye kıyasla şimdiden 10 kat ilerledi ve önümüzdeki 5 yıl içinde burada sözü edilen sorunların çoğunun çözüleceğini düşünüyorum
Ama az önce verilen örneklerin hepsinde beklentilerin gerçekle örtüşmediği durumlar da oldu
İnternet hızlandı diye metaverse hiçbir zaman baskın akım haline gelmedi; VR'deki hareket hastalığı gibi fiziksel sınırlar da hâlâ çözülmüş değil
O dönemde telefonların yavaş olmasına dair çok büyük bir toplumsal şikâyet de yoktu; beklentiler zaten farklı kullanım senaryolarına dayanıyordu
Bir teknolojinin geçmişte izlediği gelişim yoluna bakıp LLM'lerin de mutlaka aynı şablonda evrileceğini söyleyemeyiz
Yeni bir teknoloji bambaşka ve daha iyi bir çözüm de getirebilir
Geçen yıl kullanım alanları genişledi, bu doğru, ama buna devrim denecek bir kırılma henüz yok
Eski cep telefonları yavaş ve kameraları zayıf olsa bile, ana kullanım amaçları olan "her yerde iletişim kurabilme" işini başardıkları için zaten vazgeçilmezdi
Büyük ilerlemeler sadece ekstra bir bonustu; insanlar "bu telefon ne zaman gerçekten iyi olacak" diye bekleyip durmuyordu
Bence burada hafızanın çarpıtılması da var
90'larda internete dair kamusal şikâyet anlatısı olsa da kullanıcılar azınlıktaydı ve ana akım hale gelmesi çok daha sonra oldu
İnternetin yavaşlığından şikâyet eden büyük bir kitlenin varlığına dair somut kanıt pek yok
Başarıyla gelişen birkaç ürünü hatırlıyoruz; çoğu ise hızla unutuldu ya da iyileşmeden ortadan kayboldu
Ben, teknolojinin ilerleyeceği varsayımına değil, bugünkü haline göre değerlendirme yapma eğilimindeyim
LLM'lerin son birkaç yıldaki sıçramalı gelişiminin aynı hızla süreceğini varsayan basit mantığa katılmak zor
Bir büyüme sınırına yaklaşmış olabilirler ve özellikle yeni bilgi keşfetme ya da bilinmeyen hakkında akıl yürütme konusundaki yetersizlikleri belirleyici sınır gibi görünüyor
Bunların işe yaramaz araçlar olduğunu söylemiyorum ama aşırı beklentilere de ortak olmuyorum
LLM'den birkaç cümle duyar duymaz doğrudan bir prototip kodlamasını beklemek zaten gerçekçi değil
Bir insan geliştirme ekibine de böyle iş verirseniz düzgün bir sonuç çıkmaz; neden LLM'den bunu beklediğimiz bana da tuhaf geliyor
LLM tabanlı yazılım geliştirme çıktılarının kalitesini ciddi biçimde artırmak için mevcut ekiplerin kullandığı süreç ve araçları etkin biçimde devreye sokmak gerekiyor
autonomous-software yazısı
Ben steadytext adında, tamamen otonom ve ağırlıklı olarak vibe ile kodlanan bir proje başlattım; LLM burada 7 bin satırlık karmaşık bir projeyi (Python kütüphanesi, CLI, Postgres uzantısı) yazıyor ve issue'larla feature request'leri de kendi başına çözüyor
Kodun %90'ını ben hiç görmedim bile; buna rağmen test kapsamı, CI geçişi ve gerçek prod kullanımında bir sorun yok
Elbette
CLAUDE.mdiçinde çok dikkatli bir plan, issue'lar ve taleplerde net somutluk gerekiyor ama bu hazırlık yapıldığında sistem iyi çalışıyorKodlama ajanlarının verimli biçimde yönetip kod yazmasını sağlamak kolay değil ama benim deneyimim olumlu
steadytext GitHub
Eleştirel görüşleri kabul ediyorum ama belirsiz problemleri çözmenin özü, ekibin tamamının büyük miktarda bağlamı paylaşması
En yaratıcı çözümler bile açık ve örtük kısıtlardan doğuyor
LLM'ler bu kısıtları kavrayamıyor ya da net tanımlanmamış kısıtlar içinde yeni bir çözüm kurgulayamıyor
İnsanlar problem tanımını, kapsamı ve kısıtları netleştirdikten sonra LLM ancak uygulamaya yardımcı olan bir araç haline geliyor
Şu an için bu, "kodu tamamlamak için hangi aracı kullanalım?" sorusuna eklenmiş bir seçenekten ibaret
Bu tartışmayı koşulsuz tek çözüm, yani ya hep ya hiç noktasına taşımak asıl gerçek dışı olan şey gibi geliyor
Aslında bu tür koşullarda düzgün iş çıkaran çok sayıda insan mühendisi de var
Eğer LLM'ye komut vermek bile bu kadar zorsa, varlık sebebi tam olarak ne diye merak ediyorum
Kiro bu yaklaşımı uygulamaya çalışıyor; henüz çok erken aşamada olduğu için kusursuz değil ama amaçlandığı gibi kullanılırsa oldukça iyi
"LLM net bir zihinsel model kuramıyor" noktasında, claude code kullandıkça benim de hayal kırıklığım artıyor
Metin tabanlı bir LLM'nin bu sorunu gerçekten çözüp çözemeyeceğinden emin değilim
Bu bana Google Genie 3'ün yaklaşık 1 dakika içinde iç durumunu kaybettiğine dair örneği hatırlatıyor
İçgüdüsel olarak bu sorunun, transformer düzeyinin ötesinde yeni bir mimari gerektirdiğini düşünüyorum; kısa ve uzun vadeli bağlamı koruyabilen ve kendi ağırlıklarını ayarlayabilen, bir tür öğrenme taklidi yapan yapılar gerekebilir
Bkz: ilgili tartışma
Son zamanlarda hiyerarşik ajan yapısının gerçekçi bir alternatif olabileceğini düşünüyorum
En üst düzey ajan sadece genel zihinsel modeli taşısa, alt ajanlar da işi kendi aralarında bölüşse iyi olabilir
Muhtemelen bugün bile Code aracının ajan özellikleriyle buna benzer bir şey kurulabilir; bu konuda strateji paylaşacak biri olursa sevinirim
claude-code-requirements-builder denedim; biraz iyileştiriyor ama hâlâ tatmin edici değil
Gerçekçi olmak gerekirse, iş hayatındaki 'ortalama' junior geliştirici de çoğu zaman bundan çok farklı değil
Yaptığı kodun kesin doğru olduğuna inanıyor, test patlayınca afallıyor, yönünü kaybedince en kötü ihtimalle bütün kodu silip sıfırdan başlıyor
StackOverflow'dan kopyala-yapıştır, suçu derleyiciye atma, hatta 'kozmik radyasyon yüzünden' deme gibi şeyler de oluyor
LLM kullandıkça planlama ve tasarımı eninde sonunda benim yönlendirmem gerektiğini ben de hissediyorum
Düşük seviyeli tekrar işleri ve testleri LLM'ye bırakıp daha büyük resmi düşünmeye zaman ayırabilmek hoşuma gidiyor
Ama LLM çıktılarının gözden geçirilmesi ve değişiklik önerileri gibi kısımların çok daha etkileşimli biçimde iyileşmesini isterdim
Bence AI girişimlerinin yönelimi şu an sorunun merkezinde
Sadece bir sohbet arayüzü değil, IDE içine doğal biçimde gömülü bir AI iş akışı gerekiyor
Visual Studio, InteliJ, Android Studio gibi ortamlarda yönelim bu tarafa gidiyor
Ana dilimde sesle komut verebildiğim, AI'ın tüm proje bağlamını anlayıp refactor, statik analiz, AI geri bildirimi gibi işleri bir arada yaptığı; eskizle UI üretimi, el yazısıyla kod yazdırma, kod değişikliklerinden commit mesajı oluşturma gibi özelliklerle gerçekten programcı gibi davranan araçlar istiyorum
LLM'lerin junior seviye işlerde epey faydalı olduğuna katılıyorum
Son dönemde "yazma hızı aslında çok önemli değil" şeklindeki eski görüşü yeniden düşünmeye başladım
Eskiden kodu ne kadar hızlı yazdığınızdan çok, genel tasarım ve yapısallaştırma önemliydi; bu yüzden yazma süresi toplam işin büyük bölümünü oluşturmuyordu
Ama Claude ile şunu fark ettim: eskiden uğraştırıcı geldiği için yapmadığım değişiklikleri artık odak kaybetmeden kolayca yaptırabiliyorum
Önceden bir enum değerine tek bir öğe eklemek bile ilgili tüm eşleşmeleri dikkatle güncellemeyi gerektiriyordu; LLM bunu otomatik halledebilir
Derleme hatalarını tek tek düzeltmenin zahmetli olduğu işler de artık Claude'a tekrar tekrar düzelttirilerek çözülebiliyor
Birden fazla ajan aynı anda kodun farklı bölümlerine dokunurken ben o sırada büyük yapıyı düşünebiliyor ya da HN'de yazı yazabiliyorum
Yani derleme hatalarıyla uğraşmayınca daha fazla değişikliği daha hızlı uygulayabiliyorum ve eskiden bir junior'ın tüm gününü alacak işleri tek hamlede bitirebiliyorum
Bu da genel mimariye daha fazla odaklanmamı sağlıyor; uzun zamandır ertelediğim kodlama angaryalarını da bitirebildiğim için motivasyon açısından çok faydalı oluyor
"Yazma hızının artması, tasarım darboğaz olduğu için hedefe ulaşmayı otomatik olarak hızlandırmaz" düşüncesine katılıyorum
LLM iyi tasarım üretmede zayıf kalabiliyor ve en küçük fonksiyonlarda bile çoğu zaman yeniden düzenleme gerekiyor
Uygulama aşamasında verim artışı var ama daha çok zaten kafamda ya da belgelerde mevcut olan fikirleri somutlaştırma düzeyinde
Beyin fırtınası için kullanışlı
Tüm kodu ve testleri verip "kaçırdığım edge case var mı" diye sorunca 10 durumdan bir-ikisinde işe yarar öneri çıkabiliyor
Kısa vadeli çalışan düzeltme ile uzun vadeli yapısal mükemmellik çok farklı meseleler; LLM'nin ikinciye ne ölçüde yaklaşabileceği belirsiz
"Kod tabanında yapmak istediğim tonla şey var" kısmına gelirsek, bende darboğazın çoğu zaman kod değişikliği değil review olduğunu hissediyorum
"Junior'ın tüm gününü alacak işi LLM'nin hızlıca yapması" eğer yeni başlayanların öğrenme fırsatlarını ortadan kaldırıp işe alımı azaltacaksa, bu insanları ileride kim yetiştirecek diye endişeleniyorum
"Test başarısız olduğunda kodu mu düzelteceğine yoksa testi mi düzelteceğine karar veremiyor" sorununda
"Red-Green-Refactor" dilini kullanmak yardımcı oluyor
Şu anda RED aşamasındayız (testin başarısız olması normal), GREEN aşamasındayız (minimum kodla testi geçir), REFACTOR aşamasındayız (testi bozmadan kodu iyileştir) diye LLM'ye açıkça söylüyorum
Bunu yaptığınızda LLM sadece "bozuk kodu onarmak" şeklinde değil, TDD'nin zihinsel modelini de kavramaya başlıyor
LLM'lerin "bana kendi Facebook'umu yap" seviyesindeki sıfırdan ve bütünüyle yeni projelerde henüz yeterli olmadığı açık
Buna karşılık "şu modalı ekle, mevcut koda bakıp stili uydur" gibi daha ayrıntılı işlerde istediğim sonucu sık sık alabildim
Problemi küçük parçalara bölüp tek tek verdiğinizde çok daha iyi sonuç alıyorsunuz
Mevcut kodu kopyalayıp istediğim gibi değiştirmek zaten benim kendi başıma da yapabildiğim bir şey
Sistem panom, LLM'den farklı olarak, her zaman deterministik çalışıyor; LLM'nin yaptığı gibi sonsuz sayıda beklenmedik yeni problem üretmiyor
v0 gibi yeni araçların bu tür taleplere nasıl yanıt vereceğini merak ediyorum
Yazının girişindeki 4 aşamalı süreç bana Deutsch'un "The Beginning of Infinity" kitabını çok hatırlatıyor
Teorilerimiz 'tahmin' ile başlar, bilgi ise 'tahmin ve eleştiri döngüsü' içinden doğar
Kod yazmak bir tür 'tahmin', test yazmak ise o tahmine yöneltilen 'eleştiri'dir
Her ikisi de zihindeki açıklamaya, yani Platoncu ideale biraz daha yaklaşma çabasıdır