When a new data source shows up at Dart Health, we hand it to an AI framework we built on Claude. It takes whatever the source can produce, be it a file spec or an actual data file, analyzes the structure, and asks us questions when it isn't sure about a field or a data type. Then it writes a JSON mapping that translates the incoming data into our standardized structure. A few hours later, the feed is live.
So you won't hear us claim that AI can't write a parser. We use it to write parsers all the time, and it's fast.
But that speed is possible because it rests on an established foundation, with file loading, data validations, error handling, and identity resolution rules already in place. We spent years building the foundation that makes a few hours of AI work safe. The AI covers the last mile, but the foundation handles the underlying complexity.
Without that foundation, AI's speed works against you. This is the AI trap: the tools solve simple problems so quickly and cleanly that they mask the complexity that will break the solution later. Your engineers could vibe code a working parser in a few hours too. They could even build one from the ground up in a day or two, and it would work for the majority case. It would also feel complete and bulletproof, which lulls everyone into ignoring the edge cases you haven't hit yet, the security gaps you can't see, and the data segregation practices you'd normally insist on.
Data on demand
So, what's your foundation? If the honest answer is "we build what we need when a new source shows up," you're living in one of two scenarios:
In the first, every new data source gets its own vibe coded process. Each one does the job, in the sense that data comes out the other end, but every process makes slightly different decisions. Parser #3 handles a malformed date of birth one way, parser #7 handles it a different way, and parser #9 doesn't handle it at all. But they each work, at least with that test data file you use every time. You know, the one with no bad data scenarios, or maybe the one or two that you saw last year?
Multiply that by every field with a quirk and every source with a deadline, and you end up with an inconsistent web of one-off processes that no one can reconcile. You don't even know where your risk is, never mind how much is there.
Or maybe you've moved on from artisanally handcrafted data ingestion scripts and you've built a unified data management layer with general error handling and some real security controls. It's faster, it feels solid, and it handles a few edge cases. It's also nobody's primary focus, so it gets attention when it breaks and neglect when it works, and it stays focused on the happy path.
You don't even know where your risk is, never mind how much is there.
Outside the happy path, things quickly get human-powered. The weird file, the twins who share a birthdate, the household ID sitting in a member ID field, all route to a human for review with no graceful failures and no error recovery. Each one becomes another maintenance request in a queue that competes with your actual product roadmap, so the platform falls further behind at exactly the rate new sources land on it. Oh, and who's watching for security patches? For that matter, do you even know what AI-selected components are in there to patch?
Compliance is not a vibe
You handle sensitive data, so you have to be compliant. You have access policies, secured storage, annual training, the whole HIPAA catalog. Or maybe you're just handling employee data, so you're "only" worried about all of the PII flowing across your servers.
Unfortunately, if you're vibe coding your data pipeline you don't know how many of those policies made it into the generated code. Your policy says every PHI access gets logged, but the generated script writes rows to a database and logs nothing, because nobody asked it to. Your policy says PHI stays in the secured store. The two-hour parser read and wrote wherever the prompt happened to point it, and it left copies along the way: intermediate files, debug output, temp tables that appear nowhere in your data-handling documentation. And did a developer paste real member data into the AI tool while they were iterating? How would you know?
AI collapsed the build cost, but the ownership cost didn't move an inch.
Then there's the code itself. AI allows you to produce code at a prodigious pace, often faster than humans can review it. Maybe you're running CodeRabbit, or you use Codex to review Claude's output, but how does that align with your secure coding policies? Whatever security flaws the generator produced are still in there until something in your process explicitly searches for them.
You'll feel all of this the day a big prospect sends over their security questionnaire: 100+ questions, every answer auditable and any one of them a landmine that could blow up a new deal. Those answers are only as true as the code, which you can't see anymore. The time you saved with vibe coding is lost to risk mitigation and talking your way around the right answers.
In other words, AI collapsed the build cost, but the ownership cost didn't move an inch.
So the next time someone says they can have a new feed flowing by Friday, ask yourself: what's this really going to cost me?
