Developing software with AI

AI coding assistants can make us faster: drafting a first version, writing the tests around it, explaining an unfamiliar piece of code, taking the boring edges off a task. We use them, and we use them openly. What does not change is who is accountable for the result. An assistant is a fast, tireless pair, not an engineer we can hand the blame to. Every line it writes ships under your name, and our bar for quality and security is exactly what it was before.

What it is

By an AI assistant we mean the tools built on large language models that sit in the editor or the terminal and help write, review or explain code: chat assistants, in-editor code completion, and the more autonomous agents that can take a task and run with it. They are good at producing plausible code quickly. They are not good at knowing whether that code is correct, safe, or the right fit for the problem in front of you. That judgement stays with the engineer.

When to reach for it, and when not

• Reach for it to scaffold something new, draft the tests, clear out boilerplate, explore an approach you are unsure about, get oriented in an unfamiliar codebase, or draft the first version of documentation and commit messages.
• Be more careful with security-sensitive code, anything touching money or personal data, cryptography, and any domain you cannot yet review with confidence. The assistant will produce all of these just as happily when they are wrong, and with the same conviction as when they are right.
• Check the engagement first. Some clients restrict AI tools, or allow only specific ones running on their own infrastructure. The client’s rules always win. If you are unsure whether a tool is allowed on a piece of work, ask before you paste, not after. See engagements.

How we do it here

• You own the output. Review what the assistant writes as critically as you would a colleague’s pull request, and understand every line before you accept it. If you cannot explain why it is there, it is not ready to merge.
• Keep changes small and reviewable, the same as any other work. A thousand-line diff nobody can hold in their head is not faster, it is risk deferred. See slicing work small.
• Never feed it what is not ours to share. No secrets, credentials or client data go into a tool the client has not approved for the purpose. Treat every prompt as though it could be stored and read by someone else, because it might be. This is part of secure engineering, and our information security policy applies unchanged.
• The same gates apply. AI-written code goes through the same continuous integration, the same tests, and the same definition of done as everything else. A green pipeline is still the bar, not a lower one.
• Mind the licence. Generated code can echo something that carries a licence. For anything substantial, satisfy yourself it is genuinely ours to use before it goes near a client’s repository.

Watch out for

• Confident nonsense. The failure mode is code that looks right, reads well, and is subtly wrong: an invented function, an off-by-one, a check in the wrong place. Plausibility is not correctness, and a fluent answer is not a checked one.
• Security holes delivered with a straight face. Injection, missing authorisation, secrets written to logs. Read AI-written code with the OWASP Top Ten in mind, not less carefully because a machine produced it.
• Big diffs, thin understanding. It is easy to accept far more than you could have written yourself. If you would not have been able to write it, do not merge it until you can follow it.
• Skill fade. Leaning on the tool for everything is how you slowly lose the ability to check it. Keep your own hands in the work, especially on the hard parts.

Used well, AI lets us spend less time on the mechanical and more on the judgement clients actually pay us for. That trade only holds while the judgement stays ours.