DEV Community: Aditya Agarwal

Cloudflare and GitHub are building identity systems for AI agents. We're not ready for this.

Aditya Agarwal — Sun, 19 Apr 2026 13:19:44 +0000

AI agents are getting their own credentials and nobody is asking who's accountable when they leak. That sentence should terrify you more than it does.

I've been managing secrets at a 15-person startup for a few years now. We can barely keep human API keys out of Git history. The idea of every AI agent running around with its own identity makes me want to close my laptop and go farm goats.

But here we are.

What Actually Happened

Cloudflare just launched a new scannable API token format with prefixes like cfat_. This is smart — it means tokens are instantly recognizable by pattern-matching tools. GitHub Secret Scanning can detect leaked Cloudflare tokens when they show up in a commit, though the revocation process may require manual remediation rather than being fully automatic.

That's genuinely good engineering. Two major platforms cooperating to shrink the window between "oops" and "revoked." I respect it.

But zoom out for a second. Why does this need to exist at all?

The Real Problem Nobody Wants to Say Out Loud

Non-human identities already outnumber human ones in most organizations. Read that again. Service accounts, CI/CD tokens, bot credentials, API keys — they've been quietly multiplying for years. Now add AI agents to the pile.

Each agent requires credentials to do anything useful. Call an API. Read a database. Deploy a service. Each one becomes a new secret to rotate, scope, monitor, and eventually lose track of.

Here's what I've seen firsthand:

→ Secrets get copy-pasted into .env files that end up in repos
→ Service accounts get created for a "quick test" and never get deleted
→ Nobody owns the rotation schedule because nobody owns the bot
→ When something leaks, the first question is always "wait, what even uses this?"

That's the state of things today. With humans mostly in the loop. 🫠

AI Agents Make This Exponentially Worse

When a human leaks a key, you yell at the human. You do a postmortem. You add a pre-commit hook. There's a feedback loop.

When an AI agent leaks a key — or gets prompt-injected into exposing one — who's accountable? The developer who deployed it? The platform that hosted it? The agent framework that didn't sandbox credentials properly?

Nobody has a good answer yet. And startups are already shipping agents with broad API access because speed wins over security every single time at that stage. I know because I've been that person choosing speed.

The Cloudflare + GitHub integration is a safety net. But safety nets work best when you're not actively trying to juggle chainsaws on a tightrope. At startup scale, with a two-person platform team, you're absolutely juggling chainsaws.

What I Think We Should Be Doing

I don't have a complete answer. But I have opinions:

→ Agents should get short-lived credentials by default. Not long-lived API keys. Tokens that expire in minutes, not months.
→ Every non-human identity needs an owner. A real human on the hook. No orphan service accounts.
→ Scope should be laughably narrow. If an agent only needs to read from one endpoint, it gets access to one endpoint. Period.
→ Audit logs for agent actions should be first-class. Not an afterthought bolted on after the first incident.

The cfat_ prefix and auto-revocation are steps in the right direction. But they're band-aids on a wound we haven't even fully discovered yet. 🩹

Here's the Thing

We built identity management for humans over decades and we're still bad at it. Now we're handing credentials to autonomous software that can act at machine speed, make unpredictable decisions, and get tricked by a well-crafted prompt.

The infrastructure isn't ready. The policies aren't ready. The org charts definitely aren't ready. And yet the agents are already shipping.

I'm not saying stop building agents. I'm saying treat agent identity as a first-class security problem right now, not after the first big breach makes it obvious.

So here's my question: who owns non-human identity at your company? Is it security? Platform? DevOps? Or is it the terrifying answer — nobody? 🔐

Cloudflare wants agents to write and deploy their own code. That should terrify you.

Aditya Agarwal — Sun, 19 Apr 2026 10:13:47 +0000

We're giving AI agents access to production infrastructure and behaving as if we're simply releasing a new feature. I need to talk about this.

Recently, Cloudflare introduced a set of tools that allow AI agents to write code, run it, and deploy it - all on their own. There's no human involved in the process. They just announced this and the developer community seems... excited? 🤔

Why This Is Different

We have been using AI code helpers for some time now. Copilot recommends a line of code. ChatGPT writes a function. You then inspect it, test it, and deploy it on your own.

This is different. Here, the agent not only writes the code but also runs it on the production server. You are not the pilot here, you are more like a passenger who might check the flight path through the window sometimes.

What Cloudflare Actually Built

So, using these Cloudflare tools:

→ Project Think — long-running stateful AI agents that persist across sessions and maintain context over time. Not a one-shot prompt-response. A thinking entity that remembers what it's doing.

→ Dynamic Workers — AI-generated code gets executed inside sandboxed isolates. The agent writes something, and it runs. In Cloudflare's infrastructure. At the edge.

→ Codemode — instead of making individual sequential tool calls, models are encouraged to write and run code that orchestrates those predefined tools as their primary way of interacting with the world. The agent doesn't pick items from the menu one at a time. It writes a script that combines them.

Each component individually? Neat engineering. All three together? That's an autopilot deployment pipeline for inanimate software agents.

The Sandboxing Argument Doesn't Comfort Me

I can already hear the arguments: "It's all compartmentalized! Isolates are secure!"

Of course. Sandboxes are useful until they're no longer effective. Throughout the history of computing, every sandbox has been evaded, circumvented, or incorrectly configured by an exhausted engineer at 2am.

Even assuming the sandbox remains intact forever — that's not the real problem. I'm worried about what the agent decides to deploy in the first place. A sandboxed isolate that runs horrendous business logic is still horrendous business logic. It's just isolated horrendous business logic. 💀

We're Normalizing Without Discussing

What bugs me isn't the technology itself. It's how casual we are about "AI writes and ships its own code" this quickly.

We sorted deployment guardrails for decades. Code review. Staging environments. Feature flags. Canary releases. All because humans make mistakes when shipping code.

And now we're skipping most of that for a system that hallucinates confidently, calling it "developer productivity."

I'm not anti-AI. I use AI tools daily. But there's a meaningful difference between "AI helps me write code faster" and "AI writes and deploys code without me." We're blurring that line and pretending it's fine.

Where This Goes

I think we end up in one of two places:

→ Agents get real guardrails — approval workflows, automated testing gates, human checkpoints — and this becomes genuinely useful infrastructure.

→ Or we speedrun past the safety conversations because shipping fast feels too good, and we learn the hard way why those deployment ceremonies existed.

Right now, the industry seems to be sprinting toward option two. 🚀

The tooling is impressive. Cloudflare's engineering here is legitimately clever. But clever infrastructure serving an unexamined workflow is how you get elegant disasters.

Here's my question for you: At what point does "AI-assisted development" become "AI-autonomous development," and who should be drawing that line — platform providers, engineering teams, or regulators?

Most webhook security guides protect the wrong side. The scary part is delivery.

Aditya Agarwal — Sat, 18 Apr 2026 19:09:42 +0000

Everyone secures webhook ingestion. Almost nobody talks about SSRF via the delivery worker.

I've been staring at webhook architectures for years, and the security conversation is almost always backwards. We obsess over verifying inbound payloads while leaving the outbound side wide open.

Why Your HMAC Doesn't Save You Here

HMAC verification only protects ingestion, not outbound delivery to tenant URLs. That signature proves the payload came from who it claims. Great.

But your delivery worker — the thing that POSTs events to customer-provided URLs — has a completely different threat model. HMAC doesn't even enter the picture on that side.

Think about it. A tenant registers https://totally-legit-domain.com/webhook as their endpoint. You validate the URL looks fine. You maybe even check it doesn't resolve to a private IP. Then you move on with your life.

DNS Rebinding: The Actual Scary Part

Here's where it gets ugly. DNS rebinding can redirect webhook deliveries to internal IPs like 169.254.169.254.

The attack works like this:

→ Tenant registers a domain they control
→ At registration time, it resolves to a perfectly normal public IP
→ Your validation passes
→ Later, the DNS record flips to 169.254.169.254 (the cloud metadata endpoint)
→ Your delivery worker happily POSTs to it, potentially leaking cloud credentials

Your worker just became a proxy into your own infrastructure. The tenant didn't hack anything. They just gave you a URL and waited. 🎯

This isn't theoretical. Cloud metadata endpoints are the crown jewels. One leaked IAM credential from that 169.254 address and it's game over.

Validate at Delivery Time, Every Time

Private IP blocklists must be checked at delivery time, not just registration time. I can't stress this enough.

Checking the URL once when the tenant sets it up is not sufficient. DNS records change. That's literally what DNS rebinding exploits.

Every single outbound request from your delivery worker needs to:

→ Resolve the hostname fresh
→ Check the resolved IP against a private range blocklist before opening the connection
→ Reject anything pointing to 10.x, 172.16-31.x, 192.168.x, 169.254.x, or localhost

Some HTTP libraries will follow redirects automatically too. A 302 hop to an internal IP is just as dangerous. You need to validate at every step of the chain, not just the initial resolution.

This Is an Architecture Problem, Not a Config Problem

The frustrating part is that most webhook guides treat security as "add HMAC and you're done." That's security theater for the delivery path. 🔒

If you're building a webhook system, the delivery worker is the most dangerous component you own. It makes outbound HTTP requests to attacker-controlled URLs. Read that sentence again.

You're essentially running an HTTP client that takes instructions from your tenants. That deserves the same paranoia you'd give to user-uploaded code execution.

At a high level, the decisions that actually matter:

→ Pin DNS resolution to the moment of delivery and validate the IP
→ Disable HTTP redirects or re-validate after each hop
→ Run delivery workers in a network segment with no access to internal services or metadata endpoints
→ Treat every tenant URL as hostile, every time, forever

The Takeaway

Your inbound webhook security is probably fine. Your outbound delivery worker is probably a loaded footgun pointed at your cloud metadata endpoint. The fix isn't complicated — validate DNS resolution at delivery time, block private IPs, isolate the worker network. But you have to actually do it, and most teams don't because every tutorial stops at HMAC. 😅

What does your webhook delivery pipeline look like — are you validating resolved IPs on every outbound request, or just at registration time?

Pinning GitHub Actions to a tag is mass negligence and we all just watched it happen

Aditya Agarwal — Sat, 18 Apr 2026 13:14:31 +0000

Many of your CI pipelines can easily be manipulated to execute any code with a single force-push. And you likely unwittingly enabled this yourself.

I certainly did.

What Actually Happened

In March 2026, LiteLLM was breached using a poisoned Trivy GitHub Action. The threat actor didn't publish a new, obviously-malicious action under a typo-squatted name. They force-pushed malicious code to existing release tags that teams were already using.

In other words, the @v1 or @v2 that you pinned to? It's mutable. Anyone with write access to that repo can point it at completely different code whenever they want.

Why Tag Pinning Is a Trust-Me Handshake

Here's what most workflows you'll see in the wild look like:

- uses: some-org/some-action@v1

See that @v1? It feels nice and pinned, right? Looks like a version. Your brain pattern-matches it to npm semver or Docker tags and moves on.

However, it's just a Git tag. Git tags are not immutable. A maintainer — or an attacker who has compromised a maintainer — could delete and recreate that tag pointing at any commit they want. Your next workflow run pulls the new code silently.

No diff. No notification. No PR review. Nothing.

→ Tag pinning gives you the illusion of reproducibility without actual reproducibility.
→ You're trusting every maintainer of every action, forever, with access to your CI secrets.
→ A single compromised token upstream means your GITHUB_TOKEN, cloud credentials, and deploy keys are exposed.

Every startup I've worked at has pinned to tags. Every template repo on GitHub has pinned to tags. Every "getting started" tutorial ever has told you to pin to a tag. We all collectively normalized this. 🤷

The Fix Is Boring and That's the Problem

In fact, GitHub themselves recommend pinning actions to full commit SHAs:

- uses: some-org/some-action@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

A commit SHA is immutable. You can't force-push over it. If someone pushes malicious code, it gets a new SHA, and your workflow will keep running the old, safe commit.

→ SHA pinning is the only pinning that actually pins anything.
→ Tools like Dependabot and Renovate can auto-update SHA pins with readable diffs.
→ You can add a comment with the tag for readability: @a1b2c3... # v2.1.0

Yes, it's ugly. Yes, it's annoying. But "annoying" beats "compromised" every single time.

This Is a Supply Chain Problem We Keep Ignoring

We dedicated years to studying left-pad, event-stream, and colors.js. We created lockfiles, SBOMs, and signed packages. Then we turned around and gave our CI pipelines — the things with write access to production — zero supply chain discipline.

Your CI runner has secrets that your application code doesn't. Cloud provider keys. Package registry tokens. Deploy credentials. For most organizations, it's the single highest-value target, and we're protecting it with vibes. 🔓

The LiteLLM incident wasn't sophisticated. It was embarrassingly simple, and that's what makes it terrifying.

What I Changed

After reading about this, I spent an afternoon auditing our workflows at the startup where I work. Every single third-party action was pinned to a tag. Every one.

I replaced all of those with SHA pins + tag comments, and added Renovate to automatically open PRs with the new SHAs. The whole thing took maybe two hours. Two hours to close a door that was wide open to any upstream compromise.

If you haven't done this yet, maybe today's the day.

Here's my question for you: Do you pin to SHAs already, and if not, what's actually stopping you? Is it tooling, awareness, or just inertia?

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? 👇

DEV Community: Aditya Agarwal

Cloudflare and GitHub are building identity systems for AI agents. We're not ready for this.

What Actually Happened

The Real Problem Nobody Wants to Say Out Loud

AI Agents Make This Exponentially Worse

What I Think We Should Be Doing

Here's the Thing

Cloudflare wants agents to write and deploy their own code. That should terrify you.

Why This Is Different

What Cloudflare Actually Built

The Sandboxing Argument Doesn't Comfort Me

We're Normalizing Without Discussing

Where This Goes

Most webhook security guides protect the wrong side. The scary part is delivery.

Why Your HMAC Doesn't Save You Here

DNS Rebinding: The Actual Scary Part

Validate at Delivery Time, Every Time

This Is an Architecture Problem, Not a Config Problem

The Takeaway

Pinning GitHub Actions to a tag is mass negligence and we all just watched it happen

What Actually Happened

Why Tag Pinning Is a Trust-Me Handshake

The Fix Is Boring and That's the Problem

This Is a Supply Chain Problem We Keep Ignoring

What I Changed

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

The Architecture That Broke The Bank

Where The Money Went

The Fix Nobody Wants To Admit

The Real Lesson

Your Turn

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

Why We Started Measuring

The Three Problems Nobody Talks About

What We Changed This Week

The Real Metric That Matters

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

Before

What changed: 3 rules

The weird part?

The real lesson

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

What it actually says

What Linus actually said

Why the rest of us should care

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

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

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

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

They Have Names Now

Why We Humanize the Math

The Coddling Myth

Tier Lists Are A Trap

What I Actually Did

The Takeaway

macOS Just Admitted Its Privacy Settings Cannot Be Trusted

The Problem

The Weird Part

Why This Matters

Why Apple Hasn't Fixed It

What You Can Do Today

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

Git Was Built for Humans

Where It's Already Breaking Down

But Do We Actually Need Something New?

The $17 Million Question

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