DEV Community: Muhammad Hamid Raza

How to Build a Next.js App That's Harder to Break in Penetration Testing 🔐

Muhammad Hamid Raza — Sat, 14 Nov 2026 10:40:52 +0000

You ship your Next.js app. It looks great and the Lighthouse score is green. Then a penetration tester sends you a report, and it's longer than your README.

It happens to many of us. Security often feels like something to "add later," right after the feature is done. Later usually arrives as a surprise.

So here's a question: what if your next pen test came back with only a few small notes instead of a wall of red? 😊

No app is 100% unhackable, and anyone who promises that is selling something. But you can build a secure Next.js app that is much harder to attack. Let's do it step by step.

What Does "Hard to Penetrate" Actually Mean?

Penetration testing (pen testing) is when a security tester, with permission, tries to break into your app the way a real attacker would. They look for weak spots, then report them so you can fix them.

Think of your app as a house:

The doors and windows are your login, forms, and API routes.
The locks are your authentication and authorization.
The security camera is your logging and monitoring.

A pen tester walks around the house and tries every handle. A hard-to-penetrate app has strong locks, few unnecessary doors, and nothing valuable left on the porch.

Your goal isn't a perfect house. It's a house where the easy tricks don't work, so attackers give up or get caught.

Why This Matters

Real users trust you with real data. Emails, passwords, and messages deserve protection.
Fixing early is cheaper. A missing check found during development takes minutes. Found after launch, it can take days.
Client and employer confidence. If you build for clients or want a strong portfolio, secure habits set you apart.
Fewer 2 a.m. emergencies. Boring, solid security means calmer weekends. ✅

10 Practical Ways to Harden Your Next.js App

1. Keep Next.js and your dependencies updated

Security bugs get found in frameworks, and fixes ship in updates. For example, in 2025 a vulnerability (CVE-2025-29927) showed that apps relying only on middleware for authorization could be bypassed in some versions. Updating fixed it.

Developer moment: "I'll update later" is the most expensive sentence in web development. 😅

Update Next.js and React regularly.
Run pnpm audit and read the results.
Check the official Next.js security announcements now and then.

2. Check permissions close to the data

This is the big one. Don't rely only on middleware or hidden buttons to protect things.

Server Actions and Route Handlers are reachable over HTTP, so treat each one like a public API endpoint. Anyone can call them directly, not just through your UI.

Check who the user is and what they're allowed to do right where the data is read or changed:

"use server";

import { z } from "zod";
import { getCurrentUser } from "@/lib/auth";
import { db } from "@/lib/db";

const schema = z.object({ postId: z.string().uuid() });

export async function deletePost(formData: FormData) {
  const user = await getCurrentUser();
  if (!user) throw new Error("Unauthorized");

  const { postId } = schema.parse({ postId: formData.get("postId") });

  const post = await db.post.findUnique({ where: { id: postId } });
  if (!post || post.authorId !== user.id) throw new Error("Forbidden");

  await db.post.delete({ where: { id: postId } });
}

Notice three things: login check, input validation, and ownership check. Skipping the ownership check is a classic pen-test finding, where user A can edit user B's data by changing an ID.

3. Validate every input on the server

Browser validation is for user-friendliness, not security. Anyone can skip your form and send requests directly.

Validate request bodies, query params, and form data on the server.
A schema library like Zod makes this clean.
Reject anything unexpected instead of trying to "fix" it.

4. Add security headers

Headers are a cheap way to close several doors at once. In Next.js you can set them in next.config.ts:

import type { NextConfig } from "next";

const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains",
  },
  {
    key: "Permissions-Policy",
    value: "camera=(), microphone=(), geolocation=()",
  },
];

const nextConfig: NextConfig = {
  poweredByHeader: false,
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  },
};

export default nextConfig;

Also consider a Content Security Policy (CSP). It tells the browser which scripts and resources are allowed, which reduces the damage if an XSS bug slips through. The Next.js docs explain how to set one up with nonces. Test it carefully, since a strict CSP can break scripts you forgot about.

5. Protect your cookies and sessions

If you handle sessions yourself, set cookies with:

httpOnly so JavaScript can't read them
secure so they only travel over HTTPS
sameSite (usually lax or strict) to reduce CSRF risk

Better still, use a well-maintained auth library instead of writing session logic from scratch. Rolling your own auth is how many bugs are born.

6. Keep secrets out of the browser

In Next.js, any environment variable starting with NEXT_PUBLIC_ is bundled into client code. Anyone can read it.

Never put API secrets, database URLs, or private keys behind NEXT_PUBLIC_.
Use the server-only package to stop server code from being imported into client components by accident.
Never commit .env files to Git.

7. Be careful with HTML you didn't write

React escapes content by default, which protects you from a lot of XSS. The danger starts when you bypass it:

Avoid dangerouslySetInnerHTML unless you really need it.
If you do need it, sanitize the HTML with a trusted library first.
Never trust user-provided URLs blindly, especially in href attributes.

8. Add rate limiting to sensitive routes

Limit attempts per IP or per account.
Add small delays or temporary lockouts after repeated failures.
Use the same generic message for "wrong email" and "wrong password" so attackers can't learn which accounts exist.

9. Don't leak details in errors

A stack trace is a gift to an attacker. It can reveal file paths, library versions, and database details.

Show users a friendly, generic error.
Log the real details on the server.
Don't expose internal IDs or database error messages in API responses.

10. Test your own app (with permission)

Before a real pen tester shows up, try basic checks yourself. Only test apps you own or have written permission to test.

Run an automated scanner like OWASP ZAP against your staging site.
Walk through the OWASP Top 10 list and ask, "Could this happen in my app?"
Try to access another user's data by changing an ID in the URL. If it works, you've found a real bug. 👀

Comparison: Client-Side Checks vs Server-Side Checks

	Client-side only	Server-side enforced
Hiding an "Admin" button	Looks secure	Actually secure only if the server also checks
Form validation	Good for UX	Needed for security
Pen-test result	Easy to bypass	Much harder to bypass

The UI is the lobby, and the server is the locked vault. Pen testers skip the lobby and go straight to the vault.

Quick Do's and Don'ts

Do ✅

Check authorization on every Server Action and API route
Validate all input on the server
Keep dependencies updated
Use trusted auth libraries
Log suspicious activity

Don't ❌

Trust the frontend to enforce rules
Put secrets in NEXT_PUBLIC_ variables
Show raw error messages to users
Disable security features just to make an error go away
Assume "nobody will find this URL" is a security plan

Common Mistakes People Make

1. Protecting only the page, not the action.
The page is hidden from non-admins, but the API behind it is open. This happens because the UI feels like the whole app. Protect the data layer too.

2. Trusting IDs from the client.
If the request says userId: 42, don't believe it. Take the user from the session instead.

3. Treating security as a final-week task.
Adding it at the end means rewriting things. Build the habits in from day one.

4. Copy-pasting auth code you don't understand.
It works until it doesn't. Read what it does, or use a maintained library.

5. Forgetting old routes and test endpoints.
That /api/test route from last month may still be live. Clean up before deploying.

6. Believing "my framework handles it."
Next.js gives you good defaults, but it can't know your business rules. Who can see what is your job.

Conclusion

Building a Next.js app that's harder to penetrate isn't about being a security genius. It's about a handful of solid habits:

Keep everything updated
Check permissions on the server, close to the data
Validate all input
Set security headers
Protect cookies and secrets
Limit abuse with rate limiting
Test your own work before someone else does

Start with one or two of these today. Secure apps are built one small, boring, careful step at a time. 🚀

If this helped, you can read more developer-friendly posts on hamidrazadev.com. And if you know someone shipping a Next.js app, share this with them. What's the most surprising security bug you've seen in a project? Drop it in the comments. 😊

How Claude Code Can Edit Video Without You Knowing Video Editing

Muhammad Hamid Raza — Thu, 12 Nov 2026 17:52:47 +0000

Ever opened a video editor, stared at the timeline, and quietly closed it again? 😅

Many developers have been there. We can build apps, but trimming a 10-second clip feels harder than it should.

Here is the good news. Claude Code can edit video through code and command-line tools, so you describe what you want in plain English and it works out the technical steps. Image generation is already common. Video is next, and you can try it with tools that exist today. 🚀

What Is Video Editing With Claude Code?

Claude Code is a coding assistant that works in your terminal. It can read your files, write code, and run commands.

It does not "watch" your video and click around a timeline like a human editor. Instead, it uses tools that edit video through text commands.

Think of it like a kitchen. You are the customer, Claude Code is the chef, and the tools are the stove and knives. You say what you want to eat, and the chef picks the tools.

The three tools most people would reach for:

FFmpeg: a command-line tool for trimming, joining, converting, and more.
Remotion: a framework that creates videos from React code.
MoviePy: a Python library for editing video in scripts.

Why This Matters

Video is everywhere: tutorials, demos, social posts, product walkthroughs. But learning editing software and FFmpeg's long commands takes time.

With this approach, you can skip memorizing flags and focus on what you want the final video to look like. It also makes repeated jobs easier, because code can be run again.

Benefits With Real-Life Examples

No need to memorize commands. Ask for "cut seconds 10 to 25 from this clip" and Claude Code can write the FFmpeg command for you.
Repeatable work. Need the same intro on 20 videos? A script can do it in one go.
Videos as code. With Remotion, you can build a title animation using React, a skill many frontend developers already have.
Easy small fixes. Extract audio, resize for social media, or convert formats without opening heavy software.
Learning by reading. You can ask it to explain each command, so you learn while you work.

Here is the kind of prompt you might give:

Trim input.mp4 from 00:00:10 to 00:00:25 and save it as clip.mp4.
Explain the command you used.

And a command it might produce:

ffmpeg -i input.mp4 -ss 00:00:10 -to 00:00:25 -c copy clip.mp4

(Using -c copy is fast, but cuts can land slightly off because of how video is stored. If you need exact cuts, ask it to re-encode.)

Comparison: Which Tool Fits Which Job?

Tool	Best for	Skill it leans on
FFmpeg	Quick edits: trim, join, convert, extract audio	Command line
MoviePy	Scripted edits and simple effects	Python
Remotion	Designed, animated videos	React

A simple rule: start with FFmpeg for editing existing footage. Choose Remotion when you want to create a video from scratch with text and animation.

Best Tips: Do's and Don'ts

Do:

✅ Work on copies of your files, never the originals.
✅ Ask for one small change at a time.
✅ Ask Claude Code to explain commands before you run them.
✅ Watch the output yourself. You are the final reviewer. 👀

Don't:

❌ Expect it to "see" your video like a person.
❌ Paste huge requests like "make this viral."
❌ Skip checking audio sync and quality.

Common Mistakes People Make

Vague prompts. "Make it better" gives vague results. Say what to change: trim, resize, add captions, speed up.
Overwriting the original file. One wrong command and your footage is gone. Always keep a backup.
Not having the tools installed. FFmpeg, Python, or Node must exist on your machine. If something fails, ask Claude Code to check what is missing.
Trusting the first result blindly. Always preview. A cut a second too early is easy to miss.
Starting too big. Try a 10-second clip first, then scale up. 💡

Conclusion

Learning how Claude Code can edit video does not mean becoming a professional editor. It means knowing the right tools exist (FFmpeg, MoviePy, Remotion) and letting Claude Code handle the technical typing while you guide the vision.

Start small, keep backups, and check your results. You may be surprised how far a few plain-English prompts can take you. ⚡

If this helped, feel free to share it with a developer friend who avoids video editing. For more practical dev guides, visit hamidrazadev.com. And tell me in the comments: what video task would you try first? 😊

What Are t9n, l10n, i18n, and g11n? A Simple Guide for Developers

Muhammad Hamid Raza — Mon, 09 Nov 2026 10:58:16 +0000

You open a codebase and see folders named i18n. Then a teammate mentions l10n in a pull request. Someone else says "we need better g11n." And you quietly nod, hoping nobody asks you to explain. 😅

Been there? You're not alone. These strange abbreviations show up in almost every app that serves more than one language. So what do t9n, l10n, i18n, and g11n actually mean, and how are they different?

Let's break them down in plain English. 🚀

What Are t9n, l10n, i18n, and g11n?

First, the naming trick. Each abbreviation keeps the first letter, the last letter, and replaces everything in between with a number. That number is how many letters were skipped.

t9n = translatio*n* (9 letters between t and n)
l10n = localizatio*n* (10 letters between l and n)
i18n = internationalizatio*n* (18 letters between i and n)
g11n = globalizatio*n* (11 letters between g and n)

Developers did this because the full words are long, and typing "internationalization" fifty times gets old fast.

Now the meanings:

t9n: Translation

Turning text from one language into another. "Welcome" becomes "Bienvenido." That's it. Translation is just about words.

l10n: Localization

Adapting your product for a specific language and region. This includes translation, but also dates, times, currency, number formats, images, and cultural details.

i18n: Internationalization

Building your app so it can support many languages and regions without rewriting the code each time. Think of it as preparing the house before the guests arrive.

g11n: Globalization

The big-picture term. It usually means the whole process of making a product work for a worldwide audience, and it commonly covers both i18n and l10n. 🌍

Quick note: these terms are used a little differently from team to team, and t9n in particular is less standardized than the others. If something is unclear, ask what your team means by it.

A Simple Analogy: Opening a Restaurant

Imagine you run a restaurant and want to serve customers in many countries.

i18n: You design the kitchen so the menu can be swapped easily, instead of painting dishes on the wall.
t9n: You translate the menu into other languages.
l10n: You also adjust prices, portion sizes, and local dishes for each country.
g11n: The whole plan of serving customers worldwide.

Same restaurant, different layers of work. 😊

Why This Matters

Not everyone reads English, and even people who do often prefer their own language. Even within one language, details differ. For example, 07/11/2026 can mean 7 November or July 11 depending on where you live. That small difference can cause real confusion.

If you ignore this early, you may end up with text hardcoded all over your components. Fixing that later is painful. 🔧

Benefits with Real-Life Examples

Reach more users. A learning app that offers Urdu and English can serve more students than one that offers only English.
Fewer confusing moments. Showing prices as "$1,000.50" to one user and "1.000,50 €" to another matches what each person expects.
Easier maintenance. With i18n done right, adding a new language often means adding a translation file, not touching component logic.
More trust. Users usually feel more comfortable when an app feels made for them, not just translated at them.
Supports different writing directions. Languages like Arabic and Urdu are written right to left, and a well-prepared layout can handle that.

Comparison: i18n vs l10n vs t9n

Term	Focus	Who usually does it	Example
t9n	Words only	Translators	"Cart" → "Carrito"
l10n	Language + region details	Translators, designers, developers	Local date, currency, images
i18n	Making the code ready	Developers	Using translation keys instead of hardcoded text
g11n	The overall strategy	Product and engineering teams	Planning a worldwide launch

A handy memory trick: i18n is the foundation, l10n is the finishing touch, and t9n is one part of l10n.

Best Tips: Do's and Don'ts

✅ Do

Use translation keys. Write t("cart.title") instead of the raw string "Your Cart."
Use built-in formatting tools. JavaScript's Intl API can format dates, numbers, and currencies for different locales.
Leave room in your layout. Translated text can be longer or shorter than English.
Plan for plurals. "1 item" and "2 items" don't work the same way in every language.
Start early. Even if you launch in one language, prepare for more.

❌ Don't

Don't build sentences by gluing words together. Word order changes between languages.
Don't assume everyone uses the same date or number format.
Don't put text inside images if you can avoid it.

Here's a tiny example of the idea:

// Hardcoded (hard to translate)
<h1>Welcome back!</h1>

// With a translation key (i18n-ready)
<h1>{t("home.welcome")}</h1>

// Formatting a price for a locale
new Intl.NumberFormat("de-DE", {
  style: "currency",
  currency: "EUR",
}).format(1000.5);

Common Mistakes People Make

1. Mixing up the terms. Many people use "translation" and "localization" as if they mean the same thing. They don't. Translation is one piece of localization.

2. Hardcoding text. It feels faster at the start. It becomes a headache when a second language arrives.

3. Translating word for word. Literal translations can sound awkward or confusing. Good localization considers meaning and context.

4. Forgetting layout changes. A button that fits "Save" may break with a longer translated word.

5. Treating language and country as the same thing. One language can be used in many regions, with different formats and spelling.

Conclusion

Let's recap:

t9n is translation: converting words.
l10n is localization: adapting for a language and region.
i18n is internationalization: building your app to support that adaptation.
g11n is globalization: the overall effort of serving a worldwide audience.

Next time you see these abbreviations in a codebase, you'll know exactly what's going on. And if you're starting a new project, a little i18n preparation now can save you a lot of pain later. 💡

If this guide helped, share it with a teammate who's still nodding politely at "l10n." 😄 Want more practical dev content? Read more blogs at hamidrazadev.com. And if you have a localization story or question, drop it in the comments. I'd love to hear it!

How to Apply Multiple Themes in Next.js (Blue, Green, Red and More) Without Refreshing or Using `dark:` Classes

Muhammad Hamid Raza — Sat, 07 Nov 2026 13:39:15 +0000

Your site has a dark mode. Then a client asks, "Can we also have a blue theme? And a green one? Oh, and red!" 😅

Suddenly you are staring at dark:bg-gray-900 blue:bg-blue-900 green:bg-green-900 red:bg-red-900 on every element. That is a lot of repeated classes.

There is a cleaner way. You define every theme's colors once in your global CSS. To switch themes, you change one class on the <html> element. No page refresh, no HTML changes, no per-element theme classes.

Ready to see how it works? 🚀

What Is a Multi-Theme System in Next.js?

A multi-theme system lets users switch between more than two color schemes, such as light, dark, blue, green, and red. The switch happens instantly, with no reload.

Think of a TV remote. The TV (your HTML) stays exactly the same. You press a button (change one class) and the colors change.

The idea has three parts:

CSS variables hold the colors, like --background and --primary.
A class on <html>, like blue or red, decides which set of values is active.
Your components use names like bg-background and text-foreground, never specific colors.

Your components never know which theme is active. They just ask for "the background color" and the CSS answers.

Why This Topic Matters

Theming gets messy fast when colors are written directly into components.

Adding a new theme means editing many files.
Rebranding means hunting through the whole codebase for color classes.
Markup gets longer and harder to read.

With the variable approach, a new theme is one new block in one CSS file. Components stay untouched.

Benefits with Real-Life Examples

Clean HTML and JSX.
className="bg-background text-foreground" replaces a long chain of per-theme classes. A card component looks the same in every theme.
One place for all colors.
Your client says, "Make the green theme a bit softer." You change one value in globals.css, and every button, card, and navbar follows.
Easy to add new themes.
Want a purple theme? Add a .purple { ... } block. No component changes.
Instant switching, no refresh.
Changing a class on <html> makes the browser re-apply styles. There is no page reload, and React does not need to re-render your components just to change colors.
Less repeated code.
You are not generating and shipping theme-specific variants for every element, which keeps your markup and CSS leaner. (It will not magically shrink your app by half, but the duplication really does go away.)

Step-by-Step: Build It

This guide assumes the Next.js App Router and Tailwind CSS v4. A note for Tailwind v3 users appears later.

Step 1: Define Your Themes in `globals.css`

@import "tailwindcss";

/* Default (light) theme */
:root {
  --background: #ffffff;
  --foreground: #111827;
  --card: #f3f4f6;
  --primary: #4f46e5;
  --primary-foreground: #ffffff;
  color-scheme: light;
}

.dark {
  --background: #0b0f19;
  --foreground: #e5e7eb;
  --card: #151b2b;
  --primary: #818cf8;
  --primary-foreground: #0b0f19;
  color-scheme: dark;
}

.blue {
  --background: #eff6ff;
  --foreground: #1e3a8a;
  --card: #dbeafe;
  --primary: #2563eb;
  --primary-foreground: #ffffff;
}

.green {
  --background: #f0fdf4;
  --foreground: #14532d;
  --card: #dcfce7;
  --primary: #16a34a;
  --primary-foreground: #ffffff;
}

.red {
  --background: #fef2f2;
  --foreground: #7f1d1d;
  --card: #fee2e2;
  --primary: #dc2626;
  --primary-foreground: #ffffff;
}

Every theme defines the same variable names with different values. That is the whole trick. 💡

Step 2: Connect the Variables to Tailwind

@theme inline {
  --color-background: var(--background);
  --color-foreground: var(--foreground);
  --color-card: var(--card);
  --color-primary: var(--primary);
  --color-primary-foreground: var(--primary-foreground);
}

Now bg-background, text-foreground, bg-card, and bg-primary work as normal Tailwind classes. They read the live CSS variable, so they follow whichever theme class is active.

Step 3: Use Semantic Classes in Your Components

export function PricingCard() {
  return (
    <div className="rounded-xl bg-card p-6 text-foreground">
      <h3 className="text-xl font-bold">Pro Plan</h3>
      <p>Everything you need to ship faster.</p>
      <button className="mt-4 rounded-lg bg-primary px-4 py-2 text-primary-foreground">
        Get Started
      </button>
    </div>
  );
}

There are no dark:, blue:, or red: classes anywhere. This markup works for every theme you will ever add.

Step 4: Create the Theme Switcher

// components/theme-switcher.tsx
"use client";

const THEMES = ["light", "dark", "blue", "green", "red"] as const;
type Theme = (typeof THEMES)[number];

export function ThemeSwitcher() {
  function applyTheme(theme: Theme) {
    const root = document.documentElement;
    root.classList.remove(...THEMES);
    root.classList.add(theme);
    localStorage.setItem("theme", theme);
  }

  return (
    <div className="flex gap-2">
      {THEMES.map((theme) => (
        <button
          key={theme}
          onClick={() => applyTheme(theme)}
          className="rounded-md bg-primary px-3 py-1 text-sm capitalize text-primary-foreground"
        >
          {theme}
        </button>
      ))}
    </div>
  );
}

Clicking a button removes the old theme class and adds the new one. The colors change instantly. The choice is saved in localStorage so it survives a reload.

Step 5: Avoid the "Flash of Wrong Theme"

You have probably seen this: the page loads white, then flips to dark a moment later. It happens because the saved theme is applied only after React loads.

The fix is a tiny inline script that runs before the page paints:

// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <head>
        <script
          dangerouslySetInnerHTML={{
            __html: `
              try {
                var t = localStorage.getItem('theme');
                if (t) document.documentElement.classList.add(t);
              } catch (e) {}
            `,
          }}
        />
      </head>
      <body className="bg-background text-foreground">{children}</body>
    </html>
  );
}

suppressHydrationWarning on <html> is needed because the script changes the class before React hydrates. Without it, React may warn about a mismatch.

Comparison: Per-Element Theme Classes vs CSS Variables

	Per-element classes (`dark:`, `red:`)	CSS variables + one class
Markup length	Grows with every theme	Stays the same
Adding a new theme	Edit many components	Add one CSS block
Changing a color	Search across files	Edit one value
Best for	Quick one-off tweaks	Real multi-theme apps

Per-element classes are not "wrong". For a simple light/dark site they work fine. But once you go beyond two themes, variables win on maintainability.

Best Tips and Do's & Don'ts

Do ✅

Use semantic names (background, primary, card) instead of color names (blue-500).
Define the same set of variables in every theme.
Set color-scheme for dark themes so native elements like scrollbars and form inputs match.
Test text contrast in every theme. A readable blue theme can still hide text in the red one.

Don't ❌

Don't put theme-specific colors directly in components.
Don't forget the pre-paint script, or users will see a flash.
Don't skip suppressHydrationWarning on <html> if you use that script.

Tailwind v3 note: v3 has no @theme block. Map the variables in tailwind.config.js instead, for example background: "var(--background)". If you want opacity modifiers like bg-primary/50 in v3, store the variables as RGB channels (like 253 110 78) and use rgb(var(--primary) / <alpha-value>).

Prefer a library? next-themes supports custom theme names through its themes prop and handles storage and the flash problem for you. The CSS-variable idea in this article works the same way with it.

Common Mistakes People Make

Using dark: plus custom variants for every theme.
It feels natural because that is how dark mode is usually taught. The fix is to define semantic variables once.
Forgetting to remove the old class.
If you only add red and never remove blue, both classes stay on <html>, and CSS order decides who wins. Always remove the old theme class first.
Missing variables in one theme.
If .green forgets --card, it inherits the value from :root, so you get odd colors. Keep every theme's variable list identical.
Reading localStorage during server rendering.
localStorage only exists in the browser. Use it inside event handlers, effects, or the inline script, not in server components.
Ignoring accessibility.
A pretty theme with low contrast is a bad theme. Check readability for every one.

Conclusion

Here is the recipe again:

Define each theme's colors once in globals.css using CSS variables.
Map those variables to semantic Tailwind colors.
Use classes like bg-background and text-primary in your components.
Switch themes by changing one class on <html>.
Add a tiny pre-paint script so users never see a flash.

The result is cleaner JSX, a single place to manage colors, and instant theme switching with no refresh. Adding a new theme becomes a ten-line job. 😊

If this helped, you can read more practical dev guides at hamidrazadev.com. Share it with a developer friend who is still typing dark: on every div 😄, and tell me in the comments which theme you would add first.

What's New in AI Models Right Now? A Simple Guide for Late 2026

Muhammad Hamid Raza — Sat, 07 Nov 2026 10:59:04 +0000

You open your favorite AI tool on Monday. By Friday, there's a new model name in your feed, and a "this changes everything" post to go with it. 😅

Sound familiar? So which of these new AI models actually matter to you? Let's sort it out together, without the hype.

What Are "New AI Models," Really?

An AI model is the engine inside the tool you use. The chat app, the image generator, and the coding assistant are the car. The model is the engine under the hood.

Labs keep building better engines, and they do it fast. One tracker counted 23 new models from 15 providers in September 2026, and another confirmed 20 models from 16 providers in October.

What's New Right Now

Here's a snapshot as of late October 2026. Names and access change quickly, so check official pages before you build on any of it.

Chat, reasoning, and coding

OpenAI: the GPT-6 family, with Astra as the top tier, Sol as the balanced pick, and Luna as the low-cost option.
Anthropic: Claude Opus 5.5, Sonnet 5.5, and Haiku 5.5 (the newest, released October 7), plus the premium Fable 5.1.
Google: Gemini 3.8 Flash is the broadly available model, while Gemini 4 Argon is rolling out in phases.

Open and budget-friendly

Kimi K3 has published weights and a 1M-token context window, and DeepSeek's V4.1 Flash targets low-cost coding and vision work.
Meta released Muse Wonder and Muse Wonder Full on October 12.

Image and video

Google shipped Nano Banana 2.1 on October 6.
FLUX 3 is built as one model that handles image, video, and audio.
Newer video models like Seedance 2.5 and Kling 3.0 are also being compared head to head.

Why This Matters

New models change what's practical. A task that was too slow, too costly, or too error-prone last quarter might be easy now.

For developers, that can mean cheaper features, better code help, and fewer workarounds. For students and beginners, it means more capable free and low-cost tools to learn with.

Trends Worth Knowing (With Real Examples)

Models come in sizes. Most labs now offer a big model, a balanced one, and a cheap, fast one. Use the cheap one for sorting support emails and save the big one for hard debugging.
Huge context windows. The GPT-6 family supports a 1.05M-token context. That's roughly like handing the model a whole stack of documents instead of one page.
Open weights. With models like Kimi K3, developers can inspect and experiment with the model itself, not just call an API.
Multimodal by default. One model can often read text and images and generate media. Think screenshot in, bug explanation out. 🔧

Quick Comparison: Which Tier Fits?

Tier	Good for	Example
Flagship	Hardest reasoning, long tasks	Debugging a tricky multi-file bug
Balanced	Daily coding and agents	Building a feature with tests
Small and fast	High volume, simple jobs	Tagging or summarizing hundreds of items

Tips: Do's and Don'ts

✅ Test models on your own tasks. One guide suggests scoring 20 to 50 real tasks on correctness, speed, tool-call reliability, and cost.
✅ Check access first. Some frontier models are limited to approved users.
✅ Start with the balanced tier, then move up or down.

Don't

❌ Switch models because of a headline alone.
❌ Trust a single benchmark. It can't reproduce your prompts.
❌ Hardcode a model name without a plan to update it. Names get retired.

Common Mistakes People Make

Chasing every release. New isn't always better for your use case. Pick a stable default and review it monthly.
Using the biggest model for everything. It's like driving a truck to buy milk. It works, but it costs more.
Ignoring access limits. A model that's "announced" may not be usable on your account yet.
Mixing up the model and the app. The same model can behave differently across products.

Conclusion

The big picture is simple. There are more models, in more sizes, with longer context, better image and video tools, and more open options. You don't need to track them all. Pick a solid default, test on your real tasks, and keep learning. 🚀

If this helped you make sense of the new AI models, read more posts on hamidrazadev.com, share this with a friend who's lost in the model names, and tell me in the comments which model you're trying next. 😊

VS Code 1.144: Cloud Sessions, Copilot Fusion, Image Generation, and More (A Friendly Guide)

Muhammad Hamid Raza — Thu, 29 Oct 2026 19:25:09 +0000

You start an agent task, close your laptop, and the session stops with it. We've all been there. 😅

VS Code 1.144 (released October 28, 2026) is built around fixing that kind of friction. It makes agent work keep going across environments, helps you pick the right model, and gives you more control over what agents change.

So what actually changed, and what's worth trying first? Let's walk through it.

What Is VS Code 1.144?

VS Code 1.144 is the latest monthly-style update of Visual Studio Code, and it's mostly about agents. An agent is an AI helper that can work on a task for you: read code, edit files, run tools, and report back.

Here's a simple way to picture it. Think of an agent as a helpful teammate. Earlier, that teammate sat at your desk and left when you left. Now, that teammate can work somewhere else (like in the cloud) and you can check in from anywhere.

The release highlights are:

Session continuity: keep sessions and automations running, even when your computer is off
Copilot Fusion and model comparisons: let Copilot choose models, or compare them yourself
Image generation (Preview): create and edit images in chat
Computer use (Experimental): let agents use desktop apps
Working set (Experimental): keep or undo agent file edits
Assisted permissions: fewer interruptions, with a risk check
Customization marketplace and Copilot connectors (Preview): add skills, plugins, and context from services like Slack and Notion

Some of these are marked Preview or Experimental, so expect them to keep changing.

Why This Update Matters

Working with agents isn't only about writing code. It's about where the work runs, which model does it, and how much you trust it to do on its own.

Those three questions come up daily:

"Can I leave this running and go to lunch?"
"Which model is best for this task?"
"Do I really have to click Approve on every tiny action?"

VS Code 1.144 gives a practical answer to each one. Fewer interruptions and less guesswork means more time for the actual problem. 🚀

Benefits With Real-Life Examples

1. Cloud sessions keep working when your laptop doesn't

Cloud sessions let you run Copilot tasks from VS Code without keeping your development machine online. Your repository and tools run in a managed environment on GitHub's infrastructure.

Example: You start a task, then head home. Later you check progress on GitHub.com or in the GitHub Mobile app, and continue in VS Code when you're back.

One thing to know: cloud sessions use a separate workspace, so local uncommitted changes aren't automatically copied. They also need a paid Copilot plan and follow your organization's policies.

2. One place to manage your remote environments

The new Remote Environments dialog brings GitHub Environments, Dev Tunnels, WSL distributions, and SSH hosts together. You can see each remote's status, connect or disconnect, and choose which remotes show up in the pickers.

Example: You have an SSH host and a WSL distro. Instead of hunting through menus, open Manage Remote Environments at the bottom of the Environment picker and handle both.

3. Cloud automations for repetitive work (Preview)

Cloud automations run on GitHub infrastructure, on a schedule or in response to repository events, even when your computer is off. You can create one from the Automations view in the Agents window, or ask an agent to set it up.

Example: Trigger an automation when you're assigned an issue with a specific label, such as triaging it automatically. You can limit the allowed tools and add filters for tighter control.

4. Copilot Fusion picks the models for you

Select Copilot Fusion in the model picker and Copilot chooses the models, reasoning effort, and execution pattern per request. A simple task might use one model. A harder one might have one model draft a solution while others review it.

You pick an effort level: Standard, High, or Max.

Example: Renaming a variable doesn't need a heavy setup. A tricky refactor might. Fusion makes that call so you don't have to.

Good to know:

You're billed for each model Fusion uses, at its standard rate.
Through November 30, 2026, paid Copilot plans get a 30% discount on Fusion.
Fusion High and Max are offered on Copilot Pro+, Max, Business, and Enterprise plans.

5. Model comparisons: same prompt, different models

Model comparisons run the same prompt across models (and harnesses) so you can review results side by side. They're enabled by default for eligible new sessions in the Agents window. This release expands them, so you can now compare from a folderless chat or from a local or empty repository with no commits.

Example: You're unsure which model writes better tests for your code. Run the same prompt on four and compare. Note that model comparisons aren't supported in Dev Containers.

6. Image generation in chat (Preview)

Agents can generate images with GPT Image 2.5 Flare. You can ask for an icon, a chat background, or a website wireframe, or attach an existing image and ask for changes or variations.

You control it with settings:

chat.copilot.imageGeneration.model: set to off to disable it
chat.copilot.imageGeneration.watermark: set to true to add a visible "Made with AI" watermark

It uses AI credits in addition to those used by the conversation model.

7. Assisted permissions: fewer clicks, still safe

Agents can make a lot of tool calls. Approving each one is safe but slow. Giving the agent full freedom can be risky.

Assisted permissions (now generally available for Copilot sessions) use an LLM-based risk check on each tool call. Low-risk calls are approved automatically. Higher-risk calls, or ones where the risk can't be determined, still ask you.

8. Working set: keep or undo agent edits (Experimental)

In the Copilot harness, edits made through agent tools land in a working set. You can use inline Keep and Undo controls for single changes, or manage everything from the working set above the chat input.

Example: The agent fixes your bug but also touches a file you didn't expect. Undo that one file and keep the rest. Edits made through terminal commands don't appear in the working set, so keep that in mind.

9. Computer use for desktop-app tasks (Experimental)

With Computer Use, the agent can see and control apps on your computer. It works in Copilot harness sessions on your own macOS or Windows machine. The agent asks permission to turn it on, or you can run /computer on (and /computer off to stop).

10. Connectors and a customization marketplace (Preview)

Copilot connectors are GitHub-managed MCP servers that connect your agent to services without local server setup. The release notes mention Slack, Notion, and Microsoft Learn as examples.

Browse is the new home page for Customizations, with plugins and skills from marketplaces you or your enterprise configured. For Business and Enterprise, an administrator must enable Editor preview features.

Quick Comparison: Permission Modes

If you're wondering how the permission choices differ, here's a simple view:

Mode	What happens	Best when
Manual	You approve every tool call	You want full control
Assisted	Low-risk calls auto-approve; others ask you	You want fewer interruptions with a safety check
Allow All	The agent has full autonomy	You accept the risk of unintended actions

Assisted permissions require Folder isolation and might be restricted by your organization. If your admin disables it, it stays visible but greyed out, with an explanation.

Best Tips and Do's & Don'ts

Do:

✅ Try model comparison on a real task before deciding which model you like.
✅ Commit your local changes before starting a cloud session, since they aren't copied over automatically.
✅ Use Assisted permissions if constant approval prompts slow you down.
✅ Set the image watermark setting if you want AI-made images clearly labeled.
✅ Use the Insiders build if you want to try upcoming features early.

Don't:

❌ Don't assume Experimental features are final. Settings and behavior can change.
❌ Don't forget that Fusion bills for each model it uses.
❌ Don't install plugins from sources you don't trust. Plugins can run code on your machine.

Common Mistakes People Make

1. Expecting cloud sessions to see local uncommitted work.
They use a separate workspace. Commit or push first.

2. Looking for a feature that isn't showing up.
Many items are Preview or Experimental and behind settings. Examples: chat.editor.workingSet.enabled, chat.agentHost.computerUse.enabled, and chat.canvases.enabled. Also, some features depend on your plan or organization policy.

3. Thinking the terminal is covered by the working set.
Edits from terminal commands don't appear there. Review those changes another way.

4. Treating model choice as a one-time decision.
New models keep arriving. Comparisons and Fusion exist so you can re-check without guessing.

5. Skipping the side notes for extension authors.
If you publish extensions, vsce publish --oidc lets you publish from GitHub Actions without storing a PAT as a repository secret. It needs @vscode/vsce 4.0.2 or later. Also, global PATs in Azure DevOps are retired on December 1, 2026, so Azure Pipelines users should move to Microsoft Entra ID with a service connection.

Small Extras Worth Knowing

Agent Host Protocol v1.0 is published. It's an open protocol VS Code uses to talk to agents locally and remotely, so you can build custom UIs or agent platforms around it.
Copilot Memory now works in the Copilot harness. It's enabled by default and respects your settings and organization policies.
Move chats between sessions (Preview) lets you drag nested chats around. Enable chat.agentHost.moveChats.enabled in Stable.
New issue reporter: turn it on with issueReporter.wizard.enabled to capture screenshots and recordings without leaving VS Code.
Windows terminal dialogs (like the Azure PowerShell sign-in picker) now open in front of VS Code instead of behind it.

Conclusion

VS Code 1.144 makes agent work feel less tied to one machine and one model. Cloud sessions and automations keep things moving, Copilot Fusion and model comparisons help you choose well, and Assisted permissions plus the working set keep you in control.

My suggestion: don't try everything at once. Pick one or two things, like model comparison and Assisted permissions, and see how they fit your workflow. If you're not on the update yet, use Check for Updates in VS Code. 😊

If this guide helped, you can find more developer posts at hamidrazadev.com. Share it with a teammate who's still approving every tool call by hand. And tell me in the comments: which VS Code 1.144 feature are you trying first? 👀

VS Code 1.143: Copilot Harness Default, Compare Models, and Other Updates Worth Knowing

Muhammad Hamid Raza — Fri, 23 Oct 2026 10:38:31 +0000

You open VS Code after an update and something feels different. A new picker here, a new setting there. You wonder: "Did they move my stuff again?" 😅

VS Code 1.143 has a few changes like that. Some are big, some are small, and several are still experimental. This post walks through the highlights in plain English so you know what changed and what to try first.

What Is VS Code 1.143?

VS Code ships a new version regularly, and 1.143 is the latest release covered here. Think of it like a new season of your favorite show: same main characters, a few new storylines.

The theme of this release is AI agents. Agents are AI helpers that can work on coding tasks for you, and this release makes them easier to run, compare, review, and clean up after.

Here are the headline items:

Copilot harness by default for new sessions
Compare models (Preview)
Reclaim worktree storage (Experimental)
On-device models (Experimental)
Multi-diff file list (Experimental)

A quick note on the word "harness." It's the engine that runs your agent session. The Copilot harness is built on the Copilot SDK, a shared foundation meant to keep behavior and improvements consistent across Copilot products.

Why VS Code 1.143 Matters

Using AI agents is fun until the questions start:

Which model is actually best for this task?
What did the agent change in my files?
Why is my disk suddenly full?

This release goes after those questions. It gives you ways to compare results, review changes, and clean up leftovers. The release notes also describe performance work for people who keep very long chats.

Benefits of the Main Features (With Real Examples)

1. Copilot harness is now the default

New sessions use the Copilot harness. You can keep these sessions running in the background and reach them from both the editor window and the Agents window. They run through the Agent Host.

Example: You start a task in the editor, then switch to the Agents window to check on it. The same session is there.

The release notes also mention reduced delays caused by MCP servers that don't finish loading their tools. If you ever waited a long time for a chat response, that fix is aimed at you.

2. Compare Models (Preview)

You can run the same task with two or more models at the same time. Each attempt gets its own session, and you can mix Copilot, Claude, and Codex harnesses with different reasoning levels.

You can also pick an optional Judge model. It evaluates the attempts and shows a scorecard with time and token usage. If you like, you can select Synthesize to build on the recommended attempt using ideas from the others. Synthesis only starts when you ask for it.

Example: You need a form validation helper. Instead of guessing which model writes the cleanest version, you run several and compare side by side.

To try it, enable sessions.chat.compareAgents.enabled in the Agents window, then choose Compare Models in the model picker.

3. Reclaim worktree storage (Experimental)

Worktrees let agents work on several features without stepping on each other. The catch is that inactive ones pile up and eat disk space.

Run Chat: Open Worktree Cleanup from the Command Palette to see how much space they use. You can filter by inactivity, review sizes, and pick what to remove. Cleaning up marks sessions as done and deletes their worktrees, and you can restore a session later to recreate its worktree. Active, running, needs-input, and pinned sessions are protected.

Example: It's like cleaning your desk. You keep the papers you're using and clear the ones from three weeks ago.

4. Easier review of agent changes

Two changes help here.

File-level Keep (Experimental). Enable chat.editor.workingSet.enabled and you get a working set above the chat input. Select Keep on a file to mark it as reviewed. The edits stay on disk, and the file comes back if the agent changes it again.

More Discard options in the Agents window. Discard Changes now works in more changesets, not just Uncommitted Changes.

5. Faster large chats

Opening a long Agent Host chat used to freeze the window for a long time. In the release notes' measurements (median of three runs on macOS), one chat with about 1,150 requests went from 35.6 s to 9.0 s on a cold open, and the unresponsive time dropped from 28.3 s to 0.6 s.

6. Smaller but useful upgrades

Detached background shells: You can now see output from things like dev servers and file watchers, and stop them from the shell's details.
Diagnostics: The editor highlight limit went from 500 to 5,000 per file, with a warning in the language status indicator if limits are hit.
Multi-diff file list (Experimental): Enable multiDiffEditor.experimental.fileList to get a file list beside the diff view, with A, M, D, and R status letters.
Copilot CLI setup: The VS Code installer on Windows can now install GitHub Copilot CLI, Linux installers add a copilot executable to your path, and macOS prompts you when you add VS Code to $PATH.

Comparison: What "Discard Changes" Does in Each Changeset

The same button behaves differently depending on where you click it. This is worth knowing before you click:

Changeset	What Discard Changes does
Branch Changes	Restores the file to its version where the branch diverged from its base branch, and deletes files the branch added
Session Changes	Reverts the session's edits to the file and keeps changes made outside the session, such as your own edits
Last Turn Changes	Reverts only the latest turn's edits and keeps all other changes

If you only want to undo the agent's most recent attempt, Last Turn Changes is the narrowest option.

Best Tips and Do's and Don'ts

Do:

✅ Try experimental features on a side project first, since they can change.
✅ Use Compare Models when a task matters and you're unsure which model fits.
✅ Check the changeset name before discarding anything.
✅ Run Chat: Open Worktree Cleanup now and then if you use many agent sessions.

Don't:

❌ Don't assume every feature is on by default. Several need a setting. The Session Activity Bar, for example, is off by default in Stable.
❌ Don't expect on-device models on any laptop. More on that below.

Common Mistakes People Make

1. Mixing up Keep and Discard. Keep marks changes as reviewed and leaves them on disk. Discard reverts them. Read the label before you click. 👀

2. Forgetting a feature is experimental or preview. If something looks different from the docs, check whether it's a Preview or Experimental feature behind a setting.

3. Trying on-device models without the hardware. MAI Code 1.1 Flash requires GitHub sign-in and an NVIDIA GPU with 96 GB or more of GPU memory. You also need a compatible llama.cpp build, plus chat.copilot.localModel.llamaServerPath and chat.copilot.localModel.enabled set. Responses that run on your device are labeled On-device and don't use AI credits.

4. Ignoring cleanup until the disk is full. Worktrees add up quietly. A quick review is easier than an emergency one.

5. Skipping the enterprise notes. If you work in a company setup, admins can control things like managed defaults, sandbox bypass, and whether the Local harness is allowed. If a toggle is locked, policy is probably the reason.

Conclusion

VS Code 1.143 is a practical release for anyone working with AI agents. The Copilot harness is now the default, Compare Models helps you pick the best result, worktree cleanup keeps your disk tidy, and the new review tools make agent edits easier to manage. Several of these are still Preview or Experimental, so try them with curiosity and keep your expectations realistic. 🚀

If this helped, share it with a developer friend who's wondering what changed in VS Code 1.143. For more practical dev posts, visit hamidrazadev.com. And tell me in the comments: which feature are you trying first? 😊

What Is a Serverless Backend? A Simple Explanation, Example, and Starter Server 🚀

Muhammad Hamid Raza — Thu, 22 Oct 2026 18:28:28 +0000

You build a small app. It works great on your laptop. Then someone asks, "Cool, where is it hosted?" and suddenly you're reading about servers, ports, uptime, and updates when you just wanted to ship a feature. 😅

That's the moment many developers first hear about a serverless backend.

The name sounds like magic, as if the servers vanished. They didn't. So what does serverless actually mean, and how can you build a small one today? Let's find out. 😊

What Is a Serverless Backend?

A serverless backend is a backend where you write your code as small functions, and a cloud provider runs them for you only when they're needed.

Servers still exist. You just don't set them up, patch them, or keep them running. The provider handles that.

A simple analogy 🍕

Imagine you want pizza.

Traditional server: You rent a whole kitchen and a chef. They wait around all day, even when nobody orders. You pay for the kitchen either way.
Serverless: You order from a pizza place. The kitchen starts working when your order arrives, and you pay for that order.

In serverless, your "order" is a request, like someone opening your app or submitting a form. Your function wakes up, does its job, sends the response, and goes back to sleep.

Where you'll see this

Several platforms offer this model, including AWS Lambda, Vercel Functions, Netlify Functions, and Cloudflare Workers. The details differ, but the idea is the same: you write a function, they run it on demand.

You'll also hear the term FaaS (Functions as a Service). It's the part of serverless that deals with running your functions.

Why Serverless Backends Matter

Here's why it's worth learning:

Less setup. You can go from idea to a working API quickly, without configuring a machine first.
Less maintenance. The provider handles the underlying servers, so you spend more time on your actual product.
Good for learning. Students and beginners can build real APIs without learning server administration first.
Common in modern stacks. If you use a framework like Next.js, you may already be writing serverless-style API routes without calling them that.

It won't replace every kind of backend. But it's a useful tool to have.

Benefits of Serverless (With Real-Life Examples)

You pay for what you use (on most platforms)
Many providers bill based on usage, such as the number of requests and how long your code runs, and often include a free tier. Example: a small portfolio contact form that gets a few messages a week doesn't need a machine running 24/7. Always check the current pricing of your provider, since it changes.
No server maintenance
You don't manage operating system updates or server patches. Example: instead of fixing a server at 2 a.m., you push code and move on.
Scaling is handled for you
If more people visit, the platform can run more copies of your function. Example: a newsletter signup endpoint shouldn't need a rewrite just because a post got shared more than usual. Platforms have limits and settings, so read their docs.
Fast to start
A small function is often just one file. Example: a "send a thank-you email" function can be live the same afternoon you write it.
Great for small, focused jobs
Example: resizing an uploaded image, validating a form, or receiving a webhook from a payment service.

Serverless vs Traditional Server: A Quick Comparison

Neither is "better" in every case. They fit different situations.

	Traditional Server	Serverless Backend
Setup	You configure and manage the machine	Provider manages the infrastructure
Running	Always on	Runs when a request arrives
Billing	Usually fixed or reserved capacity	Usually based on usage
State	Can keep things in memory	Don't rely on memory between requests
Long tasks	Comfortable	Often limited by execution time
Best for	Steady traffic, long-running work	Small APIs, bursts of traffic, quick jobs

Honest nuance: serverless functions can have a short delay on the first request after being idle. This is commonly called a cold start. For many apps it's barely noticeable, but it's good to know it exists.

Let's Build a Tiny Serverless Backend 🔧

Since this blog should be practical, here's a small starter you can run today.

We'll use a Next.js Route Handler. On platforms like Vercel, route handlers can run as serverless functions. We'll build two endpoints:

GET /api/hello returns a greeting
POST /api/subscribe validates an email and responds

Step 1: Create a Next.js project

pnpm create next-app@latest my-serverless-api
cd my-serverless-api

Pick TypeScript and the App Router when asked. (You can use npm or yarn too.)

Step 2: Create your first function

Create this file: app/api/hello/route.ts

import { NextResponse } from "next/server";

// GET /api/hello?name=Sara
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const name = searchParams.get("name") ?? "friend";

  return NextResponse.json({
    message: `Hello, ${name}! 👋`,
    time: new Date().toISOString(),
  });
}

That's a working backend endpoint. No server setup. No port configuration in your code.

Step 3: Add a POST endpoint

Create: app/api/subscribe/route.ts

import { NextResponse } from "next/server";

// POST /api/subscribe
export async function POST(request: Request) {
  // If the body isn't valid JSON, treat it as empty
  const body = await request.json().catch(() => null);

  const email = body?.email;

  if (typeof email !== "string" || !email.includes("@")) {
    return NextResponse.json(
      { error: "Please send a valid email." },
      { status: 400 }
    );
  }

  // In a real app, save the email to a database or email service here.
  return NextResponse.json(
    { ok: true, message: `Thanks! We'll write to ${email}.` },
    { status: 201 }
  );
}

Notice the comment inside the function. We're not storing the email in a variable that lives between requests. In serverless, that wouldn't be reliable. Real data belongs in a database. More on that below.

Step 4: Run it locally

pnpm dev

Then test it:

# GET request
curl "http://localhost:3000/api/hello?name=Sara"

# POST request
curl -X POST http://localhost:3000/api/subscribe \
  -H "Content-Type: application/json" \
  -d '{"email":"sara@example.com"}'

You should see JSON responses for both. 🎉

Step 5: Deploy it

One simple way is to push your project to GitHub and import it into Vercel. Your route handlers get deployed as serverless functions. You can also use the Vercel CLI if you prefer the terminal.

Other hosts work too. Just check how each one supports Next.js route handlers.

Not using Next.js? Here's a plain AWS Lambda version

The idea is the same: a function that receives an event and returns a response.

// index.mjs
export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? "friend";

  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ message: `Hello, ${name}!` }),
  };
};

On AWS, you'd connect this function to an HTTP endpoint (for example, using API Gateway or a Lambda function URL). Setup steps vary, so follow the current AWS docs.

Best Tips and Do's & Don'ts ✅

Do:

Keep functions small and focused. One function, one job.
Store data in a database or storage service. Don't rely on memory between requests.
Validate input. Never trust whatever the client sends.
Use environment variables for secrets. API keys should never sit in your code.
Check your provider's limits. Timeouts, payload sizes, and memory limits differ between platforms.
Log useful information. It makes debugging much easier when you can't "look inside" the server.

Don't:

Don't put secrets in your repo. Not even "just for testing."
Don't run very long jobs in a single function unless your platform clearly supports it.
Don't assume local behavior equals production behavior. Test after deploying.

Common Mistakes People Make

1. Thinking "serverless" means "no servers"

Servers exist. You just don't manage them. Knowing this helps you understand limits like timeouts and cold starts.

2. Saving data in a variable and expecting it to stay

This is a classic. It seems to work on your machine, then data disappears in production. Why? Your function may run in different instances, and instances can start and stop. Fix: use a database.

3. Ignoring cold starts

The first request after a quiet period can be a little slower. Fix: keep functions lightweight, and measure before worrying.

4. Forgetting about timeouts

Functions usually have a maximum run time. A heavy job that works locally might get cut off. Fix: check your provider's limits and break big jobs into smaller pieces.

5. Skipping input validation

It's tempting to trust the request body. Don't. Fix: validate everything, like we did with the email check above.

6. Hardcoding secrets

It happens when we're in a hurry. Fix: use environment variables from day one.

7. Choosing serverless for everything

It's a great fit for many things, but not all. Fix: pick the tool that fits the job, not the one that's trending.

Conclusion

A serverless backend lets you write small functions and let a cloud provider run them when needed. You skip much of the server management, start quickly, and focus on building features.

To recap:

Servers still exist, you just don't manage them.
Functions run on demand, and billing is often based on usage.
Don't store important data in memory. Use a database.
Watch out for cold starts, timeouts, and provider limits.
It's a great way to build small APIs, forms, and webhooks.

You've already seen how little code a working serverless backend takes. Try the starter above, change the message, add a field, and make it yours. 😊

If this post helped, you can read more developer-friendly articles on hamidrazadev.com. And if you know someone who's curious about serverless, share it with them. 🚀

Got questions, or want to share what you built? Drop a comment. I'd love to hear how it goes!

Stop Comparing Android and iOS — They Were Never Meant to Compete

Muhammad Hamid Raza — Sat, 26 Sep 2026 10:34:59 +0000

You've seen the arguments. Someone tweets that iPhone is overpriced, and within minutes the replies are on fire. Android fans say it gives you freedom. iOS fans say it just works. Round and round we go.

Here's the thing: this debate has been running for over a decade, and nobody has won. That's not an accident.

Android and iOS were not built to beat each other. They were built for completely different goals, different people, and different visions of what a smartphone should be. So every time we compare them like they're competing for the same crown, we miss the whole point.

Have you ever compared a hammer to a screwdriver? Both are tools. Both are useful. But they were never meant to do the same job. 🔧

What Does "Comparing Android and iOS" Actually Mean?

When most people compare Android and iOS, they usually mean one of two things:

Which is better for everyday use?
Which should I pick?

Both are fair questions. But they're personal questions, not universal ones.

Android is an open-source mobile operating system developed by Google. It runs on devices made by Samsung, Google, OnePlus, Xiaomi, and hundreds of other manufacturers. You can customize almost everything.

iOS is Apple's mobile operating system. It runs only on iPhones and iPads. Apple controls the hardware and software together, which gives it a unique level of polish and consistency.

They are two completely different philosophies wrapped in the shape of a phone.

Why This Topic Actually Matters

If you're a developer, this debate affects your decisions every day.

Which platform should you build for first?
Should you go native, cross-platform, or web-first?
How do you test your app on both ecosystems?
Which users are you actually targeting?

And if you're just someone buying a phone, the comparison still matters — but in a very different way. Choosing the wrong platform for your life can cause real friction.

The problem isn't that people compare the two. The problem is that most comparisons assume one must be better than the other. That assumption is wrong, and it leads to bad decisions.

Understanding why they're different — not which is better — is what actually helps you make smart choices.

Why Android and iOS Are Not the Same Kind of Thing

Here's an analogy that might help.

Imagine two restaurants. One is a five-star hotel restaurant. The menu is fixed, the portions are perfect, the service is flawless, and everything feels like it was designed together. You cannot ask for substitutions. You trust the chef.

The other is a bustling city market. There are dozens of stalls. You can mix and match. You can find rare flavors from around the world. Nothing is perfectly coordinated, but the variety and freedom are unmatched.

Which restaurant is better? That depends entirely on what you want tonight.

iOS is the hotel restaurant. Android is the city market.

Neither is wrong. They simply offer different experiences for different people.

Real Reasons Why Comparing Them Is Misleading

✅ 1. They Serve Different User Bases

iOS users tend to value simplicity, privacy, seamless integration across Apple devices, and a consistent experience. Many are professionals, creatives, or people who want tech that "just works."

Android users often value choice, flexibility, price range, and the ability to customize their experience. Many are power users, developers, or people in markets where mid-range phones dominate.

When you declare one "better," you are really saying "better for people like me." That's fine. But it's not a universal truth.

✅ 2. Android Is Not One Thing

This is one of the most overlooked points in the debate. Android runs on thousands of devices across every price point. Saying "Android is better than iOS" is like saying "cars are better than iPhones." Which car? A budget hatchback or a luxury SUV?

A Samsung Galaxy S series is a very different experience from a budget Xiaomi phone. Both run Android. Comparing either to an iPhone without specifying the model makes the whole comparison unreliable.

✅ 3. iOS Is a Closed System by Design, Not Mistake

Apple's control over its ecosystem is a deliberate choice. It allows them to optimize performance, guarantee security updates, and create smooth integration between iPhone, Mac, iPad, Apple Watch, and AirPods.

That closed nature frustrates some users. But for many others, especially those already in the Apple ecosystem, it is exactly the feature — not the flaw.

✅ 4. The "Better" Answer Depends on Your Life

Are your friends and family on iMessage? iOS might feel smoother.
Do you need a phone under $200? Android gives you more options.
Are you a developer building apps? You might need both.
Do you live in a Google Workspace office? Android might feel more natural.

Context drives the answer. Stripping context out of the comparison makes it meaningless.

✅ 5. Each Keeps the Other Better

This is the quiet truth nobody says enough. The existence of iOS makes Android better. The existence of Android makes iOS better. Competition pushes both platforms forward.

When Android introduced widgets, Apple eventually added them too. When Apple pioneered Face ID, Android followed. When Google brought real-time translation, Apple improved Siri. They are watching each other — and both of us benefit.

A Quick Look at What Each Does Well

Area	Android	iOS
Customization	🏆 Highly flexible	Limited but clean
Hardware Choice	🏆 Hundreds of options	Only Apple devices
Privacy Controls	Strong (improving)	🏆 Industry-leading
App Ecosystem	Massive	🏆 Higher app revenue
Software Updates	Fragmented	🏆 Fast and consistent
Price Range	🏆 Budget to premium	Premium only
Developer Experience	Strong tools	🏆 Great for SwiftUI
Cross-device Sync	Good with Google	🏆 Seamless with Apple

The takeaway: Neither column dominates. Each wins where its philosophy shines.

Practical Tips for Developers and Users

For Developers 💡

Build for both from day one. Use React Native, Flutter, or a web-first strategy if your budget allows. Ignoring one platform means ignoring half your potential users.
Don't assume behavior. iOS and Android handle navigation, permissions, notifications, and even font rendering differently. Test on real devices.
Respect each platform's design language. iOS users expect the feel of UIKit/SwiftUI conventions. Android users expect Material Design patterns. Forcing one on the other causes friction.
Prioritize based on your market. In South Asia and Southeast Asia, Android dominates. In North America and Japan, iOS has a strong share. Data should drive your decision.

For Everyday Users 💡

Think about your ecosystem. If you own a MacBook, Apple Watch, or AirPods, iOS will feel dramatically smoother. If you use Google Docs, Drive, and Gmail heavily, Android might feel more natural.
Try before you decide. If you have a friend with the other platform, spend an hour using it. Your preference might surprise you.
Don't switch just to win an argument. Switch if your current phone genuinely isn't meeting your needs.

Common Mistakes People Make in This Debate

❌ Mistake 1: Generalizing Android as One Platform

Many people say "Android crashes more" or "Android feels slow." But they're usually talking about a specific budget phone from three years ago. A Pixel 9 or Galaxy S25 is a completely different experience. Be specific.

❌ Mistake 2: Assuming iOS Is Just About Status

Yes, iPhones are expensive. But dismissing iOS users as people who "just want to look rich" ignores real technical reasons many developers, videographers, and professionals choose Apple — like Final Cut Pro integration, Apple Silicon performance, or consistent security updates.

❌ Mistake 3: Picking a Side and Ignoring the Trade-offs

Every platform has trade-offs. iOS restricts sideloading apps. Android is fragmented across updates. Pretending your preferred platform has no downsides makes you less informed, not more confident.

❌ Mistake 4: Using Old Information

The mobile landscape changes every year. Android's privacy controls have improved significantly. iOS has opened up more customization than ever before. Don't make decisions based on a 2016 Reddit thread.

❌ Mistake 5: Making It Personal

You can love your phone and still acknowledge the other one does some things well. It's not loyalty. It's just honesty. 😊

Conclusion: Use the Right Tool, Not the Popular Opinion

Android and iOS are both remarkable pieces of technology. They've changed how billions of people communicate, work, learn, and create. Neither is inferior. Neither is perfect.

The real question was never "which is better?" The real question is "which is better for you, right now, given your needs?"

As a developer, understanding both platforms makes you more employable, more empathetic to your users, and more capable of building things people actually love to use.

As a regular user, understanding both platforms helps you make a smarter purchase — one based on your actual life, not the loudest voice in the comment section.

So next time someone tries to start the Android vs iOS argument, you can smile and say: "They're different tools. I know which one works for me."

That's a more useful answer than anything a 200-comment thread ever produced. 🚀

Want more practical developer content like this?
Head over to hamidrazadev.com for articles, tools, and insights built for developers who want to keep learning and building smarter.

If this post helped you see things differently, share it — you might save someone from a very long and very pointless argument. 😄

Ollama vs LM Studio vs llama.cpp: Which One Should You Actually Use to Run Local LLMs? 🚀

Muhammad Hamid Raza — Fri, 18 Sep 2026 07:42:24 +0000

You finally decided to run an AI model on your own machine. No API keys, no per-token billing, no "you've hit your limit" popup at 2 AM.

Then you open Google and get hit with three names at once: Ollama, LM Studio, and llama.cpp. Every tutorial swears by a different one. Every Reddit thread contradicts the last.

So you do what we all do. You install all three, burn 40 GB of disk space, and still aren't sure which one you're supposed to keep. 😅

Here's the part nobody tells you upfront: these three tools are not really competing the way it looks. They sit at different layers of the same stack.

So the real question isn't "which one is best?" — it's "which one matches the way you work?"

Let's clear it up, simply.

First, What Are We Even Comparing?

Imagine you want to drive somewhere.

llama.cpp is the engine. Raw, powerful, and you're expected to know where the bolts go.
Ollama is the car with an automatic gearbox. Turn the key, drive, done.
LM Studio is the car with a big touchscreen dashboard. Same driving, but you can see and tap everything.

All three run the same kind of local language models. The difference is how much of the machinery you touch.

Let's meet them one by one.

🔧 llama.cpp — The Engine Underneath

llama.cpp is an open-source project (started by Georgi Gerganov) that runs large language models efficiently in C/C++. It's the reason running a decent model on a normal laptop became realistic at all.

It introduced and popularised the GGUF model format — a single file containing the model weights plus the metadata needed to load it.

It ships with command-line tools, including:

llama-cli for chatting in the terminal
llama-server for exposing a local HTTP API
llama-quantize for shrinking models to smaller formats

It supports CPU-only machines and can accelerate on GPUs through backends like Metal (Apple), CUDA (NVIDIA), and Vulkan.

The catch: you either build it yourself or grab a prebuilt release, and you download model files manually. Flags matter. Paths matter. It's not hostile, but it does assume you're comfortable in a terminal.

Who it's for: people who want control, are building something custom, or genuinely want to understand what's happening under the hood.

⚡ Ollama — The "Just Run It" Tool

Ollama wraps local model running into something that feels like Docker for LLMs.

You install it, then:

ollama run llama3

That's it. It downloads the model, loads it, and drops you into a chat prompt.

It also runs a local HTTP server (by default on port 11434) with an OpenAI-compatible endpoint, which is the part developers actually fall in love with. You can point existing code at your own machine by changing a base URL:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # required by the client, not actually checked
)

response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Explain recursion to a 10-year-old."}]
)

print(response.choices[0].message.content)

Ollama also supports a Modelfile — a small config file where you set a system prompt and parameters, then save it as your own named model. Think "Dockerfile, but for model behaviour."

It's available on macOS, Linux, and Windows, and there's a desktop app alongside the CLI.

Worth knowing: Ollama has historically built on llama.cpp for inference. So when you use Ollama, you're often benefiting from llama.cpp's work with a much friendlier wrapper on top.

Who it's for: developers who want local models inside their apps and scripts, with minimum setup friction.

👀 LM Studio — The Desktop App With a Real UI

LM Studio is a desktop application (macOS, Windows, Linux) built around a graphical interface.

You get:

A model browser that searches and downloads GGUF models from Hugging Face
A chat window with settings you can see and adjust
A local server mode that exposes an OpenAI-compatible API, same idea as Ollama
On Apple Silicon, support for MLX models in addition to GGUF

The real advantage is visibility. Context length, temperature, GPU offload — they're sliders and fields, not flags you have to remember. When a model fails to load, you can usually see why.

Trade-off: it's a GUI-first app, so it's a less natural fit for a headless server. And unlike llama.cpp, the app itself isn't an open-source project you can freely fork, so check the current licence if you're deploying it at work.

Who it's for: beginners, students, designers, prompt engineers, and anyone who wants to test models quickly without living in the terminal.

Why This Matters More Than It Used To

Running models locally isn't just a hobbyist flex. It solves real problems.

1. Your data stays on your machine.
Debugging a bug in code covered by an NDA? A local model means that code never leaves your laptop. No policy review needed.

2. No usage bill while you experiment.
Testing 300 prompt variations against a paid API gets expensive fast. Locally, the only cost is your electricity and your patience.

3. It works offline.
Flights, trains, bad hotel Wi-Fi, a conference venue with 400 people on one router. Your model doesn't care.

4. You learn how the thing actually works.
Once you've watched a model fail to load because your context window was too big for your VRAM, you understand LLM memory in a way no blog post can teach you. (Including this one. 😄)

5. It's a genuinely useful skill.
"Set up a private local LLM workflow for the team" is a real task at real companies now.

Quick Comparison Table

	llama.cpp	Ollama	LM Studio
Interface	Command line	Command line + desktop app	Graphical desktop app
Setup effort	Highest	Low	Lowest
Model downloads	Manual (you fetch GGUF files)	Built-in (`ollama pull`)	Built-in browser UI
Local API server	Yes (`llama-server`)	Yes, OpenAI-compatible	Yes, OpenAI-compatible
Control over settings	Maximum	Good (Modelfile + params)	Good, and visible in the UI
Open source	Yes	Yes	App is not open source
Best for	Custom builds, deep control	App development, automation	Learning, testing, quick chats

Short version:
Learning and exploring → LM Studio.
Building apps and scripts → Ollama.
Custom control, embedding, or squeezing out performance → llama.cpp.

And honestly? Many people use two. LM Studio to browse and test models, Ollama to serve the one they picked. That's not indecision — that's using the right tool for each job. ✅

Best Tips (Learned the Slightly Painful Way)

✅ Start with a small model.
Begin with something in the 3B–8B range. If it works, go bigger. Starting with a 70B model on a 16 GB laptop is how you end up thinking "local AI is broken."

✅ Understand quantization before you download.
Those Q4_K_M and Q8_0 labels are compression levels. Lower numbers = smaller file, less memory, some quality loss. Q4_K_M is a popular balanced starting point. Q8_0 is closer to the original but much heavier.

✅ Check your RAM/VRAM against the file size.
Rough rule: the model file needs to fit in memory, plus extra headroom for the context. A ~4.5 GB file on a machine with 8 GB total RAM will be tight.

✅ Lower your context length if loading fails.
Context isn't free. A large context window eats memory before you've typed a single word.

✅ Use the OpenAI-compatible endpoint.
Both Ollama and LM Studio expose one. That means you can prototype locally and switch to a hosted API later by changing one base URL. Your code barely changes.

❌ Don't judge a model from one bad reply.
Try a different prompt, a different quantization, or a different model. First impressions of small models are often unfair.

❌ Don't leave a 30 GB model on your SSD "just in case."
You know you won't use it. Your disk knows too.

Common Mistakes People Make

1. Expecting frontier-model quality from a 7B model on a laptop.
Small local models are genuinely useful for summarising, drafting, classifying, and answering routine questions. They will not match the biggest hosted models on hard reasoning. Knowing that upfront saves a lot of disappointment.

2. Thinking these three tools are rivals.
They overlap, but they're layered. Ollama being easier doesn't make llama.cpp obsolete — Ollama has leaned on llama.cpp's engine work. Picking one doesn't mean the others were wrong.

3. Forgetting the local server is already running.
"Port 11434 already in use" usually means Ollama is doing exactly what you asked it to, in the background, from yesterday.

4. Ignoring the model's licence.
"Open weights" doesn't automatically mean "free for commercial use." Different models ship with different terms. Check before you build a product on one.

5. Downloading five models before testing one.
Classic developer behaviour. Test one properly, then decide. Your bandwidth will thank you.

6. Blaming the tool for a hardware limit.
If a model is slow, it's usually memory or GPU offload, not the app. Switching from Ollama to LM Studio won't add VRAM. 💡

Final Thoughts

Here's the honest summary of Ollama vs LM Studio vs llama.cpp:

llama.cpp gives you the most control and powers a lot of what the others do.
Ollama gives you the smoothest path from "installed" to "in my app."
LM Studio gives you the friendliest way to see, test, and understand models.

None of them is the "wrong" answer. They're three different doors into the same room.

If you're totally new, install LM Studio tonight, download one small model, and just chat with it. That single step teaches you more than a week of reading comparisons.

If you're a developer with a project in mind, install Ollama and point your existing OpenAI client at localhost. It takes about ten minutes and it feels a little bit like magic. ⚡

And if you love knowing exactly how things work, clone llama.cpp and go exploring. It's worth it.

Running AI on your own machine used to be a research-lab thing. Now it's an afternoon. That's a genuinely good time to be a developer. 😊

If this helped, pass it along. Share it with the teammate who's been meaning to try local models, or drop it in your group chat.

📚 More practical developer guides at hamidrazadev.com

💬 Now tell me in the comments: which one did you end up keeping — Ollama, LM Studio, or llama.cpp? And what model are you running? I'm always curious what's working on other people's machines.

VS Code 1.137 Is Here: Automations, Voice Mode, and the Features That'll Change How You Code

Muhammad Hamid Raza — Sat, 12 Sep 2026 21:29:02 +0000

VS Code just dropped another release, and this one feels different. 🚀

Not in a "they changed a color somewhere" kind of way. More like "wait, the editor just started doing things I used to do manually, and I can now talk to it." VS Code 1.137, released on September 9, 2026, is packed with features that push the editor closer to a real AI-powered coding partner.

If you've ever thought, "I wish my editor could just handle this on its own while I grab a coffee" — this release was made for you.

Let's break down everything that's new, what it actually means for your workflow, and how to get the most out of it.

What Is VS Code 1.137?

VS Code 1.137 is the latest stable update to Visual Studio Code, Microsoft's widely used free code editor. This version focuses heavily on agent-powered automation, smarter chat workflows, voice interaction, and better GitHub integration — all without ever leaving your editor.

Think of it as VS Code leveling up from "smart assistant" to "proactive team member." It's still your editor. It just does more now.

Why This Release Matters

Here's the thing: most developers spend a big chunk of their day on repetitive work. Triaging issues. Catching up on recent changes. Reviewing pull requests. Switching between tools — editor, browser, GitHub, back to editor.

VS Code 1.137 tackles all of that head-on. You can now:

Schedule agent tasks to run on a timer, like a cron job but for AI
Talk to the agent with your voice and interrupt it while it's working
Review GitHub issues and pull requests right inside the editor
Continue a quick chat even after deciding it needs a full workspace

This isn't just a list of shiny features. These are actual developer pain points getting solved.

Key Features — What's New and Why It's Useful

⚡ Automations (Preview): Let the Agent Handle the Routine Stuff

Setting: chat.automations.enabled

You know those Monday morning tasks that are the same every single week? Checking what changed over the weekend, scanning for new bugs, triaging open issues? You can now schedule a Copilot agent task to handle those automatically — hourly, daily, or weekly.

You pick a template (catching up on changes, triaging issues, finding bugs) or write your own prompt. Set the schedule. Done.

This is genuinely one of those features where the first time it runs and saves you 20 minutes, you'll wonder how you worked without it.

How to try it: Enable chat.automations.enabled, open the Agents window, and select Automations in the sidebar.

Note: Automations is in Preview and rolling out gradually.

🎙️ Voice Mode (Experimental): Talk to Your Agent Like a Human

Setting: agents.voice.enabled

This is the feature people will demo at meetups. Voice Mode lets you have a real spoken conversation with the Copilot agent while it works on your code.

And the useful part? You can interrupt it. While the agent is speaking or working, you can jump in with a new instruction or correction — just like you would with a teammate. No waiting for it to finish before you can redirect it.

You can also:

Show a live transcript in the chat input (agents.voice.showTranscript)
Choose which voice reads responses aloud (agents.voice.voice)
Pick your input microphone from the Command Palette

It's aware of your active session too — so you can ask things like "which model are we using?" or "what files are attached?" and it'll answer correctly.

How to try it: Enable agents.voice.enabled, then select the Voice Mode button in the chat input.

🐙 GitHub Issues and Pull Requests, Right in the Agents Window (Experimental)

Setting: extensions.experimental.enableAgentsWindowCapability

This one is a workflow changer for teams using GitHub.

Normally, when a chat conversation references a GitHub issue or PR, you'd click the link, open it in the browser, read through it, come back. VS Code 1.137 removes that detour. Select a github.com issue or pull request link and its details open directly in the Agents window — even if the repository isn't open locally.

You can also add GitHub issues or pull requests as context using the Add Context... menu in any chat input. The description, comments, or PR changes become available to the agent without you copy-pasting anything.

Or paste a GitHub URL directly into the chat — VS Code automatically adds it as a context attachment.

To enable: Install the GitHub Pull Requests extension and enable extensions.experimental.enableAgentsWindowCapability.

💬 Continue Quick Chats in a Workspace

This one's subtle but genuinely useful.

You start a quick chat to explore an idea — maybe you're not sure if it's project-specific yet. The conversation develops, and it turns out you do need access to project files.

Before, you'd have to start over in a workspace session and lose your chat history. Now, you just ask the Copilot agent to attach a local folder. After you confirm, the chat converts into a workspace session — keeping its title, conversation history, and current request. The agent picks up right where it left off, now with access to your files.

🤖 Agent Host and Parallel Agent Workflows

VS Code 1.137 introduces a few important agent infrastructure improvements worth knowing about.

Agent-queued messages let you keep agents working in parallel. If an agent tries to contact a busy chat, VS Code queues the message and processes it in order once the active turn finishes. No interruptions, no lost messages.

The agent host lets you connect to the same agent session from multiple VS Code windows. It runs agent harnesses in a dedicated process and aligns behavior with the Copilot CLI and the standalone GitHub Copilot app.

🔀 Smart Diff Editor and Binary Files in Diffs

Small but polished improvements to the diff editor:

You can now choose Inline, Side by Side, or Automatic layout consistently across regular diffs, multi-file diffs, and the Agents window Changes editor.
Binary files (like images) now stay visible in multi-file diffs instead of disappearing. You'll see a "Binary file changed" placeholder, and you can select Open Diff to review the file properly.

🔗 GitHub Rich Links in the Markdown Editor (Experimental)

Settings: markdown.experimental.richLinks.enabled, chat.experimental.richLinks.enabled

Paste a GitHub issue or PR link in your Markdown editor and it shows the current title and status inline — including CI updates. No more opening the browser just to check if an issue is still open or a PR was merged.

Set chat.experimental.richLinks.enabled to true to get the same behavior in chat.

Before vs. After: How 1.137 Changes Your Daily Workflow

Situation	Before 1.137	After 1.137
Weekly issue triage	Manual, every time	Scheduled automation handles it
Redirect an agent mid-task	Wait for it to finish	Interrupt with Voice Mode
Review a PR in a chat context	Open browser, copy info, paste back	Add as context or click the link in Agents window
Quick chat → workspace	Restart conversation	Continue same chat, history intact
Binary file in multi-file diff	Invisible — just missing	Placeholder shown, Open Diff available
GitHub link in Markdown	Just a URL	Live title and status inline

Practical Tips for Getting the Most Out of VS Code 1.137

✅ Do's

Enable Automations for recurring tasks first. Start with one of the built-in templates. See what it does automatically before writing your own prompt.
Try Voice Mode with a clear workspace. It works best when you have a session active and files attached. Give it a focused task.
Install the GitHub Pull Requests extension before trying the Agents window GitHub integration. It's required.
Use Add Context from the chat menu when discussing GitHub issues. It's cleaner than copy-pasting descriptions.
Update to 1.137 immediately using Check for Updates, or download the Insiders build if you want the latest features even earlier.

❌ Don'ts

Don't expect Voice Mode to replace the keyboard entirely — it's a conversation layer, not a full replacement.
Don't skip reading the automation output. Even scheduled agent tasks need a human review occasionally.
Don't paste GitHub URLs into chat expecting context without the GitHub Pull Requests extension installed.
Don't use the Agents window GitHub integration without enabling extensions.experimental.enableAgentsWindowCapability first — nothing will work.

Common Mistakes Developers Make with New VS Code Features

1. Enabling everything at once and getting confused

It's tempting to flip on every experimental setting and see what happens. The problem is, when something doesn't work as expected, you won't know why. Enable features one at a time so you understand what each one does.

2. Ignoring the "rolling out gradually" note

Some features in 1.137, like Automations, are not available to everyone on day one. If you enable the setting and don't see the feature, wait a day or check the Insiders build.

3. Writing automation prompts that are too vague

"Check things" is not a useful automation prompt. "Summarize any new issues opened in the last 24 hours and flag ones labeled 'bug'" is. The agent follows the prompt you give it. Be specific.

4. Forgetting to install the required extension

The GitHub integration in the Agents window needs the GitHub Pull Requests extension installed in your default VS Code profile. If you use separate profiles, make sure it's in the right one.

5. Not trying the quick-chat-to-workspace transition

This feature is easy to overlook because it solves a problem you might not realize you're having. Next time you start a quick chat that grows into something project-specific, try attaching a workspace instead of starting over.

Conclusion

VS Code 1.137 is a thoughtful release. It's not just adding features for the sake of it — it's solving the annoying, repetitive, context-switching parts of a developer's day.

Scheduled automations mean your routine tasks can run without you. Voice Mode means you can direct the agent without stopping to type. GitHub integration means you never have to leave your editor to check an issue. And continuing quick chats in a workspace means your conversational momentum doesn't get lost when work gets real.

It's a genuinely good update. 😊

Give it a try, explore the experimental features, and see which ones fit naturally into your workflow. Chances are at least two of them will stick.

If you found this helpful, share it with a teammate who still manually triages issues every Monday morning. They'll thank you.

For more practical dev tutorials, tools, and blog posts like this, head over to hamidrazadev.com — there's plenty more where this came from. 🔧

VS Code 1.134 Is Here — Side-by-Side Chats, Prompt Timeline, and More Features You'll Actually Use

Muhammad Hamid Raza — Thu, 20 Aug 2026 09:03:11 +0000

If you've ever scrolled forever trying to find something you typed ten minutes ago in a long chat session... VS Code 1.134 just heard your pain. 😅

Released on August 19, 2026, this update is one of those rare releases that feels like the team was watching over your shoulder while you worked. It fixes small but real annoyances, adds tools for managing complex agent sessions, and makes the whole editor feel a bit more like a smart workspace and less like a blank canvas you have to fight every day.

So what exactly changed? Let's break it down in plain English.

What Is VS Code 1.134?

Visual Studio Code is the most popular free code editor in the world. Millions of developers use it daily — from students writing their first Python script to professionals building large-scale apps.

Every month or so, the VS Code team ships a new version packed with bug fixes, performance improvements, and new features. Version 1.134 is the latest of those updates, focused on three main areas:

Agents — how VS Code handles AI-powered sessions and multi-window workflows
Chat — organizing and navigating your conversations with AI
Editor Experience — small quality-of-life improvements that make daily work smoother

Think of it like a phone software update — except instead of fixing battery drain, it fixes the things that slow you down while writing code.

Why This Update Matters

AI-powered coding tools have become a normal part of most developers' workflows. But as those tools get more powerful, the conversations get longer, the sessions get more complex, and managing everything becomes its own challenge.

VS Code 1.134 addresses that challenge head-on.

If you've used GitHub Copilot inside VS Code for any extended session, you know the feeling:

You're mid-task and can't remember what you asked earlier
You want to compare two different agent responses
You made a bunch of file changes but can't trace which prompt caused them
You need to find a specific line from your conversation but scrolling takes forever

This release tackles all of those problems — not with flashy features, but with practical, focused solutions.

Key Features in VS Code 1.134 — With Real-Life Examples

1. 🗂️ Side-by-Side Chats (Grid Layout)

Imagine you're comparing two approaches for the same problem. You ask the agent one way, then another. But switching between those conversations constantly is frustrating — like flipping between two browser tabs when you wish you could just split the screen.

VS Code 1.134 lets you do exactly that. You can now arrange chats in horizontal or vertical groups inside a session. Drag a chat — or a subagent chat — into a group and view them side by side.

You can also:

Hold Alt and click a chat in the Chats picker to open it directly to the side
Create a "side chat" to start a fresh conversation beside your current one
Restore the exact same layout when you reload the window or return to the session

This is genuinely useful when you're running parallel tasks or comparing results from different agent prompts without losing context.

2. ⏱️ Prompt Timeline

Long agent sessions are powerful — but they also produce a wall of conversation that's hard to navigate. Which prompt caused those file changes? Where did you start exploring that feature? Which earlier idea should you revisit?

The Prompt Timeline solves this with a clean timeline in the transcript gutter of the Agents window. Each dot represents one of your prompts. The highlighted dot shows where you are right now.

Hover over the timeline to see a list of your prompts. Click one to jump to it instantly. And if a prompt changed any files, the timeline shows you exactly how many lines were added or removed — and lets you open the diff right there.

You can control how the timeline appears using the sessions.chatTimeline.display setting:

ruler — shows the timeline beside the scrollbar
off — hides it completely

Think of it like a chapter list for your agent session. You can finally stop scrolling through everything just to find where you were.

3. 🔍 Find in Chat

This one is simple but long overdue.

You can now use workbench.action.chat.find to search your entire conversation — including content that's not currently visible on screen. It works in the Chat view, chat editors, and the Agents window.

It supports:

Case-sensitive matching
Whole-word matching
Regular expressions

When you jump to a match, VS Code scrolls it into view and even expands collapsed work summaries if the match is inside them.

If you've ever said "I know I typed this somewhere earlier..." — this feature is for you.

4. 🌐 Open HTML Files in the Integrated Browser by Default

Frontend developers, this one's for you.

If your workflow involves frequently previewing local HTML files rather than editing them, you can now set the integrated browser as the default editor for HTML files. Configure it through workbench.editorAssociations or directly from the editor header.

The integrated browser works just like a standalone browser tab — but it stays connected to your HTML file. Any links inside the file open in new tabs so the association is preserved.

No more switching to Chrome just to check if your layout looks right. 💡

5. 🏠 Agent Host — Connect Multiple Windows to One Session

This is a more advanced feature, but worth knowing about.

The Agent Host lets you connect to the same agent session from multiple VS Code windows. It runs agent processes in a dedicated environment using the Agent Host Protocol (AHP), and the Copilot agent inside it is powered by the Copilot SDK — so its behavior is consistent with the CLI, the standalone Copilot app, and other Copilot tools.

If you work across multiple monitors or windows, this means your agent session doesn't have to be isolated to one window. You can attach to it from wherever you're working.

The feature is still actively being developed, and the team is welcoming feedback through GitHub issues.

6. 🪟 Improved Side Pane Layout

The single-pane layout now follows your workbench.editor.showTabs setting more naturally:

With multiple tabs visible, the layout stays familiar
With single or none settings, a compact single-title header takes over — much cleaner for minimal setups

Text file editors in this mode now use file breadcrumbs in the header, just like the Changes editor — so you always know exactly what you're looking at.

The side pane also holds its size and visibility when you switch between sessions. No more unexpected layout jumps.

7. ✖️ Close Other Editors with Alt+Click

Small feature, real time-saver.

You know how you sometimes end up with eight tabs open and you just want to keep one? Normally you'd right-click a tab and dig through a context menu.

Now you can just hold Alt and the close button on any tab transforms into "Close Other Editors". Click it, and every other tab closes except the one you clicked on.

That's it. Clean and fast.

Before vs. After — What Actually Changed for Daily Work

Situation	Before 1.134	After 1.134
Comparing two agent responses	Open one, close it, open the other	Drag both into a side-by-side group
Finding an earlier prompt	Scroll through the whole session	Jump directly using the Prompt Timeline
Searching conversation history	Manual scrolling	Ctrl+F style search with regex support
Previewing HTML files	Switch to an external browser	Use the integrated browser as default
Keeping one tab, closing the rest	Right-click → context menu	Alt+click the close button

None of these changes are dramatic on their own. But together they remove a surprising amount of friction from the daily workflow.

Tips and Do's & Don'ts

✅ Do:

Enable the Prompt Timeline (sessions.chatTimeline.display: ruler) if you run long agent sessions — it pays off immediately
Use Alt+click on chat items in the Chats picker to open them to the side instead of navigating away
Set workbench.editorAssociations for HTML if you're a frontend developer previewing files regularly
Check for updates manually if you want 1.134 now — VS Code rolls out updates gradually, so use Help → Check for Updates

❌ Don't:

Ignore the Agent Host documentation if you work with multiple windows — it's worth a quick read
Forget that the Find in Chat tool supports regex — it's more powerful than a plain text search
Close the side pane between sessions if you're actively comparing chats — 1.134 now preserves its size and position

Common Mistakes to Avoid

1. Waiting for the update to appear automatically

VS Code uses a gradual rollout, so not everyone gets the update on day one. If you want 1.134 right now, go to Help → Check for Updates and grab it manually. Waiting and wondering why you don't see the new features is a common time-waster.

2. Overlooking the Prompt Timeline setting

The Prompt Timeline defaults to showing beside the scrollbar. If you don't see it, check sessions.chatTimeline.display in your settings. Some users enable the single-pane layout without realizing the timeline is available — don't miss it.

3. Not using Find in Chat for long conversations

It's natural to scroll when looking for something — because that's how we've always done it. But the new Find in Chat works across the entire conversation, including collapsed summaries. Make it a habit early so you stop wasting time scrolling.

4. Forgetting that the Agent Host is still in development

The Agent Host is genuinely useful, but it's early stage. If something doesn't work as expected, file an issue rather than assuming it's a permanent limitation. The team is actively improving it.

Conclusion

VS Code 1.134 is not a "wow, everything changed" release. But it is a well-thought-out, practical improvement to how you work with AI-powered sessions, long conversations, and everyday editor tasks.

Side-by-side chats, the Prompt Timeline, Find in Chat, HTML preview by default, the Alt+click tab shortcut — each of these is small on its own. But if you spend hours every day in VS Code, these are exactly the kinds of improvements that add up.

The team is clearly paying attention to how developers actually use the editor — not just adding features, but fixing the rough edges. 🚀

If you want to try the latest features before the next stable release, grab the Insiders build — it gets updates as soon as they're ready.

👉 Want more posts like this? I cover the latest in VS Code, frontend development, and developer tools at hamidrazadev.com. Come check it out, and if this post saved you some time, share it with a developer friend who might find it useful. ✌️

DEV Community: Muhammad Hamid Raza

How to Build a Next.js App That's Harder to Break in Penetration Testing 🔐

What Does "Hard to Penetrate" Actually Mean?

Why This Matters

10 Practical Ways to Harden Your Next.js App

1. Keep Next.js and your dependencies updated

2. Check permissions close to the data

3. Validate every input on the server

4. Add security headers

5. Protect your cookies and sessions

6. Keep secrets out of the browser

7. Be careful with HTML you didn't write

8. Add rate limiting to sensitive routes

9. Don't leak details in errors

10. Test your own app (with permission)

Comparison: Client-Side Checks vs Server-Side Checks

Quick Do's and Don'ts

Common Mistakes People Make

Conclusion

How Claude Code Can Edit Video Without You Knowing Video Editing

What Is Video Editing With Claude Code?

Why This Matters

Benefits With Real-Life Examples

Comparison: Which Tool Fits Which Job?

Best Tips: Do's and Don'ts

Common Mistakes People Make

Conclusion

What Are t9n, l10n, i18n, and g11n? A Simple Guide for Developers

What Are t9n, l10n, i18n, and g11n?

t9n: Translation

l10n: Localization

i18n: Internationalization

g11n: Globalization

A Simple Analogy: Opening a Restaurant

Why This Matters

Benefits with Real-Life Examples

Comparison: i18n vs l10n vs t9n

Best Tips: Do's and Don'ts

✅ Do

❌ Don't

Common Mistakes People Make

Conclusion

How to Apply Multiple Themes in Next.js (Blue, Green, Red and More) Without Refreshing or Using `dark:` Classes

What Is a Multi-Theme System in Next.js?

Why This Topic Matters

Benefits with Real-Life Examples

Step-by-Step: Build It

Step 1: Define Your Themes in globals.css

Step 2: Connect the Variables to Tailwind

Step 3: Use Semantic Classes in Your Components

Step 4: Create the Theme Switcher

Step 5: Avoid the "Flash of Wrong Theme"

Comparison: Per-Element Theme Classes vs CSS Variables

Best Tips and Do's & Don'ts

Common Mistakes People Make

Conclusion

What's New in AI Models Right Now? A Simple Guide for Late 2026

What Are "New AI Models," Really?

What's New Right Now

Why This Matters

Trends Worth Knowing (With Real Examples)

Quick Comparison: Which Tier Fits?

Tips: Do's and Don'ts

Common Mistakes People Make

Conclusion

VS Code 1.144: Cloud Sessions, Copilot Fusion, Image Generation, and More (A Friendly Guide)

What Is VS Code 1.144?

Why This Update Matters

Benefits With Real-Life Examples

1. Cloud sessions keep working when your laptop doesn't

2. One place to manage your remote environments

3. Cloud automations for repetitive work (Preview)

4. Copilot Fusion picks the models for you

5. Model comparisons: same prompt, different models

6. Image generation in chat (Preview)

7. Assisted permissions: fewer clicks, still safe

8. Working set: keep or undo agent edits (Experimental)

9. Computer use for desktop-app tasks (Experimental)

10. Connectors and a customization marketplace (Preview)

Quick Comparison: Permission Modes

Step 1: Define Your Themes in `globals.css`