Essay · The evolution of engineering6 eras · read time 3 min

From one core
to a thousand agents.
And why it stays manageable.

Each era of software engineering raised how much work one engineer can keep in flight. This is where that curve has been, where it goes next, and what it takes to keep a thousand parallel sessions safe, reviewed and paid for.

01 · Six erasparallel work per engineer
eraE1typing alone×1

One engineer, one core.

A person, an editor and a compiler. Every line typed by hand, every test run by hand. The limit is how fast one person can think and type.

  • one thread
  • all context in one head
Fig. E1One person, one editor, one thread of work
eraE2autocomplete×1

The machine finishes the line.

Completion models guess the next few tokens. It is faster typing, not more work in flight: the person still plans, edits, runs and checks everything.

  • faster typing
  • same single thread
Fig. E2Suggestions inside the editor
eraE3chat×1

Answers arrive in a side window.

A model can explain, draft and debug, but it cannot see the repository or run anything. Work moves by copy and paste, and the person carries the context between windows.

  • no tools
  • context by hand
Fig. E3Editor and chat, joined by copy and paste
eraE4one agent×1

The agent edits and runs.

An agent can plan, change files, run the tests and read the output in a loop. It is still one session on one laptop, and the person approves every step and waits.

  • real tools
  • one at a time
  • your laptop
Fig. E4One agent loop, supervised step by step
eraE5many prompts×10+

A dozen prompts on one laptop.

Strong engineers now run ten or more agent sessions side by side. The laptop and the person become the bottleneck: no isolation between sessions, no shared knowledge, no review, and every “waiting for you” is a context switch.

  • no isolation
  • no review
  • no budget
  • no audit
Fig. E5Parallel sessions, one machine, one attention span
eraE6Frazer×1,000+

A thousand sessions, and you stay in charge.

Log in to the Frazer app or VS Code and run work the way a company does: many workspaces, standing agents, campaigns across hundreds of repositories, fleets of devboxes, coordinators that spawn sub-agents. Frazer is designed for 1,000+ concurrent sessions per organization, each in its own sandbox with its own budget.

  • workspaces
  • campaigns
  • standing agents
  • fleets of devboxes
  • sub-agents
Fig. E6Person → surfaces → workspaces → agents → sessions; one coordinator tree
02 · Why it stays manageableFig. G

More sessions need better gates,
not more people watching.

Scale is only useful if the work that reaches you is verified. Every session passes the same gates, and only what survives them lands in your systems.

Fig. GFive gates between a thousand sessions and your infrastructure
  1. Devboxes and sandboxes

    Every session runs in its own VM or box with default-deny egress. Credentials are injected by proxies and expire within the hour.

  2. LLM gateway

    One door to every model: keys per session, guardrails for secrets and injection, logs without content, a zero-retention mode.

  3. Frazer Reviewer

    Evidence or silence. A comment needs a reproduced test, a trace or an approved rule; suspicions stay quiet.

  4. Verifier

    Before a merge, a model from another family checks the exact commit. The builder never verifies itself.

  5. Approvals

    Production, destructive and large changes wait for a person, with a passkey. An agent never approves anything.

  6. Budgets

    Caps per session, agent, campaign and project. Hitting one pauses work and tells someone; nothing is deleted.

  7. Security Center

    Agents are principals like people: what they can reach, what they did, and a kill switch for the organization.

  8. Quotas that queue

    Concurrency is a quota per project and organization; a 200-repository campaign waits its turn instead of failing.

  9. Audit

    Every write by a person, an agent or Frazer itself is a plan with an audit entry: who, on whose behalf, and why.

03 · It all lands in your infrastructure

Nothing disappears into a black box.

Agents work in your repositories, deploy through your Git and Frazer GitOps, write to your databases through plans, and leave their record in your audit log. If you stop using an agent, everything it built is still yours and still runs.

Code
Pull requests in your repositories, from the Frazer bot, on behalf of a person
Deploys
Your environment repository and Frazer GitOps; production waits for approval
Data
Your databases and buckets, on your servers or in your cloud accounts
Knowledge
Accepted proposals only; nothing an agent writes is trusted until a person accepts it
Record
Sessions, costs and verdicts in your organization, exportable
04 · What we believe

We don’t limit what you build.
We give you every tool to succeed.

We think a small team with compute and a model can build a very large company. That is a bet, not a measurement. Our job is to make the attempt safe: real machines, real knowledge, and gates that keep a thousand sessions honest.

Start with one session.
Grow to a thousand.