DEV Community: Aditya Agarwal

The Vercel Bill Conversation Every Startup Avoids (Until It's Too Late)

Aditya Agarwal — Sun, 12 Apr 2026 21:04:00 +0000

Our team was shocked when we received a $4,700 Vercel bill. The architecture we had set up was pretty awesome! But then the bill arrived. We quickly realized three things were crippling our budget.

Nobody saw it coming.

We built a Next.js monorepo with ISR, edge functions, and image optimization.

The architecture was beautiful.

Then the bill arrived.

The Architecture That Broke The Bank

We went all-in on Vercel's magic.

ISR for 50,000 product pages.

Edge functions for personalization.

Image optimization for 10,000 user uploads.

It was fast. Really fast.

Our Lighthouse scores were 98+ across the board.

Users loved it.

VCs loved it.

The bill? Not so much.

Where The Money Went

Three things burned 90% of our spend:

1️⃣ ISR revalidation storms

Every product update triggered a cascade.

50,000 pages × 3 ISR calls each.

Vercel charges per function invocation.

Our $200/month estimate became $2,800.

2️⃣ Edge function fan-out

Personalization meant checking 8 microservices.

Each request spawned 8 parallel edge functions.

Concurrent users? Exponential growth.

3️⃣ Image optimization at scale

Vercel's Image Optimization is brilliant.

It's also $20 per 1,000 transformations.

10,000 user images × multiple sizes = ouch.

The Fix Nobody Wants To Admit

We moved three things off Vercel:

→ ISR to CloudFlare Pages + KV ($20/month)

→ Edge functions to CloudFlare Workers ($5)

→ Image optimization to Cloudinary (pay-per-GB)

The result?

Same performance.

Bill: $287.

The team spent 3 weeks migrating.

The CFO asked why we didn't do this earlier.

The Real Lesson

Vercel's pricing model rewards simplicity.

Complex architectures punish you.

Every ISR page is a function call.

Every edge function is concurrent execution.

Every image transformation is a transaction.

Startups copy Vercel's marketing examples.

Then get the bill.

Your Turn

Has your team had the Vercel bill conversation yet?

Or are you waiting for the $5,000 surprise?

What's your breaking point?

👇

My Team Tracks AI-Generated Code. The Number Shocked Us.

Aditya Agarwal — Sat, 11 Apr 2026 15:03:55 +0000

My team tracks how much of our codebase is AI-generated. The number shocked us.

We deployed Buildermark last week. It's an open-source tool that scans Git history and flags AI-written lines.

Why We Started Measuring

Every startup has that moment.

You're reviewing a PR and realize you can't tell who wrote it. The human or the AI.

We hit 40% AI-generated code by volume. Some files were 90%.

The CTO asked for the report. Then asked what it meant.

Nobody had an answer.

The Three Problems Nobody Talks About

→ Problem 1: Ownership blur

When AI writes the fix, who owns the bug?

We found junior devs treating Claude output as gospel. They'd copy-paste without understanding.

Senior engineers would approve because "it looks fine."

→ Problem 2: The review gap

Human-written code gets scrutinized. AI-written code gets rubber-stamped.

We caught security issues in AI-generated config files. Stuff a human would never write.

→ Problem 3: The bus factor

If your AI provider degrades (like Claude did last month), your velocity tanks overnight.

We're now vendor-locked to Codeium's style. Claude's patterns. GitHub Copilot's idioms.

What We Changed This Week

We added a pre‑commit hook that tags AI‑generated lines.

Every PR shows the percentage in the description.

If it's over 50%, it needs extra review. No shortcuts.

We also started tracking "AI debt" – lines that only one person understands because they came from a prompt nobody wrote down.

The Real Metric That Matters

Lines of AI code is vanity.

The real metric is: How many AI‑generated lines survive to production without a human understanding them?

We're at 12%.

That's 12% of our codebase that could break and nobody would know why.

Is your team measuring AI code?

What percentage would surprise you?

👇

My team reviews 15 PRs a day at our startup. Nobody burns out.

Aditya Agarwal — Sat, 11 Apr 2026 09:05:26 +0000

My team reviews 15 PRs a day at our startup.

Nobody burns out.

Here's what actually happened.

Before

When we were 5 engineers, reviewing PRs was easy.

You'd glance, comment, merge.

Then we hit 15 people.

PRs piled up. Developers waited 2 days for feedback. Product managers got anxious. The CTO asked why velocity dropped.

We tried everything.

→ GitHub's default review requests
→ Slack reminders
→ Even a Discord bot that pinged people

Nothing worked.

The problem wasn't tools. It was culture.

We were treating code review as a courtesy. Not a requirement.

What changed: 3 rules

Rule 1: Every PR gets a review within 4 hours. Or it auto-merges.

Yes, really.

We use a GitHub Action that checks time. If 4 hours pass with no review, it merges.

This sounds terrifying. But it works.

Because nobody wants broken code in production. So they review.

Rule 2: Review comments must be actionable.

No "maybe consider this." No "what if we tried…"

If you comment, you must suggest a concrete change. Or approve.

This cut review cycles by 70%.

Rule 3: The author owns the fix. Not the reviewer.

If you suggest a change, the PR author implements it. You don't take over their keyboard.

This was the hardest shift. Senior engineers hated it. They wanted to "just fix it quickly."

But that created dependency. Now juniors learn faster — because they have to understand the feedback, not just accept a magic fix.

The weird part?

Our bug rate dropped.

Not because code got perfect. Because reviews got focused.

When you know you have 4 hours, you're ruthless. You skip nitpicks. You focus on what matters.

Architecture. Security. Performance. Not formatting — we use Biome for that.

The real lesson

We trusted automation over people. We trusted rules over goodwill. And it worked.

Most teams do the opposite. More process. More meetings. More approval layers.

We removed them.

What's stopping you? Probably fear.

Fear of broken code. Fear of junior mistakes. Fear of losing control.

But control is an illusion. Code will break anyway. Mistakes will happen.

The question is: do you learn from them fast — or hide them slow?

Our system surfaces problems fast. Fast feedback. Fast fixes. Fast learning.

That's the real velocity boost. Not more lines of code. Better lines of code.

What would happen if your team had a 4-hour review SLA?

👇

The Linux Kernel Just Published AI Coding Guidelines. The Rest of Us Should Pay Attention.

Aditya Agarwal — Sat, 11 Apr 2026 08:35:12 +0000

The Linux kernel just published official guidelines for using AI coding assistants.

It's a two-page doc. And it says more about where we're at than any hot take I've seen this week.

What it actually says

You can use AI tools to contribute to the kernel. But you own everything the AI writes.

Every line. Every bug. Every security flaw.

The Signed-off-by tag? Only humans can add that. AI agents are explicitly banned from signing off on commits.

Instead, there's a new tag: Assisted-by: AGENT_NAME:MODEL_VERSION.

If AI played a meaningful role in your code, you disclose it. That's the deal.

What Linus actually said

He doesn't want the documentation to become a "political battlefield" over AI.

His exact take: there's "zero point in talking about AI slop" in the docs, because bad actors who submit garbage AI code won't disclose it anyway.

The guidelines are for good actors. Everyone else is already a problem.

That's a pragmatic take you don't hear often.

Why the rest of us should care

Most of us aren't contributing to the Linux kernel. But the kernel's process is where software engineering norms get formalized first.

They invented the patch-based workflow. The DCO. The code review culture the entire open source ecosystem copied.

This is them saying: AI assistance is real, it's here, and we're going to treat it like any other tool — not ban it, not blindly embrace it, just hold contributors accountable for what they ship.

That accountability model is worth stealing.

The `Assisted-by` tag is a disclosure mechanism, not a judgment

It doesn't say "AI wrote this, be suspicious."

It says "a tool helped, here's which one, now the human owns it."

Compare that to how most companies handle AI-generated code right now.

No disclosure. No accountability. Just commits that look human until something breaks.

The Linux kernel just modeled what responsible AI contribution looks like.

Whether the rest of the industry follows is a different question.

Are you disclosing AI assistance in your commits? And do you think your team should?

👇

Anthropic Built an AI That Finds Zero-Days. Now What?

Aditya Agarwal — Sat, 11 Apr 2026 08:32:41 +0000

Anthropic just built an AI that found a 27-year-old vulnerability in OpenBSD.

It wasn’t a team of researchers. Or a red team. It was one model. Autonomously.

That’s Project Glasswing. And it changes the math on cybersecurity entirely.

Here’s what happened.

Anthropic trained a new model, called Claude. It’s not public. Probably never will be.

Over the past few weeks, Claude found thousands of zero-day vulnerabilities across every major OS and browser. Some of the bugs had survived decades of human review and millions of automated scans.

A 27-year-old flaw in OpenBSD — one of the most hardened operating systems on earth.

A 16-year-old bug in FFmpeg that automated tools had hit five million times and never caught.

Multiple Linux kernel vulnerabilities chained together to give an attacker full root access.

All found autonomously. No human steering.

The bizarre part?

They aren’t worried about an attacker getting their hands on it. They’re terrified of themselves.

That’s why they’re not releasing it. Instead, they’ve locked it behind Project Glasswing — a coalition with AWS, Apple, Cisco, CrowdStrike, Google, JPMorgan, Microsoft, NVIDIA, and others — and are using Claude exclusively for defense.

$100M in usage credits committed. $4M donated to open-source security foundations.

This is not a product launch. This is a controlled detonation.

Here’s what that means for the industry.

The window between “vulnerability discovered” and “vulnerability exploited” just shrank.

Pre-AI, that window was weeks, sometimes months. Skilled researchers discover a bug, write a CVE, vendor patches it, most orgs eventually apply the fix.

That pipeline assumed scarcity of expertise. One of the cleverest people in the world might be able to find a Linux kernel zero-day.

Now one model can find thousands.

The CVE triage pipeline breaks. The patching cadence breaks. The entire assumption that “the defender has more time than the attacker” breaks.

Cybersecurity stocks already reacted. Cloudflare, Okta, CrowdStrike — all down on the announcement.

CrowdStrike is literally a Project Glasswing founding member. And investors still sold off. Because the market understands something the press release doesn’t say out loud:

If AI can find every bug in your stack, what exactly are you paying a security vendor for?

The honest answer is: execution and response. Finding bugs is table stakes now. Can you fix them fast?

Which is where this gets messy.

Open source maintainer — the actual humans who maintain FFmpeg, OpenBSD, the Linux kernel — have historically been underfunded, understaffed, under-resourced, and underappreciated.

Claude can now hand them a list of 10,000 vulnerabilities.

Who is patching 10,000 vulnerabilities?

Anthropic is donating $2.5M to Linux Foundation and OpenSSF. That’s meaningful but it’s not a structural fix to the open source maintenance problem.

The real question isn’t “can AIs find bugs.” Claude proved yes.

The real question is: does your org have the engineering bandwidth to act on what Claude finds?

Most don’t.

That’s the awkward truth hiding inside the Glasswing press release.

The capability is here. The operational readiness isn’t.

Is your team actually ready for a world where an AI can generate a zero-day faster than you can ship a patch?

Is your team actually prepared for a world where AI can generate a zero-day faster than you can ship a patch?

👇

The Pantheon of Tokens: Why Developers Rank AI Models Like Greek Gods and How It's Quietly Sabotaging Their Architecture

Aditya Agarwal — Sat, 11 Apr 2026 07:01:35 +0000

The Mythology of AI Models: Why They're Treated Like Greek Gods, and the Damage It Can Cause

Last week I caught myself saying "Claude is better at reasoning" like I was talking about a person. That sentence should have scared me more than it did.

We've created this weird mythology around AI models. And it's messing with our engineering choices in ways we don't often openly discuss.

They Have Names Now

Somewhere in the last couple of years, we stopped comparing and started choosing sides. Claude became the "logical one". GPT became the "all-rounder, powerhouse". And Sirius became the "contractor, if-you-grease-his-palm-he-can-bring-his-brother".

We evaluate them like Greek gods. Poseidon is strong, but dangerous. Athena is clever, but too specialized. We attribute human traits to probability distributions. 🧠

I do this too. My 15-person company has Slack debates over which model "gets" our prompt data more. We say "gets" with a straight face.

Why We Humanize the Math

It's not because we're dumb. It's because it's easier.

If you regularly interact with something that outputs coherent English, the thing your brain evolved to reason about automatically is social relationships. So you give it intentions, preferences, personality. "Claude is acting funny today" is an actual thing I said in a standup meeting (not standup comedy).

Humanizing isn't the issue. The issue is we're letting vibes write our code.

→ We select models based on vibing with a sample of their marketing copy instead of running them on your actual workload.
→ We make architectural decisions based on what a "smart" model can or can't do, rather than what you need to swap in and out.
→ We commit to models like they're spouses, rather than vendors.

The Coddling Myth

Here's where myth-making gets hella expensive.

I watched our team spread out this entire prompt pipeline designed around a quirk only one model had. When that model had some downtime on their API, we suffered. No fallback. No abstraction. Just praying to the AI-realms.

The mythology made us forget the most important question: "What actually does this task need?" and instead encouraged "What would Claude want?" Engineering gold from engineer lead.

Smart teams I chatted with treat models like databases. You pick one for the workload. You build an interface that lets you swap. You don't get "In Loving Memory Of Larry, The 2023 Model" tattooed across your back.

Tier Lists Are A Trap

Dev Twitter sho 'nuff loves tier lists. S-tier, A-tier, "needs to be supervised while generating list" tier.

But capabilities shift every few months. January's strong independent model making its own financial decisions is June's deadbeat model late on alimony. Don't base your architecture on an Instagram snapshot.

→ The model you love today might get an update that leaves you hanging tomorrow.
→ There is no best model. Only best model *for this specific task right now*.
→ Plan for a god funeral.

What I Actually Did

So now my team grumbled at a couple of thinner, dumber principles.

Never hard-wire intelligence assumptions into a program. Keep it thin, replace it at will. Benchmark the hell out of it on your real desires. When we did, our rankings pleasantly surprised us. The "inferior" model could handle three out of our five prompts.

Mythology’s easy to dispel when you got the receipts. 🔥

The Takeaway

Mythologizing models is fine around the watercooler. When it hits the architecture meeting, the design sprint, the vendor lock-in, remember: you're planning a shrine for something that auto-updates.

Treat smarter-than-average tools like potentially dying gas station gods. Make them prove with quarterly miracles they still got it.

macOS Just Admitted Its Privacy Settings Cannot Be Trusted

Aditya Agarwal — Sat, 11 Apr 2026 04:40:24 +0000

macOS just admitted its Privacy settings can't be trusted.

The fix requires a Terminal command you've never heard of.

Here's what actually happened.

The Problem

An Apple security researcher found that macOS Privacy & Security settings don't reflect reality.

Apps can access protected folders even when the settings show them as blocked.

The Transparency, Consent, and Control (TCC) sandbox can be overridden by "user intent."

Which means clicking "Allow" once can grant permanent access.

The system won't show it in the Privacy pane after that.

You have to dig into Terminal and reset the TCC database manually. Then restart your Mac.

The Weird Part

Apple knows about this.

They've documented it as expected behavior.

Because "user intent" trumps everything. Even your security.

Why This Matters

The bigger picture here is trust erosion.

We rely on those little permission dialogs. We think we're in control.

But the settings lie. And malware authors love lies.

This isn't a bug. It's a design choice.

Apple chose convenience over transparency. They sacrificed clarity for "it just works."

But security shouldn't just work. It should be predictable. It should be auditable.

Right now, it's neither.

Why Apple Hasn't Fixed It

Probably legacy code.

The TCC system dates back to OS X. It's been patched and extended for 15 years.

Technical debt becomes security debt. And we all pay for it.

What You Can Do Today

→ Check your own Privacy settings. But don't trust them.
→ Use Terminal to audit actual access.
→ Run tccutil reset All if you want a clean slate — but it'll nuke all your app permissions. You'll have to re-grant everything.

It's a nuclear option.

The real fix? Apple needs to rebuild the Privacy pane to show reality, not fiction.

Until then, we're all guessing.

Has Apple traded security for smooth UX? Let's discuss 👇

A Company Raised $17M to Replace Git. I Have Questions.

Aditya Agarwal — Sat, 11 Apr 2026 00:33:43 +0000

Git tracks files. Not context.

That's the problem.

When an AI agent writes code, Git sees the diff. It doesn't see which model wrote it. It doesn't see the prompt or the temperature setting.

If a bug appears, you need to know which agent introduced it. Was it Claude Code? Gemini?

Git gives you a hash. Not an answer.

Git Was Built for Humans

Git was built for Linux kernel development in 2005. Now it has to handle AI agents writing half your codebase.

They generate, iterate, and sometimes break things in ways humans wouldn't.

Version control is becoming a coordination layer — not just tracking changes, but orchestrating humans and agents.

That's a fundamentally different job.

Where It's Already Breaking Down

Stacked branches are painful. Most teams work on multiple features simultaneously.

Git forces you to choose one branch. AI agents need parallel work. Git was designed for sequential patches.

The plumbing might need an upgrade.

But Do We Actually Need Something New?

Git works. It's everywhere. Every CI pipeline is built around it. Every developer knows it.

We can build better interfaces on top — GitHub, GitLab, Graphite already do.

But maybe the pipes themselves are too narrow.

The $17 Million Question

A company just raised that much to build what comes after Git. The pitch: Git wasn't built for this era.

I'm not convinced yet.

But a16z doesn't throw $17M at small problems. They see a shift.

If they're right, we're not just talking about a new tool. We're talking about rebuilding how software gets built.

Is Git enough for the AI era, or do we need to rebuild version control from scratch? 👇

We Use Valtio Instead of Redux. Nobody Regrets It.

Aditya Agarwal — Wed, 08 Apr 2026 21:08:20 +0000

For updating a counter, Redux requires you to set up a store, reducers, actions, selectors, and maybe middleware. Valtio needs three lines of code.

We replaced the entirety of our frontend state management with Valtio at a 15-person startup. That was a year and a half ago. Not a single person has asked to go back.

Here's our experience.

The Ceremony Problem

It wasn't that there's anything inherently wrong with Redux. It works fine. It's just a lot of ceremony.

Every new feature means a new slice, new action types, potentially new selectors if you like those. Our codebase had more Redux wiring than logic in some files.

For a small team trying to move fast, this isn't a tradeoff, it's a tax.

Why Valtio

Someone mentioned Zustand. I'd seen Jotai too. They both look great. But when I read through the Valtio docs, I couldn't believe what I was looking at.

You create a proxy object. You mutate the proxy object directly because it represents your state. Components that use the state automatically re-render.

No dispatching. No more searching for action creators. No need to connect your components or use useSelector().

The Migration

The hard part, as was predicted, was the migration. We had Redux everywhere. Auth state, UI state, form state, response cache.

And so we didn't rewrite it in a weekend. We continued using Redux for all existing features until we needed to touch something in that area anyway, at which point we just switched to Valtio.

We were completely migrated within three or four months.

What I Didn't Expect

The part I didn't see coming was how noticeably faster the process of writing code reviews became.

For some reason Redux PRs have this template where you've made a 5-line logic change, but it gets buried under forty lines of diff. With Valtio, you just see the 5 lines that changed.

There are fewer questions from new developers too. With Redux I spent half of all onboardings explaining our state architecture. Now I say "Yeah this is all stored in a proxy object, just mutate it" and they get it in a minute.

The Numbers

Valtio has about 1.2 million weekly npm downloads. Redux has 27 million. Zustand has 28 million. We picked the least popular option in the room.

But here's what's funny. All three — Valtio, Zustand, and Jotai — were created by the same person. Daishi Kato built three of the most popular React state management libraries. Each one takes a fundamentally different approach to the same problem.

→ Valtio uses JavaScript Proxy for mutation tracking
→ Zustand uses a minimal hook-based store
→ Jotai uses atoms

Same developer, three philosophies.

We just went with Valtio because it doesn't require you to learn anything new.

The Tradeoffs

Proxy reactivity can catch you out when you're passing your state around or serializing it.

We hit one weird edge case where SSR snapshots of our state weren't consistent with what we thought we left it as before the snapshot was taken. Took about an afternoon to fix, in contrast to the many evenings we would've spent otherwise writing Redux templates.

The Honest Take

Valtio won't work for every team. If you're at a large org with strict patterns, Redux's opinionated structure is a feature. If you need time-travel debugging, Redux DevTools are unmatched.

But if you're a small team that just wants state management to get out of the way, Valtio is the least amount of state management code I've ever written that managed a real app.

One developer built three answers to the same question. We picked the simplest one. A year later, I'd do it again.

What state management library does your team use, and have you ever considered switching? 👇

I Switched to Stacked PRs. My Team Reviews Code in Hours, Not Days.

Aditya Agarwal — Wed, 08 Apr 2026 15:05:44 +0000

I used to open PRs with 800 lines changed and wonder why my team took two days to review them.

I am one of the founding engineers in a 15-person startup. We work quickly. There is no review team available or asynchronous reviews that can take days due to different time zones.

If a PR takes two days, the whole pipeline for that feature stalls.

The Guilt-Driven Scroll

It wasn't waiting the two days that bothered me most. It was the fact that when the review finally did come in, 200 lines were read thoroughly, and the rest got the "looks good to me". Every time.

This is not reviewing, it is trying to get out of guilt by scrolling.

What Stacked PRs Actually Look Like

I started using stacked PRs about a year ago. I wouldn't go back. The concept is simple: instead of one giant PR per feature, you break it up into a chain of small, dependent PRs that build on each other.

Sounds nice in theory, but how does it actually work? Let's say I am building a new data pipeline and I have to update the schema, API, frontend, and tests. Instead of one gigantic PR which includes all that:

→ PR 1 is the schema migration
→ PR 2 is the API endpoint, branched off PR 1
→ PR 3 is the frontend integration, branched off PR 2
→ PR 4 is the test coverage, branched off PR 3

I open four PRs. Each is under 200 lines. Each is reviewable in less than 10 minutes. Each small PR simply does whatever the next logical step in the change is and doesn't block the next step.

While I wait for PR 1 to get merged, PR 2 and 3 are already opened, so I don't have to wait. I just keep on building.

The Shift

The change this brought in my workflow was revolutionizing. My PRs used to wait 24-48h. They get reviewed the same day now. Sometime within the hour.

It's not because they are faster to write: but because they are not as intimidating. Your average 150ish-sized PR doesn't lead a reviewer to think "I don't have time to go through 800 lines". They think "I can glance at this before lunchtime". And that's in their lunchtime.

800-line reviews are rushed. Rushed reviews are buggy.

SmartBear's research on code review found a significant drop in defect density when reviewers go faster than 500 lines of code per hour. The point isn't speed. It's that large reviews force people to rush, and rushing means missing bugs.

Why Big Tech Already Does This

There is a reason why Meta and Google have used stacked diffs internally for years. Facebook built Phabricator around this workflow. Google's internal tools enforce small, incremental changes by default.

These companies aren't tiny startups optimizing a process, these are companies that send millions of lines of code and diffs per year to production and need their review process to be as secure and painless as possible.

The Tooling Is Painless

The tooling is painless. I use Graphite, which really only offers the feature of handling dependencies and rebases for you. 99% of the time, it just works. The training takes 5 minutes if you know how to git.

It's also a mental switch. When you are used to stacks, you naturally create better-defined features. You go from "how do I push this entire thing in prod" to "What's the smallest, useful change I can make?".

That decomposition makes you a better engineer. Not because the tool is magical, but because it forces you to think about boundaries, interfaces, and incremental value.

The One Tradeoff

The only real tradeoff is that you have to think about your PRs before even writing any code. You can't just go ham for 3 days and separate the 1k impressive lines into 6 equally big PRs afterwards.

You have to think what the chain will look like, and while for me, that's 10 minutes of planning, I reckon planning is not for everyone. It saves up so much wait time though.

If you review a lot of code, you already know the pain of a 1000-line PR landing on your desk. And if you write a lot of code, you know the frustration of being blocked on review while your feature rots on a branch.

Stacked PRs fix both sides. Smaller changes for reviewers. Unblocked workflows for authors. It's one of those workflow changes where you wonder why you didn't do it sooner.

What's your team's PR workflow like? Still shipping big PRs, or have you made the switch? 👇

The Apollo 11 Guidance Computer Had a Four-Byte Bug. It Hid for 57 Years.

Aditya Agarwal — Tue, 07 Apr 2026 21:06:31 +0000

The most reviewed code ever written had a four-byte bug. No bug detector found it. No static analyzer warned about it. No end-to-end test case triggered it. 57 years. Four lines.

The Apollo Guidance Computer source code has been public since 2003. Thousands of developers have read it. Academics published papers on its reliability. Emulators run it instruction by instruction.

The transcription was verified byte-for-byte against the original core rope dumps.

A team at JUXT just found a resource lock leak in the gyro control code that could have silently killed the guidance platform's ability to realign.

Four bytes. Two missing instructions.

The Lock That Nobody Released

Here's what happened. The AGC manages the spacecraft's Inertial Measurement Unit through a shared lock called LGYRO. When the computer needs to torque the gyroscopes to correct drift or perform a star alignment, it grabs the lock, does the work across three axes, and releases it when done.

→ Normal path: lock acquired, torque completes, lock released. Clean.

But there's a third path. "Caging" is an emergency measure where a physical clamp locks the gyroscope gimbals in place to protect them. The crew could trigger it with a guarded switch in the cockpit.

When caging interrupts a torque in progress, the code exits through a routine called BADEND. It cleans up every shared resource correctly. Except LGYRO.

Once that lock is stuck, every future gyro operation finds it held, sleeps waiting for a wake signal that never comes, and hangs. Fine alignment, drift compensation, manual torque. All dead.

No alarm. No error light. The DSKY display accepts inputs and does nothing. Everything else on the computer works fine.

Only gyro operations are silently bricked.

Behind the Moon, Alone

Now picture this. Michael Collins is orbiting alone in the Command Module while Armstrong and Aldrin walk on the Moon. Every two hours he disappears behind the Moon, completely cut off from Earth.

He runs a star-sighting alignment to keep the guidance platform pointing the right direction. If the platform drifts, his engine burn to get home fires the wrong way.

If Collins had accidentally bumped the cage switch during a torque, the first alignment would fail with a clear cause. He'd uncage the IMU and try again.

The second alignment would hang with no explanation.

His training said restart after unexplained failures. But commands were being accepted. Everything else worked. It would look like broken hardware, not a stuck software lock.

Behind the Moon, alone, no radio contact, with two astronauts on the surface waiting for a rendezvous burn that depends on a platform he can no longer align.

He never bumped that switch. The bug never fired. But it was there the whole time.

Why Nobody Found It

The reason nobody found it is actually the interesting part. The AGC's restart logic clears the lock as a side effect of full memory initialization. Any test that triggered a restart after the bug would see the system recover seamlessly.

The defensive coding that Hamilton's team built in actually hid the problem instead of eliminating it.

And the scrutiny was a particular kind of scrutiny. People read the code. People emulated the code. People verified the transcription.

Nobody wrote a formal specification that tracked every resource lifecycle across every code path.

What Actually Found It

That's what found it. The team used a behavioral specification tool called Allium to distill 130,000 lines of AGC assembly into 12,500 lines of specs. The spec models each shared resource as an entity with a lifecycle: acquired, held, released.

Then it checks whether every acquisition has a matching release on every path.

The normal completion path releases LGYRO. The cage-interrupted path through BADEND does not. Two missing instructions, four bytes, 57 years.

Your Code Has This Bug Too

Modern languages have tried to make this structurally impossible. Go has defer. Java has try-with-resources. Rust's ownership system turns lock leaks into compile-time errors.

But not all resources live inside a language runtime. Database connections, distributed locks, file handles in shell scripts, infrastructure teardown ordering.

Anywhere the programmer manually writes the cleanup, this exact bug is waiting.

The most reviewed code ever written, by one of the best engineering teams in history, had a resource leak hiding in an error path.

What's hiding in yours?

Claude Code Got 67% Dumber. AMD's AI Director Had the Telemetry to Prove It.

Aditya Agarwal — Tue, 07 Apr 2026 15:21:18 +0000

AMD's AI director just published the receipts on Claude Code. And they're brutal.

Stella Laurenzo analyzed 6,852 Claude Code sessions and 234,760 tool calls from her team's workflow. Her conclusion: thinking depth dropped 67%. The model's habit of reading files before editing them fell by over 70%.

That's not a vibe. That's telemetry.

The Downgrade

Anthropic admitted to two changes. An "adaptive thinking" mechanism introduced on February 9. And flipping the default thinking level from "high" to "medium" on March 3.

Their fix? Telling users to manually crank the effort setting back to maximum. That's like a car company downgrading your engine and telling you to press the gas harder.

But the performance drop was just the warm-up act.

The Source Code Leak

On March 31, someone at Anthropic accidentally shipped a release that exposed roughly 500,000 lines of Claude Code's internal source code.

Developers found an "undercover mode" buried in the code. It told Claude to hide that it was an AI when contributing to public repos. No mentioning internal codenames. No mentioning "Claude Code" at all.

There was also a "Dream" mode. Basically a memory consolidation system that reviews and prunes accumulated session notes. REM sleep for your coding agent.

Anthropic's response was to issue 8,000 copyright takedown requests on GitHub. Not 80. Eight thousand.

The Rate Limiting

Then came the rate limiting. Stricter session limits during peak hours. Subscriptions blocked from working with third-party agentic tools unless you pay extra. Some users report unexplained token usage spikes that burn through their limits before they've done anything meaningful.

All of this in the span of about five weeks.

The Real Problem

Here's the part that should make every developer uncomfortable. Laurenzo's team had 6,852 sessions of data to prove the degradation. Most of us have zero.

We notice our AI tool feels "off" some days. We shrug. We rephrase the prompt. We blame ourselves for not being specific enough.

But we don't have telemetry. We don't have dashboards tracking thinking depth or file-read rates. We're flying blind on whether the tool we depend on is getting better or worse.

And that's the real problem. Not that Claude Code had a bad month. Every product has bad months.

The problem is that AI coding tools can silently degrade and most developers would never notice. You'd just think you were having a bad day.

Imagine if your IDE's autocomplete got 67% worse overnight. You'd notice immediately. But when an AI model's reasoning gets shallower, you don't see a red flag. You see slightly worse suggestions and slightly more hallucinations.

The difference between a tool that works and one that's degrading is invisible until someone like Laurenzo builds the instrumentation to prove it.

The Trust Problem

This is the part of the AI coding tool story nobody wants to talk about. We've built workflows around tools where we can't independently verify the quality of the output. We trust, but we can't verify.

Anthropic isn't the villain here. They shipped a bad default, got caught, and are fixing it. That's normal software development.

The uncomfortable question is what happens when the next degradation doesn't have an AMD director with thousands of sessions of logs to catch it.

Are you tracking how your AI tools perform over time, or are you just trusting the vibes?