Make AI Coding Requests Reviewable: Five Habits and an Acceptance Checklist

ちーあい — Tue, 22 Sep 2026 14:54:17 +0000

AI-assisted coding becomes harder to review when one sentence mixes several targets, exceptions, and intended behaviors. In my solo iOS work, I find that separating those pieces makes the conversation easier to correct.

This is a practical workflow from my experience, not a benchmark showing that clause count determines accuracy. The example below is a hypothetical profile editor, not a claim about a production defect.

Start with a request that is hard to verify

Fix the name field and the Save button so empty names are rejected and errors are red, but keep the normal flow and show a confirmation when it works.

What exactly should turn red? Does “empty” include whitespace? Does a failed save still show confirmation? A reviewer must supply missing decisions before even checking the code.

Five changes to the instruction

1. Number the requirements

Give every independently checkable behavior its own item. This provides a stable reference for implementation and review: “R3 is missing” is more useful than “the form still feels wrong.”

2. Put short clarifications in parentheses

Write “Save button (the checkmark in the top-right corner)” instead of leaving the target implicit. Keep parentheses short. A separate condition deserves a separate requirement.

3. State the goal and your current understanding

Goal: prevent accidentally saving a blank display name.

Current understanding: the form allows an empty value. Ask the coding assistant to verify that assumption against the actual implementation before editing. Do not present an untested guess as a confirmed bug.

4. Restate current and intended behavior on every revision

For the feature being changed, say what it does now and what it should do afterward. Include behavior that must be preserved. This is especially useful after several revisions, when an earlier message may describe an older implementation.

5. Separate combined requests without losing logical conditions

“A and B” can hide two separate changes or a shared condition. Write one rule per target when scope is ambiguous. However, preserve genuine conjunctions: “signed in AND has edit permission” requires both predicates. Splitting the prose must not change that logic.

A reviewable replacement prompt

Target: profile editor, display-name validation and Save action.
Goal: prevent blank display names from being persisted.

Current behavior (my understanding; verify first):
An empty name can be submitted.

Required behavior:
R1. Treat a name as blank if trimming whitespace and newlines
    produces an empty string.
R2. For a blank name, show “Enter a name” below the field.
R3. For a blank name, do not call the persistence operation.
R4. Render the validation message in red (the message itself).
R5. For a valid name, preserve the existing persistence behavior.
R6. Show a success confirmation only after persistence succeeds.
R7. Preserve the existing handling of persistence failures.

Before editing:
Check the implementation and identify any incorrect assumption
or conflict in these requirements.

After editing:
Report the change and verification result for each R-number.
Mark unverified items explicitly.

The prompt is longer, but the conditions are easier to locate. It also avoids accidentally requesting a red button when only the message should be red.

Turn the requirements into checks

Input or event	Expected observation	Requirements
Empty string	Validation message; no persistence call	R1–R4
Spaces and a newline	Same as empty input	R1–R4
Valid name, save succeeds	Existing save behavior; confirmation after success	R5–R6
Valid name, save fails	Existing failure handling; no success confirmation	R6–R7

These are suggested checks for the example, not tests I ran against an app in this article. In a real change, verify both the visible UI and the side effect: a warning alone does not prove that persistence was skipped.

Keep the next revision equally explicit

If R2 needs different wording, restate its current message and replacement message. If the save flow has changed since the previous prompt, update that baseline. Requirement numbers help only if their meaning stays current.

My next step is to review AI-assisted changes item by item as implemented, incorrect, or unverified. That makes the result easier to inspect and gives the next prompt a concrete starting point.

Disclosure: I am an independent developer of Wacha, an iOS party-game collection. This post was drafted and organized with AI assistance from my development experiences and notes.

I Shipped Three iOS Apps With AI: 12 Downloads, $37, and ¥3

ちーあい — Tue, 08 Sep 2026 01:46:03 +0000

I am an independent developer who has shipped three iOS apps with the help of AI. The results are not a polished success story: one paid app generated $37.18 in roughly two months, another took about three months to build and earned only ¥3 from ads, and my multilingual party-game collection Wacha! reached 12 downloads on its first day.

Those first two apps do not support multiple languages, so I am not linking them here as recommendations for international readers. They still matter to this story because they taught me that finishing a product, monetizing it, and helping people discover it are three separate challenges.

What is Wacha!?

Wacha! is a free iPhone party-game collection for 2–8 players. It combines social deduction, quizzes, cards, word games, and action games, with both local and online play. The app supports Japanese, English, and Korean.

Players join a six-digit room, pick a game, and keep playing together without creating an account. Messages and visual stamps remain available in the lobby and during games.

AI was part of the entire workflow

I used AI for more than code:

Reading an expanding Swift codebase
Implementing and debugging game rules
Generating visual assets
Translating the interface
Preparing App Store review notes
Writing outreach copy
Building and updating the product website

I have also used Claude Code and Cursor professionally. For this personal workflow, Codex has been the best fit for me—not as a universal benchmark, but because it can connect long natural-language requirements, source analysis, image generation, and visual feedback from screenshots in one continuous context.

Developing away from the desk

I sometimes leave my Mac running at home and work remotely while I am away. I send concrete tasks to Codex for implementation, review preparation, localization, and promotion. AI keeps production moving, while product decisions, testing, and responsibility for the release remain mine.

What the small numbers taught me

The biggest lesson was that building and distribution are different jobs. AI can dramatically increase the amount one person can create, but it does not automatically create an audience. Instead of hiding the small numbers, I use them to decide what to improve next.

I am continuing to add games, improve multiplayer behavior, and make it easier for groups to start playing immediately.

Disclosure: I am the developer of Wacha!.

DEV Community: ちーあい