Making a dashboard column sortable sounds like a contained change. Deciding what the column means can reach further.
\nIn October 2026, Scott Stouffer, Co-Founder and CTO of Market Brew, was using Codex to build the company's client reporting dashboard. The requirements expanded to make every table's column labels sortable. The team kept the existing report and branch, because the change concerned table interaction and a restart would have discarded already-tested work. What still needed settling was which result would count as correct.
\nThe initial request said dates should sort earliest-first; the clarification changed that to latest-first. Composite columns needed decisions too: sort by the answer's timestamp rather than the prompt text, and by inclusion percentage rather than a raw count. The initial row order had to stay intact until someone clicked a header, and a missing value had to remain distinct from a measured zero.
\nThese rules decide which result a tester should accept. A check that approved earliest-first ordering cannot also establish that the revised latest-first requirement works. Stouffer said the revised build passed developer verification and fresh tester QA on October 20 before the pull request merged. Earlier approval stayed in the record as history; it was not reused to approve the changed version.
\nThe same distinction applies to everything an AI coding agent has already produced. A new requirement can invalidate one part of a project while leaving other parts useful. The engineer has to decide which instructions still apply, which code remains compatible, which conversation helps the next step, and which earlier checks still support the result. Choosing whether to keep the chat answers only one of those questions.
\nRunbo Li, Co-founder and CEO of Magic Hour, described a video-template project that changed midway through a Claude Code session. The agent had scaffolded API routes, a database schema and part of the frontend for flat templates. Li then realized that the product needed nested, composable template blocks.
\nThe shift affected more than the schema declaration. With a flat structure, a renderer can process a single level of items. Nested blocks require the code that consumes the structure to account for deeper levels. Merely telling the agent that the model has changed leaves any old single-level behavior in the repository until someone finds and changes it.
\nLi kept the session and asked the agent to sort the existing work by its dependence on the old model. He retained work such as authentication and rate limiting, which he described as independent of the template structure. Rendering logic depended on the old schema and needed replacement. He also discarded work whose compatibility was uncertain. That last decision was his response to uncertainty in this project, not evidence that ambiguous code should always be deleted.
\nHe then gave the agent a short plaintext specification for the nested model and asked it to identify contradictions in the existing code. According to Li, that scan found a utility that assumed flat template IDs and a frontend component with a single-depth rendering loop. The findings put specific code behind the broad instruction to support nested blocks.
\nThe causal point is straightforward: code can preserve an old requirement without any remaining prompt telling the agent to follow it. A new chat that reads the same utility or renderer can inherit the same assumption. Inspecting the code's behavior is therefore a separate task from clearing the conversation.
\nLi said the team shipped in about a day and a half, including the pivot. He estimated that a complete restart would have added a day. That alternative was not run, so the estimate cannot establish measured time saved or predict the benefit for another team.
\nVictor Smushkevich, Founder of Tested Media, described another way a changed requirement spreads: a funnel built around a quote form has to become a booking flow halfway through the build. He presented this as a recurring pattern, not a single dated project.
\nHis first step is to rewrite the short brief at the root of the project and remove the old requirement from the active instructions. As he put it, \"an agent will happily follow a stale line sitting next to a new one.\" He then searches for old wording in form labels, thank-you copy and tracking event names. He keeps layout, styles and SEO structure when they do not depend on the conversion flow, and rebuilds the form handler, confirmation page and follow-up automation from the new brief.
\nThat division holds only if the retained parts really are independent of the user's action, and the rebuilt parts are exactly the ones that encode it. A page can keep its layout while the action it offers changes. The handler accepts that action, the confirmation page tells the user what happened, and the follow-up automation acts on the result. When a quote request becomes a booking, all three still encode the old action until they are rebuilt. This describes the dependency to check, not unreported details of Smushkevich's implementation.
\nA wording search helps locate those dependencies, but it does not settle them. An old term might still belong in historical documentation or a migration. Conversely, a generic function might embody the obsolete behavior without mentioning the old term at all. Li's single-depth renderer is the useful counterexample: the problem lies in how it traverses the data, not necessarily in what its variables are called.
\nThe outcome of this inspection should be a concrete account of what the change reaches. For nested blocks, that means checking how the structure is identified, stored and rendered. For a booking flow, it means checking what is submitted, what is confirmed and what follows. These are PSEEDR's proposed inspection questions, not additional reported features of either system.
\nAbhishek Pareek, Founder and Director of Coders.dev, chose a fresh start for the conversation in a fintech API project. Tax requirements moved from a flat structure to a tiered, jurisdiction-based model. His team retained validated data models and discarded the functional routines.
\nPareek is more skeptical than Li about continuing after a major change. \"Attempting to refactor agent-generated code after a major pivot is a sunk-cost trap that usually results in prompt pollution, where the model attempts to reconcile conflicting instructions and produces hybrid logic that fails complex edge cases,\" he wrote in a written response to PSEEDR.
\nHis practice is to branch from a clean checkpoint and give the agent the retained models alongside the new requirements. \"We now treat agent sessions as ephemeral and output files as durable assets,\" he wrote. He did not supply an elapsed-time comparison or a detailed verification outcome for the project, so his broader claim about efficiency remains his judgment from delivery work.
\nLi's account shows that continuing can work in one reported case. Pareek's account explains why his teams prefer to replace the context. Neither establishes a universal rule. Both preserved selected files while explicitly changing the instructions governing subsequent work. The session choice did not determine how much code had to survive.
\nSmushkevich makes that choice according to what the conversation contains. He continues when it mainly concerns layout. If it contains hours of discussion about the old flow, he opens a fresh session with updated notes and a short account of the repository changes. Useful background can then carry forward without presenting the withdrawn flow as the current task.
\nThe four decisions can be kept distinct:
\n| What may carry forward | \nWhat must be decided after the requirement changes | \n
|---|---|
| Active specification | \nWhich instruction now governs the work, and which has been superseded? | \n
| Code and other files | \nWhich assumptions still hold, including assumptions made by code that consumes changed data? | \n
| Conversation | \nWhich history helps implement the new requirement, and which history could direct the agent toward the old one? | \n
| Earlier checks and approval | \nWhich claims remain supported, and which expected results must change? | \n
This table is PSEEDR's synthesis of the accounts. It does not rank workflows by measured success. Its purpose is to prevent a decision to keep a file or restart a chat from silently carrying an obsolete instruction or approval with it.
\nTool controls make the distinction between conversation and files concrete. Claude Code's checkpointing documentation, consulted for this article, describes restoring the code, the conversation, or both. Summarizing a conversation does not change files on disk. Restoring only the conversation leaves the current code in place.
\nFile restoration also has limits. A file changed only through shell commands is not tracked by these checkpoints. If the session's file-editing tools had already edited that file, however, rewinding also undoes subsequent shell changes to it. Most subagent edits to other files, and edits made outside the session, are not captured. The documentation treats checkpoints as a way to recover within a session, alongside permanent version control.
\nSo after a rewind, the workspace may still contain changes that the engineer expected to remove. Before using it as the base for the revised task, the engineer needs to establish which files were restored and which remained. These documented controls do not establish which tool version or features any contributor used.
\nConversation compaction has a different job. Anthropic's explanation of context engineering describes summarizing a long conversation and continuing with that summary in a smaller context. It cautions that excessive compression can remove subtle but important details.
\nSelecting what to remember does not by itself determine which requirement is authoritative. Take an illustrative summary of the dashboard project: it could accurately report that dates once needed earliest-first sorting while failing to make clear that latest-first replaced it. The summary would preserve history and still leave the next agent with an unresolved instruction. The revised brief needs to distinguish a former decision from the current one, whether the team continues, compacts or starts a fresh session.
\nThe GitHarness preprint studies a related decision: which prior work state fits a changed requirement? Its framework pairs requirement states with recoverable work states. An agent selects a compatible historical base, after which the system can reuse it, modify it or start fresh. The latest version is one possible base, not the automatic choice.
\nThe mechanism matters because later work may be organized around a requirement the user has withdrawn. Returning to an older compatible version can avoid carrying those changes into the next attempt. But the system still has to interpret the new requirement correctly and choose the appropriate version. Saving history supplies options; it does not identify the right option on its own.
\nThe authors evaluated constructed, seven-turn requirement sequences derived from existing benchmarks, rather than conversations collected from real users. For the software-engineering tasks, they report 73.6 percent lower average token use than native continuation. Their cost accounting aggregates model calls across each seven-turn interaction and averages completed samples. It does not measure developer hours. The savings also depend on the task: the math results use more tokens than the native baseline.
\nOne experiment tests the importance of choosing the base. When the system was forced to resume from the latest state, rather than select a historical version, the reported code resolved rate fell from 74.0 percent to 44.0 percent in that setting. Resolved rate is the share of benchmark tasks whose patches met the benchmark's success criterion. This result supports historical selection within the experiment; it does not tell a team which checkpoint to choose in its own repository.
\nThe authors also acknowledge that restoring a compatible state does not guarantee preservation of all unaffected work. PSEEDR has not reproduced the results, and they are not a product recommendation.
\nFor the practical decision, the current branch may remain the best base when the change is local and compatible work is already present. An older checkpoint may be useful when later changes depend on the withdrawn requirement. A broader restart becomes reasonable when the engineer cannot establish a reusable boundary at an acceptable cost. None of these choices removes the need to check the resulting behavior.
\nStouffer's dashboard account shows why that final check is separate from choosing what code to keep. The team replaced ambiguous sorting instructions with explicit rules in its existing Monday.com QA item and test plan. In its workflow, a revision to an existing specification returns that QA item to specification approval. A new specification receives a separate change request. A proposed real-data pilot remained follow-up scope.
\nThose are the team's reported procedures, not extra approval requirements for every engineering team. Their role in this case was to give the implementer and tester the same revised target while keeping a larger proposed task separate.
\nConsider what would happen if an old sorting test survived unchanged. This is PSEEDR's reasoning from the reported rules, not a failure Stouffer described. A test expecting earliest-first order could reject a correct latest-first implementation. If the implementation still sorted earliest-first, that same test could pass while the new requirement remained unmet. The code and test would agree with each other because both still encoded the old rule. Agreement alone would provide false reassurance.
\nThe opposite mistake is to discard every previous result merely because one rule changed. Earlier checks can remain useful for claims whose relevant assumptions still hold. The work is to identify those claims, update checks that express the superseded rule and test the interactions through which the change might affect retained behavior.
\nStouffer reported browser regression checks and saved-data comparisons for filters, pagination, exports and the underlying evidence. The stated endpoint was acceptance of the revised build and a merged pull request, not production deployment or a measured productivity gain. Missing values and measured zero also needed distinct expectations because the requirement explicitly treated them differently.
\nSmushkevich described rebuilding, clicking through the full path on a phone and comparing untouched pages with the previous commit. These checks answer different questions. A comparison can establish that a file did not change. A journey check can expose a broken interaction between files. An unchanged file can still receive different input after its caller changes, so an unchanged diff alone cannot establish that its behavior remains suitable.
\nThis gives the engineer a reason to retain work beyond the agent's recommendation. A module belongs in the keep group when its relevant requirements and assumptions still hold, supported by inspection and appropriate checks. The agent's classification helps organize that work; the label itself does not supply the evidence.
\nWhen requirements change, preserve the work that still fits, then choose how to give the agent that work. Write the revised requirement where the agent will actually read it. Mark superseded instructions as history or remove them from the active brief while preserving the historical record. State which behavior should remain unchanged and follow the changed assumption into the code that depends on it.
\nThat leaves a concrete choice of starting point. Continue when the instructions are clear and the conversation remains useful. Start a fresh conversation when the old discussion continues to drive obsolete behavior, carrying forward files whose compatibility has been checked. Use an older version when it offers a better base. Restart more broadly when a useful boundary cannot be established.
\nFinally, make the checks answer the revised question. The dashboard could keep its report and branch while changing its expected sort order and renewing the evidence for acceptance. Li could keep a session while replacing code tied to flat templates. Pareek could replace the session while retaining selected models. Useful work survives because its assumptions still apply, not because the team chose a particular reset button.
\nLi put the remaining responsibility plainly: \"Coding agents are fast, but they don't know when their assumptions expired. That's still your job.\"
\nReporting note: These accounts were supplied in written responses to PSEEDR and were not independently reproduced. Contributors hold leadership roles at the companies identified above. Stouffer and Li describe their own companies' products. GitHarness results come from a preprint that PSEEDR has not reproduced. The comparisons, illustrative explanations and proposed checks are PSEEDR's analysis; the accounts are not an industry survey.
\n", "articleImage": { "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/when-coding-agent-requirements-change-what-should-survive.58278bc8.jpg", "width": 1280, "height": 720, "alt": "Reusable blocks beside a card with crossed-out and revised instructions. Text: What should survive?" }, "image": { "@type": "ImageObject", "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/when-coding-agent-requirements-change-what-should-survive.58278bc8.jpg", "width": 1280, "height": 720, "alt": "Reusable blocks beside a card with crossed-out and revised instructions. Text: What should survive?" } }