How Do We Embed AI Best Practice Into Daily Coding?

Most technology teams in financial services have already run a training session on AI coding assistants.

Fewer have worked out what happens the next day, when a developer is under delivery pressure, a pull request is waiting for review, and nobody has agreed what "good use" of an AI coding assistant actually looks like in that moment.

Awareness and adoption are not the same thing. A developer can understand the risks of AI-generated code and still skip disclosure, skip extra scrutiny, or skip testing when a deadline is close.

Embedding AI best practice means making the right behaviour the easiest behaviour — built into the pull request template, the CI pipeline, the linting rules and the review checklist — rather than something that depends on memory or goodwill.

This matters more, not less, in regulated environments where AI-generated code may end up inside systems that affect trading, settlement or client data.

Why AI coding practice needs more than training

Training sessions are useful for building initial awareness. They explain what AI coding assistants can and cannot be trusted to do, and they set expectations about disclosure, review and testing.

But training has a shelf life. Once the session ends, developers return to sprint deadlines, incident queues and competing priorities. Guidance that exists only in a slide deck or a wiki page tends to fade quickly, especially under pressure.

The result is uneven practice across a team. Some developers disclose AI-assisted changes diligently; others don't think to, or don't have time to. Some scrutinise generated code line by line; others accept suggestions without close review. None of this is necessarily malicious — it is simply what happens when a standard is not built into daily workflow.

In a regulated financial services environment, that inconsistency creates a real operational problem. If AI-generated code enters a settlement, reconciliation or client-facing system without a clear, evidenced trail of review, it becomes very difficult to answer a basic governance question after the fact: who reviewed this, and on what basis was it approved?

Traditional approaches to embedding coding standards

Embedding any coding standard — not just AI-specific ones — has always relied on the same handful of mechanisms:

• Style guides and documented standards, setting out what is expected.
• Linting and static analysis, catching deviations automatically before code is reviewed by a human.
• Mandatory code review, requiring a second set of eyes before code is merged.
• CI/CD pipeline gates, blocking merges or deployments that fail defined checks.
• Pull request templates, prompting developers to answer specific questions before submitting changes.

These mechanisms work because they do not depend on a developer remembering a rule. The rule is encoded into a tool or a process step that has to be satisfied before work can proceed.

The same logic applies directly to AI-assisted coding. A pull request template can ask whether AI assistance was used. A linting rule can flag patterns commonly associated with AI-generated boilerplate. A CI gate can require additional test coverage for flagged changes. None of this is new invention — it is the application of familiar SDLC discipline to a new source of code.

The limitation of these traditional mechanisms is that they were designed around human-authored code and predictable failure patterns. They need to be adapted, not discarded, to account for the specific risks AI-generated code introduces — such as plausible-looking but subtly incorrect logic, or code that compiles and passes tests while embedding an assumption nobody has reviewed.

Where AI helps reinforce good practice

AI tooling is not only the source of the risk here — it can also be part of the control.

Some AI coding assistants can be configured to tag or annotate the sections of code they generated, making disclosure automatic rather than dependent on the developer remembering to flag it. Linting and CI tooling can then use that tag to trigger an additional review step, in the same way a security-sensitive file path might trigger a mandatory security review today.

AI can also help reviewers, not just generate code for them. Some tools can generate a plain-language explanation of what a piece of generated code does, or suggest additional test cases that a human reviewer can then evaluate. This narrows the gap between "code was generated quickly" and "code was understood before merge."

This is a meaningful operational change: it means good practice does not rely entirely on developer discipline. But it is reinforcement, not replacement. An AI tool flagging its own output for review still requires a human being to actually review it, understand it, and take responsibility for approving it. Automated tagging can be bypassed, misconfigured or simply wrong, so the underlying review step cannot be removed.

Making embedding stick across a technology team

Getting the tooling right is necessary but not sufficient. A few practical factors determine whether embedded standards actually last:

• Senior engineer buy-in. If experienced developers visibly skip the process under pressure, junior developers will learn that the standard is optional.
• Avoiding standards that only exist on paper. A rule that is documented but not enforced by any tool or review step tends to erode within weeks.
• Balancing automation with review effort. Flagging every AI-assisted change for senior review does not scale if AI assistance becomes routine; teams need to calibrate which changes genuinely warrant extra scrutiny.
• Revisiting standards regularly. AI coding tools change quickly. A control designed around today's tooling may be irrelevant, or insufficient, within a year.

Embedding is therefore not a one-off project with a defined end date. It is closer to a maintained control that needs periodic attention, similar to how coding standards or security policies are periodically reviewed and updated.

Example

A London-based clearing technology team introduces a pull request rule requiring developers to tag any code generated with AI assistance, and a linting step that flags AI-tagged commits for an additional senior review before merging into the settlement reconciliation service.

Over several months, AI-assisted code entering the reconciliation service receives consistent additional scrutiny without slowing down routine development, and the team can demonstrate to internal audit that AI-generated code is subject to a defined, evidenced control rather than informal trust.

FAQs

• Is embedding AI coding practice just about writing a policy document?

  No. A policy document sets out what is expected, but on its own it rarely changes daily behaviour. Embedding means building the policy's requirements into the tools developers already use — pull request templates, linting rules and CI/CD gates — so the standard is enforced as part of normal workflow rather than left to memory or goodwill.

• Can AI tools be trusted to enforce their own best practice?

  AI tools can help by flagging AI-assisted changes, suggesting additional tests or explaining generated code, which supports a more consistent review process. However, they cannot replace human judgement. Automated flags can be missed, bypassed or wrong, so a person still needs to review and take accountability for any code before it is merged.

• How often should embedded AI coding standards be reviewed?

  There is no fixed universal interval. Standards should be revisited whenever AI coding tools materially change capability, following any relevant incident or near miss, and in response to new regulatory guidance, rather than treated as a one-off exercise that never needs revisiting.