AI coding assistants such as GitHub Copilot, Cursor, Claude Code and Gemini Code Assist are now part of everyday work for many development teams. According to the Stack Overflow Developer Survey 2025, 84% of developers use them or plan to; the same survey found that 46% do not trust the accuracy of their output, against 33% who do.
So for a company the real question is not whether to use them, but how to use them without lowering the quality of the software it delivers. In our projects we start from a simple principle: the AI suggests, a person decides. Code that goes to production passes the same checks, whoever or whatever wrote it.
Here is where these tools help, where they cause damage and which rules keep quality high.
Where AI really helps
Assistants do their best work on tasks whose results are easy to check:
- Repetitive code: the so-called boilerplate, the structural parts that always look the same (data classes, mappings, configuration, API calls).
- Tests: suggesting test cases, including the edge cases people tend to forget. Generated tests must be read: a test that confirms the wrong behaviour is worse than no test at all.
- Refactoring: restructuring code without changing what it does, for example extracting functions or updating how a library is used, in small steps.
- Documentation: comments, READMEs, pull request descriptions, release notes.
- Legacy code: getting an explanation of a function written years ago, with no documentation, by someone who has since left. It is one of the most useful and least risky uses, because it changes nothing.
Where it causes damage
The main risk is plausible but wrong code: it compiles, it looks reasonable, and it hides a logic error, a missing check or a library function that does not exist. In the Stack Overflow survey the most common frustration, cited by 66% of respondents, is exactly this: AI solutions that are “almost right, but not quite”.
- Security: for Veracode’s 2025 GenAI Code Security Report, more than 100 language models completed 80 coding tasks; in 45% of cases the code they produced contained a vulnerability from the OWASP Top 10 list.
- Licences: a suggestion may reproduce parts of open source projects whose licences come with obligations. Some tools offer a filter for suggestions that match public code: switch it on.
- Confidential data: pasting an access key, personal data or a client’s code into a prompt means sending it to an external service, under retention and usage terms that depend on your contract.
- Assumed productivity: in a controlled study by METR (July 2025), 16 experienced open source developers working on projects they knew well took 19% longer with AI, while believing they had been faster. The sample is small and the tools were those of early 2025, but the lesson holds: productivity has to be measured, not taken for granted.
The rules that keep quality high
Human review on everything
Every change goes in through a pull request, a merge request that a colleague reviews before it is accepted. Whoever opens it must be able to explain every line, including the ones the assistant suggested. Whoever reviews it checks logic and edge cases, not just style.
Automated tests and continuous integration
CI (continuous integration) is the automated process that builds the project and runs the tests on every change: if something breaks, the merge stops. Code without tests does not get in, whether it was typed by hand or generated. In the Angular front end we built for SIMOGE, for example, unit tests are written with Jasmine and Karma.
Static analysis and security
Linters check style and common mistakes; static analysis tools such as Semgrep and SonarQube look for vulnerable patterns and duplicated code; a dependency scanner flags libraries with known vulnerabilities. That last one matters a lot with AI, which can suggest outdated or even non-existent packages. All these checks run on every change and block the release on serious findings.
Approved tools, data kept out of prompts
- Company-approved tools only, under a contract that makes clear where the data goes and whether it can be used to train models.
- Central settings: public code filter on, sensitive files excluded from the assistant’s context, company accounts rather than personal ones.
- No secrets in prompts: passwords and keys live in a secrets manager or in environment variables, never in the code, and a scanner checks every commit.
- No personal data: GDPR rules still apply when you ask a model to help with a bug.
- Client code: used with AI only if the contract allows it, and only with the agreed tools.
The developer stays responsible
Delivered code carries a developer’s name, not a model’s. That is why AI does not replace expertise: if you cannot assess a solution, you should not accept it. For people early in their career, an assistant can be an excellent teacher, as long as they use it to ask for explanations and not just answers.
In practice this means training on how to use the tools, written rules the whole team shares, and the same quality thresholds for all code. That way AI speeds up the repetitive work and leaves more time for what needs judgement: architecture, security, and talking with the people who will use the software.
If you are bringing AI assistants into your team, or looking for a team that already works with them under these rules, let’s talk. You can see what we do on our services page.
