I have been hearing the term “vibe coding” everywhere lately. It shows up in YouTube ads, the business newsletters I read each morning, and even television shows. Like a lot of things involving AI, it seemed to go from something I had barely heard of to a Baader-Meinhof situation. The basic premise is thus: vibe coding allows someone to describe what they want a piece of software to do using everyday language while AI handles much of the actual coding behind it.  

You do not necessarily have to know how to build software anymore to create something that works like software. The implications for dentistry are endless, but when does building helpful tools for your practice stop being a clever solution and start becoming a bad idea?

I am certainly not a software developer or an AI expert, so I took those questions and quite a few others to Dr. Ryan Hungate, Chief Clinical and Strategy Officer at Henry Schein One. We had a lengthy conversation about vibe coding, what dental teams can realistically do with it today, and where the limitations need to be. 

What I learned is that this is probably not about dental practices suddenly becoming software companies. It is about the barrier between recognizing a problem and being able to create a small tool to solve it becoming considerably smaller. 

From asking AI to building a tool 

The first thing we needed to establish was what vibe coding actually is, because it is easy to lump it together with everything else happening with generative AI. Hungate broke it down like this: “Asking a chatbot gets you an answer, once. Vibe coding gets you a tool.”  

Think about asking an AI chatbot to analyze a spreadsheet compared with describing how you want that spreadsheet analyzed and having AI help you create something that can perform the same analysis again next week or next month when you have new data. In one instance, AI completes the task for you. In the other, it helps you create something reusable to complete that task. 

This starts getting interesting for dental teams because the person describing the problem does not necessarily need to understand programming. They need to understand the problem, and there is probably nobody better positioned to identify inefficient parts of a dental practice than the people performing those jobs every day.  

Someone working insurance knows which reports never seem to reconcile correctly. A scheduling coordinator knows which information they repeatedly have to hunt down, and so many other examples of issues. But how do you select which tasks to create a tool for? Surely not every problem needs a tool built out, and there should be a priority list. Hungate again described it this way: “If someone on your team does it manually every week and dreads it, that is the candidate.” 

Start with the problems your team already knows 

What makes this different is not necessarily that these tools could never have existed before. Most of them could have been built years ago. The difference is who can potentially build them, how much effort it takes, and how much less it may cost.  

A relatively small operational problem probably did not justify finding a software developer, explaining the intricacies of a dental workflow, paying for a custom project, and waiting for it to be completed. AI-assisted coding dramatically lowers that barrier, which makes solving smaller and more specific problems more realistic. 

The areas that appear best suited for this approach are those built around rules, numbers, and repeatable processes. Revenue cycle management, insurance, and reporting provide obvious opportunities, while scheduling optimization and some forms of compliance documentation may also lend themselves to customized tools.  

As the use case moves closer to clinical decision-making, however, the stakes and regulatory requirements increase significantly, and the threshold for experimenting with something a team built itself should increase with them. 

Dental knowledge still matters 

One of the more interesting parts of this conversation is that AI’s growing ability to create software does not make knowledge of dentistry less important. In many ways, it makes that knowledge more valuable.  

AI may be able to generate code, but it does not work in your practice. It does not understand why your team handles a particular process differently, which information matters when evaluating a claim, or why a workflow that appears perfectly logical on paper does not work particularly well when patients, insurance companies and an actual schedule become involved. The person using the technology still has to supply that context and ultimately determine whether the result makes sense. 

The same principle applies to AI tools that are already becoming part of dental workflows. Ambient voice charting, for example, may reduce the amount of time a clinician spends typing documentation, but it does not eliminate the need for that clinician to review what was created and determine whether it accurately reflects the encounter. The technology can perform part of the work, but the dental professional remains responsible for the judgment surrounding it.  

That is one reason Hungate does not see the practical near-term AI conversation in dentistry as one of eliminating jobs. “It replaces tasks, not people,” he said, with the more realistic opportunity being to remove lower-value tasks so team members can spend more of their time doing work that actually requires their expertise or interacting with patients. 

Better tools still depend on better data 

There is another limitation that becomes increasingly important as practices start asking AI to do more with their information: the technology can only work with the data it has.  

Dental practices can accumulate years of inconsistent information as coding practices change, fields are left blank, duplicate patient records are created, or different team members enter the same type of information in different places. Automating the analysis of that information does not magically correct what was wrong with it in the first place. As Hungate put it, “AI cannot repair what a team never entered.” 

Data hygiene therefore becomes part of the conversation before a practice starts dreaming about everything it could build. A report that previously took someone hours to compile manually may have allowed that person to notice inconsistencies and correct them along the way. A tool designed to automate that process is going to follow the information and rules it is given. If the underlying data is inconsistent, the output will inherit those problems, only much faster.

Avoid creating a new technology problem 

The ability to create software more easily also introduces another potential problem. If everyone can build a tool, a practice could eventually find itself with a collection of small applications created by different people for different purposes. 

Someone creates a claims tool, someone else builds something for scheduling, a manager creates a reporting dashboard, and six months later the employee who understands one of those tools leaves the practice. Instead of simplifying the technology environment, the team may have accidentally created another group of disconnected systems that someone has to manage. 

Hungate takes that possibility seriously and offered three practical rules for avoiding it: every tool a practice keeps should have a named owner, anything that has not been used for 90 days should be deleted, and “nothing homemade becomes load-bearing for patient care or payroll.”  

Those guidelines draw an important distinction between creating something that makes an internal process easier and creating something responsible for critical operations. 

Know when to stop building 

Security and privacy make that distinction even more important. There is a significant difference between building a simple tool using non-sensitive information and putting patient records, financial information, or other protected data into an AI environment. 

The fact that an application is easy to create does not remove HIPAA requirements, security concerns, regulatory obligations, or the need to control who can access information. Practices should be particularly cautious about uploading patient or practice data into consumer AI tools simply because they want to experiment with what they can build. 

Hungate’s dividing line for when purchasing or using a governed commercial solution makes more sense is relatively straightforward: anything that touches the patient record, moves money, or carries a regulatory obligation deserves a much higher level of protection.  

That does not necessarily mean customization disappears. Instead, customization may increasingly happen within secure platforms where access to data can be governed, permissions can be controlled and activity can be monitored rather than through a collection of independent tools with unrestricted access to practice information. 

What happens to practice management software? 

That also helps answer one of the bigger questions surrounding vibe coding: If practices can increasingly create software themselves, what happens to traditional practice management software? 

The answer may be that those platforms become more important rather than less important, but their role begins to evolve. Practices still need a secure and reliable foundation containing trustworthy data, appropriate permissions, audit trails, and controlled ways for other applications to interact with the system.  

What may change is the expectation that one software company has to anticipate and build every feature that every dental practice could possibly want. 

Start with one problem 

For practices and team members who are curious about vibe coding, the opportunity is probably not to begin by imagining an entirely new practice management system. It is much smaller than that.  

Look at the repetitive work happening around you, particularly the work involving reports, lists, numbers and information that someone repeatedly must manipulate into a usable form. There may now be a space between accepting that inefficient process as part of the job and purchasing another large software solution to address it. 

After spending so much of the last few years talking about what AI might eventually do in dentistry, this is one area where the interesting question may be what a dental team can do with AI today. Vibe coding will not make every team member a software engineer, nor should it encourage practices to start building their own critical clinical or financial systems.  

It does, however, give people who understand dental workflows a new way to approach the smaller problems they encounter every day. 

Hungate left me with a simple place to begin: “You do not need a strategy for this. You need one question that has bothered you for a year, a safe vibe-coding environment, and an afternoon.”

A sincere thank you to Dr. Ryan Hungate for taking the time to thoroughly answer my questions. His thoughtful responses not only helped me better understand vibe coding, but ultimately shaped the direction of this article.