Why “Done” Does Not Mean “Correct”

When an AI coding assistant replies “Done” in a conversation, many people feel relieved and close the window. This is exactly where risk begins.

“Done” usually means only that the current round of tasks has been handled. It does not mean the result meets your expectations. In real work, AI may do things such as:

• Modify unrelated files as part of the task;
• Remove or replace existing logic just to “make the feature work”;
• Silently install new dependencies without telling you, creating security and compatibility risks;
• Reply that tests are recommended, but not actually run any tests;
• Look fine on desktop but break on mobile, with layout issues or non-working buttons.

So moving from “let AI write code” to “review AI’s work” is a necessary skill. The review process can be broken into three steps: see which files changed → see what changed in each file → verify that the project can still run.

Step 1: Check Which Files Were Modified

Depending on the tool and version, this feature may be called Review, Diff, Changes, or “View changes”. The names differ, but the core idea is the same: compare before and after versions side by side.

In many interfaces, a dedicated review pane shows these changes. If the project is under version control, you can also add line-level comments there and decide which changes to keep, stage, or discard.

When reading the diff, remember these conventions:

• Green usually means added content;
• Red usually means removed content;
• The file list next to it shows the files affected by the current changes.

One detail is often overlooked but important: the review pane shows changes in the whole project workspace, and they may not all come from the AI. If you had manually changed files earlier but have not committed them yet, those changes will appear here too. When you see a long list of changes, first separate what you changed from what the AI changed.

Step 2: Review What Changed in Each File

If the first step is checking the list, the second step is checking the details. Open each marked file and focus on whether the logic is truly correct.

Beginners who cannot fully understand the code do not need to read every line. For the first review, start with a simple but effective question: did it change things it should not have? Pay special attention to these high-risk areas:

• Entry points and configuration files: Did it change startup, routing, or build configuration?
• Dependency files: Were new dependencies added silently?
• Shared components and utility functions: Changes to widely reused code can have a much larger impact.
• Core business logic: Be especially careful with critical paths such as amount calculations and permission checks.

A typical “well-intentioned but dangerous” change looks like this:

- function calcTotal(price) {
-   return price;
- }
+ function calcTotal(price, taxRate) {
+   // Add tax rate
+   return price * (1 + taxRate);
+ }

Adding a tax rate may seem more complete. But if all callers of calcTotal are not updated at the same time, the project may fail at runtime or produce incorrect calculations. This is why understanding “what changed” matters.

Step 3: Verify That the Project Still Runs

Being able to understand a change does not mean the project can run. In this step, check three things: whether it starts, whether it builds, and whether core functionality works as expected.

• Start: Run the development command and confirm that the service starts correctly and pages open normally.
• Build: Run a production build. Some errors, such as path errors or missing dependencies, only appear during packaging.
• Core functionality check: Manually walk through key flows and make sure one change does not break something else.

Pay special attention to differences across devices. Many features work well on desktop but have layout problems or broken interactions on mobile. If your product targets multiple devices, verify on different real screen sizes instead of checking only the window on your development machine.

High-Frequency Warning Signs

From the analysis above, the most common warning signs can be summarized as follows. If you see any of them, stop and check carefully:

1. Removing existing functionality: especially removing APIs, pages, or logic without clear explanation;
2. Adding dependencies without permission: new dependencies increase package size, security risk, and version conflicts, so they should be confirmed by you;
3. Claiming tests were run when they were not: real test results should include output and logs, not just “run tests”;
4. Modifying unrelated files: changing module B while working on feature A may mean a misunderstanding or side effect;
5. Reporting only success: describing only the happy path and ignoring errors, warnings, or edge cases.

Make Review a Habit: Prepare While Delegating the Task

Efficient review does not mean passively checking after the AI finishes. It means preparing for review when you assign the task:

• Keep tasks small: Let the assistant do one thing at a time. Fewer changes are easier to review.
• Define boundaries clearly: State which files should not be changed and whether new dependencies are allowed.
• Require verifiable results: Ask for actual output from commands or tests, not just conclusions.
• Keep versions easy to roll back: Use version control commits and branches so any change can be reverted.
• Make small, frequent changes: Review a little after each change instead of reviewing a large batch at the end.

Summary

“Done” is only a period in the process, not a guarantee of quality. When using AI coding assistants, professionalism comes from having a stable review workflow: first check which files changed, then understand what changed in each file, and finally verify that the project still runs. Use the warning-sign checklist as a backup. By making these steps a habit, you can benefit from AI productivity while keeping risk under control.