How to introduce AI into an engineering team that already works

When a software team already works well, changing it requires more care than starting from scratch. Some habits protect quality, implicit agreements sustain collaboration and a professional identity has been built over years. AI can expand all of that or erode it.

I have supported the evolution of an engineering team of more than fifteen people towards an increasingly agentic way of working. The first lesson was simple: the unit of adoption is not the tool. It is the work system.

Start by observing, not imposing

Before choosing use cases, look at where friction accumulates: understanding someone else’s code, preparing tests, reproducing incidents, updating documentation, reviewing changes, exploring a technology or turning a decision into a first implementation.

Then distinguish three kinds of work:

• Work that is slow because it requires judgement.
• Work that is slow because context is missing.
• Work that is slow because we mechanically repeat known steps.

AI does not solve each case in the same way. It can expand judgement by offering alternatives, organise context or execute repeatable work. Mixing the three categories produces impressive pilots and little real improvement.

A safe first cycle

The best pilot is not necessarily the one that promises the greatest savings. It is the one that lets the team learn without putting the product at risk. I would choose a frequent, reversible and observable task; agree what a good result means; keep human review; and compare the complete workflow before and after.

I would not measure only lines of code or generation time. I would look at time to production, defects, rework, ease of review and later comprehension. Producing faster may simply move the bottleneck to review or operations.

Turn personal tricks into team infrastructure

If everyone keeps a private prompt collection, the organisation is not learning. Useful patterns should become shared instructions, examples, tools, evaluations and versioned review criteria.

Review also changes. It is no longer enough to ask whether the code works. We need to check whether the problem was framed correctly, what context the agent received, what decisions it made, what tests it ran and what remains unverified.

Quality does not disappear because execution becomes cheaper. It becomes more important because the volume of changes we can produce increases.

Make room for useful resistance

Not every objection is fear of change. Sometimes someone is pointing to a real privacy, maintainability, cognitive-load or learning problem. Adoption improves when the team can turn those objections into guardrails and experiments, not when compulsory enthusiasm is expected.

Leadership must make three things clear: which problems we are trying to solve, which boundaries cannot be crossed and how improvement will be recognised. The team can then explore safely inside that space.

The sign that it is working

Adoption is becoming mature when a new team member can benefit from the system without copying the habits of the person who ran the first experiment; when results can be reviewed; and when the team knows when it should not delegate.

The aim is not for everyone to use AI all the time. The aim is for the team to gain a new shared capability and evolve it with judgement.

Sources and references

• DORA’s 2025 report on AI-assisted software development.
• NIST Secure Software Development Framework.
• Primary source: Victor’s experience evolving an international engineering team.