Over the last few months, I've quietly but completely changed how I build software.

This wasn't a single "aha" moment. It was more like a slow realization that a lot of the friction I'd accepted as normal—planning overhead, missing context, endless clicking, poorly scoped tasks—wasn't actually required anymore.

This post walks through that workflow end-to-end, why it works so well, and why some tools I expected to matter (Jira, Asana, MCP servers) ended up being mostly unnecessary.

---

Why I Moved Away from Jira and Asana

I've used Jira and Asana for years. They're fine tools. Powerful, even.

But once I started doing serious work with AI agents, they stopped fitting the way I actually work.

The issues I ran into weren't philosophical—they were practical:

• Too much clicking
• Weak or awkward CLI tooling
• Context lives outside the repo
• Hard to programmatically create or update tasks exactly the way I want
• Planning and execution feel disconnected

I can make Jira or Asana work. With enough effort, plugins, or MCP servers, I'm sure I could recreate parts of this workflow.

But GitHub Issues and GitHub Projects have quietly become very good.

And more importantly: They live where the code lives.

That matters a lot once AI enters the picture.

---

The Core Idea: Treat the GitHub Issue as the Planning Document

I don't do a separate "planning phase" anymore.

I don't switch into some explicit AI planning mode.

Instead, planning naturally happens during the conversation with Claude, and the final output of that planning is a fully-fleshed-out GitHub issue.

That issue becomes:

If a junior developer were handed the issue, they'd have everything they need.

That's the bar.

---

Step 1: Start With Claude Inside the Repo

My workflow almost always starts at the command line, inside the repository I'm working on.

I launch Claude CLI right there. This is important.

Claude now has:

• The repo structure
• The existing code
• Access to CLI tools
• Access to GitHub via gh
• Whatever local context I choose to give it

If I'm working on a frontend feature that depends on a backend API, I'll feed Claude everything relevant:

• Links to backend pull requests
• API docs
• Code references
• Existing functions I want reused
• Prior implementation patterns

"Here's everything you'd need if you were another senior dev joining this project."

---

Step 2: Brainstorming, Outlining, and Over-Explaining (On Purpose)

This is where things start to feel different from traditional task creation.

We talk.

I'll brainstorm out loud:

• Different implementation approaches
• Tradeoffs
• Edge cases
• Things I'm unsure about

Claude might:

• Suggest alternatives
• Surface related code
• Propose pseudocode
• Identify risks I missed

I'll often ask for:

1. High-level architecture first
2. Then progressively lower-level detail
3. Then pseudocode
4. Then concrete steps

At this point, I'm wearing two hats:

Flesh this out so thoroughly that a junior developer could pick it up and succeed without interrupting anyone.

---

Step 3: Have Claude Create the GitHub Issue For Me

Once the task is fully thought through, I tell Claude to create the GitHub issue.

This is where the magic really kicks in.

Claude:

• Uses the GitHub CLI
• Applies my exact formatting rules
• Assigns the issue correctly
• Sets the right status
• Adds it to the right project
• Links related PRs or docs

No copying. No pasting. No forgetting to assign something. No "I'll fix that later."

The output is simply:

"Here's the issue: [link]"

I click it. I review it.

If something's off, I tell Claude:

• "Tweak this section"
• "Add more detail here"
• "Change the acceptance criteria"

Claude updates the issue directly.

The issue evolves through conversation, not clicking.

---

A Small but Powerful Hack: Voice-to-Text

One thing that dramatically improved this workflow is using Wispr Flow on macOS.

It's near-perfect voice-to-text.

So instead of typing long explanations, I often just talk.

It feels like:

• Pair programming
• Explaining a task to another developer
• Whiteboarding verbally

While Claude is thinking or working (sometimes for several minutes), I'll jump to something else.

Parallelism—both human and AI—is a real productivity unlock.

---

Step 4: Turn the Issue Into Code With One Command

Once the issue is ready and I decide to work on it, I run a single command:

From there, Claude already knows:

• How I pull from main
• How I name branches
• How I structure commits
• How I prefer PRs to look

Claude reads the GitHub issue exactly like a junior developer would—and then starts coding.

Depending on the task:

• It might take a few minutes
• It might take much longer

Eventually, Claude pushes a PR and gives me the link.

I also have a notification system that tells me when it's done.

---

Step 5: Review the PR Like a Normal Code Review

This part is important: I do not treat Claude's code as magical.

I review it exactly how I would another human's PR.

• Sometimes I run the code
• Sometimes I just read it
• Sometimes I spot issues immediately

Instead of inline comments, I usually go back to the CLI and just tell Claude:

• "This part should be refactored"
• "This logic is wrong"
• "Edge case here"
• "This naming feels off"

Claude updates the PR.

We go back and forth—just like real life.

Once I'm happy:

GitHub automation moves the issue to the correct state automatically.

---

Screenshots, Databases, and Treating Claude Like a Real Dev

A few other small but powerful patterns:

This feels exactly like working with a junior developer—except faster and always available.

---

Why I Don't Find MCP Servers Very Useful (Yet)

I've experimented with MCP servers.

They're interesting.

But honestly? If there's a CLI, I almost always prefer that.

The GitHub CLI alone can:

• Create and edit issues
• Manage PRs
• Assign projects
• Handle metadata

Claude using real tools feels more reliable than abstract integrations.

Less glue. Less indirection. More leverage.

---

The Real Win: No More Under-Scoped Tasks

The biggest frustration of my career hasn't been hard problems.

It's been starting a task without enough context.

That's usually not negligence—it's time pressure.

AI changes this.

That's a massive quality-of-life improvement for everyone.

---

Final Thoughts

I've been running this workflow for months now.

It's not fragile. It doesn't feel experimental. It just works.

GitHub Issues became my planning docs. Claude became my project manager, junior developer, and coding partner. And I spend more time thinking, reviewing, and shipping—and less time clicking.