What actually has to change in tickets, reviews, testing, and handover before AI starts affecting delivery rather than just individual productivity of software developers?

Ad hoc AI use is not the interesting part anymore, most teams already have that. What matters is whether the workflow around it changes. When tickets stay vague, reviews stay manual, tests stay thin, and handover stays informal, AI does not improve delivery, just adds more variation.

The first 90 days in the process usually decide whether implementing AI into the core development workflow becomes structured and usable or remains messy.

Why most teams stall after early AI adoption

The first mistake is to treat AI as an individual working style rather than a team-level change.

As long as AI lives at the level of personal habits, the results will stay inconsistent. Some engineers use it heavily, some barely trust it. Some use it for scaffolding, some for debugging, some for tests, some for almost everything. The result is more variation, not a stronger delivery process.

The second mistake is to standardise too early and too broadly. Teams write ambitious policies, buy more seats, run a few workshops, and assume the workflow will change by itself. It rarely does.

The first 90 days of a serious AI implementation process should not be framed as an AI rollout but used to decide where AI is useful, where it adds risk, and what the team now expects from work that involved it.

A 90-day roadmap for AI workflow adoption

Days 1–30
Main objective: Set boundaries and decide where AI belongs.
What the team needs by the end: A pilot scope, risk buckets, baseline metrics, and minimum rules for AI-assisted work.

Days 31–60
Main objective: Change tickets, review, testing, and handover.
What the team needs by the end: A working review and testing model for AI-assisted tasks.

Days 61–90
Main objective: Make the workflow repeatable without slowing the backlog.
What the team needs by the end: A small operating layer the team will actually keep using.

Days 1–30: set boundaries and decide where AI belongs

In the first month, speed matters less than control.

Starting point
Rather than telling everyone to “use AI more,” start by deciding where AI is acceptable and where it is not.

Task types
Most teams need three buckets.

1. Low-risk work includes scaffolding, boilerplate, test setup, documentation, refactoring with clear boundaries, and internal utilities.
   
2. Medium-risk work includes feature logic inside existing patterns, integration code, query changes, and workflow updates.
   
3. High-risk work includes authentication, permissions, payments, migrations, destructive operations, critical customer workflows, and anything tied to compliance or infrastructure.

Risk rule
Put that model in writing. Once a task falls into the high-risk bucket, the review standard should change with it.

Pilot team
Choose one team or one product area where the process can be observed closely. This should not be a company-wide exercise. Pick a team with an active backlog, a codebase in reasonable shape, and at least one senior engineer willing to shape the process rather than simply use the tools.

Minimum rules
Set a few practical rules for AI-assisted work.

• Every non-trivial AI-assisted change must be reviewable without guessing where the logic came from.
• No AI-generated change goes in without a human owning the final result.
• No sensitive data goes into a public model unless there is an approved path.
• No schema change, permission change, or production script is accepted without senior review.
• “The model suggested it” is never a valid reason to lower the review bar.

Baseline
Before changing the workflow, measure the current state for one team or one stream of work. That usually means lead time from ticket start to merge, review time per pull request, reopen rate after QA or production, number of hotfixes or rollbacks, average ticket size, and time lost to clarification or rework.

Ticket format
Update the ticket format in the pilot area. Every ticket likely to involve AI should include the expected outcome, constraints that must not be violated, known edge cases, source documents or systems that define the logic, and whether the task is low, medium, or high risk.

Closing point
This alone improves quality, even before the first AI-assisted change is merged.

Days 31–60: change tickets, review, testing, and handover

By the second month, the team should start changing the workflow itself.

Tickets
Tickets need to become more precise. AI is good at moving quickly once the task is clear. It is much weaker when the task is vague, contradictory, or missing constraints. Broad requests such as “add support for X” need to become implementation-ready problem statements: what needs to happen, what must stay unchanged, where the business rules live, what the output should look like, and which parts are risky. If the team uses AI while still writing weak tickets, it will simply arrive at bad first drafts faster.

Review
This is usually where teams underestimate the change. A review process designed for manually written code often starts to strain once AI is involved, because the volume of change can increase while the depth of understanding drops. The answer is not to “review harder,” but to review differently.

For every medium- or high-risk AI-assisted pull request, require a short implementation note in the description:

• what was generated
• what was changed manually
• what the engineer verified personally
• where the risky parts are
• what still needs closer attention in review

That makes review much more concrete.

Senior reviewers should focus on the things AI tends to miss:

• architecture boundaries
• repeated logic that should have stayed centralised
• side effects
• permission checks
• failure handling
• test quality
• code that looks plausible but does not fit the codebase

Testing
This is where the workflow needs to become stricter. AI can help generate tests, but those tests often mirror the implementation too closely. They pass and still prove very little. The team needs a clear definition of sufficient testing for AI-assisted work.

A practical rule works best here: every medium- or high-risk AI-assisted change should include at least one test that checks a boundary case or failure path, not just the happy path. That one rule usually improves thinking without making the process heavy.

Handover
Handover is where weak AI adoption becomes obvious. If work moves faster but the next engineer cannot follow what was done, the team has not improved, merely shifted the cost.

A handover note helps. It should say:

• what changed
• what assumptions were made
• what the feature does not cover
• what needs watching after release

The note can be short, but it needs to exist.

Days 61–90: make the workflow repeatable without slowing the backlog

By the third month, the task is to decide which parts of the pilot deserve to stay in the workflow and which do not.

Review the pilot
At this point, the pilot team should be able to answer a few practical questions.

• Which task types actually got faster?
• Where did review get slower?
• Which quality problems appeared more often?
• Which rules reduced rework?
• Where is the team still hesitating?

Create standards
Turn that into working standards. This does not require a giant policy deck. What helps is a small operating layer the team will actually use:

• a risk classification for AI-assisted tasks
• a pull request template
• review rules for medium- and high-risk changes
• minimum testing expectations
• a handover standard
• a clear escalation path for tasks that sit in a grey zone

Track metrics again
Recheck the same measures for another sprint or two:

• lead time to merge
• review time
• defect escape rate
• rework after review
• hotfix rate

The goal is not to prove that AI improved everything, but to see where the workflow improved, where it became heavier, and whether the trade-off is acceptable.

Scale selectively
This is also the point where many teams make a useful correction. AI should not be scaled evenly across the whole backlog. Some work will move faster with it. Some work should stay more manual. That is not failure. It is evidence that the team is starting to understand where the workflow holds up.

Carry it into the next team
Finally, decide who can carry the workflow into the next team. In most cases, that means one senior engineer and one hands-on team lead who understand both the process and the codebase. Without those people, the gains stay local and disappear as soon as the pilot ends.

What senior developers still need to own

The role of senior developers does not shrink once AI enters the workflow, just becomes more specific.

They still need to own architecture decisions, code review standards, test quality, release safety, knowledge transfer, and the judgement around where AI should and should not be trusted.

That is also why it's efficient to embedd 1 to 3 external senior developers experienced with AI implementation into the team, ideally for at least 6 months, helping shift how the team works while the actual backlog keeps moving.

Review your AI development workflow with Blocshop

This is the point where Blocshop tends to fit in.

Not at the “let’s get everyone using AI” stage, but where a team wants AI to become part of the development process itself and wants that change to hold up while delivery continues.

If AI is already being used in your team, but the workflow around it still depends on individual habits, schedule a free consultation with Blocshop.

We will review where AI already fits well in your process, where the pressure points are likely to appear, and what would need to be formalised as usage scales.