What Claude Code's Task System Reveals About the AI-Native Engineer

Last week, Claude Code quietly renamed Todo to Task. It looks like a minor terminology change, but it marks the beginning of an entirely different system.

Todo was a list that Claude maintained by itself - a single agent’s personal memory. Task is a unit of work shared across multiple agents. That distinction changes the paradigm of AI coding tools.

In other words, a new abstraction unit for AI swarms has arrived.

The Core Is Delegation, Not Automation

The old Claude Code was a single brain. Hand it a complex project and it would forget earlier steps midway through, forcing you to restart around the 60% mark over and over.

The new Task system has a fundamentally different architecture:

• You talk to a team leader. The leader doesn’t write code directly. It plans, delegates, and synthesizes.
• Once you approve the plan, specialist agents are spawned and work in parallel.

This is not automation - it’s delegation. The difference matters. Automation means scripting a known sequence. Delegation means defining outcomes and trusting a structured team to figure out the execution path.

Dependency Graphs Are the Real Weapon

The critical feature of the Task system is inter-task dependencies (blockedBy). Task 3 cannot start until Tasks 1 and 2 are complete.

Why does this matter?

Previously, Claude had to hold the entire plan in its head. As context grew longer, it naturally forgot pieces of the plan. The longer the session, the more drift accumulated.

Now the plan itself is externalized and structured. Even when context gets compressed or an agent is swapped out, the plan survives. The dependency graph acts as a persistent coordination layer that outlives any individual agent’s memory.

Parallel Processing Comes for Free

Assign seven to ten tasks and the system no longer processes them sequentially. Tasks without dependencies run concurrently. Fast searches go to Haiku, implementation goes to Sonnet, complex judgment calls go to Opus - model allocation happens automatically based on task characteristics.

This is a direct consequence of structured task design. The more cleanly you decompose work and define dependencies, the more parallelism the system extracts. You don’t optimize for parallelism explicitly - you get it as a byproduct of good task architecture.

The Job Becomes Orchestration

The Swarm documentation reveals clear patterns:

• Parallel Specialists: Multiple experts review simultaneously - security, performance, type-checking, all at once.
• Pipeline: Research flows into planning, planning into implementation, implementation into testing - sequential stages where each depends on the previous.
• Self-Organizing Swarm: Agents pull from a shared task pool, picking up whatever is unblocked and unassigned.

The work is no longer writing code. The work is designing which agents do what, in what order, with what dependencies between them.

Swarm Efficiency Hinges on Task Design

There are three levers for optimizing swarm performance:

• Task granularity: Smaller tasks increase the parallelization rate, but inter-agent communication overhead grows with each split.
• Role separation: Specialization improves quality, but creates potential bottlenecks at agents with disproportionate workloads.
• Dependency design: Structuring what must finish before the next thing can start without blocking - this is the topology of your workflow.

From my own experiments, the third lever has the most significant impact. Task granularity and role separation are relatively intuitive. Dependency design requires thinking about the shape of work itself - what I’ve come to call dependency topology design.

This is the real skill of the swarm era. It’s not about writing faster code or choosing better models. It’s about structuring the flow of work so that the maximum number of agents can operate without waiting.

From Writing Code to Designing How Work Gets Done

The progression is clear:

First, we wrote code. Then, we designed systems. Now, we design the way work itself is structured.

You’re not using AI tools. You’re directing an AI team. The person who understands that distinction first will dominate the next year of software development.

The shift from Todo to Task is small on the surface. Underneath, it’s the scaffolding for a world where the engineer’s primary output isn’t code - it’s the architecture of collaboration between machines.