Independent AI-Generated Software Review
You have built working software with AI. Now make sure it is ready for your business
A review service just for AI-created code
AI coding tools can turn an idea into a working application remarkably quickly. You may already have a customer portal, internal database, booking system or operational tool that does something genuinely useful.
That is an achievement.
Before you launch it, connect it to live data or make your business dependent on it, an experienced developer should check what sits behind the screen.
Evergreen provides independent AI-generated software reviews for UK businesses and charities. We examine the code, test the application and explain what needs attention in plain English. You will know what is safe to use, what should be improved and what must be corrected before the software goes live.
Is AI-generated code safe?
AI-generated code can be safe, but the fact that an application works does not prove that it is secure, reliable or ready for everyday business use.
A login page may accept the right password while containing a flaw that allows somebody to bypass it. A customer portal might show the correct information but fail to prevent one client from seeing another client’s records. An internal application may work perfectly for ten people and fall over when two hundred try to use it.
These problems are often invisible during a demonstration.
AI coding tools are good at completing the immediate task. They do not always understand the wider business, security and regulatory context in which the software will operate.
What is an AI software audit?
An AI software audit is an independent review of software created with AI coding tools. It assesses whether the application is secure, functions correctly, handles data appropriately and can be maintained as the business becomes more reliant on it.
The review can cover software created with tools such as Claude Code, Gemini, ChatGPT, GitHub Copilot, Cursor, Lovable and Replit, whether AI produced the entire application or helped you build parts of it.
We start by understanding what the software does, who will use it and what would happen if it failed. A simple internal tool presents different risks from a customer-facing portal holding personal or financial information. The review is shaped around the application and the way you intend to use it.
You receive a prioritised report separating critical launch blockers from desirable improvements. We will not hand you a long technical document and leave you to interpret it. We explain what we found, why it matters and what should happen next.
What can go wrong with AI-generated code?
AI-generated software can appear finished while containing weaknesses that only emerge under pressure, during an attack or after somebody tries to change it.
Users can gain access to information they should not see
A system can have a working login without having effective access controls.
We review authentication, user permissions and data separation. This includes checking whether different users, customers, teams or organisations are properly isolated from one another.
For example, changing a part of the web address should never allow one customer to open another customer’s account. Nor should a standard user be able to reach an administrative function simply because the button has been hidden from view.
The software can behave differently when something goes wrong
AI coding tools tend to concentrate on the “happy path”, where users enter the expected information and connected services respond correctly.
Real users leave fields blank, paste unusual characters into forms and click twice when a screen appears slow. Internet connections disappear. Payment services time out. Two people update the same record at once.
Functional and exploratory testing deliberately puts the application through these awkward situations. We check whether it responds safely or leaves behind missing records, duplicate transactions and half-completed processes.
A third-party package can introduce security or licensing problems
AI tools often rely on external software packages to complete a task. Some may be out of date, unsupported or affected by a known security vulnerability. In some cases, AI can suggest a package that does not exist, leaving an opening for an attacker to publish malicious code under the invented name.
There can be a commercial problem too. A genuine open-source dependency may carry licence conditions that restrict its use, require attribution or oblige you to disclose related source code.
Our dependency, licence and software-supply-chain checks establish what your application relies on and whether those choices could create a security, ownership or commercial risk.
The application can struggle when more people use it
A demonstration with a few users and a small amount of data tells you very little about how the application will perform at scale.
Performance and stress-testing recreate more realistic use. We look for inefficient database requests, slow processes and parts of the application that consume far more computing capacity than they should.
The aim is to find out whether your software can support the number of users and records you expect, rather than discovering its limit on a busy Monday morning.
Nobody can safely change the code
AI can solve a tightly defined problem without considering how that feature fits into the rest of the application. The result may work today but become difficult and expensive to maintain.
The same business rule might be repeated in several places. One small change could break an unrelated process. There may be little documentation and no automated tests to warn the next developer that something has gone wrong.
We assess the architecture, source code, automated test coverage and technical debt. You will find out whether another competent developer could understand, support and extend the software without having to reverse-engineer it first.
How do I know if my AI-built software is secure?
The only dependable way to know whether an AI-built application is secure is to inspect the code and test the running system.
A manual source-code and architectural review looks for weaknesses in the way the software has been designed and written. This is more effective than a penetration test that only approaches the application from the outside. This can identify known problems, but it cannot always understand how a particular permission, workflow or piece of business logic could expose information.
Depending on the application, we can examine:
- Login, password reset and account recovery processes
- Multi-factor authentication and session management
- User roles and administrative permissions
- Separation of customer and organisational data
- Application programming interfaces, commonly called APIs
- Input validation and protection against common attacks
- Exposed passwords, keys and configuration details
- Vulnerable or unsupported software packages
The result is a practical assessment of the application you have built, not a generic security score.
Can you review UK GDPR compliance in AI-built software?
Yes. A UK GDPR software review examines how the application collects, stores, uses, shares and deletes personal information.
Software alone cannot make an organisation compliant. Your lawful basis, privacy information, internal policies and working practices also matter. However, the application must support those responsibilities rather than undermine them.
We can review whether access to personal or sensitive information is properly restricted, whether unnecessary data is being collected and whether retention and deletion requirements can be followed.
We will also consider where information is stored, what is recorded in system logs and whether users’ actions can be traced when necessary.
There is a second issue to check. During development, somebody may have pasted customer records, database structures, API keys or confidential business information into an AI tool.. We would check the code to ensure the API keys are stored outside the reach of AI and recommend all keys are rotated to prevent this.
What does an independent AI code review cover?
The scope depends on the software, how it will be used and the consequences of something going wrong. An AI code review for a small internal tool will not need the same level of assurance as a public application holding sensitive customer data.
A review can include four connected areas.
1 – Is the software built properly?
We manually examine the architecture and source code to see whether the system has a sound structure. We also assess documentation, automated test coverage, duplicated logic and technical debt.
This tells you whether the application can be maintained and developed sensibly, or whether every future change is likely to become harder than the last.
2 – Does it work outside the demonstration?
We carry out functional and exploratory testing across real user journeys, including invalid information, interrupted processes and unexpected behaviour.
Where scale matters, we can also test performance and load. This establishes how the application responds as user numbers and data volumes increase.
3 – Is the application secure and handling data correctly?
We examine authentication, permissions, data separation, application interfaces and sensitive-data handling. Where appropriate, this can include penetration testing of the application and its APIs.
We also review dependencies, known vulnerabilities and licence obligations that could affect commercial use.
4 – Could the business recover when something fails?
Backups are useful only if they contain the right information and can actually be restored.
We review backup and recovery arrangements, system logs, error reporting and monitoring. The purpose is to establish whether you would know when the application had failed, understand what happened and be able to restore service without losing important data.
What will I receive after the review?
You will receive a prioritised report that distinguishes urgent risks from sensible improvements.
Findings are normally grouped into:
- Critical launch blockers: issues that should be corrected before the application handles real users or live data
- High-priority risks: weaknesses that could affect security, reliability, compliance or business continuity
- Maintainability improvements: changes that will make the software easier and less expensive to support
- Desirable improvements: useful work that can be planned without delaying an otherwise safe launch
We will talk you through the findings. If something is technically complicated, we will explain the business consequence rather than expecting you to learn software engineering terminology.
Once defects have been corrected, Evergreen can retest the affected parts of the application and confirm whether the original findings have been resolved.
Will I have to give Evergreen my source code?
A meaningful AI code review usually requires access to the source code, but how that access is provided, protected and removed should be agreed before any files are shared.
We understand that your source code contains valuable intellectual property and may reveal confidential business processes, connection details or security controls. You should know exactly who can access it, where it will be stored and what happens to every copy after the work is complete.
Before the review begins, we will agree:
- Whether access will be provided through your existing private repository or another secure method
- Which members of the review team need access
- What supporting credentials or test data are required
- How the code and related information will be protected
- When access will be withdrawn
- How downloaded copies and supplied credentials will be deleted
We will not ask you to send a valuable codebase through an unsuitable file-sharing service or leave access open indefinitely.
If you are not comfortable granting full access at the outset, talk to us. We can discuss the application, the available evidence and a sensible first stage before you commit to a wider review.
Will Evergreen insist that the application is rebuilt?
No. An AI software audit should establish what condition the application is in before anybody recommends a rebuild.
Some AI-built applications have a sound idea and need only focused improvements. Others work well as prototypes but should not yet hold live customer information. Occasionally, the safest and most economical decision is to rebuild part or all of the system.
We will tell you which position applies and explain the evidence behind it.
The purpose of the review is not to criticise the work you have done or turn every finding into a development project. It is to help you make the next decision with your eyes open.
Why ask Evergreen to review your AI-generated software?
Evergreen has been building bespoke software for UK organisations since 1999 and has delivered more than 400 software projects. Founder Andrew Cope has over 30 years’ programming and database development experience.
Our developers know what it takes to move software from an interesting idea to a dependable business system. We design architectures, write code, manage data, test awkward user journeys and support applications after they go live.
That practical experience matters. Reviewing software is not simply a matter of running a scanning tool and listing everything it flags. It takes judgement to distinguish a genuine business risk from a theoretical concern, and to recommend a proportionate response.
We also work directly with business owners and managers who do not want to be talked at in technical language. You will have clear advice, direct access to experienced developers and an honest assessment of what you have built.
For more detail on Evergreen’s position, read Andrew Cope’s article: AI Can Build Your Software. But Who Is Checking Its Work?
How much does an AI software review cost?
The cost of an AI software review depends on the size and complexity of the application, the sensitivity of the data and the depth of testing required.
A small internal tool with a limited codebase will take less work to assess than a customer-facing platform with several user roles, external integrations and payment or personal data.
We will first discuss what you have built and how you intend to use it. We can then recommend an appropriate scope and provide a clear proposal showing what will be reviewed, what you will receive, the timetable and the agreed cost.
You pay only for the work agreed. Evergreen follows this same individually scoped approach across its bespoke software projects.
When should AI-generated software be reviewed?
AI-generated software should be reviewed before it holds live data, accepts payments, becomes customer-facing or takes over an important business process.
A review is also sensible when:
- A prototype is being prepared for launch
- A potential investor or customer has asked security questions
- The application will process personal or sensitive information
- More staff or customers are about to start using it
- The original creator is leaving the business
- Frequent changes are causing unexpected faults
- Nobody can explain how the whole system works
- You are considering further investment and need to know whether the foundations are sound
The earlier weaknesses are found, the more choices you have about how to correct them.
Frequently asked questions
Can you review software built entirely with AI?
Yes. Evergreen can review an application built entirely with AI or software where AI was used to create particular features. We will need to understand the technologies involved, where the software is hosted and whether the source code is available.
What is a vibe coding review?
A vibe coding review is an independent technical assessment of software created mainly by describing requirements to an AI coding tool and refining the results through prompts. It checks whether the finished application is secure, reliable, maintainable and suitable for real users.
Can you review an application that is already live?
Yes. We can review a live application, although testing must be planned carefully to avoid interrupting users or affecting genuine data. Some security and load testing may need to take place in a separate test environment.
Can you fix the problems you find?
Yes. Evergreen can discuss correcting defects, improving the architecture, adding tests or completing the work needed to prepare the application for use. You can also use the report to brief your own developer or another supplier.
Do I need penetration testing for an AI-built application?
Penetration testing is advisable when an application is accessible online, exposes APIs or handles confidential, personal or commercially sensitive data. We will recommend a proportionate testing scope after understanding the application and its risks.
Does an AI software review guarantee that no problems remain?
No software review can guarantee that an application will never contain a defect or face a new security threat. A properly scoped review gives you evidence about its current condition, identifies material risks and shows what should be corrected before you rely on it.
How long does an AI-generated software review take?
The timescale depends on the size of the codebase, the number of user journeys, the testing required and the quality of the available documentation. Evergreen will agree the scope and timetable with you before work begins.
Will you keep my source code confidential?
Yes. Access, storage, confidentiality and deletion arrangements should be agreed in writing before the review starts. We will confirm who needs access, how the code will be protected and when access and retained copies will be removed.
Find out whether your software is ready
You have already turned an idea into something real. The next step is to find out whether it can safely support your customers, your data and your business.
Talk to Evergreen about an independent review of your AI-built application. We will listen, take an initial look at what you have and explain the most sensible next step.
Call 01454 269 087 or use Evergreen’s contact form for an informal discussion with one of the team. Evergreen’s office hours are Monday to Friday, 9am to 5pm.