Forem: Aditya Agarwal

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?

Cursor wants you to be a manager now. Most devs will hate it.

Aditya Agarwal — Thu, 07 May 2026 16:08:50 +0000

You were just promoted by Cursor to middle management. Yay. Nobody checked if you were interested. 🎉

Thanks to parallel agent orchestration in Cursor 3, your IDE basically has you standing up a fleet of AI workers spinning up tasks all at once. You've gone from writing code to merging pull requests from robots.

The Feature Nobody Warned You About

Cursor 3 lets you spawn multiple AI agents working in parallel. On paper, it sounds like a productivity dream. In practice, you're now a project manager watching terminals scroll.

Some users reported surprise bills hitting thousands of dollars. That's not an exaggeration — charges spiked because Cursor shifted to a credit-based pricing model and nobody set a budget ceiling.

The Identity Crisis Is Real

The community was almost immediately divided into two groups.

Camp 1: The Architects. These people are all in. They perceive themselves as architects of systems, who oversee the labor of AI. Manually writing code is akin to sweeping the floor when you have a Roomba to do it for you.

Camp 2: The Authors. These developers relate to the art of writing code. They didn't volunteer to be managers. They prefer their hands on the keyboard, not giving constant approvals.

→ Architects say: "I'm 10x more productive directing agents."
→ Authors say: "I became a developer to develop, not to delegate."
→ The tension is real and neither side is wrong.

The Uncomfortable Question

You know what really bothers me? No one actually chose to make this career pivot.

One day you are a software engineer. The next day, your main job is to act as a fleet coordinator. The important skill is no longer coding cleanly but writing clear prompts and catching agent mistakes before they go live.

That's a fundamentally different job. And your IDE just decided you should do it.

The Money Problem Makes It Worse

When unchecked agents run amok in parallel, they actually end up wasting compute. Those $2000 surprise bills? Not a bug — a feature of granting autonomous agents a credit card. 💸

This new situation brings anxiety. Now you're not only evaluating the code quality but also monitoring a meter running. It's like doing ops work in addition to dev work, and you're not getting a raise for it.

Where This Lands

I agree with Cursor that in the future we will be coordinating with other AI agents, but I think they are incorrect about how soon this will happen and about the issue of consent.

Developers should have the opportunity to decide they want to become managers. Forcing developers into management via tooling, and then charging them when agents go rogue, is a pretty nasty way to introduce a career change.

Some of you will become architects and thrive in that role. Some of you will discover a tool that allows you to continue writing code as a human would. Both are fine. 🤷

The real question: Did you become a developer to write a code, or to manage things that write code? I’d love to hear which camp you’re in.

Claude vs Codex debates are astrology for developers

Aditya Agarwal — Wed, 06 May 2026 13:13:35 +0000

The AI tool wars have devolved into horoscope readings with syntax highlighting. People aren't comparing benchmarks. They're defending identities.

I have seen a similar developer commenting, "Claude is the best choice for React work" whereas another comment says, "Claude cannot be used for React, Codex outperforms it" Same person, same React framework, polar opposite impressions. Both are convinced. Neither has a controlled process.

The Unfalsifiability Problem

Here's what makes this astrology and not science: nobody controls for anything.

The outcomes you achieve using Claude are influenced by how you phrase your prompts, the complexity of your project, the programming language you use, the version of the library, and let’s be real – how you feel when you assess the results. And the same goes for Codex. The same goes for Gemini.

The performance of a model changes significantly depending on the language and framework used. For example, the experience of a developer using Rust differs from the one using Python. Additionally, the environment of a person developing a CLI tool is worlds apart from someone else connecting a Next.js app.

However, no one actually means "Claude is better for my specific use case with my specific prompting habits". What they claim is "Claude is better." End of story. 🙄

The Cult Dynamics

Both groups actually display very cult-like tendencies, if you've ever visited a developer forum thread about AI tools.

→ Cherry-picked examples presented as universal truth
→ Dismissal of contradictory experiences as "skill issue"
→ Identity fusion with the tool ("I'm a Claude developer")
→ Tribal hostility toward people who prefer the other option

This is not engineering. It's being a sports fan with a subscription fee.

The wildest part? People in the same thread, using the same model, report wildly contradictory experiences. One person says the model nails TypeScript generics. The next says it hallucinates types constantly. Neither is lying. Both are generalizing from a sample size of "my afternoon."

Your Workflow Is The Variable

Here's an uncomfortable truth nobody likes to hear: the model itself is not as important as the process you build around it.

It is more important how you break down problems before you cue. It is more important how you verify the output. It is more important if you provide context little by little or all at once.

I've had excellent outcomes with both Claude and Codex. I've had junk outcomes with both as well. But it was never about which model I used. It depended on whether I was lazy with my inputs or actually putting some effort and thinking into them.

The Real Question Nobody Asks

"What are the differences between these two models?"

→ What kind of code am I writing most often?
→ How do I structure my prompts — do I give examples or just describe?
→ Am I evaluating output carefully or just vibing on first impressions?
→ Could my "bad experience" have been a bad prompt? 🤔

These questions are dull. They don't spark engagement. They don't allow you to feel superior for choosing the correct team.

However, in reality, they can increase your productivity.

The Takeaway

Let’s not make model preference a personality trait. The way you prompt, the project you choose, and the way you evaluate the outputs are doing 80% of the work. The model is just the last mile. Pick whatever works for your context, revisit it regularly, and don’t dunk on the people who chose differently.

So what I'm asking is have you ever truly switched models for the same task with the same prompt and looked at the outputs right next to each other — or are you vibing as well? 👀

AI is pulling up the ladder on junior devs and seniors don't care

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

Last week someone shared that "AI just killed 2 frontend devs from my team" and when the juniors panicked about it most of the replies from seniors were "well, they should have been more valuable." Yeah, that's the spirit. 🙃

Can I pose a tough question to answer: Where do you suppose you came from?

The Ladder Is Real

Every senior dev I know — myself included — got good by doing junior work. We wrote the CRUD endpoints. We fixed the CSS bugs. We copy-pasted Stack Overflow answers and slowly learned why they worked.

That grunt work wasn't busywork. It was the training ground.

AI Eats the Bottom Rungs First

Over 50,000 organizations already use coding assistants like Copilot. And they are particularly good at providing help with the kind of more routine work that less experienced programmers traditionally work on.

→ Boilerplate components
→ Simple API integrations
→ Bug fixes with obvious stack traces
→ Writing tests for existing code

If a team is able to deliver those things with AI in place of a junior, the junior is just not hired. The learning opportunity disappears before it is even created.

"Just Learn AI Tools" Isn't an Answer

I hear this a lot. "Let juniors just learn to use AI effectively" - fair enough, but use it on what exactly?

You won't improve engineering judgment by asking Copilot to write code for something you don't comprehend yet. It’s similar to suggesting that someone can learn to be a chef by just finding a better way to order DoorDash.

The gap in skills between those who can manipulate AI and those who can design systems is vast. Junior positions used to serve as a bridge to cross that gap. Now, we're destroying the bridge and expecting people to make the leap.

Seniors Are Complicit

What is most concerning to me, is that those who are rejoicing over AI taking over the mundane tasks of junior employees are the very same individuals who will be lamenting in five years that “nobody knows how to actually build anything anymore.”

You can't strip-mine the talent pipeline and then act surprised when there's no talent. 🤷

The current business strategy in this industry is to optimize headcount for this specific quarter regardless of the consequences for the future, creating a generational knowledge gap. For every junior dev that the industry rejects today, we're down a senior dev in 2030.

This Isn't Anti-AI

I use AI tools in my daily work. They are actually helpful. This is not a Luddite perspective.

We must be truthful about the compromise. Generating output faster today, but less competent engineers tomorrow, is not a victory without a cost. It is a debt - and as with any debt, it will have to be paid by someone in the end.

→ Companies could create AI-augmented apprenticeship roles
→ Teams could pair juniors with AI and a mentor, not AI instead of a mentor
→ Senior devs could advocate for junior headcount instead of shrugging

All of this can be prevented if we stop pretending that the pipeline will automatically be replenished. 🔥

The Question Nobody Wants to Answer

What is the strategy if junior positions are not available to juniors, and juniors can't become seniors without first being juniors?

Are we just hoping the current generation of seniors lives forever?

I'm eager to hear from hiring managers, team leads, and juniors who are currently on the hunt. What does the process of actually breaking in right now look like?

Gmail renders at 5fps and nobody cares. Performance culture is a cope.

Aditya Agarwal — Mon, 04 May 2026 19:11:22 +0000

Despite scrolling at approximately 5 frames per second in a crowded inbox, billions of people use Gmail every single day without mass-migrating to a “faster” email client.

This should indicate something uncomfortable about how we spend our time as engineers.

The Inconvenient Truth About Speed

We treat performance like a moral virtue. A slow app is a bad app, built by lazy developers. A fast app is a good app, built by craftspeople.

However, the reality is different. Gmail performs slowly. Slack consumes so much RAM that it seems to be teaching a language model. And whenever you access a board in Jira, you feel like the universe is on the verge of heat death. These products are leading solutions that are being used by hundreds of millions of users.

Fast Alternatives Keep Losing

Here's the recurring sequence I observe:

→ A popular app is visibly slow
→ Someone builds a "blazing fast" alternative
→ Developers celebrate on forums and share benchmark screenshots
→ The alternative tops out at a few thousand users and stalls

Speed-focused alternatives to mainstream apps consistently fail in the market. Not because speed doesn't matter at all. But because it matters way less than we think relative to distribution, integrations, habit, and trust.

Performance isn't the reason the quick email client or the rapid project tracker loses to the alternatives mentioned by the author. It's because their respective companies are already using Google Workspace and have three years of Jira history. Performance might be a tiebreaker, but it's hardly ever the cause for an actual tie.

Lighthouse Scores Are Developer Vanity Metrics

I have witnessed teams that burned entire sprints just to improve their Lighthouse scores, even though their product had almost no users. I have been that team. It's a comfortable process to focus on, the numbers increase, the graphs turn green.

Optimizing rendering performance for an application used by twelve people is not engineering craft. It’s engineering narcissism. You are literally polishing a trophy case in an empty building.

A recurring debate in developer circles is whether successful apps are essentially “tolerated garbage”. That’s the wrong way to think about it. They’re not garbage. They’re good enough at performance, while excelling at the things that actually drive adoption.

Users don't interact with your application through a Lighthouse audit. They interact with it while trying to get something done. If your workflow solves their problem, they're going to put up with a less than optimal scroll. They'll sit through a 200ms-longer load time. They'll complain and use it.

When Performance Actually Matters

I'm not saying performance is irrelevant. There are real thresholds where slowness kills products:

→ E-commerce checkout flows where every 100ms correlates with conversion drops
→ Real-time tools like video editors or trading platforms where latency is the product
→ Mobile web in emerging markets on 3G connections

These are real-world performance-critical situations. However, the majority of us are not developing those types of applications. We are developing CRUD apps, dashboards, and internal tools where the real bottleneck is if anyone would even want to use the application.

Working tirelessly for a week to reduce load time by 40ms on a bundle, before you’ve gotten any validation that people actually want what you’re building is not “disciplined”, it’s procrastination. It’s easier to prematurely optimize a Webpack config than to talk to users.

The Real Cope

A culture of performance doesn’t do much, if anything, for the user. Realistically, it’s mostly for us. It gives us something tangible and measurable to point to and feel like we’re competent or talented. Green scores. Fast builds. Small bundles. These things feel good because they’re simple and easy to understand. They’re also usually easy to control. Which is nice because most of the important, real answers are scary or hard — terrifyingly ambiguous, or just difficult and take time to reveal themselves.

Performance is still important to me but I think I just try to care about it in proportion to where my product actually is. Pre-product-market-fit, I ship fast and ugly. Post-traction, I optimize what users actually complain about. Not what my dev tools highlight in red.

Ship the slow thing. Find out if anyone wants it. Then make it fast. 🔥

How side projects die is in reverse order.

What's the most time you've spent optimizing something that turned out not to matter?

OpenAI Codex is free right now. That's the trap.

Aditya Agarwal — Mon, 04 May 2026 16:38:42 +0000

We all understand that free services from a company that is spending billions on computing power won't remain free. It's inevitable. But the reality is we are all already using Codex.

OpenAI recently announced that Codex was made available in ChatGPT for free, but access was limited. At the moment, developers can use code completions, refactorings, or generate entire functions without spending any money, but they have limited usage. And thousands of developers have been already incorporating it into their daily routines.

That's the point.

The Dealer Playbook

This isn't new. It's the oldest growth hack in tech. Give it away until the switching cost is too high to leave.

Slack has done it. Figma has done it. AWS has done it using free tier credits that for some reason consistently run out just when your startup is unable to migrate off them. OpenAI is simply executing the maneuver with a product that interfaces with your real codebase.

Each time you scribe a prompt, each shortcut you memorize to "correct this function," every manual you choose to bypass as Codex provides a prompt response — you're accumulating lock-in similar to technical debt. It builds up quietly and exponentially.

The Quality Tradeoff Nobody Talks About Honestly

Here's what I continue to see in dev conversations: Codex performs quickly. It's faster than other options and people can tell. But the quality of the code it produces? Not as good.

Developers are actively debating Codex versus Claude right now. The tradeoff keeps coming up:

→ Codex gives you speed. You get answers quickly and move on.
→ Claude gives you cleaner output. But it's slower, and it's not free.
→ Speed wins in the moment. Quality wins at 2 AM when you're debugging.

The issue is that bad code that gets there fast gives the impression of being efficient. You ship faster today. Tomorrow, you debug even more. However, at that point, you have already integrated Codex with your muscle. 🎯

Dependency Is the Product

Codex will need to be the coding assistant you grab like second nature for any OpenAI projects.

Once everyone in your team is using it, when your junior developers are capable of coding with it helping as a tool, when your PR (pull request) reviews consider that the output is generated with AI assistance, when your sprint velocity is taking into account the acceleration this tool provides, at that point, you should start considering the costs associated with using it.

And you'll pay it. Because rewiring a team's workflow is harder than just eating the cost.

I still subscribe to tools that I find somewhat annoying for the same reason. The cost of switching is not the subscription money. It’s the cognitive load. It’s building new habits. It’s the painful week of everything not working. 😅

What I'm Actually Doing About It

I don't love Codex. But free tools are free tools. Boycotting them would be silly.

However, I am multitasking:

→ Keeping my prompts portable. I write them in a way that works across models. No Codex-specific syntax dependencies.
→ Not letting it replace understanding. If I can't explain what the generated code does, I rewrite it myself.

We simply aim to make use of the free tier without being exploited as a product of the free tier.

The Takeaway

OpenAI is actually subsidizing your compute today because it wants the value of your future dependency tomorrow. That's not evil. It's just business. But pretending it's charity is foolish.

Use it. Don't need it. That's the only play that keeps you flexible when the invoice arrives. 💸

I have a question for you. Has your team integrated Codex into its standard workflow yet? And if they have, how do you plan to phase it out when the pricing becomes more competitive?

The junior developer pipeline is drying up and nobody's panicking enough

Aditya Agarwal — Mon, 04 May 2026 13:38:46 +0000

The fact that we're slowly removing the apprenticeship layer and passing it off as "productivity gains" should be far more alarming.

Just imagine. The kind of work that is best suited for AI, such as boilerplate code, simple CRUD endpoints, and basic component wiring, is actually similar to the work that helps in training junior developers. It was not that we were working on those tasks because they were difficult, but rather because they are the tasks that build our understanding of how software works.

The pipeline problem

Every senior developer alive today was once a junior who learned by doing boring work. You wired up forms. You wrote repetitive tests. You copy-pasted patterns until they became intuition.

Today, companies perceive equivalent work and ask “AI is able to do this quickly, why recruit a junior? Job ads reveal the reality: relative to senior posts, the number of junior developer positions has decreased by 2024 and has continued to decline to 2025. The access ramp gets steeper as we act as if the road is in good condition.

We're eating the seed corn 🌽

What concerns me the most is that the industry is focusing on short-term gains, without realizing that it is actually leading to a long-term crisis.

→ Fewer juniors hired today means fewer mid-levels in 3 years
→ Fewer mid-levels means fewer seniors in 6 years
→ The "talent shortage" everyone complains about? We're actively manufacturing the next one

Companies report hiring fewer juniors because AI handles their traditional workload. Online dev communities are full of people debating whether entry-level frontend roles even exist anymore. These aren't hypotheticals. This is happening now.

"Just learn AI tools" isn't an answer

A recurring statement I come across is that "Juniors should just learn to use AI and they'll be fine." Okay. But could you be more specific about what they should use AI for?

If you have never constructed a mental model regarding how state is propagated in an application, asking an LLM to make one for you doesn't help you learn. You are a passenger, not a driver. You can't debug what you don't know. You can't architect what you have not crafted from scratch.

Using AI to assist in development is great for seniors because of course, the mental models are already there. They know when the AI is wrong. A junior using AI without the context of experience is just writing code they can't conceptualize. That's not learning. That's copying homework. 😅

What would actually help

→ Intentional apprenticeship programs — companies investing in juniors despite the short-term cost, because they understand the pipeline
→ AI as training wheels, not replacement — let juniors write it first, then compare with AI output as a learning tool
→ Senior devs mentoring deliberately — code review matters more now, not less

This issue cannot be solved by the market alone. Markets are designed to perform best in the short term. The junior pipeline requires a ten-year commitment that ultimately results in institutional expertise, preservation of the organizational culture, and the presence of individuals who truly comprehend your codebase.

The uncomfortable truth

We got ours. We had the luxury of learning by doing tedious work in environments that tolerated our inexperience. Pulling that ladder up behind us — even unintentionally — is a choice with consequences.

Each time we throw a "we replaced two junior roles with Copilot" party, we are also dancing on the grave of a hypothetical future senior developer. 💀

So I’d love to know: What are you doing if you’re in a position of hiring or decision making to ensure the junior pipeline is running? Or are we all crossing our fingers someone else figures this out?

React won't die because AI won't let it

Aditya Agarwal — Sun, 03 May 2026 13:08:50 +0000

All frameworks are eventually replaced. React is probably the first that won’t be.

It's not the best language out there, it's not the language developers love the most, it's the language the robots just won't quit.

The Default Output Problem

Request ChatGPT to develop a todo app for you. You'll receive React. Request Copilot to generate the basic structure of a component. React. Request Claude to design a prototype for a dashboard. React.

It's not a conspiracy theory, it's the power of statistics. React has been the leader in frontend development for 10 years. This means that 10 years of Stack Overflow responses, blog entries, tutorials, and open-source repos are included by default in every major LLM.

Newer frameworks like Solid and Svelte are genuinely excellent. They solve real problems React still struggles with. But they have a fraction of the written material online, which means they have a fraction of the representation in AI training corpora.

AI Assistants Are the New Defaults

Think about how many developers now start projects by prompting an AI. Not all of them, sure. But enough to matter.

If a junior developer asks an AI for advice, and the response is React code, it's not a neutral suggestion. It's a recommendation machine with the most significant bias in the world towards a framework. Then that junior developer goes and ships React, blogs about React, and trains the next model on React.

→ More React code in the wild means more React in future training data.
→ More React in training data means AI generates even more React.
→ The loop compounds every single day.

This is a force that no number of "Svelte has a better developer experience" blog posts can overcome. Not that the point is invalid. It's just that there are more of these articles.

npm Downloads Don't Lie

The npm download numbers of React continue to rise. Every quarter, a tweet claims that React is dead. Every quarter, the graph goes up.

The critics who express their views are correct about React having some shortcomings. We had to deal with class components for many years. The mental model of hooks confuses many people. Server components can be very difficult to understand.

However, all of that becomes irrelevant if the complete AI-aided development pipeline is set to React output. Previously, framework adoption was determined by developer preference, but now it's by AI defaults. 🤖

This Isn't About Quality Anymore

I need to clarify that I'm not saying React should be in this role. The reactivity model of Solid is better. The compiler approach of Svelte is beautiful. The learning curve of Vue is easier.

But "deserves" doesn't drive adoption at scale. Distribution does. And React now has the most powerful distribution channel in the history of software development: it's the default answer every AI gives to every frontend question.

The winners going forward won’t be the frameworks with the best APIs. They’ll be the ones creating enough training data to change the default AI. That’s a brutal, unglamorous grind. And React is a decade ahead.

What Would It Take to Break the Cycle?

To be honest, I don't think there's anything other than a significant AI company intentionally biasing the model towards another framework that would fix this. Or a framework so unique that the prompts would have to include its name to sample it each time.

Sure, when the default prompt is to create a "web app" and the default response is React, we continue this pattern. The React loop isn't about developers making a free choice anymore. It's become an emergent reaction to how LLMs operate. 😅

The tech industry often discusses the concept of using the best tool for a job. However, if your AI assistant provides you with only one tool, you will have to adjust the job to fit that tool.

So here's what I want to know: if AI training data locks in today's winners permanently, does framework innovation even matter anymore?

14 years at one company broke a senior dev's career. Loyalty is a scam.

Aditya Agarwal — Fri, 01 May 2026 13:25:48 +0000

A senior frontend dev spent 14 years at one company, got laid off, and discovered they couldn't pass a modern interview. That's not a cautionary tale. That's the system working as designed.

I keep thinking about this story. It surfaced in a developer community known for strict anti-venting rules, and it still resonated hard. That tells you something about how many people saw themselves in it.

The Comfort Trap

Fourteen years is a long time. Long enough to become the person everyone asks about that one legacy system. Long enough to stop learning things that scare you.

The dev reported being completely unprepared for today's job market. Not because they were bad at their job. Because their job had quietly stopped demanding growth years ago.

Loyalty Is a One-Way Contract

People never talk about what being comfortable costs you: the company isn’t being loyal, it’s being efficient. You’re a known quantity. You have institutional knowledge. And you’re probably underpaid compared to the market.

The day the spreadsheet says your role is a cost and not a benefit, fourteen years of “loyalty” goes out the window in a single calendar invite with HR. There’s no pep talk. No time to upskill. Just the severance package they already calculated and a LinkedIn that says “Single-company career.”

I’ve seen it done to people I work with. It sucks every time.

Job-Hopping Is Self-Defense

I used to think multiple moves looked flaky. Now I think staying too long without growing is the riskier bet. Here’s why:

→ Every job switch forces you to learn new codebases, new tools, new team dynamics
→ Interviews keep your skills market-tested, not just employer-tested
→ Compensation resets happen at transitions, not during annual reviews
→ You build a network across companies instead of a reputation inside one

It’s not about running from a good thing in a bad day. But if you haven’t interviewed in three years, you have no clue what you’re worth or what seams are stretching. That’s not solid ground. That’s a blindfold. 🎯

The Real Problem Is Invisible Decay

Skills don't rot overnight. They rot over years while you feel productive. You ship features, close tickets, mentor juniors. Everything feels fine.

Then one day you're in a take-home assignment using a framework you've only read about. Or you're whiteboarding system design patterns your company never needed. The gap isn't small. It's a canyon you didn't notice forming because you never looked down.

What Actually Works

I don't think the answer is "hop every 18 months" like some career advice suggests. The answer is intentional pressure-testing:

→ Interview once a year even if you're happy — treat it like a health check
→ Build side projects with tools your company doesn't use
→ Track what the market demands and honestly assess your gaps
→ Have a "what if I got laid off tomorrow" plan that isn't panic

Staying somewhere for a decade can be great if you're genuinely growing. But growth means discomfort. If you haven't been uncomfortable at work in a while, you might just be stagnating with a senior title. 😅

The Takeaway

The industry doesn't reward loyalty. It rewards optionality. The developers who survive layoffs unscathed aren't the ones who never get cut — they're the ones who can land somewhere new within weeks because they never stopped being marketable.

Comfort is nice. Comfort without awareness is a trap with a delayed trigger.

Have you ever stayed somewhere too long and only realized it after leaving? What was the wake-up call?

Taste" is the new 10x. Senior devs who can't curate AI output are cooked.

Aditya Agarwal — Fri, 01 May 2026 10:12:07 +0000

Writing code is easily done, but identifying the code that ought to be available is what's difficult nowadays.

Many experienced engineers are having a conversation regarding the capability of "taste" to be the most crucial ability of the AI age. "Taste" here doesn't refer to fashion. Instead, it’s about judgment. It is about being able to assess the AI output and understand precisely what’s inappropriate about it, the type of thing that will add up as technical debt, before it's pushed through.

Why This Matters Right Now

Junior-level AI virtually generates code for free thanks to AI. You can develop a feature immediately that would have needed an entire day to build. But being "functional" and being "ready to ship" are not equivalent to each other.

The space amid those two terms is where skilled engineers show their real value. Or where they reveal they have been slacking off.

Taste Is Not Vibes

I am referring to taste, which is how to distinguish code that needs to be written. 2 decades of experience, and here's what I will reveal about this taste concept. It's not some type of cryptic, elusive instinct. It's a pattern recognition that develops as you observe programs succeed and fail for years.

→ Knowing that a 200-line abstraction will save you now but cost you in six months.
→ Recognizing when AI output follows the "happy path" but ignores every edge case your users will hit.
→ Feeling the friction in an API surface before anyone files a bug.

There is an ongoing debate: does having good taste is enough or it should be combined with solid architecture knowledge? In my opinion, having good taste without architecture knowledge is mere personal preference. Having architecture knowledge without good taste leads to unnecessary complexity. You must have both. However, there is a lack of good taste right now because no one is educating for it.

The Role Shift Nobody Prepared For

Earlier, senior developers were appreciated because they could build things quickly and well. Now AI builds things quickly. The "well" part depends entirely on you.

Your role is more similar to a film director than a construction worker. You're inspecting, selecting, altering. You will have to reject 80% of automatically generated content and understand the reason behind it. This skill is completely different from writing code independently.

If your only advantage is typing speed and syntax, you are already in distress. In fact, these were never senior skills — it's just that the industry has allowed some people to think that way. 🫠

How You Build Taste

You can't read a book about it. You build taste by shipping things, watching them break, and developing strong opinions about why.

→ Review more code than you write. Especially code that's been in production for a year.
→ Study systems that aged well. Ask what decisions made them resilient.
→ When AI gives you output, don't accept it — interrogate it. What would you change? Why?

The engineers I respect most can look at a PR and say "this works but it's wrong" and then articulate the reason in one sentence. That's taste. It's specific, defensible, and earned. 🎯

The Uncomfortable Truth

Some senior engineers are going to struggle here. Not because they lack knowledge, but because they never developed the editorial instinct. They were builders, not curators. And the industry rewarded building for two decades.

That era is ending. The 10x engineer of 2025 isn't writing 10x more code. They're preventing 10x more bad code from shipping.

So here's what I want to know: Do you think "taste" is a real, trainable skill — or is it just gatekeeping dressed up in a new outfit?

React won't die because LLMs won't let it

Aditya Agarwal — Thu, 30 Apr 2026 19:16:00 +0000

Almost all AI programming tools use React as the standard. This single piece of information will have a greater influence on frontend development in the next ten years than any technological indicator ever will.

Consider this: When a million engineers ask ChatGPT to “create a todo app for me”, they receive React. When somebody uses v0 or Bolt to bootstrap a SaaS dashboard, they get Next.js. React won by being the default.

The Training Data Flywheel

LLMs are only as good as the data they’re trained on. The web contains more React examples than any other code. Thus, LLMs create React examples more proficiently than anything else.

This makes the circle virtually unbreakable. More React results in more React in the training data to follow. More React in the data trains a better React model. A better React model leads to more people producing React. 🔄

→ React dominates training corpora
→ LLMs generate React with higher quality and confidence
→ AI-powered tools choose React as their default
→ New projects ship React, producing more training data
→ The cycle repeats

Svelte and Solid are genuinely excellent. But they have a fraction of the representation in the data that shapes these models. It doesn't matter if your framework is technically superior when the robots haven't read enough of it to be fluent.

Vibe Coding Is a React Monoculture

"Vibe coding" — where you describe what you want and an AI builds it — is exploding. And it's overwhelmingly React.

v0 generates React components. Bolt scaffolds Next.js apps. When non-technical founders prototype their ideas with AI, they're unknowingly casting a vote for React's continued dominance. They don't care about the framework. They care that it works. And React works because the AI knows it best.

This is the worst possible news for framework diversity. Innovation used to spread through blog posts, conference talks, and developer curiosity. Now adoption spreads through whatever the LLM spits out first.

Why This Should Bother You (Even If You Love React)

I don't hate React. It's fine. It does the job. But "fine" shouldn't win by default forever.

Monocultures are fragile. They stifle the experimentation that gave us hooks, signals, compiled reactivity, and server components in the first place. If every new project starts as React because an AI decided, we lose the pressure that forces frameworks to evolve.

The irony is brutal: React's best features were inspired by ideas from smaller frameworks. Signals came from Solid. Compilation came from Svelte. If those frameworks can't gain adoption because LLMs ignore them, React loses its own innovation pipeline. 😬

What Would It Take to Break the Loop?

Honestly? I'm not sure it can be broken organically. A few things that might help:

→ AI tool builders intentionally offering framework choice upfront
→ Smaller frameworks investing heavily in structured training data and documentation
→ A major LLM provider partnering with a non-React framework as a first-class target

But the incentives don't align. Tool builders want reliable output. Reliable output means React. Nobody's going to ship a worse product to promote ecosystem diversity out of principle.

The Uncomfortable Truth

React is unlikely to become obsolete because it's the best tool for the job. It's unlikely to fade out because it has the largest, most engaged community. It's no longer possible to have an alternative perspective because the machines are the ones imposing it on us, and we are increasingly accepting the decisions of the machines.

There’s no conspiracy here, just logic. The amount of data used to train the model has created a force of gravity, and every line of code generated by AI makes it stronger. 🕳️

So the real issue is: if you're starting a new project today and an AI presents you with React —will you take it, or will you resist the current? And if you do choose to resist, why?

AI doesn't replace junior devs. It makes senior devs do junior work.

Aditya Agarwal — Wed, 29 Apr 2026 19:09:18 +0000

Here's the deal: companies are firing junior developers and handing their work to AI. But that work doesn't disappear. It just rolls uphill to the most expensive people in the building.

The "replace juniors with AI" strategy sounds brilliant in a board meeting. In practice, it's a false economy that burns out your best engineers.

The Hospital Secretary Problem

There's a well-known pattern in healthcare. Hospitals cut administrative staff to save money. Suddenly, doctors — the highest-paid people in the building — are filling out forms, scheduling appointments, and doing data entry.

The work didn't vanish. It just got redistributed to people who cost 5x more per hour.

That's exactly what's happening in software right now. Multiple companies have publicly reduced junior hiring, citing AI capabilities. The pitch is simple: "Copilot can do what a junior does."

Except it can't. Not without supervision.

Seniors Are Now Babysitting LLMs

Here's what actually happens when you replace a junior with an AI tool. A senior engineer prompts the LLM. They review the output. They catch the subtle bugs. They refactor the weird architectural choices. They fix the hallucinated API calls.

Senior engineers are increasingly reporting that they spend significant time reviewing and fixing AI-generated code. That's not leverage. That's a new job responsibility nobody signed up for. 🫠

→ Before: Senior architects systems, junior implements under guidance, senior reviews.
→ After: Senior architects systems, prompts AI, reviews AI output, fixes AI output, then reviews their own fixes.

You didn't remove the junior's workload. You removed the junior and gave a senior a worse version of the same task — one that looks done but requires forensic inspection.

The Hidden Cost Nobody's Tracking

The real damage isn't just salary arbitrage gone wrong. It's attention.

A senior fixing AI slop isn't designing systems. They're not mentoring. They're not making the architectural calls that actually move the product forward. You're paying principal-engineer rates for code-review grunt work.

And let me get to the real part that keeps me up at night: if the junior roles are the training ground, you cut them off and you're eating your seed corn. In five years, you'll have a generation gap with nobody ready to step into senior roles.

The pipeline doesn't refill itself. 🔥

The Honest Math

If you're a manager considering this trade, do the real math:

→ Junior salary: X
→ Senior time spent babysitting AI: Y hours × senior hourly rate
→ Opportunity cost of senior not doing senior work: enormous and invisible

That second line item never shows up in the "AI savings" spreadsheet. But it's real. Every senior who spends an afternoon debugging AI-generated garbage is an afternoon of system design that didn't happen.

What Actually Works

AI is a great amplifier for juniors, not a replacement for them. Give a junior developer AI tools and senior mentorship? Now you've got acceleration. The junior learns faster. The senior stays focused on high-leverage work. The AI handles boilerplate under human supervision at the appropriate pay grade.

That's the model that makes economic sense. Not "fire the cheap people and make the expensive people do their jobs plus a new meta-job."

The companies cutting junior roles aren't saving money. They're hiding costs in senior burnout and pretending the spreadsheet tells the whole story.

What's your experience? Are you a senior spending more time wrangling AI output than you expected? Or a junior watching doors close? I'd love to hear how this is playing out on your team.