AI for developer teams — coding, reviews and toolchains

A developer team adopting AI-assisted coding is rarely asking whether a tool writes code faster — it almost always does. The real question is whether the existing review process, the toolchain and the development practice keep up with that speed, or whether they quietly erode until nobody can explain why a given piece of code is in the repository. This page covers three tasks that belong together: using AI-assisted coding productively, adapting review standards to it, and securing toolchain selection and development practice so that speed is not paid for with control.

AI-assisted coding without losing control

An assistant that suggests code, completes functions or drafts whole modules changes a team's work in several places at once — not just typing speed:

• The provenance of code becomes invisible. When a large part of a module was proposed by an assistant, nobody on the team can necessarily say why a particular solution was chosen. The reasoning never existed as a human thought, only as a plausible continuation of a prompt.
• Familiarity is mistaken for understanding. Code accepted because it looks plausible and the tests pass is not the same as code someone on the team has actually worked through. The difference shows up reliably at the first bug that cannot be fixed with another prompt.
• Dependencies creep in. Assistants preferentially suggest libraries and patterns that were common in their training data, not ones that fit your architecture or your security profile. Without deliberate review, a project's dependency list grows in a direction nobody decided on.

The productive response is not to avoid the tool but to name the questions that must be answered before a suggestion is accepted. Does someone on the team understand the solution well enough to explain it in six months without the assistant? Does the proposed dependency fit the existing stack? And where in this flow does an agentic system belong — one that carries out several steps on its own rather than making a single suggestion? For that, the same pre-rollout assessment applies as described on AI in companies; there is no special exemption for the development context.

Review standards that respond to AI-assisted code

A review process built for human-written code implicitly reviews the thinking that produced it. With AI-assisted code that part is missing unless the process adapts:

• Mark provenance. A pull request should make clear which parts were produced with AI assistance — not to distrust them, but so a reviewer knows where asking for the reasoning is worthwhile.
• Tie review depth to the cost of being wrong, not to who wrote it. An AI-generated suggestion for an internal helper and an AI-generated suggestion for payment logic do not deserve the same scrutiny. The cost of an error in that task decides, not the question of who or what produced the code.
• Require explainability. A reviewer should be able to ask "why this solution and not another?" and expect an answer from a person on the team. "The assistant suggested it" is not a justification that passes review.
• Tests remain the reference, not the reassurance. AI-generated tests that merely confirm the existing code rather than probe its limits give false confidence. A test still has to answer what happens on bad input or at an edge case, regardless of who wrote it.

These adjustments are not an extra process step but a shift of focus: away from pure code inspection, towards whether the reasoning behind the code actually exists inside the team.

Toolchain selection grounded in your own setup

Choosing a coding assistant, a development environment or an automation tool should turn on four points that go beyond a vendor's marketing:

• What happens to your code. Where do the prompts, snippets and context a tool uses for completion actually go — do they stay local, are they used to train someone else's model, and can that be verified contractually and technically rather than merely asserted?
• Integration with the existing toolchain. An assistant that works in isolation from version control, the CI pipeline and existing review tooling creates more friction than it saves. The relevant question is not what the tool can do on its own, but how it fits the flow you already have.
• Traceability of suggestions. Can you reconstruct later which section came from an assistant, and with which version of the tool? Without that trail, every subsequent investigation into AI-assisted code becomes conjecture.
• The ability to leave. A team should be able to switch a tool off without losing knowledge about its own codebase because that knowledge existed only inside the tool — in comments or configuration only that tool understands.

These criteria are deliberately vendor-independent, because the market changes faster than the questions a team should ask of a tool.

Secure development as the foundation, not an add-on

AI-assisted coding does not change the fundamental requirements of secure development, but it raises the speed at which violations of them can appear:

• Secrets and credentials. An assistant reading project context can inadvertently carry credentials or internal endpoints into a suggestion if those sit in code or config rather than in secret management. The defence is the same as without AI — secrets do not belong in the code — but the higher speed makes it more urgent.
• The dependency supply chain. A suggested library deserves the same scrutiny as a manually chosen one: who maintains it, how long has it existed, and does it meet your security requirements? An AI suggestion is not a substitute for that check, even though it makes the check look faster than it is.
• Rights and provenance of training data. Where an assistant proposes code in a style or structure that clearly derives from a particular source, the licensing and usage question is the same as for any other adopted line of code. It does not disappear because a model generated it.

Where this goes wrong in practice

The typical failure is not a single security-critical bug but a gradual drift: a team accelerates code production without bringing the review process, the toolchain criteria or the safeguards along with it. After a few months the codebase holds a growing body of code whose reasoning nobody can reconstruct, and a review process that formally still exists but in practice confirms rather than checks. The problem usually surfaces only when a bug appears that cannot be fixed with another prompt, or when a customer or regulator asks questions that depend on documentation which, for exactly this reason, was never written.

Next step

If you are preparing a toolchain decision, adapting your review process to AI-assisted coding, or want an existing development practice checked for how well it is secured, get in touch. A short description of your current toolchain and the decision ahead is enough to start from.