Who Should Get AI Coding Tools at Work?

Giving everyone the newest AI coding agent sounds progressive.

It can also create a situation where people generate code they cannot review, tools reach data they should not see, and nobody knows whether the productivity gain is real.

A better rule is simple:

Give people the AI capability their job requires, under controls appropriate to what that capability can access and change.

The recent Goldman Sachs story is a useful example.

Bloomberg reported on November 2, 2026 that internal guidance updated in October restricted Anthropic's Claude Code and Microsoft's GitHub coding tools for most bankers and traders, while engineers retained access. The directive reportedly did not apply to "strats," whose work spans trading, quantitative research, and software engineering. Goldman said it experiments with tools across the firm and considers factors including productivity and risk management before deciding who is best suited to use them longer term.

The lesson is not "copy Goldman."

The lesson is that AI access can be role-based instead of universal.

1. Match the Tool to the Job

The first question should not be:

Who wants access?

Ask:

What does this role actually need to accomplish?

An engineer may reasonably need an agent that can inspect a repository, generate tests, modify files, or prepare a pull request.

Someone in another department may get more value from an assistant that can summarize documents, draft content, or analyze approved information.

Those are both legitimate AI use cases.

They do not require identical permissions.

I would think of access as four levels:

1. No access
2. Assistant only
3. Tool with human approval
4. Tool with bounded autonomy

The mistake is treating the most powerful tier as the default.

1. Classify Tools by What They Can Do

"AI tool" is becoming too broad a category.

Compare these two systems:

Tool A:

• suggests code
• cannot read repository
• cannot execute commands

Tool B:

• reads repository
• edits multiple files
• runs commands
• opens pull requests

Calling both "coding assistants" hides the important difference.

I prefer thinking in capabilities:

READ What can it see?
WRITE What can it change?
EXECUTE What can it run?
DEPLOY Can it affect production?
TRANSACT Can it trigger business actions?

Each step increases the control requirements.

A tool that generates a function inside an IDE is one thing.

An agent with credentials, terminal access, and deployment permissions is another.

1. Require Someone Who Can Verify the Output

This is where broad access becomes uncomfortable.

AI can let someone generate code they could not have written independently.

That does not mean they can evaluate it independently.

Generated code can look perfectly reasonable while containing:

incorrect authorization logic

insecure input handling

unnecessary dependencies

inefficient queries

race conditions

poor error handling

architectural mismatches

For production-impacting work, I want someone involved who can recognize those problems.

A simple rule:

Impact ↑ => Review requirement ↑

That does not mean non-developers should never experiment with code.

It means experimentation should not automatically grant production authority.

If someone cannot meaningfully review what the agent creates, another qualified person should.

1. Separate Experiments From Production

Companies often jump between two extremes:

BAN AI

or:

ENABLE FOR EVERYONE

There is a much better middle ground.

Run a controlled pilot.

A reasonable path looks like:

Sandbox
↓
Limited repository
↓
Human-reviewed changes
↓
Controlled production use

During the pilot, measure actual work rather than enthusiasm.

Ask:

Did total completion time improve?

Did review time increase?

Did defects or rework change?

Which tasks benefited?

Which tasks became harder?

What did the tool cost?

Did unexpected data-access issues appear?

A demo proves that something can work.

A pilot tells you whether it belongs in your operating environment.

1. Put Data Boundaries in Writing

Most AI security problems do not require malicious employees.

A normal employee can accidentally paste the wrong information into the wrong tool.

That is why "use common sense" is a weak AI policy.

At minimum, employees should know how the company treats:

customer data
credentials
API keys
private source code
financial records
internal documents
regulated information
production data

Then support policy with technical controls where possible:

SSO
role-based permissions
approved integrations
repository restrictions
secret scanning
audit logs
revocable access

The policy should tell people what is allowed.

The architecture should make the dangerous path harder.

1. Reapprove Tools When Their Capabilities Change

This may become the most important governance habit.

AI products evolve quickly.

A tool approved six months ago as autocomplete may later gain:

repository-wide context
file modification
command execution
browser access
pull request creation
external integrations
agentic workflows

Same product.

Different risk.

So instead of approving:

"Product X is allowed."

approve something closer to:

Product X:

• repository read access: allowed
• code suggestions: allowed
• file edits: allowed with review
• shell execution: blocked
• production credentials: blocked
• merge/deploy: human approval required

Now the approval describes the actual capability.

When capabilities change, revisit it.

Typical / Indicative Governance Priority

1. Role fit ████████░░ High
2. Capability ██████████ Very High
3. Verification ██████████ Very High
4. Pilot boundary █████████░ High
5. Data controls ██████████ Very High
6. Reapproval ████████░░ High

Typical / indicative only. My rough read is that capability, verification, and data access deserve more attention than simply deciding whether a product is "approved."

A Practical AI Access Checklist

Before approving a coding tool, I would ask:

[ ] What job requires it?
[ ] What data can it read?
[ ] What systems can it modify?
[ ] Can it execute commands?
[ ] Can it reach production?
[ ] Who verifies its output?
[ ] What requires human approval?
[ ] Are actions logged?
[ ] Can access be revoked quickly?
[ ] What is the worst plausible mistake?
[ ] What will success be measured against?

And measure productivity honestly.

Do not compare:

time to generate code

with:

time to write code manually

Compare:

generate

• review
• test
• correct
• rework

against the complete manual workflow.

A tool that generates code in seconds but creates an hour of cleanup has not necessarily improved productivity.

How KSoft Technologies Helps With Responsible AI Adoption

KSoft Technologies is our own software engineering company. We help teams evaluate AI-assisted development and automation in the context of their existing architecture, permissions, integrations, review processes, and data boundaries rather than treating the tool as an isolated purchase.

The question I would ask every technical leader is:

Which person needs which capability, against which systems, with what review?

That produces a much better policy than either "everyone gets AI" or "nobody gets AI."

I wrote the longer version here: Who Should Get AI Coding Tools at Work?.