NAVER Backend Developer: In the AI Era, Every Developer Has Become a Manager of an AI Team
A software engineer at NAVER in South Korea, who has been programming since 1989, published a long-form article on the D2 blog on October 27, 2026, proposing a core judgment: the underlying executors within organizations are now AI, and every developer has become a manager of an AI team. This is not rhetorical exaggeration but a description of his daily work—assigning tasks to multiple AI agents, providing background information and evaluation criteria, and quickly providing feedback to correct deviations when results occur.
He maps the responsibilities of traditional managers one-to-one with AI agent management: setting goals and values for multiple individuals (AIs), reducing information retrieval costs, assigning work based on respective strengths while controlling the scope of context, and establishing efficient feedback loops between decision-makers and executors. He also points out a specific engineering consequence: when module boundaries are clear, AI agents narrow their scope of modification; when boundaries are vague, AI replicates similar code in multiple places, thereby accumulating technical debt. This means architectural decisions no longer only affect the collaboration efficiency of human developers but directly determine the work quality of AI agents.
However, the author believes that what AI agents cannot replace is human accountability. Even if AI completes all coding, testing, and deployment operations, it is still humans who decide to let users use a certain software; therefore, responsibility for problems falls on the final approver. From this, he infers that if the title 'developer' continues to exist in the future, its most likely meaning would be 'the person who approves the deployment of code for sensitive systems to production environments.' To gain this trust, methods to verify and ensure code behavior—code reviews, automated testing, multi-layer security checks—become even more important, not less so.
He provides a specific risk mechanism to support this judgment: LLM outputs follow a probability distribution, and the same instruction may produce different code; AI feedback loops primarily run in development environments, whereas the development environment and runtime environment of large-scale systems differ significantly in traffic, data scale, and diversity of execution paths. Therefore, code passed by AI in the development environment cannot guarantee the absence of performance latency, memory overflow, or data pollution in the runtime environment. He cites his own experience: participating in system architecture transformations involving annual transaction volumes of tens of trillions of won, multiple production incidents made him realize this gap is '운영 환경의 중압감' (the pressure of the runtime environment).
Regarding what capabilities developers need to cultivate, the author unfolds two lines of thought. The first is human-to-human communication and the collection of implicit information: AI can amplify the direction determined by humans, but the direction itself needs to be determined through communication; implicit premises within organizations, temperature differences among stakeholders, and inspiration emerging from face-to-face interactions—information that AI cannot obtain from training data—needs to be actively mined by humans. The second is establishing standards higher than the general level in specific fields and combining standards from multiple domains to make judgments: he gives an example where AI considers N+1 queries acceptable in the runtime environment, but given the actual deployment scale, he cannot accept this standard; caching is good from a performance perspective but potentially dangerous from a data consistency perspective—such comprehensive judgments require humans to have sufficient depth across multiple dimensions.
Sources:d2.naver.com