Vibe Coding a Healthcare Product: What You Can and Cannot Build This Way

Vibe coding is a legitimate way to build the informational and internal layers of a healthtech business — your marketing site, your documentation, your admin tooling, your early prototypes. It is not a legitimate way to ship software that touches patient data, informs a clinical decision, or forms part of a regulated product, unless every line has been through the same review a human-written code base would face. The reason is measurable: AI models have become excellent at producing code that runs and have not improved at producing code that is safe.

---

What vibe coding actually is

The term was coined by Andrej Karpathy — former director of AI at Tesla and a founding member of OpenAI — in February 2025, to describe building software by describing what you want in natural language and iterating on the result, to the point where you can “forget that the code even exists.” Collins Dictionary named it Word of the Year for 2025, defining it as “the use of artificial intelligence prompted by natural language to assist with the writing of computer code.”

The word “vibe” makes the method sound casual. A good workflow is not. You are still making product decisions; you are expressing more of them through conversation than through syntax. A typical cycle runs: define the outcome, describe the component, generate a small working version, review it in the browser, identify the highest-impact problem, request one focused change, test before moving on.

Traditional development translates a specification into design and then into code. Vibe coding compresses those stages, which is genuinely valuable — and which also makes it easy to skip checks. A page can look polished while containing weak copy, confusing navigation, inaccessible controls, or code that fails in ways nobody has looked for.

The useful definition is not “coding without knowing code.” It is building through intent, examples and review — with the emphasis on the third word.

---

The evidence: what the research actually measures

Most discussion of AI-generated code security is anecdote. There is now enough measured data to be specific, and the shape of it is more useful than any single number.

Models got much better at working code and not at all better at safe code

Veracode has tested more than 100 large language models across 80 coding tasks over four snapshots, covering multiple languages and vulnerability categories.

The 2026 report puts the average security pass rate at 56% — described as virtually unchanged from 55% in the previous report. Roughly 44% of code generation tasks introduced a risky security vulnerability from the OWASP Top 10.

The trend line is the important part. Syntax pass rates climbed from about 50% to 95% since 2023. Over the same period, security pass rates hovered between 45% and 55% regardless of model generation or release date. As Veracode put it, models have become excellent at writing code that compiles and have failed at writing code that is safe.

Three details sharpen this.

Scale does not fix it. Whether a model has 20 billion or 400 billion parameters, security performance clusters around the same mark, and even that marginal difference has largely disappeared in recent releases.

Neither does specialisation. Models purpose-built for code average a 51% security pass rate — below the general average.

Language matters a great deal. Java sits last by a wide margin at a 30% mean security pass rate, against Python at around 62%. If your stack is Java-heavy, the review burden roughly doubles.

The best model in the Summer 2026 dataset reached 68%. That is a real improvement, and it still means the leading model fails nearly one security task in three.

The methodology detail that changes how you read this

Veracode’s models were evaluated under standardised conditions with no security-specific prompting.

That is not a flaw in the study — it is the finding. It measures what the model does by default, when nobody thinks to ask for input validation, parameterised queries or output encoding. Security behaves as an opt-in rather than a default, because a model rewarded for passing functional tests has no built-in reason to defend against inputs nobody mentioned.

Which means the figure describes the experience of exactly the person most likely to be vibe coding: someone who does not know which security questions to ask.

An experienced engineer prompting deliberately for secure patterns will do better than 56%. A founder describing a patient intake form in plain English will not.

Vulnerabilities are now being counted, and the count is climbing

Georgia Tech’s Systems Software and Security Lab runs the Vibe Security Radar, which scans over 43,000 security advisories to identify vulnerabilities attributable to AI-generated code.

In the second half of 2025 it found roughly 18 cases across seven months. In the first three months of 2026 it identified 56. March 2026 alone accounted for 35 — more than all of 2025 combined.

Two caveats belong with those figures. Attribution is uneven: some tools leave a signature in commit metadata and others leave no trace, so the confirmed count under-represents the true number by an unknown margin. And rising counts partly reflect that somebody finally started looking. Neither caveat changes the direction.

Two failure modes specific to how AI writes code

Hallucinated dependencies. Cloud Security Alliance research across 2.23 million AI-generated code samples from 16 models found 19.7% contained at least one package name that does not exist. Attackers register those invented names on public package indexes and wait — a technique known as slopsquatting. The developer runs an install command suggested by a model, and pulls in someone else’s code.

Credential exposure. GitGuardian’s State of Secrets Sprawl 2026 recorded 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-on-year increase. AI-assisted commits showed a 3.2% secret-leak rate against a 1.5% baseline — roughly double.

Neither of these is a hypothetical. Both are ordinary consequences of a model producing plausible-looking code quickly.

---

Why healthcare is a different project

None of the above means vibe coding is unsafe. It means the acceptable failure rate depends entirely on what fails.

A brochure site with a broken access control leaks nothing, because there is nothing behind it. The same flaw in a patient intake form is a notifiable personal data breach involving special category data under UK GDPR, or protected health information under HIPAA.

That is the whole distinction, and it does not track the technology at all. It tracks consequence.

	Informational layer	Clinical or data layer
Examples	Marketing site, docs, careers page, internal wiki, static prototype	Patient intake, appointment data, clinical notes, triage logic, anything touching a record
Failure mode	Broken layout, wrong copy, bad link	Data breach, wrong clinical information, regulatory exposure
Who catches it	Anyone looking at the page	Nobody, until it matters
Review standard	Visual and functional QA	Security review, DPIA, clinical safety case, penetration testing
Suitable for conversational build	Yes	Only with the same review a human-written codebase gets

The tell is not how the code was produced. It is whether an undetected flaw would be visible.

Layout problems announce themselves. A missing authorisation check does not — the application works perfectly for everyone who uses it correctly, right up until someone does not.

---

What you can safely build this way

Your marketing site. This is the clearest yes. A healthtech company’s website is an informational asset carrying no patient data. Vibe coding it is fast, appropriate and — in our case — exactly what we did.

Documentation and knowledge bases. Static, reviewable, low consequence.

Internal tools that touch no patient data. Dashboards over anonymised or synthetic data, content workflows, admin utilities.

Prototypes for demonstration. A clickable prototype using synthetic data only is a legitimate and efficient use. The constraint is absolute: synthetic means synthetic, not de-identified real records. De-identification is a technical claim requiring validation, not a checkbox.

Component scaffolding within a reviewed codebase. Generating a form component, a responsive layout or a test harness inside a project that has code review, static analysis and CI is a normal engineering practice.

What you should not build this way

Anything handling real patient data without security review. Not “review it later.” The Veracode data says roughly two in five generated tasks introduce a vulnerability by default, and the categories that fail most are access control and input handling — precisely the ones that matter for records.

Authentication and authorisation. Broken access control appears repeatedly as a dominant failure pattern in AI-generated code. It is also invisible in testing, because the application behaves correctly for authorised users.

Anything that informs a clinical decision. This crosses out of engineering and into device regulation, covered below.

Integrations with clinical systems. FHIR and HL7 integrations carry correctness requirements a model cannot verify. A field mapped to the wrong resource produces valid-looking data that is clinically wrong.

Anything you cannot review or have reviewed. This is the honest constraint underneath all the others. If nobody on the project can read the generated code well enough to spot a missing authorisation check, the project needs someone who can before it touches patients — not after.

---

The regulatory layer nobody mentions

No regulator has a category for vibe-coded software. That is precisely the problem: the obligations attach regardless.

Device classification follows intended purpose, not build method. If your product is intended for diagnosis, prevention, monitoring, prediction, prognosis or treatment, it may be a medical device — in Great Britain under UK MDR 2002, in Australia under section 41BD of the Therapeutic Goods Act 1989, in the US under the FD&C Act. Whether the code was typed or prompted is not a question any of those frameworks ask. Our breakdown of is an AI scribe a medical device sets out where that line falls in each market.

You are the manufacturer. If you incorporate a model into a product with a medical purpose, the regulatory responsibility is yours — not the model provider’s, and not the coding tool’s. The TGA states this explicitly, and the MHRA and FDA frameworks assign obligations the same way.

NHS suppliers owe DCB0129 regardless. Clinical risk management for health IT applies to the manufacturer of a digital health solution. There is no exemption for AI-assisted development, and a clinical safety case that cannot explain how the software was verified is not a clinical safety case. NHS England’s position is that safety requirements apply to all digital products used in the NHS regardless of whether they are considered a medical device.

DTAC will ask questions the workflow must be able to answer. Clinical safety, data protection, technical assurance, interoperability and usability — each requires evidence. “The AI generated it and it worked” is not evidence for any of the five.

Data protection obligations start before the first line. A DPIA is required for high-risk processing under UK GDPR, and health data is special category data. If patient data may not lawfully leave your infrastructure, that constrains your architecture before any code exists — we cover the deployment consequences in open medical AI models and the contractual ones in what the BAA actually covers.

The practical implication is a sequencing point. These obligations are cheapest to design for and most expensive to retrofit. A prototype built without them is a prototype, not a head start — and teams regularly discover during procurement that their fast MVP has to be rebuilt to be assurable.

---

A method that survives review

Everything below applies to any vibe-coded project. It matters more in healthcare because the cost of skipping a step is higher.

1. Start with the outcome, not the homepage

The first prompt should not ask for colours or a hero section. Write a one-page brief first: primary audience and the situation they arrive in, the single action a qualified visitor should take, the core promise, the evidence that supports it, the objections a sensible visitor would raise, the pages that genuinely need to exist, and the constraints the site must respect.

Turn it into a success statement you can review against: “A first-time visitor should understand who this is for, what problem it solves, why the approach is credible, and what to do next, within two minutes.”

Give the model a role, an audience, an outcome, constraints and a definition of done. Aesthetic adjectives are not a brief.

2. Plan the information architecture before any layout

Start with the smallest set of pages that answer the visitor’s real questions, and give each page a one-sentence job. Do not create pages because other sites have them. If two pages answer the same question, merge them. If one page serves several unrelated audiences, split it.

Navigation should be predictable. Clever labels increase the effort required to move through a site, and on mobile the menu must work one-handed and close reliably.

3. Never let the model invent evidence

This is the rule that matters most in healthcare and the one most often broken.

Supply source material rather than asking a model to invent expertise. Tell it explicitly not to create statistics, clients, certifications, testimonials, outcomes or clinical claims that were not supplied.

A drafting instruction that works: “Write a clear first draft using only the facts below. If evidence is missing, mark the gap in square brackets rather than inventing it.”

That produces visible placeholders for human input instead of confident fabrication. In a regulated sector, an invented certification or an unsupported efficacy claim is not an editing problem — it is a regulatory and advertising compliance problem.

4. Define the visual system before designing pages

A small set of reusable decisions — typography, spacing scale, a neutral palette with one accent, button styles, border and shadow rules, and visible hover, focus, active, disabled, success and error states — makes generated output consistent and reduces per-page repair.

Describe character through relationships, not adjective piles. “Editorial layout, generous white space, strong typographic hierarchy, restrained colour” is actionable. “Premium, futuristic, bold, clean, elegant, dynamic” is six conflicting instructions.

Ask for tokens or variables so a colour change happens once rather than forty times.

5. Work in small, testable slices

Build the foundation first — typography, colour, spacing, header, navigation, footer, buttons, form fields — and test it at both ends of the range before anything else depends on it.

Then build one complete page end to end with realistic content. Placeholder text hides layout problems. A detailed service page often exposes more of the system than a homepage.

Then extract reusable components, then generate the remaining pages against the established rules.

Save a known-good checkpoint before any significant redesign or dependency change. If the next prompt breaks the layout, you want to compare and revert rather than debug.

6. Prompt like a compact creative brief

Seven parts: context, page goal, approved content, structure, visual direction, behaviour, and acceptance checks.

For revisions, change one thing at a time and state explicitly what must not change. “Change only the mobile navigation behaviour; preserve the desktop layout, colours and page content” is verifiable. A prompt that simultaneously alters typography, navigation, animation, content and forms is not.

7. Review with a human quality loop

Resize the browser slowly rather than checking two presets. Test every action with a mouse and with a keyboard, confirming focus is visible and follows a logical order. Submit forms with correct, missing and malformed input — success and error states both need to be understandable.

Review content separately from design. Then inspect the implementation for empty links, duplicated identifiers, console errors, broken asset paths, unused components and secrets in client-side code.

If you cannot assess those yourself, have a developer review the project before launch. In healthcare, make that a security review, not a code read.

8. Build accessibility in, not on

Accessibility is not a finishing layer, and in healthcare the audience skews towards people more likely to need it.

Semantic structure first: one clear main heading per page, real buttons for actions and real links for navigation, visible labels on form fields, lists marked up as lists. Sufficient contrast, meaning never carried by colour alone, every interactive element keyboard-operable with a visible focus indicator, useful alternative text on informative images.

Ask the model to audit a component against accessibility requirements, but do not treat the answer as certification. Use automated tools for common failures and manual testing for what automation cannot judge.

---

What we did on kasthunt.com

Experience, not a recommendation. kasthunt.com was built with an AI-assisted workflow. It is an informational site: it carries no patient data, no authentication, no clinical logic and no integration with a clinical system. That is precisely why the method was appropriate for it.

The same team does not build KH Scribe that way. A product that processes consultation audio and produces clinical documentation sits on the other side of the line described above, and goes through conventional engineering discipline — code review, security testing, and the clinical safety process any documentation product needs.

That split is the honest version of the advice in this article. We use the fast method where failure means a broken layout, and the slow method where failure means a patient record.

---

A pre-launch checklist for healthcare projects

Twelve items. The first three are the ones general guides omit.

1. Classify the project honestly. Informational, or data- and clinically-adjacent? If uncertain, treat it as the latter.
2. Confirm no real patient data has entered a prototype. Including in prompts, test fixtures, screenshots and error logs.
3. Determine whether intended purpose triggers device regulation before building, not after a procurement team asks.
4. Scan for hardcoded secrets across the whole repository and its history — not just current files. A rotated key in an old commit is still exposed.
5. Verify every dependency exists and is maintained. Given that roughly one in five AI-suggested dependencies in one study did not exist, check each package against its official registry entry.
6. Run static analysis on generated code, and treat AI-generated code as unreviewed third-party code rather than as your own.
7. Test authentication and authorisation deliberately, including attempts to access another user’s data by manipulating identifiers. Broken access control is the failure mode least visible in normal use.
8. Validate all input server-side, never only in the browser.
9. Complete a DPIA where personal data is processed, and document the lawful basis before launch.
10. Confirm data residency and processing location match your compliance position.
11. Have someone who did not build it review it — and for anything beyond the informational layer, someone with security expertise.
12. Document how to rebuild and restore, including deployment steps, environment settings and ownership. A site only one person can publish is a maintenance risk.

---

Where this leaves AI-assisted development in healthtech

The honest summary is that vibe coding has a clear and useful place, and its boundary is unusually easy to describe.

Build your informational and internal layer this way. It is faster, the failure modes are visible, and there is no good argument for spending three months on a marketing site. We did exactly this, and would again.

Do not build your clinical or data layer this way without the review a human-written codebase would receive — because the evidence says the default output introduces a vulnerability in roughly two of every five tasks, that the rate has not improved across four testing cycles, and that the categories failing most are precisely the ones that matter when a record is behind the form.

The deeper point is about what improved and what did not. Models became dramatically better at producing code that runs. They did not become better at producing code that is safe. Those are different skills, and only one of them is visible when you look at the screen and it works.

In healthcare, that gap between looks finished and is finished is the entire risk. It is the same gap that runs through AI-generated clinical documentation, where a fluent note can omit the finding that mattered — we cover the evidence on that separately, and the pattern is identical.

Speed is real. So is the review that has to follow it.

---

Frequently asked questions

Is vibe coding safe for healthcare products?
It depends entirely on which layer of the product. Informational assets such as a marketing site, documentation or internal tooling with no patient data are appropriate candidates. Software handling patient data, informing clinical decisions or forming part of a regulated product requires the same security review, testing and clinical safety process as any other codebase, regardless of how the code was produced.

How secure is AI-generated code?
Veracode’s 2026 GenAI Code Security Report, covering more than 100 models across four testing snapshots, found an average security pass rate of 56% — virtually unchanged from 55% the previous year. Roughly 44% of code generation tasks introduced an OWASP Top 10 vulnerability. Notably, syntax pass rates rose from about 50% to 95% since 2023 while security pass rates stayed flat between 45% and 55%.

Do newer or larger AI models write more secure code?
Not meaningfully. Veracode found model size has only a very small effect on security performance, and that difference has largely disappeared in recent releases. Models purpose-built for code average a 51% security pass rate — below the overall average. The best model in the Summer 2026 dataset reached 68%, still failing nearly one security task in three.

Does prompting for security improve the result?
Almost certainly, and the published figures do not measure it. Veracode’s testing was conducted with no security-specific prompting, so the results describe default behaviour. That is the relevant condition for a non-specialist builder, who by definition does not know which security requirements to specify. An experienced engineer prompting deliberately should expect better outcomes — but should still verify rather than assume.

Are vulnerabilities in AI-generated code actually being found in the wild?
Yes, and the count is rising. Georgia Tech’s Vibe Security Radar, which scans over 43,000 security advisories, recorded roughly 18 AI-attributed cases across the second half of 2025 and 56 in the first quarter of 2026, with March 2026 alone exceeding all of 2025. Attribution is uneven because some tools leave a signature in commit metadata and others do not, so the confirmed count understates the total.

What is slopsquatting?
An attack that exploits AI models inventing package names. Cloud Security Alliance research across 2.23 million AI-generated code samples from 16 models found 19.7% contained at least one non-existent package name. Attackers register those invented names on public package indexes, so a developer following an install suggestion pulls in the attacker’s code. Verify every dependency against its official registry entry.

Does AI-generated code leak credentials more often?
GitGuardian’s State of Secrets Sprawl 2026 found AI-assisted commits exposed secrets at a 3.2% rate against a 1.5% baseline across all public GitHub commits — roughly double. It also recorded 28.65 million new hardcoded secrets in public commits during 2025, a 34% year-on-year increase.

Can I build a healthtech MVP with vibe coding?
You can build a demonstration prototype using synthetic data only, and that is often a sensible use of the method. What you cannot safely do is put real patient data behind a conversationally-generated application without security review. Be aware that a prototype built without clinical safety, data protection and assurance requirements is a prototype rather than a head start — those requirements are cheapest designed in and most expensive retrofitted.

Does using AI to write the code change our regulatory obligations?
No. Regulatory classification follows the product’s intended purpose, not its build method. No regulator has a category for AI-generated software. If your product meets the medical device definition in your market, you are the manufacturer with the full set of obligations that entails, and how the code was produced is not a question the framework asks.

Does DCB0129 apply to AI-generated code?
Yes. DCB0129 clinical risk management applies to the manufacturer of a health IT product supplied to NHS organisations, with no exemption for AI-assisted development. A clinical safety case must explain how the software was verified, which means an AI-assisted build needs a documented verification process rather than an assurance that the output worked.

Should I let AI write authentication for my healthcare app?
No, not without expert review. Broken access control and missing authorisation checks appear repeatedly as dominant failure patterns in AI-generated code, and they are the failures least likely to surface in normal testing — the application behaves correctly for every authorised user. Authentication and authorisation warrant experienced review regardless of how they were written.

How do I stop an AI-built site from looking generic?
Use real content, a specific audience, a coherent point of view and a restrained design system. Explain what you like about a reference rather than asking the model to copy it. Remove filler sections and the habit of placing every block in a rounded card, which flattens hierarchy. Most generic output comes from generic input.

Do I need to know how to code?
For an informational site, useful results are achievable with limited coding knowledge, though basic familiarity with HTML structure, CSS layout, browser testing, hosting, accessibility and security helps you evaluate output. For anything handling patient data, someone on the project must be able to read the code well enough to spot a missing authorisation check — or you need to bring in someone who can.

Can vibe coding replace a developer?
It reduces routine production work. It does not replace strategy, technical judgement, security expertise or accountability. In a regulated context, accountability is not optional and cannot be delegated to a tool. The expertise required scales with the consequence of failure, which in healthcare is high.

How often should we review an AI-built site after launch?
Monitor critical functions immediately after launch. Review technical health at least monthly — updates, backups, errors, forms, speed, broken links — and content on a schedule matching how quickly the organisation changes. Dependency updates deserve particular attention given the hallucinated-package risk.

---

Building a healthtech product and not sure which layer you are on?

The line between “ship it fast” and “this needs assurance” is usually clearer than founders expect, and drawing it early saves a rebuild later. We work it out during the Discovery Workshop against your actual intended purpose and data flows — including when the answer is that your prototype is fine as it is and does not need us.

---

About the author

Jatin Sharma is a Voice AI & Multi-AI Developer at KastHunt Consulting LLP, working across voice agents, conversational AI, web technologies and multi-model AI integrations. He also works with AI-assisted development and vibe-coding workflows to build and test practical digital products.

LinkedIn: Jatin Sharma

Questions or corrections: info@kasthunt.com

---

Sources

Security research

1. Veracode. Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security.
2. Georgia Institute of Technology, School of Cybersecurity and Privacy. Bad Vibes: AI-Generated Code is Vulnerable, Researchers Warn, 13 April 2026. Source
3. Cloud Security Alliance AI Safety Initiative. Research notes on AI codegen vulnerability debt and slopsquatting, April 2026.
4. GitGuardian. State of Secrets Sprawl 2026, 17 March 2026.

Terminology

6. Collins Dictionary. Word of the Year 2025.

Regulatory

7. MHRA. Ambient voice technology-enabled products, 29 July 2026; UK Medical Devices Regulations 2002.
8. NHS England. Guidance on the use of AI-enabled ambient scribing products in health and care settings, Version 3, 29 July 2026.
9. NHS Digital. DCB0129 Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
10. TGA. Artificial intelligence (AI) and medical device software regulation, 5 February 2026.

---