The Next Phase of Agentic Software Development

The way software gets built has already changed.

For a lot of work, the starting point is opening Codex, Claude Code, or another coding agent inside the repo and explaining the change.

The developer still needs taste, context, judgment, and review. But the daily loop has shifted. You describe the goal, the agent reads the codebase, edits files, runs commands, checks errors, and comes back with a patch.

This blog post is a small example.

I am trying to explain an idea inside a Next.js repo. The repo has an AGENTS.md file that defines the purpose of the blog, the writing style, and the editing rules. I explain the thesis, the agent edits the post, I correct the direction, and the artifact improves.

This is roughly how Codex and Claude Code work today. They sit inside a project, read the repo, use project notes, remember prior context, and help move the work forward. Over time, the agent gets better because the project develops more memory around it.

That is already a different way to make software.

General coding agents are the first step. They can enter almost any repo and help with almost any task. That makes them useful, but it also makes them broad. Their context usually accumulates around the project over time.

The next step is domain-specific agents.

A domain-specific agent starts from the job itself. A frontend implementation agent, a market research agent, or a support triage agent should be built with the goal, tools, memory, permissions, and evals that match the domain.

A serious software project will have agents shaped around the actual product.

A real frontend agent goes beyond editing React files.

It needs context on who the product is built for, what the interface is supposed to make easy, what the design system allows, how the component library is used, which flows matter most, what counts as a good user experience, and how frontend changes are reviewed, tested, deployed, and measured.

A real backend agent goes beyond writing API handlers.

It needs context on the product's data contracts, auth model, failure modes, deployment practices, observability, rollback paths, customer risk, and the business-specific evals that define whether a change is actually correct.

A market intelligence agent needs the same specificity. It should understand market structure, pricing logic, liquidity, adverse selection, risk limits, and what the product is trying to help the user see.

A growth or writing agent needs the same kind of domain context. It should know the audience, tone, proof artifacts, distribution channels, legal or reputational risks, and what kind of claim the company can defend.

The pattern is the same across domains: useful agents need the context that a good teammate would slowly accumulate.

They need to know how the product works, who it serves, how changes ship, what can break, what quality means, and how success is evaluated.

These agents are software artifacts.

They are made from instructions, tools, memory, permissions, evals, approval gates, logs, runtime choices, and repo conventions.

This is where frameworks like Vercel Eve and Flue become interesting.

Eve treats an agent as a project made from files: instructions, tools, skills, runtime config, channels, connections, schedules, and sandbox configuration. The agent becomes something you can author, version, deploy, and inspect.

Flue points at the same idea through a TypeScript harness. It gives the agent sessions, tools, skills, instructions, filesystem access, and sandboxing. Cloudflare's writeup on Flue frames this as the context an agent needs: model, skills, sandbox, and instructions.

The direction is away from one-off prompts and toward agents that are authored, versioned, and shaped around a product domain.

That changes how teams build.

If I am building a complex product, I should start asking what domain-specific agents belong inside the system. Which agent understands the frontend? Which agent owns QA? Which agent watches user feedback? Which agent turns product decisions into implementation tasks? Which agent maintains docs? Which agent knows the market?

The repo becomes more than source code. It becomes a place where the product, the team, and the agents share context.

Faster code generation is only part of the shift. Developers will also design the agents that help build and operate the software.

That requires a different kind of judgment: knowing what context an agent needs, what tools it should have, what it should never be allowed to do, and where human review stays in the loop.

Prompting is only one small part of this. The real work is agent design: defining scope, context, tools, permissions, review points, logs, and evals.

Good agents will feel boring in the same way good internal tools feel boring. They do a clear job, operate inside narrow boundaries, and make their work inspectable.

That feels like the next layer of software development.