01Nerede gerçekten hızlandırırWhere it genuinely accelerates
Asistanların en iyi olduğu işler, doğrusu zaten bilinen ve çıktısı kolay doğrulanan işlerdir. Sizin yerinize mimari tasarlamazlar; elinizi mekanik işten kurtarırlar. Ekiplerde en net kazanım şu alanlarda görülüyor:
Assistants are best at work where the right answer is already known and the output is easy to verify. They don't design your architecture for you; they free your hands from the mechanical work. The clearest gains in teams show up here:
- Boilerplate ve tekrarlı kod. CRUD endpoint'leri, DTO'lar, konfigürasyon dosyaları — şablonu belli olan her şey.
- Boilerplate and repetitive code. CRUD endpoints, DTOs, config files — anything with a known template.
- Test yazımı. Var olan davranışı sabitleyen unit test'ler, gözden kaçan edge case önerileri. Test yazmanın maliyeti düşünce bahanesi de kalkar.
- Writing tests. Unit tests that pin existing behavior, edge cases you'd have missed. When tests get cheap to write, the excuses go away.
- Migration ve mekanik refactor'lar. Bir API değişikliğini elli dosyaya uygulamak, deprecated çağrıları güncellemek.
- Migrations and mechanical refactors. Applying an API change across fifty files, updating deprecated calls.
- Yabancı kodu keşfetmek. Devraldığınız bir codebase'de "bu akış nereden geçiyor" sorusuna dakikalar içinde harita çıkarmak.
- Exploring unfamiliar code. Mapping "where does this flow go" in an inherited codebase in minutes instead of days.
- İlk taslaklar. Boş dosya korkusunu kaldıran, üzerine düşünülecek bir başlangıç noktası.
- First drafts. A starting point that kills blank-file paralysis and gives you something to think against.
Ortak nokta: bu işlerin hepsinde doğruyu tanımak, doğruyu yazmaktan kolaydır. Asistan üretir, siz doğrularsınız — kazanç buradan gelir. Bu sınırın dışına, doğrusu bilinmeyen ve doğrulaması zor işlere çıktıkça kazanç hızla eriyor.
The common thread: in all of these, recognizing correct is easier than writing correct. The assistant produces, you verify — that's where the gain lives. Step outside that boundary, into work where correct is unknown and hard to verify, and the gain evaporates fast.
02Yeni hata türleriThe new failure modes
Hız bedava değil. İlk ve en sinsi tür: makul görünen ama yanlış kod. Derlenir, code review'da doğal durur — ama var olmayan bir API'yi çağırır ya da bir edge case'i sessizce yanlış yönetir. İnsan hatası genelde dikkatsiz görünür; asistan hatası özgüvenli görünür. Bu yüzden yakalaması daha zordur.
Speed isn't free. The first and sneakiest failure mode: plausible-but-wrong code. It compiles, it reads naturally in review — but it calls an API that doesn't exist, or quietly mishandles an edge case. Human mistakes tend to look careless; assistant mistakes look confident. That makes them harder to catch.
İkincisi inceleme yorgunluğu. Kod üretmek ucuzlayınca diff'ler büyüdü; 800 satırlık "asistan yazdı" PR'ını göz gezdirip onaylamak alışkanlığa dönüşebiliyor. Onay hızlandıkça inceleme, bir kontrol olmaktan çıkıp bir ritüele döner. İncelenmeden merge edilen kod, kim yazmış olursa olsun incelenmemiş koddur.
The second is review fatigue. When generating code got cheap, diffs got big; skimming and rubber-stamping an 800-line "the assistant wrote it" PR becomes a habit. As approvals speed up, review stops being a check and turns into a ritual. Code merged without review is unreviewed code, whoever wrote it.
Üçüncüsü beceri ve bağlam erimesi: her şeyi asistana bırakan ekip, bir süre sonra kendi sisteminin nasıl çalıştığını anlatamaz hale gelir; kod okuma kası da her kas gibi kullanılmadıkça zayıflar. Dördüncüsü, üretilen kodda gözden kaçabilen lisans ve güvenlik sorunları — kaynağı belirsiz bir snippet, doğrulanmadan geçen bir input yolu.
The third is skill and context atrophy: a team that delegates everything eventually can't explain how its own system works — code-reading, like any muscle, weakens when unused. The fourth is subtle license and security issues in generated code — a snippet of unclear origin, an input path that skips validation.
Asistan kodu yazabilir; sorumluluğu yazamaz.
An assistant can write the code. It can't write the accountability.
03Hızı koruyan ekip pratikleriTeam practices that keep the speed
İyi haber: çözüm yeni değil, bildiğimiz mühendislik disiplini. Yapay zekâ ile artık herkes yazılım üretebiliyor; farkı mühendislik yaratıyor. Asistan iyi süreci hızlandırır; kötü süreci de aynı hızla hızlandırır. Üç kural yeterli:
The good news: the fix isn't new, it's the engineering discipline we already know. With AI, anyone can produce software now; the difference is engineering. An assistant accelerates a good process — and a bad one just as fast. Three rules cover it:
- İnceleme disiplini değişmez. Üretim ucuzladı diye PR büyümez. Küçük, odaklı PR'lar asistan çağında daha da önemli — inceleyenin sindirebileceğinden büyük diff, inceleme değildir.
- Review discipline doesn't change. Generation getting cheap is not a reason for PRs to grow. Small, focused PRs matter more in the assistant era — a diff bigger than a reviewer can digest is not a review.
- Test'ler sözleşmedir. "Asistan yazdı, çalışıyor" bir inceleme değildir. Davranışı sabitleyen test yoksa kod bitmemiştir; asistan test yazmayı ucuzlattığına göre bahane de kalmadı.
- Tests are the contract. "The assistant wrote it and it works" is not a review. Without tests that pin the behavior, the code isn't done — and since the assistant made tests cheap, the excuse is gone.
- Sahiplik kuralı: merge ettiğinizin sahibi sizsiniz. Üç ay sonra o kod üretimde patladığında "onu asistan yazmıştı" bir cevap değildir. Merge tuşuna basan, kodu açıklayabilmelidir.
- The ownership rule: you own what you merge. When that code breaks in production three months from now, "the assistant wrote it" is not an answer. Whoever presses merge should be able to explain the code.
04Bağlam hijyeni — ve ne zaman kapatmalıContext hygiene — and when to switch it off
Asistan kalitesinin en büyük belirleyicisi model değil, verdiğiniz bağlamdır. İyi bir CLAUDE.md ya da agents dosyası, güncel README'ler, asistanın okuyabileceği convention'lar: bir kere yazılır, her oturumda kazandırır. Asistanın körü körüne uyduğu kurallar yerine, uymadığında fark edeceğiniz kurallar yazın. Bağlam bakımsız kalırsa asistan da dünün kurallarına göre üretir.
The biggest driver of assistant quality isn't the model, it's the context you give it. A good CLAUDE.md or agents file, up-to-date READMEs, conventions the assistant can read: written once, they pay off every session. Write rules you'd notice being broken, not rules to be followed blindly. Let the context go stale, and the assistant builds to yesterday's rules.
# repo kökünde / at repo root stack: "Next.js + TypeScript strict, pnpm" test: "pnpm test — her PR'da yeşil / green on every PR" style: "mevcut util'leri kullan, yeni bağımlılık ekleme / reuse utils, no new deps" never: "auth/ ve billing/ elle incelenmeden değişmez / auth/ and billing/ never change without human review"
Bir de kapatma disiplini var. Üç durumda asistanı ikinci plana alın: özgün algoritma tasarımı — problemi önce kendiniz düşünmelisiniz; güvenlik-kritik yollar — auth, ödeme, yetkilendirme kodunda her satır insan gözünden geçmeli; ve öğrenme anları — junior geliştiricinin kendi yazması gereken kod. Bu üçünde yavaşlık bir maliyet değil, işin kendisidir. Araç iyi; her işin aracı değil.
There's also a discipline of switching it off. Push the assistant to the background in three cases: novel algorithm design — you need to think the problem through yourself first; security-critical paths — every line of auth, payment and authorization code needs human eyes; and learning moments — code a junior developer should write themselves. In these three, slowness isn't a cost; it's the work itself. It's a good tool; it's not the tool for every job.