Worker vs Pro

Worker and Pro can both inspect repositories, plan changes, write code, use tools, and complete software development tasks.

The practical difference is how much uncertainty the task contains.

Use Worker when the intended change is reasonably clear and the repository provides reliable patterns.

Use Pro when significant investigation, architectural reasoning, or uncertainty resolution must happen before the correct change becomes clear.

Quick Decision

Situation	Recommended Model
Normal feature development	Worker
Conventional MVC application	Worker
Clear bug with identifiable behaviour	Worker
Existing pattern to follow	Worker
Multi-file implementation	Worker
Third-party integration with clear documentation	Worker
Tests and routine refactoring	Worker
Difficult intermittent bug	Pro
Unknown root cause	Pro
Major architecture decision	Pro
Poorly understood legacy system	Pro
Cross-service redesign	Pro
Race condition or concurrency investigation	Pro
Major migration with compatibility risks	Pro
Ambiguous high-impact requirement	Pro

The Main Question to Ask

Do not ask:

How many files will this task change?

Ask:

How difficult is it to determine what the correct change should be?

A large task can still be a Worker task. A small task can still be a Pro task.

Large Task, Use Worker

Suppose you have a Laravel application with established patterns for controllers, services, policies, migrations, Livewire components, and tests.

You want to add project archiving. The change requires:

• A migration
• Model changes
• New authorization logic
• Several UI changes
• API updates
• Tests
• A scheduled cleanup job

This may affect many files, but it is still a good Worker task because the requirement is clear and the repository provides familiar patterns.

Small Task, Use Pro

Suppose a distributed lock occasionally remains active after a failed job.

The relevant code may exist in only three small classes, but the cause could involve:

• Lock expiration
• Worker termination
• Retry behaviour
• Transaction ordering
• Network failure

The amount of code is small. The uncertainty is not.

That makes it a good Pro task.

What Usually Favors Worker

Worker is the better choice when the task mainly involves implementation inside an understandable system.

Typical signals include:

• The required behaviour is clear
• The repository follows recognizable conventions
• Similar implementations already exist
• The framework is well established
• Normal repository investigation is sufficient
• The task mainly involves extending existing patterns

Applications built with frameworks such as Laravel, Rails, Django, Spring, and ASP.NET MVC often fit this category because they provide strong structural conventions.

This makes ordinary feature development, maintenance, integrations, and refactoring especially suitable for Worker.

Read Worker Model for more detail.

What Usually Favors Pro

Pro becomes more useful when understanding the problem is harder than implementing the eventual fix.

Typical signals include:

• The root cause is unknown
• The bug is intermittent
• Several systems interact in unclear ways
• Requirements contain unresolved architectural decisions
• The repository is difficult to interpret
• Failure scenarios are subtle
• The change has significant compatibility or architectural risks

Custom and legacy systems often fall into this category, especially when they contain:

• Undocumented internal frameworks
• Heavily modified framework behaviour
• Multiple architectural styles
• Unclear ownership of business logic
• Few tests
• Implicit side effects

Read Pro Model for more detail.

What Does Not Automatically Mean Pro

Several characteristics can make a task look difficult without actually requiring Pro.

Planning

Both models can plan.

Do not choose Pro simply because you want an implementation plan.

For example:

Inspect the existing notification system, create a plan for adding SMS notifications, then implement it.

This is still a reasonable Worker task if the notification architecture is clear.

Use Pro when creating the plan itself requires substantial architectural reasoning.

Multi-File Changes

Both models can modify many files.

A task that touches controllers, models, migrations, frontend components, jobs, and tests can still be a Worker task.

File count is not a reliable measure of reasoning difficulty.

Business Importance

A task can be commercially important without being difficult to reason about.

Adding a new payment provider may be important, but if your application already has a stable payment interface and several existing implementations, Worker may still be the right model.

By contrast, investigating rare duplicate charges may justify Pro because the root cause is uncertain.

Choose based on the engineering problem, not business importance alone.

Using Both Models

You can combine both models when only part of a project requires deeper reasoning.

A common workflow is:

1. Use Pro to investigate an unfamiliar or ambiguous subsystem.
2. Ask Pro to produce a staged implementation plan.
3. Give conventional implementation stages to Worker.
4. Use Pro again for architectural review if necessary.

This can reduce unnecessary Pro usage while still applying deeper reasoning where it matters.

For normal development, this split is usually unnecessary.

Cost and Capability

Worker is intended to handle the majority of software development work efficiently.

Pro uses substantially more model capacity and is best reserved for tasks where deeper reasoning has a meaningful chance of improving the outcome.

A practical rule is:

Start with Worker when the path is clear.

Use Pro when the path itself needs to be discovered.

Simple Routing Guide

Use Worker when:

• You know what behaviour you want
• The repository follows recognizable conventions
• Similar implementations already exist
• The task mainly involves implementation
• Normal investigation is sufficient

Use Pro when:

• The root cause is unknown
• Requirements need architectural interpretation
• Several systems interact in unclear ways
• The codebase is difficult to understand
• Failure scenarios are subtle
• The change carries major architectural consequences

The shortest version is:

Known problem, understandable system → Worker

Unknown problem, uncertain system → Pro

Read Next

For day-to-day development, see Worker Model.

For deep investigation, architecture, and complex reasoning, see Pro Model.