Skip to content
←

필사 모드: Working With AI Tools as a Skill — Where the Delegation Line Sits and How to Verify

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Why "Good With the Tools" Is an Empty Phrase

Saying someone is good with the tools carries no information on its own. What was delegated, how the result was checked, and what they fell back to when it was wrong are all missing. Without those three, being good at it and being lucky are indistinguishable.

So this part is not about tools. Which product beats which product goes stale in six months; what does not go stale is a way of working. Three things are in scope: the criterion for how far to delegate, the procedure for judging what comes back, and the cost of skipping both.

The Line Is Drawn by Verification Cost, Not Difficulty

The common criterion is: delegate the easy things, keep the hard ones. By this series' discriminant that criterion has the wrong axis. What determines whether something can be delegated is not the cost of producing it but the cost of judging it.

Hold three tasks against that and some intuitions flip.

  • A gnarly regular expression: annoying to produce, cheap to judge. Ten examples tell you whether it is right. Good to hand over.
  • Changing one configuration value: nearly free to produce, potentially expensive to judge. A wrong value surfaces in production weeks later.
  • A data migration script: looks easy to produce and is hard to reverse. Its verification cost is effectively at maximum.

The third is the point. Irreversible work is never a delegation candidate no matter how cheap the generation is. Reversibility has nothing to do with difficulty, which is exactly why drawing the line by difficulty causes the accident in this square.

Four Lines Before You Hand It Over

Applying the criterion is simple: write four lines before delegating.

Example — a four-line delegation card

delegate:      first draft of the payment-failure retry logic
how to judge:  existing integration tests + 3 double-charge scenarios I add myself
reversibility: runs behind a feature flag. flag off returns to the previous path
keep in-house: the retry ceiling and the idempotency key design. wrong = charged twice

Two minutes to write. The value is in the second and fourth lines. If the judging line will not write, the task is not ready to hand over; if the keep-in-house line is empty, you usually have not drawn a boundary at all.

The Procedure for Judging What Comes Back

The most common failure in handling a result is the order you read it in. Read the result first and you rebuild your expectations around it. The more plausible the result, the stronger that overwrite.

Change the order. Before opening it, write three lines of expectation: which files should change, which edge cases should be handled, what must not change. Then open the result and compare. Any change that was not on your list is your first question.

Second, do not treat passing as grounds. Part 4 argued that a green build means nothing by itself. Here it means even less: take the artifact and the tests that check it from the same origin and the thing being judged and the standard judging it share a source. At least one edge case has to go in by hand.

Third, ask for an explanation but do not count it as evidence. A smooth answer to "why did you do it this way" is always available, and smoothness correlates weakly with correctness. Use the explanation to decide where to look; do the looking with execution and logs.

Where It Goes Slower Instead

Perceived speed is especially unreliable here. The randomized controlled trial METR published in July 2025 is the example. Sixteen developers experienced in their own open-source repositories worked through 246 issues, with AI tool use randomly allowed or disallowed per issue. The allowed condition took 19% longer, while participants had forecast a 24% speedup beforehand and still believed they had been sped up by 20% afterward.

Do not generalize it. The authors state explicitly that this is not evidence that AI slows down most developers, and that the result may not carry to other settings or to more skilled use. The sample is sixteen people. One condition does stand out, though: participants were working in repositories they knew well, held to high quality standards. That is an environment where verification was already expensive.

The Stack Overflow developer survey published in 2025 points the same direction. The top frustration, at 66%, was AI solutions that are almost right but not quite, and 45.2% said debugging AI-generated code is more time-consuming. On accuracy, 45.7% expressed some level of distrust against 32.7% who trust it. A survey records perception, not performance, so what it supports is a claim about where people report spending their time — nothing further.

Four recurring patterns come out of this: increasing delegation in areas where verification is expensive, underestimating the time to fix an almost-right result, shipping code you skipped understanding and meeting it again months later as a debugging target, and output that exceeds the team's review capacity. The last one progresses the most quietly.

What Is Genuinely Unsettled

Honestly stated, not much here is certain. Two things are. Generation got dramatically cheaper, and verification did not get cheaper alongside it.

The rest is open. Which categories of work show a net gain, whether the result flips as skill accumulates, and what changes at the organizational level are not settled questions. Anyone selling confident sentences in this space is usually selling something else too, or trading on fear.

Which makes the most rational individual move keeping your own record. For your own work you are the sample, and that sample is more accurate about you than somebody else's average.

Try It This Week

Pick three tasks you delegated this week and write down, for each, how many minutes you actually spent confirming the result was right. Not producing time — judging time. That number tells you where your own delegation line sits. If any of them took longer to judge than it would have taken to build, that category is faster done yourself next time.

  • Harness Engineering RPG — twenty-seven scenarios where the model is a fixed input and you design the tools, stopping rules, permissions, and evaluator around it. The debrief shows you that a weak evaluator caps everything below it. Same structure as the judging procedure in this post.
  • Logical Reasoning Trainer — separating necessary from sufficient conditions and reconstructing someone else's argument accurately. The closest available drill for not counting a plausible explanation as evidence.

Where this does not apply: in an area you are currently learning, invert the criterion. Even when a task is cheap to judge and therefore safe to hand over, if it is the skill you are trying to acquire, do it yourself. As part 3 noted, practice at reading and writing does not arise on its own, and delegation takes that practice first.

Further Reading

What Stays Expensive series

Sources

현재 단락 (1/37)

Saying someone is good with the tools carries no information on its own. What was delegated, how the...

작성 글자: 0자원문 글자: 7,083자작성 단락: 0/37