← All articles

Mikhail Polyakov

Developers and analysts working with AI: how their work differs and how to check the results

Level: BeginnerReading time: 12 min

Topics: AI, Systems analysis

Two workstations on a dark background: on the left a monitor with coloured bars of code and a green check mark, on the right sheets with a diagram of blocks and arrows and a magnifying glass; above them a glowing sphere with threads running to both workstations

Short answer: developers and analysts work with AI differently because their results are checked differently. Code can be run and put through tests. That does not prove it is correct, but the machine finds some of the errors on its own. So you can hand a developer's AI more work, up to whole tasks. Requirements, diagrams and conclusions drawn from data cannot be run like that. Individual points in them can be checked against a source or recalculated, but a missed scenario or a wrong business rule is looked for, before any code exists, by reading and asking questions. A person can ask those questions, and AI can suggest them too if you ask it to look for what could go wrong. If the gap goes unnoticed, it may surface later: during testing, in the working program or in a decision that has been made. So an analyst takes drafts, questions and cross-checks from the AI, and remains responsible for every statement. For a manager, one thing follows from this: set up different checks for the two roles and measure the benefit with numbers, not feelings.

I have been in IT for more than 13 years, I have headed an analytics department, and I am now a principal systems analyst. I build my own projects on this site together with AI agents that write the code. Below is what I see from both sides, plus data from surveys and one experiment. There are figures for developers; I did not find large surveys on analysts, so that part has more reasoning and advice, and I mark it as such.

Who is who

A developer writes the program: the code that the computer runs.

An analyst in this article means two closely related kinds of specialist. A systems or business analyst decides what exactly the program should do and writes it down as requirements: what data, what screens, what to do when something fails. A data analyst pulls numbers out of the database and answers questions such as "how many customers did we lose this quarter and why". In a small company one person may do both roles.

How developers already work with AI

The figures here come from surveys; they are the participants' own answers. The Stack Overflow survey includes not only professional developers but also, for example, learners, so the shares below refer to all participants unless stated otherwise. DORA surveyed IT professionals, from developers to product managers.

  • Many use it every day. In the 2025 Stack Overflow survey (49 thousand responses), 84% already use AI in their work or plan to start; this figure combines both groups. Among professional developers, 51% use it every day. In Google's 2025 DORA report (about 5 thousand professionals), 90% use AI, and the median time spent working with it is two hours a day.
  • They are trying agents. An AI agent is a program that carries out a task step by step on its own: it reads the project's files, writes code and runs checks. In the 2025 Stack Overflow survey, 31% of participants used agents regularly. In a separate quick Stack Overflow survey in April 2026, 59% of participants reported using agents; the publication does not say how often they use them. The two surveys have different questions and samples, so these shares cannot be compared with each other.
  • They trust it little. In the same 2025 survey, 33% trust the accuracy of AI and 46% distrust it. The main complaint, chosen by 66%: answers that are "almost right, but not quite". 45% say debugging AI-generated code takes longer.
  • They feel the benefit. In DORA, more than 80% say AI has increased their productivity. This is a self-assessment, and the next section shows why self-assessment alone is not enough.

Perceived speed and measured speed

In the first half of 2025, the research organisation METR ran an experiment: 16 experienced open-source developers worked on 246 real tasks in their own projects. For each task, it was decided at random whether AI could be used. With AI, tasks took 19% longer. Yet after the experiment, the developers believed AI had sped them up by 20%.

The authors themselves limit the conclusion: this is a small sample of experienced people in familiar projects, using tools from early 2025, and the result does not mean that AI slows down all developers.

In February 2026, METR published an update. The new experiment produced unreliable data: 30% to 50% of participants admitted they had not submitted some tasks to the experiment because they did not want to do them without AI. The authors themselves believe that in early 2026 developers are most likely sped up more than in 2025, but they acknowledge that their data supports this only very weakly.

The takeaway for a manager: the feeling that "it's faster with AI" is not a measurement. Even for developers, who have tests and code review, the benefit has to be counted by tasks and how long they take.

Why an error is easier to find in code than in requirements

This is the main difference, and everything else follows from it. This is my conclusion from practice, not research data.

After AI, a developer still has checks that do not depend on who wrote the code:

  • the code runs or it does not;
  • tests (small programs that check predefined cases: with this input, the result should be this) pass or fail;
  • a colleague reviews the changes before they reach the working version.

None of these guarantees the code is correct: code can run and produce a wrong result, and tests only catch the cases built into them. But "almost right" code may break a test or crash when run, and then that run shows that an error exists, although its cause may still need to be found.

An analyst's result is text. The requirement "if the payment button is pressed again, show the customer a message" sounds reasonable. But it says nothing about what to do if the money has already been charged twice. While there is no code, there is nothing to run, and such a gap is found by reading: a developer, a tester, a second analyst or an AI that was asked to list failure scenarios asks, "what if the money was charged twice?". Later, a tester may catch it if they check this scenario on their own, independently of the requirements. If nobody catches it, the gap may surface only in the working program. The example is hypothetical.

A data analyst faces a similar trap. The AI writes a database query (an SQL query, a command that pulls out data), the query runs and returns a number. But running is not the same as calculating correctly: for example, the query might have counted cancelled orders together with paid ones. The number looks plausible. The error can be found by rereading the query's conditions or checking the number against another source.

What to give the AI in each role

Developer Analyst
Good to hand to AI Routine code, tests, analysing someone else's code, translating from one programming language to another, whole tasks through an agent A draft of requirements from a meeting recording, a list of questions and failure scenarios, comparing two documents, a draft database query
How to check Running the code, tests, code review by a colleague A link to a source for every statement, the developer reading the requirements, checking a number a second way
When the error shows up If a run or a test catches it, on that run May surface later, in the code or in a decision
What the AI needs to know The project's code; it can be given access to the files Agreements, business rules, laws. Sometimes they exist only in people's heads and in correspondence
Main risk "Almost right" code that passes the checks but breaks a rare case Plausible text or a number with nothing behind it

What a manager should do

For developers.

  1. Keep tests and code review by a colleague mandatory for everything written with AI. Who does it: the lead developer. How to check: in the task tracker (the program where tasks are managed), every task has a mark that it was reviewed.
  2. Give the agent tasks whose results are easy to check first: tests, small fixes, investigating bugs. Who decides: the lead developer.
  3. Measure the benefit by tasks, not by feelings. Who does it: the team lead. How to check: compare, for the month before and the month after, the time spent on comparable tasks and the number of tasks returned for fixing; the procedure is in the section on payback below.

For analysts.

  1. Ask the AI for questions and failure scenarios, not ready-made answers: "here is the description of a feature, list what could go wrong". The analyst makes the decision on each point.
  2. Require a link to a source for every statement in the requirements: a meeting, an email, a law, a company rule. Who checks: the analyst's manager or a second analyst, selectively. A statement without a link is worth rechecking: the AI may have made it up.
  3. Before work starts, the developer reads the requirements and asks questions. Who does it: the developer who will write the code. How to check: the list of their questions is attached to the task.
  4. Check any number the AI helped calculate a second way: against a report from another system or by counting by hand on a small sample. Who does it: the data analyst, before the number reaches management.
  5. Do not paste customers' personal data or confidential agreements into a public chatbot. Which service may be used in the company is decided by management together with a lawyer.

Does a subscription pay for itself

According to Habr Career for the first half of 2026, the median salary (half of specialists earn less, half earn more) of a backend developer, that is, someone who writes the server side of a program, is 251 thousand roubles a month, and of a systems analyst 222 thousand. Suppose an AI service subscription costs 2 thousand roubles a month: this is a hypothetical price, so plug in your own plan.

2 thousand out of 251 thousand is 0.8% of a developer's salary, and out of 222 thousand it is 0.9% of an analyst's salary. In other words, the subscription costs less than 1% of the working time of an employee on the median salary, not counting taxes and social contributions. This is a preliminary reference point, not proof of payback. Payback depends on net savings: the time saved minus the time spent checking what the AI did and on rework. And the time saved only brings value if it is spent on other useful work.

Both of these deductions are easy to underestimate. Time spent checking does not show up in reports unless it is logged separately. An error missed during review may still be caught by a test on the developer side. On the analyst side, an error in the requirements may require rework from the whole team: the code, the tests and the requirements themselves. Such rework may turn out to cost more than all the savings from the subscription. That is why for analysts the calculation has to include rework.

How to check after a month. Who does it: the team lead.

  1. Take one type of routine task, for example small fixes for a developer or describing one feature for an analyst.
  2. In the tracker, look at how many hours such tasks took in the month before AI, and how many of them there were.
  3. In the month with AI, ask the team to log separately in the tracker the time spent on the task itself, on checking the AI's output and on rework.
  4. Work out the average time per task before and after, with the "after" figure including checking and rework. The difference multiplied by the number of such tasks in the month with AI is the net saving in hours for that month.
  5. Multiply it by the cost of an hour of the employee's time (the company's monthly spend on them divided by their working hours in the month) and compare it with the price of the subscription.

The comparison is rough: no two tasks are the same, so trust a noticeable difference, not fractions of a percent. It is also worth watching:

  • Developers: the number of tasks returned for fixing, before and after.
  • Analysts: the number of developers' questions and reworks related to the requirements. If requirements are ready faster but there is more rework, the gain may have gone into rework.

If the numbers have not changed or have got worse, do not rush to give up: look at which tasks the AI is being used for. It may be easier to narrow down the tasks than to switch the tool off.

When this does not fit

  • The team has no tests and no code review. Then AI may speed up the appearance of errors on the developer side as well: "almost right" code is left to be checked by running and reading it. The DORA report calls AI a mirror and a multiplier: in a cohesive organisation it increases efficiency, in a fragmented one it highlights weaknesses. Checks first, agents second.
  • Business rules are not written down anywhere. An analyst's AI may fill them in on its own, and the text will come out smooth but wrong wherever it filled things in. Write the rules down first, then ask for drafts.
  • Work with especially sensitive data, and there is no contract with the AI service. That is a question for a lawyer, not a choice of model.

Summary

A developer can hand a lot to AI because code has checks that do not depend on its author: running it, tests, review by a colleague. With an analyst, individual points can be checked against a source or recalculated, but a missed scenario or a wrong business rule is looked for, before any code exists, by reading and asking questions, and a person makes the decision on each point found. So for an analyst, AI is a helper with drafts and questions, and the backing for every statement stays with the person. Compared with a salary, a subscription costs little, but payback depends on net savings: the time saved minus checking and rework. For analysts it is especially important to account for rework. After a month, compare the time spent on comparable tasks, including checking and rework, before and after; that will tell you more than the team's impressions: the METR experiment showed how far a feeling can drift from a measurement.

I have a separate piece on what a systems analyst actually does and when to hire one for a small team: does a startup need a systems analyst.

I work in systems analysis, AI agents and automation. If you would like to see my projects or discuss your own task, take a look at my portfolio.

Sources