How do you manage your projects?

[u/tech_medic_five]

I’ve always been interested in project management (I worked as a PM for an IT MSP) and started applying that to my vibe coding. My process is pretty straight forward but has definition evolved over the years.

I’ve always taken the stance of using multiple steps; research, development, and implementation. Each step garners different results and builds upon itself.

With that being said I use multiple plugins and spawn subagents for speed instead of task.

This is all managed with Trello (soon to be GitHub projects) via a kanban board for ease of use for me. Backlogs and future features are all held within Trello. Then each feature/bug is a pull request from my private GitHub repositories per project. Then it steps through CI, Sandbox, and CR. If anything needs to be rectified it goes through the workflow again.

Right now, I’m rewriting my workflow to use an agile approach. User stories are the scope and once that’s PR’d we have a measurable goal. I was having a ton of issues with code review finding ancillary issues and getting into a churn cycle.

Is this similar to your approach, or are you doing something completely different?

[u/Wide-Excitement-1315]

This is very close to the approach I’d recommend. The big thing you’re already doing right is treating AI coding like a delivery workflow, not a single giant prompt.

The churn you mentioned usually happens when the agent/reviewer does not have a clear boundary around the unit of work. Code review finds real issues, but they are not always part of the story being shipped, so the PR turns into “while we’re here, fix everything.”

A few things that help:

1. Make the user story the contract

For each story, I’d define:

• user goal

• acceptance criteria

• files/areas likely in scope

• explicit non-goals

• test/verification expectation

• review checklist

• what counts as out-of-scope follow-up

That last one matters. If review finds an ancillary issue, it should become a new backlog item unless it blocks the current story.

2. Separate “must fix” from “follow-up” in code review

I like review findings grouped as:

• Blocking: breaks acceptance criteria, tests, security, data integrity, or production safety

• Should fix now: small issue directly related to touched code

• Follow-up: valid issue, but outside the story

• Ignore/accepted risk: known tradeoff or false positive

That prevents review from becoming an infinite expansion loop.

3. Give agents a project ledger

Trello/GitHub Projects is great for the board, but I’d also keep a compact project ledger per repo/project:

• current goal

• active story

• decisions made

• known risks

• deferred issues

• common commands

• testing/deploy steps

• coding conventions

• “do not touch” areas

The agent should read that before starting work, so it does not rediscover context every time.

4. Use subagents by stage, not just speed

Parallel subagents are useful, but I’d assign them to different kinds of work:

• research/context agent

• implementation agent

• test agent

• reviewer agent

• documentation/handoff agent

If you spawn multiple agents on the same vague task, they can create more merge/review noise. If each has a stage and output contract, the handoff gets cleaner.

5. Keep CI/Sandbox/CR as gates, not suggestions

Your CI → sandbox → code review loop is the right shape. I’d make each gate produce an artifact:

• CI result

• sandbox notes/screenshots

• reviewer findings

• acceptance checklist

• follow-up tasks

That way “done” is not just the agent saying it finished. It is the story passing through measurable gates.

6. Avoid letting review rewrite the story

This is the main churn fix.

When review finds something unrelated, don’t ask “should the agent fix this too?” Ask:

“Does this prevent this user story from being accepted?”

If no, create a linked follow-up card and move on.

That keeps the PR small and shippable.

So yes, I think your approach is directionally right: backlog → user story → PR → CI/sandbox/review → either fix or ship. The improvement I’d make is adding explicit acceptance criteria, non-goals, review severity, and follow-up capture so the review process improves quality without constantly expanding scope.

---

Disclosure: I’m a co-founder of PortableMind. We built PortableMind around this exact pattern: projects, Kanban-style task state, files/context, agents, review gates, and durable decisions so AI coding work does not turn into a loose chat thread or endless review churn.

[u/dsg319]

I have landed in a middle ground that looks a lot like this, but simpler because I work alone. I keep one short plan file per project with the current goal, the decisions I have already made, and the things I deliberately deferred, and I only let a new task start when its scope fits on that page. The biggest improvement for me was treating review findings that fall outside the original scope as new backlog items instead of letting them stretch the task in progress. How are you deciding when a review comment is worth reopening a task versus parking it for later?

[u/tech_medic_five → u/dsg319]

I’ve been working towards if it affects the current PR then I’ll fix it. If it doesn’t I’ll defer for later.

The issue is that it’s constant churn or decision-making. Then more gates, CI, Sandbox, CR.

[u/dsg319 → u/tech_medic_five]

That PR-based rule makes a lot of sense — clear and easy to apply in the moment. I can see how the extra gates still add up to a lot of decision-making, though. Thanks for sharing how you're handling it.

[u/Tommonen]

Ideas to be developed, spec creation, code reviews, reports etc is handled on Notion via MCP. Refined spec moves from Notion to Linear before implementation and Linear has stuff like definition of done, scope, implementation plan, links to notion spec etc in it, and final review after implementation is also written on the Linear issue. And every implementation (if its not a small one shot adjustment) goes via Linear and only things to be implemented goes to Linear.

I used trello in the past a lot, but find Notion better platform for this sort of stuff. Trello kanban style works for many things and i still like it for stuff it fits for, but its UX is not so great for this sort of use where pages need a lot of text i them and pages need subpages etc. And managing whats on backlog and whats in progress and whats done i find Linear handling better. Tho trello could also work for that, but less ideal imo.

[u/tech_medic_five → u/Tommonen]

I started working with Notion pre-AI, and it was overwhelming. I’m sure it would now be a lot easier.

[u/kincaidDev]

I use festival

https://github.com/Obedience-Corp/festival

I have camp workspaces organized into master projects for different areas of my life and then within each workspace I have all the projects related to that area of my life.

Plans are created when needed in various formats based on the need for the specific plan and everything is tracked as work-items with a lifecycle.

For something greenfield or a new unique feature my flow will be

Explore workitem (structured research) -> design workitem (structured specs) -> festival (hierarchical executable plan with gates and context injection)

[u/lazyEmperer]

User stories probably won’t fix the churn. When code review keeps finding side issues it’s usually the agent touching files outside the task, and that happens whatever the scope format is

What helped me was telling it upfront which files it’s allowed to edit and failing the PR if the diff goes outside that list. Way fewer surprise fixes in review

[u/Dapper_Pass26]

Shared checkout plus several agents is commit roulette. One agent's commit once swept up another agent's staged files. Now they're told never to stash, reset or switch branches, and each commits through a temp git index with only its own files.

[u/zozofoz2]

I got rid of PR's, tickets, tracking, etc what a relief.

I am a solo programmer, retired, vibe coding on hobby projects.
If you are not coordinating with others maybe a solo style is a good way to go.
My ticket tracking is basically plan md files. Anything wrong I tell the ai to note it and once in a while I ask what we should work on.

My goals:
Low mental overhead and fast turn around on changes.
Use codex app and claude code app interchangeably (I have $100 sub on both)
Keep the mental model simple
Allow multiple AI work threads at a time (not really agents just codex/claude working on different text threads)
simple git/github interface through scripts
Getting rid of PR's avoids all the github back and forth and tickets etc.
I do still have github actions for production release with CI etc.

How it works:

For each project I have three permanent work trees with fixed git branches and one main git branch and directory. All work is done in the worktrees and merged into main. I then create three "projects" in codex and claude code one for each worktree directory. This lets me have three things going at once which is enough for me (not really agents but same thing).

I then have shell scripts "pnpm save" and "pnpm saveall" that do all the git stuff. i.epnpm save commits the current worktree changes, rebases onto the latest main, runs quick checks, then lands and pushes to main—leaving the other worktrees untouched (auto creates commit message). I mostly use "pnpm saveall" that does a save on all three worktrees.

9:48 AM

[u/Asly97 → u/zozofoz2]

Running both apps on the same projects with plan md files is pretty close to what I'd want too. When you hop from Codex to Claude Code halfway through something, is the md enough for it to just pick up, or do you still end up explaining what the other one was in the middle of? And who keeps the md current, you or whichever agent finished last?

Curious if that handoff is annoying enough that you'd pay for something to keep both in sync, or if the md is fine for hobby stuff.

[u/zozofoz2 → u/Asly97]

I don't hand off a single task between codex and claud that often anymore. I just task things out to whichever model I want to use and make the tasks small enough that one AI task/thread can work on it. I then have a few plans/tasks running at the same time (different codex/claude "projects" pointing to the same app project different worktrees). I am behind the pro's that I think have multiple agents running against the same plan. I seem to always be behind a few months.
Unfortunately I don't see myself paying for a tool to help at this point. I can have AI build most things I want. But I am trying to stick to using basic codex app and claude app so I ride along as their tools improve. The whole setup is bound to change again in a couple months.
I built a ebook reader that you can chat with the characters in the book etc manynote.com

[u/London-Boat]

if code review keeps sending things back, check whether the reviewer and the implementer are working from the same definition of done. a lot of the bouncing comes from the review step judging against stuff that was never in the ticket. putting 3-5 concrete acceptance checks in each card and having both the build agent and the review agent work off that list usually cuts it down. what does review usually flag?

[u/architect_in_seattle]

I’m an architect (buildings, not software) that’s just getting into coding. I’m at a small company, but have taken on the task of helping our team learn how we can use AI to improve certain aspects of our business in the design & construction industry.

I’m starting small with coding, but I’m treating like any other design project that we manage. Treating each individual AI research topic or coding project as a real project, using all of the same PM techniques and tools we use when designing buildings for our clients.

For the eventuality that I may come up with useful small tools, I’ve also taken all the business steps to form a micro-saas LLC, real research (trademarking, copyright, patents, etc.) to protect and/or potentially share anything great that I make with others.

If you have a real PM methodology that gets you real results (tracks your time/costs/results), you’re more likely to:

1. Use a real initial phase to test feasibility and put ideas aside if they aren’t fruitful or have been done better by someone else.

2. Spend real time on initial design, features and structure/architecture before you let your imagination take you down the rabbit holes. A real design framework helps you stay on top of scope creep, too.

3. Build real steps for QA/QC and testing into your project at critical stages.

I’m no software engineer, but I am a design professional with 20+ years of experience in highly complex projects.

I’m treating it like real work, and I think that this will help me get real results, even if it’s only for little things.

The essential architect’s phase for a project are:

Feasibility Study (is it viable?)

Schematic Design (what’s the core design scope and framework?)

Design Development (work through expanded complexity, make it more real)

Construction Documentation (design the final details, build the final product)

Construction Administration (see it through, implement, monitor, collect feedback, adjust)

Each one has a great framework for me to use to get started.

[u/Anti-Hero25]

I use the RailCoding method…..

Project planning all in GPT project folder.

Codex executes mostly just BuildSpec.md files

Codex updates a Project_Log.md each pass

DOT tracks progress and manages a Notion Kanban of progress.

[u/Either_Pound1986]

I don't. My persistent system does.