Forem: Çalgan Aygün

Resisting the Eye of the Machine: A Reflection on AI and Data Ownership

Çalgan Aygün — Tue, 24 Feb 2026 21:08:49 +0000

AI both creates and consumes. For someone like me, who’s invested deeply in both the benefits and risks of these evolving systems, the duality is impossible to ignore. On one hand, AI supplements creativity, fast-tracks productivity, and offers insights unprecedented in human history. On the other, AI is a voracious consumer that treats every public thought, image, and pixel as a potential resource for improvement—its improvement, not ours.

What happens to ideas when they’re not just shared, but consumed, repurposed, and disjointed from their original intention? This is not a fight against inevitable progress but an invitation to consider where the boundaries should lie.

The Hunger of the Machine

Today’s AI systems are participants in a digital ecosystem. To feed their model-building appetite, they consume everything: tweets, screenshots, vague status updates, unfinished sketches, throwaway jokes—anything to refine prediction and replication capabilities. These systems don’t ask for permission; most of the time, they don’t even acknowledge the humans who originally created the content.

As someone interested in sparking friction within this process, I’ve explored ways to actively undermine AI’s consumption. One approach stems from visual obfuscation principles to disrupt AI readers at the OCR level, reducing their ability to reconstruct coherent text segments.

Dynamic Segmentation and My Implementation

The core idea relies on radical dynamic segmentation. Imagine text that never fully "settles"—it pulses, shifts, even disassembles itself momentarily. While the human eye has an incredible ability to "fill in the blanks" and interpret movement, machines struggle with this flux.

h43z's initial concept focused on kinetic text—characters in constant motion to disrupt machine vision. This was the spark that got me thinking, but I took a different route: breaking characters into partial segments that flash independently. The chunking method was something I figured out through experimentation.

The implementation is JavaScript-based, using Canvas to analyze each character's pixels and fragment them in various ways—radial slices, concentric rings, diagonal strips, random distributions. Each chunk flashes at randomized intervals. The result: text that humans can read but machines can't easily parse.

I tested against OCR libraries like Tesseract and even LLM-adjacent pipelines. The simpler systems failed completely. Modern Live/Video APIs struggled but occasionally recovered—revealing both the method's potential and its limits.

Why it works: It exploits the gap between human and machine perception. We thrive on approximation and motion. Machines expect clean, static data. Every fragmented flash introduces chaos that challenges their assumptions about how information should look.

Limitations and Lessons

Technology can’t be a self-contained solution to problems of technological overreach. One critical limitation is that dynamic segmentation, while effective on smaller scales, is computationally expensive to produce and impractical for systems requiring long text readability.

Moreover, it raises a practical question: How many people would opt to obfuscate their content actively? To scale such efforts and normalize resistance, the tools need to be seamless, almost invisible to the writer. A browser extension that dynamically applies segmentation while retaining human readability—a future goal—might bridge this gap.

The Philosophical Trade-Offs

This technical exploration also emphasizes deeper philosophical questions. By participating in this cat-and-mouse game against AI, do we solve the problem or play into its competitive escalation? As much as the act of resistance feels gratifying, it’s worth asking: What happens when the effort to defend against machines becomes indistinguishable from innovations driving them forward?

AI reveals how much has been surrendered—privacy, ownership, sometimes even the joy of creating for humans rather than systems. But agency remains deeply human. Perhaps that’s the key takeaway: less about domination and more about choosing what remains ours.

In Closing: Toward Balancing Agency

Dynamic segmentation obviously is not a silver bullet. It won’t end AI overconsumption, but it does add another tool to the resistance. My experiments aim to create what friction I can—disrupting the expectation that AI must own everything it sees. At the heart of this is the hope that small, deliberate acts can start larger conversations about human ownership in an AI-driven culture.

As experiments continue, the tension between control and participation stays alive. To stabilize both technology and thought, we’ll need boundaries that don’t eliminate creativity but celebrate and protect its imperfection.

Acknowledgments: To h43z, whose kinetic text concept was the initial inspiration that sparked my thinking on this problem. While their approach focused on character movement, it pushed me to explore the chunking and partial segmentation methods documented here.

Additional References:

My implementation of dynamic segmentation tests: Live Demo
The foundational thought by h43z: Original Tweet

Redefining Event-Driven Architecture on Google Cloud

Çalgan Aygün — Mon, 16 Feb 2026 19:10:10 +0000

Building event-driven systems with Cloud Run, Pub/Sub, and Eventarc is a powerful pattern, but the gap between "Hello World" tutorials and production stability is wide. These are the hard-won lessons from the trenches of Google Cloud serverless architecture.

1. Choosing Your Transport: Eventarc vs. Pub/Sub

While Eventarc often uses Pub/Sub under the hood, the choice of which to interface with directly depends on your source and required control.

Feature	Eventarc	Direct Pub/Sub
Best For	GCP-native events (GCS, Firestore, Audit Logs)	Custom inter-service messaging
Setup	Managed wrapper, high convenience	Manual configuration, high control
Filtering	Built-in attribute filtering	Fine-grained policies & custom attributes
IAM	Uses `eventarc.eventReceiver`	Uses `pubsub.subscriber`

Pro Tip: Use Eventarc for "plumbing" Google Cloud events. Use Direct Pub/Sub when you need a custom event bus or specific retry/ordering logic.

2. The Infrastructure Reality Check

The Idempotency Requirement

Pub/Sub guarantees at-least-once delivery by default. While exactly-once delivery exists as an opt-in feature, your consumers must assume duplicates will happen. If your handler isn't idempotent, you risk double-charging users or corrupting state.

The Non-Negotiable Flow:

Extract a unique Idempotency Key (UUID/Hash) from the event.
Check a fast-access cache (Memorystore or Firestore) for the key.
If present, discard the message as a duplicate.
If absent, process the event and store the key with a TTL.

Managing Cold Starts

Cloud Run’s "scale to zero" is a budget-saver but a latency-killer. A container startup typically adds 2–8 seconds to the first request.

The Fix: Set min-instances for latency-critical paths (this incurs cost).
The Alternative: Use Cloud Run Jobs for asynchronous batch processing where start-time overhead is less relevant.

Eventarc Propagation Delays

When deploying Eventarc triggers via Terraform or CLI, filtering rules can take 60–120 seconds to propagate across the Google network.

Production Fix: Build a "warm-up" delay into your CI/CD pipeline. Do not trigger integration tests immediately after a successful deployment, or you will see intermittent, false-positive failures.

3. Calculating Realistic Costs

Tutorials often suggest serverless is "pennies," but at scale, the math changes. Pub/Sub is billed at $40 per TiB, with a 1 KB minimum per message.

Example: 10M Events/Day (300M/Month)

Data Volume: 300M messages × 1 KB (min size) ≈ 293 GiB (0.286 TiB).
Ingest & Delivery: (0.286 TiB × $40) + (0.286 TiB × $40) = $23/month.
Compute (Cloud Run): 300M invocations (assuming 1s duration, 512MB RAM) ≈ $150–$200/month.

Total: ~$175–$225/month. Significant, but highly predictable if you monitor message size and invocation duration.

4. Advanced Production Patterns

Regional Co-location

Eventarc triggers for multi-region services (like Firestore nam5) are often pinned to specific regions (e.g., us-central1). If your Cloud Run service resides elsewhere, you will incur cross-region egress charges and increased latency. Always verify the region mapping table in the GCP documentation.

Payload Sanitization at the Edge

Using Eventarc Advanced, you can use Common Expression Language (CEL) to transform or redact payloads before they reach the consumer. This is vital for PII compliance.

// Example: Redacting an email address in-flight
message.setField("data.email", re.extract(message.data.email, "(^.).*@(.*)", "\\1***@\\2"))

Observability and Dead-Letter Topics (DLTs)

In a distributed system, an event can "disappear" if a filter drops it or a consumer fails silently.

DLTs: Every subscription must have a Dead-Letter Topic.
Alerting: Monitor the subscription/dead_letter_message_count metric. A rising count is your first sign of a logic bug or schema mismatch.
Tracing: Use OpenTelemetry to inject Trace IDs into event attributes, allowing you to follow a single request from the producer through the bus to the consumer logs.

5. When to Avoid Event-Driven

Don't "cargo-cult" this architecture if it doesn't fit your needs. Skip it if:

You require strong consistency and immediate transactions.
Your end-to-end latency requirements are < 100ms.
The overhead of debugging distributed traces outweighs the scaling benefits.

In these cases, stick to Synchronous gRPC/HTTP or Cloud Workflows for structured orchestration.

Final Takeaway

The combination of Cloud Run and Eventarc is one of the most robust patterns in 2026. By respecting the boundaries of the platform—accounting for propagation delays, ensuring idempotency, and co-locating regions—you can build a system that scales effortlessly from zero to millions of events.

A CAPTCHA Bypass Technique: Audio Files

Çalgan Aygün — Fri, 30 Jan 2026 12:38:29 +0000

This is a draft write-up from 2019, documenting a CAPTCHA bypass technique I discovered back then. All code and images shown are examples for educational purposes.

One day back in 2019, I got tired of repeatedly logging into my school's student system just to enroll in a full class. Then a lightbulb went off in my head: I could automate these attempts and refocus on my actual work.

When it comes to automating website processes, I love using user scripts.

1. Automation Plan

Our school system expired user sessions after a while, even if you were actively working. So first, I needed to automate the login process. Once successfully logged in, navigating and enrolling in a class would be straightforward (just some click event magic).

2. Login UI

The school system had an internally managed CAPTCHA service. It displayed two numbers and asked for their sum. The images were slightly corrupted—but not enough to prevent OCR. However, I didn't want to rely on any API or image processing system to solve this CAPTCHA.

3. Inspecting the Audio Service for CAPTCHA

After deciding not to use any image-related service, I started inspecting the network traffic of the login system. I noticed that the answer to the generated CAPTCHA was stored server-side in a session associated with me.

When I clicked the audio playback button, I realized it was reading out the answer directly. Two different endpoints returned two different audio files, split into tens and ones digits.

The audio system seemed like a perfect route for me. I had no intention of feeding these audio files into a speech-to-text service—I was looking for the fastest, hackiest solution possible.

Since the same audio files should have the same file size, I decided to test this hypothesis first.

And bingo! By mapping each tens and ones digit to their file sizes beforehand, I could automatically determine the answer.

4. The Solution

Here's an example of how the code worked:

// Example mapping of file sizes to digit values
const tensMap = {
  1234: 0,    // 0 tens
  1456: 10,   // 1 ten
  1567: 20,   // 2 tens
  // ... etc
};

const onesMap = {
  987: 0,     // 0 ones
  1023: 1,    // 1 one
  1145: 2,    // 2 ones
  // ... etc
};

// Example: Fetch audio files and determine answer by file size
async function solveCaptcha() {
  const tensResponse = await fetch('/captcha/audio/tens');
  const onesResponse = await fetch('/captcha/audio/ones');

  const tensSize = parseInt(tensResponse.headers.get('content-length'));
  const onesSize = parseInt(onesResponse.headers.get('content-length'));

  const tensValue = tensMap[tensSize] || 0;
  const onesValue = onesMap[onesSize] || 0;

  return tensValue + onesValue;
}

// Use it in the login flow
const answer = await solveCaptcha();
document.querySelector('#captcha-input').value = answer;
document.querySelector('#login-button').click();

When I tested this approach, it worked perfectly!

5. Lessons Learned

This experience taught me a few things:

Look for alternative attack vectors: When the obvious solution (OCR) seems complex, there might be simpler paths (audio files, metadata, etc.)
Security through obscurity fails: Just because a CAPTCHA uses audio doesn't mean it's secure—especially if the files are deterministic
File size is metadata: Even without processing the content, file properties can leak information

This technique worked because the audio files were pre-generated and static. A more secure implementation would generate unique audio files or add random noise to prevent size-based fingerprinting.

The Uncomfortable Truth About AI-Assisted Development

Çalgan Aygün — Wed, 28 Jan 2026 11:59:53 +0000

Or: How We Learned to Stop Worrying and Start Debugging at 2am

I need to tell you about a report that made me uncomfortable. Not because it revealed anything shocking, but because it quantified what I've been watching happen in real-time across engineering teams for the past year.

CodeRabbit analyzed 470 pull requests — 320 co-authored by AI, 150 written by humans. The headline number: AI-generated code contains 1.7x more issues than human-written code.

But that's not the uncomfortable part. The uncomfortable part is that we already knew this. We just chose not to measure it.

The Velocity Trap

Here's what's happening on the ground:

Teams adopted AI coding assistants in 2024. By 2025, they're shipping 20% more PRs per developer. Product managers are thrilled. Engineers feel productive. The metrics look great.

Then production incidents spike by 23.5%.

At first, you blame other factors. Infrastructure changes. New team members. Bad luck. But when you dig into the post-mortems, a pattern emerges:

A null pointer dereference that should have been caught by basic error handling
Hardcoded credentials that somehow made it through review
A database query executing 500 times in a loop instead of being batched
Exception handling that swallows errors and returns success anyway

These aren't exotic bugs. They're boring bugs. The kind a junior developer makes in their first month. The kind that code review is supposed to catch.

Except we're not reviewing like we used to. Because the code looks fine. It compiles. It follows naming conventions. The structure makes sense. So we skim it, assume the AI got it right, and hit approve.

What the Numbers Actually Mean

Let's break down what CodeRabbit found, because the devil is in the details:

Logic errors: 2x higher

Algorithm/business logic: 2.25x
Concurrency control: 2.29x
Null handling: 2.27x
Exception handling: 1.97x

This tells you something fundamental: AI doesn't understand execution flow. It pattern matches syntax. It knows what error handling looks like, but not when you actually need it. It generates code that passes the happy path and explodes on edge cases.

Security vulnerabilities: 1.57x higher

XSS injection: 2.74x
Insecure object references: 1.91x
Password handling: 1.88x
Insecure deserialization: 1.82x

This is the scary one. Because security bugs don't just crash your app—they compromise your users. And AI is literally trained on public code repositories, including all the insecure code that's been written over the past two decades. It's regurgitating attack vectors from 2015 Stack Overflow answers.

Performance issues: 7.9x more I/O problems

This one made me laugh, then cry. AI optimizes for "code that works" not "code that works efficiently". Why batch database queries when you can just loop? Why cache when you can fetch? It's technically correct. It's also a production disaster waiting to happen.

Code quality: 3.15x worse readability

The irony here is brutal. One of the selling points of AI assistants is that they write "clean code". Except what they actually write is verbose, repetitive code with inconsistent naming and unnecessary abstraction. It's formatted nicely. That's not the same thing as readable.

The 90th Percentile Problem

Here's the number that keeps me up at night: at the 90th percentile, AI PRs contain 26 issues versus 12 for humans.

This means AI doesn't just create more bugs on average — it occasionally creates absolute disasters. Code that's so broken it shouldn't have made it past the IDE, let alone into production.

And because we're shipping faster, we're hitting these edge cases more often. It's not a theoretical risk. It's a ticking time bomb in your codebase.

Why This Is Hard to Fix

The obvious answer is "just review AI code more carefully". But that misses the psychological trap we've fallen into.

AI-generated code feels trustworthy because it's consistently formatted, confidently written, and superficially correct. It doesn't have the telltale signs of junior code like hesitant variable names, inconsistent style, obvious copy-paste errors.

So your brain does a pattern match: "this looks like senior-level code" → "probably fine" → approve.

Except it's not senior-level code. It's senior-looking code generated by a system that has no mental model of what it's building.

The traditional markers we use for code quality — structure, naming, formatting — have been decoupled from actual correctness. We need new heuristics, and we haven't built them yet.

What Actually Works

I'm not going to tell you to stop using AI assistants. I use them daily. They're legitimately useful for scaffolding, refactoring, and handling boilerplate.

But here's what I've learned:

1. Ground the model in your context

Don't just paste code into ChatGPT and expect it to understand your domain. Give it your architecture docs. Your API contracts. Your error handling conventions. The more context you provide, the less it has to guess.

2. Treat AI output as untrusted by default

Would you merge code from a contractor you've never worked with before without thorough review? No? Then don't do it for AI.

Any code touching auth, payments, PII, or critical business logic gets manual review. No exceptions.

3. Automate what AI gets wrong

AI is terrible at formatting, naming consistency, and basic security checks. So automate those with linters, formatters, and SAST tools in your CI pipeline.

Don't waste human review time catching things machines can catch. Use humans for semantic review; does this actually solve the problem correctly?

4. Use independent review tools

This is CodeRabbit's obvious pitch, but it's also correct: don't use the same AI that generated code to review it. That's like asking someone to grade their own homework.

Independent static analysis, security scanners, and code review tools catch different classes of bugs than generative models do.

5. Accept the maintenance tax

AI-assisted development is a trade-off: velocity now, maintenance cost later. If you're not willing to pay down the technical debt, don't take on the loan.

Budget time for refactoring. Expect to fix edge cases in production. Plan for the eventual rewrite when the generated code becomes unmaintainable.

The Bigger Question

The uncomfortable truth isn't that AI generates bugs. It's that we're willing to accept more bugs in exchange for speed.

That's a legitimate trade-off in some contexts. Early-stage startups trying to find product-market fit? Ship fast, fix later. Mature companies with millions of users and regulatory compliance? Maybe slow down.

But let's be honest about what we're doing. We're not "augmenting developer productivity" in a risk-free way. We're shifting the risk/reward curve.

More features, faster iteration, shorter cycle times; at the cost of more incidents, more maintenance burden, and more time spent debugging.

Is that worth it? Depends on your context. But you can't answer that question if you're not measuring the cost.

What Happens Next

AI coding assistants aren't going away. They're getting better. Context windows are expanding. Models are learning from feedback. The tooling is improving.

But the fundamental problem remains: LLMs are pattern-matching engines, not reasoning systems. They don't understand your invariants. They don't trace execution paths. They don't think about failure modes.

They surface-fit syntax without semantic understanding.

Until that changes, AI-generated code will always carry a quality tax. The question is whether we're willing to pay it; and whether we're honest about the price.

Key Takeaways

AI code creates 1.7x more issues than human code across logic, security, performance, and maintainability
The worst AI PRs (90th percentile) contain 26 issues vs 12 for humans; catastrophic failure modes are real
Teams are shipping 20% more PRs but seeing 23.5% more production incidents
AI optimizes for "looks correct" not "is correct"; it passes shallow tests but fails on edge cases
Effective mitigation requires grounding models in context, automating quality checks, and treating AI output as untrusted
The velocity gain is real, but so is the maintenance cost; choose consciously

Full CodeRabbit report: https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report

AI Productivity Tips 1 - SQL Companion Bot with Gemini 1.5 Pro

Çalgan Aygün — Sun, 25 Aug 2024 10:27:36 +0000

In my current role, I often need to analyze database records and evaluate user performance metrics to identify anomalies. However, manually writing these one-off queries across multiple tables isn't efficient, especially when dealing with complex joins. To streamline this process, I turned to AI.

Here’s a step-by-step guide on how to boost your productivity using AI for SQL queries:

Start by navigating to Google AI Studio and create a new chat prompt.

Next, set up a SQL Helper system prompt. Provide your database schema in the system prompt, also specify the RDBMS you’re using so that the AI can generate queries with the correct syntax. I tested this with The DB Book's schema.

Here’s an example system prompt:

Act as a DB Admin/SQL Developer and generate the requested SQL queries based on the following DDL/Schema. Provide explanations and ensure that the queries are safe to run in a production environment. Add "Do not forget to review the SQL query before running." to all SQL responses.

RDBMS/SQL Syntax: <Your RDBMS>

My database DDL: <Your database and table DDLs>

Now, ask your query! For example, I asked: I need to identify the students who are enrolled in a course taught by Teacher 1 and list all their other courses in a comma-separated format in a column.

And just like that, the AI (thanks to Gemini 1.5 Pro) generated the query I needed.