Antoine documents how Claude Code, with no medical imaging library installed, wrote its own pydicom-driven parser, decoded pixel arrays, normalized window/level, rendered volumetric slices as PNGs, and then switched modalities to inspect them via vision. His emphasis is on the agent's autonomous tool-assembly — uploading files and typing a sentence replaced what used to be a multi-step manual workflow involving DICOM viewers, per-slice API calls, and human stitching.
By submitting Antoine's post to HN where it climbed to 406 points, the submitter signaled that the engineering substrate — a general coding agent bootstrapping a DICOM pipeline on its own — was the headline, not the radiology result. The framing prioritizes the agent's capability over the clinical use case.
The editorial explicitly cautions that dozens of FDA-cleared radiology products exist that are more specialized, more validated, and far less prone to hallucination than a general LLM. Handing the same MRI to a cleared lumbar-spine detector would yield a more defensible answer — the novelty is workflow assembly, not diagnostic superiority.
A French developer who goes by Antoine published a walkthrough of feeding his own lumbar MRI — raw DICOM files, not screenshots — to Claude Code running Opus, and asking for a second opinion on the radiologist's reading. The post is sitting at 406 on Hacker News and still climbing.
The medical outcome is mildly interesting. The engineering substrate is the actual story. Claude Code had no medical imaging library installed. It wrote one — a pydicom-driven parser that walked the DICOM directory tree, decoded the pixel arrays, normalized window/level, and rendered the volumetric stack as PNGs. It then switched modalities, loading the rendered slices back as images for vision-mode inspection. It paged through more than 200 slices to localize the L4–L5 region the radiologist had flagged, then produced a structured report that materially extended the original reading.
No specialist medical model. No FDA-cleared pipeline. A general coding agent with pip access, a Python interpreter, and a vision head.
It is worth being precise about what is and isn't new here, because the hot-take version of this story is wrong in both directions.
What is *not* new: vision models reasoning about medical images. There are dozens of FDA-cleared products in radiology AI. They are more specialized, more validated, and far less likely to hallucinate than a general LLM. If you handed this exact MRI to RadNet's stack or any of the cleared lumbar-spine detectors, you would get a more defensible answer.
What *is* new: a general-purpose agent assembling the domain-specific toolchain on its own, in one session, without being asked to. Three years ago this workflow required a DICOM viewer, a manual export to PNG, a separate vision API call per slice, and a human stitching the per-slice analyses back into a coherent reading. Antoine uploaded files and typed a sentence. The agent did the rest, including the part where it decided it needed to write a renderer at all.
This is the capability inflection that has been gestured at for two years and is now showing up in casual blog posts. It isn't "can the model reason about X" — for almost any X with public documentation, the answer has been yes for a while. It's "can the model stand up the tooling it needs to *get at* X in a format it can reason about." pydicom is a fifteen-year-old library. The novelty is that Claude figured out it needed pydicom, installed it, used it correctly, and pivoted to vision mode when its text-based introspection plateaued.
The HN comment thread splits cleanly along professional lines and both sides are right. The doctors — and there are several in the thread, identifying themselves — are warning specifically about hallucination risk in radiology, where a confidently-stated false negative is the worst possible failure mode and a generalist model has no calibration for the prior probability of any given finding. The engineers are pointing out that the workflow Antoine describes is the workflow they are now using on every domain they touch: legacy binary formats, vendor-specific log files, weird industrial telemetry. Both observations are compatible. The agentic toolchain is genuinely capable, and it is genuinely dangerous to use in regulated, high-stakes settings where a wrong answer doesn't surface until months later.
The hard internal question, if you build tooling for a living: which of your team's "we need a custom app for this" use cases were actually "we need a coding agent with file access"?
The DICOM viewer market is in the billions. Most of those viewers are bad — slow, licensed per-seat, UI patterns from 2008. A coding agent with pydicom and a vision model is not a replacement for diagnostic radiology software. But it absolutely is a replacement for the half-dozen ad-hoc internal scripts every imaging team has accumulated to do one-off analyses, format conversions, anonymization sweeps, and quality audits. Those scripts have a maintainer. That maintainer's job description is changing.
Generalize the pattern. Any internal tool whose job is "open this proprietary format, do something quick, write a report" is now structurally one prompt away from being commodified. CAD inspection. Sensor dumps from an industrial controller. Legacy ERP exports in fixed-width columns. Game telemetry in custom protobuf variants. The moat around "viewer for format X" thinned overnight. The moat around "trusted opinion about format X in a context where being wrong has consequences" did not move at all.
The practical takeaway is to draw the line clearly. Internal exploratory tooling is fair game for the agent — let it write the parser, run the analysis, hand you the chart. External-facing tooling, anything that produces a written conclusion a customer or a regulator will rely on, still needs the specialized stack, the validation suite, and the human in the loop. The failure mode of agentic exploration is wasted time. The failure mode of agentic diagnosis is a missed cancer.
Patients are going to keep doing this regardless of what the AMA or your hospital's IT department thinks about it, and the second-opinion use case will quietly become routine within twelve months. The more interesting question for builders is whether the tools you ship — for any data domain you own — can credibly outcompete the agent that writes itself in ninety seconds. If the answer is no, the value you're shipping isn't the tool. It's the trust, the validation, and the accountability around the answer. Price accordingly.
A few years ago (before the AI craze), I was misdiagnosed with tuberculosis. I had a chronic cough, and an outsourced radiologist at a clinic found signs of tuberculosis. The findings were sent to the city's tuberculosis hospital, as required by the country's law. The doctors there took th
Radiologist. I don’t read MR shoulder exams in my day to day practice, but from the few pictures shown , I can’t conclusively disagree with the original report.These models are generally terrible at reading medical images. The amount of public training data on the internet compared to the number of
I'm a radiologist but can't really weigh in without seeing the full 3D MRI dataset. Regarding this point:> They performed shockwave therapy on my shoulder even though a recent clinical practice guideline says clinicians should not use or recommend shockwave therapy for rotator-cuff tend
It funny to see the community here expects the human body to be treated like a deterministic function: for input X expect output Y - and that transfers to diagnosis - people expect to receive the same diagnosis from different specialists for the same issue.Given human body complexity, the diagnosis
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> There's something incredibly peaceful about being in the hands of an expert you trust. [...] AI can absolutely shatter that feeling in an uncomfortable way [...] but I don't know if I can fully trust AI either.This really is key. We know we can't trust the AI, but at the same tim