APPARITION
Agents become viable engineering actors: they interpret intent, explore repositories, use tools, modify software, execute commands and iterate.
A working model by Orlando Garcia
August 2026
A model for reasoning about how software engineering may evolve from individual coding agents toward systems of specialized, cooperating engineering capabilities — and the DevEx conditions required for that evolution to scale.
Agents become viable engineering actors: they interpret intent, explore repositories, use tools, modify software, execute commands and iterate.
Agent configurations proliferate: models, tools, context strategies, permissions, subagents, swarms and orchestration patterns.
Engineering environments determine what can scale. Fit configurations produce useful outcomes without proportional growth in cost, risk or human attention.
Fit agents compose into complex workflows: work is divided, state is exchanged, capabilities combine and coordination becomes an engineering problem.
Repeated cooperation produces stable, differentiated capabilities with distinct context, tools, authority, interfaces and evaluation criteria.
The useful question is not which agent mutation will win, but which engineering conditions allow useful configurations to succeed and scale.
Candidate DevEx conditions. Context, Execution and Verification are one current area of exploration, not an organizational roadmap.
1K agents is not a utilization target. It is a stress test for DevEx design. Small inefficiencies become systemic when multiplied across an agent population.
A practical starting point is the minimum engineering loop: acquire → execute → verify.
The 1K constraint asks whether each capability remains viable as agent populations grow. Which conditions matter most — and in what sequence — should follow evidence rather than a roadmap assumed in advance.
When sufficiently fit agents can cooperate repeatedly, stable, differentiated engineering capabilities can emerge.
Specialization may live in roles, context, tools, authority, memory, interfaces and evaluation criteria — not necessarily in different models. The engineer increasingly composes capabilities rather than treating every agent as interchangeable.
Possibly — this is a hypothesis to test, not a conclusion.
Agent architectures are still mutating rapidly. But as organizations increase agent concurrency, recurring constraints become more consequential: context, execution, verification, coordination, observability, economics and learning.
The hypothesis is that these constraints increasingly influence which agentic engineering approaches can scale. 1K-agent scale is a forcing function for testing that idea.
Public evidence does not establish the evolutionary sequence — or that any company can operate 1,000 coding agents concurrently. But independent engineering organizations are encountering similar problems that this model groups under Selection: context, isolated execution, verification, coordination, observability and durable operation.
Honk runs many concurrent sessions in Kubernetes, verifies changes in CI, integrates with fleet orchestration, and is evolving toward shared sessions and agent orchestration. Spotify reports 99%+ weekly AI-tool adoption and fleet-wide migrations completed by a single engineer in days.
OpenAI found that engineers could comfortably manage only 3–5 simultaneous Codex sessions before context switching reduced productivity. Symphony moves coordination into an always-on orchestrator where open tasks receive agents in isolated workspaces; OpenAI reports a 500% increase in landed PRs on some teams.
Cursor is moving from single-agent interaction toward fleets of async subagents, parallel plans and isolated worktrees. Its own framing describes a future where fleets of agents work autonomously to ship improvements.
Google's Agent Executor was created because long-running agent workflows exposed reliability and efficiency problems. Durable execution, event logs, snapshots and resumption become runtime infrastructure rather than agent-level concerns.
Use 1K agents as a forcing function for your engineering decisions. Pick the condition closest to your work and ask what breaks when usage increases by orders of magnitude.
Find what breaks. Engineer the condition.
Then turn the constraint you find into an engineering expectation.
The purpose of the model is to generate useful engineering questions. It should change when evidence contradicts it.
This model was developed using Daniel San Martín's Clarity model as a thinking lens, particularly its progression through Apparition, Mutation, Selection, Cooperation and Specialization.
The application of those ideas to agentic software engineering—including the interpretations and hypotheses presented here—is my own.