I Stopped Managing AI Coding Work in Chat

A simple workflow I found useful for managing large coding tasks with AI agents.

I recently found a coding workflow that has been surprisingly useful for me.

It is not a new AI model.

It is not a new coding agent.

It is GitHub Issues.

More specifically, I started turning my conversations with AI agents into a structured set of GitHub Issues.

The idea is simple:

When a conversation leads to actual work, I turn that work into a parent issue and break it down into smaller child issues.

I didn’t start doing this because I wanted to build a sophisticated project management system.

I started doing it because I noticed a problem with the way I was working with AI agents.

The conversations were getting bigger.

The tasks were getting bigger.

And it was becoming harder to keep everything in my head.

It started with a real migration

I recently got assigned a website migration at my full-time job.

The company is changing its direction in terms of web technology.

We had been using Webflow and WordPress.

Now we are moving toward JavaScript frameworks that can be hosted on Vercel. The company also subscribed to Vercel Pro.

For this particular migration, I chose Astro.

For dynamic data and CMS, I chose Sanity.

So the project became something like:

Webflow → Astro + Vercel

and

Webflow CMS → Sanity

At first, I did what I normally do with an AI coding agent.

I started talking to it.

We brainstormed.

We looked at the existing website.

We discussed what needed to be migrated.

We discussed the new architecture.

We talked about the CMS.

We talked about things that might go wrong.

This part was useful because I didn’t have to know the entire solution before starting.

I could explore the problem with the agent.

But after the brainstorming, I didn’t want to immediately start coding.

I wanted a plan.

First, I asked the agent to make two plans

The migration actually contained two different problems.

The first was the website migration.

The second was the data migration.

So I asked the agent to turn our discussion into two high-level Markdown documents.

One document described the website migration.

The other described the CMS/data migration.

This gave me a much clearer picture.

The website migration plan contained things like:

• auditing the existing Webflow website
• setting up the Astro project
• rebuilding components
• migrating pages
• configuring Vercel
• handling redirects
• testing the new website

The data migration plan had a different set of problems:

• auditing the existing Webflow CMS
• designing Sanity schemas
• setting up the Sanity project
• migrating the data
• handling relationships
• validating the migrated content
• connecting Astro to Sanity

These documents were not meant to be a list of every tiny task.

They were high-level plans.

They helped answer:

What actually needs to happen?

But I still needed something better for answering another question:

What should I work on next?

That’s where GitHub Issues came in.

From plans to parent and child issues

After the high-level plans were ready, I asked the agent to break them down into GitHub Issues.

The big migration became the parent issue.

The individual pieces became child issues.

For example:

Migrate Webflow website to Astro
│
├── Audit existing Webflow website
├── Set up Astro project
├── Rebuild shared components
├── Migrate static pages
├── Configure Vercel
├── Implement redirects
└── Test production deployment

The CMS migration became another tree:

Migrate Webflow CMS to Sanity
│
├── Audit existing CMS collections
├── Design Sanity schemas
├── Set up Sanity project
├── Build migration script
├── Migrate CMS data
├── Validate migrated data
└── Connect Astro to Sanity

Now I had a much better structure.

The conversation was where I explored the problem.

The Markdown documents captured the high-level plan.

The GitHub Issues represented the actual work.

I could look at the parent issue and understand the bigger goal.

Then I could look at the child issues and see the pieces that needed to be done.

The conversation is no longer the project

This is probably the biggest change for me.

Before this workflow, a lot of the project existed inside the AI conversation.

We could have a long discussion about a feature.

The agent could understand the context.

We could make decisions.

Then I would move on to another task.

Later, I might need to remember what we decided.

That is not ideal.

The conversation is useful, but it is not a great project management system.

Now I think about it differently.

The conversation is where we think.

The issues are where the work lives.

If I close the AI session, the project does not disappear.

The parent issue is still there.

The child issues are still there.

The decisions are still documented.

And I can start a new AI session without expecting it to remember an old conversation forever, much like the session-based context workflow I use for AI agents.

It also gives the agent smaller problems

This workflow has another benefit.

AI agents are much easier for me to work with when the task has a clear boundary.

Compare these two instructions:

Continue the Webflow migration.

and:

Work on the issue for migrating the blog collection from Webflow CMS to Sanity.

The first one is huge.

The second one has a clear scope.

The issue tells the agent what the task is.

The parent issue gives it the bigger context.

And the repository gives it the actual code.

This means I don’t have to constantly tell the agent what it should and should not work on.

The issue already gives us a boundary.

But a child issue can still be a big task

This is where I added another part to the workflow.

A child issue does not necessarily mean a small task.

For example:

Build the Sanity migration script

might be only one child issue under the larger CMS migration.

But implementing it could still require a significant amount of code.

I might need to create new files, modify existing code, run tests, experiment with the data structure, and make several changes before it works.

So I added a simple rule:

If a task is substantial, give it its own Git worktree.

Why I use worktrees with AI agents

This became important because I sometimes want to start another AI session while the first one is still working.

Without worktrees, multiple agents can end up working in the same project folder.

That can get messy quickly.

One agent changes a file while another agent is editing the same file.

One agent runs tests while another agent changes the code those tests depend on.

An agent can also see changes made by another agent and assume those changes were part of its own task.

Files can overwrite each other.

Tests can become unreliable.

And the context of each agent becomes harder to reason about.

Git worktrees solve a big part of this problem.

Each worktree gives an agent an isolated working directory while still using the same Git history.

I think of them as separate desks in the same workshop.

The agents share the same project history, but they don’t have to work on the same desk.

So I can have something like:

Project
│
├── Main worktree
│
├── issue-21-saninity-migration
├── issue-24-blog-components
└── issue-27-redirects

One agent can work on the Sanity migration.

Another session can work on the blog components.

Another can handle redirects.

Their files are isolated from each other.

I don’t need to worry about one agent accidentally editing the files another agent is currently working on.

I don’t create a worktree for every issue

This is also important.

I don’t want to turn a simple coding task into a complicated process.

If the issue is something like:

Fix a typo in the footer.

I probably don’t need a worktree.

If it is a small CSS change, I can just work on it directly.

The rule is more like:

If this issue requires substantial code changes, create a dedicated worktree.

The issue tree tells me what needs to be done.

The worktree gives the agent a safe place to do it.

I put the rule in AGENTS.md

There is another small problem.

I don’t want to explain this workflow to the agent every time.

So I put a small rule in my AGENTS.md or CLAUDE.md.

Something like:

When a task requires substantial code changes,
create and work inside a dedicated Git worktree.

Do not perform substantial parallel work in the
main working directory when another agent session
may be active.

Now this becomes part of the project instructions.

The agent doesn’t need me to repeat the rule every time.

This is one of the things I like about working with coding agents.

When I discover a rule that makes my workflow better, I can turn that discovery into an instruction.

Instead of relying on my memory, I put the rule where the agent can see it too. This is the same kind of workflow change I explored when customizing Pi’s system prompt: put useful context where the agent can see it.

The workflow I ended up with

After all these small changes, my workflow looks something like this:

                AI conversation
                       │
                       ▼
                  Brainstorm
                       │
                       ▼
              High-level plans
                 /           \
                ▼             ▼
        Website migration   Data migration
                │             │
                └──────┬──────┘
                       ▼
                 GitHub Issues
                       │
                       ▼
                Parent issues
                       │
                       ▼
                 Child issues
                       │
                       ▼
              Is the task big?
                 /       \
               No         Yes
               │           │
               ▼           ▼
           Work directly  Git worktree
                            │
                            ▼
                       AI session

It looks more complicated when written down.

In practice, it actually makes my work simpler.

I don’t have to remember the whole migration.

I don’t have to keep one giant AI conversation alive.

I don’t have to manually remember every task I discover along the way.

And I don’t have to worry as much about multiple AI agents touching the same working directory.

Each part has a job.

The conversation is for exploration.

The Markdown plans are for high-level thinking.

The GitHub Issues are for execution.

The worktrees are for isolation.

And the AGENTS.md / CLAUDE.md rules make the workflow repeatable.

This is not really about GitHub Issues

The funny thing is, I don’t think the main lesson here is “use GitHub Issues.”

You could probably build a similar workflow with another issue tracker.

The useful part is the separation of concerns.

I don’t want one AI conversation to contain everything.

I want to move information from one layer to another.

First, explore the problem.

Then write down the plan.

Then break the plan into executable tasks.

Then give each task to an agent.

And when a task becomes large enough to interfere with other work, isolate it.

That makes the AI agent feel less like a chat window and more like a developer working inside a structured workflow.

The conversation can disappear. The issue should remain.

This is probably the simplest way I can describe why I like this workflow.

AI conversations are great for thinking.

They are great for brainstorming.

They are great for exploring problems that I don’t fully understand yet.

But I don’t want my entire project plan to live inside a conversation.

The conversation can disappear.

The model can change.

The session can end.

I can start another session tomorrow.

The work still needs to be there.

That’s why I started turning those conversations into issues.

The AI helps me think about the work.

GitHub helps me remember the work.

And Git worktrees help multiple agents work on that work without stepping on each other.

It is a small workflow change.

But for the way I work with AI coding agents today, it has made large tasks feel much more manageable.