Key Takeaways
- On November 5, 2026, researchers from Upwork and the University of Technology Sydney posted "Take It From Here" to arXiv. It tests whether coding agents can take over an ongoing project from its message history and deliver the next request.
- Across six Codex CLI and Claude Code configurations, the mean complete-delivery rate was 4.95%. A delivery counts as complete only if the project builds, the requested change works and earlier requirements still hold.
- Agents usually kept the project building (58.56% of runs) but rarely made the requested change work (6.31%). By our count, that is 11 complete deliveries in 222 runs.
- Handing the agents the correct target requirements raised builds to 96.40% but complete delivery only to 8.11%. No configuration reconstructed an exact requirement state in any of 312 tests.
- The differences between models come down to one to three tasks out of 37, so this study doesn't crown a best agent. It shows where the work breaks: tracking what the client currently wants.
A coding agent project takeover study published this week puts a number on a question many engineers have asked about their own jobs: if an agent inherits a project halfway through, can it pick up where the last person left off? In this benchmark, it almost never could. The agents kept the code compiling, but they lost track of what the project was supposed to do now.
What happened
The preprint "Take It From Here: Evaluating Coding Agents On Project Takeover" by Dingxian Wang and 11 co-authors was submitted to arXiv on November 5, 2026. Its first line sets the premise: "Coding agents increasingly collaborate on long-term projects." The authors gave each agent a project's interaction history, its current files and a new request, and checked whether it delivered.
The corpus is 44 ongoing projects covering software, Word templates and reports, and PCB design, with 7,983 messages in total. A project's history ranged from 18 to 1,075 messages, with a median of 110. The paper doesn't say where the projects came from, only that the material was processed to protect privacy and won't be released without authorization.
What the coding agent project takeover study tested
Six agents, four levels of help
The authors ran Codex CLI 0.155.1 with GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol and GPT-5.6 Terra, and Claude Code 2.1.283 with Claude Opus 5.5 and Claude Sonnet 5, all at high reasoning effort. Each run had 30 minutes to code. Every configuration was tested under four conditions:
- Full history: every message before the takeover point, a mean of 186.86 messages per delivery target.
- Relevant history: only the messages about the requirements the request touches, a mean of 8.70 messages.
- Correct starting state: the right list of requirements before the request, so the agent only has to apply the change.
- Correct target state: the right list of requirements after the request, so the agent only has to implement it.
Executable checks covered 37 targets from 7 projects: 22 software or website tasks, 9 ESP32 circuit-board tasks, 4 Word templates and 2 security reports. A separate diagnostic set of 349 targets measured whether the agent understood the requirements at all. In 312 of those the agent should act, and in 37 key information was missing and it should ask.
The project kept building while the requested work failed
With the full history, the mean build pass rate was 58.56% and the regression pass rate was 51.35%. The requested change worked 6.31% of the time, and all three checks passed together in 4.95% of runs. Cutting the history down to the relevant messages made things worse, not better: complete delivery fell to 2.70%.
The oracle conditions isolate the two problems. Given the correct starting state, complete delivery was 4.50%, about the same as with the full history. Given the correct target state, builds rose to 96.40% and regressions to 90.99%, but target tests passed only 9.01% of the time and complete delivery reached 8.11%. In the paper's words, agents struggle both to work out what the target requirements are and to implement them in an existing project.
The numbers behind it
Per model, counted out of 37
Percentages on 37 targets hide how small the counts are. We converted the paper's Table 4 into tasks, and added the share of runs that built which were also complete deliveries.
| Configuration | Builds (of 37) | Requested change works | Complete deliveries | Complete as share of builds | Complete, given correct target state |
|---|---|---|---|---|---|
| GPT-6 Astra (Codex CLI) | 21 | 6 | 4 | 19% | 4 |
| GPT-6 Sol (Codex CLI) | 18 | 3 | 2 | 11% | 5 |
| GPT-5.6 Sol (Codex CLI) | 22 | 1 | 1 | 5% | 5 |
| GPT-5.6 Terra (Codex CLI) | 20 | 2 | 2 | 10% | 2 |
| Claude Opus 5.5 (Claude Code) | 28 | 2 | 2 | 7% | 2 |
| Claude Sonnet 5 (Claude Code) | 21 | 0 | 0 | 0% | 0 |
| All six | 130 of 222 | 14 of 222 | 11 of 222 | 8.5% | 18 of 222 |
Two things stand out. Claude Opus 5.5 kept the most projects building (28 of 37) but completed 2, so a green build told you little about whether the work was done. And the best result, GPT-6 Astra's 4 of 37, is a few tasks ahead of the rest. With samples this small, the paper's own ranking between models isn't something to buy a tool on.
Finding a requirement is not the same as getting it right
The diagnostic set shows where the understanding breaks. Reading the full history, the agents identified 0.50 to 0.68 of the relevant requirements (coverage) but recovered their current values far less well, scoring 0.24 to 0.28 on attribute reconstruction. Not one configuration produced an exactly correct requirement state on any of the 312 targets that called for action.
The paper gives a concrete example. On a circuit-board project, Claude Opus 5.5 recorded the mounting-hole layout requirements in its starting state, then dropped the whole mechanical-layout requirement from its target state, even though the request never withdrew it. That is the failure a human handover note exists to prevent.
Deciding whether to act or ask also went badly. The paper reports that always choosing to act would score 0.894 decision accuracy on this set. Every configuration scored lower, from 0.50 to 0.79. The four GPT configurations asked for clarification on roughly half of the requests that needed none, and five of the six never produced a fully successful clarification under the full history.
Limits of the data
The executable results rest on 37 targets from 7 projects, and the authors say so: "Executable validation currently covers only 37 tasks from 7 projects." Some scoring uses a model as a semantic judge. Nine of the 37 delivery targets are circuit-board tasks and six are documents, so the mix isn't typical of a software team's backlog, and the paper doesn't break results out by domain. The project data isn't public.
What this means for you
If you hand projects or tickets to an agent
- Write the current requirements down in one place before the handover. The agents found requirements in long histories but got their values wrong, and trimming the history to relevant messages lowered delivery from 4.95% to 2.70%.
- State what the request changes and what it leaves alone. Dropped constraints, like the circuit-board layout above, are the regressions a build won't catch.
- Test the requested behavior, not just the build. 96.40% of runs built when the target state was given, and 9.01% passed the target tests.
- Expect an agent to either guess or over-ask on vague requests. None of the six handled the act-or-ask decision better than the trivial baseline.
If you're worried about your job
This study measures one thing: taking over someone else's project from its history. On that task, the part that failed is the part engineers are paid to own. Agents could edit files and keep the build green, and they couldn't reliably reconstruct what the client currently wants. That doesn't predict hiring, and the paper doesn't claim to. It does tell you which skills are hard to hand off right now: keeping a project's requirements straight, writing a usable spec, and verifying that a change does what was asked.
If you lead a team
Treat the project's requirement state as a maintained artifact, not something buried in chat or ticket comments. If an agent, a contractor or a new hire is going to pick the work up, they all need the same document, and this study suggests the agent needs it most.
How this connects
Our analysis of whether AI will replace software engineers argued that the work is moving from writing code to directing agents, with the spec as the unit of work. This study adds evidence for why: without a correct, current spec, agents that inherited a project completed 4.95% of requests. It fits the earlier finding that coding agents follow stale instruction files over the code in 90.1% of choices, and that coding agents follow repository precedent over your intent: what the agent is told about the project decides what it delivers.
For what employers are hiring for while this plays out, see the software engineer job market 2026 data. If you're preparing for interviews where this comes up, a strong answer to "how would you hand this codebase to an agent?" starts with the requirement state, then the tests for the requested change, then the regression checks. How coding interviews changed in the age of AI covers the AI-assisted rounds, and Mastering the Tech Interview covers the system design and communication skills those rounds now test.
FAQ
Can AI coding agents take over an existing project?
Rarely, in this benchmark. Across six Codex CLI and Claude Code configurations given a project's full message history, the mean complete-delivery rate on 37 targets was 4.95%. Builds passed 58.56% of the time, but the requested change worked 6.31% of the time.
Does giving the agent less history help?
Not in this study. Keeping only the messages relevant to the request lowered mean complete delivery from 4.95% to 2.70%. Giving the agent the correct target requirements raised it to 8.11%.
Which coding agent did best?
GPT-6 Astra in Codex CLI completed 4 of 37 targets with the full history, and Claude Sonnet 5 in Claude Code completed none. The gaps are one to three tasks, too small to rank tools on.
Why do agents fail at project takeover?
They find most of the relevant requirements but get their current values wrong, scoring 0.24 to 0.28 on attribute reconstruction. No configuration produced an exactly correct requirement state on any of 312 targets.
Further Reading
- Wang et al., "Take It From Here: Evaluating Coding Agents On Project Takeover" (arXiv:2611.07307): the study, its benchmark design and full results tables.
- Xu and Wu, "Stale Instruction Files Override the Code in Coding Agents: A One-Sentence Fix" (arXiv:2610.30571): what agents do when the instruction file and the code disagree.
