VSCode Is a Fancy Notepad and Other Corporate Developer Realities

There's a special kind of frustration reserved for developers who work in large organisations. It's not the legacy codebase. It's not the meetings about meetings. It's the moment you realise your IDE — the one tool that's supposed to make you productive — has been stripped down to something your parents could've used to write grocery lists.

Welcome to corporate development, where the tools fight you harder than the code.

The Notepad Problem

Let me set the scene. You join a large organisation. They hand you a laptop. Pre-installed: VSCode. Great. You open it, reach for your usual extensions — the ones you've been using for years, the ones that make you fast — and you hit a wall.

"This extension has not been approved."

So you raise a request. Someone reviews it. Someone else reviews the review. A third person questions whether you really need a linter. Three weeks later, you're still writing code in what is technically VSCode but functionally Notepad with syntax highlighting.

The IDE options themselves are already limited. You didn't choose VSCode because it was the best tool for the job — you chose it because it was the only option on the approved list. The alternative was something that hasn't been updated since people thought Java applets were the future.

And look, I get it. Security matters. Compliance matters. But there's a line between "let's be careful" and "let's make sure nobody can be productive."

AI Tools: The Wrapper of a Wrapper

Now let's talk about AI. Because of course, every large org has jumped on the AI bandwagon. They'll tell you they're "empowering developers with AI-assisted coding." What they actually did is wrap ChatGPT or GitHub Copilot behind an internal portal, slap a corporate logo on it, and call it innovation.

The catch? You can't feed it your codebase. You can't give it context about your project. You can't point it at a repo and say "understand this, then help me."

So what do you get? A general-purpose chatbot that hallucinates function names that don't exist in your stack, suggests patterns your architecture doesn't follow, and confidently writes code that would fail every code review your team has ever done.

It's like hiring a consultant who's never seen your product but insists they know exactly what you need. We've all met that person.

The irony is brutal. The entire value proposition of AI coding assistants is context. Take away the context, and you're left with a very confident autocomplete that's wrong half the time. But sure — let's put it behind a portal, restrict its access, and then wonder why adoption is low.

The Gatekeeping Machine

Here's where it gets personal. In many organisations, access to developer tools is controlled by systems designed to "validate your knowledge" before granting access. On paper, this sounds reasonable. You don't want a junior accidentally nuking a production database because they got admin access on day one.

But in practice? These systems don't distinguish between someone who's never touched a terminal and a senior engineer who's been shipping production code for a decade. Everyone goes through the same approval pipeline. Everyone fills out the same forms. Everyone waits.

And the approvals are controlled by a small group of people who may or may not understand what you're actually asking for. You end up explaining to someone why you need Docker access — not in technical terms, because that would be too easy — but in business justification language that sounds like you're applying for a government grant.

"This tool will enable me to containerise microservices, reducing deployment friction and improving environment parity across development stages."

What you mean: I need to run a container locally.

For the few individuals who genuinely need hand-holding, fine. The system works. But for experienced developers — people who've already been through the fire, who understand the risks, who just want to do their job — it's a massive blocker disguised as a safety net.

The Real Cost Nobody Talks About

Here's the reality check. Every hour a developer spends fighting tooling is an hour they're not building. Every week waiting for an extension approval is a week of suboptimal output. Every AI interaction without context is a context switch that slows things down instead of speeding them up.

Large organisations love to talk about developer productivity. They hire consultants, run surveys, buy platforms. But they won't let you install a code formatter without a two-week approval process.

The developers who've already proven they can handle these tools — who've built their workflows around them, who know exactly what they need and why — are the ones most punished by these systems. Seniority should buy you trust, not more paperwork.

What Would Actually Help

I'm not saying throw the doors open. I'm not saying let everyone install whatever they want on a corporate machine. But there are reasonable middle grounds that most large organisations refuse to explore.

Tiered access based on role and seniority. A staff engineer doesn't need the same approval flow as an intern.

AI tools with actual codebase access, even if scoped and sandboxed. The technology exists. The fear is what's holding it back.

Faster approval cycles. If reviewing an IDE extension takes three weeks, the process is broken. Full stop.

Trust your developers. You hired them because they're good. Let them prove it with more than a Jira ticket.

The Quiet Resignation

The worst part isn't the frustration. It's the quiet acceptance. Developers stop asking. They stop raising requests. They adapt to the limitations and write code with half the tools they could have. Productivity drops, but nobody notices because there's no baseline — everyone's equally handicapped.

And the really good ones? They leave. They go somewhere that trusts them with a full IDE and an AI tool that actually knows what their code looks like.

Corporate tooling doesn't just slow developers down. It tells them something: we don't trust you enough to let you work properly.

And that message lands louder than any all-hands presentation about "developer experience."