An AI Estimator Without AI: Rule-Based Code Found 310 Issues in Five Cost Estimates

The product is called "AI Estimator," but so far the neural network in it has not calculated a single ruble. A Moscow company that renovates and finishes apartments gave the developer five working estimates, and the system returned 310 findings on them. The most expensive catch: the total of one estimate is understated by 515,786 ₽. Rule-based code produced every finding. The author described the project on Habr.

What the system found

The runs took place from 16 to 21 August 2026. The author immediately adds a caveat about the biggest finding. He spotted the 515,786 ₽ understatement while surveying the estimates, before writing the technical specification, and only wrote the rule for it afterward. In his words, careful reading did the work here, not code.

Another figure is more interesting. During the survey, the author compiled a reference list of errors, and the system returned 51 confirmed findings that were not on that list. For a deterministic rule set, this is a telling result: the errors were first found by hand, then the rules reproduced them and caught some of what the human had missed.

Where the neural network fits in

The AI layer is written and covered by tests, but only against a stub. It has not been run on a live model, for two reasons: there is no access key, and the customer chooses the platform. The author has already handed over the working version, and it runs without internet access.

That last point deserves attention. The company's estimates stay inside its own perimeter, and the question of sending data to an external service does not arise for now. This is our conclusion; the author does not state it directly.

The author's second project is stricter still. It is a measurement configurator for a service that prepares drawings of custom glass shower enclosures, and it contains no neural network at all.

That said, a model did work on both projects, but at the development stage. It wrote code, parsed the customer's Excel files, and checked findings against rows in the estimates. The author lets it into the product itself only where it cannot be avoided.

The project in numbers

• 5 working estimates from a Moscow apartment renovation and finishing company
• 310 findings across the runs of 16–21 August 2026
• 515,786 ₽ — the largest understatement found in the total of a single estimate
• 51 confirmed findings beyond the reference list
• 0 findings from the neural network: rule-based code produces all of them
• The AI layer has been tested only against a stub

What you can take from this

The workflow is reproducible. First, survey the customer's real documents by hand and build a reference list of errors. Then write the rules and check them against that list. Bring in a model where a rule cannot be formulated. That way the customer gets a verifiable result, and token costs and data-leak risks appear only when there is a real need.

The limitations are also obvious. The sample is small: five estimates from one company. The figures come from the author himself, with no independent verification. There is no live model in the product yet, so it is impossible to compare a version with AI against one without. Once the customer picks a platform and the key arrives, the main question will be a different one: will the model find anything beyond the 310 findings, or will it add only false positives?