How mandatory AI usage metrics in companies reduce developers' motivation

A developer from a major Russian fintech described the downside of the corporate race to implement AI: mandatory KPIs for AI usage may not accelerate work, but rather undermine team motivation. His thesis is simple: when an engineer is evaluated by the share of code generated, the tool begins to compete not with routine, but with a sense of professional value.

Where the Conflict Comes From

In many teams, AI code assistants have already ceased to be an experiment and entered the everyday workflow. Along with them came coverage metrics, usage dashboards, and the expectation that a developer should regularly show the "correct" percentage of tasks completed with AI assistance. For management, the logic is clear: licenses cost money, implementation needs to be measured somehow, and numbers in reports look convincing. But in such a model, the focus shifts from the result to the mere fact of using the tool.

The problem, according to the author, is not in AI as such, but in its mandatory nature. For many developers, the main driver is not abstract "efficiency," but a sense of authorship: I figured it out myself, I found the bug myself, I brought the code to a working state myself. When a requirement comes from above to use generation in almost every task, even a convenient tool begins to be perceived as external control. At this point, AI stops being a tool of choice and becomes part of corporate policy.

When AI Gets in the Way

The article provides a specific work example: there was a need to quickly assemble a simple CDC scenario implementation where one service writes data to a database and sends it to Kafka, while another reads the message and saves it to another database. For an experienced engineer, this is a familiar, short task that can be completed manually in about ten minutes while the entire context is still held in mind. But in order to comply with KPIs, the author decided to perform it entirely through AI.

In practice, this turned out to be slower. Instead of direct work, he had to formulate a prompt, wait for generation, check whether the model made up anything extra, verify the logic, and read through code he didn't write himself. As a result, the task took two to three times longer.

And this is an important counterargument to the popular idea that using AI automatically equals increased productivity. On familiar tasks, the overhead of formulating and verifying can eat up all the gains.

• Job satisfaction decreases because the result exists, but there's no feeling of "I did this"
• Speed is lost if time goes to prompts, re-verification, and understanding someone else's code
• Understanding of context weakens when part of the thinking is delegated to the model
• Anxiety returns about your own skills and professional form

Loss of Authorship

The strongest thesis of the text is not about speed, but about the internal state of the developer. If a simple task is closed, but done mostly by the machine, a person may not get the usual feeling of completed work. For those who came into the profession not just for a salary, this is a painful substitution. Development from a craft and creative work begins to turn into supervision of a "black box," and the engineer becomes an operator who accepts or rejects the proposed option.

"I write complex architecture myself, I delegate routine"

From this comes the connection with impostor syndrome. If the Internet goes down and LLM access disappears, can I solve the same task myself? If I increasingly rely on generation, won't the skills I'm actually paid for begin to degrade? This fear is especially acute for strong specialists whose professional identity is built on self-reliance and deep understanding of the system. And it's precisely such people who often shoulder complex releases, critical services, and engineering culture quality.

What This Means

The story well illustrates the limits of AI implementation metrics. It's useful to measure not the share of generated code, but where the tool actually saves time: in template DTOs, tests, drafts, documentation, and other routine. As soon as the KPI begins to deprive the developer of the right to choose, the company risks getting a nice dashboard, but a slower team, lower engagement, and a new cycle of burnout.