DEV Community: Muhammad Hamid Raza

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.

GitHub vs GitLab: Which One Should You Actually Use in 2026?

Muhammad Hamid Raza — Mon, 20 Jul 2026 08:25:22 +0000

If you have ever started a new project and stared at the screen wondering, "Wait… should I put this on GitHub or GitLab?" — you are not alone. 😄

Every developer hits this crossroads at some point. Both platforms are powerful. Both are built around Git. And both have passionate fans who will defend their choice like it is a religion.

But here is the real question: which one is actually right for you?

In this post, we will break down the honest differences between GitHub and GitLab — no hype, no bias, just what you actually need to know to make a smart choice.

What Is GitHub?

GitHub is a cloud-based platform where developers store, share, and collaborate on code. It uses Git under the hood — the version control system that tracks changes to your code over time.

Think of GitHub like Google Drive, but for your code. Instead of just saving files, it also remembers every change you ever made, lets you work with a team, and makes it easy to show your work to the world.

GitHub was launched in 2008 and was acquired by Microsoft in 2018. Today it hosts millions of public and private repositories and is widely used by individual developers, open-source communities, and large companies.

What Is GitLab?

GitLab is also a Git-based platform for hosting code and collaborating on projects. But it goes a step further.

Where GitHub focuses on being a great place to host and share code, GitLab is built to be a complete DevOps platform — meaning it tries to bring your entire software development lifecycle into one tool. That includes planning, coding, testing, deploying, and monitoring.

GitLab was founded in 2011 and offers both a cloud-hosted version (GitLab.com) and a self-hosted version you can run on your own servers.

Why This Comparison Actually Matters

Choosing the wrong platform is not the end of the world — but it can slow you down.

If you pick GitHub for a project that needs heavy CI/CD pipelines, you might end up paying more or stitching together extra tools. If you pick GitLab for an open-source project where community visibility matters, you might miss out on the massive developer audience GitHub brings.

This decision affects:

How you set up your workflows — CI/CD, code reviews, deployments
How your team collaborates — issue tracking, merge requests, access controls
Your budget — free tiers differ, and advanced features have different pricing
Your career visibility — GitHub profiles are widely viewed by employers

So yes, it is worth thinking about. Not forever. Just for a few minutes. 😊

GitHub vs GitLab: A Practical Comparison

Let's go feature by feature and see how they stack up.

🔹 Community and Open Source

GitHub wins here — by a lot.

GitHub has the largest developer community in the world. Almost every popular open-source project lives on GitHub. If you want to contribute to open source, get noticed, or build a public portfolio, GitHub is where the action is.

GitLab has a community too, but it is much smaller for public open-source discovery.

Best for open source: GitHub ✅

🔹 CI/CD (Continuous Integration / Continuous Deployment)

GitLab wins here — and it is not close.

GitLab CI/CD is built directly into the platform, deeply integrated, and very powerful right out of the box. You get a feature-rich pipeline tool without needing to install or configure third-party services.

GitHub has GitHub Actions, which is also solid and has improved a lot. But GitLab's CI/CD has been around longer and offers more built-in features without extra setup.

Best for CI/CD: GitLab ✅ (GitHub Actions is a strong second)

🔹 Self-Hosting

GitLab wins clearly.

If your company or team needs to host everything on your own servers — maybe for security, compliance, or privacy reasons — GitLab makes this easy with GitLab Community Edition (free) and GitLab Enterprise Edition.

GitHub offers GitHub Enterprise for self-hosting, but it is more expensive and less flexible than GitLab's self-hosted options.

Best for self-hosting: GitLab ✅

🔹 User Interface and Experience

GitHub wins for simplicity.

GitHub's interface is clean, familiar, and very beginner-friendly. Most developers feel comfortable on GitHub within minutes.

GitLab's interface is more feature-rich, which is great once you know your way around. But for newcomers, it can feel a little overwhelming at first. The navigation has more layers because there is simply more to explore.

Best for beginners: GitHub ✅

🔹 Free Tier

Both platforms offer free plans, but they differ in what they include.

Feature	GitHub Free	GitLab Free
Private repos	✅ Unlimited	✅ Unlimited
CI/CD minutes	2,000 per month	400 per month
Pages / Hosting	✅ GitHub Pages	✅ GitLab Pages
Container Registry	✅	✅
Self-hosting	❌ (Enterprise only)	✅ Community Edition

GitHub's free tier gives more CI/CD minutes. GitLab's free tier gives you more DevOps tools overall, but the pipeline minutes are more limited.

🔹 Security and Compliance Features

GitLab leads here for enterprise teams.

GitLab has built-in security scanning tools — dependency scanning, container scanning, SAST, DAST — available even on lower-tier plans. This makes it popular in regulated industries where security audits matter.

GitHub has security features too (Dependabot, secret scanning, code scanning), and they have improved significantly. But GitLab's security toolset is more deeply integrated.

Best for security-focused teams: GitLab ✅

🔹 Project Management and Issue Tracking

Both are solid, but GitLab goes deeper.

GitLab includes boards, epics, roadmaps, time tracking, and milestones — all built in. It tries to replace tools like Jira for teams that want everything in one place.

GitHub has Issues and Projects too, and they work well. But for complex project management, GitLab has more native features.

Best for project management: GitLab ✅ (GitHub is catching up)

🔹 Integrations and Ecosystem

GitHub wins — it has a massive marketplace.

GitHub Marketplace has thousands of integrations, apps, and actions built by the community. Whatever tool your team uses — Slack, Jira, Figma, AWS, Azure, anything — there is likely a GitHub integration for it.

GitLab integrates with most popular tools too, but the ecosystem is not as wide as GitHub's.

Best for integrations: GitHub ✅

Quick Summary Table

Category	GitHub	GitLab
Open Source Community	⭐⭐⭐⭐⭐	⭐⭐⭐
CI/CD Built-in	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Self-hosting	⭐⭐	⭐⭐⭐⭐⭐
Beginner Friendliness	⭐⭐⭐⭐⭐	⭐⭐⭐
Security Tools	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Integrations	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Project Management	⭐⭐⭐	⭐⭐⭐⭐⭐
Free CI/CD Minutes	⭐⭐⭐⭐⭐	⭐⭐⭐

Which One Should You Choose?

Here is a simple guide based on real situations:

Choose GitHub if you:

Are a student or beginner learning development
Want to build a visible portfolio
Are contributing to or starting an open-source project
Need a large ecosystem of integrations
Want a simple, friendly interface

Choose GitLab if you:

Need a full DevOps pipeline out of the box
Want to self-host your code for privacy or compliance
Work in a team with complex project management needs
Are in a regulated industry that needs built-in security scanning
Want everything — planning, coding, testing, deploying — in one place

Best Tips for Using Either Platform 💡

Use descriptive commit messages. "Fixed bug" tells nobody anything. "Fix null pointer error in user login flow" is far more useful.
Protect your main branch. Always set branch protection rules to avoid accidental pushes directly to main or master.
Use .gitignore from day one. Do not push your node_modules, .env files, or build artifacts. Use a .gitignore file before your first commit.
Write a proper README. Your repository's first impression is its README. Spend a few minutes on it.
Use merge/pull request templates. They save time and improve code reviews enormously.
Tag your releases. Use Git tags and releases so your team and users can track versions clearly.

Common Mistakes People Make 🔧

1. Committing secrets or API keys

This is the classic mistake. You push a .env file or accidentally hardcode an API key. GitHub and GitLab both scan for this now, but the damage can happen fast. Use environment variables and add .env to your .gitignore immediately.

2. Working directly on the main branch

Beginners often push all their changes straight to main. This works until it doesn't. Set up a branching strategy (like Git Flow or feature branches) early.

3. Ignoring CI/CD because it "looks complicated"

A lot of developers skip CI/CD because it feels like extra work at the start. Then they waste hours on manual deployments. Even a simple pipeline that runs your tests automatically saves enormous time.

4. Thinking one platform is always better

Neither GitHub nor GitLab is universally superior. The best one depends on your team size, workflow, budget, and goals. Choose based on your needs, not trends.

5. Never reading the docs

Both platforms have excellent documentation. When something seems impossible, the answer is almost always already in the docs.

Conclusion

Both GitHub and GitLab are excellent platforms. They are not enemies — they are tools. And like most tools, the right choice depends on what you are building and how you work.

GitHub is the home of open source. It is beginner-friendly, community-rich, and has a massive ecosystem. If you are building your portfolio or contributing to the world's code, GitHub is hard to beat.

GitLab is the DevOps powerhouse. It is built for teams that want one platform to manage the entire software lifecycle, with strong CI/CD, self-hosting, and enterprise security baked in.

If you are just starting out, GitHub is a great first home. As your projects grow and your needs evolve, you will naturally figure out which fits best. And honestly? Many teams use both.

The important thing is to start building. 🚀

Want more developer guides like this? Check out hamidrazadev.com for more practical posts that help you grow as a developer. If this article helped you, share it with someone who is still deciding — you might save them an afternoon of confusion. Drop a comment with which platform you use and why!

VS Code 1.129 Is Here — Agent Hosts, Modern UI, and a `!` Trick You'll Actually Use

Muhammad Hamid Raza — Sat, 18 Jul 2026 15:48:55 +0000

VS Code just dropped version 1.129, and this one isn't your typical "we fixed some stuff" release. 🚀

This update brings a completely rearchitected agent system, a brand-new editor panel inside the Agents window, a slick quality-of-life shortcut for running terminal commands, and — possibly the most talked-about thing — a first look at a modernized VS Code UI.

If you've been using GitHub Copilot, Claude, or Codex inside VS Code, you're going to want to read this. Things are changing in a big way, and mostly for the better.

So, what actually landed in VS Code 1.129, and which features are worth turning on today?

What Is VS Code 1.129?

Visual Studio Code 1.129 is the July 2026 release of Microsoft's free, open-source code editor. It shipped on July 15, 2026, with a gradual rollout to all users (you can force the update right now by going to Help → Check for Updates).

This release is heavy on AI and agent improvements, which makes sense given how central Copilot and third-party AI tools have become to the daily dev workflow. But it also adds some genuinely useful editor-level changes that don't require any AI setup at all.

Let's break it all down.

Why This Release Matters

VS Code has been steadily evolving from a code editor into something closer to an AI-powered development environment. Version 1.129 makes the biggest structural bet on that direction yet.

The agent host — the flagship feature of this release — fundamentally changes how AI agent sessions run inside VS Code. Instead of being tightly coupled to a single editor window, agent sessions now live in their own dedicated process. That means you can open the same agent session across multiple windows simultaneously.

Think of it like this: before, your AI session was tied to one browser tab. Now it's more like a shared Google Doc — multiple windows, same live session.

For developers juggling multiple projects, reviewing agent-generated code across workspaces, or just working across monitors, this is a meaningful upgrade.

The Big Features in VS Code 1.129

🤖 The Agent Host — A New Architecture for AI Sessions

The agent host is the core infrastructure change in this release. Instead of running agent sessions inside the editor process itself, VS Code now spins up a separate dedicated process called the agent host. This process runs agent harnesses — Copilot, Claude, and Codex — based on a new open protocol called the Agent Host Protocol (AHP).

Here's why that matters in practice:

Multiple windows, one session. You can connect to and render the same agent session from multiple VS Code windows at once. No more duplicating your context across tabs.
Aligned behavior across products. The Copilot agent on the agent host is powered by the Copilot SDK, which means it behaves consistently with the Copilot CLI, the standalone Copilot app, and other Copilot products. Less "why does it work here but not there" confusion.

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

Worth noting: not every feature in this release works with every harness. Some features are agent-host-only, and some have extra settings to enable specific agents (like chat.agents.claude.preferAgentHost for Claude on the agent host).

🗂️ New Editor Panel in the Agents Window (Experimental)

If you use the Agents window, you've probably felt the friction of switching back and forth between the chat panel and the file-review panel. The new editor panel fixes that.

It merges the editor and the detail area into a single docked pane with a shared tab bar. You get:

Files and diffs opening directly next to your chat conversation — no separate panels to juggle.
An improved diff experience with toggle between inline and side-by-side views, collapse/expand all, and a more compact diff representation that shows more change on screen.
The next action (like "Create Pull Request") right in the editor tab title — no hunting through menus.
Session state persistence. Each session remembers its side-pane width, open editors, active file, and collapsed state across session switches and reloads.

To enable it, turn on the sessions.layout.singlePaneDetailPanel setting and reload your window (it's read at startup, so the reload is required).

This is experimental, but it feels like the kind of change that becomes the default pretty quickly.

⚡ Run Terminal Commands with `!` from Chat

Here's the shortcut you didn't know you needed.

You can now prefix any chat message with ! to run its contents as a terminal command directly — no need to copy, switch to the terminal, paste, and run.

! npm run build
! git status
! python manage.py migrate

It works in agent host sessions in both the editor window and the Agents window. Small feature on paper, but when you're deep in a conversation with an agent and need to quickly verify something in the terminal, it saves more context-switching than you'd expect.

🎨 Modern UI Preview (Experimental)

This is the one people have been waiting for. 👀

VS Code 1.129 introduces a modernized workbench UI — updated look and feel across the editor, available as an experimental opt-in via the workbench.experimental.modernUI setting. It's already enabled by default in Insiders builds.

Details on exactly what's changing are still rolling out as this is a preview, but if you want to see where VS Code's visual direction is heading, enable it and take a look.

🔑 Session-Management Tools for Agents

Agents on the agent host now have access to a suite of session-management tools. This means an agent can — with your permission — list your active sessions, read another session's recent conversation, create a new session to hand off a sub-task, and even send a message to a session it created.

A few important guardrails are baked in: sending a message to another session always asks for your confirmation first, an agent can't message its own chat, and the number of sends per request is capped to prevent runaway session spawning.

This is the kind of feature that starts to feel like working with a team of agents rather than a single assistant.

🏢 GitHub Enterprise Support for Copilot in the Agent Host

If your Copilot access comes through a GitHub Enterprise (GHE) instance, you can now sign in and use Copilot in VS Code through the agent host. Previously, only github.com accounts could complete the sign-in flow in the agent host — GHE users were effectively locked out.

With 1.129, VS Code runs the OAuth flow and requests Copilot tokens from your GHE host instead. This works in both the editor window and the Agents window, with both the Copilot and Claude agents.

To use it, make sure chat.agentHost.enabled is on, then sign in and choose your GHE instance.

📁 Other Improvements Worth Knowing

Reopen Editor from the Toolbar — When a file supports multiple editors (like a Markdown file that can open as raw text or a preview), you can now switch directly from the editor toolbar via the ... menu → Reopen Editor With. No need to open the Command Palette for this anymore.

Migrate Prompt Files to Skills — If you have custom prompt files (*.prompt.md) for slash commands, VS Code now offers a migration interface to convert them into skills for compatibility with agent host harnesses. Enable chat.customizations.promptMigration.enabled to access it.

BYOK Models in the Agents Window — You can now use Bring Your Own Key (BYOK) models in the Agents window when using the Copilot harness on the agent host.

Agents Window UX Improvements — The new-session flow now remembers your last agent mode and approvals settings as defaults. Plus, the worktree/folder isolation option is now a simple checkbox instead of a dropdown.

Comparison: Agent Sessions Before vs After 1.129

	Before 1.129	After 1.129
Session process	Tied to the editor process	Dedicated agent host process
Multi-window support	Not available	Same session across multiple windows
Copilot behavior alignment	Varied by surface	Aligned via Copilot SDK
GitHub Enterprise support	Not supported in agent host	Fully supported
Diff review in Agents window	Separate panels	Unified docked editor (experimental)
Terminal from chat	Copy → switch → paste	`!` prefix, done

Best Tips for Getting the Most Out of 1.129

✅ Enable the agent host gradually. Turn on chat.agentHost.enabled first, get comfortable with it, then layer in features like the single-pane editor panel or session-management tools. Don't flip every experimental toggle at once.

✅ Use ! for quick terminal checks during chat. It's most useful when you're mid-conversation with an agent and want to verify something fast — think ! git log --oneline -5 or ! node -v.

✅ Try the modern UI on Insiders. If you want to preview it with the least friction, switch to the VS Code Insiders build where it's already the default.

✅ GHE users: update and sign in fresh. If you've been unable to use Copilot on the agent host with a GHE account, this release fixes that. You may need to sign out and sign back in to pick up the new authentication flow.

✅ Migrate your prompt files. If you have .prompt.md files for custom slash commands, the new migration tool in the AI Customizations overview is the easiest path to cross-harness compatibility.

Common Mistakes to Avoid

🚫 Expecting all new features to work on every harness. Several 1.129 features — like session-management tools and some agent-host-specific options — only work when an agent is running on the agent host. If a feature isn't showing up, check whether chat.agentHost.enabled is on and the right harness is selected.

🚫 Forgetting to reload after enabling the new editor panel. The sessions.layout.singlePaneDetailPanel setting is read once at startup. Enabling it without reloading means you won't see any change — and then you'll wonder why the setting "doesn't work."

🚫 Treating the modern UI preview as production-ready. It's experimental. Great to explore, but probably not the time to rely on it in a high-stakes client demo just yet.

🚫 Missing the gradual rollout. VS Code 1.129 is rolling out gradually. If you don't see it yet, go to Help → Check for Updates to pull it immediately instead of waiting for the rollout to reach you.

Wrapping Up

VS Code 1.129 is a meaningful step forward — not just a collection of bug fixes and small tweaks, but a release that actually reshapes how AI-assisted development works inside the editor.

The agent host is the biggest structural change: agent sessions in their own process, connectable from multiple windows, aligned with the broader Copilot ecosystem. The new editor panel in the Agents window makes reviewing AI-generated code feel natural rather than clunky. The ! prefix is the tiny shortcut you'll use every single day once you know it exists. And the modern UI preview gives us a glimpse of where VS Code's look is heading.

Not everything in 1.129 is production-ready yet — several features are explicitly experimental. But the direction is clear, and it's a good one.

Update, explore the new settings, and let the agent host do some of the heavy lifting for you. 💡

Want more write-ups like this? I cover VS Code releases, frontend dev, and developer tools at *hamidrazadev.com*. Drop a comment if there's a feature you want me to dig into deeper — or share this post if it saved you time!

GPT-5.6 vs Claude Fable 5: Which AI Model Should Developers Use in 2026?

Muhammad Hamid Raza — Wed, 15 Jul 2026 04:11:08 +0000

The AI model race is moving fast. Almost too fast. Just when you think you've picked a winner, a new release drops and your comparison sheet is already out of date.

July 2026 gave us two major launches within weeks of each other: OpenAI's GPT-5.6 family and Anthropic's Claude Fable 5. Both are frontier-class models. Both are targeting serious developers, enterprise teams, and ambitious agentic workflows. Both are genuinely impressive.

But which one actually fits your use case? And which one gives you better value for money? 🤔

Let's break it down honestly — no fluff, no fanboy takes. Just the facts, the benchmarks, and what they mean for your real-world work.

What Is GPT-5.6?

GPT-5.6 is OpenAI's newest model family, launched on July 9, 2026. It comes in three tiers:

Sol — the flagship, highest capability
Terra — balanced performance for everyday work
Luna — the fastest and most cost-efficient option

The whole family is built around one core idea: getting more useful work done per token. OpenAI trained GPT-5.6 to be efficient by default, with the ability to scale up to max or even ultra mode (which runs four agents in parallel) when you need maximum firepower.

It's available through ChatGPT, the OpenAI API, and Codex.

What Is Claude Fable 5?

Claude Fable 5 is Anthropic's fifth-generation model, launched on June 9, 2026 and fully rolled out by July 1. It sits at the Mythos tier of Anthropic's model lineup — which places it among their highest-capability class.

Fable 5 is designed for long-running, complex, and asynchronous tasks. Think multi-day coding sessions, large-scale enterprise knowledge work, and agentic pipelines that need minimal hand-holding. It's thorough, proactive, and designed to check its own work.

It's available to Pro, Max, Team, and Enterprise Claude users, and also through AWS, Google Cloud, and Microsoft Foundry.

Why This Comparison Matters

Picking the wrong model for your workload doesn't just hurt your results — it affects your costs, your team's velocity, and sometimes your product's reliability.

If you're building an AI-powered app, running an agentic coding pipeline, or just trying to choose the right API to integrate into your SaaS product, this decision has real weight. Both models are expensive at the frontier tier. You want to spend wisely. ⚡

The benchmarks help, but they don't tell the whole story. Let's go through both.

GPT-5.6 vs Claude Fable 5: The Key Differences

💰 Pricing

This is one of the clearest differences between the two.

Model	Input (per 1M tokens)	Output (per 1M tokens)
GPT-5.6 Sol	$5	$30
GPT-5.6 Terra	$2.50	$15
GPT-5.6 Luna	$1	$6
Claude Fable 5	$10	$50

GPT-5.6 Sol is half the input cost and 40% cheaper on output compared to Fable 5. At scale, that difference compounds quickly. If you're running thousands of long-context API calls a day, this matters a lot.

Fable 5 does offer a 90% prompt caching discount on input tokens, which can significantly reduce costs on repeated or templated prompts.

🧠 General Intelligence

On the Artificial Analysis Intelligence Index v4.1 — a broad measure covering agentic work, coding, scientific reasoning, and general capabilities — the scores are remarkably close:

Claude Fable 5: 59.9
GPT-5.6 Sol (max reasoning): 58.9

For general intelligence, they're essentially neck and neck. Neither has a clear runaway lead here.

🤖 Long-Horizon Agentic Tasks

The Agents' Last Exam is an evaluation of long-running professional workflows across 55 fields. Here, GPT-5.6 Sol pulls ahead:

GPT-5.6 Sol: 53.6%
Claude Fable 5: 40.5%

That's a meaningful 13-point gap. For workflows that span extended tasks across multiple domains, GPT-5.6 Sol performs noticeably better on this specific benchmark.

That said, Claude Fable 5 is built for multi-day autonomous sessions and can run for extended periods inside agent harnesses like Claude Code. The benchmark and the real-world experience don't always map perfectly.

💻 Coding

This is where things get interesting. It depends on which coding benchmark you look at.

On the Artificial Analysis Coding Agent Index v1.1:

GPT-5.6 Sol: 80
Claude Fable 5: 77.2

GPT-5.6 has a slight edge here.

But on SWE-Bench Pro — a benchmark testing real-world software engineering on actual codebases:

Claude Fable 5: 80%
GPT-5.6 Sol: 64.6%

That's a 15-point gap in Fable 5's favor on a benchmark many developers consider closer to real work. For large migrations, complex implementations, and multi-day autonomous coding sessions, Fable 5's advantage on SWE-Bench Pro is hard to ignore.

🖥️ Computer Use and Browsing

For computer use tasks — where the model controls a computer to complete tasks — GPT-5.6 Sol leads:

OSWorld 2.0: GPT-5.6 Sol 62.6% vs Claude Opus 4.8 (Fable 5 not tested here) 54.8%
BrowseComp: GPT-5.6 Sol 90.4% vs Fable 5 84.4%

If your agent needs to browse the web, fill forms, or interact with a GUI, GPT-5.6 Sol currently has stronger benchmarks in this area.

🔒 Cybersecurity

Both models take safety seriously, but their approaches differ.

GPT-5.6 Sol scores 73.5% on ExploitBench (vs GPT-5.5's 47.9%), making it their strongest security model yet. OpenAI has a "Trusted Access for Cyber" program for verified defensive security professionals.

Claude Fable 5 includes robust cybersecurity safeguards and automatically routes many sensitive queries to a safer fallback model (Opus 4.8). This protects against misuse but can limit some legitimate security research workflows.

If you're doing authorized penetration testing or defensive security work, you'll want to check access programs for both providers.

🌐 Vision and Document Understanding

Claude Fable 5 has a strong emphasis on vision-assisted work — it can understand diagrams, charts, and tables inside PDFs and even use vision to check its own coding output against design goals.

GPT-5.6 Sol also handles multimodal work well, scoring 83% on MMMU Pro (with tools). Both are strong here, and this one's largely a wash for most use cases.

When to Use GPT-5.6 Sol

GPT-5.6 Sol makes sense when:

Cost efficiency matters at scale — it's meaningfully cheaper than Fable 5 for similar capability
You need strong agentic performance — Agents' Last Exam results show it handles multi-step professional workflows well
Computer use is central to your workflow — stronger benchmarks on BrowseComp and OSWorld
You want the ultra multi-agent mode — four agents running in parallel for demanding tasks
You're already in the OpenAI/Codex ecosystem — zero migration friction

When to Use Claude Fable 5

Claude Fable 5 makes sense when:

Real-world coding depth matters more than benchmark breadth — SWE-Bench Pro results are significantly stronger
You need multi-day autonomous agent sessions — built specifically for this use case with Claude Code
You work in enterprise workflows — designed to handle complex, multi-stage knowledge work with minimal oversight
You're on AWS, Google Cloud, or Microsoft Foundry — native integrations are available
Vision + document understanding is a core need — especially in finance, legal, and architecture workflows
Your team values Anthropic's safety approach — automatic fallback routing adds a layer of protection

Practical Tips for Choosing

✅ Do run a real test with your own prompts. Benchmarks are helpful but your actual use case might behave differently. Both providers offer API access — test on your real data before committing.

✅ Do factor in caching. Claude Fable 5's 90% prompt caching discount can significantly reduce costs if your prompts have a lot of repeated context (like system prompts or document chunks).

✅ Do consider the ecosystem. If your app is already OpenAI-native, switching to Fable 5 means reworking your integration. If you're starting fresh, both are viable.

✅ Do think about task type, not just model quality. For web agents and computer use, GPT-5.6 Sol has the edge today. For deep coding tasks in real codebases, Fable 5's SWE-Bench numbers are hard to dismiss.

❌ Don't rely on a single benchmark. Every benchmark has its context. Agents' Last Exam and SWE-Bench Pro measure different things. Read what each eval actually tests.

❌ Don't ignore the safety requirements. Claude Fable 5 requires 30-day data retention for safety monitoring. If your use case has strict data handling requirements, check this carefully before integrating.

❌ Don't assume the most expensive model is always the best choice for your task. GPT-5.6 Terra ($2.50/$15) outperforms Claude Fable 5 on some benchmarks at a fraction of the price.

Common Mistakes Developers Make When Comparing AI Models

Treating one benchmark as the whole story. It's tempting to see "GPT-5.6 wins on Agents' Last Exam" and call it settled. But a different benchmark — SWE-Bench Pro — tells a very different story. No single number captures everything.

Ignoring cost at scale. It's easy to run a few API calls and not think about price. But at production scale, the difference between $5/$30 and $10/$50 per million tokens adds up fast. Do the math for your actual usage volume before deciding.

Picking based on brand loyalty. Some teams are Team OpenAI or Team Anthropic before they've even tested. That's a fine starting point, but make the final call based on your actual workload.

Not testing vision-heavy workflows. If your product processes PDFs, invoices, diagrams, or screenshots, you need to test that specific scenario. General benchmarks may not reflect how each model handles your document types.

Forgetting that models evolve quickly. Both GPT-5.6 and Claude Fable 5 are already being evaluated against Claude Mythos (Anthropic's higher tier) and will face new releases soon. The landscape shifts fast — avoid over-engineering your entire pipeline around one model.

Conclusion

Both GPT-5.6 Sol and Claude Fable 5 are impressive frontier models that genuinely push what's possible with AI-assisted development in 2026.

If cost efficiency and strong agentic performance across broad workflows are your priority, GPT-5.6 Sol is a compelling choice — especially given its lower price point and strong computer use benchmarks.

If you're doing deep, real-world coding work, running multi-day autonomous agent sessions, or handling complex enterprise pipelines that need thorough, self-checking intelligence, Claude Fable 5 has clear strengths — particularly on SWE-Bench Pro, which reflects more realistic software engineering scenarios.

The honest answer? There's no universal winner. The right model depends on your specific workload. Test both, measure what actually matters for your product, and let the results — not the marketing — guide you.

Curious what else is happening in the AI and developer tooling space? Check out more practical posts at hamidrazadev.com 🚀

If this comparison saved you some research time, share it with your team or drop it in your dev community — there's always someone else trying to make the same call right now.

VS Code 1.128 Is Here: Multi-Chat Agent Sessions, Copilot Vision, and OS-Level Shortcuts 🚀

Muhammad Hamid Raza — Wed, 08 Jul 2026 16:38:05 +0000

Ever had five different conversations going with an AI assistant, all about the same project, but scattered across five separate tabs? You lose track of which chat had the good idea. You forget which one was just testing something weird. It gets messy fast.

VS Code 1.128 (released July 8, 2026) tackles exactly that problem, along with a few other genuinely useful upgrades. Let's walk through what's new, in plain language. 😊

What Is VS Code 1.128?

VS Code 1.128 is simply the latest update to Visual Studio Code, the free code editor made by Microsoft that millions of developers use every day.

Think of it like a phone getting a software update. Your phone still works the same way, but suddenly you have new camera features or better battery controls. VS Code updates work the same way: same editor you know, but with new tools added on top.

This release focuses heavily on Chat and Agents, the part of VS Code where you talk to an AI to help you write code, debug, or answer questions.

Why This Release Matters

If you use AI chat inside your editor, you already know the small annoyances: switching between chats, losing context, or not being able to attach an image when you need to show a bug visually.

This update directly fixes those friction points. It also adds a shortcut feature that goes beyond the editor itself, and gives teams more control over how AI usage is tracked. In short: less busywork, more focus on actual coding.

Benefits with Real-Life Examples

Multiple chats in one Claude session 💬
Instead of opening a brand-new session every time you want to try a different approach, you can now keep related chats grouped together. Example: one chat adds a /health endpoint to your Express app, while a peer chat writes tests for it at the same time, and a forked chat tries an alternative way to build the same feature. All three stay organized under one session instead of cluttering your session list.
Quick chats without opening a workspace ⚡
Sometimes you just want to ask a quick question, not open an entire project folder. Now you can start a chat in the Agents window without picking a workspace first. It's like asking a coworker a quick question in the hallway instead of walking them to your desk.
Copilot Vision, now generally available 👀
You can paste, drag, or drop images and PDFs straight into Chat. Say you have a screenshot of a broken UI layout — you can hand that directly to the agent instead of typing out a long description of what's wrong.
Read-only subagent chats (Preview)
When an agent delegates work to helper subagents, you can now watch their progress in a read-only view without accidentally interrupting them. Useful when you want visibility without micromanaging.
Configurable browser tab placement 🔧
You can choose whether integrated browser tabs open in your active editor group, a dedicated side group, or their own window. Small thing, but it keeps your workspace from feeling cluttered.
OS-level keyboard shortcuts
You can now set up shortcuts that trigger VS Code commands even when VS Code isn't the focused window. For example, a cmd+shift+a shortcut on macOS that opens the Agents window instantly, no matter what app you're currently in.

Beginner Approach vs Better Approach: Managing Multiple AI Conversations

Beginner approach: Open a new top-level session every time you want to try a different idea. Result: ten sessions, no idea which one has the code you actually want to keep.

Better approach (as of 1.128): Use multiple chats inside one Claude session. Add a chat, fork from an earlier turn, or run chats in parallel — all while keeping everything grouped under one session that's easy to find later.

This isn't about one method being "wrong." It's just that as your AI usage grows, organized sessions save real time.

Best Tips for Using These New Features

✅ Try forking a chat before starting a totally new session. If an idea works, you keep it. If it doesn't, you didn't lose your original conversation.
✅ Use quick chats for one-off questions. Don't open a whole workspace just to ask something simple.
✅ Turn on OS-level shortcuts sparingly. They're powerful, but pick a key combo that doesn't clash with shortcuts your other apps already use.
✅ If you're on a team, check with your admin about the new OpenTelemetry settings for Copilot — managed settings will always override your personal ones.
⚠️ Remember: chats without a workspace only work when the agent host is enabled through the chat.agentHost.enabled setting.

Common Mistakes People Make

Assuming every chat needs its own session. This gets overwhelming fast. The new multi-chat model exists specifically so you don't have to do this anymore.
Forgetting that BYOK (Bring Your Own Key) models don't use utility models by default. If you're using your own key as the main agent and notice chat titles or commit messages aren't generating, it's because chat.byokUtilityModelDefault needs to be set. It's not a bug, it's a default behavior worth knowing about.
Not checking the modelOptions settings when using Custom Endpoint models. If your provider has strict parameter requirements, setting temperature or top_p incorrectly (or forgetting to set them to null when needed) can cause request failures.
Ignoring the difference between sideGroup and window for browser tabs. People often pick one, get annoyed, and don't realize there's a setting to change it.

Wrapping Up

VS Code 1.128 is a solid, practical update. Multi-chat agent sessions make working with Claude in VS Code more organized. Copilot Vision going GA means images and PDFs are now a natural part of your chat workflow. And OS-level shortcuts mean VS Code can be one keypress away, even when it's not in focus.

None of this reinvents the editor. It just removes small annoyances that add up over a normal coding day, which honestly is what good updates should do. 💡

If you found this useful, feel free to share it with a fellow developer who's still juggling ten browser tabs of AI chats. And if you want more practical, no-fluff dev content like this, check out more posts at hamidrazadev.com.

Got a favorite feature from this release? Drop a comment below and let's talk about it! 👇

The New HTTP QUERY Method: Why GET and POST Weren't Enough

Muhammad Hamid Raza — Sun, 05 Jul 2026 10:19:28 +0000

Have you ever built a search feature and hit a wall because your filters were too long for a URL? 😅 Yeah, me too. You start with a clean GET /search?q=... request, everything's happy, and then someone adds ten more filters and suddenly your URL looks like a ransom note.

Most of us just switch to POST at that point and move on with our lives. It works, sure. But it always felt a little... off. POST is meant for creating or changing things, not for asking a question.

Turns out the IETF felt the same way. In June 2026, they published RFC 10008, which defines a brand-new HTTP method called QUERY. It's built specifically to fix this exact headache. Let's break down what it is, why it matters, and how you'd actually use it. 🚀

What Is the HTTP QUERY Method?

Think of HTTP methods like different types of requests you can make to a waiter at a restaurant.

GET is like pointing at a menu item. Simple, safe, repeatable — you can point at it a hundred times and nothing changes.
POST is like telling the waiter "surprise me, and also charge my card." It might change something, and doing it twice could mean two charges.
QUERY is the new one: it's like handing the waiter a detailed written note describing exactly what you want, but with a promise attached — "this is just a question, not an order, so ask it as many times as you need."

In technical terms, QUERY lets you send a request with a body (just like POST), but it's explicitly marked as safe and idempotent — meaning it won't change server state, and repeating it is completely fine.

Here's what it looks like in practice:

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&limit=10&sort=-published

Compare that to the old GET-with-a-giant-URL approach:

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org

Same intent, but QUERY moves the data into the body, where it belongs when things get complex.

Why This Topic Matters

You might be thinking, "okay, cool, but why should I care about one new HTTP verb?" Fair question. Here's the real-world pain it solves:

1. URL length limits are real. The spec itself points out that request URIs often need to stay under roughly 8000 characters. If your search has a dozen filters, a full-text query, and some tags, you can blow past that fast.

2. URLs get logged everywhere. Proxies, browser history, server logs, analytics tools — they all love to record URLs. If your "query" contains anything sensitive, that's a problem. A request body is far less likely to get logged the same way.

3. POST breaks caching and safe retries. If your query is actually a POST, browsers and caches can't safely retry it after a dropped connection, because POST might have side effects. QUERY tells everyone in the chain: "relax, this is just a read."

If you've ever debugged a flaky search endpoint or worried about sensitive data leaking into a URL, this method was made for you.

Benefits with Real-Life Examples

Cleaner architecture for complex searches. Imagine an e-commerce filter with brand, price range, size, color, and rating. With QUERY, all of that lives in a structured request body instead of a mile-long URL string. Way easier to read and maintain.
Safe automatic retries. Since QUERY is idempotent, your HTTP client (or a proxy) can safely resend the request if the connection drops — no risk of accidentally triggering something twice, unlike a risky POST retry.
Built-in caching support. RFC 10008 explains that responses to QUERY requests are cacheable, similar to GET. So a cache can store the result and serve it again for an identical query, saving your server some work.
Content negotiation like a champ. The Accept-Query header lets a server advertise which query formats it understands — say, application/sql or application/jsonpath — so clients know exactly what to send before they even try.
Optional shareable URLs. A server can still hand back a Location header pointing to a URI that represents the same query, so you can bookmark or share a query result if you want to — you're just not forced to cram everything into the URL upfront.

GET vs POST vs QUERY: Quick Comparison

	GET	QUERY	POST
Safe (no side effects)	Yes	Yes	Maybe not
Idempotent (safe to repeat)	Yes	Yes	Maybe not
Has a request body	No defined meaning	Yes, expected	Yes, expected
Cacheable	Yes	Yes	Only in special cases
Good for long/complex queries	No	Yes	Sort of, but semantics are unclear

The short version: QUERY gives you POST's flexibility (a body for your data) with GET's safety guarantees (safe, idempotent, cacheable). It really is the best of both worlds for read-only operations.

Best Tips for Using QUERY

Always set a Content-Type header. The spec is strict here — if it's missing or doesn't match your actual body content, the server is expected to reject the request with a 4xx error.
Check for support first. You can send an OPTIONS request and look at the Allow header, or check for an Accept-Query header, to see if a server actually supports QUERY before relying on it.
Use it for reads only. If your request changes data on the server, that's not a QUERY — stick with POST, PUT, or PATCH for that.
Take advantage of conditional requests. Just like GET, QUERY supports things like If-Modified-Since, so you can avoid re-downloading a query result that hasn't changed.
Don't put sensitive data in a Location URI. If your query result gets a temporary URL, make sure that URL itself doesn't leak sensitive query details.

Common Mistakes People Make

Mistake 1: Treating QUERY like a normal POST.
It's tempting to just swap the method name and call it done. But since QUERY promises to be safe and idempotent, any implementation that changes server state under the hood is technically breaking the contract — even if nothing crashes right away.

Mistake 2: Forgetting that QUERY needs CORS preflight.
If you're calling this from a browser across origins, QUERY isn't in the CORS-safelisted method list, so your browser will send a preflight OPTIONS request first. Skipping this consideration can lead to confusing failures in production.

Mistake 3: Assuming every server supports it already.
QUERY is brand new as of this RFC. Many servers, frameworks, and even browsers won't support it out of the box yet. Always check for support instead of assuming.

Mistake 4: Ignoring the Accept-Query header.
If a server tells you exactly which formats it accepts, use that information instead of guessing and getting a 415 Unsupported Media Type response.

Wrapping Up

The HTTP QUERY method fills a real gap that a lot of developers have quietly worked around for years — usually by misusing POST or fighting with URL length limits. Now there's an official, standardized way to send a safe, idempotent request with a full body, and get proper caching and retry behavior for free.

It's not going to replace GET or POST. It's simply the right tool for a very specific job: asking a detailed question without changing anything. If you build APIs with search, filtering, or reporting features, this is worth keeping on your radar as tooling and framework support catches up.

If this cleared things up for you, I'd love for you to share it with a fellow developer who's fighting with a 3,000-character search URL right now. 😄 You can find more practical, beginner-friendly dev content over at hamidrazadev.com — drop a comment if you have questions or your own QUERY use case!

Visual Studio Code 1.127: Everything New in the July 2026 Update

Muhammad Hamid Raza — Wed, 01 Jul 2026 10:11:14 +0000

If you open Visual Studio Code every day, you know the feeling. A new update appears, you skim the release notes, promise yourself you'll read them later... and then get back to debugging that one mysterious error that somehow disappeared after adding a console.log() 👀.

The Visual Studio Code 1.127 release brings several meaningful improvements, especially if you use AI-powered development, build web applications, or simply want a smoother coding experience. So what's actually worth your attention? Let's break it down. 🚀

What Is Visual Studio Code 1.127?

Visual Studio Code 1.127 is the July 2026 update of Microsoft's popular code editor.

Like most VS Code releases, this update focuses on improving developer productivity instead of introducing flashy changes. Many improvements make existing workflows smoother, especially around AI agents, browser integration, and session management.

Whether you're a student learning programming or an experienced developer working on large projects, these updates aim to reduce friction while writing and testing code.

Why This Update Matters

Small improvements add up.

Imagine spending a few seconds less every time you organize AI sessions, review changes, or test your web app. Those seconds become minutes, and those minutes become hours over weeks of development.

This release helps developers:

spend less time switching between tools
organize AI workflows more easily
test browser-based applications inside VS Code
understand AI usage more clearly
work with fewer interruptions

None of these features magically write perfect software. They simply make the development process a little smoother.

What's New in Visual Studio Code 1.127

🌐 Browser Tools for AI Agents Are Now Generally Available

One of the biggest highlights is that browser tools for AI agents are now generally available.

Agents can now:

Open web pages
Read page content
Take screenshots
Click buttons
Navigate websites
Help validate web applications

For frontend developers, this reduces the need to constantly switch between VS Code and an external browser during certain AI-assisted workflows.

🔒 Per-Site Browser Permissions

The integrated browser now supports individual permissions for each website.

Supported permissions include:

Camera
Microphone
Geolocation
Clipboard
Bluetooth
USB devices
Sensors

Instead of allowing everything globally, VS Code asks for permission per site, similar to modern web browsers.

This gives developers better control while testing browser features.

📂 Better Agent Session Organization

If you've ever had several AI sessions open at once, you know how quickly things become messy.

VS Code 1.127 introduces:

Custom session groups
Drag-and-drop organization
Pinning sessions
Moving multiple sessions together
Collapsible groups

Think of it like organizing folders on your desktop instead of leaving everything scattered everywhere.

💬 Chat Input Banners

The Agents window can now display helpful banners above the chat input.

Examples include:

Failed CI checks
New pull request comments

Instead of hunting through different windows, you can respond directly inside your current workflow.

💰 Subagent Credit Visibility

When AI delegates work to subagents, you can now hover over them to see how many AI credits were used.

This adds more transparency and helps developers better understand resource usage.

✨ Improved Multi-Chat Sessions

Multi-chat sessions continue to improve with several useful additions:

Create multiple chats inside one session
Close and reopen chats
Permanently delete chats
Fork conversations into peer chats
Better progress tracking across chats

This makes complex AI-assisted development easier to organize.

⚡ Better Session Layout

Several interface improvements make sessions easier to work with:

Consistent header buttons
Cleaner workspace indicators
Combined file change summaries
Automatic focus on the chat input when switching sessions

These aren't dramatic changes, but they remove small annoyances that developers experience every day.

🛠️ /troubleshoot for AI Sessions

If an AI session behaves unexpectedly, you can now use:

/troubleshoot

The command analyzes session logs and helps explain issues such as:

ignored custom instructions
slow responses
unexpected behavior

Instead of guessing what happened, you get more useful diagnostic information.

🧪 Terminal Sandboxing

On macOS and Linux, many agent-invoked terminal commands now run inside a sandbox by default.

This means:

restricted filesystem access
blocked network access
fewer approval prompts for safer commands

Commands requiring broader access still request permission.

🤖 Built-in Ollama Provider Deprecation

The built-in Ollama provider has been deprecated.

If you use Ollama inside VS Code, the recommended approach is now the official Ollama extension.

This change helps model providers ship updates faster without waiting for VS Code releases.

Benefits with Real-Life Examples

✅ Cleaner AI workflows
- Instead of scrolling through dozens of sessions, you can organize them into logical groups.
✅ Safer browser testing
- When testing a web app that requests camera access, permissions are granted per site instead of globally.
✅ Less context switching
- Pull request comments and CI failures appear directly where you're already working.
✅ Better transparency
- Credit usage helps teams understand how AI resources are being consumed.
✅ Improved debugging
- The /troubleshoot command provides insights instead of leaving you guessing.

Visual Studio Code 1.127 vs Earlier Versions

Earlier Versions	VS Code 1.127
Basic AI session management	Better grouping and drag-and-drop organization
Browser tools in preview	Browser tools generally available
Limited browser permissions	Per-site permission model
Less visibility into AI usage	Subagent credit information
Simpler multi-chat experience	Improved multi-chat management

Best Tips

✅ Do

Keep your AI sessions organized with groups.
Use browser tools when validating web applications.
Review permission prompts before granting access.
Try /troubleshoot if AI responses seem unusual.
Update extensions alongside VS Code for the best compatibility.

❌ Don't

Ignore permission requests without reading them.
Leave dozens of sessions open if they are no longer needed.
Assume AI-generated changes are always correct. Review them carefully.
Forget to migrate if you're still using the deprecated built-in Ollama provider.

Common Mistakes Developers Make

Ignoring release notes

Many developers install updates without checking what's new.

Even spending five minutes reading the highlights can reveal features that save time every day.

Treating AI like autopilot

AI tools are helpful, but they still need human review.

Always verify generated code before committing it.

Keeping messy sessions

Leaving every conversation open makes it harder to find the work that actually matters.

Grouping sessions keeps projects much easier to navigate.

Forgetting extension updates

Some new VS Code capabilities work best when related extensions are also up to date.

Keeping both current helps avoid compatibility issues.

Final Thoughts

Visual Studio Code 1.127 isn't about huge visual changes. Instead, it focuses on refining everyday development.

The improvements to AI agents, browser tools, permissions, session management, and diagnostics are practical additions that can make daily coding feel a little more organized and efficient.

If you spend hours inside VS Code each week, even small workflow improvements are worth exploring.

If you found this article helpful, consider sharing it with other developers who might benefit from it. You can also discover more practical developer tutorials, guides, and articles at https://hamidrazadev.com. Happy coding! 🚀

DX Matters Too: Why Developer Experience Deserves the Same Love as UX

Muhammad Hamid Raza — Sun, 28 Jun 2026 11:06:52 +0000

Everyone talks about UX. But who's talking about the people building the product? 🤔

Introduction

You've heard it a thousand times: "Make it a great experience for the user." And yes, that matters. Nobody wants a confusing app.

But here's something we don't say out loud enough — what about the developer sitting at 11 PM, fighting a broken CLI, cryptic error messages, and documentation that reads like a legal contract?

Developer Experience, or DX, is the UX for the people who build things. And for a long time, it's been treated like an afterthought.

If you've ever rage-quit a library because the docs were useless, spent hours just getting a "Hello World" running, or stared at an error message that told you absolutely nothing — you've experienced bad DX firsthand.

So let's talk about it. Because DX deserves the spotlight. 🚀

What Is Developer Experience (DX)?

Developer Experience is how a developer feels and works when using a tool, API, framework, SDK, or platform.

Think of it like this: UX is how your users feel using your app. DX is how developers feel building it.

If a user gets confused by a button, that's a UX problem.

If a developer gets confused by your package setup, broken error messages, or missing documentation — that's a DX problem.

DX covers things like:

How easy is it to install and get started?
Are error messages actually helpful?
Is the documentation clear and complete?
Does the API feel intuitive and consistent?
How fast is the local development feedback loop?
Are there good examples to follow?

It's not just about "developer happiness" (though that matters too). Good DX directly affects how fast teams ship, how many bugs slip through, and whether people adopt your tool at all.

Why Developer Experience Actually Matters

Here's a truth most product managers and business owners overlook:

Developers are users too.

When a developer struggles to use your API, SDK, or platform, they don't push through it out of loyalty. They Google the competition, find something easier, and move on.

And beyond adoption — bad DX slows everything down internally too.

When your team's own development workflow is painful, onboarding new engineers takes weeks instead of days. Simple tasks become complicated. Simple bugs become mysterious. Time that could go into building features goes into fighting the environment.

Good DX is a multiplier. When your dev tooling, APIs, and internal systems are clean and intuitive:

Developers ship faster
Bugs get caught earlier
Onboarding becomes smooth
Code stays consistent
Teams stay motivated

And that directly improves the final product — which means, ironically, good DX leads to better UX in the end.

Real Benefits of Prioritizing DX (With Examples)

✅ Faster onboarding

When your README is clear, your CLI has a guided setup, and your examples actually work — a new team member can be productive in hours instead of weeks. Think of how Vercel's npx create-next-app gets you running in under two minutes. That's intentional DX at work.

✅ Better error messages mean fewer lost hours

A good error message tells you what went wrong, where, and ideally how to fix it. A bad one says Error: undefined. Rust's compiler is famous for giving helpful, readable error messages. Developers genuinely appreciate that.

✅ Clear docs reduce the "wall of shame"

The "wall of shame" is that moment where you close the docs tab and paste into ChatGPT instead. Stripe's API documentation is a gold standard — clear, well-organized, and full of real examples. When docs are good, developers trust the product.

✅ Intuitive APIs reduce cognitive load

When an API behaves consistently and predictably, developers spend less mental energy remembering edge cases. React's hook design, for example, follows consistent rules that feel natural once learned.

✅ Fast feedback loops keep developers in flow

Hot reloading, instant previews, fast build times — these aren't luxuries. They're productivity tools. When you break a developer's flow with a 30-second rebuild every save, you're draining energy and focus.

UX vs DX: Two Sides of the Same Coin

People sometimes treat UX and DX as competing priorities. They're not. They're complementary.

Area	UX Focus	DX Focus
Who is the user?	End users (customers, visitors)	Developers (builders, integrators)
Key concern	Is the interface easy and pleasant?	Is the tooling easy and productive?
Measured by	Task success, satisfaction, retention	Onboarding time, error rate, adoption
Common pain points	Confusing UI, slow load, broken flows	Bad docs, cryptic errors, fragile setup
Tools that help	Figma, user testing, analytics	CLI tools, SDKs, sandboxes, good docs

The best products invest in both. A beautiful app built on a nightmare codebase will slow down every future improvement. Great DX makes it possible to maintain great UX over time.

Best Practices: How to Improve DX

💡 Write documentation like you're teaching a friend

Don't assume knowledge. Explain what something does, why it exists, and show a working example. Add comments inside code samples. One good example beats three paragraphs of explanation.

💡 Make error messages human-readable

Every error should answer: what went wrong, where did it happen, and what should I do next? If your error message is just a stack trace with no context, it's not helpful.

💡 Build a great getting-started experience

The first five minutes are everything. If a developer can't see results fast, they'll leave. Offer a working starter template, a one-command setup, or a sandbox playground.

💡 Be consistent across your API or codebase

If you name one thing getUserById, don't name the next one fetchUserData. Consistency lets developers predict how things work. Inconsistency forces them to check docs for every single call.

💡 Listen to developer feedback

If multiple developers ask the same question, that's a DX problem — not a developer problem. Update your docs, improve the error, or simplify the flow.

💡 Test your own DX

Hand your tool to a new developer and watch them use it without help. Where do they get stuck? That's where your DX needs work.

Common Mistakes That Kill Developer Experience

❌ Assuming developers will "figure it out"

No, they won't. They'll Google it. If they find a better alternative, they'll use that instead. Good DX is never accidental — it's designed.

❌ Writing docs after the fact

Documentation written as an afterthought shows. It's usually incomplete, outdated, or just confusing. Treat docs as part of the product, not a checkbox you tick before launch.

❌ Returning vague errors

Something went wrong is not an error message. It's an apology that doesn't help. Every error state should give the developer something to act on.

❌ Neglecting the local development experience

If your app needs 12 steps to run locally — environment variables, Docker containers, manual seed data, two separate config files — that's a DX issue. Simplify wherever you can.

❌ Breaking changes without clear migration paths

Introducing a breaking change and just saying "update your code" is painful. Provide changelogs, migration guides, and deprecation warnings. Developers respect that.

❌ Ignoring the onboarding experience for your own internal systems

DX isn't just for public-facing tools. If your internal codebase, CI/CD setup, or component library is confusing, new team members suffer. Internal DX matters just as much.

Conclusion

Here's the bottom line: UX and DX are both about respect.

UX is about respecting your users' time and attention. DX is about respecting your developers' time and energy.

When you invest in Developer Experience, you're not just making life easier for engineers. You're building a foundation that lets great products get shipped faster, maintained better, and improved continuously.

The next time someone says "let's focus on the user experience," add this to the conversation: "And let's also take care of the people building it."

Because when developers feel good about the tools they use and the environment they work in, the things they build are better. And that? That's good for everyone. 😊

If this gave you a new way to think about development, I'd love for you to check out more articles at hamidrazadev.com. There's a lot more on frontend development, tooling, and building things the right way.

If it was useful — share it with a developer friend who deserves better DX. They'll appreciate it. 🙌

DEV Community: Muhammad Hamid Raza

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

What Is VS Code 1.131?

Why This Release Matters

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

👀 Subagents: Finally, Some Visibility

🎙️ Built-In Dictation (Experimental)

📝 Hybrid Markdown Editor (Experimental)

🏗️ Agent Host Architecture (Under the Hood)

🐾 VS Code Pet (Very Experimental)

♿ Accessibility: Quieter, Smarter Terminal Updates

🖥️ Control the Terminal Resize Overlay

🐍 Python: Faster Startup, Smarter Environments

VS Code 1.131 vs 1.130 — What Actually Changed

Tips for Getting the Most Out of 1.131

Common Mistakes to Avoid with These New Features

Wrapping Up

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

What Is Prettier?

Why This Matters

Full Setup Guide (Step by Step)

Step 1: Install Prettier and Its Plugins

Step 2: Create Your Prettier Config

Step 3: Create a .prettierignore File

Step 4: Add npm Scripts

Step 5: Update Your ESLint Config

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

Debugging Every Error (The Real Journey)

🔴 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'

🔴 Error 4: 155 TypeScript and JSX Parsing Errors

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

Pros and Cons: FlatCompat vs Native Flat Config

Final File Checklist

Best Tips

Common Mistakes to Avoid

Wrapping Up

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

What Are Tokens, and Why Do They Matter?

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

Why Claude's Limits Exist: The Bigger Picture

Why This Matters for Developers and Everyday Users

✅ You Can Trust the Output More

✅ Refusals Protect You Too

✅ Long-Context Performance That Holds Up

✅ Better Reasoning, Not Just More Output

Claude vs Other AI Models: A Fair Comparison

Tips: Getting the Most Out of Claude Within Its Limits

Common Mistakes People Make With Claude

❌ Assuming limits mean low quality

❌ Hitting rate limits and blaming the model

❌ Prompting vaguely and expecting perfection

❌ Comparing outputs without comparing task types

❌ Ignoring Claude's uncertainty signals

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

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

What Is VS Code 1.130?

Why This Release Matters

What's New in VS Code 1.130

🔧 The Agent Host — A Smarter Foundation for AI Sessions

✅ Assisted Tool Approvals — Fewer Interruptions, Smarter Decisions

👀 Agents Window Improvements (Preview)

💬 Chat Timestamps

📊 Aggregate AI Credit Usage for Copilot Business and Enterprise

⚡ Clickable File Links in Git Diffs with Mnemonic Prefixes

🏗️ TypeScript 7 — Under the Hood

Before vs. After: Agent Workflows in VS Code

Best Tips for Getting the Most Out of VS Code 1.130

Common Mistakes to Avoid

Wrapping Up

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

What Is a Folder Structure?

Why Folder Structure Actually Matters

The 5 Most Common Folder Structures (With Examples)

1. 🗂️ Flat Structure

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

3. 🧩 Feature-Based Structure

4. 🏗️ Domain-Driven Structure

5. 📦 Monorepo Structure

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

⚡ Run Terminal Commands with `!` from Chat