AI Tooling Belongs on a Path That Already Works

The pitch is always the same. Give every engineer an assistant. Watch velocity go up. Put the chart in a QBR.

I have led AI enablement programs. I have trained engineers on Claude, Claude Code, and OpenAI tooling in a regulated healthcare environment. I believe these tools are real. I also believe most organizations are trying to buy a path they have not built.

An assistant cannot outrun a broken Developer Experience. It can only generate code faster toward the same traffic jam.

What the tool actually accelerates

AI-assisted development is very good at the middle of the work: drafting, translating, filling in the obvious, proposing a test you should have written.

It is not very good at the edges that actually determine whether software ships:

• Which pipeline is the real one.
• Which environment is safe to touch.
• Which module is the company’s, not last year’s experiment.
• Which secret must never land in a prompt.
• Which “green” check is theater.

Those edges are platform. If they are muddy, the assistant will be confidently wrong in a new font.

I have watched this movie with agents in production. A model that sounds sure while missing the contract is not a productivity story. It is an incident with better UX.

Enablement without a path is a workshop

When I ran AI code assistant programs, the unlock was never the license. It was the habit plus the guardrail.

Prompting patterns people reused on Monday. Review standards that assumed the first draft might be generated. Clear rules about data that does not leave the building. Pairing until “the AI did it” stopped being an excuse and started being a step in a reviewable process.

That work only stuck where the surrounding path was already honest. Teams with a paved CI/CD road used the assistant to move along it. Teams without one used the assistant to generate more snowflakes.

More snowflakes is not velocity. It is entropy with a copilot.

Evaluate the tool against the path

If you are evaluating AI-assisted development in 2026 — and you should be — do not start with a feature matrix. Start with a walk.

Give the candidate tool the same job you would give a strong new hire:

1. Open a real service, not a demo repo.
2. Change something that has to pass CI.
3. Stand up a preview.
4. Get a reviewable diff that a staff engineer would not be embarrassed to comment on.

Then ask the questions that actually matter:

• Does it respect your contracts? Modules, linters, policy-as-code, secret scanning. If it cheerfully bypasses them, it is a liability.
• Does it shorten time-to-honest-feedback? Or does it just produce more code for the same twenty-minute pipeline to chew?
• Does it make juniors skip judgment? Speed that skips formation is a training debt you will pay in review, then in production.
• Does it stay inside your data boundary? Wealth, healthcare, any regulated shop: if the answer is a shrug, the evaluation is over.

I am doing this work now as part of leading Developer Experience at AssetMark. The order is deliberate. Platform first. Assistant second. Not because I am allergic to new tools — because I have seen what happens when the order is reversed.

The Expert Vision problem, again

Experts use tools as lenses. They glance, they verify, they keep what survives contact with the system they already understand.

Novices use tools as oracles. The sentence looks finished, so the thought must be finished.

If you drop an assistant into an organization without a visible path, you do not just risk bad code. You risk freezing novice scan paths in place. The model becomes the structure they never learned to see.

That is the opposite of amplified expertise. That is outsourced perception.

The fix is not “ban the tools.” The fix is to make the platform so structurally obvious that the assistant has something true to complete: a template, a workflow, a module, a test that already encodes the company’s taste.

What I will fund, and what I will not

I will fund AI tooling that sits on a golden path — the same path a human would walk — and makes that walk shorter.

I will not fund a second, unofficial path that only exists inside a chat sidebar.

I will fund training that treats the model as a junior pair: useful, fast, and not to be trusted with the keys.

I will not fund “we bought seats, so we transformed.”

This is the same reframe that worked for GenAI governance. Safe paths to yes. Clear tiers. Instrumentation. Habits that survive the vendor’s next keynote.

The question under the license

Before you renew, or buy, or mandate:

If you turned the assistant off tomorrow, could a competent engineer still ship?

If the answer is no, you did not buy productivity. You bought a dependency.

If the answer is yes — and the assistant makes the same path faster, safer, and easier to review — then you bought Developer Experience.

That is the only purchase I am interested in.