Who this is for: anyone wondering "how can you trust software that an AI helped write?" — no technical background needed. Especially relevant if you work in governance, policy, ethics, clinical practice, or research.
🤖 Want the full technical version? See Deterministic Agentic AI Development with Claude Code on GitHub. 🔧 Companion guide: How We Build This Software.
An AI assistant is fast, tireless, and has "read" an enormous amount — but it is also unpredictable and can be confidently wrong. So we treat it like a talented new intern: give it a clear handbook, limited keys, and put its work through the same automatic checks every human's work goes through.
The AI provides speed and breadth. The surrounding rules and checks provide trust. Neither is enough on its own.
Picture a brilliant intern on their first week:
- They've read more than anyone, and they work incredibly fast.
- They'll happily attempt anything you ask.
- But they don't know your house rules yet, they sometimes state wrong things with great confidence, and occasionally they invent a detail that sounds plausible but isn't true. (In AI terms this is called a hallucination.)
- And asked the same question twice, they might answer slightly differently each time. (AI is non-deterministic — there's no single fixed answer.)
You wouldn't hand that intern the keys to the safe and let them publish to the public unsupervised. You'd give them a handbook, let them draft work, and check it. That is exactly how the AI is used here.
-
A handbook the AI reads every time. A file called
CLAUDE.mdplus a set of rules describe this project's conventions, the do's and don'ts, and the traps to avoid. The AI reads them at the start of every session, so it follows house style instead of guessing. -
Limited keys (it can look, but not unilaterally act). The AI is allowed to read files, build, and run tests freely — the harmless, useful things. Anything risky (publishing, deleting, deploying) needs a human's go-ahead. Like an intern with a reading-room pass but no key to the archive.
-
Specialist "reviewer" personas. For tricky areas, the project can summon focused reviewers — a security reviewer, a compliance reviewer, a testing reviewer. Crucially, these can only look and advise — they cannot change anything. A wrong opinion is cheap; a wrong edit is not.
-
The exact same checkpoints as a human. Whatever the AI produces must pass the identical automatic checks described in the building guide — tidiness, tests, security and privacy scans, the lot. The gate doesn't care whether a human or an AI wrote the change; the checks decide what ships, not the author.
-
A clear paper trail. Every change the AI helps with is labelled as AI-assisted in the project's permanent history, so it's always clear what the machine touched — essential for accountability in a health-data setting.
Here is the idea most worth taking away — and it's where non-technical experts matter most:
An AI is only ever as good as the instructions it's given. When a domain or governance expert sharpens a written rule, corrects a diagram, or describes a requirement precisely, that correction becomes permanent input the AI obeys in every future session.
So "correcting the AI" is not a chore at the margins — it's the highest-impact contribution to the whole system. A clearer requirement from a policy or clinical expert raises the quality of everything the AI produces next. The human expert is the steering wheel; the AI is the engine.
You (expert) ─ write a clearer rule / requirement ─▶ the handbook
▲ │
│ the AI reads it
│ ▼
review & critique ◀── the result is checked ◀── the AI proposes a change
This loop — expert improves the brief, AI produces better work, checks verify it, expert reviews — is the real method behind "using AI well."
| Where the AI shines | Where it needs the guard-rails | How that's handled |
|---|---|---|
| Doing broad, repetitive work quickly | Sounding confident while being wrong | Automatic tests & checks catch it |
| Applying the house style consistently | Drifting away from the original intent | Decision records first; small, reviewable changes |
| Wiring up tedious safety scaffolding | Inventing things that aren't real | "Base everything on what's actually here — don't invent" |
| Never skipping a checklist step | Doing too much / over-engineering | A human trims the scope before it's accepted |
The pattern throughout: the AI handles breadth; automatic checks and human judgement handle correctness.
In a regulated field like the European Health Data Space, you must be able to trust and audit every change — including AI-assisted ones. The approach here means:
- No AI change bypasses the safety and privacy checks.
- Every AI contribution is logged and attributable.
- A human — ideally a domain expert — remains the final decision-maker.
AI is used to go faster and broader, never to remove the human from the loop.
- AI assistant / agent — software that can carry out multi-step tasks on instruction (here: Claude Code).
- LLM (large language model) — the kind of AI behind it, trained on vast text to predict helpful responses.
- Non-deterministic — won't always give the identical answer twice.
- Hallucination — when an AI states something false but plausible-sounding.
- Prompt — the instruction you give the AI.
- Guard-rail — a rule or check that constrains what the AI can do.
- Human-in-the-loop — keeping a person in control of key decisions.
- Claude Code — overview and on GitHub — the AI tool used here
- Building Effective AI Agents — Anthropic (accessible, principles-first)
- What is a large language model? — Wikipedia
- AI "hallucination" — Wikipedia
- Human-in-the-loop — Wikipedia
- Model Context Protocol — how AI tools connect to live data sources
- European Health Data Space (EHDS) Regulation — European Commission
- 🤖 Full technical version: docs/AGENTIC-DEVELOPMENT-WITH-CLAUDE-CODE.md
- 🔧 Companion plain-language guide: How We Build This Software