Designing AIDD Resume Notes through SWE-1.7 Self-Compaction

On July 8, 2026, Cognition published SWE-1.7. The article explains that SWE-1.7 is available in Devin, and discusses topics such as the reinforcement learning pipeline, training across multiple clusters, data quality, and self-compaction for long-running tasks.

The performance tables and training infrastructure are interesting, but the part that caught my attention most was self-compaction. When a long task approaches the context limit, the model summarizes its own work state and resumes from that summary.

This is a very familiar problem in AIDD.

When using development AI agents such as Claude Code, Codex, Devin, and Cursor, work rarely finishes in one turn. The agent investigates, edits, tests, fails, reads another file, and sometimes waits for a human decision. When work is interrupted at that point, the quality of the next restart depends heavily on what state was left behind.

Wait, does the quality of the note determine the speed of development?

This article does not verify SWE-1.7 performance itself. Instead, it takes one idea from Cognition’s article, that long-running tasks need a compressed state in order to be restarted, and tests what should be preserved in an AIDD resume note.

LLM Lab If You Do the Same Work Twice, Turn It into an AIDD Standard Entry Point An article on turning personal AI usage tricks into team-reusable development processes through standard commands, templates, and review criteria. https://llm-lab.dev/posts/aidd-standardization-repeat-work/

What I Took from the SWE-1.7 Article

Cognition’s article explains several axes of SWE-1.7, including handling the gap between top-p sampling and the training distribution, reinforcement learning across multiple clusters, verifier quality and anti-cheating data work, and self-compaction for long-running tasks.

This article focuses only on self-compaction because it connects directly to my own AIDD operations.

In development AI agent operations, model intelligence is not the only issue. The following questions appear very quickly.

• Which files were read?
• Which commands were executed?
• What is failing?
• What has not been decided yet?
• What should be done next?
• Which areas should not be touched?

If this information exists only deep inside the chat history, every restart begins with digging through past context. If another AI agent takes over, or if a human reviewer needs to understand the state, assuming that they will read the entire history is not realistic.

In the SWE-1.7 article, self-compaction is described as a technique for a large model. But when applied to AIDD operations, it becomes a very practical design problem: what granularity of work state must be preserved so the next actor can restart safely?

What I Wanted to Verify

For this verification, I used a fictional development task: adding a failed-status filter to a CSV import history list in an order management screen. It does not use confidential information or real business data.

I prepared two resume notes.

Too-short resume note:
Working on the CSV import history in the order management screen.
Tests are failing around the filter, so continue from there.

The other note is longer and explicitly includes the goal, target files, commands already run, failing test, open decision, next actions, and safety constraints.

The verification script prepared for this article does not call an external API or model. It takes a fixed work state and the two resume notes as input, then deterministically checks whether the information needed to restart the task remains in the note.

The seven criteria are:

• Goal
• Files currently being inspected
• Commands already run
• Failing checks
• Open decisions
• Next actions
• Safety constraints

This is a custom verification script prepared for the article, not an official CLI. npm run verify reads the sample work log, evaluates the two resume notes against the same criteria, and outputs JSON plus an HTML report.

npm run verify

What I wanted to confirm here was not whether the natural-language summary was elegant. I wanted to confirm whether the compressed note contained the state the next worker needs.

A Short Note Leaves Only a Sense of Comfort

The result was extreme.

The too-short resume note failed all seven criteria. The operationally usable resume note satisfied all seven.

The short note still describes the situation in a vague way. It says that the CSV import history is being edited and that tests around the filter are failing. But it is not enough to restart the task.

For example, “tests are failing around the filter” does not tell the next worker which test to inspect. It also does not say which files were changed, so the next step begins with search. In addition, it does not preserve the safe scope of the work.

That hurts.

If the same human restarts on the same day, memory can fill the gap. But once the restart happens the next day, by another agent, by another person, or on another machine, the short note becomes almost useless. It creates reassurance, but the work state is too thin.

A Resume Note Is Not a Summary, but a Handoff Specification

What this verification made clear is that treating an AIDD resume note as a simple summary is weak.

If the goal is summarization, brevity has value. But the purpose of a resume note is not to be short. Its purpose is to reduce unnecessary searching, avoid mistaken scope changes, and let the next worker take the next safe step.

In that sense, a resume note is closer to a handoff specification.

The particularly important part was safety constraints. When instructions are vague, development AI agents may “helpfully” modify surrounding code. The SWE-1.7 article also explains that models which explore more tend to add tests or broaden the work scope. That can be a sign of capability, but in operations it appears as expansion of the change surface.

That is why a resume note needs not only what to do next, but also what not to touch.

What to preserve:
goal, target files, commands already run, failing checks,
open decisions, next actions, safety constraints

These seven items are not a perfect standard. They should increase or decrease depending on the task. But when handling long-running AIDD tasks, starting from this granularity reduces dependence on chat history.

Bringing Self-Compaction into Operations Turns It into Evaluation

At first glance, self-compaction looks like a technique for saving context. It is partly that. But operationally, the problem is not whether the note became shorter.

The important question is whether the compressed state can be verified.

Even with the simple script used here, the difference between the short note and the operational note was visible. In real AIDD operations, this state would also include Git diff, unfinished tasks, review comments, CI results, commands run locally, and decisions waiting for a human. Once that happens, judging resume-note quality only by human intuition becomes difficult.

If I were putting this into operation, I would start with the following flow.

• Have the AI create a resume note at the end of long-running work.
• Deterministically check whether the resume note contains required items.
• If items are missing, ask the AI to add only the missing parts.
• On restart, read the resume note before reading the chat history.
• Move important decisions back into design notes or issues, not only into the resume note.

At that point, self-compaction is no longer just prompt craft. It becomes AIDD operational log design.

What I Did Not Verify

This article does not evaluate SWE-1.7 performance, verify behavior in Devin, or reproduce Cognition’s benchmark results.

It also does not test LLM-generated resume notes. In this verification, the resume notes already exist, and I only checked whether they contain the information needed to restart the task.

The next step would be to generate resume notes from real AIDD work logs, detect missing items using the seven criteria from this article, and ask the AI to fill only those gaps. At that point, the quality of self-compaction can be evaluated not as “readable summary” but as “restartable state.”

Summary

What I found interesting in the SWE-1.7 article was that intelligence on long-running tasks depends not only on having a long context, but also on how intermediate state is compressed and restarted.

The same is true in AIDD. The longer AI agents can work, the more important it becomes to decide how to preserve the intermediate work state. “It is all in the chat history” is not an operational design.

A short resume note leaves reassurance. But for the next worker to restart safely, the note needs the goal, target files, commands already run, failing checks, open decisions, next actions, and safety constraints.

Personally, I think AIDD self-compaction is better treated not as “making summaries better” but as “testing whether the work state can be restarted.” If this becomes a system, AI-driven development can move from one-off chat sessions toward a development process that can be handed off.