DEV Community: Syed Ahmer Shah

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

What 90% of Devs Screw Up When Wiring Next.js, Node.js, and Git Together

Syed Ahmer Shah — Fri, 05 Jun 2026 10:43:44 +0000

And some of those devs pushed to production. That's the scary part.

There's this one story I keep thinking about. A junior dev — smart kid, decent portfolio — built a full-stack app for his freelance client. Next.js frontend, Node.js backend, everything wired together. Pushed to GitHub. Client's competitor found the repo three weeks later because it was public and the .env file was sitting right there. Database password. Stripe secret keys. Everything.

That project was not just a technical failure. It was a trust failure.

And here's the brutal thing: it wasn't a dumb mistake from an incompetent person. It was a normal mistake from a developer who never learned the actual mechanics of connecting these three tools. He knew how to code. He didn't know how they link.

Most developers are in that same boat right now in 2026, and none of them would admit it.

Why This Stack Is So Dominant Right Now (And Why That Creates a Problem)

Next.js, Node.js, and Git. This is basically the default web dev stack for a huge chunk of the internet at this point. Next.js crossed 6 million weekly npm downloads in late 2024 and has held that range through 2025 into 2026. Node.js powers something like 6.3% of all websites directly and a much larger chunk indirectly through server-rendered frameworks. Git is used by 97.8% of professional developers according to the Stack Overflow Developer Survey 2025.

So you've got three massively dominant tools that every developer is expected to just... know. And because everyone assumes everyone else already knows this, nobody actually teaches how they interact.

The documentation covers them separately. Tutorials cover them in isolation. And then a developer has to wire them together in a real project and suddenly nothing makes sense.

This is that article. The one nobody wanted to write because it's admitting that the ecosystem has gaps nobody talks about.

The Actual Mistakes (And How Bad They Get)

Let me go through them honestly. Not in order of how often they happen but in order of how badly they can hurt you.

1. Your .env File Is Probably Already on GitHub

I'm going to say this as directly as possible.

If you started a Next.js or Node.js project in the last three years and you didn't set up .gitignore before your first git init or git add ., there is a real chance your secrets are in your repository history. Even if you deleted the file later. Git doesn't work like a regular file system. It remembers.

GitHub's own security team reported that in 2024 alone, more than 12.8 million secrets were exposed in public repositories. That includes API keys, database credentials, tokens, private keys. The number in 2025 was not smaller.

And the thing is, .env is listed in the default .gitignore that create-next-app generates. So why does this keep happening?

Because developers clone starter repos. They spin up custom setups. They copy folder structures from YouTube tutorials that are six months old and never show the .gitignore setup. They run git add . out of habit.

Here's what a proper .gitignore for a Next.js + Node.js project actually looks like:

# Node
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*

# Next.js
.next/
out/
build/
dist/

# Environment variables - THIS IS THE ONE
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
.env*.local

# Vercel
.vercel

# TypeScript
*.tsbuildinfo
next-env.d.ts

# OS
.DS_Store
*.pem
Thumbs.db

# Debug
.npm
.eslintcache

And if you've already pushed secrets, here's the painful truth: deleting the file and pushing again does NOT remove it from history. You need to do this:

# Install git-filter-repo (better than BFG for 2025+)
pip install git-filter-repo

# Remove the .env file from entire history
git filter-repo --path .env --invert-paths

# Then force push (you will need to coordinate with your team)
git push origin --force --all

But honestly if the secret was already exposed for more than a few hours? Rotate the credentials. Assume they were taken. That's the real answer.

2. The NEXT_PUBLIC_ Trap Nobody Explains Properly

This one is subtle and it catches even experienced developers.

Next.js has two environments: server and client. Environment variables work differently in both. Variables that start with NEXT_PUBLIC_ are bundled into the client-side JavaScript. Everything else stays on the server.

Sounds simple. But here's where people get it wrong.

// This runs on the SERVER (API route, Server Component)
// Works fine
const dbPassword = process.env.DB_PASSWORD;

// This runs on the CLIENT (browser)
// process.env.DB_PASSWORD is undefined here
// because it's not prefixed with NEXT_PUBLIC_
const something = process.env.DB_PASSWORD; // undefined, no error, just silently broken

The terrifying part isn't the error. It's the silence. You won't get a crash in many cases. You'll just get undefined and then a cryptic failure somewhere downstream that takes you an hour to debug.

And the opposite mistake is even worse:

// DON'T DO THIS
// This exposes your secret to every user's browser
NEXT_PUBLIC_DB_PASSWORD=supersecret123
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_...

Anything with NEXT_PUBLIC_ is visible to anyone who opens your site. It gets embedded into the JavaScript bundle. DevTools. View Source. It's all there.

Variable Type	Accessible In	Exposed to Browser?	Use For
`NEXT_PUBLIC_*`	Client + Server	YES	API base URLs, public keys, analytics IDs
Regular `ENV_VAR`	Server only	NO	DB passwords, secret keys, tokens
`process.env.NODE_ENV`	Both	NO (built-in)	Environment detection

The rule is simple: if it's a secret, it never gets NEXT_PUBLIC_. If it has to be on the client, it better not be a secret.

3. CORS Is Not a Bug. It's You.

You've got Next.js running on port 3000. Your Node.js/Express backend is on port 3001. You make a fetch request. CORS error. You Google it. You find a Stack Overflow answer from 2019 that tells you to do this:

// The lazy "fix" everyone copies
app.use(cors());

And it works locally. So you push to production.

And then in production it breaks again because the origin is different, or worse: it works but you've now allowed every single origin on the planet to make requests to your backend. Including people you don't want.

Here's what actually correct CORS configuration looks like for a Next.js + Node.js setup:

// Express backend - cors.config.js
const allowedOrigins = [
  'http://localhost:3000',
  'https://your-actual-domain.com',
  process.env.FRONTEND_URL // dynamic, set in .env
].filter(Boolean);

app.use(cors({
  origin: function(origin, callback) {
    // Allow requests with no origin (mobile apps, Postman, curl)
    if (!origin) return callback(null, true);

    if (allowedOrigins.indexOf(origin) === -1) {
      const msg = 'CORS policy blocked this origin: ' + origin;
      return callback(new Error(msg), false);
    }
    return callback(null, true);
  },
  credentials: true, // if you're using cookies/sessions
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
}));

And honestly? If you're already using Next.js, ask yourself whether you need a separate Express server at all. Next.js API routes handle a huge amount of backend logic without this CORS mess.

4. You Don't Actually Know When to Use API Routes vs Express

This is the architectural confusion that costs teams weeks.

Next.js has built-in API routes (in pages/api/ or app/api/route.ts). They run on Node.js. They're serverless by default when deployed to Vercel. They're fine for most things.

But a lot of developers either:

a) Build a whole Express.js server for things Next.js API routes would handle perfectly, creating unnecessary complexity and CORS problems.

b) Cram everything into Next.js API routes when they actually need persistent connections, WebSockets, heavy background jobs, or something Vercel doesn't support well.

Here's the honest comparison:

Use Case	Next.js API Routes	Separate Node.js/Express
CRUD for your app's own data	Perfect	Overkill
Authentication (JWT, sessions)	Fine	Unnecessary complexity
Real-time features (WebSockets)	Not supported natively	Required
Heavy file processing	Cold starts are a problem	Better
Shared API between multiple frontends	Awkward	Right choice
Microservices architecture	Wrong tool	Right tool
Background jobs / cron	Limited (Vercel Cron has limits)	Better
Long-running processes	Hard timeout limits	Required
Database connection pooling at scale	Works but tricky	More control

If you're building a standard web app with a database, auth, and CRUD — just use Next.js API routes. You don't need Express. You're adding complexity for no reason.

If you're building something that needs persistent connections, serves multiple clients, runs heavy background jobs, or lives on a VM you control — separate Node.js server makes sense.

Most developers I've seen choose the wrong one because they learned Express first and can't let it go.

5. Hardcoded URLs That Die in Production

This one is so common it's almost a rite of passage.

// Works on your laptop, breaks everywhere else
const response = await fetch('http://localhost:3001/api/users');

This is hardcoded to localhost. When you deploy to Vercel or any server, localhost:3001 means nothing. There's no machine called localhost in production. The request goes nowhere.

The fix isn't complicated. But you have to actually do it.

// In .env.local (for development)
NEXT_PUBLIC_API_BASE_URL=http://localhost:3001

// In .env.production
NEXT_PUBLIC_API_BASE_URL=https://api.yourdomain.com

// In your code
const API_BASE = process.env.NEXT_PUBLIC_API_BASE_URL;

const response = await fetch(`${API_BASE}/api/users`);

And if you're using Next.js API routes as your backend (same app), you don't even need an absolute URL:

// This works in both dev and production when backend = same Next.js app
const response = await fetch('/api/users');

Relative URLs. Underrated. People overcomplicate this.

6. Git Workflow for Full-Stack Projects Is Different and Nobody Talks About It

In a typical single-technology project, Git workflow is straightforward. Feature branch, PR, merge. But in a Next.js + Node.js project where the frontend and backend are sometimes in the same repo and sometimes in different repos, things get messy fast.

The two main patterns:

Monorepo (same repo, both apps)

my-project/
  ├── apps/
  │   ├── web/          (Next.js)
  │   └── api/          (Express.js)
  ├── packages/
  │   └── shared/       (shared types, utilities)
  └── package.json      (root, with workspaces)

Polyrepo (separate repos)

my-project-frontend/    (Next.js)
my-project-backend/     (Express.js)

The mistake most junior developers make is none of the above. They put everything in one flat folder and commit everything together, so a frontend change and a backend change always get tangled in the same commit. Makes code review messy. Makes rollbacks a nightmare.

And then there's branching. Here's what actually works for full-stack:

# Never commit directly to main
git checkout -b feature/user-authentication

# Commit frequently with meaningful messages
# Bad commit message:
git commit -m "fix stuff"

# Good commit message:
git commit -m "feat(auth): add JWT validation middleware to /api/auth/verify

- Validates token expiry
- Returns 401 on invalid token
- Logs failed attempts to console (temporary)"

# When done, push and open PR
git push origin feature/user-authentication

The conventional commits standard (feat:, fix:, chore:, docs:, refactor:) isn't just cosmetic. Tools like semantic-release and automatic changelog generators depend on it. In 2026 with AI code review tools integrated into GitHub, structured commits also give the AI better context about what changed.

7. The package-lock.json Civil War

Every team eventually has this fight.

One developer uses npm install. Another uses yarn add. A third one used pnpm because they watched a YouTube video. Now you have package-lock.json, yarn.lock, and pnpm-lock.yaml all in the same repo. Three different lockfiles, three different dependency resolution algorithms, and production might be running a completely different version of a package than what's on your laptop.

This is not a minor problem. Node.js's package ecosystem has had supply chain attacks where malicious code ended up in popular packages. Lockfiles are your defense mechanism. If everyone on the team is generating different lockfiles, the lockfile is meaningless.

Pick one package manager. Enforce it. Delete the others.

// package.json - add this
{
  "engines": {
    "node": ">=22.0.0",
    "npm": ">=10.0.0"
  },
  "packageManager": "npm@10.8.0"
}

# .npmrc - to enforce no other package managers
engine-strict=true

And commit your package-lock.json. I know it's large. I know it creates merge conflicts. Commit it anyway. The moment you add it to .gitignore you've thrown away reproducible builds.

8. The .next Folder Is Not Source Code

This is a smaller mistake but it's one of those things that adds up.

.next/ is Next.js's build output folder. It's generated fresh every time you run next build or next dev. It's specific to your machine, your Node.js version, and your build configuration.

Some developers commit it because they think it's needed. It's not. It should be in .gitignore.

Folder	Commit to Git?	Why
`.next/`	No	Build output, machine-specific
`node_modules/`	Never	Installable from package.json
`out/`	Usually no	Static export output
`public/`	Yes	Static assets served by app
`src/`	Yes	Your actual source code
`.env.local`	Never	Local secrets
`next.config.js`	Yes	Configuration, not secrets

Committing node_modules is the classic version of this mistake. Everyone learns it eventually. But .next/ and out/ catch more people than you'd think.

9. Nobody Configures next.config.js for Real Environments

The next.config.js file is where a lot of important production behavior lives and most tutorials just skip it entirely.

Here's a real example of things that break in production because they weren't configured:

// next.config.js - what a real production config looks like

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Tell Next.js where your external API lives (for rewrites/proxying)
  async rewrites() {
    return [
      {
        source: '/api/backend/:path*',
        destination: `${process.env.BACKEND_URL}/api/:path*`,
      },
    ];
  },

  // Image domains (or you get 400 errors on external images)
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-image-cdn.com',
        port: '',
        pathname: '/images/**',
      },
    ],
  },

  // Environment variables you want to expose through Next.js config
  // (alternative to NEXT_PUBLIC_ prefix for build-time values)
  env: {
    APP_VERSION: process.env.npm_package_version,
  },

  // Strict mode - catches more React issues in dev
  reactStrictMode: true,

  // Output mode for deployment
  // 'standalone' is what you want for Docker/VPS deployment
  output: process.env.NEXT_OUTPUT_MODE || undefined,
};

module.exports = nextConfig;

One that kills a lot of people: Next.js 15 (with App Router) handles rewrites differently from the Pages Router in some edge cases. If you're proxying requests to your Node.js backend through Next.js rewrites, test this in a staging environment that matches production. Vercel's serverless environment is not the same as next start on a VPS.

10. The Deployment Split Nobody Plans For

Here's the final one and it's the most expensive mistake in real projects.

You build your app locally. Next.js and Node.js both run on your machine, communicate fine, everything works. Then you go to deploy. And someone (probably you) makes a decision without thinking about it:

"I'll put the Next.js app on Vercel because it's free and easy."

So your Next.js app is on Vercel, which is serverless, auto-scaling, edge-deployed.

Your Node.js backend is on... a $5 DigitalOcean droplet. Or Railway. Or Render's free tier that spins down after 15 minutes of inactivity.

Now you have:

Different deployment cadences
Different environment variable management systems
Cold start latency on one side but not the other
CORS configuration that has to be updated every time the domain changes
Two separate CI/CD pipelines to maintain
Your Node.js backend hitting cold starts on the free tier, making your Vercel frontend look slow

Nobody planned this. It happened by accident. And now you're refactoring three months into the project.

The planning question you have to answer before writing a line of code:

Scenario	Frontend	Backend	Notes
Hobby project, low traffic	Vercel	Vercel (API Routes only)	One deployment, no CORS
Medium app, budget matters	Vercel	Railway / Render	Plan for cold starts
Serious production app	Vercel	VPS (DigitalOcean, Hetzner)	Most control, more work
Full control / enterprise	VPS (Docker)	VPS (same or different)	You manage everything
Monorepo, full stack	Vercel	Vercel (both)	Works if serverless is fine

What the Actually Good Developers Do That Nobody Posts About

I've worked with and observed enough codebases at this point to notice the difference. Here's what separates developers who get this right:

They set up the project structure before writing the first component. .gitignore, environment variable schema, API base URL configuration — all before git init.

They test environment variable loading in isolation. Before wiring up any API call, they console.log(process.env.WHATEVER) in the actual runtime context where it'll be used. Server component? Client component? API route? They verify.

They use a .env.example file committed to the repo that shows every variable needed without the values. This is how you tell your team what to configure without leaking anything.

# .env.example (COMMIT THIS)
DATABASE_URL=postgresql://user:password@host:port/database
NEXTAUTH_SECRET=generate-with-openssl-rand-base64-32
NEXTAUTH_URL=http://localhost:3000
BACKEND_URL=http://localhost:3001
NEXT_PUBLIC_API_BASE_URL=http://localhost:3001

# Production values go in your deployment platform's environment settings
# NEVER commit .env.local or .env.production

They treat Git history as documentation. Not just for code review. When something breaks in production six months later, a good commit history lets you bisect the problem in minutes instead of hours.

# Binary search through commits to find when a bug was introduced
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Git checks out the middle commit, you test it
# Then mark good or bad until you find the exact commit
git bisect good  # or git bisect bad

They never debate whether to use the App Router or Pages Router in 2026. The App Router is the default, it's stable, React Server Components are the future of this ecosystem. If you're starting a new project today and using Pages Router you're actively choosing to work with a deprecated pattern. That's a choice you're allowed to make but be honest that it's a choice.

Spicy Take: The Real Problem Is Tutorials, Not Developers

Okay I'm going to say this and people are going to disagree with me.

The reason 90% of developers get this wrong isn't stupidity or laziness. It's the tutorial industry.

A YouTube tutorial on "Build a Full Stack App with Next.js and Node.js" has a 43-minute runtime. The first 38 minutes is features. The last 5 minutes is "and now deploy it to Vercel." The .gitignore setup takes 30 seconds and is either done off-camera or copied from a template without explanation. Environment variables are hardcoded for simplicity. CORS is fixed with app.use(cors()) and nobody explains why.

Millions of developers learned from those tutorials. And then they went to build real things with those patterns and ran into real problems.

"The documentation tells you what the tools do. It rarely tells you what happens when you misuse them in combination."

That gap between "I finished the tutorial" and "I can build real production software" is where most developers are stuck. And the combination of Next.js, Node.js, and Git is exactly where that gap shows up most violently.

The One Thing That Would Fix 80% of These Problems

It's embarrassingly simple.

Start every project with this:

# 1. Initialize git FIRST, before anything else
git init my-project
cd my-project

# 2. Create .gitignore BEFORE adding any files
# Copy the one from the Node + Next.js section above

# 3. Create .env.example
touch .env.example
# Write out all the variables your app will need (empty values)

# 4. Create .env.local for your actual local values
# (This is already in .gitignore so it won't be committed)

# 5. THEN scaffold your Next.js app
npx create-next-app@latest . --typescript

# 6. First commit should be: gitignore + env.example + nothing else
git add .gitignore .env.example README.md
git commit -m "chore: project initialization with gitignore and env template"

That sequence. In that order. If every new developer starting a Next.js project followed those six steps in that order, the number of accidental secret exposures would drop dramatically.

The order matters because once you run create-next-app, you're tempted to immediately start building. And in that excitement, you forget to check what's actually being staged when you do git add ..

Data Snapshot: Where This Stack Is in 2026

Some numbers that give context to why this matters at scale:

Next.js remains the dominant React meta-framework by weekly npm downloads (consistently above 5.8M per week through Q1 2026)
Node.js 22 LTS is the current recommended version as of early 2026; Node.js 24 released April 2025 is on a path to LTS in October 2026
Git is used by 97.8% of developers in the Stack Overflow Developer Survey 2025 — effectively universal
The State of JavaScript 2024 survey showed Next.js with 81% retention (developers who used it and would use it again) and rising adoption year-over-year
GitHub's transparency report data for 2024 indicated that secrets scanning blocked millions of exposures before they became public — meaning the push-protection feature is catching the exact mistakes described in this article

The scale of adoption means these mistakes aren't happening to a few developers. They're happening tens of thousands of times a day, globally, by people across all experience levels.

Common Questions That Don't Have Good Answers Online

"Should I use Next.js API routes or a separate Express server for a startup?"

If you're building a startup MVP, use Next.js API routes. You'll ship faster and you have one less deployment to manage. When you hit actual scaling problems, migrate. You won't hit those problems as early as you think.

"Does it matter if node_modules gets committed once?"

Yes. node_modules can be hundreds of megabytes. It bloats your repository permanently (remember, Git keeps history). And it creates reproducibility problems. Delete it from history using git filter-repo the same way you'd remove a secret.

"What's the right Node.js version to use with Next.js 15?"

Node.js 18 is the minimum for Next.js 15. Node.js 22 LTS is what you should be using in production as of early 2026. The compatibility table on the Next.js docs is up to date and should be your source of truth.

"Why does my Next.js app work on Vercel but my environment variables are undefined?"

Because you configured them in .env.local on your machine but forgot to add them to Vercel's environment variable settings in the dashboard. Vercel does not read your .env.local. You have to set every variable manually in the Vercel project settings. This trips up everyone once.

Final Thought

The combination of Next.js, Node.js, and Git is genuinely powerful. The ecosystem in 2026 is mature enough that you can build serious production applications with it and compete with teams twice your size.

But "powerful" and "forgiving" are different things. This stack is not forgiving. It will let you push your .env to GitHub. It will silently give you undefined instead of your secret key. It will deploy with broken environment variables and give you no useful error message at 2am.

The developers who get this right aren't necessarily more talented. They've just been burned once and learned from it, or they were lucky enough to learn from someone who was burned.

Now you've read about it instead of having to live through it.

Use that.

References and Sources

GitHub Security: "Detected and Prevented Secrets in 2024" — GitHub Blog, January 2025. https://github.blog/security/application-security/
Stack Overflow Developer Survey 2025 — Version Control Systems usage data. https://survey.stackoverflow.co/2025
State of JavaScript 2024 — Meta-Frameworks section, Next.js retention and usage figures. https://2024.stateofjs.com/
Next.js 15 Release Notes and Changelog — Vercel/Next.js GitHub repository. https://github.com/vercel/next.js/releases/tag/v15.0.0
Node.js Release Schedule — Node.js Foundation. https://nodejs.org/en/about/previous-releases
npm package download statistics for next — https://www.npmjs.com/package/next (weekly download trends, 2024-2026)
Next.js Documentation: Environment Variables — https://nextjs.org/docs/app/building-your-application/configuring/environment-variables
Next.js Documentation: API Routes — https://nextjs.org/docs/pages/building-your-application/routing/api-routes
Conventional Commits Specification v1.0.0 — https://www.conventionalcommits.org/
git-filter-repo documentation — https://github.com/newren/git-filter-repo
OWASP Secrets Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
Vercel Deployment Environment Variables Guide — https://vercel.com/docs/projects/environment-variables

This article reflects my actual experience debugging these issues in real codebases. The mistakes described are patterns I've seen repeatedly, not edge cases. If something here contradicts what you've been doing, that's not an accident.

Find me across the web:

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

Will AI Replace Software Engineers? No. But It Will Shrink Junior Roles.

Syed Ahmer Shah — Wed, 03 Jun 2026 14:57:05 +0000

And if you think you have time to "wait and see," you really, really don't.

Let me tell you about a friend of mine. Seven years of experience. Mid-level engineer. $190K total comp at a solid company — a Series B startup, let's not get sidetracked with names. He got laid off in early 2025. It happens. He had a strong GitHub profile, could do system design in his sleep, had a clean resume that would've cleared any screen two years ago. He got to final rounds at three different companies.

Lost all three.

The feedback, each time, was some version of the same sentence: "We went with someone who was more fluent with AI tools."

He wasn't anti-AI. He used Copilot sometimes. He wasn't one of those "real engineers write real code" types. He just hadn't gone deep on it. Sometimes was enough — until suddenly it wasn't. The bar had moved and nobody sent him a memo.

That story is not unique. Right now, as you're reading this in 2026, that exact story is playing out for tens of thousands of engineers across every level, every stack, every timezone. And here's the part that makes it worse: it's not slowing down. It's accelerating.

Let's look at what's actually happening.

The Numbers Don't Care About Your Feelings

A lot of engineers are still operating on vibes. They hear "AI won't replace developers," breathe out, and go back to writing CRUD endpoints like nothing changed. I get it. But let's stop going on vibes for a second and look at what the data says.

American tech companies eliminated more than 142,000 jobs in just the first five months of 2026 — a 33% increase over the same period the year before — even while those same employers were posting record revenues and committing to the largest infrastructure buildout in tech history, according to tech layoff trackers. Read that again. Record revenues. More layoffs. The math only makes sense when you understand what's actually driving it.

The Stanford HAI 2026 AI Index, drawing on research from the Stanford Digital Economy Lab, found that early-career workers aged 22 to 25 in AI-exposed occupations experienced a 13% relative decline in employment since late 2022. Among 22-to-25-year-old software developers specifically, employment fell nearly 20% from its late 2022 peak by July 2025.

Twenty percent. Gone. Not during a recession. Not because the industry slowed down. During a period of AI investment unlike anything we've ever seen.

And here's the part that should genuinely bother you: for workers aged 30 and over in the highest AI-exposure categories, employment actually grew between 6% and 12% over the same period. AI isn't destroying engineering as a profession. It's pulling up the floor. The junior layer is disappearing while the senior layer holds firm or grows. That is a very specific, very surgical thing happening.

Entry-level postings dropped 60% between 2022 and 2024. Google and Meta are hiring roughly 50% fewer new grads compared to their 2021 peaks. According to Indeed's labour market data, software engineering listings are down approximately 35% from pre-pandemic levels — and roughly 70% from their 2022 peak.

Seventy percent from peak.

Think about what that means for a CS student graduating right now. Their professors built careers on a hiring market that simply doesn't exist anymore.

The CEOs Stopped Being Diplomatic

There used to be a script. "AI will create new jobs." "We're augmenting, not replacing." Every earnings call, every keynote, the same careful language. That script is mostly gone now.

Marc Benioff, CEO of Salesforce — San Francisco's largest private employer — got on an earnings call in early 2025 and said it plainly: "We're not going to hire any new engineers this year. We're seeing a 30% productivity increase in engineering, and we're going to really continue to ride that up."¹

Zero new engineers. At one of the biggest enterprise software companies on Earth. Because AI made the existing team 30% more productive. Why hire ten people when seven get you the same output?

But the line that deserves to be carved into the wall of every CS department in every university was this one, from the same call:

"My message to CEOs right now is that we are the last generation to manage only humans."
— Marc Benioff, CEO of Salesforce, Q4 FY2025 Earnings Call

That's not some fringe tech provocateur being edgy for an audience. That's the CEO of a $145 billion company saying the quiet part loud, on a call with investors and analysts. That's the actual strategy being announced.

Then there's Zuckerberg. On the Joe Rogan Experience in January 2025, he said something that didn't get nearly enough attention:

"Probably in 2025, we at Meta, as well as the other companies that are basically working on this, are going to have an AI that can effectively be a sort of midlevel engineer that you have at your company that can write code."
— Mark Zuckerberg, Joe Rogan Experience, January 2025²

Did that prediction land perfectly? Depends who you ask. But what isn't debatable is that Meta's junior developer hiring shrank dramatically through 2024 and 2025. The vision was stated. The hiring decisions followed.

At Google, the numbers tell a story that keeps accelerating. Sundar Pichai first disclosed the 25% figure on the Q3 2024 earnings call.³ By April 2025 it had climbed past 30%. By late 2025, Google's own CFO was citing "nearly half." Then, at Google Cloud Next 2026 in Las Vegas — just weeks ago — Pichai said this out loud:

"Today, 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall."
— Sundar Pichai, Google Cloud Next 2026, April 22, 2026

Three-quarters of the codebase at one of the world's premier engineering organisations. Not written by a human hand.

Satya Nadella, at Microsoft Build 2025, put Microsoft's comparable figure at around 30%.⁴ That number has likely moved too.

Let that trajectory sink in. The most influential software company on the planet just told the world, publicly, that three in four lines of new code it ships were generated by AI. Not as a confession. As a boast.

The Klarna Story Nobody Wants to Sit With

I keep coming back to Klarna because people draw the wrong lesson from it every single time.

Between 2022 and 2024, Klarna reduced its workforce — cutting approximately 700 positions — while deploying AI to handle the volume those roles had covered: customer service, operations, repetitive backend work. CEO Sebastian Siemiatkowski was open about it. Then things went wrong. Customer complaints climbed. Service quality dropped. Siemiatkowski publicly acknowledged that the AI-driven transition had negatively affected service and product quality. By 2025, Klarna was rehiring human staff.

People love this story. "See? AI failed. Humans win. Everyone goes home."

But here's what everyone skips over: those 700 people lost one to two years of income. Some pivoted careers entirely. Others are still looking. When Klarna came back to rehire, they didn't rebuild what they had. They built something smaller, leaner, structured around a gig-style model that requires fewer permanent headcount. The company rolled back the pace of replacement — not the direction.

The lesson from Klarna is not "AI will fail so we're safe."

The lesson from Klarna is this: companies will try to replace you with AI. Sometimes it'll backfire badly. When they course-correct, they'll hire back fewer people than they let go. The reset doesn't go home. It goes to a new, lower, permanent baseline.

That's not a comfort. That's a warning.

The Split That's Already Happening

Here's what I'm actually seeing in the developer community right now, and it is not subtle.

There are engineers who went all in — integrated AI tools into their workflows, learned the failure modes, used them to ship faster. A 2025 Microsoft/GitHub study found that engineers using Copilot completed comparable tasks 55% faster.⁵ That productivity multiplier has translated directly into smaller junior headcounts at companies like Meta, Google, and hundreds of mid-size SaaS companies that right-sized their engineering organisations through 2024–2025. The engineers using AI well aren't just surviving — they're getting the promotions, the offers, the raises. By Q1 2025, 82% of developers reported using AI tools weekly, with 59% running three or more simultaneously. And the pay reflects it: AI-fluent developers are landing entry-level roles at $90K–$130K versus $65K–$85K for traditional profiles, according to job market data.

Then there's the other group. Engineers who say "I don't trust AI code" or "it's glorified autocomplete" or — and I've heard this more than once — "real engineers write real code." Look, I understand the psychology. There's something genuinely uncomfortable about watching a tool do a significant portion of work you spent years learning. It feels like a betrayal of the craft.

But the market has no feelings about your feelings about the craft.

Take something like this — the kind of endpoint a junior developer used to spend a morning on:

from flask import Flask, request, jsonify
from models import db, User
from auth import require_auth

app = Flask(__name__)

@app.route('/users/<int:user_id>', methods=['GET'])
@require_auth
def get_user(user_id):
    user = User.query.filter_by(id=user_id).first()
    if not user:
        return jsonify({'error': 'User not found'}), 404
    return jsonify(user.to_dict()), 200

@app.route('/users', methods=['POST'])
@require_auth
def create_user():
    data = request.get_json()
    if not data or 'email' not in data:
        return jsonify({'error': 'Email required'}), 400
    user = User(email=data['email'], name=data.get('name', ''))
    db.session.add(user)
    db.session.commit()
    return jsonify(user.to_dict()), 201

GitHub Copilot or Claude Code generates something like that in about four seconds. With tests. With error handling. With docstrings if you ask. The junior developer who spent a career building this kind of muscle is now competing against a tool that does it in seconds.

The job of writing this code isn't gone. The reason to hire someone specifically to write this code absolutely is.

What's not gone: knowing why this architecture might be wrong for your specific use case. Knowing when to break the pattern. Understanding what happens when this hits 100,000 concurrent requests. That's senior engineer judgment. And AI, as of 2026, is still genuinely bad at it.

The World Is Treating This Differently Than You Are

Here's something that struck me hard: the institutions that usually move the slowest — governments — are scrambling faster than most individual developers I know.

The U.S. has provided funding for AI certifications for 120,000 laid-off workers. Across Europe, AI retraining enrolments jumped 39%. Singapore has baked workforce AI transition programs directly into its national strategy. The WEF's Reskilling Revolution initiative has mobilised commitments expected to reach over 856 million people globally by 2030.⁶

India — which has the world's largest pool of software developers — is doing something particularly interesting. Rather than panic about AI consuming developer jobs, India is systematically working to ensure its developers are the ones building the AI. A NASSCOM report projects India's AI talent pool to double from 6.5 lakh to over 12.5 lakh professionals by 2027, growing at 15% year-on-year. In the past three years alone, 8.65 lakh candidates were trained in emerging tech, with 3.20 lakh specifically in AI and Big Data Analytics.⁷ That's not a country in denial. That's a country repositioning at scale.

The WEF's Future of Jobs Report 2025 puts the global picture in stark terms: by 2030, job disruption could affect 22% of all roles globally — displacing 92 million jobs while creating 170 million new ones.⁶ Net positive on paper. Except the 92 million displaced are largely doing specific things: entry-level coding, repetitive testing, documentation, basic customer support. And the 170 million new jobs are in AI oversight, system architecture, ML infrastructure, AI safety, and technical leadership.

The math is brutal in its simplicity. If you're a developer who primarily does the work AI now generates, you're in the 92 million. If you learn to architect systems, supervise AI output, and build what AI can't build alone — you're in the 170 million.

Every country that's paying attention is trying to get into the 170 million. Are you?

What AI Is Actually Taking (And It's Not What You Think)

Let me be precise about the mechanism here, because the discourse is sloppy and sloppy thinking leads to wrong decisions.

AI is not replacing software engineering as a discipline. The judgment, the architecture, the systems thinking, the ability to navigate technical debt and organisational complexity — that's not going anywhere soon. What AI is replacing are the specific tasks that junior developers were hired to do: boilerplate, basic CRUD, scripted testing, routine bug fixes, first-draft documentation.

The problem is, those weren't just tasks.

They were the apprenticeship. You wrote the boilerplate and slowly started to understand why the boilerplate worked. You fixed the simple bugs and developed an intuition for reading unfamiliar code. You built the CRUD endpoints and gradually developed a feel for data modelling. You did the repetitive work and, somewhere in that repetition, you became an engineer who could do the hard work.

That entire training pipeline is now compressed or closed. Companies are skipping the junior layer and hiring mid-to-senior engineers who can direct and supervise AI output. The most visible effect of AI coding tools in 2026 isn't eliminating senior engineers — it's hollowing out the layer below them. Companies that used to run 3–5 juniors per senior are now running leaner teams.

AWS CEO Matt Garman said it directly, calling the strategy of simply eliminating the junior layer "one of the dumbest things I've ever heard" — warning that companies risk creating a catastrophic skills gap over the next decade. If you wipe out the apprenticeship, you stop producing the next generation of senior engineers.

He's right.

And most companies are doing it anyway, because short-term cost savings beat long-term talent pipeline thinking every single quarter. That's not cynicism. That's just how publicly traded companies behave.

What You're Actually Supposed to Do

Okay, I've been pretty dark. Let me be useful for a second, because fear without action is just anxiety.

The engineers I see doing well right now share a few specific things.

They treat AI like a junior developer, not an oracle. They use it to generate first drafts and review those drafts with the same critical eye they'd apply to a first-year intern's pull request. They understand why the AI generated what it generated — which means they catch when it's confidently wrong. They have architectural opinions that the AI cannot substitute for.

The practical workflow looks something like this:

# How senior engineers are actually working in 2026

# Step 1: You design the architecture — AI is genuinely bad at this
# Step 2: AI scaffolds the implementation
# Step 3: You review critically and catch the failure modes

# Example — prompting Claude Code or Cursor:
# "Create a rate-limiter middleware for our Express API
#  using Redis, with per-user and per-IP limits,
#  with proper fallback handling for Redis connection failures"

# AI gets ~80% right immediately
# The remaining 20% — Redis failover edge cases,
# production-specific config, security gaps — YOU catch that
# That gap is the job now. That's your value.

They have strong opinions about system design. When to use microservices versus a monolith. When a message queue adds value and when it just adds complexity. How to handle distributed transactions. When to cache — and when caching creates more problems than it solves. This is the domain where experience lives and AI doesn't, because it requires judgment shaped by having built things that broke in production.

They know exactly where AI fails. Not vaguely ("AI makes mistakes") but specifically: hallucinated API calls that look correct until they don't. Security vulnerabilities in generated authentication code. Incorrect business logic assumptions baked silently into generated functions. Only about 30% of AI-suggested code gets accepted by developers who actually know what to look for — and that selectivity is itself a skill you have to develop. The developers doing well right now have built a detailed personal map of where AI goes wrong.

Here's the clearest way I can put the distinction:

# AI generates this in seconds — low value in knowing it by heart
def get_user_by_email(email: str) -> Optional[User]:
    return db.session.query(User).filter(User.email == email).first()

# AI cannot answer these for you — this is where your career lives:
# → Why PostgreSQL over MongoDB for this specific use case?
# → How does this query behave under 10,000 concurrent requests?
# → What are the GDPR implications of storing this email field?
# → When do you add a Redis cache here, and when is it overkill?
# → How does this endpoint interact with your circuit breaker?

That second list. That's the job now.

They're building in public. Writing about what they're learning, contributing to open source, creating content that makes their thinking visible. When AI can replicate anyone's code sample, the hiring signal shifts to judgment. The developers getting offers right now are the ones whose judgment is legible from the outside — you can read who they are from their GitHub, their articles, their opinions on hard problems.

And the ones who are most secure? They understand the business too. AI is making pure technical skills cheaper every month. What it cannot replicate is the engineer who deeply understands the domain, speaks the language of product and business, can talk to customers, can translate between the technical and the strategic. That profile — technically sharp and business-fluent — is more valuable right now than it has been at any point in the last decade.

The Criticism That Needs to Be Said

Something unpopular needs to be said.

A lot of the "AI won't replace developers" discourse is being driven by people with significant financial or psychological incentives to believe it. Senior engineers who don't want to feel their skills are devaluing. Bootcamp founders who need enrolment. CS departments whose own enrolment is already dropping. VCs who've bet on human-in-the-loop products.

None of these people are lying exactly. But they're all reading the same data through a very interested filter.

U.S. Bureau of Labor Statistics data shows software developer employment fell 27.5% between 2023 and 2025.⁸ A Resume.org survey of 1,000 U.S. business leaders found that six in ten companies are likely to lay off employees in 2026, with four in ten planning to specifically replace workers with AI.⁹ These are not rounding errors. These are not post-pandemic corrections. These are structural shifts.

When critics say "but AI code is buggy, it needs human review, it can't handle complex systems" — they're not wrong. But they're imagining a binary: either AI replaces engineers completely or nothing changes. Reality is a third option, the one that's already here: AI replaces specific tasks within engineering, shrinks team sizes, raises the floor of what gets you hired, and leaves a smaller but more capable group of engineers doing work that genuinely requires human judgment.

That third option arrived while people were still debating whether the first one was possible.

What a Resume Has to Look Like Now

Two years ago, a junior developer posting read: "1–2 years experience, proficiency in React and Node, familiar with Git."

Today — if a junior posting exists at all, and there are far fewer — it reads something closer to: "Experience with AI-assisted development workflows, ability to review and validate AI-generated code, familiarity with prompt engineering for code generation, experience with at least two AI coding tools."

Entry-level hiring at the 15 biggest tech firms fell 25% from 2023 to 2024, according to a SignalFire report.¹⁰ Employers' rating of the market for college graduates is at its most pessimistic since 2020, per NACE's Job Outlook 2026.¹¹ With AI performing more of the grunt work that used to be the entry-level on-ramp, expectations for new grads have shifted dramatically upward. You're expected to show up already knowing things that used to be learned on the job.

If you're graduating this year, or seriously thinking about entering the field — the playbook has fundamentally changed. You cannot follow the path that produced the engineers who might be mentoring you. Their path, the one that started with two years of boilerplate and slowly accumulated into expertise, is largely gone.

The Bet That's Already Been Made

Here's the context I don't see enough people connecting to the rest of this.

Tech companies globally are committing to a combined $700 billion in AI infrastructure investment. Jensen Huang put it directly: "One trillion dollars of AI infrastructure is coming. The entire installed base of data centers will be renewed."

Companies don't bet that kind of money on something they think might fizzle. This is the largest concentrated capital commitment in tech history — bigger than the cloud transition, bigger than mobile. And every dollar of it is simultaneously a bet that AI will replace significant volumes of human cognitive labour, including coding labour.

The companies making that bet are also the companies deciding who to hire. When Amazon, Microsoft, Google, and Meta collectively commit hundreds of billions to AI infrastructure, they are making a simultaneous workforce decision: fewer junior developers, more ML engineers, more people who build and maintain the systems that will do what humans used to do.

This is not a hiring cycle. This is a structural transformation. And the decision was made years ago. We're just living in the consequences.

A Question Worth Actually Sitting With

Here's something I'd encourage every working developer to honestly answer for themselves.

If your job title stayed exactly the same, but all the junior tasks — the boilerplate, the tests, the first-draft implementations — were offloaded to AI, what would you actually be doing all day?

If the answer is "still plenty: architecture decisions, complex debugging, cross-team alignment, technical strategy, reviewing AI output critically" — you're probably in good shape. You've built the kind of irreplaceable judgment that AI, as of today, genuinely cannot replicate.

If the answer is "I'm not sure" or "honestly, a lot of what I do could probably be generated" — that's important information. That's a signal worth acting on now, not later.

Among Gen Z developers, 64% report worrying about being laid off, compared to 45% of their millennial counterparts, per Stack Overflow's Developer Survey. Those numbers aren't paranoia. They're pattern recognition. Gen Z engineers entered a market that looked like one thing and found something completely different when they arrived.

The Honest Summary

Will AI replace software engineers? No. The discipline of engineering — systems thinking, architecture, the judgment that comes from having built things that broke — is genuinely hard to replicate and AI is genuinely bad at it.

But will AI shrink junior roles, compress the hiring pipeline, raise the floor of what's expected at every level, and leave a smaller total number of engineers employed than the 2022 peak? It already has. That's not a prediction. That's a 2026 fact.

In 2025 alone, at least 58 million workers globally received some form of AI training or certification, reflecting the scale of workforce transition already underway. The people who are going to be fine are the ones treating that transition not as a professional option but as a professional requirement.

AI is not optional anymore. Not because some blog post said so. Because the hiring data, the layoff data, the productivity data, and the capital allocation data all point in the same direction. The companies with the most money in the world made their decision. They made it years ago.

The question is just whether you make yours, and when.

Because the engineers who ignore this — who wait for clarity, who keep doing what they've been doing and hope the market swings back to them — are making a bet. A bet that one of the best-funded, fastest-moving technological transitions in history is going to stall out before it reaches their desk.

I wouldn't take that bet.

What You Can Do, Starting Now

Not a lecture. Just what I'd do.

Start using AI tools as a real collaborator, not as autocomplete. Use Claude Code, Cursor, Copilot — use multiple, because they have different strengths and critically different failure modes. Build things with them. Learn where they fail. That failure map is your professional edge, because knowing when the AI is wrong is worth far more than being able to generate code you can't evaluate.

Build the skills AI provably can't replicate in 2026: distributed systems design, security architecture, ML infrastructure, technical leadership, the ability to translate business requirements into technical decisions that account for real operational constraints. These are deeply human skills right now.

Write publicly about what you're building and learning. In a market where AI can produce anyone's code sample, your thinking has to be the differentiator. Make it visible.

And invest real time in the business side. Understand the domain you're building in. Talk to the users. Learn enough about the product and the economics to make real decisions — not just technical ones. That combination of technical depth plus business fluency is, right now, as hard to replace as anything in this industry.

Closing

The friend I opened with — he's okay. After three rejections in a row, he spent three months rebuilding his workflow. AI for 60–70% of implementation. Critical review of everything it produced. He built a real sense of where it went wrong. Got back to final rounds. Got the job.

But he lost months. He lost income. He went through the specific kind of humiliation that comes with being objectively skilled at something and still being passed over — not for someone better, but for someone who had simply adapted faster. The only reason was timing. He moved slower than the market moved.

Don't be him. Move now.

The question was never whether AI will replace software engineers. The question has always been whether you will make yourself the kind of engineer that AI makes more powerful — or one that AI makes obsolete. That answer is entirely up to you.

But you don't have unlimited time to decide.

References & Sources

Additional data from: Stanford HAI 2026 AI Index · Stanford Digital Economy Lab · Stack Overflow Developer Survey 2024–2025 · Indeed Labour Market Data · Tech Layoff Tracker (May 2026) · Harvard Business Review (February 2026)

Find me across the web:

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

Salesforce Q4 FY2025 Earnings Call — Marc Benioff, CEO ↩
Joe Rogan Experience, January 2025 — Mark Zuckerberg, CEO of Meta ↩
Alphabet Q3 2024 Earnings Call; Google Cloud Next 2026 (April 22, 2026) — Sundar Pichai, CEO of Google ↩
Microsoft Build 2025 — Satya Nadella, CEO of Microsoft ↩
Microsoft/GitHub Copilot Productivity Study, 2025 ↩
World Economic Forum — Future of Jobs Report 2025 & Reskilling Revolution Initiative ↩
NASSCOM AI Talent Report 2026; Indian Ministry of Labour and Employment ↩
U.S. Bureau of Labor Statistics, Occupational Employment Data, 2025 ↩
Resume.org Survey of 1,000 U.S. Business Leaders, 2025 ↩
SignalFire Entry-Level Hiring Report, 2024 ↩
National Association of Colleges and Employers (NACE) — Job Outlook 2026 ↩

Java vs C# in Kubernetes: A Practical Guide to Docker Optimization in 2026

Syed Ahmer Shah — Sun, 31 May 2026 09:58:22 +0000

There's a question that keeps surfacing across engineering teams — sometimes in architecture reviews, sometimes buried in a Slack thread at 11 PM the night before a production incident — and it goes something like this: we're containerizing everything for Kubernetes, we're choosing between Java and C#, and we want to get this right.

Both ecosystems have matured enormously in the container space. Both have answers to the problems that plagued them five years ago. But those answers are different, the tradeoffs are real, and the wrong defaults will silently cost you — in cloud bills, in startup latency, and in operational headaches that only show up when things go wrong at scale.

This article doesn't take sides. What it does is go deep on what actually matters when you're building and deploying Java or C# services on Kubernetes: image sizes, startup behavior, JVM tuning, .NET Native AOT, garbage collection, memory limits, probe configuration, and the specific mistakes that bite teams over and over again.

The Modern State of Java and C# in 2026

Java

Java 25 is the current LTS as of late 2025. The language and runtime have come a long way — virtual threads (Project Loom) are stable and production-ready, the JVM's container awareness has been solid for years, and GraalVM Native Image has matured into a legitimate production option for teams willing to work within its constraints.

Spring Boot 3.x remains the dominant framework for backend Java, though Quarkus and Micronaut have carved out real niches precisely because they were designed with containers and fast startup times in mind from day one. For JDK distributions, Eclipse Temurin is the community standard, with Red Hat's OpenJDK and Azul Zulu as solid alternatives. All three have first-class Docker support.

What changed in recent Java versions that actually matters for containers:

UseContainerSupport is enabled by default, so the JVM reads cgroup memory and CPU limits correctly instead of sizing itself against the host machine — a problem that plagued early containerized JVM deployments.
MaxRAMPercentage gives you a clean, portable way to configure heap without hardcoding megabyte values that break when you resize your pods.
ZGC and Shenandoah are both production-grade, low-pause garbage collectors that behave well in memory-constrained environments.
AppCDS (Application Class Data Sharing) genuinely improves startup time for traditional JVM deployments without requiring a full recompilation model.

A note on the examples below: Dockerfiles in this article use the 21 tag, which maps to a widely-available and stable Eclipse Temurin release. If you're starting fresh, substitute 25 once your toolchain — especially GraalVM — has matching image support. Always check Docker Hub for available tags before pinning a version in production.

.NET

.NET 10 is the current LTS as of November 2025. Microsoft has invested heavily in container-first deployment across several releases. Native AOT, still experimental in .NET 7, became a first-class feature in .NET 8 and has been progressively better supported in ASP.NET Core through .NET 9 and 10.

The chiseled Ubuntu images Microsoft maintains are stripped-down, non-root-by-default base images that produce significantly smaller final containers than the traditional aspnet base images. ReadyToRun compilation, trimming, and ahead-of-time compilation give .NET more optimization levers than it's ever had.

ASP.NET Core Minimal APIs pair particularly well with Native AOT, since they sidestep the reflection-heavy patterns that AOT struggles with. If you're building new services and targeting native compilation, Minimal APIs are the right starting point — not as a preference, but because the AOT compatibility story is genuinely better there.

Docker Fundamentals That Actually Matter Here

Before getting into language-specific details, a few fundamentals worth internalizing if you haven't already.

Image size affects pull time, storage cost, and attack surface. Smaller images pull faster during pod scheduling, cost less in registry storage, and give attackers fewer tools to work with after a container compromise.

Startup time matters enormously in Kubernetes because pods restart, scale out, and get rescheduled constantly. A 30-second JVM startup that seems acceptable in staging turns into a real problem when your autoscaler is trying to add capacity during a traffic spike.

Memory behavior determines whether you're crashing pods under pressure or over-provisioning and wasting money. CPU behavior determines whether you're hitting throttling under load.

Both Java and C# have specific characteristics in each of these dimensions that differ from Go or Rust containers, which is why generic Docker optimization advice often misses the mark for these runtimes. A JVM service and a statically compiled Go binary are fundamentally different runtime models, and your container strategy needs to reflect that.

Java Container Optimization

Multi-Stage Builds Are Non-Negotiable

Shipping a full JDK in your production image is wasteful in almost every sense. A naive Java Dockerfile pulls in a 500+ MB JDK image along with your fat JAR, and the build toolchain has absolutely no business being in a production container.

Here's a reasonable starting point for a Spring Boot service:

# Stage 1: Build
FROM eclipse-temurin:21-jdk-alpine AS build
WORKDIR /app
COPY . .
RUN ./mvnw clean package -DskipTests

# Stage 2: Runtime only
FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

ENTRYPOINT ["java", \
  "-XX:+UseContainerSupport", \
  "-XX:MaxRAMPercentage=75.0", \
  "-XX:+UseZGC", \
  "-jar", "app.jar"]

Switching from a JDK to a JRE-only base image cuts roughly 200–300 MB from the final image. Alpine-based images shave off more, but they use musl libc instead of glibc — which occasionally surfaces compatibility issues with native libraries compiled against glibc. Worth testing before committing to Alpine in production, especially if you use dependencies with native components like certain database drivers or crypto libraries.

Distroless Containers

Google's Distroless images take this a step further. They contain only the Java runtime and your application — no shell, no package manager, no OS utilities that an attacker could misuse after a container compromise.

# Stage 1: Build
FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw clean package -DskipTests

# Stage 2: Distroless runtime
FROM gcr.io/distroless/java21-debian12
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar

ENTRYPOINT ["java", \
  "-XX:+UseContainerSupport", \
  "-XX:MaxRAMPercentage=75.0", \
  "-XX:+UseZGC", \
  "-jar", "app.jar"]

Debugging distroless containers is harder — no shell means no kubectl exec for ad-hoc inspection. You'll need kubectl debug with an ephemeral sidecar, or rely entirely on your observability stack. That's a fair tradeoff for production security, but make sure your team understands and accepts that operational model before adopting it.

GraalVM Native Image

This is the most significant shift available to Java teams, and it's worth understanding properly rather than just copy-pasting the Dockerfile.

GraalVM Native Image compiles your application ahead-of-time into a standalone native binary — no JVM, no warmup. Startup times drop from seconds to milliseconds. Memory footprint drops dramatically because you're no longer carrying a JIT compiler, metaspace, or a full runtime in memory.

Spring Boot 3.x has first-class support for Native Image through native Maven and Gradle plugins:

# Stage 1: Native compile
FROM ghcr.io/graalvm/native-image:21 AS build
WORKDIR /app
COPY . .
RUN ./mvnw -Pnative native:compile -DskipTests

# Stage 2: C runtime only — this is a native binary, not a JAR
FROM gcr.io/distroless/cc-debian12
WORKDIR /app
COPY --from=build /app/target/myservice .

ENTRYPOINT ["/app/myservice"]

Notice the runtime base image is distroless/cc-debian12 — not a Java base. Since the output is a native binary, you only need glibc and the C runtime, not a JVM. This keeps the final image genuinely small and free of Java metadata.

The build takes longer — 5–15 minutes for a complex service is normal — and there are real constraints around reflection, dynamic class loading, and runtime proxies that require explicit configuration hints in reflect-config.json and resource-config.json. For frameworks that lean heavily on reflection, writing those hints is a genuine time investment, not an afternoon task.

The reward is a service that starts in 50–100ms, uses a fraction of the heap, and deploys as a compact binary. For event-driven microservices, serverless-style patterns, or anything that scales to zero, Native Image is the right choice. For long-running, compute-intensive services where JIT's aggressive runtime optimization pays off at peak throughput, the traditional JVM still has the edge.

JVM Tuning for Containers

A handful of flags that matter specifically in Kubernetes environments:

-XX:+UseContainerSupport — Enabled by default since JDK 10. Reads cgroup limits correctly. Never disable it.

-XX:MaxRAMPercentage=75.0 — Sets heap to 75% of available container memory. The remaining 25% covers metaspace, code cache, thread stacks, and native allocations. Setting this to 100% will trigger OOMKills even though the heap "fits" — there's always non-heap consumption to account for.

-XX:+UseZGC — Delivers consistent low-pause garbage collection, well-suited for latency-sensitive services. G1GC is the default and solid for most workloads, but ZGC's pause times are more predictable under memory pressure. Shenandoah is a reasonable alternative with similar design goals.

-XX:+TieredCompilation -XX:TieredStopAtLevel=1 — Can improve startup time at the cost of peak throughput. Useful if you're not on Native Image but need faster pod readiness for frequent scaling events.

For services that restart frequently or scale aggressively, AppCDS is worth the setup effort. It serializes class metadata to a shared archive that gets memory-mapped on startup, reducing JVM initialization time by several seconds for large applications:

# Step 1: Generate the class list
java -XX:DumpLoadedClassList=app.classlist -jar app.jar

# Step 2: Create the shared archive
java -Xshare:dump \
  -XX:SharedClassListFile=app.classlist \
  -XX:SharedArchiveFile=app.jsa \
  -jar app.jar

# Step 3: Use the archive at runtime
java -Xshare:on \
  -XX:SharedArchiveFile=app.jsa \
  -XX:MaxRAMPercentage=75.0 \
  -XX:+UseZGC \
  -jar app.jar

C# / .NET Container Optimization

Multi-Stage Builds for .NET

Same principle, same payoff. The .NET SDK image runs around 800 MB to 1 GB. Your production container needs only the ASP.NET Core runtime.

# Stage 1: Build and publish
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore && \
    dotnet publish -c Release -o /app/publish

# Stage 2: Chiseled runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled
WORKDIR /app
COPY --from=build /app/publish .
USER app

ENTRYPOINT ["dotnet", "MyApi.dll"]

The noble-chiseled tag refers to Microsoft's chiseled Ubuntu images — stripped-down base images with minimal attack surface, non-root by default, and significantly smaller than the standard aspnet images. Switching to chiseled is a one-line Dockerfile change that cuts the final image by 30–40% with zero code changes. If there's one thing to do before anything else on the .NET side, this is it.

.NET Native AOT

Native AOT in .NET compiles your application into a standalone native binary at publish time — the .NET equivalent of GraalVM Native Image, with similar tradeoffs in both directions.

# Stage 1: AOT publish
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -r linux-x64 \
    --self-contained true \
    -p:PublishAot=true \
    -o /app/publish

# Stage 2: C runtime only — no .NET runtime layer needed
FROM mcr.microsoft.com/dotnet/runtime-deps:10.0-noble-chiseled
WORKDIR /app
COPY --from=build /app/publish .
USER app

ENTRYPOINT ["/app/MyApi"]

With Native AOT, you're on runtime-deps rather than aspnet — just the native C runtime, no .NET runtime layer at all. The final image can get surprisingly small, sometimes under 60 MB for a well-trimmed Minimal API service.

Constraints to know before committing: reflection must be declared via [DynamicallyAccessedMembers] attributes or rd.xml files, serialization works well with System.Text.Json's source generation mode, and Entity Framework Core has limited Native AOT support depending on the database provider and version. Check your specific dependencies before going down this path for data-heavy services.

ReadyToRun and Trimming

If full Native AOT feels like too much overhead for a given service, ReadyToRun provides ahead-of-time compilation of IL to native code — faster startup without the full AOT constraints:

dotnet publish -c Release -r linux-x64 \
    --self-contained true \
    -p:PublishReadyToRun=true \
    -p:PublishTrimmed=true

Trimming removes unreachable IL code from the published output, meaningfully reducing image size. It does require careful testing — it can silently remove code paths that appear dead to the linker but are invoked via reflection at runtime. Run your full integration and end-to-end test suite after enabling it. Unit tests alone are unlikely to catch trimming-caused failures.

Memory Configuration for .NET Containers

.NET manages its heap differently from the JVM. Key environment variables for containerized .NET services:

DOTNET_GCHeapHardLimit — Sets a hard memory ceiling for the GC in bytes. Useful for strict per-pod memory isolation.
DOTNET_GCConserveMemory — A value from 0 to 9 that trades GC aggressiveness for memory conservation. Values of 5–7 are useful under memory pressure; higher values reduce footprint at the cost of more frequent collections. Start at 0 and tune up only if you're seeing memory strain.
DOTNET_SYSTEM_GC_SERVER — Defaults to true in containers since .NET 6. Server GC is appropriate for backend services on multi-core hosts and rarely needs to be overridden.

Kubernetes-Specific Considerations

Resource Requests and Limits

This is where Java teams most frequently get burned. Without resource requests and limits, the Kubernetes scheduler has no useful information, and your pods will get evicted under memory pressure without warning — often at the worst possible moment.

For a traditional JVM service:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "2000m"

Set the memory limit conservatively above your expected heap plus overhead. Setting memory request equal to limit (Guaranteed QoS class) prevents OOM eviction under cluster memory pressure — worth doing for latency-critical services. For native compilation services, you can set much tighter limits — often 64–128 Mi memory, 100–250m CPU — and that's where the real resource efficiency gains show up at scale.

Startup Probes, Readiness, and Liveness

This trio is critical and commonly misconfigured, and getting it wrong causes cascading problems that are genuinely painful to debug.

The startup probe exists specifically for slow-starting applications. It gives the container time to initialize before the liveness probe kicks in and starts restarting it for appearing unhealthy:

startupProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 0
  periodSeconds: 5
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 15
  failureThreshold: 3

Spring Boot Actuator exposes /actuator/health/readiness and /actuator/health/liveness out of the box when you add management.health.probes.enabled=true to your application properties. ASP.NET Core has built-in health check endpoints via app.MapHealthChecks("/healthz").

Never route the liveness probe to an endpoint that checks downstream dependencies. If your database is slow, that should affect readiness — stop sending traffic to this pod — not liveness, which triggers a restart. Misconfiguring this is one of the most common causes of cascading pod restart storms during dependency degradation: slow database causes pod restarts, pod restarts add more connection pressure to the database, which makes it slower, which causes more restarts.

Autoscaling

CPU-based HPA is the baseline, but for JVM services it can be misleading during JIT warmup. JVM pods spike CPU on startup in ways that don't reflect steady-state load — your autoscaler sees those spikes, adds more pods, which also spike CPU on start, and suddenly you have more pods than you actually need.

For JVM services, memory-based or request-rate-based autoscaling gives more meaningful signals. KEDA (Kubernetes Event-driven Autoscaling) is worth evaluating for queue-depth or RPS-based scaling in production workloads:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: java-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: java-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70

Here's a complete Kubernetes Deployment manifest for a Java service, putting all of the above together:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-service
  labels:
    app: java-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: java-service
  template:
    metadata:
      labels:
        app: java-service
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: java-service
        image: myregistry/java-service:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "1Gi"
            cpu: "2000m"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        env:
        - name: JAVA_TOOL_OPTIONS
          value: "-XX:MaxRAMPercentage=75.0 -XX:+UseZGC"
        startupProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          failureThreshold: 30
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          periodSeconds: 15
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "sleep 5"]
      ter9yMnTm4NSzvG9rrwjM2ec8xZgh1cafXH8: 60

Java vs C# in Kubernetes: The Real Comparison

Startup Speed

Traditional Spring Boot commonly hits 10–15 seconds on cold start. Quarkus and Micronaut are faster by design — often 1–4 seconds — because they push more work to build time rather than runtime. GraalVM Native Image brings this down to 50–200ms, competitive with native Go and Rust binaries.

On the .NET side, a typical ASP.NET Core service starts in 1–5 seconds on standard JIT. .NET Native AOT reaches 20–100ms — comparable to GraalVM Native Image.

For standard Kubernetes deployments running 3–5 replicas with gradual scaling, a 10-second JVM startup is usually acceptable. For scale-to-zero patterns, event-driven architectures with bursty traffic, or rapid horizontal scaling, startup time becomes a real bottleneck and native compilation moves from a nice-to-have to essential.

The more interesting comparison is between Quarkus and standard .NET JIT — they land in similar territory. If you're not using native compilation, .NET starts faster than traditional Spring Boot, but the gap largely disappears once you bring Quarkus or Micronaut into the equation.

Memory Footprint

A traditional Spring Boot service sits at roughly 300–600 MB under load once you account for everything the JVM carries — metaspace, JIT code cache, thread stacks, native memory allocations. The heap is only part of that picture.

GraalVM Native Image drops this to 30–100 MB for the same service. The absence of the JVM runtime, JIT compiler, and metaspace is a dramatic reduction.

A typical ASP.NET Core service lands at 80–200 MB. The .NET runtime is lighter than the JVM baseline without any special configuration, which is why .NET has historically had lower memory consumption than equivalent Spring Boot services out of the box.

.NET Native AOT brings this down further to 20–80 MB.

At scale — 50 pods of a microservice — the difference between a 400 MB JVM pod and an 80 MB native pod is 16 GB of cluster memory across a single service. That's real money on managed Kubernetes, and it compounds across every service in a large microservices architecture.

Developer Experience and Build Complexity

Standard JVM builds with Maven or Gradle are fast, well-understood, and easy to hire for. The CI setup is straightforward, the Dockerfile is simple, and most engineers on a Java team have seen this before. That's a real advantage that's easy to underestimate when weighing ecosystem choices.

GraalVM Native Image builds are slower — 5–15 minutes for a complex service — and require dependency compatibility verification before you get a clean build. When native:compile fails due to a reflection issue, the error messages can be cryptic. The Spring Boot native hints ecosystem has improved significantly, but it's still a meaningful investment for a non-trivial service.

Standard .NET builds are fast and ergonomic. dotnet publish is polished and the tooling tends to have a shorter learning curve than Maven or Gradle for engineers coming from other backgrounds.

.NET Native AOT has similar build-time costs and constraint management overhead to GraalVM. The AOT analyzer and ILLink warnings have improved substantially in recent .NET versions, making issues easier to diagnose — though "easier to diagnose" is relative when you're hunting for a trimming-caused regression.

For teams without deep container optimization experience, .NET's standard setup tends to reach a reasonable baseline faster. For teams willing to invest the setup effort, both ecosystems' native compilation options produce broadly comparable results.

Ecosystem and Tooling

Java's ecosystem is deeper in specific domains: financial services (Spring Batch, Apache Camel), data engineering (Kafka Streams, Flink, Spark), and enterprise integration. The Kubernetes operator ecosystem has extensive Java tooling, and most major cloud provider SDKs have strong Java support.

.NET is the natural choice if you're Microsoft-stack heavy, Azure-native, or have significant existing C# codebase investments. The Azure SDK for .NET is excellent. If your team is building on SQL Server with EF Core and deploying to AKS, .NET is the path of least resistance by a wide margin.

Neither ecosystem is a wrong choice for general microservice backend work in 2026. Let your integration requirements and existing team expertise drive the decision rather than synthetic benchmark numbers.

Image Size Optimization

Java: Worst to Best

Starting from a naive full JDK with fat JAR and no multi-stage build, you're looking at roughly 600 MB. Moving to a multi-stage build with a JRE-only base gets you to 250–300 MB. Alpine-based JRE images bring this down further to 150–200 MB, and Distroless images land at around 180–220 MB depending on the runtime version.

From there, JLink is an underused option worth knowing about. It lets you build a custom JRE containing only the Java modules your application actually uses:

# Identify exactly which modules your JAR needs
jdeps --ignore-missing-deps --print-module-deps \
  --class-path "BOOT-INF/lib/*" app.jar

# Build a minimal JRE with only those modules
jlink \
  --add-modules java.base,java.logging,java.sql,java.naming \
  --strip-debug \
  --no-man-pages \
  --no-header-files \
  --compress=2 \
  --output /custom-jre

A JLink custom runtime combined with Distroless gets you to roughly 80–120 MB — meaningful size reduction without any Native Image constraints. GraalVM Native Image with Distroless represents the floor: 30–80 MB for a typical service.

.NET: Worst to Best

The naive approach — SDK image with no multi-stage build — produces a container around 800 MB. A standard aspnet multi-stage build gets you to 200–250 MB. Switching to chiseled images brings that to 100–140 MB, and adding trimming with self-contained deployment gets to 60–100 MB. Native AOT with runtime-deps chiseled is the floor: 30–70 MB.

The chiseled images are the easiest win that many teams haven't taken yet. Switching the final stage from mcr.microsoft.com/dotnet/aspnet:10.0 to mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled is literally changing one word in your Dockerfile. Do that before anything else.

Monitoring and Observability

Both ecosystems have solid OpenTelemetry support. For Java, the OpenTelemetry Java agent provides automatic instrumentation without code changes — attach it at runtime and your traces, metrics, and logs flow to the configured exporter without touching application code:

COPY otel-javaagent.jar /otel-javaagent.jar
ENV JAVA_TOOL_OPTIONS="-javaagent:/otel-javaagent.jar"

For .NET, the OpenTelemetry.Extensions.Hosting package integrates cleanly with ASP.NET Core's IHostBuilder:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddOtlpExporter())
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()
        .AddPrometheusExporter());

Micrometer (Java) and ASP.NET Core's built-in metrics APIs both produce Prometheus-compatible metrics. Standard Grafana dashboards cover JVM heap usage, GC pause times, thread pool utilization, HTTP request rates, and error rates out of the box.

One important caveat for native compilation: observability tooling that relies on JVM internals or CLR profiling APIs won't work with GraalVM Native Image or .NET Native AOT. The OpenTelemetry SDK-based approach works correctly for both compilation targets, which is a strong reason to adopt SDK-based instrumentation over agent-based approaches if you're considering native compilation. Plan your observability strategy before committing to native — not after.

Security Best Practices

Non-Root Containers

Every Dockerfile in this article explicitly drops to a non-root user. This isn't optional hygiene — it's the baseline. A surprising number of production Kubernetes deployments still run as root simply because the base image default was never overridden and nobody caught it in review.

For Java:

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

For .NET, the chiseled images come with a non-root app user by default. USER app activates it.

Enforce this at the cluster level with a pod security context too:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  seccompProfile:
    type: RuntimeDefault

Vulnerability Scanning

Include image scanning in your CI pipeline. Trivy is the standard open-source tool for this and integrates with GitHub Actions, GitLab CI, and most other platforms. The value of Distroless and chiseled images isn't purely about size — fewer OS packages means fewer CVEs to track and patch. A Distroless GraalVM native binary container and a full JDK Alpine image produce a meaningfully different CVE list when scanned. That difference grows louder every time there's a glibc or OpenSSL vulnerability.

Secrets Management

Don't bake secrets into images — not even as build arguments. In Kubernetes, use envFrom with native Secrets for low-sensitivity configuration, or the External Secrets Operator with Vault, AWS Secrets Manager, or Azure Key Vault for sensitive credentials. Both Spring Boot and ASP.NET Core read configuration cleanly from environment variables and mounted secret files without any special library dependencies.

Common Mistakes Teams Make

Java-Specific Mistakes

Setting -Xmx to a fixed value without accounting for non-heap memory. The JVM consumes memory beyond the heap — metaspace, code cache, direct buffers, thread stacks. Setting -Xmx to the container's full memory limit will trigger OOMKills even though the heap "fits." Use -XX:MaxRAMPercentage=75.0 instead and let the JVM calculate from available container memory.

Not configuring a startup probe for JVM services. Without a startup probe, the liveness probe runs immediately and restarts the pod during normal JVM warmup. This is one of the most common causes of pod restart loops on deploy that teams debug for hours before realizing what's happening.

Shipping the build stage image as the final image. An eclipse-temurin:21-jdk final image includes compilers, header files, and build tools that have no purpose in a production container.

Assuming GraalVM Native Image just works on the first attempt. A Spring Boot application with several dependencies will require reflection hints, proxy configurations, and resource includes. Budget real time for this — it isn't a one-afternoon project for a complex service.

Ignoring JIT warmup in CPU-based HPA. JVM services spike CPU on startup. If your HPA is watching CPU utilization, it will scale up pods during normal restarts, which also spike CPU, causing more scale-up. Use memory-based or request-rate-based HPA for JVM services.

.NET-Specific Mistakes

Using mcr.microsoft.com/dotnet/sdk:10.0 as the final image base. The SDK is for building. The aspnet or runtime-deps image is for running. This produces containers approaching 1 GB that are slow to pull and expose unnecessary attack surface.

Enabling PublishTrimmed=true without testing. Trimming can silently remove functionality if reflection patterns aren't annotated with [DynamicallyAccessedMembers]. Run your full integration and end-to-end test suite after enabling trimming — unit tests alone are unlikely to catch failures caused by it.

Publishing for the wrong architecture. Building on an ARM Mac and publishing for linux-arm64, then deploying to an x64 node pool, produces a container that crashes immediately on start. Be explicit about -r linux-x64 or use multi-platform builds.

Not setting ASPNETCORE_ENVIRONMENT=Production. Without it, development-mode behaviors may activate — including detailed error pages that expose stack traces to anyone who can reach the service.

Kubernetes Deployment Mistakes (Both Ecosystems)

No preStop hook and an insufficient ter9yMnTm4NSzvG9rrwjM2ec8xZgh1cafXH8. When Kubernetes terminates a pod, it sends SIGTERM and simultaneously removes the pod from the load balancer. Without a preStop sleep of a few seconds, in-flight requests get dropped. Add preStop: exec: command: ["sh", "-c", "sleep 5"] and ensure ter9yMnTm4NSzvG9rrwjM2ec8xZgh1cafXH8 is long enough for your service to drain — 60 seconds is a reasonable starting point.

Readiness probes that check external dependencies. If your readiness probe calls the database, a slow database will knock pods out of the load balancer rotation, increasing database pressure further. The readiness probe should answer one question: is this specific pod ready to handle requests right now? Downstream dependency health belongs in the application layer, not in Kubernetes probes.

No PodDisruptionBudget. Without a PDB, Kubernetes can evict all pods of a deployment simultaneously during node maintenance, causing complete service downtime. Set minAvailable: 1 or maxUnavailable: 1 for any service with availability requirements.

Practical Recommendations

When Java Makes More Sense

You're in a Java-heavy organization with existing Spring Boot or Quarkus expertise that goes beyond surface familiarity. You're building data-intensive or integration-heavy services where the JVM ecosystem is a genuine advantage — Kafka Streams, JPA, Apache Camel, Flink. Your services are long-running with stable, predictable load patterns where JIT compilation pays off in peak throughput. You need deep integration with Java-native cloud tooling.

When .NET Makes More Sense

You're Azure-native or Microsoft-stack heavy. Your team's core expertise is C# and you want to leverage that fluency in framework APIs and ecosystem libraries. You need fast cold starts on standard JIT builds without investing in Native Image's build constraints. You're migrating Windows-origin backend code to Linux containers — the migration path is significantly smoother staying in .NET.

When Native Compilation Makes Sense for Either

Your architecture has scale-to-zero or rapid burst scaling requirements where cold start latency directly affects user experience or SLOs. Memory costs at scale are significant and you've done the math on how much native compilation saves at your pod count. Your services are stateless, structurally simple, and don't depend on reflection-heavy framework features. You have CI infrastructure that can absorb 10–15-minute native builds without blocking your team.

What to Prioritize, In Order

1. Multi-stage builds. Highest ROI, lowest effort. Every Java and .NET service should use multi-stage builds before any other optimization.

2. Resource requests and limits with correct probe configuration. An unstable deployment costs more than an unoptimized one. Get this right before worrying about image size.

3. Non-root containers and security context. Baseline professionalism, and required by most organization security policies and compliance frameworks.

4. Chiseled images (.NET) or JRE images (Java). Easy size wins with minimal effort and zero code changes.

5. Memory tuning. Once you have observability and real load data, tune based on actual heap behavior — not guesses or defaults.

6. Native compilation. Evaluate after you have real production metrics showing that startup time or memory footprint is actually a problem at your scale. Don't optimize prematurely.

Conclusion

Java and C# are both credible, production-ready choices for Kubernetes-native backend development in 2026. The gap that existed five years ago — where Java containers were notoriously heavy and slow to start — has been substantially closed through GraalVM Native Image, Spring Boot's native AOT support, and better JVM container awareness. The JVM is no longer the obvious wrong choice for cloud-native work.

.NET's traditional edge in startup time and memory footprint on standard JIT builds remains, but the difference is less dramatic than it once was. Where .NET Native AOT and GraalVM Native Image meet, the numbers are comparable.

The practical decision factors are ecosystem fit, team expertise, existing infrastructure, and specific service requirements — not abstract language benchmarks. A well-optimized Java service with proper multi-stage builds, ZGC configuration, and sensible memory settings will outperform a poorly configured .NET service, and the reverse is equally true.

What separates well-run container deployments from poorly-run ones isn't which language you chose. It's whether you're using multi-stage builds, whether your resource requests and limits reflect measured reality, whether your probes are configured correctly, and whether you have observability to catch problems before they become incidents. Get those fundamentals right first. Then optimize.

Find me across the web:

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

I Coded My Portfolio From Scratch. No Templates.

Syed Ahmer Shah — Tue, 26 May 2026 18:22:40 +0000

There is a very specific kind of regret that hits when you deploy someone else's template, change the name and the profile picture, push it to GitHub, and then look at the result and think — yeah. That's me. That's my work.

It's not. It never was.

I made that mistake once. Grabbed something off a free portfolio site, tweaked the colors a bit, added my name in the hero section. It looked clean. It looked professional even. But whenever someone asked me about it I'd skip over the details because deep down I knew I hadn't built any of it. I had dressed up someone else's house and called it home.

So when I finally decided to sit down and build ahmershah.dev properly, the first rule I set for myself was simple — no template. Not even as a reference. Start from index.html and figure the rest out.

What followed was months of fighting with CSS, arguing with Three.js, debugging scroll behavior at 1 AM, and slowly building something that I can actually explain line by line. This is that story.

Why Templates Are a Trap (For Beginners Especially)

Before I get into the build, I want to actually say something here because I see this conversation come up constantly in developer communities. People ask — should I use a template for my portfolio? And the nice answer is: it depends.

The honest answer is: if you're learning, a template will stunt you.

Using a template means you skip the decisions. You skip figuring out why a section is structured the way it is, why a certain animation works the way it does, why the developer chose to reach for a library instead of writing something custom. You inherit a finished product and you don't get any of the understanding that came from building it.

Now if you're a senior developer trying to ship a portfolio in a weekend because you're job hunting — sure. Template makes sense. Time is money.

But if you're a student, if you're early in your career, if you're trying to prove to yourself and to the people hiring you that you can build things — then building your own portfolio is genuinely one of the best projects you can do. Not because the portfolio itself is impressive. Because the process of building it forces you to answer real questions.

The Stack and Why It Looks the Way It Does

My stack for this project is: HTML5, custom CSS (this is the majority of the codebase, not Bootstrap), Bootstrap 5 for the grid layer only, vanilla JavaScript, a little bit of jQuery (honestly way less than I planned), Three.js, TurnJS, TiltJS, Lenis.js, and AJAX for some of the dynamic loading. Contact form runs through Formspree.

If you look at the repo's language breakdown — it's 50.7% JavaScript, 29.3% CSS, 20% HTML. That CSS number felt right when I saw it. A lot of the complexity in this site lives in the stylesheets.

I want to explain why the stack ended up looking like this because I made some deliberate choices and some accidental ones.

Bootstrap vs Custom CSS — this one matters

The instinct a lot of beginners have is to let Bootstrap do everything. You end up with like 50 utility classes on every div and very little actual understanding of what the layout is doing. I made the decision early on to use Bootstrap only for the grid system and for a few responsive breakpoints. Everything else — spacing, typography, animations, color, positioning — is custom CSS using variables.

This was slower. It was also much better for me as a developer. When something broke I had to understand why it broke instead of just switching utility classes until it looked right.

The result is a CSS file that is actually kind of long and in some places probably not perfectly organized. That's real. I'm not going to pretend the codebase is immaculate. There are sections where I know I could refactor things, places where I wrote a specific rule to fix a very specific layout problem and then never cleaned it up properly. The site works and it looks good but the code behind it has the marks of something that was built iteratively over time, not planned from the start.

JavaScript — mostly vanilla, jQuery at the edges

I planned to use jQuery more. Ended up using it way less. Vanilla JS handles most of the interaction logic. jQuery ended up in a few specific places where I was doing quick DOM manipulation and the syntax was just cleaner.

I don't think there's a strong philosophical argument here. It's just that once you start writing vanilla JS properly you realize most of the things you were reaching for jQuery to do are actually not that hard.

Three.js, a Blender File, and the Learning Curve I Underestimated

The Three.js section of this build took way longer than I thought it would.

Three.js is one of those libraries where the documentation is technically good and also kind of confusing if you haven't done any 3D work before. The concepts — scene, camera, renderer, geometry, material, mesh, light — they make complete sense once you get it. Before you get it, it feels like you're assembling furniture from instructions written in a different language.

I used Blender to create the 3D model that lives in the portfolio. If you've never opened Blender, it is a lot. The interface alone takes a few days to get comfortable with. But for what I needed — modeling a specific object, exporting it in a format Three.js can read — it was the right tool.

The thing nobody tells you about Three.js performance is that 3D on the web is heavy by default and you have to actively fight against that. Geometry complexity, texture resolution, how you're handling the render loop, whether you're correctly disposing of objects when they're not needed — all of this hits your frame rate. I ended up adding a toggle that lets users turn off the 3D effects entirely, specifically for older devices. Some people will land on the site on a five year old phone. The site should still work for them.

Before adding the 3D scene:
The hero section was static. Clean, but kind of flat. No real visual depth.

After:
There's actual spatial weight to the page. The 3D element gives the viewport a sense of depth that you can't really replicate with CSS tricks alone.

The trade-off is performance. I'll be honest — Three.js adds real weight to the bundle and if you don't handle it carefully your Lighthouse score will tell you. I spent time optimizing how and when the scene initializes, deferring it until after critical content loads.

The Certifications Book That Took a Weird Amount of Work

One of the sections I'm most satisfied with is the certifications section. Instead of a standard grid of certificate images, I built a flipbook — an actual book you can page through — using TurnJS combined with TiltJS for the 3D tilt effect when you hover.

TurnJS is a library that simulates page turning. It uses CSS3 transforms and JavaScript to create a page-flip animation that looks like a real book. Wiring it up to work with the actual certificate content, making it responsive, handling the edge cases around what happens when someone is on a touch device — this took more time than I expected.

TiltJS sits on top of that and adds the parallax tilt effect when you move your mouse over the book. The way the two libraries interact required some careful event handling. There were bugs. There were moments where the tilt was triggering when it shouldn't, or where the page flip animation was cutting off because something in the transition timing was conflicting.

But when it works — and it works now — it's genuinely one of the most distinctive things on the site. Every other developer portfolio has a grid of certificates. Mine has a book.

Scroll Behavior: Lenis, IntersectionObserver, and the Scrolljacking Debate

Smooth scroll is one of those things that sounds like a nice small detail and turns into a rabbit hole.

I'm using Lenis.js for smooth scrolling. Lenis intercepts the native scroll and replaces it with a smoother, physics-based animation. The result is this buttery, almost native-app feel when you scroll through the page. It's subtle but it matters. The difference between scrolling a site with and without Lenis is the difference between dragging something across carpet versus dragging it across glass.

The debate around scrolljacking is real and worth acknowledging. Scrolljacking — controlling or manipulating the scroll behavior beyond the user's direct input — has a bad reputation and for good reason. It can feel jarring, it breaks user expectations, and it's particularly bad for accessibility. I made specific choices here: the Lenis implementation I'm using follows the user's actual scroll direction and speed, it doesn't take over or redirect the scroll, it just smooths the physics. That's different from the aggressive scrolljacking you see on some agency sites where sections snap into place whether you wanted them to or not.

IntersectionObserver is what drives the section animations. Elements animate in when they enter the viewport. I'm not using a library for this — it's native browser API, well supported, and honestly not that complicated once you write it a few times. The performance profile is much better than scroll event listeners, which fire constantly and are easy to abuse.

SignalHub: The Section I've Never Seen on Another Portfolio

The section called SignalHub is the one I get the most questions about.

Most portfolios have a contact section with a few social icons at the bottom. Facebook, GitHub, LinkedIn, maybe Twitter. That's fine. Functional. Forgettable.

SignalHub is a full section built around two sides — a personal side and a professional side. It's my complete social presence, organized by context. The professional side has GitHub, LinkedIn, dev.to. The personal side has the stuff that's more me and less resume. Both sides are clean, navigable, and presented as a real part of the site rather than an afterthought footer row.

The reason I built it this way is that I think there's actually a signal in how a developer organizes their online presence. Showing that I've thought about context — personal vs professional, what belongs where — says something. It's also just more useful for whoever is looking at the site. If a recruiter lands on it they go to the professional side. If another developer is curious about what I'm actually like as a person they go to the other side.

Is it unconventional? Yes. Did some people think it was weird when I described it? Also yes. It's still on the site.

Nine Sections, One Page, Zero Frameworks

The portfolio is a single page application in the most literal sense — it's one HTML file with nine distinct sections: Home, About, Education, Skills, Certification, Blog, Contact, Projects, and SignalHub.

No React. No Vue. No Next.js. Just HTML, CSS, JavaScript, and a set of libraries that handle specific things.

I want to defend this choice because the developer community has a habit of treating framework usage as a marker of seriousness. If you're not using React you're not building real things, that sort of attitude. I think that's backwards.

For a static portfolio site, a framework adds complexity without adding value. React's component model solves problems that a single-page portfolio doesn't have. The virtual DOM solves a reconciliation problem that doesn't exist when your content doesn't change at runtime. You're adding a build step, a node_modules folder, a mental model, and a bundle size — and none of those things make the portfolio better for the people visiting it.

The cursor tracking, the trailing cursor effect, the animations — all of that is JavaScript. Not framework JavaScript. Just JavaScript.

SEO on a Static Site: The Part Most Portfolio Guides Skip

This part took longer than any feature.

I want to go through what's actually implemented because "I set up SEO" is a phrase people say without explaining what that means.

Meta Tags and Open Graph

Every important meta tag is in the head. Open Graph tags so the site previews correctly when shared on social media. Twitter card meta. Canonical URL. Description. Keywords. These are the basics and they take maybe 30 minutes but a lot of portfolio sites don't have them.

JSON-LD Structured Data

This is the thing most developers skip. JSON-LD is a way to embed structured data in your page that search engines can parse to understand what your page is about. For a personal portfolio, the relevant schema types are Person, WebSite, and potentially BreadcrumbList. Having this in place means Google can potentially show rich results — things like your name and links directly in the search results, not just the page title.

llms.txt

If you haven't heard of llms.txt, it's a relatively new convention — a plain text file at the root of your site that describes your site to large language models. The idea is similar to robots.txt but for AI crawlers. I added one because I think it's going to matter more over time as AI-driven search and AI assistants become the primary way people discover content.

robots.txt and sitemap.xml

Both are present. The sitemap is submitted to both Google Search Console and Bing Webmaster Tools. The robots.txt is correctly configured — there's nothing sophisticated to block, so it's mostly permissive, but having it there properly formatted matters.

Cloudinary for Image Delivery

Images are served from Cloudinary in WebP format with PNG fallbacks. WebP images are on average 25-35% smaller than equivalent JPEG or PNG files. When you're serving a portfolio that has project screenshots, certificate images, profile photos — that size difference accumulates. Cloudinary also gives you automatic format selection and responsive image delivery, so mobile users aren't downloading desktop-sized images.

Google and Bing Indexing

The site is verified with both Google Search Console and Bing Webmaster Tools. Manual indexing requests were submitted. I know this because I did it. Not passively waiting for crawlers to find it.

Structured Heading Hierarchy

One H1 per page. H2s for major sections. H3s inside sections where appropriate. This isn't just SEO — it's accessibility. Screen readers navigate by heading structure. If your headings are a mess the page is a mess.

The "Over-Clean" Problem

There is a thing that happens when you have full control over a codebase and you spend too much time on it. Everything starts looking a little too perfect. Every spacing value is consistent, every transition matches, every color is deliberate. And then you look at it from a distance and something feels slightly off. Too polished. Like a room that nobody actually lives in.

I've had a few people describe my portfolio as "over-clean." I understand what they mean. There's something about a site that looks like it was designed in Figma and exported perfectly that can feel slightly removed. Like you're looking at a product shot rather than a person's work.

I don't have a full solution for this. I've thought about adding more intentional asymmetry, rougher textures, sections that break the grid on purpose. Some of the upcoming features I'm working on — a built-in blog, a personal AI integration, a game — those might add the kind of lived-in quality that the site currently lacks.

For now I'm sitting with it. Sometimes clean is clean and that's fine.

What's Coming Next (The Honest Version)

Here are the features I'm actively working on or thinking seriously about:

Personal AI integration — an AI assistant that knows my work, my writing, my projects, and can answer questions about me. This is actually more interesting technically than it sounds because it requires some form of retrieval-augmented generation rather than just wrapping a model API call.

Built-in blog — not links to external posts. Articles that live inside the portfolio itself, properly rendered, indexed, and consistent with the site's design language.

Case studies for projects — right now the project section shows what I built. The plan is to add case studies that show why I built it, what decisions I made, what I'd change. The how matters less than the thinking behind it.

Performance and accessibility audit — Lighthouse scores are okay but there's work left. WCAG 2.1 AA compliance is the target for accessibility. fetchpriority hints for above-the-fold images. Better font loading strategy.

Replacing the current modal with a custom one — the modal system I'm using right now is borrowed. Writing my own gives me full control over the interaction model and removes an external dependency.

The Thing That Actually Mattered

145 commits to the main branch. 23 stars. 7 forks. JavaScript at 50.7% of the codebase.

None of those numbers are the point.

The point is that when someone asks me how the certification flipbook works, I can explain it. When someone asks why I chose Lenis over native smooth scroll, I have an actual answer. When someone asks about the SEO implementation, I don't have to guess — I built it, I know what's in there.

A template can look better than what I built. Probably several of them do. But a template doesn't teach you anything except how to edit someone else's decisions. And if you're at the beginning of your career, decisions — making them, understanding them, owning them — are what you're supposed to be practicing.

Build your own portfolio. Make it messy if you have to. Make decisions you'll regret later and then learn why you regret them. Put your name on something you actually built.

That's the whole thing.

Stack summary: HTML5, custom CSS3, Bootstrap 5 (grid only), Vanilla JS, jQuery (minimal), Three.js, Blender (3D modeling), TurnJS, TiltJS, Lenis.js, AJAX, Formspree, Cloudinary, GitHub Pages / custom domain

Live: ahmershah.dev

GitHub Repo: ahmershahdev/Portfolio

Find Me Across the Web

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

I Built a Production-Grade E-Commerce Platform in 3 Months — GitHub Copilot Was My Co-Founder

Syed Ahmer Shah — Sat, 23 May 2026 20:57:12 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Let me be honest with you first — when I started Commerza, I genuinely didn't know if I would ever finish it.

I'm a 19-year-old software engineering student from Pakistan. Not from some well-funded university. Not from a bootcamp in San Francisco. I'm doing a 4-year BSE at HITMS and a 3-year Advanced Diploma in Software Engineering at Aptech Pakistan, side by side, trying to become a full-stack developer with real skills — not just tutorial-following muscle memory.

Commerza is a production-grade PHP + MySQL e-commerce platform. Full storefront. Full admin panel. Real payments (COD + Stripe). Enterprise-level security — CSRF protection, Google reCAPTCHA v2 and v3, rate limiting, audit logs, stock locking, SMTP failover, Argon2id password hashing, SQL injection defenses across every user-facing mutation path.

The kind of stuff you'd expect from a team. Not one broke student coding at 2am.

And no — it wasn't a "weekend project". This thing has:

80 PHP files
339 total tracked files
136 commits
PHP 62.6% | JavaScript 20.8% | CSS 15.0% | PowerShell 1.6%

Stack: HTML · CSS · JavaScript · jQuery · Bootstrap · PHP · MySQL · JSON · XML · SEO

It has a dark mode (OrangeRed + Black) and a light mode (NavyBlue + White). It has Cloudinary integration, Redis/APCu caching layers, ClamAV upload scanning, sub-admin role management, a product trash bin, coupon campaigns, review eligibility enforcement, OAuth via Google and Facebook, customer blacklists, and a CI security gate that runs on every push.

This is Commerza.

And GitHub Copilot — with Claude Sonnet 4.6, Claude Opus 4.6, and GPT-5.2-Codex — built probably 78% of the backend alongside me.

Demo

🔗 GitHub: github.com/ahmershahdev/commerza

(Screenshots Below)

The Comeback Story

Where It Started

January 2026. I had the idea. I wanted to build something I could actually show to a client or employer — not a todo app, not a blog engine. Something real. An e-commerce platform from scratch. No Laravel, no framework crutch. Raw PHP. Because I wanted to understand every layer.

The first month? I was mostly doing frontend. HTML structure. CSS design system. Bootstrap grid. jQuery interactions. I wrote those by hand. Clean, methodical, slow. Every component manually. The product cards. The navbar. The cart page. The admin sidebar.

You can see it in my commit history. Slow, small, frontend commits. One file at a time.

Then I hit the backend wall.

I stared at the PHP folder for three days. I knew PHP basics. But production PHP is a different animal. PDO vs mysqli. Prepared statements everywhere, not just "when you feel like it". CSRF tokens — what are they, really, and where do they go? Argon2id vs bcrypt — does it matter for a student project? (Yes. It does.)

The stuff I thought would take me "a few days" started looking like months of work. Email automation — SMTP with a failover to a backup transport? Rate limiting that doesn't break normal users? reCAPTCHA v3 with score thresholds and action validation?

I'd have been done in 6-8 months. Maybe.

Enter Copilot

I'd been using GitHub Copilot casually for code completion. But sometime in early February 2026, I started actually talking to it. Using the agent mode. Giving it context. Describing what I needed. Letting it write entire systems.

The shift was dramatic.

Here's one of the first real "wow" moments. I needed SMTP failover. My plan was: try primary SMTP, if it fails, fail the email. Copilot suggested something I hadn't considered — a dual-route architecture where the primary and secondary share a duplicate-suppression check so you don't accidentally send the same email twice if both routes are responsive at once.

I did not know that was a real pattern. I learned it in the tool. Not from a YouTube tutorial. Not from StackOverflow. From watching Copilot write it and then asking it to explain why.

The final architecture for backend/mailer/mailer.php:

// Simplified illustration of the SMTP failover logic Copilot introduced
function send_mail(string $to, string $subject, string $html_body): bool {
    $primary   = smtp_transport('primary');
    $secondary = smtp_transport('fallback');

    // Suppress duplicate route — if both point to same host/account, skip fallback
    if (same_transport($primary, $secondary)) {
        return attempt_send($primary, $to, $subject, $html_body);
    }

    if (attempt_send($primary, $to, $subject, $html_body)) {
        return true;
    }

    // Primary failed — try fallback
    return attempt_send($secondary, $to, $subject, $html_body);
}

Small thing. But I would not have thought of the duplicate suppression check. That detail would have caused a real bug in production.

What Copilot Built

Let me be specific. Here's what GitHub Copilot generated — or heavily scaffolded — with me reviewing, testing, and iterating:

Email Automation System

SMTP primary + fallback routing (mailer.php)
Security code generation + 15-minute expiry OTP for 2FA and password resets
Cart expiry reminder emails (send_engagement_reminders.php)
Wishlist expiry reminder emails
Monthly profit report emails (monthly_profit_report.php)
Weekly analytics report emails (weekly_analytics_report.php)

Admin Panel Systems

Coupon management (create, activate, validate, campaign control)
Product review moderation with delivery-status eligibility enforcement
Product trash bin with restore workflow and storefront exclusion logic
Sub-admin lifecycle (invite, email verify, roles, suspend/reactivate, delete + immediate session revocation)
Security event monitoring UI

Security Infrastructure

Google reCAPTCHA v3 verification with strict score threshold (0.65 default), action validation, hostname checking, challenge_ts freshness
reCAPTCHA v2 fallback when v3 isn't active for a flow
Honeypot field embedded in CAPTCHA widget
Fallback CAPTCHA challenge (arithmetic + knowledge, hashed answer per nonce, attempt lockout)
Rate limiting across all sensitive endpoints
PDO helper layer for controlled incremental migration from mysqli prepared statements
security_helpers.php — centralized Argon2id/bcrypt hashing, password policy enforcement, rehash logic
CI security gate via .github/workflows/security-gate.yml — static checks on every push + dynamic probes when SECURITY_BASE_URL is configured

Checkout Hardening

Stock locking with SELECT ... FOR UPDATE during order placement
Idempotency key consumption to block duplicate form submissions
High-value COD OTP threshold (email OTP for orders above configurable limit)
Refund and review blacklist enforcement across all user-facing mutation paths

The Before vs. After

Dimension	Before Copilot	After Copilot
PHP files written	~8 (basic CRUD)	80 tracked PHP files
Security posture	basic input escaping	3-level security model (baseline → sensitive forms → critical money paths)
Email system	single PHP mail() call	SMTP failover + 6 automation scripts
Estimated time to complete	6–8 months	3–4 months
Things I knew I didn't know	PDO vs mysqli	stock locking, CSP nonces, Argon2id, idempotency keys
Things I didn't know I didn't know	SMTP duplicate suppression, COD OTP threshold patterns, APCu/Redis cache layering	discovered through Copilot's generated code

The last row is the real one. The things I didn't know I didn't know.

My Experience with GitHub Copilot

The Models Matter

I used three models across this project:

Claude Sonnet 4.6 — my daily workhorse. Fast, accurate for PHP, good at following context across multiple files. When I was iterating quickly on storefront logic or admin UI, Sonnet was my go-to. It understood my existing codebase structure without me re-explaining every time.

Claude Opus 4.6 — for the scary parts. When I needed the CAPTCHA hybrid system designed, or when I was trying to figure out the checkout security model (transaction boundaries, row locking, idempotency), I reached for Opus. Slower, but it reasoned through edge cases I wouldn't have caught. The "Level 1, Level 2, Level 3 security severity model" in my README — that framework came out of an Opus session.

GPT-5.2-Codex — I used this mostly for breakpoint testing, spotting logic flaws, checking SQL injection vectors, and validating security helpers. Different model, different angle on the same code. Like having a second pair of eyes that reads code differently. Copilot's multi-model architecture made this seamless — I could switch within the same workflow.

As of April 2026, GitHub Copilot supports model selection for both Claude and Codex agents, with Claude Sonnet 4.6 and Claude Opus 4.6 available for Anthropic tasks, and GPT-5.2-Codex, GPT-5.3-Codex, and GPT-5.4 available for OpenAI Codex tasks.

What Actually Happened in Practice

It wasn't magic. Let me be clear.

I wrote every single frontend file by hand. Copilot suggestions during HTML/CSS work were mostly noise — I ignored them. The jQuery interactions, the Bootstrap grid, the storefront layouts — that's mine, manually typed.

Where Copilot exploded in value was PHP systems logic. The kind of code where one missed edge case means a security hole or a race condition in checkout. The kind of code where you need to know patterns you've never been taught.

A real example: I knew I needed "CSRF protection." What I didn't know was where exactly to validate the token (before any database operation, not after), or that regenerating the token after each validated request is a meaningful hardening step. Copilot wrote it the right way. I read the code, asked it why, it explained. That's not just autocomplete — that's mentorship encoded into a tool.

What I Pushed Back On

Copilot is not always right. A few things I rejected or significantly modified:

It initially generated SQL using string concatenation in a few helper queries — I pushed back and forced prepared statements everywhere
One version of the reCAPTCHA logic didn't validate hostname or challenge_ts — I asked for hardening and got a stricter implementation
The first version of the rate limiter didn't have burst tolerance — it would have flagged fast-typing legitimate users. I caught it in testing

The right model is: you're the architect. Copilot is a very fast contractor who sometimes cuts corners. Review everything.

On Learning While Using AI

Here's the thing people don't say enough: AI-assisted development taught me more than it replaced. I learned PDO, Argon2id, CSP nonces, idempotency keys, stock locking, Cloudinary server-side signing, APCu caching, and Redis connection pooling — all through reading, testing, and interrogating code that Copilot generated. If I'd been alone, I'd have written simpler code and never encountered these patterns at all.

The alternative wasn't "I would have learned this from scratch." The alternative was "I would have shipped something less secure and less complete."

Conclusion

Commerza is archived now — May 5, 2026. I archived it not because I abandoned it, but because it reached a state I'm actually satisfied with. 339 files. 80 PHP files. 136 commits. A CI security gate. A dual-SMTP mailer. An admin panel I'd actually use.

Is it perfect? No. There are things I'd change. The PDO migration is incomplete — the README says so honestly. Some admin UI pages are rougher than others. There's a lot of room to grow.

But it exists. It runs. It handles real security concerns that most tutorial-based PHP projects completely ignore.

That's the difference three months and GitHub Copilot made.

I'm not a "vibe coder." I'm not someone who just prompts and ships. Copilot was my accelerator, my pattern library, and — genuinely — my teacher on the backend. The frontend was mine. The architecture decisions were mine. The testing, the debugging, the "wait this doesn't make sense, let me re-read the generated code at 1am" — all mine.

If you're a student developer who thinks AI tools are "cheating": they're not. They're the closest thing to a senior developer pair-programming with you that most of us will ever get access to, for free. Use them intelligently. Read everything they generate. Push back when it's wrong. Ask why.

That's how you build a production-grade e-commerce platform in 3 months instead of 8.

Links:

🔗 GitHub: github.com/ahmershahdev/commerza

Built by Syed Ahmer Shah — BSE student, HITMS BSE, Aptech ADSE, Pakistan. 2026.

Find Me Across the Web

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

Antigravity & WebMCP: Why Google I/O 2026 is Terrifying for Devs

Syed Ahmer Shah — Wed, 20 May 2026 11:44:46 +0000

This is a submission for the Google I/O Writing Challenge

"It's been 10 years since we pivoted the company to be AI first."
— Sundar Pichai, Google I/O 2026 Keynote, May 19, 2026

I watched the Google I/O 2026 keynote. And somewhere around the part where a Google DeepMind engineer named Varun Mohan demoed an AI agent that built a functioning operating system from scratch — in 12 hours — I kind of just... sat there staring at the screen.

Not because it was cool. I mean, it was cool. But because of what it quietly meant.

If agents can build operating systems, what does that say about my carefully maintained full-stack skill set? What does it say about yours?

Let me be honest with you. I'm a developer still learning, still grinding. I've spent time with HTML, CSS, JavaScript, Firebase, Supabase — the whole usual roadmap. And this I/O felt different from previous years. It wasn't just model benchmarks and capability updates. It felt like Google was quietly drawing a map — and the destination on that map is a world where AI agents don't help developers write code.

They are the developers.

And honestly? That question kept me up.

🗓️ What Actually Happened at I/O 2026 — The Short Version

Before I get into opinions, let's be clear on the facts. Google I/O 2026 ran May 19–20 at the Shoreline Amphitheatre in Mountain View, California. Over 7,000 people attended in person. The event was livestreamed to more than 500 developer events across 100 countries.

The big announcements, in order of "things that made my eye twitch":

Announcement	What it is	Why it matters
Gemini 3.5 Flash	New flagship model for agentic workflows	Outperforms Gemini 3.1 Pro, runs 4x faster than competing frontier models
Antigravity 2.0	Agent-first development desktop platform	Multiple autonomous AI agents working in parallel on your codebase
Antigravity CLI	Terminal version of Antigravity	Build and orchestrate agents without leaving your terminal
Antigravity SDK	Programmatic access to agent harness	Host custom agents on your own infrastructure
Managed Agents (Gemini API)	One API call = fully provisioned agent in isolated Linux sandbox	Infrastructure friction = gone
Google AI Studio updates	Native Kotlin support, Workspace integration, one-click Cloud Run deploy	Build and ship full-stack apps with a single prompt
WebMCP	Open web standard for browser-based AI agents	AI agents can directly interact with your web app's JS functions and HTML forms
Firebase → Agent-native	Firebase now integrates directly with AI Studio and Antigravity	Vibe-code full-stack apps, deploy to Cloud Run with one click
Gemini Omni	Multimodal world model — any input → any output	Videos, images, audio, text — all combined
Modern Web Guidance	Expert-vetted agent skills for web dev (100+ use cases)	Your agent knows web best practices
Migration Agent (Android Studio)	Migrates React Native/web/iOS to native Kotlin	Weeks of migration → hours
CodeMender	AI code security agent from Google DeepMind	Scans agent-generated code for vulnerabilities, auto-fixes

🤖 The Part Nobody's Talking About: Antigravity Is Not a Coding Tool

Most people are framing Antigravity as "a better Copilot" or "Google's answer to Cursor."

That's wrong.

Antigravity — especially with the 2.0 update — is an agent orchestration runtime. There's a real difference. A coding tool suggests the next line. An agent runtime executes plans. It spins up subagents to work in parallel. It runs in the background. It connects to your Android builds, your Firebase project, your Cloud Run deployment. It does quality audits. It emulates user experiences. It even masks credentials automatically.

Google is trying to turn Gemini from a chatbot family into a distributed agent runtime. The center of gravity is not one product. It is the stack formed by Gemini 3.5 Flash, Antigravity, Gemini Spark, AI Mode in Search, Gemini Omni, Chrome, and developer-facing managed agents.

That's not a coding assistant. That's a software development lifecycle, automated.

💻 Let Me Show You What This Looks Like in Practice

Here's how Managed Agents actually work using the real Gemini Interactions API. This isn't pseudocode — this is the actual documented syntax from Google's official docs as of May 19, 2026.

Getting Started with Managed Agents (Real API Syntax)

Step 1: Install the SDK

Requires @google/genai version 1.33.0 or later for Interactions API support.

npm install @google/genai

Step 2: Spin up a full agent with a single call

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

async function runManagedAgent() {
  // One call = a fully provisioned Antigravity agent in a remote Linux sandbox
  // The agent reasons, uses tools, executes code, and manages files autonomously
  const interaction = await client.interactions.create(
    {
      agent: "antigravity-preview-05-2026", // The Antigravity base agent
      input: `
        Create a full REST API with Express.js that:
        1. Has /users endpoint (GET, POST, DELETE)
        2. Uses in-memory storage
        3. Includes input validation
        4. Writes unit tests with Jest
        5. Creates a README.md
        Run the tests and confirm they pass.
      `,
      environment: "remote", // Isolated Linux sandbox, hosted by Google
    },
    { timeout: 300000 } // 5 min — agents take longer than a single prompt
  );

  // The agent doesn't just generate code — it runs it, fixes errors, returns results
  console.log(interaction.outputText);

  // Save these — you'll need them for the next turn
  console.log("Interaction ID:", interaction.id);
  console.log("Environment ID:", interaction.environmentId);
}

runManagedAgent();

Step 3: Continue the same session — files and state are still there

// Multi-turn: resume the exact same Linux environment
const followUp = await client.interactions.create(
  {
    agent: "antigravity-preview-05-2026",
    input: "Now add JWT authentication to the existing API. Don't rewrite from scratch.",
    // This is what makes it powerful — the previous environment persists
    environment: interaction.environmentId, // Reuse the same sandbox
    previousInteractionId: interaction.id, // Continue conversation history
  },
  { timeout: 300000 }
);

console.log(followUp.outputText);

The agent doesn't forget. It picks up exactly where it left off — same files, same packages, same state. Like handing off to a developer who was already in the middle of the work.

⚠️ Note: Managed Agents / Interactions API is currently in preview. The API schema may change. For stable production work, generateContent remains the recommended path — Google's own docs say so.

Modern Web Guidance — The Underrated Announcement

This is, in my opinion, the most slept-on announcement of I/O 2026. Nobody is talking about it enough.

# Install with one command — works with Antigravity or any agent
npx modern-web-guidance install

What this does: it gives your coding agent a set of 100+ expert-vetted web development skills. Not just "write valid HTML." We're talking WCAG accessibility standards, Core Web Vitals, security headers, Baseline API compatibility, progressive enhancement patterns.

Before this, your agent wrote working code. After this, your agent writes correct code.

That's not a nice-to-have. That's changing what "senior developer" actually means.

Firebase + AI Studio: Full-Stack App in One Prompt

// You type this in Google AI Studio:

"Build a task management app where users can:
- Sign in with Google
- Create and complete tasks stored in Firestore
- Get AI-powered task prioritization
- Deploy it live"

// What happens next (this is real, not a demo):
// ✅ Firebase project scaffolded with security rules
// ✅ Authentication configured via Firebase Auth
// ✅ Firestore schema and rules written
// ✅ Firebase AI Logic integrated for prioritization
// ✅ One-click deploy to Cloud Run (free tier for first 2 apps)
// ✅ Google Workspace APIs available via natural language

Firebase's integration with Google AI Studio now supports one-click deployment to Cloud Run — no billing required for your first two Firebase-enabled apps on the new Google Cloud Starter Tier. You can also connect your apps to Google Workspace data like Gmail, Docs, and Sheets using natural language, through a standard Firebase Auth "Sign in with Google" flow.

I tried this. It generated a working expense tracker — Firestore rules, authentication flow, and a functional UI — in about 4 minutes. Did I have to tweak things? Yes. A few field names, one security rule that was too permissive. But the scaffolding was solid. Faster than writing it myself? Embarrassingly, yes.

🤔 The Real Question: Are Developers Being Replaced?

Okay. Deep breath.

Let me tell you what I actually think — not the comfortable answer, not the "AI is just a tool" cope that shows up in every LinkedIn post.

Some developers are being replaced. Some are being upgraded. The difference is whether you understand what's happening.

The "Before" World (pre-2026)

You write a feature → 2 days
You debug a weird edge case → 3 hours
You migrate an old codebase → weeks
You write tests → almost as long as the feature
You deploy → configuration hell

The "After" World (I/O 2026 and beyond)

Feature → agent does it in 20 minutes
Debug → agent finds it, fixes it, verifies the fix
Migration → The Android Studio migration agent turns weeks into hours
Tests → auto-generated and auto-run inside the sandbox
Deploy → one click, Cloud Run

So yeah. Some of the work is being replaced. Specifically: the repetitive, formulaic parts.

But here's what ISN'T being replaced (yet):

System design decisions — WHY you're building this architecture, not just HOW
Understanding user needs — translating messy human requirements into precise specs
Security judgment — knowing which tradeoff is acceptable and which isn't
Domain context — what legal, ethical, business constraints apply
Quality bar — recognizing when "working" ≠ "good enough to ship"

The agent doesn't know your company's security requirements. It doesn't know your users' edge cases. It doesn't know what scales to 1 million users. Yet is doing a lot of work in that sentence.

📊 Pros & Cons: Honest Assessment

✅ What's Actually Good

What	Why
Gemini 3.5 Flash speed	4x faster than competing frontier models — finally usable in real workflows
Managed Agents removing infrastructure	No more Docker config / VM setup just to run an agent
Firebase → Cloud Run one-click deploy	Free for first 2 apps. Removes the biggest full-stack friction point
WebMCP open standard	Web agents can be precise, not just "AI guessing at your DOM"
Migration Agent	Genuinely solves a real, painful, existing problem
Antigravity CLI	Terminal-first devs aren't second-class citizens
$2M XPRIZE Hackathon	Largest hackathon prize pool ever. A real opportunity.

❌ What I'm Worried About

Concern	Why
Forced Gemini CLI → Antigravity CLI migration	Google literally says "we encourage Gemini CLI users to migrate." Not a choice.
$100/month AI Ultra plan	Who gets access to frontier AI? Developers in Pakistan? India? Nigeria? The access gap is real.
Agent-generated code security	CodeMender catches vulnerabilities — but it's an agent checking another agent's code. Trust chains all the way down.
Total Google lock-in	AI Studio + Antigravity + Firebase + Cloud Run + Workspace. One ecosystem. Tightly coupled. What happens when pricing changes?
"Vibe coding" quality bar	Prompting a CRUD app ≠ building software that's maintainable in 2 years

🔥 The Most Underrated Announcement: WebMCP

Everyone is talking about Gemini 3.5 Flash. Almost nobody is talking about WebMCP.

WebMCP is a proposed open web standard that allows developers to expose structured tools — like JavaScript functions and HTML forms — so browser-based AI agents can execute complex tasks with greater speed, reliability, and precision. The experimental WebMCP origin trial starts in Chrome 149, with Gemini in Chrome support coming soon.

Think about what this actually means.

Right now, AI agents interacting with the web are basically doing screen-scraping with extra steps. They're looking at raw HTML, guessing at intent, clicking things, and hoping it works. It's fragile. It breaks constantly.

WebMCP changes that architecture. Instead of the agent guessing at what your form does, you tell it. It's structured. Precise. Like giving AI a clean API to your website.

// WebMCP — based on proposed spec (origin trial in Chrome 149)
// Note: exact API surface may evolve as the standard matures

// In your web app, you expose capabilities to browser AI agents:
if ("webmcp" in navigator) {
  navigator.webmcp.register({
    tools: [
      {
        name: "create_task",
        description: "Creates a new task in the project management system",
        parameters: {
          type: "object",
          properties: {
            title: { type: "string" },
            priority: { type: "string", enum: ["low", "medium", "high"] },
            dueDate: { type: "string", format: "date" },
          },
          required: ["title"],
        },
        handler: async (params) => {
          // Your actual business logic here
          return await taskAPI.create(params);
        },
      },
      {
        name: "get_user_tasks",
        description: "Retrieves all tasks for the current user",
        handler: async () => {
          return await taskAPI.getForCurrentUser();
        },
      },
    ],
  });
}

// Now a browser agent (Gemini in Chrome, etc.) can:
// "Create a high-priority task called 'Fix the login bug' due Friday"
// And it executes — precisely, through your API, not through DOM hacking.

This is the internet becoming agent-native. Not just a few Google apps — the whole web, if developers adopt it.

And the reason this matters for you as a web developer: the websites that expose WebMCP tools will work with AI agents. The ones that don't will be invisible to them. It's a new SEO, kind of. Except instead of optimizing for Google's crawler, you're optimizing for AI agents.

💬 What Sundar Pichai Actually Said — And What I Think He Meant

Pichai opened the keynote with: "It's been 10 years since we pivoted the company to be AI first."

On the surface, that's a corporate milestone statement. But underneath it, there's an implicit message:

The first 10 years were about building the AI. The next 10 years are about the AI building everything else.

Google's planned AI spending is expected to hit somewhere between $180 billion and $190 billion this year alone. That's not a bet. That's a complete restructuring of what the company is.

And for developers, that means the ground is moving under your feet whether you're watching the keynote or not.

🧪 My Honest Hands-On Experience

After the keynote, I actually tried things instead of just forming opinions in a vacuum:

1. Google AI Studio + Firebase
Built a simple expense tracker app via prompt. Firestore rules, auth flow, working UI — about 4 minutes. I had to edit the Firestore security rule for the user document (it was too open), and one of the UI components had hardcoded user IDs that needed replacing. But the scaffolding? Solid. The deploy to Cloud Run worked first try.

2. Modern Web Guidance
Ran npx modern-web-guidance install. It pulled in a large set of expert knowledge covering web performance, accessibility, and security. I then asked the agent to "make this page accessible." It identified missing alt text, added proper ARIA roles, and noted the color contrast ratio was below WCAG 2.2 AA standard. That's not a generic suggestion. That's specificity that usually requires a senior dev to catch.

3. Antigravity CLI (early preview)
Fast. The terminal experience is genuinely good. The credential masking is real — I tested it by deliberately putting an API key in a prompt and it masked it automatically. The agent ran terminal commands, checked output, and fixed its own mistakes mid-task. No manual intervention.

The honest verdict: it works. It's not magic. Agents still make dumb mistakes — wrong assumptions, over-eager refactors, occasional hallucinated package names. But the infrastructure is real. The speed is real. And it's moving faster than most developers are adjusting to.

📖 What This Means For Developers — The Uncomfortable Reflection

There are three kinds of developers right now:

Developer Type A — Sees AI agents and panics. Dismisses them as "hype." Keeps doing everything manually. Will be fine for a while. Then suddenly won't be.

Developer Type B — Sees AI agents and fully surrenders. Just prompts everything. Has no idea what the generated code actually does. Can't debug. Can't make architecture decisions. Produces fast, shallow work.

Developer Type C — Sees AI agents as force multipliers. Understands systems deeply. Uses agents for the mechanical work. Keeps judgment, architecture, and critical thinking in their own hands. This person becomes 10x more productive without becoming 10x more replaceable.

I/O 2026 forced me to ask: which one am I actually building toward?

Because Google didn't just release tools at this keynote. They released a vision. This is the era of agent-led development, where agents are evolving from coding assistants to intelligent collaborators capable of managing the entire software development lifecycle.

The entire lifecycle. Not part of it. All of it.

The only way to stay relevant in that world is to own the parts agents can't: judgment, context, taste, accountability. Those aren't soft skills. Those are the new technical skills.

🎯 What Should You Actually Do Right Now?

Stop consuming. Start building with the new tools. Here's a concrete list:

Try the Antigravity base agent → antigravity.google — free tier available
Run a Managed Agent interaction → npm install @google/genai@1.33.0 + the code above
Install Modern Web Guidance → npx modern-web-guidance install — immediate, free
Build one app in AI Studio with Firebase → aistudio.google.com — first 2 Cloud Run deploys free
Read the WebMCP spec → developer.chrome.com/docs/ai/webmcp — origin trial, Chrome 149
Apply for the XPRIZE Hackathon → geminixprize.com — $2M prize pool, September finals in LA

✅ Conclusion: The Map Has Changed

I'll leave you with this.

In 2016, Google said "AI first." Nobody really believed them, not fully.

In 2022, ChatGPT hit. People said "AI is a tool."

In 2024, agents started shipping. People said "it's not production-ready."

In 2026, at I/O, a Google engineer demoed an AI building an operating system in 12 hours. People in the audience laughed, nervously.

That nervous laugh is the sound of a mental model breaking.

We're not in the "AI assists developers" phase anymore. I/O 2026 was a clear pivot toward an agentic AI ecosystem where intelligent systems can assist users, automate workflows, and work across apps, devices, and services with minimal human intervention.

Minimal. Human. Intervention.

That's the destination Google put on the map at I/O 2026.

The question isn't whether you agree with the direction. It's whether you're building the skills that matter at the destination — or the skills that only mattered on the way there.

📚 References & Useful Links

Resource	Link
🎬 Google Keynote (May 19, 2026)	YouTube
👩‍💻 Developer Keynote	YouTube
🤖 What's New in Google AI	YouTube
🔥 What's New in Firebase	YouTube
💙 What's New in Flutter	YouTube
☁️ Google Cloud Live from I/O	YouTube
Google Developers Blog — Dev Keynote Recap	developers.googleblog.com
Google Blog — Developer Highlights	blog.google
Introducing Managed Agents in the Gemini API	blog.google
Firebase I/O 2026 Announcements	firebase.blog
Official Antigravity Agent Docs	ai.google.dev
Gemini Interactions API Docs	ai.google.dev
WebMCP Origin Trial (Chrome 149)	developer.chrome.com
Modern Web Guidance	goo.gle/modern-web-guidance
Build with Gemini XPRIZE Hackathon	geminixprize.com
Google AI Studio	aistudio.google.com

Written May 20, 2026 — the day after watching Google announce that an AI built an operating system in 12 hours, and feeling the very specific emotion of "excited and deeply unsettled at the same time."

Find Me Across the Web

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

Swapping Go for Rust: 10x Cheaper K8s Ingress

Syed Ahmer Shah — Tue, 19 May 2026 16:59:42 +0000

Let me tell you a story that starts in 2013, peaks somewhere around 2019, and ends with me staring at a $4,200 AWS bill at 11pm on a Tuesday.

The Revolution Nobody Saw Coming

March 2013. PyCon. A French developer named Solomon Hykes gets on stage and does a five-minute demo of something called Docker.

The audience is confused. Then curious. Then the applause starts.

In those five minutes, he essentially broke software deployment as everyone knew it. No more "works on my machine." No more environment hell. You take your app, you put it in a box, and that box runs anywhere. Same box. Every time.

The internet lost its mind.

Within a year, every startup was containerizing everything. Within two, enterprises were asking their CTOs why they weren't doing it yet. Within three, Docker was valued at over a billion dollars and "containerization" stopped being a niche word.

But here's the thing about revolutions — they create new problems.

Enter: The Orchestration Wars

By 2014 you had thousands of containers. Maybe tens of thousands. And now what? How do you run them? How do you restart the ones that crash? How do you roll out updates without downtime? How do you route traffic between them?

This is when it got messy. Genuinely messy.

Three players showed up:

Docker Swarm — Docker's own answer. Simple. Integrated. And honestly? Pretty good. But Docker the company was making decisions that confused everyone. They kept pivoting. Swarm never got the trust it deserved.

Apache Mesos — the enterprise option. Heavy. Complex. Battle-tested at Twitter and Airbnb scale. But you needed a PhD to configure it and the learning curve was basically a vertical wall.

Kubernetes — Google's open-source version of Borg, the internal system they'd been running for over a decade. K8s dropped in 2014 and it was ugly at first. The config was verbose, the concepts were alien, the documentation was written by people who already understood it.

But then something happened. Google poured resources into it. A foundation formed around it (CNCF — Cloud Native Computing Foundation, 2015). AWS, Azure, GCP all built managed versions of it. The ecosystem exploded.

By 2017 the wars were effectively over.

Kubernetes won. Swarm is still technically alive but nobody talks about it at conferences anymore. Mesos is mostly a ghost. K8s became the operating system of the cloud.

Go's Golden Era

Here's something worth understanding: Kubernetes is written in Go. Docker was written in Go. Traefik, Prometheus, Terraform, Consul, etcd, Helm — basically everything that runs your infrastructure today traces back to Go.

This wasn't an accident.

Go was designed at Google in 2007 by some of the most legendary people in computer science — Rob Pike, Ken Thompson (yes, the Unix guy), Robert Griesemer. They wanted a language that compiled fast, ran fast, handled concurrency natively, and didn't make you want to throw your laptop through a window.

They got it right.

Go's goroutines made writing networked, concurrent services stupid easy. The toolchain was clean. The standard library was rich. You could hire people who knew it. Everything clicked.

The cloud-native world standardized on Go almost by accident. It was the right language, at the right time, for the right problems.

Between 2015 and 2020, if you were building infrastructure tooling and not using Go, people looked at you sideways.

Meanwhile, In a Mozilla Office Somewhere...

A Mozilla employee named Graydon Hoare is working on something in his spare time. A new systems language. One that gives you C-level performance but makes memory corruption structurally impossible.

No garbage collector. No runtime overhead. But also no dangling pointers, no buffer overflows, no use-after-free bugs — the entire class of vulnerabilities that has haunted C and C++ for fifty years.

The trick? A concept called ownership. Every piece of memory has exactly one owner. When the owner goes out of scope, the memory is freed. Not by a GC running in the background. Not "eventually." Immediately. Deterministically. At compile time.

Mozilla ships Rust 1.0 in May 2015. The initial reaction from the systems programming community was somewhere between skeptical and hostile. The borrow checker — the compiler mechanism that enforces ownership — felt like fighting the language more than writing it.

People tried it, got confused, went back to C++ or Go.

But a small group of people got it. And they kept building. Quietly.

The Quiet Takeover

Cloudflare has a problem.

They're running nginx. Everywhere. nginx is written in C. It's fast, it's reliable, but it's also showing its age — the architecture doesn't handle modern HTTP patterns well, extending it is painful, and the codebase has had its share of security issues because, well, it's C.

Cloudflare decides to replace it. Not patch it. Replace it.

They write Pingora in Rust. A full HTTP proxy, from scratch, handling 1 trillion requests per day in production.

The numbers they published were obscene. Compared to nginx: 70% reduction in CPU. 67% reduction in memory. Near-zero security vulnerabilities because the entire class of memory bugs simply cannot exist in safe Rust.

And they didn't stop there. By late 2025, Cloudflare went further — they rewrote FL, the actual "brain" of Cloudflare (the system that applies every customer's WAF rules, DDoS settings, and routing logic) in Rust, calling it FL2. The result: response time dropped by 10ms and overall performance went up 25%. They shut down FL1 entirely in early 2026.

Then AWS announced they were writing parts of their virtualization layer in Rust. Then Microsoft said Rust was the preferred language for new systems code at the company. Then the Linux kernel — the Linux kernel, which has run on C for thirty years — accepted Rust as a second language, with stable driver support landing in kernel 6.1.

The systems programming community quietly started paying attention.

And then the Go community started getting uncomfortable.

Back To My Tuesday Night

This is where I come back in.

We were a mid-size startup. Not Cloudflare. Not Amazon. But we were scaling, traffic was growing, and our Kubernetes setup was running fine.

That word again. Fine.

We were using Traefik as our ingress controller. Go-based, battle-tested, the default choice for half the K8s tutorials on the internet. Three replicas, handling maybe 800 req/s at peak.

I was not watching the AWS bill closely enough. That was my fault.

Then I did. And I saw $4,200 for one month of ingress-related compute.

I didn't say anything for thirty seconds. I just sat there. That specific feeling when a number doesn't match your mental model and your brain is trying to reconcile it.

The Panic Phase

I started Googling. You should never Google things when you're panicking. You come out two hours later having read about eBPF, service meshes, and someone's confident blog post from 2021 recommending something that got deprecated in 2023.

What I found when I actually focused: the memory profile of our ingress layer was absurd for what we were asking it to do.

Each Traefik pod idling at ~180MB RSS. Under load? Comfortably 400MB+. That's not Traefik being badly written — it isn't. It's Go's garbage collector doing what it's designed to do. The GC optimizes for latency, not memory. It keeps things around, waits for a good time to clean up, and "a good time" under constant HTTP load basically never comes.

We had 3 pods × 400MB × 2 t3.large nodes (because they needed the headroom) running 24/7.

Do the math on AWS pricing. Then cry.

Then I found the Pingora post. Read the whole thing this time. Pulled the benchmark numbers. Understood what was actually happening at the memory level in Rust vs Go.

Something clicked.

Why Rust Hits Different Here

Nobody says this clearly enough so I will:

For most application code, Go's GC is fine. Genuinely fine.

Writing a web API? Go. Building a CLI tool? Go. Microservices with moderate traffic? Go, easily.

But a proxy is a different beast. A proxy's entire job is to sit between two things and move bytes from one to the other, as fast as possible, thousands of times per second. Every request means allocations — headers, buffers, connection state. Every one of those allocations eventually needs to be freed.

In Go, "eventually" is doing a lot of work in that sentence.

In Rust, memory is freed the moment it goes out of scope. Not by a background process. Not on a schedule. Structurally, at the language level. The compiler guarantees it.

For a proxy, that's not a nice-to-have. It's the difference between flat memory usage and a profile that climbs under load and triggers GC pauses at exactly the wrong moment.

linkerd2-proxy — the data plane for the Linkerd service mesh — is written in Rust for exactly this reason. It's running in production service meshes at serious scale. Tokio — Rust's async runtime — is mature enough that they're running their own conference in 2026. The ecosystem isn't a science experiment anymore.

The Migration (It Was Not Smooth, I Won't Lie)

We didn't rewrite Traefik. We're not a systems programming shop.

We moved to Envoy as the core proxy (C++, but with a very different memory model than Go's runtime, and a mature extensibility story) plus a small Rust service handling our custom routing logic that Traefik was previously doing in middleware.

Week one: three outages.

Not because Rust is hard (our Rust service was fine). Because Envoy's config model is completely different from Traefik's and we were copying assumptions over like fools. Traefik does a lot of magic via annotations. Envoy does nothing by magic. Everything explicit. Everything verbose. First time you see an Envoy config file you think someone is hazing you.

Week two: stable. Genuinely stable. We kept waiting for something to explode. Nothing did.

Week three: I pulled up the memory dashboards.

I called my co-engineer over. We both stared at it for a moment.

The Numbers (This Is The Part You Came For)

Before:

3x Traefik pods
~380MB average RSS each
CPU spikes during GC under high traffic
2x t3.large nodes just for ingress (2 vCPU, 8GB each)

After:

2x Envoy pods + Rust routing layer
~40MB average RSS each
CPU: completely flat. No spikes. No GC sweeps. Nothing.
1x t3.small node handles it without breaking a sweat

Node costs alone: from ~$340/month to ~$30/month.

Factor in traffic processing, data transfer handling, reduced overhead across the board — the full picture came out to roughly 10x cheaper.

Not 10% cheaper. Not 2x. Ten times.

The title isn't clickbait. I was as shocked as you are right now.

Should You Actually Do This?

Real answer: probably not yet, unless you're bleeding money.

Operational complexity is a real cost. This migration took two engineers about three weeks including the debugging nights and the config archaeology. If Traefik is working for you and your AWS bill isn't making you spiral, leave it alone. Boring infrastructure is good infrastructure.

But if your ingress layer has its own line item on your cost explorer — and you feel a specific kind of shame looking at it — the tooling exists, it's production-proven, and the math is not subtle.

The Rust networking ecosystem in 2026 is not the Rust networking ecosystem of 2018. Cloudflare has replaced their entire request-handling stack with Rust. Pingora is open-source and now at v0.7.0 — it's evolved from "proxy" into what people are calling programmable network infrastructure. linkerd2-proxy has been running in production service meshes for years. Tokio is the undisputed async runtime of the ecosystem. The scary part is mostly gone. What's left is just learning.

The Actual Lesson (And It's Not About Languages)

Go didn't lose. This wasn't a rivalry with a winner.

Go won the cloud infrastructure era because it was exactly right for that moment — concurrency primitives, fast compilation, readable code, a great standard library. Kubernetes exists because of Go. The cloud-native ecosystem exists because of Go.

But Rust is winning the next layer — the performance-critical substrate that the rest of the infrastructure runs on. Proxies. Kernels. Network dataplanes. Places where a GC isn't a tradeoff you can afford because memory is money and latency is user experience.

Both can be true. A hammer is the right tool for nails. A scalpel is the right tool for surgery. Neither replaces the other.

That $4,200 bill became $390.

The CFO asked me what changed.

I said I learned a new programming language.

He nodded like he understood and immediately changed the subject.

That's fine. The bill was paid. The graphs were flat. The nodes were small.

Sometimes the best infrastructure is the one nobody notices.

Find Me Across the Web

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

Gemma 4 vs Claude vs Llama: Which Model Wins for Devs

Syed Ahmer Shah — Sun, 17 May 2026 16:27:41 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Okay, let me be honest with you for a second.

I'm tired of AI comparison posts that read like a press release had a baby with a spreadsheet. You know the ones. Big table. Green checkmarks. "Model X wins for enterprise use cases." Thanks, very useful, completely useless.

So let me try something different. Let me tell you what I actually found after spending time digging into Gemma 4, Claude, and Llama 4 in 2026 — what surprised me, what annoyed me, and where each one genuinely earns your trust or loses it.

Because the honest answer is: it depends, but not in the way you think.

First — What Even Is Gemma 4?

If you haven't been paying attention, Google DeepMind dropped Gemma 4 on April 2, 2026 and it quietly started breaking things.

Not in a bad way. In the "wait, this runs on what?" way.

Gemma 4 isn't a single model. It's a family:

E2B (~2.3B effective params) — designed for phones and Raspberry Pi. Yes, literally your Pi.
E4B (~4.5B effective params) — the sweet spot. Runs on integrated graphics or any 8GB+ GPU.
26B A4B MoE — 26 billion total params, but only 3.8 billion active per inference thanks to Mixture-of-Experts routing. One A100 80GB can serve it.
31B Dense — the big gun. All params active, maximum quality.

All of it built on the same research foundations as Gemini 3. All of it released under Apache 2.0. No MAU limits. No special permissions. No restrictive use clauses. Just: here, use it.

That last bit matters more than people are giving it credit for.

The Numbers Nobody's Contextualizing

Let me throw some benchmarks at you, but I'm actually going to explain what they mean:

Gemma 4 31B on AIME 2026 (math): 89.2%

For context, Gemma 3 27B scored 20.8% on the same test. That's a +330% jump. Not incremental. Not a rounding error. Something fundamentally changed.

LiveCodeBench v6: 80%

Gemma 3 was at 29.1%. So you're looking at 175% improvement in coding benchmarks in one generation.

Codeforces ELO: 2,150

That's expert competitive programmer territory. Running locally. On your machine.

Agentic Tool Use (τ2-bench Retail): went from 6.6% to 86.4%

That's +1200%. The model went from basically failing at multi-step tool use to crushing it. This is the benchmark I'd bet money on being the most meaningful one for 2026 workflows.

The 31B Dense model currently sits at #3 on the Arena AI text leaderboard among all open models — outcompeting models with 20x more parameters.

And look — I know benchmarks lie sometimes. I know labs cherry-pick. But when every benchmark jumps by 100-300% simultaneously, that's not cherry-picking. Something real happened here.

Claude: The One You Pay For (And Why You Still Might)

Let me be clear: I respect what Anthropic has built. Claude is genuinely different from most models in ways that are hard to benchmark.

As of early 2026, the main Claude options are:

Sonnet 4.6 — $3/$15 per million tokens. 79.6% on SWE-bench Verified.
Opus 4.6 — $5/$25 per million tokens. 80.8% on SWE-bench Verified.
Opus 4.7 — $5/$25 per million tokens. 87.6% on SWE-bench Verified. Released April 16, 2026.

The gap between Sonnet 4.6 and Opus 4.6 is 1.2 percentage points on the benchmark that matters most for developers. That's it. One point. At 40% lower cost and 17% faster output. Most production teams route 80% of work to Sonnet and reserve Opus for the genuinely hard stuff.

Cursor's co-founder called Sonnet 4.6 "a notable improvement over Sonnet 4.5 across the board, including long-horizon tasks." GitHub reported strong performance on complex code fixes. Cognition said it "meaningfully closed the gap with Opus on bug detection."

So what's the catch?

Claude has no weights. Full stop.

You cannot run Claude locally. You cannot fine-tune it on your data. You cannot deploy it on your own infrastructure. There's no local option, no open version, nothing. It's a pure API play.

Constitutional AI baked into the architecture means you will occasionally hit refusals that feel arbitrary — requests the model could handle but won't. The reason-based constitution introduced in January 2026 made these responses more nuanced, but you'll still encounter them if you push edge cases.

The 200K context window is solid. The 1M beta (via header) is there for Opus if you need it. But if your use case requires data sovereignty, EU compliance, or offline deployment? Claude is a non-starter. Full stop. No negotiation.

Llama 4: The "Free" Option That Has Fine Print

Meta dropped Llama 4 in early 2026 and the internet exploded. Two models released:

Scout — 17B active params (16 experts), 10M context window. Fits on a single H100.
Maverick — 17B active params (128 experts). 400B total params. The flagship.

The 10 million token context window on Scout is genuinely staggering. Nothing else touches it. If you need to feed an entire codebase, years of logs, or a library of documents into a single context — Scout is the only realistic option today.

Maverick is positioned as a generalist, and for everyday writing, analysis, and conversation? It's good enough that the quality gap versus paid models often doesn't justify the cost.

But here's what doesn't get talked about:

The benchmark gaming incident. In April 2025, Meta submitted a variant called "Llama-4-Maverick-03-26-Experimental" to LMArena. It topped the leaderboard. The public release performs noticeably worse. LMSYS later acknowledged the variant wasn't labeled clearly. Meta's VP denied training on test sets. The AI community read it as benchmark gaming regardless. Until that trust is rebuilt, take any single LMArena number for Llama 4 with healthy skepticism.

The license isn't what you think. It looks open. It isn't OSI-certified open source. There's a 700M MAU clause — if your service exceeds 700 million monthly active users, you need a separate Meta license. For most devs that's irrelevant. But it also means you can't legally call it Apache or MIT. Attribution requirements exist on derivatives. Enterprise legal teams in regulated industries will flag this.

EU multimodal restriction. Vision is unavailable for EU-domiciled licensees. Hard block.

Hardware reality. Llama 4 Scout needs 24GB VRAM minimum even quantized. Gemma 4 E4B runs on 6-8GB. If you're on a laptop or consumer GPU, this comparison basically ends here.

Llama 4 on coding specifically? It's competitive but not dominant. If your primary workload is code generation or agentic refactoring, it's not the strongest open-weight choice in 2026.

The Comparison Nobody Actually Makes

Let me put this plainly, because most posts won't:

The real trade-off isn't quality. It's the question of: *who controls the model?*

What You Need	Best Pick
Highest raw reasoning quality	Claude Opus 4.7
Best local deployment, low VRAM	Gemma 4 E4B
Coding on a budget	Gemma 4 31B locally, or Claude Sonnet 4.6 via API
10M+ token context	Llama 4 Scout
Full data sovereignty	Gemma 4 (Apache 2.0, no restrictions)
Commercial use, no legal headaches	Gemma 4 (Apache 2.0 beats Llama's custom license)
Privacy-first, runs on a phone	Gemma 4 E2B
Agentic workflows, tool use	Gemma 4 31B (86.4% on τ2-bench) or Claude Sonnet 4.6
You're in the EU with vision needs	Not Llama 4
You need fine-tuning freedom	Gemma 4 or Llama 4 (not Claude)

Where Gemma 4 Actually Wins the Argument

The thing that keeps pulling me back to Gemma 4 isn't the benchmark numbers. It's the combination of things nobody else is offering together:

Edge-to-server coverage under one license. E2B runs on a Raspberry Pi at ~48 tokens per second on a ROG Phone 9 Pro. The 31B Dense runs on a workstation. The 26B MoE runs on a single A100. One model family. One license. One mental model for your entire stack.

The Apache 2.0 shift is a big deal. Earlier Gemma releases had custom licenses that enterprise legal teams routinely flagged as ambiguous. Apache 2.0 means: modify it, fine-tune it, deploy it commercially, redistribute derivatives — no royalties, no MAU limits, no acceptable use policy headaches. In 2026, as companies build always-on AI agents that process customer data continuously, the licensing terms of the underlying model are a strategic decision. Gemma 4 made that decision easy.

Multimodal natively, not bolted on. Text, image, video, audio — not as separate pipeline steps, but as native capabilities built from the Gemini 3 foundation. The smaller models (E2B, E4B) support video and audio. The larger models handle all modalities. This matters for real applications, not benchmark demos.

The reasoning jump is real. When Gemma 4 "thinks," it can produce 4,000+ tokens of reasoning before committing to an answer. The Codeforces ELO of 2,150 puts it at expert programmer level — locally, on your GPU, free.

The Honest Verdict

If I had to give you one paragraph:

Use Claude when you need the absolute ceiling on reasoning and you're okay with API costs, black-box architecture, and no local option. Sonnet 4.6 is the value play; Opus 4.7 is for the problems that genuinely require the best thing available.

Use Llama 4 Scout when you need the 10M token context window and you have the hardware for it. For everything else, its coding performance lags and the licensing is messier than it looks.

Use Gemma 4 when you want the freedom to actually own your AI stack. Run it on a phone for edge apps, a consumer GPU for development, a workstation for production — all with the same model family, the same license, the same mental model. The performance is now genuinely competitive at frontier level. The agentic tool use numbers in 2026 suggest it's not just catching up; in specific areas, it's already leading.

The era of "open source AI is just good enough to tinker with" is over.

Gemma 4 31B sitting at #3 on Arena AI, outscoring models with 20x the parameter count, running on hardware you already own, under a license that puts zero friction between you and shipping — that's not a compromise. That's just the better option for most use cases.

The question isn't "which model is best" anymore.

The question is: which model fits the kind of developer you want to be?

If your answer involves ownership, privacy, cost control, and the freedom to deploy wherever you want — the answer in 2026 is becoming increasingly obvious.

References:

You can find me across the web here:

✍️ Read more on Medium: @syedahmershah
💬 Join the discussion on DEV.to: @syedahmershah
🧠 Deep dives on Hashnode: @syedahmershah
💻 Check my code on GitHub: @ahmershahdev
🔗 Connect professionally on LinkedIn: Syed Ahmer Shah
🧭 All my links in one place on Beacons: Syed Ahmer Shah
🌐 Visit my Portfolio Website: ahmershah.dev