AI Coding Agents Shift Engineering Value From Implementation To Problem Definition And Decision Ownership

For most of the history of software engineering, organizations measured output: lines shipped, tickets closed, pull requests merged. As autonomous coding agents get better at generating syntax, it's become clear that generating code was never what slowed teams down. The hard part has always been figuring out what to build, aligning people around it, and keeping execution synchronized as the work scales.

Alex Sasnouskikh is a Tech Lead at Picnic Technologies, an online grocery delivery platform operating across the Netherlands, Germany, and France. Previously at Adyen, he built and scaled Cassandra infrastructure handling tens of petabytes of storage and managed open-source contributions to containerized data platforms. Operating at the system-design level across both high-growth fintech and logistics gives him a pragmatic read on where generative tools actually help in large organizations, and where they introduce new forms of friction.

"You need to make sure the 'what' and the 'how' are synchronized between people. Otherwise you cannot scale delivery. You need a person who understands the business and can translate it to a solution with software," Sasnouskikh said. That synchronization, he argued, has always been the constraint. AI can accelerate the implementation layer, but the coordination and judgment that sit above it remain human work.

"Coding was never a bottleneck," he said. "The bottleneck was to figure out what to do, not how. After Google and Stack Overflow, how is already solved. The bigger problem was always the people problem."

• The context cure: The impact of AI looks different depending on company maturity. Startups can spin up prototypes using agents to test ideas in a single afternoon. Scaling those same capabilities into established enterprises requires engineers to synchronize human context across deeply entrenched systems, and AI delivers high value here by pulling fragmented knowledge into one place. "You can think of it as an advanced Google search using your internal information base," Sasnouskikh said. "If you configure an agent properly, you can ask in one place and solve a problem where knowledge is spread across multiple systems. It fetches bits of information from everywhere and gives you a summary." He described onboarding into two separate teams in a single week using that approach, independently navigating unfamiliar codebases and identifying problems without needing to pull senior engineers away from their own work.

• Measure twice, prompt once: Sasnouskikh argued that architecture has always carried more weight than implementation, and that the current shift makes the gap visible in a way that organizations can no longer ignore. He pointed to high-level system design interviews, where candidates are asked to architect platforms like Netflix by mapping pure business requirements, never dropping into implementation detail. "I'm from Belarus, and we say that you should measure seven times and then do a cut only once," he said. "You first sit in a room with subject matter experts, business representatives, people who are involved in what you need to decide, basically becoming a decision maker. Then you decide, and after, it's trivial." He drew a direct line between that decision-making discipline and what separates engineers who lead from engineers who execute. "In my team, the best engineer is the engineer that can decide. That engineer knows what to do, and if they don't, they go and look for the problems to solve without needing to gather a whole room of people to figure it out."

The shift creates real clarity about where human value lives, but it also introduces a skills risk that engineering leaders are starting to confront. If implementation becomes mostly automated, the path from junior engineer to senior architect gets harder to walk. The foundational reps that build intuition about why systems fail, how edge cases surface, and where abstractions break down are the same reps that frictionless tooling makes easy to skip.

• The manual mandate: Sasnouskikh described a recent conversation with one of the most junior engineers on his team, who admitted he could complete his daily tasks using agents but questioned how he would actually learn the fundamentals of engineering by only prompting. "We sat together, thought a bit about it, and just prompting nudges you to become kind of a vibe coder," Sasnouskikh said. His advice was concrete: intentionally do a portion of the work without AI. "You can be a person who uses AI to write the software, but on the other side, you can become that really important person in every team, the exceptional one who can actually go there and say where AI is wrong. Maybe the problem is not in the code that AI wrote. Maybe the problem is in the underlying layer, in a database or in the framework that AI uses. To get there, you need to be hands-on. My advice to junior engineers who use AI: take one of your five tasks and do them just by hand." The analogy he reached for was the difference between engineers who use frameworks and engineers who build them. Both roles exist, but the developer trust gap between the two is widening as AI absorbs more of the implementation surface.

• The accountability anchor: As agentic coding tools scale, Sasnouskikh cautioned against assuming that speed translates to reliability in mature environments. Fully delegated development works for early products where iteration is the priority and the blast radius is small. Sustaining momentum within established businesses that carry commitments to large customer bases requires enforcing system-level constraints and keeping accountability with people. "In businesses that already run and have commitments to a lot of customers, I still see the problem of accountability, which should be on people," he said. "If you are accountable, then you likely won't delegate decision-making to an AI agent. You still would like to have more control. And there are also more regulated environments like finance, where there is a little bit more emphasis on that."

The governance question grows sharper as more people become builders and the volume of AI-generated code increases across enterprise systems. Sasnouskikh argued that the advantage is shifting from teams that can ship the fastest to teams that maintain the strongest review discipline, the clearest ownership boundaries, and the most deliberate separation between what gets automated and what stays human.

The role that orchestration plays in scaling AI across complex organizations will depend on whether leaders treat their agents as tools to be governed or as substitutes for the judgment that governance requires. "If you are steering the wheel, then you should decide where to turn," Sasnouskikh concluded.