AI writes code that looks good enough. So maybe reading the code will become pointless.
I was at a coffee shop the other day, watching the barista work, and it got me thinking about the question everyone keeps asking me about AI and code, because that’s what you do when you’re waiting for coffee.
You order a flat white. 30 seconds later it’s in front of you, and the latte art on top is perfect. A clean little tulip. But you can’t see the one thing that matters from the top of the cup. What milk is under there? Did they use the oat you asked for, or grab the regular out of habit?
That’s AI-generated code. It comes out fast, and the features mostly work.
All cups look the same from the top. What matters is the milk, and that’s what you can’t see.
So everyone’s worried that nobody’s reading the code anymore. I get it. But I want to flip the question. Do we even need to read it?
Look at the espresso machine behind the counter. Nobody stands there watching what it does inside. You press the button and you trust the shot, because it does what it’s commanded to do. Nobody on your team reads the assembly their compiler produces, or the machine code under that. We stopped reading the computer’s output decades ago, moved up a level, and software got better for it. The trust never came from a human reading what the machine wrote. It came from the recipe above it, combined with the machine being predictable enough to deliver it consistently every day.
Every time we climbed a step, somebody worried we’d lost the plot. But it has worked out so far.
We’re standing on another one of these steps right now. So maybe this is the same story.
AI can write the code but it can’t decide what to build
The espresso machine changed what a barista does. Before the machine a barista may have made all coffees by hand, and they may have been inconsistencies between orders . The machine made the coffee consistent and freed the barista to run everything else at the counter.
AI is that machine for code. It writes the lines, and the engineer moves the work around them, like communicating with stakeholders, removing blockers, or understanding requirements.
Code arrives faster than anyone can review it, so review stops being where you catch problems. What decides whether the software is right moves earlier, to the spec.
The spec is where you catch problems now
The spec is the document worth your full attention. It is the clearest record of what you asked for, and it is the one thing the AI did not write to look finished. A loose spec used to be survivable, because the code came back obviously wrong and you fixed it. A loose spec now produces code that looks finished and does the wrong thing, and nobody notices for months.
So the work moves into the spec itself. You settle the architecture, the interfaces, and the security model there, before a line is generated, while changing your mind is still cheap. Writing a sharp spec used to be optional. It is the main control you have now.
In health tech, this becomes an audit
In a normal app, code nobody checked is a quality risk. In health tech and finance it becomes a compliance problem, because the code runs on patient data or someone’s money, and someone outside the team gets to ask where it came from.
A regulator asks you to prove it. Which parts came from an AI tool, what prompt produced them, and whether anyone checked them against your HIPAA controls. Whether an engineer read the code never comes up.
Yujan Shrestha, who works on FDA-regulated software, puts it well. Compliance “is a property of the evidence and provenance surrounding the code.” Nobody has to have read the code. They need the record of how it got there.
Most teams can’t produce that record. Cycode asked more than 400 security leaders, and 81% said they can’t see how or where AI is being used across their own development. The market is already paying to fix it. Medical-device teams live under FDA traceability rules, and Ketryx, which sells exactly that kind of tracking, raised a $39 million round last year. People spend real money to prove where their software came from.
Check it while the code is written
Your security scanner and your code review both run after the code already exists. One reviewer, staring at work the AI produced in seconds, trying to catch everything. That setup was built for code that arrived at human speed. If you want to know what the AI wrote and whether it followed your rules, the check has to run while the code is being written, and it has to leave a record.
That’s what we built Anthara to do. You load the standards you answer to, like HIPAA. The checks run while the AI writes the code, before any of it reaches a pull request. It can pull patient data out of prompts before they ever leave your environment.
And it logs every prompt, response, action, and decision, so when someone asks what the AI wrote and whether it was allowed, you can answer. It runs next to the security scanner and the review you already run. We’re moving the check up to where the code gets made, the same way the industry once decided to trust the compiler instead of reading what it printed.
The speed is going to keep climbing, and that’s honestly good. But for your next leadership meeting, this is the question I’d put on the table. Pick any service you’re running right now. If an auditor, a customer, or a regulator asked you to prove what that code is and where it came from, how much of it could you defend?
Sources: Stack Overflow Developer Survey 2025; DORA 2025 (Google); DX; Faros AI; Cycode, State of Product Security in the AI Era; Ketryx; Yujan Shrestha, Innolitics.
