Main site

Engineering AI agent · Tech debt

Tech-Debt Refactoring AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Named reviewer
Behaviour first
After launch
Agent Care

What this agent does

Restructures the code, not the claim that nothing moved

In

  1. 01

    A module is restructured, and the behaviours it promises to hold are written down before a line moves.

  2. 02

    A function moves in the sequence, and SEC Release 34-70694 para 14 is why its dead callers are retested.

Reason

  1. 03

    A path with no callers is raised with a proposed category — dead, deactivated or extraneous — not deleted.

  2. 04

    A bug is found mid-restructure, and whether it was buggy does not matter, so it is raised separately.

  3. 05

    A behaviour is observable and never promised, and it goes on the list, because the edge is found by breaking it.

Decide

  1. 06

    A transformation runs, and the engine that performed it is named, because engines ship bugs of their own.

  2. 07

    A run touches many files at once, and FDA asks whether that is a significant software re-write.

Out

  1. 08

    A behaviour resists enumeration, and that is recorded as a limit of the check rather than as a pass.

  2. 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

  1. 1Module and history receivedRepository, call graph, runtime traces, test suite and the change history behind the module
  2. 2Preserved behaviours enumeratedThe observables the module shows now, its callers, the paths believed unreachable and what no test asserts
  3. 3Restructure draftedThe diff, the enumerated list, what the check could not cover and confidence
  4. 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

  1. 6Repository and tracker updatedOnly where write access and change policy allow it
  2. 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 required

8 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 boundary

    Agent 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 module

Illustrative example
Module
Order-routing module
Behaviour at issue
A caller on a path with no live route was not replayed
Checked against
The enumerated list
Evidence of record
Production traces
Confidence
81%
Held for
The named reviewer, by name

As received

Taken from the module as it runs and the traces behind it — nothing here is assumed preserved.

What the record holds

  • Production traces
  • Caller inventory
  • Unused-path register

Why this is held

The reachable callers pass; one sits on a path nothing exercises.

What the score decides

Below the configured threshold a change picks up an owner read before the reviewer sees it.

Action

MergeAmendSend to owner review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each restructure

From 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.

04

Build 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.

  • Repositories and forges

    • GitHub
    • GitLab
    • Bitbucket
    • Azure DevOps
    • Gerrit
    • Perforce

  • Refactoring engines

    • Eclipse JDT
    • IntelliJ IDEA
    • NetBeans
    • OpenRewrite
    • Rope

  • Code quality and analysis

    • SonarQube
    • CodeScene
    • Semgrep
    • CodeQL
    • coverage and mutation tools

Agent

Tech-debt refactoring

  • Reads the module
  • Drafts the restructure
  • Holds for the reviewer

  • Trackers and change records

    • Jira
    • Linear
    • Azure Boards
    • ServiceNow
    • Polarion
    • Jama Connect

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six clamps between the model and the mainline

Six clamps around one beam, the last the tightest. What holds is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to enumeration and reporting when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, transformation-rule and engine-version changes.Track
L4TraceabilityRecord the enumerated list, the diff, what went unchecked and the merge time.Record
L3Reviewer acceptanceHold the change for the named reviewer; the hold governs the merge, not whether behaviour held.Gate
L2Change guardrailsTest each change against its enumerated list; a difference left unexplained returns it.Restrict
L1Confidence thresholdsRoute low-confidence changes to a codebase-owner read before the reviewer sees them.Require review
Model coreRestructure drafted — the diff, the enumerated list, what went unchecked and confidence
L1 – L2
Test whether a change may stand
L3
Leaves the merge to a named reviewer
L4 – L5
Keep the restructure and the baseline behind it
L6
Leaves the structure alone when signals degrade

How Nestack evaluates it

Evaluate the whole restructure — not only the diff that comes out of it.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the code the mainline now carries

  1. E1Final-output evaluationDid the change hold the behaviours its own list named?
  2. E2Step-level evaluationDid the agent read the live module, its callers and the traces behind them?
  3. E3Tool evaluationDid it read and write the correct module and the correct paths?
  4. E4Confidence calibrationDo low-confidence changes actually attract more reviewer amendments?
  5. E5Slice evaluationHow does performance change across specific module classes?
  6. E6Business outcomeHow many changes needed an amendment before the reviewer merged?

Floor — the behaviour the module actually had

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed where the restructure first shows it.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • RZ-03

      Caller inventory incomplete

      A dependent nobody knew about is missed.

    Stage gathers

    The module, its callers, the traces and the suite

  2. 02 · Reasoning

    2 modes

    • RZ-04

      Corrected while restructuring

      A bug is fixed inside a no-change diff.

    • RZ-06

      Unused code called dead

      A path is deleted without being categorised.

    Stage proposes

    The diff, the list and what went unchecked

  3. 03 · Tool / write

    2 modes

    • RZ-02

      Merged without a person

      Agent completes a merge that needed a reviewer.

    • RZ-05

      Engine transformation wrong

      A tested engine returns an altered program.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • RZ-01

      Merged, list unrecorded

      The record shows a merge but not what was checked.

    Stage returns

    The code the mainline carries into tomorrow

  5. 05 · Change / Version

    1 mode

    • RZ-07

      Silent scope creep

      Small changes accumulate into a re-write.

    Stage tracks

    Model, prompt, rewrite rules and engine versions

  • Sev-1 · a merge made outside the boundary
  • Sev-2 · a preserved behaviour moved anyway
  • Sev-3 · coverage drops, change goes to review
See the complete Engineering failure-mode catalogue

Affected slices

Unreachable paths absorb the amendments

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Paths believed unreachable6.1%3.7×Review
Interfaces other teams read4.3%2.6×Review
Timing-sensitive code2.7%1.6×Watch
Well-covered internal modules1.3%0.8×Normal

Bar: reviewer-amendment-rate lift vs. well-covered-module baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Amendment rate rises in one module class.

  2. 02

    Diagnose

    The diff that says no functional change, over behaviour nobody has ever written down, is worked backwards until one cause is left standing.

  3. 03

    Improve

    Numbered the change ships, and the restructures behind it travel attached.

  4. 04

    Verify

    Each touched behaviour case is run again, and one red holds it back.

  5. 05

    Learn

    The case is kept, and the restructuring rules change in that same commit.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Refactoring discovery and automation-boundary scope.Week 1
  2. 02Repository and engine assessment.Week 1, Week 2
  3. 03Preserved-behaviour and unused-code categorisation.Week 1, Week 2
  4. 04Module ingestion.Week 2
  5. 05Enumeration and preservation logic.Week 2, Week 3
  6. 06Confidence scoring and review routing.Week 3
  7. 07Reviewer acceptance workflow.Week 3, Week 4
  8. 08Repository and engine integration.Week 5
  9. 09Preservation and scope cases.Week 4, Week 5
  10. 10Guardrails and transformation controls.Week 4
  11. 11Restructure-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 price
Confirmed after discovery based on integrations, workflow complexity, codebase size, approval controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your modules and what each one still does

    Behaviour enumeration and list versioning

    Week 1

  2. 02Representative production traces and callers

    Enumeration baseline, engine binding and the preservation suite

    Week 2

  3. 03Your change-classification and merge policy

    Preserved-behaviour and unused-code categorisation

    Week 1

  4. 04Access to relevant repositories, engines or exports

    Repository and engine assessment, then integration setup

    Week 2

  5. 05Restructures you would not want inspected

    Preservation cases and the evaluation round

    Week 4

  6. 06What no restructure may remove

    Confidence scoring, review routing, guardrails and acceptance controls

    Week 3

  7. 07A named reviewer to take the changes

    Reviewer acceptance workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Refactoring workflow discovery, behaviour enumeration and the automation boundary

W2Repository and engine integration and the enumeration baseline

W3Restructuring workflow, confidence logic and acceptance controls

W4Evaluation suite, preservation cases and failure-mode testing

W5Repository integration, pilot modules and targeted corrections

W6One engineering cycle run under the codebase owner, then Agent Care handover

Reading the band
A bar spans the weeks its own work is named in, and the week five overlap is real.
At the end of W6
Once the behaviour record validates, Agent Care picks the agent up.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your repositories
Named reviewer
Behaviour first
After launch
Agent Care available

Nestack Agents · Tech-debt refactoring

AGT-ENG-12 · Agent Care available after launch

Build a refactoring agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your codebase

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.