After six months of broad access and the committee debate described in part 1, Fynbos Capital Bank, a fictional South African bank, published an interim coding-assistant rule while it redesigned access around entitlements. The rule was clean: technology staff may use it, everyone else may not. Within a week the exceptions queue held forty requests. A quantitative analyst on the rates desk who maintained the desk's pricing scripts. An actuarial analyst in the insurance subsidiary who built reserving models in Python. A credit portfolio analyst who wrote the SQL behind a monthly risk pack that went to the board risk committee. A treasury dealer who had taught himself enough code to automate a liquidity report.
None of them was an engineer. All of them wrote code as part of their job, and some of them wrote code that the bank depended on. The rule drew its line through the middle of them.
Everything about Fynbos, its people and its systems is invented. The problem is not.
Why titles fail
Bloomberg reported on 2 November 2026 that Goldman Sachs had limited advanced AI coding tools to engineers under updated internal guidance, and that the directive did not apply to "strats", staff who work across trading, quantitative research and software engineering. Whatever the bank's internal reasoning, which we do not know beyond the report, the exemption illustrates the problem this article is about: a role-based rule needed a named exception for people whose work does not fit a role category.
Titles are a poor proxy for AI entitlements because they describe a position in an organisation chart, not the work. Two people called "analyst" may do completely different things: one reads reports, the other maintains a model that prices transactions. AI roles: read the verbs, not the title makes the same argument for hiring. For access, the verb that matters most is not "writes code". It is "ships something other people rely on".
Decide by where the output goes
Fynbos replaced the title rule with a ladder based on the destination of the work. The question is not who the person is, but where the thing they build ends up.
Level 1: personal analysis. Code and outputs used only by the person who wrote them, to inform their own work. A one-off query, an exploratory notebook, a chart for a meeting. If it is wrong, the person usually finds out and the harm stays local.
Level 2: team tool. Something colleagues reuse: a shared notebook, a macro, a small script the desk runs every morning. If it is wrong, several people are wrong in the same way, often without knowing it.
Level 3: business-critical tool. Something a decision, a customer or a regulatory output depends on: the SQL behind the board risk pack, a reserving model, a pricing script whose numbers reach a client. Most banks already have an end-user computing policy for spreadsheets and models of this kind, with an inventory, an owner and periodic review. The policy rarely anticipated that the tools would be written with an agent.
Level 4: production system. Something that runs as part of the bank's systems: scheduled, integrated, holding credentials, writing to systems of record.
Each level changes what is needed, independent of the person's title.
What each level requires
| Level | Environment | Data | Review | Ownership |
|---|---|---|---|---|
| 1. Personal analysis | Tier A sandbox or analytics workspace | Masked or curated data products | The person | The person |
| 2. Team tool | Tier A sandbox with a version-controlled shared repository | As level 1, with data class recorded | A peer reads it before the team relies on it | Named owner in the team |
| 3. Business-critical tool | Registered workspace; changes tracked | Production data through governed read paths | Independent review and test evidence before each material change | Business owner, registered in the end-user computing inventory |
| 4. Production system | Delivery pipeline only (tier C from part 3) | Through service identities, never personal credentials | Engineering review and the normal change process | Engineering team, with the business owner as product owner |
Tier A, from part 3, includes access to version-controlled shared repositories for team work; what it excludes is production data and production credentials. The table makes something clear that a title rule hides: most hybrid builders spend most of their time at levels 1 and 2, where the risk is modest and an AI coding assistant in a sandbox is exactly the right tool. The danger is not that they use the assistant. It is that a level 2 tool quietly becomes a level 3 or 4 tool without anyone noticing it crossed a line.
The crossings are the control points
Fynbos therefore put its controls at the crossings, not at the door.
Crossing from 2 to 3. When a team tool starts feeding a decision, a customer or a regulatory output, it must be registered in the end-user computing inventory. Registration names a business owner, records the data it uses, and requires test evidence and an independent review. The AI coding assistant can help write those tests. It cannot be the reviewer.
Crossing from 3 to 4. When a business-critical tool needs to run unattended, integrate with other systems or hold credentials, it moves into engineering. The hybrid builder does not lose it. They become the product owner and remain the person who understands what it should do, while an engineering team owns how it runs. The pull request from the analyst's sandbox to the engineering repository is the handover point, and the engineering reviewer is the acceptance authority for it.
The pairing at that crossing is where hybrid roles add the most value and where the most goes wrong. Done badly, engineers receive a tool they did not design, with no tests, and are asked to make it production-grade by Friday. Done well, the analyst has been working in a sandbox with version control and tests from the start, and the handover is a review, not a rescue.
The four Fynbos cases
Applying the ladder to the forty requests took two weeks. A few examples:
- The rates desk quant. The pricing scripts were level 3: their outputs reached client quotes. He was entitled to the tier A coding sandbox for development, the scripts were registered with the desk head as business owner, and every material change now went through independent review with test evidence. Two scripts that ran on a schedule from his workstation were moved to level 4 and taken into the markets technology team's pipeline.
- The actuarial analyst. The reserving models were level 3 and already in the subsidiary's model inventory. The only change was entitlement to the sandbox and a requirement that the assistant's sessions on those models were logged, which part 7 covers.
- The credit portfolio analyst. The board risk pack was level 3, but nobody had registered it. Registration came first, then entitlement.
- The treasury dealer. The liquidity report automation was level 2 in his view and level 4 in reality: it ran nightly and wrote to a shared folder that another system read. It was paused, handed to engineering, and rebuilt in the pipeline with him as product owner. He was entitled to the sandbox for further work.
No one was refused outright. Several people received less than they had asked for, and every one of them got an explanation tied to the destination of their work rather than their title.
Where the model breaks down
The ladder is simple to describe and harder to run. Fynbos found three recurring failure modes in its first quarter.
Self-classification drifts downwards. People placed their own tools one level lower than they were, usually in good faith. The liquidity report in the treasury case was the clearest example. Fynbos now asks one extra question at registration, "does anything run this without you?", because unattended running is the most reliable sign of level 4.
Engineering capacity becomes the bottleneck. If every level 4 crossing waits months for an engineering team, builders keep tools at level 3 longer than they should, or stop declaring them. Fynbos set aside a small, fixed share of the markets technology team's capacity for handovers, and publishes the queue.
Review becomes a signature. Independent review at level 3 only works if the reviewer can read the code and the tests. A line manager signing a form is not review. Fynbos pairs each business unit with a named reviewer from a pool of experienced builders and engineers.
Competence is evidence, not attendance
An entitlement at levels 2 and above also asks a question about the person: can they work safely with an agent that writes and runs code? Fynbos does not answer that with course attendance. Applicants for level 3 work complete a short practical task in the sandbox: take a small, deliberately flawed script, use the assistant to fix it, write tests that would have caught the flaw, and explain the change. An engineer reviews the result in twenty minutes.
This mirrors the argument in Hire on evidence: what someone can show in the work is better evidence than a certificate. It also gives hybrid builders a visible path to more access, which matters for part 8 of this series.
Key points
- Hybrid roles write code that others rely on, but they are not engineers. A title-based rule splits them arbitrarily.
- Base entitlements on where the output goes: personal analysis, team tool, business-critical tool or production system.
- Most hybrid work sits at levels 1 and 2, where a sandboxed coding assistant is the right tool and the risk is modest.
- Put controls at the crossings: registration and independent review from 2 to 3, engineering ownership through the pipeline from 3 to 4.
- Test competence with a short practical task, and give hybrid builders a visible path to wider access.
Next: Part 6, From pilot access to durable entitlement. All parts are on the series page. For the delivery system around the assistant, see Coding agents are tools inside a delivery system.
How CloudNala can help
CloudNala helps regulated organisations design access for hybrid builders. We classify existing tools by output destination, connect the result to your end-user computing inventory, design the crossing controls and the handover into engineering, and set up a practical competence check, so that analysts and quants can keep building without their tools drifting into production unseen.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Access Review or write to us at consult@cloudnala.co.za