Skip to content

Scaling is pre-launch.Book a call (opens in a new tab)

Scaling

Finished work, merged and confirmed in production.

Scaling does the plan and the review, follows the change until it is live in production, and merges on its own.

  • An issue from your issue tracker
  • An error from your error tracking
  • A set of issues from your issue tracker
  • leads to A change confirmed in production
Illustrative session

Let admins rename a workspace

Reading the request

acme/web · from a Linear issue

intent · 1 of 6

  1. Priya Raman in Linear

    ACME-158 Let admins rename a workspace Assigned by Priya Raman

An illustrative session, replayed. Not a customer's.

More decided work than people to finish it

Most product teams we know have decided on more than they have people to finish: the features on the roadmap, the fixes, and the check after a deploy that it actually works.

We think coding agents made the writing faster and left the finishing where it was.

  1. ACME-142Export invoices as CSV
  2. ACME-151TypeError: plan.steps is undefined
  3. ACME-158Let admins rename a workspace
  4. ACME-163Webhook retries double-charge on a timeout
  5. ACME-170Show the billing page in dark mode

Work in, production out.

01 / Intent

Scaling reads what the issue asks for. If it is too unclear to plan, Scaling asks on the issue instead of guessing.

Errors from error tracking go in too.

Illustrative session

Let admins rename a workspace

Reading the request

acme/web · from a Linear issue

intent · 1 of 6

  1. Priya Raman in Linear

    ACME-158 Let admins rename a workspace Assigned by Priya Raman

  2. The planner asked, you answered
    QuestionShould a rename change the workspace URL too? Changing it breaks bookmarked links.

    "Keep the URL. Only the display name changes." - in your words

  3. Intent packetClear

    An admin can rename a workspace, and its URL stays the same.

    1. An admin saves a new nameFails if: the old name still shows
    2. The workspace URL is unchangedFails if: /acme stops resolving

    Linear issue · started by Priya Raman · 5 Jan 2026, 09:00 UTC

Who does what

  1. Founder or CTO

    Sets the guardrails: which repositories Scaling works on, and any repository where it should not merge on its own.

    Guardrails

    Illustrative
    Self-merge
    • acme/webOn
    • acme/apiOn
    • acme/docsOn

  2. Product

    Puts work in where it already lives, as an issue in your issue tracker. When an issue is unclear, Scaling's question arrives on the issue.

    Request

    Illustrative

    ACME-158

    Let admins rename a workspace

    scaling

    1. Scalingasked

      Should a rename change the workspace URL too? Changing it breaks links people have bookmarked.

    2. Priya Ramananswered

      Keep the URL. Only the display name changes.

    We picked up the answer and are planning

  3. Engineers

    Own the stack, and review what Scaling has proven before it reaches them.

    Review verdict

    Illustrative
    acme/web #1288Draft

    Let admins rename a workspace

    Independent review: passed - checked on the running app against what was asked for

The jobs it does

  • Ship the roadmap

    Point Scaling at features and fixes in your issue tracker. Each one comes back as a reviewed pull request, or as a question or a reason it stopped, on the issue, and the issue closes once the change is live in production.

  • Keep production healthy

    An error from your error tracking goes in as work like any other.

  • Trust the output

    An independent reviewer checks every change from your issue tracker on the running app before its pull request opens, and it merges on its own only when your checks pass and the review is clean.

What it can reach, and what it can merge

  • Your code runs inside a sandbox designed to keep it there.

  • While Scaling works, the sandbox reaches only the hosts an admin on your team approved.

    Installing reaches npm, PyPI and Ubuntu's package mirrors, and only while installing.

  • Scaling merges through a pull request, never a push to your main branch.

  • Your model key and GitHub tokens never enter the sandbox.

  • The agent cannot push to your repository.

    Scaling only ever pushes its own branch, and the push happens outside the sandbox.

Questions

No. Scaling opens a pull request. It merges through that pull request, never by pushing to your main branch, and only when your checks pass and the review is clean. An admin can switch that off for any repository.

Talk to the founder

Bring the work your team has decided on and not finished. We will tell you plainly what Scaling can do with it today.