How I Use AI

A creative process, not a productivity hack

Mike Joyce · 2026

My Mission

Find useful ways to spend tokens that give me operational leverage.

That's it. Everything else follows from this.

The Mindset Shift

Craftspeople Build Their Tools

An oboe player doesn't buy reeds off the shelf.

A blacksmith doesn't buy their hammers.

The tool-making is part of the craft.

If I was a blacksmith that made a hammer for me, it would be different than the hammer you'd make for yourself. It's a deeply personal thing.

This is a creative endeavor. Not homework. Not a box to check. You're building capabilities that make you more of what you already are.

How This Actually Developed

Each build was faster than the last. The models improved. My ability to invoke them improved. The context infrastructure compounded.

"I Wish It Had Context For..."

Build the context.

ChatGPT tries to build a graph for me that is pretty garbage. I have my own graph that I curated, and I can invoke it with any agent on any platform.

~/knowledge/           ← personal knowledge graph
├── CLAUDE.md          ← agents read this first
├── people/            ← who I work with
├── projects/          ← what I'm working on
├── reference/         ← methodology, conventions, tenets
├── domains.md         ← how my world is organized
└── every repo/
    └── CLAUDE.md      ← project-specific context

This is context infrastructure. Portable. Curated. AI agents always have what they need because I built it.

Planning Is The Work

People underestimate how much time goes into planning and spec'ing.

A recent feature: exposing an API for customer context.

• A few hours in plan mode — thinking through the design
• 15 tickets split out with clear scope
• A couple hours of actual implementation

The ratio matters. This isn't "type a prompt, get code." It's careful consideration of what to build and why.

Sometimes I don't feel like coding. I just want to do some planning, do some thinking. So I cut a bunch of tickets. Maybe I come back to them three days later.

Agents Get Better When You Build Them Better

Start using the agent. Hit a wall. Fix the wall.

• Agent doesn't research before creating docs? Add that behavior.
• Agent needs customer context every session? Build a context API.
• Agent can't extract taste from transcripts? Create that skill.

This is iterative. You don't design the perfect agent up front. You start building, hit a headwind, and add the capability that removes it.

The agent improves because you systematically address what's missing. Each addition compounds.

What This Looks Like in Practice

Real tickets from a repo — click one to see the full spec:

TASTE = philosophy + constraints + output_contracts + behavioral_rules

How Collaboration Actually Works

When Alex and I started working together, it was hard.

He'd think of something to build. He'd call me. I'd already built it and was way ahead. He was sad because he spent time thinking about something I'd already done.

It transformed when we each had end-to-end ownership.

• Instead of asking me to add a feature — he adds it himself, or cuts a ticket
• When he's not sure how — he uses plan mode to spec it out, then cuts the ticket
• When I want to do a big refactor — I plan only, create a backlog of issues

The lesson: 2-person teams work when both people can do everything end-to-end. Dependency on one person is a bottleneck.

The 90% Threshold

LLMs open up a new class of problems that aren't pass/fail.

When you download a file, there's one right answer. When you write an email, there are thousands of right answers.

The goal isn't to remove humans. It's to make humans faster, more informed, more responsive.

90% accuracy is genuinely good enough for most use cases. Human review is part of the design.

Capabilities, Not Systems

The instinct is to build a system that solves a problem completely. A "platform."

Systems are expensive, brittle, and take forever. By the time they ship, the problem has evolved.

The better question: what capabilities would make your people faster and better at what they're already doing?

A capability doesn't replace what someone does — it amplifies it. It doesn't require a workflow redesign — it slots into how they already work.

Systems are expensive and brittle. Capabilities are cheap, composable, and compound.

The Math of Marginal Gains

If you want to double your output, don't look for one thing that makes you twice as good.

Find a hundred things that each make you 1% better.

Easier to find. Easier to implement. Less risk you'll get it wrong. And they compound.

1.01¹⁰⁰ = 2.7x

Every workflow has a hundred small frictions. "Where's that file?" "What were the requirements on the last one?" "Did we do something like this before?"

Remove a hundred small frictions and you've transformed how work gets done.

Bottom-Up, Not Top-Down

A UX designer at a major scooter company builds software for warehouse operations. Corporate tries to help, but it takes forever.

Berlin and New York have different needs. Different constraints. Different workflows.

The Berlin hub — staffed with people who know Claude Code — started building their own dashboards. Not because they wanted to go rogue, but because they needed tools and couldn't wait.

This is bottom-up software development. It's happening now.

The question for leadership isn't "how do we stop this?" It's "how do we enable it?"

Responsiveness vs. Stability

Traditional software development optimizes for reliability at the cost of responsiveness.

The promise: wait long enough and you'll get something stable that works for everyone.

The reality: by the time it ships, requirements have changed, and people find workarounds anyway.

I would rather have responsiveness than a promise of stability with a week-and-a-half turnaround. I would make that trade-off every time.

If a tool is useful to a team in isolation, and there's a backup plan if it breaks, that's good enough.

The Enablement Model

Imagine a team of one UX designer and one product engineer that travels to the Berlins of the world and just builds solutions.

Not requirements gathering. Not design review meetings. Not alignment sessions with management. Just: understand the problem, build something, see if it works.

The learnings feed back to product teams. Instead of product trying to anticipate needs from a distance, they receive validated solutions from the field.

Software Is Ephemeral Now

Building used to be expensive. So you'd plan carefully, review thoroughly, commit reluctantly.

Building is cheap now. Rebuilding is cheap now.

I rebuilt the same app for GCP, Azure, Cloudflare, and AWS — all in one day. From scratch. Including all the infra.

Stop being precious about code. Start being precious about outcomes.

Think in Timeboxes

The question isn't "how long will this take?" — it's:

A 1-day build that proves something is feasible is worth more than a 6-month plan that never ships.

Every Build Makes the Next One Faster

My progression: markdown notes → canvases → full applications.

Each time, faster. Models improved. My skill improved. The context compounded.

Total time spent building swerk was less than the time it would have taken to do proposals the old way. And the quality was higher.

This is the path for everyone:

• Build something small for yourself
• Notice what slowed you down
• Build a tool to fix that friction
• Use that tool on the next build
• Repeat — the leverage compounds

The Real Work

AI handles production. You handle:

• Deciding what's worth building
• Knowing when something is good enough
• Understanding what the customer actually needs
• Making judgment calls the models can't

I am a critical input to this process. It is not me yoloing "I want an app." My judgment is the direction.

None of this is "prompting." It's building.

Show, Don't Tell

Every time we talk to a customer, we want to show them something. Something that's for them.

Not a deck. Not a proposal. Something they can react to.

The question I ask: What could we build in one day for this use case?

Do that 10 times and you get really good at product thinking, using the tools, and understanding customers. Low stakes. High learning.

Start by starting.

AMA

What would you build for yourself if building were cheap?

That's your starting point.