A day in the life with AI

AI runs through most of my working day. I research with it, shape with it, build with it and review with it. This is how each step works, and the system that keeps the output consistent.

01 Context

Context is the design material

A model only knows what you hand it at the moment you ask. So I keep a local wiki for each product I work on, built on the llm-wiki pattern. Research goes in as raw sources, and an agent compiles it into cross-linked articles on the domain, the market and the open decisions. When I plan a feature, the model reads the wiki first and cites it.

Product wiki Domain rules Customers Competitors Market Open decisions Build plan Spec
  1. 01

    Ingest

    Articles, regulations, competitor pages and my own notes land in the wiki as raw sources.

  2. 02

    Compile

    An agent writes articles that link to each other and flags where sources disagree.

  3. 03

    Query

    Plans, specs and decks draw on the wiki with citations, so they rest on research the model can show.

  4. 04

    Build

    The prototype starts from that plan, inside the design system.

A wiki usually covers the domain's rules, the customers, the competitors and the decisions still open. It turns into the documents I act on, such as specs and build plans.

The links between articles work like a mind map. A question about one rule can pull in the research behind it, what competitors do about it and the decisions already made, so a plan starts from the whole picture. I run more than a dozen of these wikis, one per product, and the research compounds over months instead of disappearing with each chat.

02 Research

Research runs in parallel

When a question is bigger than one search, I split it across several agents at once. Each one takes an angle, reads the sources it finds and files them into the wiki, and the findings compile into articles with citations I can check.

For a decision, I state it as a thesis and ask for the evidence on both sides before I accept a verdict. Models tend to agree with the framing they're given, so I ask for the case against my position too.

03 Shape

Shape the work before anyone builds it

My shaping borrows from Basecamp's Shape Up. Before a project starts, I define the problem, decide who on the team needs to be involved and write down the goes and no-goes, so everyone knows what is in bounds.

Shape Up keeps the interface rough on purpose, with breadboards and fat-marker sketches. I front-load it instead. The screens come from a defined design system, so I can shape with real components, and the pitch arrives as an artifact people can use. Most often that is a clickable prototype I build as a Claude artifact.

From there, I build it myself or an engineer picks it up, and we refine it together as we go. Engineers start from something they can click through.

When the shape needs more than a prototype, agents work in Figma through its plugin API. They lay out wireframes and screens from the design system's components and variables and wire the prototype links. I review each screen and spend my time on the information architecture, the states a screen has to handle and what it leaves out.

  • Problem

    What is broken and for whom, defined before any screen exists.

  • Team

    Who needs to be involved, and at which point they come in.

  • Goes and no-goes

    What is in bounds, and what we have agreed to leave out.

  • Solution

    An artifact the team can use, most often a clickable prototype.

04 Standards

My standards, written down

Without guidance, models fall back on the most common patterns. I write my standards down so each session starts with them.

Writing rules cut the patterns that make text read as generated, like em dashes and stacked colon lists. Design rules cover what I catch in review, from sentence-case labels to real photos of people instead of initials. When I correct something, I save it as a rule with the reason attached, so I only have to make that correction once.

memory/no-all-caps-eyebrows.md
---
name: no-all-caps-eyebrows
type: feedback
---

Never set eyebrows, section labels, table headers or small
captions in all caps. Use sentence case at medium or semibold
weight, one size smaller, in the muted text colour.

Why: the uppercase eyebrow is a common tell of
AI-generated UI, and I want it out of my work.

How to apply: label helpers never uppercase text.
Table headers use the body font at medium.

05 Build

Build inside the system

I work across a mix of models, hosted frontier models alongside open weights, and match the model to the task. I write my own plugins and skills for the agents I use. I prototype in code early, beside the Figma file, so I can try an idea in the browser before I commit to it.

Without a system, every prompt makes a new design decision and the product drifts with each generation. So my prototypes start inside a design system, which gives a generated screen the same components, form styling and navigation patterns a person would reach for.

Design system Prompts Product

06 Review

Review before it ships

Before anything ships, I run agents against it to find problems, then decide which findings are worth fixing.

  • Red team

    Attacks the plan for failure modes and edge cases before any code exists.

  • Scope check

    Flags hidden complexity and unclear requirements in a feature request.

  • Code review

    Reads the diff for correctness bugs, then for duplication and simplification.

  • Accessibility

    Checks contrast, focus, labels and keyboard paths against the screens.