Editing AI Drafts: The Missing Project Details

I asked for a project account and got general advice

While building the blog, I asked the AI to write about the work. Its first article focused on why Astro had been chosen. I wanted to write about how I used AI, so I asked it to change direction.

The next drafts were three posts on providing context, checking completion reports, and giving design feedback. Their subjects had changed, but they still said little about my actual requests or where the AI had gone wrong. Before another rewrite, I asked it to analyze the problems and propose improvements.

The AI compared the original brief, drafts, work log, design proposals, and verification records. It then combined the three posts into one build case with actual requests and results. This article records that revision on September 15, 2026.

Reading the original brief alongside the drafts

The original request included this rule, translated from Korean:

Record only what was actually verified. Do not reconstruct conversations or earlier decisions that you cannot recall.

The brief called for requests, AI proposals, corrections, and checks to be recorded. The drafts instead spent much of their space on general advice. Comparing the sources exposed these gaps.

Missing or compressed in the draft Material already available Revision
The conditions for building the blog The original request specifying private material and publication boundaries Put the conditions in the opening and implementation account
The designs I compared and selected Four proposals and the conversation selecting option 2 Add the comparison image and describe the selection
What actually failed The translation collision, corrected code, and follow-up checks Explain the cause, fix, and recheck together

I also had the AI read the series plan and article template to examine why the posts kept repeating similar advice. It wrote an analysis with examples from the drafts and proposed changes. After reading that analysis, I directed the rewrite and asked it to record the revision itself.

Replacing a general opening with the actual request

The previous English version began:

The desired result is only part of a project brief. The AI also needs to know where to find existing material, which files it may change, and where to save its output.

That could describe almost any project. It omitted why I needed this blog and what I wanted to keep private.

The September 15 rewrite used the following opening. Its wording has since been edited, but this quotation preserves that revision for comparison.

I needed a blog to organize working notes from using AI in development and automation. I did not want to publish the code, data, or internal operations of my work projects. I chose the blog build itself as a case that could be shared, and asked the AI to record the planning, failures, and verification from the start.

The opening now stated the blog’s purpose, the material to keep private, and the work assigned to AI. Those conditions also explained why the implementation needed an approval list and checks of the release output.

Describing who did what through actual actions

The drafts repeatedly said that I requested something and the AI changed it. They needed more detail about the request and the change.

For example, I set the condition that only selected posts could be public. The AI implemented an approval list and file-hash checks, then tested that private material stayed out of the build. For design, I supplied the conditions and selected a proposal; the AI researched references and made the comparison screens.

The AI found and fixed the collision between translations. The revision stated that explicitly:

The AI found and fixed this bug. My role was to request Korean and English support and delegate verification of the actual screens and interactions.

This is also a quotation from the September 15 revision. Later wording edits preserved who made the request and who changed the code.

Combining the posts and using the existing evidence

Finding folders, reviewing completion reports, and choosing a design all happened during the same blog build. The AI proposed combining them into one article, and the rewrite followed that proposal.

A table alone did not show the differences between the four designs, so the original comparison image was added. The verification section gained the translation bug’s cause, corrected code, and follow-up results. An actual deployment screenshot was included, with a caption distinguishing old proposal titles from the current articles. The failure screenshot was not included; the account used the work log and corrected code instead.

The combined article is the account of delegating the blog build to AI. This article keeps the analysis and editing work separate.

Leaving unsupported explanations out

Some proposed improvements had supporting material; others did not. The design and verification records were available, but no records compared task duration or cost. No productivity figures were added. The design account records my choice of option 2 without inventing reasons I had not stated.

A link-check count, for example, records that those URLs were checked. It cannot establish that the work became faster or needed less human intervention.

I summarized the method as a request for future articles. This example was composed after the work; it is not a quotation from the conversation.

Compare the original brief, current draft, and work records.
Identify the evidence and decision-maker behind each important claim.
Check whether generic advice can be replaced with a concrete case.
Separate changes supported by existing evidence from those needing new checks.
Use that analysis to propose a structure and preserve the before-and-after text.

The wording needed another pass after the structure changed

The revision combined three advice posts into one build case, connected requests to results, and put the design and verification material in the article. The AI preserved the old and new drafts and prepared Korean and English review versions.

Adding real examples did not resolve everything. In the next review, I still found that the writing missed the point and sounded awkward in Korean. I asked the AI to find and apply a Korean writing skill. The account of that trial shows the wording changes and the editing decisions that required more than a style pass.

Working with AI

  1. An AI Blog Build: Design Rework and a Translation Bug
  2. Editing AI Drafts: The Missing Project Details
  3. A Korean Writing Skill: Before and After
On this page