Egor Shlyupikov, a senior business analyst at YADRO, described on Habr how his team built an LLM-powered reporting service. The team manages a fleet of IT hardware and components: what to buy, what's sitting idle, what's under repair or disposal, plus financial analytics. Every morning, the service releases more than a dozen reports with neural-network takeaways without any human involvement. Not a single number in the report comes from the model — everything is computed by code, and the LLM only writes the text.
It all started in April with a task on stock levels at a single warehouse and the aged metric — the share of assets sitting around for over a year or two. The analyst exported data from Naumen.ITAM, stripped out legal entities and warehouse names, and handed it to a neural network with a prompt to assemble an HTML report. Next came the Dify low-code platform inside the company's perimeter and a knowledge base with process descriptions and metric explanations.
In the summaries, the model started moving numbers into the text on its own, and one day the comments contained figures from the day the knowledge base was connected — instead of current ones. From that point on, the separation became strict: charts are built by a linear algorithm, and the LLM generates comments without numbers. The script prepares two datasets — a full one for the template and a compressed one with a few dozen key figures for the model. Instead of values, the text contains labels, and the numbers are inserted at report assembly time using the same rules as in the template.
The temptation to let an LLM loose on corporate reporting is huge: writing dashboard explanations is boring and eats up a lot of time. The YADRO case shows a typical evolution — first "feed it an export and ask for HTML," then you hit context limits and hallucinations, and you end up with a strict scheme. Our assessment: the main takeaway here isn't about the model but about architecture — generative text and arithmetic should live in separate processes, otherwise figures from yesterday's report resurface in today's.
What this changes: a ready-made template emerges that's easy to copy — code computes, the model comments, labels instead of numbers. For the analyst, that means less routine, but also fewer reasons to open Superset for every question. In our experience, the savings on "make one more dashboard" will prove more significant than the savings on tokens, because an analyst's time gets cheaper more slowly than inference does.
Who wins — vendors of low-code AI platforms like Dify, although in this particular case the platform had to be wrapped with external tooling. It looks like the losers are sellers of "AI analytics" as a BI replacement: the case shows the BI layer hasn't gone anywhere — it became the foundation. And there's another win — trust: a report where the model physically cannot fudge a number sells easier inside a company than a smart chat.
No numbers: how many hours the service saves, which exact models run in the perimeter, what a single run costs, how large the hardware fleet is. There's a single source — a corporate blog, where the author has an interest in showing off the result. He promises to cover Trino and cases where the needed data simply isn't in the accounting system in the full article, but these details aren't visible in the available excerpt. The one thing readers should verify: whether placeholder labels truly rule out number substitution — or whether the template is still assembled by code that also requires testing.
Prediction: within six months, at least one public case from another major company will appear using the same "code computes — model comments" scheme. It can be checked via corporate blogs and conference talks; it will come true if companies keep publishing internal AI cases just as willingly.
Disclaimer: a single source — a corporate blog, no independent confirmation.
Source: habr.com · post in Telegram