Nikolai's self-evolving agent harness, Termbox meets Pathling, and EHR as an IDE — Aug 18, 2026
Nikolai's self-evolving harness — 500 functions, agent forks, no closed tools
Nikolai spent the week building his own agent harness instead of switching back to Claude Code or Codex, and reported the experiment was working well enough to keep. The design is deliberately minimal: close to raw Python plus one magic tool — evalTypeScript. Rather than a large set of formal tools, the harness relies on a catalog of ~500 functions indexed in a database at startup. The agent can search inside that catalog, invoke functions, and even write new ones — which makes the setup self-evolving. Web search, for example, is just a function that drives Chrome through CDP; it never needed to be a first-class tool.
The core loop is structured around three first-class objects: goal, plan, and principles. A plan is a structured to-do list; if the agent stops with tasks unfinished, the harness injects a prompt telling it to continue. When the agent declares a goal complete, a forked copy asks whether the goal was actually met, and loops if not. Forking is the piece Nikolai considers the most valuable primitive — because of LLM caching, a fork tool spins up multiple agents that share the same context essentially for free, which turns any research step into parallel sub-work.
Now they trained the LLM. So it understands that if you just give it three, five tools, it's working exactly like you're inside Codex or Claude. And then you can start tweaking the whole pipeline, the whole loop — create memory, create whatever you want because you're inside. It's not a black box.
John still uses a spec or plan artifact for multi-session work — not as up-front scope but as persistent state across sessions — and agreed the up-front spec has become optional. His main objection to Claude Code is the same shape as his objection to Visual Studio or IntelliJ: closed-source blobs aren't a foundation you can build a workflow on top of.
The main problem with Claude Code is that it's just a closed-source blob. You can't hack it, you can't understand it, and it's not really a good basis to build your whole workflow off.
Codex vs Opus, and the coming wave of harness engineering
Nikolai has switched from Claude Opus to Codex — recent Opus changes made it too aggressive in his read, firing off tool calls before understanding what's actually going on, while Codex 5.6 has a better balance between asking and acting. He's also been testing Kimi, the Chinese model, and rates it as still behind Claude for agentic dev work but closing the gap.
OpenAI's announcement of ChatGPT 5.6 running at 14x current speed (currently API-preview only) came up as the more interesting near-term signal — if inference gets fast enough, the human becomes the bottleneck. John pushed that further, pointing at application-specific silicon: AMD's recent acquisition in that space, Google's related investments, and the idea of burning a specific model to a chip that mass-produces at roughly 100x current speeds.
Yeah, then you will be the limiting circuit.
Both John and Nikolai see harness engineering as the next big lever — memory, sub-agent management, swarm coordination — and closed tools as a block on innovation there.
Building software with AI — Bun, landing pages, and Salesforce for $500K a year
Steve's team just used the AIDLC framework (aidlc.guru, from AWS) to produce a full working EMR prototype for a non-US RFP, generating a large volume of working code. Nikolai pointed at the Bun rewrite as another proof point: fully agent-rewritten in about a week, passed the existing test suite, and shipped to production without seg faults. His own team rebuilt the Health Samurai landing page in roughly two months with half an engineer plus a designer and a marketing lead — replacing Webflow, a CMS, and GitBook. Since dev can now clone, write, and push, blog output has tripled.
Steve's counterweight was that the agent-with-known-truth story works cleanly — a full test suite, a spec — but hits a human bottleneck fast when requirements are still being discovered. John's response was that iteration speed is the unlock for the fuzzy-requirements case: a tactile prototype in your hand within a minute lets you zero in on what you actually want before committing to a build. Nikolai extended the argument to enterprise SaaS — a company paying roughly $500K a year for Salesforce that vibe-coded a replacement in two months — and predicted Epic-scale incumbents are similarly exposed.
EHR as an IDE, and where clinical decision support actually lives
Nikolai's framing: most EHRs today are administrative machines with almost no decision support — text areas and forms — and the real clinical value should live at the back end as checks, not in the UI. He described a past LA-hospital project where a small team built exactly what the physicians asked for; years after the system was retired, physicians still logged into it just for the timeline, documents, and summaries, in preference to Epic. His concept for the future is a headless FHIR server with a plugin ecosystem — every physician or vendor can install or build UI plugins, with clinical guardrails enforced in the back-end layer.
John's pushback was on the governance side. Unwarranted clinical variation is a known harm; the sort of plugin-picking Nikolai described puts more power in clinicians' hands to modulate care outside evidence-based lanes. He described Queensland's single-instance Cerner Millennium setup as the opposite extreme — 16 hospital districts sharing one schema, economies of scale and consistency, but effectively frozen because any change requires sign-off from roughly 100 stakeholders.
You've got to basically get sign-off from a list of about a hundred people just to change some screen. So it basically can't ever be changed.
Steve added the clinical-decision-support angle: most CDS alerts get ignored — clinicians avoid them at close to 100% — and the only shot at changing that is if the clinicians have a real stake in how the tools are built.
Most clinical decision support systems don't get used. Doctors avoid them completely, to the degree of 90-100%. The trick is if they can build it — if they have some stake in how it works.
Nikolai connected that back to a German group he's working with on "care as continuous research": real-time cohort views alongside individual patient care, so a clinician sees the pathways and outcomes of similar patients while treating the one in front of them. John's take was that clinicians reason from similar cases more naturally than from abstract probabilities, and imagined a sophisticated interface for exploring similar-case cohorts overlaid with population-health stats.
Relational terminology schema — Termbox meets Pathling meets Athena
The one concrete near-term thread was terminology. John loaded the entire Athena dataset — around 10 million concepts — as a single FHIR CodeSystem in Ontoserver, which required custom unblocking of unbounded resource size and streaming imports. Pathling ships a local terminology system with roughly eight tables (concept, description, property, relationship, closure, value-set expansion, and so on). Nikolai's Termbox is fully relational and inspired by the same Athena shape with a handful of optimizations. The three implementations have quietly converged on nearly the same schema.
If you're thinking Athena way about FHIR, you're getting almost to the same schema.
Open design questions surfaced but weren't resolved: whether property and relationship belong in separate tables (John was unsure, Nikolai argued FHIR's extra concept properties push toward a distinct property table), and how the closure table should be handled. Both agreed the schema should target roughly 80% of analytic use cases rather than full semantic parity with FHIR — SNOMED CT post-coordination and similar edge cases are technically representable in FHIR but practically unused in analytics. John's guardrail is to piggyback on FHIR terminology semantics rather than invent new ones, to avoid ending up with "a THO for SQL on FHIR". Nikolai's Grahame-terminology-test-suite pass rate on the relational implementation currently sits around 70%.
The dependency chain that motivates John here is his FHIR-to-OMOP work — today it depends on Athena's schema, and he'd prefer to depend on a shared open one instead.
Terminology distribution and licensing — the real Athena moat
Steve raised the harder half of the problem: the technical aggregation of terminologies is doable; the licensing negotiation with the publishers is not. Athena's value is largely in the paperwork it's done with multiple licensors. Some terminologies are moving toward open (SNOMED CT); others (CPT and similar) will likely never fully open and carry complicated obligation webs.
The hard part that Athena has delivered is a lot of it is in the licensing part. They've brought together a bunch of licensed terminologies in a single place and negotiated agreements with different parties.
Nikolai flagged Athena's CPT self-certify checkbox as a gray area legally. He also connected the thread back to Babylon — an internal Health Samurai project originally scoped to tackle pragmatic terminology distribution, publishing open code systems in FHIR format similar to Athena, with the loading scripts and relational model shared openly. Steve raised Gidna (a FHIR-based terminology server from the Vulkan team, on a fhir.org domain that isn't officially HL7-affiliated) as a parallel effort; Nikolai mentioned it had been loaded with Athena data during a recent connectathon and John had compared results with his own implementation.
Next step: send a message to the SQL on FHIR group to gauge interest, set up a dedicated call with a demo from John, and possibly invite Grahame Grieve.