dooopSoftware · Process · 12 min

How to Decide Which Tasks Not to Delegate to AI

Use ambiguity, impact, and verification to separate delegable, assisted, and human tasks before activating AI in programming.

Published on September 6, 2026

CENTRAL THESIS

AI accelerates execution but does not resolve ambiguous intent. Screening prevents delegating decisions that do not yet exist.

Ambiguity, impact, and verification separate delegable, assisted, and human tasks before activating AI.

The limits of AI in programming do not appear only when the code is difficult. They appear when the task requires deciding on ambiguous intent, assuming relevant impact, or accepting a result that cannot be safely verified before reaching the user.

Therefore, the practical question is not whether artificial intelligence can generate a plausible change. It is whether that task can be delegated, requires active human guidance, or should be conducted by people with AI only as support.

When a Task Seems Simple but Still Requires Judgment

Before activating a programming agent, the team may realize that an apparently small task still has something out of place. The change touches an unwritten rule, affects a sensitive journey, or depends on a product decision that no one has clearly formulated.

This discomfort is a useful signal. It shows that the difficulty of the task is not only in implementation. It lies in the responsibility to interpret what must be true.

A text change on a screen can be simple if the approved message already exists. The same change can be delicate if it alters the user's expectation about a deadline, a charge, a permission, or an operational exception. A refactoring can be safe when it preserves tested behavior. It can be risky when it changes the boundary between domains, redistributes responsibilities, and makes a failure harder to diagnose.

Human guidance should not come only at the end, as a late review of something AI has already effectively decided. It needs to appear before execution when the task mixes incomplete intent, relevant consequence, and weak verification.

In screening, the question changes: will AI execute a decision already made or occupy a decision the team has not yet organized?

Use Three Criteria: Ambiguity, Impact, and Verification

An objective way to choose AI-assisted tasks is to classify the work by three criteria: ambiguity, impact, and possibility of verification.

Ambiguity is the lack of clarity about intent or rule. It appears when the description uses expressions like “improve,” “adjust,” “avoid problems,” “handle exceptions,” or “make more flexible,” without saying which behavior should change and which should remain the same. It also appears when there is tacit knowledge in product, support, operation, or architecture.

Impact is the consequence of the change. It can be technical, operational, reputational, security-related, revenue-related, user trust-related, or service continuity-related. It is not just the size of the diff. One line of code can carry more impact than a broad reorganization of visual components.

Verification is the ability to confirm that the result is correct. This may involve automated tests, peer review, logs, before-and-after comparison, acceptance criteria, staging environments, or approval from a responsible area. DORA describes continuous integration as frequent integration into the main codebase, accompanied by automated build and tests. In the screening proposed here, this helps reveal problems early but does not replace human decision when the expected behavior is not yet clear.

The screening question becomes simple:

Is the intent written so that a different person would make the same decision?
Is the impact of the change low, reversible, and isolated?
Is there an objective way to verify the result before exposing users or critical systems?

If all three answers are positive, the task tends to be delegable to AI with review. If one or two answers are uncertain, AI can help, but a person must guide the interpretation. If all three are fragile, the task should be conducted by people, with AI as support for research, comparison, simulation, or documentation.

Delegable Tasks Are Small, Independent, and Testable

Delegable tasks are those where AI can perform most of the work without assuming the central decision. They usually have a small scope, explicit expected result, low impact, and clear verification.

Typical examples include:

Updating already approved nomenclature in isolated components.
Adding tests for already defined behavior.
Fixing a visual inconsistency with an objective criterion.
Adjusting a simple adapter when contract, input, and output are clear.
Removing identified dead code covered by tests.

DORA recommends working in small, independent, and testable units to get earlier feedback on changes and review hypotheses with less delay. The same guidance warns about the difficulty of reviewing and integrating large AI-generated changes, especially when they arrive as broad blocks that are hard to decompose DORA.

The practical application is not to turn every task into mechanical micro-work. It is to avoid giving an agent a mission that is too broad, producing a change that is too large and forcing the team to review intent, architecture, business rule, and test all at once.

A delegable task should fit into a verifiable sentence. For example: “change the label of button X to the approved text Y in files A and B, without changing behavior, maintaining current tests.” In this case, AI can support execution because the decision has already been made. Human review confirms adherence to scope, code quality, and absence of apparent side effects.

The limit appears when the description becomes: “improve the billing flow to reduce doubts.” This phrase may be a good product intention but is not yet a delegable task. Before that, someone needs to separate hypotheses, rules, messages, events, exceptions, and verification criteria.

This care aligns with broader decisions about organizing AI-assisted work. An AI roadmap connected to real opportunities helps prioritize where technology fits. In engineering, the same logic needs to descend to the task level: what is clear, what is risky, and what can be proven.

Assisted Tasks Require a Person Guiding Interpretation

There is an intermediate range where AI is useful but should not lead alone. These are tasks where part of the work is implementable, but interpretation requires ongoing human judgment.

This includes ambiguous business rules, adjustments in flows used by customers, refactoring that changes domain boundaries, changes with dependencies between areas, or defect fixes whose diagnosis is not yet closed.

In this range, the person leads the task in short cycles. They formulate the hypothesis, select the context, request alternatives, compare effects, and decide the next step. AI can generate code, suggest tests, raise related files, summarize history, and explain possible impacts. But the direction remains human.

Context engineering helps at this point. Anthropic defines context engineering as the selection and maintenance of information available to the model during inference, including instructions, tools, external data, and history, within a limited window Anthropic. Practically, this means the AI’s output depends on what was presented and what was left out.

When the task depends on dispersed knowledge, human guidance must decide which context matters. It is not enough to dump documents into the agent. It is necessary to specify which rule prevails, which files delimit the scope, which behaviors cannot change, and at what point AI should stop to request a decision.

A good instruction for this range is not just “implement.” It looks more like:

“Map affected points before changing code.”
“List business rule doubts before implementation.”
“Propose options and risks without modifying files yet.”
“Implement only the approved alternative.”
“Stop if undocumented behavior or contradictory tests are found.”

Human review here is not just a step in the pull request. It is guidance during reasoning. This reduces the risk that a missing decision is filled in by the most likely, most convenient, or most coherent path with incomplete context.

Human Tasks Use AI as Support, Not as Main Executor

Some tasks should not start as autonomous AI execution. Not because AI is useless, but because the central work is to decide, negotiate trade-offs, and assume consequences.

This range includes architectural decisions difficult to reverse, changes that affect user trust, changes without a clear form of verification, incidents without reliable diagnosis, rule exceptions with operational impact, and decisions requiring alignment among product, engineering, and leadership.

GitHub’s documentation on Copilot agents describes features with distinct environments and permissions and emphasizes human supervision and output review GitHub. This guidance aligns with a simple practice: the greater the autonomy granted to a tool, the more explicit scope, permission, stopping, and review must be.

In human tasks, AI can support in various ways:

Summarize already documented architectural alternatives.
Compare pros and cons of options formulated by the team.
Generate questions for a decision meeting.
Create test drafts after expected behavior is defined.
Help document the decision made.

But AI should not alone choose the business exception, define risk tolerance, decide a sensitive experience change, or turn an implicit preference into a system rule.

Here is an uncomfortable phrase: delegating execution when the decision does not yet exist is an elegant way to hide misgovernance.

Maturity is not in banning AI in these situations. It is in preventing it from becoming a shortcut for decisions that should be explicit. Leadership that treats AI as part of strategy needs to connect technical capability to decision responsibility, as in an artificial intelligence strategy connected to business, not just to automation of isolated tasks.

Fictional Example: Changing the Late Payment Rule

Imagine a digital product that needs to adjust communication and late payment calculation in a billing routine. This example is fictional and serves only to apply the criteria. Expected effects would be hypotheses to measure, not occurred results.

The first subtask is renaming interface messages. The approved text already exists, affected components are known, and the change should not alter behavior. Ambiguity is low, impact is limited, and verification is direct by visual review and existing tests. This task can be delegable to AI with human review.

The second subtask is adjusting the calculation of days late. Now there is more risk. The rule seems objective but may depend on time zone, holiday, closing time, reprocessing, or divergence between systems. AI can help map calculation points, suggest tests, and implement an alternative. But a person must guide interpretation, confirm the rule, and require tests covering relevant scenarios. It is an AI-assisted task with active human guidance.

The third subtask is deciding exceptions for specific customers. Here the main issue is not code. It is product and operation policy. Who can receive exceptions? Under what conditions? How to record the decision? Who assumes impact if two users in similar situations are treated differently? Before any code generation, people need to define the rule, risk, and verification method. AI can help organize options and document the decision but should not lead the main execution.

The point of the example is not to classify billing as always sensitive. It is to show that the same initiative contains tasks of different natures. Some are delegable. Others require guidance. Others need human decision before becoming technical backlog.

That is why screening must happen before activating AI, not only at final review.

Screening Checklist Before Executing with AI

Use this checklist before handing a task to a programming agent or any AI-assisted code flow. The criteria below are a practical proposal for the team’s decision.

Ambiguity

Low human guidance: intent is written, expected behavior is objective, and there is no dispute about the rule.

Active human guidance: general intent exists, but there are exceptions, vague language, or dependence on business context.

Primary human guidance: the task requires deciding what must be true, not just how to implement.

Impact

Low human guidance: the change is reversible, isolated, and affects a low-risk area.

Active human guidance: the change touches flows used by customers, integrations, or rules with operational consequences.

Primary human guidance: the change may affect revenue, security, compliance, user trust, or service continuity.

Possibility of Verification

Low human guidance: there are automated tests, clear acceptance criteria, or objective comparison before delivery.

Active human guidance: part of the result can be tested, but final validation depends on rule, product, or operation review.

Primary human guidance: the team cannot prove the correctness of the change before exposing users or critical systems.

Available Context

Low human guidance: instructions, relevant files, and constraints are available for the task.

Active human guidance: context exists but needs to be selected, explained, or protected against misinterpretations.

Primary human guidance: necessary knowledge is dispersed, tacit, or depends on a decision not yet made.

Stopping Criterion

Low human guidance: AI can proceed if it maintains scope and tests continue passing.

Active human guidance: AI must stop upon finding undocumented rules, unexpected dependencies, or divergence between tests and intent.

Primary human guidance: the task should not start as AI execution while decision, risk, and verification are undefined.

Before execution, the task must fall into one of these three ranges: delegable to AI with review, AI-assisted with active human guidance, or conducted by people with AI only as support.

If the task lacks clear intent, understood impact, and a way to verify, it is not ready for autonomous delegation. First, the team must decide what kind of responsibility that task carries before handing the keyboard to AI.

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

Sources

To Continue This Reading

How to Close a Development Task with AI

NEXT DECISION

Discuss 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.