The optimal task is not the smallest piece of work we can describe. It is the largest coherent piece of work we can reliably complete.
The Task Is a Legacy Abstraction
Software engineering has spent decades optimizing how we break work into tasks.
Epics become stories. Stories become tickets. Tickets become subtasks. We estimate their complexity, assign ownership, coordinate dependencies, track progress, and measure velocity.
This decomposition made sense.
Human engineers have limited working memory, competing priorities, and finite attention. Teams need boundaries for assigning work, communicating expectations, and coordinating progress.
Small tasks offer predictability. They make estimation easier, reduce the impact of individual failures, and create frequent opportunities to inspect progress.
But what happens when the primary executor is no longer a human engineer?
What if an AI agent can understand a substantial portion of a system, modify dozens of files, execute tests, evaluate results, and complete an entire feature in one continuous workflow?
Should we still decompose that feature into fifteen tickets?
Or are we imposing the limitations of human-centered software development onto a fundamentally different execution model?
I believe the definition of a task needs to change.
From the Smallest Manageable Task to the Largest Coherent Task
Traditional engineering often encourages breaking work into small, independently manageable units.
In AI-native engineering, I would argue for a different objective:
Find the maximum scope of work that an AI system can understand, execute, and validate reliably with the context and capabilities available to it.
This is not an argument for giving an agent an enormous request and hoping for the best.
It is an argument that task size should be an engineering decision informed by the capabilities of the execution system.
Consider a feature that involves:
- Updating an API contract.
- Implementing backend behavior.
- Modifying a database schema.
- Updating client integration.
- Adding tests.
- Updating documentation.
A traditional workflow might distribute this across multiple tickets, potentially involving several engineers.
An AI-native workflow could treat the entire feature as one task, provided the agent can maintain a sufficiently accurate understanding of the system and validate the resulting behavior.
The advantage is not simply fewer tickets.
It is preserving the coherence of the intended change.
When an agent understands the entire feature, it can reason about consistency across its components instead of navigating separately defined fragments of the same intent.
In this model, decomposition should be driven by context boundaries, validation boundaries, and execution risk, rather than arbitrary expectations about task size.
Context Is the New Task Boundary
Modern AI models have increasingly large context windows.
But the advertised context window is not the same as the amount of context a model can effectively use.
A model may technically accept an enormous quantity of information while becoming less reliable at identifying the important details, maintaining relevant constraints, and reasoning across distant dependencies.
We need to distinguish three concepts.
| Concept | What it measures |
|---|---|
| Context capacity | How much information the model can technically accept. |
| Effective context | How much relevant information the model can use reliably for a particular type of work. |
| Task context demand | How much information the task requires for correct execution. |
These quantities are not interchangeable.
A task may fit within a model’s context capacity but exceed its effective reasoning capability. Another task might require significantly less context because its dependencies are well understood and its interfaces are stable.
The goal is not to fill the context window.
The goal is to maximize useful work within the model’s effective context.
This leads to an important design principle:
Task scope should be tailored to the model, the available context infrastructure, and the nature of the work.
The same task can be appropriate for one model and too ambitious for another.
The same model can handle a larger task when the relevant architecture, dependencies, constraints, and validation tools are made available in a structured form.
This makes task definition dynamic rather than static.
The Maximum Effective Task
We can think of the optimal task boundary as an optimization problem.
Let:
- S represent the scope of a task.
- C represent the quality and coverage of relevant context.
- M represent model capabilities.
- V represent the strength of available validation.
- R represent execution risk and recovery cost.
Then the optimal task scope is not simply the maximum scope that fits inside the available context.
It is the largest useful scope for which execution reliability remains acceptable:
Maximize S, subject to acceptable reliability, validation coverage, and recovery cost.
More practically, we want to maximize:
Validated value delivered / Total execution cost
Total execution cost should include more than tokens and inference time. It also includes context preparation, orchestration, repeated attempts, human review, and rework after failures.
This distinction matters because larger tasks have competing effects.
| As task scope increases, the agent may gain | But it also takes on |
|---|---|
| Greater architectural coherence | More dependencies |
| Fewer handoffs | More possible mistakes |
| Less repeated context preparation | Potentially more expensive recovery |
The optimal task is therefore not necessarily the biggest task an agent can attempt.
It is the biggest task that remains economically and operationally effective.
Why Bigger Can Be Better
There is a hidden cost to splitting work into small tasks: each boundary can lose information.
Suppose an agent needs to implement a new capability across a service.
We could break the work into separate tasks for design, implementation, testing, and documentation.
Each task might require reconstructing some of the same context. Decisions made in one task must be transferred to another. Assumptions can drift, and inconsistencies may emerge.
Now imagine the agent executing the entire change as one coherent unit.
It can use the original intent while designing the implementation, writing tests, and reconciling the documentation.
The potential benefits include:
- Less repeated context preparation. The system does not need to repeatedly reconstruct the same understanding.
- Fewer coordination boundaries. Decisions can propagate across related artifacts without waiting for separate task handoffs.
- Greater consistency. Implementation, tests, interfaces, and documentation can be evaluated against one shared objective.
- Stronger end-to-end optimization. The agent can select a solution that is effective for the overall feature rather than optimizing isolated tickets.
This connects directly to the idea of maximum engineering velocity.
Velocity is not the number of tasks completed. It is the rate at which valuable, validated changes reach users.
A workflow completing one coherent feature may be more effective than one completing twenty disconnected subtasks.
However, larger scope only delivers these advantages when the execution system can manage it reliably.
Otherwise, the coordination overhead we eliminate is replaced by debugging and recovery overhead.
The Task Should Have One Coherent Intent, Not Necessarily One Small Change
One subtle point deserves attention.
A large task should not become a collection of unrelated requests merely because the model has enough capacity.
The task needs a coherent objective.
For example:
Implement support for customer-configurable log retention across our platform.
That is a meaningful unit of work. It might involve API design, configuration storage, retention enforcement, permissions, monitoring, testing, and documentation.
All of these changes serve one objective.
By contrast:
Implement retention policies, optimize query performance, redesign authentication, and migrate the billing system.
Even if a sufficiently capable model could work on all four, combining them would provide little benefit from shared context.
| Coherent task | Bundled request | |
|---|---|---|
| Objective | One: customer-configurable log retention | Four unrelated objectives |
| Work involved | API design, configuration storage, retention enforcement, permissions, monitoring, testing, docs | Retention, query performance, authentication, billing |
| Shared context | Every change serves the same intent | Little overlap between the parts |
| Benefit of one task | Consistency across the whole change | Little benefit from shared context |
There is an important difference between maximizing scope and maximizing coherence.
The task should contain as much related work as the execution system can reliably handle, but no more unrelated work than the objective requires.
Coherence becomes one of the primary criteria for identifying task boundaries.
Hierarchical Context Makes Larger Tasks Possible
This is where the concept of Hierarchical Context becomes especially important.
An agent should not need to discover an entire organization from scratch for every task.
It should inherit relevant context from progressively narrower layers:
Enterprise → Organization → Team → Service → Task
Enterprise context establishes global engineering principles, security requirements, and architectural expectations.
Organization context provides platform strategies, shared systems, and cross-team contracts.
Team and service context provide ownership, architecture, operational requirements, and implementation conventions.
Task context captures the specific intent, constraints, and acceptance criteria.
With this hierarchy in place, agents can access the information needed for execution without repeatedly rebuilding organizational knowledge.
More importantly, context can be selected according to the task.
A change affecting one service should not require loading every repository in the company.
A cross-service feature may require architectural contracts and dependency information from multiple services.
We should optimize not just task decomposition but also context composition.
A well-designed context infrastructure effectively increases the size of the task an AI system can execute reliably.
And this might be one of the most important benefits of ContextOps: expanding the amount of coherent engineering work that can be delegated safely.
Task Sizing Becomes a Model-Routing Problem
If different models have different effective context capabilities, then task definition and model selection should be connected.
Imagine a software factory with multiple AI execution systems.
A lightweight model might be highly effective at updating isolated tests or performing constrained transformations.
A more capable model might handle an entire feature involving several components and architectural decisions.
A specialized reasoning model might be appropriate for planning a complex migration, while other agents execute bounded portions of the plan.
We should not force every task into a universal ticket size and then assign a model.
Instead, the workflow could evaluate the intended outcome, required context, dependencies, risks, and available validation mechanisms before selecting an execution strategy.
In some cases, one capable agent handling the entire task may be most efficient.
In others, a planner coordinating multiple agents with smaller context scopes may be better.
And sometimes human involvement is necessary before execution can proceed safely.
The important shift is this:
Task decomposition is no longer exclusively a planning activity performed by humans. It becomes part of the AI execution system itself.
A software factory should be able to decide whether to execute a task directly, decompose it, or escalate it.
Validation Determines How Far We Can Stretch Scope
Context is only part of the equation.
Even if a model perfectly understands what needs to be done, we still need confidence that the resulting change is correct.
This is why validation capacity places another boundary on task size.
Consider two scenarios.
| Scenario 1 | Scenario 2 | |
|---|---|---|
| Change | A large refactoring | A smaller change |
| Tests | Comprehensive, with strong type checks | Limited |
| System clarity | Clear interfaces | Poorly documented |
| Validation | Automated integration validation | Unclear production behavior |
The larger task might actually be safer.
The difference is not simply scope. It is our ability to evaluate the outcome.
As validation improves, we can expand task scope without necessarily increasing uncertainty.
This suggests a powerful organizational relationship:
Better context increases what AI can understand. Better validation increases what AI can safely deliver.
Both are necessary for increasing autonomous execution.
And this creates another reason to invest in test infrastructure, executable specifications, observability, and reliable evaluation.
These are no longer just software quality investments.
They are infrastructure for increasing the productive capacity of the software factory.
What Should Actually Define a Task?
I would propose that an AI-native task is defined through a set of explicit properties.
1. Intent
What outcome should the system produce, and why does it matter?
The objective should describe the desired behavior or business result, not merely prescribe code modifications.
2. Scope and boundaries
Which parts of the system may change? What must remain unchanged?
This includes architectural restrictions, backward compatibility, security requirements, and acceptable trade-offs.
3. Required context
Which organizational, architectural, service-level, and task-specific knowledge must the execution system understand?
This should preferably reference durable, versioned context artifacts rather than duplicate extensive instructions.
4. Acceptance criteria
How do we know the task is complete?
Criteria should be observable and, where practical, executable through tests, evaluations, or measurable system behavior.
5. Authority
What decisions can the agent make independently?
Can it change interfaces? Introduce dependencies? Modify database schemas? Deploy to production?
A task can have a large scope while still placing strict limits on the actions an agent is authorized to perform.
6. Recovery and escalation
What happens when assumptions are invalid, validation fails, or the agent reaches a boundary of its competence?
The system should know when to retry, decompose, request clarification, or transfer control to a human.
The resulting task is more than a ticket.
It is an executable contract between human intent and the AI SDLC.
Dynamic Task Decomposition
One consequence of this approach is that task boundaries no longer need to remain fixed from planning through execution.
Imagine submitting a feature request to an AI-native development system.
The system first evaluates the work:
- What context is required?
- Which dependencies are involved?
- What models and tools are available?
- Can the outcome be validated?
- What is the expected recovery cost if execution fails?
It then selects an initial execution scope.
- What context is required?
- Which dependencies are involved?
- What models and tools are available?
- Can the outcome be validated?
- What is the recovery cost if it fails?
- One agent, whole featureThe coherent change runs as a single task.
- Contract first, then parallelDefine the interface, then split implementation.
- Human decision firstAn architectural choice is reviewed before execution.
When assumptions failRevise the plan and split the work into smaller units, instead of continuing blindly.
Perhaps the entire feature can be assigned to one agent.
Perhaps the interface contract should be defined first, followed by parallel implementation tasks.
Perhaps the task requires an architectural decision that must be reviewed by a human.
During execution, the system may discover that its assumptions were incorrect or that the available context is insufficient.
Instead of blindly continuing, it can revise the plan and split the work into smaller units.
The decomposition becomes adaptive.
That is a meaningful departure from the traditional model, where task structure is often largely predetermined in a planning meeting.
The important artifact is no longer the static list of subtasks.
It is the original intent, the execution strategy, the accumulated evidence, and the validated outcome.
Don’t Confuse Agent Autonomy with Unbounded Execution
There is a tempting conclusion that as AI systems become more capable, we should simply make every task larger.
I think that would be a mistake.
There are several reasons to preserve boundaries even when a model could theoretically handle more work.
Some decisions require independent human judgment.
Some changes must be reviewed separately for compliance or security.
Some work benefits from parallel execution.
Some actions are irreversible or have a large operational blast radius.
And some tasks involve uncertainty that cannot be resolved through additional context alone.
The right boundary is therefore determined by both the intelligence of the executor and the operating constraints of the organization.
Maximum effective scope is not maximum autonomy.
A model may understand an entire deployment and still be authorized only to prepare changes for review.
This distinction becomes critical as we build increasingly autonomous software factories.
The New Economics of Task Size
AI changes the economics of engineering decomposition.
Historically, a small task provided a convenient unit for assigning, estimating, and reviewing human work.
In an AI-native workflow, every additional task boundary can introduce orchestration costs, repeated context retrieval, validation work, and loss of continuity.
But excessively large tasks can also increase failures and expensive retries.
This suggests that task granularity should be optimized experimentally rather than established through universal rules.
We could measure:
- Validated value delivered per unit of execution cost.
- First-pass acceptance rate by task scope and model.
- Context preparation and repeated-context costs.
- Recovery effort after failures.
- Human interventions and review effort.
- End-to-end delivery time, including dependencies and handoffs.
Over time, a software factory could learn which task shapes work best for different types of changes, models, and repositories.
It might discover that API additions can reliably be handled end-to-end, while complex database migrations require smaller execution boundaries.
It might discover that better context infrastructure enables significantly larger changes without increasing failure rates.
The definition of an optimal task would become an empirical property of the system, continuously refined through feedback.
This links task design directly to the broader concept of the AI SDLC as a learning engineering system.
Maximum Effective Task Scope as a Measure of Software-Factory Maturity
There is a bigger implication here: the maximum effective scope of a task could become a leading indicator of an organization’s AI-native engineering maturity.
Imagine two engineering organizations using the same frontier model.
In one organization, the agent struggles to complete anything beyond a small, isolated code change. Repository conventions are implicit. Architectural documentation is stale. Tests are incomplete. Every task requires significant human intervention.
In the other, the agent can routinely deliver an end-to-end feature spanning services, contracts, migrations, tests, and documentation. The relevant context is discoverable, validation is trustworthy, and recovery paths are built into the workflow.
| Organization A | Organization B | |
|---|---|---|
| Model | Same frontier model | Same frontier model |
| Context | Implicit conventions, stale architecture docs | Relevant context is discoverable |
| Validation | Incomplete tests | Trustworthy validation |
| Human role | Significant intervention on every task | Recovery paths built into the workflow |
| Typical unit of work | A small, isolated code change | An end-to-end feature spanning services, contracts, migrations, tests, and docs |
The model is the same. The productive unit of work is not.
The difference is the surrounding software factory.
Its context infrastructure, architectural clarity, automated checks, tool access, execution orchestration, and ability to learn from failures all determine how much coherent intent can become validated software in one reliable execution cycle.
We can imagine an illustrative progression:
- Isolated changes. Agents reliably update a function, test, or localized component.
- Complete features. Agents handle coherent vertical slices across code, tests, and documentation.
- Cross-service initiatives. Agents coordinate contracts, dependencies, and multiple repositories while retaining verifiable outcomes.
- Larger product outcomes. The factory translates broader intent into dynamically decomposed, validated work, with humans governing the boundaries that matter.
These are not fixed maturity levels or a claim that all work should eventually run as one giant task. They illustrate how the feasible frontier can expand as the execution system improves.
Two Distinct Ways to Improve Velocity
This also exposes two different kinds of progress that are easy to confuse.
Execution acceleration: Make an existing task faster or cheaper. Better inference, caching, tool calls, and more efficient agents can all help.
Scope expansion: Increase the amount of coherent, valuable work that can be reliably represented and delivered within a task or coordinated execution cycle.
| Execution acceleration | Scope expansion | |
|---|---|---|
| What improves | An existing task gets faster or cheaper | More coherent work fits in one reliable execution cycle |
| Typical levers | Inference, caching, tool calls, efficient agents | Context infrastructure, validation, orchestration, recovery paths |
| Effect on process | Same handoffs, run faster | Handoffs, context reconstruction, and integration work can disappear |
Both matter, but scope expansion changes the structure of the development process itself. A factory that delivers ten small tasks twice as quickly has improved execution speed. A factory that safely replaces those ten handoffs with one coherent, validated outcome may have removed an entire layer of coordination, context reconstruction, and integration work.
In other words, the frontier of reliable task scope can be just as consequential as the speed of an individual agent.
Measure the Frontier, Not the Biggest Demo
The wrong metric would be the largest task an agent has ever completed once.
A more useful measure is the largest coherent task class consistently completed at a defined quality threshold, for a particular system and level of risk.
Organizations could track this frontier using a combination of:
- Task complexity and breadth: affected services, interfaces, behavioral requirements, and dependency depth.
- Reliability: first-pass acceptance and validation success over repeated attempts.
- Total economics: inference, preparation, orchestration, review, recovery, and elapsed delivery time.
- Safety: production incidents, regressions, rollback rates, and policy violations.
- Human effort: interventions and decisions required per validated outcome.
Task size by itself is a poor KPI; it can be gamed by combining unrelated work. And some complex changes should remain intentionally small because their risk is high.
The meaningful question is: For this class of engineering intent, how much can our factory reliably deliver without unnecessary handoffs?
That creates a practical improvement loop. Measure the frontier, identify what constrains it, invest in better context or validation, and test whether a larger coherent task becomes reliably executable.
The result is a more ambitious definition of engineering productivity: not merely more code or more tickets per day, but an expanding capacity to translate meaningful intent into safe, validated outcomes.
From Managing Tasks to Managing Intent
There is a deeper organizational implication.
If AI can dynamically determine effective execution boundaries, should humans remain responsible for defining every implementation task?
Perhaps not.
Human engineers, product managers, and engineering leaders can focus more on establishing objectives, constraints, priorities, and measures of success.
AI systems can translate that intent into an execution plan, choose appropriate models, decompose the work when necessary, and generate the artifacts required for review.
Humans still own judgment and accountability.
But they do not necessarily need to prescribe every step.
This is aligned with a broader transition in software development: moving from managing the execution of individual activities toward designing systems that reliably translate intent into outcomes.
The quality of the organization increasingly depends on how well that translation works.
A New Definition of a Task
I would define a task in an AI-native SDLC as follows:
A task is a coherent, outcome-oriented unit of engineering intent, bounded by the effective context, execution capabilities, validation mechanisms, authority, and recovery constraints of the system responsible for delivering it.
This definition has several important consequences.
Tasks do not need to have a universally standardized size.
The same intent may be executed as one task by one model or as several coordinated tasks by another system.
Improving context engineering can increase the scope of executable tasks.
Improving validation can increase the scope of safely executable tasks.
And task boundaries can change as models, tools, and organizational infrastructure evolve.
The task becomes a dynamic execution abstraction rather than a static planning artifact.
The Bigger Picture
We’ve spent years teaching engineers to break large problems into small, manageable pieces.
That discipline remains valuable. Decomposition is still fundamental to reasoning, modularity, and risk management.
But the unit of decomposition should reflect the capabilities of the system doing the work.
If an AI agent can reliably deliver an entire feature, breaking it into ten disconnected tickets may not improve engineering effectiveness.
It may simply introduce unnecessary coordination overhead.
At the same time, if a task exceeds the effective context or validation capacity of an agent, attempting it as one unit may destroy the very productivity we hope to gain.
The goal is not smaller tasks.
The goal is not larger tasks.
The goal is the largest coherent, reliably executable unit of work for the available system.
As AI-native software engineering matures, I expect the ability to discover and continuously optimize that unit to become an important capability of the software factory itself.
And the scope of work that factory can reliably deliver may become one of the clearest ways to see how far it has progressed.
Not because tasks are the ultimate thing we care about.
But because the way we define them determines how effectively human intent can become reliable software.