As AI writes more, I pay closer attention to how I decide.
From translation to a development partner: notes on shaping direction, scope, verification, and final decisions while working with AI.
RESEARCH NOTE01
From translation to shaping a way of working.
I did not begin with a defined workflow.
I started with Japanese translation and writing checks. As I learned, I began using AI for coding, SQL, and school projects, then tried tools such as Cursor and Copilot.
As projects and context grew, requirements could be forgotten and working changes could be undone. The shift was not one model suddenly becoming stronger; it was learning to shape how AI joins the work.
- 01
Language
Translation and Japanese writing
- 02
Learning
Coding, SQL, and coursework
- 03
Experiments
Local AI, OCR, and VLM
- 04
Workflow
Specs, agents, and review
02
Reduce ambiguity before asking AI to build.
For important work, the first step is often a conversation.
I discuss an early idea in chat, using questions and answers to clarify requirements, use cases, scope, and technical direction. For important work, a second AI can help surface what I may have missed.
For visual work, I shape an image direction and test it in a demo. Confirmed decisions then become a plan, AGENTS.md, DESIGN.md, scope boundaries, and evidence—so an agent does not have to guess again each round.
- 01
Questions
Explore through discussion
- 02
Requirements
Make the needs explicit
- 03
Direction
Set boundaries before building
03
Choose a workflow that fits the task.
A full team is not needed for every task.
A small, clear change can often be handled quickly with Codex and a focused check. Loading broad context and multiple agents for every task can make preparation heavier than the work.
For important, cross-module, or higher-risk work, I use a fuller path: brainstorm, specify, divide implementation, review from another perspective, and collect evidence. The process should fit the task.
| STEP | Small / clear | Complex / important |
|---|---|---|
| Task | Included | Not included |
| Codex | Included | Not included |
| check | Included | Not included |
| Brainstorm | Not included | Included |
| spec | Not included | Included |
| build | Not included | Included |
| review | Not included | Included |
| evidence | Not included | Included |
04
Implementation can be shared; responsibility stays human.
Human as PM does not mean stepping away from the technical work.
AI can think alongside me, help implement, and support review. I define the problem, choose direction, set scope, and verify the result.
Human as PM does not mean leaving technology behind. It means focusing more on understanding requirements, structural judgment, scope, priorities, and acceptance—while still deciding what to build and accept.
- Human
- Define · decide · direct · verify
- AI
- Think with me · build for me · review with me
05
Do not ask the implementing agent to own every judgment.
For complex work, separate roles and points of view.
For complex work, I may split implementation, difficult debugging, UI, visual QA, and review across agents. The point is not to maximize agent count, but to add a perspective that is not identical to the implementer’s.
I also bound what a reviewer sees—such as the design, plan, changed files, test results, and screenshots—so its conclusion has a visible basis.
- Plan
- Set the scope
- Build
- Work by assigned role
- Independent review
- Separate the writer and reviewer
- Verify
- Check the evidence
06
Look for visible evidence, not only a PASS.
I look for evidence suited to the task—type checks, tests, builds, diffs, or screenshots. For UI review, I also verify that the reviewer received the actual image pixels, not just filenames or descriptions.
An AI visual PASS is not acceptance. I inspect the result, request a fix when needed, and make the final decision myself.
- Change
- Inspect what changed
- Checks
- Typecheck · test · build
- Actual pixels
- Inspect the rendered page
- Human acceptance
- Make the final call
Passing tests do not prove that a page looks right.
07
Learning to set boundaries after context drift.
The issue was not that AI could not code; it was that the boundaries were unclear.
In early Cursor work, long or interrupted context sometimes lost confirmed decisions. That could lead to redoing completed work or creating overlapping changes.
Plans, scope, Git boundaries, independent review, and evidence helped me separate what an agent can explore from what a person needs to decide first.
Before
Prompt → generate → fix → repeat
Now
Define → bounded build → review → evidence
08
Tools change; human judgment stays at the center.
Using AI well is not a count of models or tools.
Experiments with local AI taught me that capability is only one factor: VRAM, quantization, context length, speed, stability, and cost all affect the experience. For large and complex work today, I mainly use cloud models while continuing local experiments.
To me, AI-assisted engineering means people keep the problem, direction, boundaries, and final decision, while AI expands thinking and execution. Tools will change; I still need to inspect the result myself.
- Local AI
- Continue exploring and learning
- Cloud models
- Mainly used for larger projects today
- Human judgment
- Set direction, boundaries, and acceptance