Why I'm retiring AER
AER ends at 6.1.0. I would rather maintain focused personal guidance and repository facts than keep a broad rules layer chasing better models and harnesses.
I've archived Agent Engineering Rules and left it public, with 6.1.0 as the final release. As models and harnesses improve, I see less value in maintaining a broad layer of prescriptive engineering instructions. I don't want to keep expanding that layer to chase behavior the tools increasingly handle themselves.
That is a maintenance decision about my project. It does not prove instructions are useless. I still want short personal guidance and repository-specific facts: what the product must do, which commands work, where the boundaries are, and what the code cannot tell an agent on its own.
What I actually compared
The runs used interactive pi 1.4.0 with qwen3.8-max at low thinking and refactored AER content from commit 28ba473, not the older 6.0.1 content. These were small local comparisons with restricted file tools and external grading, not a representative benchmark of everyday coding agents.
The first pilot covered three tasks per condition using the relevant standalone skill, without the full kernel. Both conditions passed the scoped checks; I saw no clear correctness gain. AER used about 23.6% more reported tokens including cached input. A harder queue task, also using a standalone skill, gave both conditions 10/10 predeclared checks, with about 25.1% more cache-inclusive tokens for AER. Those percentages describe these runs, not prices or savings.
Evaluated AER content: commit 28ba473
The webapp comparison has a bigger caveat
The mini webapp pair did compare the full kernel and skill catalog against no AER. The original round hit a flawed conservative budget guard and left both apps incomplete. That round is inconclusive. The original pi histories were not saved, so repair used fresh sessions on copies, with identical instructions and limits. It was not a continuation of the original sessions.
Both repaired apps passed 17 sampled interaction checks. Both still had code and data-quality weaknesses, including incomplete seed descriptions. The treatment received the kernel and catalog, but did not explicitly read skill bodies or references. I did not establish a clear overall code-quality advantage. A select-arrow difference came from native browser styling versus custom CSS; I cannot attribute it to an AER instruction.
One model, one harness, tiny samples, unblinded grading, constrained tools, caching and order effects leave plenty unresolved. Passing sampled checks does not establish equivalence, and these runs do not establish statistical significance, general benefit, or billed cost. They gave me no clear reason to keep maintaining the broad layer.
What I'm keeping
The release and public source remain available as a record of the work. The installer and its ownership checks were real engineering; that alone was not evidence that the instructions improved model output. For my own work, I'll keep guidance focused on information and preferences the agent needs, and let the repository's executable checks carry requirements they can actually enforce.
A ten-minute check for your own guidance
Pick one instruction you maintain. Does it supply a fact the repository doesn't reveal, record a real preference, or repeat generic advice? Try one small task with and without it, using the same model, harness and checks. Treat that as a local observation, not proof. My decision to stop maintaining AER does not need to become everyone else's rule.