dooopPillar page · 16 min

AI-Enhanced Development: Process, Context, and Verification

Understand how to organize software development with AI in small cycles, with clear context, controlled scope, and verification before merging.

Published on September 6, 2026

CENTRAL THESIS

AI accelerates code writing but also amplifies ambiguities. The process must decide what can move forward.

Organize each task with context, small batch size, and verification. Gains depend on control before merging.

Software development with artificial intelligence fails when a task that is too fast reaches review without context, limits, and evidence. When AI generates code quickly, the team needs clear visibility of what was requested, what context was used, where the change starts and ends, and how it will be verified before entering the main codebase.

The minimal cycle is simple to name and difficult to practice: sufficient context, execution in small units, and human and automated verification before integration.

Where AI-Assisted Tasks Lose Control

The problem appears in a familiar scenario: a pull request arrives with a lot of code, a convincing explanation, and partial tests. The description seems reasonable. The change compiles in some environment. The reviewer understands the general intention but cannot confidently answer basic questions.

What exactly was requested? Which files did the AI consult? Did the solution only change the requested behavior or also reorganize neighboring sections? Do the tests cover the business rule or just confirm that the new implementation does not break the happy path? Who decided the remaining risk was acceptable?

AI increases execution capacity but does not automatically increase process maturity. It can produce more alternatives, more code, and more explanations in less time. This is useful. It can also shift the bottleneck to review, integration, and mental reconstruction of what happened.

This shift concentrates risk in the final review, which accumulates discovery of scope, intention, architecture, testing, impact, and decision. When this happens, the team is not using AI to amplify development. It is using AI to anticipate work that has not yet been well defined.

The difference matters. AI-assisted development should not be organized as a queue of prompts. A prompt is an interface. Process is how the organization decides, executes, checks, and learns from a change.

In engineering teams, this changes the main question. Instead of only asking "which tool will we use?", it is worth asking: "which cycle prevents plausible code from entering without context, limits, and sufficient verification?"

This cycle needs to be small enough to fit daily work and explicit enough to survive haste.

The Minimal Cycle: Context, Execution, and Verification

An AI development process can quickly become sophisticated. It can involve agents, isolated environments, permission policies, test automations, assisted review, and living documentation. All of this can have a place. But the operational design must start with three responsibilities.

Context: define what the AI needs to know and respect before changing code.
Execution: transform the task into small, independent, and testable changes.
Verification: confirm behavior, scope, and integration before advancing the change.

This cycle does not depend on treating AI as an autonomous author or as simple autocomplete. It works because it separates responsibilities that many teams mix under pressure.

Context is not dumping the entire repository into the tool. It is selecting relevant information to reduce guessing. Execution is not accepting the largest possible response. It is limiting the change so it can be reviewed. Verification is not looking for defects after everything is done. It is deciding if that change deserves to move forward.

This separation also helps technical leadership better distribute human judgment. The person should not only enter at the end, tired, facing a change that is too large. Human judgment appears before, when formulating the task. During, by interrupting deviations. After, by confirming if the change should be integrated.

For organizations structuring broader AI adoption, this segmentation aligns with a prior decision: connect AI use to business priorities, not just technological enthusiasm. This point appears in dooop's guide on AI strategy connected to business, but here the unit of analysis is smaller: a software change.

The practical question is: is this task ready to be amplified by AI or does it still need refinement by people?

Context: What AI Needs to Know Before Changing Code

Context engineering is the selection and maintenance of information available to the model during inference. The Anthropic definition includes instructions, tools, external data, and history, always within a limited window. This limitation is relevant: if everything does not fit, someone needs to choose what goes in.

In AI software development, context is an engineering decision, not a bureaucratic attachment. It guides the model on what the task intends to change, what constraints exist, and which paths should not be followed.

A minimally prepared task should make explicit some elements.

Change objective: what behavior should be created, corrected, or preserved.
Allowed scope: which modules, files, or layers can be changed.
Technical constraints: already adopted standards, dependencies that should not be introduced, architectural and compatibility limits.
Acceptance criteria: how the team will know the change worked.
Known risks: sensitive parts, edge cases, and expected impacts.
Useful evidence: existing tests, architectural decisions, logs, usage examples, or internal documentation.

Curation is as important as quantity. A large, contradictory, and unprioritized context can worsen the decision. The model may follow an old instruction, interpret an exception as a rule, or propose a solution coherent with an irrelevant piece of history.

Therefore, the team needs to treat context as a living artifact of the task. If during execution an unknown business rule appears, the answer is not to ask the AI to "try anyway." The task returns for refinement. If the architectural constraint is unclear, the team records the decision or points to where it is already documented. If the change depends on untested behavior, this must appear in the verification criteria.

This discipline does not require creating encyclopedic documentation before each change. It requires recognizing that AI will fill gaps when they exist. Some gaps are acceptable. Others transfer too much risk to an output that seems safe only because it is well written.

There is a simple criterion: if a new person on the team cannot understand the objective, limit, and verification method of the task, AI is probably also operating with insufficient context.

This point connects to organizational capability diagnosis. Before scaling tools, it is worth knowing if the organization can formulate problems, prioritize risks, and maintain useful information. The topic appears at another level in content about AI maturity. In the development cycle, maturity appears as operational clarity.

AI Software Development Requires Execution in Small Units

After context comes execution. Here the temptation is to ask for too much at once: fix the defect, improve function names, refactor an old service, update tests, and reorganize a dependency. AI may accept. The problem is the team then needs to review everything together.

DORA recommends small, independent, and testable work units to get feedback on changes and review hypotheses earlier. The same guidance warns about the difficulty of reviewing and integrating large AI-generated changes. This point does not make AI a problem by itself. It shows that size and mixing objectives remain critical factors.

A small unit is not just a change with few files. It is a change with a verifiable hypothesis. "Fix the rounding rule in freight calculation for orders with coupons" is more reviewable than "improve checkout." "Add test to preserve current behavior before change" is different from "rewrite the test suite."

The right size depends on the system, team, and risk. But some signs indicate the task is too large for AI-assisted execution.

The description contains several intention verbs, such as fix, refactor, optimize, and standardize.
The change crosses layers without explanation.
The model proposes changes in files not cited or justified.
The review requires understanding a new architectural design not part of the task.
Added tests validate implementation details but not expected behavior.

In these cases, the correct decision may be to divide before generating more code. One part investigates. Another preserves behavior with tests. Another changes the rule. Another removes technical debt if it really needs removal. Not everything needs to happen in the same pull request.

This discipline reduces the temptation of "while we're here." In AI development, this phrase deserves caution. The model can easily execute collateral improvements, but ease of change is not authorization of scope.

Technical leadership has a direct role: protect the decision unit. If the change fixes a rule, the review must be able to decide on that rule. If refactoring is necessary, it must have its own justification. Mixing the two makes the decision opaque.

Verification: What Needs to Happen Before Integration

The verification step begins before the merge button. It answers four questions: does the solution meet the intention? Was the scope respected? Was the behavior tested? Does the base remain healthy for new changes?

GitHub documentation describes agent features with distinct environments and permissions and emphasizes human supervision and output review. For the engineering process, this supports a practical rule: even when the tool executes tasks in its own environments, acceptance of the change must pass review.

Human review of AI-generated code should not be an aesthetic check. It needs to verify intention. The reviewer must look for the relationship between task, context, change, and evidence. An elegant implementation may be solving the wrong problem. A passing test may only cover the path the model chose.

A practical verification sequence can follow this reasoning.

Read the task and confirm the expected behavior before reading the solution.
Compare changed files with the allowed scope.
Check if the change introduced dependencies, patterns, or shortcuts not requested.
Verify if automated tests cover the acceptance criteria.
Run build and tests defined by the team.
Decide if the change can be integrated, needs adjustment, or should be discarded.

Continuous integration also fits here. DORA describes continuous integration as frequent integration into the main code, accompanied by automated build and tests. The guidance also states that fixing a broken build should have priority over new changes. For an AI flow, this reinforces a limit: it makes no sense to stack new outputs on a base that is already unhealthy.

Verification needs interruption criteria. If the agent changes a file outside the scope, stop. If the justification does not match the diff, stop. If the solution depends on an undocumented rule, stop. If the test fails and the response is to change the test without explaining the behavior change, stop.

Stopping is not failure. It is process control.

This is one of the most culturally difficult decisions because AI output creates a sense of progress. A well-presented output may seem like sufficient progress. Without verification, however, the team postpones the work of confirming behavior, scope, and impact.

Fictional Example: Fixing a Discount Rule Without Opening Refactoring

Consider a fictional example in an e-commerce platform. The team identifies that a promotional coupon should not accumulate with a volume discount rule. In some orders, both discounts appear together. The task seems simple but touches a sensitive checkout area.

A poor AI input would be: "fix discounts in checkout and improve code." This formulation opens space for many implicit decisions. The model may restructure the calculation, rename functions, change application order, modify broad tests, and still deliver a plausible explanation.

A better input separates context, execution, and verification.

Minimal task context:

Objective: when a promotional coupon is applied, the volume discount should not be added to the total.
Allowed scope: change only the component responsible for discount composition and tests related to this rule.
Constraint: do not change the general order of tax, freight, or total calculation.
Acceptance criteria: order with promotional coupon and quantity eligible for volume discount should apply only the coupon.
Preservation case: order without coupon should continue applying volume discount when eligible.
Known risk: checkout changes may affect calculation displayed in order summary.

Execution must fit in a small unit. First, the team can request creation or adjustment of tests expressing both behaviors: with coupon and without coupon. Then, the code change must be limited to discount composition. If AI proposes reorganizing the entire discount strategy, this should be refused or separated into another decision.

Verification also needs to be concrete. The reviewer checks if the test fails before the fix, when this is part of the team flow. Checks if the solution did not change tax, freight, or totalization. Checks if the naming used in code corresponds to the business rule. Checks if the diff does not include opportunistic refactoring files.

In this fictional example, expected effects would be hypotheses to measure, not presumed results. The team could observe if the change became easier to review, if there was less scope discussion, and if tests gave enough confidence to integrate. But this would need to be monitored in the organization's real flow. It should not be declared as automatic gain.

The point of the example is not the discount rule. It is the limit. AI can help write the test, locate relevant sections, and propose implementation. The team remains responsible for deciding which problem is being solved and which problem will not be solved now.

This decision not to expand scope is a form of technical leadership. It prevents each small task from becoming a disguised overhaul.

Minimal Execution Standard for AI Development

The pattern below organizes the context, execution, and verification cycle. It does not replace architecture, security review, domain-appropriate tests, or team-specific criteria. It serves as a filter to decide if a task is ready for AI, if execution should continue, and if the change can be integrated.

Does the task have a verifiable objective?

Before triggering AI, the team must be able to say which behavior needs to change and how they will know the change worked. If the objective cannot be tested, observed, or demonstrated, the task returns for refinement.

Decision criterion: if the description uses terms like "improve," "adjust," or "optimize" without observable behavior, it is not ready yet.

Is the context limited to what helps the decision?

Including relevant instructions, files, rules, and history helps reduce guessing. But context without curation creates noise. The question is not "how much context can I attach?" but "which information changes decision quality?"

Decision criterion: if AI needs to guess business rules, architecture, or constraints, the task is not ready.

Does the change fit in a small, independent, and testable unit?

Execution must produce a change that can be reviewed without mixing correction, refactoring, and collateral improvement. Small batches make the hypothesis clearer and help review earlier, in line with DORA guidance on small work units.

Decision criterion: if the change has multiple objectives, divide before generating code.

Are there clear criteria to stop the AI?

The team must define stop signals. Change outside scope, broken test, unexpected file changed, new dependency without justification, or inconsistent explanation are enough signals to stop.

Decision criterion: if the output expands the problem instead of solving the task, stop and respecify.

Does human review verify intention, not just syntax?

Human review must confirm the solution meets the objective, preserves constraints, and does not create unnecessary dependencies. Supervision is not a stamp at the end of the flow. It is part of the process design.

Decision criterion: if the review only checks style, formatting, or compilation, verification is incomplete.

Does integration depend on build and tests in a healthy state?

Before integrating, the change must pass build and automated tests defined by the team. If the base is broken, new AI outputs may only increase confusion. DORA guidance on continuous integration reinforces that fixing the broken build should have priority over new changes.

Decision criterion: if the build breaks, fix that before proceeding with new changes.

How to Turn the Cycle into Technical Leadership Decisions

AI adoption in engineering should not be judged only by the amount of code produced. Code produced is a step. The management question is whether the organization can transform intention into verifiable change without losing scope control.

In practice, this shifts technical leadership to decisions about scope, evidence, and integration. Define which tasks can use AI. Establish minimal context. Limit change size. Maintain human review with real authority. Do not integrate over a broken base. Record when the task returned for refinement and why.

These choices also help avoid two extremes: blocking AI for fear of losing control or releasing AI as if the final review could absorb any previous ambiguity. The useful criterion is to use AI where the process can preserve decision, traceability, and safe integration.

If the organization is still formulating its adoption agenda, it is worth connecting this cycle to a broader vision of priorities, risks, and capabilities. Content about AI roadmap can help at this layer. For engineering teams, the first decision is closer: choose a class of tasks, apply the cycle, and observe where the process fails.

To start, define a minimal standard of ready task, small change, and mandatory verification. Then choose a low-coupling change category, apply the cycle, and record points where the team needed to stop, divide, or respecify.

If it makes sense to discuss how this cycle fits your organization, talk to dooop.

Sources

NEXT DECISION

Discussing Application in Your 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.

Deepen this topic

How to adopt AI in legacy systems safelyUse AI in legacy systems with small changes, observable tests, and human review to preserve critical behaviors.How to conduct a process pilot with AICompare current and AI-assisted flows with the same standard, using small changes, prior criteria, human review, and tests.How to coordinate parallel code agentsDefine boundaries, acceptance, dependencies, integration order, and joint review before running parallel code agents.How to decide which tasks not to delegate to AIUse ambiguity, impact, and verification to separate delegable, assisted, and human tasks before triggering AI in programming.How to divide tasks for programming agentsLearn to create small, verifiable, and reversible tasks for programming agents, with context, scope, and independent acceptance.How to close AI-assisted development tasksClosing an AI task requires validating behavior, reviewing scope, and recording who accepts the risk before treating code as delivery.How to write specifications for AI developmentLearn to define behavior, scope, constraints, acceptance, and stop condition in specifications for AI development.How to hand off context between developersUse a short record of decision, state, next action, risk, and evidence to avoid rework when tasks change hands.How to integrate AI into continuous integration safelyUse AI in CI flow without exceptions: keep small batches, reproducible builds, relevant tests, and human review before merge.How to limit scope of AI-generated changesDefine boundaries before prompt, separate correction from refactoring, and review AI diffs with clear criteria to avoid out-of-scope changes.How to maintain useful documentation for people and agentsKnow when changes in interfaces, rules, decisions, operation, or permissions require updating, archiving, or removing documentation.How to organize human review in AI flowsSeparate automation, context, and human judgment to review AI pull requests according to impact, ambiguity, tests, and risk.How to plan AI refactoring without changing behaviorBefore the first prompt, define protected behavior, scope limits, and review so AI reorganizes code without changing the product.How to prepare repositories for AI workSee how to make commands, conventions, and boundaries discoverable in the repository to reduce ambiguities in AI-assisted changes.How to redesign development flow with AIMap waits, rework, and context loss to choose where to redesign AI development flow without accelerating problems.How to reduce rework in AI-generated codeClassify failures as requirement, context, or verification before fixing AI code and reduce recurrence with smaller changes.How to record architecture decisions for AI useLearn to create useful ADRs for AI, with context, alternatives, consequences, and review criteria guiding people and agents.How to use AI in requirements discoveryUse AI to organize evidence, reveal gaps, and transform scattered reports into testable hypotheses before specifying requirements.How to use AI to investigate bugs without skipping stepsUse AI to organize evidence, compare hypotheses, and define minimal reproduction before confirming defect cause.How to use AI prototypes without overvalidatingUse AI prototypes to test observable hypotheses in discovery, without confusing convincing simulations with real validation.How to version instructions for code agentsChanges in agent instructions must have hypothesis, small batch test, regression criteria, responsible party, and clear rollback.Context engineering for development teamsHow to select origin, responsibility, and validity of context to reduce noise in AI-assisted development tasks.AI failures: how to improve context without creating noiseLearn to decide when an AI failure becomes context, where to record the fix, and how to avoid contradictory rules in the agent.Retrospective with AI: how to create small experimentsUse retrospectives to transform frictions in AI development into testable hypotheses, clear limits, and review criteria.