Blog

Agentic Coding in Practice

This is the workflow I use to go from rough idea to shipped product. I'm still learning, and sharing what works along the way.

April 20265 min read

I'm a designer learning to build. Most of my agentic coding happens on GigHub, a platform I'm building for musicians to find gigs. I'm a musician myself, so it lets me test the idea properly before sharing it with others.

The Setup

Most of the work happens in the terminal with Claude Code. Cursor comes in for local testing, checking what got built, and running agents in parallel when I need it. MCP links the stack together: Paper for design, Firebase, Notion, Playwright, Vercel, GitHub, and the Cursor browser.

What made this feel less random was using skills: reusable commands that load context, rules, and standards for me. These are the ones I use most:

superpowers:brainstorming: pressure-tests an idea before I commit to it
superpowers:subagent-driven-development: parallel work across multiple agents
sprint-ticket-review: acts like an engineering lead by reviewing each ticket against the actual codebase before any agent touches it
push-to-paper: syncs implementation code back into Paper via MCP so design and code don't drift
security-review: flags security issues before anything ships; useful when you don't have a dedicated security person
/critique, /audit, /harden for design review, quality checks, and production hardening as needed

Story to Production

Step 01

Brainstorm and build the Epic

I start by talking it through with Claude, either in a free-form chat or by running superpowers:brainstorming if I want to properly pressure-test the idea. If it still makes sense, I turn it into an Epic with clear stories.

Step 02

Stories into Notion

Stories go into Notion as tickets. Before any agent touches them, I run sprint-ticket-review. It reads each ticket against the codebase and adds missing implementation context. That one step has saved me a lot of rework.

Step 03

Sprint planning

I pick the sprint scope and move tickets to To Do. Nothing goes to an agent before this pass. Vague ticket in, vague output out.

Step 04

Design checkpoint

Before implementation, I decide if this needs design first or if I can iterate in code and polish after.

New layout, tricky interaction, or an unfamiliar pattern goes to Paper before code. If it's straightforward, I build first and use push-to-paper to sync and refine. Either way, design stays connected to implementation.

Step 05

Implement

I split the work between Claude Code and Cursoragents. Sometimes it's one agent, sometimes a few in parallel. I handle direction and quality checks; agents handle most of the execution.

Clear acceptance criteria really matters. If a ticket is fuzzy, agents invent scope: extra abstractions, config layers, features nobody asked for. The ticket is your contract.

Step 06

Security review

I run security-reviewbefore anything ships. As a designer, I don't always spot backend risk early. This is where I catch auth gaps, exposed data paths, and other production issues.

Step 07

Test and ship

Layered tests: Vitest for logic, Firebase emulator for rules, Playwright for full user journeys. I also sometimes use AntiGravity because having a separate agent run tests catches assumptions the implementation agent can miss.

If everything is green, I ship to Vercel, push rules with Firebase CLI, and sync status back to Notion via MCP.

What I've Learned

A few lessons that saved me the most time.

Plan before you build.

When tickets are reviewed well, I usually get mergeable output. When they're vague, I get cleanup work. Planning feels slow up front but saves time overall.

Test everything. Even if you're a designer.

Every time I skip tests to move faster, I pay for it later. Tests aren't just for engineers. They're how I ship without guessing.

You have blind spots on security and backend. Skills close them.

I don't naturally spot every auth and data edge case. security-review has caught things I would have missed, so now I run it every time.

Skills kill the context tax.

Without skills, each session starts with a long re-brief. Skills preload that context, so I spend more time building and less time repeating myself.

This workflow is still evolving, but it's stable enough to ship real work. If you're in product, design, or engineering and building with agents, I'd love to hear what's working for you.