AI can help a developer produce code faster. Before that code goes live, you still need someone to review it, test the business rules and take responsibility for keeping the software running.
The demonstration looks good. The screens are there, the buttons work and a process that sounded complicated now seems almost finished. Then come the less visible questions: can one customer see another's records? What happens if a payment update arrives twice? Who fixes the system after launch?
These questions matter whether the code was written manually or with AI assistance. If you're commissioning software in the UAE, judge the delivered work by the evidence behind it—not just how quickly the first version appeared.
There should be a person who understands the build
Ask who owns the architecture and who reviews changes. An explanation that “the AI wrote it” doesn't answer a maintenance question or resolve a defect. The development partner still needs to stand behind the agreed result.
You don't need to inspect every line yourself. You do need to know which parts are custom, which depend on outside services and who will look after those dependencies. Someone should be able to explain the important decisions without asking the original coding tool to reconstruct them.
Test the awkward cases, not just the demonstration
A purchase portal may look complete when a request goes through normally. Try an unauthorised approval, an accidental double submission or a cancelled request. Check that the data is saved to the correct account and survives a restart.
Write these acceptance scenarios before approving the build. Link the results to the requirements so you can see what was tested. A large test count isn't especially helpful if nobody can explain which business risks those tests cover.
Ask what remains untested as well. A useful handover is honest about its limits.
Another AI review isn't the final sign-off
AI review can suggest useful changes, but an accountable engineer still needs to inspect the implementation and its tests. GitHub's responsible-use guidance makes the same broad distinction: coding assistance supports programming judgment; it doesn't replace it.
Review authentication, record-level permissions, inputs, file access, secrets and error handling. Check dependencies too. A package may have been introduced because it helped generate a feature, but it still needs a reason to stay and an owner for updates.
| Area | Ask to see | Be cautious if |
|---|---|---|
| Functionality | Tests tied to your requirements | There is only a demo |
| Security | Access and failure-path tests | Hiding a button is treated as a permission check |
| Ownership | Repository and account handover | Only the supplier has access |
| Operations | Deployment and rollback instructions | Recovery hasn't been considered |
Agree what the coding tools may access
Production credentials and real customer records shouldn't be copied into prompts just to make development easier. Use synthetic or minimised test data where possible, and agree which repositories and services the tools may access.
Have the appropriate people review provider terms, retention and organisational policy. Different tools don't necessarily handle information in the same way. The approved arrangement should be clear to the people doing the development, not left as an assumption in a proposal.
Know how you'll recover from a bad release
A test environment and controlled deployment process matter as much for AI-assisted work as for any other development. Check configuration, backups and database migrations. Restoring an older frontend file won't undo every data change.
After launch, someone needs to watch the important journeys: sign-in, enquiries, payments and scheduled jobs. Agree who receives an alert, who investigates and how the team rolls back or repairs a failed change.
Think about the next team, too
If another developer takes over in a year, will they have the code, access, documentation and a reproducible environment? That's a more useful ownership test than asking which model produced the original implementation.
When discussing software development with Gligx, bring the process you want to improve and the mistakes the system must prevent. For website work, the project-brief checklist can help organise those requirements. A first consultation can then establish what you should expect to see before launch.
Sources and further reading
References checked on 23 October 2026.
Frequently Asked Questions
Is code written with AI automatically a risk?
Judge the implementation, not just how it was produced. Both AI-assisted and manually written code need review, testing and maintenance.
Can an AI code review replace an engineer's sign-off?
No. It can offer useful feedback, but accountable engineering review and appropriate tests are still needed before production changes.
What should we ask for before accepting the software?
Ask for results tied to your requirements, security checks, dependency records, account and repository handover, plus deployment and recovery instructions.
Can the developer use our customer data in coding tools?
Only within explicitly approved handling arrangements. Prefer synthetic or minimised test data and review tool access, retention and repository permissions.