# Tooling

> The enablement layer beneath IDEs, agent CLIs, notebooks, and chat. How to survive tool churn without re-platforming every year.

Source: https://brocs.fyi/build/tooling/
Part of the surface: B · Build. Enable people to make things.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Build surface

- Tooling: IDEs, agent CLIs, notebooks, chat surfaces
- Access: who gets which tools, and how fast
- Keys and models: distribution, scoping, rotation, BYOK
- Data access: without handing out production credentials
- Idea to production: golden paths, templates, scaffolds


Tooling is the set of interfaces through which people in your organization do AI work:
IDEs and their assistants, agent CLIs, notebooks, chat surfaces, and low-code builders.
The Build question is not which of these is best. It is what sits underneath all of them,
and whether that layer is yours.

## The churn is the design constraint

Name the AI coding tool your engineers used eighteen months ago. Now name the one they
use today. For most organizations those are different answers, and there is no reason to
expect the next eighteen months to be calmer.

This is normally treated as a procurement annoyance. It is actually an architecture
requirement. If identity, key distribution, data access, and runtime are configured
inside a specific tool, then adopting the next tool means redoing all four, and the
organization quietly develops a preference for whatever it already has. That preference
is not a considered decision. It is switching cost pretending to be strategy.

The alternative is an enablement layer that the tools plug into rather than the other way
round. Identity comes from your identity provider. Keys come from your key service.
Data access goes through your gateway. Execution happens in your runtime. The tool
becomes a client, and a client is replaceable.

## What belongs in the layer, not the tool

Five things, and it is worth being strict about them.

**Identity.** The tool authenticates the person against your IdP. It does not hold its
own user list, and it does not have a separate concept of a team.

**Model credentials.** The tool receives a scoped, short-lived credential, or it talks to
a gateway that holds the real key. It never sees a long-lived provider key, and it is
never the thing that decides which model is allowed.

**Data access.** The tool reaches data through an interface that already knows who the
user is and what they are allowed to see. Handing an assistant a database URL and
trusting the prompt is not access control.

**Execution.** Anything that runs code, installs packages, or touches infrastructure runs
somewhere you chose, with the permissions you granted. See [Run](/run/).

**Telemetry.** Usage, cost, and traces flow to your observability stack, not only to the
vendor's dashboard, which you will lose access to the day you stop paying. See
[Observe](/observe/).

If those five are yours, a tool migration is a configuration change and a training
session. If any of them lives inside the tool, it is a project.

## Desktop tools, remote capability

A common false choice: either people work locally and lose access to shared compute,
data, and long-running agents, or everything moves to a browser and you fight the
developers who are faster in their own editor.

The resolution is that a desktop tool can drive remote capability. The editor stays
local; the agent runs on a machine you control, with the data mounted and the credentials
injected there. Nothing sensitive lands on the laptop, and the workflow is still the one
people already know. Getting this right is mostly about the execution and credential
boundaries above, not about the editor.

## Standardize the interface, not the vendor

The useful standardization target is the shape of the integration: how a tool discovers
what data and actions it may use, how it authenticates, and how it reports what it did.
Where an open protocol exists for that shape, prefer it, because it is what makes the
next tool a drop-in.

Standardizing the vendor instead produces the outcome the framework is arguing against:
a single supplier holding your identity, your keys, your data path, and your runtime,
with a switching cost that grows every quarter.

{{< aside title="How platform engineering thinks about this" >}}
A platform team's instinct is to build the paved road and let teams choose their own
boots. Applied here: the platform owns identity, credentials, data access, runtime, and
telemetry, and stays deliberately uninterested in which editor you like. The failure mode
platform teams already know is building the road around one vendor's boots, then
discovering the vendor changed the sole.
{{< /aside >}}

## Tooling is a supply chain

An agent CLI or an editor extension is executable code with network access and, usually,
your credentials. It deserves the same provenance questions as any other dependency:
who publishes it, who can merge to it, is the version pinned, and what happens on
auto-update.

There is a newer wrinkle. Prompts are now part of the shipped artifact, and a prompt is
an instruction to something that can act. Review processes built to read a code diff will
skim a text file.

{{< failure id="amazon-q-wiper" >}}

{{< checklist >}}
- If we replaced our primary AI coding tool next quarter, what would we have to rebuild?
  Name the systems, not the effort.
- Where does this tool get the user's identity? If the answer is "its own account", who
  deprovisions it when someone leaves?
- What model credential does the tool hold, and how long does it live?
- Does anything this tool does show up in our telemetry, or only in the vendor's console?
- Which extensions and agent CLIs are installed across the fleet right now, at which
  versions, and who can merge code into them?
- When the tool auto-updates, what reviewed it?
- If people work remotely, is the sanctioned path better than cloning the repository to
  a laptop? If it is a jump box and a VPN, assume the code is on the laptops.
{{< /checklist >}}