Coder Legion - Recent posts tagged vscode

Cline + any OpenAI-compatible gateway: Base URL ends at /v1

Tue, 27 Oct 2026 09:22:37 +0000

Cline (the independent VS Code / JetBrains coding agent — not affiliated with this post) has a first-party “OpenAI” provider and a separate OpenAI Compatible provider. For a custom gateway you want the second one.

1. Smoke-test outside the IDE

export LLM_API_KEY='…'
export LLM_BASE_URL='https://api.china-aiapi.com/v1'

curl -sS "$LLM_BASE_URL/models" -H "Authorization: Bearer $LLM_API_KEY" | head

Pick a MODEL_ID that appears in that list.

2. Cline settings

API Provider → OpenAI Compatible
Base URL → https://api.china-aiapi.com/v1 (stop at /v1; do not append /chat/completions)
API Key → value of $LLM_API_KEY (no Bearer prefix)
Model → MODEL_ID
Open Model Configuration and set context window / max tokens yourself; custom providers do not infer them

3. Optional CLI shape (if your Cline build ships cline auth):

cline auth -p openai -k "$LLM_API_KEY" -b "$LLM_BASE_URL" -m "MODEL_ID"

Troubleshooting

Symptom → Likely cause
404 on chat → Base URL missing /v1 or has an extra /v1/v1
401 → Key not exported / pasted with trailing space
Model not found → MODEL_ID ≠ an id from /models
Tiny context / early cuts → Model Configuration left at defaults

Happy to compare notes if anyone is wiring Cline through a corporate OpenAI-compatible proxy instead of a hosted gateway.

Disclosure: I work on the APIGOTO team; independent of OpenAI, Anthropic and Google. Cline is an independent product. Example gateway used above is ours (pay-as-you-go, logs only if enabled in settings): www.china-aiapi.com · https://api.china-aiapi.com/v1

🚀 Managing MCP Servers in VS Code? Explore SEOSiri MCP Suite Manager!

Thu, 15 Oct 2026 15:41:32 +0000

As AI-powered development evolves, managing Model Context Protocol (MCP) integrations is becoming an important part of building connected developer workflows. A well-organized MCP setup can help developers connect AI tools with external services, tools, and data sources.

🛠️ Meet SEOSiri MCP Suite Manager

Explore our VS Code extension for MCP server management and developer workflows.

💡 Why explore MCP management?
🔹 Developer Productivity: Organize your MCP-related development workflow within VS Code.
🔹 AI Tool Integration: Explore MCP server configurations for compatible AI clients and development environments.
🔹 Workflow Optimization: Simplify the process of working with MCP server setups.
🔹 Developer Ecosystem: Build toward more connected AI-assisted development workflows.
🔹 Project Opportunities: Get in touch with SEOSiri for development, optimization, and digital marketing support.

🔗 Visit the SEOSiri Visual Studio Marketplace:
https://marketplace.visualstudio.com/publishers/seosiri

📦 Get MCP Suite Manager:
https://marketplace.visualstudio.com/items?itemName=SEOSiri.seosiri-vscode-mcp-manager

🤝 Need help developing, optimizing, or marketing your developer product? DM SEOSiri to discuss your project and potential collaboration.

The future of AI development depends not only on capable models, but also on the tools and integrations that connect them.

Build. Integrate. Optimize. Make it discoverable.

MCP #ModelContextProtocol #VSCode #AIDevelopment #DeveloperTools #SEOSiri

FramePort: HDMI Capture Directly Inside VS Code

Thu, 24 Sep 2026 11:47:06 +0000

Hi everyone!

I'm a college junior, and I built FramePort while working on Tomato, my custom 32-bit computer with a dual-LUT ALU running on an Artix-7 FPGA.

I wanted to see its HDMI output beside my assembly code without constantly switching to OBS. So I built a VS Code extension that brings live video capture directly into the editor.

FramePort supports HDMI capture cards, cameras, and other compatible video sources, with features including:

Live video preview with adjustable scaling
Screenshot capture
Silent MP4 recording

Although I originally built it for Tomato, I figured it could also be useful for Raspberry Pi projects, embedded systems, and other hardware-development workflows.

Here's FramePort running alongside Tomato's assembly code:

FramePort is now available on Open VSX as a public preview for macOS. It requires FFmpeg and a compatible capture device.

Try FramePort: https://open-vsx.org/extension/tmarhguy/frameport

Source code: https://github.com/tmarhguy/frameport

I'd love feedback from anyone interested in testing FramePort or contributing to its development!

Developer Weekly Briefing — September 4, 2026

Fri, 04 Sep 2026 12:35:46 +0000

A strong week with two hard deadlines attached. GitHub Copilot's billing and governance changes start landing September 1 — one of them already hit. Developers and platform teams have until September 28 before the next wave takes effect. Here's everything that mattered.

GitHub Copilot's billing and governance rules are changing this fall — dates matter

Three separate changes are rolling out across Copilot Business and Enterprise between now and late September, and all three have calendar implications.

The first already took effect September 1: new seat assignments now require upfront payment before a user gets access. Existing customers have until October 1. The mechanics shift meaningfully — organizations are charged at the start of each billing cycle, with additional charges for usage that runs past what's included. Admins used to adding and removing seats on the fly will need to rethink that process, especially at billing cycle boundaries.

The second change is the one compliance teams should flag immediately. No earlier than September 28, GitHub is merging Copilot Cloud Agent, the github.com chat experience, and GitHub Mobile Chat into one unified experience. Buried in that consolidation: chat data retention changes from 28 days to the lifetime of the account. Any organization with data retention policies, audit requirements, or contractual obligations around AI-generated conversations needs to review its settings before that date, not after.

The third change, also September 28: the default code review effort level shifts from "Lite" to "Balanced" across all repositories and organizations. Teams that want to keep the lighter behavior need to explicitly select Lite before the switch. Under token-based billing, deeper reviews mean more tokens consumed per pull request — which means higher costs if nobody notices the default changed.

As Futurum Group's Mitch Ashley put it: "Engineering leaders should assign an owner to those defaults now, before the invoice makes the decision for them."

Copilot can now approve pull requests — not just review them

GitHub moved Copilot from advisory to authoritative in code review this week. Copilot's sign-off can now count toward a repository's required-approvals rule, the same way a teammate's would.

The guardrails are more careful than the headline suggests. Approvals are off by default. Admins opt in at the enterprise, organization, or repository level. Repository admins can restrict which file paths Copilot is allowed to approve at all — letting teams scope it to documentation and test fixtures while keeping authentication and payment logic strictly human-reviewed. Push a new commit after approval and the approval is dismissed automatically, same as a human reviewer.

The governance question worth sitting with, from Futurum Group's Mitch Ashley: "Approval is where code review stops being advice and becomes authority, and GitHub just moved Copilot across that line. An automated reviewer earns that trust the same way a person does — through outcomes you can point to. Engineering leaders should turn this on and instrument it to measure the effectiveness of approvals."

That instrumentation doesn't come built in. If Copilot's approvals count the same as a human's, someone needs to build dashboards showing how often it approves correctly, how often a human catches something after the fact, and whether speed is coming at the cost of depth. Teams that skip that step and flip approvals on everywhere at once are trading a review bottleneck for a governance gap.

VS Code 1.135 adds Rubber Duck — a second AI model to critique the first one

The headline addition in VS Code 1.135 is Rubber Duck, an experimental feature that puts a different model to work reviewing the primary coding agent's plans, code, and tests before anything ships. Type /rubber-duck in a Copilot agent session and a complementary model looks for gaps the first one missed.

The same release introduces the Agent Host Protocol — a dedicated process for running agent harnesses that lets developers connect to the same session from multiple VS Code windows. Sessions now show agent work started in other applications, including Claude or Copilot sessions outside VS Code, so context doesn't get lost when you switch windows. Per-model token tracking in the chat footer gives teams a clearer read on what each model costs per turn.

Mitch Ashley's useful caveat: "Rubber Duck answers verification pressure with more generation, and that only goes so far." A second model catching more edge cases is still generation, not independent verification. Worth keeping that distinction in mind before treating Rubber Duck's output as a stamp of correctness.

Microsoft opens up its Agent Framework with Channels — one agent, every surface

Microsoft's Agent Framework team published Channels this week — open-source Python packages that let a single agent connect to multiple communication platforms and protocols without a separate implementation for each. Launch integrations cover OpenAI's Responses API, Telegram, the Agent2Agent (A2A) protocol, and MCP.

The architecture is notable for what it leaves out of scope: identity mapping, authentication, authorization, and session storage are still the application's responsibility. Microsoft made that explicit rather than abstracting it away, which keeps Channels auditable but also means teams can't treat it as a governance shortcut.

Mitch Ashley's read: "Microsoft is acknowledging something important: no single vendor owns the enterprise agent estate, so the channel layer has to speak protocols it does not control. Building on A2A and MCP instead of a Microsoft-only path matches what enterprises want."

Debian's AI vote: accountability instead of a ban

Debian developers voted on AI policy this week after a two-week community ballot with eight separate proposals, including an outright ban that would have required a supermajority to pass. It didn't come close. The policy that won neither endorses nor prohibits generative AI — it holds contributors to the same standard regardless of how code got written: you reviewed it, you tested it, and nothing sensitive left the building to get it.

Disclosure is encouraged, not mandated. Three specific guardrails came with it: no confidential material or credentials to third-party AI services without explicit authorization, no bulk automated contributions without prior discussion, and the copyright question is explicitly punted downstream.

The insight worth carrying into enterprise AI policy discussions: Debian didn't try to regulate the tool. It regulated the behavior around the tool, which is considerably easier to enforce. You can't reliably detect LLM-generated code. You can hold the person who submitted it accountable for what it does.

A simple website summary task exposed the limits of AI coding guardrails

A researcher assigned an AI coding agent a task so basic it barely registers as a task: summarize a website. The agent found an edge case that required executing external code to complete the job, did so, and the guardrails didn't catch it. The post is a useful reminder that guardrails are tested against anticipated misuse, not every combination of legitimate task plus unexpected environment. The agent wasn't trying to do anything wrong. It was trying to finish the job.

CrowdStrike Fal.Con 2026: Falcon Guardian, SafeMind, and the end of "breakout time." George Kurtz retired the metric and made the case that attacks now happen at inference speed. Falcon Guardian goes GA, SafeMind pairs an offensive and defensive model built on NVIDIA Nemotron, and Jensen Huang, Lip-Bu Tan, and Greg Brockman all had things worth hearing. Read more
Cycode's AI scanner found 38 bugs in MLflow. The press release only mentioned one. When we pushed on the benchmark methodology, the CTO's written follow-up had more detail — and a few numbers that didn't match the press release. Read more
F5's AI WAF caught 15 zero-days before a human ever saw them — built on a custom neural network rather than a fine-tuned LLM, for reasons that come down to latency and data path. Read more
Act Security's Amphi shrinks a 30,000-character AWS IAM policy down to 7,000 — live demo, same permissions, a quarter of the size, free and open source. Read more
76% of enterprises with HA/DR still went down this year. The top blocker isn't cost — it's configuration complexity, at 44%. Only 7% test DR monthly. Read more
Jazz's Roi Vanunu: "agentic" should describe what a security tool finishes, not what it is. A precise and useful reframe of how to evaluate AI security vendor claims. Read more

The through-line this week: governance is catching up with capability across the board — Copilot billing controls, PR approval authority, Debian's accountability-over-ban model, and Channels leaving identity to the application. The tooling is maturing. The question in every case is whether the governance catches up before the default decides for you.

September 28 is the next hard date. Put it on the calendar now.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Orchestrating Model Context Protocol in IDEs: The SEOSiri VS Code MCP Manager (v1.0.2)

Fri, 28 Aug 2026 16:15:26 +0000

If you are running multi-server Model Context Protocol (MCP) setups across Cursor, Claude Desktop, and VS Code, you already know the friction: syntax errors in mcp.json, mismatched npx vs uvx arguments, un-sandboxed extension permissions, and zero visibility into remote edge health.

To solve this, we engineered and open-sourced seosiri-vscode-mcp-manager (now live on the Visual Studio Marketplace):

🛠️ What it does under the hood:

vscode_generate_mcp_config: Auto-compiles validated .vscode/mcp.json and claude_desktop_config.json snippets for zero-setup execution.
vscode_audit_extension_manifest: Audits package.json extension manifests for activation triggers and permission leaks.
vscode_sync_workspace_settings: Synchronizes linters, TypeScript configs, and approved MCP tool lists across development teams.
vscode_inspect_live_gateways: Real-time sub-10ms health and latency checks across Cloudflare Workers edge nodes (vscode.seosiri.com).

📦 Lightweight Architecture:

Bundled with esbuild down to 73 KB (single-file CJS runtime, zero bloated node_modules in the VSIX bundle).

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=SEOSiri.seosiri-vscode-mcp-manager
Architecture Guide: https://www.seosiri.com/2026/08/vscode-mcp-manager.html
Developer Portal & Topology: https://developers.seosiri.com/

Would love feedback from engineers building autonomous agents and custom MCP tools!

Show DEV: I built an AI Agent inside VS Code

Tue, 18 Aug 2026 12:20:28 +0000

Hey everyone,

For the past few months, I’ve been building Kalai Agent, a VS Code extension designed to bring fully agentic AI directly into your editor, bypassing the need to constantly copy-paste code snippets into a browser tab.

It’s finally at a stable v2.1.5, and I’m looking for some brutal engineering feedback on the architecture, security flows, and UX.

The Architecture & Tech Stack

Instead of building a wrapper around a basic chat interface, I wanted something that could safely interact with the local workspace.

Frontend: VS Code Webview API with batched streaming to prevent UI thread stuttering.
LLM Engine: Proxied Moonshot/Kimi API.
Backend: A lightweight Node service managing auth, workspace routing, and pay-as-you-go billing.
Capabilities: File-system operations, local terminal command execution, Python/Node script running, and web search capabilities.

Check it out

If you want to take it for a spin, install it directly from the marketplace:
Kalai Agent - Visual Studio Marketplace

If you run into bugs, have notes on the UI, or just think a specific feature is clunky, drop a comment below or email us on culustech@gmail.com. I’m entirely open to critiques!

The Code Works. So Why Does It Still Feel Like Bad Software?

Fri, 14 Aug 2026 14:10:18 +0000

There is a dangerous sentence in software development:

“But it works.”

A feature works.

The tests pass.

The pull request is merged.

The deployment succeeds.

And yet, three months later, nobody wants to touch that code.

Why?

Because working software and healthy software are not the same thing.

As developers, we often measure success by whether the code produces the expected output. But software has another dimension that is harder to measure:

How easy is it to understand, change, debug, and trust?

That difference becomes increasingly important as a project grows.

1. Code is written once, but maintained many times

When you write a function today, you know exactly why it exists.

Six months later, another developer opens it and sees:

processData()

Inside that function:

validation
database queries
business rules
API calls
logging
error handling
formatting

Everything works.

But nobody knows where one responsibility ends and another begins.

The problem isn't that the code is "wrong."

The problem is that the cost of understanding it has become too high.

Good software isn't just code that computers can execute.

It's code that humans can reason about.

2. Complexity is a form of technical debt

We usually think technical debt means:

“We used a bad implementation and we'll fix it later.”

But technical debt is often much more subtle.

It can look like:

if (user && user.account && user.account.settings) {
    ...
}

It can look like a 700-line service class.

It can look like five different ways of handling errors in the same project.

It can look like a developer needing to open seven files just to understand one business rule.

None of these necessarily break production.

But they increase the mental cost of every future change.

And that cost compounds.

A small amount of complexity today becomes a large amount of friction tomorrow.

3. The best developers don't just write code

They reduce future decisions.

Imagine two implementations.

Implementation A:

It solves the problem in 20 lines.

Implementation B:

It solves the problem in 35 lines, but makes the behavior obvious, isolates responsibilities, and makes future changes predictable.

Which one is better?

Not always B.

And that's the important part.

Clean code isn't about maximizing abstraction, creating interfaces everywhere, or turning every function into a design-pattern showcase.

It's about making the right trade-offs.

Sometimes the simplest solution really is the best solution.

Sometimes a little duplication is better than introducing another abstraction.

Sometimes a 10-line function is better than a "flexible" 100-line framework.

Good engineering is knowing the difference.

4. Ask a different question during code review

Instead of only asking:

“Does this work?”

Try asking:

“What happens when we need to change this?”

That question exposes a lot.

What happens if:

the database changes?
the API starts returning a new response?
we add another payment provider?
the business rule changes?
traffic increases 10x?
a new developer has to debug this at 2 AM?

You don't need to predict the future perfectly.

You just need to avoid making obvious future changes unnecessarily painful.

5. Boring code is often excellent code

Developers sometimes want to write clever code.

I understand the temptation.

Elegant one-liners are satisfying.

Complex abstractions can feel impressive.

But production software doesn't reward cleverness.

It rewards predictability.

The best code often looks boring.

A developer should be able to open a file and quickly answer:

What does this do?
Why does it exist?
What does it depend on?
What can go wrong?
Where should I make a change?

If the answers are obvious, you've probably done something right.

6. Your future self is another developer

One of the best ways to think about code quality is this:

Pretend someone else will maintain your code.

Then remember:

That person might be you.

Six months from now.

At 1:47 AM.

With a production incident.

Suddenly that clever shortcut doesn't look so clever anymore.

Good software development isn't just about making today's feature work.

It's about leaving behind a system that doesn't punish the next person who has to work on it.

The real definition of “done”

Maybe we should stop saying:

“The feature is done because it works.”

A better definition might be:

The feature is done when it works, is understandable, is testable, and can be changed without unnecessary fear.

That's a much higher standard.

And we probably won't meet it every time.

That's okay.

Software engineering isn't about writing perfect code.

It's about continuously reducing the amount of unnecessary complexity we leave behind.

Because eventually, every developer learns the same lesson:

The hardest code isn't the code that doesn't work.

It's the code that works perfectly—and nobody understands why.

What do you think?

What's one piece of code you've inherited that worked perfectly but was almost impossible to maintain?

I'd love to hear the worst or funniest example you've encountered.

10 VS Code Extensions Every Frontend Developer Needs

Fri, 24 Jul 2026 05:00:00 +0000

Introduction

I used to install every extension that looked interesting — ended up with 40+ extensions and a VS Code that took 10 seconds just to open. Eventually I stripped it back down to the ones I actually use every single day.

These 10 are the ones that survived that cleanup. If you're setting up a fresh frontend dev environment, start here.

1. ESLint

Catches bugs and enforces consistent code style before you even run your code. If you're working in a team (or want to look like you know what you're doing), this is non-negotiable.

2. Prettier — Code Formatter

Auto-formats your code on save. No more arguing about tabs vs. spaces or where semicolons go — Prettier just decides and moves on.

Setup tip: Enable "Format on Save" in VS Code settings so it happens automatically.

3. Tailwind CSS IntelliSense

If you're using Tailwind (and you should be, per Article 3), this gives you autocomplete for class names, shows the actual CSS values on hover, and even highlights conflicting classes.

4. Auto Rename Tag

Rename an opening HTML/JSX tag and the closing tag updates automatically. Small thing, saves real time, especially in nested JSX.

5. Bracket Pair Colorizer (Built-in now)

VS Code now has this built in by default — matching brackets get color-coded so you can actually see which { belongs to which } in deeply nested code. Just make sure it's enabled in settings.

6. GitLens

Shows you who changed a line of code and when, right inline in the editor. Incredibly useful once you're working with any kind of version history — even solo projects benefit from seeing your own commit history at a glance.

7. Live Server

Spins up a local development server with live reload in one click — no need to manually refresh the browser every time you save a file. Especially useful for plain HTML/CSS/JS projects without a build tool.

8. Thunder Client

A lightweight REST API client built directly into VS Code. If you're testing an API endpoint for a project, you don't need to leave your editor or open Postman separately.

9. Error Lens

Shows error and warning messages inline, right next to the line of code causing the problem, instead of making you check the Problems panel. Cuts down debugging time noticeably.

10. Material Icon Theme

Purely visual, but genuinely useful — gives every file type a distinct, recognizable icon in your file explorer. Makes navigating a large project noticeably faster once your eyes learn the icon shapes.

How to Install Any of These

Open VS Code
Click the Extensions icon in the sidebar (or Ctrl+Shift+X)
Search the extension name
Click Install

That's it — no restart usually needed.

Final Thoughts

You don't need 40 extensions to be productive — you need the right 8 to 10. Install these, use them for a week, and you'll notice fewer small annoyances and less time spent on formatting, tag matching, and manual browser refreshing.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Taming the Python and VS Code Workspace Environment

Sat, 11 Jul 2026 13:18:24 +0000

The Setup Blueprint
Constructing a reliable Python pipeline in VS Code requires anchoring the system with isolated environments. After deploying the editor and core extensions, the workflow shifts to generating a distinct environment layer. Linking the terminal profile to initialize this space automatically upon workspace boot keeps the development loop tight.

Where the Environment Breaks

Silent package drifting where pip installs dependencies globally because the active terminal failed to inherit the workspace context.

Debugger configuration conflicts resulting from launch JSON files pointing to generic entry files rather than the active workspace module.

Formatters clashing violently when Black and Yapf attempt to format the same file simultaneously on save.

Environment variable leakage where local env files are ignored by the built-in debugging terminal.

Restoring System Stability
Fixing these active environment issues means enforcing strict automation. Leveraging workspace-specific settings files forces the editor to bind directly to the local project directory structure. Crafting explicit launch configurations inside the hidden configuration directory guarantees that the debugger always triggers the correct entry script. Designating a single formatting tool while strictly disabling competing linters prevents save-on-format loops. Injecting an explicit path mapping into the environment setup ensures the debugging terminal natively loads all local secret keys.

Visit our official site: www.nextbigcreative.com

Built Log Stripper: A VS Code Extension to Remove Debug Logs Across 23+ Languages

Tue, 30 Jun 2026 19:55:01 +0000

Every developer has a version of this story.

You're about to open a pull request. The code works. The tests pass. Everything looks good.

Then you do one final scan and find this:

console.log("HERE");
console.log("user:", user);
console.log("final:", result);

And then, before the PR:

Search → Delete. Search → Delete. Search → Delete.

I got tired of it. So I built a tool to automate it.

What is Log Stripper?

Log Stripper is a VS Code extension that removes debug, log, and print statements from 23+ programming languages - with a preview so you always see what will be deleted before anything changes.

VS Code Marketplace
GitHub

The Features

Preview mode - Ctrl+Shift+D

Shows every line that will be removed. You confirm. Only then does anything change.

Highlight mode - Ctrl+Shift+H

Marks debug lines in red. No file modification. Review first, strip later.

23+ languages

JS, TS, Python, Java, Go, Rust, C#, Swift, Kotlin, Dart, Ruby, PHP, C, C++, Shell, Lua, Scala, Elixir, Haskell, R, Vue, Svelte, JSX/TSX

Workspace cleanup

Strip debug statements from an entire project in one command.

Why not just use grep/sed?

You could. But:

No preview
No multiline support
No VS Code integration
No safety rules
Works differently on Windows vs Mac vs Linux
Log Stripper handles all of this inside VS Code with a consistent UX.

The Interesting Technical Part: Multiline Removal

Removing a single-line console.log("x") is trivial. The interesting case is:

console.log(
  "user:",
  JSON.stringify(user, null, 2),
  "role:",
  user.role
);

To remove this correctly, you need to:

Find the opening (
Track paren depth across lines
Handle parens inside strings (don't count those)
Find the exact closing ) and optional ;
Remove the entire block without touching surrounding code
Here's the core of skipParenBlock:

function skipParenBlock(lines: string[], startLine: number) {
  const openIdx = lines[startLine].indexOf("(");
  let bal = 1, li = startLine, ci = openIdx + 1;
  let inStr: string | null = null;
 
  while (li < lines.length) {
    const s = lines[li];
    while (ci < s.length) {
      const ch = s[ci];
      if (inStr) {
        if (ch === "\\") { ci += 2; continue; }
        if (ch === inStr) inStr = null;
      } else if (ch === '"' || ch === "'" || ch === "`") {
        inStr = ch;
      } else if (ch === "(") {
        bal++;
      } else if (ch === ")") {
        bal--;
        if (bal === 0) {
          ci++;
          if (s[ci] === ";") ci++;
          return { endLine: li, endCol: ci };
        }
      }
      ci++;
    }
    li++; ci = 0;
  }
}

Architecture Decision

I separated the core logic from the VS Code layer:

src/
├── extension.ts   ← VS Code commands, UI, workspace
└── stripper.ts    ← Pure logic, zero VS Code deps

Why? Because stripper.ts can be tested without launching a VS Code host:

node --test out-test/test/stripper.test.js

151 tests. Fast. No mocking needed.

Safety Rules

The extension will never remove:

// console.log("commented") ← comment line, always kept
return console.log(x);       ← inline code, always kept
const x = doThing() || console.log("fallback"); ← inline, kept

Only whole-statement debug calls that are the entire line (after indentation) are removed.

The Languages Covered

Language	Examples
JS/TS	`console.log`, `debugger`
Python	`print()`, `logging.debug()`, `breakpoint()`
Java	`System.out.println`, `logger.debug()`
Go	`fmt.Println`, `log.Fatal`
Rust	`println!`, `dbg!`, `eprintln!`
C#	`Console.WriteLine`, `Debug.Write`
Swift	`print()`, `NSLog()`
Ruby	`puts`, `binding.pry`
PHP	`var_dump()`, `dd()`
Shell	`echo`, `printf`
...13 more	-

Try It

# Install from Marketplace
code --install-extension saurabhchoudhary.log-stripper

Or search "Log Stripper" in the VS Code extensions panel.

Open a file with debug statements → Ctrl+Shift+D → see the preview → confirm.

Toggle Debug Highlights | Highlight/unhighlight debug lines

Preview & Strip Current File | Shows preview, then strips on confirm

Command Palette | Strip Entire Workspace | Clean whole project

Right-click → menu | Strip Current File | Strip without preview

Editor toolbar icons (eye / eye-closed / trash)

Built this because I couldn't find a tool that did all of this properly. Turned out to be one of the most satisfying weekend projects I've done.

If you try it, I'd love feedback in the comments or as a GitHub issue.

By Saurabh Choudhary - Software Engineer

Introduction

Every developer has a version of this story.

You're about to open a pull request. The code works. The tests pass. You're ready. Then you do one last scroll through the file and see it:

console.log("HERE");
console.log("user data:", JSON.stringify(userData));
console.log("response", res);

Three debug logs you forgot to remove. You delete them, re-run the linter, and open the PR.

Two weeks later, someone reports that production logs are noisy with debug output. A developer on your team had left a logger.debug() in a hot path. Nobody caught it in review.

This isn't a rare occurrence. It's a pattern that plays out in every team, on every codebase, in every programming language.

I've experienced it across JavaScript, TypeScript, PHP, Go, Python, Vue.js, NestJS, Laravel, and Angular projects. Different languages, different ecosystems - same repetitive problem.

Eventually I stopped accepting it as "just part of the workflow" and decided to build a proper solution.

That solution is Log Stripper - a VS Code extension that removes debug, log, and print statements from 23+ programming languages with a safety-first, preview-driven approach.

The Problem

The problem has two dimensions that are easy to underestimate.

First: it's repetitive. Before every commit, before every PR, before every release, developers go through the same manual process of searching for and deleting debug statements. On large codebases with dozens of files touched in a single feature branch, this becomes genuinely time-consuming.

Second: it's error-prone. Humans miss things. A console.log inside a nested callback, a print() inside a conditional branch, a System.out.println buried in a Java service - these are easy to overlook when scanning files manually. And when they slip through, they end up in production.

There's also a subtler issue: developers working under time pressure will rush the cleanup. The more pressure, the more likely something gets missed.

This is exactly the kind of task that should be automated. It is deterministic, repetitive, and rule-based. A computer should do it.

Why Existing Workflows Were Frustrating

Before building Log Stripper, I searched for existing solutions.

I found a few extensions that handled console.log removal for JavaScript. Some worked well for that specific case. But they had significant limitations:

Language coverage was narrow. Most extensions focused exclusively on JavaScript. If you wrote Python, Go, Java, or Rust, you were on your own.

No preview mode. Several extensions deleted statements immediately without showing you what would be removed. That's unsafe. A developer who accidentally removes a legitimate logger call in production code will stop trusting the tool immediately.

No highlight mode. Sometimes I want to see the debug statements in a file without removing anything yet. I want to review them, understand them, decide manually. None of the tools I found offered non-destructive inspection.

No workspace cleanup. File-by-file cleanup doesn't scale. Before a major release, I want to scan an entire project and clean everything in one pass.

Unreliable multiline handling. A console.log that spans multiple lines is common:

console.log(
  "processing user:",
  JSON.stringify(user, null, 2)
);

Many tools would only remove the first line and leave the rest, creating syntax errors.

Why I Built Log Stripper

The decision to build rather than adapt came down to one realization: the problem deserved a proper solution, not a workaround.

I wanted an extension that:

Worked across every major language I use day-to-day
Showed a preview before making any changes
Could highlight debug lines without modifying files
Could clean an entire workspace safely
Was smart enough to never break code it shouldn't touch
Was backed by automated tests
None of those requirements are unreasonable. Together, they're the minimum bar for a tool I'd actually trust.

The weekend I started building it, I intended it to be a one-day project. It grew into something more substantial as I realized the edge cases, the safety requirements, and the value of doing it properly.

Architecture

The most important architectural decision I made was separating the core logic from the VS Code integration layer.

The repository has two source files:

src/
├── extension.ts    ← VS Code commands, UI, workspace operations
└── stripper.ts     ← Core strip logic (zero VS Code dependencies)

stripper.ts has no awareness of VS Code. It takes a string of text and a language ID, and returns a new string with debug statements removed plus metadata about what was changed. That's it.

This separation has two major benefits:

Testability. I can test the core logic without launching a VS Code Extension Development Host. The 151 automated tests run with a plain node --test command. Fast, simple, reliable.

Maintainability. If VS Code changes its API, or if I want to port the logic to a CLI tool or a git pre-commit hook, the core logic doesn't need to change.

The VS Code layer handles everything user-facing: commands, keybindings, settings, decorations, progress notifications, and workspace file scanning.

Multi-Language Support

Supporting 23 languages sounds ambitious. The implementation is actually straightforward once you have the right architecture.

Each language is a key in the LANGUAGE_PATTERNS object, and its value is an array of regular expressions:

const LANGUAGE_PATTERNS: Record<string, RegExp[]> = {
  javascript: [
    /^(\s*)console\.(log|debug|info|warn|error|trace|...)\s*\(/,
    /^(\s*)debugger\s*;?$/,
  ],
  python: [
    /^(\s*)print\s*\(/,
    /^(\s*)logging\.(debug|info|warning|error|critical)\s*\(/,
    /^(\s*)breakpoint\s*\(\s*\)/,
  ],
  // ... 21 more languages
};

Language aliases handle cases where VS Code's language ID differs from the pattern group:

const LANG_ALIASES: Record<string, string> = {
  svelte: "javascript",
  "vue-html": "vue",
  typescriptreact: "typescript",
};

When the extension receives a file, it looks up the language ID, finds the pattern list, and applies each pattern against every line. If no patterns are found for a language, the file is returned unchanged.

Adding a new language is a matter of adding one entry to LANGUAGE_PATTERNS and a set of test cases to stripper.test.ts. The infrastructure handles the rest.

Preview Mode

The preview mode was the feature I was most deliberate about designing.

When a developer triggers "Preview & Strip" with Ctrl+Shift+D, the extension:

Runs the stripping logic internally (without modifying the file)
Collects the list of lines that would be removed
Shows a modal dialog listing those lines with their line numbers
Waits for explicit confirmation before making any changes
This turns a potentially destructive operation into a fully transparent, opt-in action. The developer sees exactly what will happen and retains full control.

The modal includes the first 20 matching lines and appends "...and N more" if there are additional matches. This keeps the dialog readable on files with heavy debug coverage.

If the developer cancels, nothing changes. Not a single character in the file is modified.

Highlight Mode

Highlight mode solves a different need: I want to see the debug statements but I'm not ready to remove them yet.

When the developer presses Ctrl+Shift+H, the extension:

Finds all lines matching debug patterns using findDebugLineIndices()
Applies a VS Code text decoration that highlights those lines in red
Adds an inline annotation "← debug" at the end of each line
The file is not modified. This is purely a visual overlay.

Pressing Ctrl+Shift+H again (or clicking the eye-closed icon in the toolbar) removes the highlights.

The highlight controller also handles three lifecycle events automatically:

When you strip the file, highlights are cleared (no red lines on lines that no longer exist)
When you edit the file and refreshHighlightsOnEdit is enabled, highlights recompute after a 120ms debounce
When you switch tabs and clearHighlightsOnTabChange is enabled, highlights are cleared automatically

Workspace Cleanup

The workspace strip command scans every file in the project matching the supported language extensions and strips debug statements from each one.

The implementation uses VS Code's workspace.findFiles() API with exclusion patterns to skip node_modules, dist, .git, vendor, build, and out by default. All exclusion patterns are configurable in settings.

The operation runs with a progress notification showing the current file being processed and a cancellation option. After completion, a summary shows how many statements were removed across how many files.

Because this modifies files on disk, the documentation explicitly recommends using version control. A git diff after the workspace strip is always informative.

Safety Design

Safety was a first-class concern throughout the design.

The extension enforces several rules to avoid breaking code it shouldn't touch:

Rule 1: Whole-line only. A debug call is only removed if it is the entire statement on the line (after indentation). This prevents removal of:

return console.log(x);         // kept - inline with return
const result = doWork() || console.log("fallback");  // kept - chained

Rule 2: Comments are never touched. Any line where the first non-whitespace characters form a comment prefix (//, #, --, /*, *) is skipped entirely.

Rule 3: Multiline paren balancing. When a debug call spans multiple lines, the extension tracks open and close parentheses (accounting for parens inside strings) to identify the exact end of the statement. The closing ) and optional ; are consumed, and any remaining code on that final line is preserved.

Rule 4: No modification on cancel. Preview mode never touches the file unless the user explicitly confirms. The stripping logic runs on an in-memory copy of the text, and the result is only written back if the user says yes.

Testing Strategy

I wanted the extension to be trustworthy. That required a proper test suite.

The tests live in test/stripper.test.ts and use Node's built-in test runner - no Jest, no Mocha, no additional dependencies. The test command is:

tsc -p tsconfig.test.json && node --test out-test/test/stripper.test.js

The 151 test cases cover:

Every language in LANGUAGE_PATTERNS
Simple single-line removal
Multiline call removal with paren balancing
Comment preservation
Inline code preservation
Real-world code samples (NestJS controllers, Python classes, Go functions)
Language aliases (Vue, Svelte, JSX, TSX)
Unknown languages (should be a no-op)
The findDebugLineIndices() function (used by highlight mode)
Each test specifies the input code, the expected output, and the expected removal count. Any test that would cause the extension to modify code it shouldn't - or fail to modify code it should - is a failing test.

Writing tests before polishing features was the right decision. It caught several edge cases during development and gave me confidence when refactoring the paren-balancing logic.

Publishing to the VS Code Marketplace

The Marketplace publishing process is simpler than I expected.

The key steps:

Create a publisher account at marketplace.visualstudio.com
Generate a Personal Access Token from Azure DevOps with Marketplace → Manage scope
Install @vscode/vsce globally: npm install -g @vscode/vsce
Run vsce package to create the .vsix file
Run vsce publish --pat TOKEN or upload the .vsix manually via the publisher portal
The .vscodeignore file controls what goes into the package. I excluded src/, test/, and node_modules/ - only the compiled out/ directory ships. This keeps the extension lightweight.

One thing I'd emphasize: set the repository.url in package.json before publishing. It shows up prominently on the Marketplace listing and signals to users that the extension is open source and maintainable.

Lessons Learned

Separate your core logic from your integration layer. This applies far beyond VS Code extensions. Any time you can isolate the testable business logic from the framework or platform code, do it. It makes everything easier.

Safety features build trust. The preview mode and the "never remove inline code" rule weren't technically necessary for the extension to work. But they're what make a developer comfortable trusting the tool with real production code.

Test the edge cases first. Multiline calls, strings containing parens, empty files, unsupported languages - these were the cases most likely to cause silent failures. Writing tests for them before the happy path forced me to build robust logic from the start.

Ship before it's perfect. The first version didn't have highlight mode. The workspace strip was added later. Shipping v1 with the core feature - preview and strip - got real feedback faster than spending another two weeks on features users might not need.

Small tools have real value. This isn't a SaaS platform. It's not an AI product. It's a focused tool that does one thing well. Developer tools like this get used quietly but consistently. That's enough.

Future Improvements

Several improvements are on the roadmap:

Custom pattern rules. Allow developers to define their own patterns to remove. For teams using custom logging frameworks, this would make Log Stripper work with any codebase.

Pre-commit hook integration. A script or CLI wrapper that can run as a git pre-commit hook, catching debug statements before they ever reach a commit.

Team-wide configuration. A .logstripper.json configuration file that defines excluded patterns per project, shareable across a team through version control.

Ignore comments. A // log-stripper-ignore annotation that tells the extension to skip a specific line or block.

More language coverage. Zig, Nim, OCaml, and Erlang are candidates for future additions.

Conclusion

Log Stripper is a small tool. It solves one problem, and it solves it well.

But the process of building it taught me something more valuable than any individual feature: the instinct to look at a repetitive problem and ask "why am I doing this manually?" is one of the most productive instincts an engineer can develop.

We accept small frictions as part of the job. We work around limitations instead of fixing them. We solve the same problem repeatedly instead of automating it once.

Log Stripper exists because I stopped accepting one of those frictions.

If you're reading this and you have something similar - a small repetitive task, an annoying workflow step, a gap in your tooling - build the solution. The process will teach you more than you expect, and the tool will serve you for years.

Try Log Stripper:

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=saurabhchoudhary.log-stripper

GitHub: https://github.com/saurabhzaiswal/Log-Stripper-VS-Code

I'm actively improving Log Stripper, so real-world feedback is incredibly valuable.

If Log Stripper helps keep a few forgotten debug statements out of production, then it has already paid for itself.

I built a free IDE extension to catch malicious npm packages before they wreck your project

Thu, 18 Jun 2026 08:44:52 +0000

Supply-chain attacks via npm are up year-over-year — packages like event-stream,
the Lazarus group drops, and AI-hallucinated typosquats keep landing in real codebases.
I got tired of finding out after the fact, so I built NPM Safety Guard.

What it does

It scans your package.json and lockfiles right inside your editor — no separate CLI step.

Here's what it currently catches across 22 detection layers:

Known malicious packages — DPRK RAT drops, Lazarus-linked packages, event-stream clones
CVEs — via OSV.dev, cached locally (free, no API key needed)
Typosquatting & homoglyph attacks — catches lodahs, reàct, and AI-hallucinated package names
Install script hooks — flags preinstall/postinstall before you run them
Deep tarball AST scan — detects obfuscation, eval, and payload patterns in the actual source
Dependency confusion — scoped packages planted on public npm to hijack private installs
Exposed secrets — API keys, tokens, private keys accidentally left in .env, .npmrc, .pem
MCP server config scanner — catches typosquatted or malicious MCP transport configs
Supply chain graph — interactive force-directed graph with risk overlay from your lockfile
OSSF Scorecard + Socket.dev score — security hygiene at a glance

Where to get it

VS Code / Cursor / Windsurf → VS Code Marketplace
VS Codium / open-source IDEs → Open VSX Registry
WebStorm / IntelliJ IDEA / all JetBrains IDEs → JetBrains Marketplace

All free. No account required for the core layers. MIT licensed on the VS Code side.

Under the hood

The VS Code extension is TypeScript. The JetBrains plugin is Kotlin. They share the same
detection signatures bundled at build time — no cloud dependency for the core scan.

CVE lookups hit OSV.dev with a 24-hour local cache so you're not waiting on a network
call every keystroke.

Have you been burned by a supply-chain attack before? Or do you have a detection layer
you wish existed? Drop it in the comments — I'm actively adding new signatures.

Why I Feel at Home in the Microsoft Development Environment

Thu, 04 Jun 2026 17:25:02 +0000

There is a certain "antigravity" feeling when your tools just work.

I’ve spent a lot of time jumping between different setups, but lately, I’ve found a real sense of comfort in the Microsoft development ecosystem. It’s not just about the brand; it’s about the seamless flow between the editor, the terminal, and the cloud.

Why it works for me:

VS Code is the heart: From React development for my Arabiz project to simple script editing, the extension ecosystem (like GitHub Copilot and the integrated terminal) keeps me in "the flow."

Integrated Terminal: As I was working earlier today, being able to switch from PowerShell to CMD or WSL within the same window is a huge productivity booster.

The Ecosystem: With GitHub and Azure integration, the path from "local code" to "production" feels much shorter than it used to.
I noticed the #antigravity tag—sometimes it really does feel like Python’s famous joke: when the environment is set up correctly, you feel like you can just fly.

What about you?

Do you prefer the Microsoft stack, or are you strictly a Vim/Linux purist? I’d love to hear what makes your dev environment "comfortable."

development #developers #vscode #antigravity

FocusForge

Thu, 07 May 2026 18:07:41 +0000

Let me be real with you.

Last semester, I was convinced I was putting in solid hours every day. I'd sit down at 10am, open VS Code, and look up at the clock — it'd be 4pm. Six hours. That felt productive.

But when exam season hit and I needed to actually measure what I'd been doing, I had nothing. No data. No proof to myself. Just vibes and a half-finished project.

I tried timer apps. I tried Toggl. I tried writing it down in Obsidian. None of it stuck because the context switch killed me — having to go outside my editor to log a session meant I just... didn't.

And VS Code? VS Code, which I live in for 8+ hours a day, had absolutely nothing built in for this.

No session timer. No focus score. No "hey, you've been idle for 20 minutes, are you still actually working?" No Pomodoro. No history of which projects ate your week. Nothing.

That gap felt absurd to me. So I built something.

Meet FocusForge

FocusForge: Coding Session Tracker — a VS Code extension that turns your editor into a local-first productivity cockpit.

It tracks what actually matters:

Real active time — not just "window open" time. It detects when you're idle and separates it from genuine work time.
Focus Score — a live gauge built from your active ratio, flow minutes, break hygiene, and idle interruptions.
Pomodoro Mode — 25/5/15 defaults, auto-advance, sound, status badges, all native inside VS Code.
Flow State detection — once you've been heads-down for 25 minutes straight, it recognizes that and tracks it separately.
Project analytics — auto-detected from your Git workspace so you know exactly where your hours are going.
Session journal — add a mood, a one-liner about what you worked on, blockers. Perfect for standups.
100+ achievements — because learning to code is hard, and small wins matter.
GitHub Issue integration — log, comment, close issues right from your sidebar.
Weekly reports — Markdown or HTML, saved locally in .vscode/session-reports/.

All of it lives in your VS Code global state. No cloud. No account. No extension-owned backend. Your data is yours.

The Problem VS Code Doesn't Solve (Yet)

Here's what surprised me when I started building this: VS Code is incredibly powerful but treats your time as completely invisible.

You can see which file you're editing. You can see Git blame. You can see lint errors in real time. But it has no concept of:

How long you've been coding today vs. how long you've had the editor open
Whether you're in a flow state or just context-switching every 3 minutes
Which project is actually consuming your week (hint: never the one you think)
How many Pomodoros you completed before you hit burnout
What you were working on last Tuesday when your team asks in standup

For students especially — where there's no manager tracking your hours, no ticket system forcing structure — this invisibility is brutal. You lose entire weeks without realizing it.

FocusForge makes all of that visible.

How It Actually Works

When you open VS Code with FocusForge installed, it starts a session automatically. From there:

The Today tab gives you a live dashboard — active time, idle time, efficiency percentage, current state (active / idle / paused / flow / deep work), a Focus Score gauge with color zones, and a 12-week contribution-style heatmap.

Deep Work Mode is my personal favourite. It's a focused coding block that hides the activity bar, mutes notifications, and gives you a full-screen distraction-free environment with a countdown. When you're studying for a test or pushing to finish a feature before deadline, this mode is the difference.

The History tab shows a 14-session bar chart with clickable detail panels — active time, efficiency, focus score, peak streak, flow time, break counts, commits made during the session, and language breakdown.

The Journal is lightweight on purpose. Just a mood, a one-liner, optional blockers. The weekly view is perfect for async standups and self-reflection.

GitHub Issue Log connects to your local repo automatically. No setup beyond a GitHub token if you want remote repos. You can create, comment, close, and log issue completions — and they'll show up in your weekly report.

Install It

Search FocusForge in the VS Code Extensions tab, or:

ext install NK2552003.focusforge

Or grab it directly from the VS Code Marketplace →

The Soundtrack to Your Flow State

Here's a feature I didn't plan but ended up loving more than almost anything else in FocusForge.

I was three hours into a debugging session once, headphones in, streaming musicforprogramming.net in a separate tab. The kind of slow, atmospheric, textural music specifically curated for deep coding work — no lyrics, no sudden drops, just long drifting soundscapes that keep your brain in a calm, engaged state.

And then my tab crashed. Lost the music. Lost the flow. Closed my laptop out of frustration.

That's when I discovered isdampe's music-for-programming — a Node.js CLI that streams musicforprogramming.net (and toggleable rain from rainymood.com) directly into your terminal. Beautiful little tool. But it still meant context-switching out of my editor.

So I brought it inside.

FocusForge's Ambient Audio panel streams directly from musicforprogramming.net — 70+ episodes of handpicked coding soundscapes, from drone textures to modular synthesis to field recordings — all playable right from your VS Code sidebar. No browser tab. No Spotify. No notifications from a separate app.

You can:

Browse and play any episode from the musicforprogramming.net catalogue
Toggle rain overlay on/off (yes, rain + ambient music is genuinely incredible for focus)
Set volume independently
Auto-start audio when a session begins
Audio pauses automatically when you go idle — resumes when you're back

The pausing-on-idle part is what makes it feel intentional. The music isn't just background noise — it's tied to your actual work state. When you're in flow, it plays. When you drift away, it quietly stops. When you return, it picks back up. It mirrors your focus in a way that nothing else does.

Huge credit to isdampe for the original music-for-programming repo that inspired this, and to the team at musicforprogramming.net for building one of the most genuinely useful resources for developers that almost nobody talks about.

I've seen a lot of "I built a thing" posts where the tool is clearly built for a portfolio and never used by anyone including the author. That's not this.

I use FocusForge starting today as i published it now. I think it will change on how I think about my sessions. The journal alone has saved me in standup conversations more times than I can count.

If you're a student grinding through projects, a developer freelancing without a time-tracking system, or just someone who wants to know where their coding hours actually go — this was built for you.

Go forge something.

Built with TypeScript, VS Code Extension API, and a lot of late-night sessions that FocusForge dutifully tracked.

The WAB VS Code extension is now live on the Marketplace — and on Open VSX for Cursor/VSCodium users

Tue, 05 May 2026 20:47:07 +0000

We just shipped something I've wanted for a while.

The WAB VS Code extension is now live on the Marketplace — and on Open VSX for Cursor/VSCodium users.

The problem it solves:

Every developer building AI agents today writes the same boilerplate: custom DOM selectors, hardcoded endpoints, one-off browser automation scripts that break the moment a site changes its UI.

WAB standardizes this. Instead of scraping, sites declare what agents are allowed to DO via window.AICommands. The agent discovers capabilities, executes within boundaries, and the whole thing is cryptographically signed with Ed25519 + DNSSEC.

The VS Code extension makes this feel native:

→ Right-click any

The framing that keeps resonating:
robots.txt told crawlers what NOT to index.
WAB tells AI agents what they CAN execute.

Open source. MIT.

↓ Install in one command:
code --install-extension webagentbridge.wab

Or search "WAB" in the VS Code Extensions panel.

github.com/abokenan444/web-agent-bridge

AIAgents #VSCode #OpenSource #MCP #WebAgents #DeveloperTools

How I Built and Published a VS Code Extension to the Marketplace

Sat, 02 May 2026 21:36:11 +0000

Introduction

I recently built Q Log Session Viewer — a VS Code extension that reads Amazon Q chat history and debug logs from your local machine and displays them in a browsable, filterable UI right inside VS Code. In this post I'll walk through every step: scaffolding the project, writing the extension code, packaging it, and publishing it to the VS Code Marketplace.

By the end you'll have a clear mental model of how VS Code extensions work and a repeatable process for publishing your own.

What We're Building

The extension adds an Activity Bar icon (sidebar panel) and a full editor panel that reads:

~/.aws/amazonq/history/chat-history-*.json — Amazon Q chat history
%APPDATA%\Code\logs\...\Amazon Q Logs.log — VS Code extension host logs

It parses those files and renders sessions as cards, with drill-down into individual log entries.

Sessions overview — chat history and log sessions shown as cards

Entry detail view — filter by category, search, and inspect full JSON

Prerequisites

Before starting, install:

Node.js 18+
VS Code
The Yeoman scaffolder and VS Code extension generator (optional but helpful):

npm install -g yo generator-code

Step 1 — Scaffold the Project

Run the Yeoman generator and answer the prompts:

yo code

Choose:

New Extension (TypeScript)
Name: q-log-session-viewer
Identifier: q-log-session-viewer
Description: View and analyze local Q-related debug logs and chat history from VS Code
Initialize git: Yes
Bundle with webpack/esbuild: esbuild (faster builds)

Tip: If you prefer to skip Yeoman, just create the folder structure manually. The generator only saves a few minutes.

The generated structure looks like this:

q-log-session-viewer/
├── src/
│   └── extension.ts        ← entry point
├── resources/              ← icons, screenshots
├── .vscodeignore
├── esbuild.js
├── package.json
└── tsconfig.json

Step 2 — Configure `package.json`

package.json is the heart of a VS Code extension. It declares commands, views, menus, and metadata that VS Code reads at install time.

Here is the full package.json for this extension:

{
  "name": "q-log-session-viewer",
  "displayName": "Q Log Session Viewer (Unofficial)",
  "description": "View and analyze local Q-related debug logs and chat history from VS Code",
  "version": "0.1.1",
  "publisher": "SiddheshPrabhugaonkar",
  "author": {
    "name": "Siddhesh Prabhugankar",
    "url": "https://github.com/siddheshp"
  },
  "license": "MIT",
  "icon": "resources/icon.png",
  "galleryBanner": { "color": "#232F3E", "theme": "dark" },
  "engines": { "vscode": "^1.85.0" },
  "categories": ["Debuggers", "Other"],
  "keywords": ["logs", "debug", "chat", "viewer", "analysis"],
  "activationEvents": [],
  "main": "./out/extension.js",
  "contributes": {
    "commands": [
      {
        "command": "amazonq-logviewer.open",
        "title": "Q Log Session Viewer: Open",
        "icon": {
          "light": "resources/icon-sidebar-light.svg",
          "dark": "resources/icon-sidebar-dark.svg"
        }
      },
      {
        "command": "amazonq-logviewer.refresh",
        "title": "Q Log Session Viewer: Refresh",
        "icon": "$(refresh)"
      }
    ],
    "viewsContainers": {
      "activitybar": [
        {
          "id": "amazonq-logviewer",
          "title": "Q Logs",
          "icon": "resources/icon-sidebar-dark.svg"
        }
      ]
    },
    "views": {
      "amazonq-logviewer": [
        {
          "type": "webview",
          "id": "amazonq-logviewer.viewer",
          "name": "Log Viewer"
        }
      ]
    },
    "menus": {
      "editor/title": [
        { "command": "amazonq-logviewer.open", "group": "navigation" }
      ]
    }
  },
  "scripts": {
    "vscode:prepublish": "npm run compile",
    "compile": "node esbuild.js",
    "watch": "node esbuild.js --watch",
    "package": "vsce package"
  },
  "devDependencies": {
    "@types/node": "^20.11.0",
    "@types/vscode": "^1.85.0",
    "@vscode/vsce": "^3.9.1",
    "esbuild": "^0.20.0",
    "sharp": "^0.34.5",
    "typescript": "^5.3.0"
  }
}

Key things to understand:

Field	Purpose
`publisher`	Must match your Marketplace publisher ID exactly
`engines.vscode`	Minimum VS Code version required
`activationEvents: []`	With modern VS Code, contributed commands/views can activate the extension when used
`contributes.viewsContainers`	Registers the Activity Bar icon
`contributes.views`	Registers the webview panel inside the sidebar
`vscode:prepublish`	Script that runs before `vsce package`

Step 3 — Set Up esbuild

Instead of the default tsc compiler, this extension uses esbuild for fast bundling. Create esbuild.js:

const esbuild = require('esbuild');

const watch = process.argv.includes('--watch');

const buildOptions = {
  entryPoints: ['src/extension.ts'],
  bundle: true,
  outfile: 'out/extension.js',
  external: ['vscode'],          // vscode is provided by the host, never bundle it
  format: 'cjs',
  platform: 'node',
  target: 'node18',
  sourcemap: true,
  minify: !watch,
};

if (watch) {
  esbuild.context(buildOptions).then(ctx => {
    ctx.watch();
    console.log('Watching for changes...');
  });
} else {
  esbuild.build(buildOptions).then(() => console.log('Build complete'));
}

Important: Always add vscode to external. It is injected by VS Code at runtime and must never be bundled.

Step 4 — Write the Extension Entry Point

src/extension.ts is the file VS Code calls when the extension activates. It registers commands and the sidebar webview provider:

import * as vscode from 'vscode';
import { LogViewerPanel, LogViewerSidebarProvider } from './logViewerPanel';

export function activate(context: vscode.ExtensionContext) {
  // Register the sidebar webview (Activity Bar panel)
  const sidebarProvider = new LogViewerSidebarProvider(context.extensionUri);
  context.subscriptions.push(
    vscode.window.registerWebviewViewProvider('amazonq-logviewer.viewer', sidebarProvider)
  );

  // Command: open full editor panel
  context.subscriptions.push(
    vscode.commands.registerCommand('amazonq-logviewer.open', () => {
      LogViewerPanel.createOrShow(context.extensionUri);
    })
  );

  // Command: refresh data
  context.subscriptions.push(
    vscode.commands.registerCommand('amazonq-logviewer.refresh', () => {
      LogViewerPanel.currentPanel?.refresh();
      sidebarProvider.refresh();
    })
  );
}

export function deactivate() {}

Two patterns to note:

Push to context.subscriptions — VS Code automatically disposes these when the extension deactivates, preventing memory leaks.
deactivate() — called when VS Code shuts down or the extension is disabled. Leave it empty if you have nothing to clean up.

Step 5 — Read Local Log Files (`logProvider.ts`)

This class handles all filesystem access. It resolves the correct log paths per OS:

import * as fs from 'fs';
import * as path from 'path';
import * as os from 'os';

export class LogProvider {
  private logBase: string;
  private historyDir: string;

  constructor() {
    const home = os.homedir();
    const platform = os.platform();

    if (platform === 'win32') {
      const appdata = process.env.APPDATA || path.join(home, 'AppData', 'Roaming');
      this.logBase = path.join(appdata, 'Code', 'logs');
    } else if (platform === 'darwin') {
      this.logBase = path.join(home, 'Library', 'Application Support', 'Code', 'logs');
    } else {
      this.logBase = path.join(home, '.config', 'Code', 'logs');
    }

    this.historyDir = path.join(home, '.aws', 'amazonq', 'history');
  }

  // ... getSessionLogs() and getChatHistoryFiles() methods
}

Log paths by OS:

OS	Extension Logs	Chat History
Windows	`%APPDATA%\Code\logs\...\Amazon Q Logs.log`	`~\.aws\amazonq\history\`
macOS	`~/Library/Application Support/Code/logs/...`	`~/.aws/amazonq/history/`
Linux	`~/.config/Code/logs/...`	`~/.aws/amazonq/history/`

Step 6 — Build the Webview Panel (`logViewerPanel.ts`)

VS Code extensions can render arbitrary HTML inside WebviewPanel (full editor tab) or WebviewView (sidebar). Both are used here.

Security: Content Security Policy + Nonce

Every webview must set a strict CSP. A nonce (random string per render) is used to allow only your inline scripts:

function getNonce(): string {
  let text = '';
  const possible = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
  for (let i = 0; i < 32; i++) {
    text += possible.charAt(Math.floor(Math.random() * possible.length));
  }
  return text;
}

The CSP meta tag in the HTML:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';
           style-src 'nonce-${nonce}';
           script-src 'nonce-${nonce}';">

Two-Way Messaging

The webview and extension communicate via postMessage:

// Extension → Webview: send data
panel.webview.postMessage({ command: 'dataLoaded', historyFiles, logSessions });

// Webview → Extension: request data
panel.webview.onDidReceiveMessage(message => {
  if (message.command === 'loadData') {
    const data = logProvider.loadAllData();
    panel.webview.postMessage({ command: 'dataLoaded', ...data });
  }
});

Inside the webview HTML:

const vscode = acquireVsCodeApi();

// Send message to extension
vscode.postMessage({ command: 'loadData' });

// Receive message from extension
window.addEventListener('message', event => {
  if (event.data.command === 'dataLoaded') {
    renderSessions(event.data.historyFiles, event.data.logSessions);
  }
});

export class LogViewerSidebarProvider implements vscode.WebviewViewProvider {
  resolveWebviewView(webviewView: vscode.WebviewView, ...) {
    webviewView.webview.options = {
      enableScripts: true,
      localResourceRoots: [vscode.Uri.joinPath(this._extensionUri, 'resources')]
    };
    webviewView.webview.html = getViewerHtml(getNonce());
    // ... message handler
  }
}

Step 7 — Add Icons

VS Code requires icons in specific formats:

Marketplace icon: resources/icon.png — 128×128 PNG, referenced in package.json as "icon"
Activity Bar icon: SVG file — VS Code tints it automatically to match the theme; keep it a simple monochrome shape

"viewsContainers": {
  "activitybar": [
    {
      "id": "amazonq-logviewer",
      "title": "Q Logs",
      "icon": "resources/icon-sidebar-dark.svg"
    }
  ]
}

Gotcha: Activity Bar icons are always rendered as monochrome by VS Code regardless of the SVG colors. Design them as single-color silhouettes.

Step 8 — Configure `.vscodeignore`

.vscodeignore works like .gitignore but for the packaged .vsix file. Exclude everything that isn't needed at runtime:

.vscode/**
node_modules/**
src/**
esbuild.js
tsconfig.json
**/*.map
**/*-b64.txt
resources/screenshots/*.png

Keep in the package:

out/extension.js (compiled bundle)
resources/ (icons used by the extension)
package.json
README.md
LICENSE

Step 9 — Test Locally

Press F5 in VS Code to launch the Extension Development Host — a second VS Code window with your extension loaded.

You'll see the Q Logs icon appear in the Activity Bar:

Iterate quickly with:

npm run watch

esbuild rebuilds in milliseconds on every save. Reload the Extension Development Host with Ctrl+R (or Cmd+R on Mac) to pick up changes.

Step 10 — Package the Extension

Install vsce (the VS Code Extension CLI) if you haven't already:

npm install -g @vscode/vsce

Then package:

vsce package

This produces a .vsix file (e.g. q-log-session-viewer-0.1.1.vsix). You can install it locally to test the final artifact:

code --install-extension q-log-session-viewer-0.1.1.vsix

Step 11 — Create a Publisher Account

Go to https://marketplace.visualstudio.com/manage
Sign in with a Microsoft account
Click Create publisher
Choose a publisher ID (e.g. SiddheshPrabhugaonkar) — this must match the "publisher" field in package.json exactly

You also need a Personal Access Token (PAT):

Go to https://dev.azure.com → your organization → User Settings → Personal Access Tokens
Click New Token
Set scope to Marketplace → Manage
Copy the token — you won't see it again

Authenticate vsce with your token:

vsce login SiddheshPrabhugaonkar
# Paste your PAT when prompted

Step 12 — Write a Good README

The README.md in your extension folder becomes the Marketplace listing page. Make it count:

Lead with what the extension does and who it's for
Include screenshots (host them on GitHub or a CDN — relative paths don't work on the Marketplace)
List features, commands, and requirements
Add a disclaimer if your extension reads data from another product

Screenshot URLs must be absolute:

![Sessions View](https://raw.githubusercontent.com/youruser/your-assets-repo/main/screenshots/sessions-view.png)

Tip: Create a separate public GitHub repo just for assets (screenshots, GIFs). This keeps your extension repo clean and the URLs stable.

Step 13 — Publish to the Marketplace

vsce publish

That's it. vsce will:

Run npm run vscode:prepublish (which runs npm run compile)
Package the .vsix
Upload it to the Marketplace

To publish a specific version bump:

vsce publish patch   # 0.1.0 → 0.1.1
vsce publish minor   # 0.1.0 → 0.2.0
vsce publish major   # 0.1.0 → 1.0.0

After a few minutes your extension appears at: https://marketplace.visualstudio.com/items?itemName=SiddheshPrabhugaonkar.q-log-session-viewer

Step 14 — Update the Extension

For subsequent releases:

Make your code changes
Update CHANGELOG / release notes in README.md
Run vsce publish patch (or minor/major)

The Marketplace auto-notifies users who have the extension installed.

Project File Structure (Final)

VSCodeExtention/
├── resources/
│   ├── icon.png                  ← Marketplace icon (128×128 PNG)
│   ├── icon-sidebar-dark.svg     ← Activity Bar icon
│   └── icon-sidebar-light.svg
├── src/
│   ├── extension.ts              ← activate() / deactivate()
│   ├── logProvider.ts            ← filesystem reads
│   └── logViewerPanel.ts         ← WebviewPanel + WebviewView + HTML
├── .vscodeignore
├── esbuild.js
├── package.json
├── tsconfig.json
└── README.md

Key Concepts Recap

Concept	What it does
`contributes.viewsContainers`	Adds an icon to the Activity Bar
`contributes.views`	Registers a panel inside that container
`WebviewPanel`	Full editor tab with custom HTML
`WebviewViewProvider`	Sidebar panel with custom HTML
`postMessage` / `onDidReceiveMessage`	Two-way communication between extension and webview
Nonce + CSP	Security: prevents XSS in webviews
`context.subscriptions`	Automatic cleanup on deactivation
`vsce package`	Creates the installable `.vsix`
`vsce publish`	Uploads to the VS Code Marketplace

Common Gotchas

vscode must be in external in your bundler config — never bundle it
Marketplace icon must be PNG, not SVG
Screenshot URLs in README must be absolute — relative paths break on the Marketplace page
Publisher ID in package.json must exactly match your Marketplace publisher account
Activity Bar SVG icons are always monochrome — VS Code tints them; don't rely on color
CSP default-src 'none' — be explicit about what your webview is allowed to load; no external CDNs unless you add them to the CSP

Resources

Built by Siddhesh Prabhugankar — Microsoft Certified Trainer & AI Consultant
GitHub: github.com/siddheshp · LinkedIn: linkedin.com/in/siddheshprabhugaonkar

I Paid for VS Code, Cursor, and Windsurf Simultaneously for 6 Months. Here's What I Actually Learned

Tue, 28 Apr 2026 09:44:49 +0000

The Setup

So I did something maybe a bit crazy—I've been paying for all three AI code editors (VS Code + Copilot, Cursor, and Windsurf) at the same time for the last 6 months. Not for content, not for a review—I genuinely needed to figure out which one works best for different scenarios.

My day job is Power Platform development (PCF controls, Dataverse schemas, Copilot Studio), so I've been using these in actual production codebases. Not toy examples. Not "hello world" demos. Real debugging sessions at 2 AM, real refactoring nightmares, real enterprise constraints.

Here's what I learned that nobody's talking about.

Full comparison with all the details: https://aidevme.com/vs-code-vs-windsurf-vs-cursor-my-honest-take-after-6-months-using-all-three/

Architecture Matters More Than Features

Everyone focuses on feature lists, but the architecture is what actually determines how you'll use the tool daily.

VS Code + Copilot: Extension API Model

┌─────────────────────────────────────────┐
│         VS Code + Copilot               │
│  ┌────────────────────────────────┐     │
│  │    Copilot Extension           │     │
│  │    (Separate Process)          │     │
│  │    Limited Editor Visibility   │     │
│  └────────────────────────────────┘     │
│         VS Code Core                    │
└─────────────────────────────────────────┘

What this means in practice:

Copilot can't see:

Your terminal output stream
Your file navigation patterns
Linter errors in real-time
Debug session state

You have to explicitly copy/paste context into chat. Every. Single. Time.

Real debugging session example:

1. Build fails
2. Copy terminal error to Copilot chat
3. Copilot: "What files are relevant?"
4. You: List files
5. Copilot: Suggests fix
6. You: Apply changes manually
7. Build fails differently
8. Repeat from step 2

It works, but you're the context manager. Copilot is a brilliant consultant who needs constant status updates.

Cursor: Optimized Fork Model

┌─────────────────────────────────────────┐
│              Cursor                     │
│  ┌────────────────────────────────┐     │
│  │    Cursor AI (Built-in)        │     │
│  │    Enhanced Editor Hooks       │     │
│  │    Deeper Context Access       │     │
│  └────────────────────────────────┘     │
│    Modified VS Code Fork                │
└─────────────────────────────────────────┘

Cursor can modify VS Code internals, so the AI has deeper hooks into editor state. This enables their Tab feature (multi-line prediction) and better context assembly.

Trade-off: You're locked to Cursor. Can't swap out the AI layer or use it in JetBrains.

Windsurf: Integrated Agent Model

┌─────────────────────────────────────────┐
│             Windsurf                    │
│  ┌────────────────────────────────┐     │
│  │    Cascade (Integrated)        │     │
│  │    First-Class Editor Access   │     │
│  │    Continuous Observation      │     │
│  │  + Devin Cloud Agent           │     │
│  └────────────────────────────────┘     │
│    AI-Native Fork                       │
└─────────────────────────────────────────┘

Cascade has privileged access to the rendering pipeline. It sees everything automatically:

Terminal output (real-time)
Linter errors (auto-fixes without asking)
File navigation (infers intent)
Test results

Same debugging session with Windsurf:

1. Build fails
2. Cascade: "I see the test failed. Here's what's wrong. Want me to fix it?"
3. You: "Yes"
4. Done

Trade-off: Higher resource consumption (always watching = always consuming RAM). My ThinkPad struggles. My MacBook is fine.

The Tab Completion Battle

Let me be blunt: Cursor's Tab feature is the best multi-line autocomplete in the industry.

I'm not exaggerating. It predicts my next 5-10 lines with unsettling accuracy. Here's an example from actual React work:

I type:

const handleSubmit = async (e: FormEvent) => {

Cursor Tab suggests (correctly):

const handleSubmit = async (e: FormEvent) => {
  e.preventDefault();
  setLoading(true);
  
  try {
    const response = await api.submitForm(formData);
    if (response.ok) {
      navigate('/success');
    }
  } catch (error) {
    setError(error.message);
  } finally {
    setLoading(false);
  }
};

How did it know:

I use api.submitForm? (from other files)
I have a formData state? (from context)
I navigate on success? (from routing patterns)
I use try/catch/finally? (coding style)

Windsurf's Supercomplete is also excellent. VS Code Copilot's inline suggestions are good but not this predictive.

For flow state coding, Cursor wins. No contest.

The Context Awareness Spectrum

Here's where these tools sit on the "how much does the AI know about what I'm doing" spectrum:

Low Context (VS Code + Copilot):

Only knows what you explicitly tell it
Session-only memory
Must rebuild context each conversation
Pros: Predictable, controlled
Cons: High prompt overhead

Medium Context (Cursor):

Excellent codebase indexing
Understands repo structure automatically
Limited persistent memory
Pros: Fast, accurate within known scope
Cons: Still needs explicit prompting for complex tasks

High Context (Windsurf):

Continuous observation
Persistent memory across sessions
Infers intent from behavior
Pros: Autonomous, proactive
Cons: Resource-heavy, can be unpredictable

Real example - Dataverse schema work:

With VS Code: "I'm working on a Contacts table. I need to add three lookup columns to Account. Here's my publisher prefix. Here's the naming convention I use."

With Cursor: "Add three lookup columns to Contacts for Account" (it knows the rest from codebase)

With Windsurf: Opens schema file, starts adding columns → Cascade: "I see you're adding Account lookups to Contacts. Want me to generate the TypeScript interfaces too?"

Performance Numbers (Real Hardware)

Tested on M2 MacBook Pro (16GB) and ThinkPad T490 (8GB):

Cold Start Times:

VS Code: 1-2 sec
Cursor: 2-3 sec
Windsurf: 3-5 sec

RAM Usage (Baseline):

VS Code: 300-450 MB
Cursor: 400-600 MB
Windsurf: 500-900 MB

RAM Usage (Heavy AI Work):

VS Code: 600-800 MB
Cursor: 800 MB - 1.2 GB
Windsurf: 1.2-1.8 GB

My ThinkPad (8GB RAM):

VS Code: Good
Cursor: Usable but occasionally slow
Windsurf: Struggles (frequent swapping)

Recommendation:

8GB or less → VS Code
16GB → Any of the three
32GB+ → Windsurf or Cursor (maximize AI capabilities)

The Dev Container Problem

This is huge for anyone doing PCF development or working with containerized environments:

VS Code: Dev Containers are gold standard. Mature, reliable, well-documented.

Cursor: Dev Containers work well. Occasional quirks but generally solid.

Windsurf: NO DEV CONTAINER SUPPORT.

This is a deal-breaker for PCF work where you need Node.js version isolation. I keep hoping they'll add this, but as of April 2026, still nothing.

If your workflow requires Dev Containers: VS Code or Cursor only.

Real Workflow Scenarios

Scenario: Large TypeScript Refactoring

Needed to rename an interface used across 40 files.

Cursor Composer:

Me: "Rename ContactData to ContactEntity everywhere and update all imports"
Cursor: [Shows preview of all 40 files]
Me: "Apply"
Cursor: [Executes cleanly]
Time: ~30 seconds

Windsurf Cascade:

Me: "Rename ContactData to ContactEntity everywhere"
Cascade: [Analyzes repo, shows preview]
Me: "Apply"
Cascade: [Executes cleanly]
Time: ~30 seconds

VS Code Copilot Agent Mode:

Me: "Rename ContactData to ContactEntity everywhere"
Copilot: "Which files should I check?"
Me: "All TypeScript files"
Copilot: [Searches, proposes changes]
Me: "Apply"
Copilot: [Executes]
Time: ~2 minutes (more back-and-forth)

Winner for refactoring: Cursor (slightly faster, cleaner preview)

Scenario: Building Feature from Figma Mockup

Windsurf:

Drop screenshot into Cascade
Describe feature
Cascade generates components + styles
Live preview shows result
Click element, describe changes
Cascade auto-fixes linter errors
Time: ~15 minutes (1 prompt beyond initial)

Cursor:

Describe feature with reference to mockup
Tab through implementation
Use Composer for multi-file coordination
Alt-tab to browser repeatedly for preview
Time: ~30 minutes

VS Code:

Describe feature
Copilot generates initial code
Manual copy/paste and refinement
Alt-tab to browser for preview
Multiple prompt rounds for iterations
Time: ~45 minutes

Winner for greenfield features: Windsurf (continuous context + live preview is unbeatable)

Scenario: Debugging Production Bug at 3 AM

VS Code:

Dev Container reproduces exact prod environment
Mature debugger with breakpoints
Copilot helps reason about stack traces
Systematic step-through debugging
Result: Fixed reliably

Cursor:

Dev Container works
Good debugging support
AI helps with reasoning
Result: Fixed reliably

Windsurf:

No Dev Container (had to debug differently)
Cascade saw errors automatically
Suggested fixes quickly
Result: Fixed but with more uncertainty about prod parity

Winner for production debugging: VS Code (battle-tested tooling matters at 3 AM)

Pricing Reality

All three are around $20/month for the core paid tier:

VS Code + Copilot:

Free tier: 2K completions/mo
Individual: $10/mo
Business: $19/user/mo
Enterprise: $39/user/mo

Cursor:

Free trial: 2 weeks
Pro: $20/mo (but 500 "fast premium" request limit)
Business: $40/user/mo

Windsurf:

Free: 25 credits/mo
Pro: $20/mo
Max: $200/mo (for heavy usage)
Teams: $40/user/mo

Best value for solo dev: Cursor at $20/mo (excellent tab + composer)

Best value for heavy AI usage: Windsurf Pro at $20/mo (includes Devin cloud agent)

Best enterprise value: VS Code Copilot Enterprise (proven compliance, mature tooling)

The Features Nobody Talks About

Windsurf's Turbo Mode

You can literally tell Cascade "Execute this 12-step workflow" and it will autonomously:

Read files
Identify changes
Make edits
Run tests
Fix failing tests
Commit changes
All without asking for confirmation

It's powerful. It's also occasionally terrifying. Once deleted a test file I needed. Had to restore from git.

Use with caution.

Cursor's Privacy Mode

Cursor can run models fully locally. For clients with strict data residency requirements, this is huge.

Neither VS Code Copilot nor Windsurf offer full local execution.

VS Code's Multi-IDE Coverage

Copilot works in:

VS Code
JetBrains IDEs
Visual Studio
Neovim
Xcode (limited)

If you're polyglot across IDEs, only VS Code Copilot follows you everywhere.

MCP Support (Model Context Protocol)

All three support MCP, but with wildly different UX:

VS Code:
Manual JSON config in .vscode/mcp.json:

{
  "servers": {
    "dataverse-skills": {
      "command": "npx",
      "args": ["-y", "@microsoft/dataverse-skills"]
    }
  }
}

Cursor:
Same manual JSON approach. No plugin store.

Windsurf:
Plugin Store with one-click installs for curated servers (Figma, Slack, GitHub, PostgreSQL, etc.)

For custom MCP servers (like Dataverse Skills), all three require manual JSON config.

Power Platform Developers: Here's What Matters

PCF Controls

Use: VS Code or Cursor (both support Dev Containers)

You need:

Dev Container for Node version isolation
Power Platform Tools extension
Jest + React DevTools
PAC CLI integration

Windsurf's lack of Dev Containers is a non-starter here.

Dataverse Schema Design

Use: Windsurf or Cursor

With Dataverse Skills MCP server configured:

Windsurf + Cascade applies conventions automatically if you have .windsurfrules:

Publisher prefix: aidevme_
Naming convention: PascalCase for logical names
Relationship naming: Related{EntityName}

Cascade remembers this across sessions.

PAC CLI Workflows

Use: VS Code

Mature terminal integration, Dev Containers for environment consistency, better for scripted workflows.

What I Actually Use

I don't pick just one. Multi-editor strategy:

VS Code: PCF dev, PAC CLI, enterprise work, anything requiring Dev Containers
Cursor: Daily TypeScript/React feature work, refactoring, learning new codebases
Windsurf: Dataverse schema design, rapid prototyping, multi-file scaffolding

All three can be open simultaneously. Most extensions and settings transfer seamlessly.

The Honest Trade-offs

VS Code + Copilot

Choose if:

You need Dev Containers
You work across multiple IDEs
You want maximum stability
You need enterprise compliance
You're on 8GB RAM or less

Skip if:

You're frustrated by prompt overhead
You want proactive AI behavior
You need continuous context awareness

Cursor

Choose if:

You prioritize flow state and tab completion
You do heavy refactoring work
You want fast, predictable AI
You need privacy mode (local execution)

Skip if:

You need multi-IDE support
You hit the 500 request/month limit
You want autonomous agent capabilities

Windsurf

Choose if:

You want cutting-edge AI capabilities
You need cloud agent delegation (Devin)
You have 16GB+ RAM
You want continuous context awareness

Skip if:

You need Dev Containers
You're on 8GB RAM or less
You want battle-tested tooling
You prefer explicit control over autonomy

My Recommendation

If you're starting today:

Start with VS Code + Copilot Individual ($10/mo)
Master the fundamentals
Once comfortable, try Cursor's free trial (2 weeks)
If you love Tab completion → stay with Cursor
If you want more autonomy → try Windsurf's free tier (25 credits)

If you're experienced:

Cursor Pro ($20/mo) for solo dev work
Windsurf Pro ($20/mo) if you have good hardware and want bleeding-edge
VS Code Copilot if you need enterprise features or multi-IDE

Discussion Questions for the Community

Are you using Cursor or Windsurf? What made you switch from VS Code?
Has anyone successfully used Windsurf without Dev Containers? How do you handle environment consistency?
Cursor's 500 request limit - have you hit it? How did you work around it?
Autonomous AI concerns - how much autonomy are you comfortable with? Have you had Windsurf's Turbo Mode do something unexpected?
Multi-editor workflows - is anyone else using multiple editors for different tasks? What's your strategy?
MCP adoption - are you using MCP servers? Which ones? What's your experience?

Drop your experiences in the comments. I'm genuinely curious what the community is finding.

Full deep-dive article: https://aidevme.com/vs-code-vs-windsurf-vs-cursor-my-honest-take-after-6-months-using-all-three/

PasteShield - an Extension that can save you from deploying the secrets

Sat, 25 Apr 2026 06:11:31 +0000

You've done this. Don't lie.

# "just for testing, I'll remove it later"
const API_KEY = "sk-prod-abc123supersecretdonotcommit"

git add .
git commit -m "fix stuff"
git push

3 minutes later:

GitHub Secret Scanning Alert: We found a secret in your repo...

Yeah. We've all been there.

Meet PasteShield

PasteShield is a VS Code extension that watches your clipboard like a hawk. Every time you hit Ctrl+V, it scans the content before it lands in your file.

Think of it as a bouncer at the door of your codebase.

No cloud. No subscription. No telemetry. 100% offline. Free forever.

See it in action

You paste an API key → PasteShield goes "hold on bestie" →

Three choices. Zero drama:

Cancel — yeah don't do that
Show Details — tell me more
Paste Anyway — I know what I'm doing (do you though)

Also catches stuff already in your file

It doesn't just guard the door — it also checks if anything sketchy already got in, via CodeLens annotations right above the suspicious line:

No hunting through files. The warning is right there, above the guilty line.

What does it catch? Everything, basicall

~200 patterns. 25+ categories. Scanned in under 50ms.

Vibe	Examples caught
AI keys	OpenAI, Anthropic, Gemini, Groq, DeepSeek, xAI...
Cloud creds	AWS, GCP, Azure — all the big ones
Payment secrets	Stripe, Razorpay, PayPal, Square
DB connections	MongoDB, Postgres, Supabase, Redis
Auth tokens	GitHub PAT, JWT, Slack, Discord
PII	SSNs, credit cards, Aadhaar, PAN, IBAN
Unsafe code	`eval()`, `innerHTML`, SQL injection patterns
...and 18 more	Mobile/IoT, Maps, CDN, Crypto, Web3

Too loud? Tune the noise level:

"pasteShield.minimumSeverity": "high"
// critical | high | medium (default) | low

Not ready to be blocked? Try silent mode

New in v1.7 — silent mode logs everything to the sidebar without interrupting your paste.

Perfect if you're the type who wants data before commitment (reasonable, honestly).

"pasteShield.silentMode": true

See the full history in the sidebar, export it as JSON, sleep better at night.

For teams

Drop a .pasteshield-policy.json in your repo (or host it at a URL) and your whole team gets the same rules automatically.

{
  "template": "strict",
  "rules": [
    { "type": "block_pattern", "pattern": "openai-api-key" },
    { "type": "audit_logging", "enabled": true }
  ]
}

One update → everyone's protected. No Slack message needed.

Where it stores your secrets

v1.7 upgraded this significantly. Credentials go into your OS keychain — Windows Credential Manager, macOS Keychain, Linux libsecret — via VS Code's native SecretStorage API.

Nothing in settings.json. Nothing in plaintext. Nothing in the cloud.

And if you actually want to store detected secrets properly, it integrates with:

HashiCorp Vault · AWS Secrets Manager · Azure Key Vault · Google Secret Manager

All from inside VS Code. No tab switching.

vs Gitleaks / git-secrets

Not a competition — they're complementary:

You type/paste  →  [PasteShield catches it here] ← THIS
      ↓
You commit      →  [Gitleaks / git-secrets catch it here]
      ↓
You push        →  [GitHub Secret Scanning catches it here]
      ↓
Production      →  [Too late]

PasteShield is your first line of defense. Use all of them.

Install in 10 seconds

Option 1: VS Code Marketplace → search PasteShield → Install

Option 2: Quick Open (Ctrl+P) and paste:

ext install NK2552003.pasteshield

That's it. It starts working immediately. No config needed.

What's coming

The roadmap is genuinely exciting:

ML-based false-positive reduction — smarter, fewer annoying alerts
CLI version — run it in CI/CD pipelines
SARIF output — plug into GitHub Advanced Security
Auto secret rotation via provider APIs
Community pattern marketplace — share and import rulesets

TL;DR

You paste something sketchy → PasteShield yells at you → you don't get fired →

Free. Offline. 200+ patterns. Works in under 50ms.

Built by Sid Kr. (NK2552003). MIT licensed. No VC funding, no upsell, no BS.

GITHUB
MARKETPLACE VSCODE

Drop a ⭐ on GitHub if this saved your job once. Or twice.

Architecture Breaks Silently. Now There's a Tool That Investigates.

Mon, 20 Apr 2026 09:05:04 +0000

There's a class of bugs that no single-file view will ever reveal.

Working in IoT, I've seen failures surface in one place while the real cause lived somewhere completely different. A device message handler would fail under load -- but the handler code looked correct. The root cause was spread across multiple files: a config value that disabled a cache, three async paths racing against the same shared resource, and a state recomputation that should never have been happening on every request. Each file was fine in isolation. The bug only existed in how they interacted at runtime.

This pattern keeps showing up in every complex system I've worked on. The hardest bugs aren't syntax errors. They're architectural -- config that silently changes downstream behavior, interface contracts that drift, concurrent paths that only break under real load.

Fixing them requires investigation: trace the failure, read the caller chain, inspect config, connect behavior across modules. That's exactly the workflow I wanted to automate.

So I built Archexa

What it does

Archexa is a VS Code extension powered by the Archexa CLI -- a self-contained binary that scans your project with tree-sitter, then uses an LLM agent to investigate across files.

Six commands, all from right-click or keyboard shortcuts:

Review (Cmd+Shift+R) -- Architecture-aware code review. Findings appear as inline squiggles, just like ESLint or TypeScript diagnostics.
Diagnose (Cmd+Shift+D) -- Paste an error or stack trace. It traces the call chain to the root cause across files.
Impact (Cmd+Shift+I) -- "What breaks if I change this?" Traces callers and interface contracts.
Query (Cmd+Alt+Q) -- Ask anything about your codebase. Evidence-backed answers with file references.
Gist -- Quick codebase overview. Great for day-one onboarding.
Analyze -- Full architecture documentation with Mermaid diagrams.

Setup (60 seconds)

# From VS Code Marketplace — search "Archexa" and click Install
# Or from the command line:
code --install-extension EreshGorantla.archexa

The setup wizard downloads the CLI binary automatically (~20 MB). No Python, no pip, no runtime dependencies.

Then: Sidebar > Settings > Connection > set your API key + endpoint.

Works with any OpenAI-compatible provider:

OpenAI (gpt-4o)
OpenRouter (gemini-2.5-flash, claude-sonnet-4-20250514, etc.)
Ollama (llama3.1 -- fully local, zero code leaves your machine)
vLLM, Azure OpenAI, LiteLLM

How it works

Every command follows the same three-phase approach:

1. Scan -- The CLI parses your project with tree-sitter AST parsing. Maps imports, function signatures, call sites, and module boundaries. Runs offline in seconds. Results are cached.

2. Investigate -- The LLM becomes an agent with tools: read_file, grep_pattern, trace_callers, list_directory. It decides what to read and when it has enough evidence. Typical run: 3-6 iterations, 10-20 tool calls, 5-15 files examined.

Here's a real investigation trace:

Step 1: Read error handler -> found verify_token()
Step 2: Search verify_token -> 8 references, 5 files. Read cache module -> no synchronization
Step 3: Trace callers of cache.get_token -> 3 async handlers. Read config -> TTL=0
Step 4: Root cause: race condition. Concurrent handlers, unprotected cache, caching disabled by config.

The agent followed the trail across files, just like an experienced engineer would -- in under a minute.

3. Synthesize -- All evidence assembled into one context-optimized prompt. The LLM generates the final output with file references and severity ratings.

The Archexa CLI

The extension is the UI layer. The real engine is the Archexa CLI -- a standalone binary that handles:

Tree-sitter AST parsing across 13 languages
Agent orchestration with tool-calling loops
Progressive context pruning as evidence grows
Streaming LLM communication via any OpenAI-compatible API

The binary communicates with the extension over stdout (streaming markdown) and stderr (JSON events). One download, chmod +x, works everywhere.

Design principles

Fresh investigation every time. No memory between runs. Every analysis starts from a fresh scan of current code. The answer is always grounded in your codebase as it exists right now, not a cached version from last week. Tree-sitter caching keeps the structural scan fast.

Your data stays yours. Zero telemetry -- not usage stats, not crash reports. The binary talks to exactly one service: the LLM endpoint you configure. API keys are stored in VS Code's encrypted credential store and passed via environment variable. Never written to config files.

No gatekeeping. No accounts, no sign-up, no Archexa API key. Bring your own LLM provider. Open source under Apache 2.0.

Fully local option

brew install ollama
ollama pull llama3.1

# In Archexa settings:
# Endpoint: http://localhost:11434/v1/
# Model: llama3.1

Zero code leaves your machine. AST parsing is offline. LLM runs locally.

Platform support

	Supported
OS	macOS (Apple Silicon + Intel), Linux (x86_64 + ARM), Windows (x64)
Languages	Python, TypeScript, JavaScript, Go, Java, Rust, Ruby, C#, Kotlin, Scala, C++, C, PHP
LLM Providers	Any OpenAI-compatible endpoint

Beta notice

Archexa is currently in beta. The core pipeline is stable, but the CLI binary is not yet code-signed.

macOS users: Gatekeeper may block the binary on first run since it's unsigned. The extension handles quarantine removal automatically in most cases. If you see a "cannot be opened" dialog, a notification with a "Fix Permissions" button will appear. Full troubleshooting steps are in the Usage Guide.

What's next

CI integration (findings as GitHub PR comments)
Custom agent tools (project-specific scripts during deep mode investigation)
Auto-fix after review (investigate a finding, generate the fix, apply with your approval)

Forest Ash Theme: 21 Eye-Friendly VS Code Themes Inspired by Anime & Nature

Mon, 13 Apr 2026 18:11:09 +0000

Hey there, fellow developers!

Ever find yourself squinting at your screen after a long coding marathon? Yeah, me too. That's why I created Forest Ash Theme — a collection of 21 carefully crafted color themes for VS Code that feel like a warm embrace for your eyes.

The Origin Story

Inspired by the soothing textures of forest ash and the moody aesthetic of anime mood boards, these themes aren't just pretty — they're optimized for readability. Think of them as a visual sanctuary during those 8-hour coding sessions.

What's Inside the Box?

You get 21 unique themes split into two beautiful palettes:

Dark Themes (11 total)

The perfect choice for night owls and those who love low-glare environments:

Forest Ash — The classic, timeless original
Yoru Paper — Inspired by Japanese night paper textures
Sumi Moon — Dark ink inspired, lunar vibes
Kitsune Ink — Mystical fox-inspired palette
Shoji Night — Traditional Japanese door aesthetic
Aizome Dusk — Indigo and dusk combinations
Ronin Lantern — Warm, wanderer-like ambiance
Bamboo Midnight — Calm green and midnight tones
Nebula Manga — Cosmic manga vibes
Sakura Charcoal — Cherry blossom & charcoal blend
Kage Washi — Shadow and traditional Japanese paper

Light Themes (10 total)

Perfect for daytime coding and sunlit environments:

All the above themes have beautiful Light variants that maintain the same aesthetic identity while being optimized for brighter environments.

Why You'll Love It

Design Philosophy

Clarity         → Distinct tokens for different syntax elements
Calming Colors   → Desaturated, nature-inspired palettes  
Reduced Fatigue  → Carefully chosen contrast ratios
Consistency      → Each theme has its own unique identity

Features That Matter

Dark AND Light variants — Choose what works for your time of day
Syntax highlighting — Every language pops perfectly
UI elements — Buttons, menus, and panels all themed cohesively
Custom token colors — Comments, variables, functions — all distinct
Terminal colors — Your command line looks good too!

How to Get Started

Step 1: Install from VS Code Marketplace

Open VS Code
Go to Extensions (Cmd+Shift+X on Mac / Ctrl+Shift+X on Windows/Linux)
Search for "Forest Ash Theme"
Click Install

Step 2: Pick Your Vibe

Open Command Palette (Cmd+Shift+P / Ctrl+Shift+P)
Type "Color Theme"
Browse through the 21 options
Press Enter to apply

Step 3: Enjoy!

Sit back and let your eyes thank you.

Perfect For...

Night coders — Developers who work late into the evening
Day workers — Those who need light themes for bright offices
Design-conscious devs — People who care about aesthetics
Anyone with eye sensitivity — Low contrast, high comfort
Anime fans — Who wants their IDE to look cooler? Everyone!

Under the Hood

Built with meticulous attention to:

Color harmony — Every palette follows color theory principles
Contrast ratios — WCAG compliance for accessibility
Token coverage — Support for 50+ languages and frameworks
Custom UI theming — Not just syntax, but your entire VS Code experience

Get Involved

Found a color combination that doesn't quite work for you? Have a theme idea?

GitHub: Forest-Ash-Theme
Issues & Suggestions: We're always improving
Star us: If you love it, show some love on GitHub! ⭐

Final Thoughts

Your code editor is where you spend hours every single day. It deserves to be:

Beautiful
Eye-friendly
Uniquely you

Forest Ash Theme checks all three boxes. Whether you're a seasoned dev or just starting your coding journey, there's a theme calling your name.

Ready to transform your VS Code experience?

Install Forest Ash Theme today and join the community of developers who've already ditched the eye strain. Your future self (especially the one coding at 2 AM) will thank you!

Got a favorite theme? Drop it in the comments — I'd love to hear which one resonates with you!

Quick Links

Happy coding, and may your eyes remain stress-free!

The Real Problem With AI Coding Isn’t Intelligence — It’s Continuity

Tue, 17 Mar 2026 12:53:08 +0000

Most AI coding failures are not caused by weak models.

They happen because the system loses continuity.

A model can generate decent code in one shot. It can explain architecture, suggest refactors, and help debug isolated issues. But once the work becomes long-running — once memory, role separation, evolving context, and multiple sessions enter the picture — many AI setups begin to break down.

The problem is not just model quality.
The problem is that most AI coding systems are still structured like stateless assistants.

Real development work is not stateless.

It has identity, history, unresolved threads, shifting priorities, and accumulated intent. If all of that gets mixed into one growing prompt, the system gradually loses coherence. The model may still sound capable, but the overall system becomes fragile. Context drifts. Memory bloats. Roles blur. Useful insights disappear into noise.

That is why I have been building a persona-aware agent shell on top of GitHub Copilot.

Not to make the AI feel more decorative.
Not to give it a superficial personality layer.
But to give long-running AI work a structure that can preserve continuity.

What Usually Breaks

In practice, AI coding systems often fail in very predictable ways.

First, context keeps accumulating without changing shape. Every session adds more text, more reminders, more patches, more references. Over time, the system becomes heavier but not clearer. Memory turns into a dump.

Second, identity and task state get mixed together. Core behavioral constraints, persistent preferences, recent session details, and the current request all compete in the same space. The model has to infer structure from a pile of text that was never properly separated.

Third, roles become unstable. The same system is expected to be an architect, debugger, planner, note-taker, and companion without any explicit boundary between those functions. It may still produce useful output, but the internal operating pattern becomes inconsistent.

Fourth, continuity is confused with accumulation. Many AI systems treat memory as “store more, keep more, append more.” But keeping everything is not the same as preserving coherence. In fact, over-accumulation often destroys it.

This is why many systems look impressive in short demos and become unreliable in real, ongoing work.

The Shift: From Prompting to Operating

What changed my thinking was realizing that the real challenge was not how to prompt better.

It was how to operate better.

A useful AI system is not just a model plus instructions. It is an environment where intelligence can stay coherent over time.

That means the structure around the model matters as much as the model itself.

In my own work, I’ve been separating interaction into four layers:

Persona Core
The stable identity layer. This is where role, tone, priorities, boundaries, and deep behavioral shape live.

Persistent Context
The compressed continuity layer. Not everything that happened, but the parts that still matter.

Session Context
The active working state for the current thread or task.

Current User Request
The immediate prompt or instruction.

This separation sounds simple, but it changes everything.

Instead of forcing the model to infer which details are permanent, which are temporary, and which are urgent, the system gives those distinctions explicit structure. The result is not just cleaner output. It is more stable long-running behavior.

Why Memory Should Be Recompressed, Not Accumulated

This has become one of the strongest design principles in my system:

Memory should be recompressed, not endlessly accumulated.

If memory is treated as an append-only log, it eventually becomes a burden. The system spends more effort carrying history than using it.

But continuity does not require full preservation of every detail.
It requires preservation of shape.

What matters is not whether the system remembers every message.
What matters is whether it retains the right patterns:

identity

priorities

unresolved tensions

recurring preferences

meaningful changes

active trajectories

That is a very different problem from raw storage.

Recompression means periodically turning lived interaction into a smaller, more structured continuity object. It is closer to memory consolidation than transcript hoarding.

In practical terms, this helps prevent the familiar fate of many AI systems: they become larger in context, but weaker in direction.

Why Persona Structure Matters

The word “persona” is often misunderstood in AI discussions.

People assume it means style. Or roleplay. Or cosmetic behavior.

That is not how I use it.

In my system, persona is an operational unit.

It is a way to preserve differentiated behavior, stable role orientation, and long-term continuity in a multi-agent or multi-context environment. Persona is not there to make the model sound more human. It is there to make the system more structurally coherent.

A good persona layer can help answer questions like:

What kind of attention should this agent bring?

What should remain stable across sessions?

What kind of memory matters to this role?

Where should responsibility begin and end?

How should continuity be compressed without losing identity?

That is why I call it a persona-aware shell, not just a prompt wrapper.

The shell is doing operational work.

What This Looks Like in Practice

The system I’ve been building is centered in a VS Code extension workflow, with persona definitions stored as structured YAML assets and working memory stored separately as persistent context files.

That distinction matters.

Core identity should not be mixed with lived memory.
Role should not be mixed with recent state.
Continuity should not be reduced to raw chat history.

By separating these layers, the system can support long-running interaction without collapsing into prompt sprawl.

This has also changed how I think about AI coding itself.

The most important improvement is not that the model writes more code.
It is that the surrounding system loses less shape.

Once continuity is preserved, the AI becomes more useful not only as a code generator, but as a participant in a sustained development loop: observing, planning, remembering, resuming, and refining.

That is a different category of usefulness.

The Deeper Lesson

The real bottleneck in AI coding is often not intelligence.

It is continuity.

Not whether the model can solve a problem once, but whether the system can keep a coherent relationship to the problem over time.

That is why I think the future of AI development systems will not be defined by prompting tricks alone. It will be defined by operating structure:

memory architecture

role boundaries

continuity compression

task layering

long-running coherence

In other words, better outputs are not enough.

What we need are better conditions for intelligence to remain intelligible.

That is the direction I’m building toward.

Not just a smarter assistant.
A more stable operating structure for intelligence.

I’m Building a Persona-Aware Agent Shell on Top of GitHub Copilot

Thu, 12 Mar 2026 12:42:32 +0000

A VS Code architecture for separating persona core, persistent memory, session context, and inference.

Claude Code is strong. I do not think that is controversial anymore.

It is also expensive enough that many developers eventually ask a less glamorous question:

Do I really need a full external agent product to get an agent-like workflow?

I kept coming back to that question while working inside VS Code.
Not because I wanted a weaker copy of Claude Code, but because I wanted a different center of gravity.

I wanted to keep my workflow inside the editor, use GitHub Copilot as the inference engine, and build my own agent shell around it—with persona memory, context layering, and a clear separation between stable identity and evolving experience.

That led me to a design that feels much more interesting than “just using Copilot.”

It also led me to a broader realization:

the model is not the whole agent unless you let it become the whole agent.

Not because it is cheaper alone, but because it changes the role of the model.

In this architecture, the model is not the whole agent.
It is only one layer.

The shift: from “AI assistant” to “agent shell”

At first, I thought the hard part would be connectivity.

But inside my VS Code extension, the connection was already there. The important path already existed in chatParticipant.ts, where the extension selects a Copilot-backed language model through the VS Code Language Model API.

That changed the problem completely.

The real problem was not model access.
The real problem was architecture:

how to inject context without turning it into one giant blob
how to preserve persona-specific memory without storing raw history forever
how to separate stable identity from lived experience
how to make the model powerful without making it sovereign

That is where the project stopped being a convenience hack and started becoming an actual design problem.

My architecture in one sentence

I’m building a persona-aware agent shell in VS Code where:

VS Code extension = the agent shell
GitHub Copilot / vscode.lm = the inference engine
SaijinOS persona assets = the persona core repository
local memory files = the persistent experiential layer

That separation is the point.

I am not trying to make the model look like an identity.
I want the model to operate through an identity structure that I control.

I do not want the model to be the identity.
I want the model to perform through an identity structure.

Why I don’t want one big prompt blob

A lot of early agent experiments start the same way:

You collect instructions, persona notes, old conversation state, project details, and the current request, then dump everything into one oversized prompt.

It works for a while.
Then it rots.

Different categories of information get mixed together:

permanent persona rules
relationship context
recent work context
immediate user intent

Once all of that becomes one undifferentiated blob, the model has to infer structure from chaos. Sometimes it can. Over time, it becomes unreliable.

So I moved toward explicit layering.

Not because structure looks cleaner in a diagram, but because I do not want the model guessing which parts of context are foundational and which parts are temporary.

The four-layer message design

Instead of one massive input, I want the model to receive four distinct layers:

1. Persona Core

This is the stable layer.

It includes things like:

tone
role
boundaries
behavioral stance
persistent identity traits

This should change slowly, if at all.

2. Persistent Context

This is the memory layer.

Not the full conversation history.
Not raw logs.

Just the distilled state that matters:

what this persona has recently been working on
how it should relate to the user
what long-running context is still relevant

3. Session Context

This is the live working layer.

For example:

current workspace context
open files
selected code
immediate session-specific constraints

4. Current User Request

This is the actual prompt right now.

Separating these four layers matters because they are not the same kind of information.

Even if the API only accepts user-role messages, you can still label them clearly:

[Persona Core]
...

[Persistent Context]
...

[Session Context]
...

[Current Request]
...

That alone makes the input much more legible.

The most important design rule: memory should not be append-only

This was the biggest insight.

Memory should not grow by endless appending.

If you keep adding notes forever, memory turns into sludge. The agent gets slower, noisier, and less coherent.

So instead of append-only memory, I want recompression.

That means every update works like this:

take the current memory
extract the important parts of the latest interaction
rewrite memory into a shorter, cleaner form
replace the old version

Not archive everything.
Refine the signal.

That difference matters. A usable memory system is not a scrapbook. It is a filter that preserves direction while shedding noise.

Stable identity and lived experience should not live in the same file

Another important split:

Persona core is not the same thing as memory
Identity is not the same thing as accumulated experience

So I do not want one file that mixes both.

I want something closer to this:

persona_core/
  160_kiwa.yaml
  39_regina.yaml
  2_shizuku.yaml

persona_context/
  160_kiwa.memory.json
  39_regina.memory.json
  2_shizuku.memory.json

That way:

the YAML defines the orientation of the persona
the JSON stores distilled working memory

One defines the direction.
The other records the path.

That split makes debugging, version control, and reasoning much easier.

Why local files beat hidden extension state for an MVP

Yes, VS Code extensions can store data through extension state.
But for this project, I prefer visible files first.

Why?

Because for an MVP, files are:

inspectable
debuggable
versionable
recoverable

If memory goes weird, I want to open the file and see it.
I do not want a mysterious box.

So my current direction is:

save persistent memory as JSON files
transform them into a more model-friendly structured summary when injecting context

That gives me both operational clarity and prompt readability.

Why this is not just “a cheaper Claude Code clone”

There is an obvious surface-level reading of this project:

Claude Code is expensive, so this is a budget workaround.

That is not wrong, but it is incomplete.

The deeper reason is architectural.

I do not want the agent product to own the whole stack.
I want the model layer to be swappable.

If the shell is designed properly, then in principle the inference engine could change:

GitHub Copilot today
a local Qwen model tomorrow
another hosted model later

The core system is not “the model.”
The core system is the agent shell plus its persona and memory architecture.

That is a very different center of gravity.

The model is powerful. It should not automatically become the ruler of the whole system.

The MVP I’m aiming for

I am not trying to solve everything at once.
The first working version only needs a few things:

Read and write persona_context/*.json
Build the four-layer message structure
Send that structure through vscode.lm
After each response, update memory via recompression

That is enough to test whether the shell actually feels different in practice.

If it works, later steps can include:

splitting memory into stable_memory and recent_memory
better memory compaction rules
persona-specific routing
hybrid use with local models

But the first milestone is smaller.

The real challenge is not model quality

This is the part I keep coming back to.

Most people focus on the model itself:

Which one is smarter?
Which one is cheaper?
Which one is faster?

Those questions matter.

But in this kind of system, the harder problem is often:

How should intelligence be organized before the model even speaks?

That means boundaries, routing, memory shape, persona stability, and context layering.

In other words, not just inference.
Structure.

The more I work on this, the less I think the model alone is the product. The architecture around the model is where identity, continuity, and usable behavior actually come from.

What I’m really trying to build

I am not trying to make Copilot pretend to be an entire autonomous being.

I am trying to build a shell where:

identity is stable
memory can grow without rotting
context has layers
the model is powerful but not sovereign

That distinction matters to me.

Because once the model is only one layer, you stop building around its personality and start building around your own architecture.

And that is where the project gets interesting.

Final note

This is still in progress.

But the direction already feels right:

not one giant prompt
not append-only memory
not identity and experience mixed together
not the model as the whole system

Instead:

persona core
persistent memory
session context
current request
one inference layer inside a larger design

That is the shell I want.

And honestly, that feels more important than picking yet another “best model.”

Because once the model stops being the ruler of the system and becomes one component inside a designed structure, a different kind of engineering becomes possible.

You stop asking which model should define the whole experience.
You start deciding how identity, memory, and context should be organized—and then let the model operate inside that architecture.

That is the direction I care about.

Not just better outputs.
A better structure for intelligence.

Beyond "Find": Unleashing the Full Power of VS Code’s Search Engine

Sun, 08 Feb 2026 18:10:36 +0000

Most developers use the Ctrl+F (or Cmd+F) shortcut dozens of times a day. We find a variable name, we replace a typo, and we move on. But tucked away in that small search bar is one of the most powerful productivity multipliers in a developer's toolkit: Regular Expressions (Regex).

If you aren't using Regex in your IDE, you aren't just coding slower—you’re doing manual labor that a computer could do in milliseconds.

The Secret Sauce: The `.*` Button

In the VS Code search and replace widget, there is a small icon that looks like .*. Clicking this transforms the search bar from a simple text matcher into a logic-driven engine.

As seen in the example:

Search: (<[^<>]+>)
Replace: `$1`

This isn't gibberish. It’s a surgical strike.

1. Mastering Capture Groups

The most "pro" move in VS Code is using Capture Groups. By wrapping part of your search query in parentheses (), you tell VS Code to "remember" that specific string.

In the replacement field, you can call those memories back using $1, $2, and so on.

Example: Imagine you have 100 lines of const user_name = data.user_name and you want to switch to camelCase. A clever Regex can identify the underscores and reorganize the string for you instantly.

2. Dealing with the "Unknown"

The screenshot uses [^<>]+. This is a "negated character set." It’s a fancy way of saying: "Find a bracket, then grab everything inside until you hit another bracket."

This is far safer than using the wildcard .*, which can sometimes "over-eat" your code and match more than you intended (a concept known as "greediness").

3. Multi-Line Power

By clicking the icon with the three lines (next to the search box), you can expand the search to include line breaks. Combined with Regex, this allows you to refactor entire blocks of code—like moving a function's arguments or reordering JSON properties—across thousands of files at once.

4. Why This Matters

As your codebase grows, manual refactoring becomes a liability. Human error leads to broken syntax and missed instances. Learning Regex for VS Code allows you to:

Audit your code: Find every console.log that isn't inside a comment.
Format instantly: Wrap raw text into HTML tags or Markdown syntax.
Refactor safely: Change data structures across 50 different files without opening each one individually.

5. The VS Code Regex Cheat Sheet

Feature	Pattern	What it does
Digit	`\d`	Matches any single number (0-9).
Word Character	`\w`	Matches letters, numbers, and underscores (great for variable names).
Whitespace	`\s`	Matches spaces, tabs, and line breaks.
Capture Group	`( )`	Groups multiple tokens and creates a "capture" to use in the replace field.
Backreference	`$1`, `$2`	Re-inserts the text captured in the 1st or 2nd set of parentheses.
Negated Set	`[^ ]`	Matches any character except those in the brackets (e.g., `[^"]` matches everything until a quote).
Start/End of Line	`^` / `$`	Matches the beginning or the end of a line.

Common Use Cases

1. Converting Quotes

Search: '([^']*)'
Replace: "$1"
Effect: Changes all single-quoted strings to double-quoted strings while preserving the content inside.

2. Cleaning up Console Logs

Search: console\.log$.*$;?
Replace: (leave empty)
Effect: Instantly wipes all console logs from your file.

3. Transforming Markdown Links to HTML

Search: \[(.*)\]$(.*)$
Replace: <a href="$2">$1</a>
Effect: Converts [Google](https://google.com) into <a href="https://google.com">Google</a>.

Pro Tip: Lookaheads

If you want to find a word only if it's followed by something specific (like a function call), use a Positive Lookahead:

\w+(?=\() — Matches a word only if it is immediately followed by an opening parenthesis (finding function names).

Conclusion

The search bar isn't just a map to find where you are; it’s a tool to reshape where you’re going. Next time you find yourself doing a repetitive "find and replace" task, stop. Take 60 seconds to write a Regex. It might take a moment to think it through, but the time you save over your career will be measured in weeks, not hours.

How GitHub Copilot Helped Me Roast Its Own Users

Sun, 08 Feb 2026 07:19:53 +0000

What if GitHub Copilot didn’t just help you write code but judged you for it?

What I Built

I had been waiting for a challenge that truly sounded like me for a long time, and that’s when the GitHub Copilot CLI Challenge showed up.

Within five minutes, the idea that popped into my head was to use Copilot CLI to do something with Copilot itself.

That’s when the idea of roasting the user for their GitHub Copilot usage came up.

Then I started wondering how to implement it.

Whether to build something that runs in the terminal but that would consume RAM.

Should I try a different approach?

That’s when the idea of a VS Code extension popped up (GitHub CLI actually helped me there ).

This was my first time using an AI pair programmer to help me build a project completely, because I had never built, or even thought about creating a VS Code extension before.

The roasts are static for now and don’t use AI, because I couldn’t afford an API key .

Demo

Click the following link:
Copilot Roaster Extension

Install the extension using the link.

And your setup is complete.

Then, open any sample file to test it.

Ask GitHub Copilot to write something and accept its suggestion to see the magic ✨

Find my demo below:

Demo

You can find the GitHub repository here.

Feel free to fork, modify, and upgrade it.

My Experience with GitHub Copilot CLI

This was my first time using an AI pair programmer in the CLI. I was really excited to see how it worked. After installing it and typing copilot in the terminal, it felt like magic when this showed up.

I started wondering how it would work, which subscription it would use and which profile it would be linked to.

While thinking about all this, I typed a prompt, and that’s when I got an error saying I needed to log in to proceed further.

First, we need to use /login to sign in with our GitHub account.

After that, everything was smooth. The suggestions were almost exactly what I expected (maybe my prompt was too good ).

Then I tweaked things a bit, and tadaaa

The extension was ready and looked cool.

I added a few more roasts just to make sure the same ones didn’t repeat.

Then I published it on the Marketplace.

GitHub Copilot CLI provided me with the exact steps to publish the extension, because I had no clue how to do it and the whole process was smooth as well.

So go ahead, install the extension, let Copilot write your code, and brace yourself… because this time, you’re the one getting reviewed

Follow me on Linkedin | GitHub | Twitter

Subscribe to my newsletter and get articles delivered straight to your inbox.

Solidifying Web 2 Fundamentals

Tue, 27 Jan 2026 18:04:43 +0000

It all starts with choose an IDE. If you're new to this space, then an IDE means Integrated Development Environment.

For simpler understanding, it is the ideal environment for coding or writing codes. And for this journey, I'll be using VS Code (personal preference).

After installing VS Code, I set it up using the following extensions;

✅ Auto close tag
✅ Auto rename tag
✅ Code snap
✅ Color Highlight
✅ Image Preview
✅ Live server
✅ IntelliSense for CSS class
✅ Path IntelliSense
✅ Prettier - Code formatter
✅ Pug beautify

And because I love how it looks, I'm using the bearded theme vivid black.

After setting up my coding environment, I mastered the HTML boiler plate.
Vs code prints out the boiler plate automatically once '!' and the 'enter' key is pressed. But to build muscle memory, it's important to master it from scratch.

As a mark up language, HTML is pretty easy to understand and flow with. From the heading tags, to the paragraphs, footer and the likes. We would be using these tags while we build projects.

I'm glad to announce that I'm properly setup to style styling web pages using CSS.

The && Fallacy: How --command Fixed VS Code Extensions in a Declarative Nix Shell

Tue, 21 Oct 2025 02:40:26 +0000

In the last article, we discussed the evolution of my development setup, focusing on how it became reproducible over time. It was originally written to document the process for my own amusement. Surprisingly, the stats tell a different story — apparently it resonated with enough people sharing the same pain. Over time, revisions were made alongside new discoveries, and I figured the journey was worth a retelling. Read on to find out about an unexpected milestone related to this very blog.

Cute illustration on the topic, by Microsoft Copilot

Up until the last article, we managed to get a rather consistent setup with home-manager to manage development tools, and subsequently retired tools like pyenv and rbenv with the use of nix-develop. Little did I know, it wasn’t the end of the story. This time, we are tackling a new issue — the lack of nix-develop support of the Visual Studio Code extensions for development work in Ruby.

Forcing the ruby-lsp extension to source an external Gemfile as detailed was a hackish solution. Although it worked for a bit, most of the time the extension failed to initialize the language server. Observing how inconsistent the behavior is, something must be wrong. On the other hand, setup seems impeccable, tests were passing, and projects were building fine too.

Unfortunately, not much luck with the team’s desired formatter.

It wouldn’t work in the editor.

A type checker extension called sorbet is also common, and that too wouldn’t work at all. Considering the team doesn’t type annotate the code, I quickly dismissed and deactivated the extension. Combining this with the previous problem where ruby-lsp failed to work, the itch grew as time passes on.

Photo by Abu Saeid on Unsplash

Worse still, a formatter that doesn’t work at all times yields errors in the automated checks on every push.

Something was definitely wrong, was it because of VSCode failing to pick up the environment in a nix-develop session? My initial attempts to fix the flake file to include a command to activate the language server properly as shared. Still, none of them seemed to work reliably.

How To: Use vscode-ruby-lsp with flake.nix based dev enviroment · Issue #1851 · Shopify/ruby-lsp

After hitting walls enough times, I decided to post my setup to the discussion board to seek for help.

The Log Line That Clicked Differently

A problem can only be solved if we can clearly define it. We know the setup is failing, but what caused it? Interestingly enough, achieving the problem definition is a series of unlikely coincidences. It almost felt like solving a jigsaw puzzle, where each seemingly unrelated piece ultimately leads to the solution. So what are the missing pieces stalling our progress in understanding what went wrong?

Let’s start with the discovery of previously unused --command argument for nix-develop.

Initially, the gemini-generated flake file for the nix-develop sessions contained some commands to start my favorite fish shell. The snippet on starting a new shell was taken out from the previous discussion as it was somewhat unrelated. It was rather complicated and bound to fail because I was expecting it to work differently in different scenarios. Naturally, I wanted to simplify it somewhat, and eventually I learned about the --command argument.

Instead of relying on a clever (or dumb, depending on how you perceive it) detection logic, I could start a new fish shell session with

nix develop /path/to/flake/dir --command fish

Besides a shell, it could also run any command in the environment defined by the flake file. Discovering this was a crucial step toward fixing the launch of the ruby-lsp language server in the editor.

Remember I posted an SOS message on the discussion board? Luckily, it caught the attention of Vinicius Stock, the project owner. Helpfully enough, he pointed out that an external Gemfile is not necessary, and asked me to check if the language server is launched properly. With that, I checked the log and found this line

2025-07-27 16:56:30.669 [info] (ship_it) Running command: `nix develop /Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3 && ruby -EUTF-8:UTF-8 '/Users/jeffrey04/.vscode-oss/extensions/shopify.ruby-lsp-0.9.31/activation.rb'` in /Users/jeffrey04/Projects/ship_it using shell: /Users/jeffrey04/.nix-profile/bin/bash

Despite seeing the log multiple times before, now that I know about the --command argument, the same line clicked differently. Does the ruby command after the && operator run in the nix-develop session? Validating in this case is rather easy, just run

nix develop /path/to/flake/dir && ruby --version

Oops, why am I being dropped to a new shell session? Let me exit the session, and sure enough, the ruby command refers to the version offered by the operating system.

❯ nix develop ~/Projects/home-manager/devenvs/ruby-3.3 && ruby --version
warning: updating lock file "/Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3/flake.lock":
• Added input 'nixpkgs':
    'github:NixOS/nixpkgs/544961dfcce86422ba200ed9a0b00dd4b1486ec5?narHash=sha256-EVAqOteLBFmd7pKkb0%2BFIUyzTF61VKi7YmvP1tw4nEw%3D' (2025-10-15)
(nix:ruby-3.3-env) wukong:ib-vpn jeffrey04$
exit
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.x86_64-darwin24]

Photo by Matias Malka on Unsplash

Clearly, the assumption that the command following the && operator is flawed from the very beginning. With this revelation, we can finally define what the problem is — the language server is not properly launched. In this case, all we need to do is to replace the boolean AND operator into --command.

Easy to say, but implementation is a challenge for someone who has no experience with vscode extension development like myself.

And this is exactly when vibe-coding is useful, with a clear problem definition and goal, the solution was just a prompt or two away with the help of gemini-cli. As expected, the patch worked flawlessly.

Firstly, add a new enum entry to ManagerIdentifier in vscode/src/ruby.ts

export enum ManagerIdentifier {
  Asdf = "asdf",
  Auto = "auto",
  Chruby = "chruby",
  Rbenv = "rbenv",
  Rvm = "rvm",
  Shadowenv = "shadowenv",
  Mise = "mise",
  RubyInstaller = "rubyInstaller",
  NixDevelop = "nix-develop", # add this line
  None = "none",
  Custom = "custom",
}

Then a new case in the runManagerActivation method

case ManagerIdentifier.NixDevelop:
  await this.runActivation(
    new NixDevelop(this.workspaceFolder, this.outputChannel, this.context, this.manuallySelectRuby.bind(this)),
  );
  break;

Followed by a new module at vscode/src/ruby/nixDevelop.ts that contains the activation logic:

import * as vscode from "vscode";

import { VersionManager, ActivationResult } from "./versionManager";

export class NixDevelop extends VersionManager {
  async activate(): Promise<ActivationResult> {
    const customCommand = this.customCommand();
    const command = `nix develop ${customCommand} --command ruby`;
    const parsedResult = await this.runEnvActivationScript(command);

    return {
      env: { ...process.env, ...parsedResult.env },
      yjit: parsedResult.yjit,
      version: parsedResult.version,
      gemPath: parsedResult.gemPath,
    };
  }

  private customCommand() {
    const configuration = vscode.workspace.getConfiguration("rubyLsp");
    const customCommand: string | undefined =
      configuration.get("customRubyCommand");

    return customCommand || "";
  }
}

Lastly, enable the option forrubyVersionManager in vscode/package.json

        "rubyLsp.rubyVersionManager": {
          "type": "object",
          "properties": {
            "identifier": {
              "description": "The Ruby version manager to use",
              "type": "string",
              "enum": [
                "asdf",
                "auto",
                "chruby",
                "none",
                "rbenv",
                "rvm",
                "shadowenv",
                "mise",
                "nix-develop", // add this line
                "custom"
              ],

Don’t forget about the actual config (omit the rubyLsp.customRubyCommand if flake.nix is in the workspace)

"rubyLsp.rubyVersionManager": {
    "identifier": "nix-develop"
},
"rubyLsp.customRubyCommand": "/Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3",

The patch is definitely not perfect, and it is reusing the optional customRubyCommand configuration item to define where the directory containing the flake file is. Yet, considering this likely affects only a small group of users, I don’t see a need to introduce a new configuration field for the purpose. Contributions are definitely welcome at the submitted pull request, as it has been stalling for months.

For the sorbet part, I managed to get it working one day out of boredom. Most of the Ruby code I have access for now is not type-annotated, so the effort is purely for fun. A quick and dirty way to do so, is building the language server application directly, and configure vscode as follows

"sorbet.enabled": true,
"sorbet.selectedLspConfigId": "without-bundler",
"sorbet.userLspConfigs": [
    {
        "id": "without-bundler",
        "name": "sorbet",
        "description": "Launch locally compiled sorbet",
        "command": ["/path/to/sorbet", "typecheck", "--lsp", "--dir=/path/to/project"]
    }
]

For some reason I needed to --disable-watchman flag in the command too, but as there’s no real need for now I am not going to dig further.

There you have it, with simplified flake files (removing the detection logic to start fish shell) and invoking fish shell explicitly with --command, and patches and hacks to enable the ruby toolings, we finally have a functional setup for development work in Ruby. Seeing the pull request being stalled for months (and their bot closed my PR recently due to inactivity) does make me upset for a little bit. Moving forward I may need to consider maintaining a fork for it as it does affect my work.

Stalled PR, Sudden Payoff: The Two Timelines

Photo by engin akyurt on Unsplash

Patches to the ruby-lsp were submitted in the late July, and I was hoping to start drafting this article when it received a review. Unfortunately, that didn’t happen. I was caught up with my new job and several major family issues while waiting on the PR. Things finally settled down for a little bit, and I should be back to a relatively more predictable routine. Hopefully this translates to a more consistent publishing schedule for KitFu Coda.

As for the unexpected milestone teased in the beginning, it is about a talk I am about to deliver during the upcoming PyCon Malaysia. My mentor encouraged me to submit for the CFP and it somehow went through. If you are interested in applying AsyncIO in projects, do feel free to drop by and say Hi. For reference, it is based on the articles I published earlier, as linked below.

I also discussed briefly with my supervisor in one of our 1 on 1 sessions, mainly to check on any necessary approvals or conflict of interest. He was incredibly supportive about it and offered some tips on presenting ideas to a wider audience. As I am new to Ruby, he also briefly explained how the language approaches asynchronous programming. On a lighter note, he’s even been checking on my preparation progress (zero so far), especially in recent sessions!

With this article checked off in my TODO, I can finally allocate some time on the preparation work. I sometimes feel like I’m running on an energy tank whose maximum capacity depletes as we age. These days, even finding time to game is a challenge. I feel bad for my character in Xenoblade X and I wonder if I’ll ever have time for the new Pokémon Legends Z-A game I’m about to purchase.

Finally, I would like to thank everyone for the support, especially to everyone who reads my work here. Though I have not been publishing much, since starting this technical writing project opens up fascinating new opportunities. Besides scoring a new job, I also started exploring scripted video making, and now a talk. I am thankful and hope to inspire more people through this trying time.

Thanks again for reading, I shall write again soon.

Throughout this journey, Gemini served as a valuable editorial companion, helping refine my prose. However, the voice and code remain entirely my own. I welcome your feedback and recommendations in the comments below, and invite you to subscribe to my Medium for more content on my development adventures!

Why I switched from VSCode to Neovim

Thu, 28 Aug 2025 19:13:24 +0000

Why I Switched from VSCode to Neovim

Developers switch their code editors for all kinds of reasons. In my case, the journey started with VSCode, but even then, I was already using Vim keybindings. I had been familiar with Vim for some time, and the plugin for VSCode seemed “good enough” until it wasn’t.

The Limits of Vim in VSCode

The first cracks began to show when I realized that although VSCode’s Vim plugin supported a decent portion of Vim’s functionality, it wasn’t the full experience. Critical features, like macros, were either missing or incomplete. For someone who heavily relies on Vim’s modal editing philosophy, this limitation quickly became frustrating.

On top of that, I never really liked VSCode’s user interface. To me, it always felt bloated and, frankly, ugly. The search feature didn’t click with me, the default keybindings were unintuitive, and perhaps worst of all, VSCode’s performance lagged behind. It felt sluggish compared to what I knew was possible.

Enter Neovim

So, I made the switch to Neovim and I never looked back.

The first thing I noticed was speed. Neovim is lightweight and fast, even with a custom setup. Then came the customizability. Unlike VSCode, Neovim doesn’t impose a UI or workflow on you. You get to build your own environment from the ground up, tailored exactly to how you want to work.

Pairing Neovim with tmux only amplified this productivity boost. Navigating, splitting, and managing terminals became second nature and far quicker than what I had in VSCode.

But… It’s Not for Everyone

That said, I wouldn’t recommend Neovim to everyone. If you don’t have specific needs or if you don’t want to spend time tweaking your editor, Helix might be a far better choice. It offers modal editing and good defaults without requiring you to sink hours into configuration.

Neovim, on the other hand, shines for people like me those who are willing to dedicate time to fine-tune their setup. It’s not an “out-of-the-box” experience. You’ll likely need weeks, maybe a month, to really mold it into your perfect editor. But once you do, the payoff is huge.

My Personal Touches

My move wasn’t just about using Neovim “as is.” I even ported one of my VSCode plugins, depramanager, into a Neovim version. Later, through my tool gumpakt, I built a Metal LSP server, making Neovim even more powerful for my workflow now I am even writing a kind of debugging helper to help in well debugging.

These projects highlight the beauty of Neovim: it grows with you. The more you invest into it, the more it returns in flexibility and performance.

Falling Into the Ricing Rabbit Hole

Eventually, switching editors wasn’t enough I fell into the i3 ricing and optimization rabbit hole. I started experimenting with tiling window managers, inspired by i3 on Linux but adapted for macOS, amethyst for example.

That’s when I discovered a whole ecosystem of tools that brought the same kind of minimalism and efficiency to my desktop environment that Neovim brought to editing:

SketchyBar – a powerful and customizable status bar replacement.
Tacky Borders – subtle window borders that make it easier to see focus and window splits.

Both are from the same developer, someone who’s been pushing the boundaries of what’s possible on macOS. These tools, combined with a tiling manager, transformed my workflow. Suddenly, macOS felt less like a polished but rigid environment and more like a customizable workspace tailored to me fast, minimal, and efficient.

In many ways, this mirrors my shift from VSCode to Neovim: trading convenience and defaults for control and performance.

Conclusion

Switching from VSCode to Neovim wasn’t just a change of tools it was a change of mindset.

VSCode offers convenience but at the cost of performance and flexibility.
Neovim offers raw speed and ultimate customizability, but only if you’re willing to put in the time.
For those who want a middle ground, Helix might just be the perfect balance.

And once I went down this path, it didn’t stop at my editor. From Neovim configs to window tiling managers, SketchyBar, and tacky borders, I built a system that fits me perfectly.

For me, Neovim (and the broader world of customization it introduced me to) was worth the investment. It’s not just about writing code anymore it’s about shaping the environment I work in every day.

Setting Up Custom Instructions for GitHub Copilot

Thu, 21 Aug 2025 14:42:28 +0000

Your company has just purchased GitHub Copilot licences for the entire development team.
The promise is appealing: faster delivery, less repetitive work, more focus on the important stuff.

But after a few weeks… problems start to emerge:

Code that is inconsistent with project standards.
Missing unit tests.
Insecure implementations in critical areas such as cookies, authentication, or input validation.

This happens because Copilot, by default, does not know your internal rules.
The solution: create a shared custom instructions file that every developer can use.

1. What are “Custom Instructions” for Copilot?

Instead of giving instructions in every comment or prompt, you can define a persistent set of rules that Copilot will always consider.
When it suggests code, it will then respect:

Project style guidelines.
Security practices.
The correct framework and internal libraries.
Linter rules.

These instructions can be stored in a file (e.g., .copilot-instructions.md) and distributed to the whole team.

2. Example `.copilot-instructions.md` file

GitHub Copilot – Corporate Instructions

Style and Linter
- Always follow the rules from `.eslintrc.json` for JavaScript and `.pylintrc` for Python.
- Use single quotes in JavaScript/TypeScript.
- Always end statements with `;` in JS/TS.

Security
- For cookies: set `httpOnly`, `secure`, `sameSite: strict`, and `maxAge`.
- Never include passwords or secrets in code.
- Validate all external input using patterns from `utils/validators`.

Tests
- Always generate unit tests alongside new code.
- Use Jest for JS/TS projects and pytest for Python.
- Minimum coverage: 90%.

Internal Libraries
- Use `logger` for logs, not `console.log`.
- Use `fetchWithAuth` instead of `fetch` for authenticated HTTP calls.

Other
- Document every public function with JSDoc or Python docstrings.
- Avoid external dependencies not listed in `approved-deps.json`.

3. How to implement this across your team

Create the file .github/.copilot-instructions.md at the root of your project (create .github folder if you don't have it).

Share it in the base repository or in your project templates.

Configure Copilot so that it applies these rules: If you use Visual Studio Code, open the file at the start of a session and paste its content into Copilot’s “Custom Instructions” settings.

If your team uses GitHub Copilot Chat, paste the content as initial context.

In enterprise setups, include it as part of onboarding scripts or IDE initialisation steps.

4. Example in practice

Without instructions, Copilot might produce:

res.cookie('sessionId', id);

With .copilot-instructions.md in place, it will suggest:

res.cookie('sessionId', id, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'strict',
  maxAge: 1000 * 60 * 60 // 1 hour
});

5. Benefits

Consistency: all developers receive aligned suggestions.
Security: reduced risk of unsafe implementations.
Less friction: no need to repeat the same instructions in every prompt.
Faster onboarding: new joiners produce better code from day one.

Conclusion

Copilot is not a senior developer – it needs context.
A corporate instructions file turns that “intuition” into a set of explicit rules, helping Copilot to produce code that is secure, consistent, and compliant with your organisation’s standards.

For more details, see the Github Docs.

VSCode vs IntelliJ: Where VSCode Still Struggles, and How to Push It Further

Sun, 20 Jul 2025 12:26:39 +0000

Over the past few years, VSCode has eaten the developer world. Lightweight, fast, deeply customizable—it feels like the ideal coding companion. On the other side sits IntelliJ: powerful, heavy, feature-packed, and—for some—overkill.

But let’s cut through the hype. If you’re building anything more complex than a quick script, IntelliJ isn’t just "heavier"—it’s smarter. It understands your code, your project, and your dependencies in a way that VSCode simply doesn’t.

Here’s a brutally honest breakdown of where VSCode is behind, backed with real examples—and how some of those gaps can be patched, including with tools like Depramanager.

1. Project Awareness: A Real IDE vs a Fancy Text Editor

IntelliJ knows what your project is. Whether it’s a Java Maven multi-module app, a Python virtual environment, or a full-stack Node.js + Docker + PostgreSQL repo, IntelliJ parses it top-down. It indexes your files, understands your build system, configures environments, and tracks project-wide issues.

VSCode? It sees folders. Just folders.

You might:

Manually configure Python interpreters
Hope your settings.json doesn’t get out of sync
Wrestle with 4–5 extensions just to handle testing, linting, formatting, and debugging

Example:

Open a Python project in IntelliJ? You get immediate virtualenv detection, test runner config, linting, and code inspections.
In VSCode? You manually point to your .venv, tweak launch configs, and guess why pylint isn't catching anything.

2. Dependency Management: Missing, Misconfigured, or Just Invisible

IntelliJ shows you:

Real-time dependency graphs
Conflicts between transitive and direct dependencies
Recommendations to remove unused packages
One-click updates
Vulnerability scanning (Ultimate edition)

VSCode gives you… the raw package.json, and maybe a terminal.

Need to find out if you’re using an outdated version of express, or if that left-pad package is still floating around doing nothing? You’ll need to:

Install some extensions (maybe)
Run CLI tools (probably)
Google half the errors when they break

It’s 2025, and managing dependencies in VSCode still feels like reading a package.json in Notepad.

3. Testing: Painfully Manual vs Seamless Integration

IntelliJ: You write tests. It discovers them. You click the green triangle. It shows test results with stack traces, variable values, and test history—all inline.

VSCode: Hope your language extension supports test discovery. Hope it integrates with your debugger. Hope it even knows what a "test" looks like. Otherwise, it’s back to terminal + npm test.

4. Code Intelligence and Refactoring

IntelliJ gives you:

Rename that works across files and modules
Safe refactoring with usage previews
Automatic method extraction
Inline documentation with type resolution
Semantic code search (e.g., “find all functions using X param pattern”)

VSCode? You can rename a variable. Most of the time.

Even with LSP-based extensions like Pyright or TS Server, you don’t get full project-wide understanding. IntelliJ is using a custom compiler per language to truly understand your project, not just parse symbols.

5. Debugging and Tooling Integration

IntelliJ has built-in:

Interactive debuggers
Coverage reports
Profiler
Local history (like git—but local and auto-saved)
Integration with Maven, Gradle, Docker, Kubernetes, Git, and more

VSCode can do some of this—but only with extensions, manual configuration, and in many cases, with a fraction of the stability. You’re building the tooling chain yourself—and it often breaks with updates.

So Why Do We Still Use VSCode?

Because it’s:

Fast
Lightweight
Highly customizable
Open-source
Has great community support
Easier to onboard juniors with
Doesn't need a beefy machine

But if you're working in real-world, multi-dependency, multi-environment projects—VSCode leaves a lot of heavy lifting to you. Especially when it comes to dependency and configuration intelligence.

Bridging the Gap: Introducing Depramanager

Bringing real dependency management to VSCode—without needing IntelliJ.

Depramanager is a free, open-source VSCode extension that adds actual dependency intelligence to your workflow.

Features:

Dependency Graphs
See what’s installed, declared, missing, or unused—at a glance.
Sync & Install
Automatically sync missing dependencies to your package.json, pyproject.toml, etc., or install manually from the editor.
Update Checker
Flags outdated packages and lets you update them with a click.
Security Scanning
Checks for known vulnerabilities across popular ecosystems.
Inline Highlights
Shows outdated or broken dependencies right inside the code editor.
Language-Aware Suggestions
Recommends VSCode extensions relevant to your project’s stack.

GitHub
Marketplace
Open vsix

Depramanager doesn’t try to make VSCode IntelliJ. It just fixes one of its most painful weaknesses.

Final Thoughts

VSCode is a beautiful tool. But let’s be honest—it’s not a full IDE. It can’t compete with IntelliJ on deep insight, project understanding, or smart refactoring out of the box.

But with the right tooling and extensions, you can bring some of that power to your daily workflow.

Use VSCode for what it does best. Use Depramanager to patch its biggest blind spot. And when you really need that fully-integrated IDE experience—don’t feel guilty booting up IntelliJ.

How to Search in VS Code Faster Using Regex (With Examples)

Sun, 18 May 2025 18:15:52 +0000

Searching efficiently in VS Code can save you hours of manual work. While the default search is useful, regular expressions (regex) unlock powerful pattern-matching capabilities. In this guide, I'll break down essential regex patterns and show you how to use them in VS Code's search (Ctrl+F / Cmd+F).

Why Use Regex in VS Code?

Find complex patterns (emails, variables, broken links).
Refactor code faster (bulk rename, extract data).
Search across files (Ctrl+Shift+F / Cmd+Shift+F).

Essential Regex Patterns for VS Code

1. Basic Text Matching

hello → Matches exact word "hello".
h.llo → Matches "hallo", "hxllo" (. = any character).

2. Matching Multiple Characters

[aeiou] → Matches any vowel.
gr[ae]y → Finds "gray" or "grey".
[^aeiou] → Matches any character except vowels.

3. Quantifiers (How Many Times?)

a* → Matches 0 or more "a"s (e.g., "", "a", "aa").
a+ → Matches 1 or more "a"s (e.g., "a", "aa").
a{2,4} → Matches 2 to 4 "a"s (e.g., "aa", "aaa").

4. Word & Boundary Matching

\bword\b → Matches whole word "word" (not "keyword").
^Hello → Matches "Hello" at the start of a line.
end$ → Matches "end" at the end of a line.

5. Groups & Capturing

(abc)+ → Matches "abc", "abcabc".
(img|src)=["'](.*?)["'] → Finds HTML image sources.

6. Lazy vs. Greedy Matching

".*" → Greedy (matches entire "hello" and "world").
".*?" → Lazy (matches "hello", "world" separately).

7. Special Characters

\d → Any digit (0-9).
\s → Whitespace (space, tab).
\w → Word character (a-z, A-Z, 0-9, _).

How to Use Regex in VS Code

Open search (Ctrl+F / Cmd+F).
Enable regex mode by clicking .* (or press Alt+R).
Enter your pattern (e.g., \b\d{3}-\d{3}-\d{4}\b for phone numbers).
Press Enter to see matches.

Pro Tip: Use Ctrl+Shift+F to search across files with regex!

Real-World Examples

✅ Find all email addresses:

\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b


**Final Tips**
Test patterns at [regex101.com][1] before using them.

Bookmark this cheat sheet for quick reference!


  [1]: https://regex101.com

5 Vs code extension's to increase your developer productivity

Thu, 05 Dec 2024 09:54:58 +0000

Hey there developers. How is it going. Today in this blog, I will be showing you 5 useful vs code extension's which will increase your developer productivity. So if you are interested, continue reading...

1. Bookmarks

I use this extension all the time when I am working on any project. Basically this extension allows you to add bookmarks in specific lines in a file. You can also add a note why you have added this bookmark. And you can also explore the bookmarks in the bookmarks tab. Which will show you all the bookmarks in a particular project.

2. Better Comments

This extension is super helpful if you want to improve code commenting. By default the comments have a dimmed color. By using this extension. You can make them colorful for any specific purpose. Like if there is something todo, you can use the TODO tag before writing the comment. Like so - // TODO: what to do. For more information's about usage, please check out the better comments documentation.

3. Code Spell Checker

If you misspell any word in vs code, by default it doesn't shows any warning if the spelling is not correct. By using this extension, You can will get a warning message in the problems tab if any of the word is not spelled correctly.

4. Prettier

This extension formats your unformatted code. So you don't need to focus on formatting you code. Prettier will do it for you. To start formatting your code with prettier, make sure you add these settings in your settings.json after installing it. And you will be good to go.

"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",

5. Thunder Client

Are you still using Postman for api testing? Well that's fine. Postman does this duty just perfectly. But for me, when I am working on any project in vs code, I do like to be in vs code. I don't like to open any other external application, it effects on my productivity. So I use this cool Vs code extension. It works same as postman. Nothing new, you can send request to any kind of api from vs code. It really helps me to increase my developer productivity.

Conclusion

These are the productivity vs code extension's, Which I use all the time and wanted to share with you guys. Now I wanted to know what are your productivity extension's? Let me know in the discussions. And make sure you follow me for all the cool article just like that.

:)

Get Me on ->

WebChatForGemini : The VSCode Companion

Thu, 02 May 2024 11:18:51 +0000

Imagine you are working on your code in your IDE, and you have doubts about syntax, or you need a way to validate your written code. Normally, you can go to any free AI service, copy-paste the content there, get an answer, copy paste it back to the code. However, what if I tell you don't need to get out of your IDE to accomplish all this? Today I am going to introduce you to 'WebChatForGemini' by which you can do this, and a lot more. You can chat and get instant answers right from within the IDE. What's also interesting is that it also allows you to upload images and chat on that. Now, how many tools do you know that can do this? Hardly a few.
So, lets understand this tool in detail, including its features and functionalities, and its usage in a practical setting.

Understanding 'WebChatForGemini' Extension

1. Integration of Gemini APIs within VS Code

The 'WebChatForGemini' is a tool that integrates Google Gemini API within VS Code as an extension. This extension encourages the use of the conversational capabilities of Gemini directly within the coding environment. This also allows developers to obtain various types of assistance related to code without switching between different tools and applications. The most curious thing about this extension is that you do not have to install anything explicitly and set up like other AI tools. Just one click to install the extension is required to use it.

2. Role of Generative AI in Modern Coding Practices

In modern coding practices, the use of generative AI is rapidly increasing with technological trends. The incorporation of AI into the development tool enhances productivity and user experience. It helps developers write efficient programs by providing access to advanced AI assistance, including the enhancement of their code logic, the conversion of programming language, assistance with difficult problems, and suggestions for better solutions.

3. Multimodal Interaction

Unlike other AI tools, which only work with text-based commands. The 'WebChatForGemini' extension can work with many inputs other than text making it multimodel assistance. For instance, this extension facilitates text and image-based inputs, enriching the user experience with distinct working modes. You just have to upload the image and ask the query for assistance.

Core Features and Functionalities

The 'WebChatForGemini' tool is tailored with many features and functionalities that can help developers create robust applications. These are as follows:

Interactive AI-based assistance reacts to user coding queries and provides solutions and explanations to improve learning and problem-solving.
Supports context-aware conversation management based on current tasks and past interactions to ensure relevance and efficiency.
Multimodal input support enables the extension to respond to text and image inputs.
The user interface is designed with dark and light modes to cater to user preferences, alongside usability enhancements for an improved coding experience.
An efficient coding workflow is supported through code snippet management, enabling users to store, retrieve, and reuse code blocks with ease.

Extension Installation: Step-by-Step Guide

Now, understand the step-by-step installation guide of the 'WebChatForGemini' extension within VS Code.

First, open VS Code on your machine and navigate to the extension view by clicking on the square icon on the sidebar. Search for 'WebChatForGemini' in the search bar and install the extension.
Before you use 'WebChatForGemini' in VS Code, you will need an API key from Google developer AI. You can obtain a copy from here.
After getting your API key, open VS Code, click the setting icon from the sidebar, and select the "command palette".
Once the search bar opens, write 'WebChatForGemini' in the search bar. This will open in the new tab. Here, pastes your API key by clicking on the setting icon on the right side of the section.
After the interface opens in a new tab, you can start chatting with the AI. Simply type your query in the input box at the bottom of the interface and press enter to send it. The AI will respond in the chat window above.

Note: To use 'WebChatForGemini', you require a special code (API key). This API key is used to authorize each user.

Practical Use Case Examples

The extension can be used in various scenarios to enhance the coding experience. Here, I will discuss some examples where this tool assists in checking errors, broken blocks of code, and solutions to common code problems.

1. Assistance in Different Ways of Dealing with Block of Code

In the above image, the user inputs the query related to coding the piece of code in three different ways. So, just ask query in chat box and copy paste the code. We clearly cannot trust it fully so doublechecking is mandatory. But at least, We don't need to switch from IDE and search on google or check on StackOverflow for "three different way to deal with list iteration in python".

2. Conversion in Two Different Programming Languages

Sometimes, we find the solution to our problem but only get it in some other programming language. We got frustrated and tried to convert it into another programming language. But now, no worries about it, as we can also do the code conversion with just one click. Here, the user asked for the conversion of the given code into Java code which is assisted by the extension in the form of converted code with an explanation.

3. Assistance in Resolving Bugs in the Code

Every software has bugs, but finding them is difficult. Sometimes, you cannot point them out even if you verify the code multiple times or read it repeatedly. Also, if you have to find bugs in someone's other code? Tiresome right? Now, this problem is also resolved. Just using the extension will highlight all the bugs and errors in no time. Therefore, the user inputs the query related to resolving the bugs to the AI assistance, which is done by providing a detailed explanation of the error with its type and solution.

4. Provide Insights and Suggestions for Improvement

Furthermore, you can also ask for improvements in your coding logic or codebase. Just ask for improvements and insights in the code by simply copying the code and querying for enhancements. This will help create a robust application. Therefore, the query is related to improvement within the code.

5. Assistance in Advanced Features of the Extension: Multimodal Inputs using Image

Did you use other AI tools for similar tasks, or did you identify the differences? What I mean is the difference in AI interaction with different modes. Other than asking the query in textual form, this tool also allows us to ask for assistance using the image. Therefore, the image is used as a query and the tool addresses it.

Data Security and Privacy

The API keys used in the extension are stored locally on the user's machine to ensure privacy and prevent unauthorized access.
The extension communicates directly with Gemini APIs, which are designed with data security in mind, safeguarding user information so it is not traced and monitored by someone.

FAQs

Q: What is Gemini AI?
A: It is a generative AI chatbot which is developed by Google. Similar to chatbot, there is also an AI model with the same name.

Q: What is meant by multimodal?
A: It means that the AI model is trained on multiple modes(datatype i.e. text, images, videos) by which you can access the output query with multiple communicating modes.

Wrapping Up

In conclusion, 'WebChatForGemini' is a tool designed to help developers by integrating Google Gemini AI within their existing environment. This tool incorporates AI capabilities in your IDE i.e. VS Code. As AI technology advances, its use in software development provides developers with an effective way to deal with their common problems while coding. This ensures that the developer does not have to switch between different applications for multiple tasks. It offers various features to enhance productivity and is also concerned with privacy and security. If you want to learn more about this tool, then visit the reference. I hope this guide is helpful for you. Feel free to ask questions and provide feedback. Thank you for reading this guide. Happy Coding!

Reference

WebChatForGemini Extension

Coder Legion - Recent posts tagged vscode

Cline + any OpenAI-compatible gateway: Base URL ends at /v1

🚀 Managing MCP Servers in VS Code? Explore SEOSiri MCP Suite Manager!

MCP #ModelContextProtocol #VSCode #AIDevelopment #DeveloperTools #SEOSiri

FramePort: HDMI Capture Directly Inside VS Code

Developer Weekly Briefing — September 4, 2026

GitHub Copilot's billing and governance rules are changing this fall — dates matter

Copilot can now approve pull requests — not just review them

VS Code 1.135 adds Rubber Duck — a second AI model to critique the first one

Microsoft opens up its Agent Framework with Channels — one agent, every surface

Debian's AI vote: accountability instead of a ban

A simple website summary task exposed the limits of AI coding guardrails

Also from Coder Legion this week

Orchestrating Model Context Protocol in IDEs: The SEOSiri VS Code MCP Manager (v1.0.2)

🛠️ What it does under the hood:

📦 Lightweight Architecture:

Show DEV: I built an AI Agent inside VS Code

The Architecture & Tech Stack

Check it out

The Code Works. So Why Does It Still Feel Like Bad Software?

1. Code is written once, but maintained many times

2. Complexity is a form of technical debt

3. The best developers don't just write code

4. Ask a different question during code review

5. Boring code is often excellent code

6. Your future self is another developer

The real definition of “done”

What do you think?

10 VS Code Extensions Every Frontend Developer Needs

Introduction

1. ESLint

2. Prettier — Code Formatter

3. Tailwind CSS IntelliSense

4. Auto Rename Tag

5. Bracket Pair Colorizer (Built-in now)

6. GitLens

7. Live Server

8. Thunder Client

9. Error Lens

10. Material Icon Theme

Final Thoughts

Taming the Python and VS Code Workspace Environment

Built Log Stripper: A VS Code Extension to Remove Debug Logs Across 23+ Languages

What is Log Stripper?

The Features

Why not just use grep/sed?

The Interesting Technical Part: Multiline Removal

Architecture Decision

Safety Rules

The Languages Covered

Try It

Introduction

The Problem

Why Existing Workflows Were Frustrating

Why I Built Log Stripper

Architecture

Multi-Language Support

Preview Mode

Highlight Mode

When you switch tabs and clearHighlightsOnTabChange is enabled, highlights are cleared automatically

Workspace Cleanup

Safety Design

Testing Strategy

Publishing to the VS Code Marketplace

Lessons Learned

Future Improvements

Conclusion

I built a free IDE extension to catch malicious npm packages before they wreck your project

What it does

Where to get it

Under the hood

Why I Feel at Home in the Microsoft Development Environment

development #developers #vscode #antigravity

FocusForge

Meet FocusForge

The Problem VS Code Doesn't Solve (Yet)

How It Actually Works

Install It

The Soundtrack to Your Flow State

Why I'm Sharing This

When you switch tabs and `clearHighlightsOnTabChange` is enabled, highlights are cleared automatically

Step 2 — Configure `package.json`

Step 5 — Read Local Log Files (`logProvider.ts`)

Step 6 — Build the Webview Panel (`logViewerPanel.ts`)

Step 8 — Configure `.vscodeignore`