Loop engineering tam otomasyon üzerine kurgulu degilse, yapay zeka ile yapacagi isler konusunda interaksiyon gerekiyor. Bir önceki yazimda tam otomasyon icin kuyruk yapilarinin nasil kullanildigindan bahsettim. Bu yazimla birlikte uygulama gelistirmeye yaklasim tarzimin nasil degistigini aktarayim.

Eger hale bir yapay zeka araci ile interaksiyon halindeyseniz, loop engineering bile olsa tam otonom yazilim yaptirmiyorsunuz.

Dünkü paylastigim videoda yazilim nereye evriliyor soruna cevap vermeye calismistim. Kullandigim araclarin nasil degistigine dair bugün gözlemledigim bir degisiklikten daha bahsetmek istiyorum.

Yazilim yaparken tek darbogaz her zaman insanin kendisiydi.

Eskiden yazilimcilar kod yazmaya yetisemezken, simdilerde kod review yapmaya ve yapilan degisiklikleri takip etmeye yetisemiyorlar.

Biraz yazilimdaki kültür degisiminden bahsedlim mi?

Ben eski programci günlerimden iyi hatirliyorum. “Ben kod yazarim. Gereksinimleri baskalari yapsin. Testleri QA ekibi halleder, ben testci degilim. Dokümentasyonu baskalari yapar” diyen bircok insanla birlikte calistim.

Simdi loop engineering icin gerekli, full otonom calisan bir setup nasil kurulur, ona deginmek istiyorum.

Cikis noktam yeni bir modül. Cok genis kapsamli oldugu icin gpt 15 loop plani olusturdu. Normalde ben her plani alip, elden opus’a verip, gelen sorulari gpt’ye aktarip, is bittikten sonrada gpt’nin analiz etmesini istiyordum. Bu 15 plan icin 2 gün sürecek bir islem gibi görünüyor, o yüzden benim aradan cekilerek, gidisati otomatize etmem gerekiyor diye düsündüm. Bu setup icinde gpt ve opus’un yapilacak isi koordine etmeleri gerekiyor. Ama gpt’nin dogrudan opus’a is verebilme kabiliyeti yok.

Loop engineering insan ve LLM arasindaki yazilim konusundaki is birliginin ilk neslidir. Daha önce gelen hersey teknik hazirlikti.

Gelelim refactoring konusuna. Programci iken en sevdigim konulardan birisi idi.

Refactoring ile kodun yeniden yapilandirilmasini kastediyorum. Refactoring her daim yapilabilecek bir aktivite degildir. Yapilabilmesi icin yerine getirilmesi gereken cok önemli bir sart bulunmaktadir. Test mevcudiyeti.

Eskiden kod ve test kodu dokümentasyondu. Örnegin Java’da bunun icin @Javadoc isminde özel bir yapi bile var.

Ben kodun icinde dokümentasyon yapmayi hic bir zaman tasvip etmedim, cünkü kod cok hizli degisebilen bir mevhum ve metotlar ve siniflar icinde birakilan yorumlar zaman icinde gecerlilklerini yitiriyorlar.

Loop engineering yapmaya kadar evrilen kendi yapay zeka serüvenimi prompt yazma üzerinden size adim adim aktarayim.

• Satir bazinda autocomplete: Github copilot ilk ciktiginda bu özelligi kullanarak, kodu satir bazinda tamamlatiyordum. Cok eglenceli oldugunu görünce, gidisati daha da derinlestirmek istedim.
Okumaya devam et →

Bir derleyici ile interaksiyona girmek ne kadar mantikli? Kimse yapmiyor degil mi?

Peki bir LLM le interaksiyona girmek ne kadar mantikli? Herkes yapiyor degil mi?

Loop engineering demistik en son, oradan devam edelim.

Loop enginneering’in ne oldugu konusuna diger yazilarimda deginmistim. Ben bunu günlük hayatimda nasil uyguluyorum, bunlara örnekler vererek devam etmek istiyorum.

Eskiden programci olarak nasil soruna cevap arardim. Bu durum tamamen degismis durumda. Artik ne sorusunun pesindeyim. Programlama tarihi de LLM’ler ile birlikte nasil sorusundan ne sorusuna dogru evrilen bir soyutlama tarihine dönüsüyor.

Yapay zeka araclari kullaniminin zaman icinde bende nasil degistigini kisaca paylasayim.

– 2022 baslarinda IIntelliJ IDEA bünyesinde Github Copilot plugini kullanmaya basladim. O zamanlar hatirladigim kadariyla chat modu yoktu. Sadece autocomplete yapma özelligi ile ben kod yazarken bana destek oluyordu. Bunu ilk gördügümde, yolculugun nereye gidecegini anlamistim.