AI Coding Is Accelerating Output Faster Than Enterprises Can Test What Actually Works

Agentic coding tools can now produce working software far faster than engineering teams can write it by hand. Nearly a third of organizations have passed on buying at least one software product because they could build it themselves with those tools. The speed of large enterprises hasn't always kept pace with the speed of their code. The constraints that remain were there long before AI arrived, in how organizations test ideas, assign ownership, and measure value.

Pavel Khmelinsky is currently Head of Engineering at the largest e-commerce platform in Eastern Europe, leading a 40-person org across development, QA, and analytics building fintech products. He previously served as CTO of Samolet's commercial division, leading a ~200-person tech org (engineering, QA, analytics). Before that, he spent a decade at Yandex, most recently heading development for its marketplace billing systems. His career in IT spans more than two decades, much of it inside large enterprises.

"Code writing was never a bottleneck, not in enterprise or even in small or medium businesses. Your bottleneck is how fast you can check your ideas. The faster you do it, and the more times you do it, the better your chance of success," says Khmelinsky. Checking an idea means forming a hypothesis, building a proof of concept, and then collecting and interpreting the data. Writing code is a small part of that cycle, even though its cost has always been easy to see.

Ownership after generation

Large enterprises have long treated source code as a trade secret that shouldn't leave the building. Khmelinsky also runs into a common misconception, even among IT professionals, that models learn from every piece of code and every conversation users send them. "It's not learning. It's pretty static, more static than you think," he notes. "If you want an LLM to learn from your text, you have to store it, filter it, and add feedback, and that costs a lot."

His caution at work has a different source. On his personal projects, Khmelinsky will give an AI coding agent direct access to his virtual machines and Kubernetes clusters. His work systems hold financial information and user data, and an agent that goes wrong could cause an outage the business can't afford. "Posting your code to an LLM, I see no real risk there. But posting the private data of your users is a real risk, so you have to guardrail it inside a big company," he explains.

The larger organizational question is who owns what the agents produce. AI can generate artifacts much faster than a slow feedback loop ever allowed, and teams don't always have time to check which ones are good. Each module, service, or document still needs a person responsible for it, including when something breaks in production. "You can produce a lot of code, but you still need the same number of programmers who could write the same amount of code by hand," Khmelinsky adds. "Slowly, but they could."

The real bottleneck

Agentic tools have exposed the difference between producing code and making progress. Teams can now write large amounts of code very quickly, yet Khmelinsky doesn't see big companies moving faster so far. "People around software development always tried to optimize writing code, but in big products, it was never a bottleneck," he observes. "Now we can see it clearly."

Output measures run into the same problem. A developer writing little new code might be fixing bugs, designing architecture, or answering everyone's questions as the only person who understands a system. Another might be talking teammates out of writing code at all, because a library or a better question about the task would serve them better. Even detailed frameworks such as SPACE, which account for how developers feel about their work, haven't produced a solid universal measure in his view. "Lines of code or commits per person per day is an interesting metric," Khmelinsky explains. "It's a source of questions, but it's never a source of answers."

Khmelinsky measures his teams by the value they deliver. He asks whether the product is moving in the right direction, whether revenue is growing, and whether customers are happy. He also asks product managers why a feature is needed before his team builds it. "If someone isn't passionate enough to explain why this feature should be implemented, it's probably a bad feature, or the person pushing it doesn't have a deep understanding of the mechanics," he notes.

Learning by doing

Agentic tools are now reaching marketing, sales, HR, and finance teams. Khmelinsky often sees people return from conferences and training sessions talking about AI, then admit they haven't opened an agent that day. His advice for non-technical teams is to start using the tools directly. "Less talking, more doing," says Khmelinsky. "There are two kinds of people. The ones who are doing are so busy, because there's so much opportunity at the moment. Then there are the ones who are talking."

Hands-on use also builds the understanding Khmelinsky considers the better protection. A friend recently described a model he used at work as private because his manager had handed him the access key. The model turned out to run on an external provider's servers, so internal data was leaving the company because no one had asked where it was hosted. Khmelinsky still encourages people to try the tools, though he enforces limits at work, where agents don't touch financial or user data. "It's the same answer it was 30 years ago," he explains. "Do backups, and let people work. It will do you good anyway, whether the risk is new or old."

Khmelinsky doesn't think companies should attach an ROI badge to AI yet, since earlier automation and machine learning already captured the most obvious gains. His advice is to let people use the tools and then hire more of the people who already do. When a candidate says they use AI, he asks them to share their screen and show him, and one candidate's subscription turned out to have expired two months earlier. He uses agents himself as well, summarizing his many work channels to catch likely incidents. "As a personal assistant, a tool you use at work, it's huge," Khmelinsky concludes. "Hire the people who use the tool."

The views and opinions expressed are those of Pavel Khmelinsky and do not represent the official policy or position of any organization.