AI · PRODUCT · UX · ENGINEERING
I build at the intersection of product thinking, UX and engineering. AI helps me explore ideas and ship faster. The hard part is using that speed to make a better product — not just a faster one.
Understand the problem. Engineer the context. Build with intention. Learn from the result.
Product-building loop
Understand the user, problem and opportunity.
Workflow
AI can get us to working software faster. Speed isn't enough — we need to solve the right problem. My workflow connects five stages, with Context Engineering in the middle — the product knowledge, design guidance and technical constraints that each stage uses.
Understand the user, problem and opportunity.
Output
A clear problem, what we think is true, and what to check next.
Turn the problem into a scoped solution and actionable requirements.
Output
A lightweight specification, prioritised scope, implementation plan.
Give AI the right context to build the right thing.
Output
The right context for this task — it guides implementation, so the agent builds the right thing.
Implement the solution in small, reviewable increments.
Output
A working prototype or feature that can be inspected and tested.
Evaluate the result, learn from feedback and improve the solution.
Output
What to keep, what to change, or what to rethink.
01 · Discover
A clear prompt cannot fix an unclear problem. Before I decide how to build something, I want to know who it is for, what they are trying to do, and whether this is worth building.
Four product risks
Before I ask AI to generate a solution, I check four product risks. They show what evidence is still missing — and whether the idea should go any further.
Are we solving a problem worth solving?
What users need, how they cope today, and whether a solution is worth it.
Can people understand and use the solution?
Explore user flows, test the prototype, and find where people get stuck.
Can we build and maintain it?
Can we actually build this with the stack, data and time we have?
Does the solution make sense for the business?
Is this worth the cost to run and keep?
AI summaries are input for the analysis — not proof that users want this.
02 · Define
I define the smallest useful solution and turn it into a plan. I use AI to explore approaches, clarify requirements, identify edge cases and break larger tasks into smaller implementation steps.
I don't write long docs for their own sake. Just enough that we know what to build — and can tell if the result is right.
Specification structure
03 · Context Engineering
A prompt describes the task. Context helps AI understand the product, its constraints and the decisions that shape a good solution.
I don't load the whole project into a prompt. I give the agent what it needs for this task — and keep that context updated as the product changes.
A / Context layer
What are we building, for whom and why?
Feeds from
I split agent work into small skills I can chain. Each has one job, clear inputs, an expected result, and instructions both I and the agent can follow.
skills/design-system/SKILL.md
Find the right components, tokens and layout rules — and use them the way the system intends.
Input
Tokens, component docs
Output
Design guidance
In Cursor, skills live in .cursor/skills/. Claude Code uses the same idea under .claude/skills/.
An agent cannot use an unwritten convention. If a form's validation or the right design-system component isn't written down, it will guess.
Compose small skills into a workflow instead of one skill that tries to do everything.
AGENTS.md is always-on guidance for the repo. Rules live in .cursor/rules/ as .mdc files — coding standards, accessibility, what not to change. Skills are folders you invoke, each with a SKILL.md. The same instruction should not live in both.
More context is not better context. Outdated notes and long chats introduce contradictions.
04 · Build
Choose one feature, component or user flow that contributes to the product goal.
Give the agent the task, relevant context, constraints and acceptance criteria. Ask for a plan when the task has meaningful complexity.
Use AI-assisted coding tools to generate, modify or refactor the implementation.
Review the code and the user-facing result against the specification, design system and existing architecture.
Correct problems, clarify missing requirements and improve the implementation before moving on.
Refine → next meaningful slice
05 · Validate & iterate
A prototype makes the idea real. I check it against the original problem, the expected behaviour, and the quality bar. If AI is in the loop, I also run evals.
Does the solution address the original problem?
Can users complete the intended task?
Does the implementation behave correctly?
Is the AI product or workflow performing well?
AI evals
Methods for measuring whether an AI product or workflow is performing well.
An eval asks: is this what I expect — and how often?
See what the AI made, and where it goes wrong.
An eval counts how often the result is actually good.
Change the workflow. Measure again. Keep what works.
Reusable workflows
The point is not just finishing one task faster. It is turning what works into something I can reuse — templates, conventions, focused agent instructions and quality checks.
Shared context. One source of truth for requirements, design conventions and technical decisions.
Principles