Almost every client asks it in the first meeting now: do you use AI to write code? The honest answer is yes, every day, under written rules. Coding assistants draft the repetitive parts of our work, the tests, the documentation and the first pass at a log investigation. They do not decide how a system is structured, and nothing they produce touches payments or personal data without an engineer reading it line by line. This article sets out where AI helps us, where we stop it, the rules that govern it, and why that matters to you as a business owner even if you never open a code editor.
Where AI assistants help us
Every software project contains two kinds of work: work that needs engineering judgement, and work that needs patience. AI shortens the second kind. These are the tasks where we use it on most projects:
- Boilerplate. Forms, field validation, list screens with search and pagination, clients for a documented third-party API. The assistant drafts in minutes what used to take an afternoon, and the engineer edits it to match the project's conventions.
- Tests. We write the first test for each component by hand to set the style, then ask the assistant to cover the edge cases: empty values, negative numbers, long Arabic strings, concurrent requests. Test counts on our projects went up without the hours spent writing them going up.
- Database migrations. Turning a required schema change into a migration file with its rollback, then checking it against a copy of real data on staging before it goes near production.
- Documentation. Function descriptions, OpenAPI specs for the endpoints we expose, and a first draft of the user guide. The draft is the assistant's; the accuracy is ours.
- Log analysis. When a client's server throws a 500 at three in the morning, an assistant condenses thousands of lines into two or three hypotheses in a minute. The engineer verifies them; it does not take them on trust.
- Translation drafts. A bilingual interface has hundreds of short strings. The assistant drafts them, and a native speaker reviews every one before a user sees it.
What these have in common: each has an answer that can be checked quickly. If the assistant gets a test wrong, the test fails. If it gets a migration wrong, staging shows it. The mistakes here are cheap and visible.
Where we do not use it
Some decisions have mistakes that are expensive and slow to surface. Those stay with the engineer no matter how confident the tool sounds:
- Architecture. How services are split, where module boundaries sit, when a job queue is needed and when a table is enough. An assistant will produce a structure that works in a demo and collapses at the first thousand real users, because it does not know your data volume, your hosting budget or who will run the system a year from now.
- Security decisions. Permission policy, password storage, authentication, rate limits. We write these by hand and review them with a second pair of eyes, because generated code tends toward the solution that works rather than the one that is safe.
- Anything that touches payments. Gateway integrations, tax calculation, e-invoice generation. Every line here is written or reviewed by an engineer who knows what a one-piastre rounding error in a tax invoice means.
- Personal data. What is stored, for how long, and who can see it. The assistant does not know which data protection law your business falls under. We are responsible for knowing.
This does not mean the assistant is banned from those files. It means whatever it produces there is treated as a draft from a junior developer: read in full, line by line, before it reaches the main branch.
Our four rules
The tools change every few months. The rules do not. Every engineer at Web Pioneer works under these four, the wider framework is on our trust page, and the delivery process they sit inside is described in how we work:
- AI-assisted changes go through the same gate as everything else. Code review by a second engineer, automated tests, a staging environment the client can open, then production. There is no fast lane for generated code. If anything, we read it more carefully, because generated code looks more correct than it is. The gate itself is described on our software testing and QA page.
- No client data in third-party models without a written agreement. Customer tables, invoices, chat transcripts, logs containing phone numbers: none of it is pasted into an external tool. When we analyse logs, identifiers are masked first. If a project genuinely needs real data processed by an external model, that becomes a contract clause naming the provider and its terms.
- Secrets never leave the environment. API keys, database passwords, payment gateway certificates live in environment files on the server and nowhere else. Coding assistants work in repositories that contain no secrets, and an automated check blocks any key from being committed by accident.
- The engineer signs off, not the tool. Every change carries the name of an engineer who is responsible for it and can explain it in the weekly review without opening the assistant. If they cannot explain it, it does not merge.
What this means for you as a client
Three practical things. First, the first version you can click through arrives sooner than it did two years ago, because the weeks that went into standard screens and documentation are now days. Second, the quality gate has not moved: review, tests, staging and the weekly session with you are exactly as they were, and that gate is what you are actually paying for. Third, when you ask which parts were AI-assisted and which were written by hand, you get a straight answer. We do not treat it as a trade secret.
What it does not mean: the price does not halve. The part AI compresses was already the cheap part of a project. The expensive part, understanding your business, making the structural calls, and running the system after launch, still needs engineers who are accountable for the outcome.
The vibe coding trap for business owners
In 2026 anyone can describe an app idea to an AI tool and have something running on their screen within the hour. The popular name for this is vibe coding. We have seen how it ends, because the business owner arrives six months later saying: the app worked, then it stopped, and nobody knows why.
A demo that works is not a system that runs. The difference is everything you cannot see on the screen:
| What looks ready | What is actually missing |
|---|---|
| Screens that work when you try them | Tests proving they still work after every change |
| Data that is saved | Scheduled backups that someone has actually restored from |
| An app deployed on a server | Monitoring that alerts a person when it stops, and a person who answers |
| A login screen | A permission model, encryption, and routine security updates |
| A payment that goes through | Handling for failures, refunds and reconciliation with the gateway |
| Code that exists | An owner who understands it and can change it a year later |
Generated code without a responsible engineer is not an asset you own. It is a liability of unknown size, and the cost of repairing it is usually higher than the cost of building it properly in the first place, because nobody documented what was built or why.
We say this while using the same tools. The difference is not the tool. It is the presence of review, tests, backups, monitoring and an owner. If you are testing an idea for yourself, vibe coding is an excellent way to do it. If your customers will pay through it, it is the starting line, not the finish.
A checklist to ask any vendor about AI use
Do not ask a vendor whether they use AI. The answer will be yes or no and will tell you nothing. Ask about the rules:
- Does AI-assisted code go through review by a second engineer before it merges? Who signs off on it?
- Are there automated tests that run on every change? Can I see the report from the last run?
- Do you paste my data or my customers' data into external tools? Where does the contract say so?
- Where are my project's keys and passwords stored? Has a key ever ended up in the repository?
- Who owns the code after payment, and could another team understand it from the documentation alone?
- Which parts do you always write by hand? (If the answer is none, that is answer enough.)
- What happens after launch: who monitors, who restores a backup, who responds when it goes down?
- If I ask, will you tell me which parts were AI-assisted?
A vendor who answers these clearly is using AI for your benefit. One who dodges them is using it for their margin.
How our own AI services differ from this
Everything above is about tools we use internally to deliver ordinary software with higher quality in less time. It is separate from the services we build for clients using AI itself, where the same four rules apply plus a further set about data:
- AI chatbots: automated replies on WhatsApp and your website that answer from your real data rather than from imagination, and hand over to a person when they cannot.
- AI agents: assistants that carry out defined tasks inside your systems, with limited permissions and a log of every action.
- AI automation: processing invoices, orders and repetitive messages under rules that can be audited.
- AI consulting: working out what in your company is worth automating and what is not, before you pay for any tool.
In these services the first question is always: where does your data go? We choose with you between an external model under a data processing agreement and a model running on your own servers, depending on how sensitive the data is and what the budget allows. The answer is written into the contract, not left as a verbal promise.
If you are evaluating a vendor now, or you have a working demo and want it turned into a system that runs, talk to an engineer. We will review what you have and tell you in writing what is missing and what it costs.
