Deep research on FHIR, and whether specs are just waterfall — Feb 19, 2026
Deep research agent over FHIR sources
Nikolai showed a deep research agent built over FHIR sources: the Zulip chat, Jira, implementation guides and the spec, all indexed for retrieval. A planner agent works out what to search, a fan-out of agents judges each hit for relevance, and a final agent writes the report with quotes back to the source.
The point isn't the workflow — it's that grounding answers in real discussions produces less hallucination than asking the model what it remembers.
The next step is a knowledge graph over the FHIR domain — resources, elements, working groups, and the links between them — so the agent has a conceptual backbone to reason over rather than a pile of text. Someone pushed on provenance with a good example: whether implementers really honour the identifier length constraint has different answers scattered across Jira and Zulip, and some are stale. The proposed fix is to make time and version first-class, so the graph can tell an answer from a working group co-chair last month apart from an answer from five years ago.
Why the barrier to FHIR participation is now too high for humans
The background you need to meaningfully participate in FHIR now is so high that people just give up before they start. Nobody can hold dozens of working groups in their head, so work gets duplicated and good ideas get lost — the kind of at-scale reading that would fix it is impossible for a human and cheap for an agent.
Spec-driven development — waterfall striking back?
A long argument about spec-driven development (OpenSpec, Spec Kit).
The case for: it's a communication artefact several people can look at and agree on, and it's automated BDD — the thing that never actually worked in practice.
The case against: if you know the codebase and can jump from A to Z, the ceremony has no ROI; you're now duplicating requirements across spec, tests and code; and a counterpoint from the Claude Code side is that tokens spent generating specs are better spent generating code and iterating on it.
This is waterfall striking back three decades after agile won.
PHR field report — specs rot during implementation
Alexander reported the failure mode from building a PHR this way: specs are genuinely useful for the design phase, but during implementation you fix bugs and forget to go back and update them, so they rot. He ends up asking the agent to read the code and rewrite the spec to match.
At which point the spec was all for nothing and the code is the source of truth.
On reading generated code: production work is still fully human-reviewed, but on experiments some of the group never open the code at all — it depends on the risk, how conventional the problem is, and whether it's well enough encapsulated that you could understand it later if it broke.