Worker

Worker is MaxLabs' general-purpose software engineering model. It is designed for the development work engineers perform every day: understanding an existing repository, planning changes, modifying code, running tools, testing the result, and correcting problems it finds.

Worker does not require a detailed implementation plan before it can begin. You can give it a development objective and let it investigate the repository before deciding how to approach the task.

For most well-maintained applications, Worker should be your default model.

If you only want help choosing between the two models, see Worker vs Pro.

What Worker Can Do

Worker can handle complete development tasks rather than isolated code generation.

A typical task may involve:

1. Inspecting the repository
2. Locating relevant code
3. Understanding existing patterns
4. Determining what needs to change
5. Creating an implementation plan
6. Modifying multiple files
7. Running tests or validation tools
8. Correcting issues
9. Verifying the final implementation

For example:

Add support for expiring API keys. Users should be able to choose an expiry date, expired keys must stop authenticating immediately, and the API key management page should show the expiry status.

Worker can investigate how API keys are currently stored, authenticated, and displayed before changing anything. You do not need to identify every controller, model, migration, component, or test that it should modify.

Worker Can Plan Its Own Work

For ordinary repository work, describe the outcome you want rather than providing a complete implementation plan.

For example:

Add soft deletion to projects. Deleted projects should disappear from normal queries but remain visible to administrators for 30 days before permanent deletion.

Worker can inspect the project model, queries, administrator screens, background jobs, and tests before deciding how to implement the change.

For larger tasks, you can also ask Worker to show its plan before coding:

Inspect the existing implementation first. Produce a short plan, then implement it.

Planning alone is not a reason to use Pro. Worker can plan normal feature development and maintenance work itself.

Where Worker Performs Best

Worker performs especially well on applications built with established, opinionated frameworks such as:

• Laravel
• Django
• Ruby on Rails
• ASP.NET MVC
• Spring

These frameworks establish conventions around routing, controllers, models, migrations, validation, middleware, authorization, background jobs, configuration, and testing.

Worker already understands these common framework concepts. Its main job is to determine how your repository uses them.

For example, when Worker enters a Laravel repository, it does not need to learn what migrations, middleware, Eloquent models, queues, policies, or service providers are. It can focus on understanding your application's architecture and conventions.

Framework Knowledge + Repository Knowledge

Worker is most effective when it can combine its existing framework knowledge with patterns discovered in your repository.

Your application might:

• Keep business logic in service classes
• Use policies consistently for authorization
• Share validation rules
• Wrap third-party integrations behind interfaces
• Follow a particular testing structure
• Use specific naming conventions

Worker can inspect these patterns and continue using them.

This also means that repository size alone does not determine task difficulty. A consistent 2,000-file Laravel application may be easier for Worker to modify than a 100-file application built around undocumented custom architecture.

Existing Patterns Improve Results

Existing implementations provide Worker with strong guidance.

Suppose your application already supports Stripe, Razorpay, and PayPal through the same payment interface. If you ask Worker to add another provider, it can inspect those integrations, understand the existing contract, and implement the new provider using the same architecture.

The same principle applies to:

• CRUD modules
• API endpoints
• Admin pages
• Background jobs
• Event handlers
• Reports
• Notification channels
• Storage providers

The more consistent your repository is, the easier it becomes for Worker to make reliable changes.

Good Worker Workloads

Worker is not limited to small changes. A task can involve several controllers, models, migrations, frontend components, API endpoints, tests, background jobs, and configuration files.

What matters more is whether the requirement is clear and the architecture provides understandable patterns.

Feature Development

Worker is a good fit for features such as:

• Account settings
• Notifications
• API keys
• Role management
• Search and filtering
• Dashboards and reporting
• User preferences
• Billing options
• Administrative tools

For example:

Add organization invitations. Administrators should be able to invite users by email, assign a role, and revoke pending invitations.

This feature may touch many files. If the application already has organizations, users, authorization policies, mail, and a consistent service layer, Worker has reliable patterns to follow.

Integrations

Worker is also well suited for integrating:

• Payment gateways
• Email providers
• Cloud APIs
• Storage services
• Analytics systems
• Authentication providers
• Webhook consumers

Maintenance and Bug Fixes

Worker can handle routine engineering work such as:

• Fixing ordinary bugs
• Updating dependencies
• Improving validation
• Adding tests
• Resolving type errors
• Removing duplicated logic
• Modifying database schemas
• Refactoring existing modules

How to Get Better Results

Describe the desired behaviour and important constraints rather than prescribing implementation details that may conflict with the repository.

Instead of:

Create a middleware named CheckSuspendedUser, add it to every route, and add a boolean called is_suspended.

Prefer:

Add account suspension. Suspended customers should not be able to create or modify resources. Administrators must still be able to manage suspended accounts. Follow the existing authorization patterns in the repository.

The second request allows Worker to inspect the application and determine the implementation that best fits its existing architecture.

A good task description usually includes:

• The desired behaviour
• Important restrictions
• Expected user-visible outcome
• Compatibility requirements
• Areas that must not change

The repository can provide most of the implementation details.

Give Worker Validation Tools

Automated validation makes Worker considerably more effective.

Useful validation includes:

• Unit tests
• Feature tests
• Static analysis
• Type checking
• Linting
• Build commands
• Integration tests

Worker can implement a change, run the available validation tools, inspect failures, revise its implementation, and verify the result.

A repository without tests does not prevent Worker from working, but it gives the model less objective feedback when verifying its changes.

When to Use Pro Instead

Worker becomes less predictable as architectural ambiguity increases.

Consider Pro when the repository has characteristics such as:

• Framework conventions are routinely ignored
• Business logic is duplicated across unrelated files
• Important behaviour is undocumented
• Hidden side effects are common
• Multiple architectures coexist
• Tests are largely absent
• Application behaviour depends on obscure infrastructure
• Custom abstractions replace familiar framework components

Worker may still be able to work with these repositories. However, when understanding the system becomes the primary engineering challenge, Pro is generally the better choice.

The same applies when the difficult part of the task is deciding what the correct solution should be rather than implementing a reasonably clear requirement.

Choosing Worker

Worker should be your default when the requirement is reasonably clear and the repository provides reliable patterns to follow.

This covers most day-to-day development inside well-maintained applications, particularly projects built with established frameworks and consistent conventions.

A useful rule is:

Clear requirement + understandable architecture = Worker

When deep architectural analysis, ambiguity, or complex engineering decisions dominate the task, use Pro.

For a direct comparison, see Worker vs Pro.