AI-assisted development delivers more than faster coding: clearer requirements, earlier feedback and easier access to project knowledge, provided teams control tool permissions, data handling and model choice. ELEKS engineer Andrii Fedorovych explains how his team does this across requirements, documentation and testing, and what they learned along the way.
Background & experience:
Andriy has extensive experience in software development, solution architecture, and database design, specialising in C# and .NET to deliver reliable, high-performance enterprise solutions.
1. How do you balance the benefits of AI tools with security requirements?
Andriy: We have clear information about what we can and cannot do with sensitive information. In our product, we don't have access to real customer data, which makes the situation easier because there is less risk of accidentally sharing sensitive customer information with an external system.
But we still have instructions defining what can be used and what is restricted. We also have a process for tools that haven't been approved yet. They may be approved, rejected, or remain under review while the security team determines whether they can be used safely.
So even if an AI tool is useful, that does not automatically mean we can introduce it into the project.
2. How can teams integrate AI tools while maintaining control over permissions and security?
Andriy: You should not simply use every AI tool, AI agent, skill, or MCP that becomes available. First, ask whether it meets your project's compliance and security requirements. Sometimes a tool can provide useful functionality but also have permissions you do not want to grant — for example, the ability to make significant changes without confirmation.
One solution is to implement your own restricted version. That is what we did with our internal MCP. We implemented only the functions we actually needed and know exactly what it can do. It is read-only and works with systems such as Jira, our test case system, and Azure through limited functionality.
Instead of manually opening a page, copying information, and pasting it into an AI session, we can retrieve the necessary information through our internal MCP. It gives us the functionality we need while letting us meet our security requirements.
3. How has AI changed the way you communicate with clients and manage requirements?
Andriy: Artificial intelligence helps us find answers in previous discussions and Jira tickets, reducing the need to go back to clients with questions. It also helps us structure requirements from documents, clarify their meaning, and identify gaps that need further discussion.
As a result, we spend less time on individual tasks and can handle more features in parallel. Software development has become so much faster that product managers sometimes need to prepare the next phase earlier than expected. AI also helps them provide clearer, more structured requirements, making it an increasingly important part of our communication process.
4. How has AI changed the analysis stage of development?
Andriy: Previously, we completed discussions and documentation before starting development. Now, we can build a proof of concept much earlier and use it to gather customer feedback.
Analysis and implementation can happen in parallel: we start with limited information, create something tangible, and refine the requirements as we go.
5. What were the main challenges when your team first started using AI?
Andriy: The biggest hurdle was working out which of the AI techniques were actually useful. There was a massive amount of advice out there, but it was hard to figure out what was relevant to our projects and worth doing.
Neither the customer nor we had all the answers, so we took a practical approach: we experimented, observed the results, and learned what worked, what was unnecessary, and what was unreliable. Over time, this helped us understand how to use AI effectively in our daily work.
6. Have you ever had situations where AI confidently led you in the wrong direction?
Andriy: Yes, several times. That is why I prefer to work incrementally rather than implement everything in one step. If AI starts going in the wrong direction, I can roll back some or all of the changes and return to a previous stage.
From there, I have several options: continue the same session with more detailed instructions, start a new session, try a different model, or provide additional context.
Sometimes, correcting a flawed implementation costs more time and tokens than starting over. In those situations, reverting to a working version and starting again can be much more efficient.
The key is to recognise when an approach isn't working rather than continue investing time in it.
7. What have you learned about using AI effectively that wasn't obvious at first?
Andriy: One important lesson is that the most powerful model is not necessarily the best choice for every task.
We learned this when we started using a newly released, more powerful model by default. It consumed more tokens than our previous model but didn't deliver the expected improvement. By the end of the month, we were running short of tokens for the work we needed to do.
On the other hand, cheaper, less capable models can also be inefficient. They may require more context, smaller tasks, and repeated corrections to achieve the same result. A task expected to take an hour can stretch into several hours because the model forgets details or misses requested changes. Сhoosing the right model for the task is an important engineering decision.
8. Can a more powerful model sometimes do more than a task actually requires?
Andriy: Yes. You realise this after working with different models. For a relatively simple task, a powerful model may start gathering information from the codebase, the internet, or external libraries, even when that research is unnecessary.
However, for complex problems that require broader research, a more powerful model can be very useful.
The key is to write precise prompts that explain not only what the model should do, but also what it should not do. You can also create dedicated skills or rules that tell the model when to ask for permission before conducting additional research or retrieving external information.
This helps reduce unnecessary token consumption and makes the model more efficient for the task at hand.
9. Can AI models take actions you didn't expect?
Andriy: Yes, and this is something teams need to understand. You can read the documentation before using a model, but not every behaviour is necessarily obvious from that documentation. Sometimes you only discover it when you actually start working with the model.
A model may do more than you expected and, in some cases, perform actions without asking for confirmation.
That can be dangerous. It can modify something locally or externally, and although you may learn what happened afterwards, by then it may already be too late.
That is another reason teams need to understand the behaviour of the tools they introduce, instead of assuming a more capable model is automatically safer or more appropriate.
10. As a team leader, how have you seen AI change the way engineers work and share responsibilities?
Andriy: Absolutely. AI has changed our daily work a lot. Developers now spend much of their time communicating with AI rather than manually implementing everything themselves. Often, the first step isn't writing code, but working with AI to prepare an implementation plan.
Even during team discussions about how something should be implemented, some of the information developers bring to the discussion may come from investigations they performed with AI.
Our project doesn't have separate BA and architecture roles, so AI handles some of that work alongside team members.
Documentation is another major example. Previously, preparing documentation, descriptions, or presentations could take days. Now we can prepare some of that material in minutes, based on the code and the changes we have made.
We can also prepare different versions for different audiences — for example, a technical presentation or a version for senior management that focuses on what a feature does rather than its technical implementation.
11. Has AI also changed testing?
Andriy: Yes. Our team members can prepare automated tests much faster. What is particularly interesting is that automated test cases can be generated by people who were not directly involved in implementing the feature.
With a short description of what the feature should do and access to the code, AI can help prepare automated test cases without requiring someone to spend a lot of time first investigating exactly how everything works. That changes how the team shares knowledge and distributes responsibilities.
12. What role does documentation play in an AI-assisted workflow?
Andriy: Keeping documentation up to date has become essential. When we implement a new feature, we use AI to update our internal documentation. As a result, future sessions already have context on where the feature lives and how it works, rather than having to investigate the code from scratch.
However, more documentation is not always better. We don't want AI to read the entire project's documentation or scan the whole codebase every time a new session starts. Instead, we provide an overview of the project structure and rules that allow AI to retrieve more detailed information only when needed.
Preparing the right context in advance makes subsequent sessions faster and more efficient.
13. Does that documentation help people outside the development team?
Andriy: Yes. Our product manager can access this up-to-date information as well.
They do not necessarily need to ask a developer how an existing feature was implemented. We make the information available through our internal MCP, so they can use AI to retrieve it.
That reduces the time developers spend explaining how previous functionality works and gives the product manager another way to access current project knowledge. For us, that has been very helpful.
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.
