You can now build an app by describing what you want. But sooner or later, your AI assistant will ask you to “merge the branch and deploy to production”.
Which sounds like something you should probably understand before saying yes.
This post started with a tweet from my colleague at Automattic, @fkadev, explaining common developer terms in plain English. I liked the idea, so I’ve expanded it into a guide for non-techies who are vibe coding with AI.
Having taught thousands of beginners to use WordPress, I’ve seen how quickly unfamiliar language can make people feel out of their depth. Often, the concept is straightforward. It’s the terminology that gets in the way.
You don’t need to become an expert in all of this. But knowing what these words mean will help you understand what your AI assistant is doing, and what you’re agreeing to.
Where your code lives
GitHub: A place to keep your code, track changes and work with others. It helps you see what changed, when it changed and who changed it.
Repo: Short for repository. Think of it as your project’s folder, with a history of its changes. It usually contains your code, images, configuration and instructions. A repo can live on your computer or on a service like GitHub.
Commit: A recorded checkpoint in your project’s history. When you’ve made a useful set of changes, you can commit them with a message explaining what you did.
Branch: A separate line of work within your project. You might use a branch to try a new design without immediately changing the main version.
For example, you could ask your AI assistant to create a branch before redesigning your homepage. That gives you somewhere to work on the idea before deciding whether to bring it into the main version.
Bringing changes together
These terms sound interchangeable, but they describe different actions.
Pull: Get changes from a remote repo and integrate them into your local branch. In plain English: “Bring my copy up to date.”
Merge: Combine changes from one branch with another. For example, bring the new contact form you’ve been working on into the main version of your app.
Rebase: Replay your branch’s changes on top of a different starting point, usually an updated main branch. Think: “Take my work and rebuild its history as though I’d started from the latest version.”
Conflict: Two changes overlap in a way Git can’t resolve automatically. Someone needs to decide what the final code should look like.
You don’t need to master all of this on day one. The useful thing to know is that pull, merge and rebase aren’t three names for the same action.
The parts of your app
Frontend: What people see and interact with. The pages, menus, buttons and forms.
Backend: The logic running behind the scenes. When someone submits a form, the backend might check the information, save it and send a confirmation email.
Database: Where your app stores structured information so it can use it later. That could be products, bookings, customer details or saved preferences.
API: A way for one piece of software to ask another for data or actions. If your app shows a weather forecast, it might use a weather service’s API to request it.
WordPress has several APIs. Two you might hear about when vibe coding are:
- WordPress REST API: Lets other apps read or update WordPress content, depending on their permissions. For example, you could build an app that displays blog posts from your WordPress site, or a tool that creates draft posts without opening the WordPress dashboard.
- WordPress Interactivity API: Helps developers make WordPress pages respond to what visitors do without reloading the whole page. Think of a menu opening, a section expanding or a product filter updating the results.
They serve different purposes: the REST API lets software exchange information with WordPress, while the Interactivity API provides a standard way to build interactive features within WordPress pages.
Server: A computer or service that handles requests from your app. It might deliver a web page, run backend code or retrieve information from a database.
Domain: The address people type to find your website, such as pootlepress.com. It points people towards your site; it isn’t the site itself.
Say you’re building a booking app. The frontend is the calendar and booking form. The backend checks whether a slot is available. The database stores the booking. An API might connect it to an email service to send a confirmation.
These terms become easier to follow when you can connect them to something you’re building.
When something goes wrong
Cache: A saved copy of something, kept so it can be used again quickly. Instead of fetching or generating the same thing repeatedly, the system reuses the copy.
Caching helps with speed, but it can also explain why you’re still seeing an old version after making a change.
Bug: Something doesn’t work the way it should. A button does nothing, a page looks wrong on mobile or a total adds up incorrectly.
Debug: Investigate why something is happening and fix the cause. “The form doesn’t work” describes a bug. Finding out why it doesn’t work is debugging.
When you’re asking AI to fix a bug, explain what you did, what you expected and what actually happened.
“The booking form is broken” gives it less to work with than “When I select Friday and press Book, nothing happens. I expected a confirmation message.”
Who can get in, and what they can do
Authentication: “Who are you?” Logging in with a password is one way to prove your identity.
Authorisation: “What are you allowed to do?” Being logged in doesn’t necessarily mean you can change settings or see someone else’s information.
For a WordPress example, a subscriber and an administrator can both log in. They have very different permissions.
If you’re building an app with user accounts, this distinction matters. Someone should be able to see their own bookings without being able to browse everyone else’s.
Getting your work online
Staging: A separate environment where you can test changes before releasing them to users. Think of it as a rehearsal space for your website or app.
Production: The live system people are actually using. If customers are placing orders on your website, they’re using production.
Deploy: Put a version of your code into an environment where it can run. You can deploy to staging for testing or to production for people to use.
Rollback: Return to an earlier version when an update causes problems. It can help restore a working app, although it doesn’t automatically undo things like database changes or emails already sent.
So when your AI assistant says “Ready to deploy to production?”, it’s asking whether you’re ready to put that version into the live system.
That’s a good moment to check you’ve tested it.
You’re allowed to ask what something means
You don’t have to learn this entire list before you start vibe coding.
But understanding the basics helps you ask better questions and make better decisions, especially when an AI assistant is about to change something on a live site.
And if it uses a term you don’t understand, try this:
“Explain what that means in plain English, what you’re about to change, and whether it will affect the live site.”
That’s a useful habit, however much technical experience you have.
Leave a Reply