Enumerate the behaviours a restructure is promising not to change, test the change against that written list rather than a specification nobody wrote, and hold it for the reviewer who takes it.
Restructures the code, not the claim that nothing moved
In
01
A module is restructured, and the behaviours it promises to hold are written down before a line moves.
02
A function moves in the sequence, and SEC Release 34-70694 para 14 is why its dead callers are retested.
Reason
03
A path with no callers is raised with a proposed category — dead, deactivated or extraneous — not deleted.
04
A bug is found mid-restructure, and whether it was buggy does not matter, so it is raised separately.
05
A behaviour is observable and never promised, and it goes on the list, because the edge is found by breaking it.
Decide
06
A transformation runs, and the engine that performed it is named, because engines ship bugs of their own.
07
A run touches many files at once, and FDA asks whether that is a significant software re-write.
Out
08
A behaviour resists enumeration, and that is recorded as a limit of the check rather than as a pass.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Enumeration, restructuring and testing belong to the agent. Taking the change belongs to a named reviewer, who merges it and answers for what moved.
Example workflow
One restructure, module to merge
AgentHuman
1Module and history receivedRepository, call graph, runtime traces, test suite and the change history behind the module
2Preserved behaviours enumeratedThe observables the module shows now, its callers, the paths believed unreachable and what no test asserts
3Restructure draftedThe diff, the enumerated list, what the check could not cover and confidence
4Controls appliedPreservation replay, scope measurement, unused-code categorisation and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is merged at any of them — the agent is restructuring, and the reviewer lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the named reviewer to merge.
Low confidence
Adds a codebase-owner read first.
Reviewer acceptance
The change is held with its enumerated list, what went unchecked and the confidence.
Merge · Amend · Send to owner review
Taken — merged by the reviewer▼
6Repository and tracker updatedOnly where write access and change policy allow it
7Outcome evaluatedAmendment rate, preservation outcomes, defects after merge and what review found
Amendments
Each reviewer amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Merging a restructure into the mainline.
Declaring unused code safe to delete.
Classifying the scope of a change under a regime.
Signing the design-control record for a change.
Automation boundaryAgent acts unaided
✓Enumerate the behaviours the change must preserve.
✓Replay each enumerated behaviour on both sides and diff the results.
✓Run the transformation through a tested engine wherever one exists.
✓Hold the change and its gaps for the named reviewer.
Nothing is merged except by a named reviewer, inside the boundaries agreed at implementation.
Correcting a behaviour found while restructuring.
Changing an interface another team already reads.
Deciding what counts as observable at all.
Changes to restructuring rules or approval thresholds.
Example output
One restructure, annotated
This serves teams whose diffs say no functional change against a definition that names observable behaviour and no observer; below is one restructure exactly as the agent leaves it.
Refactoring output · single moduleIllustrative example
Module
Behaviour at issue
Checked against
Evidence of record
Confidence
Held for
Order-routing module
A caller on a path with no live route was not replayed
The enumerated list
Production traces
81%
The named reviewer, by name
As receivedTaken from the module as it runs and the traces behind it — nothing here is assumed preserved.
What the record holdsProduction tracesCaller inventoryUnused-path register
Why this is heldThe reachable callers pass; one sits on a path nothing exercises.
ActionMergeAmendSend to owner review
What the score decidesBelow the configured threshold a change picks up an owner read before the reviewer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each restructureFrom the module it touches
03Restructuring
Enumerate before you change
Fowler defines the promise over observable behaviour and names no observer; Opdyke fixes it to the inputs and outputs of main, and concedes some preconditions are undecidable.
01Approved path
It promised nothing changed
MDCG 2020-3, on the Article 120 transitional regime for legacy devices, gives the bug fix a safe harbour and withholds one from the restructure.
02Human review
What was searched for, and not found
No regulator found here defines technical debt. Nothing requires code to be maintainable, forbids duplication or sets a complexity limit, and no rule found requires a restructure to be tested — the protocol Knight was faulted for lacking was constructed after the loss.
04Build an evidence trail
The restructure, the behaviour it preserved and the reviewer who took it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A module-level preservation figure can read clean while paths believed unreachable carry most of the amendments. Nestack reports the reviewer-amendment rate by module class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Paths believed unreachable
6.1%
3.7×
Review
Interfaces other teams read
4.3%
2.6×
Review
Timing-sensitive code
2.7%
1.6×
Watch
Well-covered internal modules
1.3%
0.8×
Normal
Bar: reviewer-amendment-rate lift vs. well-covered-module baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a no-change diff costs later
A cycle shuts when the path nobody could reach is a regression case. That suite is what the next restructure taken is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises in one module class.
02Diagnose
The diff that says no functional change, over behaviour nobody has ever written down, is worked backwards until one cause is left standing.
03Improve
Numbered the change ships, and the restructures behind it travel attached.
04Verify
Each touched behaviour case is run again, and one red holds it back.
05Learn
The case is kept, and the restructuring rules change in that same commit.
Learn → DetectThe return edge. The next restructure taken is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, refactoring workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Refactoring discovery and automation-boundary scope.
02Repository and engine assessment.
03Preserved-behaviour and unused-code categorisation.
04Module ingestion.
05Enumeration and preservation logic.
06Confidence scoring and review routing.
07Reviewer acceptance workflow.
08Repository and engine integration.
09Preservation and scope cases.
10Guardrails and transformation controls.
11Restructure-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne module, one cycleProductionProduction repositoryAdvancedMultiple repositories / teams
Introduced at Pilot
Restructuring to your rules✓✓✓
Named reviewer acceptance✓✓✓
Observable-behaviour baseline✓✓✓
Introduced at Production
Reporting by module class—✓✓
Acceptance workflow in your systems—✓✓
Approved write-back—✓✓
Engine-and-forge integration—✓✓
Introduced at Advanced
Multi-language transformation rules——✓
Multi-stage change approvals——✓
Large codebases——✓
Multi-module transformation controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, codebase size, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your modules and what each one still does→Behaviour enumeration and list versioningWeek 1
02Representative production traces and callers→Enumeration baseline, engine binding and the preservation suiteWeek 2
03Your change-classification and merge policy→Preserved-behaviour and unused-code categorisationWeek 1
04Access to relevant repositories, engines or exports→Repository and engine assessment, then integration setupWeek 2
05Restructures you would not want inspected→Preservation cases and the evaluation roundWeek 4
06What no restructure may remove→Confidence scoring, review routing, guardrails and acceptance controlsWeek 3
07A named reviewer to take the changes→Reviewer acceptance workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each phase gets exactly the width it costs, so week five shows two bands where one would look neater.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Refactoring workflow discovery, behaviour enumeration and the automation boundaryW2Repository and engine integration and the enumeration baselineW3Restructuring workflow, confidence logic and acceptance controlsW4Evaluation suite, preservation cases and failure-mode testingW5Repository integration, pilot modules and targeted correctionsW6One engineering cycle run under the codebase owner, then Agent Care handover
Reading the bandA bar spans the weeks its own work is named in, and the week five overlap is real.
At the end of W6Once the behaviour record validates, Agent Care picks the agent up.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a refactoring agent around the behaviour your last no-change diff never listed.
Show us one module you keep meaning to clean up and who merges it. What the last restructure did not enumerate was the caller on a path nobody could reach and the ordering somebody relied on. A migration declares that things will change; this declares that nothing will.
