How I work

I stopped prompting and started designing the process.

As a non-technical designer, I've built a workflow where AI handles much of the implementation, while planning, execution and verification remain deliberately separated. I can spend as much time as necessary understanding a problem before anything gets built.

PlanDefine the problem. Approve the specification.

BuildExecute approved work in bounded phases.

VerifyCheck intent, quality, behavior, and safety.

ShipReview, merge, and preserve project context.

01 · Plan

A good plan starts with a well-defined problem.

AI supports the planning process rather than simply generating code. I use a separate planning space to define the problem, evaluate options, and produce an approved specification before implementation begins.

Planning and implementation happen in separate spaces. No code changes begin until the scope and acceptance criteria are clear.

Planning space · Cowork

Define problemWhat are we actually solving?

Use casesWhat do they need to do?

DiscussionExplore, challenge, compare.

Draft plansDefine scope, requirements, constraints.

Final specOnly when the plan is ready.

02 · Build

Complex features don't get built in one giant leap.

Each feature is divided into phases. A phase is implemented, checked and only then does the next phase begin.

Execution space · Claude CodeApproved final spec

Execute the specStay within the approved scope.

Work phase by phaseComplexity is deliberately contained.

Verify before moving forwardEvery phase has a quality gate.

Splitting into phases reduces the mistakes AI makes, since the context won't get bloated fast. Only once a phase is tested and confirmed is the next one drafted. So any error can be caught earlier. For example:

Phase 00: Master plan
Phase 01: Build → test → review
Phase 02: Build → test → review
Phase 03: Build → test → review
Phase 04: Build → test → review → merge

03 · Verify

Verification is where patience pays.

I don't trust a feature because an agent says it works. Different kinds of quality need different kinds of checks.

Manual eye testVisual quality, interaction, product intent and anything that requires human judgment.

Code reviewImplementation quality, consistency, maintainability and alignment with the specification.

Architecture auditSystem boundaries, patterns, technical decisions and architectural rules.

Safety auditCheck behavior and implementation against the safety constraints of the product.

PR reviewReview the complete change before it becomes part of the product.

DocumentationImportant decisions, rules and system knowledge remain persistent rather than disappearing in chat.

04 · Ship

Shipped only when it is reviewed, approved, and recorded.

PR review: Review the complete change before it enters the product.
Quality gate: Required checks pass. Failed checks return to iteration.
Merge: Merge the approved change through Git.
Update context: Record decisions, rules, and lessons for future work.

The workflow is designed to make drifting difficult.

Plans are stored and organized. Rules persist. Execution follows approved specifications. Progress happens in bounded phases.

Persistent contextRules live with the project.The AI doesn't have to rediscover the operating rules every time. The project carries the constraints that keep planning, execution and verification aligned.

Controlled autonomyI define intent. AI carries the weight.I don't need to micromanage implementation. I need to establish what good looks like — then I let specialized agents do the repetitive work of getting there.

The system is portable; the controls stay consistent.

The workflow is not tied to one workspace or model. Planning, execution and review can happen in different tools; the shared contract remains the same: explicit intent, an approved specification, bounded work, verification, and a Git-backed record of change.

Git is the record of approved decisions and the safety boundary for change.