Architect of Intent: software engineering isn't ending, the typing is

In late August and September, the same post went around in different words: Chinese researchers have published a paper titled “The End of Software Engineering”, and writing code is finished as a skill. One post called it a “brutal title”, another a “devastating” one. The paper itself says the person who used to write the code becomes an “intent architect” who directs agents and audits what comes back.

I’ve been doing a version of that job on my own projects, so I read the paper instead of the posts. The posts got the headline wrong and the job title roughly right. The most useful thing in the paper is one number from someone else’s benchmark, and it says more about what an intent architect does all day than the title does.

This is what the paper says, what that number means, and what the role looks like in a real repository: the rules files, the refusals, the hashes, and the one decision on a recent tool that no agent was going to make for me.

One author, two titles, and a softer conclusion than the posts

The paper is arXiv 2606.05608, by Zhenfeng Cao. The affiliation on the paper is Lingxi Intelligent Investment (Shenzhen) Development Co., Ltd. That’s one author at a company, not a research group at a university. It’s an arXiv preprint, and the listing names no journal or conference, so I’m treating it as unreviewed work.

The submission history is the interesting part. Version 1, posted June 4, was titled “The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm”, and its conclusion said “the old software engineering is ending; the new one has already begun.” Version 2, posted June 10, is titled “Agentic Software: How AI Agents Are Restructuring the Software Paradigm”, and its conclusion now reads: “The old software engineering is not ending; it is growing into something larger.”

The core argument survives both versions:

• In traditional software, code carries decision logic a human wrote in advance.
• In agentic software, a model generates the decision logic at run time and treats code as something it writes, uses and throws away.
• The paper traces a line from licensed software to SaaS to “Agent-as-a-Service”.
• It says the human role moves from “code author” to “intent architect, coordinator, auditor”.

I think the role name is good. I’d take it over “prompt engineer” or “AI orchestrator” any day, because it names the thing that’s hard.

I’d check some of the supporting evidence before quoting it. The reference for SWE-bench lists different authors from the ICLR 2024 paper (Jimenez et al.). The headline model results are from a 2024 paper. The “93% faster root-cause identification” figure comes from a company blog post about a pilot, not a peer-reviewed study. None of that makes the argument wrong. It does mean the posts announcing “Chinese researchers” and “a devastating title” were doing more work than the paper was.

The number that matters is 80% falling to 38%

Section 5 of the paper is the part I’d hand to an engineering leader. It quotes a benchmark the paper calls EvoClaw, now titled SWE-Milestone. Most coding benchmarks score an agent on one issue at a time. This one makes the agent keep evolving a codebase across a commit history, where each change has to preserve what the earlier ones built, and mistakes carry forward.

The abstract’s result: across 12 frontier models and 4 agent frameworks, overall scores “drop significantly from >80% on isolated tasks to 38.03% in continuous settings.” That 38.03% is the best configuration (Claude Opus 4.6 in OpenHands), not an average. The paper’s stricter measure, the share of milestones fully resolved, peaks at 13.37%.

The paper lists four causes: context drift, error propagation, no sense of technical debt, and tests that pass while the meaning is wrong. I’d put them in one sentence. Every change gets checked against the state just before it, and nothing checks the sequence against what you meant in the first place.

That’s the job, and it isn’t writing the code or even reviewing each diff. The intent architect keeps a fixed reference that every change is measured against, across time, after the context window that produced the change is gone.

Drift is what you get when every check is local

Here’s the failure as a physical thing. Two rows of six test blocks sit on a bench, with one master block at the near end engraved SPEC. That block is the written intent.

In the back row, each block was copied from the one before it and checked only against that neighbor. Every step is within tolerance. In the front row, each block was checked against the master. Both rows have exactly the same per-step errors.

Code review on a busy team works like the back row. A reviewer compares the pull request to main, not to the design doc from March. An agent with a fresh context does the same thing, faster and with more confidence. Each step is reasonable. The sum isn’t what anyone asked for.

The fix isn’t more review of each step. It’s a master block: intent written down somewhere durable, plus checks that compare against it rather than against yesterday.

Intent has to live in files, not in a conversation

My master blocks are boring. They’re text files and small pieces of code, and almost every rule in them exists because something went wrong first.

The writing rules for this site live in a skill file added in af270ec blog-writing skill: framing, numbers, polish bar . Its opening line says each rule exists because an earlier draft got it wrong. Two days before that, I’d pulled the site’s launch framing. The first version, from 4f3ce99 add Built with Agents series , led with how the work was produced. About an hour later, 8a11708 reframe series around human-managed delivery dropped the authorship stats and rewrote three articles around scoping, review, tests and gates. That decision now lives in the rules file, so no later draft can quietly bring the old framing back. The file keeps growing the same way: a1b4bc2 blog-writing skill: screenshot and crop lessons added a rule after a crop command silently cut off a page header and kept a line that should never appear in an article.

Rules in prose are necessary, and they aren’t enough. My drafting tool’s prompts tell the model never to use em dashes. It used them anyway, often enough that f546743 Studio: no em dashes or employer names in drafts added a stripDashes function that removes them from every suggestion after the model returns it. The prompt states the intent. The function enforces it.

The same review applies to my own words. In e49d4c7 Narration review: say blocking, and show blocking , an editorial pass on a video script found that the narration promised a hook would ask for human approval. The code didn’t do that. A hook that exits with code 2 refuses the call; it doesn’t prompt and it doesn’t wait. The words changed to match the code. The narration was intent too, and it was the part that had drifted.

The most important review was of the plan, not the code

Here’s the story I’d tell anyone asking what an intent architect does that an agent doesn’t.

On October 30, I wanted a command-line tool to draft comments with the same prompts and voice settings my browser extension uses. I asked one agent to write a handoff for another. The handoff was careful. It listed what to reuse, what not to touch, and limits such as “No live generation/API calls” in tests and “Avoid automatic retry after an uncertain paid request.” It also proposed a design: keep generation inside the extension and have the CLI call it through the existing local bridge.

The first build followed that design faithfully. b41d261 Studio drafting CLI: draft with the extension’s own generator added 1,485 lines across 18 files: a new bridge handler, a new MCP tool, a thin client and 32 tests. Nothing in it was wrong.

Then I looked at what it meant to run it. Drafting a comment from a terminal needed Chrome open, the extension loaded, the bridge connected and a token in place. I wrote back: “it seems simpler cli is more standalone and we just import any shared settings.” The second build, 0ae265d Studio CLI: draft standalone from a saved source and exported profile , removed the bridge handler and the MCP tool. It shares the drafting code with the extension at build time, reads a saved page and an exported voice profile from files, and calls the model API itself. It wasn’t smaller: it added 873 lines and deleted 679. It needed fewer things running, which was the point: no browser, no extension, no bridge, no token.

An agent can check an implementation against a spec, and it did that well. It can’t decide the spec was the wrong shape, because the spec is the only reference it has. The bench has one master block, and somebody has to be willing to say the master is wrong. In my experience, that’s where most of the leverage is.

Make the intent checkable before money moves

The redesign kept every limit from the handoff and moved as many as possible from prose into code. This is the part of the role I’d call architecture: deciding which pieces of intent a person holds and which ones code enforces.

The terminal shows what that looks like. These are real runs against a fixture article, with no API key in the environment, so nothing could be sent:

Three things in there carry intent, two of them enforced:

• The source hash. --expect-source-sha256 says “draft from the text I reviewed, not from whatever the file says now.” If it changed, the tool exits 4 before spending anything.
• The request hash. Since 0ae265d the standalone redesign , the dry run’s requestSha256 is computed over the exact request body, and the real run reports the same hash. The CLI doesn’t enforce a match yet: there’s no flag to require the reviewed hash, so comparing them is still my job. That’s the next gate I’d add.
• No retry. A timeout isn’t a cancellation. The provider may still finish and bill the request, so the tool reports and stops, and a person decides.

The step that stays human is the last one. Since d71de02 Add Claude MCP bridge for Timurista Studio extension , the bridge has had no submit tool: it can stage and paste a draft, and posting stays manual. Anything that goes out under my name goes out because I clicked.

Intent goes stale, so give it a version

Drift across commits has a cousin: drift across time. A person changes their mind, and an agent that started earlier finishes later with an answer to the old question.

I built a small public demo of exactly this in cb7e0bb Stale-completion admission demo: 11 synthetic schedules, three policies , written up in When the agent finishes yesterday’s task. Letting the newest result win got the active value right in 3 of 11 authored cases. Checking that the goal was still current before writing got 10 of 11. Checking at the write, in one step, got all 11.

The lesson for intent architecture is that “the intent” isn’t one document. It’s a sequence of decisions, each replacing the last. If agent output doesn’t carry the version of the intent it was produced against, you can’t tell a correct answer from a correct answer to last Tuesday’s question. The source hash in the CLI is a small version of the same idea: the draft names the exact text it came from.

What changes downstream

The paper’s practitioner advice is reasonable: shift to “intent engineering”, learn orchestration, invest in observability, keep a human in the loop. Here’s what I think follows from that once you’ve done it for a while.

Cost becomes a design input, not a bill you read later. The paper predicts outcome-based pricing for Agent-as-a-Service. Whoever prices outcomes has to know what one costs, including the reruns, the rejected drafts and the reviews. If the agent is the software, then every rerun and rejected output is part of what the software costs to run. Cost attribution stops being a FinOps report and becomes part of the architecture.

Accountability concentrates on the steps no tool may take. When agents do most of the execution, the few irreversible steps carry all the responsibility: publish, pay, delete, send, deploy. Those steps should be designed out of the agent’s reach, not guarded by a sentence in a prompt. My rule of thumb is that if I’d sign my name to it, no tool should be able to do it without me.

The skill that matters is spotting the wrong spec. Auditing output against intent is a skill people build by having written the thing themselves and watched it break. The paper suggests smaller teams of “agent orchestrators” may replace larger teams of developers. If juniors never write and break things, I don’t know where the next generation of auditors comes from. I don’t have an answer to that. I’d want any team that adopts this model to have one.

The title isn’t new. Strip out the typing and “intent architect” is what a good senior engineer already did. They held the reason for the system, said no to the plausible wrong design, and decided which rules belong in code. What’s new is that the typing no longer takes up the week, so the rest of the job is all of it.

What I didn’t check

• I didn’t reproduce the benchmark. The 38.03% and “>80%” figures are from SWE-Milestone, version 4, where 38.03% is the best configuration. I didn’t run it. The paper cites it under an earlier name, EvoClaw.
• The bench figure is illustrative. The per-step errors are synthetic numbers I chose to show the mechanism. They aren’t measurements of any agent.
• I didn’t contact the author. My reading of the change from version 1 to version 2 rests on the two texts, not on anything the author said about why.
• I can’t tell which version the viral posts read. They used the version 1 title. I dated them from their post IDs and didn’t verify who wrote them or whether they read the paper.
• My examples are one person’s projects. A solo repository with explicit rules files isn’t a team of fifty. Holding one fixed reference is harder when many people can edit it, and I haven’t shown how that scales.
• The 26 tests come from one commit message. They describe the CLI as committed in 0ae265d, and I didn’t rerun them for this article.

A checklist for the architect of intent

1. Write the intent down where agents read it. Use a rules file, a handoff or a design note, and add a rule every time a draft gets something wrong.
2. Measure against the master, not the neighbor. Review changes against the written intent, not only against the previous commit.
3. Move rules from prose into checks. If breaking a rule would embarrass you, enforce it in code after the model answers.
4. Refuse before spending. Validate inputs and require the hash of what you reviewed before any paid request.
5. Decide retries per tool. Never retry an uncertain paid request automatically.
6. Version the intent. Make agent output carry the version of the goal it answered.
7. Keep irreversible steps out of reach. Publishing, paying, deleting and deploying go through a person.
8. Review the plan, not just the build. A faithful implementation of the wrong spec is the most expensive kind of correct.

If you’re working out who owns intent, and what it costs, in your own agent workflows, here’s how I work.

---

AI-assisted, human-reviewed. The intent bench was drawn with the open-source anatomy isometric kit (MIT, © 2026 Ryan).

Related: When the agent finishes yesterday’s task, unalloc: checking a cost-attribution tool before anyone quotes its numbers and Any app on your machine can rewrite your agent’s rules.