The Known and Costly Problem of Rework
BLUF: Rework is one of the most expensive failure modes in mission-critical software development. It is preventable. So how come it impacts so many projects? This paper defines what rework is, where it comes from, and shows how the cost of rework escalates the longer it goes unaddressed, then lays out how to fix it.
This white paper defines rework, traces its root causes and escalating costs, then provides a solution. No software program budgets for rework. Every software program pays for it anyway. Code gets rewritten. Designs get scrapped. Features get rebuilt after stakeholders discover the delivered product does not match the intended need. These happen at the worst possible moment in the schedule during testing, deployment, or in production. In mission-critical applications, where budgets and operational outcomes carry real consequences, rework is a direct threat to delivery. This paper walks through those causes, the compounding cost of late correction, and a specification-first approach that attacks the problem at the source.
Where rework comes from
In mission-critical development, rework kills momentum. It's what happens when code or designs get torn down and rebuilt after the work has started. This can be weeks into a project after the scope and timeline have already been established. This is not an accident either. A handful of cases can show up repeatedly.
Most of the time it traces back to requirements no one bothered to nail down. Vague goals invite scope creep into a project. Scope creep can invite the kind of last-minute change that costs real money if caught later in the standard development lifecycle (SDLC). Then there is the gap between different teams who might be working on a project together. If communication isn't strong enough then small misunderstandings can quietly turn into architectural problems that no one notices until they are too costly or pushes deadlines. Adding a tool that does not integrate cleanly with the rest of the stack or not providing a team context for that tool from day one then friction will be added to slow project velocity.
Total understanding of the stack, the tooling, context, and structure is required for a team to operate at peak efficiency. Any disruption to the development process can also cause errors to slip in unless these gaps are closed for the team. Equipping teams with the right tools and coherent understanding of their goals is vital.
The bottom line: skip quality control early on, skip the groundwork as part of the process of software development, and rework will be inevitable.
What rework costs projects
Naming the root causes is the easy part. The downstream effects are where the damage shows, and the Government Accountability Office has documented these effects across both federal and commercial sectors (U.S. Government Accountability Office, 2023):
- Delivery. Rewriting code doubles the work, stalls agile processes, and slips deadlines.
- Morale. Developers discard code while analysts chase missing requirements and program managers run damage control. The cycle burns out entire teams.
- Quality. Rework executed under deadline pressure bypasses thorough testing, so the fix itself introduces new bugs and deepens the technical debt the fix was supposed to reduce.
- Budget. The cost of correcting an error rises sharply the later the error is discovered. Dismantling established code carries hidden costs in labor, time, and risk that push final products over budget (Consortium for Information & Software Quality, 2022; Tassey, 2002).
Rework is common. Rework is not inevitable. Clear requirements established before development begins remove the conditions that produce rework in the first place.
The Solution: Alchemist AI Pro™
Alchemist AI Pro™ is a requirements and specifications engine built for exactly this problem. The platform supports business analysts, subject matter experts, and full teams through an eight-stage process grounded in proven requirements-engineering methods. A human analyst stays in the loop at every stage.
The export stage tailors output to the audience:
- Developers receive AI-readable and human-readable specifications with a buildable package.
- Program managers receive use cases, specifications, test scripts, and JIRA-ready exports.
- Analysts can pull deep-dive packages covering market research, competitive landscape, and pricing.
- Every stakeholder gets a complete and readable requirements document in PDF.
The result is a requirements package with fewer gaps and a stronger baseline, produced in a fraction of the time human teams need alone. The work is still getting done but gets done earlier in the SDLC where corrections are the cheapest.
Structured collaboration, not prompt engineering
Generative AI has already reshaped requirements writing and can have positive outcomes, but as time passes using LLMs feels more like a dice roll rather than a sure bet. Treating AI as a magic black box is a fundamental mistake in requirements engineering. The evidence for this problem is mounting.
In a 2025 industry study, LLMs were found to be causing challenges for requirements engineers (Murali Rani et al., 2025):
- 61.9% with interpretability
- 52.4% with reproducibility
- 47.6% with controllability
This non-determinism is a foundational problem for any engineering discipline.
An empirical study published in ACM "Transactions on Software Engineering and Methodology" found that the non-determinism of LLM models can be severe. Researchers ran three benchmark tests. They found that more than half of the time an AI could not even produce the same results consistently. Even lowering the temperature to zero in order to freeze the answer and drive consistent behavior did not yield strong results. Among the top 5 responses some answers remained wrong and even the correct answers failed to match each other (Ouyang et al., 2025).
Unstructured AI output creates a second cost: manual verification. Research shows that 81.2% of practitioners manually check and approve AI suggestions and 71.9% frequently correct or override AI-generated requirements (Murali Rani et al., 2025).
Organizations are doing homework that AIs were meant to eliminate.
Figure 1. Share of practitioners reporting model-unpredictability challenges (interpretability, reproducibility, controllability) versus the manual-verification burden those gaps create, per Murali Rani et al. (2025).
Alchemist AI Pro™ answers both problems by pairing AI with structure.
Alchemist AI Pro™ does not accept a prompt and a stack of documents and hand back an answer. The platform guides the AI and the human together through established requirements-engineering practice. Industry research identifies human-in-the-loop collaboration as essential for incorporating AI into existing workflows (Murali Rani et al., 2025). Alchemist AI Pro™ makes that collaboration the default rather than an afterthought, which keeps requirements compilation controlled and every decision traceable.
Automated auditing to end the homework. Alchemist AI Pro™ employs a multi-model design in which a secondary AI model, distinct from the first, audits the initial output. AI performs strongly on quality-assurance tasks: cross-referencing requirements, flagging conflicts, identifying ambiguities, checking regulatory compliance (Murali Rani et al., 2025). Delegating validation to an independent auditing model cuts the manual review burden on engineers while preserving human authority over every accepted change.
Structure and process close that gap between non-deterministic AI and disciplined requirements engineering. That unpredictable text generator, given those tools, now holds up under an audit: traceable, repeatable, with no guesswork.
Alchemist AI Pro™ is Tradewinds Awardable
Alchemist AI Pro™ has been assessed as "Awardable" through the Chief Digital and Artificial Intelligence Office (CDAO) Tradewinds Solutions Marketplace. CDAO describes the marketplace as a repository of post-competition, readily awardable pitch videos addressing government challenges in AI/ML, digital, and data analytics (Chief Digital and Artificial Intelligence Office, n.d.).
For Department of Defense stakeholders, this status matters because Tradewinds is designed to accelerate access to AI, machine learning, digital, and data analytics solutions.
Expected outcomes
Figure 2. Two paths to delivery. In the traditional path, requirements gaps surface during testing and force work back into development. A specification-first approach resolves requirements before development begins, in the phase where correction is cheapest.
Organizations adopting a specification-first approach with Alchemist AI Pro™ can expect:
- Fewer defects reaching development. Ambiguities, conflicts, and gaps get resolved before a line of code is written.
- Lower total cost, since errors surface in the phase where correction is least expensive.
- Faster delivery. Development teams build from implementation-ready specifications instead of rediscovering intent mid-sprint.
- Stronger traceability, with every requirement carrying a documented lineage from capture through export.
- Preserved institutional knowledge. Captured expertise becomes a durable organizational asset rather than knowledge that leaves when an employee does.
ACC3 International recommends a focused demonstration with your team or designated staff representatives. Contact ACC3 International to schedule a demonstration of Alchemist AI Pro™ and assess how a specification-first approach can eliminate rework before development begins.
References
Chief Digital and Artificial Intelligence Office. (n.d.). Tradewinds Solutions Marketplace. https://www.ai.mil/Industry/Tradewinds
Consortium for Information and Software Quality. (2022). The cost of poor software quality in the US: A 2022 report. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
Murali Rani, L., Berntsson Svensson, R., & Feldt, R. (2025). AI for requirements engineering: Industry adoption and practitioner perspectives (arXiv:2511.01324). arXiv. https://doi.org/10.48550/arXiv.2511.01324
Ouyang, S., Zhang, J. M., Harman, M., & Wang, M. (2025). An empirical study of the non-determinism of ChatGPT in code generation. ACM Transactions on Software Engineering and Methodology, 34(2), Article 42. https://doi.org/10.1145/3697010
Tassey, G. (2002). The economic impacts of inadequate infrastructure for software testing (Planning Report 02-3). National Institute of Standards and Technology. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf
U.S. Government Accountability Office. (2023). Defense software acquisitions: Changes to requirements, oversight, and tools needed for weapon programs (GAO-23-105867). https://www.gao.gov/products/gao-23-105867
