"We are moving from writing code to training neural nets to orchestrating agents. Software 3.0 is the Agent Ecosystem."
Three eras of building software
Software development has moved through three distinct modes of work. In the first, people wrote explicit instructions: source code that defined every branch, state transition, and edge case. In the second, people trained neural nets: they collected data, chose objectives, and shaped behavior through optimization rather than hand-written rules. Software 3.0, as framed by Andrej Karpathy, is the shift to orchestrating agents—systems that plan, use tools, call models, and complete multi-step work with less step-by-step human coding.
These eras do not fully replace one another. You still write glue code, still train or fine-tune models when you need specialized behavior, and now you also design how agents coordinate. The unit of progress changes: less “ship this function,” more “define goals, constraints, tools, and recovery paths so an agent can finish the job.”
What an agent ecosystem actually is
An agent is more than a single model call. It is a loop: observe context, decide a next action, use a tool or another model, check the result, and continue until the goal is met or a stop condition is hit. An ecosystem is what appears when many such loops share memory, permissions, APIs, and human oversight. The hard problems move from “does this model answer well?” to “can agents find the right tools, hand off cleanly, and fail safely?”
In practice, that means treating prompts, policies, tool schemas, and evaluation harnesses as first-class product surface—not as afterthoughts bolted onto a chat box. Reliability comes from clear interfaces between agents and the systems they touch, not from hoping a single large model invents the whole workflow every time.
How to design for orchestration
Build around goals and boundaries, not only around model quality. Specify what success looks like, which tools are allowed, what data can leave which boundary, and what the agent must ask a human before doing. Prefer small, composable tools with predictable inputs and outputs over one mega-tool that tries to do everything. Log decisions and intermediate state so you can debug failed runs the way you debug distributed systems.
- Define a narrow goal and explicit stop conditions for each agent run.
- Expose tools as stable contracts (inputs, side effects, error shapes).
- Add checkpoints where a human must approve irreversible actions.
- Evaluate end-to-end task completion, not only single-turn fluency.
When something goes wrong, ask whether the failure was planning, tool design, missing context, or weak verification. Often the fix is a better workflow or a tighter tool, not a larger model.
What teams should change in day-to-day work
Teams that only hire for “write more code” or “train better nets” will underinvest in the skills Software 3.0 rewards: product sense for agent goals, careful API and permission design, evaluation that measures real task success, and ops that can observe multi-step runs. Version your prompts, policies, and tool definitions the same way you version services. Keep humans in the loop where stakes are high, and automate where the cost of error is low and recovery is easy.
The move from writing code to training nets to orchestrating agents is a change in where effort pays off. You still need solid engineering underneath. The new leverage is designing systems of agents that can pursue goals with tools, memory, and guardrails—and improving that ecosystem as deliberately as you once improved codebases and model training pipelines.