Beyond Code Generation: Understanding the System Software Must Survive Inside

How Alchemist AI Pro™ Preserves Operational Context for Change and Sustainment

BLUF: AI can produce code quickly. Program leaders and delivery teams still need a durable record of why the system exists, which rules it enforces, what it connects to, and how a change will be verified. Alchemist AI Pro™ helps preserve that operational context as reviewable requirements and acceptance evidence before it disappears into implementation.

Audience: Federal and defense program leaders, product owners, sustainment decision-makers, and technical delivery leads responsible for long-lived software systems.

Purpose

Federal agencies report spending about 80 percent of their IT budgets operating and maintaining existing systems that support essential missions (U.S. Government Accountability Office [GAO], 2025). For the leaders responsible for those systems, the 2026 delivery question extends beyond how quickly teams can generate code. The larger challenge is whether a capability can be understood, changed, tested, and supported after the original developers and decisions are gone. The IEEE Software Engineering Body of Knowledge treats requirements, architecture, testing, operations, and maintenance as connected parts of software engineering, because each affects whether a system remains useful over time (IEEE Computer Society, 2024).

AI tools can help teams code faster, but writing code quickly does not mean a team actually understands how it works. Shen and Tamkin (2026) showed that developers who passively relied on AI ended up worse at understanding concepts, writing readable code, and debugging, while developers who actively engaged with the tool held onto that key knowledge. For maintenance teams, this difference is significant. Workflows have to be set up so that people are forced to check, question, and approve whatever the AI generates, ensuring the team genuinely understands the system it is taking over.

The Sustainment Problem Begins Before Code

Source code shows how a system works right now, but it almost never tells you who approved a feature, why a specific rule exists in the first place, or what proof you would need to safely change it. Research on how programmers understand code shows that a developer's mental model directly affects how well they perform tasks (Heinonen et al., 2023). A study looking at over 450 developers across 60 different teams found that higher-risk code changes usually needed extra reviews and testing to avoid breaking things (Shihab et al., 2012). As Figure 1 shows, missing context, complex system setups, and years of piled-up patches on older codebases only make this harder on teams.

Figure 1. A code-first approach erodes context, increases environmental fragility, and makes brownfield systems harder to sustain. Derived from Abbasi (2025), Yusuf (2022), and Uttamchandani (2026).

Consider a hypothetical aircraft-maintenance scheduling rule that shows the practical effect. Adjusting an inspection interval may influence work-order generation, supervisor approval, parts forecasting, compliance reporting, and data exchanged with another system. The calculation is visible in the implementation. Sustainment also requires the authority behind the interval, its approved exceptions, the affected interfaces, and evidence that confirms the revised behavior.

Table 1. The Information a Sustainment Team Needs Beyond the Current Implementation

Questions that must remain answerable	What code may reveal	What the organization must preserve
Why does this behavior exist?	Current logic and comments	Mission outcome, policy source, stakeholder decision, and rationale
What else depends on it?	Direct calls, imports, and schemas	Users, data flows, interfaces, permissions, reports, and external obligations
What counts as an acceptable change?	Existing tests and validation routines	Approval authority, constraints, acceptance criteria, and edge cases
What is still uncertain?	TODOs, incomplete branches, or informal notes	Assumptions, disputed rules, missing evidence, and unresolved risks

What a System-Understanding Approach Preserves

To really understand a system, an organization needs documentation that stays linked together over time. A good record connects the initial goal to its specific requirement, the design choices made along the way, the test results, and the final approval. When the system needs to be updated later, having those links gives reviewers a practical way to see how one change will affect everything else.

Traceability is only useful if teams can maintain it without getting buried in paperwork. In a study on software maintenance, Tian et al. (2021) noted that tracking changes was the main reason teams used traceability, but they also pointed out how much time and effort it takes to build and keep up with those links. Finding that balance matters. Teams are far more likely to keep documentation up to date if it actually helps them answer daily questions like what changed, why it was changed, and what needs to be checked next.

Source material remains available. Unresolved ambiguity stays visible. Requirements connect to the evidence used to accept them, and reviewers decide which artifacts enter the approved baseline.

How Alchemist AI Pro™ Supports the Work

Alchemist AI Pro™ helps teams gather and organize the information needed to support that translation. It can work with existing documentation, legacy-system context, prior mission notes, stakeholder input, partially defined concepts, and operational lessons learned to produce concise, usable application requirements. Preyna's (2026) companion paper, The Lifecycle Evidence Boundary, adds the governance detail: approved sources and stakeholder clarifications remain linked to requirements and acceptance criteria, generated material stays provisional, and designated reviewers decide what enters the approved baseline. Figure 2 summarizes that intended workflow from source recovery through verification and later change. Because both papers are published by ACC3, they establish the method ACC3 intends to use. Measured pilot results would be needed to establish program outcomes.

Figure 2. An understanding-first workflow shifts effort from reading code for clues to maintaining a clearer record of system intent.

The platform organizes and connects evidence; accountable people determine what becomes authoritative. Engineers choose the implementation. Product owners and subject-matter experts approve the mission meaning, while test and assurance personnel decide whether the evidence is sufficient. Architecture, code review, testing, configuration management, and operational judgment remain part of delivery.

What Changes in Practice

The workflow is intended to give teams a clearer starting point for impact analysis and onboarding. When a requirement changes, reviewers can inspect related rules, interfaces, acceptance criteria, and tests before editing the system. New team members begin with approved context, then use the code to understand implementation detail.

Generated artifacts remain subject to source review and human approval. Modernization can proceed one workflow at a time, with current behavior and constraints documented before implementation changes begin.

A Focused Pilot

Start with a legacy workflow that changes frequently or has a history of rework. Tap into existing records and involve the people who understand how the operation actually runs day to day. From there, Alchemist AI Pro™ can organize the source material, flag conflicting information, and draft a candidate set of requirements and acceptance criteria for human review before implementation (Preyna, 2026).

The pilot in The Lifecycle Evidence Boundary targets a change containing at least one source conflict or local exception. Once implementation wraps up, bring in an objective reviewer from outside the original workstream to trace the entire path, from source material to requirements, code changes, test evidence, and final sign-off. Time how long this reconstruction takes, pinpoint where the chain of evidence breaks, and track whether missing or conflicting sources trigger downstream rework (Preyna, 2026).

Getting Started with ACC3

ACC3 recommends a working session around one current sustainment or modernization problem. Bring existing artifacts and one or two subject-matter experts. The session should identify available system knowledge, unresolved decisions, and the evidence needed for the next change. Contact ACC3 International to schedule a demonstration of Alchemist AI Pro™.

References

Abbasi, H. (2025, March 22). The promise and pitfalls of AI-assisted code generation: Balancing productivity, control, and risk. Medium. https://hammadulhaq.medium.com/the-promise-and-pitfalls-of-ai-assisted-code-generation-balancing-productivity-control-and-risk-80869176202f

Heinonen, A., Lehtelä, B., Hellas, A., & Fagerholm, F. (2023). Synthesizing research on programmers' mental models of programs, tasks and concepts: A systematic literature review. Information and Software Technology, 164, 107300. https://doi.org/10.1016/j.infsof.2023.107300

IEEE Computer Society. (2024). Guide to the software engineering body of knowledge (SWEBOK guide) (Version 4.0; H. Washizaki, Ed.). https://www.computer.org/education/bodies-of-knowledge/software-engineering

Preyna, D. (2026, July 25). The lifecycle evidence boundary. ACC3 International. https://acc3int.com/whitepapers/lifecycle-evidence-boundary

Shen, J. H., & Tamkin, A. (2026). How AI impacts skill formation. arXiv. https://doi.org/10.48550/arXiv.2601.20245

Shihab, E., Hassan, A. E., Adams, B., & Jiang, Z. M. (2012). An industrial study on the risk of software changes. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (Article 62, pp. 1-11). Association for Computing Machinery. https://doi.org/10.1145/2393596.2393670

Tian, F., Wang, T., Liang, P., Wang, C., Khan, A. A., & Babar, M. A. (2021). The impact of traceability on software maintenance and evolution: A mapping study. Journal of Software: Evolution and Process, 33(10), e2374. https://doi.org/10.1002/smr.2374

U.S. Government Accountability Office. (2025). Agencies need to plan for modernizing critical decades-old legacy systems (GAO-25-107795). https://www.gao.gov/products/gao-25-107795

Uttamchandani, S. (2026). Why your AI coding agents fail on brownfield projects (and how to fix it). LinkedIn. https://www.linkedin.com/pulse/why-your-ai-coding-agents-fail-brownfield-project-how-sandeep-sgv4c/

Yusuf, B. (2022). Software deterioration. In bulama.io. https://bulama.io/software-deterioration/