- Agentic coding hakkında gerçek kullanım örnekleri paylaşılıyor
- Başlıca Claude Code Sonnet modeli kullanılıyor ve IDE entegrasyonundan çok tüm işi yapay zekaya devretme yaklaşımı tercih ediliyor
- Go dili, ajan dostu yapısı ve ekosistem istikrarı sayesinde özellikle yeni backend projeleri için öneriliyor
- Hız ve sadelik, agentic coding’in çekirdeğini oluşturuyor; test cache’i ve basit araç yapısı önemli
- Kod basit ve paralelleştirilebilir şekilde kurgulanmalı; ajan performansını en üst düzeye çıkarmak için refactor zamanlaması çok kritik
Preface
- Son dönemde agentic coding deneyimlerini paylaşan geliştiricilerin sayısı hızla arttı
- Şu anda Claude Code Sonnet modelini Max planında ($100/ay) kullanıyorum
- IDE’nin ağırlığı azaldı; onun yerine yeniden Vim kullanmaya başladım ve iş akışımda görevi Claude’a verip yalnızca sonucu kontrol ediyorum
- Yenilik hızı çok yüksek olduğu için bu yazının içeriği hızla eskiyebilir; bu nedenle daha kalıcı kavramlara odaklanıyorum
The Basics
claude --dangerously-skip-permissions komutunu claude-yolo olarak alias’layıp tüm izin kısıtlamalarını kaldırıyorum
- Bunu, dev ortamını Docker ile güvenli biçimde izole ederek yönetebildiğim için yapabiliyorum
- Claude çoğu temel aracı iyi kullandığından MCP(Multi Capability Protocol) yalnızca özel durumlarda kullanılıyor
- Örnek: playwright-mcp ile tarayıcı otomasyonu
- Kendi yaptığım araçlar sıradan script’lerden oluşuyor ve mümkün olduğunca basit bir araç yapısı korunuyor
Choice Of Language
- Farklı dillerde agentic coding denemeleri yaptıktan sonra, yeni backend projeleri için Go’nun en ideal seçenek olduğu sonucuna vardım
- Context sistemi: Kodun tamamında açıkça akan bir veri yapısı sunuyor ve ajanlara bunu açık biçimde aktarmak kolay
- Test cache’i: Rust gibi diğer dillere kıyasla test çalıştırma ve cache yapısı daha basit; bu da ajanın kod-test döngüsünü verimli kılıyor
- Sadelik: Go’nun kendi sadeliği ajanlar için de avantaj sağlıyor
- Yapısal interface’ler: Bir type’ın method’ları uyuyorsa interface olarak kabul edilmesi, LLM’in bunu kolay işlemesini sağlıyor
- Düşük ekosistem değişim oranı: Uzun ömürlü sürümler ve açık değişimler sayesinde eski tarz kodun otomatik üretilme riski azalıyor
- Python birçok soruna yol açıyor
- fixture, async işleme ve yavaş çalışma gibi nedenlerle agentic loop içinde verim düşüyor
- Frontend tarafında Tailwind + React + Tanstack Query/Router + Vite kullanılıyor
- Tanstack Router dosya adlarındaki
$ işareti ajanı şaşırtıp sorunlara neden olabiliyor
Tools, Tools, Tools
- Araçlar için ölçütler şöyle
- Hızlı olmalı
- Anlaşılır hata mesajları vermeli
- LLM yanlış kullansa bile kararlı çalışmalı
- Gözlemlenebilir ve debug etmesi kolay olmalı
- Makefile tabanlı olarak
make dev, make tail-log gibi komutlar sunuluyor
- Aynı sürecin tekrar çalışmasını önlemek için shoreman’ın fork sürümüyle pid yönetimi yapılıyor
- Loglar hem stdout’a hem dosyaya yazılıyor; böylece ajan loglardan doğrudan bilgi çıkarabiliyor
- Örnek: e-posta doğrulama bağlantıları da loglara yazdırılarak tarayıcı otomasyonuyla e-posta doğrulama süreci yürütülebiliyor
It's All About Speed
- Agentic coding’deki en büyük verimsizlik, çıkarım maliyeti ve araçların verimsiz kullanımı
- Araçların hızlı yanıt vermesi üretkenliğin anahtarı
- Ajan kendi geçici araçlarını oluşturup kullanıyorsa, hızlı çalıştırma/derleme süreleri iş verimini ciddi biçimde artırıyor
- Yavaş ortamlarda dinamik modül yükleme gibi alternatiflerden yararlanmak avantajlı olabilir (ör. Sentry için dosya modülü izleme ve otomatik çalıştırma)
- Loglar kısa ve net tutulmalı; token tüketimini ve hızı optimize etmek için bu önemli, gerekirse LLM’in log seviyesini değiştirebileceği bir arayüz sunmak faydalı
- Kod üretim aşamasından itibaren anlamlı log/observability üretecek şekilde tasarım yapmak önemli
Stability and Copy/Paste
- Ekosistem istikrarı, kodun yeniden kullanılabilirliği ve ajanın kafasının karışmaması açısından çok önemli
- Go ve Flask gibi değişkenliği düşük ve öngörülebilir dil/framework’lerin kullanılması öneriliyor
- Kütüphaneleri otomatik yükseltirken dikkatli olunmalı; ajanın bıraktığı yorumlar veya kod akışı bozulabilir
- Mümkünse kodu doğrudan yazma → bağımlılıkları en aza indirme stratejisi öneriliyor
Write Simple Code
- Ajanlar basit ve açık kodla daha iyi çalışıyor
- Önerilen yaklaşım
- Açıklayıcı ve uzun fonksiyon adları tercih edin; class yerine daha çok fonksiyon yazın
- Kalıtım ve karmaşık numaralardan kaçının
- Saf SQL kullanımı öneriliyor; ajanlar SQL’de başarılı ve loglarla karşılaştırma ile takip daha kolay
- Açık yetki kontrolleri kod içinde sezgisel biçimde görünmeli (ayrı dosya/ayar içine gizlemeyin)
Make It Parallelizable
- Tek tek ajanların işlem hızı çok yüksek değil, ancak paralel çalışma ile toplam verim artırılabilir
- Örnek: dosya sistemi temelinde checkout kopyaları
- Redis veya DB gibi paylaşılan kaynakların nasıl ayrılacağı düşünülmeli
- Örnek araç: Docker tabanlı oturum ayrımı için container-use
- CI tabanlı paralel işler ve Cursor’un background agent gibi araçları da dikkat çekiyor
Learn To Refactor
- Agentic yaklaşımda doğru zamanda refactor etmek önemli
- Karmaşıklık arttığında ajan kodu düzgün yönetemiyor
- Örnek: Tailwind class’ları 50 dosyaya dağılmadan önce bunları component library haline getirmek
- Çok erken ya da çok geç yapılan refactor verimsizdir; bu yüzden doğru anda yapısal iyileştirme talimatı vermek gerekir
What Next?
- Agentic coding hızla evriliyor ve temel ilkeler “sadelik, istikrar, görünürlük, paralellik” olmaya devam ediyor
- Araçlar ve metodolojiler değişse de bu ilkeler geçerliliğini koruyor
- Amaç yalnızca üretkenliği artırmak değil, daha iyi kod kalitesine ulaşmak
- Ajanların yazdığı kodun kalitesi birkaç ay öncesine göre belirgin biçimde iyileşti
- Değişime esnek biçimde uyum sağlayarak kodlama deneyimini genişletin
2 yorum
Ben de hâlâ yapay zekaya en fazla basit test kodları ya da örnekler soruyorum; ama artık bunu genel olarak uygulamaya çalışan insanlar giderek daha fazla ortaya çıkıyor.
Henüz erken olabilir, ancak birkaç yıl sonra bunun gayet doğal hale geleceği kesin.
Hacker News görüşleri
VS Code Nightly sürümlerinde Copilot ile Claude Sonnet 4'ü birlikte kullanarak Agentic Coding deneyimi yaşıyorum. Günümün yarısı toplantılarla dolu olsa bile, sadece git geçmişime bakan biri bunu fark etmeyecek kadar üretkenlik artışı hissediyorum. Artık ince ince implementasyon yapmak yerine, değişikliğin gerçekten doğru çalışıp çalışmadığını, bu kodun anlaşılır olup olmadığını, daha iyi anlaşılması için yapının nasıl kurulması gerektiğini ve agent'ın yanlış anlamasını azaltmak için AI convention markdown'a neler eklenebileceğini düşünüyorum. Dün gece mypy hatası 38 tane olan bir dosyayı Agent'a bıraktım, 15 dakika ailemle konuştuktan sonra döndüğümde Agent yaptığı değişiklikleri ve nedenlerini özetlemişti. Değişikliklerden biri üzerine tartıştık ama sonunda Agent'ın görüşünün doğru olduğuna karar verdim. mypy kontrolü de geçti. Şimdi ekipte de bu teknolojinin gerçek potansiyelini anlatmaya çalışıyorum ama şüpheyle bakanlar ve AI mükemmel değil diye karşı çıkanlar da var. Ama bir arkadaşımın dediği gibi, "bugün senin ve bu teknolojinin yaşayacağı en kötü gün" olması bence tam da bunun yenilik olduğunun kanıtı
type checker hataları aslında geliştirme iş akışında en az zaman harcanması gereken şeylerden biri; o kısmın neden bu kadar uzun sürdüğünü merak ettim. AI kullanımına dair tüm tartışmalarda herkesin bunu pratikte hangi işlerde kullandığını birlikte görebilsek (Cloudflare yazısında olduğu gibi) etkisi çok daha büyük olur diye düşünüyorum
Kişisel olarak Agent'a Python'dan çok Rust kodunda güvenirim. Python'da statik analiz seviyesi clippy ya da rust-analyzer kadar iyi değil; bu yüzden tüm kod yollarını her seferinde bizzat çalıştırıp kontrol etmek gerekiyor
Günün yarısı toplantı olsa bile git geçmişinden anlaşılmayacağını söylemişsin; ama benim çalıştığım şirketin çalışanı olsaydın, yakında bu seviyede çıktıyı sürekli beklemeye başlayacağımı da aklında tutardım
İş akışını merak ediyorum. Claude Code'u kişisel proje deneyleri için kullanıyorum, şirket hesabımla da Copilot'u VS Code agent modunda 3.5, 3.7 Sonnet ve 04-mini dahil çeşitli kombinasyonlarla denedim. Bunu büyük bir Go projesinde kullandım ama test tarafı hariç sonuçlar berbattı. Aracı yanlış mı kullanıyorum diye düşünüp "en güncel best practice" ne varsa denedim; context yönetimi, model değiştirme, kurallar tanımlama, prompt iyileştirme, hepsini denememe rağmen hiçbir gelişme olmadı
AI convention markdown'a Agent hatalarını azaltacak şeyler daha eklenebilir demişsiniz; bunun her işte context olarak eklediğiniz bir dosya mı yoksa VS Code Copilot Agent'ın resmî convention'ı mı olduğunu merak ediyorum. Ayrıca belge yapısını belirlerken yararlandığınız bir kaynak var mıydı, yoksa AI'nın tekrar eden hatalarına bakıp zaman içinde kendiniz geliştirdiğiniz bir çıktı mı, bunu da sormak isterim
Agentic coding'i verimli kılan tekniklerin çoğunun insanın kod yazma verimini de artırması gerçekten çok teşvik edici. Eskiden yalnızca AI'nın anlayacağı "dev bir çamur yığını" koddan endişe ediliyordu ama gerçekte tam tersi oluyor. Açık kod artık AI üretkenliği için de çok daha önemli hale geldi ve bunun sayesinde üretkenlik farkı sayısal olarak net biçimde görünür oldu. Claude'un her kod tabanında ne kadar iyi çalıştığını ölçülebilir şekilde gösterebildiğimiz için, kodun iyi yapılandırılmış olup olmadığı tartışması da artık görüş ayrılığı değil, nesnel dayanaklarla yapılabiliyor
Kodun bir "çamur yığını"na dönüşeceği korkusu aslında programlama boyunca hep vardı (Rich Hickey konuşmalarına bakın). İnsanlar "şimdilik kolayına kaçalım" deyip ertesi gün devasa teknik borç yükleniyor. LLM'ler sayesinde anlamsız boilerplate üretmek de daha kolaylaştı. Acı azalırsa, insanın düzeltme isteği de tamamen ortadan kalkabilir
"Kodun sadece AI'nın anlayacağı bir şeye dönüşeceği kaygısı bugün için gerçek olmayabilir ama gelecekte ne olacağını bilmiyoruz" cümlesini de özellikle eklemek isterdim
Bu kısma gerçekten katılıyorum. İyi hata mesajları, hızlı araçlar, oturmuş bir ekosistem, basit ve "magic"siz kod, sezgisel SQL; bunlar zaten benim hayalimdeki geliştirme ortamıydı. Agent'lar o kadar hızlı çalışıyor ki en küçük gecikme bile hissediliyor; bu yüzden bu tür teknolojiler tüm geliştirme deneyiminin seviyesini yükseltebilir diye düşünüyorum
Agent kullanınca doğal olarak Go ve Tailwind'e yönelindiğini duyuyorum. Eğitim verisi bol olduğu için AI bunları düzgün ele alabiliyor. O halde herkes bu araçları kullanırsa, gelecekte yeni dil, framework ve kütüphane ortaya çıkarmak zorlaşır mı diye endişeleniyorum. Mevcut çözümlerle rekabet etmek zorlaşabilir ve Stack Overflow gibi insan toplulukları da yok olabilir
Yeni dil ya da framework'lerin artık hiç çıkmayacağı endişesine katılmıyorum. LLM'ler çeviri konusunda çok güçlü; eğitim verisi olmasa bile, sıra dışı ama yapısı net bir framework'ü kod tabanına bakarak hemen öğrenebiliyorlar. Bizzat kimsenin daha önce görmediği kendime özgü bir C# framework'ünde bile LLM'lerin çok iyi çalıştığını gördüm. Elbette Rust'ın lifetime gibi sıra dışı özellikleri hemen uyum sağlamayabilir ama Go gibi basit şeylere çok çabuk adapte oluyorlar. Hatta gelecekte yeni dil tasarlarken baştan LLM uyumluluğunu da düşünmek gerekebilir; tasarım, araçlar, dokümantasyon gibi
Bu gerçekten çok önemli bir soru. Başka bir deyişle, internet LLM üretimi içerikle doldukça kaliteli eğitim verisi azalacak ve LLM dostu geliştiriciler geçmişin "daha az radyasyonlu" eski teknolojilerine (JS/React gibi) daha çok yönelebilir. İleride JavaScript/React geleceğin COBOL'u olsa bile pahalı danışmanlara ihtiyaç kalmadan, bakım işini LLM'ler halledebilir. AI akımından uzak durmak istiyorsanız yeni dil geliştirmek, özellikle de Lisp+DSL gibi LLM'nin hemen öğrenemeyeceği tuhaf diller, AGI çağı gelene kadar epey güvenli bir alan olabilir
Yazılım yığınının geleneksel döngüsü şöyledir: (1) Mevcut yığın bütün niş alanları kapsadıkça karmaşıklaşır ve uzmanlar gereksiz "atotecture" üretir (2) Bunun sonucunda yeni trendleri çok daha kolay ve net çözen daha basit yeni bir yığın çıkar ve popüler olur (3) Zamanla bu yeni yığın da aynı sebeple ağırlaşır ve döngü tekrar eder. AI coding'de context genişlemesi çok hızlı ilerlediği için bu döngünün kolay kolay kırılacağını sanmıyorum
Go ve Tailwind'e zorlanıldığı iddiası aslında yazarın kişisel eğilimini de fazlasıyla yansıtan bir bakış açısı. Sonnet'in
cargo testCLI'da sorun yaşaması, Rust'ın, cargo'nun ya da daha genel olarak AI'nın problemli olduğu anlamına gelmez. Mesela PHP testlerinde Junie built-in runner'ı iyi kullanamıyor ama onabin/test-phpscript'i verince kendi kendine düzgünce kullanıyor. Gereksinimleri kılavuzlarda açıkça belirtmek işe yarıyor ama fark daha çok, varsayılan araçlara takılı kalma eğilimi. Stack Overflow deneyimi konusunda da benim AI asistanımın soruları yinelenen diye kapatmaması büyük bir artı. SO'nun kürasyon çabası değerli ama bu yüzden çok sayıda kullanıcıyı da uzaklaştırdığı bir gerçekDaha dün Claude'a (Zed kullanarak) sadece koşulları verip sıfırdan bir elixir phoenix projesi kurdurdum ve sorunsuz yaptı. CSS tarafında tailwind kullandı ama sanırım bunun nedeni phoenix'in bunu zaten varsayılan olarak kurması. AI'nın Go'ya yönelttiği iddiasına katılmıyorum. Hatta bağlam vermeden sorunca daha çok Python önerileri geliyor ve topluluğu küçük olan elixir'i bile sorunsuz kullanabildim
Claude Code Sonnet 4.0 ile Rust kodunda yaklaşık bir haftadır deneme yapıyorum ama beklentimin altında kaldı (üstelik Bedrock üzerinden geçtiği için pahalı da). Başlangıçta plan yapmaya çok zaman harcıyor ama sonunda işin ancak yarısını tamamlıyor. Acaba benim gözden kaçırdığım bir şey mi var diye merak ediyorum
Bende de neredeyse aynı his var. Cursor Edit/Agent modunda çoğu zaman tek seferde istediğime çok yakın düzenlemeler çıkıyor ve inanılmaz verimli oluyor; ama CLI ortamında fazlasıyla hantal. Acaba Claude Code'a 10-15 dakikalık işleri bırakıp sadece diff mi inceliyorsunuz, yoksa gerçekten kod incelemesi de yapıyor musunuz, bunu merak ediyorum
Ben de tamamen aynı deneyimi yaşadım. Bilerek işe yarar kullanım alanları arayarak denememe rağmen bir türlü doğru dürüst çalışmadı; bu da beni gerçekten şaşırttı
Pahalı geliyor dememelisin. Pro plan aylık 20 dolar, Max ise 100-200 dolar; API ile kullanıp ayda bin doların üstüne çıkmaktan daha ucuz bir yapı bu
Konteyner kullanımının anılması hoşuma gitti. Ben dagger/container-use üzerinde çalışıyorum; ekipte eski Docker çalışanları ve Docker'ın kurucusu da var. Agent'ları paralel çalıştırabilmek, bunu güvenilir biçimde iyi kullanabildiğimiz anda, çok büyük bir teknik kırılma noktası olacak diye düşünüyorum. O zamana kadar bile, Agent iş yaparken benim başka işlerle uğraşabilmem ya da Agent'ın alakasız yerlere dokunmasından endişe etmemem için geliştirme ortamını konteynerleştirmek çok faydalı. Konteyner kullanımı teknolojisi de hâlâ erken aşamada ama çok hızlı gelişiyor; şu anda özellikle kararlılık, git çakışmalarını azaltma ve insan-Agent etkileşimini güçlendirme üzerine odaklanıyor
Dil seçimiyle ilgili benim düşüncem şu: 1) Java, LLM'nin başvurabileceği çok büyük ve eski veri kümesi sayesinde en kapsamlı dil (ama bu mutlaka en doğru olduğu anlamına gelmiyor). 2) Her şeyden önce en iyi bildiğiniz dili kullanmalısınız; çünkü ancak o zaman LLM'nin hatalı akıl yürütmesini, yanlışlarını ve halüsinasyonlarını hızla yakalayabilirsiniz
Java'nın en büyük, en eski ve en net veri kümesine sahip olduğu görüşü bana, LLM'nin API, dokümantasyon ya da 3rd party kaynak kodu arayacak araçları kullanamadığı durumda geçerli bir tavsiye gibi geliyor. Araçlar otomatik olarak neyin kullanılacağını saptayabiliyorsa, hangi dili seçtiğinizden çok agent'ın kaynağı okuyabilmesi önemli olur. Ama ikinci görüşe, yani bildiğiniz dili kullanmanız gerektiğine tamamen katılıyorum. Sonuçta insanın dikkatli incelemesi şart ve bildiğiniz dilde hata ayıklamak çok daha kolay
Java neden en büyük veri kümesine sahip olsun ki? Açık kaynak projelerde Java gerçekten en yaygın dil mi (örneğin tüm Apache ekosistemi yüzünden mi)? Yoksa Java açık kaynak kütüphanelerinin dokümantasyonu çok daha zengin olduğu için mi?
Ben hep en büyük veri kümesinin Python kodu olduğunu sanıyordum. Herhangi bir şey söylenmediğinde LLM'lerin çoğunun önce Python önermesi de bunu düşündürüyor
Go'nun context system'inin (açık veri aktarımı, kod yürütme akışı boyunca ilerleyecek şekilde tasarlanmış olması) AI agent'lara sadelik sunduğu iddiasına karşı, "tracing data dışında veriyi context.Context içinde taşımak aslında iyi bir pratik değil" eleştirisi var
Katılıyorum. chromedp'de (Go için chrome headless driver)
context.Contextilk parametre olarak kullanılıyor ama doğrudancontext.Background()yerine özel bir factory'den alınmış context kullanmanız gerekiyor. Timeout ayarını da ayrıcacontext.WithTimeoutile yapıyorsunuz; yani neredeysevoid*işaretçisi gibi kullanılıyorGo konusunda uzman sayılmam ama pratikte birçok kütüphanenin context içine veritabanı bağlantısı, yapılandırma, rate limiter, cache backend gibi şeyler koyduğunu görüyorum; o yüzden şu an bana o kadar problemli gelmiyor
'AI'nın anlayacağı kadar basit kod yazmak' benim beklediğim yenilik noktası değildi. Önceki çirkin kod yazım ile bunun nasıl çatıştığını da merak ediyorum
Yazarın Claude Code için söylediği gibi, çeşitli alternatifler gerçekten var: OpenCode, goose, Codex, Devin, Cursor background agent vb. Claude Code'a benzer açık kaynak + yerel LLM çözümü var mı diye sorulmuş
Şu an için güçlü biçimde önerebileceğim bir açık kaynak + yerel LLM çözümü yok. Yine de SST'nin OpenCode'u UX tarafında hızla gelişiyor ve gelecekte daha iyi yerel modeller çıktıkça buna uyarlamak da kolay olacaktır. Asıl büyük sorun, gerçek anlamda iyi 'tool use' yapabilen modelin neredeyse hiç olmaması. Sonnet'in şaşırtıcı derecede iyi olmasının sebebi de araç kullanımına özel eğitilmiş olması. Gemini bile henüz epey geride; yani mesele bence iyi modelin gelmesiyle çözülecek
Aider neredeyse o noktaya geldi ama bilerek tam agentic hale getirilmiyor. Test çalıştırma, statik analiz, otomatik hata düzeltme gibi şeyleri yapabiliyor; to-do listesi tabanlı şekilde tüm proje spesifikasyonlarını da ele alabiliyor. Şu anda reflection döngüsü sayısına ilişkin sabit kodlanmış bir sınır var (3 tur) ama biraz hack'leyerek bunu artırabilirsiniz; self prompting de eklenirse tamamen otomatik bir agent'a dönüşebilir
Yakında çıkaracağım uygulamanın da iyi bir alternatif olacağını düşünüyorum. Tek dosya indiriliyor, kurulum gerekmiyor; Mac, Windows, Linux ve Docker'da çalışıyor. OpenAI API ile uyumlu tüm modelleri kullanabiliyor (kendi çalıştırdıklarınız dahil), tarayıcı tabanlı olduğu için Claude Code kadar kullanışlı ve komut tabanlı konsol uygulamaları da oluşturabiliyor. Ayrıca terminali doğrudan açıp bir servise bağlayabiliyorsunuz. Şu an kapalı alfada ama kullanmak isterseniz e-postayla ulaşabilirsiniz
Neredeyse her gün yeni alternatifler (ya da denemeler) çıkıyor; bu yüzden yakında herkesin tam aradığı çözümü bulabileceğini düşünüyorum. Örneğin app.build Neon ekibi (şimdi Databricks bünyesinde) tarafından yeni duyuruldu ve oldukça umut verici görünüyor
Neovim eklentisi CodeCompanion da son dönemde daha agentic bir yöne evriliyor. Zaten auto-submit loop, yerleşik araçlar ve MCP entegrasyonu destekliyor. Bağımsız bir CLI aracı değil ama tam editör ortamını doğrudan kullanabilmek özellikle hack'lemeyi, özelleştirmeyi ve hafif editörleri sevenler için daha büyük bir avantaj olabilir
Aylık 100-200 dolar, doğrulanmamış kod yazma AI'ı için fazla pahalı. Kendi deneyimim de çok tatmin edici değildi; üstüne etik tartışmalar da olunca bu ciddi bir giriş engeli yaratıyor
Claude Code API anahtarıyla da kullanılabiliyor, aylık 20 dolarlık Pro aboneliğiyle de
Aider'ı API ücret modeliyle denemenizi öneririm. Context boyutunu kontrol ederek (
/clear,/add,/drop) bunu yaklaşık 25K civarında tutabilirsiniz. İstediğiniz modeli kullanabilirsiniz (örneğin Sonnet 4, Gemini 2.5 Pro). Basit script'leri çoğu zaman 1 doların altında tamamlayabildim; büyük bir araç geliştirirken bile prompt + kod + 100 kadar test toplamda 6 doların altında kaldı. AI ile kod yazmaya alıştıktan sonra Claude Code'a geçmenizi öneririm; daha güçlü ama sık kullanmıyorsanız daha pahalıya gelebilir20 dolarlık bir aylık abonelikle birkaç küçük projede rahatça deney yapıp 100 dolarlık planı düşünüp düşünmeyeceğinize karar verebilirsiniz. Ya da birkaç ay daha bekleyip başkalarının gerçek kullanım deneyimlerine dair yorumlarını takip etmek de mantıklı olabilir