DEV Community: M. Adhitya

Junior Developers Aren't Being Replaced by AI. Senior Developers Who Use AI Are Replacing Both.

M. Adhitya — Wed, 10 Jun 2026 17:12:16 +0000

Everyone's been having the wrong argument.

For two years, the debate has been: "Will AI replace junior developers?"

The answer is no. The real answer is worse.

Senior developers who use AI are now doing the work of an entire team. And companies are starting to notice.

What actually changed

A year ago, a typical SaaS startup needed:

2 senior devs
2–3 junior devs
1 DevOps
1 part-time designer

Today, solo founders and small teams of 2–3 are shipping what used to require that entire org. Not because AI writes perfect code — it doesn't. But because the bottleneck was never typing.

The bottleneck was decision-making at speed.

AI removed the cost of exploring a wrong path. You can prototype three approaches in the time it used to take to argue about one in a standup.

The math nobody wants to say out loud

A senior dev with 5 years of experience and solid AI tooling can now output what used to require a 4-person team — not in quality, but in throughput.

Entry-level engineering job postings dropped ~35% year-over-year in 2024. Not because AI replaced juniors. Because one experienced person with AI does what three people used to do.

The juniors who were supposed to fill those seats never got hired.

Where junior developers actually are right now

They're split into two groups:

Group 1: The ones who treated AI as a shortcut.
They use Copilot to autocomplete. They paste errors into ChatGPT. They can ship fast but can't debug what they didn't write. When something breaks in production at 2am, they're lost.

Group 2: The ones who used AI to compress years of learning.
They don't just accept AI output — they read it, question it, break it. They're learning distributed systems, auth flows, database design faster than any previous generation because they can ask infinite questions to an infinitely patient tutor.

Group 2 is going to be terrifying in three years.
Group 1 is going to be unemployable in three years.

The uncomfortable truth about vibe coding

"Vibe coding" — shipping apps by prompting without really understanding what you're building — works. For demos. For MVPs. For the first 500 users.

Then the codebase becomes unmaintainable. Then a security hole appears that you don't understand. Then a senior dev looks at your repo and rewrites it in a weekend.

Here's what nobody says: vibe coding is fine if you're learning while doing it. It's dangerous if you think shipping is the same as understanding.

The senior devs who are thriving right now aren't vibe coding. They're using AI to move faster on things they already understand. That's a completely different skill.

What this means if you're early in your career

Stop worrying about whether AI will take your job. Start worrying about whether you're building the foundation that lets you use AI at the level a senior dev uses it.

That means:

Read the code AI writes. Every line. Ask why.
Build things that break. And fix them yourself first.
Understand one layer deeper than your stack. Always.
Ship. Nothing teaches production thinking like production.

The developers who win the next five years aren't the ones who used AI the most. They're the ones who used AI to learn faster than was ever previously possible — and built genuine depth while doing it.

The senior dev problem nobody's talking about

Senior developers who are not using AI are being lapped. Fast.

Not because they're less talented. Because velocity is now a compounding advantage. The developer who ships 3x faster has 3x more feedback, 3x more iterations, and learns 3x more — and that gap widens every month.

"I prefer to do it without AI" is a legitimate personal preference. It is not a competitive strategy.

The actual prediction

In five years:

There will be fewer developer jobs at large companies.
There will be more developer-founded companies than ever before.
The developers who survive inside large companies will be the ones who made themselves 10x multipliers.
The developers who thrive outside large companies will be the ones who built things that generate revenue, not just commits.

The question was never "AI vs. developers."

The question is: what kind of developer are you becoming while everyone else is having that argument?

Building production apps and open-source tools at Rewrite Labs. Writing about building things that matter.

How I Added a Razorpay Paywall to My React App in 10 Minutes

M. Adhitya — Sat, 06 Jun 2026 13:14:36 +0000

Every time I built a new app, I copy-pasted the same paywall code.

The Razorpay subscription logic. The gate component that blocks UI for free users. The pricing modal with the monthly/yearly toggle. The usePro hook that checks localStorage and optionally pings a verification endpoint.

Same code. Every app. Every time.

So I extracted it all into react-premium-gate — a zero-dependency React library with three exports that handle the entire Razorpay subscription flow.

What's in the box

Three things and nothing else:

usePro — a hook that manages Pro status. It reads a subscription ID from localStorage, optionally verifies it against your backend, and gives you isPro, loading, activatePro, and deactivatePro.

PremiumGate — a component that replaces any Pro-only UI with a paywall card. Fully customisable title, description, icon, button text, and accent colour.

PricingModal — a bottom-sheet pricing modal with a monthly/yearly plan toggle, a save badge, and a loading state for while the Razorpay checkout is opening.

Plus three copy-paste Vercel API templates for creating subscriptions, verifying HMAC payment signatures, and checking subscription status server-side.

Install

npm install react-premium-gate

Zero runtime dependencies. Works with React 17+.

The flow in plain English

User hits a Pro feature → PremiumGate shows instead of the real UI
User clicks Upgrade → PricingModal opens
User picks a plan → your handler calls /api/create-subscription
Razorpay checkout opens → user pays
Razorpay calls your handler → you call /api/verify-payment
Signature is valid → call activatePro(subscriptionId)
isPro flips to true → real UI renders, modal closes

That's the entire flow. The library handles steps 1, 2, and 7. The templates handle steps 3 and 5. You wire them together in about 10 minutes.

Why Razorpay

If you're building for Indian users, Razorpay is the only serious option. Stripe doesn't support INR subscriptions properly. Razorpay has native UPI, net banking, and card support, plus a generous free tier.

The HMAC signature verification in the template is the part most tutorials get wrong — they skip it entirely, which means anyone can fake a successful payment. The template handles it correctly with crypto.createHmac.

Customisation

Every visual element is a prop. Swap the accent colour from the default gold to match your brand. Change the icon from 👑 to whatever fits. Override the button text to show your price — "Upgrade to Pro — ₹399/mo" converts better than a generic label.

The usePro hook's storageKey is configurable so it doesn't clash if you're running multiple apps on the same domain.

Why I Keep My Apps Private and My Libraries Public

M. Adhitya — Sat, 06 Jun 2026 09:04:34 +0000

Every project I build falls into one of two buckets.

Apps go private. Libraries go public.

This isn't an accident. It's the most important strategic decision I've made as a solo builder, and I want to explain exactly why.

Apps are IP

When you build a product people pay for, the code is the least valuable part.

The valuable parts are the distribution, the brand, the user trust, and the specific decisions you made that nobody else can see. Putting the source code on GitHub doesn't help you — it just hands your architecture to anyone who wants to copy it before you've had a chance to build a moat.

My apps under Rewrite Labs are all closed source. No one can fork them, no one can inspect the payment flow, no one can see how I structured the AI logic. That's intentional.

Open sourcing an app you're trying to monetize is like publishing your playbook before the game starts.

Libraries are reputation

Every library I've shipped started as code I pulled out of an app because it was useful enough to stand alone.

When I built a Razorpay paywall component for one of my apps, I extracted it into react-premium-gate and published it on npm. When I got tired of LangChain for simple LLM chaining, I wrote groq-chain and put it on PyPI. When I needed LLM calls routed by cost and complexity, I built llm-router and open sourced it.

None of these hurt my apps by being public. They're infrastructure, not product.

What they do is build a public record of how I think about problems. Any developer who finds one of my libraries on GitHub gets a real signal — not a portfolio project, not a tutorial clone, but something I built because I needed it and decided to share.

That's the kind of proof of work that actually matters.

The separation is the strategy

Here's the thing most builders miss: your apps and your libraries serve completely different audiences.

Your apps serve your users. They don't care about the code. They care about whether the product solves their problem.

Your libraries serve other developers. They don't care about your product. They care about whether the code solves their problem.

Mixing these up — open sourcing apps for clout, or keeping libraries private to protect them — gets you the worst of both worlds. You give away your product edge and build no developer reputation.

Keep them separate and each one compounds on its own terms.

What this looks like in practice

I currently have 7 live apps under Rewrite Labs — all private, all on Vercel, all monetized. None of them are on my GitHub.

I also have 7 open source libraries — all MIT, all on GitHub at github.com/iamadhitya1, all published on npm or PyPI. None of them are products by themselves.

The apps pay for the time I spend on the libraries. The libraries build the credibility that makes people trust the apps. They feed each other without competing with each other.

The rule

If it makes money, keep it private.

If it makes you credible, make it public.

That's it. Everything else is just execution.

Here is the URL to Rewrite Labs and the tools we offer - https://rewritelabs.vercel.app/

You can find all of the apps I built here - https://github.com/iamadhitya1

I'm a 21-Year-Old Student Who Shipped 7 AI Apps and 7 Open Source Libraries. Here's the Strategy.

M. Adhitya — Sat, 06 Jun 2026 08:36:04 +0000

I'm a third-year engineering student at IITRAM, Ahmedabad.

In the last year I shipped 7 production AI apps and 7 open source libraries — all while attending college full-time. No team. No funding. No co-founder.

Here's exactly how.

Build silently. Ship publicly.

Most people announce what they're building, get dopamine from the likes, lose motivation when it gets hard, and quietly drop it.

I stopped announcing. I started shipping.

My apps are all private repos. No previews, no "coming soon" posts. I build until they're live, then I tell people. The libraries are the opposite — public MIT, on npm and PyPI, maintained in the open. That's the proof of work. The apps are the business.

Why libraries, not just apps

Apps are IP. Libraries are reputation.

Every time I extracted reusable logic from an app into a standalone library, two things happened — the app got cleaner, and I got a public artifact that developers could find and star.

My libraries cover things I genuinely needed and couldn't find done well: LLM routing by prompt complexity, Razorpay paywalls for React, offline-first sync engines, fraud detection you can pip install.

None of them are moonshots. All of them solve one specific problem, have zero runtime dependencies, and fit in a README.

The stack I stopped reconsidering

Decision fatigue kills momentum. I picked a stack and stuck with it.

React + Vite + Tailwind for the frontend. Supabase for the database. Groq for AI inference. Razorpay for payments. Vercel for deploys.

Every new app starts from this. I'm not re-evaluating frameworks every project. I'm building.

How I decide what to build

One filter: would I pay for this myself?

Not "would someone pay for this" — would I, personally, right now, pull out my card.

If yes, I build it. If no, I skip it no matter how clever the idea sounds. This filter has killed a lot of bad ideas fast and saved me hundreds of hours.

The mistake most student builders make

They spend 80% of their time building and 20% on getting users.

It should be 60/40 at minimum.

Building is the comfortable part. Getting strangers who don't know you to care about what you made — that's the hard part. Most people avoid it by adding more features instead.

Your product doesn't need one more feature. It needs ten more users.

What I've shipped

Libraries (all MIT, all on GitHub at github.com/iamadhitya1):

llm-router — routes prompts to the right LLM by complexity and cost
react-premium-gate — Razorpay subscription paywall for React
groq-chain — Python LLM chaining with a .step() builder API
react-offline-first — offline-first React template with IndexedDB sync
fraud-shield — pip-installable fraud detection with Random Forest
react-macro-rings — animated SVG nutrition progress rings

Apps: 7 live products under Rewrite Labs — all private, all monetized.

The honest part

Most days are just writing code, fixing bugs, and shipping things nobody noticed yet.

The compounding happens quietly. One library gets starred. One app gets a paying user. One article gets shared in a Slack channel you've never heard of. You don't see it building — then one day you look back and there are 14 live products with your name on them.

That's the whole strategy. Pick a problem. Pick a stack. Ship before you're ready.

Find everything I have built at https://github.com/iamadhitya1

I Built 7 AI Apps in College — Here's What Nobody Tells You

M. Adhitya — Tue, 02 Jun 2026 14:46:47 +0000

Most students are still figuring out their first to-do app tutorial when they enter college. I decided to build a company instead.

I'm Adhitya, a B.Tech student at IITRAM, Ahmedabad. In my first two years of college, I built and shipped 7 live, monetized AI applications under my indie studio Rewrite Labs — plus 7 open source libraries used by other developers.

No CS degree required. No internship at a big tech company. Just a laptop, free tiers of incredible tools, and an obsession with shipping.

Here's everything I wish someone had told me before I started.

1. The Stack That Actually Works for Solo AI App Builders

Before I talk about lessons, here's the exact stack I use across all my apps. I landed on this after painful trial and error and I haven't needed to change it since:

Layer	Tool	Why
Frontend	React + Vite + Tailwind CSS	Fast dev, huge ecosystem
Auth	Clerk	10-minute auth setup, handles JWTs
Database	Supabase	Postgres with a clean dashboard, free tier is generous
AI	Groq API	Blazing fast inference, free tier, llama-3.3-70b is incredible
Payments	Razorpay	Best option for India, subscription plans supported
Deployment	Vercel	One command deploy, serverless functions built in

This stack lets me go from idea to live, paying app in under a week. Every tool has a free tier. Every tool has great documentation. There's no reason to use anything more complex when you're building solo.

2. Groq Will Change How You Think About AI Apps

Most people default to OpenAI. I did too, for about five minutes.

Then I tried Groq — and it felt like switching from dial-up to fiber.

Groq runs LLM inference on custom hardware called LPUs (Language Processing Units). The result? Responses that stream so fast they feel instant. For a chat app like my AI companion Nura, this is the difference between a product that feels alive and one that feels like it's thinking too hard.

The API is almost identical to OpenAI's, so migration is trivial. And the free tier is genuinely usable — not just a "taste."

If you're building any AI app today, start with Groq. You can always switch models later.

3. Ship Ugly. Polish Later. Seriously.

My first app took way too long because I kept polishing before shipping.

The brutal truth: nobody is looking at your app until you tell them to. That means every hour you spend pixel-perfecting before your first 10 users is an hour wasted.

My current process:

Build the core feature loop in 2–3 days
Deploy it live (even if it looks rough)
Get 5 real people to use it
Fix what breaks
Then polish

The version of your app you ship first will look nothing like version 1.0. Stop treating the MVP like a portfolio piece.

4. Auth is Not Your Problem — Stop Building It

Early on I wasted two days building a custom authentication system. Session tokens, password hashing, email verification — the works.

Then I discovered Clerk and deleted all of it.

Clerk gives you:

Email + social login
JWT verification for your API routes
Pre-built React components
User management dashboard

Setup takes literally 10 minutes. It's free for the first 10,000 monthly active users. There is zero scenario where you should be hand-rolling auth as a solo builder in 2025.

Same principle applies everywhere — use Supabase instead of building your own database layer, use Vercel instead of managing your own server. Your job is to build the product, not the infrastructure.

5. Monetization Is Easier Than You Think (If You Start Early)

I put a paywall in my second app. It felt bold, almost arrogant — who would pay for something a college student built?

Turns out: people who find it valuable.

Here's what I've learned about pricing AI apps as a student:

Start charging from day one. A free plan is fine, but have a paid tier. It forces you to build something worth paying for.
Subscriptions beat one-time payments. Recurring revenue means you can predict growth. Razorpay makes this straightforward with their subscription plans API.
The paywall is actually a feature. It filters out users who aren't serious. Your paying users give better feedback and stick around longer.

Don't wait until your app is "ready" to think about money. The business model should be part of the design from the start.

6. Open Source Is Your Best Marketing

While my apps are private (protecting the IP), I extracted reusable pieces into 7 open source libraries — things like:

react-premium-gate — Razorpay subscription paywall components
react-macro-rings — animated SVG nutrition progress rings
react-toast-native — lightweight toast notifications
groq-chain — Python LLM chaining without LangChain
llm-router — routes prompts to the right LLM by complexity and cost

Each library is a tutorial disguised as code. Developers find them, use them, and discover who built them. It's the most authentic form of marketing there is — you're not selling anything, you're just being useful.

If you're building apps, look for the pieces you keep rebuilding and open source them. It builds your GitHub profile, your reputation, and your network simultaneously.

7. The Thing Nobody Tells You About Building in College

Everyone focuses on the technical side. The harder part nobody talks about is the mental game.

You'll have weeks where nothing works. Where a bug takes three days to find and it's a single missing await. Where you ship something and nobody cares. Where your college workload collides with a critical bug in production.

What keeps you going isn't motivation — motivation is unreliable. What keeps you going is having built the habit of showing up and shipping anyway.

Some things that helped me:

Build in public (even quietly). Writing about what you're building creates accountability.
Ship something every week, even if it's small. Momentum compounds.
Separate your identity from the product. Your app failing doesn't mean you failed. It means you learned something that cost you nothing but time.

The builders who win aren't the smartest. They're the ones who kept going when it stopped being fun.

What I'm Building Next

Rewrite Labs is still growing. The app suite is expanding. The OSS library count is going up.

If you're a student reading this wondering whether to start — start. The tools have never been cheaper, the knowledge has never been more accessible, and the market has never been more open to AI products.

You don't need permission. You just need to ship.

Follow along — I'll be posting technical deep-dives, build logs, and honest lessons from the trenches right here on Dev.to.

The Shadow Syllabus: How I stopped relying on my college degree (Case Study

M. Adhitya — Thu, 08 Jan 2026 15:45:26 +0000

The Double Life of an Engineering Student...

The syllabus ends at 5:00 PM. My real education starts at 8:00 PM.

I am currently a full-time engineering student.
I attend the lectures.
I respect the degree.
But I stopped expecting the university to teach me everything.

In my manual, The Rewrite, I analyze a case study named "Zahir" (Chapter 5).

He realized early on that a degree gives you safety, but self-education gives you leverage.

He didn't quit college.

He just added a second shift.
Day Shift: Thermodynamics, Assignments, Attendance. (The Script).
Night Shift: Psychology, Systems Engineering, Building Products. (The Rewrite).

I am living this "Double Life" right now. When I look around the classroom, I see many students waiting to be spoon-fed skills that will get them a job. But the market doesn't pay for what you were taught.

It pays for what you built while no one was watching.

If you feel like the curriculum is too slow for your ambition, don't blame the college. Build your own Shadow Syllabus.

Read Chapter 5 in "The Rewrite" (v1.0) here in our website - https://rewrite-labs.netlify.app/

The Syntax Trap: Why 2026 Belongs to Architects, Not Typists

M. Adhitya — Fri, 26 Dec 2025 09:54:11 +0000

Welcome to the first edition of Code & Context. Every week, I break down the intersection of Engineering, AI, and Human Psychology.

If you walk into any Computer Science lab in India right now, you will see the same thing: Students furiously memorizing syntax.

They are memorizing matplotlib libraries. They are stressing over missing semicolons in C++. They are treating coding like a vocabulary test.

As a CS student myself, I understand the pressure. But as someone who has spent the last year analyzing the AI landscape (and recently being recognized as a Top AI Creator for it), I have a hard truth to share:

In 2026, Syntax will be the cheapest commodity on the market.

We are entering a new era of software development. If your primary skill is "I know how to write a for loop without looking at documentation," you are in trouble.

Here is why the market is shifting, and what you need to do about it.

The "Copilot" Reality
Three years ago, writing a boilerplate API in Python took 20 minutes. Today, with tools like GitHub Copilot and Cursor, it takes 20 seconds.

AI has commoditized the "How." It can write the code, refactor the code, and even write the test cases for the code.

As the graph of AI capability goes up, the value of pure syntax memorization goes down. But notice the other line? That is Context.

The Rise of the "Architect"
If AI handles the syntax, what is left for us humans? The answer is Context.

The developers who will dominate in 2026 aren't the ones who type the fastest. They are the ones who can answer these three questions:

The Architecture Question: "AI can write the function, but where does this function fit in the microservices architecture?"
The Logic Question: "The model gave me three solutions. Which one is the most scalable, and which one introduces a security vulnerability?"
The Human Question: "How do I explain this technical constraint to a non-technical founder?"

This is why I named this newsletter Code & Context.

The "Code" is the easy part. The "Context" is the leverage.

Stop Being a Compiler
My advice to my fellow students and developers is simple: Don't stop coding. But stop learning like a compiler.

Don't just memorize the Pandas library. Learn data storytelling.
Don't just copy-paste the Neural Network code. Understand the math behind the weights and biases.
Don't just build the app. Document the decision-making process.

The future doesn't belong to the person who writes the most lines of code. It belongs to the person who knows why those lines were written in the first place.

What to Expect from This Newsletter
I am M. Adhitya. I operate at the intersection of hard engineering and human narrative.

In the coming weeks, Code & Context will cover:

Deep Dives: How LLMs actually "think" (without the jargon).
System Design: Building scalable architectures in the age of AI Agents.
Tech Strategy: How to build a personal brand as a developer.

If you are ready to move from being a Typist to being an Architect, you’re in the right place.

See you next week.