The article Why We Can't Decide Every Time a Refactoring Proposal Arrives generated significant discussion on Zenn. Today, AI coding agents can instantly output countless refactoring proposals. However, what teams are experiencing on the ground is a new form of stagnation: "Proposals keep coming, but we cannot judge whether to accept them, whether to prioritize them, or whether they will break things right now." The fundamental problem has shifted from "can we fix it?" to "can we determine what to fix, why, and whether it should be fixed right now?"
This is particularly critical on the maintenance frontlines of custom development. Teams easily fall into a dilemma between "blindly accepting AI proposals and breaking working code" and "deferring every proposal due to an inability to evaluate them, causing debt to accumulate." When supporting system maintenance through custom development, we view this as a design challenge: not merely asking "should we refactor?" but designing a system to evaluate based on value and risk, make improvements safely and accountably, and deliver code seamlessly integrated into operations. Connecting this with the design improvement decision-making in Custom Soft Delete / State Table DB Redesign Development (GH Media), the safety nets to prevent regressions in Custom Test Automation Adoption Support Development (GH Media), and the AI deliverable verification in Custom Deliverable QA Development Learned from EY's AI Hallucination Report (GH Media), this article organizes "refactoring decision-making and technical debt governance support" as a custom development package.
Why refactoring "decision-making" "now"?
| Dimension | Proposal-based (traditional) | Decision-based (2026) |
|---|---|---|
| Trigger | Fixing when noticed | Mass proposals from AI |
| Bottleneck | Hands to write fixes | Criteria to decide |
| Adoption | Based on intuition | Based on value and risk |
| Prioritization | Loudest voice | Based on impact |
| Safety | Hope and prayers | Guaranteed by tests |
| Deliverable | Ad hoc improvements | Explainable improvements |
In short, "being able to fix" and "being able to decide" are completely different things, and in custom development, "evaluating adoption based on value and risk, making non-breaking and explainable improvements, and handing them over embedded into operations" has become a prerequisite for quality. This enables us to guarantee "decisive, non-breaking, and justifiable improvements" as tangible deliverables.
Three structural changes beneficial to custom development projects
Structure 1: From "hands to write fixes" to "criteria to decide"
As long as AI supplies the execution power, decision-making is the scarce resource. In custom development, we establish criteria for evaluating value, risk, and cost so teams can decide whether to adopt suggestions without hesitation.
Structure 2: From "intuitive adoption" to "value and risk"
Adoption based on personal preference is not reproducible. In custom development, we provide explainable adoption decisions based on evaluations of impact, regression risk, and maintainability.
Structure 3: From "hope-based changes" to "guaranteed by tests"
Modifications without tests invite disaster. In custom development, we deliver non-breaking improvements backed by tests serving as safety nets and phased rollouts.
The 5 phases of "Refactoring Decision-Making and Tech Debt Governance Support" provided for clients
Phase 1: Current state audit (1 week)
- Auditing and visualizing technical debt
- Identifying high-churn / fragile areas
- Checking existing tests and safety nets
- Interviewing teams on AI suggestion workflows
Phase 2: Decision criteria design (1 week)
- Defining evaluation criteria for value, risk, and cost
- Establishing rules for adoption and prioritization
- Criteria for "fix now / fix later / do not fix"
- Designing review workflows for AI suggestions
Phase 3: Safety net implementation (1–2 weeks)
- Building tests around high-risk areas
- Designing phased refactoring procedures
- Mandating decision criteria in code reviews
Phase 4: Executing improvements (2–3 weeks)
- Incrementally improving high-priority technical debt
- Applying each change in small increments backed by tests
- Documenting rationales for decisions (why it was fixed)
Phase 5: Ongoing operations (continuous)
- Periodic audits of technical debt
- Reviewing and refining decision criteria
- Institutionalizing review practices for new suggestions
Standard set of decision criteria for client development
| Evaluation axis | Evaluation point | Impact on decisions |
|---|---|---|
| Value | Contribution to bug reduction / development velocity | Higher gets higher priority |
| Regression risk | Blast radius / test coverage | Higher requires more caution |
| Frequency | Frequency of changes to that section | Higher gets higher priority |
| Cost | Modification man-hours | Larger requires splitting |
| Reversibility | Can it be rolled back? | Lower requires more caution |
| Explainability | Can the rationale be demonstrated? | Required |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Overwhelmed by AI suggestions and unsure how to decide | Hardly using suggestions |
| Technical debt is piling up | New project with little debt |
| Constant anxiety about breaking things during updates | Sufficient test coverage exists |
| Core systems requiring long-term maintenance | Short-lived evaluation environments |
| Wanting to explain the rationale behind improvements | Low accountability requirements |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Areas to improve | Agreement on priorities |
| Decision criteria | Rules for adoption / prioritization | Agreement on evaluation axes |
| Safety | Testing / phased rollouts | Non-breaking prerequisite |
| Documentation | How to preserve decision rationales | Accountability |
| Handover | Decision criteria / runbooks | Premise of in-house operation |
| Ongoing maintenance | Periodic audits | Operating costs |
Client ROI estimate (assuming enterprise system maintenance)
| Item | Existing (unable to decide) | Decision governance | Difference |
|---|---|---|---|
| Handling suggestions | Blind adoption or total rejection | Screening by value | Eliminating wasteful modifications |
| Modification incidents | Breakages cause outages | Prevented by tests | Reduction in incident response |
| Technical debt | Accumulates | Paid down systematically | Maintaining development velocity |
| Accountability | Ambiguous rationale | Explained through documentation | Increased client trust |
| Annual benefit | — | — | Reduction of wasteful modifications + prevention of modification incidents |
Even if a substantial investment is required, it can be fully justified by avoiding a single outage caused by blindly accepted changes and reducing wasted modification hours.
Five common pitfalls
Pitfall 1: Blindly adopting AI suggestions
It breaks working code. Judge based on value and risk.
Pitfall 2: Rejecting everything out of indecision
Technical debt accumulates. Screen using decision criteria.
Pitfall 3: Improving without tests
It causes incidents. Establish safety nets first.
Pitfall 4: Making massive changes all at once
Reversibility is lost. Apply changes in small, incremental steps.
Pitfall 5: Failing to document decision rationales
You will not be able to explain them later. Record why fixes were made.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Debt inventory + identifying critical risk areas |
| Week 2 | Designing decision criteria + adoption rules |
| Week 3〜4 | Establishing safety nets for high-risk areas |
| Week 5〜7 | Phased improvement of priority debt |
| Week 8〜13 | Periodic audits + establishing routine reviews |
Summary — From "an era where we can fix" to "evaluating, preserving stability, explaining, and handing over"
In an era where AI generates endless proposals, the scarce resource is not "hands to write fixes," but "criteria to make decisions." When supporting system maintenance in custom development, evaluating adoption by value and risk, preventing breakages with safety nets, and handing over documented rationales through "Refactoring Decision-Making and Tech Debt Governance Support" serves as our new core offering delivering decisive, non-breaking, and explainable improvements as deliverables.
If you are facing challenges like "unsure whether to accept AI suggestions," "technical debt is piling up," or "afraid of breaking things during modifications," feel free to contact us via our contact form.
Sources
- Why We Can't Make Decisions Every Time a Refactoring Suggestion Arrives (Zenn 2026-06-01)
- DB Redesign Client Services for Soft Deletes and Status Tables (GH Media)
- Support for Establishing Test Automation in Client Engagements (GH Media)
- Deliverable QA for Clients: Lessons from EY's AI Hallucination Report (GH Media)
- Deployment Acceleration and CI/CD Improvement Services for Clients (GH Media)
