How to Bring GenAI into Operational Work

Artem started as an engineer at Parallels, a maker of virtual machines, and as Head of NLP at the bank found he had spent three years on everything but training models: processes, product discovery, the business itself. Alexander frames the question of the episode: why did the most intellectual profession get automated first, while the work of an operator with a script held out? There is no paradox, Artem replies. Ten or fifteen years ago engineers dealt with paging and registers, and then spent decades making sure they would never touch that again: runtimes, dynamic memory management, interpreted languages. He now writes only in Python, the language he once laughed at as a beginner. A model learns from signal, and around code we assembled a whole machine of signals: the compiler punishes broken syntax, linters catch the level above, tests catch logic errors. Alexander recalls a talk by Jensen Huang: after the convolutional revolution a perfect approximator of any function existed, leaving only which function to approximate and where to find the data.

The counter-example is a salesperson. Someone dials a number and a whole apparatus of reading emotions and adapting switches on, yet no unit test exists for a call. The base of prospects is finite, recordings are frozen in time, and you cannot go back and phrase it differently; Alexander adds that exactly one trace happened and no counterfactual data exists. Artem agrees: spend the base on one gradient pass and nobody is left to call, because people block the number. Simulation helps only partly, in self-driving cars, so what remains is to split work into atomic steps with a predictable input and output — Alexander recalls Adam Smith and his pins. Rewards get decomposed into proxies too: nobody knows what a good sale is, but in good sales people say hello and do not swear at each other. Where an environment with an automatic reward can be built, everything works: Alexander cites AlphaEvolve, which rewrites code by evolutionary search for optimisation problems such as scheduling resources, and notes that Google still runs the Borg orchestrator internally.

Artem turned to support right after ChatGPT appeared: he put the rules of an invented restaurant into a prompt, fired questions at it for a long time, and saw that a prompt and manual tweaking delivered what used to require dialogue trees and a model trained on hundreds of examples. He expected to close the problem in a year — and has never in his life been so wrong. An experiment sobered him up: experienced staff of one small support area wrote down how they serve customers, and a model was then asked, against the real flow of tickets, to point at the clause each operator relied on. About 20% of cases could be found, and strong people had written that document. Sometimes there is nothing to distil: instead of a process there is judgment — how do you extract from a CTO what good architecture is, when the signal takes years? Alexander adds that any quality metric is easy to game, recalling Vlad Khononov's example of a star-shaped component split in two: the diagram improves while the link carries the same volume.

Then quality control begins. With people it rests on fear: a separate vertical reviews a sample, and anyone whose dialogue may land there tracks product and procedure changes unprompted. A model cannot do that — it was trained never to decline a task: a hit scores plus one, a miss minus one, there is no middle option, and, as in a multiple-choice exam, guessing pays. Where a person would hesitate, the model ploughs ahead. Checking it needs a reference standard of service for the specific case, and none exists: procedures in large support organisations are written for convenience at runtime and stay shallow. Economics, Artem says, is a third-order question, although engineers like to start there. Hardest is the organisation: thousands of people must work differently, and even at T-Bank not everyone was ready — and it is not the operators who are afraid but those who built the old system. Hence his advice: a model cannot be slotted into an existing process, so take responsibility for a vertical slice all the way to the customer outcome.

Artem likes accounting as a mix of classical and generative engineering: income minus expenses and the rate go calmly into code, quirks of payroll, value-added tax and headcount-dependent rates included. The intellectual part sits elsewhere — working out, transaction by transaction, what it was and which contract it belongs to, when statements arrive from two banks as PDFs and XML and some payments came in cash outside the till. So the case calls for a carefully designed workflow rather than an agent. Interpretation stays contested: two accountants hold three opinions on which documents confirm an entry, and the tax code has grey zones. Alexander objects to one fixed internal answer for such a zone: what is permitted to Jupiter is not permitted to the ox, and a standard practice may expose a client. Artem answers with risk analysis: a warning comes first, paying the fine is sometimes cheaper, and ordinary accountants make mistakes too.

In marketing the bottleneck was not the copy but the ping-pong of approvals: a product manager writes positioning and slogans, then waits days for the content editors — so the editors were proxied by a model that brings the rules straight to the author. Part of the gain arrived with no generative technology at all, as with the Yandex team that switched off expensive labelling nobody had looked at for a long time. The last case Artem heard in a sauna from a friend whose company builds industrial facilities: we have adopted GenAI and it designs our buildings. The trick was the goal — not to generate a building but to find points of saving: the model sketches variants of a fragment, and a designer who has worked the same way for ten years takes them as references. Alexander adds that structural strength is still computed by classical means, and external verification puts the task back into an engineering frame. The resulting screen: name the goal, estimate the end-to-end effect under a perfect outcome, ask how quality is measured today, and check whether control will cost more than the saving.