dooopSoftware · Organization 12 min

How to Integrate Developers with AI Without Losing Context

Onboarding with AI requires context, verification, and reasoning review before expanding autonomy over code, architecture, and product.

Published on September 6, 2026

CENTRAL THESIS

AI accelerates onboarding but also hides gaps. Onboarding must reveal how the person verifies what they accept.

Autonomy starts small and situated. Context, evidence, and review come before significant changes.

A new developer can join the team, open the repository, use artificial intelligence to explore the code, and deliver an apparently good change within a few days. That is not the problem. The risk appears in the first pull requests, when a plausible AI explanation turns into a change without reading the flow, tests, and decisions surrounding that code. Developer onboarding with AI should begin with context and verification before expanding autonomy over code, architecture, or product flows.

Why the first risk is not using AI, but using AI without context

In many teams, new people already use AI tools to explore code, formulate questions, and draft alternatives. Therefore, integration needs to define how this use will be verified.

This can shorten the initial exploration and, at the same time, produce premature confidence.

Even when a code-related answer seems coherent, it must be confronted with the product context, tests, and documentation. A repository may carry old decisions, acceptable shortcuts, known debts, incidents, fragile integrations, and business rules that do not always appear in class names or comments.

Therefore, developer onboarding with AI should not be designed as either a release or a prohibition. The better question is: in which situations can the person use AI to learn, in which to propose, and in which do they still need close review before changing something relevant?

The DORA 2025 report describes AI as an amplifier of existing organizational strengths and weaknesses. This is a good lens for onboarding. Applied to developer integration, it suggests that teams with clear criteria, locatable documentation, and disciplined review tend to offer a more controlled environment for AI use by new people. When knowledge is oral and implicit, AI can reinforce existing confusion.

Apparent speed is not sufficient evidence of autonomy.

What the new developer needs to learn before gaining autonomy

Before expanding the scope of action, the team needs to transform context into an observable prerequisite. It is not enough to ask the person to read documents, watch recordings, or attend meetings. They need to demonstrate that they understand what changes when they touch a part of the system.

Some contexts should appear early in developer integration:

Product context: which user or business problem that flow solves, which behaviors cannot be broken, and which decisions have already been discarded.
System map: which modules, services, queues, APIs, libraries, or routines are affected by a change.
Current architectural decisions: which patterns the team follows, which exceptions are accepted, and which changes require conversation before coding.
Testing standards: what type of test supports each risk, where reliable examples are, and which gaps are known.
Review criteria: what makes a pull request acceptable beyond compiling and passing existing tests.
Sensitive data and tool limits: which information should not be placed in external tools and when to consult someone before using AI.
External dependencies: which integrations require care because failures affect operation, support, or user experience.

DORA, when addressing documentation quality, highlights attributes such as clarity, ease of location, and reliability. For a new person using AI, these attributes cease to be details. In this context, documentation can function as a source of verification against plausible tool responses.

One possible practice is to ask the new developer to keep a small learning log in the first deliveries. It does not need to be bureaucratic. It should answer: what I understood, where I confirmed it, what is still uncertain, and which decision needs human review.

This log reveals two things simultaneously. It shows the person’s maturity in using AI and exposes failures in the team’s own work system.

How to delimit AI use in the first delivery cycles

One possible mistake is treating AI as a switch. Either the person can use everything freely, or they cannot use anything until gaining trust. Neither option solves the real problem.

A safer progression separates use for understanding, use for proposing, and use for changing.

In the first cycle, the person can use AI to explain code snippets, raise hypotheses, and formulate better questions. The expected result is not ready code. It is a more precise conversation with the mentor or tech lead.

At this stage, good AI requests are like: “explain the flow of this function,” “point out dependencies I should check,” or “list questions I should ask before changing this module.” The acceptance criterion is not the beauty of the answer but the person’s ability to confront the answer with code, documentation, and real behavior.

In the second cycle, AI can help generate small alternatives. For example, two ways to simplify a validation, write tests for an error case, or improve the readability of an isolated function. The person should compare options with team criteria, not just choose the most elegant suggestion.

In the third cycle, the team can allow somewhat more relevant changes, provided the scope is clear and the review continues to examine the reasoning. Autonomy does not mean absence of review. It means the person can already anticipate risks, justify choices, and ask for help before turning doubt into change.

Microsoft describes its experimentation platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. As an adaptation for onboarding, the team can treat changes as hypotheses to be verified with evidence and review, even in small changes.

How to review the person, reasoning, and output generated

Code review with AI needs to look beyond the diff. If the team reviews only the changed file, it may approve a correct change by chance and miss the opportunity to calibrate judgment.

During onboarding, the review should answer four questions.

Did the person understand the intention of the change?
Do they know which premises they used to accept the AI suggestion?
Did they verify the output against code, documentation, tests, or team criteria?
Can they explain what they discarded and why?

This type of review does not turn the process into an interrogation. On the contrary, it prevents the new person from learning that the goal is to “make AI get it right” and pass the pull request. The goal is to discover if the person knows how to verify a suggestion before putting it into code.

A useful review can include questions such as:

“Which part of this solution came from AI and which part did you adjust?”
“Which file or test confirmed this interpretation?”
“What behavior would break if this premise were wrong?”
“Why did you choose this alternative instead of the other?”
“At what point would you have stopped and called someone before proceeding?”

These questions make AI use visible without creating a surveillance atmosphere. The team does not need to punish tool use. It needs to prevent it from becoming an invisible shortcut for decisions the person does not yet know how to support.

There is an important limit here. In systems impacting security, privacy, availability, or critical business rules, additional review must continue even when the person seems mature. The checklist helps guide the conversation but does not replace technical judgment about risk.

A fictional 30-day roadmap for context, verification, and autonomy

Imagine a fictional team maintaining a subscription management platform for education companies. A new developer joins the team and already has experience with programming and AI tools. The technical leadership’s goal is not to block AI use. It is to calibrate autonomy.

In the first week, she receives an initial product map, the main system flows, and a short list of current technical decisions. She can use AI to explain code snippets but must mark each explanation as confirmed, uncertain, or rejected. Evidence can be a test, internal documentation, a conversation with the mentor, or reading another related module.

The expected delivery that week is not a feature. It is a simple context map: which files participate in a flow, which dependencies appear, which rules were not obvious, and which questions remain open.

In the second week, she takes on small fixes. For example, adjusting an inconsistent error message or covering a known validation case with a test. AI can suggest tests or refactorings, but each pull request must declare where the tool was used and how the suggestion was verified.

In the third week, she implements a limited change in a low-risk flow. Before coding, she writes the hypothesis of the change: which behavior should change, which behaviors should remain the same, and which tests support minimal confidence. AI can help compare alternatives, but the final choice must be explained with product and code criteria.

In the fourth week, the team grants partial autonomy on similar tasks. The mentor reduces presence in simpler steps but maintains close review on integrations, sensitive data, and decisions with architectural impact. At the end of the cycle, the team reviews not only the new person’s performance but also documentation failures and criteria that remained too implicit.

This example is fictional and adaptable. The point is not the calendar. It is the sequence: first context, then verification, then gradual autonomy.

Checklist to release gradual autonomy in the first cycles

Before expanding the scope of a new person’s work, technical leadership, mentor, and developer can use a simple checklist. It does not decide automatically. It serves to guide an objective conversation.

Product context: can the person explain which user or business problem the change affects? Expected evidence: own summary, not relying solely on AI-generated explanation.
Technical context: can the person locate modules, dependencies, and risk points related to the change? Expected evidence: simple map of impacted files, services, or flows.
Declared AI use: does the person report where AI was used and for what purpose? Expected evidence: short record, such as explanation, alternative generation, test writing, refactoring, or review.
Independent verification: did the person validate AI output against code, documentation, tests, or team criteria? Expected evidence: concrete references used to accept, adjust, or reject the suggestion.
Risk-appropriate testing: do tests cover relevant behavior and not just the happy path? Expected evidence: success, error, and boundary cases compatible with the change’s impact.
Explanation of tradeoff: can the person defend why they chose one alternative and discarded others? Expected evidence: brief comparison between at least two options, with technical or product criteria.
Well-formulated help request: when in doubt, can the person ask for help pointing out context, hypothesis, and evidence? Expected evidence: specific question with code snippet, observed behavior, and attempted action.

The practical rule is to expand autonomy when the person demonstrates context, verification, and consistent explanation in small deliveries. If the delivery involves critical areas, sensitive data, or architectural decisions, close review remains necessary.

Signs that autonomy came too early

Fluency with AI can mask fragile understanding. Some signs deserve tech lead attention:

Answers about the system without reference to real code, documentation, or tests.
Excessive confidence in AI explanations, even when someone points out a domain exception.
Tests that confirm only the most likely path and ignore error, boundary, or legacy behavior.
Difficulty explaining tradeoffs beyond “the solution became simpler.”
Changes larger than the demonstrated understanding of the flow.
Pull requests with good appearance but unclear premises.
Vague help requests without hypothesis, evidence, or prior attempt.

These signs do not mean the person is weak. Often they indicate the team has not made its criteria teachable. If documentation is hard to locate or unreliable, demanding more individual attention does not solve the cause. The team needs to fix documents, examples, and criteria that appear only during review.

This point connects onboarding to a larger organizational decision. To deepen the topic, see also the content on AI maturity and the guide on how to create an AI strategy connected to business.

How to turn onboarding into team learning

Onboarding with AI is not only to teach the new person. It also shows where the team depends too much on informal memory.

If every new developer asks the same things, maybe the problem is not lack of seniority. It may be scattered documentation, architectural decisions without records, tests hard to interpret, or review criteria that appear only when someone makes a mistake.

DORA relates learning culture to software delivery performance and proposes treating learning as an organizational investment. Applied to onboarding, this principle can be translated into a concrete practice: turning recurring doubts into documentation, example, and review criteria adjustments.

At each integration cycle, the team can review:

Which AI answers seemed plausible but were wrong or incomplete?
Which documents really helped?
Which review criteria needed to be explained more than once?
Which code areas required oral context to be understood?
Which AI use limits remained ambiguous?

This learning also relates to leadership. Instead of measuring integration only by delivery speed, it is worth observing if the new person is forming judgment: understands the product, verifies outputs, explains choices, and asks for help precisely. For a related discussion, see the article on leadership and augmented human.

Treat the new developer’s first cycles as calibration. Allow AI use from the start but delimit scope, request verification, and review criteria used to accept or reject suggestions. At the end of the cycle, the important question is: which parts of onboarding still depend on oral context that AI can repeat but cannot validate?

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

Sources

NEXT DECISION

Discuss application in your company

Conversation about your software company’s context

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