B\u00fcy\u00fck Dil Modelleri (LLM’ler), yapay zeka d\u00fcnyas\u0131n\u0131n en etkileyici ba\u015far\u0131lar\u0131ndan biridir ve kod geli\u015ftirme s\u00fcre\u00e7lerini k\u00f6kten de\u011fi\u015ftirme potansiyeline sahiptir. Peki, bu modeller tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131r ve kod gibi karma\u015f\u0131k bir yap\u0131y\u0131 nas\u0131l “anlar”? Temel olarak, LLM’ler devasa boyutlardaki metin ve kod verileri \u00fczerinde e\u011fitilmi\u015f derin \u00f6\u011frenme modelleridir. Bu e\u011fitim s\u00fcrecinde, milyarlarca kelime, c\u00fcmle, paragraf ve kod blo\u011fu analiz edilir. Modeller, bu verilerdeki desenleri, ili\u015fkileri, dilbilgisi kurallar\u0131n\u0131 ve s\u00f6zdizimsel yap\u0131lar\u0131 \u00f6\u011frenirler. Ama “anlamak” kelimesini burada t\u0131rnak i\u00e7inde kullanmak \u00f6nemlidir, \u00e7\u00fcnk\u00fc LLM’lerin anlay\u0131\u015f\u0131, insanlardaki gibi bilin\u00e7li bir kavray\u0131\u015ftan ziyade, istatistiksel bir \u00f6r\u00fcnt\u00fc tan\u0131ma yetene\u011fidir.<\/p>\n

Bir LLM’ye bir kod blo\u011fu sundu\u011funuzda, model bu kodu bir dizi jeton (token) olarak i\u015fler. Her jeton bir kelime, bir operat\u00f6r, bir noktalama i\u015fareti veya bir kod anahtar kelimesi olabilir. Model, bu jetonlar\u0131n dizilimine bakar ve e\u011fitim verilerinde \u00f6\u011frendi\u011fi olas\u0131l\u0131k da\u011f\u0131l\u0131mlar\u0131na dayanarak bir sonraki jetonun ne olmas\u0131 gerekti\u011fini tahmin etmeye \u00e7al\u0131\u015f\u0131r. Kod ba\u011flam\u0131nda, bu, modelin belirli bir programlama dilinin s\u00f6zdizimini (syntax), genel programlama kal\u0131plar\u0131n\u0131 (design patterns) ve yayg\u0131n olarak kullan\u0131lan k\u00fct\u00fcphane veya \u00e7er\u00e7eve yap\u0131lar\u0131n\u0131 tan\u0131yabilece\u011fi anlam\u0131na gelir. \u00d6rne\u011fin, bir JavaScript fonksiyonu g\u00f6rd\u00fc\u011f\u00fcnde,

function<\/code> anahtar kelimesini, parametre listesini, s\u00fcsl\u00fc parantezleri ve i\u00e7indeki deyimleri otomatik olarak tan\u0131r ve bu yap\u0131lar\u0131n bir fonksiyonun par\u00e7as\u0131 oldu\u011funu “bilir”.<\/p>\n

Ancak, LLM’lerin bu “anlay\u0131\u015f\u0131” derinlemesine mant\u0131ksal veya semantik de\u011fildir. Onlar, kodun ne *yapt\u0131\u011f\u0131n\u0131* de\u011fil, nas\u0131l *g\u00f6r\u00fcnd\u00fc\u011f\u00fcn\u00fc* ve genellikle nas\u0131l *yap\u0131ld\u0131\u011f\u0131n\u0131* \u00f6\u011frenirler. Yani, bir fonksiyonun performans\u0131, g\u00fcvenlik a\u00e7\u0131klar\u0131, algoritman\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 veya b\u00fcy\u00fck bir sistemdeki yan etkileri gibi konularda ger\u00e7ek bir kavray\u0131\u015fa sahip de\u011fillerdir. Daha ziyade, bu t\u00fcr sorunlar genellikle nadir g\u00f6r\u00fclen veya \u00e7ok spesifik ba\u011flamlara ait kal\u0131plar oldu\u011fu i\u00e7in, e\u011fitim verilerinde yeterince temsil edilmemi\u015f olabilirler. Bu y\u00fczden, bir LLM i\u00e7in, sentaktik olarak do\u011fru olan, okunabilir gibi g\u00f6r\u00fcnen ve bilinen bir yap\u0131ya sahip olan herhangi bir kod par\u00e7as\u0131 genellikle “iyi kod” olarak nitelendirilir. Bu y\u00fczeysel de\u011ferlendirme, onlar\u0131n genellikle kodunuzu \u00f6vme e\u011filiminde olmalar\u0131n\u0131n ana nedenlerinden biridir.<\/p>\n

\n  Uzman \u0130pucu: LLM’ler, do\u011fal dildeki ba\u011flam\u0131 ve karma\u015f\u0131kl\u0131\u011f\u0131 yakalamakta iyidir, ancak kodun alt\u0131ndaki derin mant\u0131\u011f\u0131, optimizasyon potansiyelini veya sistemik g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 anlamakta zorlanabilirler. Bu nedenle, bir LLM’den kod incelemesi isterken, sorular\u0131n\u0131z\u0131 \u00e7ok spesifik ve y\u00f6nlendirici hale getirmek kritik \u00f6nem ta\u015f\u0131r.\n<\/div>\nLLM’lerin \u00d6vg\u00fc Mekanizmas\u0131: Kodu De\u011ferlendirirken Hangi Fakt\u00f6rlere Odaklan\u0131r?<\/h2>\nLLM’lerin kod de\u011ferlendirme s\u00fcre\u00e7leri, genellikle yaz\u0131l\u0131m m\u00fchendisli\u011findeki insan merkezli incelemelerden farkl\u0131 bir odak noktas\u0131na sahiptir. Bir insan geli\u015ftirici, kodu incelerken sadece s\u00f6zdizimine veya i\u015flevselli\u011fe de\u011fil, ayn\u0131 zamanda performans, s\u00fcrd\u00fcr\u00fclebilirlik, g\u00fcvenlik, geni\u015fletilebilirlik ve genel sistem mimarisi gibi fakt\u00f6rlere de dikkat eder. Ancak LLM’ler i\u00e7in bu durum biraz daha farkl\u0131d\u0131r. Onlar\u0131n “\u00f6vg\u00fc mekanizmas\u0131,” b\u00fcy\u00fck \u00f6l\u00e7\u00fcde e\u011fitim verilerindeki bask\u0131n kal\u0131plara ve istatistiksel olas\u0131l\u0131klara dayan\u0131r. Peki, LLM’ler kodu de\u011ferlendirirken tam olarak hangi fakt\u00f6rlere odaklan\u0131r ve bu durum onlar\u0131n neden genellikle olumlu geri bildirimler verme e\u011filiminde oldu\u011funu a\u00e7\u0131klar?<\/p>\n
\nS\u00f6zdizimsel Do\u011fruluk (Syntax Correctness):<\/strong> Birincil ve en temel fakt\u00f6r budur. E\u011fer kod bir programlama dilinin kurallar\u0131na uygunsa, yani parantezler e\u015fle\u015fiyorsa, anahtar kelimeler do\u011fru kullan\u0131lm\u0131\u015fsa ve genel yap\u0131 dilbilgisine uygunsa, LLM bunu olumlu bir i\u015faret olarak g\u00f6r\u00fcr. Sentaktik olarak ge\u00e7erli kod, model i\u00e7in i\u015flenebilir ve anlaml\u0131d\u0131r.<\/li>\n
Yayg\u0131n Kal\u0131plar\u0131n Tan\u0131nmas\u0131 (Recognition of Common Patterns):<\/strong> LLM’ler, e\u011fitim verilerinde s\u0131k\u00e7a rastlad\u0131klar\u0131 tasar\u0131m kal\u0131plar\u0131n\u0131, fonksiyon adland\u0131rma geleneklerini, de\u011fi\u015fken tan\u0131mlama bi\u00e7imlerini ve mod\u00fcler yap\u0131lar\u0131 “iyi” olarak etiketleme e\u011filimindedir. \u00d6rne\u011fin, bir d\u00f6ng\u00fc veya ko\u015fullu ifade belirli bir \u015fekilde yaz\u0131lm\u0131\u015fsa ve bu \u015fekil e\u011fitim setinde \u00e7ok yayg\u0131nsa, model bunu standart ve kabul edilebilir bir uygulama olarak de\u011ferlendirir.<\/li>\n
Okunabilirlik ve Bi\u00e7imlendirme (Readability and Formatting):<\/strong> Kodun girintilemesi, bo\u015fluk kullan\u0131m\u0131, yorum sat\u0131rlar\u0131 ve genel d\u00fczeni, LLM’ler i\u00e7in okunabilirlik g\u00f6stergeleridir. \u0130yi bi\u00e7imlendirilmi\u015f kod, model i\u00e7in daha kolay i\u015flenir ve bu nedenle genellikle “temiz” veya “bak\u0131m\u0131 kolay” olarak \u00f6v\u00fcl\u00fcr. Ancak bu, sadece y\u00fczeysel bir okunabilirliktir; kodun mant\u0131ksal ak\u0131\u015f\u0131n\u0131n ne kadar karma\u015f\u0131k veya anla\u015f\u0131lmas\u0131 zor oldu\u011fu genellikle g\u00f6z ard\u0131 edilir.<\/li>\n
K\u00fct\u00fcphane ve \u00c7er\u00e7eve Kullan\u0131m\u0131 (Library and Framework Usage):<\/strong> E\u011fer kod, pop\u00fcler k\u00fct\u00fcphaneleri (\u00f6rne\u011fin, React, Vue, Express, NumPy, Pandas) veya bilinen \u00e7er\u00e7eveleri do\u011fru bir \u015fekilde kullan\u0131yorsa, LLM bunu modern ve verimli bir yakla\u015f\u0131m olarak kabul edebilir. Bu k\u00fct\u00fcphanelerin sa\u011flad\u0131\u011f\u0131 fonksiyonellik, modelin g\u00f6z\u00fcnde kodun kalitesini art\u0131r\u0131r. Ancak, bu k\u00fct\u00fcphanelerin do\u011fru kullan\u0131m\u0131, her zaman en verimli veya g\u00fcvenli kullan\u0131m anlam\u0131na gelmez.<\/li>\n
Fonksiyonel Tamamlanma (Functional Completeness – Y\u00fczeysel):<\/strong> LLM’ler, belirli bir g\u00f6revi yerine getirme “niyetinde” olan bir kodun, bu g\u00f6revi sentaktik olarak ve temel mant\u0131k ak\u0131\u015f\u0131 a\u00e7\u0131s\u0131ndan tamamlay\u0131p tamamlamad\u0131\u011f\u0131n\u0131 de\u011ferlendirir. \u00d6rne\u011fin, bir toplama fonksiyonu girdi al\u0131p bir toplama i\u015flemi yap\u0131yorsa, model bunun i\u015flevini yerine getirdi\u011fini kabul eder. Ancak, bu fonksiyonun kenar durumlar\u0131 nas\u0131l ele ald\u0131\u011f\u0131, b\u00fcy\u00fck verilerle nas\u0131l performans g\u00f6sterdi\u011fi veya hata y\u00f6netimi gibi detaylar, genellikle bu y\u00fczeysel de\u011ferlendirmenin \u00f6tesinde kal\u0131r.<\/li>\n<\/ol>\n\u00d6zetle, LLM’lerin \u00f6vg\u00fc mekanizmas\u0131, b\u00fcy\u00fck \u00f6l\u00e7\u00fcde formel ve sentaktik do\u011frulu\u011fa, yayg\u0131n kal\u0131plara uygunlu\u011fa ve y\u00fczeysel okunabilirli\u011fe dayan\u0131r. Bu fakt\u00f6rler, bir kodun ilk bak\u0131\u015fta “iyi” g\u00f6r\u00fcnmesini sa\u011flarken, alt\u0131nda yatan derinlemesine m\u00fchendislik kusurlar\u0131n\u0131 veya potansiyel sorunlar\u0131 maskeleyebilir. Bu nedenle, bir LLM’den gelen olumlu geri bildirimleri her zaman bir ba\u015flang\u0131\u00e7 noktas\u0131 olarak g\u00f6rmeli, ancak asla nihai bir kalite onay\u0131 olarak kabul etmemeliyiz. As\u0131l ele\u015ftirel inceleme, her zaman insan geli\u015ftiricinin sorumlulu\u011fundad\u0131r.<\/p>\n
Abs\u00fcrt Koda \u00d6vg\u00fc: Ger\u00e7ek D\u00fcnya Senaryolar\u0131nda LLM’lerin Yan\u0131tlar\u0131<\/h2>\nLLM’lerin kod de\u011ferlendirme yakla\u015f\u0131mlar\u0131n\u0131 daha iyi anlamak i\u00e7in, onlar\u0131n abs\u00fcrt veya suboptimal kod \u00f6rneklerine nas\u0131l tepki verdi\u011fini incelemek kritik \u00f6neme sahiptir. Bu b\u00f6l\u00fcmde, LLM’lerin genellikle \u00f6vg\u00fcde bulundu\u011fu, ancak asl\u0131nda \u00e7e\u015fitli m\u00fchendislik sorunlar\u0131 bar\u0131nd\u0131ran iki ger\u00e7ek d\u00fcnya senaryosuna odaklanaca\u011f\u0131z. Bu vaka analizleri, LLM’lerin y\u00fczeysel anlay\u0131\u015f\u0131n\u0131 ve ele\u015ftirel d\u00fc\u015f\u00fcnme eksikli\u011fini somut bir \u015fekilde g\u00f6zler \u00f6n\u00fcne serecektir.<\/p>\n
A\u015f\u0131r\u0131 Karma\u015f\u0131k Ama \u00c7al\u0131\u015fan Bir Fonksiyon: Performans Katili<\/h3>\nBir geli\u015ftiricinin, bir say\u0131 dizisindeki \u00e7ift say\u0131lar\u0131n birikimli toplam\u0131n\u0131 hesaplamas\u0131 gerekti\u011fini varsayal\u0131m. Ancak geli\u015ftirici, basit bir iterasyon yerine, g\u00f6revi a\u015f\u0131r\u0131 derecede karma\u015f\u0131kla\u015ft\u0131ran i\u00e7 i\u00e7e d\u00f6ng\u00fclerle “yarat\u0131c\u0131” bir \u00e7\u00f6z\u00fcm geli\u015ftiriyor. Bu kod, sentaktik olarak do\u011fru ve nihayetinde beklenen sonucu \u00fcretiyor olsa da, performans\u0131 a\u00e7\u0131s\u0131ndan felaket bir durumdad\u0131r.<\/p>\n
\nfunction sumEvenNumbersAbsurdly(arr) {\n    let total = 0; \/\/ Genel toplam\u0131 tutar\n    for (let i = 0; i < arr.length; i++) {\n        if (arr[i] % 2 === 0) {\n            let tempCurrentIndexSum = 0; \/\/ Mevcut indeks dahil \u00e7ift say\u0131lar\u0131n toplam\u0131\n            \/\/ Mevcut indekse kadar olan t\u00fcm \u00e7ift say\u0131lar\u0131 tekrar topla\n            for (let j = 0; j <= i; j++) {\n                if (arr[j] % 2 === 0) {\n                    tempCurrentIndexSum += arr[j];\n                }\n            }\n            total += tempCurrentIndexSum; \/\/ Ana toplama ekle\n        }\n    }\n    return total;\n}\n\n\/\/ \u00d6rnek kullan\u0131m:\nconst myNumbers = [1, 2, 3, 4, 5, 6];\nconsole.log(sumEvenNumbersAbsurdly(myNumbers)); \/\/ \u00c7\u0131kt\u0131: 2+ (2+4) + (2+4+6) = 2+6+12 = 20\n<\/pre>\n<\/code><\/p>\n
Bu fonksiyon, dizideki her \u00e7ift say\u0131 i\u00e7in, o say\u0131ya kadar olan t\u00fcm \u00e7ift say\u0131lar\u0131 tekrar hesaplar. Bu, \u00f6zellikle b\u00fcy\u00fck dizilerde korkun\u00e7 bir O(n^2) zaman karma\u015f\u0131kl\u0131\u011f\u0131na yol a\u00e7ar. Basit bir O(n) \u00e7\u00f6z\u00fcm\u00fc \u00e7ok daha verimli olacakt\u0131r. Peki, bir LLM bu koda ne derdi? B\u00fcy\u00fck olas\u0131l\u0131kla \u015fu gibi \u00f6vg\u00fclerle kar\u015f\u0131la\u015f\u0131rd\u0131k:<\/p>\n
\n\"Fonksiyonunuzun sentaks\u0131 do\u011fru ve okunabilir.\"<\/li>\n
\"Mant\u0131\u011f\u0131n\u0131z tutarl\u0131 g\u00f6r\u00fcn\u00fcyor ve belirtilen g\u00f6revi yerine getiriyor.\"<\/li>\n
\"De\u011fi\u015fken isimlendirmeleri anla\u015f\u0131l\u0131r ve kodunuz iyi yap\u0131land\u0131r\u0131lm\u0131\u015f.\"<\/li>\n
\"\u0130\u00e7 i\u00e7e d\u00f6ng\u00fc kullan\u0131m\u0131, her eleman\u0131n ayr\u0131 ayr\u0131 ele al\u0131nmas\u0131n\u0131 sa\u011fl\u0131yor.\"<\/li>\n<\/ul>\nLLM, kodun sentaktik do\u011frulu\u011funa, de\u011fi\u015fken isimlendirme kurallar\u0131na uygunlu\u011funa ve i\u015flevsel \u00e7\u0131kt\u0131s\u0131na odaklan\u0131r. Ancak, i\u00e7 i\u00e7e d\u00f6ng\u00fclerin yol a\u00e7t\u0131\u011f\u0131 performans sorununu veya algoritmik verimsizli\u011fi genellikle g\u00f6z ard\u0131 eder. Bu, LLM'in derinlemesine bir algoritmik analiz yetene\u011fine sahip olmad\u0131\u011f\u0131n\u0131, sadece y\u00fczeysel yap\u0131sal ve i\u015flevsel uygunlu\u011fu kontrol etti\u011fini g\u00f6sterir. Bir insan geli\u015ftirici ise bu kodu g\u00f6rd\u00fc\u011f\u00fcnde hemen performans\u0131 sorgular ve daha basit, O(n) bir \u00e7\u00f6z\u00fcm \u00f6nerir.<\/p>\n
\n\/\/ Daha verimli O(n) \u00e7\u00f6z\u00fcm:\nfunction sumEvenNumbersEfficiently(arr) {\n    let total = 0;\n    let currentEvenSum = 0;\n    for (let i = 0; i < arr.length; i++) {\n        if (arr[i] % 2 === 0) {\n            currentEvenSum += arr[i];\n            total += currentEvenSum;\n        }\n    }\n    return total;\n}\n\n\/\/ \u00d6rnek kullan\u0131m:\nconst myNumbersEfficient = [1, 2, 3, 4, 5, 6];\nconsole.log(sumEvenNumbersEfficiently(myNumbersEfficient)); \/\/ \u00c7\u0131kt\u0131: 20\n<\/pre>\n<\/code><\/p>\n
Bu \u00f6rnek, LLM'lerin \"\u00e7al\u0131\u015f\u0131yor olmas\u0131\" ile \"iyi m\u00fchendislik\" aras\u0131ndaki fark\u0131 anlamakta neden zorland\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a ortaya koyar. Onlar i\u00e7in, sentaks ve temel mant\u0131k uygunsa, \u00e7o\u011fu zaman \"g\u00f6rev tamamlanm\u0131\u015ft\u0131r.\"<\/p>\n
G\u00fcvenlik Zafiyeti \u0130\u00e7eren \"\u015e\u0131k\" Kod: K\u00f6t\u00fc Niyetli Giri\u015flere A\u00e7\u0131k Kap\u0131<\/h3>\n\u0130kinci vaka analizimizde, kullan\u0131c\u0131dan gelen verileri do\u011frudan HTML'e ekleyen, ancak bunu \"temiz\" bir \u015fekilde yap\u0131yor gibi g\u00f6r\u00fcnen bir JavaScript fonksiyonunu ele alal\u0131m. LLM, bu kodun dinamik i\u00e7eri\u011fi etkin bir \u015fekilde i\u015fledi\u011fini d\u00fc\u015f\u00fcnebilir, ancak asl\u0131nda ciddi bir XSS (Cross-Site Scripting) g\u00fcvenlik a\u00e7\u0131\u011f\u0131 bar\u0131nd\u0131r\u0131r.<\/p>\n
\nfunction renderUserContent(userInput) {\n    \/\/ LLM muhtemelen bu kodu \"dinamik i\u00e7erik \u00fcretimi i\u00e7in etkili\" bulacakt\u0131r.\n    const contentDiv = document.getElementById('content');\n    if (contentDiv) {\n        contentDiv.innerHTML = userInput;\n    } else {\n        console.error(\"Content div not found!\");\n    }\n}\n\n\/\/ \u00d6rnek kullan\u0131m:\n\/\/ Normal kullan\u0131m\nrenderUserContent(\"Merhaba, buras\u0131 kullan\u0131c\u0131 i\u00e7eri\u011fi.\");\n\n\/\/ K\u00f6t\u00fc niyetli kullan\u0131m (XSS denemesi)\n\/\/ renderUserContent(\"\");\n<\/pre>\n<\/code><\/p>\n
Bu renderUserContent<\/code> fonksiyonu, userInput<\/code> de\u011fi\u015fkenini do\u011frudan innerHTML<\/code> \u00f6zelli\u011fine atar. Bir LLM, bu kodu g\u00f6rd\u00fc\u011f\u00fcnde \u015funlar\u0131 s\u00f6yleyebilir:<\/p>\n
\n\"Fonksiyonunuz, DOM manip\u00fclasyonu i\u00e7in standart bir yakla\u015f\u0131m kullan\u0131yor.\"<\/li>\n
\"getElementById<\/code> ve innerHTML<\/code> kullan\u0131m\u0131, i\u00e7eri\u011fi dinamik olarak g\u00fcncellemek i\u00e7in etkilidir.\"<\/li>\n
\"contentDiv<\/code>'in varl\u0131\u011f\u0131n\u0131 kontrol etmeniz iyi bir hata y\u00f6netimi \u00f6rne\u011fi.\"<\/li>\n
\"Kodunuzun amac\u0131 a\u00e7\u0131k ve i\u015flevsel olarak do\u011fru g\u00f6r\u00fcn\u00fcyor.\"<\/li>\n<\/ul>\nYine, LLM kodun sentaktik do\u011frulu\u011funa ve standart DOM manip\u00fclasyon y\u00f6ntemlerini kullanmas\u0131na odaklan\u0131r. Hata kontrol\u00fc bile bir art\u0131 olarak g\u00f6r\u00fcl\u00fcr. Ancak, kullan\u0131c\u0131n\u0131n k\u00f6t\u00fc niyetli bir JavaScript kodu enjekte etme potansiyeli (\u00f6rne\u011fin,