DEV Community: Aditya Agarwal

AI killed the junior dev ladder. Nobody has a plan for what's next.

Aditya Agarwal — Mon, 20 Apr 2026 19:26:04 +0000

We are creating an industry that employs senior engineers but at the same time are actively eliminating the very means of producing them. This is not a hot take. This is the math.

The Ladder Is Disappearing

Junior dev work has always been the training ground. You build a button component. You wire up a form. You fix a CSS bug and seriously reevaluate your life decisions. Those reps are how you learn to think about systems.

Now those tasks are increasingly AI-generated. Simple UI components. Boilerplate endpoints. Basic CRUD. The exact work that used to be a junior's entire job for the first year or two.

Reports are already surfacing of frontend devs being cut from teams because AI now handles their workload. Not senior devs. Not architects. The juniors. The ones who were supposed to become the next generation of senior talent.

Nobody Is Talking About the Pipeline

Here's the thing that gets me. Every major tech company is out here racing to ship AI coding tools. They're all hyping "10x developer productivity" and "do more with fewer engineers."

Not a single one of them has publicly grappled with the obvious follow-up question: if AI is handling junior-level work, how does anyone become senior?

It's like removing the minor leagues and wondering why MLB talent dried up five years later. 🤷

Senior engineers didn't emerge from a vacuum. They got there by doing junior work badly, getting feedback, and slowly building intuition. That process takes years of hands-on reps.

→ You don't learn system design by reading about it.
→ You learn it by building something that breaks at scale.
→ You learn debugging by staring at a bug for three hours, not by asking a model to fix it.
→ You learn code review by having your own code torn apart.

Remove those reps and you don't get "AI-augmented juniors." You get people who never develop the instincts that make senior engineers valuable.

The Structural Paradox

The industry desperately needs senior engineers. Every company out there is crying about the talent shortage. Every hiring manager will tell you they can't find enough experienced people.

And yet the collective response is to automate away the exact experience that produces those people. We're eating the seed corn. 🌽

Some will argue that juniors should just "adapt" — learn to prompt better, focus on architecture earlier, skip the grunt work. I'm skeptical. That's like saying medical students should skip residency and just supervise robots. The grunt work is the education.

Others will say AI creates new types of junior work. Maybe. But nobody has defined what that work looks like. Nobody has built the new ladder. We're just pulling up the old one and hoping something appears.

This Isn't a Tech Problem

This is a people problem disguised as a tech story. The question isn't whether AI can write a React component. Obviously it can.

The question is what happens to the industry in five to ten years when the current batch of seniors burns out, retires, or moves into management — and there's no one behind them with real experience.

We're optimizing for short-term productivity while creating a long-term talent crisis. Every team shipping faster today with fewer juniors is borrowing against a future they haven't thought about.

I don't have a clean answer here. But I know that "just let the market figure it out" isn't a plan. It's a cop-out. And the ones who'll pay the price are the 22-year-olds graduating right now into an industry that automated their first rung and called it progress. 😐

What's your take — is there a realistic path for juniors to build real skills in an AI-first world, or are we sleepwalking into a talent collapse?

Vibe coding produces the silhouette of software, not software

Aditya Agarwal — Mon, 20 Apr 2026 13:34:52 +0000

It seems like every week there's a new "Here's a full-stack app I made in 48 hours with AI!" screen recording that wows you visually. Then you click the repo link and you're just… staring at a corpse in a suit.

The term "vibe coding" has entered the lexicon. It describes shipping AI-generated code you haven't actually reviewed. You prompt, you accept, you deploy. Vibes.

The Silhouette Problem

There's a metaphor floating around developer forums that nails this perfectly: AI-generated apps are silhouettes of software. From a distance, the shape is right. The outline matches. But there's nothing behind it.

A silhouette of a chair looks like a chair. You still can't sit in it.

These demo apps pass what I'd call the screenshot test. They have auth screens, dashboards, CRUD operations, maybe even a dark mode toggle. But try to do anything slightly off the happy path and the whole thing folds like wet cardboard.

Cargo Cult Engineering

The "I built a Reddit clone in a weekend" genre is cargo cult engineering at scale. It mimics the artifacts of real software — routes, components, database tables — without any of the decisions that make software survive contact with users.

→ No input validation beyond what the framework gives you for free.
→ No error handling strategy. Just silent failures everywhere.
→ No concept of edge cases, race conditions, or concurrent users.
→ No tests. Obviously no tests.

Real software is boring. It's the 200 lines of retry logic around a flaky third-party API. It's the migration script that handles the column rename without dropping production data. It's the argument your team had for three days about whether that field should be nullable.

Vibe coding skips all of that. That's the point. That's also the problem.

The Deletion That Says Everything

A public online thread where veteran developers criticized vibe coding got memory-holed by the mods, apparently. I find that telling.

This is an uncomfortable conversation because it pokes at something the industry wants to believe right now. We want AI to make us 10x faster. But pointing out that "10x faster to a demo" and "10x faster to production" are wildly different claims is a buzzkill. But it's true.

Junior developers are especially vulnerable here. If you've never built software that had to survive a normal Tuesday afternoon with real users, a vibe-coded app genuinely looks complete to you. You don't know what you're not seeing. That's not a character flaw — it's an experience gap. But the gap is real 🔥

What Actually Matters

I'm not anti-AI in coding. I use it daily. The difference is I treat AI output the way I'd treat code from an enthusiastic intern — potentially useful, definitely needs review, occasionally dangerous.

→ AI is great at generating boilerplate I was going to write anyway.
→ AI is terrible at making architectural decisions it doesn't understand the context for.
→ The value of a senior engineer was never typing speed. It was judgment.

Vibe coding removes judgment from the loop and calls it productivity. That's not a workflow improvement. That's a regression dressed up in a time-lapse video 😅

The Real Cost

The silhouette ships fast. Then someone has to maintain it. That someone opens the codebase, sees thousands of lines of AI-generated code with no clear intent behind any of it, and starts over from scratch.

I've seen this happen. The rewrite takes longer than building it right would have in the first place. Every single time.

The demo impressed people. The deploy didn't. Software isn't a screenshot.

I'm curious to know — where do you draw the line between using AI as a tool and letting it drive? Have you ever inherited a vibe-coded project? I'm here for the war stories 👇

2000 modules to render a button. Web dev earned this reputation.

Aditya Agarwal — Mon, 20 Apr 2026 10:23:25 +0000

A viral thread just asked developers what feels over-engineered in modern web dev. The answers hit like a group therapy session nobody knew they needed.

Thousands of comments. The loudest ones all circled the same absurdity: we're compiling thousands of modules to ship a button that says "Submit." And honestly? Nobody could argue back.

The Space Shuttle Problem

Someone compared modern front-end tooling to building a space shuttle for a marketing site. That metaphor is painfully accurate.

You need a static page with a contact form. By the time you're done, you've got a bundler, a transpiler, a CSS-in-JS library, a state manager, a routing layer, and a deployment pipeline that would make NASA nervous. The button works, though. So that's nice.

The thing is, none of these tools are bad. Webpack solved real problems. React solved real problems. TypeScript solved real problems. But stacking all of them on a five-page site isn't solving a problem — it's performing competence.

Why We Keep Doing This

Here's the part nobody wants to say out loud: simple solutions don't get you promoted.

Nobody writes a blog post about the time they shipped a project with plain HTML and a single CSS file. Nobody gets a senior title for choosing the boring option. The incentive structure in our industry rewards complexity, even when that complexity serves the toolchain more than the user.

→ Complex architectures look impressive in system design interviews
→ "I built it with zero dependencies" doesn't make your résumé pop
→ Conference talks about simple solutions don't fill rooms
→ Pull requests with 47 new packages feel like progress

We cargo-cult complexity because the industry tells us complexity equals skill. Then we wonder why onboarding a junior dev takes three weeks before they can touch a single component.

It Wasn't Always Like This (But Also It Was)

I'm not a fan of making the past seem better than it was. Dealing with jQuery spaghetti code was a nightmare in itself. PHP templating with inline SQL left our applications so vulnerable you could drive a truck through the holes. There were real issues with the old days.

However, somewhere between hand-writing everything and needing 2000 modules to render a button, we overshot. We went from solving user problems to solving developer-experience problems to solving problems that only exist because of the tools we chose to solve the previous problems. It's turtles all the way down. 🐢

The Uncomfortable Fix

The solution doesn't lie in a new tool. It comes down to restraint.

Before you add a dependency, ask yourself one question: who does this serve? If the answer is "it makes the DX nicer for our eight-person team," that might be fine. If the answer is "everyone uses it," that's not a reason — that's peer pressure.

The most effective engineers I've worked with have one thing in common. They're happy being boring. They choose the smallest tool that accomplishes the task at hand, and then they get on with their lives. They don't need the architecture to be interesting. They need the product to ship. 🚀

Start with what solves the user's problem, and work backwards. Not with whatever new hotness the latest blog post introduced to your ecosystem.

So Where Does That Leave Us?

The thread wasn't just people complaining. It was a signal. A lot of developers are quietly exhausted by tooling that exists to justify itself.

We earned this. Every time we npm install'd our way to a 400MB node_modules folder for a freakin' landing page, we earned it. The good news is we can also un-earn it — one boring, right-sized decision at a time.

What's the most over-engineered setup you've ever seen on a project that definitely didn't need it? Give me your horror stories. 👇

Stop picking Cursor or Claude Code. Pay for both, you cheapskate.

Aditya Agarwal — Sun, 19 Apr 2026 16:14:39 +0000

Each week I see a new post asking "Cursor vs Claude Code — which do you choose?" And each week I keep on scrolling. The comparison is false, and deep down, you know it is.

You're not making a choice between two competitors. You're making a choice between a hammer and a screwdriver, and then boasting that you only needed one.

Why This Debate Exists

Cursor was $20 a month (then it flipped to a metered model in mid-2025), and Claude Code is $20 a month. That's the whole issue. People will sign up to $20 of forgotten streaming services a month, but $40 of the tool they rely on for eight hours a day? Breakout the spreadsheet, we need a pro-con list.

The "vs" sets the premise. It grants you the excuse to only try to get away with one.

What Claude Code Actually Does Well

Claude Code is right there in your terminal. It has a 200k token context window. We're not exaggerating for marketing. It's why Claude can hold the entire codebase in its head.

I reach for it whenever I need to think through the contents of dozens of files. Refactoring a shared type that touches forty components? Claude Code doesn't lose track of the change halfway through. It's the tool for big-picture work:

→ Architectural decisions across a monorepo
→ Multi-file refactors that need full context
→ Asking "where does this data actually flow?" and getting a real answer

What Cursor Actually Does Well

Cursor is right there in your editor. It's watching your keystrokes. It's autocompleting the line you're halfway through writing before you've had a chance to finish thinking it through.

That inline autocomplete is ridiculously good for tiny, precise, single-file edits. Writing a new function, fixing a test, tweaking a component. Cursor is faster than anything else I've used.

One thing that developers never mention enough: Cursor becomes inefficient in large codebases. When projects become very large, the indexing becomes slow, memory usage grows, and the AI can't look at enough of the code in your project, which means suggestions may drift. Suggestions drift. You begin to get completions that reference patterns for the wrong part of your project.

That's not a bug. It's a tradeoff. Cursor is optimized for speed and precision in a small radius. Claude Code is optimized for depth across a large surface area.

The Actual Workflow

Here's what my day looks like now:

→ Morning planning session in Claude Code — I describe what I want to build, let it reason across the full codebase, and sketch out the approach
→ Implementation in Cursor — I write the actual code with fast autocomplete and targeted edits
→ Back to Claude Code when something breaks across boundaries — when a change in one service ripples into three others

It's not complicated. One tool thinks wide. The other tool types fast. 🛠️

The $40/mo combined cost is less than most developers spend on coffee in a week. If these tools save you even thirty minutes a day — and they save me way more than that — the ROI isn't even a conversation.

Stop Optimizing for the Wrong Thing

We're in a weird moment where AI tools are genuinely changing how code gets written. Spending energy on "which single tool is best" is like arguing over vim vs emacs while the building is on fire 🔥

The answer is boring. Pay for both. Use each one where it's strong. Move on and ship something.

So here's my question: if you're using both already, what's your split look like — and if you're only using one, what's actually stopping you from trying the other?

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?

👇

DEV Community: Aditya Agarwal

AI killed the junior dev ladder. Nobody has a plan for what's next.

The Ladder Is Disappearing

Nobody Is Talking About the Pipeline

The Structural Paradox

This Isn't a Tech Problem

Vibe coding produces the silhouette of software, not software

The Silhouette Problem

Cargo Cult Engineering

The Deletion That Says Everything

What Actually Matters

The Real Cost

2000 modules to render a button. Web dev earned this reputation.

The Space Shuttle Problem

Why We Keep Doing This

It Wasn't Always Like This (But Also It Was)

The Uncomfortable Fix

So Where Does That Leave Us?

Stop picking Cursor or Claude Code. Pay for both, you cheapskate.

Why This Debate Exists

What Claude Code Actually Does Well

What Cursor Actually Does Well

The Actual Workflow

Stop Optimizing for the Wrong Thing

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

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