Raif Agentic Development: AI Transformation of Development at Raiffeisenbank

Hello everyone. My name is Andrey Usavka. I lead the corporate business financing development area at Raiffeisenbank.

My main focus right now is the AI transformation of our business unit.

This entails redesigning production and operational processes. This entails understanding which technologies we need to introduce where, how to reconsider the structure and content of roles, and much more that we need to do in order to achieve the ambitious goals I will discuss a little later.

Three key ideas that I want you to take away from this meeting.

• The first is that most often, you do not need to introduce AI into existing processes; you need to rebuild processes around AI.
• The second is the Output versus Outcome dilemma. It is about choosing goals that will motivate you to redesign existing processes.
• And the third is an agent error. It is not a reason to finish its work manually. It is a reason to further tune the system instead.

What does a typical implementation of GenAI technologies look like in 2025–2026?

Most often, we take, for example, a product development team and give each role its own AI agent.

• The product manager gets ChatVRD,
• the Backender gets Codex or Claude, and each role immediately sees that it can produce many times more Output per unit of time. The product manager will have far more specs in that unit of time, and the Backender far more code. And it seems that every step has become faster.

But local accelerations do not add up to an effect that the business can feel or that the client can feel. Why does this happen? Because between roles, between people, there are queues, waits, handoffs that distort and lose some part of the information and lead to rework. And therefore our overall efficiency does not grow.

If you look at macroeconomic statistics, you can see that output per hour is growing, while overall productivity—which is, in essence, efficiency beyond added capital and people—has growth roughly in the zero range, at the level of the pre-crisis years. And at the end of the 1980s, economist Robert Solow noted that the computer age was visible everywhere except in labor productivity statistics. That is how the Solow paradox emerged, and we are now observing, in essence, its second reincarnation.

It is interesting to look at one of the cases from process engineering, also from the beginning of the 1990s. IBM Credit, financing purchases for IBM customers. A classic credit process: registering a loan application, credit analysis, setting terms, and so on. Several departments, several key roles. Accordingly, researchers looked at how much actual work took in total, across all employees throughout this process. It turned out to be only one and a half hours. However, the client waited 144 hours from submitting an application to receiving the result. That is almost a week. And it turned out that if every employee were made twice as fast, the savings for the client would be only 45 minutes—which, you will agree, is negligible compared with 144 hours. And, in fact, one of the researchers who worked on this case formulated an interesting idea: computers are being used to automate processes that should simply be abolished and totally, totally redesigned. And, in fact, IBM Credit managed this even without computers. There, in essence, all the roles involved in the process were consolidated into one. Here I am alluding to the product engineer from the previous session. And, in fact, this led them to turn 144 hours into 4 hours for the client.

The conclusion is that the unit of AI transformation is not an employee, not a role, not an agent. The unit of transformation is an end-to-end process around a measurable result. What opportunities have we gained compared with the 1990s? Beyond the obvious fact that many iterations of the computer revolution have taken place, we can note that any business process in any company is, in essence, a journey of information between decision-making nodes. Some of them are conventional classic software, and some of them are people.

Why people? Because previously only a person was capable of taking unstructured information as input, applying their expertise and accumulated experience that was not digitized anywhere, and arriving at a decision.

With the emergence of large language models, it has become possible to automate such decision-making nodes as well, because LLMs handle this work quite well. And therefore we have gained the opportunity to transform business processes not only with AI, but around AI as well.

However, the question arises: how will we understand that the transformation we are carrying out is effective and useful? Here I will recall the classic management dilemma of output and outcome. What is the difference? Output is some set of indicators, evidence that work is moving forward. These can be subjective sensations of acceleration from having received an AI agent. It can be the number of merge requests, pull requests, lines of code written by an agent. All of this is necessary as evidence that work is taking place, but it does not guarantee that the work taking place is useful and creates a useful effect for the client. On the other hand, outcome is precisely the effect we are trying to obtain, for example, when we write code. These are changes that our client can feel. This dilemma often manifests itself in goal-setting as follows. You may see that a team or an entire company sets itself a goal of implementing AI in all teams. Or, for example, building a harness, building a platform, or adding one capability or another to our platform offering. What does this lead to? It leads to AI indeed being implemented in all teams, and a platform, harness, and so on indeed being built. However, what effects this produced beyond the fact that we built something is most often unclear. Most often, business metrics remain at the same level as before the relevant construction.

But an outcome goal is formulated differently. For example, we can say that we want the client to receive any change, any feature requested by the client, in less than 24 hours. This is the outcome, for example, that our teams and our company are targeting. We want the client to be able to receive any change they need in less than 24 hours. But more than that, we want this change to be implemented autonomously, without human involvement. And we want quality and reliability not to suffer.

We currently calculate our time to market in a simplified way, from creating a task in Jira to deploying the corresponding change into production. This implies that this segment of the journey covers part of the discovery process. However, a significant part of the discovery process is still outside the scope of this measurement for us. We will focus on it after we fully automate our entire delivery pipeline. And here we have good automation results. In particular, as a result of redesigning our development process, we managed to reduce the median time to market by 36 times, and the 85th percentile by more than 40 times. And now more than 50% of tasks are completed autonomously in less than 24 hours, and 85% of all product development within the financing area goes through the agentic pipeline.

We were moving toward this for quite a long time, in my view. You can see it on this chart. By the way, this is a logarithmic scale. Back in 2025, we had access to advanced models and AI agents. However, as you can see, this did not lead to our time to market dropping radically. Up until August, it was essentially a flatline. And then something happened in August, and our time to market dropped dramatically.

You can see a correlation with the chart below: since August, the share of tasks completed by the agentic pipeline has grown sharply, and it continues to grow. And, hopefully, it will reach 100% by the end of the year. One may ask: perhaps we bought speed at the expense of quality, or by slicing tasks in some special way. However, that is not the case. We have counter-metrics for our time to market. Of course, we monitor quality, reliability, and how our tasks are sliced. And it is important to note here that our defect rate remains approximately at the same level as before. Rollbacks and hotfixes have actually dropped twofold. From the perspective of the size of changes, it can be measured, for example, in files, lines of code, and so on. We see that these metrics are also at approximately the same level as before the implementation of the agentic pipeline.

To understand what important thing happened for us in August, why such a dramatic effect occurred, we need to explain how we view the concept of a harness and what types of them exist for us. Globally, at the highest level, we divide them into two types. These are inner harness and outer harness. Inner harness is essentially OpenCode, Codex, Claude Code, and so on. Everything that you can download, buy, install locally, and use.

Outer harness is something that turns a multitude of agents into a production system, into industrial software development. What is industrial software development? It is engineering practices, style, quality, security, reliability. It is everything that defines how your company approaches the development process. This expertise cannot be bought and installed. You have it, and only you know how it should work for you. And our outer harness, which we called Atomic, essentially implements all this expertise as an executable process. That is, it is not some collection of handbooks, instructions, and so on. It is all part of one unified moving machine. And this machine, this outer harness, essentially implements a production contract. A production contract is the answers to five key questions:

• Who sets the goal,
• what the boundaries of autonomy are,
• which checks are mandatory during the process and how they are carried out,
• what our definition of done is and, specifically,
• how we approach and respond to errors that arise during operation.

Next, I will discuss each of these questions in more detail. For us, one of the key changes is that we replaced all specialized roles that we had in teams with one engineering role. It is the product engineer.

Previously, we had backend developers, frontend developers; we had not had testers or analysts for quite some time already, but in principle, with the emergence of LLMs, it became obvious that any engineer can be a generalist if they have sufficient engineering expertise and, at minimum, expertise in computer science. The product manager sets the goal. Essentially, this means they say for whom and why we are building something, which metric we want to move. And the product engineer takes that intent brought by the product manager, turns it into a specification together with the agent, sends it to the agentic system for implementation, and performs its acceptance. We scaled up the scope of our engineer many times over. That is, if previously, for example, we gave our backend engineer Codex or Claude Code, and they turned into, let us say, an assembler on a production line augmented by a powerful electric tool, who, together with that tool, performs large-unit assembly of the finished product. That is, if something happens to them, or if we want to scale this process somehow, we still run into a bottleneck: the person. In contrast, our product engineer focuses on developing and improving this pipeline. That is, they build and improve guardrails, set boundaries and acceptance rules, analyze new exceptional cases, and train the system.

How do we treat specifications, and how do we generally set goals for the agentic system? Here, our approach is that specifications must reduce uncertainty about intent, rather than describe an implementation plan. We tried descriptive specs, but they did not work for us. We tried different specifications in the SDD framework, specifications in a driven-development framework. However, in the end, we arrived at a fairly lightweight version in which we have a system through which product managers and engineers interact at the task-setting stage. In general, they proceed through self-checking. It looks approximately as follows. A product manager enters a certain chat with an agent. The agent has access to the product monorepository. And accordingly, when the person says, “I want to build this particular feature,” the agent can compare their intent with what is already actually working as executable code. It needs much less time to build a certain model of the world. Then the product manager answers a series of questions and provides certain comments, after which we get a specification of intent. After that, the product engineer takes over and, again together with the agent, designs a design solution. By and large, this also comes down to answering a series of questions, making some corrective remarks if necessary, and getting a product design document as an output. The design document does not spell out in detail which files need to be changed, which functions need to be added, and so on. We do not believe in that. We believe that the agent essentially needs a clear goal, a clear target, toward which the agent can do Kill Clearance. That is, there are functional requirements, non-functional requirements, and acceptance criteria here.

Probably the most important property—the agreement that allowed us to boost our time-to-market many times over—is the agreement on what our definition of done looks like.

For us, all standard product code must be written by an agent. If a person commits something to a merge request that was created by an agent or does work manually, that essentially worsens our performance metrics. Therefore, we have certain incentives to ensure that all work is done by the agent. During the design of the agentic pipeline, we made many different attempts. I think we built about four unsuccessful versions of the pipeline and learned a number of lessons. One lesson is that role-based SDLC pipelines do not work. In my view, they do not work in classic human development either, and they work poorly in agentic development as well.

The idea of building a pipeline with a planner, an executor, a tester, all kinds of critics, and so on looked very tempting. It turned out that such a pipeline works much worse than a mono-agent system. Here, our experience correlates with a Google study that found that on sequential tasks, multi-agent systems produce worse results than mono-agent systems. We formulate this for ourselves as: “it is important to ensure cognitive continuity for the agent,” so that it can, like a person, move quite nonlinearly during task implementation, so that it does not have rigid constraints imposed by one stage or another, or by a specific role mask. That is, it can explore code, write code, run tests in an arbitrary order, interact with the environment, find omissions in the design. And we even tune it, in principle, so that if it finds some critical flaw in the goal-setting or in the course of its attempt, it does not try to finish it at any cost, but rather gives up and says, “I failed.” And this gives us an opportunity to eliminate the critical flaw.

At a high level, our system looks like this. That is, you can see that there are several key layers here. There is an agent layer, which is essentially those Inner Harness parts. There is an agent responsible for task-setting. There is an agent responsible for execution. This is the largest part of precisely this Harness component. There is a Refine agent whose task is to find improvement points in the historical corpus of traces, comments, and so on. And we have an enormous, incomparably larger component. It is deterministic code; I call it “the system.” Classic Python code. There is such an entity there, for example, as a controller, which is responsible for many very important things. For example, it verifies that the executor agent has actually carried out all those quality checks that it claims to have completed. That is, this system examines the evidence of work that remains after the agent. This system is responsible for recovery from errors. For example, some infrastructure component flickered, or, I do not know, the whole system went down. In that case, we do not lose the state and accumulated progress. We recover approximately from the point at which we failed. This same part is responsible for error budgets, self-healing, and many other things. Our agent does not create any MRs itself. This is done, again, by a deterministic component. That is, in principle, we can see that the system is a deterministic layer on top of a non-deterministic stochastic component. We do not take the agent at its word. Despite the fact that the agent can run all possible types of tests that exist in the project, run linters, checks, and so on, these checks will still be run additionally later during the CI/CD pipeline and by the controller itself even before the merge request is created. That is, here, before handing over a change as a merge request for human review, we try to carry out every possible automated check available to us. And at the end, we have review. And clearly, when we boosted the performance of our pipeline by so much, we had much more code that needed reviewing. And it is clear that the focus of engineers shifts toward ensuring this review.

And it becomes impossible to review such volumes of code using the previous method. Therefore, our engineers do not focus on reviewing the diff itself. We add a certain layer that turns these diffs into a set of decisions the agent made along the way. That is, essentially, a certain report, perhaps with some visualizations, that a person can review. If necessary, they can drill down and inspect a specific diff. But in principle, the review of the diff directly is also carried out by an agentic system.

This is what our operational dashboard looks like, the one our team starts and ends its day with. Specifically, you can see that more than 900 tasks had already passed through the agentic system in August. This is a fairly old screenshot. There are actually far more than a thousand there. And our cumulative success rate is around 70%. That is for a 90-day period. Here you can see such an important metric as first-time acceptance. Pass at one, 31%. This is essentially the share of tasks in which the agent handled the solution perfectly, so that the reviewer did not find anything to comment on and simply accepted the solution. This share is growing for us. What generally helps us ensure, so to speak, growth in the metrics that are key for us? Several key process changes. For example, previously it was customary for us to store services, frontends, tests, and so on in separate repositories. Well, that is how it developed historically. Therefore, when you need to build a feature, you need to make several merge requests and orchestrate the merging of those merge requests into the corresponding masters and deployment. We moved to the monorepository concept. That is, we take a bounded product context and collect all its services, frontends, tests, wikis—everything—into a single monorepository. First, this allows us to add any feature change, any new feature to this product, this product area, through only one merge request. Second, it enables the agent, during exploration, analysis, and execution, to have access to the broadest possible context in order to deliver quality solutions and understand what world, what environment it is working with.

One of the most important lessons we learned from all our Harness building is that premature optimization is evil. At the initial stages, when you are building a pipeline, you should not try to save pennies, save tokens, dollars, and so on. Unfortunately, this leads to simply wasting your resources. We started by learning this lesson the hard way, of course. We began by taking a weak model and trying to build some overly sophisticated Harness around it that would push it in the direction we needed. And we fought entropy that disappeared by itself literally a few months later when the next version of the same model family was released. That is, we simply spent a lot of resources building some bicycles that we immediately threw away. In general, since then we have tried not to make such mistakes. We take a ready-made component base. These are agentic frameworks; in our case, the LangChain ecosystem. Ready-made workflow management tools. Observability tools, LLM gateways. We use them to assemble and model our Outer Harness process. We use these blocks to model our internal production process, which, naturally, we cannot simply take ready-made and buy.

Another important lesson here is how to instill a mindset in the team such that if an agent makes a mistake or fails, you do not feel the desire to do its work manually. This desire naturally arises in us, especially when the agent failed on a very simple task—that is, it completed a complex task but got stuck on a small one—and, of course, it seems that I can just finish it manually now. This instinct is, of course, completely unconstructive because it leads to the problem not being solved systematically. The systemic solution here is to ask yourself: what can I change in the product context, what knowledge, information, or check can I give the agent so that next time it reasons in the same way as I do and applies the same solution as I do? This is why, among other things, we look through this lens at what happens in review. Naturally, engineers review code quite carefully, especially during the early stages of implementing the agentic pipeline, and find a great many comments.

The agent is often verbose; it often creates tests that test form rather than substance, that test form rather than behavior. And such tests have very little value in themselves. And in order to address this problem systematically, we developed an autonomous self-improvement cycle. It runs once every period, reads all previously unreviewed developer comments on MRs in the product monorepo, then the agent analyzes them, tries to identify typical recurring episodes, and proposes hypotheses about how this could be addressed systematically. After it puts forward these hypotheses, it proposes changes as merge requests to the product monorepo, to the monorepo of the agentic pipeline itself if, for example, it seems that the problem can be addressed by changing the system prompt.

We have already had more than 60 such proposals formulated and accepted by the team, and this led to a rather pleasing increase in the first-attempt solution metric.

For delivery speed to become the norm, it is necessary to focus on four key areas.

• First, and probably nearly the most important—one of the two most important things—is the quality of upstream task-setting. That is, the task must arrive to the agent with an appropriate framing and level of uncertainty. It is important here to eliminate all significant uncertainty at the very initial stage.
• Second is a stable validation environment, a stable environment, a stable setup in which the agent works. Tests must not be flaky, infrastructure must not flicker, dependencies must be mockable, and so on. That is, in principle, all standard engineering practices apply here.
• Third, the agent cannot read your mind. Therefore, team agreements must not live in people’s heads, but should instead move, for example, into skills, prompts, into something the agent can reach and use as guidance when making decisions.
• Fourth, all possible checks must be embedded into the process. Deterministic checks are extremely important. Classic engineering practices help us establish adequate boundaries between products and systems. Domain-driven design works well here. You need to have a fairly high level of coverage with integration tests, unit tests, and so on. Connect static analysis, and so on.

That is, all this allows you to gradually expand the agent’s autonomy, because the agent’s autonomy is not expanded on faith, but because you gain the ability to automatically and autonomously verify the quality of its work. If we consider why transformations such as ours can often stall, it is simple: everything ultimately comes down to people. Clearly, any engineer, including me, becomes attached to the way of working that we mastered over years. I love writing code; I do not like handing work over to agents. And in one way or another, this resistance arises in each of us.

I think that the way to address it comes down to working with the team’s mindset, to working on involving the team in the changes that seem strategically important to you. And, of course, at the definition-of-done level, you can also say that work is considered accepted only if it was done by an agent. You do not have to go full-in; you can apply such a change in a fairly limited area. For example, we started this transformation by having one specific team out of five move completely to the new way of working.

It is important that there is a fully complete element of transformation there, that there is no “I will do this part of the work with agents, and I will do this part the old way.” If this optionality remains, this optionality will always be exercised not in favor of transformation. Largely because people fear errors, while in my view errors are, first, inevitable during such a transformation, and second, necessary, because it is through these errors that the system ultimately learns.

Therefore, the key decisions a leader must make during such a transformation are, first, to formulate the goal as an outcome—that is, as something the client can feel and experience. Formulate an ambition for that goal such that it is simply unattainable with the old way of working. Reconsider the staffing structure: which roles do you have in the team, and whether you have a chain of roles and handoffs between different stages. If you do, it is better to make one owner of changes in the process. You need to work on having automated control, so that all checks are embedded in the processes and automated. And eliminate the demo trap. I call this the situation in which a team presents management with a beautiful demonstration of an agent working autonomously, laying out a presentation, writing code, and so on, but then you look at how the team works and everything is still happening manually, just as before. This demo trap must be eliminated. And probably one important point that worked well for us is that you take your North Star metric—Time to Market for us—and its various components, put it on a dashboard that you monitor literally in real time, and start every workday with that dashboard.

I believe that the leader is responsible for strategy and makes the strategic bet. But without the team buying into that strategy, understanding it, and sharing your values, this transformation will not work. Because it is the team that determines exactly how we will reach the goal. Therefore, to conclude, I would like to recall the main lesson of the 1990s: people used to try to automate, using computer technologies, processes that should have been abolished and fully redesigned. Now, most often, we use artificial intelligence in exactly the same way, and we are, of course, inclined to look for magic pills, tools that can be downloaded and installed to solve all our problems. There are no such tools; we will have to swallow the bitter pill and undertake the difficult work of redesigning existing processes. And in order to begin in a clear way, I would advise choosing the process without which it is already impossible to imagine your company’s work, and asking yourself a simple question: how can we get the same result without doing all this work? That will be the starting point for your AI transformation. That is all from me. Thank you.

Q1: Listen, Andrey, you said you have one mono-agent, but a person reviews the result. Was there no idea, for example, to replace that with panels—orchestrated panels of independent agents using different models—to review code? And if a person reviews it, the bottleneck—has that person not become the new bottleneck?

• Speaker 1: Well yes, of course, a person has become the new bottleneck, but the person is not our only reviewer. In one way or another, we have an agent reviewer that provides additional feedback and gives it primarily to the person, not to the executor agent, because otherwise we get adversarial loops and work can become cyclical without delivering a result. From the perspective of panels, first, this probably did not work for us in our initial iterations, when we built some multi-agent, multi-role systems. It did not bring us the result we needed. And we decided to take the path of adding complexity only when it is justified. That is, if we see that the executor agent cannot handle its work, only then will we add additional roles, stages, and so on.

Q2: Andrey, speaking about business units and agentic development, at what scale did you start applying agentic development specifically? At the scale of what services?

• Well, several things matter here, probably. First, if we talk about the scale of our business unit, it is around 170 people in total. That includes agile teams and operational support. If we talk about the number of services developed in one form or another by the agentic pipeline, we had more than 200 product and service repositories. We consolidated them into 10 such product monorepos. So our scale is fairly large. All these services were also written over years. The code volume is enormous. There is probably no universal answer to the question of how to enable an agent to handle code. It is engineering practices: how your code is designed, how your tests are written. It is, again, a question of the tools you give the agent for exploring the codebase. For example, some time ago, when we had slightly weaker models and a somewhat different architecture of our agent, we performed semantic code search. That is, we indexed it, and so on. Then we abandoned it because at the current stage, for current models, ripgrep gives comparable results and requires no upfront indexing. That is, all of this is fairly cyclical. It seems to me that the point is rather that you need to try different things. Over time, return again to practices that did not work. Perhaps they will work in a new version of the model or framework you use.

Q3: Is there any example of a process that was developed entirely by the agent? If this is not just an idea.

• Well, I probably will not speak directly about the business process here. We have many different services that implement this business process. Essentially, our agile teams automate the credit process of corporate financing. There are various things there: issuance of powers of attorney, certification—that is, verification of signatures of authorized persons—and so on. That is, there are all kinds of systems there. And, by and large, if the question comes down to how complex the changes made by the agent are compared with what a person does, the agent now does all the same work that a person used to do. That is, it is not the case that we left some work to the agent while doing the most difficult tasks ourselves. That is not the case; it is simply written into our definition of done.

Q4: Hi, I am a tester. I saw on the slide that you abandoned manual checks, manual testing. And you shifted it to automated tests: end-to-end, integration, and so on. It is interesting how you now determine the necessary scale of validation and verification? It sounds in an extremely radical context, as if you now have a great many end-to-end tests for every corner case. How do you handle this?

• We did some preparatory work to prepare the testing pyramid, to ensure an optimal testing pyramid for our projects. We worked on this throughout 2025, even before we implemented agents at scale in any way. When we came to product engineers and so on, it became obvious to us that we needed somehow to standardize testing practices. So we did some preparatory work here. To say that there is some scientific approach one can use to understand that there should be such-and-such a proportion of end-to-end tests, such-and-such a proportion of UI tests, such-and-such a proportion of unit tests, and then everything will be fine—I do not know of such an approach. Here, we act more historically. One way or another, a person remains involved for us, but at the current stage a significant share of users of our systems are people. And still, a person as a product engineer looks over these MRs. We have not yet reached the point where it is physically impossible to do that. Therefore, in one way or another, probably both with our eyes and through feedback from users—which they can provide to us directly in chats, plus through some SDKs and so on—we see whether there are signals indicating that quality has declined. So far, we have no such signals.

Q5: Okay, so am I right in understanding that at the team level it is decided that whoever reviews individual MRs looks at and checks what kind of tests were written, whether they all adequately handle the business idea that was originally intended?

• Well, in very conditional terms, yes. And it is the same person who, in principle, approved the product design of that business idea. That is, we do not have separation where one person approves the product design, then the agent builds it, then some third person reviews it. We abandoned this practice. There is no major point in it now. That is first. Second, we already have an established set of skills, so to speak—engineering practices digitized as skills—that recommend what kinds of tests we expect to see for our changes. So we have already traveled some path here as well. Naturally, at the first stage engineers look at a large amount of this slop generated by systems, get annoyed, leave comments, rewrite skills. This is inevitable; it cannot be set up otherwise.

Q6: A very interesting talk. Two questions. One short one, and the other for reflection. There are processes that matter according to the letter of the law: compliance, various kinds of regulation. Have you had successes there or not?

• That is a great question, thank you. Here, indeed, we are still running into limitations. It is inevitable that we will run into the rigidity of this part of the system. It will change more slowly than everything else. But in one way or another, we believe that here too there is a certain... First, we see progress among colleagues in terms of changing and introducing technologies there. Second, our company is, in principle, API First. All interaction between divisions strives to be designed through APIs. And we believe in this very strongly. And third, I think that legislation, regulatory standards, and so on will also gradually change based on what technologies are available to us and what they enable in economic terms.

Q7: Now for the difficult question. In general, we are becoming agentic, transferring our knowledge-management mechanics. One problem is point 0, when there is enough knowledge to make a change, to give the agent context. It seemed to me that when you moved everything into a monorepository, you actually took off the table the thesis that code is a commodity. It became your point of truth, which is used in the context as part of the knowledge base for the agent to do something. Is my thesis correct?

• Correct thesis, yes.

Q8: Good afternoon. I have a concise question. In the talk, you said that you managed to accelerate development by several times or even dozens of times. How did you manage to accelerate your product managers by comparable figures, so that they would prepare described goals without uncertainty and your development would not stall right at the beginning? Because your pipeline must start at the same speed right at the beginning with product managers.

• Yes, that is a great question. I also made a caveat there that part of discovery is at the current stage. That is, we focused on delivery; discovery is still largely outside the scope. The example of the interface I showed is a kind of prototype of how product will define a task for us. We are trying gradually to extend this part of the system to the left in order to cover discovery as much as possible as well. For example, it is obvious that intent qualification happened there simply so that the agent could understand what I mean. But before I had this intent, some work also took place. We believe that this work should also take place within this system using different connectors: scouting the external environment, customer analysis, and so on. It should take place on this surface. And we have not yet gone very deeply into it. That is, in principle, work in this direction is also happening in the company outside the business units. We have, for example, an agreement on dividing areas of influence and focus areas. For now, we are focusing more on the delivery part. But again, in principle, we know quite well what we need to do. This backlog has been accumulated for years. We need to process it first.

Q9: TMS architect. There used to be a story where TMS items happen and then all of this is automated. Where does all of this go, does this trail remain, and who then handles support complaints and everything else?

• This responsibility is assumed by virtue of how we approach what a project team is responsible for. This responsibility was never strictly assigned to automated tests for us. As for TMS, last year we still had this dilemma: should we keep the comp divide TML that we had, put all of this in there, or not. We wrote some handbooks and instructions so that engineers could do it too. The engineers looked at it, said it was all nonsense, and abandoned it. They began doing the work without TMS. In our case—I am not saying this is a universal recipe applicable to everyone—we abandoned both TMS and this super-formal part of the test automation engineer’s work. As for testers, we have a simple dilemma: a tester must become a product engineer.

Q10: But suppose that when a technical specification is formed, decomposition takes place, and in general we can estimate the volume of the technical specification for its coverage by test documentation in order to understand and speak about quality and assess it from the testing perspective.

• Yes, I understand what you mean. I also worked at such a company, which had a waterfall approach, but now we have agile in the company, so we do not have a situation where we maintain, write, and update some technical specification. That is, our process is structured differently and, by and large, around agents; we have a different approach to development, we do not have technical specifications. Even now, when there is an agentic pipeline, we do not write a detailed technical specification, some volume of tests, testing.... We have a spec. A spec exists. Perhaps it replaces the role you assign to a technical specification. And for us, a spec answers key questions. Again, there are many formats for how it can be maintained: it can be a technical specification, PRD, ADR, SDD, and other practices. Everyone has done and does it differently, but we have a fairly simple spec: functional and non-functional requirements, non-goals, acceptance criteria. But we do not specify in the spec which tests need to be made: the agent itself chooses within its execution trajectory what to do. Overall, we are currently happy with that choice, given that the skills also specify what exactly needs to be covered, to what extent, and so on.

Q11: My last question. If a task is very complex and affects several products, services, and so on—that is, it needs very extensive grooming and is itself a source of a large backlog. In that case, the agent may not be able to cope with such a large story where everything needs to be done at once. Do you need to involve some solution architect or whoever is responsible for that role for you?

• Developers have always been responsible for this role for us; we did not have solution architects. We have enterprise architects from the company, but their focus is in a completely different area. If we talk about how similar requests are solved for us, within the system I showed there is the possibility of decomposition. The happy path was shown there—that is, a simple task is created, completed, and that is all. But for complex tasks there is the possibility of decomposition within the delivery workflow that we had. That is, it can all be done there because the agent has access to all product monorepos. That is, if a task arises at the intersection of products, it can explore all the products.

Q12: But in that case, within its delivery it must prepare a backlog and distribute solution owners. And who should control this story? Is that execution on your side?

• The agent itself performs all these changes. The agent makes MRs in all product monorepositories. Again, it controls the entire context itself. In one way or another, we have approaches. Now any harness you use—Claude Code, Codex, and so on—all good harnesses control the entire context of all the code to understand what needs to be done. Plus, context changes dynamically: something is loaded, something is unloaded. The context window is, in essence, a key element of stabilization in any case.

Q13: Do you use any tools, for example subagents, that perform narrow tasks?

• Right now, at this moment, we are not sure. We have a subagents tool; how actively it is used, we need to look at the trajectories, study the traces. At first, it worked rather poorly for us. In the industry, there is, in principle, a polarized view on subagents, to be honest. We initially adopted one extreme: no subagents. Then we gradually relaxed that and said that the agent could, at its discretion, for example delegate read-only activities to a subagent. In principle, it can use that. Whether this helps or does not help, we have not conducted experiments that would show how it was and how it became.

Q14: Is there any practice at all for working with long tasks, for example several hours of work?

• Regarding long tasks: we do not have long tasks that would take more than several hours to complete. That is, always less than four hours.

Q15: Could you speak about tests, or rather testing technologies? Are functional tests still built on some framework where automated tests are actually written and stored in the monorepo? Or does the agent itself take, I do not know, something like Playwright and run it on its own?

• Most often, it is still an enhancement of some existing product, which already has established testing practices. We do not let it reinvent the wheel, touch every possible framework, and bring one in. We do not have that. Theoretically, it can happen. For example, we can create a task if we understand during some postmortem analysis that an additional type of testing would be useful, which currently cannot be implemented within the available frameworks. We create a coverage task, and then the agent can, in principle, handle that autonomously as well.

Q16: The agent, like, if there is no driver: “Well, come on, make a button on a smartphone, one element was not found,” right?

• Yes, we have rather few UI tests; they are in the minority simply because the process itself is not UI-heavy. There is an interface, as it were. It is a bit easier than, conditionally, if it were a front-heavy mobile bank interface for a retail customer. In that case, we would need to invest much more in this area.

Q17: The question is: what is a typical workday like for such an engineer? From an everyday perspective. It is clear that they build this agent wrapper, and that is where their value lies. Do they only do that, or something else as well?

• First of all, it must be said that the product engineer as a role turned out to be a moving target for us. That is, for example, at the end of last year, when we introduced it, we were essentially answering the question: is the existing role model—backend developers, frontend developers, testers—relevant in a world where GenAI has won? We decided it was not relevant, that we needed generalist engineers who understand the entire stack. And, by and large, generalist engineers turned into product engineers. We thought that they would primarily write functionality manually or with coding agents. In the end, now our engineers write very little code. When our agentic pipeline appeared, they, by and large, stopped writing code other than the code of the pipeline itself. Therefore, probably 70% of their time goes to fairly classic elements of teamwork and team interaction: what we do, for whom, why, how, and so on. Then, of course, goal-setting and review take a significant focus. At the moment, probably review more so, because the volume of code is fairly large. We strive at all costs to push changes through in less than 24 hours. Therefore, it is important for them to pay more attention to the quality of what they receive. Accordingly, when they do this, they leave comments. They can immediately go and refine projects and skills based on feedback. They can immediately go and talk to the Harness team, think about what capabilities can be given to pipeline agents. That is, it fluctuates. Q18: If everything works like that, then they should make sure that the changes being made do not break previous projects?
• Do you mean so that new edits, new skills do not contradict one another? Yes. We realized that this was happening, that there was drift. We developed a system that analyzes and identifies these drifts. And specifically, this also happens within that agent self-improvement cycle. That is, it literally finds contradictions in skills. Q19: Regressions result, and on a new task you can get problems it handled before. And now it has begun to degrade?
• It is worse than that: mutually exclusive paragraphs can be identified in the skill code because, for example, different people wrote that skill at different times. Different agents looked at it from different angles. We now identify and fix these things so that they are coherent. So that a skill representing some expertise is digitized and non-contradictory.

Q20: So, you took and transformed the team. You removed roles and turned everyone into product engineers. Then, it turns out, there is some complex feature. It is decomposed, as I understand it, by domain areas. And it is crystallized quite finely. Because if I give a large feature to a team, then in my channel there will be a stream of these product engineers. They will somehow negotiate and interact among themselves. It will turn into exactly the same thing that previously existed between roles. That is, interaction will also begin between this large number of product engineers, and it will start taking time. Because they are in the context of some particular domain area and possibly their own background. So, it turns out you break tasks down that finely, then distribute them one to each of these five engineers. They then communicate somehow, and at the end review their own MRs? Is that how it works?

• It does not work like that for us. But probably we simply have not yet reached such large changes that would affect more than three product monorepos and some adjacent systems at once. In one way or another, probably product managers simply do not even come to delivery with that. They themselves try somehow to decompose these changes.

Q21: Is work decomposed so that it fits exactly one engineer? Crystallized to a minimum?

• It is not crystallized. That is, we have an agent responsible for planning. You can come to it with an intent. This intent can be split into component parts if it seems too complex. Even regardless of whether it is complex or not, we cannot assess that at input. We understand it more by the number and composition of repositories—that is, how many tasks of a certain level should exist, for example. Most work, most often, fits within the boundaries of one product monorepository by design. If something arises at the intersection—that is, large work across several products—then it will be split, for example, into two or three tasks. The same engineer who plans this change together with the agent will be responsible for them. That is, it is not the case that we distribute it among three agents. One engineer is responsible for a large task. One change, one person. A person must be responsible end-to-end for changes, however large they may be. But we simply try to reduce that largeness. Q22: So it has to be super planning: the task must always be such that one person can be responsible for it end-to-end. Some small, so to speak, interaction, execution. You need to perform just ideal planning?
• Well, I have not heard that teams suffer from this for us, to be honest. Probably we overcame it at some even earlier stages. But ours is more... In short, we are not waterfall; we have a very agile culture. And in principle we try... What is it called... Tasks where it is completely unclear how to do them, right? “I want this particular thing, I do not know how it should work, but I will put it in your backlog and then you figure it out however you like.” Is that one story point or a million story points? But such tasks simply do not end up in our backlog. My product managers and the team approach this quite adequately and eliminate uncertainty at the discovery stage, before delivery. This is all about discovery. Q23: In brief: some task comes in from a client, and it involves five clients. You need to go to the client, find out what is happening with the second one, go to designers, analysts, product managers, collect all of this, and overcome this feature. And one person really does that?
• Well yes, one person can really do that for us, but that was, in principle, the case before as well. One person can sort all of this out.

Q24: Regarding designers. I did not see designers in this setup either. If there is some request—for example, it is necessary to redo something, make a new design from new components, and so on—how does this whole story happen?

• We assign this more to the discovery part, for the most part. We have a design system implemented as some kind of kit that is available to the agent. That is, in principle, the agent can already assemble an interface from the UI Kit.

Q25: Well, should there be a designer review?

• Well, it turns out that a design mockup can emerge at the discovery stage. Again, we have rather little UI. Especially UI that would require refinement, because we expose very few screens directly to the client. Most of our screens are interfaces for employees. Hand on heart, we are not ready to spend a designer’s resources proofreading interfaces for employees.

Q26: Demos have now changed for clients, as I recall. And have you started recalculating payment for every delivered feature?

• We are probably simply not an outsourcing company in that respect, right? That is, we do not sell time and expertise of in-house development. From the perspective of demos for internal clients, well, by and large they look fairly similar to before. That is, we still show some features. A Harness team section has been added to it, which shows, well, the successes of the production process.

Q27: Do the business and employees like these changes?

• Our business is literally mixed in, every month it throws in tasks, registers investments, credit programs, new pensions. So there is much less work to do, everything is close. First, from this perspective. Second, our operational line employees themselves are incentivized and motivated. They receive people more actively. We all have shared goals there. Probably for us this is a somewhat less pronounced problem. We try to do everything completely.

Q28: In what form does the person who will later execute it receive the task? Some elaborated descriptions of who wants what, or is it literally a couple of lines such as "make a beautiful button"?

• Previously, we had a question of great variability: when people assembled tasks manually and created them in Jira, everything depended on the person’s speed. Sometimes there were just one-liners, a couple of lines about the task, and so on. That is why we developed this system, so that it would minimize variability for us. Therefore, from the product manager we receive fully concrete intents: what, why, which metric, what mechanics are expected. The product manager clarifies and elaborates all of this with the agent. And accordingly, the engineer then takes it over in that form. And simply brainstorms with the agent about how best to implement it.

Q29: Which models do you use? Everyone is switching to the Chinese now?

• Well, we tried different ones: we tried ChatGPT, Kimi, Qwen, and probably the worst are Qwen, despite the fact that they are used most often. Kimi K3 is performing well for us now. It simply suits us, even compared with ChatGPT it produces more pleasant code. Without the verbal diarrhea that we get with ChatGPT. They

Q30: It worked out for me that I use DeepSeek 4.1 for development, and GLM 5.3 verifies it. And it turns out that lately they have really stopped understanding each other. Okay, it is not easy.

• They all have, like, this, object, intelligence—that is, strengths and weaknesses. GLM can find something Kimi did not find and miss something GPT will find easily. That is, they should all complement one another.

Q31: The second question: what team made the Harness, and the question arising from this is how did it manage to do it? That is, I assumed you started with laboratories, not all at once but sequentially, and then how was this process equipped?

• Well, development itself was handled by a team of about 4 people plus me: different engineers, two classic generalist engineers, two NLP engineers. The work took around half a year, probably in terms of effort: in half a year we built four harness prototypes that did not work, then in a month we built one that did work, and started moving everyone to it in August. And I had a fairly simple heuristic there: I simply understood that it worked. When I understood that it worked, based again on me and the team as an example, we ran a lot of things simulating what we usually encounter in different teams. When I understood that it would work fine, but that we would inevitably encounter some errors, that without those errors we simply would not improve the agentic system, we went all-in despite what I said about acting in a limited way. That is, all teams received, so to speak, the incentive for all development to be done through the agentic pipeline, not to write code manually. We had some exceptions. That is, we first excluded a project that was on the critical delivery path, a general, like, worldwide migration with a strict deadline. That is, we did not want to demonstrate something there and get some errors. It was literally one team out of six. And there was one system supported—and still supported—by two people: commissions, legacy things, Windows, and so on. We simply did not want, so to speak, to deal with the sandbox there. We set it aside and said, guys, we will sort it out later. That was it; everyone else went into this story.

Q32: Do you have any frameworks for organizing context and memory?

• I understand. Damn, in short, on this topic too, I was just talking about reinventing the wheel. We started by reinventing the wheel, thinking that we needed somehow to organize the context of our products in a form that the agent could understand better. We started designing our own implementation of Deep Wiki. It did not turn out very well. And at the moment we understood that it was not turning out very well, Lang Chain released OpenWiki, and we switched everywhere to OpenWiki. That is, we simply have pipelines that analyze the Wiki of product monorepos at night. This is available to the agent. And from the perspective of some actual memory, we have not yet come to the point of having some specifically... That is, it is unclear why this memory is needed now? What specific decisions should it remember?

Q33: That is, for example, we started creating clarifying courses for roles. And it became more realistic. (inaudible)?

• No, I do not believe in that paradigm at all. I saw the results. Well, I saw people trying it live. Trying to use it, implement it. And it did not work. Based on that, we concluded that it does not work. And in addition, our failures with role-based pipelines pushed me toward the view that such an approach would work quite poorly.

Q34: Could you share your experience? You came to the team and said... You are no longer backend or frontend; now you are simply an engineer. How did you work with resistance? How did teams react? And how did you rebuild this environment in general?

• Well, it took us a long time. Longer than the Harness engineering itself, actually. That is, we were moving toward it. But probably since last summer I had been warming people up. And it started with presentations about where the industry was going, what was happening in it, why it was happening, why in two years people would most likely not be paid for the work you are doing.

Q35: That is clear. But when the time for changes actually came?

• We stepped into it much earlier than all the other companies. Last autumn, we said, guys—for example, testers, frontend people, ops, whoever we had—you will need to become product platforms. We are ready to provide the necessary training. Let us all sit down together now and standardize what is missing in terms of descriptions of team agreements, engineering practices, and so on. And we worked on this standardization. Through it, essentially, some engineers, for example backend developers, mastered some testing nuances that they had not previously possessed or worked with. Now, all of this took some time. By and large, we ended up throwing away all that work. All those handbooks we wrote—in the new reality, some of them moved into skills, and some are simply no longer used by anyone. But it was useful in terms of gradual adoption, for reassurance.

Q36: And are there any experts left who, for example, look at architecture, or not really?

• We had very unpleasant cases. We thought we had an expert—the position was literally called “expert”—and they even worked on writing some trendbooks and so on. While they were writing these trendbooks and presenting their expertise, it turned out that the depth of this expertise was not as unattainable as we had thought before. It is literally tangible and easily transferred into ordinary classic engineering roles. We have strong generalist experts; I have several such generalists who can do absolutely any work, they have powerful reasoning in any area of computer science. But otherwise, we have no other experts left, and even these experts are not used by me to verify someone else’s decisions, but to solve some extremely non-typical task in building the Harness or optimizing some part of it—something we had not done before, R&D in short.

Q37: Final question. Teams used to be large; you started doing this work. What percentage of reductions or optimizations occurred, or did it not happen and you found everyone a new place?

• In fact, we were not trying to optimize or reduce costs in any way; our goal was and is TTM. There were examples where people, for instance, chose themselves that this was not for them. “I will keep working as a tester at company N.” Or, damn, “I do not understand how I will become an engineer from a tester if I no longer write code.” Such people made their own decision that they were not on the same path as the company. We force no one. Our attrition rate is essentially probably at the level of 5% to 8%. That is perfectly normal given such radical changes.

Q38: You said in the talk that you had not had systems analysis for quite a long time. But what should companies do where systems analysis has existed for a long time? And there are huge numbers of places where something is written: BTS, FOD. There is, I do not know, user documentation of some kind. And all this documentation contradicts itself. There is no single point of entry. It is quite extensive. There is also a lot of code; it all lies in different repositories. Accordingly, to build an agentic pipeline... I have this problem now: all my agents end up in unreliable context. They tell me things, make decisions based on untruths. How can this be overcome?

• Product operation is more important than exhaustive documentation. Simple telemetry. Most likely, in most cases that is how it will happen in our world. But where we had... We retained useful context, for example at the level of business descriptions. For example, some regulation, normative documents, descriptions of complex products remain unchanged. That remained and simply moved into the conditional product monorepo. Yes, all the rest—those tables, diagrams, designs. But this was always a problem. It became outdated even before agents and so on. And there was no normal solution for how... Well, there were solutions, attempts, like: let us create an architecture test, create there... In short, add some layer of testing and verification. But it was difficult and very expensive. We did not do this. We simply threw such things away and considered that this was the way to solve tasks.

Q39: What serious incidents have you had with agents?

• In general, even before agents there were always... No, if you look at the incident rate metric—I showed it—the defect rate stays at the same level as before. Some truly large-scale incidents specifically due to the specifics of corporate business and corporate lending are fairly unlikely. Where, in short, where our potential blast radius is fairly significant, we perform a double-check, a triple-check. That is, we try. It is really possible to make severe mistakes in some financial postings, tranches, and so on. Here, these systems were already surrounded before agents by conditions, tests, checks of every kind. And they were designed quite well, in my view—we worked extremely hard on their redesign—so now no incidents happen there. Well, perhaps it is not time yet. Perhaps we have lived like this for three months; perhaps something will happen tomorrow.

Q40: A question about the time-to-market metric. Parallel development models for different domains. You say you improved time to market, but the parallelism remained, especially merge request conflicts and other such nonsense. If I understand correctly, suppose there is a well-designed domain model, yes, but nevertheless a product or your backlog can change the same domain, and conflicts must be resolved. Are they resolved for you at the agent-layer level, at the level of planning products and features, or how?

• They are definitely not resolved at the planning level, at least I do not know of such a method of resolution; perhaps it exists somewhere, I simply do not know it. It is all resolved at the level of... Let me remember how we did it. That is, the agent itself does a rebase. So, by and large, we have trunk-based, we have linear history, and all these conflicts need somehow to be resolved differently in the MR. People no longer resolve these conflicts now; by and large, agents resolve conflicts, and in most cases they handle it.

Q41: And if it happens simply in parallel—say, one has already been reviewed and is ready for production, while the second is also ready for production in exactly the same domain?

• Well, the agents themselves... They are not exactly agents; the system is complex. Approaches and strategies implement themselves.

Q42: And what do you do with blockers? For example, blocking a domain. Like, we do not edit domains while another domain is being edited and human approval has not happened.

• To be honest, I have not heard that such conflicts occurred for us...

Q43: In a monorepo? In a monorepo, they will always arise, right? When editing one domain, one product wants feature A and another product wants feature B?

• Ah, no, we do not have several products in one domain. That is, at the management level there is a well-structured queue of decisions. You could say, correctly. And, by the way, one more important point: during the process I showed, one of the agents also explores whether the feature you want contradicts what already exists. That is, conditionally, whether you want to violate operating boundaries altogether, add some mutually exclusive paragraphs to the system that should not be there. It already works differently by design. You are trying to break behavior that people previously committed. That is first. Second. This same thing also scans existing tasks in principle to ensure that there are no contradictions already. Because we are trying to resolve these contradictions directly now. I had forgotten about this part because it was done a long time ago. Because a lot has been done there, many facets in this area were made afterward. That is, contradiction resolution can also be performed here, in this part of the system. Thus, the agentic pipeline really receives, in essence, a ready queue of tasks on which pre-base is trivial and safe.

Q44: I understand, because pre-base is precisely the thing where the agent periodically makes mistakes well. And the second point: did you tune models, infrastructure, temperature, reasoning, and all the rest?

• Last year, we actively played with temperatures and reasoning. In the current approach, we try not to do that. We try to use default settings. Because it is unclear how to compare. You need fairly substantial investments in benchmarks, evals, and judges. You need more engineer attention to inspect this regeneration that models begin producing. Again, these are most often poorly quantifiable comparisons. It is a matter of taste. And we do not play with it. We try to make it so that, at the level of instructions, it arrives at a result that is acceptable for a person.

Q45: And then the models are independent. If, for example, third models make it possible through this essentially not to depend on who is who. If you need to perform some next enumeration.

• We are model-agnostic here. We currently try not to go down and do downscaling to simple models. We still have money not to do that. And to do it, we would need to invest heavily in benchmarks as well. But in one way or another, we now have much more material for a benchmark than before. Previously, it had to be assembled from the historical tail of tasks from different projects with different engineering practices. Now we have more or less functioning co-agentic systems. Project practices, for example, have become more aligned. Task sizes have become more or less aligned. Task descriptions are more or less clear. They are the same everywhere. Therefore, the material for a benchmark is richer now. Well, apparently we will start working on it after some time.

Q46: So, is SDD not used at all here? Or as a mirror?

• Well, OpenWiki is more likely not a mirror; I call it a simplification of navigation for the agent. Reducing the number of hops it needs to understand and find what it needs. That is, this can be solved in different ways, but we do not use Semantic Search; we rely more on something like grep, ripgrep, and so on. Therefore, OpenWiki helps here. But if we speak specifically about SDD, that is an entity of a different order. We tried it in our own development, in vibe coding, for example using some OpenSpec, Spec Kit. To be honest, I no longer even remember what results we had with Spec Kit. We lived in OpenSpec for quite a while within the Harness engineering team. Some of the guys liked it. Then I came in and looked at what it looked like. I thought: damn, this is complicated, to be honest. The same result can be achieved with a much less excessive process. It is, essentially, passing things back and forth. Yes, yes. The idea is clear: the more tokens you spend on directed brainstorming, the better result you will most likely get within some probabilistic range. But now we are moving away from this practice and instead making a very lightweight SDD spec in the format, well, like the Playbook Anthropic recently had. And they published that Playbook in which they said they had Intent.Markdown, Spec.Markdown, Design.Markdown, something like that. And literally, our system is implemented very similarly. Everything is committed into the same Git repository as the main code, but without some rigid workflow characteristic of, for example, OpenSpec, and certainly with a lower level of verbosity than it has.

Q47: So the spec is still stored somehow?

• Yes, yes, of course. It is an important part.

Q48: Andrey, perhaps I missed it. What exactly do you call a group of role-based teams and role policy? Is it an analyst agent, developer agent, tester agent? Yes, you said that at first you became disillusioned with the role-based pipeline, and then began doing things as you do now.

• Ah, yes, yes, yes. There was... I am trying to remember what we had. Actually, it was very close, I think. Some prompts like Codex Planning, for example. We had a planner that was supposed to provide a detailed implementation plan. We had an implementer that was supposed to implement the implementation plan. It was not allowed, I think, to write tests. There was an additional test writer. And I think we had adversaries for every phase that were supposed to verify things and restart work if anything inappropriate was noticed. Yes, it did not work for us.

Q49: So now there is one agent?

• Well, one key executor that owns, essentially, the end-to-end core. One samurai warrior. There are also, let us call them... Not exactly advisers, but in short, a reviewer can be launched. At the end of the work, it is launched and can give some feedback to the agent, and the agent can complete something once or ignore it. It may disagree with this feedback, and then it will simply be explicitly recorded that it was ignored. And accordingly, by and large, we try not to build role-based chains.

Q50: Another question. One engineer does one task. When I ask about an engineer’s workday, when they come to the team and engage in team synchronization, what is this team synchronization then?

• Well, it is important for me to understand, conditionally, that I should not have tunnel vision because I received a task and went to do it alone, but this leads to people becoming weirdos; first, it is probably not interesting for them to work, they feel like mere executors, and because someone now does all their work alone. Therefore, all our engineers are fully immersed in the product context, solve the client’s problems, come up with how to implement this. Those are our teams. Those are our teams: large teams, everyone performs their own task. These are the kinds of teams we have now.