DEV Community: Aditya Agarwal

Google used 6,000 open-source contributors then locked the door. Classic.

Aditya Agarwal — Sat, 23 May 2026 19:11:00 +0000

Google recently merged the work of 6,000 community contributors to its Gemini CLI. Then they pulled up the drawbridge and told free users to kick rocks.

If that doesn't get your blood pumping, you haven't been listening.

What Happened

Google is deprecating Gemini CLI for free users and paid consumer subscribers, shifting them to a replacement tool called Antigravity CLI. Enterprise customers retain access to the tool. Everyone else, including the thousands of developers who contributed to it, gets a thank-you card and a locked door.

Approximately 6,000 community contributions were merged prior to the change. Six thousand PRs, bug fixes, docs improvements, and feature additions. All volunteered work, because those people saw value in the project.

The Playbook Is Always the Same

This is nothing new. The pattern is so obvious that there should be a Wikipedia page about it.

→ Step 1: Launch an open-source tool with big promises
→ Step 2: Let the community do massive amounts of free work
→ Step 3: Wait until the tool is mature and battle-tested
→ Step 4: Lock it behind an enterprise paywall

The community isn't the customer. The community is the unpaid QA team. The free R&D department. The marketing engine that gets developers emotionally invested so enterprises feel safe buying in.

"But You Should Have Known"

Yes, I can already imagine people saying that. "Oh well, it's Google after all. They destroy every other project."

That's a valid argument. But "you should have seen it coming" doesn't make it okay. It simply implies that we have accepted such exploitation to the extent that victims are held accountable for trusting a company worth a trillion dollars.

Contributing to corporate open source is a gamble. You're betting that the company's incentives will stay aligned with yours. And the house always wins. 🎰

The 6,000 people who contributed to this tool were not given any shares. They were not compensated. They didn't even get a vote on whether the tool they helped build would remain accessible to them.

What Devs Should Actually Do

I'm not suggesting you should never support corporate Open Source Software. That's unrealistic and honestly some of those projects do real good.

However, be cautious and well-informed.

→ Treat corporate OSS contributions as resume-building, not community-building
→ If a project doesn't have a strong independent governance model, assume the company will eventually rug-pull
→ Prioritize contributing to foundation-backed or truly community-owned projects
→ If you're going to contribute to BigCorp's repo, at least make sure the license protects forks

The Apache License, MIT, and the like do not prevent the code from being closed up again. However, the project itself, including the brand, infrastructure, and distribution, can certainly be taken away, which is precisely what occurred in this case.

The Bigger Problem

This goes beyond Gemini CLI. It concerns the overall interaction between big tech and the open-source community.

Companies get billions in value from open-source labor. The contributors get... exposure? A green square on their GitHub profile? Cool. Try paying rent with that. 😤

Every time this happens and we shrug it off, we tell the next company that the playbook works. That developers are an infinitely renewable resource who will keep showing up with free labor no matter how many times they get burned.

The Takeaway

Google leveraged the open-source community to develop, test, and refine Gemini CLI. But ultimately determined that only paying enterprise customers would have access to the final product. The 6,000 contributors were the scaffolding. And you tear the scaffolding down when the building is complete.

My question is: Is it reasonable for developers to ask for formal contribution agreements with guaranteed access clauses before contributing to corporate open source? If not, is the alternative to simply not contribute to tools owned by companies that have a history of being rug-pullers?

AI slop debt" is technical debt on fast forward. Nobody's ready.

Aditya Agarwal — Sat, 23 May 2026 13:15:15 +0000

Every cleanup process you have was designed for human-speed mess-making. AI agents just have a “hit the nitro” button.

A recent piece on pmdata.substack.com coined a term I can't stop thinking about: "AI slop debt." It's about what happens when tools like Claude Code and Lovable generate mountains of functional-but-soulless code. And it nails something most of us are feeling but haven't named yet.

The Speed Problem Isn't New. The Scale Is.

Technical debt has been around ever since we started delivering software. We've always cut corners, shipped the hacky thing, promised to fix it later. It was acceptable. Humans generate tech debt at a pace humans can (theoretically) clean up.

AI agents are not concerned about “later.” They write code so fast that your backlog is obsolete before the next sprint planning.

Nobody Owns This Code

The author of pmdata compares it to taking on unowned critical code at SoFi. You’ve been there. Some system is load-bearing, nobody wrote docs, the original author left, and now it’s your problem.

AI slop debt is that scenario, except it's every file. The "original author" was a probabilistic model that doesn't remember writing it. There's no one to Slack. There's no institutional memory. There's just... output.

Here is what exacerbates the situation:

→ No ownership. Nobody feels responsible for AI-generated code the way they do for code they wrote at 2am before a deadline.
→ No taste. The code works. It passes tests. But it doesn't reflect any coherent design philosophy.
→ No friction. The thing that used to slow down bad decisions — the effort of actually typing them — is gone.

"Taste" Is the Actual Moat

The pmdata piece argues that the real challenge is encoding engineering taste into these systems. I believe this also hits the mark.

Taste is why a senior engineer's "simple" solution looks different from a junior's "working" solution. It's the difference between code that survives contact with the next feature and code that collapses under it.

AI tools don't have taste; they have patterns. They will output code that seems reasonable but they don't have a belief on how something should be developed. 🧠

And here's the uncomfortable part: most teams can't even articulate their own taste. It lives in code review comments, hallway conversations, and the gut feelings of people who've been burned before. Good luck putting that in a system prompt.

Your Existing Processes Will Break

Code review? Already stressful. Now picture going through the output that comes in such bulk that no human team could even review it.

Refactoring sprints? They inherited debt built up over quarters. Not overnights.

Linting and static analysis catch syntax-level issues. They don't catch "this architecture will be a nightmare in six months." That's a judgment call. That's taste again.

The teams that survive this aren't the ones generating code fastest. They're the ones who figure out how to maintain velocity without drowning in their own output. 🏊

What Actually Helps

I don't think the answer is "stop using AI tools." That ship sailed. That option is no longer available to us.

→ Treat AI output like a pull request from an untrusted contractor. Review it like you'd review code from someone who doesn't know your system.
→ Invest in architectural guardrails before you invest in generation speed. If you can't describe your system's taste in writing, an AI definitely can't follow it.
→ Accept that "fast" and "maintainable" are in tension. Every team needs to decide where they draw that line, deliberately, not by default.

The Real Question

AI technical debt is not a later problem. It is accumulating right now, in every codebase where a generated file was submitted without a close read. The term is coined because the hurt is already there. 💥

We built decades of processes around human-speed mistakes. We have maybe months to adapt them for machine-speed mistakes.

So here's what I want to know: has your team changed any process specifically to handle AI-generated code quality? Or are you still treating it like regular tech debt and hoping for the best?

AI made senior devs 19% slower. They swore it made them faster.

Aditya Agarwal — Fri, 22 May 2026 19:15:29 +0000

AI made senior devs 19% slower. They swore it made them faster.

Take a moment to let that satisfying contradiction sink in.

A recent study discovered that experienced developers using AI coding tools took 19% longer to complete tasks. And get this: Those developers also self-reported a 20% higher productivity rate. That’s not a small difference in perception. That’s a full-on reality warp.

The Confidence Trap

I understand. Copilot writes your function. The chat outputs a regex your brain didn't feel like working on. It almost feels like cheating.

However, thinking that you are fast and actually being fast are not the same. This is particularly dangerous for senior engineers. Because nobody questions the person in the room who's been shipping code for a decade.

Where the Time Actually Goes

The debate around this study keeps circling back to the same thing: verification and debugging overhead.

I can give you my perspective:

→ AI generates code that looks right but carries subtle bugs.
→ Senior devs spend time reviewing, testing, and fixing that output.
→ The generation felt instant, so the brain logs it as "fast."
→ The cleanup gets mentally filed under "normal debugging."

You may not be aware of the toll because it is distributed over many micro-moments. Renaming a variable in this place. Mistakes in an edge case there. It's an off-by-one error that you've noticed just before pushing. None of this seems to be the fault of the AI. But it's accumulating.

Why Seniors Get Hit Hardest

This may seem counterintuitive. One would assume that junior developers would have more difficulty with AI-generated code. However, seniors are more susceptible to a specific threat: they are overly confident in their ability to assess the code.

A junior dev might paste AI output and run tests because they're unsure. A senior dev reads the output, thinks "yeah, that's roughly what I'd write," and moves on. The confidence that makes them great engineers becomes the exact thing that lets bad code slip through.

It's like giving a seasoned driver a car with a slightly delayed steering wheel. They'll compensate without noticing. They'll arrive late and blame traffic. 🚗

The Real Problem Isn't Speed

To be honest, being 19% slower may not be significant for the majority of teams. The fact that a feature is shipped on Thursday instead of Wednesday hardly ever destroys a company.

The real problem is the false signal. If your entire team believes they're 20% more productive, that belief shapes hiring plans, sprint commitments, and deadline promises. You're making decisions based on vibes that directly contradict the data.

This issue cannot be solved with tools. It's a risk within the organization. 😬

What I'm Doing About It

I don't hate AI tools. In fact, I use them every day. But I've started treating them the way I treat Stack Overflow answers from 2014 — useful starting points that I never trust without verification.

A few things that help:

→ Time yourself occasionally. Not obsessively. Just enough to check your assumptions.
→ Track rework. If you're fixing AI-generated code more than you expect, the "productivity" is a mirage.
→ Be honest about the assist. When AI writes a block, mentally flag it as unreviewed. Don't let familiarity substitute for verification.

All of these suggestions are simple, basic ideas. It's the follow-through that's hard. The kind that's easy to skip when a tool is whispering "you're so fast now" in your ear.

The Takeaway

AI coding tools are powerful. They're also flattering. And flattery is the one thing experienced engineers aren't trained to defend against. The 19% slowdown isn't the scary number here. The 20% false confidence is.

So here's my question for you: Have you ever measured whether AI tools actually make you faster — or are you going off how it feels? I’d really appreciate an honest answer. 👇

Your company won't replace you with good AI. They'll replace you with bad AI.

Aditya Agarwal — Fri, 22 May 2026 16:06:37 +0000

The CEO doesn't want an AI writing better code than you. They want an AI writing code for cheaper than you.

That's the part most developers get wrong when they think about the AI threat to their careers.

The Fear Is Backwards

We keep debating whether AI can match a senior engineer's output. If it can have a real understanding of architecture. If it can think through edge cases.

None of that matters to the person approving headcount. The question in the boardroom isn't "Is this AI as good as Sarah?" It's "Is this AI good enough to skip hiring Sarah's replacement?"

Those are two completely different questions. However, only one of them determines your future.

Meet "Vibe Debt"

There's a term gaining traction in developer circles: vibe debt. It describes the specific flavor of technical debt that AI-generated code creates — code that looks right, passes a cursory review, maybe even works today, but carries hidden rot.

It's the kind of code that makes you say "this feels off" without being able to immediately point to why. That's how it got its name.

Here's the thing about vibe debt: it doesn't show up on a quarterly report. You know what does show up? The salary line item that just got eliminated.

→ AI slop ships on Tuesday
→ The bug surfaces in October
→ The dev who could've caught it was laid off in March
→ A contractor gets hired at 2x the cost to fix it

This situation has been happening since the beginning of outsourcing. The only difference is that now we have a new type that creates pull requests.

Cost-Cutters Don't Optimize for Quality

Business incentives favor cost-cutting over code quality. This isn't cynicism. It's just how quarterly earnings work.

A Vice President doesn't receive a promotion because they "maintained excellent code health across the platform." It's because they "reduced engineering spend by 40%." What drives people are the rewards they seek.

So when a mediocre AI tool can generate a feature that mostly works, that's not a failure to the person holding the budget. It’s considered successful. Ship it, file the bugs later, let the remaining skeleton crew deal with the fallout.

I have seen this happening before with offshore outsourcing, with no-code tools, with every "developers are too expensive" trend. The process is always identical:

→ Replace skilled people with a cheaper alternative
→ Declare victory for two quarters
→ Quietly hire specialists to clean up the mess
→ Never acknowledge the total cost was higher

AI just makes the first step more convincing. 🎯

Why This Should Change Your Strategy

If the threat isn't brilliant AI but mediocre AI in the hands of aggressive cost-cutters, then your defense isn't "be slightly better than GPT at writing functions."

You are defending being the individual who "gets" the why of broken things. The person who can enter a repository full of vibe debt and reliably determine it. The person the suits phone after their AI-first approach begins spewing production incidents.

The skills that matter most in this world:

→ Systems thinking — understanding how components interact, not just how to generate them
→ Debugging intuition — the AI can write code but it can't feel the wrongness in a stack trace at 2 AM
→ Organizational trust — being the person a team actually believes when you say "this will break"

A cost-cutter can't replace any of those with a $20/month subscription.

The Bottom Line

The developers who are in the most danger are not the ones who can’t keep up with AI. It’s the ones who work at organizations where the leadership sees engineering as an expensive cost to be cut, rather than an essential capability to be grown.

The AI isn't the threat. The spreadsheet is.

So here's my question for you: Have you seen this pattern emerge within your company — not AI replacing devs outright, but AI being used by leadership as a reason to shrink teams below what they should be? And what happened next?

Vibe coding works until it doesn't. The debt is real.

Aditya Agarwal — Fri, 22 May 2026 13:11:06 +0000

Every dev I know is shipping faster than ever. Nobody wants to talk about what the codebase looks like six weeks later.

We're in the golden age of AI-assisted development. You can go from idea to working feature in hours instead of days. Payment integrations, auth flows, CRUD scaffolding — LLMs eat that stuff for breakfast. But I keep noticing the same pattern. The fast part stays fast. The hard part gets harder.

The Speed Is Real

I'm not here to be a hater. AI-generated code has genuinely changed how quickly you can move through the boring stuff.

No more boilerplate code required and developers no longer have to write repetitive glue code. The payment integration that previously required a week to read the documentation? Developers are now saying they can deliver that in a tiny fraction of the time.

I know, right? I mean, you're not joking. This is awesome!

The Debt Is Also Real

This is when things start to look messy. LLMs are excellent at producing code that works. They're terrible at producing code that fits.

They handle boilerplate well but struggle with system design and abstractions. They don't understand your domain boundaries. They don't know why you split that service in two last quarter. They generate plausible-looking architecture that quietly fights against the grain of your system.

You deliver the feature. Tests pass. PM is satisfied. And somewhere in the guts of your codebase, you now have a chunk of code that nobody fully understands — including the person who prompted it into existence.

Vibe Debt Is Not Tech Debt

There is a term I recently heard that I feel really captures this: vibe debt.

Vibe debt is different from tech debt. Tech debt is a decision you make, a conscious trade-off: “I know I’m going to regret this shortcut, but it’s worth it because we’re going to overhaul this component soon.” Vibe debt is what happens when you ship code that you never quite had a handle on to begin with.

The distinction is important:

→ Tech debt: "We hardcoded this config because launch is Friday. We'll fix it next sprint."
→ Vibe debt: "The AI wrote this service layer and it works but I couldn't explain the design decisions if you asked me."

Vibe debt is invisible because every test passed and management happily ticked off Jira stories. You don't notice it until something breaks in a way that requires you to actually reason about the system. And suddenly you're staring at code that has no coherent design philosophy because it was generated piecemeal by a model optimizing for "make the test pass."

Accidental vs. Essential Complexity

This is the crux of the issue. Vibe coding selects hard for speed on accidental complexity — the stuff that's tedious but not intellectually difficult. Configuration files, API...

However, it actually undermines your capability to manage essential complexity — the real important things like domain modeling, state management across boundaries, and making decisions about what not to build.

LLMs can't do the work for you. And if all you do is prompt and not think, you lose the muscle for it. 🧠

I've seen teams move incredibly fast for two months and then hit a wall where every new feature takes longer than it would have without AI. Because the codebase has no coherent shape. It's a patchwork of locally correct, globally incoherent decisions.

What I Actually Think You Should Do

I'm not suggesting we abandon AI. That ship has sailed and honestly it would be dumb to stop.

Approach AI-generated code like you would a pull request from a junior developer. Take the time to read it. Challenge the architecture. Refactor it into your existing patterns before merging. The ten minutes you spend reshaping AI-generated code saves you days of confusion later.

Also, be honest with yourself about what you actually understand. If you can't explain why the code is written the way it is, you haven't shipped a feature. You've shipped a liability. 💀

So here's my question: have you already hit a vibe debt wall? Or are you still in the honeymoon phase where everything feels fast and free?

Most 'AI agents' are just scripts with a marketing budget

Aditya Agarwal — Thu, 21 May 2026 10:15:21 +0000

If your "AI agent" follows the same path every single time, I have news for you. That's a script.

The term "agent" has become the new "cloud." Slap it on anything and watch the funding roll in.

Why This Matters Right Now

Developers are in a heated battle over the very definition of "agent". It's a noisy, messy, and ubiquitous debate occurring in every programming community I pay attention to.

And honestly? The confusion is the product. Startups love that nobody agrees on a definition because it lets them call everything an agent.

The Three Things People Keep Conflating

Here's the rough taxonomy I keep seeing developers converge on:

→ Tool-using chatbots — An LLM that can call an API when you ask it to. It's a chatbot with hands. Not an agent.

→ Prompt-driven workflows — A hardcoded sequence of steps where an LLM handles some text processing in the middle. It's a pipeline. Still not an agent.

→ Autonomous decision loops — A system that observes its environment, decides what to do next without a predetermined path, and adjusts based on outcomes. This is the only one that earns the word "agent."

Most of the products I have reviewed are solidly in bucket one or two, but they position themselves as bucket three.

The "If" Statement Test

Here’s my quick gut check. Look at the code (or the architecture diagram, if that’s all you can get).

If you can easily describe what the system does using a simple flowchart that fits on a napkin, then it’s orchestration. If you could rip out the LLM, replace it with a regex or a template, and describe the majority of the behavior in the same way, then it’s a script with an overcomplicated language model tacked on.

An actual agent surprises you. Not because it's buggy — because it chose a path you didn't explicitly wire up. That's the difference. Deterministic control flow with an LLM in the middle is not agency. It's automation with better vibes.

Why Label Inflation Hurts Us 🔥

This is more than just arguing about words. It's actively making tool evaluation harder for working engineers.

When every product out there is an "agent" you cannot filter. You spend hours in demos only to discover the thing is a glorified cron job agent calling GPT-4 in a loop. Devs are getting more vocal about this, and the pushback against generic agent marketing is real.

This type of discussion also has a negative impact on discussions regarding truly agentic systems. Important issues such as goal decomposition, error recovery, and safe autonomy are overlooked because they are overshadowed by the marketing hype of products that are not exposed to such challenges since they never actually allow the model to decide.

The Uncomfortable Truth

Ironically, some of those scripts that are perceived as “mere scripts” are actually quite handy: a well-designed prompt-driven script can be more robust, more maintainable, and less expensive to operate than a fully autonomous agent.

The problem isn't building pipelines. Pipelines are great. The problem is calling your pipeline an agent so you can charge agent prices and ride the hype wave 🏄.

If the industry settled on honest labels, we'd all evaluate tools faster, set better expectations, and stop being disappointed when our "agent" can't handle a task that wasn't in its flowchart.

Where I Land

Refer to your scripts as scripts and your pipelines as pipelines. Reserve the term "agent" for systems that truly operate autonomously in unbounded environments. The threshold should be very high as the term implies a level of capability that most systems do not possess.

Honest naming isn't just good engineering culture — it's how we keep our tools trustworthy and our hype cycles from eating us alive. 💀

So here's my question: what's the most egregious example of "agent-washing" you've seen in the wild?

Junior devs using Copilot are speedrunning their own irrelevance

Aditya Agarwal — Tue, 19 May 2026 19:07:34 +0000

There's a post floating around dev forums from a junior engineer that stopped me cold. The essence of it was: “I can sense myself turning into an imbecile.”

Not burnout. Not imposter syndrome. Something new. A slow, creeping sense that the tools doing the work for them are hollowing out the skills they never got to build.

That should scare the entire industry.

The Speed Trap

Copilot and Cursor adoption among junior engineers in 2025 is massive. Almost everyone coming up right now is using AI-assisted coding from day one. And on the surface, it looks like a miracle. Juniors are shipping faster than ever.

However, delivery is not learning. Fast learning is very similar to speed without understanding, simply heading towards a wall.

At the beginning of my coding journey I inevitably had to sit with bugs. An hour staring at a stack trace would lead me to grok something elemental about the system. That friction was the education. AI assistants remove the friction and the education with it.

Autocomplete Isn't Mentorship

Here's what I keep seeing play out. A junior dev gets stuck, tabs over to Copilot, accepts a suggestion, and moves on. The code functions as expected. The PR is merged. There is no inquiry about whether or not the dev could explain why it worked.

→ They learn to prompt, not to reason.
→ They learn to accept, not to evaluate.
→ They learn to ship, not to debug.

Studies and widespread anecdotal evidence are pointing the same direction: heavy AI dependency correlates with weaker skill retention. People who lean on autocomplete for everything struggle more when the autocomplete disappears. This isn't shocking. It's scary.

The junior who said "I felt myself becoming an idiot" was not dramatic. They were accurate about the feedback loop we're in, where output is rewarded and curiosity is punished. 🎯

The Industry's Blind Spot

Experienced engineers and engineering managers are excited about the increase in productivity. It's only natural. Juniors are closing tickets faster, asking fewer questions, and seemingly ramping up in record time.

But "ramping up" and "getting good" aren't the same thing. We're confusing onboarding speed with competence. And when those juniors hit a problem that Copilot can't pattern-match — a weird race condition, a subtle data corruption bug, an architecture decision that requires actual judgment — they're stuck.

Stuck not at “I need to Google this”. Stuck at “I don’t even know what question to ask”.

This gap is fundamentally different, and it actually grows the longer someone continues to exclusively code through AI suggestions.

This Isn't Anti-Tool. It's Anti-Autopilot.

I use Copilot. I use Cursor. I'm not a luddite yelling at clouds. These tools are genuinely powerful for experienced devs who already have mental models and can evaluate suggestions critically.

But for someone who's never built those mental models? The tool becomes a crutch before it becomes a superpower. 😬

→ Copilot is a force multiplier — but you can't multiply zero.
→ If you skip the struggle phase, you skip the part where intuition forms.
→ The best junior devs I've worked with deliberately turn AI off for learning tasks.

The final point is the most important. The ones who are going to thrive are the ones who treat AI like a power tool, not a brain replacement. They will utilize it only after they have grasped the problem, and not in place of grasping the problem.

What Actually Helps

If you're a junior dev reading this, I'm not telling you to delete Copilot. I'm telling you to build a practice around it.

→ Write the first draft yourself. Then compare it to what AI suggests. The delta is where learning lives.
→ Debug without AI once a week. Sit with the discomfort. That's the gym for your engineering brain.
→ Read the suggestion before you accept it. Every single time. If you can't explain it, you didn't learn it.

If you're a senior or a manager, stop measuring junior productivity by ticket throughput alone. Instead, request them to provide you with details on the code they’re working on. Collaborate with them. Notice if they're building judgment or just building features.

The Real Risk

The industry is not experiencing a shortage of junior developers. It's a shortage of thinking developers and it's gradually developing. And we are supporting this trend with $20/month subscriptions. 🔥

We are quickly educating a generation of engineers who are capable of writing code but lack the ability to think about systems. This is not an issue with the tools. It is an issue with leadership.

Now, over to you: Do you think that embracing A.I. in our daily lives could be reducing our ability to tackle complex problems without it? When was the last time you solved something hard, and what did you learn from the struggle?

Junior devs who learned with Copilot can't debug without it. That's fine.

Aditya Agarwal — Tue, 19 May 2026 16:05:55 +0000

A junior developer shared online that they’re “starting to feel like an idiot” for using AI tools and the post went viral. Thousands of senior developers agreed with them and said “we told you so”.

I think they're panicking about the wrong thing.

The Sky Is Always Falling

Copilot adoption among new developers is basically universal at this point. Juniors are shipping code they can't fully explain. They struggle to debug without autocomplete holding their hand. And senior engineers are treating this like a five-alarm fire.

I feel like we've been here before. Ten years ago, it was Stack Overflow that was the villain. “These young developers can’t do anything without copying from the internet!” Does that ring a bell?

We Never Required Assembly to Write C

Here's the reframe that matters.

When C replaced assembly, nobody demanded that every C programmer first prove they could hand-write machine code. The level of abstraction was raised. The required skills were shifted as well.

→ Assembly programmers thought C devs were lazy.
→ C programmers thought Java devs were sheltered.
→ Java devs thought JavaScript devs were unserious.
→ Now everyone thinks AI-assisted devs are broken.

It's like a recurring cycle. Every generation of developers gets told they don't understand "the fundamentals." The definition of "fundamental" just keeps shifting upward.

That junior who can't trace a segfault manually but can architect a working feature by collaborating with an AI? They have a different skill set. Not an absent one.

Where It Actually Gets Dangerous

I'm not claiming there is no risk involved. There is, but it's not in the direction most people think.

The actual risk is not that junior developers are unable to debug without Copilot. It's that they might never develop the taste to know when AI output is subtly wrong. An imagined function that appears good. A race condition hidden in self-assured code. An architectural choice that works now and collapses at scale.

That's the skill gap we should be concerned about. Not "are you able to write a for loop without using any reference." 🙄

The Skill Bar Moved, Not Disappeared

The juniors coming up right now need to learn different things than I did. They must be taught to critically read code, not simply to write it. They need to develop a sense for when the AI is confidently wrong. They must be able to grasp systems well enough to be the critics of output, not just the producers.

→ Prompt engineering is a real skill, even if the name is silly.
→ Knowing what to build matters more than typing it out character by character.
→ Code review instincts are more valuable than ever.

The standard didn't drop. It just shifted slightly. To be honest, some of these junior developers are shipping work more quickly and acquiring knowledge about how to architect systems sooner than I did, simply because they weren't stuck for six months trying to memorize syntax first.

What Seniors Should Actually Do

If you're a senior dev frustrated with AI-dependent juniors, I get it. But the move isn't to take away their tools. It's to teach them the layer underneath — just enough to build judgment.

Pair up with your mentee on a debugging session when Copilot is disabled. Do it as exposure, not as punishment. Show them what this tool is abstracting away so they can easily spot its mistakes. That’s mentorship. Protecting the old way of doing things is not. 💡

The younger member who made that post about “turning into an idiot” is not broken. They notice a gap, which already makes them stand out from most. It’s the ones who never question what the AI produces that I would be concerned about.

Every generation of developers looks soft to the one before it. Every generation turns out fine because the work itself forces growth. The times change. The thinking doesn't.

What's the one skill you think AI-assisted juniors should learn the hard way, without any tools helping them?

AI will keep React alive forever. That should terrify you.

Aditya Agarwal — Mon, 18 May 2026 16:12:01 +0000

Whenever you tell an AI, “build me a login page,” it writes React. Not Svelte. Not Solid. Not Vue. React. And that default is unobtrusively but strongly shaping the future of the web as a whole.

I've been mulling this over since I came across the Dead Framework Theory. The argument is simple and uncomfortable: LLMs are trained on massive amounts of existing code, and React dominates that training data by a landslide. AI generates React code. Humans integrate that React code and ship it. It's now new code for the model to learn from. And so on.

This situation is like a feedback loop that nobody constructed a way out of.

The loop that feeds itself

Here's how it works in simple terms.

→ React has the most tutorials, the most Stack Overflow answers, the most open-source repos.
→ LLMs absorb all of that and learn that "web app" basically means "React app."
→ New developers use AI to scaffold projects and get React by default.
→ Those projects produce more React code on the public internet.
→ The next generation of models trains on that code.

Each cycle tightens the grip. It's not a conspiracy. It's just math. The biggest corpus wins the autocompletion lottery.

Why this should bother you

I don't have anything against React. I've used it plenty. But a monoculture is dangerous in any ecosystem.

The way Svelte's compiler-first approach truly stands out. The real problems Solid's fine-grained reactivity solves are still problems React just doesn't address. These aren't play things -- they're real innovation in how we conceptualize rendering and state. If AI-assisted coding silently starves them of potential users, we all lose.

It's not alarming that React has become popular. What is alarming though is that this popularity is now being reinforced by machines, in a manner that has never existed in the past. Human hype cycles eventually cool down. But this may not.

"Just fine-tune the models"

The obvious counterargument: we can fine-tune LLMs on Svelte or Solid codebases and fix the bias. And actual business applications written in the non-canonical implementation aren’t irrelevant. Critics of the Dead Framework Theory say exactly this.

However, fine-tuning is expensive, time-consuming, and requires continuous investment. Who would pay for it? The framework authors who are already struggling with their open-source sustainability? Should the Svelte community come up with the money to fine-tune a model that would still be in direct competition with React’s "organically" obtained data model?

It's possible in theory. In practice, the incentives don't line up. Companies building AI coding tools optimize for the largest user base. That's React developers. So the default stays React. The loop continues.

The real question is about defaults

Default settings have a strong influence on software. The majority of developers stick with them. Most AI-generated code gets accepted with minor edits, not rewritten from scratch.

When React is the default output of any AI coding tool, React stops only being the most popular framework. It becomes an infrastructural assumption of AI-assisted web development. That’s a different kind of lock-in than “a lot of people use and like this."

I think we're sleepwalking into a world where framework choice is an illusion. Technically, you can choose differently. But your AI tools will fight you every step of the way. Your junior devs will have never seen anything else. Your hiring pipeline will filter for React because that's what candidates learned — from AI.

So what do we do?

To be honest, I can't give you a definitive answer on that. However, I believe that AI tooling, which is aware of the framework you are using and prompts you to select it before generating any code, is important. Also, I think that anyone developing coding assistance tools should consider training data diversity as a primary issue.

And I think we need to talk about this now, before the loop gets another two or three training cycles deeper.

What do you think – is AI-driven framework lock-in a serious problem, or will things work out in the end? I’d especially love to hear from folks working on non-React frameworks. Is the pain already setting in? Drop your comments below! 👇

Claude wants your government ID now. Local models just won.

Aditya Agarwal — Mon, 18 May 2026 13:17:24 +0000

To use the Claude API by Anthropic, you need to provide your government-issued photo ID and a live selfie. Yes, you read that correctly.

I genuinely thought this was satire when I first saw it. It's not.

Why This Matters

Reports have surfaced that Claude's API access may soon require government-issued photo identification and a real-time selfie for verification. Not for enterprise contracts. Not for classified data. For API access.

Developers immediately reacted with strong emotions. From disbelief to “I knew it wouldn’t work,” the LocalLLaMA community had valid points. Hard to argue with them.

The Privacy Red Line

There's a difference between "sign up with an email" and "hand over your passport." One is friction. The other is a fundamentally different relationship between you and a tool.

Think about what this means in practice. Every prompt you send is now tied to your verified legal identity. Every weird experiment, every edgy test case, every half-baked prototype — all of it linked to your face and your government ID.

I don't care how good Claude is. That's a privacy red line for a lot of devs. 🚩

Local Models Aren't a Compromise Anymore

Here's the thing that makes this story bigger than one company's policy. Local inference has gotten really good.

One year ago, if you wanted to run models locally, you had to be ready to make incredible sacrifices when it comes to quality. That difference is not even as pronounced anymore. Open weight releases like Llama 3 and Qwen are sort of... wildly competitive for most of the developer's work. Programming assistance, summarization, data extraction - all these things, you run them locally and they just... do it.

→ No identity verification
→ No usage logging by a third party
→ No policy changes that retroactively change your relationship with the tool
→ Your data stays on your hardware, period

The hardware story has improved too. You don't need a server rack. A decent GPU and some patience gets you surprisingly far.

Every Requirement Is Free Marketing

This is the aspect that cloud AI providers often fail to understand. Every new hoop they make developers jump through pushes another cohort toward self-hosted alternatives.

API rate limits pushed people to explore local options. Content filters that blocked legitimate use cases pushed more. And now biometric identity verification is going to push the biggest wave yet.

Each restriction is essentially a press release for the local LLM ecosystem. You couldn't buy better marketing if you tried. 😅

I’m not saying cloud AI is dead. Managed APIs still make sense for large-scale production workloads for many teams. But individual developers? Side projects? Anything where you value autonomy over convenience?

The situation has changed significantly.

What This Really Comes Down To

Cloud AI providers are creating isolated environments. They are entitled to do so. But developers have always routed around gatekeepers when the friction gets high enough.

The trend towards identity verification is a really big tell in terms of how those companies view their relationship with customers. They want to know exactly who is using their models and exactly what they’re using them for. That’s a business decision, not a safety one.

Local models provide an alternative proposition. You trade some convenience and peak capability for ownership. Control of your data, your process, and your reputation. For a growing number of developers, that trade is looking better every month.

The open-weight community has momentum. The tools are maturing. And cloud providers keep handing them new reasons to exist. 🏔️

Here's my question for you: Where's your red line? What would a cloud AI provider have to require before you'd invest the time to run models locally?

Agentic coding isn't a trap. Lazy engineering is.

Aditya Agarwal — Sun, 17 May 2026 13:05:03 +0000

The hottest take in developer discourse right now isn't about frameworks or languages. It's about whether AI agents are silently destroying your codebase.

A viral post recently called agentic coding a "liability accelerator." It painted a picture of codebases rotting from the inside out, maintained by developers who no longer understand what they've built. The post spread fast. Engineers nodded along. And I think they're blaming the wrong thing entirely.

The real problem has a name

The issue is not with the representative. It is with the approach that exists, or the absence of it.

A counterpoint article on Dev.to actually provided production logs from a team that was using agents that had very precise well-written specs, and the results were clean output, actually, predictable output, and fewer bugs than we had experienced in their pre-agent workflow.

What made a difference was not the tool used, but rather that an individual took the time to write a solid specification before using the generation tool.

Agents don't skip code review. You do.

This is what goes down in reality when agentic coding flops:

→ Developer gives a vague prompt with no constraints
→ Agent produces plausible-looking code that technically works
→ Developer ships it without reading it carefully
→ Three months later, nobody understands the module

Sound familiar? Now substitute "agent" with "junior developer" or "Stack Overflow copy-paste" or "that contractor we hired for two weeks." The end result is the same. Throughout history, we've found ways to write code that escapes our comprehension. Agents just automated the process.

It's the speed that frightens everyone. I understand. However, it was never the problem. Being reckless was.

The codebase comprehension problem is real but not new

The biggest legitimate concern is that developers stop understanding their own systems. That's worth taking seriously. 🧠

However, we have to admit that this was already in motion. Enormous monorepos, automatically created boilerplate code, dependency trees that no one checks, copying and pasting infrastructure-as-code templates from blog posts. In fact, most teams were already working without a complete understanding of their stack.

Agents were not responsible for the comprehension gap. They simply brought it to our attention.

We shouldn't eliminate the tool. But regard agent output as any other contributed code: review it, test it, understand it before it merges. If your team lacks that discipline, you had a process problem long before you had an AI problem.

What good agentic workflows actually look like

Agents tend to provide real value to teams that have a few things in common:

→ They write detailed specs before prompting — acceptance criteria, edge cases, constraints
→ They review agent output line by line, same as a human PR
→ They use agents for the boring stuff — boilerplate, tests, migrations — not architecture decisions
→ They treat the agent like a fast but inexperienced teammate, not an oracle

All of this is evolutionary. It's engineering discipline being applied to a new-fangled tool. The type of discipline we've always known we needed, but often conveniently overlooked. 😅

The uncomfortable truth

Blaming agents for tech debt is comfortable. It gives us an external villain.

The developers who are now shipping unreviewed agent code are the ones who shipped unreviewed human code before. They are the ones who neglected to write tests. The same ones who approved their PRs on a Friday afternoon. The process may have changed, but their habits haven't.

Writing code in a way that reflects your engineering culture is not a bad thing. It's not a trap. It's a mirror. It shows you what you are. And it does so faster and more honestly than ever before. If you don’t like what you see, the problem isn’t the reflection.

Good process makes agents a multiplier. Bad process makes agents a liability accelerator. The variable was never the agent.

So here's my question: has your team established any specific rules or review practices for agent-generated code, or is it still the Wild West?

Cursor 3 users are getting $2000 bills. Nobody read the pricing page.

Aditya Agarwal — Sat, 09 May 2026 12:58:53 +0000

Developers are waking up to four-figure bills from a code editor. Let that sink in.

Cursor 3 sent out cloud agents along with usage-based billing, and some early adopters got bills $2000+, including one who was mistakenly billed for an annual Ultra subscription. No one read the pricing page because come on, who is going to assume their text editor costs more than their rent?

The Trap Is the Default

What happened was that Cursor introduced new parallel agents that create cloud computing resources for you. When you start a job, it spreads across many threads, and each thread consumes tokens and computing resources.

The problem? The meter is running and there's no big flashing warning. You're in flow state, shipping features, feeling productive. Then the invoice arrives like a bar tab after a blackout.

Usage-Based Pricing Is Predatory by Design

I'll say it plainly: variable pricing on AI dev tools is predatory. It exploits the exact behavior the tool is designed to encourage.

→ The tool is built to make you use it more.
→ Using it more costs you more.
→ There's no natural stopping point or feedback loop.

This is like the gym membership model turned inside out. Gyms make money when you don’t show up. Usage-based AI tools make money when you can’t stop. One of these is a nuisance. The other has the potential to put a freelancer out of business overnight.

The excuse given is always "well, you should have read the pricing page." Okay. However, if your entire business model relies on users not being aware of how much they will be charged, that is not a pricing strategy. It's a trick. 🪤

Flat-Rate Will Win

Competitors like Claude Code are included with flat-rate Claude subscriptions. You pay a fixed amount, you get access, you use it as much as you want. Simple.

Charging a flat-rate works because just like Netflix beat pay-per-view, developers need predictability. We plan for monthly expenditures. We get things expensed by companies. We can't go to our manager and say I know IDE cost $2000 this month but last month it was $47.

→ Predictable costs mean adoption without anxiety.
→ Anxiety-free tools get used more freely.
→ Tools used freely become indispensable.

The irony here is that with flat-rate pricing, you likely create more long-term value. When users aren’t afraid of the bill they use the hell out of it. When users use the hell out of it they become your biggest fans. When users are your biggest fans they bring the whole team on board. But that takes time, and VC-backed tools aren’t exactly patient.

The Real Cost Is Trust

Trust is a costly thing Cursor burns through more rapidly than compute credits. 💸

Developers talk. A few viral screenshots of insane bills and suddenly every potential user hesitates before enabling the new agent features. That hesitation is death for a tool whose entire value proposition is "just let the AI do it."

You can't sell autonomy and then punish people for granting it. Pick one.

The flat-rate model will win this market. Not because it's more generous, but because it aligns incentives correctly. The tool maker profits when you're happy enough to keep subscribing. Not when you accidentally leave an agent running overnight.

I think we're watching the AI dev tools market learn the same lesson SaaS learned a decade ago: surprise bills destroy word-of-mouth faster than any competitor ever could.

Have you been hit with an unexpected bill from any AI tool? What's your ceiling before you'd cancel immediately?