dooopSoftware · Process · 11 min

Context Engineering for Development Teams

How to select the source, owner, and validity of context to reduce noise in AI-assisted development tasks.

Published on September 6, 2026

CENTRAL THESIS

Too much context also disorients. The task needs to separate current source, history, and hypothesis before generating code.

Source, owner, and validity become review criteria. Context stops being loose input and enters the team’s workflow.

Context engineering is the practice of choosing and maintaining the information that will guide a task with artificial intelligence. For a development team, the decision is not “gather everything so the model understands better.” It is to separate what changes the implementation, where that information came from, who can confirm it, and until when it is valid. Without this, AI can amplify the noise already present in the process.

When too much context hinders as much as too little context

A task arrives with an apparently sufficient description: change a rule, adjust a flow, fix an exception. In the repository, however, the story is less clean. There is an old decision in an issue, an exception discussed in a pull request comment, a rule described in a spreadsheet, and an operational constraint only one person usually remembers.

Before artificial intelligence, this scenario already caused rework. With AI, it gains another dimension. The model does not know by itself which information is current, which is historical, which was superseded, and which is just an opinion recorded somewhere. If everything enters the request as if it had the same weight, the output may seem coherent and still be guided by the wrong context.

More context is not automatically better context.

The team’s first decision must be editorial, not technical: choose what should guide the task. This choice requires criteria. Long and outdated documentation can hinder more than help. A short comment, but written by the person responsible for the rule, can be decisive. An automated test can be worth more than an ambiguous description on a forgotten page.

AI adoption only reaches development when it becomes a task criterion. Content such as how to create a business-connected artificial intelligence strategy helps frame adoption. But in the team’s flow, the decision remains to separate useful context from noise.

What counts as context in a development task

Anthropic defines context engineering as the selection and maintenance of the information available to the model during inference. This set can include instructions, tools, external data, and history, within a limited window.

Applied to development, this definition needs to move from the abstract. Context can be:

the task description;
repository files to be read or changed;
existing tests;
recorded architecture decisions;
relevant review comments;
current business rules;
environment constraints;
tool or agent permissions;
related incident or correction history;
acceptance criteria defined by the team.

The problem is that these items do not have the same authority. Production code, automated tests, product documentation, review comments, and oral memory should not be treated the same. Each has a source, an owner, and a different degree of validity.

The limited context window reinforces this discipline. Since not everything fits, someone needs to decide. And even when the tool allows attaching many things, the question remains the same: does this information improve the implementation, test, or review decision for this specific task?

If the answer is no, it can remain as a side reference. But it should not guide the change.

The minimal matrix: information, source, owner, and validity

A simple way to organize context engineering in development teams is to record four dimensions before requesting, reviewing, or integrating an AI-assisted change:

information: exactly what item should guide the task;
source: where it came from;
owner: who or which artifact can confirm, correct, or revoke the item;
validity: in which version, product, environment, or rule this information still applies.

This matrix does not need to become bureaucracy. It can be in the issue body, the task template, the comment accompanying the pull request, or the team’s operational document. The point is not to create another document repository. It is to prevent information without provenance from being treated as instruction.

A practical criterion helps: if the team cannot say where information came from, it should be marked as a hypothesis. A hypothesis can guide investigation but should not guide automatic implementation. If there is no owner, the information may be useful but must be used cautiously. If validity is uncertain, the team needs to resolve the doubt before delivering the change as if it were safe.

Context relevance checklist

Relevance: does this information change the implementation, test, or review decision for this specific task? If it does not change, remove it from the main context.
Source: did the information come from code, test, documentation, recorded decision, review comment, business rule, or responsible person? If the source does not appear, treat it as a hypothesis.
Owner: is there someone or an official artifact who can confirm, correct, or revoke this information? If not, do not use it as the sole basis for the change.
Validity: does the information still apply to the current version, product, client, environment, or rule? If not, mark it as historical.
Conflict: is there another source saying something different about the same point? If so, resolve the conflict before requesting the change.
Test: can the information be confirmed by automated test, defined manual test, or objective review? If not, separate it as a human decision or investigation.
Permission: should the agent or tool access this information and act on it in this environment? If not, exclude it from the operational context.

This checklist is a practical application. It does not replace requirements discovery, architecture decision, or human review. It only makes explicit what many teams leave implicit.

How to choose relevant context for a small change

Context engineering becomes more difficult when the task is too large. If the change mixes business rule, refactoring, visual alteration, technical migration, and behavior correction, the necessary context also spreads. The team then needs more sources, more owners, and more validity criteria.

DORA recommends small, independent, and testable work units to get feedback on changes and review hypotheses earlier. The same source warns about the difficulty of reviewing and integrating large AI-generated changes.

This guidance does not prove that a small task always has better results with AI. But it offers an operational criterion: the smaller and more testable the change, the clearer the set of information that should guide it tends to be.

Instead of requesting “adjust the discount flow,” the team can cut the task: “change the discount rule for orders with promotional coupons in a specific channel, preserving existing behavior in other channels.” This cut changes the search for context. Now the rule files, tests for that flow, the current coupon decision, the person or area responsible for the rule, and the verification criteria matter.

This cut requires a specific organizational capability: deciding scope, source, and responsibility before increasing the tool’s autonomy. Diagnosing this capability can be considered alongside topics such as AI maturity, but practice starts with each task.

Fictional example: changing a discount rule without contaminating the task

Imagine a fictional example. An e-commerce company needs to change a discount rule for orders made through a partner channel. The task arrives like this: “Update partner discount according to new rule. See docs and old comments.”

In the first scenario, the team sends the programming agent a folder of documentation, some old issues, review comments, and checkout module files. Everything seems relevant. But there is conflict: a documentation page describes the old rule, an issue mentions a temporary exception, a pull request comment suggests a change never implemented, and the current test confirms another behavior.

AI can produce a plausible change. But the team does not know if it followed the new rule, the old exception, or an interpretation of the comments. Human review becomes heavier because it needs to reconstruct the context after the code is ready.

In the second scenario, before the request, the team organizes the context:

Information: partner discount must follow the current rule for the specific channel.
Source: rule recorded in current product documentation and confirmed in the existing test covering the base flow.
Owner: person responsible for the commercial rule or official artifact defined by the team.
Validity: applies only to the partner channel and the current version of the rule.
Conflict: old issue marked as historical because it described a temporary exception.
Test: update or create a test that confirms the behavior of the affected channel and preserves the others.
Permission: agent can read the module files and related tests but should not change rules for other channels.

This second request does not guarantee a correct output. The hypothesis to measure is more modest: review tends to be more objective when the context used in generation already separates current source, history, and scope restriction. The team still needs to review code, tests, and rule adherence. The difference is that the conversation stops being “what did the AI understand?” and becomes “was the provided context correct, sufficient, and authorized?”

This change of question is small but shifts process responsibility.

Where human review fits in context engineering

Human review should not appear only at the end as a late correction step. In AI-assisted tasks, it also needs to review context before and during the work.

GitHub documentation describes agent features with distinct environments and permissions and emphasizes human supervision and output review. For development teams, this allows a practical reading: permissions, environment, and review are part of work design, not just the tool.

In practice, human review should answer questions such as:

Did the agent have access only to what was necessary for the task?
Did any sensitive, historical, or unauthorized information enter the operational context?
Was the main source of the rule clear?
Was there conflict between documentation, code, and review comments?
Did the request separate instruction, hypothesis, and reference?
Do the tests used to verify the change correspond to the current rule?

This type of review requires judgment. It is not a formality to satisfy governance. It is the way to prevent the team from outsourcing to the model a decision that still belongs to the process.

This is also where technical leadership and product leadership meet. Not every context item is technical. A business rule, an operational constraint, or a product decision can determine what the code must do. If this information enters without an owner, the engineering carries ambiguity that cannot resolve itself.

Closing criterion: context survives continuous integration

The last check is simple to formulate and difficult to sustain: does the context used in the change still make sense when the change reaches the main code?

DORA describes continuous integration as frequent integration into the main code, accompanied by automated build and tests. It also states that fixing a broken build should have priority over new changes.

For context engineering, this creates a closing criterion about context persistence, not task division. Before integrating an AI-assisted change, the team must verify that:

the change remains within the defined scope;
tests correspond to the information that guided implementation;
documentation or decision used as source remains valid;
conflicts discovered during review were resolved or recorded;
automated build was not broken;
a build failure blocks new changes until fixed.

This criterion does not promise quality, speed, or defect reduction. It reduces a common inconsistency: treating context as useful to generate code but disposable when integrating.

If the rule used to guide the agent does not appear in tests, review, or recorded decision, it remains fragile. If a historical exception entered the request without marking, it can reappear as new behavior. If the team does not know who owns information, it probably will not know when it stops being valid.

Context engineering depends less on rhetorical trust in technology and more on operational trust in the source, responsibility, and validity of the information guiding the work.

In the next AI-assisted task, before requesting, reviewing, or integrating the change, list the information that really guides the change and mark source, owner, and validity for each. If information does not pass this filter, treat it as a hypothesis or remove it from the operational context.

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 linking this topic to the reader’s journey and tracking interest in the subject.