DEV Community: Muhammad Hamid Raza

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.

Why Claude Has Stricter Limits Than Other AIs — and Why That's Exactly What Makes It Great

Muhammad Hamid Raza — Sun, 26 Jul 2026 16:48:03 +0000

You asked Claude to do something. It paused. It thought carefully. And then it gave you a response so clean and well-structured that you actually read the whole thing.

Meanwhile, some other AI just confidently made up a court case that never happened. 😬

There's a pattern here worth exploring. Claude has real limits — on tokens, on behaviors, on what it will and won't do. And at first glance, that can feel frustrating. But the more you work with it, the more you realize: those limits aren't bugs. They're the whole point.

So what's actually going on? Why does Claude hold itself back in ways other AIs don't — and why does that restraint make it one of the most trusted AI models available today?

Let's break it all down.

What Are Tokens, and Why Do They Matter?

Before we talk about limits, let's make sure we're on the same page about what a "token" actually is.

A token is basically a chunk of text. It could be a word, part of a word, or even a single character — depending on how the AI splits it. When you type a message to Claude, your message gets converted into tokens. When Claude replies, that reply is also made of tokens.

Every AI model has a context window — the total number of tokens it can "see" at once, including your entire conversation history. Think of it like working memory. Once you go over the limit, older parts of the conversation start falling out of view.

Claude's context window is large. Claude 3 models support up to 200,000 tokens — that's enough to process an entire novel. For most real-world tasks, that's more than plenty.

But here's the thing: having a big window isn't the only thing that matters. What the model does inside that window — how carefully it reasons, how honestly it responds — matters far more.

Claude Does Have Limits. Let's Be Honest About Them.

It would be easy to just hype Claude up and ignore the trade-offs. That's not the goal here.

Claude has genuine constraints:

Rate limits on free tiers that can slow heavy usage
Stricter content policies that mean it'll decline certain requests
No live internet access by default in its base form
Refusals for tasks it deems harmful, even when the request seems reasonable to you

Some users find this annoying. There are moments where you're mid-project and Claude pumps the brakes in a way that feels overcautious.

That's a real friction point. No sugarcoating.

But let's zoom out and look at why those limits exist — because that context changes everything.

Why Claude's Limits Exist: The Bigger Picture

Anthropic, the company behind Claude, was founded with one specific goal: to build AI that is safe and beneficial for humanity. Not just powerful. Not just impressive. Actually trustworthy and safe.

That mission shapes every design decision.

Claude is built using an approach called Constitutional AI (CAI). Instead of just training the model to be helpful and hoping for the best, Anthropic gave Claude a set of principles — a kind of internal compass — and trained it to evaluate its own outputs against those principles.

This is why Claude:

Won't help you build something harmful, even if you phrase the request cleverly
Tells you when it's uncertain instead of guessing confidently
Declines tasks it finds ethically problematic, even under pressure
Tries to be honest even when honesty is uncomfortable

These aren't accidental behaviors. They're intentional design.

The limits aren't weakness. They're integrity.

Why This Matters for Developers and Everyday Users

Let's get practical. Why should you care about any of this?

Because when you ship something to production — or when you hand a tool to someone who depends on it — reliability and honesty matter more than raw output speed.

Here's what Claude's approach delivers in practice:

✅ You Can Trust the Output More

Claude is designed to say "I don't know" or "I'm not sure" rather than fabricating an answer. For developers using Claude in apps, this is huge. A confidently wrong AI is genuinely dangerous. A carefully honest one is useful.

✅ Refusals Protect You Too

That moment Claude refuses a request? Sometimes it's protecting your users, your reputation, or your product from going somewhere it shouldn't. AI that agrees with everything isn't a feature — it's a liability.

✅ Long-Context Performance That Holds Up

A 200K token context window isn't just a number. Claude actually maintains coherence across that entire window. Some models advertise large windows but degrade badly toward the end. Claude's performance stays consistent — that's the engineering quality underneath the limits.

✅ Better Reasoning, Not Just More Output

Claude is consistently ranked among the top models in reasoning, coding, and nuanced writing tasks. It's not because it produces the most text. It's because it thinks more carefully before producing any.

Claude vs Other AI Models: A Fair Comparison

Feature	Claude	Some Competitors
Context Window	Up to 200K tokens	Varies widely
Refusal on harmful requests	Yes, by design	Varies by model
Honesty about uncertainty	Strong	Inconsistent
Constitutional safety layer	Yes (CAI)	Rare
Raw speed on free tier	Moderate	Sometimes faster
Reasoning quality	Top-tier	Varies

This table isn't here to say Claude is perfect at everything. It isn't. There are tasks where other models are faster, cheaper, or more permissive.

But if your priority is a model you can actually trust — one that won't hallucinate facts, won't agree with bad ideas just to seem helpful, and won't put harmful content in front of your users — Claude's design philosophy is a real advantage.

Tips: Getting the Most Out of Claude Within Its Limits

Working with Claude's design rather than against it makes a massive difference.

💡 Be specific in your prompts. Claude responds better to clear, detailed instructions than vague ones. The more context you give, the better the output.

💡 Respect the refusals — then rephrase. If Claude pushes back, it's often because the prompt is ambiguous or hits a sensitive area. Try rephrasing with more context about what you actually need and why.

💡 Break large tasks into smaller chunks. Even with a 200K context window, long tasks benefit from being broken into steps. Treat Claude like a thoughtful collaborator, not a magic button.

💡 Use Claude for tasks that need trust. Code review, writing analysis, research summaries, customer-facing copy — these are areas where Claude's careful, honest output shines.

💡 Don't fight the safety features. If a certain task keeps getting refused, ask yourself honestly if the output could be misused. Often, Claude is catching something worth catching.

Common Mistakes People Make With Claude

❌ Assuming limits mean low quality

Some users equate more permissiveness with higher quality. It's actually the opposite. A model that will do anything isn't more capable — it's less trustworthy.

❌ Hitting rate limits and blaming the model

Rate limits on free tiers exist because inference is expensive. They're not a reflection of Claude's capabilities. Upgrading to a paid plan removes most of these friction points.

❌ Prompting vaguely and expecting perfection

Claude isn't a mind reader. If your prompt is a half-sentence, you'll get a half-baked result. Invest 30 extra seconds in your prompt and watch the output quality jump.

❌ Comparing outputs without comparing task types

"ChatGPT did this and Claude wouldn't" is only meaningful if you're comparing the same task. Different models make different trade-offs. Claude's trade-offs favor safety and accuracy. That matters for some use cases more than others.

❌ Ignoring Claude's uncertainty signals

When Claude says "I'm not certain about this" — listen. That's a feature. Don't override it. Verify the information instead.

Conclusion: Limits Are Part of the Design. That's the Point.

Here's the honest truth: Claude has limits. It refuses some things. It has rate caps. It doesn't always do what you want on the first try.

But those limits reflect a deliberate choice to build AI that is careful, honest, and trustworthy — not just fast and agreeable.

In a world full of AI models racing to do more, say more, and agree with more, Claude's restraint is actually rare. And increasingly, that restraint is exactly what developers, companies, and everyday users are looking for.

Because the goal was never to build the most talkative AI. The goal was to build one you can actually rely on. 🚀

If this post helped you see Claude's design in a new light, I'd love for you to share it. You can find more developer content, tutorials, and AI breakdowns at hamidrazadev.com — drop by whenever you want practical, honest tech content written by someone who actually builds with these tools.

VS Code 1.130 Is Here — And It Makes AI-Assisted Coding Feel Way Less Annoying

Muhammad Hamid Raza — Fri, 24 Jul 2026 12:57:27 +0000

If you've ever been deep in an AI-assisted coding session and got interrupted by one approval popup after another, you know the pain. It's like trying to watch a movie and someone keeps pausing it to ask, "Are you sure? Are you really sure?"

VS Code 1.130, released on July 22, 2026, quietly fixes a lot of those friction points. And along the way, it brings some genuinely useful upgrades to agent workflows, chat visibility, terminal file links, and more.

So — what actually changed, and does any of it matter in your daily dev life? Let's walk through it. 🚀

What Is VS Code 1.130?

VS Code releases updates on a regular cadence. Version 1.130 is the latest stable release, and it's focused heavily on making AI agent sessions smoother and more manageable.

If you use GitHub Copilot, Claude, or Codex inside VS Code, this update is directly relevant to your workflow. Even if you don't, there are quality-of-life improvements worth knowing about.

Why This Release Matters

The way we write code is changing fast. AI coding agents now handle multi-file edits, run terminal commands, and take actions on your behalf — all inside the editor.

But managing those agents has been clunky. You'd approve tool after tool manually, get lost in long diff views, and lose track of what the agent actually changed.

VS Code 1.130 addresses these pain points directly. The team has rearchitected how agent sessions work, improved how you review changes, and added smarter ways to handle approvals.

If AI-assisted coding is already part of your workflow, this update makes it noticeably cleaner. If it isn't yet, now is a good time to start paying attention.

What's New in VS Code 1.130

🔧 The Agent Host — A Smarter Foundation for AI Sessions

The biggest architectural change in this release is the agent host.

Think of it like moving your AI coding session into its own dedicated room, instead of running it in the same crowded space as everything else. The agent host is a separate process that runs agent harnesses — including Copilot, Claude, and Codex — based on the Agent Host Protocol (AHP).

Why does that matter? Because now the same agent session can be connected to and rendered from multiple VS Code windows at once. You can have your agent running in one window and check its progress from another — no need to restart or duplicate work.

The Copilot agent on the agent host is also powered by the Copilot SDK, which aligns it with the Copilot CLI, the standalone GitHub Copilot app, and other Copilot products. This means more consistent behavior across tools.

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

✅ Assisted Tool Approvals — Fewer Interruptions, Smarter Decisions

Setting: chat.assistedPermissions.enabled

Here's the one that's going to save you the most frustration.

When an AI agent runs a task, it often calls multiple tools along the way — reading files, running commands, making edits. Each tool call can trigger an approval prompt. On a long-running task, those prompts stack up fast and break your flow.

With assisted tool approvals, the language model itself evaluates the risk level of each tool call. Low-risk actions can run automatically. Only genuinely risky actions ask for your approval.

It's like having a capable assistant who uses good judgment — they handle the routine stuff and only interrupt you when something actually needs your sign-off.

Enable the setting to add Assisted permissions to the permissions picker for agents running on the agent host.

👀 Agents Window Improvements (Preview)

The Agents window got a meaningful round of upgrades. Here's what changed:

File-level diff statistics
Each file header in the Changes editor now shows live insertion and deletion counts next to the file path. No more guessing how much each file changed — you can scan a multi-file diff and immediately know which files were touched heavily and which had minor edits.

Compact multi-file diff view
The diff view now uses a tighter gutter layout. Empty space before the code is removed. File headers, line numbers, and unchanged-region controls share consistent alignment. More room for actual code review — especially helpful on narrower screens.

Compact quick chats
Quick chats now appear as single-line rows in the sessions list. Regular sessions still show a second line with stats, status, and timestamps. This makes it easier to tell quick chats from full project sessions at a glance.

Worktree support for all agent harnesses
Previously, the New Worktree checkbox in the Agents window only worked with the Copilot harness. Now Claude and Codex sessions also support Git worktrees, so you can spin up parallel sessions for different features in the same workspace — regardless of which agent you're using.

💬 Chat Timestamps

Setting: chat.verbose

Small addition, surprisingly useful. Chat requests and responses now show timestamps. You can hover over the message toolbar to see when an interaction happened and how long it took.

If you've ever come back to a chat session and had no idea whether those edits were from two minutes ago or two hours ago, this solves that problem. You can disable it with chat.verbose if you prefer a cleaner view.

📊 Aggregate AI Credit Usage for Copilot Business and Enterprise

If your organization uses Copilot Business or Copilot Enterprise, you can now see your total AI credit usage for the current billing cycle directly in the Copilot status menu.

Before this change, credit usage only appeared when you had a user-level budget configured. Most org-managed users had no way to see how many credits they'd consumed.

Now, even without a user-level budget set, the status menu shows the total credits used so far in the billing cycle. It's a small thing, but it helps you understand your usage without leaving the editor.

⚡ Clickable File Links in Git Diffs with Mnemonic Prefixes

This one's for terminal users.

When Git's diff.mnemonicPrefix option is enabled, Git diff output uses prefixes like i/ for the index and w/ for the working tree. These look informative but have historically made file paths in terminal output non-clickable.

VS Code 1.130 now recognizes those prefixes and removes them from the link target so the correct file opens when you click. VS Code also handles the numeric 1/ and 2/ prefixes produced by git diff --no-index.

If you rely on terminal-based Git workflows, this removes a small but real piece of friction.

🏗️ TypeScript 7 — Under the Hood

The VS Code codebase is now compiled using the release version of TypeScript 7. The team also switched to the TypeScript 7 extension.

This is an engineering milestone more than a user-facing feature, but it signals a big step in the TypeScript ecosystem. If you want to read more, the TypeScript team published a full release announcement worth checking out.

Before vs. After: Agent Workflows in VS Code

Before 1.130	After 1.130
Approval prompt for every tool call	Model evaluates risk; low-risk calls run automatically
Agent session tied to one window	Same session visible from multiple windows
Worktrees only for Copilot harness	Worktrees work for Claude and Codex too
No timestamps in chat	Timestamps visible on hover
Mnemonic prefix paths not clickable in terminal	Clickable and correctly resolved
Credit usage hidden without user budget	Total usage shown in status menu

Best Tips for Getting the Most Out of VS Code 1.130

💡 Enable the agent host gradually. It's still rolling out and some features require it. Start by enabling chat.agentHost.enabled and testing your preferred harness.

💡 Try assisted permissions on a low-stakes project first. It's a smart feature, but get familiar with how the model evaluates risk before relying on it for critical tasks.

💡 Use worktrees for parallel feature work. Now that Claude and Codex support them, you can run separate agent sessions for different branches without interfering with your main workspace.

💡 Check the Copilot status menu if you're on a Business or Enterprise plan. Knowing your credit usage in real time helps you plan more effectively.

💡 Enable mnemonic prefixes in Git if you use the terminal heavily. The clickable link support makes diff navigation genuinely faster.

Common Mistakes to Avoid

Skipping the update and wondering why new features aren't showing up.
VS Code 1.130 is rolling out gradually. If you want it immediately, use Check for Updates in VS Code. Or download the Insiders build if you always want the latest.

Enabling assisted permissions and forgetting about it.
This feature is smart, but it's not infallible. The model makes judgment calls. Keep an eye on what runs automatically, especially in the early days of using it.

Confusing quick chats and project sessions in the Agents window.
The compact row style makes quick chats visually distinct from regular sessions. Take a few minutes to understand the new layout so you don't accidentally close a session you wanted to keep.

Ignoring the chat timestamp feature.
It sounds minor. But if you run long sessions or collaborate on the same workspace, knowing when an AI interaction happened can save real debugging time.

Wrapping Up

VS Code 1.130 isn't a flashy release, but it's a thoughtful one. The team is building toward a more stable, more capable foundation for AI-assisted development — and the improvements in this release show real progress.

The agent host architecture is the biggest story here. It's still rolling out, but once it lands fully, it's going to change how agent sessions feel in a meaningful way. Fewer interruptions, more visibility, better multi-harness support — it all adds up.

If you work with AI coding agents regularly, update today and explore the new settings. The improvements are subtle but genuinely useful.

And if you're just starting to explore AI-assisted coding in VS Code, this is a solid time to dive in. The tooling is getting better with every release. 😊

Happy coding — and as always, keep building things that matter.

Want more practical dev content like this? Head over to *hamidrazadev.com** for more articles, guides, and resources. If this post saved you some time or taught you something new, share it with a fellow developer — it goes a long way.* 🙌

Folder Structures Explained: The Right Way to Organize Any Project (Any Language, Any Framework)

Muhammad Hamid Raza — Fri, 24 Jul 2026 08:13:08 +0000

Have you ever opened a project someone else wrote and thought, "What is even happening here?" 😅

Files dumped in the root. Folders named stuff, temp2, and final_FINAL. No clear pattern. Nothing where you expect it.

We've all been there — and honestly, most of us have created that mess at least once. The good news? Folder structure is a skill. Once you learn it, your projects feel instantly more professional, easier to debug, and way less stressful to work with.

So, whether you're building a React app, a Django API, a mobile app, or a simple CLI tool, this guide will show you the folder structures that actually work — and why they work.

What Is a Folder Structure?

A folder structure is the way you organize your project's files and directories on disk.

Think of it like organizing a kitchen. If your spices are in one spot, your pots in another, and your cutting boards hung up neatly, cooking is easy. But if everything is scattered around randomly, even making toast becomes stressful.

Your code project is the same. A good folder structure tells every file where it belongs — and tells every developer (including future-you) where to find it.

Why Folder Structure Actually Matters

Bad folder structure isn't just ugly. It causes real problems:

Debugging takes longer because you can't find the file that's causing the issue.
Onboarding new developers is painful when nobody can figure out the layout.
Scaling your project becomes hard because you have no room to grow cleanly.
AI coding agents like Cursor and bolt.new work better when your project is organized. They navigate your code more accurately and make fewer mistakes.

A good structure saves hours every week. It's one of those habits that pays you back constantly.

The 5 Most Common Folder Structures (With Examples)

Let's go through the main types you'll encounter — and when to use each one.

1. 🗂️ Flat Structure

What it looks like:

my-project/
├── index.js
├── utils.js
├── styles.css
├── db.js
└── README.md

Best for: Small scripts, quick prototypes, or learning projects. Nothing more.

Why it works: Zero overhead. You just write code.

Why it fails: The moment your project grows beyond 10 files, this becomes a nightmare. Everything is mixed together with no organization.

Use this only when you know the project will never grow.

2. 📁 Layer-Based Structure (MVC / Separation of Concerns)

What it looks like:

my-project/
├── controllers/
│   ├── userController.js
│   └── productController.js
├── models/
│   ├── userModel.js
│   └── productModel.js
├── views/
│   ├── home.html
│   └── dashboard.html
├── routes/
│   └── index.js
├── middleware/
│   └── auth.js
└── app.js

Best for: Backend APIs, Node.js/Express apps, Django, Laravel, Ruby on Rails.

Why it works: You always know where something lives based on what it does. Controllers do one job. Models do another. Clean separation.

Real example: When you get a bug report saying "the login is broken," you go straight to controllers/userController.js. No hunting required.

3. 🧩 Feature-Based Structure

What it looks like:

src/
├── features/
│   ├── auth/
│   │   ├── AuthPage.jsx
│   │   ├── authSlice.js
│   │   ├── authService.js
│   │   └── auth.test.js
│   ├── dashboard/
│   │   ├── DashboardPage.jsx
│   │   ├── dashboardSlice.js
│   │   └── dashboardService.js
│   └── products/
│       ├── ProductList.jsx
│       ├── productSlice.js
│       └── productService.js
├── shared/
│   ├── components/
│   ├── hooks/
│   └── utils/
└── main.jsx

Best for: React, Vue, Angular apps. Medium to large frontend projects. Any app where features grow over time.

Why it works: Everything about one feature lives together. When you work on the auth feature, you open the auth/ folder and never leave it. No jumping between five unrelated directories.

This is the structure most senior developers recommend for modern frontend projects. ✅

4. 🏗️ Domain-Driven Structure

What it looks like:

src/
├── domain/
│   ├── user/
│   │   ├── User.ts
│   │   ├── UserRepository.ts
│   │   └── UserService.ts
│   └── order/
│       ├── Order.ts
│       ├── OrderRepository.ts
│       └── OrderService.ts
├── infrastructure/
│   ├── database/
│   └── email/
├── application/
│   └── useCases/
└── presentation/
    └── api/

Best for: Large-scale enterprise applications, microservices, TypeScript monorepos.

Why it works: Each business domain (user, order, product) is completely self-contained. Teams can own domains independently. Scaling is clean.

Why it's not for beginners: The overhead is real. Don't use this for a to-do app. Use it when your business logic is genuinely complex.

5. 📦 Monorepo Structure

What it looks like:

my-monorepo/
├── apps/
│   ├── web/
│   ├── mobile/
│   └── admin/
├── packages/
│   ├── ui/
│   ├── utils/
│   └── config/
├── package.json
└── turbo.json (or nx.json)

Best for: Full-stack projects where the frontend, backend, and shared packages live in one repository. Popular with Turborepo and Nx.

Why it works: Shared code stays shared. No copy-pasting the same utility function into three different repos. Changes to a shared package update everywhere.

Real example: Your web app and mobile app both need the same date-formatting function. Put it in packages/utils and both apps import it directly.

Language & Framework Quick Reference

Project Type	Recommended Structure
React / Next.js	Feature-Based
Vue.js	Feature-Based or Layer-Based
Node.js / Express API	Layer-Based (MVC)
Django / Flask	Layer-Based
Laravel / PHP	Layer-Based (built-in)
React Native	Feature-Based
TypeScript / NestJS	Domain-Driven
Full-Stack Monorepo	Monorepo Structure
CLI Tool or Script	Flat or Light Layer-Based
Enterprise SaaS	Domain-Driven or Monorepo

A Recommended Starter Structure for React + Node Projects

If you're building a full-stack app and just want something solid to start with, this works well:

my-app/
├── client/                  ← React frontend
│   └── src/
│       ├── features/
│       ├── shared/
│       │   ├── components/
│       │   ├── hooks/
│       │   └── utils/
│       ├── pages/
│       └── main.jsx
├── server/                  ← Node.js backend
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   ├── middleware/
│   └── app.js
├── .env
├── .gitignore
└── README.md

Clean. Scalable. Easy for any developer to understand on day one.

Best Tips for Folder Structure 💡

Do this:

✅ Name folders by what they do, not by what they contain (auth/ not components2/)
✅ Keep a shared/ or common/ folder for things used across features
✅ Keep configuration files at the root level (.env, tsconfig.json, etc.)
✅ Add a README.md in complex folders if the structure isn't obvious
✅ Be consistent — pick a structure and stick to it across the whole project
✅ Keep your test files close to the code they test (co-location)

Avoid this:

❌ Naming folders temp, new, stuff, or misc
❌ Putting everything in one giant components/ folder regardless of feature
❌ Switching structures halfway through a project without refactoring
❌ Over-engineering a small project with enterprise-level folder depth
❌ Ignoring structure entirely "until later" — later never comes

Common Mistakes Developers Make 👀

Mistake 1: Starting with no structure at all

It feels faster at first. But after 50 files, you're lost. Start with even a light structure on day one.

Mistake 2: Copying a structure without understanding it

You see a GitHub repo with a fancy structure and copy it into your weekend project. Now you spend more time navigating folders than writing code. Match the structure to the project size.

Mistake 3: Going too deep too early

src/features/auth/components/forms/inputs/PasswordInput.jsx

That's five levels deep for an input field. Breathe. Start shallow and only add depth when it's genuinely needed.

Mistake 4: Treating structure as permanent

Your project will grow. Your structure should evolve with it. Flat → Layer-Based → Feature-Based is a completely valid progression. Refactoring your folder structure is normal and healthy.

Mistake 5: Inconsistency across the team

Half the team organizes by feature, half by layer, and nobody agreed on it. Establish a structure at the start and document it in your README.md.

Conclusion

Folder structure is one of those things that feels optional until it isn't. A messy project slows you down, frustrates your team, and makes the code harder to trust.

The right structure doesn't have to be complex. It just needs to be consistent, purposeful, and matched to your project size.

Start simple. Grow intentionally. And remember — a well-organized project is a joy to work in, both for you and everyone who touches it after you. 🚀

If this post helped you think differently about how you organize your projects, share it with a developer friend who might need it. And for more practical guides like this, check out hamidrazadev.com — there's plenty more where this came from.

Got a folder structure you swear by? Drop it in the comments — I'd love to see how other developers organize their work.

DEV Community: Muhammad Hamid Raza

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

What Is VS Code 1.134?

Why This Update Matters

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

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

2. ⏱️ Prompt Timeline

3. 🔍 Find in Chat

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

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

6. 🪟 Improved Side Pane Layout

7. ✖️ Close Other Editors with Alt+Click

Before vs. After — What Actually Changed for Daily Work

Tips and Do's & Don'ts

Common Mistakes to Avoid

Conclusion

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

What Is Vibe Coding, Exactly?

Why This Matters More Than People Admit

How Vibe Coding Quietly Damages Beginner Growth

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

2. You Cannot Debug What You Do Not Understand

3. You Develop Zero Problem-Solving Instincts

4. You Miss the Connections Between Concepts

5. You Build a False Confidence That Eventually Cracks

Vibe Coding vs. Intentional AI-Assisted Learning

Practical Tips for Beginners Who Want to Actually Learn 💡

Common Mistakes Beginners Make With Vibe Coding

So, Is Vibe Coding Completely Bad?

A Note of Encouragement 😊

Conclusion

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

What Is VS Code 1.133?

Why This Release Matters

The 4 New Features Worth Knowing

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

2. Open the Agents Window Without GitHub Sign-In

3. Sticky Scroll for Chat Prompts

4. Auto-Reload HTML Files in the Integrated Browser

Benefits at a Glance

Comparison: Before vs. After 1.133

Using Claude with Multiple Providers

HTML Preview Workflow

Long AI Chat Sessions

Tips for Getting the Most Out of 1.133

Common Mistakes to Avoid

Conclusion

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

What Are CSS Container Queries?

Why This Matters

Benefits with Real-Life Examples

Media Queries vs Container Queries

How to Use Container Queries (Step by Step)

Step 1: Define the container

Step 2: Optionally name the container

Step 3: Write your container query

Best Tips

Common Mistakes People Make

Conclusion

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

What Is VS Code 1.132?

Why This Release Matters

The Big New Features — With Real-Life Context

🤖 Agent Host: One Agent Session, Multiple Windows

🪟 Agents Window: Your Mission Control for Agent Sessions

💬 Side Chats with /btw — Ask Without Interrupting

🌐 Commenting in the Integrated Browser

🎙️ Multilingual Dictation — Now Actually Smart

📝 Markdown Diffs in the Hybrid Editor (Experimental)

🖥️ Terminal Output Reflow

Comparison: Before vs. After 1.132 for Agent Workflows

Best Tips for Getting the Most from 1.132 ✅

Common Mistakes to Avoid

Wrapping Up

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

What Is Next.js 16.3?

Why This Release Actually Matters

What's New — Feature by Feature

🧠 Up to 90% Less Memory in Dev

⚡ Faster Builds — Up to 5.5×

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

🛡️ Custom Error Boundaries with `catchError`

Network Resilience (`useOffline`)

Step 3: Create a `.prettierignore` File

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

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

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

Pros and Cons: `FlatCompat` vs Native Flat Config