B\u00fcy\u00fck Dil Modelleri (LLM’ler), yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerimizi d\u00f6n\u00fc\u015ft\u00fcrme potansiyeli ta\u015f\u0131yor. Ancak bu g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131 etkin ve verimli bir \u015fekilde kullanmak, genellikle tahmin etti\u011fimizden daha fazla \u00e7aba gerektirir. \u00c7o\u011fu zaman, bir g\u00f6revi otomatikle\u015ftirmek i\u00e7in LLM’leri devreye soktu\u011fumuzda, fark\u0131nda olmadan ba\u015fka bir manuel i\u015f y\u00fck\u00fc yarat\u0131r\u0131z. \u00d6rne\u011fin, bir test raporundan veya kullan\u0131c\u0131 geri bildiriminden d\u00fczinelerce GitHub sorunu (issue) olu\u015fturmak, bir zamanlar saatler s\u00fcren el eme\u011fi gerektiren bir s\u00fcre\u00e7ti. Peki ya bu s\u00fcreci tamamen ortadan kald\u0131rabilseydik? Bu makalede, LLM’leri disiplinli bir \u015fekilde kullanarak GitHub sorunlar\u0131n\u0131 otomatikle\u015ftirme y\u00f6ntemlerini ad\u0131m ad\u0131m ke\u015ffedece\u011fiz ve b\u00f6ylece el ile issue olu\u015fturma derdine son verece\u011fiz.<\/p>\n
Yapay zeka teknolojileri, \u00f6zellikle B\u00fcy\u00fck Dil Modelleri (LLM’ler), yaz\u0131l\u0131m geli\u015ftirme ekiplerinin \u00fcretkenli\u011fini art\u0131rma vaadiyle hayat\u0131m\u0131za girdi. Kod yazmaktan hata ay\u0131klamaya, dok\u00fcmantasyon olu\u015fturmaktan test senaryolar\u0131 tasarlamaya kadar pek \u00e7ok alanda LLM’lerin sundu\u011fu imkanlar g\u00f6z kama\u015ft\u0131r\u0131c\u0131. Ancak bu potansiyelin tamam\u0131n\u0131 ger\u00e7ekle\u015ftirmek, \u00e7o\u011fu zaman beklentilerin \u00f6tesinde zorluklarla dolu olabiliyor. LLM’ler, do\u011fru y\u00f6nlendirilmediklerinde, “hal\u00fcsinasyon” olarak adland\u0131r\u0131lan yanl\u0131\u015f veya uydurma bilgiler \u00fcretebilir, istenmeyen \u00e7\u0131kt\u0131lar verebilir ya da basit g\u00f6revleri bile karma\u015f\u0131k hale getirebilirler. Bu durum, geli\u015ftiricilerin LLM \u00e7\u0131kt\u0131s\u0131n\u0131 s\u00fcrekli kontrol etme, d\u00fczeltme ve manuel olarak i\u015flemeye devam etme ihtiyac\u0131n\u0131 do\u011furuyor. \u0130\u015fte tam da bu noktada, LLM’leri “s\u0131k\u0131 bir tasmal\u0131 tutmak” kavram\u0131 devreye giriyor.<\/p>\n
Bir \u00f6rnekle a\u00e7\u0131klayal\u0131m: Bir yaz\u0131l\u0131m ekibi, yeni bir \u00fcr\u00fcn\u00fcn beta test a\u015famas\u0131nda y\u00fczlerce kullan\u0131c\u0131 geri bildirimi ald\u0131\u011f\u0131n\u0131 varsayal\u0131m. Her bir geri bildirim, potansiyel bir hata raporu, \u00f6zellik iste\u011fi veya iyile\u015ftirme \u00f6nerisi olabilir. Geleneksel yakla\u015f\u0131mla, bu geri bildirimleri okuyan bir geli\u015ftirici veya \u00fcr\u00fcn y\u00f6neticisi, ilgili olanlar\u0131 ay\u0131klar ve her biri i\u00e7in ayr\u0131 ayr\u0131 GitHub’da bir sorun (issue) olu\u015fturur. Bu s\u00fcre\u00e7, sadece okuma ve anlama k\u0131sm\u0131nda de\u011fil, ayn\u0131 zamanda her bir issue i\u00e7in ba\u015fl\u0131k belirleme, a\u00e7\u0131klama yazma, etiketleme ve \u00f6ncelik atama gibi tekrarlayan ve zaman al\u0131c\u0131 ad\u0131mlarda da ciddi bir manuel y\u00fck getirir. G\u00fcnde 30, haftada 150 veya ayda y\u00fczlerce issue olu\u015fturdu\u011funuzu hayal edin. Bu, yarat\u0131c\u0131l\u0131\u011f\u0131n\u0131z\u0131 ve as\u0131l m\u00fchendislik g\u00f6revlerinizi baltalayan, s\u0131k\u0131c\u0131 ve hataya a\u00e7\u0131k bir i\u015f y\u00fck\u00fcd\u00fcr. Dahas\u0131, bu manuel s\u00fcre\u00e7ler s\u0131ras\u0131nda \u00f6nemli detaylar g\u00f6zden ka\u00e7abilir, yanl\u0131\u015f etiketlemeler yap\u0131labilir veya ayn\u0131 sorun birden fazla kez a\u00e7\u0131labilir. Bu da proje y\u00f6netiminde kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na ve verimsizli\u011fe yol a\u00e7ar.<\/p>\n
LLM’leri bu s\u00fcrece dahil etme fikri cazip g\u00f6r\u00fcnse de, ilk denemeler genellikle h\u00fcsranla sonu\u00e7lanabilir. Bir LLM’e “Bu kullan\u0131c\u0131 geri bildirimlerinden GitHub issue’lar\u0131 olu\u015ftur” dedi\u011finizde, bazen \u00e7ok genel ba\u015fl\u0131klar, yetersiz a\u00e7\u0131klamalar veya alakas\u0131z etiketlerle kar\u015f\u0131la\u015f\u0131rs\u0131n\u0131z. Hatta bazen LLM, bir geri bildirimi birden fazla issue’ya b\u00f6lebilir veya \u00f6nemli bir geri bildirimi tamamen g\u00f6z ard\u0131 edebilir. Bu da, LLM’in \u00fcretti\u011fi \u00e7\u0131kt\u0131lar\u0131 manuel olarak kontrol etme ve d\u00fczeltme ihtiyac\u0131n\u0131 beraberinde getirir. Yani, bir otomasyon arac\u0131 olarak d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcm\u00fcz LLM, asl\u0131nda yeni bir manuel kontrol katman\u0131 ekleyerek i\u015f y\u00fck\u00fcn\u00fc daha da art\u0131rabilir. Bu durum, “LLM’leri nas\u0131l daha \u00f6ng\u00f6r\u00fclebilir, tutarl\u0131 ve g\u00fcvenilir hale getirebiliriz?” sorusunu g\u00fcndeme getiriyor. Bu sorunun cevab\u0131, g\u00fc\u00e7l\u00fc prompt m\u00fchendisli\u011fi (komut m\u00fchendisli\u011fi), \u00e7\u0131kt\u0131 formatlama ve entegrasyon stratejilerinde yat\u0131yor.<\/p>\n
Manuel s\u00fcre\u00e7lerin getirdi\u011fi y\u00fck\u00fc ve LLM’lerin kontrols\u00fcz kullan\u0131m\u0131n\u0131n potansiyel risklerini anlad\u0131ktan sonra, \u015fimdi bu iki d\u00fcnyan\u0131n en iyi y\u00f6nlerini birle\u015ftiren bir \u00e7\u00f6z\u00fcm in\u015fa etme zaman\u0131. LLM destekli GitHub issue y\u00f6netimi, sadece bir otomasyon arac\u0131 olman\u0131n \u00f6tesinde, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinizde devrim yaratma potansiyeline sahiptir. Bu yakla\u015f\u0131m, LLM’lerin do\u011fal dil anlama ve \u00fcretme yeteneklerini, yap\u0131land\u0131r\u0131lm\u0131\u015f bir i\u015f ak\u0131\u015f\u0131yla birle\u015ftirerek, manuel olarak olu\u015fturulan issue’lar\u0131n say\u0131s\u0131n\u0131 s\u0131f\u0131ra indirmeyi hedefler.<\/p>\n
Bu ge\u00e7i\u015fin temelinde yatan fikir olduk\u00e7a basittir: \u0130nsanlar\u0131n tekrarlayan ve kural tabanl\u0131 g\u00f6revleri yapmas\u0131n\u0131 beklemek yerine, bu g\u00f6revleri ak\u0131ll\u0131 bir sisteme devretmek. Ancak bu, LLM’e sadece “i\u015fi yap” demekle olmuyor. LLM’i, bizim belirledi\u011fimiz kurallar, formatlar ve beklentiler \u00e7er\u00e7evesinde \u00e7al\u0131\u015facak \u015fekilde e\u011fitmemiz ve y\u00f6nlendirmemiz gerekiyor. Bu, bir robotu programlamak gibi d\u00fc\u015f\u00fcn\u00fclebilir; ona sadece ne yapaca\u011f\u0131n\u0131 de\u011fil, nas\u0131l<\/i> yapaca\u011f\u0131n\u0131 da s\u00f6ylemeliyiz. \u00d6rne\u011fin, bir kullan\u0131c\u0131 geri bildirimini analiz edip bir GitHub issue’u olu\u015fturmas\u0131n\u0131 istedi\u011fimizde, LLM’den sadece bir ba\u015fl\u0131k ve a\u00e7\u0131klama beklemek yetersizdir. Ayn\u0131 zamanda issue’nun hangi depoda (repository) a\u00e7\u0131laca\u011f\u0131n\u0131, hangi etiketlerin (label) atanaca\u011f\u0131n\u0131, hangi \u00f6nceli\u011fe sahip olaca\u011f\u0131n\u0131 ve hatta belki hangi geli\u015ftiriciye atanaca\u011f\u0131n\u0131 da belirtmeliyiz. Bu yap\u0131land\u0131r\u0131lm\u0131\u015f yakla\u015f\u0131m, LLM’in “serbest” do\u011fas\u0131n\u0131, bizim belirledi\u011fimiz “s\u0131k\u0131 tasmaya” ba\u011flamam\u0131z\u0131 sa\u011flar.<\/p>\n
Bu otomasyonun faydalar\u0131 \u00e7ok y\u00f6nl\u00fcd\u00fcr. \u0130lk olarak, insan hatas\u0131n\u0131 minimize eder. Manuel olarak issue olu\u015ftururken yap\u0131lan yaz\u0131m hatalar\u0131, yanl\u0131\u015f etiketlemeler veya unutulan detaylar, otomatik bir sistemde standartla\u015ft\u0131r\u0131lm\u0131\u015f \u00e7\u0131kt\u0131lar sayesinde ortadan kalkar. \u0130kincisi, verimlili\u011fi art\u0131r\u0131r. Birka\u00e7 y\u00fcz kullan\u0131c\u0131 geri bildirimini analiz edip elle issue olu\u015fturmak saatler hatta g\u00fcnler alabilirken, otomatik bir sistem bu i\u015fi dakikalar i\u00e7inde tamamlayabilir. Bu, geli\u015ftiricilerin zamanlar\u0131n\u0131 daha yarat\u0131c\u0131 ve karma\u015f\u0131k m\u00fchendislik g\u00f6revlerine ay\u0131rmalar\u0131na olanak tan\u0131r. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, tutarl\u0131l\u0131k sa\u011flar. Her issue, belirli bir formatta ve belirli kurallara g\u00f6re olu\u015fturuldu\u011fu i\u00e7in, proje y\u00f6netimi ve izleme s\u00fcre\u00e7leri daha d\u00fczenli ve \u00f6ng\u00f6r\u00fclebilir hale gelir. Son olarak, i\u015f ak\u0131\u015flar\u0131n\u0131 h\u0131zland\u0131r\u0131r. Geri bildirimden aksiyona ge\u00e7i\u015f s\u00fcresi dramatik bir \u015fekilde k\u0131sal\u0131r, bu da \u00fcr\u00fcn geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fc h\u0131zland\u0131r\u0131r ve kullan\u0131c\u0131 memnuniyetini art\u0131r\u0131r.<\/p>\n
Bu otomasyon sistemini kurmak i\u00e7in birka\u00e7 temel bile\u015fene ihtiyac\u0131m\u0131z var: Birincisi, i\u015flenecek verinin (kullan\u0131c\u0131 geri bildirimleri, test raporlar\u0131 vb.) toplanmas\u0131 ve \u00f6n i\u015flenmesi. \u0130kincisi, bu veriyi anlay\u0131p anlaml\u0131 issue’lara d\u00f6n\u00fc\u015ft\u00fcrecek bir LLM entegrasyonu ve g\u00fc\u00e7l\u00fc bir prompt m\u00fchendisli\u011fi stratejisi. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, LLM’in \u00fcretti\u011fi \u00e7\u0131kt\u0131lar\u0131 al\u0131p ger\u00e7ek GitHub issue’lar\u0131na d\u00f6n\u00fc\u015ft\u00fcrecek bir GitHub API entegrasyonu. Bu bile\u015fenleri bir araya getirerek, sadece 30 de\u011fil, 300 GitHub issue’unu bile el de\u011fmeden olu\u015fturabilen, ak\u0131ll\u0131 ve verimli bir sistem kurabiliriz. Bu sistem, yaz\u0131l\u0131m geli\u015ftirme ekibinizin \u00fczerindeki y\u00fck\u00fc hafifletirken, ayn\u0131 zamanda daha h\u0131zl\u0131, daha tutarl\u0131 ve daha kaliteli \u00fcr\u00fcnler ortaya koyman\u0131za yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
LLM destekli GitHub issue otomasyonu kurmak, sand\u0131\u011f\u0131n\u0131zdan daha kolay olabilir. Bu b\u00f6l\u00fcmde, bu s\u00fcreci ad\u0131m ad\u0131m inceleyece\u011fiz ve size kendi sisteminizi nas\u0131l kurabilece\u011finize dair pratik bilgiler ve kod \u00f6rnekleri sunaca\u011f\u0131z. Temel olarak, \u00fc\u00e7 ana a\u015famadan ge\u00e7ece\u011fiz: veri toplama ve \u00f6n i\u015fleme, LLM entegrasyonu ve prompt m\u00fchendisli\u011fi, ve son olarak GitHub API ile issue olu\u015fturma.<\/p>\n
Otomasyonun ilk ad\u0131m\u0131, i\u015flenecek veriyi do\u011fru ve temiz bir \u015fekilde toplamakt\u0131r. Bu veriler, e-posta, Slack mesajlar\u0131, m\u00fc\u015fteri destek kay\u0131tlar\u0131, test raporlar\u0131 veya do\u011frudan kullan\u0131c\u0131 geri bildirim formlar\u0131 gibi \u00e7e\u015fitli kaynaklardan gelebilir. \u00d6nemli olan, bu da\u011f\u0131n\u0131k veriyi LLM’in anlayabilece\u011fi ve i\u015fleyebilece\u011fi yap\u0131land\u0131r\u0131lm\u0131\u015f bir formata d\u00f6n\u00fc\u015ft\u00fcrmektir. \u00d6rne\u011fin, bir test raporundan gelen metinleri veya bir Slack kanal\u0131ndaki konu\u015fmalar\u0131 tek tek al\u0131p, her birini ayr\u0131 bir girdi olarak haz\u0131rlamam\u0131z gerekebilir.<\/p>\n
Python gibi bir dil kullanarak bu verileri toplamak ve \u00f6n i\u015flemek olduk\u00e7a kolayd\u0131r. \u00d6rne\u011fin, bir metin dosyas\u0131ndaki her sat\u0131r\u0131 veya bir JSON dosyas\u0131ndaki her bir \u00f6\u011feyi i\u015fleyebiliriz. Temel \u00f6n i\u015fleme ad\u0131mlar\u0131 \u015funlar\u0131 i\u00e7erebilir:<\/p>\n
Basit bir metin dosyas\u0131ndan veri okuma \u00f6rne\u011fi:<\/p>\n
\n# Python ile \u00f6rnek veri okuma\ndef read_feedback_data(filepath):\n with open(filepath, 'r', encoding='utf-8') as f:\n feedback_items = [line.strip() for line in f if line.strip()]\n return feedback_items\n\n# \u00d6rnek kullan\u0131m\n# feedback_data = read_feedback_data('user_feedback.txt')\n# print(feedback_data)\n <\/code><\/pre>\n<\/p><\/div>\n2. LLM Entegrasyonu ve Prompt M\u00fchendisli\u011fi: Ak\u0131ll\u0131 Y\u00f6nlendirme<\/h4>\n
Bu a\u015fama, otomasyonun kalbidir. LLM’e ne istedi\u011fimizi \u00e7ok a\u00e7\u0131k ve net bir \u015fekilde anlatmal\u0131y\u0131z. \u0130yi bir prompt (komut), LLM’in do\u011fru ve tutarl\u0131 \u00e7\u0131kt\u0131lar \u00fcretmesini sa\u011flar. Prompt m\u00fchendisli\u011fi, LLM’i belirli bir g\u00f6revi yerine getirmesi i\u00e7in en etkili talimatlar\u0131 ve ba\u011flam\u0131 sa\u011flamak sanat\u0131d\u0131r. GitHub issue’lar\u0131 i\u00e7in bir prompt olu\u015ftururken, a\u015fa\u011f\u0131daki unsurlar\u0131 dahil etmek \u00f6nemlidir:<\/p>\n
\n- Rol Tan\u0131m\u0131:<\/strong> LLM’in bir “yaz\u0131l\u0131m geli\u015ftirici” veya “\u00fcr\u00fcn y\u00f6neticisi” gibi bir rol \u00fcstlenmesini isteyebilirsiniz.<\/li>\n
- G\u00f6rev Tan\u0131m\u0131:<\/strong> A\u00e7\u0131k\u00e7a belirtin ki, g\u00f6revi “verilen metinden bir GitHub issue’u olu\u015fturmak”t\u0131r.<\/li>\n
- \u00c7\u0131kt\u0131 Format\u0131:<\/strong> LLM’den bekledi\u011finiz \u00e7\u0131kt\u0131n\u0131n JSON gibi yap\u0131land\u0131r\u0131lm\u0131\u015f bir formatta olmas\u0131n\u0131 isteyin. Bu, \u00e7\u0131kt\u0131y\u0131 daha sonra i\u015flemek i\u00e7in kritik \u00f6neme sahiptir. Hangi alanlar\u0131n (ba\u015fl\u0131k, a\u00e7\u0131klama, etiketler, \u00f6ncelik) dahil olaca\u011f\u0131n\u0131 belirtin.<\/li>\n
- \u00d6rnekler (Few-shot learning):<\/strong> M\u00fcmk\u00fcnse, birka\u00e7 \u00f6rnek girdi ve bu girdilere kar\u015f\u0131l\u0131k gelen \u00f6rnek \u00e7\u0131kt\u0131lar\u0131 (issue format\u0131nda) sa\u011flay\u0131n. Bu, LLM’in beklentinizi daha iyi anlamas\u0131na yard\u0131mc\u0131 olur.<\/li>\n
- K\u0131s\u0131tlamalar:<\/strong> Issue ba\u015fl\u0131\u011f\u0131n\u0131n maksimum uzunlu\u011fu, hangi etiketlerin kullan\u0131labilece\u011fi gibi k\u0131s\u0131tlamalar\u0131 belirtin.<\/li>\n<\/ul>\n
\u00d6rnek bir prompt yap\u0131s\u0131 ve LLM \u00e7a\u011fr\u0131s\u0131 (OpenAI API kullanarak):<\/p>\n
\n\nimport openai\nimport json\n\n# API anahtar\u0131n\u0131z\u0131 buraya ekleyin\n# openai.api_key = \"YOUR_OPENAI_API_KEY\"\n\ndef generate_github_issue(feedback_text):\n prompt = f\"\"\"\n Sen bir yaz\u0131l\u0131m geli\u015ftiricisinin asistans\u0131n. G\u00f6revin, verilen kullan\u0131c\u0131 geri bildirimini analiz ederek\n bir GitHub issue'u olu\u015fturmak. Issue'yu a\u015fa\u011f\u0131daki JSON format\u0131nda olu\u015fturmal\u0131s\u0131n:\n\n {{\n \"title\": \"K\u0131sa ve a\u00e7\u0131klay\u0131c\u0131 bir ba\u015fl\u0131k (max 70 karakter)\",\n \"description\": \"Geri bildirimi \u00f6zetleyen ve sorunu\/iste\u011fi detayland\u0131ran bir a\u00e7\u0131klama. Ad\u0131m ad\u0131m yeniden \u00fcretme talimatlar\u0131 (varsa) ve beklenen\/ger\u00e7ekle\u015fen davran\u0131\u015f fark\u0131n\u0131 belirt.\",\n \"labels\": [\"bug\", \"feature\", \"enhancement\", \"documentation\"],\n \"priority\": \"low\", \/\/ \"low\", \"medium\", \"high\", \"critical\"\n \"assignee\": null \/\/ Opsiyonel: atanacak ki\u015finin GitHub kullan\u0131c\u0131 ad\u0131\n }}\n\n Geri bildirim metninden \u00f6nemli detaylar\u0131 ka\u00e7\u0131rmamaya \u00f6zen g\u00f6ster.\n Sadece belirtilen JSON \u00e7\u0131kt\u0131s\u0131n\u0131 \u00fcret, ba\u015fka hi\u00e7bir a\u00e7\u0131klama veya metin ekleme.\n\n Geri bildirim:\n \"{feedback_text}\"\n \"\"\"\n\n try:\n response = openai.chat.completions.create(\n model=\"gpt-4o\", # Veya tercih etti\u011finiz ba\u015fka bir model\n messages=[\n {\"role\": \"system\", \"content\": \"Sen deneyimli bir GitHub issue olu\u015fturma botusun.\"},\n {\"role\": \"user\", \"content\": prompt}\n ],\n response_format={\"type\": \"json_object\"}\n )\n issue_data = json.loads(response.choices[0].message.content)\n return issue_data\n except Exception as e:\n print(f\"LLM \u00e7a\u011fr\u0131l\u0131rken bir hata olu\u015ftu: {e}\")\n return None\n\n# \u00d6rnek kullan\u0131m\n# sample_feedback = \"Uygulamada profilimi d\u00fczenlemeye \u00e7al\u0131\u015ft\u0131\u011f\u0131mda 'Kaydet' butonuna bast\u0131\u011f\u0131mda hi\u00e7bir \u015fey olmuyor. Sayfa yenilenmiyor ve de\u011fi\u015fiklikler kaydedilmiyor. Chrome taray\u0131c\u0131da denedim.\"\n# generated_issue = generate_github_issue(sample_feedback)\n# if generated_issue:\n# print(json.dumps(generated_issue, indent=2, ensure_ascii=False))\n <\/code><\/pre>\n<\/p><\/div>\nBu prompt, LLM’e hem rol\u00fcn\u00fc hem de beklenen \u00e7\u0131kt\u0131 format\u0131n\u0131 net bir \u015fekilde belirtir. response_format={\"type\": \"json_object\"}<\/code> parametresi, \u00f6zellikle OpenAI API’lar\u0131nda, LLM’in \u00e7\u0131kt\u0131y\u0131 kesinlikle JSON format\u0131nda vermesini garanti eder, bu da sonraki ad\u0131mlarda \u00e7\u0131kt\u0131y\u0131 ayr\u0131\u015ft\u0131rmay\u0131 \u00e7ok daha kolayla\u015ft\u0131r\u0131r.<\/p>\n3. GitHub API ile Issue Olu\u015fturma: Son Dokunu\u015f<\/h4>\n
LLM’den gelen yap\u0131land\u0131r\u0131lm\u0131\u015f JSON \u00e7\u0131kt\u0131s\u0131n\u0131 ald\u0131ktan sonra, son ad\u0131m bu veriyi kullanarak GitHub’da ger\u00e7ek bir issue olu\u015fturmakt\u0131r. GitHub API’si, bu i\u015flemi programatik olarak yapmam\u0131za olanak tan\u0131r. GitHub API’ye eri\u015fim i\u00e7in bir Personal Access Token (PAT) olu\u015fturman\u0131z gerekecektir. Bu token’\u0131n ‘repo’ veya ‘public_repo’ izinlerine sahip oldu\u011fundan emin olun.<\/p>\n
Python’daki requests<\/code> k\u00fct\u00fcphanesini kullanarak GitHub API ile etkile\u015fime ge\u00e7ebiliriz:<\/p>\n\n\nimport requests\n\n# GitHub ki\u015fisel eri\u015fim token'\u0131n\u0131z\u0131 buraya ekleyin\n# GITHUB_TOKEN = \"YOUR_GITHUB_PERSONAL_ACCESS_TOKEN\"\n# GITHUB_REPO_OWNER = \"your-github-username\"\n# GITHUB_REPO_NAME = \"your-repository-name\"\n\ndef create_github_issue(issue_data):\n if not GITHUB_TOKEN or not GITHUB_REPO_OWNER or not GITHUB_REPO_NAME:\n print(\"GitHub token veya repo bilgileri eksik.\")\n return False\n\n url = f\"https:\/\/api.github.com\/repos\/{GITHUB_REPO_OWNER}\/{GITHUB_REPO_NAME}\/issues\"\n headers = {\n \"Authorization\": f\"token {GITHUB_TOKEN}\",\n \"Accept\": \"application\/vnd.github.v3+json\"\n }\n\n payload = {\n \"title\": issue_data.get(\"title\"),\n \"body\": issue_data.get(\"description\"),\n \"labels\": issue_data.get(\"labels\", []),\n \"assignees\": [issue_data[\"assignee\"]] if issue_data.get(\"assignee\") else []\n }\n\n # GitHub API'si priority do\u011frudan desteklemedi\u011fi i\u00e7in, bunu bir etiket olarak ekleyebiliriz.\n if issue_data.get(\"priority\"):\n payload[\"labels\"].append(f\"priority:{issue_data['priority']}\")\n\n response = requests.post(url, headers=headers, json=payload)\n\n if response.status_code == 201:\n print(f\"GitHub issue ba\u015far\u0131yla olu\u015fturuldu: {response.json()['html_url']}\")\n return True\n else:\n print(f\"GitHub issue olu\u015fturulurken hata olu\u015ftu: {response.status_code} - {response.json()}\")\n return False\n\n# T\u00fcm s\u00fcreci birle\u015ftiren ana fonksiyon\ndef automate_issue_creation(feedback_file_path):\n feedback_items = read_feedback_data(feedback_file_path)\n if not feedback_items:\n print(\"\u0130\u015flenecek geri bildirim bulunamad\u0131.\")\n return\n\n for feedback in feedback_items:\n print(f\"\\n\u0130\u015fleniyor: '{feedback[:50]}...'\")\n generated_issue = generate_github_issue(feedback)\n if generated_issue:\n create_github_issue(generated_issue)\n else:\n print(\"Issue olu\u015fturulamad\u0131, atlan\u0131yor.\")\n\n# \u00d6rnek \u00e7al\u0131\u015ft\u0131rma\n# automate_issue_creation('user_feedback.txt')\n <\/code><\/pre>\n<\/p><\/div>\nBu \u00fc\u00e7 ad\u0131m\u0131 birle\u015ftirerek, manuel olarak 30 de\u011fil, y\u00fczlerce GitHub issue’unu otomatik olarak olu\u015fturabilen g\u00fc\u00e7l\u00fc bir sistem kurmu\u015f olursunuz. Bu sistem, geli\u015ftirme ekibinizin zaman\u0131n\u0131 ve enerjisini ger\u00e7ekten \u00f6nemli i\u015flere odaklamas\u0131na olanak tan\u0131r.<\/p>\n
Vaka Analizi: Ger\u00e7ek Bir Senaryoda Otomasyonun Faydalar\u0131<\/h3>\n
\u015eimdiye kadar teorik bilgileri ve teknik ad\u0131mlar\u0131 ele ald\u0131k. Peki, bu otomasyon ger\u00e7ek bir senaryoda nas\u0131l bir fark yarat\u0131r? Hayali bir yaz\u0131l\u0131m \u015firketi olan “Y\u0131ld\u0131z Yaz\u0131l\u0131m”\u0131n hikayesiyle bu soruyu yan\u0131tlayal\u0131m. Y\u0131ld\u0131z Yaz\u0131l\u0131m, pop\u00fcler bir e-ticaret platformu geli\u015ftiriyor ve her ay binlerce kullan\u0131c\u0131dan geri bildirim al\u0131yor. Geleneksel olarak, bu geri bildirimleri analiz etmek ve ilgili GitHub issue’lar\u0131n\u0131 olu\u015fturmak, iki ki\u015filik bir “Issue Y\u00f6netim Ekibi”nin tam zamanl\u0131 i\u015fiydi. Bu ekip, g\u00fcnde ortalama 30-40 issue olu\u015fturabiliyor, ancak yine de birikmi\u015f i\u015f y\u00fck\u00fc (backlog) her zaman mevcuttu.<\/p>\n
Ekip, \u00f6zellikle yo\u011fun d\u00f6nemlerde (yeni \u00f6zellik lansmanlar\u0131 veya kampanya d\u00f6nemleri) geri bildirim selinin alt\u0131nda kal\u0131yor, \u00f6nemli hatalar ge\u00e7 fark ediliyor ve kullan\u0131c\u0131 memnuniyeti d\u00fc\u015f\u00fcyordu. \u00dcr\u00fcn y\u00f6neticileri, geli\u015ftiriciler ve test uzmanlar\u0131 aras\u0131nda koordinasyon eksikli\u011fi ya\u015fan\u0131yor, \u00e7\u00fcnk\u00fc issue’lar zaman\u0131nda ve do\u011fru etiketlerle a\u00e7\u0131lmad\u0131\u011f\u0131 i\u00e7in ilgili ki\u015filere ula\u015fm\u0131yordu. Hatta bazen, ayn\u0131 hata i\u00e7in birden fazla issue a\u00e7\u0131ld\u0131\u011f\u0131 veya \u00f6nemli bir \u00f6zellik iste\u011finin g\u00f6zden ka\u00e7t\u0131\u011f\u0131 durumlar oluyordu. Bu durum, Y\u0131ld\u0131z Yaz\u0131l\u0131m’\u0131n \u00e7evik (agile) geli\u015ftirme prensiplerine ayk\u0131r\u0131yd\u0131 ve s\u00fcrekli bir darbo\u011faz yarat\u0131yordu.<\/p>\n
Y\u0131ld\u0131z Yaz\u0131l\u0131m’\u0131n lider geli\u015ftiricisi Ay\u015fe, bu soruna bir \u00e7\u00f6z\u00fcm bulmak i\u00e7in LLM destekli otomasyon fikrini ortaya att\u0131. \u0130lk ba\u015fta, ekip \u00fcyeleri LLM’lerin g\u00fcvenilirli\u011fi konusunda \u015f\u00fcpheciydi. “Ya yanl\u0131\u015f issue’lar a\u00e7arsa? Ya \u00f6nemli bilgileri ka\u00e7\u0131r\u0131rsa?” gibi sorular ak\u0131llar\u0131 kurcal\u0131yordu. Ancak Ay\u015fe, yukar\u0131da bahsetti\u011fimiz prompt m\u00fchendisli\u011fi ve yap\u0131land\u0131r\u0131lm\u0131\u015f \u00e7\u0131kt\u0131 format\u0131 stratejilerini kullanarak bir prototip geli\u015ftirdi. Bu prototip, kullan\u0131c\u0131 geri bildirimlerini analiz edip, belirli etiketler (bug<\/code>, feature<\/code>, ux-improvement<\/code>, priority:medium<\/code> vb.) ve atanm\u0131\u015f ki\u015filerle (@ayse<\/code>, @mehmet<\/code>) birlikte JSON format\u0131nda issue’lar \u00fcretiyordu. Ard\u0131ndan, bu JSON \u00e7\u0131kt\u0131lar\u0131 do\u011frudan GitHub API’si arac\u0131l\u0131\u011f\u0131yla issue’lara d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcyordu.<\/p>\nUygulama S\u00fcreci ve Sonu\u00e7lar:<\/strong><\/p>\n\n- Pilot Uygulama:<\/strong> \u0130lk olarak, ge\u00e7mi\u015f 1000 kullan\u0131c\u0131 geri bildirimi \u00fczerinde prototip test edildi. LLM, bu geri bildirimlerin %90’\u0131ndan fazlas\u0131 i\u00e7in kabul edilebilir issue’lar olu\u015fturdu. Kalan %10’luk k\u0131s\u0131m i\u00e7in ise manuel d\u00fczeltmeler yap\u0131ld\u0131 ve prompt daha da iyile\u015ftirildi.<\/li>\n
- Entegrasyon:<\/strong> Otomasyon sistemi, kullan\u0131c\u0131 geri bildirimlerinin geldi\u011fi ana kanallara (destek e-postalar\u0131, anket formlar\u0131) entegre edildi. Her yeni geri bildirim otomatik olarak LLM’e g\u00f6nderiliyor ve issue olu\u015fturma s\u00fcreci tetikleniyordu.<\/li>\n
- \u0130nsan Kontrol\u00fc ve Geri Bildirim D\u00f6ng\u00fcs\u00fc:<\/strong> Ba\u015flang\u0131\u00e7ta, olu\u015fturulan issue’lar “bekleyen onay” (pending review) etiketiyle a\u00e7\u0131l\u0131yor ve Issue Y\u00f6netim Ekibi taraf\u0131ndan h\u0131zl\u0131ca g\u00f6zden ge\u00e7iriliyordu. Ekip, LLM’in yanl\u0131\u015f yapt\u0131\u011f\u0131 durumlar\u0131 not al\u0131yor ve bu geri bildirimler prompt’u daha da optimize etmek i\u00e7in kullan\u0131l\u0131yordu. Bu s\u00fcrekli geri bildirim d\u00f6ng\u00fcs\u00fc, sistemin \u00f6\u011frenmesini ve do\u011frulu\u011funu art\u0131rmas\u0131n\u0131 sa\u011flad\u0131.<\/li>\n
- E\u011fitim ve Adaptasyon:<\/strong> Ekip \u00fcyeleri, LLM’in nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131 ve prompt m\u00fchendisli\u011finin \u00f6nemi konusunda e\u011fitim ald\u0131. Art\u0131k, spesifik bir senaryo i\u00e7in daha iyi issue’lar \u00fcretmek istediklerinde, prompt’u kendileri iyile\u015ftirebiliyorlard\u0131.<\/li>\n<\/ol>\n
Elde Edilen Faydalar:<\/strong><\/p>\n\n- %80 \u0130\u015f Y\u00fck\u00fc Azalmas\u0131:<\/strong> Issue Y\u00f6netim Ekibi’nin manuel i\u015f y\u00fck\u00fc %80 azald\u0131. Art\u0131k g\u00fcnde 30-40 issue olu\u015fturmak yerine, LLM taraf\u0131ndan olu\u015fturulan issue’lar\u0131 kontrol edip %10’luk bir d\u00fczeltme yap\u0131yorlard\u0131. Bu, ekibin haftada harcad\u0131\u011f\u0131 s\u00fcreyi 80 saatten yakla\u015f\u0131k 16 saate d\u00fc\u015f\u00fcrd\u00fc.<\/li>\n
- H\u0131z ve \u00c7eviklik:<\/strong> Geri bildirimden issue olu\u015fturma s\u00fcresi, saatlerden dakikalara indi. Bu, kritik hatalar\u0131n \u00e7ok daha h\u0131zl\u0131 tespit edilip \u00e7\u00f6z\u00fclmesini sa\u011flad\u0131.<\/li>\n
- Tutarl\u0131l\u0131k ve Kalite:<\/strong> T\u00fcm issue’lar standart bir formatta ve do\u011fru etiketlerle a\u00e7\u0131ld\u0131\u011f\u0131 i\u00e7in proje y\u00f6netimi daha d\u00fczenli hale geldi. G\u00f6zden ka\u00e7an veya yinelenen issue say\u0131s\u0131 dramatik bir \u015fekilde azald\u0131.<\/li>\n
- De\u011fer Odakl\u0131 \u00c7al\u0131\u015fma:<\/strong> Issue Y\u00f6netim Ekibi, art\u0131k s\u0131k\u0131c\u0131 manuel g\u00f6revler yerine, daha karma\u015f\u0131k kullan\u0131c\u0131 geri bildirimlerini analiz etme, trendleri belirleme ve \u00fcr\u00fcn iyile\u015ftirme stratejilerine katk\u0131da bulunma gibi daha stratejik g\u00f6revlere odaklanabildi.<\/li>\n
- Geli\u015ftirici Mutlulu\u011fu:<\/strong> Geli\u015ftiriciler, daha iyi organize edilmi\u015f ve daha net tan\u0131mlanm\u0131\u015f issue’larla \u00e7al\u0131\u015ft\u0131klar\u0131 i\u00e7in daha verimli oldular ve i\u015flerinden daha fazla keyif ald\u0131lar.<\/li>\n<\/ul>\n
Y\u0131ld\u0131z Yaz\u0131l\u0131m’\u0131n deneyimi, LLM destekli otomasyonun sadece bir maliyet azaltma arac\u0131 olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda bir organizasyonun \u00e7evikli\u011fini, verimlili\u011fini ve genel \u00fcr\u00fcn kalitesini nas\u0131l art\u0131rabilece\u011fini g\u00f6steren somut bir \u00f6rnektir. Do\u011fru prompt m\u00fchendisli\u011fi ve entegrasyon ile LLM’ler, manuel i\u015f y\u00fck\u00fcn\u00fc ortadan kald\u0131rarak ekiplerin ger\u00e7ek de\u011fer yaratmaya odaklanmas\u0131n\u0131 sa\u011flayabilir.<\/p>\n
\u0130leri Seviye Optimizasyonlar ve Entegrasyonlar: LLM’leri Daha Ak\u0131ll\u0131 Hale Getirmek<\/h3>\n
Temel otomasyon sistemini kurduktan sonra, LLM’lerinizi daha da ak\u0131ll\u0131, g\u00fcvenilir ve verimli hale getirmek i\u00e7in ileri seviye optimizasyonlar ve entegrasyonlar d\u00fc\u015f\u00fcnebilirsiniz. Bu b\u00f6l\u00fcmde, sisteminizi bir sonraki seviyeye ta\u015f\u0131yacak baz\u0131 ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131 ele alaca\u011f\u0131z.<\/p>\n
1. S\u00fcrekli Geri Bildirim D\u00f6ng\u00fcs\u00fc ve Prompt \u0130yile\u015ftirmesi<\/h4>\n
LLM’lerin performans\u0131n\u0131 art\u0131rman\u0131n en etkili yollar\u0131ndan biri, s\u00fcrekli bir geri bildirim d\u00f6ng\u00fcs\u00fc olu\u015fturmakt\u0131r. LLM taraf\u0131ndan olu\u015fturulan her issue, bir insan taraf\u0131ndan g\u00f6zden ge\u00e7irilmeli ve gerekirse d\u00fczeltilmelidir. Bu d\u00fczeltmeler, LLM’in gelecekteki \u00e7\u0131kt\u0131lar\u0131nda daha iyi performans g\u00f6stermesi i\u00e7in bir \u00f6\u011frenme f\u0131rsat\u0131 sunar. \u00d6rne\u011fin, bir issue yanl\u0131\u015f etiketlendiyse, bu bilgi prompt’u g\u00fcncelleyerek LLM’e benzer durumlarda do\u011fru etiketi nas\u0131l se\u00e7ece\u011fini \u00f6\u011fretmek i\u00e7in kullan\u0131labilir. Bu, “insan d\u00f6ng\u00fcde” (human-in-the-loop) yakla\u015f\u0131m\u0131 olarak bilinir.<\/p>\n
\n- Manuel D\u00fczeltmeleri Kaydetme:<\/strong> Hangi prompt’un hangi girdiye ne t\u00fcr bir yanl\u0131\u015f \u00e7\u0131kt\u0131 verdi\u011fini ve nas\u0131l d\u00fczeltildi\u011fini kaydeden bir veritaban\u0131 olu\u015fturun.<\/li>\n
- Prompt Versiyonlama:<\/strong> Prompt’unuzu s\u00fcrekli olarak iyile\u015ftirdi\u011finiz i\u00e7in, farkl\u0131 versiyonlar\u0131n\u0131 y\u00f6netmek ve hangi versiyonun en iyi performans\u0131 verdi\u011fini izlemek \u00f6nemlidir.<\/li>\n
- A\/B Testi:<\/strong> Farkl\u0131 prompt versiyonlar\u0131n\u0131 ayn\u0131 girdi setleri \u00fczerinde test ederek, hangisinin daha do\u011fru ve istenen \u00e7\u0131kt\u0131y\u0131 \u00fcretti\u011fini belirleyin.<\/li>\n<\/ul>\n
2. Dinamik Etiketleme ve Atama Kurallar\u0131<\/h4>\n
GitHub issue’lar\u0131nda etiketler ve atamalar, proje y\u00f6netiminin kilit unsurlar\u0131d\u0131r. LLM’in bunlar\u0131 dinamik olarak belirlemesini sa\u011flamak, otomasyonun de\u011ferini art\u0131r\u0131r. Bu, prompt’a daha fazla ba\u011flam ve kural ekleyerek yap\u0131labilir:<\/p>\n
\n- Anahtar Kelime Bazl\u0131 Etiketleme:<\/strong> Prompt’a, belirli anahtar kelimeler ge\u00e7ti\u011finde belirli etiketleri eklemesini s\u00f6yleyebilirsiniz (\u00f6rne\u011fin, “\u00f6deme” kelimesi ge\u00e7iyorsa
billing<\/code> etiketini ekle).<\/li>\n- Mod\u00fcl Bazl\u0131 Atama:<\/strong> Geri bildirimin hangi \u00fcr\u00fcn mod\u00fcl\u00fcyle ilgili oldu\u011funu (\u00f6rne\u011fin, “profil”, “sepet”, “\u00f6deme”) LLM’in anlamas\u0131n\u0131 sa\u011flay\u0131n ve ilgili mod\u00fcl\u00fcn sorumlusuna issue’yu atamas\u0131n\u0131 isteyin. Bu, LLM’in \u00e7\u0131kt\u0131s\u0131nda
assignee<\/code> alan\u0131n\u0131 do\u011fru bir \u015fekilde doldurmas\u0131n\u0131 sa\u011flar.<\/li>\n- \u00d6ncelik Belirleme:<\/strong> Geri bildirimin aciliyetini veya etkisini (\u00f6rne\u011fin, “uygulama \u00e7\u00f6k\u00fcyor” gibi ifadeler) LLM’in analiz etmesini ve buna g\u00f6re
priority:critical<\/code> gibi etiketler atamas\u0131n\u0131 isteyin.<\/li>\n<\/ul>\n3. \u00c7oklu Kaynak Entegrasyonu ve Veri Zenginle\u015ftirme<\/h4>\n
Geri bildirimler genellikle tek bir kaynaktan gelmez. E-posta, Slack, m\u00fc\u015fteri destek yaz\u0131l\u0131m\u0131 (\u00f6rne\u011fin Zendesk), test raporlama ara\u00e7lar\u0131 (\u00f6rne\u011fin Jira, TestRail) gibi farkl\u0131 platformlardan gelen verileri entegre edebilirsiniz. Bu, LLM’e daha zengin bir ba\u011flam sunar.<\/p>\n
\n- Webhook’lar ve API’lar:<\/strong> Farkl\u0131 platformlardan gelen olaylar\u0131 (yeni bir e-posta, yeni bir Slack mesaj\u0131) tetikleyici olarak kullanarak LLM i\u015f ak\u0131\u015f\u0131n\u0131z\u0131 ba\u015flat\u0131n.<\/li>\n
- Kullan\u0131c\u0131 Verileriyle Zenginle\u015ftirme:<\/strong> E\u011fer geri bildirim bir kullan\u0131c\u0131dan geliyorsa, o kullan\u0131c\u0131n\u0131n abonelik seviyesi, kulland\u0131\u011f\u0131 cihaz veya ge\u00e7mi\u015fteki etkile\u015fimleri gibi ek bilgileri LLM’e sa\u011flayarak daha bilin\u00e7li issue’lar olu\u015fturmas\u0131n\u0131 sa\u011flayabilirsiniz. \u00d6rne\u011fin, “premium” bir kullan\u0131c\u0131n\u0131n geri bildirimi daha y\u00fcksek \u00f6ncelikli olabilir.<\/li>\n<\/ul>\n
4. CI\/CD Entegrasyonu ve Test Otomasyonu<\/h4>\n
Bu otomasyon sistemini Continuous Integration\/Continuous Delivery (CI\/CD) s\u00fcre\u00e7lerinizin bir par\u00e7as\u0131 haline getirebilirsiniz. \u00d6rne\u011fin:<\/p>\n
\n- Otomatik Test Hata Raporlama:<\/strong> CI\/CD pipeline’\u0131n\u0131zda ba\u015far\u0131s\u0131z olan testler otomatik olarak LLM’e g\u00f6nderilerek detayl\u0131 hata issue’lar\u0131 olu\u015fturulabilir. Bu, test ekibinin \u00fczerindeki y\u00fck\u00fc azalt\u0131r ve hatalar\u0131n an\u0131nda raporlanmas\u0131n\u0131 sa\u011flar.<\/li>\n
- Performans \u0130zleme Entegrasyonu:<\/strong> Uygulaman\u0131z\u0131n performans izleme ara\u00e7lar\u0131ndan (\u00f6rne\u011fin Prometheus, Grafana) gelen anormal metrikler, LLM taraf\u0131ndan analiz edilerek potansiyel performans issue’lar\u0131 olarak GitHub’a aktar\u0131labilir.<\/li>\n<\/ul>\n
Bu ileri d\u00fczey optimizasyonlar ve entegrasyonlar, LLM destekli issue otomasyon sisteminizi sadece bir g\u00f6rev otomasyonu olmaktan \u00e7\u0131kar\u0131p, yaz\u0131l\u0131m geli\u015ftirme ekosisteminizin ayr\u0131lmaz ve ak\u0131ll\u0131 bir par\u00e7as\u0131 haline getirecektir. Bu sayede, LLM’leri ger\u00e7ekten “s\u0131k\u0131 bir tasmal\u0131 tutabilir” ve onlar\u0131n potansiyelini maksimum d\u00fczeyde kullanabilirsiniz.<\/p>\n
Sonu\u00e7: Gelece\u011fin Yaz\u0131l\u0131m Geli\u015ftirme S\u00fcre\u00e7leri ve Otomasyon<\/h3>\n
G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen teknoloji d\u00fcnyas\u0131nda, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinin \u00e7evik, verimli ve hatas\u0131z olmas\u0131 hayati \u00f6nem ta\u015f\u0131yor. B\u00fcy\u00fck Dil Modelleri (LLM’ler), bu hedeflere ula\u015fmam\u0131z i\u00e7in bize e\u015fsiz f\u0131rsatlar sunsa da, onlar\u0131n “vah\u015fi” do\u011fas\u0131n\u0131 kontrol alt\u0131na almak, yani onlar\u0131 s\u0131k\u0131 bir tasmal\u0131 tutmak, ba\u015far\u0131l\u0131 bir entegrasyonun anahtar\u0131d\u0131r. Bu makale boyunca, manuel olarak 30 GitHub sorunu olu\u015fturma derdinden kurtulmak i\u00e7in LLM’leri nas\u0131l kullanabilece\u011fimizi, ad\u0131m ad\u0131m bir otomasyon sistemi kurarak g\u00f6sterdik.<\/p>\n
Ba\u015flang\u0131\u00e7ta, LLM y\u00f6netimindeki zorluklar\u0131 ve manuel s\u00fcre\u00e7lerin geli\u015ftirme ekipleri \u00fczerindeki a\u011f\u0131r y\u00fck\u00fcn\u00fc inceledik. Ard\u0131ndan, LLM destekli GitHub issue y\u00f6netiminin nas\u0131l bir \u00e7\u00f6z\u00fcm sundu\u011funu ve bu ge\u00e7i\u015fin getirece\u011fi faydalar\u0131 detayland\u0131rd\u0131k. Uygulamal\u0131 k\u0131s\u0131mda, veri toplama ve \u00f6n i\u015fleme, etkili prompt m\u00fchendisli\u011fi ve GitHub API entegrasyonu ile kendi otomasyon sisteminizi nas\u0131l kuraca\u011f\u0131n\u0131z\u0131 g\u00f6steren kod \u00f6rnekleri sunduk. Y\u0131ld\u0131z Yaz\u0131l\u0131m’\u0131n vaka analizi, bu otomasyonun ger\u00e7ek d\u00fcnyada nas\u0131l somut faydalar sa\u011flad\u0131\u011f\u0131n\u0131 g\u00f6zler \u00f6n\u00fcne serdi: i\u015f y\u00fck\u00fc azalmas\u0131, h\u0131z art\u0131\u015f\u0131, tutarl\u0131l\u0131k ve geli\u015ftirici mutlulu\u011fu. Son olarak, s\u00fcrekli geri bildirim d\u00f6ng\u00fcleri, dinamik etiketleme kurallar\u0131 ve CI\/CD entegrasyonu gibi ileri d\u00fczey optimizasyonlarla sisteminizi nas\u0131l daha da ak\u0131ll\u0131 hale getirebilece\u011finizi ele ald\u0131k.<\/p>\n
Bu otomasyon stratejisi, sadece GitHub issue’lar\u0131 ile s\u0131n\u0131rl\u0131 de\u011fildir. LLM’leri benzer bir yakla\u015f\u0131mla test senaryosu olu\u015fturma, dok\u00fcmantasyon g\u00fcncelleme, kod inceleme \u00f6nerileri sunma veya hatta m\u00fc\u015fteri destek taleplerini otomatik yan\u0131tlama gibi bir\u00e7ok alanda kullanabilirsiniz. \u00d6nemli olan, LLM’e ne istedi\u011finizi net bir \u015fekilde ifade etmek, \u00e7\u0131kt\u0131y\u0131 yap\u0131land\u0131r\u0131lm\u0131\u015f bir formatta istemek ve bir geri bildirim d\u00f6ng\u00fcs\u00fc ile sistemi s\u00fcrekli iyile\u015ftirmektir. Bu sayede, LLM’lerin muazzam potansiyelini dizginleyebilir, manuel i\u015f y\u00fcklerini ortadan kald\u0131rabilir ve geli\u015ftirme ekibinizin daha stratejik, yarat\u0131c\u0131 ve de\u011ferli i\u015flere odaklanmas\u0131n\u0131 sa\u011flayabilirsiniz. Gelece\u011fin yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7leri, \u015f\u00fcphesiz ki insan zekas\u0131 ile yapay zeka otomasyonunun uyumlu birle\u015fimiyle \u015fekillenecektir.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n\n- LLM’ler her zaman do\u011fru issue’lar olu\u015fturur mu?<\/dt>\n
- Hay\u0131r, LLM’ler “hal\u00fcsinasyon” ad\u0131 verilen yanl\u0131\u015f veya uydurma bilgiler \u00fcretebilir. Ancak, iyi prompt m\u00fchendisli\u011fi, \u00e7\u0131kt\u0131 format\u0131 k\u0131s\u0131tlamalar\u0131 ve s\u00fcrekli bir geri bildirim d\u00f6ng\u00fcs\u00fc ile do\u011fruluk oran\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir ve insan kontrol\u00fcyle hatalar\u0131 minimize edebilirsiniz.<\/dd>\n
- Hangi LLM modelini kullanmal\u0131y\u0131m?<\/dt>\n
- Bu, b\u00fct\u00e7enize, performans gereksinimlerinize ve hassasiyetinize ba\u011fl\u0131d\u0131r. OpenAI’nin GPT-4o, Anthropic’in Claude veya a\u00e7\u0131k kaynakl\u0131 modellerden (\u00f6rne\u011fin Llama 3) fine-tune edilmi\u015f versiyonlar\u0131 gibi se\u00e7enekler mevcuttur. Daha karma\u015f\u0131k g\u00f6revler i\u00e7in daha b\u00fcy\u00fck ve yetenekli modeller, daha basit g\u00f6revler i\u00e7in daha k\u00fc\u00e7\u00fck ve uygun maliyetli modeller tercih edilebilir.<\/dd>\n
- Bu otomasyonu kurmak ne kadar s\u00fcrer?<\/dt>\n
- Temel bir prototipin kurulmas\u0131 birka\u00e7 saat veya birka\u00e7 g\u00fcn s\u00fcrebilir. Ancak, sistemi farkl\u0131 veri kaynaklar\u0131yla entegre etmek, prompt’u optimize etmek ve s\u00fcrekli geri bildirim d\u00f6ng\u00fcs\u00fcn\u00fc oturtmak haftalar s\u00fcrebilir. Ba\u015flang\u0131\u00e7ta k\u00fc\u00e7\u00fck ad\u0131mlarla ba\u015flay\u0131p zamanla geni\u015fletmek en iyi yakla\u015f\u0131md\u0131r.<\/dd>\n
- G\u00fcvenlik endi\u015feleri nelerdir?<\/dt>\n
- LLM’lere g\u00f6nderilen hassas verilerin gizlili\u011fi ve g\u00fcvenli\u011fi \u00f6nemlidir. API anahtarlar\u0131n\u0131z\u0131 g\u00fcvenli bir \u015fekilde saklad\u0131\u011f\u0131n\u0131zdan ve kulland\u0131\u011f\u0131n\u0131z LLM sa\u011flay\u0131c\u0131s\u0131n\u0131n veri gizlili\u011fi politikalar\u0131n\u0131 anlad\u0131\u011f\u0131n\u0131zdan emin olun. M\u00fcmk\u00fcnse, hassas bilgileri LLM’e g\u00f6ndermeden \u00f6nce maskeleme veya anonimle\u015ftirme i\u015flemlerini uygulay\u0131n.<\/dd>\n
- Sadece GitHub i\u00e7in mi ge\u00e7erli, yoksa ba\u015fka platformlarda da kullan\u0131labilir mi?<\/dt>\n
- Bu makalede GitHub \u00f6rne\u011fi verilse de, ayn\u0131 prensipler Jira, Trello, Azure DevOps gibi di\u011fer proje y\u00f6netim ve issue takip platformlar\u0131 i\u00e7in de ge\u00e7erlidir. Her platformun kendi API’si (Uygulama Programlama Aray\u00fcz\u00fc) bulunur ve LLM’den gelen \u00e7\u0131kt\u0131y\u0131 bu API’lere uygun \u015fekilde d\u00f6n\u00fc\u015ft\u00fcrerek entegrasyon sa\u011flayabilirsiniz.<\/dd>\n<\/dl>\n
#LLM #YapayZeka #Otomasyon #GitHub #Yaz\u0131l\u0131mGeli\u015ftirme #PromptM\u00fchendisli\u011fi #DevOps #Verimlilik<\/p>\n