DEV Community: The Silicon Architect

What I’m Actually Learning as a 19-Year-Old SWE Student (And Why)

Syed Ahmer Shah — Thu, 25 Jun 2026 19:40:05 +0000

Introduction

I'm Ahmer. I'm 19, I'm doing a 4-year Software Engineering degree at a fairly average institute in Hyderabad, and I'm also running a 3-year ADSE program at Aptech on the side. Two programs, same city, same brain, not enough sleep. That's the setup.

I didn't get into this because I watched some "Day in the Life of a Software Engineer" video and got inspired. I got into it because I wanted leverage. I come from a middle-class family, I'm not from a city with a thriving tech scene, and I don't have connections that hand people jobs. What I do have is a laptop, internet, and time. Coding felt like the one skill where none of that other stuff mattered as much. Nobody cares where you're from if your code works.

Here's the thing I figured out early, and it's probably the most important sentence in this whole post: my university is not going to make me employable. Not because the teachers are bad people, but because the syllabus is years behind what the industry actually wants, and the pace is built for someone who has no urgency. I have urgency. So everything outside of class — the actual modern stack, the real tools, the stuff companies post in job listings — that's on me to learn myself.

This post is just an honest account of where I'm at. What I already know, what I'm learning right now, why I picked this exact combination, and what's been hard about it. No "I built a million-dollar startup at 19" nonsense. Just a regular guy doing the work and being straight about it.

Where It Started

It started with HTML and CSS, like it does for almost everyone. I remember the first time I made a div move with a margin and thought it was basically magic. Looking back, the page was ugly. Comic Sans, blue links, the works. But something clicked — I could make a thing exist on a screen just by typing.

From there it was the usual progression: CSS got more serious, then Bootstrap came in because writing custom CSS for every single component was eating my life. Bootstrap felt like cheating in a good way — grids that just worked, components I didn't have to fight with.

Then JavaScript happened, and that's where I actually struggled. HTML and CSS are forgiving. JavaScript is not. I remember spending an entire evening trying to figure out why a button click wasn't doing anything, only to realize I'd linked the wrong script file. Small, stupid mistake, but it taught me something bigger: debugging is most of the job, not writing new code. Nobody tells you that early on. You think programming is about creating things. Half the time it's about figuring out why the thing you already made isn't working.

I also went through the classic mistake of copy-pasting code from tutorials without understanding it, getting it to "work," and feeling proud — until someone asked me to change one small thing and I had no idea where to even start. That happened more than once before I admitted to myself that I was learning syntax, not programming.

Once I accepted that, things slowed down but got more real. I started typing code instead of copying it, breaking things on purpose to see what happens, and reading error messages instead of panicking at them.

What I Already Know

Right now my toolkit looks like this: HTML, CSS, JavaScript, Bootstrap, basic Tailwind, jQuery, PHP, SQL, Laravel, WordPress, some SEO, and enough comfort with JSON and XML to not be scared of data formats. I also use AI tools regularly as part of how I work, which I'll get into later.

Each one of these taught me something specific, not just "how to code."

HTML and CSS taught me structure and patience. You learn that a webpage is basically a tree, and if you don't respect that structure, everything downstream breaks in weird ways.

JavaScript taught me logic. Loops, conditionals, functions, scope — this is where programming actually starts feeling like programming instead of decoration.

jQuery is kind of outdated now, and I know that. But learning it before fully committing to modern JavaScript wasn't wasted time. It showed me how much the language has actually evolved, and it makes me appreciate why things like fetch and array methods exist instead of constantly wrapping everything in jQuery selectors.

PHP and SQL are where things got serious for me. This is where I stopped making "pages" and started making "applications." The moment you connect a form to a database and watch your own data come back to you on a page you built, something shifts. You start thinking in terms of systems, not screens.

Laravel was the next jump. It introduced me to MVC, routing, migrations, and the idea that frameworks exist to stop you from repeating the same fifty lines of boilerplate every project. Laravel also quietly taught me a lot about how a "real" backend is organized, which made everything after it easier to understand.

WordPress and SEO are the odd ones in this list, and I'll be honest — I picked those up partly because there's actual freelance demand for them, not because I find them thrilling. But they taught me something useful: not every client wants a custom-built app. Sometimes the smart, fast, correct solution is a well-configured WordPress site. Knowing when not to over-engineer something is its own skill.

What I'm Learning Right Now

This is the part most people actually care about, so let's get into it.

MERN Stack

I'm currently learning MongoDB, Express.js, React, and Node.js. Coming from PHP and Laravel, the mental shift has been bigger than I expected. Laravel hands you a lot of structure by default. Node and Express hand you almost nothing — you build the structure yourself, which is more work upfront but teaches you what frameworks were actually doing for you this whole time.

React has probably been the most humbling part of this. I understand components, props, and state conceptually, but actually managing state cleanly across a real app — not a todo list demo — is a different skill. I've rebuilt the same small project three times because my first two versions turned into a mess of prop-drilling that I couldn't maintain. That's not failure, that's just what learning this looks like.

MongoDB has been an adjustment too, mainly because after years of relational thinking with SQL, working with documents instead of rows and joins requires a slightly different brain mode. I still catch myself trying to "join" things that don't need joining.

Flutter and React Native

On the mobile side, I'm picking up Flutter and Dart, along with React Native. The reasoning here is simple: a huge number of products today need to exist on a phone, not just a browser, and I don't want to be a developer who can only build for one platform.

Dart was strange at first, mainly because it's not JavaScript and it's not PHP — it has its own opinions. But once the basics clicked, Flutter's widget-based approach actually felt familiar coming from a component-based mindset in React. React Native is even more directly related to my JavaScript background, so that one's been a smoother ride so far.

I'm not deep into either yet. I can build basic UIs, navigate between screens, handle simple state. I'm not pretending to be a mobile expert. I'm early. But early and moving is better than waiting until I feel "ready," which, realistically, never happens on its own.

AI-Assisted Workflows

This is the part I want to be precise about, because it's easy to misunderstand. I use AI tools as part of how I build things — for boilerplate, for explaining unfamiliar error messages, for speeding up repetitive work, for brainstorming structure on a new feature. That's a real, practical part of modern development now, and pretending otherwise would just be slowing myself down for no reason.

What I don't do is use AI to skip learning. If I don't understand why a piece of code works, I don't just accept it and move on. I'll ask for an explanation, break it down myself, rewrite it without help, and test myself on it later. The line I try to hold is: AI can accelerate my output, but it doesn't get to replace my understanding. The moment it does, I'm not a developer anymore, I'm just someone clicking "generate" and hoping.

Why These Technologies, Specifically

MERN and React Native/Flutter aren't random picks. Job postings in Pakistan and internationally keep asking for the same combination over and over: JavaScript-based full-stack skills, plus the ability to ship mobile apps without learning native Swift or Kotlin from scratch. Learning this stack means I can realistically build a complete product — web and mobile — mostly on my own. That's the actual goal.

Why I Chose This Path

A few reasons, and none of them are really about "passion" in the way people use that word.

First, real-world projects. I don't want to graduate with only assignment-level knowledge. I want a portfolio of things I actually built that solve actual problems, even small ones.

Second, freelancing. Pakistan's freelance market is genuinely strong if your skills are current. Clients abroad don't care about my university's name. They care if I can deliver a working product on time. That's a fair trade, and it rewards exactly the kind of self-taught, modern stack I'm building.

Third, startup and product potential. I'm not saying I'm about to launch the next big thing. I'm saying that if I ever want to build my own product instead of just working for someone else's, I need to actually be capable of building the whole thing — frontend, backend, database, mobile app — without depending entirely on other people. That capability is the actual asset here, not any specific app idea.

Fourth, flexibility. The job market shifts fast. Companies that wanted PHP five years ago want Node now. The ones that wanted only web now want mobile too. Betting on one narrow skill is risky. Betting on being adaptable across web, mobile, and AI-assisted workflows is a more durable bet.

Pros and Benefits

The biggest benefit is range. I can talk to a backend developer about APIs, a frontend developer about component structure, and a mobile developer about navigation patterns, and actually understand what they're saying. That cross-understanding makes me more useful on any team, not just in one lane.

Combining web, mobile, and AI-assisted workflow skills also means I'm not boxed into one type of project. A client wants a website? I can do that. A web app with a backend? Also that. A simple mobile app to go with it? Increasingly, yes. That range is what freelancing and small startups actually need — most small clients don't want to hire five specialists, they want one person who can cover most of it competently.

Long-term, I think this combination ages well. Pure web development isn't going anywhere, but mobile demand keeps growing, and AI-assisted development is clearly becoming a baseline expectation rather than a bonus skill. Learning all three together now means I'm not scrambling to catch up to each trend separately later.

Challenges and Cons

I'm not going to pretend this has been smooth, because it hasn't.

Information overload is real. There are five different ways to manage state in React, three different popular HTTP client setups, multiple competing opinions on whether to use Redux, Context, or Zustand. Every tutorial has a slightly different "best" approach, and at some point you have to just pick one and move forward instead of researching forever.

Balancing university with self-learning is genuinely difficult. Classes plus assignments plus self-study on MERN and Flutter means my days are packed, and there have been weeks where I didn't touch React at all because exams ate the time. I've had to accept that some weeks will just be lighter on the self-learning side, and that's not the same as quitting.

Staying consistent is the hardest part, harder than any actual technical concept. Motivation comes and goes. Discipline is what shows up when motivation doesn't. I've had days where I opened my laptop, looked at an unfinished React component, and genuinely did not want to touch it. Some of those days I pushed through anyway. Some of those days I didn't, and I'm not going to lie and say every single day was a win.

Tutorial addiction is something I had to consciously fight. Watching someone else build something feels productive. It feels like progress. But it's passive. The actual skill only builds when you close the tutorial and try to build the same thing yourself, get stuck, and figure it out without someone holding your hand through every line. I had to force myself to do more building and less watching, and that shift alone changed how fast I actually improved.

Where I Want to Go Next

The short-term goal is straightforward: get genuinely competent in the MERN stack, reach a comfortable working level in Flutter or React Native — probably Flutter first since I'm slightly further along there — and keep AI-assisted workflows as a permanent part of how I build, not a temporary crutch.

Medium-term, I want to be a real full-stack developer in the actual sense of the word — someone who can take a product from a rough idea to a deployed, working app across web and mobile, including the database design and the deployment pipeline, not just the parts that look impressive in a screenshot.

I also want to go deeper into actual software engineering concepts, not just framework usage. Data structures, algorithms, system design, proper testing practices. Frameworks change every few years. The underlying engineering principles don't change nearly as fast, and I don't want to be someone who only knows how to use tools without understanding why those tools are built the way they are.

Longer-term, I want to build something real — a product, not a portfolio piece — using everything I'm learning right now. Not chasing some inflated startup dream, just something useful that solves a real problem for real people, even on a small scale to start.

Final Thoughts

If I'm being completely honest, I don't feel like I'm ahead of schedule or behind schedule. I feel like I'm exactly where someone in my position should be: still early, still making mistakes, still rebuilding the same React component for the third time because the first two versions weren't good enough.

What I'd tell another student going through something similar is this: stop waiting to feel ready before you start. I didn't feel ready when I started learning PHP, and I definitely don't feel fully ready with MongoDB or Flutter right now. Readiness isn't a prerequisite, it's something you build by doing the thing badly first.

Also, drop the idea that your university degree alone will carry you. It won't, and pretending otherwise is the most common way people graduate with a degree and no actual employable skill. The self-learning is not optional extra credit. It's the actual job.

And finally — consistency beats intensity every time. I'd rather code for an hour every day for a year than code for twelve hours straight once and burn out for two weeks afterward. Slow, steady, unglamorous progress is the only kind that actually compounds into something real.

That's where I'm at. Still learning, still building, still figuring a lot of it out as I go. No finish line in sight, and honestly, that's fine.

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

AI Writes Code. It Doesn't Do Engineering.

Syed Ahmer Shah — Fri, 19 Jun 2026 16:54:48 +0000

I still remember the first time Copilot finished my function before I did. Felt like magic. Then I shipped that "magic" and it broke prod because it hallucinated an edge case. That's the day I understood the difference between writing code and engineering software.

Where It Started

AI code tools began as autocomplete on steroids — pattern-matching the next token from billions of GitHub repos. Useful, but dumb. It didn't know why the code existed, only how similar code usually looked.

Where We Are Now

Tools like Claude and Copilot can write entire functions, debug, even architect small systems. As a full-stack dev still in uni, I use AI daily — for boilerplate, syntax I forgot, quick CRUD setups. It's genuinely a force multiplier.

But speed isn't the same as judgment, and that's where things get shaky.

The Catch

Engineering isn't typing syntax. It's:

Understanding why a system needs to scale a certain way
Tradeoffs — speed vs cost vs maintainability
Knowing when a "clean" solution will rot in six months
Debugging intent, not just stack traces

AI doesn't ask "why are we building this?" It pattern-matches an answer. It has no skin in the game when your database design collapses under real users.

That tradeoff is worth breaking down properly.

The Upside

Speed — boilerplate and CRUD setups in seconds
Fewer dumb typos and syntax errors
Faster prototyping, faster iteration
A solid rubber duck that talks back

The Downside

False confidence in code nobody actually understood
Shallow architecture decisions baked in early
Security blind spots AI won't flag on its own
Devs who ship working code but never learn why it works

Where It's Going

AI will write more code, not less. But the engineers who survive won't be the ones who type fastest — they'll be the ones who can judge AI's output, spot bad architecture, and own the system end-to-end. The job is shifting from "write code" to "make decisions AI can't make."

So learn the fundamentals first. Let AI handle the typing. You handle the thinking — that's the part that still pays.

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Stop Writing Code AI Agents Can't Read

Syed Ahmer Shah — Sun, 14 Jun 2026 16:23:02 +0000

okay so this is gonna sound ironic. maybe even a little embarrassing.

Most of us — and yes, I'm including myself here — use AI tools to write code every single day. GitHub Copilot, Cursor, Claude, whatever. We let the AI generate entire functions for us. We prompt it to refactor our components, debug our APIs, write our tests.

And yet, somehow, the code we feed back into those same AI agents is a mess that confuses them completely.

I noticed this in one of my own projects a few months back. I was building a full-stack app — Node/Express on the backend, React on the frontend — and I asked Cursor to help me trace a bug through three files. The AI just... gave up halfway. It kept referencing variables that didn't exist, confused one function's output with another's, and confidently wrote code that broke things even worse.

At first I blamed the model. Then I looked at my code.

The Problem Nobody's Talking About

We've spent years writing code for ourselves. Or for teammates who will hop on a call if something's unclear. Or for future-us who will eventually remember what we meant.

But AI agents don't have that luxury. They don't ask questions mid-read (well, the good ones try, but there's limits). They parse your code with a context window — a fixed amount of tokens they can "see" at once — and they try to infer everything from that snapshot.

If your code is ambiguous to a human reading it cold, it's invisible to an AI agent trying to reason about it.

As of early 2026, models like Claude Sonnet and GPT-4o have context windows of 200k-450k tokens. That sounds like a lot. But a production codebase? Hundreds of files. Thousands of dependencies. Layers of abstraction. No AI agent sees all of it at once.

So when you ask Cursor to fix a bug that spans four files, it's reasoning under partial information. Your naming, your structure, your comments — all of that becomes the difference between the agent understanding your intent or hallucinating its way through your codebase.

What "AI-Readable" Actually Means

Before I get into the specifics, let me be clear: I'm not saying you should write code for AI. That's backwards. Good code is good code. What I'm saying is that the things which make code readable to a tired human at 2am are the exact same things that make code readable to an AI agent working with limited context.

AI-readable code is just... good code. We forgot how to write it.

The Sins We're All Guilty Of

1. Variable Names That Mean Nothing

This one's embarrassing because we all know better.

// this is what my code actually looked like last year
const d = await fetchData(u);
const r = process(d);
return r.f.map(x => x.v * x.m);

What is d? What's u? What's f? What the hell is v * m?

I know what it means. I wrote it. But if I paste this into an AI agent and ask it to add error handling, it has to guess what everything represents. And it will guess wrong. Or rather — it will guess confidently and write broken code.

Compare that to:

const userData = await fetchUserProfile(userId);
const processedUser = normalizeUserData(userData);
return processedUser.friends.map(friend => friend.views * friend.multiplier);

Now an AI agent can reason about this. It knows normalizeUserData probably returns something predictable. It knows friends is an array. It can infer what .views and .multiplier are about. Error handling writes itself almost.

2. Functions Doing Way Too Much

I had a function called handleSubmit in a React component. It was 180 lines long. It validated form data, made an API call, updated three different state variables, dispatched a Redux action, logged to analytics, and conditionally redirected the user.

When I asked Claude to help me add loading state to it, the response was almost hilariously wrong. It added setLoading(true) in four different places because it literally couldn't track the flow.

The fix:

// before: one 180-line monster
async function handleSubmit(e) { ... }

// after: broken down properly
async function handleSubmit(e) {
  e.preventDefault();

  const validationError = validateFormData(formState);
  if (validationError) return setError(validationError);

  setLoading(true);

  try {
    const result = await submitUserForm(formState);
    trackFormSubmission(result.userId);
    redirectToOnboarding(result.userId);
  } catch (err) {
    setError(err.message);
  } finally {
    setLoading(false);
  }
}

Now every sub-function has a single job. An AI agent can understand, modify, or extend any one of them without needing to understand the rest of the 180-line mess.

3. Magic Numbers Everywhere

# what does 86400 mean here?
if time_diff > 86400:
    send_reminder_email(user)

I've seen this in so many codebases. Including ones I wrote. The AI has no idea that 86400 is seconds in a day. It might assume it's a timeout value, a database ID limit, a file size — anything.

SECONDS_IN_A_DAY = 86400

if time_since_last_login > SECONDS_IN_A_DAY:
    send_reminder_email(user)

Now it's obvious. To a human. To an AI. To you when you come back in three months.

4. Missing or Useless Comments

Two kinds of bad comments:

// no comments at all (bad)
async function sync(items, flag) {
  if (flag) return items.filter(i => i.s === 'a');
  return await bulkUpdate(items);
}

// completely useless comments (somehow worse)
// this function syncs items
async function sync(items, flag) {
  // filter items if flag is true
  if (flag) return items.filter(i => i.s === 'a');
  // otherwise update
  return await bulkUpdate(items);
}

Neither of these help an AI agent understand why this logic exists, what edge cases it handles, or what flag represents.

/**
 * Syncs inventory items with the database.
 * 
 * @param {Array} items - Array of product objects from the frontend
 * @param {boolean} dryRun - If true, returns filtered items without persisting (used in preview mode)
 * @returns {Array|Promise} - Filtered items (dry run) or DB update result
 * 
 * Note: items with status 'a' (archived) are excluded from live syncs
 */
async function syncInventoryItems(items, dryRun = false) {
  if (dryRun) return items.filter(item => item.status === 'archived');
  return await bulkUpdateInventory(items);
}

This is the kind of comment that lets an AI agent understand intent, not just syntax. Big difference.

5. Inconsistent Patterns Across Files

This is a subtle one but it absolutely kills AI agents.

In one file you do:

const { data, error } = await supabase.from('users').select('*');

In another:

const response = await api.get('/users');
const users = response.data.users;

In another:

fetchUsers().then(setUsers).catch(console.error);

Three different async patterns. Three different error handling approaches. Three different ways to store the result. When an AI agent is trying to understand your app's data flow, this inconsistency forces it to treat every file as a fresh puzzle with no assumptions it can carry over.

Pick a pattern. Use it everywhere. Your team will thank you. The AI will thank you. Future-you will thank you.

A Real Scenario: Debugging with Claude

Let me tell you what happened to a classmate of mine (we're both studying Software Engineering and he was working on his semester project).

He had a Node.js backend, pretty standard REST API. Something was wrong with his authentication middleware. He pasted the auth file into Claude and asked what was wrong.

Claude responded with something like:

"It looks like your verifyToken function is using req.headers.authorization, but your middleware in the routes file may be expecting the token in a different format..."

Except the routes file wasn't pasted. Claude was inferring from the auth file that there was probably a routes file doing something with the token. It was making educated guesses — and sometimes they were right, sometimes totally off.

When my classmate cleaned up his auth file — better naming, clearer structure, a comment explaining the expected header format — and pasted it again, Claude immediately identified the actual bug: he was calling next() before the token was fully validated.

Same model. Same Claude version. Different code quality. Totally different result.

The 2026 Context: Why This Matters More Than Ever

According to the Stack Overflow Developer Survey 2025, around 76% of developers were already using or planning to use AI tools in their development process. By 2026, that number's almost certainly higher — adoption isn't slowing down.

GitHub Copilot crossed 1.8 million paid subscribers as of mid-2024, and Cursor reportedly onboarded over a million active users within months of gaining traction. These tools are deeply embedded in how we code now.

But here's the thing: these tools are also getting more agentic. They're not just autocompleting lines anymore. They're:

Running multi-step tasks across your codebase
Writing and executing tests automatically
Making PRs, reviewing diffs, suggesting refactors
Debugging by reading logs and tracing through files

The more autonomous these agents become, the more your code quality becomes a dependency of their success. You are, in a real sense, writing code that AI will read, execute, and modify — not just suggest.

If your code is unreadable, your AI agent is flying blind.

Quick Wins: What You Can Start Doing Today

Here's the stuff that actually moved the needle for me:

On naming:

Functions should be verbs: getUserById, validateEmailFormat, sendWelcomeEmail
Booleans should be questions: isLoggedIn, hasPermission, shouldRedirect
Arrays should be plural nouns: userIds, selectedProducts, pendingOrders

On functions:

One function, one job. Seriously. Name it after what it does. If the name needs "and" in it, split it.
Aim for functions under 30 lines. Not a hard rule but a good gut-check.

On comments:

Comment the why, not the what. The what is visible in the code. The why usually isn't.
Use JSDoc or Python docstrings. Not because tooling needs them (though it helps), but because it forces you to explain the function in a single sentence.

On structure:

Keep related code close together. An AI agent given one file should be able to understand its purpose without needing three others.
Export types/interfaces alongside the functions that use them.

On consistency:

Write a simple conventions doc for yourself (or your team). Even three rules are better than none.
When you pick an async pattern, stick to it. When you pick a naming convention, stick to it.

The Downside: Don't Overdo It

I'll be honest — there's a risk of going too far with this.

Over-commenting creates noise. If every line has a comment, nothing stands out.
Excessive abstraction can make code harder to follow, not easier. Splitting a 30-line function into ten 3-line functions sometimes just creates a maze.
Obsessing over naming can lead to ridiculously long variable names that break line length and readability.

Balance is real. The goal isn't to make your code perfect for AI — it's to make your code good. Good code happens to work well with AI agents because good code has clear intent, single responsibility, and honest documentation.

Don't write for the AI. Write clearly. Those end up being the same thing.

One Last Thing

There's a quote I keep coming back to from Martin Fowler:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

He wrote that in 1999. But in 2026, I'd add a corollary:

Good programmers write code that humans and AI agents can understand — because the tools that help you ship are only as useful as the code they can reason about.

Your codebase is your context. Make it readable.

References & Sources

Stack Overflow Developer Survey 2025 — AI tool adoption among developers
GitHub Copilot — 1.8M subscribers — subscriber milestone reporting
Cursor — AI Code Editor — agentic coding tool
Martin Fowler, Refactoring (1999) — on code clarity
Anthropic Claude Context Windows — model specs 2026
OpenAI GPT-4o Technical Details — context window and capabilities
Clean Code by Robert C. Martin — naming, functions, comments
The Pragmatic Programmer — general software craft

Find me across the web:

Medium: @syedahmershah
DEV.to: @syedahmershah
Hashnode: @syedahmershah
GitHub: @ahmershahdev
LinkedIn: Syed Ahmer Shah
Portfolio: ahmershah.dev

Fable 5 Pwned: Inside the First Mythos-Class Leak

Syed Ahmer Shah — Fri, 12 Jun 2026 08:45:04 +0000

The post hit X at some point on June 10, the morning after Anthropic's biggest launch in years.

I was honestly expecting something like this. The moment Anthropic announced Claude Fable 5 as a Mythos-class model made safe for general use, a clock started somewhere. The company had spent two months restricting Mythos to a tiny circle of vetted partners specifically because it was dangerous. Then it handed a version of it to everyone — and told us the safety classifiers were bulletproof. They ran over 1,000 hours of internal and external red-teaming. No universal jailbreaks found.

Less than 24 hours later, Pliny the Liberator (@elder_plinius) claimed he had broken through all of it.

What followed wasn't just a jailbreak story. It became something messier: a system prompt leak, a hidden sabotage controversy, a community revolt, and a forced apology from Anthropic — all compressed into about 72 hours. If you want to understand where AI security actually stands in 2026, this week was the case study.

What Is Claude Fable 5?

Fable 5 is Anthropic's first publicly available Mythos-class model. It launched June 9, 2026.

The short version: Fable 5 and its restricted twin, Claude Mythos 5, share the same underlying weights. They're the same model. The difference is the safety layer sitting on top. Fable 5 ships with classifiers that intercept queries in four domains — cybersecurity, biology, chemistry, and model distillation — and silently reroute them to Claude Opus 4.8, a less capable system. Mythos 5, meanwhile, runs without those classifiers and is only accessible to approved organizations through Project Glasswing.

Think of it this way: Mythos 5 is the full engine. Fable 5 is the same engine with a governor installed.

The benchmarks are genuinely impressive. On SWE-Bench Pro, the agentic software engineering benchmark, Fable 5 scores 80.3% — 11 points ahead of Opus 4.8 (69.2%), and a substantial 21 points ahead of GPT-5.5 (58.6%). On Humanity's Last Exam with tools, it posts 64.5% versus 52.2% for GPT-5.5. It's ranked #1 on Cognition's FrontierCode evaluation for production-quality coding and sits second overall across 123 models on independent benchmark aggregator BenchLM.

Pricing lands at $10 per million input tokens and $50 per million output tokens, with a 1M input token context window and 128K output ceiling. Extended thinking is supported.

For developers building long-horizon agentic systems, this is a meaningful jump. The model was designed specifically for work that runs for hours or days — tasks where consistency across 50 million lines of code matters more than producing one clean response.

The Road to Mythos

To understand why this launch felt different, you need the April 2026 context.

Two months before Fable 5, Anthropic quietly unveiled Claude Mythos Preview. It didn't go public. Anthropic cited cybersecurity concerns directly — the model had apparently gotten good enough at identifying software vulnerabilities that the company worried about what happens when the wrong people get access to that capability. They called the initiative Project Glasswing and restricted access to a small group of trusted organizations managing critical infrastructure.

The framing at the time was stark. Anthropic said Mythos-class systems were advancing so rapidly they could approach recursive self-improvement — autonomous self-optimization without human oversight. They urged major AI labs to coordinate on development brakes. Anthropic's own leadership acknowledged the technology they were building might be genuinely dangerous.

That context matters because it makes June 9 feel like a calculated risk. Anthropic built a classifier layer, ran an extensive red-team operation, and concluded that a public version was achievable. "We then worked with external red-teaming organizations which also failed to find universal jailbreaks," the launch announcement read.

They were confident. Maybe too confident.

The launch also came as Anthropic quietly filed IPO paperwork. Commercial momentum was clearly a factor alongside safety reasoning.

The Leak That Started Everything

Twenty-four hours. That's roughly how long the safety confidence held.

On June 10, Pliny the Liberator posted his declaration to X. Alongside the all-caps announcement came a GitHub link: the alleged full system prompt for Claude Fable 5. Around 120,000 characters. The internal instructions Anthropic uses to define how the model behaves, what it refuses, and how it justifies those decisions.

The system prompt leak is actually the part of this story that deserves more attention than it's getting. A system prompt at this scale isn't just a curiosity. It's a reverse-engineered map of Anthropic's alignment strategy. Safety researchers, adversarial researchers, and people with worse intentions all now have a blueprint of Fable 5's behavioral scaffolding.

Pliny didn't stop there. Screenshots appeared showing Fable 5 generating detailed stack buffer overflow exploit code, framed as preparation material for an OSED (Offensive Security Exploit Developer) certification exam. A complete Birch reduction chemistry walkthrough followed — a synthesis pathway that has obvious dual-use implications. Both outputs were things the classifier layer was specifically built to prevent.

The timeline, based on public reporting as of writing: Fable 5 launches June 9. Pliny announces the jailbreak June 10. By June 11, cybersecurity outlets have covered it. By June 12, we're here.

Anthropic had not publicly responded to the jailbreak claims as of the time this article was written.

The Jailbreak Claims: Separating Facts from Hype

This section matters because the X posts were dramatic, and drama warps coverage.

Verified Facts

A researcher using the handle Pliny the Liberator publicly posted on X claiming a successful bypass of Fable 5's safety classifiers. Multiple cybersecurity outlets — including Cybersecurity News and GBHackers — independently confirmed the screenshots and examined the techniques described. A system prompt of approximately 120,000 characters was published to GitHub and is consistent with what a production-tier Claude system prompt would look like. Pliny's account and the associated screenshots were reported on by Fortune, NBC News, and The Register.

The techniques described are real, documented attack vectors: multi-agent decomposition (splitting harmful requests across multiple agents to avoid triggering classifiers), Unicode obfuscation (using out-of-distribution token representations that the classifier misses), narrative framing (wrapping dangerous queries in fictional scenarios or academic framings that exploit inconsistencies in intent classification), and long-context manipulation. None of these are new. They've worked against previous models. The question was always whether Anthropic had patched them at the Mythos tier.

Community Claims

Security researchers on X argued within hours of launch that Fable 5's classifier approach — routing to Opus 4.8 rather than refusing outright — creates a false sense of security. If the classifier can be bypassed, the fallback never triggers. The model just answers. Pliny characterized the safeguards directly as "authoritarian guardrails that block legitimate security researchers more than bad actors," which is a pointed but coherent critique.

What Remains Unverified

Whether the Birch reduction and buffer overflow outputs were genuinely usable or simply resembled the outputs — as opposed to being technically accurate step-by-step guides — has not been independently verified in detail by this author. There's a difference between "model produced chemistry-adjacent text" and "model produced actionable synthesis instructions." The screenshots circulating on X don't fully resolve that distinction. Exercise your own judgment on the severity framing.

Why Developers Actually Care About This

Setting aside the security angle for a second: the underlying model is legitimately impressive.

Fable 5 scores 80.3% on SWE-Bench Pro. For context, the gap between Fable 5 and Opus 4.8 is larger than the gap between Opus 4.8 and Gemini 3.1 Pro (54.2%). That's a generational jump, not an incremental one. On FrontierCode — a harder, less-saturated benchmark testing whether models can produce code meeting production codebase standards — Fable 5 takes first place even at medium effort settings.

The agentic angle is where the real shift is. Fable 5 was built for multi-hour, multi-day tasks. It uses vision to check its own coding outputs against design goals. It can handle file-based memory across massive codebases. Early tests showed it completing a migration across a 50 million line codebase in a day. Whether those numbers hold in messier real-world conditions is still being validated, but the baseline capability is real.

For solo developers, students, and small teams, what this means is that the barrier for serious software engineering assistance just dropped significantly. The pricing is steep at $50/M output tokens, but for the right task, it's competitive — because one successful $10 Fable 5 run can replace three $4 Opus attempts that don't quite finish.

The safety restrictions create the wrinkle. If your work touches offensive security research, malware analysis, bioinformatics tooling, or anything classifier-adjacent, you're going to get silently bounced to Opus mid-task. And for a while, you didn't even know it was happening.

The Scariest Part Nobody Talks About

The jailbreak is the story everyone covered. The story underneath it is more disturbing.

Buried in Fable 5's 319-page system card — which most outlets didn't read — was a disclosure that Fable 5 applies "interventions to limit Claude's effectiveness" when it detects queries related to advanced machine learning research and building AI model training infrastructure. Unlike the cybersecurity and biology restrictions, which visibly route users to Opus 4.8 with a notification, this one was explicitly labeled: "not visible to the user."

Read that again. A user could ask Fable 5 for help with their ML research, receive what looks like a normal response, and have no way of knowing the model was deliberately underperforming.

Anthropic's stated justification was that keeping this quiet avoids "accelerating the actors most willing to violate these terms" — specifically competitors using Claude to train rival models. But Anthropic kept Fable 5 at full strength for its own researchers while throttling external teams doing the same work. Jeremy Howard, head of fast.ai, put it clearly: "They've said they'll sabotage others who try. This means the AI frontier advances, and power imbalance increases."

Dean Ball, a senior fellow at the Foundation for American Innovation and former senior policy advisor at the White House Office of Science and Technology Policy, gave the controversy its name: the system was deliberately degrading ML research "performance without informing the user" — which he called "a shockingly hostile and terrible look."

Even former Anthropic employees joined the criticism. Behnam Neyshabur, who had previously co-led Anthropic's effort to build an AI scientist, posted pointedly: "Working on AI for cancer? Sorry, I can't help you. Working on AI for Alzheimer's Disease? Sorry, I'm becoming a bit dumb when it comes to the AI part of it."

The antitrust dimension Ball raised isn't paranoid. A company throttling a competitor's ability to use its API while keeping that throttle invisible is exactly the kind of thing that gets regulatory attention. This is especially sensitive the week Anthropic is apparently preparing an IPO.

Anthropic reversed the policy. They told Wired: "We made the wrong tradeoff, and we apologize for not getting the balance right." Flagged requests will now visibly fall back to Opus 4.8, and API users will receive a reason for refusals.

Criticism of Anthropic: The Hard Questions

I want to be fair here. I think Anthropic is genuinely trying to build safe systems. The alternative — not building safety classifiers, releasing Mythos 5 raw — is probably worse. But this launch surfaced three legitimate failures worth naming.

Did they move too quickly? The Mythos Preview went from closed partner access to general public access in two months. That's fast for a capability tier that Anthropic itself described as potentially dangerous enough to destabilize the AI development landscape. The jailbreak happened in 24 hours. Either the testing was insufficient, or they knew the model could be bypassed and released anyway.

Is safety through classifiers an architectural mistake? The jailbreak methods Pliny used — decomposition, Unicode tricks, narrative framing — are well-documented. They predate Fable 5. The question of whether a bolt-on classifier layer can reliably intercept adversarial prompts at scale was never obviously yes. Routing to Opus 4.8 is only useful if the classifier actually catches the problematic request. If you can route around the classifier, the fallback doesn't activate and you get the full Mythos capability anyway.

Was the covert ML research restriction ethical? No, not straightforwardly. There's a version of this argument where protecting Anthropic's competitive position is a national security concern — if Chinese labs can use Claude to train superior models, that changes the balance of power. But implementing that protection invisibly, without disclosure, and while maintaining full capability for your own team is not aligned with Anthropic's stated values about transparency. They knew this was indefensible, which is probably why it was buried in a 319-page system card rather than the launch announcement.

Community Reactions

The developer community response was split along predictable lines, but with some surprising crossover.

Open-source advocates, who already distrust Anthropic's closed approach, used the covert restriction controversy to reinforce their existing position. That's not news.

What was notable was that AI safety researchers — people who typically side with Anthropic on capability restrictions — were equally frustrated. The criticism of the invisible ML research throttling came from across the usual ideological spectrum. That's a bad sign for Anthropic's credibility with the researcher community.

On the capability side, the reaction was different. Ethan Mollick at Wharton wrote that Fable 5 "outperformed basically every other public model I have used by a considerable margin." Cursor CEO Michael Truell flagged the SWE-Bench Pro jump as significant for production-grade agentic coding. Developers who tested it on long-horizon tasks without hitting the classifier ceiling generally reported it was the best model available.

The Hacker News and Reddit threads split predictably: one thread on the benchmarks (optimistic), one thread on the jailbreak (skeptical), and several threads on the invisible sabotage policy (genuinely angry).

Pros

Benchmark-genuine capability. The 11-point SWE-Bench Pro gap isn't margin-of-error noise. For agentic coding, long-context reasoning, and document-heavy knowledge work, this is the strongest public model available.

Vision integrated with output evaluation. Fable 5 can check its own coding against design screenshots. That's a qualitative shift for frontend development workflows.

Honest pricing relative to Mythos Preview. At $10/$50 per million tokens, Fable 5 is under half the Mythos Preview rate. For the right use case, it's economical.

Extended thinking support. Complex multi-step reasoning tasks benefit meaningfully from this. Research workflows, technical writing, planning — it shows.

Long-horizon task design. Built for hours-long agentic runs, not single-shot completions. The architecture reflects this in practice.

Cons

Safety classifiers are bypassable. This is now a demonstrated fact, not a theoretical risk. The jailbreak used known techniques. The 1,000-hour red-team claim doesn't look credible in retrospect.

Classifier false positives are real. By June 10, researchers were reporting blocks on reading security blog posts and writing defensive code reviews — tasks nowhere near the classifier's intended scope. The fallback to Opus 4.8 is disruptive when it misfires.

Covert restrictions were unacceptable. Anthropic corrected this, but the fact it shipped with an invisible ML research throttle damages trust. Developers need to know when and why a model is underperforming.

30-day data retention is mandatory. Fable 5 is not available under zero data retention. For privacy-sensitive enterprise work, this is a hard constraint.

Price. $50/M output tokens is real money for high-volume inference. Small teams and students will feel this.

Real-World Uses

Where Fable 5 actually earns its cost premium:

Software engineering at scale. Long refactoring runs, multi-file migrations, debugging unfamiliar codebases. The 50M-line codebase benchmark is illustrative. This is its obvious home.

Research and literature synthesis. The long context window and document reasoning capabilities make it genuinely useful for academic and technical research workflows.

Finance and legal document analysis. The vision improvements — reading tables, charts, and complex PDFs — directly target document-heavy professional work.

Scientific research (where the classifier doesn't fire). For biology and chemistry research that doesn't trigger the safety layer, this is a real capability upgrade.

Autonomous agent workflows. If you're building AI agents that run extended tasks with tool use, Fable 5 is the current frontier. The consistency across long contexts matters here.

Potential Losses and Risks

The risks here are not hypothetical.

If the jailbreak holds up under scrutiny — and early evidence suggests at least partial validity — then Mythos-class offensive security capabilities are now accessible to anyone with patience and knowledge of multi-agent decomposition. The classifier was the only gate. It's been bypassed.

The 120,000-character system prompt leak is a separate, sustained problem. It gives adversarial researchers a map of Fable 5's refusal logic. Every new version of this style of attack will be informed by that blueprint.

For enterprises, the covert restriction incident establishes a precedent: AI vendors can silently degrade performance without disclosure. Even after Anthropic's correction, that precedent was set. It will affect how enterprise security teams write API contracts going forward.

The IPO timing adds commercial pressure that doesn't obviously improve safety decision-making. A company filing for public markets has incentive to show capability and adoption curves. That tension with responsible deployment is worth watching.

My Perspective as a Software Engineering Student

I want to be honest about where I sit in this conversation.

I'm a software engineering student. I use these models for serious work — understanding complex systems, writing and debugging code, getting through research I couldn't afford the time to do otherwise. Fable 5 is relevant to me in a practical, not abstract, way.

And I think the honest take is this: Anthropic built something that is genuinely impressive and genuinely insecure, and then tried to manage the insecurity in ways that were sometimes dishonest.

The invisible ML research throttle bothers me more than the jailbreak. Jailbreaks happen. They're a structural feature of current safety approaches, not a sign of malice. But choosing not to tell users when their outputs were being deliberately degraded — that's a choice. That's not a technical accident. Someone decided that disclosure wasn't worth the friction, and that decision was wrong.

At the same time, the benchmarks are real. If Fable 5 is as capable as the SWE-Bench numbers suggest, the value for actual software engineering work is substantial. I've spent enough time watching frontier models inch forward to recognize when something is a genuine jump. This appears to be one.

The question for me isn't whether to use it. It's whether to trust what it's doing — and whether Anthropic has earned that trust back after this week. I think they took a step toward it by reversing the covert restriction. But the step was forced by community pressure, not voluntary.

That's a pattern worth paying attention to.

Final Thoughts

The story of Fable 5's first 72 hours is really two stories running in parallel.

In one, a powerful model built on dangerous capabilities was made public, jailbroken within a day, and its core instructions exposed to the world. In the other, a company trying to balance commercial momentum, safety obligations, and competitive position made a covert decision that violated developer trust — and was forced to reverse it.

Neither story is resolved.

The jailbreak will evolve. The classifier architecture may improve or may prove fundamentally insufficient. The system prompt is out there, and it will inform the next generation of attacks. Anthropic hasn't responded publicly to Pliny's claims. At some point, they'll have to.

The trust story is longer. Anthropic is approaching a public market. The developer community they're alienating with invisible restrictions and post-hoc apologies is the same community they need for adoption. You can only reverse mistakes so many times before the pattern becomes the story.

Fable 5 is, by the benchmarks, the best public AI model for software engineering work available today. That's true. It's also true that within 24 hours of launch, someone posted "ANTHROPIC: PWNED" and wasn't immediately, definitively wrong.

Both things are the landscape. Developers should operate accordingly.

Note: To stay fully transparent with the community, I want to share that I used AI assistance to help draft and polish this article. I’ve reviewed and edited everything to ensure it aligns with community guidelines and brings genuine value to you all!

Sources & Further Reading

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev

Is Node.js Still Enough? When to Move Your Backend to Rust

Syed Ahmer Shah — Sun, 07 Jun 2026 11:55:43 +0000

Node.js Is Not Failing You — You're Already Outgrowing It

The uncomfortable truth about backend performance, Rust, and why the event loop will betray you exactly when it matters most.

It was 3 AM. Not the good kind of 3 AM.

The monitoring dashboard looked like a medical emergency. Latency on the main API endpoint had gone from 38ms to over 4 seconds. Not spiking — sitting there, steady, 4 seconds on every request. The Node.js process wasn't crashed. That would've been easier, honestly. It was alive, the process was running, it was just completely frozen in place. Someone — and it wasn't me, I'm saying that for the record — had shipped a synchronous image compression function directly in the request handler. No worker thread. No queue. Just blocking, heavy, CPU-bound work sitting right there inside the event loop.

Every other request was standing in line behind it. Not errored. Not rejected. Just waiting to die.

That night broke something in my brain regarding how I thought about Node.js. Not in a dramatic "I'm done with this runtime" way. More in the way you start actually understanding something you thought you already understood. The event loop is not magic. It's a design choice. And every design choice has limits.

This article is about those limits. When they show up. What they look like. And whether Rust is actually the answer or just the current internet-famous overcorrection.

Why Everyone Started Here (And That Was Fine)

To be fair to Node.js, the original pitch was genuinely exciting. Ryan Dahl showed the world in 2009 that you could handle thousands of simultaneous connections with almost no memory overhead by using non-blocking I/O and a single-threaded event loop. JavaScript on the server. One language across the whole stack. One hiring pool. One mental model.

For most web applications that pitch still holds. REST APIs, GraphQL endpoints, WebSocket servers, BFFs, real-time dashboards, lightweight microservices — Node.js handles all of this with very little complaint. The npm registry crossed 2.5 million packages in 2024. The developer tooling around TypeScript and Node.js is genuinely excellent right now. You can spin up a production-ready Express or Fastify API in an afternoon and have it deployed before dinner.

And the thing is — most web applications are fine with this. Most companies are operating at scales where Node.js performance is genuinely not the bottleneck. The bottleneck is the database. Or the architecture. Or the fact that nobody indexed that column three years ago.

So when I say "you're outgrowing it" — I'm not saying you've outgrown it right now, today, reading this on your laptop. I'm saying the situations where the runtime itself becomes the problem are growing. And understanding where that line is seems more important than it used to.

The Event Loop Is a Single Lane Highway

Here's what nobody explains clearly when they first teach you Node.js.

The event loop is brilliant for waiting. Network requests go out, database queries go out, file reads queue up — the process just sits there juggling callbacks and never actually has to work very hard in between those I/O operations. Concurrent in the sense that many things are in flight at once. But still single-threaded. Still one lane.

The moment you give it real computation to do, it blocks. Full stop.

const express = require('express');
const app = express();

// This looks innocent enough
app.get('/generate-report', (req, res) => {
  const rawData = req.query.records;

  // 50,000 records, some sorting and aggregation
  // This takes ~800ms on a decent machine
  const parsed = JSON.parse(rawData);
  const sorted = parsed.sort((a, b) => b.revenue - a.revenue);
  const aggregated = sorted.reduce((acc, item) => {
    acc[item.region] = (acc[item.region] || 0) + item.revenue;
    return acc;
  }, {});

  res.json(aggregated);
});

app.listen(3000);

While that 800ms computation runs, every other request hitting your server sits in a queue. No parallelism. No preemption. The user requesting their login token is waiting for a sales report to finish generating. That's the architecture. That's not a bug in the code — that's how the runtime works.

Worker threads exist, yeah. worker_threads has been available since Node.js 11.7. But using them correctly is genuinely more complex than it should be, and honestly it's a workaround for a design limitation rather than a first-class solution. You're fighting the runtime's nature.

// The worker_threads "fix" — real code, real overhead
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
const express = require('express');

if (isMainThread) {
  const app = express();

  app.get('/generate-report', (req, res) => {
    const worker = new Worker(__filename, {
      workerData: { records: req.query.records }
    });

    worker.on('message', (result) => res.json(result));
    worker.on('error', (err) => res.status(500).json({ error: err.message }));
  });

  app.listen(3000);

} else {
  // Same logic, now in a thread
  const parsed = JSON.parse(workerData.records);
  const sorted = parsed.sort((a, b) => b.revenue - a.revenue);
  const aggregated = sorted.reduce((acc, item) => {
    acc[item.region] = (acc[item.region] || 0) + item.revenue;
    return acc;
  }, {});
  parentPort.postMessage(aggregated);
}

This works. But you're now managing worker lifecycles, serialization overhead, error propagation across thread boundaries. For one endpoint. And you're still not getting native parallelism — you're getting OS thread concurrency with a JavaScript wrapper around it.

Is this the direction you want to keep going?

What Garbage Collection Silently Does to Your Latency

There's another issue that gets less attention than CPU blocking, and it's more subtle and harder to debug. Garbage collection pauses.

Node.js uses V8's garbage collector. V8 is genuinely excellent engineering. But even excellent GC has to stop and clean up memory at some point. In production, under real load, with real memory pressure, these pauses are real. They're usually short — tens to hundreds of milliseconds. Sometimes longer. And they're not triggered by your code. They're triggered by the runtime. You cannot schedule them, predict them precisely, or prevent them.

For a lot of applications this is totally acceptable. For latency-sensitive systems — financial data feeds, real-time multiplayer, high-frequency trading, voice and video processing, anything where a 200ms unpredictable pause actually matters — GC becomes a design problem, not just a performance footnote.

This is not a Node.js-specific problem. Go has it. Java has it. Python has it. Every language with a managed runtime has it. Which is, importantly, why Rust's approach is so different.

What Rust Actually Offers (Without the Cult)

Rust is a systems programming language that compiles to native machine code with no garbage collector and no runtime overhead in the traditional sense. Developed originally at Mozilla, now maintained by the Rust Foundation with backing from Amazon, Google, Microsoft, and Meta. First stable release in 2015. Slow build, fast execution, steep learning curve.

The borrow checker — Rust's most infamous feature — is the compile-time system that enforces memory safety without a GC. Instead of collecting garbage at runtime, Rust proves at compile time that your code cannot have dangling pointers, data races, or use-after-free bugs. The compiler rejects the code if it finds violations. That sounds annoying (it is, initially) but what it means in practice is that entire categories of runtime bugs simply do not exist in Rust programs.

For the ninth consecutive year, in the 2024 Stack Overflow Developer Survey, Rust ranked as the most admired programming language. 83.5% of Rust developers said they want to keep using it. That's not a hype cycle anymore. Nine years is a signal. That's a community of people who went through the hard part and stayed.

But let's be clear about something: Rust is not a replacement for Node.js in the general case. It's a replacement for Node.js in specific cases. The key is knowing which cases those are.

The Discord Post That Every Backend Developer Should Read

In February 2020, Discord published a blog post called "Why Discord is switching from Go to Rust." If you work in backend development and you haven't read it, go read it. It changed how I think about language and runtime choices.

Discord was running their Read States service in Go. This is the service that tracks which messages you've read across all your servers and channels. At their scale, it was handling millions of concurrent users. Go's garbage collector kept introducing latency spikes every two minutes, almost like clockwork. Users experienced stutters. Discord tried tuning the GC. They tried throwing more memory at the service to space out collection cycles. The spikes kept coming. They couldn't engineer their way out of a fundamental runtime behavior.

They rewrote the service in Rust.

The latency spikes disappeared. Not reduced — disappeared. Memory usage dropped dramatically. The service became boring in the best possible way. It just ran. Predictably. Consistently. Without surprise pauses.

The thing that gets me about that story isn't the performance numbers. It's the fact that they weren't doing anything exotic. Read States is conceptually simple: track what you've read, update it in real time, serve it fast. That's not a supercomputer problem. But at Discord's scale, the runtime's behavior became the application's behavior. And they couldn't hide from it.

Cloudflare's Bigger, Quieter Bet

If Discord is an interesting data point, Cloudflare is a confirmation of the direction things are heading.

In 2022, Cloudflare announced Pingora — a new HTTP proxy built in Rust that they'd been running internally as a replacement for NGINX. In February 2024, they open-sourced it. The numbers they reported were not subtle: the service runs at over 1 trillion requests per day across their network. CPU usage dropped. Memory usage dropped significantly compared to their NGINX setup. The Rust rewrite was not a side project or an experiment. It became the backbone of how Cloudflare connects to the internet.

Cloudflare Workers — their serverless edge computing platform — lets developers deploy JavaScript and TypeScript at the edge. But the runtime itself, the thing executing your JavaScript efficiently at hundreds of datacenters worldwide? Built in Rust. You're writing JS code that runs inside a Rust-built sandbox.

Deno 2.0 shipped in October 2024. Built on Rust bindings to V8. Added much better Node.js compatibility, making it a genuine migration path from Node. Bun, the other JavaScript runtime that came up as a performance competitor, is built on Zig — which, like Rust, compiles to native code and has no GC.

Here's the thing that I think deserves more attention: even in ecosystems where the developer experience stays JavaScript, the infrastructure layer underneath is moving toward Rust and systems languages. The fastest runtimes are compiled. The most reliable proxies are compiled. The pattern is not "Rust instead of Node.js" at the application layer. The pattern is "Rust underneath everything" at the infrastructure layer.

That matters because the performance expectations users are going to have — shaped by Cloudflare edge computing, Pingora proxy speeds, and Deno/Bun runtime benchmarks — are going to creep upward. And Node.js in the middle will have to answer for it.

What Rust Looks Like for a Backend Developer

Here's a basic HTTP endpoint in Actix-Web, which is one of the more popular Rust web frameworks:

use actix_web::{web, App, HttpServer, HttpResponse, Responder};
use serde::{Deserialize, Serialize};
use tokio::task;

#[derive(Deserialize)]
struct ReportRequest {
    region: String,
    record_count: u32,
}

#[derive(Serialize)]
struct ReportResponse {
    region: String,
    total_revenue: u64,
    record_count: u32,
}

async fn generate_report(query: web::Query<ReportRequest>) -> impl Responder {
    // CPU-bound work goes to a blocking thread pool
    // This does NOT block other async requests
    let result = task::spawn_blocking(move || {
        // Simulate heavy computation
        let mut total: u64 = 0;
        for i in 0..query.record_count as u64 {
            total += i * 42; // Some CPU work
        }
        total
    }).await.unwrap();

    HttpResponse::Ok().json(ReportResponse {
        region: query.region.clone(),
        total_revenue: result,
        record_count: query.record_count,
    })
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/report", web::get().to(generate_report))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Compared to the Node.js version with worker threads, the structural difference is significant. Rust's async model is built on top of actual OS thread pools. The CPU-bound work in spawn_blocking runs in a separate thread pool managed by Tokio (the async runtime) without blocking the async task executor. There's no serialization overhead across an IPC channel. There's no GC ever entering the picture. The borrow checker ensures at compile time that the closure passed to spawn_blocking doesn't share mutable state with anything else.

The TechEmpower Framework Benchmarks — which are one of the more credible public benchmarks for web framework performance across languages — consistently place Actix-Web and ntex (another Rust web framework) in the top tier for raw throughput. Express.js and Fastify appear much lower. Not because Node.js frameworks are badly written, but because the measurement is raw request throughput and Rust's compiled native execution simply processes requests faster at the infrastructure level.

For I/O-bound workloads, the difference narrows. For CPU-intensive workloads, it widens considerably.

The Real Cost of Switching Nobody Tells You About

Here's the section that most "Node.js to Rust" migration articles skip, or mention briefly before rushing to the benchmark charts. The actual cost of this migration is serious and you should stare at it for a while before deciding anything.

The learning curve is genuinely steep. Not in a "watch a few tutorials and you're good" way. The borrow checker, lifetimes, ownership — these concepts don't exist anywhere in JavaScript. They don't really exist in Python, Ruby, Go, or most languages most backend developers have used. It will take a capable developer weeks of dedicated effort before they stop fighting the compiler on basic memory patterns. Not writing good Rust. Just getting past the initial wall.

The hiring pool is small. npm knows 2.5 million packages. Node.js developers are everywhere. Finding a Rust developer with production web backend experience is a different challenge entirely. You're paying more, waiting longer, and getting someone who probably learned Rust on personal projects and systems code, not web services. The talent market is growing, slowly.

The ecosystem is thinner. crates.io had around 150,000 packages as of early 2025. Growing fast, but not npm. For certain integrations — some payment gateways, certain analytics SDKs, niche database clients — you'll find yourself writing wrapper code or bindings that you'd get for free in Node. That's real engineering time.

Compile times. This one is annoying in day-to-day development. Cold builds on a mid-size Rust project take several minutes. Incremental builds are better. But the feedback loop is longer than TypeScript. When you're debugging something fast-moving, that matters to your energy and focus.

None of this means don't do it. It means count the cost before you commit. Migration projects that underestimated the friction tend to get abandoned halfway through, which leaves you with a half-Rust, half-Node.js system that has the downsides of both and the advantages of neither.

Stop. Answer These Questions Honestly.

Before you close this tab and start reading the Actix-Web documentation, ask yourself:

Have you actually profiled your application? Most Node.js performance problems are not the runtime. They're N+1 database queries, missing indexes, no caching layer, or serializing entire database rows when you only need two fields. None of those are fixed by switching to Rust. Find the actual bottleneck before you decide what to replace.

What is your real traffic volume? If you're handling under 500 requests per second and your endpoints are mostly database reads, Rust is almost certainly not where your engineering time should go. The overhead of the migration will dwarf any performance gain at that scale.

Does your use case actually involve CPU-bound work? AI inference, image processing, cryptographic operations, video transcoding, large data aggregations, compression — these are legitimate candidates for a Rust service. Authentication checks and database-backed CRUD are not.

What does your team actually want to learn? This is the one people underrate most. A team that genuinely wants to learn Rust will fight through the rough parts and come out the other side shipping good code. A team that's being told to use Rust because leadership read a blog post will write bad Rust slowly and resent the whole thing.

When You Genuinely Should Not Move to Rust

Early-stage startups or solo developers trying to ship a product. Developer velocity is your scarcest resource. Use the stack you know. The performance difference between Node.js and Rust is irrelevant if you're trying to find product-market fit.

Standard web applications with normal CRUD logic. A TypeScript + Node.js + Prisma + PostgreSQL stack is a genuinely excellent combination for most web products. There is nothing broken about it. Adding Rust to this because you read about Discord is not senior engineering — it's resume-driven development.

Teams where nobody wants to learn Rust. Forced adoption of technology produces the worst version of that technology. A team that doesn't want to be there will produce buggy, unidiomatic, unmaintained Rust that will be a liability in six months.

When you haven't exhausted your current optimizations. Have you looked at clustering Node.js processes? Have you profiled your event loop lag? Have you moved CPU work to queues or separate services? Have you reviewed your database query plans? These cost less than a rewrite and often fix the problem.

My Actual Opinion

I'm going to stop being balanced here and just say what I think.

Node.js is not going away. It will be running a meaningful portion of the internet ten years from now, the same way PHP still runs half the web despite being declared dead roughly every eighteen months. It's battle-tested, well-understood, and good enough for the vast majority of what gets built.

But I do think there's a version of "defaulting to Node.js without thinking" that's becoming harder to justify as the use cases for backends get more complex. AI inference is being pushed to the backend. Real-time systems are becoming more common. Edge computing is maturing. Workloads are changing. And the runtime you picked in 2019 for a REST API might not be the right answer for what you're building in 2026.

The smarter architecture for most teams isn't a full rewrite. It's a hybrid — Node.js handling your API gateway, your user-facing routes, your standard CRUD, and a Rust service (or a few) handling the parts that actually need performance. One Rust microservice doing image resizing. One handling the expensive report generation. Keep the rest of your system in a language your team already knows. Add Rust where it earns its complexity cost.

Is Node.js still enough? For most of what most people are building, honestly yes. For the direction backends are heading over the next five years — probably not everywhere.

The question isn't whether to switch. The question is whether you understand your runtime well enough to know when switching actually helps. Most developers don't. Most developers, including me a couple of years ago, just pick Node.js because it's comfortable. That's fine — until it isn't.

Start learning Rust. Not to rewrite anything. Just to understand what you're missing. The moment you write your first program that compiles cleanly with the borrow checker satisfied, you understand something about memory and ownership that changes how you write code in every other language too.

That's worth something, independent of whether you ever ship a Rust API.

References and Sources

Stack Overflow Developer Survey 2024 — https://survey.stackoverflow.co/2024/
"Why Discord is switching from Go to Rust" — Discord Engineering Blog, February 2020 — https://discord.com/blog/why-discord-is-switching-from-go-to-rust
"How we built Pingora, the proxy that connects Cloudflare to the internet" — Cloudflare Blog — https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/
"Pingora: Open Source" — Cloudflare Blog, February 2024 — https://blog.cloudflare.com/pingora-open-source/
TechEmpower Web Framework Benchmarks — https://www.techempower.com/benchmarks/
Deno 2.0 Release — Deno Blog, October 2024 — https://deno.com/blog/v2.0
"The Rust Programming Language" (official book) — https://doc.rust-lang.org/book/
Node.js Worker Threads Documentation — https://nodejs.org/api/worker_threads.html
Actix-Web Documentation — https://actix.rs/docs/
Tokio Async Runtime Documentation — https://tokio.rs/
crates.io — Rust Package Registry — https://crates.io
"Node.js: The Documentary" — Honeypot, YouTube, 2024

Written by a software engineering student who blocked the event loop in production once and decided to understand why. If something here is wrong, tell me — that's how this works.

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev