dooopSoftware · Organization 13 min

How to Share AI Practices in Engineering

AI practices only travel well between teams when they include context, hypothesis, evidence, limits, and clear stop criteria.

Published on September 6, 2026

CENTRAL THESIS

Without context, a practice that seemed like learning becomes a risky shortcut and misplaced trust.

The way forward is to circulate examples as testable hypotheses, not as ready-made patterns.

Sharing AI practices among engineering teams requires more than passing along a prompt that worked in one squad. The useful decision is to transport the example with context, hypothesis, local evidence, limits, and stop criteria.

A practice without this information looks like learning but becomes operational folklore. It circulates as a shortcut, loses the conditions that supported it, and can create trust precisely where the team should remain attentive.

What an AI Practice Needs to Contain Before Being Shared

An artificial intelligence practice in engineering should not be treated as a loose tip. If a squad uses AI to review pull requests, suggest tests, summarize incidents, or improve documentation, the question is not just "Did it work?" The better question is: did it work for which problem, in what context, with what limits, and under what type of supervision?

The minimum unit of sharing needs to contain some clear elements:

Observed problem: which engineering difficulty the practice tries to reduce.
Applied practice: what the team concretely did, including tool, workflow, and timing of use.
Test context: type of system, criticality, codebase maturity, team composition, and relevant dependencies.
Hypothesis: what the team expected to improve, reduce, or make more visible.
Local evidence: which signals justified continuing to test the practice in that environment.
Known limits: where the practice failed, has not yet been tested, or requires stronger human review.
Maintenance owner: who reviews the example when tools, models, architecture, or internal agreements change.
Stop criteria: which signal indicates the practice should be paused, redesigned, or discarded.

This record does not need to become heavy bureaucracy. It needs to be sufficient to prevent false equivalence between teams. Two squads may use the same programming language and still operate with very different risks, deadlines, seniority, and dependencies.

The presentation of the DORA 2025 report describes AI as an amplifier of existing strengths and weaknesses in the organization. This reading helps avoid a trap: when an AI practice seems good in isolation, it may be amplifying a real competence of a specific team, not necessarily creating a transferable capability for all.

How to Separate Tested Example, Local Preference, and Organizational Standard

Not everything worth sharing should become a standard. This distinction saves political energy and reduces symbolic adoptions.

A tested example is a practice that solved or made a problem more manageable in a specific context. It deserves to circulate because it accelerates reflection in other teams. But it still carries an open question: in another environment, does the hypothesis remain valid?

A local preference is a way of working that fits a squad but should not be imposed. It may involve prompt style, review format, preferred tool, or chosen ritual. If the practice depends heavily on the team's taste and has low systemic impact, the best path may be to document it as an option, not as a recommendation.

An organizational standard is something else. It requires more weight: clear documentation, evidence in more than one context, known limits, maintenance owner, and review mechanism. It also requires the organization to accept the cost of keeping the standard alive. If no one reviews it, the standard ages silently.

A simple criterion helps decide:

If the practice is useful but depends strongly on context, share it as a commented example.
If the practice reflects work style and does not reduce relevant risk, keep it as a local preference.
If the practice reduces risk, improves consistency, and has been evaluated in different contexts, treat it as a candidate for internal reference.

This distinction connects to the broader preparation of the organization to work with AI. Instead of jumping directly to standardization, it is worth relating the practice to the decision system described in how to prepare a software company to work with AI. The point is not to control every use. It is to know when a local experience should become shared learning.

How to Record Context So Another Squad Can Evaluate the Practice

Context is not a detail. It is part of the practice.

When a team shares "we use AI to review tests," the phrase still says little. The practice changes completely if the system is an internal API with low exposure risk, a product with critical integrations, a legacy codebase without good test coverage, or a new service with simpler architecture.

Before recommending the practice to another squad, record questions such as:

What type of system was involved?
Did the change affect API, interface, data, infrastructure, or business rules?
Did the team have mastery over the reviewed code?
Were reliable automated tests in place before the practice?
Was AI used before, during, or after human review?
Could the AI output block merges or only suggest points of attention?
What tool, repository, or internal policy dependencies existed?
What was the error tolerance in that workflow?

This care is not fastidiousness. The DORA on documentation quality evaluates documentation by attributes such as clarity, ease of location, and reliability, and recommends active creation and maintenance. When sharing AI practices in engineering, these attributes become an operational requirement: if the other squad cannot find, understand, and trust the record, they will likely copy only the surface.

Documentation also prevents leadership from confusing adoption with learning. A poorly recorded practice can spread quickly and teach little. A well-recorded practice may spread more slowly but carries the conditions to be evaluated.

How to Make Limits Explicit Without Undervaluing Learning

Teams sometimes avoid recording limits because it seems to weaken the case. In practice, the opposite happens. A well-described limit increases confidence because it shows where the team thought, where it measured little, and where it decided to remain cautious.

A good limit is not a generic phrase like "use with caution." It needs to guide decisions. For example:

Not tested in authentication changes.
Do not use as the sole criterion to accept test coverage.
Requires human review by someone familiar with the business rule.
May suggest redundant tests when the suite already covers behavior by contract.
Should be paused if it starts increasing rework in review.

This type of limit protects both the sharing team and the receiving team. The first does not sell a promise larger than what was learned. The second does not have to pretend it is rejecting innovation when it is actually preserving technical judgment.

A learning culture does not depend on permanent agreement. The DORA on learning culture relates this culture to software delivery performance and proposes treating learning as an organizational investment. But this does not mean every new practice deserves scaling. Learning also includes stopping, restricting, and adapting.

How to Adapt an AI Practice to a New Squad Without Losing Its Character

When another squad receives a practice, they should not simply "deploy" it. The better word is to repeat the hypothesis in a new context.

There is a difference between discovery, hypothesis, and experiment. Discovery is the perceived problem: reviews miss relevant test cases. The hypothesis is a testable formulation: using AI to suggest forgotten scenarios can improve the quality of review discussion. The experiment is the bounded execution: applying the practice in a specific type of change, with mandatory human review and combined pause criteria.

Adaptation should preserve the intention, not necessarily the form. If the original squad used a long prompt inside the review tool, another squad may prefer a shorter script before opening the pull request. If the first had high domain familiarity, the second may require review by a more experienced person. If the second’s codebase has weak documentation, AI may suggest plausible but misaligned cases with the product’s real behavior.

Microsoft describes its ExP experimentation platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. The application here is more modest and organizational: AI practices between squads should also travel as hypotheses to validate, not as ready conclusions.

A short adaptation script might work like this:

Preserve the original practice’s intention.
Compare the origin squad’s context with the destination squad’s context.
Formulate a local hypothesis.
Define where the practice will be tested and where it will not be used.
Combine signals for continuation and signals for interruption.
Record differences found, including when the practice does not hold.

This process aligns with organizational decisions on AI adoption without paralyzing deliveries, a topic explored in how to organize AI adoption without paralyzing deliveries. The care is not to turn every practice into a heavy project. The goal is to create enough learning to decide better.

How to Decide When a Practice Should Become an Internal Reference

A practice should only become an internal reference when the organization can sustain it. The enthusiasm of a squad is not enough. The authority of leadership is not enough either.

Before promoting a practice, verify if it meets concrete criteria:

It is clearly documented and can be found by those who need it.
It has been evaluated in more than one context or has a strong justification to remain restricted.
It has explicit limits and non-use situations.
It has a maintenance owner.
It has a review mechanism when tools, models, architecture, or policies change.
It does not create invisible dependence on a specific person.
It does not reduce human responsibility over sensitive technical decisions.

The last condition deserves attention. AI can accelerate reading, comparison, and generation of alternatives. But in engineering, accepting a suggestion is still a decision of design, risk, and maintenance. When the practice shifts judgment to a tool without making this clear, it has not matured. It has only become convenient.

This point approaches discussions about technical leadership and critical use of AI, without replacing them. If the central doubt is who decides, reviews, or arbitrates, it is worth addressing this at another organizational design level, as in leadership and augmented human intelligence. Here, the focus is more specific: a practice only travels well when its limits travel with it.

Fictional Example: Using AI to Review Automated Tests

Imagine a fictional example. A squad responsible for an internal API starts using AI to suggest forgotten test cases before the final pull request review. The team does not authorize AI to approve changes, block merges, or automatically alter code. They use the output as a list of questions for the review conversation.

The observed problem was simple: some API contract changes generated late discussions about error scenarios, invalid inputs, and compatibility behaviors. The local hypothesis was that AI could help raise forgotten cases and improve review quality, provided a team member evaluated each suggestion.

The practice record could be like this:

Defined problem: API change reviews did not always raise negative or compatibility test scenarios.
Described context: internal API, team with good service mastery, existing test suite, and mandatory human review.
Explicit hypothesis: using AI to suggest test scenarios can make the review more complete without replacing team decisions.
Evidence to observe: useful suggestions for discussion, perceived less rework in review, and identification of scenarios the team considers relevant. These signals would be local observations, not universal proof.
Known limits: do not use in authentication, authorization, or critical behavior changes without reinforced technical review. Do not accept suggested tests without understanding the business rule.
Risk of direct copying: another squad with low test coverage or little system mastery may accept plausible but wrong suggestions.
Stop condition: pause if the practice increases noise, generates undue trust, or shifts review to superficial checking of suggestions.
Update owner: a designated squad member reviews the record when the tool, model, API architecture, or internal review agreement changes.

Now imagine another squad trying to use the same practice in a system with weak documentation and more ambiguous business rules. Copying the original prompt would be a poor decision. The correct adaptation would be to preserve the intention, reformulate the hypothesis, and perhaps restrict use to small changes, with stronger human review and recording cases where AI invents scenarios incompatible with the product.

Notice the difference. The organization is not asking "should we use AI to review tests?" It is asking "under which conditions does this practice help the team think better, and under which conditions does it create noise or risk?" This question is slower at first but avoids fragile scaling.

Checklist to Transport an AI Practice Between Squads

Before recommending a practice to another squad, use this checklist as a filter. It does not automatically approve the practice. It improves the conversation.

Defined problem

Which observable engineering problem does the practice address?

If the answer is vague, the practice is probably being shared because it seems modern, not because it solves a real difficulty.

Described context

In what type of system, team, workflow, and tool was the practice tested?

Without this information, another squad tends to assume equivalence where there may be decisive differences.

Explicit hypothesis

What did the team expect to improve or reduce by using AI?

The hypothesis separates intentional learning from casual tool use. It also allows repeating the practice with a clear question.

Observed evidence

Which signals supported continuing the practice?

They can be qualitative signals, as long as described as local observation. The mistake is presenting one squad’s perception as proof for all.

Known limits

Where did the practice fail, remain untested, or require stronger human review?

A limit is not an excuse. It is trust infrastructure.

Risk of direct copying

What can go wrong if another squad applies the practice without adaptation?

This question forces leadership to discuss domain, criticality, technical maturity, and people dependency.

Stop condition

Which signal indicates the practice should be paused or redesigned?

Without a stop condition, adoption tends to become symbolic adherence. The team keeps using it because they started, not because they keep learning.

Update owner

Who reviews the example when tools, models, architecture, or internal agreements change?

AI practices age. What was acceptable in one context may become inadequate when the tool, model, codebase, or organizational policy changes.

Sharing AI practices among engineering teams is an organizational learning decision, not internal propaganda. Before recommending any practice, leadership should require a minimum record: problem, context, hypothesis, local evidence, limits, copying risks, stop condition, and maintenance owner.

If the practice does not carry this, it may still be a good conversation. It just should not travel as a reference.

If you want to discuss this decision in your company’s context, talk to dooop.

Sources

NEXT DECISION

Discussing Application in the Company

Conversation about the software company context

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