Agents extracting business rules from code: arXiv 2609.22719

What happened on 2026-09-19

At 03:08 UTC on 2026-09-19, Garima Agrawal and co-authors submitted v1 of 'From Code to Requirements: Agentic Reverse Engineering of Business Rules at Enterprise Scale' (arXiv 2609.22719), with cs.SE as the primary category. The setting is legitimate modernization. Enterprise software often lacks structured requirements because its logic lives in code, configuration and staff knowledge. The authors describe a framework of seven specialized agents that identify user journeys, extract business rules from code, tests, configuration and existing documentation, and produce Business Requirements Documents. The agents use static analysis tools, and human reviewers step in at defined escalation points. The abstract reports that, on execution traces from a real enterprise deployment, each service's document took under nine minutes. The extracted rules were checked independently against real production defect records. Measured against a baseline built from repository metrics, IFPUG complexity models and industry labor rates, cost fell by more than 98%; a comparable earlier migration had taken over two years.

What it means for assessing cloning risk

In an app-cloning threat model, the expensive step is usually not copying the UI. It is working out what the rules actually are: how prices are computed, which conditions trigger risk controls, which features sit behind entitlements. This paper shows that, given source code, tests and configuration, a multi-agent pipeline can compress that step to minutes. The honest caveat is that the setting is an internal migration with full access. It does not evaluate an outside party who only holds a shipped binary or front-end bundle, so it does not prove a cloner could achieve the same results. It does show where defenders should look. Rule tables, feature flags, JSON configuration, test fixtures and comments that ship with the client are exactly the material such pipelines exploit most easily, because they are already semi-structured requirements.

Checks to run on your own release artifacts

First, check release packages and front-end output for test files, sample data, source maps, rule tables and annotated configuration files. Remove what can be removed, and move to the server what can be moved. Second, separate rules from presentation. The client should receive results, not the formulas and thresholds that produce them; where needed, the server can send back pre-trimmed results. Third, review code comments and log strings so release builds do not keep text that describes business logic. Fourth, set access boundaries for your own internal AI agents too. Keep a clear record of which repositories, configuration and documents they may read, and whether any of that content is sent to an external service.

Your checklist

• Strip test files, source maps, rule tables and annotated configs from releases
• Send results to the client and keep rules and thresholds on the server
• Document which repositories and docs internal AI agents may read