AI tools are boosting engineering productivity software development, but they come with real limitations — errors, lack of business context, and a need for constant human oversight. Adoption across teams has been broadly positive, and the direction is clear: engineering is becoming more high-level, with AI handling more of the execution. The open question is whether that shift comes at a cost to foundational knowledge.
We spoke with Mykola Kohut about his hands-on experience with AI tools. The conversation focused on practical use cases, real limitations, risks, and how day-to-day engineering work is evolving.
Senior .NET Developer with 12+ years of experience, focused on practical AI adoption, agentic tools, and AI-driven engineering workflows.
Can you walk us through your journey of adopting AI tools?
Mykola Kohut: Initially, I used these tools individually rather than at the team level. At that time, there was no structured company-wide AI adoption — it was more about personal experimentation.
At first, I used AI mostly as a chat interface — for small tasks: quick questions, coding help, simple solutions.
Later, when the company started introducing artificial intelligence more broadly, tools were integrated into IDEs. Even though they were still quite immature, they already provided a noticeable boost, especially in routine tasks.
What problems did AI help solve first?
Mykola: Mostly basic and obvious ones such as detecting issues, repetitions, and potential risks in the code. AI acts as an additional “second opinion,” quickly scanning and highlighting overlooked issues. It wasn’t used to analyse the entire codebase at once; more like a task-based approach: you implement something, then ask the AI to review it.
What expectations turned out to be unrealistic?
Mykola: The idea that AI can be fully trusted. In practice, it makes mistakes and sometimes quite serious ones. That’s why generated code must always go through:
- Manual review
- Testing
- Validation
Otherwise, the risks are too high.
Can AI be compared to junior developers?
Mykola: It's an interesting comparison, but not entirely accurate. A junior developer, even with limited experience, understands the context they're working in: the team's standards, the project's history, the reasoning behind certain decisions. AI doesn't have that. It produces code in isolation.
Once AI output goes through code review, you may see inconsistencies with the rest of the codebase, solutions that don't align with existing patterns, or logic that needs rework to meet the requirements.
So in terms of raw output speed, AI can outpace a junior developer. But in terms of judgment, context awareness, and consistency — it still falls short. Human oversight remains essential.
Across your team, who gets the most out of AI tools on a daily basis?
Mykola: Developers benefit the most. AI helps analyse code, explain logic in plain language, and answer complex technical questions that previously required either deep experience or significant time investment. Instead of spending hours digging through documentation or debugging manually, developers can get quick, structured answers and move faster.
QA engineers also benefit from automation and test generation. Writing test cases is time-consuming and repetitive by nature, so having AI generate a baseline that can then be reviewed and adjusted saves meaningful effort. That said, the biggest overall impact is still on the development side, simply because the volume and variety of tasks AI can assist with are much broader there.
Did engineers embrace AI tools willingly, or was there pushback?
Mykola: Rejection hasn't happened — if anything, the direction has always been toward broader adoption. When issues come up, the response is to address them through learning and knowledge sharing rather than stepping back. There's been no rollback.
Some engineers have deeply integrated AI into how they work, while others still treat it more like an advanced search engine. Over time, most people move toward more advanced use — as they see colleagues using AI more effectively and build their own experience with it, the approach naturally evolves. It's less about resistance and more about where each person is in that learning curve.
What would you warn a business about before they go all-in on AI tools?
Mykola: The biggest risk is assuming AI can replace developers. AI does not understand business context, and that gap has real consequences. For example, AI might generate code that handles a calculation correctly in isolation, but completely ignores a business rule that applies only to certain clients or conditions.
On the surface, it looks fine; it passes basic checks, but in production it produces incorrect outcomes that are hard to trace back. In my work, I frequently adjust generated code based on that context. Without that adjustment, issues can become serious — sometimes even critical.
How is AI changing the way engineers learn and grow professionally?
Mykola: It significantly lowers the entry barrier — you can start doing complex work much faster. That's a genuine advantage, especially for engineers early in their careers who can now contribute to complex tasks without years of foundational buildup first.
But it also reduces motivation to learn fundamentals. Previously, learning was gradual — you'd work through problems manually, build understanding layer by layer, and develop intuition over time. Now there's a risk of working with generated building blocks without deeper understanding of what's actually happening underneath. And that gap tends to surface eventually, usually at the worst possible moment.
How is the development process itself evolving with AI in the picture?
Mykola: It's becoming more high-level. Instead of spending time writing implementation details, engineers increasingly define what needs to be done and let AI handle the execution. That shift is already happening, and automation will only continue to increase.
However, AI still lacks context understanding and awareness of business logic — and until that changes, full trust isn't realistic. The developer's role is evolving from writing code to directing it, but the judgment, experience, and business knowledge behind those decisions still have to come from a person.
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.
