Learning the basics of Git has changed how we use AI at Dental TI.
My technical background is in dental radiography. I support imaging systems, train teams, troubleshoot IT issues, and help practices get more from their technology. Software engineering is a different discipline. I spent a year in San Francisco working on Hup and learned a tremendous amount from its founder, Stan Mattingly, and other founders I met there. I came back with a much better understanding of what we could build and how to approach it.
One of the most useful things to learn was also one of the most basic: how to work with a repository.
A repository holds a project's files and their history. Those files can include instructions, reference material, examples, and software. Git records changes so you can compare versions, see how something developed, and restore an earlier version when needed. It works with much more than code. Git's introduction to version control explains the foundation well.
We use a private repository to keep the processes our team and its agents work from. When someone figures out a better way to do something, we can save the process, the relevant context, and an example of the result. The next person's agent can start with that material.
In our first week using this approach, we improved SOPs, ran outreach that booked appointments, produced email campaigns that converted leads, and made technical and SEO improvements to our own site and client websites. We also built internal tools and worked out an AI video process. In my judgment, the commercials it produced were comparable to work we've paid thousands for.
The video work is a useful example. I spent a day working through reference images, storyboards, visual consistency, and the transition into video generation. Some approaches worked. Others produced images that were wrong for the product or didn't survive the move into motion. By the end, we had a much better process and a clear record of what to avoid.
That learning can become instructions the next teammate's agent reads before it starts. They can bring a new idea without needing my entire conversation or spending another day repeating the same mistakes.
The same approach applies to sales, marketing, and follow-up. Our best people already have judgment worth capturing: which questions to ask, what information a customer needs, how to explain a product, and when a follow-up is useful. Approved examples and clear instructions give an agent something specific to work from. We can then judge the result against standards the team already uses.
There is a practical detail here that matters: the agent has to read the relevant material. A folder full of good instructions does very little if each new task starts without them. We give agents a clear starting point and tell them which process and references to load for the work at hand.
The repository also gives us a way to keep improving together. A teammate can try a change, compare it with the current process, and have it reviewed before it becomes the shared version. If the change causes trouble, the previous version is still available. We can see the history instead of trying to reconstruct why an instruction exists.
You only need a few concepts to get started. A commit records a set of changes. A diff shows what changed. A branch gives you a place to work on a proposed change, and a merge brings the accepted work into the shared version. An agent can handle much of the mechanics while you decide whether the work is right.
I still have to evaluate the output. The team still has to explain what worked, what missed, and what should change. Our experience in the business is what makes the instructions useful. The agent helps us apply that experience across more work.
If you want to try this, start with one process your team repeats. Put the instructions, an approved example, and the necessary references in a private repository. Have an agent use them on a real task. Review the result and update the process with what you learn. Then ask another teammate to try it with their agent.
That second person is a good test. If they can produce useful work without needing you to retell the whole story, you've saved something the business can keep using.