Writing
Part 1: Get Everyone an AI IDE - The Foundation of Enterprise AI
The most useful advice I can give a large engineering organization about AI is also the least exciting: before you build agent platforms, get every engineer a serious AI IDE and make it safe enough to actually use. Everyone wants to start with the impressive part. The impressive part comes later, and it goes badly if you skip this step.
Why the IDE is the wedge
The IDE sits at the point of work. It explains unfamiliar code, writes tests, handles the boring half of a migration, and shortens the gap between intent and implementation. None of that is dramatic on its own. The gain compounds because it touches almost everything an engineer does in a day.
There's a quieter reason too. The IDE is where engineers build the muscle memory for working with models — what to trust, what to verify, where the failure modes hide. An organization that wants people supervising autonomous agents next year needs them arguing with a code assistant today. You can't skip the apprenticeship.
The rollout is a control-plane problem
Buying licenses is the easy part. The real work is everything underneath: identity, source-code boundaries, secrets handling, network policy, logging, extension allowlists, model routing. The IDE is the surface the developer sees. The platform work sits below it, and it's the part that determines whether the tool gets used at all.
Here's the pattern I've seen repeatedly: when security policy is ambiguous, engineers don't ask for clarification. They quietly stop using the tool — or worse, they keep using it and stop telling you. Ambiguity suppresses use more effectively than a hard no, because at least a hard no can be appealed.
The principle that resolves this is one I keep returning to across this whole series: make the safe path the default path. Approved models, approved repositories, approved tools, automatic redaction, and a clear escalation route when someone genuinely needs more access. Developers shouldn't have to hold the policy in their heads. If the safe way to work is also the easy way to work, you don't need a compliance campaign.
Measure usage, not procurement
License counts tell you who could be using AI. They tell you nothing about whether work changed. The signals worth watching are humbler: which teams are actually activated, whether AI-generated diffs survive review or get reverted, where people get stuck, and which policy violations keep recurring — secret exposure, disallowed repository access, unsafe command execution. You don't need an elaborate dashboard on day one. You need enough signal to distinguish a tool that changed how people work from a tool that's merely installed.
The AI IDE is not the end state. It's the foundation — the place where engineers learn the new reflexes before the organization asks them to supervise something larger. The next problem is that an IDE without access to internal context is working with one hand tied behind its back, which is where the series goes next.
This is Part 1 of the AI-for-Work series. Next: Part 2: Building a Centralized MCP Gateway.