AI 작업을 끝내는 법

Key takeaways

The most dangerous moments when working with AI are when you feel like you're "almost done" and you don't know what's actually done.

It is safer to break down large tasks into small steps rather than taking on them all at once. If you set goals, results, and confirmation methods for each step, you won't lose the flow even if the work takes longer.

Why are the steps needed?

The short fix is ​​simple: If it's just a matter of fixing a typo or changing the button text, you can edit and check it right away.

However, the tasks that require creating functions, changing screens, editing documents, and even checking tests are different. At this time, it must remain what judgment the AI ​​made, how far it progressed, and what it verified.

Without the step, the following problem arises:

• The scope of work grows in the middle.
• Completion standards vary from person to person.
• I'm missing a test, but it looks complete.
• Next time you watch it again, you'll have to keep track of the context.

Flow of using Phase Runner

For tasks that require changing multiple files or even verification, Moonshot Phase Runner comes to mind first. Although the name is grandiose, it is not difficult to actually use.

The simplest way to start is to ask:

1/moonshot-phase-runner2Please continue this task until the end.3If you get stuck, leave a message about where you got stuck and check the verification results.

If the task already has a planning document, pass along the planning directory.

1/moonshot-phase-runner docs/implementation --autonomous

The expectation is not “to come up with a great answer the first time.” The idea is to break the task down into smaller pieces and keep track of what changed and what was checked at each step.

When is it best to use it?

If any of the following applies, it is better to proceed on a step-by-step basis.

• You need to change multiple files or screens together.
• Not only does it require implementation, but it also requires documentation, testing, and deployment verification.
• It cannot be completed all at once; it must be done several times in succession.
• If you fail along the way, you need to know where to start again.
• Like “Please proceed until the end,” this is a request in which process management is more important than the outcome.

Conversely, it is overkill for very small corrections. Fixing single phrases, fixing obvious typos, or making small style adjustments is faster when you can fix and confirm them right away.

How to make a request

When entrusting AI with a large task, it's a good idea to not just say "what to build" but also "how to ensure completion."

Good requests usually look like this:

1Please go through this function step by step.2After each step, please leave a message about what you changed and what you confirmed.3If a test or build fails, explain the cause and what to do next.

Even if you don't use Phase Runner, you can achieve a similar effect by making a request like below.

1Proceed with this task in the order of planning, execution, and verification.2Briefly summarize the changes you made and the results you confirmed at the end.3If there is a screen problem, please check it yourself on a desktop/mobile basis.

How to check your progress

In long tasks, you need to be able to check “how far we have been” frequently. When checking, it is better to see actual results rather than verbal progress reports.

For example, if you are working on a blog, you would look at:

• Was the article file based on actual public articles?
• Is the image visible without being cropped?
• Are the categories and tags too long or awkward?
• Are exposure paths such as search, RSS, and sitemap up to date?
• Did the tests and build pass?

These items aren't just for developers. In the eyes of the administrator, it is also a standard for judging whether this article can be made public.

Clarify completion criteria

To say the job is done, at least three things must be true.

• [x]The requested scope was reflected in the actual results
• [x]Visible problems were confirmed
• [x]Necessary verifications such as testing, building, and documentation were completed

Especially in AI work, we need to distinguish between “written” and “done.” Writing is the state of creating a result, and completion is the state of confirming that the result works as expected.

Failure example: When trying to complete a large request at once

A common failure we see in practice is to set big goals at once, such as “Improve the overall quality of the blog.” The AI ​​can go through several files, fix some sentences, run a few tests, and come up with an answer that seems complete. However, when you check later, you may find that the really important text is short, the list of changed files is different from the description, and policy conditions such as ad settings are missing.

The key to the problem is not model capabilities but task boundaries. Large requests often have different completion criteria mixed in. Enriching content is an editorial quality issue, ad blocking is a metadata policy issue, and passing tests is a build stability issue. Bundling these three into one vague "improvement" makes it unclear which criteria must be met before you can say you're done.

A worse pattern is to only receive results at the end, with no intermediate checkpoints. If the direction changes in the middle of a long task, the model can do a lot even in the wrong direction. So, in the phase runner method, we first select the atomic task to be processed in this attempt, change the state of that task to in_progress, and record the results and verification commands. This record is not a cumbersome document, but a necessary safeguard when stopping and picking up work again.

Application example: Dividing content improvement requests into phases

If you change the request to something smaller like below, it becomes much clearer what the AI ​​should do.

1# bad request2Improve the quality of your blog posts and organize them for AdSense.3 4# good request5In this attempt, only one active atomic task in Phase 04 is processed.61. Only the 12 designated articles should be strengthened to at least 1,200 words.72. Add two or more failure cases, implementation examples, comparison tables, or checklists to each article.83. For the remaining public posts of less than 1200 words, check whether adsEnabled: false.94. Record npm run validate:posts and npm run test results.

This example isn't just a long sentence. Scope, how values ​​are added, policy conditions, and validation commands are all separated. Even if the AI ​​wants to organize other articles in the middle, the sentence “Only 12 designated articles” prevents it. If a test fails, you will know right away which criterion was blocked, rather than saying, “But most of it worked.”

Checklist application results

If you actually treat this article as a phase task, check it as follows.

This table makes “finishing AI work” much more concrete. Completion is not a sentiment, but a collection of evidence. By showing which files were fixed, which criteria passed, and which risks were left behind, the next person doesn't have to track down the same task again.

Recovery example: Records to be kept in case of intermediate failure

Long tasks may not be completed cleanly in one go. A test may fail, a post may not exceed the word count, or the verification tool may not run due to environmental issues. The important thing at this time is not to hide the failure but to leave it in a form that can be immediately followed by the next attempt.

A good handoff includes at least four things: First, write down what step you got stuck on. Second, write down which files you changed and which files you intentionally left untouched. Third, distinguish between executed commands and failed commands. Fourth, write down the conditions that the next attempt must check first.

1Stage: verify2Changed: content/posts/example.mdx3Passed: word count check, metadata check4Failed: npm run test5Next action: Check the failing test name and determine if it is content rendering regression.

This record is not an excuse or embellishment. The most expensive cost in AI work is the time it takes to reacquire the same state. Structuring failure allows the next agent or person to quickly determine “how much they can trust.” So, in phase runner-type work, failure records are as important as success records. Even in failed attempts, if the scope, evidence, and next actions are clear, the entire operation moves forward.

finish

When working on big things with AI, the important thing is not to throw in more instructions at once. Divide the work, check the results of each step, and record them for the next person to follow.

Moonshot Phase Runner is the name for automating the flow, but the principles themselves apply the same no matter which tool you use.