The Changing Role of Engineers in the AI Era: From Code Writers to Systems Thinkers

In an environment where AI agents handle code writing, test generation, and even documentation, the role of engineers is changing. Dongbin Shin, Product Engineer at MyRealTrip's Accommodation Product Team, believes that the ability to decide what to build and by what criteria to judge has become more important than code output volume.

In the past, an engineer's competence was focused on how fast and accurately they could write code. But now, as AI rapidly handles implementation, testing, and bug detection, human value is revealed not in the code itself but in problem definition, judgment, and policy setting.

In the existing development approach, AI was a tool and humans reviewed its output. However, as AI has advanced, development, testing, review, and revision can now be tied together into a single automated cycle, allowing humans to focus more on setting initial standards and final review.

The core role Dongbin emphasizes is that of the standard setter. An engineer is not simply an implementer, but someone who decides what to build and what quality to demand, while also becoming the gatekeeper who sets the line AI must not cross.

Amid this change, the job roles drawing attention are also shifting.

• Product Engineer: Focuses on why something is being built and what it solves, rather than implementation.
• Staff+ Engineer: Exercises leadership not just through technical skill but through critical thinking, judgment, listening, empathy, and communication.
• Founding Engineer: Handles customer conversations, product direction, and business strategy, with code becoming a means to an end.

Time allocation is also inefficient. Many engineers spend 60–70% of their time writing code, while only 10–15% goes into establishing standards and policy. However, since the areas AI excels at are code and testing, and the areas where humans are stronger are standards and policy, more time should be allocated to what matters.

Documentation is also emerging as a core competency. Standards are not an asset when they exist only in someone's head; they become reusable only when left as documents that teams and AI can share. This documentation must go beyond simple comments or API docs to include business context, design intent, and architectural decisions.

However, the approach of "write documentation perfectly first, then implement" has its limits. Some problems only surface once something is actually built, so what's needed is not a one-shot completion approach but a method of evolving documentation and implementation together in short cycles. This requires an iterative process of writing only as much as is known, then reflecting what is discovered during implementation back into the documentation.

Early on, it's easy to think only about functional requirements, but the area where AI is particularly weak is non-functional requirements. Elements like performance, security, reliability, and operability are determined not by a single piece of code but by the system as a whole, and it's also pointed out that AI-generated code can more frequently create security vulnerabilities, performance issues, and delivery stability problems.

Accordingly, non-functional requirements should be handled in three layers.

• Prevention: Define rules such as banning N+1 queries and complying with OWASP as specifications.
• Detection: Automate load testing, security scanning, and architecture checks.
• Response: Humans take responsibility for incident response, capacity planning, and architectural evolution.

Ultimately, the engineer's role expands to that of standard setter, verification designer, systems thinker, and specification evolution manager. The core of AI-native development lies not in automating code generation, but in designing how quality judgment is distributed between humans and machines.