dooopSoftware · Organization · 11 min

How to Manage the Transition to Amplified Development

Organize the transition to amplified development with practices, responsibilities and evidence. Decide what to scale, restrict or stop.

Published on September 6, 2026Updated on September 6, 2026

CENTRAL THESIS

Scaling the pilot requires choosing which practices deserve to become team routine.

The transition connects observed learning to agreements that can be sustained.

A transition to amplified development begins when the pilot stops being just a good story and becomes an operational decision. If a team used artificial intelligence to review documentation, suggest tests or speed up code analysis, the question is not only whether it worked. The question is what can be confidently repeated, by whom, under which conditions and with what limits. Scaling requires linking tested practice, observed evidence, identified limits and explicit decision.

The problem is not leaving the pilot phase, but deciding what deserves to scale

Pilots often produce mixed signals. Some people report gains in flow, others distrust the quality of responses, leaders see opportunity and technical leads perceive hidden rework. All of this can be true at the same time.

The mistake occurs when the organization tries to resolve this ambiguity with an overly broad decision: allowing use for everyone, blocking out of fear or choosing a tool as if the tool were the process.

Amplified development, in this text, means redesigning engineering practices so people use AI to support reasoning, production and review without removing technical responsibility. The transition to amplified development needs to treat the pilot as learning material, not as automatic proof of productivity.

The presentation of the DORA 2025 report describes AI as amplifying existing strengths and weaknesses in the organization. This idea is useful for leadership because it shifts the question: before asking "Did AI improve the team?", ask "What did AI usage make more visible in our work system?"

If the pilot only worked when an experienced person led everything, perhaps the practice is not yet ready to scale. If it worked when there were clear acceptance criteria, locatable documentation and disciplined review, perhaps the opportunity lies less in the tool and more in the combination of context, practice and judgment.

This distinction avoids two bad extremes: turning enthusiasm into permanent policy or turning legitimate doubt into paralysis.

Separate practice, tool and observed behavior

The transition becomes confusing when leadership evaluates only the tool. "Using AI for testing" is too broad. It can mean generating scenario names, creating test data, suggesting unit tests, reviewing coverage, explaining failures or proposing edge cases. Each of these practices has different risks, evidence and criteria.

A good description separates three layers:

Tested practice: the specific activity the team tried to amplify with AI.
Tool used: the resource, assistant, model or environment that supported the practice.
Expected behavior: what the person should do before accepting, adapting or discarding the output.

For example: "generate first version of automated tests from acceptance criteria" is a practice. The tool is only the means. The expected behavior may include reviewing assumptions, comparing with known risks, recording exceptions and validating if the test really covers system behavior.

This separation helps avoid a poor conclusion: "the tool is good" or "the tool is not suitable." In many cases, the better question is: is the practice described so another team can repeat it without copying the pilot’s improvisation?

This logic aligns with a broader discussion about organizational preparation for AI. The foundational article on how to prepare a software company to work with AI deepens the capability system. Here, the focus is narrower: deciding what to do after a concrete pilot.

Turn the pilot into comparable evidence

Reports matter, but are not enough. They show perception, friction and confidence. To decide on scaling, leadership needs to convert the pilot into evidence comparable across practices.

It is not necessary to create a bureaucratic machine. It is necessary to record the minimum that allows comparing one practice with another without relying on memory or charisma.

A useful set of evidence includes:

Clarity of use case: does the practice solve a specific activity or just explore the tool?
Frequency of use: did the practice appear in recurring situations or in unrepresentative exceptions?
Review effort: did reviewing the output require less, similar or more effort than doing it without AI?
Type of error found: did AI err due to lack of context, requirement ambiguity, technical limitation or hasty acceptance by the person?
Perceived impact on flow: did the practice reduce waiting, improve understanding, shift bottlenecks or just change where the work appeared?
Dependencies for repetition: does the practice depend on documentation, examples, code patterns, test data or tacit knowledge of few people?

Microsoft describes its Experimentation Platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact and iterate products. The reference is useful here as it reinforces the discipline of hypothesis, measurement and iteration. It does not authorize concluding that any AI use is an experiment, nor that all feedback automatically retrains a model.

Discovery and experiment are also not the same. In discovery, the team understands where AI can help. In experiment, it formulates a testable hypothesis, defines a measure and combines a possible decision before execution. If the practice lacks hypothesis, measure and decision, it can still be learning but should not be treated as strong evidence for scaling.

Identify what AI amplified in the existing system

An AI pilot rarely tests only AI. It also tests documentation quality, requirement clarity, review discipline, decision traceability and leadership maturity to handle exceptions.

When the team asks AI to explain part of the system and receives a poor answer, the problem may be the model but also fragmented documentation, confusing names, unclear architecture or business rules scattered in old conversations. When AI suggests useful tests, perhaps the merit lies in well-written acceptance criteria and available examples.

DORA links learning culture to software delivery performance and proposes treating learning as an organizational investment. For the transition, this means the pilot must feed agreements, documentation and practices, not just internal presentations.

The same DORA capability family evaluates documentation quality by attributes such as clarity, ease of location and reliability, and recommends active creation and maintenance. This is practical: if AI depends on poor context, scaling the practice may amplify noise.

Here is a phrase leadership should take seriously: AI does not fix by itself a system that does not know how to explain its own work.

It can help find inconsistencies, synthesize material and suggest paths. But if no one is responsible for deciding which source is valid, which exception was accepted and which practice should change, scaling only spreads ambiguity faster.

Define criteria to scale, adapt, restrict or abandon

The passage from pilot to scale must end in decision, not feeling. For each tested practice, choose one of four actions.

Scale when the practice is repeatable, reviewable and useful in more than one context. This requires another person to be able to execute the practice with sufficient guidance, risks to be known and human review to have a defined responsible.

Adapt when there is value but the practice depends too much on one person, one type of task or documentation that does not yet exist. In this case, the decision is neither to expand nor kill. It is to redesign the practice and test again with clearer limits.

Restrict when operational risk demands greater control. This can occur when an error accepted by AI affects safety, sensitive data, critical user experience, availability or decisions hard to reverse. Restricting is not failure. It is recognizing that not every practice should become a general standard.

Abandon when the practice increases rework, uncertainty or review cost without clear flow gain. Also abandon when the team starts accepting outputs without understanding the reasoning or when the tool shifts attention to low-value tasks.

A simple checklist helps turn discussion into decision:

Defined practice: can the team describe the practice without relying on the tool’s name? If not, keep in pilot until separating practice, tool and expected behavior.
Observable evidence: are there records of use, review, exceptions and problems found, as well as positive reports? If only informal perception exists, adapt the pilot before scaling.
Repeatability: can another person or team apply the practice with sufficient documentation? If it depends on a specific person, restrict expansion and document the process.
Review cost: is the effort to review AI output less, equivalent or greater than doing the activity without AI? If cost grows without clear flow gain, abandon or redesign.
Context quality: does the practice depend on reliable requirements, documentation or examples? If context is fragile, fix the base before scaling.
Operational risk: can an error generated or accepted by AI affect safety, compliance, sensitive data or critical user experience? If risk is high, keep the practice restricted with explicit review.
Incorporated learning: does the team update agreements, documentation and examples based on what was learned? If learning does not enter the process, scaling tends to repeat improvisations.

The transition gathers decisions that must remain coherent. Empowering people, defining usage agreements, reviewing roles and measuring adherence are relevant decisions, but the question here is more specific: what to do with each practice after the pilot?

Fictional example: turning a pilot into a team practice

Imagine a fictional example. A digital product team uses AI to suggest automated tests from acceptance criteria written in stories. The pilot happens in some internal services, with mandatory review by a person responsible for the code.

The practice is not "use AI for testing." The practice is more precise: generate a first version of automated tests based on acceptance criteria and already recorded examples.

The evidence to observe would be:

Were the acceptance criteria clear enough to guide good suggestions?
Did AI invent behaviors not described?
Did the review find useful cases the person might have forgotten?
Did the output require much rewriting?
Did errors come from AI or ambiguous criteria?
Could another person repeat the practice following pilot documentation?

Suppose the team perceives a promising hypothesis: when acceptance criteria are clear and there are examples of expected behavior, AI can help assemble a first version of tests, provided the person reviews logic, names, data and coverage. This is not yet proven result. It is an operational hypothesis to measure in another context.

The possible decision could be: scale in a restricted way for services with clear acceptance criteria, available examples and mandatory review by a technical lead. For stories with ambiguous requirements, the practice does not scale. First, the team improves acceptance criteria.

This type of conclusion is stronger than "the pilot was positive." It says where the practice applies, where it does not, who reviews and what condition must exist before expansion.

It also helps avoid a common confusion: attributing to AI the credit for an improvement that may come from better writing of criteria, more careful review or extra leadership attention during the pilot. The point is not to diminish AI. It is to locate the real value mechanism.

Make the transition a learning cycle, not a generic authorization

The transition to amplified development does not end with broad permission. It needs to create a learning cycle: defined practice, collected evidence, recorded limit, decision made and later review.

This requires a simple ritual of passage between pilot and scale. It can be a recurring conversation among technical leadership, product and people who executed the practice. The format matters less than the questions:

What exactly was tested?
What observable evidence do we have?
Under which conditions did the practice work best?
What limits appeared?
What needs to become documentation, agreement or internal example?
Is the decision to scale, adapt, restrict or abandon?

The decision also needs an owner. Someone must take care of updating agreements, documentation, examples and recording exceptions. Without responsibility, the organization calls scale what is only informal propagation.

If the company already has a broader strategy, it is worth connecting this decision to the capability plan. Content such as AI maturity, AI roadmap and business-connected artificial intelligence strategy help frame the transition in larger decisions. But scaling an engineering practice still requires local evidence.

The concrete decision is to institute a ritual of passage from pilot to scale and classify each tested practice into one of four actions: scale, adapt, restrict or abandon. If the practice cannot be described, reviewed, repeated and limited, it is not yet ready to become standard.

If you want to talk about how to organize this decision in your team, contact dooop.

Sources

To continue this reading

How to form an internal AI practice community

NEXT DECISION

Discuss application in the company

Conversation about the software company context

Content by dooop. Registration allows linking this topic to the reader’s journey and tracking interest in the subject.