DEV Community: Muhammad Hamid Raza

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. ✌️

Vibe Coding Is Fun — But It Might Be Quietly Ruining Your Learning Journey 🚨

Muhammad Hamid Raza — Wed, 19 Aug 2026 07:15:21 +0000

You open your laptop. You have a project idea. You type it into an AI tool. It spits out 200 lines of working code. You paste it in. It runs perfectly.

You feel like a genius. 🚀

But here is the thing — do you actually know what just happened? Can you explain any of that code? Could you fix it if it broke tomorrow? Could you write even 10 lines of it yourself?

If your honest answer is "not really," then welcome to the trap that is quietly swallowing an entire generation of beginner developers.

We need to talk about vibe coding.

What Is Vibe Coding, Exactly?

Vibe coding is a style of programming where you describe what you want in plain English, let an AI tool generate the code for you, and keep going without deeply understanding what was written.

The term got popular because it matches a certain feeling — you are in flow, things are getting built, you feel productive. You are vibing.

Think of it like ordering food at a restaurant by just saying "surprise me" every single time. The food might taste great. But you will never learn to cook.

Vibe coding is not the same as using AI to help you learn or speed up repetitive work. There is a real difference between:

Using AI as a tool while understanding the output
Using AI as a crutch that replaces understanding entirely

Vibe coding is the second one. And for beginners, it is a serious problem.

Why This Matters More Than People Admit

Most beginners start coding because they want to build things. That is a great motivation.

But building things and understanding things are not the same. When you are learning to drive, someone can steer the wheel for you while you sit in the seat. You might reach your destination. But you have not learned to drive.

Vibe coding gives beginners the destination without the journey. And the journey is literally where the learning happens.

Programming is not a collection of finished code snippets. It is a way of thinking. It is logic, problem-solving, pattern recognition, debugging, and understanding how things connect. None of that grows when you skip the thinking step.

The market does not care how fast your AI can generate code. It cares whether you can solve problems, adapt when things break, and build things that actually work.

How Vibe Coding Quietly Damages Beginner Growth

1. You Skip the Struggle — And the Struggle Is the Lesson

There is a reason teachers give you practice problems instead of just showing you the answer. The struggle is not a bug in learning. It is the feature.

When you sit with a problem, try different approaches, fail a few times, and finally figure it out — that is when your brain actually builds a mental model. That model sticks.

Vibe coding removes the struggle entirely. You never build the model. So two weeks later, you cannot remember how to write a simple loop. And that is not laziness. It is just how learning works.

2. You Cannot Debug What You Do Not Understand

Here is a scenario every vibe coder eventually faces.

The AI-generated code works on day one. On day five, something breaks. You ask the AI to fix it. It gives you updated code. That breaks something else. You are now in a loop of asking, pasting, and hoping — with no idea what is actually going wrong.

Debugging requires understanding. If you do not know what a piece of code is supposed to do, you cannot figure out why it is not doing it.

Beginners who vibe code end up paralyzed the moment something does not work. They have no foundation to fall back on.

3. You Develop Zero Problem-Solving Instincts

A senior developer looks at a broken feature and knows roughly where to start looking. They read an error message and already have a mental shortlist of suspects. That instinct is built over years of actually solving problems.

Vibe coding replaces your problem-solving loop with an AI-prompting loop. Instead of "why is this happening and how do I fix it," the thought becomes "let me paste this error into ChatGPT."

That sounds convenient. And sometimes it is. But when you have never trained your own instincts, you have no backup when the AI fails you — and it will fail you.

4. You Miss the Connections Between Concepts

Programming is not a list of isolated facts. Everything connects. Variables relate to functions. Functions relate to scope. Scope relates to closures. Closures relate to async behavior. And so on.

When you vibe code, you jump straight to output without tracing those connections. You end up with a patchwork of half-understood pieces that do not form a real picture.

At some point, every developer needs to build something complex. That is when the gaps in understanding show up all at once — and it is overwhelming.

5. You Build a False Confidence That Eventually Cracks

This one hurts the most.

Beginners who vibe code often feel more confident than those who struggle honestly. They have projects. They have demos. They can share links.

But put them in a technical interview or a real team environment where they need to explain their code, extend it, or write something from scratch — and the confidence shatters.

That moment is genuinely painful. And it is avoidable.

Vibe Coding vs. Intentional AI-Assisted Learning

Let's be honest — AI tools are here to stay. Refusing to use them is not the answer. The answer is using them the right way.

Vibe Coding	Intentional AI-Assisted Learning
Paste code without reading it	Read every line and understand what it does
Use AI to avoid thinking	Use AI to check your thinking
Skip errors by asking AI to rewrite	Debug errors yourself first, then consult AI
Build projects without knowing the concepts	Learn concepts first, use AI to speed up practice
Cannot explain your own code	Can walk anyone through what you wrote

The difference is not the tool. It is your relationship with the output.

Practical Tips for Beginners Who Want to Actually Learn 💡

Do these things:

✅ Write code by hand first, even if it is slow and painful
✅ When you use AI-generated code, read every single line and look up what you do not understand
✅ Try to rebuild the AI's solution yourself after studying it
✅ Use AI to explain concepts, not to replace your understanding of them
✅ Keep a learning journal — write down what you figured out today in your own words
✅ Solve at least a few practice problems every week without AI help

Avoid these habits:

❌ Pasting code you have never read into your project
❌ Moving on from a topic the moment the code "works"
❌ Using AI as your first response to every problem
❌ Building portfolios full of projects you cannot explain
❌ Skipping fundamentals because AI can handle them

Common Mistakes Beginners Make With Vibe Coding

Mistake 1: Treating working code as understood code

Code running without errors is not the same as code you understand. A lot of beginners make this assumption and end up building on a foundation they do not actually have.

Mistake 2: Jumping to complex projects too early

Vibe coding makes it easy to build things that look impressive but require zero understanding. Beginners think they are ready for advanced work when they have not even covered the basics. The gap catches up with them fast.

Mistake 3: Replacing learning resources with AI chat

Documentation, courses, and tutorials are designed to build knowledge step by step. AI answers are designed to be immediately useful. Those are different goals. Relying only on AI chat for learning skips the structured progression that actually builds skills.

Mistake 4: Never reading error messages

Error messages are not obstacles. They are information. Beginners who vibe code often stop reading error messages entirely because they just paste them into AI. Over time, they lose the ability to interpret them. Error messages are one of the most valuable debugging tools you have.

Mistake 5: Assuming AI-generated code is always correct

AI tools make mistakes. They use outdated syntax. They misunderstand context. They generate code that looks right but has subtle bugs. A developer who does not understand the code cannot catch those mistakes — and ships broken software.

So, Is Vibe Coding Completely Bad?

No. That would be a lazy take.

Vibe coding has a place. For experienced developers, it is a productivity tool. For people building internal prototypes, it can speed things up. For exploring an unfamiliar technology, it can show you what is possible before you dig in.

But for someone who is still learning? For someone who has not yet built a mental model of how programming actually works?

Vibe coding at that stage is like using a calculator before you understand math. You get the right answers. You learn nothing.

The phase where you struggle with concepts, write bad code, break things, and fix them slowly — that phase is not something to escape. It is the phase where you actually become a developer. Skip it, and you skip the most important part of the whole journey.

A Note of Encouragement 😊

If you have been vibe coding and you are reading this feeling a little uncomfortable — that is okay. Recognizing the problem is the first step.

You do not have to throw away your AI tools. You just have to change how you use them.

Slow down. Read the code. Ask yourself why it works. Try writing it yourself. Break it on purpose and figure out how to fix it. That is what learning actually looks like.

The developers who will stand out in the next few years are not the ones who best know how to prompt AI. They are the ones who understand programming deeply enough to work with AI intelligently.

That kind of understanding does not come from vibing. It comes from doing the real work.

You have got this. 💪

Conclusion

Vibe coding feels productive. It delivers results fast. And for experienced developers, it genuinely is a useful approach. But for beginners who are still building foundational skills, it removes the very process that creates those skills.

The learning phase is not a hurdle to get past. It is the whole point.

Use AI tools. Explore them. But use them as a supplement to your learning, not a replacement for it. Read the code you use. Understand what you build. Debug your own problems. Build slow, and build well.

Your future self — the one sitting in a real interview, working on a real product, solving a real problem — will thank you for it.

Want more honest takes on the developer journey? Head over to *hamidrazadev.com** for more practical articles just like this one. If this post made you think, share it with a fellow beginner who needs to hear it. Drop a comment below — have you caught yourself vibe coding? How did you course-correct? 👇*

VS Code 1.133 Is Here — And These 4 New Features Will Change How You Code

Muhammad Hamid Raza — Fri, 14 Aug 2026 10:37:39 +0000

VS Code just dropped another update. 🚀

If you've been opening the editor every single day and feeling like something could be smoother, faster, or just a little less annoying — this release has a few answers.

VS Code 1.133 shipped on August 12, 2026, and while it's not the most massive release in history, the features it brings are genuinely useful. Especially if you're working with AI agents, long chat conversations, or building HTML files and wanting instant feedback.

So what actually changed? Let's break it down in plain, honest terms.

What Is VS Code 1.133?

VS Code (Visual Studio Code) is a free, open-source code editor made by Microsoft. It's one of the most popular tools for developers worldwide, and the team releases updates regularly with new features, fixes, and improvements.

Version 1.133 is the latest stable release. It focuses on three main areas: AI agent flexibility, a better chat experience, and a smarter live browser preview.

Nothing revolutionary on the surface — but when you're coding every day, small quality-of-life upgrades add up fast.

Why This Release Matters

Most developers don't celebrate small editor updates. You open the editor, see a "1.133 available" notification, click update, and move on.

But skipping the release notes is how you miss features that could save you 10 minutes every day.

Here's why 1.133 is worth your attention:

If you use Claude or Copilot for AI-assisted coding, you now have more provider flexibility.
If you have long AI chat conversations, you won't lose track of your prompts anymore.
If you preview HTML locally, it now refreshes automatically on every save.
And if GitHub authentication gets in your way, there's a new workaround for that too.

Small changes. Real impact.

The 4 New Features Worth Knowing

1. Mix Anthropic and Copilot Models in a Single Claude Session

This one is big if you use the Claude agent in VS Code.

Previously, your Claude session was tied to one provider — either your GitHub Copilot subscription or your own Claude API key. If you wanted to switch, you had to reconfigure the entire agent host. That was annoying.

Now, the model picker shows both groups at once. You can switch between Anthropic models (billed to your API key) and Copilot models (billed to your Copilot subscription) between turns — without touching any settings.

Think of it like switching between two toolkits mid-project without putting anything away first.

This is especially useful when you want to try a different model for a specific task or compare outputs without interrupting your workflow.

2. Open the Agents Window Without GitHub Sign-In

Setting: chat.agentHost.allowSignedOutWhenUsable

This is marked experimental, but it solves a real frustration.

Before this, opening the Agents window always showed a GitHub sign-in prompt — and you couldn't dismiss it. If your machine couldn't reach github.com, or you simply didn't need GitHub in your workflow, you were stuck staring at that screen.

If you already had Claude configured with an API key, you didn't need GitHub at all. But the editor forced you through the sign-in step anyway.

With this new experimental setting enabled, the Agents window opens without the GitHub sign-in gate. Authentication becomes per-agent or per-model instead of blocking the whole window.

Right now this only works for Claude. Copilot with custom model keys and Codex support is planned for future releases.

To enable it:

"chat.agentHost.allowSignedOutWhenUsable": true

3. Sticky Scroll for Chat Prompts

Setting: chat.stickyScroll.enabled

This is a simple feature, but once you use it, you'll wonder how you lived without it.

If you've had a long back-and-forth conversation in the VS Code chat panel — asking Claude or Copilot to debug, refactor, explain, generate, and review code — you know how fast it gets overwhelming. You scroll down to read a response, and suddenly you've lost track of which question that response was even answering.

Sticky scroll for prompts pins the last prompt you scrolled past to the top of the chat window. It shows you its position in the conversation, and you can click it to jump back or use the previous/next buttons to step through your prompts one by one.

It works the same way as sticky scroll in the code editor — but for your chat history. 👀

4. Auto-Reload HTML Files in the Integrated Browser

Setting: workbench.browser.autoReloadOnFileChange

If you've ever worked on a plain HTML file in VS Code and used the built-in browser preview, you know the pain. You save your file, switch to the preview, and... nothing changed. You have to manually reload it. Every. Single. Time.

This feature kills that friction.

Now, when you have a local HTML file open in the integrated browser, it refreshes automatically whenever the file changes on disk. Save your file, and the preview updates immediately — no manual reload needed.

You can toggle auto-reload per tab or set it globally using the setting above.

It's a small thing. But if you're doing any kind of front-end work or quick HTML prototyping, it's a genuine time-saver.

Benefits at a Glance

Feature	What It Solves
Mix Anthropic + Copilot models	No more provider lock-in per session
Agents window without GitHub sign-in	Unblocks users who don't need GitHub
Sticky scroll for chat prompts	Never lose your place in long AI conversations
Auto-reload HTML preview	Instant feedback without manual refresh

Comparison: Before vs. After 1.133

Using Claude with Multiple Providers

Before: Pick one provider. Want to switch? Reconfigure the agent host.

After: Both providers live in the same model picker. Switch mid-conversation. No reconfiguration needed.

HTML Preview Workflow

Before: Save → switch to preview → manually reload → check result → repeat forever.

After: Save → preview updates automatically. Done.

Long AI Chat Sessions

Before: Scroll through 40 turns of conversation and lose track of which prompt a response belongs to.

After: The prompt sticks to the top of the screen. You always know where you are.

Tips for Getting the Most Out of 1.133

✅ Enable sticky scroll early. If you use chat regularly, turn on chat.stickyScroll.enabled right now. You'll notice the difference immediately in longer sessions.

✅ Try the unsigned Agents window if GitHub is slowing you down. If you already use Claude via API key and GitHub sign-in is just friction, enable chat.agentHost.allowSignedOutWhenUsable and simplify your workflow.

✅ Use auto-reload for static HTML prototyping. It's not just for agent edits — your own saved changes trigger the reload too. Great for quick mockups and style experiments.

✅ Explore the mixed model picker. If you have both a Copilot subscription and a Claude API key, the new model picker makes switching between them genuinely easy. Test both on the same task and see which output suits you better.

✅ Update immediately if you want these features now. VS Code 1.133 is rolling out gradually. Use Help → Check for Updates in the editor to get it right away without waiting.

Common Mistakes to Avoid

❌ Ignoring experimental settings. Features labeled "experimental" are still real, working features — they're just not fully finalized. The Agents-window-without-sign-in setting works today for Claude. Don't dismiss it just because of the label.

❌ Forgetting to enable settings. A few features in this release (sticky scroll, auto-reload, unsigned agents) are not on by default. If you're waiting to see these features magically appear, they won't. Open your settings and enable them manually.

❌ Assuming mixed model support works for all agents. Right now, switching providers mid-session only works within Claude sessions. It doesn't extend to every agent or configuration. Read the docs before expecting it everywhere.

❌ Skipping the agent host documentation. The agent host is getting more powerful with every release. If you're not familiar with it yet, the VS Code Agent Host documentation is worth a read.

Conclusion

VS Code 1.133 isn't a flashy, headline-grabbing release. But it's a polished one.

The ability to mix Anthropic and Copilot models in a single session gives you real flexibility when working with AI tools. Sticky scroll for chat prompts solves a genuine usability problem that grows worse the longer your conversations get. Auto-reload HTML preview removes a small friction that adds up to a lot of lost seconds over a long day. And the unsigned Agents window quietly removes a blocker for a whole group of developers who didn't need GitHub standing between them and their tools.

Good tools get better in small steps. This release is exactly that.

Update your editor, enable the settings that fit your workflow, and keep building.

💡 Enjoyed this breakdown? More posts like this live at hamidrazadev.com — practical dev content, tool breakdowns, and real-world tips.

If this helped you, share it with a teammate who hasn't updated yet. Drop a comment if you've already tried any of these features — I'd love to hear what your experience has been like.

CSS Container Queries: Write Truly Responsive Components (Finally!)

Muhammad Hamid Raza — Tue, 11 Aug 2026 07:32:46 +0000

Most of us have written media queries that felt... a little wrong. You're styling a card component, but you're checking the viewport width to decide how it should look. The card lives inside a sidebar, though. So when the sidebar is narrow — even on a wide screen — your card still renders like it has all the space in the world. 🙃

Sound familiar?

CSS Container Queries fix exactly this. And if you haven't used them yet, this post will change how you think about responsive design.

What Are CSS Container Queries?

Here's the simple version: a container query lets an element respond to the size of its parent container, not the viewport.

Think of it like this. Imagine you're a chameleon. With media queries, you change color based on the weather outside — the whole environment. With container queries, you change color based on the room you're standing in. Much more accurate. Much more useful.

In code terms, you define a container, and then you write styles that activate based on how wide (or tall) that container is.

.card-wrapper {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

That's it. The .card now adapts based on .card-wrapper's width, not the browser window.

Why This Matters

Here's the problem with viewport-based media queries for components.

You build a ProductCard component. It looks great in the main content area. Then a designer drops it into a sidebar. Suddenly it breaks — because the sidebar is only 280px wide, but your media query triggers at 768px viewport width. The viewport is still wide. The component has no idea it's in a tight space.

This is such a common frustration that developers have patched around it for years using JavaScript resize observers, custom hooks, or just making separate components. That's a lot of workarounds for something CSS should handle natively.

Container queries are the native solution. They've been in all major browsers since late 2023, and by 2025 browser support crossed 94%+. There is no good reason not to use them.

Benefits with Real-Life Examples

Here's what container queries actually give you in day-to-day work:

Truly reusable components. A card component can live in a sidebar, a grid, a modal, or a full-width section — and style itself correctly in each case. You write it once. It works everywhere. ✅
Cleaner component code. Instead of passing a variant="compact" prop to a card just to handle narrow layouts, let CSS handle it. Your component logic stays focused on behavior, not presentation math.
Better design systems. Design system teams love this. A Button, Card, or ListItem component can now be truly layout-agnostic. It adapts to wherever the design places it without needing every consuming team to override styles.
Less JavaScript. Before container queries, libraries like react-use-measure or custom ResizeObserver hooks were common. Container queries replace most of those use cases with two lines of CSS.
Easier maintenance. When styles live with the container instead of scattered across breakpoints at the page level, debugging is much faster. You open the component's CSS, not 400 lines of @media rules. 🔧

Media Queries vs Container Queries

This comparison does make sense here, because knowing when to use each one is the whole point.

Situation	Use
Layout changes at the page level (header collapses, sidebar hides)	Media Query
A component adapts based on where it's placed	Container Query
Typography scaling for the whole page	Media Query
A card switches from column to row layout in different contexts	Container Query
Dark mode, print styles	Media Query
A widget component used across multiple layout zones	Container Query

Short version: page-level layout → media queries. Component-level layout → container queries.

You will still use both. They solve different problems. Container queries don't replace media queries — they complete them.

How to Use Container Queries (Step by Step)

Step 1: Define the container

Add container-type to the parent element you want to query against.

.sidebar {
  container-type: inline-size;
}

inline-size means you're querying the width of the container (which is the horizontal size in most writing modes). There's also size if you want to query both width and height.

Step 2: Optionally name the container

Naming is useful when you have nested containers and need to query a specific ancestor.

.sidebar {
  container-type: inline-size;
  container-name: sidebar;
}

Or shorthand:

.sidebar {
  container: sidebar / inline-size;
}

Step 3: Write your container query

@container (min-width: 500px) {
  .card {
    display: flex;
    gap: 1rem;
  }
}

/* Using a named container */
@container sidebar (min-width: 300px) {
  .card-title {
    font-size: 1.25rem;
  }
}

That's the full API for the most common use cases. There's also max-width, aspect-ratio, and orientation queries available.

Best Tips

✅ Do: Apply container-type to the wrapper, not the component itself.

The container and the element being queried should be different elements. Querying your own size creates a circular reference. Wrap the component in a div and apply container-type there.

/* Correct */
.card-wrapper {
  container-type: inline-size;
}

/* Avoid: the card querying itself */
.card {
  container-type: inline-size; /* then @container styles for .card itself won't work as expected */
}

✅ Do: Use container queries for layout decisions, not content decisions.

Swapping from a stacked layout to a side-by-side layout based on container width — great use case. Changing text content based on container size — that's better handled in JavaScript or with conditional rendering in your framework.

✅ Do: Combine with CSS custom properties for cleaner scaling.

.card-wrapper {
  container-type: inline-size;
  --card-padding: 0.75rem;
}

@container (min-width: 400px) {
  .card-wrapper {
    --card-padding: 1.5rem;
  }
}

.card {
  padding: var(--card-padding);
}

✅ Do: Name your containers when nesting.

Unnamed queries match the nearest ancestor container. When you have nested containers, name them to be explicit and avoid surprising style inheritance.

Common Mistakes People Make

1. Forgetting to set container-type.

Writing a @container query without first declaring container-type on the parent does nothing. No error, no warning — just silence. This trips up almost everyone the first time. Always double-check the parent has the declaration.

2. Querying the element that is also the container.

If .card has both container-type: inline-size and @container rules targeting .card, you'll get unexpected behavior. The element cannot query its own size cleanly. Use a wrapper.

3. Replacing media queries entirely.

Some developers get excited and try to remove all media queries. Don't. Page-level layout (navigation collapsing, footer restructuring, font scaling for the whole page) still belongs to media queries. Container queries handle component layout. Know the difference.

4. Not testing in all the layout positions the component lives in.

The whole point of container queries is that your component adapts. But you need to actually test it in every context it'll be used — sidebar, main column, modal, full-width section. A component that works in isolation might still break somewhere in the app if you haven't checked.

5. Worrying about browser support when you don't need to.

Container queries have strong support across Chrome, Edge, Firefox, and Safari. If you're not supporting very old browsers, you can use them today without polyfills. Check caniuse.com if you need to verify for your specific audience, but for most modern projects the answer is: go ahead. ⚡

Conclusion

CSS Container Queries solve one of the longest-standing frustrations in responsive web development. The idea is simple: components should respond to where they live, not just how big the screen is.

If you've been shipping variant props, ResizeObserver hooks, or duplicated CSS just to handle components in different layout contexts — container queries are the cleaner answer you've been waiting for.

The API is small. The browser support is solid. And once you start using it, you'll wonder how you built component libraries without it.

Start with one component. Pick a card, a widget, or a sidebar item that behaves differently in different layouts. Replace that logic with a container query. See how it feels.

Once you do, you probably won't go back. 🚀

If this helped you, I'd love for you to share it with a dev friend who's still wrestling with layout props and media queries. More practical guides like this are on hamidrazadev.com — drop by anytime.

Got questions or a use case you want to talk through? Leave a comment below. Happy to help.

VS Code 1.132 Is Here — And It's Packed with Features You'll Actually Use 🚀

Muhammad Hamid Raza — Thu, 06 Aug 2026 09:26:56 +0000

Have you ever wished you could ask a quick question without breaking your AI agent's flow? Or leave feedback on a web page element the same way you'd leave a comment in a PR? VS Code 1.132, released on August 5, 2026, brings exactly those moments — and a handful more that quietly make your daily coding life smoother.

Let's walk through everything new, and why it matters.

What Is VS Code 1.132?

Visual Studio Code 1.132 is the latest monthly release from the VS Code team. Every release ships with new features, fixes, and quality improvements — but this one leans heavily into the AI and agent experience, making it one of the more exciting drops of the year.

From smarter chat interactions to a revamped dictation engine and a browser you can annotate like a document, 1.132 is pushing VS Code closer to a full AI-native development environment.

Why This Release Matters

AI-assisted coding is no longer a novelty — it's a workflow. Millions of developers now rely on agents to write code, run tasks, and navigate projects. VS Code 1.132 doubles down on making that workflow feel less like fighting tools and more like working with a teammate.

At the same time, it improves things that matter beyond AI — like terminal output readability, dictation accuracy, and Markdown editing.

Whether you're a solo dev, a student, or working in a large team, something in this release will likely improve how your day feels at the keyboard.

The Big New Features — With Real-Life Context

🤖 Agent Host: One Agent Session, Multiple Windows

Previously, each VS Code window had its own isolated agent session. If you were working across windows, you had to juggle multiple contexts — annoying when you're deep in a large project.

The new Agent Host lets you connect to the same agent session from multiple VS Code windows. It runs AI harnesses like Copilot, Claude, and Codex in a dedicated process, using the new Agent Host Protocol (AHP).

Think of it like having one shared whiteboard that every window can see and write on.

The Copilot agent on the agent host is powered by the Copilot SDK, so its behavior stays consistent with the Copilot CLI and standalone Copilot app.

🪟 Agents Window: Your Mission Control for Agent Sessions

The new Agents Window gives you a dedicated space to start and monitor multiple agent sessions at once.

Above the chat input, you'll see live status pills that update in real time:

Changes — shows how many file changes the agent has made; click to view a live multi-file diff
Previews — quick access to Markdown previews for files the agent creates or edits
Subagents — follow what's happening inside a subagent in a separate chat
Browsers — watch the agent interact with an integrated browser

This is the kind of visibility you need when an agent is touching ten files across three folders. Instead of wondering what just changed, you can see it live.

💬 Side Chats with `/btw` — Ask Without Interrupting

This one is genuinely clever. You're running an agent turn — maybe it's refactoring a module or generating a test suite — and you have a quick question. Do you stop the agent? Do you wait?

Now you can just type /btw in the chat input to open a side chat. It shares the context and prompt cache of your primary chat, so your question is informed by what's already happening. The agent keeps going; you get your answer.

You can also select text in a chat response to ask a follow-up question about that specific part. Very useful when a response is long and one paragraph needs clarification.

Want to share context across chats? Drag chat tabs into the input box, or type #chat: and pick a chat by name.

🌐 Commenting in the Integrated Browser

Imagine you're reviewing a generated web page in VS Code's built-in browser and the layout is slightly off in one section. Instead of describing it in words ("the button near the top, I think?"), you can now click directly on the element and attach a comment.

Use the workbench.action.browser.addElementCommentToChat keyboard shortcut to enter comment mode. Select multiple elements, add a note to each, then send the whole set of annotated feedback straight to the chat. Precise, fast, and way clearer than text descriptions.

🎙️ Multilingual Dictation — Now Actually Smart

VS Code's built-in dictation received a major upgrade. The new default model is multilingual Nemotron 3.5, which runs entirely on-device (your audio never leaves your machine).

What's new:

Language auto-detection: dictation can follow your agents.voice.language setting or automatically detect the language from your system locale
Shell-aware cleanup in the terminal: say "git commit dash m hello world" and it produces git commit -m "Hello World" — not the literal words
Custom instructions: run Voice: Configure Dictation Instructions and add a dictation.md file to your project or home directory to teach it your terminology and formatting preferences
Onboarding experience: first-time users see a microphone waveform, a device picker, and links to settings before they start

If your network restrictions block the model download, an action lets you import an official Foundry Local model package from disk — no internet required.

📝 Markdown Diffs in the Hybrid Editor (Experimental)

VS Code 1.131 introduced the hybrid Markdown editor — a view that combines rendered Markdown with in-place editing and agent-actionable comments.

In 1.132, Markdown diffs now open inside that hybrid editor. The modified document stays editable while gutter indicators highlight what's been added, changed, or deleted — just like code diffs, but for rendered Markdown.

You can switch between the text diff view and the Markdown editor with diff annotations using the editor type dropdown. This is marked experimental, but it already works well enough for daily use.

🖥️ Terminal Output Reflow

This is a small fix with a surprisingly large quality-of-life impact.

Previously, expanded terminal output in Chat used a fixed width. If you resized your panel, lines would wrap too early on narrow views or leave dead space on wide ones.

Now, terminal output reflows to match the available width as you resize. It works for both the Local agent harness and the Copilot harness on the agent host. Clean, readable, and no more awkward wrapping mid-command.

Comparison: Before vs. After 1.132 for Agent Workflows

Situation	Before 1.132	After 1.132
Working across two windows	Two isolated agent sessions	One shared agent session
Quick question during agent turn	Stop the agent or wait	Open a side chat with `/btw`
Browser feedback	Describe elements in words	Comment directly on page elements
Dictating terminal commands	Literal transcription	Shell-aware cleanup
Watching agent file changes	Unclear unless you check manually	Live status pills above chat input

Best Tips for Getting the Most from 1.132 ✅

Use /btw for quick questions — don't interrupt agent turns for things that can wait in a side chat
Set up dictation.md with your project's terminology before using voice heavily — it'll save you a lot of corrections
Enable breadcrumbs.showEditorType if you switch between diff and regular editors often — the dropdown saves time
Try the Markdown diff view on files where your agent is making large edits — seeing the rendered diff is much clearer than a raw text diff
Drag chat tabs into the input when you want to share context across multiple chat sessions

Common Mistakes to Avoid

Ignoring the status pills. A lot of developers dismiss the live status pills above the chat input as visual noise. They're not — they're your only real-time window into what an agent is doing across your project. Get in the habit of checking them.

Not configuring dictation instructions. Out of the box, Nemotron 3.5 is solid but generic. Adding a dictation.md file with your preferred terms, abbreviations, and formatting rules makes a real difference, especially on long coding sessions.

Assuming the agent host is always on. The ChatAgentHostEnabled policy has been removed, so administrators can no longer centrally disable it — but individual developers can still toggle it via chat.agentHost.enabled. If agent behavior feels inconsistent, check this setting.

Skipping the dictation onboarding. The new onboarding shows you a live waveform and lets you pick your microphone before you start. Skipping it and diving straight in often leads to picking the wrong mic or missing a setting that affects quality.

Wrapping Up

VS Code 1.132 is a thoughtful release. It doesn't reinvent the editor — it tightens up the agent experience, adds the kind of small contextual touches that make a workflow feel polished, and quietly fixes the rough edges that accumulated over the last few releases.

Side chats with /btw, element-level browser commenting, shell-aware dictation, live agent status pills — these are the kinds of features that sound small in a changelog but genuinely change how a day at the keyboard feels.

If you haven't updated yet, do it now. Use Check for Updates in VS Code, or download the latest nightly Insiders build to get features even earlier.

For more posts like this, check out hamidrazadev.com — practical dev content without the fluff. If this helped you, share it with a teammate who's living in VS Code all day. They'll thank you. 😊

Next.js 16.3 Is Here — And It's the Biggest Update Since 16.0

Muhammad Hamid Raza — Tue, 04 Aug 2026 08:57:42 +0000

If you've ever opened a Next.js project, run next dev, and watched your laptop fans spin up like a jet engine — this update is for you. 🚀

Next.js 16.3 dropped on August 3rd, 2026, and honestly, the changelog reads like a wish list that someone actually delivered on. Less memory. Faster builds. Faster rendering. Smarter prefetching. New devtools. Oh, and an entire suite of opt-in features that bring SPA-style snappiness to your server-rendered apps.

Sound too good to be true? Let's walk through everything together — clearly, practically, and without the jargon overload.

What Is Next.js 16.3?

Next.js is the popular React framework built by Vercel. It helps developers build fast, production-ready web apps with features like server-side rendering, static generation, file-based routing, and more.

Version 16.3 is not a complete rewrite. Think of it like a major tune-up on a car you already love. The engine is the same, but they've cleaned out the oil, replaced the air filter, upgraded the exhaust, and added a GPS that actually works.

Every improvement in 16.3 either makes your development experience faster, your app's runtime faster, or both — with zero changes to your existing app code.

Why This Release Actually Matters

Here's the honest truth about working with Next.js before this update.

Dev sessions on large projects could chew through gigabytes of RAM. If you had 50+ routes, your machine would slow down over time. Builds felt slow on CI. Navigations sometimes felt sluggish compared to SPAs. And error boundaries were a bit of a minefield.

These aren't small complaints. They're the kinds of daily friction that add up over a long project. And 16.3 takes a serious swing at fixing most of them.

Whether you're a student building your first portfolio or an engineer shipping production apps, these improvements will be noticeable from day one.

What's New — Feature by Feature

🧠 Up to 90% Less Memory in Dev

This is probably the headline feature. Turbopack (Next.js's Rust-based bundler) now uses disk caching and memory eviction by default during development.

In real-world tests on vercel.com's dashboard, memory dropped from 21.5 GB to 2 GB after compiling 50 routes. On nextjs.org, it went from 4,600 MB down to 840 MB.

To put that in human terms: if your dev server used to feel like a memory black hole after a few hours of work, it now behaves more like a well-organized tool that actually gives memory back when it's done with it.

No config change needed. It just works after upgrading.

⚡ Faster Builds — Up to 5.5×

The same disk caching that improved dev is now enabled by default for next build too. Turbopack can read unchanged artifacts from cache instead of recompiling everything from scratch.

In tests, the vercel.com/geist project went from a 30-second cold build to a 5.5-second cached build. That's not a typo.

For CI pipelines that run dozens of builds a day, this is a significant time (and cost) saving.

🔷 TypeScript 7 Support for Faster Type Checking

TypeScript 7 is a native Rust port of the TypeScript compiler, and it's roughly 10× faster at type checking than the previous Node.js-based version.

To use it during next build, you just bump your local TypeScript version:

pnpm add -D typescript@^7

That's it. No special flags. No extra configuration.

🖥️ 22% More Requests Handled Under Load

The App Router rendering layer now uses native Node.js streams instead of web streams. Previously, there was overhead from converting between the two during server-side rendering. Removing that conversion layer lets your server handle up to 22% more requests under the same load.

No changes to your code. Just upgrade and your server gets faster automatically.

🤖 Versioned Docs for AI Coding Agents

Here's a thoughtful addition. When you run next dev, Next.js now writes an AGENTS.md file that points AI coding agents (like Cursor, GitHub Copilot, etc.) to the documentation that matches your specific version of Next.js.

No more agents giving you advice based on the wrong version of the docs. They now read the docs bundled right inside your node_modules. It's a small detail that makes AI-assisted development noticeably more reliable.

🔗 Fewer Prefetch Requests

Previously, every visible link could trigger its own prefetch request. In large apps, this led to dozens of network requests firing at once.

In 16.3, small prefetches are automatically bundled together, reducing the total number of requests. Larger shared segments still stay separate so they can be reused across routes.

Less network chatter. Faster perceived load times.

📦 Better Caching for Static Assets

Immutable static assets (files that never change after they're built) can now be reused across deployments. Since they're immutable, there's no risk of serving stale files from the previous version. It's safe, and it means repeat visitors load your site faster after a new deploy.

🛡️ Custom Error Boundaries with `catchError`

Before 16.3, React error boundaries in Next.js had real limitations. They interfered with notFound() and redirect(). They couldn't retry server components that failed. And they had no clean way to re-fetch failed data.

16.3 introduces a catchError API that fixes all of this:

'use client';
import { catchError, type ErrorInfo } from 'next/error';

function ErrorFallback(props: { title: string }, { error, retry }: ErrorInfo) {
  return (
    <div>
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => retry()}>Try again</button>
    </div>
  );
}

export default catchError(ErrorFallback);

The retry() function re-fetches the boundary's children — including any Server Components that failed — without a full page reload. This is a genuinely useful addition for handling real-world errors gracefully.

🗂️ Built-In Glob Imports

Turbopack now supports import.meta.glob, the same API Vite users have been enjoying for a while. It lets you import multiple files from the file system in one line, with hot-module reloading support:

const posts = import.meta.glob('./posts/*.md', { eager: true });

This is especially handy for blog pages, documentation sites, or any pattern where you're loading content from local files dynamically.

Instant Navigations — The Big Opt-In Suite

This deserves its own section because it's not just one feature. It's a whole approach to making Next.js apps feel as fast as SPAs without giving up the benefits of server rendering.

You enable it by adding two flags to your next.config.ts:

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

Here's what that unlocks:

Instant Insights (New DevTool)

A new panel in the Next.js DevTools that automatically surfaces slow navigations while you work. Each insight also gives you a prompt you can pass to your AI agent to fix the issue. No more guessing which routes feel sluggish.

Partial Prefetching

Before 16.3, you had two options: a shared loading shell via loading.tsx, or aggressive full-page prefetching with <Link prefetch={true}>. Both were limiting.

Partial Prefetching lets Next.js extract per-route loading shells and gives you fine-grained control over how much content to prefetch per link. It's more flexible and less wasteful.

Better Incremental Static Regeneration (ISR)

Previously, if you didn't prerender a page at build time, the first visitor had to wait for it to generate — no loading shell, just a wait.

Now, even pages you didn't prerender can serve an instant loading shell to the first visitor, then upgrade to the fully rendered version in the background. Every later visitor gets the final cached content.

Navigation Inspector (New DevTool)

Because Next.js disables prefetching in dev, it was hard to know exactly what a user would see during a navigation. The Navigation Inspector lets you pause navigations at the shell so you can visually inspect the loading state before the full page loads. Incredibly useful for QA and polish.

Playwright Test Helper

This one's for teams who care about preventing regressions. The new instant() helper for Playwright lets you write tests that assert what content should be immediately visible during a navigation:

import { instant } from '@next/playwright';

test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');

  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
  });
});

If a refactor accidentally makes that content slow to appear, the test fails. No surprises in production.

Experimental Features Worth Knowing About

Rust-Based React Compiler

The React Compiler already optimizes your components at build time, so you don't have to manually add useMemo and useCallback everywhere. Until now, it ran through Babel in Node.js.

16.3 ships an experimental Rust port that runs directly inside Turbopack, skipping the Babel step entirely. In tests on large apps like v0, this cut the time from next dev to a ready page by 34% on a cold build and 46% on a warm one.

You can try it today:

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

It's experimental, but the numbers are impressive.

Network Resilience (`useOffline`)

With experimental.useOffline enabled, when the network drops, instead of throwing an error, Next.js keeps the request pending and retries automatically when the connection returns.

A new useOffline hook also lets you show the user a banner so they know what's happening:

import { useOffline } from 'next/offline';

export function OfflineBanner() {
  const isOffline = useOffline();
  if (!isOffline) return null;
  return <div>You're offline. Retrying when you reconnect.</div>;
}

Combined with Partial Prefetching, prefetched routes can still render their shell while offline. It's a small feature that makes apps feel much more resilient on spotty connections.

Before vs. After — At a Glance

Area	Before 16.3	After 16.3
Dev server memory (50 routes)	~21.5 GB	~2 GB
Build time (cached)	Baseline	Up to 5.5× faster
SSR request throughput	Baseline	Up to 22% more
Error boundaries	Limited, interfered with `redirect`	Full control with `catchError`
Prefetching	All-or-nothing	Fine-grained per link
Glob imports	Not built-in	`import.meta.glob` supported
AI agent docs	Generic	Version-matched automatically

Tips for Getting the Most Out of 16.3

✅ Upgrade immediately for the free wins.
Memory savings, faster builds, and faster SSR require zero code changes. Run npm install next@latest and you're done.

✅ Try TypeScript 7 if type checking feels slow.
If next build type checking is a bottleneck on your team's CI, bumping to typescript@^7 is low-risk and potentially high-reward.

✅ Enable Instant Navigations on a branch first.
The cacheComponents and partialPrefetching flags change navigation behavior. Test on a feature branch before rolling them out to production.

✅ Use the Navigation Inspector before shipping.
If you care about perceived performance, use the new DevTools panel to check what loading states users actually see during navigations.

✅ Write an instant() Playwright test for your most important routes.
If you have a product page or checkout flow, protect its navigation speed with a regression test. Future you will thank present you.

❌ Don't skip the error boundary migration if you're using custom boundaries.
The old approach is still supported, but catchError is cleaner and more capable. It's worth migrating.

❌ Don't enable the experimental Rust React Compiler in production yet.
It's promising, but it's still experimental. Use it locally to measure the gains, then wait for a stable release before shipping it.

Common Mistakes to Watch Out For

Upgrading without testing cacheComponents behavior.
Cache Components changes how data is cached and served. If you turn it on in an existing app without reading the migration guide, you might see unexpected behavior with dynamic data. Always test on a staging environment first.

Assuming TypeScript 7 is a drop-in replacement for all projects.
For most projects it is, but if you rely heavily on Babel-based transforms, the interplay with the Rust React Compiler may need a bit of extra configuration. Check the docs before flipping both on.

Ignoring the Instant Insights panel.
It's easy to dismiss DevTools notifications during development, but the Instant Insights panel actually tells you something actionable. If a route shows up as slow, it's worth spending five minutes on the fix while you're in that area of the codebase.

Forgetting that experimental features can change.
useOffline and turbopackRustReactCompiler are experimental. Their APIs could change in a future release. Build on them for learning and prototyping, but don't build critical production paths around them just yet.

How to Upgrade Right Now

Just run this in your project:

npm install next@latest

Or with pnpm:

pnpm add next@latest

That's it for the stable improvements. For Instant Navigations, add the two flags to your config. For experimental features, follow the individual guides in the docs.

Wrapping Up

Next.js 16.3 is one of those releases where the team clearly listened. The 90% memory reduction in dev is huge. The build speed improvements are real and measurable. The SSR throughput gains cost you nothing. And Instant Navigations gives you a proper upgrade path toward SPA-style responsiveness without abandoning the server-rendering model that makes Next.js worth using in the first place.

It's not a revolutionary release that breaks everything. It's a thoughtful, well-executed one that makes the framework noticeably better for everyone who uses it daily.

If you've been on the fence about upgrading your Next.js projects, 16.3 is the push you needed. The gains are real, and the migration path is gentle.

Give it a try, and if you found this walkthrough useful, share it with a teammate or fellow developer who's still running a memory-hungry dev server. 😊

For more practical dev guides, deep dives, and developer content, head over to hamidrazadev.com — there's always something worth reading there.

Happy building! 🔧

Claude Opus 5 Is Here — And It's the Most Capable Everyday AI Model Yet 🚀

Muhammad Hamid Raza — Tue, 04 Aug 2026 06:18:53 +0000

You know that feeling when a tool you already rely on suddenly gets dramatically better, for the exact same price? That's what Anthropic just delivered with Claude Opus 5.

Released on July 24, 2026, Claude Opus 5 is not a quiet point-release. It is a genuine step change in the Opus tier — better at coding, smarter at reasoning, more aligned, and still priced at the same rate as its predecessor, Opus 4.8.

Whether you are a developer using AI to write and debug code, a researcher running complex multi-step analyses, or a builder trying to ship products faster, Opus 5 was designed with you in mind.

So what exactly changed, and is it worth switching to? Let's break it all down.

What Is Claude Opus 5?

Claude Opus 5 is Anthropic's latest flagship AI model in the Opus tier — their highest-capability class of models available for general use.

Think of Claude's model lineup like a team with different specialists. Haiku is fast and lightweight. Sonnet balances speed and smarts. Opus is the deep thinker — the one you bring in when the problem is hard and you need the best result, not just the quickest one.

Opus 5 is the newest and most powerful version of that deep thinker.

It sits below Claude Fable 5 (the current top-tier model) and the restricted-access Claude Mythos 5, but it comes remarkably close to Fable 5's performance — at half the price per task on many benchmarks. That is not a small deal.

Why Claude Opus 5 Matters

Here is the honest truth about AI models in 2026: the race is no longer just about raw capability. It is about who can get you frontier-level intelligence without burning through your budget in the process.

Opus 5 is Anthropic's answer to that. It is designed to be used every single day — for coding, research, writing, analysis, and long-running automated workflows — without requiring the cost of a top-tier frontier model for every task.

It is now the default model on Claude Max and the strongest model on Claude Pro. In other words, if you are already on Claude, you are probably using Opus 5 right now.

Benefits with Real-Life Examples

1. Top of the leaderboard on coding tasks

On Frontier-Bench v0.1, Opus 5 outperforms every other model and more than doubles Opus 4.8's performance — at a lower cost per task. On CursorBench 3.2 at max effort, it lands within 0.5% of Fable 5's peak score, at half the cost.

What this means for you: You can tackle harder engineering problems with the same budget. Think complex refactors, root-cause debugging, and building full features end to end.

2. Dramatically better at agentic, multi-step work

On Zapier AutomationBench — a benchmark for completing real business workflows from start to finish — Opus 5's pass rate is around 1.5 times the next-best model, at the same cost. Even at its lowest effort setting, Opus 5 passes more tasks than any other model on the leaderboard.

Real example from early-access testing: A trading firm engineer used Opus 5 to build a full market data feed for a new exchange in a single session. Previous models could not complete this task at all, even with detailed plans from the engineer.

3. A massive leap on novel problem-solving

On ARC-AGI 3 — an evaluation where the model must solve completely new problem types it has never seen before — Opus 5 scored three times higher than the next-best model. That is not a small margin. That is a different class of reasoning.

4. Better computer use, at less cost

On OSWorld 2.0, a computer use benchmark, Opus 5 outperforms every other model at any given cost — and it surpasses Fable 5's best result at just over a third of the cost.

5. Improved scientific research capabilities

Opus 5 outperforms Opus 4.8 on every single life sciences evaluation Anthropic runs, including structural biology, organic chemistry, and bioinformatics. On organic chemistry tasks, it scores more than 10 percentage points higher than Opus 4.8. On protein-related tasks, it scores nearly 8 points higher.

6. Stronger visual outputs

Early adopters noted better animations, games, 3D work, and visual artifacts — the strongest visual output from an Opus model to date.

Opus 5 vs Opus 4.8 — Is the Upgrade Real?

Yes, and here is the honest picture:

What Changed	Opus 4.8	Opus 5
Frontier-Bench performance	Baseline	More than 2×
ARC-AGI 3	Lower	3× next-best
Price per million input tokens	$5	$5 (same)
Price per million output tokens	$25	$25 (same)
Alignment (behavioral audit score)	Higher	2.3 (lowest of recent models)
Default on Claude Max	Yes	Yes (still default)
Fast mode (2.5× speed)	Available	Available

The short version: same price, significantly better results. The biggest gains are on hard, long-horizon tasks — exactly the kind of work where Opus models are supposed to shine.

One real note on honest nuance: Opus 5 stays behind Mythos 5 on cybersecurity exploitation tasks by design. Anthropic has intentionally kept those capabilities gated in the restricted-access Mythos tier, and Opus 5's safety classifiers are tuned accordingly.

Best Tips for Getting the Most from Opus 5

Use the effort setting for your task type. Opus 5 comes with per-turn effort controls — including an xhigh reasoning mode. For simple tasks, use lower effort to save tokens and speed up the response. For deep debugging, root-cause analysis, or long research tasks, bump it up. The model's performance scales noticeably with effort level.

Let it verify its own work. One of the biggest shifts in Opus 5 is how it checks itself. In testing, it repeatedly caught its own errors during planning — before writing a single line of code. Trust the process, and give it room to think rather than rushing it toward an answer.

Use it for long agentic workflows. If you have been holding off on building multi-step AI agents because earlier models kept losing the thread halfway through, Opus 5 is worth trying again. Lovable reported 22% improvement over Opus 4.7 on their hardest agentic coding tasks, with significantly less run-to-run variance.

Pair it with Claude Code for serious engineering tasks. The Fast mode integration in Claude Code makes this combination a good fit for iterative build-debug cycles where you need both speed and depth.

Developers: check out the two new beta features. Mid-conversation tool changes let you swap which tools Claude can use mid-session without breaking your prompt cache. Automatic fallbacks route flagged requests to the best available model instead of returning a block. Both are useful for production agentic systems.

Common Mistakes to Avoid

Treating every task the same. Opus 5 is powerful, but that does not mean you should use max-effort mode for a simple summary or a quick code snippet. Match the effort to the task. The model is efficient by design — use that.

Expecting it to replace human judgment on risky decisions. Opus 5 is notably more honest about its own uncertainty and limitations than previous versions. It will push back on bad designs (early testers reported it holding its ground in code reviews rather than just agreeing). That is a feature, not a flaw. Let it.

Ignoring the safety fallback settings. If you are building production systems, set up the automatic fallback option on the API. It routes classifier-flagged requests to the best available model automatically, so you do not end up with unexpected blocks in your workflow.

Assuming your old prompts still need heavy optimization. Opus 5 is more instruction-following and better at picking up intent from context. Prompts that needed heavy engineering to work with earlier models may now work more simply. Test before you over-engineer.

Confusing Opus 5 with a niche research model. Some people mentally categorize the Opus tier as "the expensive one for edge cases." Opus 5 is specifically designed to be an everyday model — it's the default on Claude Max precisely because Anthropic built it to work efficiently across normal daily usage.

Conclusion

Claude Opus 5 is a meaningful upgrade in every area that matters for practical developer and knowledge work: coding performance, agentic reliability, reasoning depth, and alignment. It delivers frontier-adjacent intelligence at the same price as its predecessor, which is the kind of thing that actually changes how people build.

If you are already using Claude, you are likely already on Opus 5. If you are using the API and want to try it explicitly, the model string is claude-opus-5. Pricing is $5 per million input tokens and $25 per million output tokens — unchanged from Opus 4.8.

The AI field is moving fast, and it is not always easy to tell which updates are genuinely meaningful versus just marketing. This one is real. 💡

Want more breakdowns like this one? Check out hamidrazadev.com for practical developer content on AI tools, frontend development, and everything in between. If this post helped you, share it with a developer friend — it genuinely helps the community grow. Drop a comment below if you have questions or have already been testing Opus 5 in your own projects. Would love to hear what you find. 👀

VS Code 1.131 Is Here — And It Just Got a Whole Lot Smarter 🚀

Muhammad Hamid Raza — Wed, 29 Jul 2026 16:54:50 +0000

VS Code dropped another update, and honestly? This one hits differently.

If you've been using AI agents in your editor, you already know the struggle — multiple subagents running in the background, no idea what they're doing, your terminal talking over your screen reader, and your Markdown file just sitting there silently judging you.

VS Code 1.131, released July 29, 2026, tackles exactly these pain points. This release is quietly one of the most developer-experience-focused updates in a while, even if the changelog doesn't scream it.

So, what's new? And should you care? Let's find out.

What Is VS Code 1.131?

VS Code 1.131 is the latest stable release of Visual Studio Code — Microsoft's wildly popular, open-source code editor used by millions of developers worldwide.

Every few weeks, the VS Code team ships updates that range from tiny bug fixes to full architecture overhauls. Version 1.131 lands somewhere in the middle — a meaningful release that pushes agent tooling, accessibility, and built-in AI features forward without breaking your entire workflow.

The headline features this time around are:

More visibility into running subagents in the Agents window
Built-in dictation (no extension needed anymore)
A hybrid Markdown editor in the Agents window

There's also important work happening under the hood with the new Agent Host architecture, and small but useful wins for Python developers and accessibility users.

Let's walk through each one.

Why This Release Matters

Here's the thing about developer tools — the best updates aren't always the flashiest ones. They're the ones that fix the small friction points you didn't even realize were slowing you down.

VS Code 1.131 is full of those.

If you're using AI agents to help with your code, you've probably experienced the "black box" problem: a subagent is running, you know something is happening, but you have no idea if it's been going for 3 seconds or 3 minutes, or what it's even doing right now.

That's now fixed.

If you've ever wanted to just speak your chat prompt instead of typing it — and you didn't want to hunt down an extension, install it, configure it, and pray it works — that's now also fixed.

And if you write Markdown in VS Code and work inside the Agents window, there's a new hybrid editor that lets you read, write, and even leave comments that your agent can act on.

Small changes. Real impact.

What's New in VS Code 1.131 — Feature by Feature

👀 Subagents: Finally, Some Visibility

When your agent delegates a task to a subagent (like running a parallel search or analysis), you can now see what's happening without opening the subagent's full conversation.

Right in the Agents window, each running subagent shows:

Which model it's using
How long it's been running
Which tool it's actively calling at that moment

That last one is huge. Instead of staring at a spinner wondering if something froze, you can see "Oh, it's running readFile right now." That's the kind of transparency that actually builds trust in agent tooling.

You can still click into any subagent to read its full conversation, while the parent conversation stays right where you left it.

🎙️ Built-In Dictation (Experimental)

This one surprised me.

VS Code now has built-in dictation — no VS Code Speech extension required. You can dictate in:

Chat inputs
Text editors
The integrated terminal

All three surfaces share one microphone session, which means no overlapping recordings and no "wait, where did that text go?" moments.

The transcription model is Nemotron, which runs completely offline on your device. Your audio never leaves your machine. It downloads the model on first use, and that's it.

A couple of settings worth knowing:

dictation.showTranscript — shows a live transcript as you speak
dictation.experimental.llmCleanup — lets Copilot clean up filler words and add formatting to your transcript as you go

Platform support right now:

Windows x64 and Arm64 ✅
macOS Apple Silicon ✅
Linux x64 and Arm64 (glibc 2.34+) ✅

Not supported yet: VS Code for the Web, Intel-based Macs, and 32-bit/Arm32 systems. More platforms are in progress.

📝 Hybrid Markdown Editor (Experimental)

The Agents window now has a hybrid Markdown editor. Instead of staring at raw .md syntax, you can:

View your Markdown as rendered output
Edit it in-place
Add comments that your agent can act on

You can switch between the regular text editor and this new hybrid view using Reopen Editor With — works both in the Agents window and in regular editor windows.

This is still experimental, but if you write docs, READMEs, or spec files inside your agent workflow, it's already genuinely useful.

🏗️ Agent Host Architecture (Under the Hood)

This one's a bigger deal than it sounds.

VS Code is rearchitecting how agent sessions work around something called the Agent Host — a dedicated process that runs agent harnesses like Copilot, Claude, and Codex using the Agent Host Protocol (AHP).

What does that mean practically?

Because each session lives in its own process, the same agent session can now be connected to and rendered from multiple VS Code windows at once. That's a pretty significant architectural unlock for complex workflows.

To try it early: enable chat.agentHost.enabled and select an agent host harness from the harness dropdown.

It's rolling out gradually, so don't panic if you don't see it yet.

🐾 VS Code Pet (Very Experimental)

Okay, this one's just fun.

Type /vscode-pet in chat to meet your new VS Code companion. That's literally all we know. Go discover it yourself. 😊

♿ Accessibility: Quieter, Smarter Terminal Updates

Screen reader users get a useful improvement in this release.

The new setting terminal.integrated.accessibleViewPreserveCursorPosition (set to always) keeps your cursor position in the terminal Accessible View steady even when new output arrives. You can read at your own pace without the view jumping around.

On top of that, terminal live updates now use non-interrupting ARIA status announcements instead of assertive alerts, so output is available to screen readers without constantly interrupting other speech.

Small change. Big difference for accessibility.

🖥️ Control the Terminal Resize Overlay

You know that columns-by-rows overlay that pops up when you resize the terminal? Turns out, some people find it distracting.

You can now disable it entirely with:

terminal.integrated.resizeDimensionsOverlay.enabled

Set it to false and it's gone. Change applies immediately to open terminals — no restart needed.

🐍 Python: Faster Startup, Smarter Environments

Python Environments is now the default environment-management experience in both VS Code Stable and Insiders, having hit 100% rollout.

The key improvements:

Conda discovery is deferred until actually needed
Concurrent environment scans are consolidated instead of running separately
Pylance can now use the last-known interpreter while a full refresh continues in the background

Translation: Python projects start faster. You spend less time waiting and more time coding.

VS Code 1.131 vs 1.130 — What Actually Changed

Area	Before (1.130)	After (1.131)
Subagent visibility	Open conversation to check progress	See model, time, and tool inline
Dictation	Required Speech extension	Built-in, offline, no extension needed
Markdown in Agents	Raw text editor only	Hybrid view with rendered preview + comments
Terminal resize overlay	Always visible	Optional, can be disabled
Screen reader updates	Assertive/interrupting alerts	Non-interrupting ARIA status
Python startup	Full environment scan every time	Deferred Conda, faster launch

Tips for Getting the Most Out of 1.131

💡 Try dictation in your next chat prompt. Even if you type fast, speaking a long system prompt or context block can be faster. Enable it, speak naturally, let LLM cleanup do the rest.

💡 Explore the Agent Host early. Enable chat.agentHost.enabled and experiment with it before it becomes the default. Getting familiar now will save you confusion later.

💡 Use subagent visibility as a debugging signal. If a subagent has been calling the same tool for two minutes, something might be stuck. You'll now catch it without opening its full conversation.

💡 Don't force the hybrid Markdown editor everywhere. It's best in the Agents window when you're working on docs your agent needs to reference or modify. For regular editing, the text editor is still faster.

💡 Update immediately. VS Code is rolling out gradually. Use Check for Updates from inside VS Code if you don't want to wait.

Common Mistakes to Avoid with These New Features

Forgetting dictation is platform-limited.
If you're on an Intel Mac or VS Code for the Web and wondering why built-in dictation isn't showing up — that's why. Check the platform support list before assuming it's broken.

Expecting agent host to be fully stable.
It's still rolling out. Some behaviors might feel unpolished. Enable it to explore, but don't build critical workflows around it just yet.

Leaving dictation.experimental.llmCleanup enabled on a slow connection.
The cleanup feature sends your transcript to a language model. If your connection is spotty, the cleanup step might lag or fail. VS Code falls back to the raw transcript, but it's worth knowing how it works.

Ignoring the subagent model info.
That little detail — which model your subagent is using — matters more than you'd think. If a subagent is using a slower or weaker model than you expected, you'll now catch it at a glance.

Wrapping Up

VS Code 1.131 isn't a flashy update. There's no headline-stealing new feature that everyone will screenshot and post about.

But it's a solid one.

Better agent transparency, built-in offline dictation, a smarter Markdown experience, faster Python startup, and thoughtful accessibility improvements — all in one release. That's the kind of steady, deliberate progress that makes a tool genuinely great to use every day.

If you haven't updated yet, open VS Code and hit Check for Updates. Or grab the Insiders build if you want to stay on the bleeding edge.

For more developer content, tips, and breakdowns like this one, check out hamidrazadev.com — I write regularly about the tools, workflows, and features that actually matter to working developers.

If this post saved you some scroll time through the changelog, share it with a developer friend who'll appreciate it. 🙌

How to Set Up Prettier in Next.js (With Every Error Fixed Step by Step)

Muhammad Hamid Raza — Mon, 27 Jul 2026 12:06:15 +0000

You just started a fresh Next.js project. Your code looks messy. Your tabs and spaces are at war. A teammate opens the same file and now there are 47 formatting "changes" in the diff — even though nothing actually changed.

Sound familiar? 😅

That's exactly why Prettier exists. It's a code formatter that takes your messy code and makes it clean, consistent, and predictable. Every time. Automatically.

But setting it up in a modern Next.js project isn't always smooth. Especially if you're using ESLint Flat Config (eslint.config.mjs), TypeScript, Tailwind CSS, and pnpm. The internet is full of outdated tutorials that either miss steps or don't tell you what to do when things break.

This guide covers the full setup and every real error you might run into — with exact fixes for each one.

Let's get into it. 🚀

What Is Prettier?

Prettier is an opinionated code formatter. You give it your code, it gives it back — clean, consistent, and formatted exactly the way you configured it.

Think of it like autocorrect for your code. You type fast and messy, and Prettier quietly cleans up after you before you even notice.

It handles things like:

Consistent use of single or double quotes
Trailing commas
Semicolons at the end of lines
Line length limits
Indentation width

Prettier doesn't care about logic or bugs — that's ESLint's job. Prettier only cares about how your code looks.

Why This Matters

Inconsistent formatting is a silent killer of team productivity. One developer uses tabs, another uses spaces. One prefers single quotes, the other uses double quotes. The result? Git shows hundreds of "changes" in every pull request that are just formatting noise — not actual code changes.

Prettier solves this completely. Once it's set up:

Every file gets formatted the same way, every time
Your team stops fighting over style preferences
Code reviews focus on logic, not formatting
Tailwind class orders stay consistent with prettier-plugin-tailwindcss
VS Code can format your file automatically every time you save

The setup is a one-time cost that saves you time forever.

Full Setup Guide (Step by Step)

Step 1: Install Prettier and Its Plugins

Open your terminal in your project root and run:

pnpm add -D prettier eslint-config-prettier prettier-plugin-tailwindcss

Here's what each package does:

prettier — The core formatter
eslint-config-prettier — Turns off ESLint formatting rules that conflict with Prettier
prettier-plugin-tailwindcss — Automatically sorts your Tailwind CSS classes in the correct order

Step 2: Create Your Prettier Config

In your project root, create a file called .prettierrc:

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100,
  "plugins": ["prettier-plugin-tailwindcss"]
}

What each option does:

semi — Adds semicolons at the end of statements
singleQuote — Uses ' instead of " for strings
tabWidth — Uses 2 spaces for indentation
trailingComma: "es5" — Adds trailing commas where valid in ES5 (arrays, objects)
printWidth — Wraps lines longer than 100 characters
plugins — Activates the Tailwind class sorting plugin

Step 3: Create a `.prettierignore` File

You don't want Prettier touching generated files, build outputs, or lock files. Create .prettierignore in your project root:

.next
node_modules
public
pnpm-lock.yaml
docs

Step 4: Add npm Scripts

Open your package.json and add these scripts:

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint",
  "format": "prettier --write .",
  "format:check": "prettier --check ."
}

pnpm format — Formats every file in your project
pnpm format:check — Checks formatting without changing files (great for CI)

Step 5: Update Your ESLint Config

Open your eslint.config.mjs and add eslint-config-prettier at the end of your config array:

import eslintConfigPrettier from 'eslint-config-prettier';

export default [
  // ... your existing ESLint rules
  eslintConfigPrettier,
];

This must go last in the array. It disables ESLint rules that would conflict with Prettier's formatting decisions.

Step 6: VS Code Auto-Format on Save (Optional but Highly Recommended)

Create or update .vscode/settings.json in your project root:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

Make sure you have the Prettier - Code formatter extension installed in VS Code (esbenp.prettier-vscode).

Now every time you hit Ctrl + S, your file gets formatted automatically. ✅

Debugging Every Error (The Real Journey)

Here's where most tutorials stop — and where developers get stuck. Let's fix every error you might hit.

🔴 Error 1: `Invalid project directory provided, no such directory: portfolio\lint`

Full error:

$ next lint
Invalid project directory provided, no such directory: H:\...\portfolio\lint
[ELIFECYCLE] Command failed with exit code 1.

Why it happens:

In Next.js 15/16 (and sometimes 14.2+), the CLI argument parser has a known bug where it misreads lint as a directory path instead of a subcommand — especially when using ESLint Flat Config (eslint.config.mjs). So it looks for a folder called lint and fails.

The fix:

Change your lint script in package.json to call ESLint directly:

"scripts": {
  "lint": "eslint ."
}

If ESLint isn't already installed locally, run:

pnpm add -D eslint

Then run:

pnpm run lint

This bypasses Next's CLI argument parser entirely. It's faster, cleaner, and fully compatible with ESLint v9+ and Flat Config.

🔴 Error 2: `TypeError: Converting circular structure to JSON`

Full error:

TypeError: Converting circular structure to JSON
  --> starting at object with constructor 'Object'
  |   property 'configs' -> object with constructor 'Object'
  |   property 'flat' -> object with constructor 'Object'
  |   ...
  |   property 'plugins' -> object with constructor 'Object'
  --- property 'react' closes the circle

Why it happens:

Your eslint.config.mjs is using FlatCompat to extend "next/core-web-vitals". Under the hood, FlatCompat from @eslint/eslintrc tries to serialize the config using JSON.stringify() to validate it. But eslint-plugin-react (included inside Next's config) contains circular object references — objects that point back to themselves. JSON.stringify() can't handle circular references, so it crashes.

The fix:

Drop FlatCompat entirely. Import @next/eslint-plugin-next directly.

First, install it:

pnpm add -D @next/eslint-plugin-next

Note for pnpm users: pnpm uses strict package isolation. Even if @next/eslint-plugin-next is used internally by eslint-config-next, pnpm won't hoist it to your root node_modules unless you explicitly install it. That's why you need to add it manually.

Then replace your eslint.config.mjs with this:

import nextPlugin from '@next/eslint-plugin-next';
import eslintConfigPrettier from 'eslint-config-prettier';

/** @type {import('eslint').Linter.Config[]} */
const eslintConfig = [
  {
    files: ['**/*.{js,mjs,cjs,ts,jsx,tsx}'],
    plugins: {
      '@next/next': nextPlugin,
    },
    rules: {
      ...nextPlugin.configs.recommended.rules,
      ...nextPlugin.configs['core-web-vitals'].rules,
    },
  },
  eslintConfigPrettier,
  {
    ignores: ['.next/**', 'node_modules/**', 'out/**', 'docs/**', 'public/**'],
  },
];

export default eslintConfig;

No FlatCompat. No circular JSON crash. Clean and native. ✅

🔴 Error 3: `Cannot find package '@next/eslint-plugin-next'`

Full error:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@next/eslint-plugin-next'
imported from H:\...\portfolio\eslint.config.mjs
Did you mean to import "@next/eslint-plugin-next/dist/index.js"?

Why it happens:

pnpm uses strict package isolation by design. It doesn't hoist nested dependencies to your root node_modules the way npm does. So even though @next/eslint-plugin-next is used internally by the next package, your code can't import it unless it's explicitly listed as your own dependency.

The fix:

Install it directly:

pnpm add -D @next/eslint-plugin-next

Run lint again:

pnpm run lint

🔴 Error 4: 155 TypeScript and JSX Parsing Errors

Sample errors:

app/_error.tsx  28:1  error  Parsing error: The keyword 'interface' is reserved
app/about/loading.tsx  5:9  error  Parsing error: Unexpected token <
app/api/ask/route.ts  15:52  error  Parsing error: Unexpected token ModelId

Why it happens:

ESLint's default parser is espree, which only understands plain JavaScript. It doesn't know TypeScript keywords like interface, type, or generics. It also doesn't know JSX syntax like <Component />. You need to tell ESLint to use @typescript-eslint/parser for your .ts and .tsx files.

The fix:

Install the TypeScript ESLint parser and plugin:

pnpm add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin

Then update your eslint.config.mjs to use the TypeScript parser:

import nextPlugin from '@next/eslint-plugin-next';
import tsParser from '@typescript-eslint/parser';
import tsPlugin from '@typescript-eslint/eslint-plugin';
import eslintConfigPrettier from 'eslint-config-prettier';

/** @type {import('eslint').Linter.Config[]} */
const eslintConfig = [
  {
    ignores: ['.next/**', 'node_modules/**', 'out/**', 'build/**', 'docs/**', 'public/**'],
  },
  {
    files: ['**/*.ts', '**/*.tsx', '**/*.js', '**/*.jsx'],
    plugins: {
      '@next/next': nextPlugin,
      '@typescript-eslint': tsPlugin,
    },
    languageOptions: {
      parser: tsParser,
      parserOptions: {
        ecmaFeatures: {
          jsx: true,
        },
      },
    },
    rules: {
      ...nextPlugin.configs.recommended.rules,
      ...nextPlugin.configs['core-web-vitals'].rules,
    },
  },
  eslintConfigPrettier,
];

export default eslintConfig;

Run lint again:

pnpm run lint

All 155 parsing errors disappear. ✅

🔴 Error 5: Circular JSON Error Returns After Re-Adding FlatCompat

Why it happens:

If at any point you re-introduce FlatCompat to extend "next/core-web-vitals" or "next/typescript", the circular JSON error comes back. FlatCompat is fundamentally incompatible with the current version of eslint-plugin-react bundled inside eslint-config-next and ESLint v9+.

The fix:

Do not use FlatCompat at all. The final working eslint.config.mjs below is the definitive version that handles everything — Next.js rules, TypeScript parsing, JSX, and Prettier compatibility — without touching FlatCompat or @eslint/eslintrc:

import nextPlugin from '@next/eslint-plugin-next';
import tsParser from '@typescript-eslint/parser';
import tsPlugin from '@typescript-eslint/eslint-plugin';
import eslintConfigPrettier from 'eslint-config-prettier';

/** @type {import('eslint').Linter.Config[]} */
const eslintConfig = [
  {
    ignores: ['.next/**', 'node_modules/**', 'out/**', 'build/**', 'docs/**', 'public/**'],
  },
  {
    files: ['**/*.ts', '**/*.tsx', '**/*.js', '**/*.jsx'],
    plugins: {
      '@next/next': nextPlugin,
      '@typescript-eslint': tsPlugin,
    },
    languageOptions: {
      parser: tsParser,
      parserOptions: {
        ecmaFeatures: {
          jsx: true,
        },
      },
    },
    rules: {
      ...nextPlugin.configs.recommended.rules,
      ...nextPlugin.configs['core-web-vitals'].rules,
    },
  },
  eslintConfigPrettier,
];

export default eslintConfig;

This is the config that works. Keep it and don't look back.

Pros and Cons: `FlatCompat` vs Native Flat Config

	`FlatCompat`	Native Flat Config
Works with ESLint v9+	❌ Often breaks	✅ Fully supported
TypeScript support	Needs extra setup	✅ With `@typescript-eslint/parser`
pnpm compatibility	❌ Circular JSON crash	✅ Works perfectly
Code complexity	More boilerplate	✅ Cleaner and simpler
Recommended for new projects	❌ No	✅ Yes

If you're starting a Next.js project today, go native Flat Config from day one. FlatCompat was a bridge for legacy configs — it's not meant to be the destination.

Final File Checklist

Here's everything you should have set up:

.prettierrc (project root)

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100,
  "plugins": ["prettier-plugin-tailwindcss"]
}

.prettierignore (project root)

.next
node_modules
public
pnpm-lock.yaml
docs

eslint.config.mjs (project root)

import nextPlugin from '@next/eslint-plugin-next';
import tsParser from '@typescript-eslint/parser';
import tsPlugin from '@typescript-eslint/eslint-plugin';
import eslintConfigPrettier from 'eslint-config-prettier';

const eslintConfig = [
  {
    ignores: ['.next/**', 'node_modules/**', 'out/**', 'build/**', 'docs/**', 'public/**'],
  },
  {
    files: ['**/*.ts', '**/*.tsx', '**/*.js', '**/*.jsx'],
    plugins: {
      '@next/next': nextPlugin,
      '@typescript-eslint': tsPlugin,
    },
    languageOptions: {
      parser: tsParser,
      parserOptions: {
        ecmaFeatures: { jsx: true },
      },
    },
    rules: {
      ...nextPlugin.configs.recommended.rules,
      ...nextPlugin.configs['core-web-vitals'].rules,
    },
  },
  eslintConfigPrettier,
];

export default eslintConfig;

package.json scripts

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "eslint .",
  "format": "prettier --write .",
  "format:check": "prettier --check ."
}

.vscode/settings.json (optional but recommended)

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

Best Tips

Always put eslintConfigPrettier last in your ESLint config array. It needs to override any formatting rules that come before it.
Commit your .prettierrc to version control so every teammate uses the same formatting rules automatically.
Use pnpm format:check in your CI pipeline to catch unformatted code before it gets merged.
Install the Prettier VS Code extension (esbenp.prettier-vscode) — it makes the whole workflow seamless.
Never mix FlatCompat with native Flat Config imports in the same file. Pick one approach and stick with it.

Common Mistakes to Avoid

Mistake 1: Keeping next lint as your lint script

next lint uses Next.js's CLI parser, which has a known argument parsing bug in newer versions. Switching to eslint . directly is more stable and faster.

Mistake 2: Using FlatCompat in ESLint v9+ projects

FlatCompat tries to convert legacy ESLint configs. But eslint-plugin-react (bundled in eslint-config-next) now contains circular object references that crash JSON.stringify(). The fix is native Flat Config — no FlatCompat needed.

Mistake 3: Forgetting @next/eslint-plugin-next with pnpm

pnpm doesn't hoist nested packages. Even if next uses @next/eslint-plugin-next internally, you need to install it explicitly in your own package.json or the import will fail.

Mistake 4: Missing the TypeScript parser

ESLint's default parser doesn't understand TypeScript or JSX. If you don't set @typescript-eslint/parser as your languageOptions.parser, you'll get hundreds of "Unexpected token" errors on perfectly valid code.

Mistake 5: Not ignoring .next/ and node_modules/

ESLint will try to lint every file it can find unless you tell it otherwise. Always add ignores in your config and a .prettierignore file to skip build artifacts.

Wrapping Up

Setting up Prettier in a modern Next.js project isn't as simple as the docs make it look — especially once you add TypeScript, Tailwind CSS, ESLint Flat Config, and pnpm into the mix. But once it's working, it's one of the best quality-of-life improvements you can make to your workflow.

Here's a quick recap of what you did:

✅ Installed Prettier with Tailwind sorting and ESLint compatibility
✅ Created .prettierrc and .prettierignore
✅ Fixed the next lint path bug by calling eslint . directly
✅ Fixed the circular JSON crash by removing FlatCompat
✅ Fixed pnpm's strict isolation with a direct @next/eslint-plugin-next install
✅ Fixed 155 TypeScript parsing errors with @typescript-eslint/parser
✅ Set up VS Code to auto-format on every save

Your codebase is cleaner, your team stays consistent, and you never have to argue about tabs vs spaces again. 😊

If you found this guide helpful, share it with your team — chances are they've hit the same errors too. And for more practical dev guides, visit hamidrazadev.com where I write about real-world frontend development, Next.js, TypeScript, and more.