If your team works in a single repository with a clean history and requirements in one place, AI-assisted development has plenty of examples to follow. But if your reality looks more like this, those examples become less useful:
- Dozens of backend services across multiple repositories.
- Business rules split between code, Jira tickets, and people's heads.
- A system that's been running for years, accumulating context.
- A domain where mistakes are expensive.
That's the environment Serhii Dakhnii's team works in: a large internal system that helps an aviation services company manage aircraft servicing at airports. We spoke with him about what happened when his team introduced AI-assisted development — what worked, what proved difficult, and why successful adoption had less to do with forcing change than letting it evolve.
Background & experience:
With over 10 years of experience, Serhii has built enterprise solutions across finance, retail, aviation, healthcare, IT, and logistics, with expertise spanning development, system design, business analysis, mentoring, DevOps, and the broader SDLC.
1. Why is AI adoption different in a large enterprise system?
Serhii: A lot of what we see around AI-assisted development comes from startups or relatively small projects that begin with AI already embedded in the development process. It is much harder to find good examples of large, established projects successfully making that transition. The reason is context.
Our project operates in the aviation domain and supports aircraft servicing at airports. It is essentially a large internal system that helps the company register and manage servicing activities.
From an architecture perspective, we have two applications: one with broader functionality for office use and another, lighter application used directly around aircraft to register defects and services. Underneath them are many backend services and interfaces that move data between different parts of the system, our own database, and multiple external data sources.
When you ask AI to work in an environment like this, opening a single repository isn't enough. The business logic cannot necessarily be understood from one service or one piece of code. Some business rules exist in the code, some in Jira, and some effectively live in people's heads. That makes providing AI with sufficient context one of the biggest challenges.
2. What was your starting point when introducing AI-assisted development into an existing enterprise project?
Serhii: We deliberately started small. Andrii Artemenko, one of our colleagues with strong expertise in AI-assisted development, helped us a lot at this stage. Instead of trying to solve every problem at once, we chose Cursor as a developer-friendly way to move from traditional development to working with AI agents.
The first question was: How do we want AI to write code for us? We documented our basic development rules: coding styles, test-coverage expectations, and other conventions. Then we selected an existing service that represented how we wanted code written and used it as a reference.
We also have many shared libraries across services, so AI needs to know where they are and when to use them. We therefore established conventions for where services and libraries live and how to access them. That gave us a small foundation — enough context for AI to complete smaller tasks in a way that was consistent with how our team actually works.
3. How did you make that context reusable across the project?
Serhii: We placed that foundation of shared rules into a separate repository and created utilities that allow us to copy the relevant context into other services.
The idea is that a developer can take an existing service that has previously been developed manually, bring in our shared AI context, and then generate repository-specific documentation.
At that point, AI has two things it needs: our general development rules and a certain level of business and technical context for that particular repository.
That becomes the starting point for implementing new functionality. It is not about giving AI complete knowledge of the entire enterprise system. It is about giving it enough structured context to work effectively within a particular part of that system.
4. Did you try to move the entire team to AI-assisted development at once?
Serhii: No, and I think that was important. When you have a large project and a large team, saying, "From tomorrow, we stop doing things the old way, and everything becomes AI-driven," can effectively disrupt development.
We took very small steps.
People who had more capacity invested time in developing the core approach and experimenting with it. People with less capacity could keep working with the existing methods. We didn't introduce strict deadlines or require everyone to change how they worked from day one.
That is one reason the transition has been relatively smooth.
5. How has the approach expanded beyond code generation?
Serhii: Once the foundation was there, we gradually started looking at other problems AI could help us solve.
For example, communication between teams can be difficult when there is no single source containing all business rules. So we introduced tooling that describes changes in human-readable language and puts that information into Jira. If something changes on the backend, the description helps QA understand what to test and helps frontend developers understand how to integrate those changes.
QA engineers are also gradually adopting AI techniques for writing test cases. The principle remains the same: we are not abandoning the existing foundation overnight. We are adding integrations and capabilities where they are genuinely useful.
6. Where does AI currently deliver the most value?
Serhii: One of the biggest areas is rapid prototyping and hypothesis validation.
Our development process does not always start with every business rule known in advance. Some requirements emerge as we build a feature and learn what will actually be most useful to the client. It may not be ideal, but it reflects the reality of the business environment we operate in.
AI lets me test a hypothesis quickly. Something that might have taken several weeks, or even a month, to prototype can sometimes be brought to a prototype stage within a few days. That means I can see very early whether an idea is likely to work.
That confidence is extremely valuable. Instead of spending weeks getting to the point where I can validate the direction, I already have a working prototype and know that the path is viable. Then I can focus on bringing it to production quality.
7. Does that mean development itself becomes dramatically faster?
Serhii: Not necessarily, at least not to the extent that is sometimes suggested online. AI does speed up development, but taking something from a prototype to a polished, production-ready state still requires considerable work.
The difficult part is often not the happy path. It is the edge cases and business-specific nuances. Those details can take more time than implementing the main functionality itself. With AI, implementation and rework are still faster, but there can also be more iterations: you discover something that isn't quite right, explain the problem to the agent, change it, find another issue, and repeat. So there are both advantages and disadvantages.
AI can implement changes much faster than I could manually. At the same time, if I were writing everything myself, I might notice some of those issues earlier. In practice, implementation is faster, but it can involve more iterations.
8. Has AI changed the code review process?
Serhii: Yes, and this is actually one of the areas that has become more challenging. We still review code manually, and I don't know many convincing cases where teams in environments like ours have handed that responsibility over completely.
There is also more code to review. AI enables us to generate code faster, and the models we work with also tend to produce more lines of code for the same task. The code may be perfectly acceptable, but there is simply more of it. That increases the cognitive load on reviewers. At the same time, agents are very useful for filtering out more superficial issues before a human review begins.
9. What does your review workflow look like?
Serhii: We use several layers. A local agent reviews the code before a pull request is created. Then another agent on the GitHub side performs another level of review.
We also use bots to check code for cybersecurity issues and known vulnerabilities in libraries.
All of this is useful because it removes a certain amount of routine work. But ultimately, a human still performs the review. For our environment, I see more advantages than disadvantages in this model, but I wouldn't say AI has removed the need for human validation.
10. Do you think human code review could eventually disappear?
Serhii: On some projects, absolutely. It is already possible to build working products with very limited knowledge of how the underlying code works. But those are often smaller products without particularly demanding performance or other requirements.
For enterprise projects, where risks are higher, or products have more serious requirements, I do not think fully removing human review is realistic at the moment. I always emphasise "at the moment" because I don't know how this will evolve.
Based on what I currently see in the market, however, fully autonomous development is not yet realistic for this kind of enterprise environment.
11. Why might some companies choose not to use external AI development tools at all?
Serhii: Security is one reason. A company can deploy its own models internally, but when you use external services, you need to consider what information you're sharing with another company.
That can include code and configuration information and, depending on how things are set up, potentially other sensitive information accessible within the development environment. Some organisations simply cannot accept that risk.
Another consideration is the nature of the product itself. In some environments, a developer may need to understand every line of code because if an incident occurs, the issue has to be resolved extremely quickly, potentially regardless of whether an AI tool is available at that moment. Human development may cost more than an AI subscription, but for some products that trade-off makes sense.
There is no universal answer. It depends entirely on where and how you use AI.
12. What have you learned about introducing AI into an established engineering team?
Serhii: There is no silver bullet. Even when we talked to people inside the company, we found very different experiences. I do not think you can create one document, hand it to a team, and say, "Read this and configure AI exactly this way.” It does not work like that.
Our approach is evolutionary. You introduce one small element. Not everyone has to use it immediately. You try it yourself, show it to the team, and let other people experiment with it. They encounter problems. They tell you what does not make sense or what is missing. You adjust it.
Then you meet regularly, discuss what is useful and what feels unnecessary, and continue shaping the process. If you have the luxury of time, I think that is the best approach.
13. So AI adoption should not be the goal in itself?
Serhii: Exactly. In our case, the approach worked because we did not force abrupt changes.
For example, I now use Cursor to write around 80% of my code. But if I need to change a few configuration settings and I know it will be faster in the IDE I have used for the last ten years, I simply do it manually.
AI is supposed to help you. You are not supposed to work for AI.
I have heard of situations where developers are discouraged from writing code manually just so an organisation can say that everything is AI-driven. That does not make sense to me. A good system should evolve naturally. You identify a real problem and decide how to solve it — rather than inventing a problem simply because you have a new tool available.
14. What is the main takeaway from your experience introducing AI into an established enterprise engineering team?
Serhii: The value comes from building the context AI needs, finding specific places where it removes friction, and expanding gradually. AI can speed up prototyping, implementation, testing, and review. But complex enterprise systems carry years of business context, edge cases, and organisational knowledge that AI cannot infer from a repository.
So it was never a choice between human and AI development. It is about finding the right place for each.
Related insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
