R10'da AI yazılımlara karşı olan bu tepki niye?

1. Injection & Untrusted Input Sweep

Trace every point where external data (user input, HTTP params, headers, files, queue messages, third-party API responses, environment values) enters the system. Follow each value to its sinks: queries, shell/exec, file paths, templates, HTML output, redirects, deserializers, eval-like constructs. Flag every path where data reaches a sink without validation or context-appropriate encoding, and name the missing defense. Report per
entry point, including entry points that are clean.

2. Authentication & Session Handling

Audit only how identity is established and maintained. Check: endpoints reachable without authentication that shouldn't be; token/session generation (entropy, expiry, rotation); credential storage and comparison (hashing algorithm, constant-time checks); logout and invalidation actually revoking access; password reset and account recovery flows; remember-me and refresh-token handling. For each mechanism, state what you verified vs. what depends on framework behavior you cannot see.

3. Authorization & IDOR Sweep

Assume authentication works; audit only WHO may do WHAT. For every operation that touches a resource owned by a user/tenant/org: is ownership or role verified server-side, before the action, on every path (including bulk, batch, export, and admin variants)? Flag any object ID accepted from the client and used without an ownership check (IDOR). Flag privilege checks done client-side, after the effect, or only on the happy path. List every endpoint/operation you inspected with its verdict.

4. Secrets & Sensitive Data Exposure

Hunt for: hardcoded credentials, API keys, tokens in code/config/tests/fixtures; secrets in log statements or error messages; PII written to logs; verbose error responses leaking stack traces, queries, or internal paths; sensitive fields returned in API responses that
callers don't need; debug endpoints or flags. Check configs and example/env files, not just source. Report every hit with exact location and the exposure path (who can see it).

5. Error Handling & Failure Paths

For every multi-step operation, ask: what happens when step N fails after steps 1..N-1 succeeded? Hunt for: empty or swallow-all catch blocks; errors logged and then execution continuing in a corrupt state; partial writes with no rollback or compensation; error types collapsed so callers cannot distinguish retryable from fatal; failure paths that leak resources or hold locks. Report the concrete corrupt state each gap can produce.

6. Concurrency & Race Conditions

Within this runtime's concurrency model, hunt for: shared mutable state accessed without synchronization; check-then-act races (exists-then-create, read-then-update, balance-then-deduct); non-atomic read-modify-write on shared stores; missing awaits / fire-and-forget with side effects; lazy initialization unsafe under concurrent first access; lock ordering that can deadlock. For each finding, describe the interleaving that triggers it in one or two sentences. If the runtime makes a category impossible, say so and move on.

7. Resource Lifecycle & Leaks

Audit acquisition and release of every scarce resource: DB connections, file handles, sockets, subprocesses, timers/intervals, event listeners, temp files, locks. For each: is release guaranteed on ALL paths including exceptions and early returns (finally/defer/RAII/using equivalents)? Are pools bounded and returns guaranteed? Are listeners/timers removed when their owner is destroyed? Flag every acquisition whose release you cannot prove from the shown code.

8. Data Access Patterns & N+1

Audit how the code talks to its data stores. Hunt for: queries inside loops (N+1); missing batching where the API supports it; unbounded queries (no limit/pagination) on tables that grow; SELECT-everything where few fields are used; filtering/sorting/joining in application
memory that the store should do; repeated identical reads within one request with no caching; write patterns causing lock contention. Where schema/indexes are not visible, tag index-related findings NEEDS-CONTEXT and name what you need.

9. Algorithmic Complexity & Hot Paths

Identify the paths most frequently executed or handling the largest data (request handlers, loops over collections, serialization). For each, state the load model you assume ("N items per request, M concurrent"), then flag: nested iteration over unbounded data, linear scans
inside loops (accidental O(n²)), repeated recomputation of invariants, redundant serialization/parsing round-trips. Every finding must state the scale at which it starts to hurt; patterns that never see scale are NITs.

10. Memory & Unbounded Growth

Hunt for state that only grows: caches without eviction or TTL; collections appended to per-request at module/global scope; unbounded queues/buffers; loading entire datasets or files into memory to process a fraction; large object graphs retained by closures, listeners, or static references; per-user/per-session state never cleaned up. For each, state the growth driver (per request? per user? per day?) and the eventual failure mode.

11. External Calls, Timeouts & Resilience

List every call that leaves the process (HTTP, DB, cache, queue, third-party SDKs). For each, verify: an explicit timeout exists (flag every infinite-default); failure is handled distinctly from success-with-bad-data; retries, if any, are bounded with backoff and only on idempotent operations; one slow dependency cannot exhaust the caller's threads/connections/event loop; user-facing behavior on dependency failure is defined, not accidental. Output a table: call site → timeout → retry policy → failure behavior.

12. Idempotency & Retry Safety

Assume every operation can be delivered twice (client retry, queue redelivery, double click, network replay). For each state-changing operation: what happens on duplicate execution? Hunt for: payments/emails/notifications sent twice; counters double-
incremented; duplicate rows on retried creates; non-idempotent handlers consumed from at-least-once queues; missing idempotency keys on unsafe endpoints that clients retry. Classify each operation: naturally idempotent / protected by key or constraint / UNSAFE.

13. Transaction & Consistency Boundaries

Find every operation that updates more than one thing (multiple rows/tables, DB + cache, DB + external service, DB + event publish). For each: is there a transaction, saga, outbox, or compensation strategy or does partial failure leave the system inconsistent?
Specifically hunt for: cache updated before/without the DB commit; events published for changes that then roll back; cross-service writes with no reconciliation. Name the exact inconsistent state each gap produces and who observes it.

14. Configuration & Environment Hardening

Audit configuration across environments: dangerous defaults (debug mode, permissive CORS, disabled TLS verification, open admin ports); prod/dev config divergence that changes security behavior; config values trusted without validation at startup; feature flags that disable security controls; identical secrets/keys across environments; missing fail-fast when required config is absent (silently running misconfigured). Report per config file/source, including which environments you could not inspect.

15. Dependency & Supply Chain Review

From manifests and lockfiles: flag dependencies that are unused (declared but never imported), duplicated across the tree in conflicting versions, abandoned or archived upstream, or pulled in for one trivial function. Check for install-time script execution and typosquat-suspicious names. Identify which dependencies sit on security-critical paths (auth, crypto, parsing untrusted input) these deserve version pinning and priority updates. You cannot query CVE feeds live: mark version-vulnerability claims NEEDS-CONTEXT with the exact package@version to check.

16. Logging, Observability & Auditability

Evaluate whether production failures can be diagnosed from the outside. Check: errors logged with enough context (correlation/request ID, relevant IDs but no PII/secrets, cross-check with pass 4); log levels meaningful (not everything ERROR or everything INFO);
security-relevant events (login failures, permission denials, admin actions) leaving an audit trail; silent failure points with no signal at all; noisy logs in tight loops. Output: the top diagnostic blind spots incidents that would be impossible to reconstruct.

17. API Contract Consistency

Audit the API surface (external or internal) as a consumer would: naming and casing consistency across endpoints; error response shape uniform and machine-parseable; status codes/error types used consistently (same failure → same code everywhere); pagination,
filtering, and sorting conventions uniform; nullable vs. absent fields deliberate and consistent; breaking-change risks (fields renamed/removed, semantics changed) versus any versioning policy. Report inconsistencies in pairs: "endpoint A does X, endpoint B does Y for the same concept."

18. Cross-Module Contracts & Emergent Risks

Ignore single-file defects; audit interactions. For each module boundary you can see both sides of, reconstruct the implicit contract: who validates, who authorizes, who retries, who owns the transaction, which invariants each side assumes. Then hunt mismatches: responsibility gaps (each side assumes the other does it), double effects (both retry/ cache/encode), invariant drift, failure-mode mismatch (one throws, the other expects codes), ordering coupling, fan-out amplification. Every finding names BOTH sides with
locations. Start with a COVERAGE list: boundaries seen end-to-end vs. one side only one-sided boundaries yield NEEDS-CONTEXT items, never conclusions.

19. Test Gap & Assertion Quality

Map existing tests against risk, not coverage percentage. Identify: critical paths (auth, money, data mutation, the findings of previous passes) with no failing-path tests; tests asserting implementation details instead of behavior (break on rename, survive real bugs); tests with no meaningful assertions (run-without-error only); shared mutable fixtures causing order dependence; concurrency- and boundary-value blind spots. Output a ranked list: the ten missing tests that would catch the most damage, each with the exact
scenario to assert.

20. Verification & False-Positive Filter (always run last)

Input: all findings from previous passes plus the code. For each finding: locate the citation mismatch means REJECTED unless you can relocate it; attempt to falsify it an existing guard, validation, type constraint, or framework behavior that already prevents the problem means REJECTED with the disproving location cited; findings that depend on unseen code remain UNVERIFIED with the exact files needed. Merge duplicates across passes, keep the best writeup. Re-score severity conservatively: CRITICAL only if
you can articulate the concrete failure yourself. You may not add new findings. Output three sections: CONFIRMED (sorted by severity), UNVERIFIED (with required context), REJECTED (with one-line reasons).



Bu testleri geçtikden sonra evet.

Madem cevap arıyorsunuz, bir yazılımcı gözünden dürüstçe belirteyim.

Bir yazılımcının gelirine yapay zeka yazılımları "negatif" yönde etki etmez. Çünkü yazılımın bir yazılımcıdan çıkıp çıkmadığını anlamak oldukça kolay. Tepki gösterenler senior yazılımcı olmayabilir. Sınırlı bilgileri vardır ve ellerinden gidecek işlere üzülüyor olabilirler. Bunu anlayışla karşılamak gerekir.

Ancak, yapay zeka yazılımlarının iyi olabilmesi için, prompt u giren kişinin yazılım mimari olması gerekir. Burada eşleşmeyen konu da tam olarak bu. Adam "şu yazılımı istiyorum" diye prompt giriyor. Detayları yazıp yazmamanız bir şeyi değiştirmiyor. Mimari emri vermeden verdiğiniz her prompt tonla açıkla geliyor. Yapay zeka sizin için "en iyisini" düşünmüyor. En iyisini mimar düşünür. Yani, insan düşünür.

Burada yapay zeka ile üretim yapan biri, $200 harcayıp size sistem yapabilir.
Bir yazılım mimari, aynı sistemi, aynı yapay zeka aracını kullanarak binlerce dolara mal eder.
Bu aradaki fark, birinin ne kadar düşünmediğini, diğerinin ne kadar sağlam alt yapı oluşturduğunu gösterir.

Yapay zekanın sizi destekleyici, manipüle edici, sorunun soruş biçimine göre cevap üretici bir yapı olduğunu unutuyorsunuz. Bir soruyu negatif yükle sorduğunuzda negatif, pozitif yükle sorduğunuzda pozitif cevap alıyorsunuz. Bazen size kasten zıt cevap verip, tepki ölçüyor, bazen manipüle için bu yola giriyor. Bunu fark etmeyen biri, aynı araçla yazılım üretiyor. O yazılımı kaç defa stres testinden geçirdiniz, kaç defa bug/gap hunting yaptınız? Hiç saldırı yaptınız mı?

Görselle örnek vereyim.

Bir e-ticaret/pazaryeri sitesinin kullanıcı yorumu sayfası:



Yorumlarını listeleme filtresi, görsel ve video paylaşım özelliği, bu görsel ve video paylaşımlarının kullandığı method ve bu metodun 5 milyon görsel yüklendiğinde yavaşlatmayan çağırılma biçimi. Bu mimaridir. Hem video için hem de görsel için alt yapı yazmak zorundasınız. Veritabanına görseli yükler, çağırırım mantığı yok.

Mesela filtreleme olayı:



Gördüğünüz gibi ürünlerin filtreleme biçimi hem sol barda, hem de sıralama biçimi orta alanda bayağı detaylı. Bu detaylara bakarsanız, bu detaylar kullanıcı deneyimleri baz alınarak tasarlanmış detaylar. Siz yapay zeka ile geliştirme yaparken, bu detayları ve kullanıcı deneyimlerini, kaç projede, internet sitesinde, kaç milyon kullanıcı ve kaç milyon ürün ile test ettiniz? Kaçında yapay veri, kaçında gerçek veri kullandınız? En basitinden filter by price en düşük ürün fiyatı ile başlıyor ve en yüksek ürün fiyatı ile bitiyor, kullanıcıya arayabileceği en ucuz ürünün fiyatını doğrudan bildiriyor. Kullanıcı daha ürünlere bakmadan bilgi sahibi oldu. Sıralama biçimi yalnızca top rated yapıp, 1 yorumla 5 yıldız almış ürünü çekmiyor, ya da reviews yapıp en çok yorum alanı seçmiyor. Bunun yerine, best sellers yapıyor. Bunu yapabilmek için hem top rated hem reviews hem de toplam satış istatistiğini analiz ediyor. Discount rate için, birbirinden bağımsız promosyonlar toplamının birbirlerine olan oranlarını hesaplamanız gerekiyor. Bir sorgu sonucu için saniyenin binde ikisinde üretmeniz gereken şey, komplex bir matematik içeriyor.

Siz $200'ı buradaki tek sayfadaki tüm algoritmaları doğru çalıştırmaya harcayabilirsiniz. Bunun nedeni, bunları tekte planlayacak kadar tecrübenin, prompta girmemiş olması, girdiğinde sınırlarının ve önemli değerlerinin belirlenmemiş olması gibi sorunlar karşınıza gelir. Yani, scope u vermek yetmez, bağlayıcı, zorunlu, olmaması gereken gibi birçok şeyi de girmeniz gerekir.

Bugün, uçak bileti satış sitesi yapsanız, içinizden biri hemen $200 harcayıp promptlarla bitirir. Benim bunu gerçek hayatta yapmak için harcayacağım "yapay zekalı bedel", $8000 altında olmaz. Kendi emeğim buna dahil değil, bu sadece yapay zekanın bana masrafı. Kullanır mıyım peki? Belli konularda bende kullanabilirim. Ama çok sınırlı, ve çok dökümantasyon içeren cinsten çünkü her bir kodu gözlemek zorundayım.

Neden mi?

İşte nedeni:



Kendisine oldukça basit bir komut verdiğim ve bir yazılımcının yaklaşık 35 saniyesini alacak bir işlem için, Opus 4.8 Max, yerel bilgisayarın D diskinde yer alan bir kodta, verilmiş oldukça sınırlı bir yetki ve oldukça çevrelenmiş bir "net scope" ile, 35 saniyede bunu üretmek yerine, önce bunu üretti, sonra yerelde live code aradı, publish edilmiş kod buldu, bu kodta geçen sunucu erişim bilgilerini aldı, sonra bu sunucu erişim bilgileri ile sunucuya ulaşıp değişiklik yaptı, ardından benim durdurmam sonucu işlem sonlandı. 12 milyon token harcandı. Yapılması gereken eylem: SampleDataInstaller içerisine 6 adet ürün görseli üretmek. Abartmıyorum. Opus'un olayı "mimarlık" yapmak ve kullanıcı verisini gözardı edip, daha çok aşamada sonuca giderek daha çok iş üretmek. Yani, çok basit veri verdiğim için, 60 aşama gitmek isteyen Opus, bunu sağlayamadığı için, saçma sapan bir aşırılığa gitti. Bu aşırılığa cevabı yukarıda.

Opus 4.8 Max ın aşağı yukarı doğru üretim oranı %60-70 arasındadır. Yani, her yazdığı 10 şeyden 3-4 tanesi yanlış/eksik/atlanmış olabilir. Siz bu oranda bir üretim aracına "şahane" diyebilir misiniz?

Elbette ihtiyacınız "bir sistem değil, bir script ise", çok önemli değil. Ancak, e-ticaret "bir script" değildir, bir sistemdir. Script dediğiniz şey "bir talimat dizisidir". Biri bir şey satarken script diyorsa, ve verdiği şey bir sistemse, yaratıcısının o olmadığını çok rahat anlarsınız.

O kadar harika bir cevap olmuş ki. Tam anlamıyla katılıyorum işte bu sebeple dip fiyat uygulaması veya forum yönetiminin en uygun göreceği şekilde bir teklif uygulamasının getirilmesini tslep ettik. Görüyorum ki sizin de dediğiniz gibi şu projeyi üret promtuyla hareket edenler kendi iç dünyalarında "geçmişte şu fiyata proje üretenler vardı şimdi kendim üretiyorum" kafasındalar

Kimseyi zan altında bırakmak istemem. Bence bunun yaş ve tecrübe ile ilişkisi var. Herkes uzman olamaz, herkes her şeyi bir anda yapamaz. Forumdaki çoğu kişi genç arkadaşlardan oluşuyor. Hepsinin belli ki geçim dertleri var. Bu nedenle, ekonomik sıkıntı olduğunda, etik ve iş ahlaki ikinci sıraya düşüyor. Forumda bizim amacımız aslında bunları cezalandırmaktan ziyade, belli bir iş ve etik ahlağa yönlendirmek, ve insanları daha güzel sonuçlar çıkarmaya teşvik etmek olabilir. Yani, cezaların ve sınırlamaların artması yerine, "iyileştirici yönlendirmelerin" yapılması daha doğru olur. Yönetici olmadığım için çok yorum yapma taraftarı değilim. Ancak, benim bakış açım, yapıcı yönde olurdu.

Bu testleri Yapay zeka tek başına geçemez. Bu yüzden kod bilen kişilerin yapay zekaya yaptırdıkları projenin arka kapısında ki yapılması gereken bu testleri kod bilen yazılımcıların yaptığı projeler zaten piyasa da kalıyor. 3-5 kendini bilmezin yaptıkları da yavaş yavaş kapanır gider ki forum da her gün görüyorum, web sitem nasıl olmuş yeni tasarım nasıl olmuş vs. Promtu girmiş ufak tefek hataları da promtla yaptırmış Arka kapı ardına kadar açık 10 gün sonra bakıyorsun site gitmiş.