Claude Code Beyond Coding: Lessons From an AI MRI Analysis

Most of us think of Claude Code as a coding tool — a CLI agent that edits files, runs tests, and ships pull requests. But the same properties that make it good at code (it can run arbitrary commands, install dependencies, write scripts, and coordinate its own subagents) make it a surprisingly general analytical engine. A recent and slightly jaw-dropping example: a developer used Claude Code to produce a second opinion on his own shoulder MRI. The story is worth unpacking not for the medical claims — which deserve heavy skepticism — but for what it reveals about agentic workflows on messy, real-world data.

The problem: a diagnosis worth double-checking

In his write-up, developer Antoine described getting a concerning read from an orthopedist: a Grade III partial-thickness tear of the subscapularis tendon, with a fairly intervention-heavy treatment path. Wanting a second perspective, he did something most patients cannot: he exported the raw MRI as a DICOM package — several hundred files, 266 MB, no file extensions — and handed the whole folder to Claude Code running on the Opus model.

That starting point is the interesting part. This was not a clean dataset or a tidy API. It was a pile of unlabeled binary medical files in a format most people have never heard of. The task was open-ended: “figure out what is in here and tell me what you see.” That is precisely the kind of ambiguous, tool-heavy problem that a chat interface struggles with and an agent thrives on. A chat model would have to ask you to convert the files, paste in text it can read, or describe what you are seeing — pushing all the hard, fiddly work back onto you. An agent with a shell can simply do the fiddly work itself: detect the format, find a library, write the extraction code, and look at the result. The friction of getting messy real-world data into a form the model can reason about is exactly the friction agentic tools remove.

Why an agent, not a chatbot

The key instruction was deceptively small: he told Claude to “install any packages it might need.” That permission is what separates an agent from a chat assistant. Claude Code could reach for DICOM-parsing libraries, write Python to extract pixel data, render slices, and iterate — all autonomously. The author called this capability “enormous” compared to the standard Claude.ai chat experience, and he is right. A chatbot can describe how to parse a DICOM file; an agent actually does it, sees the output, and adjusts.

This is the mental shift builders should take away. When your problem involves unknown data formats, multi-step processing, and the need to verify intermediate results, you do not want a model that returns text — you want a model with a shell. The loop of plan, execute, observe, correct is where agentic tools earn their keep, and it generalizes far beyond writing application code.

The workflow: two reads and an arbitration

What the author did next is the genuinely instructive bit, because it mirrors good engineering practice. He did not trust a single pass. The workflow had three stages:

• A first independent analysis — given only minimal context (“right shoulder pain for 2–3 weeks”), Claude drew up an analysis plan, processed the imaging over roughly an hour, and produced a full PDF report. Its conclusion contradicted the radiologist: the subscapularis tendon looked intact.
• A separate, blind context — supplementary findings from a physical-exam discussion were gathered independently so they would not bias the imaging read.
• An arbitration pass — Claude was then given both the human report and its own report and asked to adjudicate, using multiple subagents structured specifically to avoid anchoring on the prior analysis. After another hour, it favored the “no discrete tear, mild insertional tendinosis” reading at moderate-to-high confidence.

Strip away the medical context and this is just a well-designed verification harness: independent analyses, isolation to prevent bias, and a separate adjudication step. It is the same pattern you would use to cross-check a risky refactor or to grade two competing implementations — and it is a pattern worth stealing for your own agent pipelines.

The economics and ergonomics of long-running agents

One detail that is easy to skim past: each stage took about an hour, and the whole exercise ran across multiple autonomous passes. This is a different operating model from the tight, interactive loop most people associate with AI coding. You are not watching every token stream by; you are kicking off a job and coming back to an artifact. That changes how you should structure the work.

Practically, it means designing for asynchrony. Have the agent emit durable artifacts — a PDF, a JSON summary, a log of the commands it ran — so you can audit what happened after the fact rather than babysitting the session. It also means thinking about cost the way you would for any compute job: an hour of a frontier model running tools is not free, and a verify-and-arbitrate pipeline multiplies that by the number of passes. For high-stakes, one-off analyses that trade-off is easily worth it; for something you run thousands of times, you would profile and prune. The skill is matching the depth of the workflow to the value of the answer.

The caveats matter more than the result

Here is where discipline is required. The fact that the AI disagreed with the radiologist does not mean the AI was right. The author is admirably clear-eyed about this: he writes that he “cannot fully trust AI either,” and is genuinely unsure whether to seek another human opinion or simply watch how his rehabilitation goes. That uncertainty is the correct response, not a flaw in the story.

There are real failure modes hiding under a confident PDF. The model could be hallucinating measurements, mis-registering image orientation, or pattern-matching to the wrong anatomy — and a polished report makes those errors look authoritative. Medical imaging analysis is a regulated, high-stakes domain for good reason. The honest framing is: this was a fascinating personal experiment that generated a hypothesis worth raising with a human specialist, not a diagnosis.

Lessons for builders

You are probably not analyzing MRIs. But the transferable lessons are concrete and apply to almost any agentic project:

• Give the agent a shell and permission to install tools. The ability to write and run code against unknown data is the single biggest capability jump over a chat model.
• Design for verification, not a single pass. Independent analyses plus a separate arbitration step catches errors that one confident run will hide.
• Use subagents to fight bias. Isolating context so a later step cannot anchor on an earlier one is a cheap, powerful way to improve reliability.
• Expect long-running autonomy. Each stage here took about an hour. Agentic work is not always interactive — budget for it and capture artifacts like reports along the way.
• Match your trust to the domain. The riskier the decision, the more the agent's output should be treated as a hypothesis for a human expert, not an answer.

Other places this pattern fits

If the MRI example feels exotic, swap in problems you actually have. The same shape — point an agent with a shell at messy data, let it install what it needs, and wrap it in a verification harness — shows up all over real engineering work:

• Forensic data spelunking — hand the agent a folder of undocumented log files, a corrupted export, or an unfamiliar binary format and let it reverse-engineer the structure rather than writing a parser by hand.
• Migration audits — have one pass inventory a legacy system and a second, independent pass verify the migration plan against it, with an arbitration step to flag discrepancies.
• Data-quality investigations — point it at a dataset, let it profile distributions, write the checks, and produce a report on anomalies it found.
• Incident analysis — give it the metrics, traces, and recent diffs and let it form and test hypotheses about a regression.

In every case the winning move is the same one Antoine used: do not trust a single confident pass, and isolate context so later steps cannot anchor on earlier ones. The domain changes; the harness does not.

The bigger picture

The reason this story resonates is that it quietly redraws the boundary of what “a coding tool” is for. Claude Code self-directed across an unfamiliar data format, installed its own dependencies, ran a multi-stage analysis, and coordinated subagents to check its own work — none of which is “coding” in the traditional sense. If you have only been pointing agentic tools at your repo, you are using a fraction of what they can do. The next time you face a gnarly, multi-step problem on messy data, consider reaching for an agent with a terminal rather than a chat box, and design the workflow so the agent has to prove its own answer before you act on it. The capability is real and genuinely new; the discipline to verify it is what turns a neat demo into something you can rely on. Just keep the skepticism dialed up to match the stakes. For more on building with these models, browse our resources.