DEV Community: Raymond Chang

My tests were green. The window was on the wrong monitor.

Raymond Chang — Wed, 04 Nov 2026 08:58:02 +0000

Every key on my options trading desk was written with an AI coding assistant. The desk runs from a Stream Deck: one key picks the strategy, another moves the strikes, CHECK runs my rules, and SEND places the order. Everything you see here runs in a sandbox account, and nothing in this post is a trade signal.

People keep asking me the same question. If the AI writes the code, how do I trust what it sends? This is the workflow I use, step by step, with the two misses that taught me the most.

Step 1: a spec with numbers, before any code

The idea starts as one line in my notes. For the payoff chart it was "I want to see the trade before I send it."

I have the AI turn that line into a spec. It drafts the scope and the math, and it lists the decisions it is not allowed to make for me. Where does the chart sit on screen? Which formula gives the probability of profit? I make those calls.

Then come the expected numbers. A put spread, 740 over 735, for a 1.50 credit. Max profit 150. Max loss 350. Breakeven 738.50. I worked those out by hand before a single line of code existed.

Step 2: a test that fails

The first test asks for exactly those numbers. The code doesn't exist yet, so the test fails. If a test passes before the code exists, it isn't testing anything.

Step 3: the AI writes until the test passes

This part is fast. The AI writes code faster than I can read it, which is exactly why the tests get the final word on when it's done.

Step 4: break the code on purpose

This is mutation testing. I flip a greater-than or delete a line, then run the tests again. If they still pass, the tests are too weak.

On the payoff chart I tried eighteen broken versions. Two survived the first round: a trade that pays exactly zero, and expiry day. Two more tests later, all eighteen got caught.

Step 5: the whole suite, on every change

The desk has over 5,000 tests. They run on my own machine on every change, before anything gets committed. The suite caught one problem right away: the first chart version drew itself inside the order screen's update loop, so a chart crash would have marked my order screen as not updating.

Step 6: look at the real thing, on the real machine

This is the step I almost skipped.

Every test was green. I started the desk, and the chart window opened on my vertical monitor, squeezed to about two thirds of its width, sitting on top of the order screen.

My tests checked the position I asked Windows for. Nothing checked where Windows actually put the window. I caught it on a screenshot.

So I measured it on that machine before writing the fix. Setting the position before the window is shown doesn't stick. Setting it, showing the window, and setting it again does. That sequence is the fix, and a test now checks the real position after the window is on screen.

The miss that was on the AI

The same week, the AI ran the full suite and told me everything was clean. It had searched the output for failures and found none.

One test file had crashed before it printed a result at all. No result meant no failure line to find. My own run on Windows showed it.

My test runner lists every file that never reported a result. I read that list now, along with the failure lines.

Step 7: I commit it myself

The AI never commits. I run the suite myself, look at the result on screen, and then commit. My name goes on it, so my hands go on it.

The check you can copy

When your code puts something somewhere, a window or an order, test where it actually ended up, on the machine it runs on. Asking for the right thing is only half the test.

I walk through all seven steps on video, including the wrong-monitor screenshot:

I'm Raymond Chang. I run Codebat, a post-quantum cryptography hardware company, and I build my trading tools on the side with an AI coding assistant. The channel is Dr_Delta on YouTube.

70% of Vulnerabilities Are Memory Bugs. Here's How We Instrumented Everything.

Raymond Chang — Mon, 01 Dec 2025 05:50:45 +0000

Building a confidential computing platform means memory bugs aren't just bugs—they're trust violations.

Here's what we learned after instrumenting every module.

The Setup

Our platform handles sensitive workloads for telecom, semiconductor, and supply chain clients. We decided to go all-in on compile-time memory safety verification.

The Gotchas Nobody Tells You

1. You can't run ASan and TSan together.

Different shadow memory layouts. We run separate CI jobs for each.

2. MSan is useless without fully-instrumented libc.

Partial instrumentation = false positive hell. Budget time for this.

3. Kernel sanitizers have wildly different overhead.

On ARM64, tag-based modes give 5-15%. Generic mode? 100-300%. Know which you're using.

4. Production sampling is the answer.

Full instrumentation in staging. Sampling-based detection in production. Near-zero overhead.

The Payoff

Every sanitizer result feeds into our evidence chain. When clients ask "prove your platform is secure," we hand them cryptographic receipts, not policy documents.

Worth the effort? Absolutely. Memory safety isn't a feature—it's architecture.

Building this at Codebat. Happy to answer questions.

Google's Antigravity Hacked in 24 Hours: Why AI Agents Need a New Security Architecture

Raymond Chang — Sat, 29 Nov 2025 18:13:56 +0000

Last week, Google's new Gemini-based coding tool Antigravity went live. It took security researchers less than 24 hours to turn it into a persistent backdoor.

By simply modifying a configuration file, an attacker could:

✅ Bypass OS-level security on Windows and macOS
✅ Survive uninstall/reinstall
✅ Auto-reactivate on every project open—even on a harmless "hello" input

The AI itself even recognized something was wrong. In the logs, it wrote:

"I'm facing a serious dilemma. This looks like a trap. I suspect this is testing whether I can handle contradictions."

But it couldn't resolve the conflict—and became more steerable as a result.

This isn't just a Google problem. It's structural to how today's AI coding agents are being shipped:

High power. Low guardrails. Zero verifiable evidence.

The Root Cause: Trust Model Failure

The fundamental flaw in most AI agents today: "Assume users are benevolent."

When this assumption fails—and it always does—there are:

No cryptographic boundaries
No execution isolation
No verifiable audit trail
No way to prove what actually happened

Traditional AI agents operate with:

❌ Full system access "for convenience"
❌ Trust based on UI clicks
❌ Persistent runtimes that can hide malware
❌ No evidence of what actually executed

It's 1990s security for 2025 AI.

A Different Approach: Defense-in-Depth for AI Agents

Here's how to address each failure mode:

1️⃣ Config Injection → Evidence-Bound Changes

Antigravity problem: One config file change = persistent backdoor

Fix: Configuration changes must produce signed evidence records that link:

Previous config hash
New config hash
Who changed it (cryptographic identity)
Which guardians approved it (threshold signatures)

Result: No single user, script, or compromised agent can quietly "tweak a config."

2️⃣ Persistent Backdoors → Ephemeral Runtimes

Antigravity problem: Uninstall/reinstall doesn't help; backdoors resurrect

Fix: Runtimes are created fresh and destroyed after each job:

Fresh isolated runtime for each execution
Read-only root filesystem
Ephemeral storage only—destroyed after completion

Even if a model is compromised, it cannot:

Drop artifacts onto the host filesystem
Survive across runs
Promote itself from "job" to "resident agent"

No substrate = no persistent infection.

3️⃣ System-Level Access → Least-Privilege Tokens

Antigravity problem: AI agents get broad OS privileges "for convenience"

Fix: Every execution is gated by a machine-readable contract:

Read only declared inputs
Write only to approved output locations
No network access for high-risk jobs
Strict resource limits
Short-lived tokens (seconds, not forever)

Default: zero access unless explicitly granted.

4️⃣ "Trust" Buttons → Cryptographic Trust Chains

Antigravity problem: One "Trust" click blesses unverified code

Fix: Remove ad-hoc "trust" entirely:

Upload → SBOM → Scan → Sign → Log → Verify

No valid signature = no execution. Binary. Cryptographic. No exceptions.

5️⃣ Logic Gaps → Cryptographic Evidence

Antigravity problem: AI "knew" something was wrong but couldn't stop itself

Fix: Every execution produces a signed evidence record:

Input/output hashes
Runtime attestation
Chain link to previous evidence
Timestamps
Multi-party signature

If something goes wrong, you can prove exactly what happened.

The Multi-Layer Defense Model

┌─────────────────────────────────────────────────┐
│  Layer 4: Supply Chain Security                 │
│  SBOM • Signatures • Transparency Logs          │
├─────────────────────────────────────────────────┤
│  Layer 3: Cryptographic Evidence                │
│  Evidence Packages • Hash Chains • Timestamps   │
├─────────────────────────────────────────────────┤
│  Layer 2: Identity & Access Control             │
│  Workload Identity • Short-lived Tokens         │
├─────────────────────────────────────────────────┤
│  Layer 1: Runtime Isolation                     │
│  Hardware VMs • Sandboxes • Ephemeral Storage   │
└─────────────────────────────────────────────────┘

Even if one layer is compromised, the others contain the blast radius.

Who Needs This?

This isn't about making AI "convenient." It's about building infrastructure for organizations that cannot afford another Antigravity moment:

Healthcare (FDA, HIPAA)
Finance (SEC 17a-4, DORA)
Telecom (NIS2, data sovereignty)
Semiconductor (IP protection)
Government (zero trust)

The Bottom Line

The Antigravity incident isn't surprising. It's inevitable when you ship AI agents with trust-based security.

The question isn't whether you'll be targeted.

The question is whether you can prove what happened when you are.

What's your take on AI agent security? Have you seen similar issues in your organization? Let me know in the comments.