Developer and PM estimate: L10-L60, workflow and AI

Traditional developer evaluation often focused on stack, years of experience, task completion speed, and subjective seniority. In an AI-native environment, these signals quickly lose weight.

A Microsoft/GitHub study on Copilot showed a 55.8% speedup on a controlled task. Anthropic's Economic Index for development describes coding-agent sessions as a highly automatable class of work. DORA adds an important constraint: AI improves individual productivity, flow, and satisfaction, but without engineering fundamentals it can hurt delivery stability and throughput.

The evaluation takeaway is simple: AI speeds up hands, but it does not own the system.

If a person's value is to write pieces of code to someone else's spec, AI really does look like a threat.

If a person's value is to own the workflow, design loose coupling, assign tasks to agents, test hypotheses, and bring results into use, AI becomes a lever.

A developer at KT.Team is not a coder who just closes tasks.

This is an engineer who independently delivers business value by changing the workflow, uses AI as a core tool, communicates with the end user, and is accountable for the production result.

The minimally sufficient state under the policy is an L20 engineer at 4 points and DEVOPS at 4 points.

If someone is below that level, the development plan must show a clear path to it within at most 6 months. L20 requires end-to-end responsibility.

If value is split between front end and back end so that no one holds it in full, that is not yet mature value delivery. L30 requires more: the developer or team must turn the current state into hypotheses, cases, checks, readiness criteria, architectural decisions, and feedback on their own.

You cannot count something as L30 just because the PM called the work an epic.

- authored by KT.Team, but it aligns with international practice rather than conflicting with it. In the AWS article The New Unit of Software Delivery: The Workflow, Mark

Schwartz writes that with agentic AI, the unit of development becomes the workflow: an end-to-end process with a business goal that can be specified, delivered, tested, and improved as a single whole.

This is almost a direct description of our L30: the workflow as the unit of outcome, not a screen, API, or user story. Amazon two-pizza teams are built around small autonomous teams and single-threaded ownership.

AWS's public description emphasizes that such teams own the full customer experience and the product or service lifecycle.

This is close to our end-to-end accountability requirement: L20 for value, L30 for workflow. Werner's recent piece

Vogels' 2026 piece on returning to two-pizza culture shows the same logic in an AI product team: a small team, autonomy, using the product from day one, and the ownership rule.