Part 8. Feature Implementation

Implementation begins only after the feature specification has been reviewed and committed. At this stage, you change the agent's working mode: it is no longer an interviewer or product editor, but an executor of a specific plan.

The main rule: don't ask to "make the feature" without referencing the specification. Ask to implement specific task groups.

Session Preparation

Check the branch:

git branch --show-current
git status --short

Launch Qwen Code:

qwen

Clear the context:

/clear

Then give a precise input:

Read @QWEN.md, @specs/mission.md, @specs/tech-stack.md,
@specs/2026-05-01-hello-hono/requirements.md,
@specs/2026-05-01-hello-hono/plan.md,
and @specs/2026-05-01-hello-hono/validation.md.

Implement the remaining task groups from the plan.
Keep the implementation minimal.
Don't add features beyond the boundaries.
After changes, report the modified files and verification commands.

When to Split Implementation

If task groups involve databases, authentication, payments, migrations, or security, implement them one at a time:

Implement only group 1 from @specs/2026-05-01-hello-hono/plan.md.
Stop after the list of changed files.

Don't proceed to group 2.

For a simple Hello Hono phase, you can implement all groups at once. For complex phases — only in small blocks.

What to Watch During Agent Work

Don't wait passively for the end. Watch for signs of deviation:

• the agent adds a new dependency not listed in tech-stack.md;
• the agent changes files outside the task boundaries;
• the agent implements a future roadmap phase;
• the agent rewrites README or styles without reason;
• the agent skips verification commands.

If this happens, stop:

Stop. This change is outside the feature specification.
Re-read @specs/2026-05-01-hello-hono/requirements.md.
Before fixes, explain why the extra change is needed.

Typical Agent Failures to Prepare For

Not every implementation session goes smoothly. Several recurring failures that students encounter most often:

1. File hallucination. The agent writes "fixed src/utils/format.ts", but no such file exists in the repository. Remedy: before committing, run git diff --stat and verify each file from the agent's response against reality.

1. Wrong library version. The agent uses an API that appeared in a later version of Hono than what's in package.json. Remedy: at the first tsc or runtime error, check npm list <package> and ask the agent to verify the version.
2. **Silent tsconfig.json patch.** To "fix type errors", the agent weakens strict or adds // @ts-ignore. Remedy: in the practice from part 5, strict mode is fixed — treat any change to tsconfig.json as a boundary violation.
3. Moving to the next phase. While implementing phase 1, the agent by inertia adds a table from phase 2. Remedy: immediately after implementation, request "list the implemented files and verify against the task group".
4. Verification substitution. The agent writes "everything works, checked with curl", but it never ran curl. Remedy: re-run the commands from validation.md yourself; if there's no execution tool in the session, the agent couldn't verify.

These failures are not a reason to abandon the agent, but a reason not to take its word for it and keep fact-checking commands from validation.md and git diff at hand.

Example of Minimal Implementation

Expected changes for Hello Hono:

package.json
package-lock.json
src/index.tsx
src/pages/Home.tsx

src/components/Layout.tsx
static/style.css
tsconfig.json

If the agent adds a database, authentication, multiple pages, or a test framework, this is a boundary violation.

Verification After Implementation

Run the commands yourself, don't just trust the agent:

npm run typecheck
npm run dev

In another terminal:

curl -s http://localhost:3000 | head
curl -s http://localhost:3000 | rg "AgentClinic"

If the server starts but type checking fails, the feature is not ready. If type checking passes but the HTML doesn't match the check from validation.md, the feature is not ready.

Implementation Commit

Before committing:

git diff --stat
git diff

Ask Qwen Code to briefly explain the changes:

Briefly explain the differences of the current branch from main.
Group changes by task groups from the specification.
Don't modify files.

Then:

git add .
git commit -m "Implement Hello Hono baseline"

Practice

• [ ] Clear the Qwen context.
• [ ] Give the agent only the needed specifications.
• [ ] Implement the task groups.
• [ ] Check types and manual curl.
• [ ] Review the changes.
• [ ] Make a commit.

Review Questions

1. Why is it better to start implementation after /clear?
2. When can all task groups be implemented at once, and when should they be done one by one?
3. How can you tell that the agent has started implementing a future phase?