Yesterday, Shopify CEO Tobi Lütke posted a tweet that caught my attention. His annual MRI came on a USB stick that required commercial Windows software to open. So he ran Claude on the stick and asked it to build him an HTML-based viewer instead.
“This looks… way better,” he wrote. One more prompt, and it annotated everything with the findings.
When asked how many prompts it took, he shared the one that built the viewer:
“This is a USB Stick of my MRI. Find all reports, find all images, use imagemagick to convert them into something useful, and get everything into a structured directory in the ./output folder that’s worth retaining. Then, make an index.html that’s a full exploration tool for the results.”
“Its a oneshot!” he added.
The tweet has 5.2 million views. The reaction has been… mixed.
The Skeptics Have a Point
Over on Reddit , the consensus was swift: “We are not impressed.”
The criticism centered on a few points. Free, open-source DICOM viewers already exist—Horos, OsiriX, 3D Slicer, Papaya. Most MRI disks come with a viewer included. One commenter, a software engineer with 24 years of experience who worked at a medical imaging startup, dismissed it outright—pointing out that building a real PACS system took his team of seven engineers two years, and that didn’t include HL7, DICOM standards, or FDA certification.
“It’s just a DICOM viewer,” another wrote. “Plenty of open source projects do the same. The LLM invented nothing.”
They’re not wrong. Given that prompt, Claude likely scanned the USB drive, recognized the DICOM file format (the standard for medical imaging), and reached for an existing JavaScript library like Cornerstone.js or dwv to do the heavy lifting. It would have used ImageMagick as instructed to convert images, then assembled everything into an HTML interface with slice navigation and basic viewing controls. The underlying DICOM parsing? Built by medical imaging engineers over years of work. Claude was assembling, not inventing.
The “vibe coding” skepticism is valid too. A working prototype isn’t production software. It hasn’t been tested across edge cases, validated for accuracy, or hardened against the thousand things that can go wrong when you’re dealing with medical data.
But That’s Not the Story
Lütke’s tweet wasn’t a claim that he’d built a medical device. It was a demonstration of reflexive AI use—his term for what happens when you’ve worked with AI long enough that reaching for it becomes automatic. He saw a friction point (Windows-only software, and he was on a Mac) and his first instinct was to prompt his way out of it.
“You want to train your brain on this intuition,” he wrote.
That’s the shift worth paying attention to.
I work in healthcare IT—specifically radiology. My employer spends tens of thousands of dollars annually on a patient portal that, at its core, lets people view images and reports. I’m not understating the complexity—HIPAA compliance, audit logging, identity verification, integrations with other systems, 24/7 availability. Enterprise healthcare software is expensive because the requirements are genuinely demanding.
But most of that cost isn’t the viewer. It’s everything around the viewer—compliance, integration, support, liability. The actual display of a DICOM image in a browser is, as the critics point out, a solved problem.
What happens when the “everything around it” starts getting easier too?
The SaaS Disruption No One’s Pricing In
I’ve been telling my team for a year now: we’re approaching a point where we won’t have to buy software anymore—we’ll just build what we need.
One Reddit comment echoed the same idea: “I really think we’re in a SaaS apocalypse. Everyone will build the tools they want.”
That’s hyperbolic, but it gestures at something real. The gap between “I need software that does X” and “I have software that does X” is collapsing for a certain class of problems—internal tools, personal utilities, one-off data transformations. The problems that used to require buying a product or hiring a developer.
A radiology practice can’t build its own PACS yet. The regulatory requirements are too high, and so is the complexity—hanging protocols, integration with reporting and dictation systems, complex reading workflows. But could they build their own internal scheduling tool? Their own report templating system? Their own patient intake forms?
It was difficult before. The overhead of software development—even simple software—was too high for an IT team with single-digit staff to absorb.
Now a physician with a weekend can prompt their way to something functional.
I don’t think this replaces enterprise software. But I think it compresses the market for everything between “enterprise” and “I’ll just use Excel.” That’s a lot of software.
The Uncomfortable Question
One of the more thoughtful Reddit comments came from a radiologist: “In complete fairness, most of the commercially available PACS systems are appalling. I’m a radiologist who is currently building one with Claude’s help.”
That’s the uncomfortable question for healthcare software vendors. Not “is AI-generated code as good as our product?” but “is our product good enough that users won’t try to replace it?”
For a lot of software, the answer has always been no—but the cost of switching was too high. AI is changing that calculus.
Tobi Lütke built a toy. The skeptics are right about that. But the toy worked, and it took him one prompt. That’s the part worth watching.