DEV Community: Syed Ahmer Shah

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

I Gave Hermes Agent 5 Impossible Tasks

Syed Ahmer Shah — Sat, 16 May 2026 08:34:50 +0000

This is a submission for the Hermes Agent Challenge

Let me be honest with you before we start.

I went into this expecting to write a clean "look how cool this AI is" post. You know the type. Polished. Slightly breathless. Ends with "the future is here."

That is not what happened.

What happened was messier, more interesting, and honestly kind of unsettling. So let me just walk you through it.

First — What Even Is Hermes Agent?

Because when I first heard the name I thought it was another LangChain wrapper with a good logo. It's not.

Hermes Agent is an open-source autonomous AI agent framework built by Nous Research, released in February 2026 under the MIT license. In roughly three months it crossed 100,000+ GitHub stars (Repository) — one of the fastest-growing open-source AI projects ever. That number alone made me pay attention.

But here's what actually makes it different from everything else out there right now.

Most AI tools you use today are stateless. You open a chat, you ask something, you close it. Tomorrow you come back and it remembers nothing. It's Groundhog Day but for your productivity.

Hermes doesn't work like that.

Hermes lives on your server — a $5 VPS, your laptop, a serverless backend, whatever you have. It runs persistently. It builds a three-layer memory system as it works: short-term conversation context, medium-term session summaries, long-term skill documents that capture how it solved specific problems. It doesn't just complete tasks. It learns from completing them.

The core mechanism behind this is called GEPA — an ICLR 2026 Oral-accepted self-improvement loop. Every time the agent completes roughly 15 tasks, it reviews its own performance, identifies patterns, and writes new Skill Documents. Agents with 20+ self-generated skills complete similar future tasks 40% faster than fresh instances. That's not a marketing claim. That's a benchmarked number from TokenMix.ai independent testing.

It supports 200+ LLMs through OpenRouter. It connects to Telegram, Discord, Slack, WhatsApp, Signal, and your terminal from a single gateway. And all your data — memories, skills, conversation history — lives in a local SQLite database on your own machine. No telemetry. No cloud lock-in.

In other words: it's the first agent that actually compounds.

Now. Let's talk about what happened when I put it through five tasks designed to break it.

Task 1: Aggregate Real-Time Data From Multiple Sources Simultaneously

The task: Pull today's top 5 tech news stories, summarize each one in under 50 words, rank them by relevance to full-stack developers, and format it as a clean daily briefing. Do it automatically every morning at 8am.

Why it's "impossible": Multi-source aggregation + LLM summarization + relevance ranking + automated scheduling is at least 3 separate tools working in sync. Most agent setups fall apart coordinating even two.

What actually happened:

It worked. And that was the first moment I got that slightly uncomfortable feeling.

The cron scheduling part especially. In Hermes, you set scheduled tasks in natural language — "every morning at 8am, pull tech news and brief me" — and it handles the cron job internally. No YAML. No crontab entries. You just describe what you want and it figures out the execution.

The ranking was interesting. It didn't just sort by publish time. It actually weighted results based on the tools and frameworks mentioned — things like Next.js, Supabase, TypeScript, Rust were flagged as relevant. Things like enterprise SaaS funding rounds got deprioritized. I did not explicitly tell it to do this. It inferred developer relevance from the task context.

Is that "intelligence"? I genuinely don't know. But it saved me from reading a funding article for a B2B CRM no one cares about.

Verdict: Passed. The daily briefing has been running for a week now. It's genuinely useful.

Task 2: Automate a Multi-Step Development Workflow End-to-End

The task: Given a GitHub repository URL, do all of the following without me touching anything: read the README, identify what the project does, write a structured code review checklist based on the tech stack detected, and push a summary as a GitHub issue.

Why it's "impossible": This requires reading external files, code comprehension, structured output generation, and writing back to a third-party service. That's four distinct operations with failure points at each handoff.

What actually happened:

Two out of four steps were clean. Reading the README and detecting the tech stack — solid. It correctly identified a Next.js + Supabase + Tailwind project just from the README and package.json reference.

The code review checklist was decent but generic. It knew the stack but the checklist read like it was pulled from a "React best practices" article from 2023. Not wrong. Just not deep. There was nothing about Supabase RLS policies, nothing about edge function cold starts, nothing stack-specific that a senior dev would actually flag.

The GitHub issue push worked when given the right token permissions. When I gave it an insufficient-scope token, it failed silently instead of telling me what scope it needed. That was annoying.

Verdict: Partially passed. The automation scaffolding works. The depth of reasoning is shallow on complex domain knowledge. This is a real limitation and I'd rather be straight about it than pretend otherwise.

Task 3: Make a Decision Under Complexity and Uncertainty

The task: I gave it a genuine decision I've been sitting on — choosing between two different backend architectures for a side project (Supabase-first serverless vs a dedicated Node/Express server + PostgreSQL). I gave it my constraints: solo developer, limited time, need for auth + realtime + storage, cost-sensitive, deployed on Vercel. I asked it to make a recommendation with reasoning.

Why it's "impossible": Real decisions have tradeoffs, missing information, and no clean right answer. I wanted to see if it would reason through ambiguity or just give me a confident-sounding nothing answer.

What actually happened:

This is the one that genuinely surprised me.

It didn't just recommend one option. It built a decision matrix. It listed factors I hadn't mentioned — like "as a solo developer, onboarding cognitive load matters; Supabase's managed auth reduces the number of systems you need to reason about under deadline pressure." It flagged that Node/Express gives more control but that control has a cost when you're the only one maintaining it at 2am.

The recommendation it landed on was Supabase-first with a specific caveat: avoid complex business logic in Edge Functions because cold starts compound when you chain them. Keep the critical path simple.

That caveat is correct. And I hadn't mentioned Edge Functions once.

I'm still not sure what to make of that.

Verdict: Passed. This is the task I expected it to fail worst at. It didn't.

Task 4: Self-Generate a New Skill From a Novel Workflow

The task: Ask it to do something it has never done before — specifically, analyze a CSV of student grade data, identify students at risk of failing (below certain thresholds across multiple subjects), and generate a personalized intervention note for each one. Then turn that workflow into a reusable skill it can apply to future CSV uploads automatically.

Why it's "impossible": Skill self-generation is the core claim of Hermes. I wanted to stress-test it against a workflow that doesn't exist in its default 118-skill library.

What actually happened:

The CSV analysis worked fine. Basic pandas-style operations under the hood, nothing shocking there.

The "personalized" intervention notes were... okay. They were structurally correct — each note addressed the specific subjects where the student was below threshold. But they were cold. "Student X is showing below-average performance in Mathematics and Science. Recommend additional support sessions." That's technically an intervention note. It's also the kind of note a tired administrator writes at the end of a long Friday. No teacher would actually send it.

The skill generation part, though? That worked exactly as advertised. After completing the task, it wrote a Skill Document called something like "at-risk-student-csv-analyzer" and indexed it. When I uploaded a second, different CSV the next day and asked it to "do the analysis thing you did before," it retrieved the skill, adapted it to the new column structure, and ran the workflow without needing my re-explanation.

That's the compounding effect in real action. And it's genuinely different from anything I've used before.

Verdict: Passed on infrastructure, mixed on quality. The skill loop is real. The output depth depends on how much context you give upfront.

Task 5: Handle a Multi-Turn Workflow That Changes Midway

The task: Start a content planning workflow. Halfway through — after it's already begun — change the brief completely. Go from "write a content calendar for a developer tools startup" to "actually, this is for a personal finance app, let me redo the audience." Watch whether it gracefully adapts or collapses.

Why it's "impossible": Mid-stream context shifts break most AI tools. They either ignore the update and keep going, or reset completely and lose all prior progress.

What actually happened:

It adapted. Mostly.

When I interrupted and changed the target audience, it acknowledged the shift, flagged which parts of what it had already generated were still salvageable (basic calendar structure, posting cadence, format) and which parts needed regeneration (topic ideas, tone, example posts). It didn't start over from scratch. It didn't ignore me. It basically said, in its way: okay, here's what I'm keeping, here's what I'm rebuilding, confirm?

That's a more sophisticated response than most human collaboration tools give you.

The place it slipped: one of the regenerated topic ideas still referenced developer tools in the framing. Subtle. If I hadn't been watching for it I'd have missed it. But it's the kind of context bleed that shows the memory management isn't perfect yet.

Verdict: Passed with caveats. The recovery behavior is impressive. The context bleed is real and worth watching in production.

So What's the Actual Verdict on Hermes Agent?

Here's the honest summary.

Hermes Agent is the most interesting open-source agent framework of 2026 — not because it's perfect, but because its architecture is the right bet. The self-improving skill loop, the three-layer memory, the GEPA mechanism — these are the right answers to the right problems. Stateless AI is a ceiling. Compounding AI is a direction.

The gaps are real though. Output quality is heavily context-dependent. The shallow-domain problem on complex workflows (the code review checklist, the cold intervention notes) is a real limitation. Silent failures on misconfiguration — like the GitHub token scope issue — need better error communication.

But it's MIT licensed. It runs on a $5 VPS. Your data stays on your machine. And it's actively evolving at a release cadence that looks less like a hobby project and more like a well-funded lab that knows what it's building. v0.10.0 shipped 16 April 2026 with 118 skills and a closed learning loop. The pace is aggressive.

The benchmark that stuck with me: agents with 20+ self-generated skills complete similar future research tasks 40% faster than fresh instances. That is compounding intelligence in measurable form. Not philosophy. Not a demo. A number.

Is it ready for production? For solo developers and small teams building non-critical workflows — yes, today. For enterprise-grade production with audit requirements — not yet. But it's closer than anything else in the open-source space.

A Question I Can't Stop Thinking About

When the agent made that call about Supabase Edge Functions — something I never mentioned — was that reasoning, pattern matching, or just a lucky inference from my constraints?

I've been turning that over for a few days and I don't have a clean answer.

What I do know is this: the gap between "useful tool" and "autonomous collaborator" is narrowing faster than I expected. And Hermes is one of the clearest signals of that.

What would you give Hermes Agent as a fifth impossible task? Genuinely curious what breaks it in your domain. Drop it in the comments.

And if you've already been using it — what's the limitation that surprised you most? Because I suspect I've only scratched the surface of where this gets weird.

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

PHP vs Node.js & Next.js vs Angular: What to Learn

Syed Ahmer Shah — Thu, 14 May 2026 16:05:01 +0000

You know the feeling. Three browser tabs open. Reddit thread from 2019. A YouTube video titled "PHP is DEAD in 2026". Another one titled "Why PHP Will Never Die."

Meanwhile — zero lines of code written.

Here's the truth nobody puts in a headline: the framework debate is a distraction. Let me save you the months I lost.

The Short Version of a Long History

PHP was born from a guy tracking visitors on his homepage in 1994. Accidental. Messy. But it stuck — and today powers 43% of the web. WordPress. Laravel. WooCommerce. It's not glamorous. It pays.

Node.js arrived in 2009 with one bold idea: stop making threads wait. Handle I/O like a browser handles clicks — non-blocking. Suddenly JavaScript ran on servers. One language, everywhere. Developers loved it.

Next.js gave React a backbone. Server rendering, file-based routing, APIs — all in one box. Messy in v13, solid in v15. It's where the React world lives now.

Angular is the enterprise workhorse. Built by Google. Opinionated. Comes with everything. Banks and governments swear by it. Indie devs avoid it.

What Should YOU Actually Learn?

Want freelance income fast? → PHP + Laravel. The WordPress market alone is enormous, the learning curve is kind, and you'll be billing clients before most "modern stack" beginners finish their setup.

Want a product company job? → React + Next.js. Full stop. It dominates hiring.

Love real-time apps? → Node.js. Chat, sockets, streaming — this is its home turf.

Targeting enterprise/corporate? → Angular. The jobs pay well and last long.

The Thing Nobody Tells You

The technology matters far less than you think in year one.

A developer who built real things in PHP will learn Node in weeks. A developer who shipped with React will get Angular faster than any bootcamp teaches it.

Concepts transfer. Confusion is temporary. Paralysis is permanent.

Pick something. Build something ugly. Deploy it. Break it. Fix it.

That's still how this works in 2026 — and probably always will be.

What stack did you start with? Tell me in the comments 👇

Connect With the Author

Platform	Link
✍️ Medium	@syedahmershah
💬 Dev.to	@syedahmershah
🧠 Hashnode	@syedahmershah
💻 GitHub	@ahmershahdev
🔗 LinkedIn	Syed Ahmer Shah
🧭 Beacons	Syed Ahmer Shah
🌐 Portfolio	ahmershah.dev

React is Overkill: Why Python + HTMX is Dominating in 2026

Syed Ahmer Shah — Wed, 13 May 2026 09:28:52 +0000

Last year I spent forty minutes setting up a React project for an internal admin dashboard. Just the boilerplate. Vite config, ESLint setup, Tailwind integration, React Router, TanStack Query because someone on Twitter said it was the right way to handle server state now. I hadn't written a single line of actual application logic yet and I already had twelve files open.

The dashboard needed to list records from a database, let you filter them, and update a status field. Three things. That's it.

I've been thinking about that moment a lot since then. Not because React was wrong exactly, but because the whole experience made me ask a question I probably should've asked earlier: what problem am I actually solving, and does my stack match that problem?

HTMX has been around since 2020, technically. Carson Gross built it on older ideas — intercooler.js, hypermedia, REST as it was supposed to work. But it's only in the last eighteen months or so that it's started showing up seriously in production codebases beyond hobby projects and blog posts. The HTMX GitHub repo crossed 40k stars. The State of JS 2024 survey showed a weird but real pattern: developers were increasingly marking "would not use again" next to React while usage stayed high. People are still using it, but the love is clearly cooling at the edges.

What HTMX actually does is conceptually simple enough to explain in one sentence: it lets HTML elements make HTTP requests and swap parts of the page based on the response. That's it. No virtual DOM, no component lifecycle, no client-side routing, no state management library to argue about. You write hx-get="/search" on an input and hx-trigger="keyup changed delay:300ms" and the results div updates. The HTML is the state. The server renders the HTML. You're done.

For a lot of use cases — the boring ones, the productive ones — that's genuinely enough.

Where Python comes in is almost too natural. Django and FastAPI are both excellent at rendering HTML fragments quickly. Django's template engine is underrated. FastAPI with Jinja2 is fast enough that you genuinely don't need to think about it for most traffic levels a small team will ever hit. You return an HTML fragment from your endpoint, HTMX drops it into the DOM, and the user sees something happen. No JSON serialization, no client-side deserialization, no React re-render cycle. The server does what servers are supposed to do: handle the data, decide what the UI should look like, send it down.

Miguel Grinberg wrote a good piece about this pattern in his Flask-HTMX tutorials and the core insight is something almost boring: web applications were server-rendered for a decade and a half and it worked fine. The SPA era solved real problems — but it also introduced an enormous amount of accidental complexity for cases that didn't need it.

I want to be fair here because the React discourse tends to go off the rails. React is not bad. React is very good at what it was built for. When you need rich client-side interactivity — collaborative editing, complex real-time interfaces, something like Figma or Notion — the component model, unidirectional data flow, and the client-side rendering approach make sense. The ecosystem is genuinely impressive. Next.js solved real deployment problems. React Server Components, once you get past the initial confusion about what they even are, are a real architectural idea worth understanding.

But most applications aren't Figma. Most applications are CRUD with some filtering. Most internal tools are forms, tables, and dashboards. Most freelance projects are e-commerce sites and appointment booking systems. And for all of those, the React stack asks you to carry a lot of weight that delivers nothing to your end users.

The JavaScript fatigue conversation has been happening for a long time — this 2016 post by Jose Aguinaga was funny eight years ago because it was accurate. The irony is it's somehow still accurate in 2026, just with different library names. Bundlers changed. State management evolved from Redux to Zustand to Jotai to whatever came after that. Server components got added to React in a way that made half the existing tutorials wrong. The amount of meta-knowledge required to set up a React project correctly — not even write application logic, just set it up — is genuinely unreasonable for a lot of teams.

Here's where I want to talk about something that doesn't get said enough in these discussions, which is the South Asian developer context specifically.

A lot of the conversation about frontend frameworks happens in the frame of a US/European developer with fast internet, a high-spec machine, and a client who doesn't care about performance as long as it looks modern. That context shapes the defaults. When Vercel or Netlify blog posts talk about bundle sizes and Core Web Vitals, they're often writing for an audience where a 300kb JS bundle is a minor annoyance. In Pakistan — Karachi, Lahore, Hyderabad, smaller cities — that's not a minor annoyance. Users on mobile data in Tier-2 cities are waiting for your SPA to hydrate and it shows.

Freelancers here mostly work on Upwork and Fiverr. A lot of the gigs are admin dashboards for small businesses, HR tools for local companies, basic inventory management systems. The budgets are not large. The timelines are tight. When a Pakistani developer can ship a fully functional admin panel with Django + HTMX in two or three days because there's no API layer to design, no client-side state to manage, no authentication token flow to wire up separately — that is a real, material productivity advantage.

I've talked to a few people doing final year university projects at HITEC, COMSATS, and similar universities around Sindh and Punjab. The React stack honestly overwhelms students who are still figuring out async/await. Watching someone understand HTMX in an afternoon and ship something that works by evening — that's not a small thing. There's something to be said for a technology that removes barriers to entry without sacrificing capability.

The local SaaS mindset here is also different. When someone in Karachi is building their first B2B software product, they're thinking about getting to paying customers fast, not about whether their architecture will scale to ten million users. Python with Django gives you ORM, admin panel, authentication, and a templating system in one package. Adding HTMX on top means you get reactive UI without the separate frontend deployment, the CORS configuration, the API versioning headache. For a solo founder or a two-person team, that simplicity is worth a lot.

The cases where I'd genuinely choose Python + HTMX are becoming clearer to me over time.

Internal tools are the obvious one. Any time a company needs a dashboard that only ten people use, building a full React SPA is an organizational tax, not a feature. The JavaScript bundle has to be maintained, the frontend dev has to know the API contract, someone has to manage the deployment pipeline. With server-rendered HTML and HTMX, it's just one application. One deploy. The developer who built the data model builds the UI. That's not unsophisticated, that's economical.

Small startups at the idea validation stage. If you're not sure whether your product has legs yet, spending three months building a polished React frontend before you talk to users is a bet you probably shouldn't be making. Django + HTMX lets a Python developer ship something users can click through in days. That's not a forever architecture, but it doesn't need to be.

Content-heavy sites with some interactivity. A blog that has a comment section, a search bar, a newsletter signup. HTMX handles those interactions cleanly. You're not pulling in a frontend framework for three interactive elements.

Where it gets harder is when you actually need rich client-side state. An application where the UI is the product — design tools, real-time collaboration, complex data visualization with local filtering and sorting that needs to feel instant. React and its ecosystem are genuinely better there. That's not a grudging admission, it's just accurate.

There's also the team dynamic angle that people underplay. A lot of teams have backend developers who know Python well and frontend skills that are functional but not deep. The React ecosystem requires either genuine frontend expertise or a willingness to do a lot of cargo-culting patterns from Stack Overflow. Server-side rendering with HTMX plays to Python developers' strengths and doesn't require a separate specialist. In markets where fullstack Python devs are easier to find and cheaper to hire than React developers, that matters organizationally.

Adam Johnson's work on Django + HTMX patterns and the HTMX documentation's own essays on hypermedia are worth reading if you want to understand the philosophy here rather than just the mechanics. The argument isn't "SPAs were a mistake." The argument is closer to: the web platform extended HTML to support interactivity through JavaScript, but maybe it should have extended HTML itself instead. HTMX is a bet on that idea. It's a small, focused library — around 14kb unminified — and it's deliberately unambitious in scope. It does one thing and expects HTML and HTTP to do the rest.

I keep coming back to something that's hard to articulate but feels important. There's a certain developer experience that React optimizes for — the experience of a developer inside the component, thinking in terms of state and props and effects. It's a powerful mental model once you internalize it. But it's a mental model you have to fully commit to, and it pulls a lot of complexity in with it.

HTMX optimizes for a different experience — the experience of building something where the server is in control and the browser is just displaying what the server says. That's a much older model. It maps onto how people actually think about data and business logic, which lives on the server. For a lot of developers, particularly those whose real expertise is in data, backend systems, and APIs, that model is more natural and requires less context-switching.

Neither of these is objectively better. They're suited to different problems, different teams, and different moments in a product's life.

What feels true in 2026, though, is that HTMX has earned its place in the conversation as a serious option for production work. It's not a protest against modern tooling. It's not nostalgia for PHP spaghetti. It's a genuine approach to building web interfaces that works well for a specific, large, and underserved category of application. The category that most of us are actually building most of the time.

I rebuilt that admin dashboard eventually. Three days with FastAPI, Jinja2 templates, and HTMX. No build step. No node_modules folder the size of a small country. Every developer on the backend team could read and modify the templates without learning a new paradigm.

It's still running. Nobody has asked me to rewrite it in React.

If you want to dig into the actual mechanics, the HTMX documentation is genuinely well-written and surprisingly short. For the Python side, full-stack-fastapi-template is a good starting point even if you swap out the React frontend for Jinja2. And this talk by Carson Gross at DjangoCon 2022 is the most coherent thirty minutes you'll spend understanding what HTMX is actually trying to do.

Connect With the Author

Platform	Link
✍️ Medium	@syedahmershah
💬 Dev.to	@syedahmershah
🧠 Hashnode	@syedahmershah
💻 GitHub	@ahmershahdev
🔗 LinkedIn	Syed Ahmer Shah
🧭 Beacons	Syed Ahmer Shah
🌐 Portfolio	ahmershah.dev

PHP vs Node.js (2026): I Benchmarked Both — Here's What Surprised Me

Syed Ahmer Shah — Sun, 10 May 2026 11:37:58 +0000

There is a conversation that has been going on in backend development circles for over a decade now, and it refuses to die. PHP or Node.js? Which one should you use? Which one is faster? Which one has a future?

I spent the last several weeks setting up identical environments, running real benchmarks, building small but representative applications in both, and reading through a significant amount of documentation, community data, and developer surveys. I went in with assumptions. Most of them were wrong.

This is not a fan piece. I have no allegiance to either camp. This is what I actually found.

Why These Two?
The Origin Stories
The State of Both in 2026
Benchmark Setup
Benchmark Results
Code Comparison
What Real Developers Say
Pros and Cons
Use Case Guide
What the Numbers Actually Mean
References
The Verdict

Why These Two?

PHP and Node.js do not look like obvious competitors on paper. PHP is a language with its own runtime. Node.js is a JavaScript runtime. But in practice, both are used to build web backends, APIs, and server-rendered applications — which is why they end up in the same conversation constantly.

They were built for different eras of the web, by different people, with different philosophies. Understanding that context changes how you read the benchmarks.

The Origin Stories

PHP — Built to Solve a Real Problem in 1994

Rasmus Lerdorf did not set out to create a programming language. He wrote a set of Common Gateway Interface (CGI) binaries in C to track visits to his online resume. He called it "Personal Home Page Tools." That is the PHP in PHP.

The language grew organically. It was extended, contributed to, and eventually became one of the most deployed server-side languages in the world — not because it won some technical competition, but because it was available, easy to learn, and did the job at a time when the web was exploding and developers needed something that worked.

Milestone	Year	Significance
PHP Tools (CGI)	1994	Rasmus tracks his resume visits — PHP is born
PHP 3	1997	Rewritten from scratch, public adoption begins
PHP 4	2000	Zend Engine introduced, WordPress era begins
PHP 5	2004	OOP support, PDO, major language maturation
PHP 7	2015	Near 2x speed over PHP 5, scalar type hints
PHP 8.0	2020	JIT compiler, named arguments, attributes, union types
PHP 8.4	2024	Property hooks, asymmetric visibility, improved array unpacking

Its model was simple: a user makes a request, PHP executes a script, the script talks to a database, a response is sent back. New request, new execution. Stateless, predictable, widely understood.

The criticism came later. Function naming was not standardized. Error handling varied. The global state model caused problems at scale. The reputation suffered.

But PHP did not sit still. PHP 7 nearly doubled speed compared to PHP 5. PHP 8.0 introduced JIT compilation. PHP 8.3 and 8.4 continued tightening the language significantly. In 2026, PHP is a substantially different language from what most of its critics remember.

Node.js — Built to Fix What Ryan Dahl Thought Was Broken

Ryan Dahl introduced Node.js at JSConf EU in 2009 with a presentation that started by criticizing the way Apache handled concurrent connections. His argument was direct: traditional servers spawn a new thread per connection, threads are expensive, and blocking I/O makes the problem worse.

Milestone	Year	Significance
Node.js 0.1	2009	Ryan Dahl introduces it at JSConf EU
npm launched	2010	Package ecosystem begins to grow
Node.js Foundation	2015	Corporate backing, io.js merged back
Node.js 6 LTS	2016	ES6 support, production stability established
Node.js 12	2019	V8 7.4, async/await goes mainstream
Node.js 18 LTS	2022	Native fetch API, built-in test runner
Node.js 22 LTS	2024	Current active LTS, significant performance improvements

Node.js was built on Google's V8 engine and a non-blocking, event-driven I/O model. Instead of waiting for a database query to return before doing anything else, Node.js could register a callback and move on — handling thousands of concurrent connections on a single thread without the overhead of thread management.

It landed at exactly the right moment. JavaScript was already everywhere on the front end. Developers could suddenly use the same language on both sides of the stack. The npm ecosystem exploded. Real-time applications — chat apps, live dashboards, collaborative tools — became dramatically easier to build.

Node.js was not trying to replace PHP. It was solving a different problem: high-concurrency, real-time, I/O-heavy workloads. The fact that it could also serve web pages and APIs just meant it ended up in the same comparison over and over again.

The State of Both in 2026

PHP Today

Factor	Detail
Current version	PHP 8.4 (stable), PHP 8.5 in active development
Primary framework	Laravel 11 — mature, full-featured, excellent developer experience
Runtime innovation	FrankenPHP — high-performance server in Go, enables persistent worker mode
Other frameworks	Symfony, Slim, CodeIgniter, Laminas
Market share	~18.2% of developers (Stack Overflow Developer Survey 2025)
Web dominance	WordPress alone powers 43%+ of all websites globally

Node.js Today

Factor	Detail
Current version	Node.js 22.x LTS, Node.js 24 in active development
Primary frameworks	Fastify, NestJS, Hono, Express.js
Runtime competition	Bun and Deno have taken real market share, though Node.js remains dominant
Package registry	npm holds over 2.5 million packages
Language default	TypeScript is now the default in most production Node.js codebases
Corporate backing	Strong investment from Microsoft, Vercel, Netlify, and others

Benchmark Setup

I ran all tests on the same machine with the same network conditions. Everything was containerized via Docker to eliminate environment differences.

Hardware

OS:       Ubuntu 22.04 LTS
CPU:      4 vCPUs
RAM:      8 GB
Storage:  SSD
Network:  Loopback (localhost)

Load Testing Tools

Primary:    wrk -t4 -c400 -d30s
Secondary:  ab -n 10000 -c 200

Each test was run five times. The highest and lowest results were discarded. The three middle results were averaged.

Stacks Tested

Stack	Runtime	Web Layer	Database Driver	Configuration
PHP	PHP 8.4-FPM	Nginx	PDO	OPcache ON, realpath_cache_size=4096K
Node.js	Node.js 22 LTS	Fastify 4.x	pg (node-postgres)	Default V8 flags

Test Scenarios

#	Test	What It Measures
1	Hello World	Pure runtime and framework overhead
2	JSON Serialization	Encoding a 100-field object
3	Database Read	SELECT 50 rows from PostgreSQL
4	Database Write	INSERT + RETURNING new row ID
5	CPU-Intensive Task	Fibonacci(35) computed synchronously per request

Benchmark Results

Test 1 — Hello World (Pure Throughput)

wrk -t4 -c400 -d30s http://localhost/hello

Stack	Requests/sec	Avg Latency	P99 Latency
PHP 8.4-FPM	12,400	32ms	89ms
PHP 8.4 + FrankenPHP (worker)	29,100	13ms	—
Node.js 22 + Fastify	38,200	10ms	31ms

Node.js was significantly faster in its standard configuration. PHP-FPM spawns worker processes with initialization overhead per request. Node.js runs as a persistent process.

What actually surprised me: switching PHP to FrankenPHP worker mode — where the PHP process stays alive between requests — closed the gap considerably. Not equal, but not the landslide most articles suggest.

Test 2 — JSON Serialization

Stack	Requests/sec	Avg Latency
PHP 8.4-FPM	9,800	40ms
Node.js 22	31,500	12ms

Node.js wins. JavaScript's JSON handling is native to V8. PHP's json_encode() is fast, but the per-request process startup adds up.

Test 3 — Database Read (50 rows, PostgreSQL)

Stack	Requests/sec	Avg Latency	P99 Latency
PHP 8.4-FPM	4,200	95ms	210ms
Node.js 22	5,800	68ms	145ms

Node.js is faster, but the gap narrows dramatically. The database is the bottleneck. Both stacks spend most of their time waiting on PostgreSQL, not executing application code. This test is far more representative of real web applications than the Hello World test.

Test 4 — Database Write (INSERT + RETURNING)

Stack	Requests/sec	Avg Latency
PHP 8.4-FPM	3,100	128ms
Node.js 22	4,400	90ms

Same pattern as Test 3. Node.js ahead, but both are constrained by I/O, not the language runtime.

Test 5 — CPU-Intensive Task (Fibonacci 35)

This is the one that will change how you think about Node.js.

Stack	Requests/sec	Avg Latency	P99 Latency
PHP 8.4-FPM	890	1,120ms	1,340ms
Node.js 22	210	4,750ms	9,200ms

PHP won — and it was not close.

This reveals the most important architectural truth about Node.js: it has a single-threaded event loop. When one request is doing heavy CPU work, every other request waits. PHP-FPM spawns multiple worker processes. A CPU-heavy request in one worker does not block any of the others.

Node.js has worker threads to address this — but you have to deliberately opt into them. Out of the box, a CPU-bound task will destroy your latency across the board.

Summary — All Tests

Test	PHP 8.4 (req/s)	Node.js 22 (req/s)	Winner
Hello World (FPM)	12,400	38,200	Node.js
Hello World (FrankenPHP)	29,100	38,200	Node.js (narrower)
JSON Serialization	9,800	31,500	Node.js
DB Read — 50 rows	4,200	5,800	Node.js
DB Write — INSERT	3,100	4,400	Node.js
CPU Task — Fibonacci(35)	890	210	PHP

Code Comparison

The same feature implemented in both stacks, side by side.

REST API Endpoint with Database Query and Cache

PHP 8.4 with Laravel

<?php

use App\Models\Article;
use Illuminate\Support\Facades\Cache;

Route::get('/articles/{id}', function (int $id) {
    $article = Cache::remember("article:{$id}", 300, function () use ($id) {
        return Article::with('author', 'tags')
            ->findOrFail($id);
    });

    return response()->json([
        'data'   => $article,
        'cached' => Cache::has("article:{$id}"),
    ]);
});

Node.js with Fastify + TypeScript

import { FastifyInstance } from 'fastify';
import { pool } from '../db';
import { redis } from '../cache';

export async function articleRoutes(fastify: FastifyInstance) {
  fastify.get<{ Params: { id: string } }>('/articles/:id', async (request, reply) => {
    const { id } = request.params;
    const cacheKey = `article:${id}`;

    const cached = await redis.get(cacheKey);
    if (cached) {
      return reply.send({ data: JSON.parse(cached), cached: true });
    }

    const result = await pool.query(
      `SELECT a.*, u.name AS author_name
       FROM articles a
       JOIN users u ON a.author_id = u.id
       WHERE a.id = $1`,
      [id]
    );

    if (!result.rows[0]) {
      return reply.status(404).send({ error: 'Not found' });
    }

    await redis.setex(cacheKey, 300, JSON.stringify(result.rows[0]));
    return reply.send({ data: result.rows[0], cached: false });
  });
}

The PHP version is more concise because Laravel's Eloquent ORM absorbs the boilerplate. The Node.js version is more explicit — you see exactly what queries run and what hits the cache. Both are valid depending on your team's preferences.

Handling Concurrent Async Operations

PHP 8.4 — Guzzle with concurrent pooled requests

<?php

use GuzzleHttp\Client;
use GuzzleHttp\Pool;
use GuzzleHttp\Psr7\Request;

$client = new Client();

$requests = function () {
    yield new Request('GET', 'https://api.example.com/users');
    yield new Request('GET', 'https://api.example.com/products');
    yield new Request('GET', 'https://api.example.com/orders');
};

$pool = new Pool($client, $requests(), [
    'concurrency' => 3,
    'fulfilled'   => function ($response, $index) {
        // handle each response
    },
]);

$pool->promise()->wait();

Node.js — native async/await with Promise.all

const [users, products, orders] = await Promise.all([
  fetch('https://api.example.com/users').then(r => r.json()),
  fetch('https://api.example.com/products').then(r => r.json()),
  fetch('https://api.example.com/orders').then(r => r.json()),
]);

This gap matters in daily development. The Node.js version is two lines. PHP requires a library, a generator function, a pool constructor, and a promise wait call. Async is not bolted onto Node.js — it is the entire foundation of it.

What Real Developers Say

"The vast majority of web applications are not performance-limited by their language runtime. They are limited by database queries, external API calls, and business logic complexity."

— Taylor Otwell, creator of Laravel

"I made some choices early in Node that I now regret. The module system, the callback model — these were harder than they needed to be."

— Ryan Dahl, creator of Node.js, from his Deno introduction (2018)

"Performance that developers cannot maintain or reason about is not actually useful performance."

— Evan You, creator of Vite and Vue.js

"Fastify's overhead is minimal. Most performance problems in Node.js applications come from userland code, not the framework."

— Matteo Collina, Node.js core contributor, co-creator of Fastify

Notice that Ryan Dahl — the person who built Node.js — publicly acknowledged its architectural regrets. That kind of self-awareness from a creator should factor into how you evaluate the runtime's design decisions.

Pros and Cons

PHP

Strengths

Strength	Why It Matters
30 years of documentation	Almost every problem has a Stack Overflow answer
Laravel framework	Best-in-class DX: Eloquent, queues, broadcasting, Horizon — batteries included
Universal shared hosting	Deploy for a few dollars a month, no DevOps knowledge required
Per-request FPM isolation	One crashed script does not bring down the entire server
Strong typing in PHP 8.x	Union types, enums, readonly properties, property hooks
CPU workload handling	Multi-worker FPM means CPU tasks in one process don't block concurrent requests
Low barrier to entry	Junior developers can onboard and contribute quickly

Weaknesses

Weakness	The Real Impact
FPM throughput ceiling	Slower than persistent-process runtimes on pure I/O benchmarks
Async is not native	Requires Swoole, ReactPHP, or FrankenPHP worker mode — not first-class support
Inconsistent standard library	`array_map`, `in_array`, `array_filter` — argument order varies, no fixing it
Perception problem	The "PHP is bad" reputation still affects hiring and architectural buy-in
Real-time limitations	WebSockets and SSE require extra infrastructure in the traditional FPM model

Node.js

Strengths

Strength	Why It Matters
Non-blocking I/O	Purpose-built for high-concurrency, I/O-heavy workloads
Massive npm ecosystem	2.5 million+ packages — there is a library for almost anything
Real-time native	WebSockets, SSE, live data pipelines — the event loop is ideal for these
TypeScript default	Large codebases are dramatically safer and easier to refactor
Full-stack JavaScript	Share types, schemas, and utilities across frontend and backend
Fastify and Hono	Framework overhead is genuinely minimal at scale
Strong corporate investment	Microsoft, Vercel, Netlify, and others fund core development actively

Weaknesses

Weakness	The Real Impact
Single-threaded event loop	CPU-bound tasks block all concurrent requests — this is an architectural constraint
Complex async error handling	Stack traces in async code are harder to read and debug than synchronous PHP
npm supply chain risk	Left-pad (2016) was a warning. Supply chain attacks on npm have increased since
Tooling overhead	TypeScript + ESLint + testing + bundler = significant configuration surface area
Memory leak risk	Long-running processes accumulate leaks that FPM's per-request model avoids
CommonJS vs ESM fragmentation	Module system debt has left many codebases in a painful, ongoing migration

Use Case Guide

Use PHP When

Scenario	Reason
Content-driven websites and CMS	WordPress, Drupal, Laravel — purpose-built with unmatched community support
SaaS products where shipping speed matters	Laravel gives you auth, queues, events, broadcasting scaffolding from day one
Small teams or less experienced developers	Simpler mental model, excellent onboarding docs, cheap shared hosting
CPU-intensive background jobs	FPM multi-worker model handles mixed workloads without blocking concurrent requests
Budget-constrained deployments	Shared PHP hosting remains one of the cheapest compute options available
E-commerce applications	Deep ecosystem (WooCommerce, Magento, Bagisto) — all PHP-native

Use Node.js When

Scenario	Reason
Real-time features	WebSockets, live notifications, collaborative editing — event loop is ideal
API gateway or thin proxy layer	Non-blocking I/O handles enormous concurrency with minimal resource usage
Microservices architecture	Fast startup, low idle memory, scales horizontally with ease
JavaScript/TypeScript-heavy teams	Share code, types, and validation logic across the full stack
Developer tools, CLIs, API clients	The npm ecosystem for tooling is exceptional and well-maintained
High-concurrency I/O without expensive infra	Hundreds of thousands of WebSocket connections on a single long-running process

What the Numbers Actually Mean

After running all the benchmarks, the honest summary is this:

For most web applications — the kind that serve pages, handle form submissions, run database queries, and send emails — the performance difference between PHP and Node.js is not your bottleneck. Your database is your bottleneck. Your external API calls are your bottleneck. The framework overhead is rounding error compared to a missing index on a frequently queried column.

This is not a dismissal of performance. It is a prioritization of it.

The benchmark where PHP was three times slower than Node.js (Hello World) will never matter in a real application, because no real application serves only a Hello World response. The benchmark where the gap narrowed to 30% (database read) is far more representative — and even then, a Redis cache collapses most of that gap entirely.

The benchmark where PHP beat Node.js by 4x (CPU task) matters a great deal if your application does image processing, PDF generation, data transformation, or complex calculations in the request path. That result should directly inform your architecture decisions.

The right question is not which runtime is faster in a benchmark. It is which ecosystem will let your team ship correct, maintainable software faster — given the specific problem you are solving.

References

Resource	Link	Why Read It
PHP 8.4 Release Notes	php.net/releases/8.4	Understand modern PHP before forming opinions on old knowledge
FrankenPHP Documentation	frankenphp.dev	Worker mode changes the PHP performance conversation entirely
Fastify Benchmarks	fastify.dev/benchmarks	Reproducible, maintained Node.js framework benchmarks
Node.js User Survey (OpenJS Foundation)	openjsf.org	Annual adoption and usage data from the foundation
Stack Overflow Developer Survey 2025	survey.stackoverflow.co/2025	Most widely cited annual developer technology survey
Ryan Dahl — Introducing Node.js (2009)	youtube.com/watch?v=ztspvPYybIY	Watch to understand what problem it was actually solving
PHP: The Right Way	phptherightway.com	Counters a significant amount of outdated PHP advice
State of JavaScript 2024	stateofjs.com/en-US/2024	Annual JavaScript ecosystem adoption and satisfaction data
Swoole Documentation	swoole.com	Async PHP without abandoning your existing framework
Matteo Collina — Node.js Performance	YouTube	Technical and rigorous, directly from a Node.js core contributor

The Verdict

I went into this expecting Node.js to win convincingly on performance and PHP to win on ecosystem maturity for web applications. I was partially right on both.

Node.js is faster in throughput benchmarks. That advantage is real and consistent. But it is smaller than conventional wisdom suggests, and it comes with a meaningful tradeoff on CPU-bound work. PHP with modern versions and FrankenPHP worker mode is no longer the slow runtime of 2012.

What surprised me most was not a benchmark result. It was realizing how rarely the benchmark result is even the right question.

Use Case	Recommendation
Real-time platform (chat, live data)	Node.js
Content platform or CMS	PHP with Laravel
SaaS product, time-to-market priority	PHP with Laravel
High-throughput I/O microservice	Node.js
CPU-intensive processing in request path	PHP — or reconsider the architecture entirely
E-commerce	PHP
Developer tooling or CLI	Node.js
Budget-constrained team	PHP

Both languages are alive. Both are actively developed. Both have communities worth being part of.

The "PHP is dead" narrative was never accurate. The "Node.js solves everything" narrative was always a sales pitch.

Use the right tool. Understand its actual tradeoffs. The verdict is not that one won — it is that the competition was never as simple as people made it sound.

All benchmarks were run on Ubuntu 22.04 LTS, 4 vCPU / 8 GB RAM, Docker containers with equivalent resource limits. PHP 8.4.1 with OPcache enabled and realpath_cache_size=4096K. Node.js 22.11.0 LTS with Fastify 4.x. PostgreSQL 16 on localhost. Five iterations per test — high and low discarded, middle three averaged.

Connect With the Author

Platform	Link
✍️ Medium	@syedahmershah
💬 Dev.to	@syedahmershah
🧠 Hashnode	@syedahmershah
💻 GitHub	@ahmershahdev
🔗 LinkedIn	Syed Ahmer Shah
🧭 Beacons	Syed Ahmer Shah
🌐 Portfolio	ahmershah.dev

Gemma 4: Why Local AI is Finally Becoming Personal

Syed Ahmer Shah — Thu, 07 May 2026 09:46:59 +0000

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

The "Before" and "After"

We’ve all been there. You want to integrate AI into a project—maybe a mini e-commerce site like my Zovita project or a custom SaaS—but you’re stuck. You’re either selling your soul to expensive API tokens or dealing with "local" models that are so slow they make a dial-up connection look like fiber optics.

Before Gemma 4: Local AI was a toy. You’d run a 7B model, wait thirty seconds for a "Hello World," and watch your laptop turn into a space heater.

After Gemma 4: We’re looking at native multimodal capabilities and a 128K context window that actually fits on consumer hardware. This isn't just a minor update; it’s a shift in power.

Three Flavors, One Goal

Google didn't just drop one model and walk away. They gave us a toolkit. If you’re building, you need to know which hammer to grab.

The Edge Fighters (2B & 4B): These are built for the stuff in your pocket. If you’re a mobile dev or working with low-power edge devices (hello, Raspberry Pi 5), this is your lane. It’s small enough to be fast but smart enough to handle basic logic without calling home to a server.
The Powerhouse (31B Dense): This is the bridge. It’s for when you have a decent GPU and need "server-grade" intelligence without the server-grade bill. It handles complex reasoning where the smaller models start to hallucinate.
The Speed Demon (26B MoE): Mixture-of-Experts. It’s highly efficient. If you need high-throughput—meaning you’re processing a lot of data quickly—this architecture is designed to give you advanced reasoning without the heavy compute cost of a fully dense model.

The 128K Context Window: Why You Should Care

If you’re a developer, the context window is your "working memory." Most local models used to give you a couple of thousand tokens. Gemma 4 gives you 128,000.

What does that look like in the real world? It means I can feed it an entire folder of PHP controllers, my CSS files, and my database schema, and ask: "Where is the logic breaking in my checkout flow?"

It doesn't just see the snippet; it sees the system.

// Example: Using Gemma 4 via a local endpoint to audit a project

const analyzeCodebase = async (files) => {
  const prompt = `Review these files for security flaws: ${files}`;

  // Gemma 4 handles the 128k context here easily
  const response = await gemmaLocal.complete({
    model: "gemma-4-31b",
    prompt: prompt,
    context_window: 128000 
  });
  console.log(response.analysis);
};

How We Actually Use This

We don't build just for the sake of building. We build to solve problems.

In Pakistan, internet stability isn't always a guarantee. Relying on the cloud for every AI-powered feature in a web app is a gamble. Gemma 4 changes the "How" by letting us host the "Brain" of our apps locally or on private, low-cost VPS setups.

The Roadmap for You:

Step 1: Download a model from Hugging Face or Kaggle.
Step 2: Use a tool like Ollama or LM Studio to get an API endpoint running in 5 minutes.
Step 3: Connect it to your Laravel or MERN stack just like you would with OpenAI—except it’s free, private, and yours.

The "Why"

Why does this matter? Because AI should be a tool, not a gatekeeper.

Whether you’re a student trying to master systems or a dev building the next big startup, Gemma 4 is about sovereignty. It’s about having the most capable open models in history sitting on your hard drive, ready to work whenever you are. No tokens, no "usage limits," just pure development.

Let’s stop overthinking and start building something real.

If you're curious about the technical fine-tuning, check out Google's guide on Cloud Run Jobs. It’s the blueprint for taking these models to the next level.

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
You can also find my verified Google Business profile here.

Stop Letting AI Write Your Database Migrations

Syed Ahmer Shah — Wed, 06 May 2026 16:36:02 +0000

The era of “just ask the LLM” has made us remarkably productive, but it has also made us dangerously comfortable. We are currently witnessing a shift where developers are offloading critical infrastructure decisions to generative models. While having an AI suggest a React component or a regex pattern is relatively low-stakes, letting it dictate your database schema transitions is playing with fire.

The problem isn’t that AI is “bad” at SQL; it’s that AI lacks context. It doesn’t know your traffic patterns, it doesn’t understand your locking mechanisms, and it certainly doesn’t care if your production environment goes dark at 3:00 AM because of a table lock that lasted ten minutes too long.

The Illusion of “It Works”

When you ask an AI to generate a migration — say, adding a non-nullable column with a default value to a table with five million rows — the code it gives you will likely be syntactically perfect. You run it in your local environment with fifty rows of seed data, and it finishes in milliseconds.

The issue arises when that same script hits a production environment.

The Before (AI-Generated Standard):

--Generated by AI: Simple, clean, and potentially catastrophic
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255) NOT NULL DEFAULT 'pending';

On a massive table, this operation can trigger a full table rewrite. In PostgreSQL, for instance, versions prior to 11 would lock the entire table while writing that default value to every single row. If your application is high-traffic, your API starts throwing 504 Gateway Timeouts because every connection is waiting for that lock to release.

The After (Human-Engineered Safe Migration):

-- Step 1: Add the column as nullable first (instant operation)
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255);

-- Step 2: Set the default for future rows
ALTER TABLE orders ALTER COLUMN status_code SET DEFAULT 'pending';

-- Step 3: Update existing rows in small batches to avoid long-held locks
-- (This would typically be handled via a background job or scripted loop)

-- Step 4: Add the NOT NULL constraint after data is populated
ALTER TABLE orders ALTER COLUMN status_code SET NOT NULL;

When “Convenience” Costs Millions

We don’t have to look far to see where automated or poorly planned migrations caused genuine wreckage. One of the most famous examples of migration-related downtime was the 2017 GitLab outage. While that was a human error during a manual intervention, it highlights the fragility of database state.

More recently, several tech startups have reported “silent” data corruption when AI-generated migrations suggested changing column types (like INT to BIGINT) without account for how the underlying ORM would handle the transition during a rolling deployment. If your AI-written migration drops a column before the new version of your application code is fully deployed across all nodes, your "After" state is a series of 500 errors.

The Context Gap

AI models operate on patterns, not performance profiles. They don’t know:

The Lock Hierarchy: Will this ALTER TABLE block SELECT queries?
Replication Lag: Will this massive update stall your read replicas?
Deployment Strategy: Is this a blue-green deployment or a rolling restart?

A migration is not just a script; it is a bridge between two states of a living system.

Moving Forward: Use AI as a Drafter, Not an Architect

I am not suggesting we go back to the Stone Age. AI is a phenomenal tool for boilerplate. If you need to scaffold a complex set of join tables, let the AI write the initial DDL.

But the moment that code touches a migration file, the “AI” portion of the task ends. You must take over as the engineer. You need to verify the locks, check the execution plan, and most importantly, simulate the migration against a production-sized data set.

If you’re interested in seeing how I’ve handled high-performance, SEO-optimized database architectures without relying on “magic” scripts, you can check out my project documentation on my GitHub or follow my updates on LinkedIn.

The database is the heart of your application. Don’t let a probabilistic model perform open-heart surgery on it.

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
You can also find my verified Google Business profile here.

Big Tech Is Firing Humans to Buy More GPUs

Syed Ahmer Shah — Fri, 01 May 2026 11:10:05 +0000

There’s a phrase that keeps showing up in corporate earnings calls this year — “efficiency rebalancing.” It sounds sterile. Bureaucratic. Almost boring. But if you strip away the PR language and look at what’s actually happening, it translates to something far more visceral: companies are selling their people to buy computers.

Not metaphorically. Literally.

April 2026 has made this undeniable. Across the tech industry, some of the most profitable companies on the planet — entities sitting on tens of billions in annual revenue — are firing thousands of engineers and developers not because they’re bleeding money, but because keeping humans on payroll has become the most convenient way to fund an AI arms race that is consuming capital at a scale the world has never seen. The math, once you see it, is almost elegant in its brutality.

This Isn’t a Downturn. It’s a Deliberate Trade.

Here’s what makes this moment different from every other tech layoff cycle you’ve heard about. In 2001, the dot-com bubble burst and companies fired people because they were running out of money. In 2008, the financial crisis rippled through everything. In 2022–2023, over-hired tech firms were correcting for pandemic-era excess.

None of that is happening now.

The companies laying people off in April 2026 are not struggling. Oracle just reported a 22% revenue increase. Meta is printing money from advertising. Microsoft’s cloud business is growing faster than anyone projected three years ago. These are not distressed companies making desperate cuts. These are dominant companies making calculated ones.

The difference is this: the cost of staying competitive in AI infrastructure has become so astronomical that it has outgrown the traditional capacity of operational budgets. You can’t slowly build toward $140 billion in AI spending. You have to create a financial runway immediately, and the fastest way to do that is to liquidate your largest variable expense — the human payroll.

Engineers, product managers, QA testers, mid-level developers — these roles represent the only flexible line item large enough to absorb a shock of this scale. The companies aren’t being cruel for the sake of it. They’re following a cold, rational calculus that goes something like: “We can either keep 8,000 people who build features, or we can put that money toward the compute infrastructure that lets AI build those features instead.”

They are choosing the servers. Every time.

The April Wave, Company by Company

Let’s go through what’s actually happening, because the details matter.

Meta announced it’s cutting roughly 10% of its workforce — around 8,000 jobs eliminated in May, plus another 6,000 open positions that are simply being erased before anyone could even be hired into them. The reason isn’t hidden. Meta has publicly committed to spending up to $135 billion on AI infrastructure this single year. To contextualize that number: it’s more than the GDP of many small nations, spent in twelve months, almost entirely on data centers and compute. To free up that kind of capital, Meta is dismantling its traditional flat management structure and reorganizing around AI “pods” — small, focused teams that work directly with applied AI. If your job doesn’t connect to one of those pods? You’re overhead now.

Oracle is arguably the most striking example of just how detached this is from financial distress. The company fired an estimated 30,000 people globally — a massive hit to the US workforce and an even harder blow to India’s tech corridor, which had grown enormously dependent on Oracle’s expansion over the last decade. This $2.1 billion restructuring wasn’t a rescue operation. It was an investment strategy. The explicit goal was to free up nearly $10 billion in cash flow, which is being funneled directly into AI-integrated cloud services and new data center capacity. They made money, then chose to make more money by removing the people who helped them make it in the first place.

Microsoft went a different, more surgical route. Rather than mass terminations, they introduced voluntary retirement buyouts targeting employees whose combined age and years of service equal 70 or more. It sounds almost gentle — nobody’s being dragged out. But what this actually means is that Microsoft is deliberately bleeding out its most experienced, highest-paid engineering talent. These are the people who built the systems, who carry institutional knowledge in their heads, who have been there long enough to remember why certain decisions were made. Microsoft is trading that accumulated human intelligence for GPU capacity, betting that their $140 billion AI infrastructure investment will eventually reproduce or surpass what those veterans knew.

Beyond the big three, the pattern repeats everywhere you look. Nike is cutting 1,400 tech roles and outsourcing internal app logic to AI tools — a consumer goods company essentially deciding it no longer needs a traditional dev team. Snap is slashing 16% of its staff to go all-in on AR and AI-driven advertising. Even ASML — the Dutch company that makes the machines that make the chips that power all of this — cut 1,700 jobs because even the physical backbone of the AI industry isn’t immune to the operational pressures of this transition.

Why Now? The Economics Nobody Explains Clearly

To really understand why this is happening in 2026 specifically, you have to understand a shift that broke one of software’s most cherished assumptions.

For thirty years, the software industry ran on a beautiful economic model: build something once, sell it infinitely. You pay a developer to write a feature, and that feature costs you nothing additional to deploy to the millionth user. The marginal cost of scale was essentially zero. This is why software companies became the most valuable businesses in human history. The economics were genuinely unprecedented.

Agentic AI destroys this model.

When an autonomous AI agent works — actually works, the way companies are now deploying them — it doesn’t just pattern-match and autocomplete. It reads entire code repositories, runs test suites, analyzes logs, iterates, makes decisions, and executes changes. Every step of that process burns compute. Real, expensive, continuous compute. You’re not paying once for a feature anymore. You’re paying a recurring compute cost every single time the agent does anything.

This means that unlike traditional software, AI-powered development has high, ongoing operational costs. But here’s the trap: before you can even get to those operational costs, you have to build or lease the infrastructure to run the agents in the first place. And that infrastructure — a single Nvidia B200 server rack — costs millions of dollars. The Big Four are racing to build tens of thousands of these.

They cannot wait for incremental quarterly revenue to fund this. The competitive window is too narrow. Whoever builds the most capable AI infrastructure fastest will have structural advantages that are nearly impossible to overcome later. So they’re doing the only thing large enough to matter: converting human capital directly into silicon capital. Your salary, multiplied across thousands of employees, becomes another server rack.

The Role That’s Actually Dying

Here’s what most commentary gets wrong about this: people frame it as “AI is taking developer jobs.” That’s too simple, and it’s almost the wrong lesson to take from this.

What’s dying is a specific kind of developer — the feature builder. The person whose primary value was translating a product requirement into functioning code. The person who could spin up a REST API, build a CRUD application, manage a straightforward database schema, or adjust CSS until a layout looked right. These tasks, which occupied the majority of junior and mid-level developer time for the last two decades, are now being handled adequately by AI agents operating at “Level 2” (conversational) and “Level 3” (task-based) autonomy.

The bottleneck has shifted. It’s not “can we generate code fast enough?” Companies can generate oceans of code now. The new bottleneck is: “can we trust, verify, secure, and orchestrate the systems that generate all this code?”

This is why companies are simultaneously firing feature developers and desperately hiring people who understand something different — system architecture, Model Context Protocol (MCP) standards, security layers that prevent prompt injection attacks, API design that is self-describing enough for an AI agent to navigate without breaking things, test-driven development practices robust enough to catch the errors an AI generates at speed.

If an AI agent can write a thousand lines of code in ten seconds, the engineer you actually need is the one who understands the production database well enough to prevent those thousand lines from taking it down. The one who can look at an agent’s output and immediately see the three security vulnerabilities the model missed because it was optimizing for functional correctness, not threat modeling.

That person is not being replaced. That person is currently being aggressively recruited.

What This Actually Means If You’re Early in Your Career

Let’s not pretend this analysis exists in a vacuum. If you’re a young person entering software development right now, reading this as a list of abstract corporate maneuvers would be a mistake.

The honest picture is that the traditional entry point into the industry — learn syntax, get a junior role, build features, grow from there — is narrowing fast. Companies that used to hire cohorts of junior developers to work under senior engineers are either not hiring those roles at all, or automating the work those roles used to do.

But the ceiling hasn’t lowered. If anything, it’s higher than it’s ever been. The engineers who understand infrastructure deeply, who can architect systems, who know how to build the scaffolding that makes AI agents safe and controllable — those people have never been more valuable. The gap between them and everyone else is just getting wider faster than most people expected.

The strategic implication is clear even if it’s uncomfortable: you can’t afford to stay at the surface level. Knowing how to use a framework, following tutorials, building projects that demonstrate you can implement features — that’s table stakes now, and the table is getting smaller. The leverage is in moving lower in the stack than most developers are willing to go, or higher in architecture than most developers bother to reach.

Understand the database internals, not just the ORM. Learn how systems fail under load, not just how they function under ideal conditions. Get comfortable with security thinking. Understand what agents are actually doing when they run, what they cost, and where they fail.

The Uncomfortable Summary

None of this is going to stop. The companies building AI infrastructure are locked in a race where stopping means losing, and losing means being irrelevant at a scale none of them can survive strategically. The human cost of that race is being distributed across workforces globally, and that distribution is not going to slow down in the next 12 to 18 months.

Complaining about it accomplishes nothing. Understanding it clearly is the only useful response.

The data centers are being built regardless of what any individual thinks about the fairness of the process. The question isn’t whether this is happening — it clearly is, at scale, right now. The question is where you want to be standing in relation to it. Are you the person being replaced by the infrastructure? Or are you building toward being the person who understands how to control what comes out of it?

That’s not a rhetorical question. It has a concrete, practical answer that requires specific skills developed over specific time. The window to develop them is still open.

It won’t stay open indefinitely.

Sources:

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
You can also find my verified Google Business profile here.