FHIR as the guardrail against agent drift, and can clinicians vibe-code their own apps? — May 28, 2026
The problem statement — agents drift
Aleksandr's problem statement will be familiar to anyone doing long-running agentic coding: agents drift. They invent slightly different data models and slightly different implementations of the same feature every session, the schema grows fields nobody needs, and there's nothing to check the result against beyond does it compile. Generic frameworks can't help because they know nothing about healthcare.
FHIR arrives with 150+ resources, a validation framework, terminology and structured data capture already decided.
Generated types are the single biggest lever
Typed classes generated from StructureDefinitions rather than hand-written interfaces. Without them the agent invents a couple of interfaces that then spread inconsistently across front end and back end; with them it never misses.
The other tell that grounding works: ask for a patient summary feature and the agent reaches for Composition unprompted, because it already knows the model.
The pushback from the integration side
FHIR has conformance testing and yet the variability across EHRs is enormous. Workflow tooling — tasks, messaging — almost always turns out to be some proprietary API even where a perfectly good FHIR structure exists.
A lot of FHIR's ambiguity is essential, not accidental. The same clinical concept can legitimately be an Observation, a Condition or a Flag depending on context, and no single answer exists. What the spec gives you is a decade of argument to draw on — whatever an engineer would hallucinate, an LLM will hallucinate too, and both hallucinate less when grounded in the same knowledge base.
The open question — can we take engineers out of the loop?
If the guardrails are good enough — skills, templates, components, SDKs — could you take engineers out of the loop entirely and let doctors build their own apps?
That's a different risk from the one FHIR solves. If a clinician vibe-codes a risk score wrong, the resource still validates perfectly — the score is just wrong. Validation and evaluation are separate problems, and only one of them has tooling.
IG Gen — an agent per modelling stage
Ward demoed IG Gen, which breaks FHIR data modelling into seven stages — use case, logical model, map to resources, quality control, document, publish, collect feedback — and puts an agent on each stage rather than one agent on the whole job. A companion skill from Firely closes a gap in the earlier FHIR skills, which could generate resources but had no validator to run them through, so the loop never closed.
I expect hand-writing FSH to feel antiquated within about six months, with humans reviewing agent output instead.
That led into Arjun's request to the community: rebuild IG publishing agent-first, as small single-purpose composable tools rather than a monolith, on the argument that agents are good at bash precisely because it's a composable toolset they already understand.