Agent-Native Software Engineering - Li Shen

Li Shen

SubscribeSign in

Agent-Native Software Engineering

Li Shen<br>Jul 22, 2026

Share

The usual way to judge a coding agent is to ask how hard a bug it can fix, how large a repository it can hold, and how long it can run unattended. Those numbers are improving fast. But most failures I hit in daily use have little to do with code generation. The agent understands a function correctly and misreads the requirement. It passes every existing test and breaks a business rule that no test encodes. It executes a badly formed goal with great care.<br>The worst failures are not entirely on the agent’s side. I maintain several projects above 100K lines. Early on, coding agents made me much faster. I knew those systems well, I could state the requirement and the constraints, and the agent did the rest. As the codebase grew, my grip on it visibly weakened. There are modules whose internals I can no longer explain. I have to search the repo to find out whether a feature already exists. The architecture in my head got blurry. So when I describe a task to an agent, I now leave out considerations I should have stated. The agent implements what I said. Sometimes it rebuilds a capability that already exists somewhere else. The architecture decays and the rework piles up.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.

Subscribe

My most productive moment was not the moment the agent got strongest. It was the moment I still held the whole system in my head. What I lost is a model that lived only in my head and was never written down: which modules exist, why they look the way they do, what must not be touched. In conventional development, that model, plus team memory and repeated review, keeps custody of everything that never made it into a document. It is a safety net you only notice when it is gone.<br>Agents weaken both sides of this at once. They do not carry the model. Context is temporary, and when a session ends, the reason behind a change made hours ago goes with it. A constraint agreed verbally in a meeting is invisible to them. Agents also raise throughput, which pushes the codebase past the size any single person can hold, so the humans who did carry the model start to let go. Gaps that someone used to close now stay open on both sides, and they reach the architecture as decay and rework.<br>Here is the underlying problem. Our entire software engineering stack was built for humans, and agents lack the properties that stack assumes. Git, issues, pull requests, code review, and CI all assume a developer with long-term memory, an understanding of undocumented background, the instinct to stop and ask when something looks wrong, and accountability for the result. An agent copies instantly but loses its context at the end of a session. It works for hours but pursues a wrong goal consistently. It produces a lot of code and answers for none of it.<br>Classical software engineering optimizes collaboration among scarce humans who remember things and carry responsibility. Agent-native software engineering optimizes something else: reliable delegation to an executor that is cheap to copy, limited in context, probabilistic in behavior, and accountable for nothing. This post is about that delegation machinery. When agents become the actual implementers, tasks, context, verification, permissions, and responsibility all need to be reorganized.<br>This is not only my impression from daily use. Researchers have started to treat it as a distinct topic and to separate software engineering for humans from software engineering for agents [1][2], which reopens questions about actors, processes, tools, and artifacts. One line of work proposes redefining the basic unit of work from a code change to a supervised delegation [3]. Industry is filling in pieces from different angles: spec-driven development addresses how a task gets expressed, and AgentOps addresses what happens after deployment. This post puts those threads into one frame and adds what I have observed while using these tools.<br>Spec-driven development solves the first step

The early pattern with coding agents was to jump straight from prompt to code. You describe what you want. The agent interprets the requirement, decides the design, and edits files, all inside one conversation. For a small change this is fine. Fix a function, add a test, done.<br>The pattern breaks on larger tasks. Which judgment calls did the agent make? Why this design? What was explicitly out of bounds? Halfway through, the requirement turns out to be wrong — continue, or go back and revise the goal? All of that lives in a temporary conversation context. A human cannot inspect it before implementation, and a second agent cannot pick it up afterward.<br>Spec-driven development inserts steps between the prompt and the code: intent → spec → plan → tasks → code. On the surface it is more documents. In practice it changes how humans and agents...