AI assistants write code fast, and we use them ourselves when building sites and bots. They are good at taking away routine: scaffolding, repetitive components, rewriting old code. But responsibility for what goes to production stays with the person who presses deploy.
Model output looks confident even when it is wrong. Below is what to check before launch when part of a project was written with AI. It is useful for developers and for clients who want to understand how their contractor reviews the work.
Small changes
The main rule: ask the assistant for small changes and read every one. When a model rewrites ten files at once, nobody reads it carefully, and a mistake ships along with the rest. One task, one clear diff, one review.
If you cannot explain a change in your own words, it is too early to accept it. “The assistant wrote it that way” will not help six months from now when something breaks.
Keys and passwords
Models happily paste keys straight into code if they saw them in the context. A bot token, the mail password for a form, a payment service key belong in environment variables or in a file that never reaches the repository. Before every commit, read the diff with exactly this in mind.
If a key does land in the repository, deleting it from the file is not enough, because it stays in the history. Revoke it and issue a new one at the service that provided it.
Dependencies
An assistant may suggest a library that does not exist, a package with a confusingly similar name, or a project abandoned years ago. Before installing, check that the package is in the registry, has a living repository, and a clear license. Every extra dependency is code whose updates you will have to follow.
Often the job takes a couple of lines without a new library. Ask the model about that directly. It frequently agrees.
Forms and anything users type
- Form data is validated on the server, not only in the browser
- Database queries use parameters, user text is never glued into SQL
- Output is escaped so foreign HTML cannot run on the page
- The form has spam protection and a rate limit
- File uploads are limited by type and size
These are the places where generated code most often looks fine and still lets too much through. An example from documentation or from a model usually shows how to do something, not how to do it safely.
When things go wrong
Model code usually describes the happy path. Check what happens when an external service does not answer, an email fails to send, or Telegram returns an error. The user should see a clear message, and you should learn about the failure from a log or an alert, not from a client a week later.
Checking by hand
A build without errors does not mean everything works. Open the site on a phone, send the form, walk the bot from start to finish. For what must not break, such as taking an order, write an automated test. An assistant drafts tests quickly, but the test should check what matters to you, not what is easy to check.
Where AI really helps
- Scaffolding pages and components from a clear pattern
- Rewriting old code into newer syntax
- Explaining an unfamiliar piece of code before you change it
- Drafts of tests and error messages
- Finding the cause of an error from a log
In all of these the result is easy to verify. Assistants do worse where a mistake is not visible right away: security, money, client data. There, treat the answer as a draft.
What to ask a contractor
- Who reads the code before it reaches the server
- Where the repository lives and whether you have access
- Where keys and tokens are kept and who can see them
- How the form, payment, and bot flow are tested before launch
Whether the contractor uses AI is a secondary question. What matters is a calm, specific answer to each of these points.
Where the repository, keys, and bot token should live is covered in the note on domain, hosting, and access. The kind of flow worth walking by hand is described in the note on a Telegram order bot. To discuss a project, use the contact form.