Roman Eloshvili is the Founder and CEO of XData Group, a B2B software development company with a focus on the European banking sector.
When AI coding tools come up in conversations, it’s pretty common for people to focus on how much faster they can write up software. It’s not hard to see why: AI can generate large amounts of functional code in just a fraction of the time it would take a human developer to do the same manually. But the more important question, I think, is what happens after that.
Writing code is not the same as putting reliable software into production. While the first has become relatively easy to automate, the second still requires human judgment and verification.
The main risk of using AI in this kind of work is not necessarily that it will generate genuinely bad code—in many cases, the code works perfectly well. The problem is context: Even when correct in isolation, that code can still be wrong for the system around it.
An AI model may generate code lines according to immediate prompts, which is technically accurate—but without looking at the broader architecture. It can, for example, potentially duplicate functionality that already exists elsewhere, creating maintenance problems that need to be solved months down the line.
And because the code itself gets generated so quickly, it can sometimes reach production before the team has even fully understood what has actually been done. That leaves a lot of room for risks, and it’s the major reason why code generation can’t be left entirely to artificial intelligence (AI).
Testing Cannot Have Shortcuts
If AI writes the vast majority of the codebase, which I’ve found it increasingly does these days, the testing process should not become AI-generated as well. And there should be no cut corners, especially where AI-made code receives less scrutiny than human-written code. The discipline of these checks has to stay rigorous in order to efficiently root out issues.
Perhaps the most important thing is ensuring that reviews happen independently. Whether the author of the code is a human developer or an AI model, they should not be the only ones checking the result. In the case of AI, one model can be used to generate the code, while another can perform an independent review.
AI can reproduce the same blind spots in both code and testing if both are generated from the same assumptions. Research from Veracode shows that in 2026 testing, about 44% of AI code-generation tasks produced code containing a known vulnerability.
This data illustrates the point perfectly: AI is becoming very good at producing code, but judging whether that code is safe is still a pitfall that remains unresolved.
AI Needs The Right Context, Not More Of It
An AI model can’t realistically hold the entire history of a software project in its working context, especially when the project itself keeps getting bigger. It introduces new layers of inefficiency, where developers waste far too much time explaining things to the model instead of letting it get on with the task at hand.
Given that one of the key arguments in favor of using AI to write code is saving time, this clearly creates a contradiction. The solution, then, is to feed AI the right information, instead of just more of it.
Based on personal testing, I’ve found that having a compact, reliably maintained knowledge base is usually the best option. There are things that AI needs to know consistently—your business logic, your architecture, your roadmap and your key project specifications—but there’s no need to give it the entire project every time.
Each individual task can be handled in a narrower, relevant context. The model does not need to understand every line of the codebase when working on a small feature; it just needs to understand the constraints that matter for that specific feature.
Regular refactoring must also play an important role here. AI can produce code much faster than humans can review it, which makes it particularly easy for inconsistencies to pile up. If you wait until the problems become obvious, there may be a huge amount of code to clean up.
Naturally, fixing things takes much longer this way, and developers may end up having a painful time untangling all the issues. It is much easier to keep the code aligned with the architecture when refactoring is part of the normal development cycle.
The Engineer’s Job Is Changing
As artificial intelligence takes over most of the actual implementation, it may transform the traditional role of engineers, turning them into decision owners.
At the end of the day, AI is just a tool, and we need to remember that. It can be used to streamline a lot of the work, yes, but it can’t define the context or the goal of that work for us. What are we building? Why are we building it? What is worth spending money on? What should go into production? All of these questions still fundamentally remain in human hands.
Earlier this year, Anthropic came out with some findings from roughly 400,000 Claude Code sessions, and the results showed that in most human-AI collaborations, people generally make the planning decisions, while the agent handles the execution. The same research also found that domain expertise improves the use of AI tools much more than coding proficiency.
In other words, manually inspecting every line of code is no longer the main part of the job. Engineers increasingly need to master understanding in order to review AI outcomes and take responsibility for them.
The amount of code generated by AI will certainly only continue to grow, but the context of a project belongs to the people behind it. Someone needs to understand why the software exists, what it’s supposed to do and what should be done when something goes wrong. And then they need to use that information to guide the AI’s execution.
That’s where the real focus of engineering work will be in the future.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?