1. What was the biggest project you completed using AI, and why was a rewrite necessary?
Andriy: A major product feature was causing support tickets, performance degradation in production and sandbox environments, and noisy-neighbour problems. The team spent considerable time applying workarounds, fixing bugs in a complex algorithm, or turning off the feature for some customers.
The underlying problem was that the implementation performed poorly with large data volumes and could not scale adequately.
2. How did you validate your proposed solution before starting the rewrite?
Andriy: I first used AI to build a small code example and check whether the proposed approach would work in our existing environment. I also verified that the necessary capabilities and libraries were available.
I presented the architectural idea and working example to stakeholders. After they requested additional checks and gave positive feedback, I proceeded with a proof of concept.
The proof of concept simulated large data volumes, measured performance, and tested whether the proposed approach could solve the problem before we committed to a full rewrite.
3. How has AI changed the way you approach a new feature, from the initial idea to implementation?
Andriy: Before daily AI use, an early technical decision could shape all later work. If that decision ignored a requirement, the team might spend days investigating and preparing tasks before learning a feature couldn't be delivered as planned. Major parts could then require a rewrite.
AI now reduces an initial feasibility assessment from days to a few hours in some cases. A proof of concept or small code sample can test whether an idea is possible and whether the environment has the required capabilities. This gives the team evidence before it commits to a design.
4. When you receive a short product request, how do you use AI to turn it into a technical plan?
Andriy: AI turns a short product request, sometimes only three sentences, into technical material that describes:
- Expected outcome — What the feature should achieve and how success will be measured.
- Proposed solution — The suggested approach to implementing the feature.
- Work breakdown — The specific tasks and responsibilities assigned to the team.
- Execution plan — The order of implementation, dependencies, and opportunities for parallel work.
- Open decisions — Questions, assumptions, and points requiring confirmation or feedback from the product manager.
5. How has AI changed your team's approach to development, documentation, and testing?
Andriy: Our project doesn't have a dedicated business analyst or architect, so product managers and team leads handled much of the technical documentation and preparation. AI helps now fill that gap by generating feature documentation, architectural plans, task descriptions, acceptance criteria, and code comments. People still review the output and ensure it aligns with the product's needs.
We also use AI throughout the software development and testing process. It generates most of my code changes, helps write unit tests, and creates automated tests from issue descriptions of expected behaviour. A single prompt can generate 20 or even 100 test cases, which we review to make sure they're correct and cover the intended behaviour.
AI has also changed how QA works. Browser-integrated tools can execute web tests, check fields, and record results through screenshots and videos. QA engineers can review this evidence instead of manually performing every step themselves. Backend testing is also increasingly automated.
6. How has AI changed your role as an engineer and team lead?
Andriy: The team includes developers and QA staff, so AI use varies by role. Speaking only for his own work, the team lead said he may go days or weeks without opening Visual Studio or Visual Code. He still considers himself a developer, but reviewing whether AI implemented the right design has become more important than writing code manually.
Code production is fast, but engineers remain responsible for validating requirements, keeping changes within scope, reviewing code, checking architectural and performance implications, and accounting for dependencies that may not be visible in the code itself.
7. What are the risks of using AI to generate technical plans and tickets?
Andriy: In one case, AI identified an incorrect documentation URL while another team was working on a ticket. The team approved the correction because it looked like a harmless documentation change, even though it was outside the ticket's scope.
Automated tests passed, but after deployment, incidents occurred because integrations depended on the old URL. Although the URL was incorrect, fixing it required coordination across several teams and could take weeks or months.
The lesson was that AI must not expand a ticket's scope without explicit confirmation that an additional change is necessary and safe.
8. What did the incident reveal about testing?
Andriy: Internal tests can miss problems when they change alongside the implementation. We need independent external automation to check externally visible behaviour, such as endpoint availability and compatibility, rather than relying exclusively on unit and integration tests.
9. How did you plan the implementation, and how long did it take?
Andriy: AI helped prepare architecture documentation, Jira tasks, descriptions, acceptance criteria, dependencies, and work that could be completed in parallel. The work involved three or four services of project.
Although the plan allowed parallel execution, one person completed most of the implementation, with limited help from others on smaller bugs and omissions. The project manager expected the work to take a few months, but roughly one to one-and-a-half people completed it in three weeks and reached deployment readiness.
10. How did you keep AI-generated code under control during such a large rewrite?
Andriy: I didn't ask AI to rewrite everything at once. I worked in small increments, starting with the structure, classes, and models, then implementing a simple service to verify the approach.
For each step, I produced a small piece, reviewed it, and committed it to git only after I accepted it and updated the docs as the implementation revealed gaps.
When an AI session went off the rails and it would take 20-30% of the result to fix it, I'd rather just start a new session with the updated documentation and the latest verified state. That way we could keep going without any loss of progress.
I also used AI-assisted code review and generated tests incrementally rather than trying to produce the entire test suite at once. Critical algorithmic logic received unit tests early, while less critical tests followed as the implementation stabilised. Code Rabbit provided an additional review during development.
11. How did you know the rewrite was ready, and what happened after deployment?
Andriy: Unit tests and automation gave me 99% confidence that the change was ready, although QA still needed to complete a final check on a small part.
After deployment, the product area had generated no further support requests at the time of the interview. We had resolved several related problems and could stop spending time on workarounds.
Most of the system had been implemented before I ran the project locally for the first time. I then verified the integrated result. The small increments, documentation, tests, and reviews helped build confidence before that final integration check.
12. What advice would you give engineers who want to use AI effectively?
Andriy: Daily practice helps people learn how to use AI effectively, and the tools change quickly. Tasks that were difficult a few months ago may now be possible with only a few prompts.
The trick is to see the AI as an implementation partner rather than as an expert. Its output still requires engineering judgement, careful code review, QA and strict control over the scope of change.
