AI code assistants: how we use them and where we do not
How AI assistants fit into the way we write software for clients, what they speed up, and what we never delegate to them.
The short answer
AI code assistants have become part of how software is written, including by us, and clients are right to ask what that means for their projects. We use them for the mechanical parts of the work: generating boilerplate, writing tests for code a developer has designed, refactoring safely, drafting documentation, explaining unfamiliar or inherited code, and producing the first version of a well-specified function. Those tasks are faster with an assistant and the time goes to the parts that need judgement. We do not use them to decide architecture, security boundaries, data models or what to build, and nothing they produce reaches a client’s repository without being read, understood, tested and owned by a developer, exactly as any code always has been. Client code and data are never sent to a tool whose terms allow training or open-ended retention; the tools we use run under agreements that keep your code yours. The result is more time on design and review at the same standard. The risk in the industry is the partner who ships what the assistant produced without either.
Where assistants help and where they do not
| Task | Assistant used? | How |
|---|---|---|
| Boilerplate and repetitive code | Yes | Generated from a specification, reviewed |
| Tests for designed code | Yes | Drafted, then reviewed for what they actually assert |
| Refactoring | Yes | Proposed changes, verified by tests and review |
| Documentation | Yes | Drafted from code and comments, edited |
| Understanding inherited code | Yes | Explanations checked against behaviour |
| First version of a well-specified function | Yes | Reviewed line by line |
| Architecture and data model | No | Decided by people, documented |
| Security boundaries and authentication | No, beyond drafting | Designed and reviewed by people; tested |
| Deciding what to build | No | The brief, the users and the client |
| Anything touching secrets or personal data | No assistant access | Kept out of tool context |
| Final review and merge | Never delegated | A person, accountable |
Our rules
- Tools under agreements that exclude training on client code and limit retention; no consumer tools for client work.
- No secrets, credentials or personal data in any assistant context.
- Assistants draft; developers decide. Every suggestion read and understood before acceptance.
- Tests are the check: assistant-written code passes the same tests and review as any other.
- Architecture, security and data models are designed by people and documented.
- Dependencies suggested by an assistant are verified to exist, be maintained and be appropriate before use.
- The repository is the record: commits are authored and owned by developers, with the same standards of message and review.
What it means for your project
More of the developer’s time on the things that determine whether software works for you: understanding the problem, designing the model, securing the boundaries, reviewing and testing. More tests and better documentation, because the tedious parts of both are now cheap. Faster takeover of inherited code. And no change to what you own: the code in your repository, written and accountable to named people, under terms that keep it confidential.
What this means for you
We use AI assistants for the mechanical parts of writing software and keep people on the decisions, the review and the ownership, under tool agreements that keep your code confidential. The effect on your project is more time on design and testing at the same standard of accountability. Ask your partner the three questions above, and judge them by the specificity of the answers.
Frequently asked questions
Does using AI assistants mean our software is written by AI?
No. It means the developers writing it type less of the repetitive parts and spend more time on design, review and testing. Every line that reaches your repository has been read, understood and tested by a developer who is accountable for it, exactly as before. The assistant is a faster keyboard with suggestions, not an author.
Is our code sent to an AI company?
Only under terms that prohibit training on it and limit retention, through enterprise agreements, and never client secrets or personal data. We treat your code as confidential and choose tools accordingly. Ask any partner which tools they use, under which terms, and whether client code is excluded from training; the answer should be immediate and specific.
Does it make the software better or worse?
Better where it is used for what it is good at: more tests written, more documentation kept current, more thorough refactoring, faster understanding of inherited code. Worse where a developer accepts suggestions without reading them, because assistants produce plausible code with subtle mistakes and outdated patterns. The difference is the review discipline, which is why we treat assistant output as a draft from a fast junior colleague.