Pro

Pro is MaxLabs' model for difficult software engineering problems.

It is designed for work where the main challenge is reasoning, investigation, and technical judgment rather than ordinary implementation.

Pro is most useful when the repository does not provide an obvious answer. This may happen because:

• The architecture is unclear
• The failure is intermittent
• Several systems interact
• Requirements contain unresolved decisions
• The consequences of a wrong implementation are significant

For routine development, Worker is usually the better starting point.

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

What Pro Is For

Pro is designed for situations where the model must spend substantial effort determining what is actually happening before it can decide what to change.

Typical questions include:

• Why does this fail only occasionally?
• Where does this state actually come from?
• Which service owns this behaviour?
• What hidden dependency could cause this?
• Which architecture should we choose?
• What will break if we change this subsystem?
• Which parts of this legacy behaviour are intentional?
• How should several systems interact safely?

These are not primarily coding questions. They are engineering questions.

A useful rule is:

Use Pro when the model must discover the solution before it can implement the solution.

Where Pro Performs Best

Pro is most valuable when understanding the system is harder than writing the eventual fix.

Root-Cause Analysis

Consider this issue:

A request fails when customer_id is null.

The cause is relatively narrow. Worker is usually a good fit.

Now consider:

Some customers are charged twice. It only happens occasionally. We process payments through webhooks and background queues, but our logs do not show an obvious duplicate request.

This may require investigation across:

• Payment provider events
• Webhook delivery
• Queue retries
• Transaction boundaries
• Idempotency
• Database locking
• Timeout behaviour
• Worker restarts
• Event ordering

The eventual fix might only require a few lines of code. Finding the correct lines may require substantially more reasoning.

That is the kind of problem Pro is designed for.

Another example:

After certain deployments, some queue workers continue using the previous configuration. Restarting the workers fixes it, but it does not happen on every deployment.

A proper investigation may involve:

• Deployment scripts
• Process supervisors
• Container lifecycle
• Configuration caching
• Queue worker behaviour
• Signals
• Restart policies
• Service discovery
• Application bootstrapping

A shallow fix may hide the symptom without correcting the underlying cause. Pro is better suited to tracing the full chain before deciding what should change.

Deep Repository Investigation

Pro is useful when you need to understand a large, unfamiliar, or inconsistent system before modifying it.

A repository may contain:

• Several generations of architecture
• Duplicated implementations
• Unusual abstractions
• Undocumented internal libraries
• Custom framework behaviour
• Hidden dependencies
• Abandoned migration paths
• Inconsistent naming
• Limited test coverage

In these environments, the model cannot rely heavily on framework convention. It has to reconstruct how the system actually behaves.

Pro can spend more reasoning capacity tracing behaviour across the repository and determining which parts matter to the task.

Legacy Systems

Legacy applications often contain behaviour that exists for reasons no longer documented.

A function that looks unnecessary may support an old integration. A strange database field may exist because of a previous migration. Two apparently duplicate code paths may behave differently under an edge case.

Pro is useful when the task requires distinguishing accidental complexity from behaviour that must remain compatible.

For this kind of work, you can explicitly ask Pro to investigate before making changes:

Do not modify anything initially. Trace how invoices are generated, identify every path capable of creating one, and explain where duplication could occur. Then propose the safest fix.

Architecture and Design Work

Pro is also useful before significant systems are built.

Consider:

Design usage-based billing for our cloud platform. Resources can be billed hourly or monthly. Customers use prepaid balances. We need automatic suspension, usage reconciliation, and support for several infrastructure providers.

This request contains several architectural decisions.

The model may need to reason about:

• Usage collection
• Metering intervals
• Authoritative records
• Balance reservation
• Reconciliation
• Provider outages
• Retries
• Double charging
• Delayed usage
• Suspension behaviour
• Audit logs
• Invoice generation
• Rounding
• Concurrency

There is no single framework convention that answers these questions. The architecture itself must be reasoned through.

Ambiguous Requirements

Sometimes the repository is straightforward, but the product requirement is not.

For example:

Add organizations with teams, custom roles, and permissions.

Before implementation, several questions remain:

• Can users belong to multiple organizations?
• Can a user hold different roles in different organizations?
• Can organizations create custom roles?
• Can team permissions override organization permissions?
• Who owns resources?
• How are invitations handled?
• What happens when a user's last organization is removed?
• How does billing relate to organizations?

If these decisions remain unresolved, the resulting implementation may be difficult to change later.

Pro can help explore the requirement, identify hidden decisions, and establish a coherent design before coding begins.

High-Impact Systems

Some tasks justify deeper reasoning because subtle mistakes can have significant consequences.

Examples include:

• Billing engines
• Authorization systems
• Authentication
• Infrastructure orchestration
• Tenant isolation
• Financial workflows
• Data migrations
• Deployment systems
• Distributed jobs
• Resource provisioning

The code itself may be conventional. The consequences of getting it wrong are not.

Pro is a good choice when you want more extensive analysis before making these changes.

Major Refactors and Migrations

Large refactors require reasoning about both the new implementation and the behaviour that must remain unchanged.

Examples include:

• Replacing an authentication subsystem
• Moving from one ORM to another
• Splitting a monolith
• Replacing queue infrastructure
• Redesigning a domain model
• Moving from synchronous processing to events
• Consolidating duplicated services
• Extracting a shared platform component

The primary risk is often not implementing the new system. It is breaking assumptions that other parts of the application depend on.

Pro can inspect dependencies, identify behavioural contracts, evaluate migration risks, and help plan an incremental transition.

Using Pro for Planning and Review

Pro does not have to perform the final implementation itself.

Planning Difficult Work

For a complex project, you can ask Pro to:

• Inspect the repository
• Identify architectural constraints
• Evaluate possible approaches
• Identify migration risks
• Produce implementation stages
• Define validation criteria

You can then let Pro implement the plan or hand the resulting implementation work to Worker.

This is particularly useful when the reasoning phase is difficult but the eventual changes are conventional.

Reviewing Important Changes

Pro can also review significant changes produced by Worker or by developers.

For example:

Review this implementation for architectural problems, race conditions, authorization gaps, and behaviour that could fail under retries. Do not focus on formatting or minor style issues.

This allows Pro to spend its additional reasoning capacity on the areas where it matters most.

How to Get Better Results from Pro

For difficult investigations, avoid telling Pro what the conclusion is before it has examined the repository.

Instead of:

The queue is definitely causing duplicate invoices. Fix the retry handling.

Prefer:

Customers occasionally receive duplicate invoices. Investigate all possible creation paths and determine the actual cause before implementing a fix.

The second prompt allows Pro to challenge your assumptions.

You can also explicitly specify the expected investigation depth:

Trace the complete request lifecycle before proposing changes.

Or:

Identify the most plausible competing explanations and use the repository to eliminate them before implementing a fix.

Pro works best when investigation is encouraged rather than prematurely constrained.

When to Use Worker Instead

Pro is not necessary merely because a task spans many files.

You usually do not need Pro for:

• Ordinary CRUD functionality
• Adding another conventional endpoint
• Adding a migration
• Creating a normal form
• Following an existing integration interface
• Routine bug fixes
• Standard MVC development
• Updating tests
• Straightforward refactoring

Worker can handle these tasks effectively.

Using Pro for every task adds unnecessary compute when the repository already makes the correct implementation reasonably clear.

Choosing Pro

Use Pro when reasoning, investigation, or architectural judgment is the difficult part of the task.

A useful distinction is:

Clear solution + conventional implementation = Worker

Unclear solution + significant investigation = Pro

If the repository already makes the intended implementation relatively obvious, use Worker.

If the model must first determine what the correct solution is, use Pro.

For a direct comparison, see Worker vs Pro.