What is your role when AI does more of the work?

Useful human work includes defining the problem, making the result usable and leaving lessons for the next task. AI can draft notes and code, but missing conditions, explanations for colleagues and checks of practical usefulness still need attention.

This is not a prediction of which jobs will survive. It compares a small company’s account, a developer’s description of field work and an AI educator’s opinion to find questions you can apply to your own work. Josh and Yun’s sources are Korean; the Nomad Coders segment was checked against its English transcript. Screenshots retain the original language.

Did faster production reduce the team’s work?

Builder Josh’s condensed Arcpoint interview discusses meeting notes. Writing may become easier while readers spend longer extracting the point from a long, vague document. The time calculation in the interview is illustrative, not a measured company productivity result.

The useful connection is between the person producing a document and the people who must interpret it. Saving your time can leave the team’s bottleneck intact if it increases the next person’s work.

The interview also describes staff proposing successful methods and the CEO selecting some for shared use. Recording why a method was chosen, rather than keeping only its output, can preserve context. The account does not establish that this operating method has the same effect elsewhere.

Include the next person’s decision

If AI summarizes a customer enquiry, decide what the responsible person must judge next. A refund decision still requires the purchase date and applicable policy. Omitting them forces a return to the source.

Try defining completion as “the person can find the evidence needed to decide,” rather than “a summary exists.” Save useful examples with their conditions and exceptions. If you work alone, next week’s you is that next reader.

Who turns an unclear request into usable work?

Nomad Coders explains the Forward Deployed Engineer role: working with customers to apply technology in their actual environment. At 02:31–03:25, the presenter groups the work into implementation, system design, customer-work understanding, operational judgment, communication and iteration. At 02:46–02:55, the focus is turning undocumented, messy processes into technical specifications.

For “automate enquiries,” code alone is insufficient if you do not know which enquiries are urgent, who should receive them or which exceptions matter. Practice eliciting these conditions and explaining the same decision to colleagues and managers.

The six capabilities reflect the presenter’s reading of job postings, not universal job requirements or a hiring guarantee. The video promotes paid training. Its salary and hiring-volume claims are not used as evidence here.

Before requesting a feature, ask: Who uses the result, and when? When should it not be automated? What would show it worked? If an answer is missing, ask someone who knows. An AI-written specification does not supply that knowledge automatically.

How should you read claims about being replaced?

Yun Jadong speaks more forcefully. He contrasts AI ability with in-person sales and interpersonal skills, says he studies with the possibility of replacement in mind, and asks staff to become capable AI users together.

This expresses an educator’s expectation that AI use become a team capability. It does not establish that all coding, design or editing jobs will disappear. Automating part of a task and eliminating an entire occupation are different claims; a short video does not measure employment changes.

A more actionable question is what to try with AI and what you must still understand and explain yourself. Define “good at AI” as observable work, such as drafting an enquiry summary and explaining omissions after comparison with the source. Provide tools and practice time, then check whether they help that task. The video’s language is not a basis for hiring or dismissal rules.

What could you change this week?

Ask whether something you produced quickly made someone’s next task easier. Then check the feeling of speed against evidence.

METR’s early-2025 randomized study compared 246 tasks completed by 16 experienced developers in familiar open-source repositories. Allowing the AI tools used then increased completion time by an average of 19%, although participants still estimated that AI had sped them up. METR marks the result as not reflecting the effect of current tools.

The February 2026 follow-up suggests later tools may make developers faster but explains why selection effects make the magnitude unreliable: people may avoid participating or submitting tasks they do not want to do without AI. Neither study supplies a universal verdict about every tool or occupation today.

For one task, record:

1. User and completion criterion: whose decision or action should this support?
2. Total time and quality: include drafting, checking, revision and colleagues’ review, plus missing information and rework.
3. One change next time: a context question, an output format or a better checking criterion.
4. One shared lesson: record both successful conditions and failed exceptions, then check whether they recur.

One observation cannot establish an effect. Compare similar tasks several times and record exclusions too. If the next question is what to hand over to AI, read how to set delegation boundaries.