Today I’m giving some tips to people who are vibe coders. I don’t necessarily like that term, but I mean people who are using LLMs to write their code and perhaps don’t know a lot else about software engineering.
Are you willing to know more about how to write and run great software using LLMs? If that is you, then read on. If you think you might know it all already, this would be a good time to stop.
You can ask your AI tool to build an app, and within a few minutes, whoever you are, you’ll have something you can use: a login screen, a dashboard, a booking form. Whatever you might have thought up, you can create it really fast. And it looks really convincing. You can click around, make a booking, and everything will seem to work.
What happens, though, if two people try to make a booking at the same time for the same time? What happens if a customer can’t log in properly? Is it possible for one customer to see another customer’s information? What happens if more than 10 people try to use the app at once, or more than 100? Are there updates happening in the background that you might not know about, and that might break the application?
These things, and many more, are the questions we’re going to try to answer. This is not going to be a complete list of everything you need to know for a computer science degree. These are just some things that might help you out.
Your demo or proof of concept is not going to have all of these things. This is about that piece of software you might put into production, hand over to a client, or even start using yourself in your business. These are the things to think about.
I recently noticed there were a lot of vibe coders around who really have no idea about what they don’t know. I’m not trying to build a moat around software development, by any means. In fact, what I love is that all of this can be learned very easily. You can ask your LLM to explain or just do many of these things, but you have to know to ask. You have to know to get these things done.
I’m excited that more people can have a go. If you’re building something for a business, or paying someone else to do it, there are things you need to understand beyond getting Claude or Codex to write the code for you.
You might have to set aside the idea that using an LLM is all you need to know to run a business or even launch a product online. There might be more to know and learn that you could benefit from.
Start With the Problem and Plan Your First Version
Let’s start with probably the most essential thing: the problem you’re trying to solve, and the plan for your first version of the application.
Let’s use a simple example. You’re making a booking form for a service business. Maybe you’re a plumber; maybe you’re a sparky. You need to let your clients book a time: “I want the plumber here at this time on this day.” There are no other bookings around that time, so the person can book it in.
The first thing you need to do is ask what problem you’re actually trying to solve. Are customers struggling to find available appointments? Can they not get through to the person who’s supposed to make the appointments? Is someone in your business spending too long making those appointments or trying to figure them out? Or maybe it’s a different problem entirely.
I’m not trying to make an exhaustive list. The point is that you need to figure out the exact problem. The problem is not “I need a booking form”. That’s the solution. What’s the problem?
That gives you an idea of what you’re trying to build and how you go about building it. What is the client or user trying to do that streamlines the business, maybe increases sales, or whatever the case might be?
Also figure out what you definitely do not need. Quite often, vibe coders get this bit mixed up because they find out how easy it is to build something, so they go ahead and build it whether the client needs it or not, or whether it’s going to be used or not, just because they can.
Do you need a loyalty program? Do you need a chatbot? Do you need a complex dashboard? No, probably not.
What you need is what’s called the MVP, the minimum viable product. What is the smallest scope that’s going to solve the problem and deliver something of use to the end user?
Some important things there might be a login. Keep it as simple as possible. Two-factor authentication is probably not going to be necessary for this. Make sure people can’t double-book. Make sure you’re collecting the right information and that it’s being stored correctly. We’ll get onto that later.
Make sure those bookings flow into the calendar application immediately so clashes are avoided. Make sure people can log back in and change that appointment if necessary, or cancel it if they need to.
That’s going to be your MVP. Everything else, don’t build. Get that into production first.
Where Do I Keep My Code?
The next problem you’re going to encounter is: where do I keep my code? It’s not inside Claude or Codex. That’s not where you store your code.
What we use is something called a repository. It could be GitHub, but it could be another type of repository as well. This also does something called version control, so if mistakes are made, you can roll back easily to the last known good code.
It gives you a history of your changes, so you can see what was being done and when, and pinpoint exact changes in the code. You can implement branches so more than one person can work on something at once, or somebody can test something while you work on something else without breaking the thing that’s being tested. All of these things are available in version control software.
It also means the code itself can be owned by the person who paid for it. If you’re doing work for a client, that code doesn’t belong to you. They’ve paid you, and when they pay you, that code belongs to them, not just the application. They would own the GitHub repository, and that is the asset for them.
Make sure everyone who needs to can access that code. They should have the right level of access, and that access should be able to be turned off if someone leaves or moves on.
Testing
The next point is very, very important: testing. There are two types of testing I’m going to discuss: user testing and automated testing.
User Testing
User testing means that as each feature is built, or perhaps a cluster of features, you hand it over to your client. Maybe that’s yourself. Whatever the case, manual testing is done.
Manual testing means inputting typical data and making sure the flow works. It means inputting incorrect data and making sure the application baulks at that, shows the correct error, or does what is expected.
It also means using what we call edge cases: data that might be correct or incorrect, but is very much on the border of one or the other. These might also be very unusual things that you think will never happen. But I tell you, they do happen, so you need to test for them.
When you test a feature in one area, make sure it doesn’t break something else in another area. On the first mistake or problem, send it back to the developer to be fixed. Again, that might be yourself. Maybe you just type another prompt to fix it. That’s fine.
Make sure you’re fixing these things as you go, or keeping a log so the most egregious ones, the worst ones, can be fixed first. You might find that as you fix some of the bigger problems, the small ones start to take care of themselves.
Be aware that when you say your software is done, it’s not completely done. There are always going to be small errors, bugs, and things you would prefer weren’t that way. Testing is ongoing, including getting feedback from users.
Automated Testing
The other type is automated testing. As your LLM writes features, it writes its own tests. For example, if it’s just written the login page, it might write a test to make sure the login page works. These tests can be simple. They don’t have to be very complex. The idea is to help make sure the whole application works.
Every time something is completed, have your LLM run those automated tests to make sure it hasn’t broken other parts of the application.
You’ll all have experienced this. You build something and think it’s working well. You add a feature that looks good in itself, but then you test something else and realise it’s broken something somewhere else. You might not even notice straight away. It might take a while to find out. Writing automated tests picks up some of these things.
Automated testing isn’t enough by itself, but get the LLM to build the tests. It’s no extra pain for you. There are a few extra tokens, of course, but it’s not that bad. It’s very necessary and a usual part of software development.
Security Is Something You Should Definitely Overthink
Oh my goodness, security. Security is something you should definitely overthink. There might be legislation around the area you’re preparing the application for. Even if there isn’t, security is still important.
If there’s a login screen, how are the passwords being stored? How are they being put into the database? Can a user accidentally access another user’s information? Can employees access users’ private information when they shouldn’t? Can the database be incorrectly accessed?
Where are you storing secret keys? You might not even know what they are, but how you store them is extremely important. They might give access to APIs or root access to the database, which you do not want to leak. Find out what they are, where they should be stored, and who should have access to them.
The thing about security is that you don’t necessarily notice when it’s not right, because the application will work. In fact, it might even work faster and better with lower security. You might not find that out by using it and testing it yourself.
You can specifically ask the LLM: “Check this application for security. Have I done anything wrong? Can this application be hacked?” Be aggressive about that. But know what to test for. Ask it specifically to test the login. Ask it specifically to test the database security.
Choose a Technology Stack You Can Understand and Maintain
Ask for a technology base, what we call a stack, that can be understood, run and maintained by you.
Of course, you can have your LLM write in programming languages you don’t understand directly by reading them, and that’s okay. But you also need to understand a little bit about what they’re doing. If you ask the LLM to run you through a particular piece of code, you can figure it out that way.
Make sure you understand what each part of the stack is doing. What is the infrastructure doing? What is this part of the code doing? Why do I need these different things? What are the different folders? You might need to understand some of those things so you’re not overbuilding or building the wrong thing.
Think about building in a language that’s going to grow with you, if that is the purpose. Latency might be an issue if you’re thinking of a big application. If you’re thinking of something small, you might want something a little easier to understand or write, or a bit easier on your token use.
Have a think about those things. Rewriting an application is a bit more trivial than it used to be, but it can still be something you might not want to get into.
Think About the Infrastructure
Infrastructure is very, very important. Don’t just assume you can deploy to Cloudflare or Render. Of course you can do those things, but think about costs, the right tooling, and where the server is located. Some of these things are very important.
For example, I’m in Australia, and there are some things the Australian government says you must store in Australia. Because of that, you’ve got to ask: where is that database located? Am I serving it from the right place? Am I storing it in the right place? Am I breaking any laws by setting up a database elsewhere?
Understanding the difference between your server and your database is another thing to think about.
Look After the Data Itself
The database needs attention all of its own. This is where the information is kept. The code is crunching, analysing and writing the data, but the database is where it sits, where it lives.
It might be in quite a separate location. You might have your server over here, and another company might be looking after your database over there.
What type of database are you going to use? Postgres? MongoDB? There are many different types, and you want to use the best type for your application. Again, you can interrogate your LLM: “Which database do you suggest I use for this?” Make sure it’s the right one. Maybe start as simple as you can. There are simpler options you can use.
Make sure the database is secure, because it will hold data you don’t want leaked. Ensure the keys for the database are properly stored. Make sure it’s fast enough for you.
Make sure it can be recovered, so you might need to back it up. Databases do fail from time to time, and if yours gets hacked, you might lose everything and have to recover it. Think about this as well. If you think it will never happen to you, it might.
Even if there’s a one-in-a-hundred-thousand chance the database falls over, think about it. It could just be one bad piece of code from your LLM. They’re not perfect, like us. That one piece of code might drop an entire table. I don’t know, and neither do you.
You should have some way of backing up your data. That’s not the same as the code, and it’s not the same as the server. It’s your database. That needs to be recoverable as well.
Maybe it needs to be backed up once a week. Maybe the data’s not written that often and it’s once a month. I don’t know, but make sure you have it available if the worst occurs. If you’re serving from home, back it up twice.
User Interface and User Experience
User interface and user experience, UI and UX, are important. This is how the application looks on a screen, how it operates for your user, and how they go from one screen to the next.
Is it intuitive? Is it easy? Does it make sense? Can it be used by a whole range of people?
This is often a point that can be forgotten. Think about who your users are going to be. If it’s the general public, accessibility needs to be a concern.
Maybe it’s an application that will be used mostly by older people. Make the font larger. Make the contrast better. Allow for light and dark.
Light and dark screens are not just there because some people like to look at dark screens at night. Different contrasts are important for people with different levels of eyesight, and you’ll need to understand that if you’re building a large-scale application.
Perhaps you need to make sure screen readers can move through the application sequentially. Prompt your LLM to do these things. Making an application public and selling it worldwide could cause problems if it has accessibility issues.
Again, how easy is it for someone? Are there too many steps to get something done? Is it impossible to get something done? Are users being asked the wrong questions at the wrong time? Think about all of these things when you’re building your website, and read some articles about the subject if you need to.
This is something LLMs are still very bad at. Perhaps in a year’s time that statement won’t make sense, but for now they’re very bad at UI and UX. You notice it because LLM-built applications all look the same until you start prompting them to do things differently.
In fact, UI and UX are things you design at the very start. Maybe this should have been higher in the list. It means the application is built right to start with, and you don’t have to fix it later. You can if you want to, but building it right from the start is better.
Who Looks After the Application After It’s Launched?
Once it’s launched, that’s not the end. All applications need maintenance. I don’t care what the application is. If it’s simple, perhaps that maintenance won’t be very frequent, but it will come up from time to time.
Applications have dependencies. These are libraries of code that LLMs pull from known repositories and use.
For example, if you’re building the login screen on your booking app, the LLM isn’t going to need to build a whole login screen from scratch. Login screens have already been written a thousand times over. You don’t need to rewrite that. It can pull in a library: “Here’s a login screen. Great, let’s use that.”
What if the library it chooses has a security vulnerability that’s found later? It needs to be patched. How does it get patched? Someone needs to write that patch, not you, someone else, but your LLM will have to pull in that corrected code and apply it.
It’s not as frequent as it has been with some applications and tools we’ve used in the past, such as WordPress. But if you’re writing an application of any size, you’ll need to think about it from time to time.
Server maintenance is another one. Otherwise, you might find yourself spinning up too much and wasting a lot of money.
Or you might have lots of users because you’ve run a great promotion. Lots of users are hitting the application, so you need to increase the number of servers or the resources they’re using, but maybe only temporarily.
All of these things need to be managed on an ongoing basis, along with backups, security and the other things I’ve talked about. A live application is not the end of the road. This is part and parcel of what software developers have always done. If you’re a vibe coder selling to the general public, you’ll need to think about these things as well.
The Questions to Ask Your Developer
I’m not just talking to developers, or people who now see themselves as developers. I’m also talking to people who are contracting others to write software for them. Everything in this list is appropriate to ask your developer.
Where are you going to store my code? How are you going to ensure it’s secure? How are you going to run the infrastructure and make sure I don’t overspend? How are you going to keep the login screen secure? When are you going to do the backups? How much is this maintenance program going to cost me from month to month?
These are all things you’ll need to ask, get good answers to, and make sure you understand. A developer should be able to answer all of them.
And now, talking to the developers again, you’re moving from someone who writes code to what I would call a software engineer: somebody who starts to work with this whole body of how you develop an application.
Just knowing how to write code, or how to prompt an LLM to write code, is not enough. It’s like building a house: “I know how to lay some bricks,” or “I know how to instruct someone else to lay some bricks.” But what about the rest of the house?
All of that can be done. You can instruct other people, or the LLM, to do these things, but you need to know to ask those questions. That’s the point of what I’m trying to discuss.
If you have any questions, or need to know how to do some of these things a little better, get onto me. I’m happy to throw you a link or two and show you. But just ask your LLM.
