As someone who has spent years in the Java ecosystem, my relationship with IntelliJ IDEA is incredibly complicated. It truly gets me — its keymaps, its global search, its tool windows, are all ingrained in my muscle memory. But it’s also heavy. Every time I click that colorful little icon, I have to go brew a cup of coffee first. When the screen shows “Indexing…” and the progress bar crawls along, my 32GB of RAM seems to let out a desperate wail.

I often fantasize: What if IDEA could be as fast as lightning, like Zed or Alacritty?

Well, now this fantasy has been monetized (well, open-sourced) by a project called OpenIDEA.

🚀 “The IDE You Know and Love, Rewritten in Rust”

OpenIDEA has already racked up over 400 stars on GitHub just one week after open-sourcing.

Its ambition is incredibly bold: to port IntelliJ IDEA’s way of working (keymaps, tool windows, global search) exactly as it is, into a native application written in Rust and built on top of Tauri.

In short, it wants to give you a replacement that “looks like IDEA, but runs like C.” You might think it’s just a VS Code clone with a new skin? No, it’s actually rewriting the wheel from scratch with Rust.

📊 The Official “Brutal” Benchmark

To prove it’s not just bluffing, the developer released a set of absolutely devastating benchmark comparisons (tested on a Python project called freqtrade containing 770 files).

Look at these brutal numbers (note the comparison target is IDEA 2026.2.3):

• Opening the project window: OpenIDEA takes 0.9 seconds, IDEA takes 3.1 seconds.
• Fully Ready (CPU stable): OpenIDEA takes 1.1 seconds, IDEA takes 13.2 seconds.
• Memory Usage (USS): OpenIDEA takes a mere 169 MB, while IDEA spikes to 2011 MB.
• Quitting the app: OpenIDEA quits instantly (0.3s), IDEA takes 5.9 seconds.

Looking at this data, I can only say: This isn’t optimization; this is dragging IDEA across the coals. What does 169MB of memory even mean? You probably use more than 169MB just opening a single webpage right now. Yet it carries a complete IDE with an editor, debugger, Git, terminal, and even a database client.

Out of curiosity, I downloaded OpenIDEA and used it for an afternoon, and the results were genuinely impressive.

For example, my most frequently used “Double Shift”:

Autocomplete from the LSP, which honestly feels even better than IDEA:

Finding where a symbol is used, almost exactly like IDEA:

Running tests, with the familiar green button:

Breakpoint debugging, the experience is exactly the same as IDEA:

It also has a terminal and an HTTP client. It’s worth noting that the HTTP client is usually a feature reserved for the paid version of IDEA, but OpenIDEA includes it — truly a kind gesture.

🛠️ How Did They Do It?

Looking at its codebase, you’ll find it’s a modern “Frankenstein” of tech:

• Rust (33.9%): Handles core logic and performance-sensitive parts.
• TypeScript (62%): Handles UI and frontend interaction.
• Tauri Framework: Uses the system’s native WebView instead of the bloated Electron (yes, I’m looking at you, VS Code).

It even supports over 60 languages, has built-in terminal themes (like Solarized and One series), and includes oxfmt and oxlint—the ridiculously fast next-gen frontend toolchains. The funniest part? If you look at the contributor list, nestled among the human developers is an AI named @claude.

💡 Should You Ditch Your IDEA?

Don’t rush. OpenIDEA is currently only at v0.1.22. Despite its 437 stars, it still has a long way to go before becoming a mature productivity tool. Its biggest significance right now is sending a wake-up call to JetBrains: In today's world of being squeezed by AI and lightweight editors from both sides, you can't just rest on your laurels by being "heavy" and "memory-hungry."

If you love IDEA’s shortcuts but are fed up with its startup speed, go clone l0ng-ai/openidea from GitHub and give it a try. After all, watching an open-source project use Rust to completely flip the script on a commercial giant—that's a "spectator" thrill unique to programmers that's hard to resist.

A few days ago, JetBrains launched a brand new AI IDE called ThinkRail, attempting a completely different approach to solve the pain points of Agent-driven development.

Unlike JetBrains’ previous AI tool “Air,” which was built on the heavy IntelliJ platform, ThinkRail is actually lightweight. The editor core is built directly on Monaco (the engine behind VS Code), and the underlying architecture is powered by a coding Agent engine called pi. The UI is just a thin shell. It doesn't secretly stitch together Prompts; model management, session compression, and tool orchestration are all handled by pi.

It’s also not like IDEA, where AI is treated as just another plugin. In ThinkRail, AI is the true protagonist.

The most brilliant trick up its sleeve is Git worktree isolation. Traditional AI IDEs read and write code directly in your current working directory. If the Agent screws up, it directly corrupts your source code. ThinkRail creates a new, independent Git worktree for every Agent task, complete with its own dedicated branch and runtime directory.

Let’s take a look at this brand new IDE.

Even though it’s just been released, ThinkRail already supports installation on Windows, macOS, and Linux. You can download and install it from GitHub or their official site at thinkrail.ai.

After installing it, I realized how truly lightweight ThinkRail is — only about 40MB. Compared to VS Code’s 400MB+, it’s 10 times lighter.

Next, we arrive at the ThinkRail homepage.

It’s the first time I’ve seen an AI IDE this clean — just a single “Open Project” button right in the middle.

After opening a project, you’ll see this interface:

Next, you can click on “Default.” This represents the default workspace, which embodies the main feature mentioned earlier: one workspace = one Git worktree.

Once you click it, you’ll see the following interface:

The core area is the chat, which is where you talk to the AI. Before you start chatting, you need to configure a provider.

It also supports OpenRouter, allowing you to use free API keys. If you have a DeepSeek API key, you can just copy and paste it in to use.

Here is how I configured it with DeepSeek:

At the very bottom is the familiar terminal.

On the far right, there are sections for “spec” and “AI changes.” The “spec” part highlights ThinkRail’s main push: spec-driven development.

Click the file icon on the right, and the project files will appear.

We can also select a chunk of code to bring up an inline chat, similar to the VS Code Agent.

Clicking “Command Palette” brings up the familiar command palette from VS Code.

If you want to develop a new feature, you can click “Default” in the top left corner to add a new workspace.

Just like this:

It implemented it very quickly.

Click “Review turn” to see the changes made this time.

Of course, it’s currently an incubated preview project under the InnovationHub. It’s not meant to replace official products like IDEA or PyCharm. It focuses on a browser-based UI, but also offers desktop installers for Windows/macOS/Linux. It’s completely open-source under the Apache-2.0 license.

Compared to the sea of AI editors on the market: others focus on the editor and treat AI as an add-on plugin. ThinkRail flips the script: the Agent is the core, and the editor is merely a window for you to watch the Agent work.

Whether it can outrun Cursor and Zed remains to be seen, but the design philosophy of “don’t let the Agent pollute the main codebase” has already struck a chord with the real pain points of many developers.

For veteran netizens like me, code.visualstudio.com is like the refrigerator at home—as long as it still keeps things cold (or in this case, still lets me download the installer), I couldn't care less if the exterior has turned yellow.

I open VS Code every day, but I rarely visit its official website. Usually, I only go there to check the docs or read the latest release notes.

A few days ago, I dropped by to look up a keyboard shortcut, and I froze on the spot: Is this still the dark, “straight-male-aesthetic” website I used to know?

This update was completely silent. No official announcement, no option to revert to the old version — they just swapped it out on you. But after taking a closer look, I genuinely don’t want to go back.

Here is what changed.

1. No More Getting Blinded: Seamless Light/Dark Mode

The old website was a bit “aloof,” defaulting to a light background. Staring at it during the day felt like making your eyes work overtime. Sure, there was a moon icon to switch to dark mode, but it felt like an afterthought.

Now, the new version natively follows your system’s light/dark theme. The little sun/moon toggle in the top right is gone — it just adapts.

Personally, I prefer setting my system to dark mode.

And here is what the new homepage looks like:

Not only that, but the entire UI has become more rounded, with more whitespace. The large banner screenshots have been replaced with more refined versions. It used to look like a rough manual; now, it has a hint of Apple-like lightweight elegance.

2. Saving the “Archaeologists”: The Blog Finally Has an Archive

In the past, if I wanted to find a deep-dive article on VS Code written six months ago, clicking into the blog would just throw me straight to the latest post. Where did the old articles go? The answer: lost at sea. No directory, no list — digging through history was more painful than writing Assembly.

The new version rolls out an independent blog homepage:

And it uses a card-based layout:

However, VS Code opted not to use pagination to display the articles, which I’m personally not a huge fan of.

3. Documentation Navigation: AI Finally Finds a Home

This is the best part for those who write tutorials or frequently read the docs.

Previously, reading the documentation meant dealing with a sidebar where languages and plugin development categories were all piled up. It was densely packed, and finding something felt like playing a game of “spot the difference.” As for AI-related content? It was scattered all over the place, here, there, and everywhere.

The new version puts sub-modules like documentation into the “Resource” tab:

The left-hand directory is much clearer now:

Finding things is much clearer now — follow the trail, and you won’t get lost.

4. The Features Page

The old website didn’t have a Features page. In the new version, it’s placed directly in the first tab on the left.

You can see that VS Code is being very smart here. It divides its features into two blocks: one is AI development, and the other is the traditional editor. It even dropped the word “code” from the title.

Let’s start with the editor part, which we are all most familiar with.

Here is the homepage for it:

It emphasizes the fundamental capabilities of using VS Code for editing: Edit, Build, Debug.

Then it specifically highlights the most commonly used features:

It also specifically mentions the terminal later on:

5. The Soul-Searching Question: What is the Homepage Actually Selling?

If you compare the copywriting of the new and old homepages, you’ll realize that VS Code’s “persona” has completely changed.

The old version used to say: “Look, I’m lightweight, I’m open-source, I’m an AI code editor.” The new version slaps its face right on the screen: “Look, I have Multi-agent, I have Copilot, I am the ultimate AI coding workbench!”

AI has gone from being a secondary selling point to taking center stage. The download button has also become incredibly prominent, fixed in the top right corner, as if they’re terrified you won’t find it.

The other block is dedicated to agents, which is a key section for VS Code:

The three main stars in here are the Agents window, the Terminal, and the Editor window, which takes third place:

Finally, it’s worth highlighting the newly added global search. Click the search button to search across all content on the VS Code website:

VS Code uses a tool called docfind for search. Even if you misspell a word, it can still locate the document. It’s incredibly useful.

Summary: From “Editor” to “AI Workbench”

What hasn’t changed is the domain — it’s still code.visualstudio.com, and the download link and Marketplace are all still there.

But its soul has evolved. The old website was a pure “code editor website,” while the new website has completely transformed into an “AI intelligent coding workbench website.”

Moreover, the overall structure is much clearer, making it easier for VS Code users to understand the product.

If you have some free time, I highly recommend taking a stroll through the new website. After all, even Microsoft itself is saying that if you can’t write a couple of prompts nowadays, you shouldn’t even call yourself a programmer.

It’s not encountering an unreproducible bug. It’s spending an entire afternoon teaching AI how to write a perfect regular expression, only to start a new session the next day and have it look at you like an amnesiac idiot, asking: “Excuse me, what is a regex?”

Large language models are incredibly smart, but their memory lasts about seven seconds. To turn Claude Code into a “veteran driver” who actually understands your quirks and remembers your codebase conventions, open-source wizards invented something called Skills. Simply put, it’s giving the AI a “cheat sheet” and “muscle memory.”

Recently, someone ranked the Top 10 Claude Code Skills on GitHub by Star count. Let’s start from the bottom and take a reverse climb to see just how hard humanity is working to teach AI how to code.

🔟 #10: Taste Skill (103.7k Stars)

“Taste” is inherently a mysterious, almost philosophical concept. AI-generated code often reeks of mass production — messy formatting, and variables named a, b, and c. This skill attempts to forcefully inject some "aesthetic sense" into the AI, so the code it writes at least looks like a human wrote it. Just look at those 100k+ stars; it shows how desperately we all crave for AI to have a little taste.

9️⃣ #9: Agent Skills (110.8k Stars)

The name couldn’t be more straightforward. It probably grants Claude more powerful autonomous agent capabilities, allowing it not just to answer your questions, but to plan tasks, call tools, and execute complex workflows on its own. It’s essentially installing an “autopilot” system for the AI.

8️⃣ #8: Caveman (115.5k Stars)

The “Caveman” skill pack? The name alone paints a vivid picture. Maybe its purpose is to simplify complex requirements, or make the AI solve problems in the most direct, brute-force way — like a caveman. In today’s world of over-engineered code, sometimes we really need a bit of “back to basics.”

7️⃣ #7: Graphify (136.8k Stars)

The name suggests it’s related to graphs. It likely helps the AI better understand the dependency relationships within complex codebases, preventing it from accidentally deleting parts of the code you didn’t ask it to touch during a refactor. With this, the AI’s “big picture” awareness gets a significant boost.

6️⃣ #6: UI UX Pro Max (141.6k Stars)

This one absolutely deserves a mention! Every time you ask AI to write a frontend page, it always produces an interface filled with purple gradients, centered cards, and a soulless “AI vibe.” This skill pack is probably designed to rescue AI from its suffocating aesthetic sense, finally making the generated pages look like something a real designer created.

5️⃣ 5: PonyTail (177.1k Stars)

A playful name. Ponytail doesn’t make the AI lazy; it forces the AI to “think clearly first, then act, and stop writing nonsense.” It has only one rule: write only what the task truly requires, and never cut corners on validation, error handling, security, or accessibility. (It is essentially the “lazy senior developer” persona that gets straight to the point).

4️⃣ 4: Anthropic Skills (184.5k Stars)

The official golden child finally makes its appearance. No matter how fierce the community creations are, deep down, everyone still feels that officially certified Skills are the safest and most reliable. This is likely the native capability extension pack provided by Anthropic for Claude Code — a must-install “foundation.”

🥉 3: Karpathy Skills (224.7k Stars)

Andrej Karpathy, former AI Director at Tesla and a leading figure in the LLM world. Feeding his skill pack to the AI is like hiring a top Silicon Valley mentor to constantly whisper in your ear: “Bro, this line of code you wrote is a bit anti-human.” The code taste of a tech titan is always the hardest currency.

🥈 2: Matt Pocock Skills (304.9k Stars)

Who is Matt Pocock? He is a god in the TypeScript community. This skill pack ranking #2 proves one absolute truth: The world has suffered long enough from TypeScript’s “type gymnastics.” Obviously, everyone is sick of AI writing any or inferring types incorrectly. Feeding the grandmaster's TS skills directly to the AI is the only way to go.

🏆1: Superpowers (307.4k Stars)

The name sounds like injecting AI with a super serum. Managing to slightly edge out Matt Pocock to take the crown, it is currently the most comprehensive and hardcore all-around foundational capability pack. Everyone wants the AI to learn its “basic internal martial arts” first before venturing into the world.

💡 Why are Skills so popular?

Because the competition among AI IDEs has shifted from “whose model is stronger” to “who understands engineering better.”

Everyone is using Claude 5.5 Sonnet or GPT-6; the raw model capabilities have leveled out. But if you equip Claude with the Clean Code Skill, the code it writes will be cleaner than yours. If you equip it with your company’s code conventions Skill, it becomes your pair-programming veteran instantly.

It’s like playing an RPG. Originally, everyone was a naked starter character. Now, others not only have legendary gear (Skills) but also chugged buff potions. If you are still manually writing Prompts for the AI, you might as well be rubbing sticks together to make a fire in the Stone Age.

In 2026, the market is flooded with products slapping the “AI IDE” label on themselves — more than there are drinks in a convenience store. But when it comes down to it, the ones that can actually put up a fight can be counted on one hand.

Below is my personal ranking, sorted from “Meh” to “Absolute Banger” (from bottom to top). It’s purely my personal bias. If you disagree, come fight me in the comments.

1. Kiro: AWS’s Golden Child, But Way Too “By the Book”

“Meh” Index: ⭐⭐⭐⭐

Kiro is the “Spec-driven” IDE pushed by AWS. Sounds fancy, right? It requires you to write a specification document first, and then let the AI generate code based on that spec. The ideal is beautiful: high code quality and excellent edge-case handling. The reality is brutal: I just want to quickly fix a bug, and you want me to write a PRD first?

Its multi-model routing (you can choose Claude, GPT, or DeepSeek) is genuinely generous, and the free tier is quite forgiving. But that default setting where “all Shell commands require approval” makes impatient people want to smash their keyboards. It’s suitable for enterprise teams with suffocatingly strict processes. For individual developers, it feels more like a strict homeroom teacher than a handy tool.

2. Google Antigravity: Big Ambitions, Rough Edges

“Meh” Index: ⭐⭐⭐

Made by Google, so it must be… hold your horses. Antigravity’s biggest selling point is multi-agent parallelism. You can run several agents simultaneously in one interface doing different tasks, and watch their planning, screenshots, or even browser recordings through “Artifacts.” Sounds like sci-fi.

But in practice, you’ll find yourself spending most of your time writing more precise prompts. Users have reported that the AI sometimes genuinely needs “extra precise instructions” to get things done, and you still have to manually review every single suggestion. The free tier’s model lineup is luxurious (Gemini, Claude, GPT-OSS), but that feeling of “wanting to do everything but falling slightly short on all of them” leaves you with mixed feelings.

3. Devin Desktop (formerly Windsurf): Changed the Name, Same Average Output

“Meh” Index: ⭐⭐⭐

Cognition renamed Windsurf to Devin Desktop, and their ambition is clear: they don’t just want to be an editor; they want to be an Agent Command Center. The Kanban-style agent dashboard is genuinely useful — you can see different agents working at different stages without scrolling endlessly through chat logs.

The problem, however, lies in the output quality. An evaluator asked it to build a website for a residential builder, and the result was “functional, but not impressive,” lacking polish in layout and copywriting. The default SWE-1.6 model performs averagely. If you are looking for “one-click generation of high-quality apps,” you might be disappointed. It feels more like a management tool than a creation tool.

4. Zed AI: Blazing Fast, But AI is Just an “Add-on”

“Meh” Index: ⭐⭐⭐⭐

Zed’s core is built with Rust + GPU rendering, and its speed in opening massive projects absolutely crushes VS Code — official data shows 0.25 to 0.6 seconds compared to VS Code’s 1.3 to 3.8 seconds. That 120 FPS scrolling experience? Once you try it, there’s no going back.

Its AI capabilities are mainly integrated through the ACP protocol to connect external agents (Claude, Codex, Copilot). This means you can run multiple agents simultaneously in Zed, each working independently. But frankly, Zed’s own native AI Agent capabilities are not as aggressive as Cursor or Claude Code.

It is an exceptionally brilliant editor that happens to have an AI interface. If you pursue the ultimate editing experience, Zed is the top choice; if you pursue the ultimate AI capabilities, it might not be the answer.

5. Cursor: The Master of Balance, But a Bit “Heavy”

“Banger” Index: ⭐⭐⭐⭐

Cursor is the kind of choice where “you can’t find any major faults.” Built on the VS Code foundation, you can import your configs with one click, resulting in a zero learning curve. Its Agent mode can autonomously plan and implement features across files, and cloud sub-agents can run tasks in parallel on independent VMs. The TAB autocomplete experience remains top-tier.

But it has two long-standing issues: It’s expensive, and it’s resource-hungry. Third-party models (Claude, GPT) go through API billing, which hurts your wallet. And as a “modded” version of VS Code, it inherited the heavy Electron genes. It is currently the safest “all-rounder,” but that feeling of “good at everything, excellent at nothing” keeps it from reaching true “Banger” status.

(If you aren’t a fan of Cursor’s style, you can also just use VS Code’s native agent, which is a solid alternative.)

6. GitHub Copilot: The Omnipresent “Honest Guy”

“Banger” Index: ⭐⭐⭐⭐

Copilot’s advantage isn’t being the “strongest,” but being the most widespread. It’s available in VS Code, JetBrains, Visual Studio, Neovim, Xcode, and even SQL Server Management Studio. If your team is deeply integrated into the GitHub ecosystem, Copilot’s Agent can start directly from an Issue, run tests in a GitHub Actions sandbox, and open a PR without ever touching your local machine.

The free tier gives you 2,000 completions and 50 advanced requests per month — enough for casual users. However, its Agent capabilities are more conservative compared to Cursor and Claude Code. It won’t give you surprises, but it rarely gives you jump scares either. Enterprise-grade security compliance and IP indemnification are its thickest moats.

7. OpenAI Codex: The King of Cost-Effectiveness, But Don’t Expect a “Soul”

“Banger” Index: ⭐⭐⭐⭐⭐

Codex might not be the number one in benchmarks — Claude Code + Sonnet 5.5 scores 68 on the Coding Agent Index, while Codex + GPT-6.1 scores 63. But look at the cost: Codex averages $1.04 and 15.5 minutes to complete a task; Claude Code takes $14.19 and 1.5 hours.

What does this mean? It means you can let Codex try, fail, and retry. Ten attempts with Codex cost less than three-quarters of a single attempt with Claude Code. It uses GPT-6.1 Sol with extremely low token consumption (3.2M vs Claude’s 27.7M). If you want to efficiently and cost-effectively complete clear tasks, Codex is the most rational choice for 2026. It doesn’t philosophize with you; it just works.

8. Claude Code: Expensive, But It Genuinely “Understands”

“Banger” Index: ⭐⭐⭐⭐⭐

I put Claude Code in the top spot, not because it wins in every single category. It’s expensive — averaging $14 per task, over ten times that of Codex. It’s slow — 1.5 hours per task is enough time for a meal and a nap.

But when you encounter tasks that require a genuine understanding of the codebase, spanning a dozen files, and handling complex business logic, Claude Code’s reasoning depth and task persistence are currently unmatched by other tools. It can stay focused during a long session and won’t forget what it’s doing halfway through. A user once commented that its recommendations “surface proactively, rather than waiting for you to ask.”

The answer might just be that Claude Code is the fastest-evolving AI IDE of them all.

If you treat an AI IDE as a cheap typist, choose Codex. If you treat it as a senior engineer who can hold their own, choose Claude Code. You get what you pay for — especially when you’re so frustrated with other tools that you want to smash your computer.

Today, we are going to take this a step further. We’re going to clean house. Using just the settings.json file, we will strip away every non-essential element to achieve the ultimate, distraction-free, code-only immersive environment.

Here is the complete configuration snippet we’ll be adding:

// Title Bar Configuration
"title_bar": {
  "show_onboarding_banner": false,
  "show_project_items": false,
  "show_branch_name": false,
  "show_user_menu": false
},
// Tab Bar
"tab_bar": {
  "show": false
},
// Top Toolbar
"toolbar": {
  "quick_actions": false
},
// Bottom Status Bar
"status_bar": {
  "experimental.show": false
},
// Project Panel (File Tree)
"project_panel": {
  "dock": "right",
  "default_width": 400,
  "hide_root": true,
  "auto_fold_dirs": false,
  "starts_open": false,
  "git_status": false,
  "sticky_scroll": false,
  "scrollbar": {
    "show": "never"
  },
  "indent_guides": {
    "show": "never"
  }
},
// Outline Panel
"outline_panel": {
  "default_width": 300,
  "indent_guides": {
    "show": "never"
  }
}

Let’s break down what each of these configurations actually does and how it transforms your workspace.

1. title_bar: Clearing the Clutter

"title_bar": {
  "show_onboarding_banner": false,
  "show_project_items": false,
  "show_branch_name": false,
  "show_user_menu": false
}

• show_onboarding_banner: Disables the welcome banner so you don't get those newbie prompts every time you open a project.
• show_project_items: Hides the project name in the title bar.
• show_branch_name: Hides the current Git branch. (If you hate glancing at the branch name constantly, turn this off).
• show_user_menu: Hides your user profile avatar in the top right corner.

Result: The title bar retains only the native OS window controls, ditching Zed’s built-in project, branch, and user info. It looks exceptionally clean.

User Info:

2. tab_bar: The Ultimate Immersion

"tab_bar": {
  "show": false
}

This is the favorite configuration for immersion lovers. It completely disables the top file tab bar.

The Shift in Workflow: You no longer use your mouse to click and switch tabs. Instead, you transition to a pure keyboard-driven workflow: use Ctrl+P to quickly find files, and Ctrl+Tab to jump between recent files. Perfect for heavy keyboard users.

3. toolbar: Removing Quick Actions

"toolbar": {
  "quick_actions": false
}

This hides the shortcut buttons just below the title bar, such as Git operations and AI assistant shortcuts. Fewer clickable buttons mean a less scattered interface.

4. status_bar: Blanking the Bottom

"status_bar": {
  "experimental.show": false
}

The status bar usually displays line/column numbers, LSP status, and Git status. By disabling it, the bottom of your screen becomes completely blank, maximizing your screen real estate for actual code.

5. project_panel: The Minimalist File Tree

"project_panel": {
  "dock": "right",
  "default_width": 400,
  "hide_root": true,
  "auto_fold_dirs": false,
  "starts_open": false,
  "git_status": false,
  "sticky_scroll": false,
  "scrollbar": {
    "show": "never"
  },
  "indent_guides": {
    "show": "never"
  }
}

• dock: "right": Moves the file tree to the right side of the editor (unlike VS Code's default left alignment).

• default_width: 400: Sets the default width to 400px.
• hide_root: true: Hides the top-level project root folder, displaying files directly. This eliminates one layer of visual nesting.

• Effect after hiding:

• starts_open: false: The file tree is closed by default when you launch Zed. Summon it only when needed.
• git_status: false: Removes the color-coded Git markers (added/modified) from the file tree.

• After turning it off, your Git-modified files will look just like unmodified ones.
• sticky_scroll: false: Disables sticky directory headers when scrolling.
• scrollbar.show: "never": Permanently hides the file tree scrollbar (use your mouse wheel).
• indent_guides.show: "never": Hides the directory indent guide lines.

Result: The file tree itself is lightweight. It doesn’t start by default, has no scrollbars, no indent lines, and no Git markers. It only appears when manually summoned.

6. outline_panel: Stripping Down the Outline

The outline panel is displayed by default.

"outline_panel": {
  "default_width": 300,
  "indent_guides": {
    "show": "never"
  }
}

This panel displays the functions, classes, and variables of the current file. Here, we disable the indent guides to maintain the minimalist style consistent with the file tree. The default width is set to 300px.

Bonus Tip: Resizing the File Finder

One last thing worth mentioning is that you can customize the size of the File Finder (Command Palette) pop-up.

Personally, I prefer the xlarge layout for a more spacious look.

The Philosophy Behind This UI Purification

The core philosophy of this configuration is simple: Hide all panels by default, summon them on demand, and remove all decorative lines and markers.

The interface is left with only the main code editor area, almost entirely devoid of UI elements.

• Switch files: Ctrl+P
• Open file tree: Ctrl+B
• Open outline: Ctrl+Shift+O

It is a completely keyboard-driven workflow. By reducing mouse usage, your visual focus remains entirely on the code.

Zed vs. VS Code: The UI Control Battle

VS Code has relatively weak native control over its UI elements:

1. You can’t easily hide the Tab bar without relying on plugins.
2. You can’t natively close the Status bar; it also requires plugins.
3. Scrollbars, indent guides, and Git markers in the file tree have very limited native control.

Zed, on the other hand, bakes all these UI toggles directly into settings.json. You don't need any extensions. It natively supports fine-grained control, and changes take effect instantly without restarting the editor. This is a major reason why many developers seeking a minimalist interface are flocking to Zed.

Final Thoughts

If the previous theme_overrides article was about "painting," this article is about "spring cleaning."

Zed natively provides incredibly delicate UI toggles. We can hide tabs, status bars, redundant buttons, and auxiliary lines to create a coding canvas with almost zero redundancy.

This extreme minimalist mode is perfect for developers who don’t want to be distracted by UI elements while writing code. By shifting all panels from “always-on” to “on-demand,” you pivot entirely to a keyboard-driven development flow. Yes, there is a learning curve — you need to memorize basic shortcuts — but once you get used to it, your level of coding immersion will increase dramatically.

It’s not accidentally dropping the production database. It’s not forgetting to git commit before a major refactor. It’s when you are juggling a dozen files—frantically jumping between logic, styles, and config files—and your finger slips. You accidentally click “Close Others.”

Staring at the suddenly empty, barren wasteland of your tab bar, you take a deep breath and console yourself: “It’s fine. I’ll just hit Ctrl+Z to undo… oh wait, no, I need to hit Ctrl+Shift+T (Reopen Closed Editor) to bring them back.”

So, you press it once. One file returns. You press it again. A second file appears. You press it a third time. A third file is back…

If you just closed 15 files, congratulations. You now need to act like a human typewriter, mashing the shortcut a dozen times in a row, all while praying you don’t accidentally hit the wrong key combination and mess up the sequence. It feels exactly like dropping a stack of coins on the floor and having to squat down to pick them up one by one. It’s a massive waste of energy, and frankly, it’s terrible for your mental health.

Well, this “anti-human” experience has finally been slain by a recent VS Code update.

The VS Code team has completely overhauled the file history service: “Reopen Closed Editor” now supports bulk operations!

Simply put, if you use a destructive, screen-clearing action like “Close All” or “Close Others” to wipe out N files, you now only need to press Ctrl+Shift+T once. All N files will return to your screen in a group, in the exact order they were closed. It perfectly recreates your workspace from right before you slipped up.

Let’s take a look at the magic in action:

Use the shortcut Ctrl+K, M (Close All) to close everything:

Now it’s completely empty.

Then press Ctrl+Shift+T, and instantly, all the closed tabs are restored one by one:

🧠 How does it work under the hood? (The Programmer’s Magic)

It sounds simple, but the underlying implementation is quite delicate. How does the editor know if you “closed a bunch at once” versus “closed them one by one manually”?

The VS Code team introduced a brilliant mechanism: the Batch ID (batchId).

In the code, every file closure is tagged. If several files are closed within the same “synchronous turn,” they share the same batchId, meaning they are treated as a single "batch." Once the timeline moves to the next "microtask," the batch resets.

This allows the system to accurately distinguish between “bulk close” and “single close,” while preserving the original index and “sticky state” of each file at the lower level.

🎉 The End of “Memory Game” Overtime

Although the code change for this feature isn’t massive, the exponential boost it brings to daily developer happiness is huge. It rescues countless developers who have panicked and spammed shortcuts after accidentally hitting “Close All.”

Now, your undo capabilities finally match the speed of your clumsy fingers. No matter how many files you impulsively close, a single shortcut brings the entire army marching right back. After all, a programmer’s time should be spent writing bugs, not practicing the one-finger typing technique on keyboard shortcuts.

For example, with massive structs generated by protobuf, deeply nested configuration objects, or anonymous structs used for one-off parameter passing — half of your code is just repeating type names. It feels like doing meaningless manual labor.

Now, Go 1.28 is bringing us a famous proposal that has been lying dormant since 2015, discussed for a full 11 years: Type inferred composite literals.

This means: as long as the context can clearly infer the target type, you can directly delete the type name before the composite literal and just keep the braces and content.

For many developers willing to type less, this is definitely a cause for celebration, because we’ve spent countless hours on this issue.

✅ Let’s Look at the Comparison First

Old syntax (Go 1.27 and earlier, forced to write full types):

type Point struct {X,Y int}
var p Point
p = Point{1, 2}

var plist []Point
plist = []Point{p, Point{3,4}}

// Protobuf nightmare, copying long type names repeatedly
p.Options = append(p.Options, &foopb.Foo_FrotzOptions_Option{Value: 123})

New syntax (Go 1.28):

type Point struct {X,Y int}
var p Point
p = {1, 2} // Equivalent to Point{1,2}

var plist []Point
plist = {p, {3, 4}} // Equivalent to []Point{p, Point{3,4}}

// Protobuf scenario ecstasy, no more pasting giant pb type names
p.Options = append(p.Options, {Value:123})

Maps, nested slices, nested structs, function parameters, channel sends, and returns are all supported:

map[string]Point{"orig": {0,0}}

// Function parameters can directly use {}, anonymous struct parameters are great
func Foo(args struct{A,B,C int}) {}
Foo({A:1,B:2,C:3})

// Return scenario, saying goodbye to repeating struct types
return {}, err

But there is an ironclad rule, which is also the red line many care about most: there must be context!

The following two lines are illegal, and the compiler will directly throw an error:

q := {1, 2} // ❌ No! := has no pre-specified target type, the compiler can't guess what this is
var r Point = ({1, 2}) // ❌ Parentheses aren't recognized for this

The left side/target location must already be fixed to a type, then you can be lazy and only write {}; without a "target expectation," you cannot write bare {1,2}.

Also note that this new feature does not yet apply to generic scenarios, for example:

package main

type Foo[T any] struct {
	A int
	B T
}

func main() {
	hello({
		A: 42,
		B: "hi", // cannot use "hi" (untyped string constant) as T value in struct literal
	})
}

func hello[T any](f Foo[T]) {}

🕰️ Why Did This Proposal Take 11 Years?

Many people’s first reaction: such a great syntax, why was it proposed in 2015 but didn’t land until Go 1.28? There’s a very classic Go team dilemma hidden here.

Back in 2015, when it was first proposed, the Go team had actually tried to do exactly this before the Go 1 release, and then actively rolled it back and cut it.

adg (a Go core member) said at the time: overall, it tended to make the code less readable on balance.

Go’s design philosophy has always been: better to type a few more characters than to ensure the code reads without ambiguity. Go has always been wary of “implicit inference” and “syntactic sugar” bringing reading traps.

The biggest concern back then was ambiguity. Someone in the comments threw out the soul-searching question:

const A = "A"
var m map[string]int
m = {A:1}

var x struct { A int }
x = {A:1}

The exact same {A:1} could be either a map or a struct. Looking at the code in isolation, you can't immediately tell what it is.

This was the biggest controversy: typing less on the keyboard, but adding cognitive burden for the person reading the code. The Go team at the time felt the trade-off wasn’t worth it, so it was shelved.

So why pick it up now?

Years of community practice have revealed a lot of high-frequency pain points:

1. Protobuf generates massive nested structs, pasting long type names everywhere makes the code bloated, and readability is actually ruined by the long type names.
2. One-off anonymous struct parameters in functions are meant for bulk parameter passing; repeating types is very verbose.
3. The high-frequency template of return struct + err, where return {}, err is very clean.
4. Existing Go already supports some literal omission rules; this just unifies and extends the rules, making the language rules themselves more self-consistent.

A netizen’s perspective is very profound, and I think it’s also the core reason that ultimately convinced the Go team:

Simplicity is a double-edged sword. It can both enhance clarity and reduce it. We can’t stop bad programmers from writing unreadable code, but we shouldn’t add burden to good people writing clear code just to prevent bad code.

Bad people who want to write confusing code will always find a thousand ways; you can’t deprive good people of the tools to simplify clean code just because someone might abuse the syntax.

💬 The Community Is Split: Classic Views from Both Sides

This proposal sparked heated comments among gophers, a famous debate arena in Go history. Both sides have very representative views. It’s clear many love this new feature, and many equally oppose it.

✅ Supporters (Ecstatic Faction)

• Developers writing protobuf or heavily nested structs: this is a lifesaver. Previously, nested three or four levels deep in pb structs, literals were stinky and long.
• Developers writing tools, business functions, or heavily returning structs: return {}, err, ch <- {val: "xx"} feels great, removing noise.
• People who like lightweight tuple-style writing: Go doesn’t have native tuples, but this feature gives a lightweight tuple experience. Foo({A:1,B:2}) looks clean.

⚠️ Opponents/Cautious Faction (Conservative Faction, also representatives of old-school Go thought)

1. Readability disaster theory: Looking at a single line {A:1,B:2} out of context, you have no idea if it's a struct, map, or slice. Newcomers reading code have to scroll up to find the type.
2. Increases language complexity: Go’s proud simple syntax adds another set of rules, remembering when it can be omitted and when it can’t, raising the learning barrier for beginners.
3. Ambiguity risks: The {A:1} ambiguity that minux raised back then still exists today; the team just considers the risk manageable "as long as there's clear context."

There’s also an interesting neutral view: calling this feature “untyped composite literal” is actually misleading. “Untyped” has a strict definition in Go. It’s not fundamentally an untyped literal; it just extends the positions where types are allowed to be omitted. It’s an extension of existing rules, not something entirely new. This view also influenced the spec wording of the final released version.

In my personal experience, Rex feels like a massive upgrade in terms of experience, texture, and capabilities: persistent sessions, smooth low-latency remote connections, program execution status displays, and a highly aesthetic UI.

Many people are wondering: Ghostty is already fast enough. What problem is Rex actually trying to solve?

Whether it’s Alacritty or Ghostty, their core focus has been on rendering performance, fonts, and refresh rates. Essentially, they are still just “beefed-up black boxes.” Command outputs are just plain text; JSON logs and error stacks are just a bunch of characters with zero interactivity.

Rex’s approach is completely different. Developed by Superlogical, it’s currently in public Beta and positions itself as a “sentient terminal.” It understands the structured information in command outputs, automatically identifying errors, file paths, Git status, and JSON data. Content is no longer a rigid block of text; you can click to jump, fold, and preview. It is built for AI-driven development workflows from the ground up, making it an absolute perfect match for Claude Code.

When using Claude Code daily, a lot of interactions get stuck in the terminal: AI provides a fix, executes a command, outputs logs, and we have to switch windows back and forth just to copy content. Rex breaks down this barrier. It understands the current session context. When you run Claude Code inside it, the terminal recognizes the AI’s output, error links can jump directly to code files with one click, and long outputs are automatically structured and formatted. No more squinting through endless logs to find the key information.

Let’s feel what it’s like to use Claude Code inside Rex.

Step 1: Enter the claude command.

Entering the familiar Claude Code interface.

Next, we can click the split-screen button in the top right corner.

The design here feels a lot like splitting the screen in VS Code.

Enter the claude command again, and now you have two Claude Codes running on the same screen.

This “cloning” ability is actually not natively available in the Claude Code CLI. You usually have to open another terminal window and type claude, which introduces the highly annoying window-switching fatigue.

What’s even better is Rex’s management of multiple Claudes. Click the three dots to the right of the Claude Code tab, and you’ll see a list of multiple Claude Code sessions, with “done” indicating the current task is complete.

Click the eye icon in the top right corner to customize the interface layout.

You can change horizontal tabs to a vertical layout. This experience is truly creative for developers.

Even with this layout, you can still monitor the status of multiple Claudes.

In the past, building and running software spanned across local machines, remote hosts, sandboxes, services, and production environments. The execution modes varied: manual interactive operations by developers, automated executions by CI and background processes, and increasingly, parallel working AI agents.

These tasks are inherently connected, but the sheer diversity of today’s tools fractures them into isolated systems. Interactive tools default to human-facing UI; automated tasks drown in a sea of tasks and logs; and once deployed to production, they are isolated behind entirely different systems and access controls.

The rise of AI has amplified the pain and cost of this fragmentation, but AI didn’t cause it. For decades, system operations, CI, remote development, and team collaboration have been chipping away at these fractured boundaries.

Powerful AI tools like Claude Code have, to some extent, actually solved this fragmentation, allowing software building to be done through a unified entry point and natural language.

That said, let’s throw some cold water: Rex is currently in testing, prioritizing macOS support. To experience it, you need to go to the Superlogical official website, subscribe to the email list, and get a Beta invite. The ecosystem is still being polished, so don’t expect it to replace your main terminal immediately.

Fun fact: Rex’s author, Mitchell Hashimoto, is also the author of Ghostty.

If Ghostty is “the fastest terminal,” then Rex is positioned as the “terminal workbench for the AI era.” As coding agents like Claude Code become more ubiquitous, the terminal shouldn’t just be responsible for running commands. Rex shows us a new possibility: the terminal is both a command-line carrier and an interaction hub between AI assistants and code.

The terminal racetrack has finished competing on speed. Now, it’s starting to compete on intelligence.

As a Python developer, have you ever experienced these scenarios?

• You’re coding at lightning speed, but the formatting is a mess.
• You’ve imported a bunch of libraries but can’t remember their names.
• You’ve spent ages debugging only to find a missing bracket.
• You’re writing documentation and start questioning your life choices…

Don’t panic! Today, I’m sharing 10 VS Code Python extensions that I’ve personally tested. They’ll more than double your efficiency! 🚀

🏆 The Top 10 Must-Install Extensions

1️⃣ Python (by Microsoft) — Official and Excellent

This is the official Python extension from Microsoft, and it’s incredibly comprehensive:

# Feature list:
✅ Linting (Pylint/Flake8)
✅ Debugging (without leaving the editor)
✅ IntelliSense
✅ Jupyter Notebook support
✅ One-click Python environment switching

💡 My Take: This is the foundation, like rice — you’ll starve without it, and you need it to do anything else!

2️⃣ Pylance — Blazing-Fast Type Checking

This is the official successor to Pyright, so fast it’ll make your head spin:

# Core features:
 Smart type completion (faster than you can think)
📚 Auto-import missing modules
💬 Hover to see docs and type info
🔍 Quick symbol definition lookup
📝 Auto-sort imports per PEP8

Real-world scenario:

# When you type 'pd.', Pylance instantly pops up:
DataFrame    Series    read_csv    read_excel...
# And shows type hints automatically. Sweet!

💡 My Take: Used to be I’d take a sip of coffee waiting for completions. Now… they appear before I even react!

3️⃣ Visual Studio IntelliCode — AI-Powered Intelligence

While the Python extension has IntelliSense, this AI-enhanced version is on another level:

# After AI scans your code:
- Recommends the most likely functions to use
- Sorts intelligently based on context
- 30%+ higher accuracy than the basic version

Comparison:

# Basic version:
requests.get()  # Ranked 5th

# IntelliCode:
requests.get()  # Ranked 1st! Because AI knows you use it often

💡 My Take: It’s like having a veteran who knows your next move… a bit scary, but oh so good!

4️⃣ Sort Lines — A Blessing for the OCD

Imported a chaotic pile of libraries? One click to sort, and everything feels right with the world:

# Before:
import os
import sys
import numpy as np
import pandas as pd
import json

# After Sort Lines:
import json
import numpy as np
import os
import pandas as pd
import sys
# World peace 🕊️

Supports 12 sorting methods:

• Alphabetical (case-sensitive/insensitive)
• By line length
• Natural sort (smart number grouping)
• Deduplication, random shuffle…

Shortcut: Cmd + Shift + P → Type Sort Lines

💡 My Take: My favorite is Natural sort. It won't put pandas2 after pandas10, and I appreciate that!

5️⃣ Black Formatter — The Unifier of Code Formatting

Black is the most popular formatting tool in the Python world, and this extension integrates it seamlessly into VS Code:

// settings.json configuration:
{
  "[python]": {
    "editor.defaultFormatter": "ms-python.black-formatter"
  }
}

Benefits:

• ✅ Compliant with PEP8
• ✅ Consistent team code style
• ✅ Saves PR discussion time (“Your spacing is wrong!”)
• ✅ Auto-format on save

💡 My Take: Our team used to argue for half an hour over 2 vs. 4 spaces. Now… Black decides!

6️⃣ Indent Rainbow — Colorful Indentation

Python relies on indentation for syntax, and this extension gives it a rainbow glow:

def my_function():        # Level 1 - Blue
    if condition:         # Level 2 - Green
        for i in range(10):  # Level 3 - Pink
            print(i)      # Level 4 - Cyan
            # See the hierarchy at a glance!

Custom colors:

{
  "indentRainbow.colors": [
    "rgba(255,255,64,0.07)",
    "rgba(127,255,127,0.07)",
    "rgba(255,127,255,0.07)",
    "rgba(79,236,236,0.07)"
  ]
}

💡 My Take: Use with Indentor for a visual experience that makes reading nested code like eating Skittles! 🌈

7️⃣ Bracket Pair Colorizer — Bracket Matching Made Easy

Good news: This functionality is now built into VS Code natively!

# How to enable:
1. File → Preferences → Settings
2. Search for "bracketPair"
3. Check "Bracket Pair Colorization"

Effect:

def outer():         # Outer bracket - Red
    if True:         # Middle bracket - Yellow
        for i in []: # Inner bracket - Green
            pass
# See which bracket matches which at a glance!

💡 My Take: Especially useful when reading JSON files. No more counting “which closing bracket is this?”

8️⃣ Sourcery — AI Refactoring Master

This isn’t an ordinary completion tool; it’s a real-time code quality consultant:

# Your code:
result = []
for i in range(10):
    if i % 2 == 0:
        result.append(i)

# Sourcery suggests:
result = [i for i in range(10) if i % 2 == 0]
# One line, Pythonic! ✨

Highlights:

• 🔧 Real-time refactoring suggestions
• 📊 Code quality scoring
• 🎓 Teaches you more elegant Python

💡 My Take: Like having a senior dev sitting beside you, pointing out “this could be more Pythonic,” and you grow fast!

9️⃣ Python Docstring Generator — Documentation Generator

Write functions without docs? This extension quickly generates docstring templates:

def calculate_area(length, width):
    """
    Calculate the area of a rectangle.
    
    Args:
        length (float): The length of the rectangle
        width (float): The width of the rectangle
    
    Returns:
        float: The calculated area
    
    Raises:
        ValueError: If length or width is negative
    """
    return length * width

How to use: Type """ and press Enter to auto-generate the template!

💡 My Take: Writing docs is now as easy as filling out a form — no more excuses! 😅

🔟 Dash — The Offline Documentation Lookup Master

No need to open a browser; look up docs directly in VS Code:

# Use case:
1. Select `pandas.DataFrame.groupby`
2. Press Ctrl + H
3. Instant official documentation (offline!)

Advantages:

• 📖 Supports official Python docs
• 🚀 10x faster than Google
• 📴 Works without internet
• 🎯 Precise targeting, no scrolling through search results

💡 My Take: This saved my life on a flight! Offline docs, yyds!

🎁 Bonus: GitLens — Git Enhancement Pack

Not Python-specific, but highly recommended if you use Git:

# Core features:
 Git Blame - See who changed each line
📝 Git Changes - Highlight local modifications
⏰ Git History - View file history

Real-world scenario:

# Seeing weird code:
if x == 42:  # GitLens shows: Zhang San, 3 months ago
    # Why 42?
    do_something_weird()

# Go ask Zhang San directly: "Bro, what's this about?"

💡 My Take: The ultimate tool for shifting blame… I mean, tracing code history! Essential for teamwork!

📊 Summary: Efficiency Comparison Table

Extension Name · Efficiency Boost · Recommendation · Target Audience

Extension Name: Python (Microsoft) · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Must-have · Target Audience: Everyone

Extension Name: Pylance · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Must-have · Target Audience: Everyone

Extension Name: IntelliCode · Efficiency Boost: ⭐⭐⭐⭐ · Recommendation: Highly Recommended · Target Audience: AI Enthusiasts

Extension Name: Sort Lines · Efficiency Boost: ⭐⭐⭐ · Recommendation: Recommended · Target Audience: OCD

Extension Name: Black Formatter · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Must-have · Target Audience: Team Development

Extension Name: Indent Rainbow · Efficiency Boost: ⭐⭐⭐ · Recommendation: Recommended · Target Audience: Visuals

Extension Name: Bracket Pair · Efficiency Boost: ⭐⭐⭐⭐ · Recommendation: Recommended · Target Audience: Heavy JSON Users

Extension Name: Sourcery · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Highly Recommended · Target Audience: Quality Control

Extension Name: Docstring Generator · Efficiency Boost: ⭐⭐⭐⭐ · Recommendation: Recommended · Target Audience: Docs Enthusiasts

Extension Name: Dash · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Must-have · Target Audience: Frequent Doc Lookup

Extension Name: GitLens · Efficiency Boost: ⭐⭐⭐⭐⭐ · Recommendation: Must-have · Target Audience: Git Users

🎯 Final Thoughts

As a Python developer, choosing the right tools really does double your results with half the effort!

My personal combo:

Foundation Trio: Python + Pylance + IntelliCode
Formatting Trio: Black + Sort Lines + Indent Rainbow
Quality Guardian: Sourcery + Docstring Generator
Efficiency Accelerator: Dash + GitLens

💡 Honest Truth: With these extensions, you’ll find:

• Coding is faster
• Fewer bugs
• More elegant code
• Most importantly: Less overtime! 😄