10 ms·

Show HN: Project management system for Claude Code

175 points by aroussi 1y ago

I built a lightweight project management workflow to keep AI-driven development organized. The problem was that context kept disappearing between tasks. With multiple Claude agents running in parallel, I’d lose track of specs, dependencies, and history. External PM tools didn’t help because syncing them with repos always created friction. The solution was to treat GitHub Issues as the database. The "system" is ~50 bash scripts and markdown configs that: - Brainstorm with you to create a markdown PRD, spins up an epic, and decomposes it into tasks and syncs them with GitHub issues - Track progress across parallel streams - Keep everything traceable back to the original spec - Run fast from the CLI (commands finish in seconds) We’ve been using it internally for a few months and it’s cut our shipping time roughly in half. Repo: https://github.com/automazeio/ccpm https://github.com/automazeio/ccpm It’s still early and rough around the edges, but has worked well for us. I’d love feedback from others experimenting with GitHub-centric project management or AI-driven workflows.

yodon 1y ago
Lots of thought went into this. It would be very helpful to see examples of the various workflows and documents. Perhaps a short video of the system in use?
- aroussi 1y ago
  Great idea! I'll whip something up over the weekend and post the video here and on the repo
- cahaya 1y ago
  I was also looking for a video. The concept sounds good, but feels like I need to learn a lot of new commands, or have a cheat sheet next to me to be able to be able to use the framework.
  - aroussi 1y ago
    Cheatsheet is available via /pm:help With that being said, a video will be coming very soon.
- raimille1 1y ago
  Agree! I see a lot of pontential here, just hard to get a grasp.
nivertech 1y ago
Task decomposition is the most important aspect of software design and SDLC. Hopefully, your GitHub tickets are large enough, such as covering one vertical scope, one cross-cutting function, or some reactive work such as bug fixing or troubleshooting. The reason is that coding agents are good at decomposing work into small tasks/TODO lists. IMO, too many tickets on GitHub will interfere with this.
- aroussi 1y ago
  I agree wholeheartedly! When we break down an epics into tasks, we get CC to analyze what can be run in parallel and use each issue as a conceptual grouping of smaller tasks, so multiple agents can work on the same issue in parallel. The issues are relatively large, and depending on the feature, every epic has between 5 to 15 issues. When it's time to work on the issue, your local cloud code will break it down into minute tasks to carry out sequentially.
jdmoreira 1y ago
I'm a huge fan of Claude Code. That being said it blows my mind people can use this at a higher level than I do. I really need to approve every single edit and keep an eye on it at ALL TIMES, otherwise it goes haywire very very fast! How are people using auto-edits and these kind of higher-level abstraction?
- Nizoss 1y ago
  Same, I manually approve and steer each operation. I don't see how cleaning up and simplifying after the fact is easier or faster.
  - CuriouslyC 1y ago
    That kills iteration speed. Carefully outline, get it to write tests first, then let it go wild and verify the tests while it's doing that. If there are test issues, tell it so without interrupting it, and it'll just queue up those fixes without having to stop and be re-routed. You want to periodically have coverage improvement -> refactor loops after implementing a few features. You can figure out the refactors you want while the agent is implementing the code, after you've sussed out any test issues, then just queue up instructions on how to refactor once the tests are passing.
- allisdust 1y ago
  Through multi pass development. It's a bit like how processes happen inside a biological cell. There is no structure there. Structure emerges out of chaos. Same thing is with AI coding tools. Especially Claude code. We are letting code evolve to pass our quality gates. I do get to sit on my hands a lot though which frees up my time.
  - aroussi 1y ago
    Yeah, I agree. I never let the AI make any architectural decisions (and I also watch Claude Code like a hawk lol). That being said, since we started using this system, we noticed that our PRDs and implementation plans (epics) became more detailed, giving the AI a lot less wiggle room. Essentially, I'm treating Claude Code as a very fast junior developer who needs to be spoon-fed with the architecture.
swader999 1y ago
The advantage with using multiple agents is in context management, not parallelization. A main agent can orchestrate sub agents. The goal is to not overwhelm the main agent with specialized context for each step that can be delegated to separate task focused agents along the way. Test runner sub agent knows exactly how to run tests, summarize failures etc. It loads up all the context specific to running tests and frees the main agent's context from all that. And so on...
- aroussi 1y ago
  100%! Use agents as "context firewalls". Let them read files, run tests, research bugs, etc, and pass essential data back to the main thread.
thomask1995 1y ago
OK I need to give this a go. tbh, I've been going back to just writing stuff manually and asking ChatGPT doc questions. I talked to and extremely strong engineer yesterday who is basically doing exactly this. Would love to see a video/graphic of this in action.
- aroussi 1y ago
  I'm going to create a video and post it both here and on the repository over the weekend
  - stronglikedan 1y ago
    And I'm going to reply here so that I remember to check back! Thanks!
    - greggh 1y ago
      Good idea. I'd love a video.
jamauro 1y ago
Looks interesting. How do you make sure that agents that need to collaborate on the solution actually collaborate if they’re working in parallel?
- aroussi 1y ago
  We gave up on that dream a while back lol. Instead, we analyze which tasks can be run in parallel (different files, etc) and which need to be worked on sequentially.
  - robbs 1y ago
    Have you found a way to have the AI assist in analyzing?
nikolayasdf123 1y ago
when you go to their website some person immediately starts talking to you at the bottom left corner. this is hilarious, websites today got to tune it down a bit with sales
nikolayasdf123 1y ago
their website also features some shredded bold dude. got to respect their sales skills
dcreater 1y ago
This is a more advanced version of what I'm doing. I was impressed that someone took it up to this level till I saw the tell tale signs of the AI generated content in the README. Now I have no faith that this is a system that was developed, iterated and tested to actually work and not just a prompt to an AI to dress up a more down to earth workflow like mine. Evidence of results improvement using this system is needed.
- aroussi 1y ago
  Damn those em dashes lol Kidding aside, of course we used AI to build this tool and get it ready for the "public". This includes the README. I will post a video here and on the repository over the weekend with an end-to-end tutorial on how the system works.
  - dcreater 1y ago
    Videos would be great, but what you be better are real trials using a) vibe coding b) basic CLAUDE.md c) your system P.S: And it wasnt the em-dashes, its the general structure and the recognizable bullet points with emojis.
mustaphah 1y ago
TL;DR workflow phases: - Brainstorm a PRD via guided prompts (prds/[name].md). - Transform PRD into epics (epics/[epic-name]/epic.md). - Decompose epic into tasks (epics/[epic-name]/[feature-name]/[task].md). - Sync: push epics & tasks to GitHub Issues. - Execute: Analyze which tasks can be run in parallel (different files, etc). Launch specialized agents per issue.
- apwell23 1y ago
  tl;dr break shit down into small chunks
apwell23 1y ago
> With multiple Claude agents running in parallel Are ppl really doing this? My brain gets overwhelmed if i have more than 2 or 3.
- aroussi 1y ago
  OP here. It really depends on how you use parallel agents. Personally, I don't run multiple instances of Cloud Code nor do I use multiple screens. I find it hard to focus :) That being said, if a task requires editing three different files, I would launch three different sub-agents, each editing one file, cutting down implementation time by two-thirds.
tmvphil 1y ago
Sorry, I'm going to be critical: "We follow a strict 5-phase discipline" - So we're doing waterfall again? Does this seem appealing to anyone? The problem is you always get the requirements and spec wrong, and then AI slavishly delivers something that meets spec but doesn't meet the need. What happens when you get to the end of your process and you are unhappy with the result? Do you throw it out and rewrite the requirements and start from scratch? Do you try to edit the requirements spec and implementation in a coordinated way? Do you throw out the spec and just vibe code? Do you just accept the bad output and try to build a new fix with a new set of requirements on top of it? (Also the llm authored readme is hard to read for me. Everything is a bullet point or emoji and it is not structured in a way that makes it clear what it is. I didn't even know what a PRD meant until halfway through)
- jcmontx 1y ago
  Waterfall is what works for most consulting businesses. Clients like the buzz of agile but they won't budge on scope, budget or timeframe. You end up being forced to do waterfall.
  - dc10tonite 1y ago
    Yep. And you often end up doing waterfall with a veneer of agile that ends up being worse than either one.
    - andrekandre 1y ago
      this has been my experience too, its horrible because everyone does all the agile meetings and "planning" but its just used as progress reporting to the product managers... if thats all thats 'agile' being used for just do daily reporting and be done with it
  - tmvphil 1y ago
    Waterfall might be what you need when dealing with external human clients, but why would you voluntarily impose it on yourself in miniature?
tummler 1y ago
A project management layer is a huge missing piece in AI coding right now. Proper scoping, documentation, management, etc is essential to getting good results. The people who are having the most success with “vibe coding” have figured this out, but it should really be incorporated into the process.
moconnor 1y ago
"Teams using this system report: 89% less time lost to context switching 5-8 parallel tasks vs 1 previously 75% reduction in bug rates 3x faster feature delivery" The rest of the README is llm-generated so I kinda suspect these numbers are hallucinated, aka lies. They also conflict somewhat with your "cut shipping time roughly in half" quote, which I'm more likely to trust. Are there real numbers you can share with us? Looks like a genuinely interesting project!
- aroussi 1y ago
  OP here. These numbers are definitely in the ballpark. I personally went from having to compact or clear my sessions 10-12 times a day to doing this about once or twice since we've started to use the system. Obviously, results may vary depending on the codebase, task, etc., but because we analyze what can be run in parallel and execute multiple agents to run them, we have significantly reduced the time it takes to develop features. Every epic gets its own branch. So if multiple developers are working on multiple epics, in most cases, merging back to the main branch will need to be done patiently by humans. To be clear, I am not suggesting that this is a fix-all system; it is a framework that helped us a lot and should be treated just like any other tool or project management system.
  - datadrivenangel 1y ago
    How many feature branches can you productively run in parallel before the merge conflicts become brutal?
    - CuriouslyC 1y ago
      That depends on how decoupled your codebase is and how much overlap in the areas being worked on by your agents are. If you have a well architected modular monolith and you don't dispatch overlapping issues, it's fine.
    - aroussi 1y ago
      That's where the human architect comes in (for now at least). We'll try to think of features that would have the least amount of conflicts when merged back to main. We usually max it at 3, and have a senior dev handle any merge conflicts.
penguin202 1y ago
[dead]
brainless 1y ago
I love what is happening in this domain, so many people experimenting. Thanks for sharing this. I recently launched https://letsorder.app https://letsorder.app, https://github.com/brainless/letsorder https://github.com/brainless/letsorder. 100% of the product (2 web UI apps, 1 backend, 1 marketing site) was generated by LLMs, including deployment scripts. I follow a structured approach. My workflow is a mix of Claude Code, Gemini CLI, Qwen Code or other coding CLI tools with GitHub (issues, documentation, branches, worktrees, PRs, CI, CodeRabbit and other checks). I have recently started documenting my thoughts about user flow with voice and transcribe them. It has shown fantastic results. Now I am building https://github.com/brainless/nocodo https://github.com/brainless/nocodo as the most ambitious project I have tried with LLMs (vibe coding). It runs the entire developer setup on a managed Linux server and gives you access through desktop and mobile apps. All self-hosted on your cloud accounts. It would basically be taking an idea to going live with full stack software.
- tantanu 1y ago
  just out of curiousity, I tried letsorder using the demo you provided. The QR code generation seems to work ok, and then using the table specific menu I tried to put in an order, and got HTTP500 for both the quick order and the other flow. this is entirely my own opinion and may not reflect your experience but this fits in with everything else I've seen that is LLM generated. It looks complete and works for the most part, except the most business critical part. Maybe the ordering flow does work, but how much traction are you going to really get without the demo actually doing what it's supposed to? Not trying to be snarky - just trying to understand if people actually pay for mediocre or low-quality products like these
  - brainless 1y ago
    You are not being snarky at all. I am sure the bug exists. There are a few out there and I still have not gotten to fix them. This is nothing to do with LLM generated. I work on about 4-5 projects at the moment, https://github.com/brainless https://github.com/brainless. All of them are to test how far LLM driven development go. This, along with time to daily reach out to people, create posts, host lessons on vibe coding: https://lu.ma/user/brainless https://lu.ma/user/brainless I will get these bugs sorted when I get some time. Let's Order is not a commercial project, it is an exercise to show what a solo founder can get done these days with LLMs.
royletron 1y ago
It still feels like the more context the agents have the worse the response becomes - and simulataneously the more money ends up being thrown at Anthropic. I have to handhold agents to get anywhere near stuff I actually want to commit with my name on.
- aroussi 1y ago
  That's exactly why we use separate agents as "context firewalls". Instead of having the main thread do all the work and get its context polluted, with sub-agents, each agent works on one thing, then provides a summary to the main thread (much smaller context use) as well as a detailed summary in an empty file.
Nizoss 1y ago
I'm genuinely curious to see what the software quality looks like with this approach. Particularly how it handles complexity as systems grow. Feature development is one thing, going about it in a clean and maintainable way is another. I've come across several projects that try to replicate agile/scrum/SAFe for agents, and I'm trying to understand the rationale. Since these frameworks largely address human coordination and communication challenges, I'm curious about the benefits of mapping them to AI systems. For instance, what advantages does separating developer and tester provide versus having unified agents that handle both functions?
- aroussi 1y ago
  The real idea is to make sure that each agent works in its own little world and documents everything. So the main thread context is occupied with the understanding of the project instead of code snippets.
linkage 1y ago
Looks like a simpler version of BMAD https://github.com/bmad-code-org/BMAD-METHOD https://github.com/bmad-code-org/BMAD-METHOD
dalore 1y ago
how to use it on an existing repo that has a few issues, a milestone, labels, etc?
- aroussi 1y ago
  We created a "/pm:import" command before making this project public to pull existing repo issues into local. Hopefully, this will work well. We have tested it, but this is not one of the functionalities that we use on a daily basis internally. Fingers crossed :)
blancotech 1y ago
I’m curious how any project management to code agent workflow can be successful given how messy the process is in real life. Especially discovering unknown unknowns that lead to changes in your original requirements. This often happens at each step of the process (e.g. when writing the PRD, when breaking down the tickets, when coding, when QAing, and when documenting for users). That’s when the agent needs to stop and ask for feedback. I haven’t seen (any) agents do this well yet.
- CuriouslyC 1y ago
  This will be a solved problem soon. With an agent wired up to slack, elastic (for all org docs) and your code base, it can iterate over high level project documents with stakeholders, clarifying things, noting codebase challenges that will need to be addressed and creating PM artifacts.
vemv 1y ago
It will increasingly become common knowledge that the best practice for AI coding is small edits quite carefully planned by a human. Else the LLM will keep going down rabbit holes and failing to produce useful results without supervision. Huge rules systems, all-encompassing automations, etc all assume that more context is better, which is simply not the case given that "context rot" is a thing.
- aroussi 1y ago
  The system is trying to solve: breaking down large projects into small tasks and assigning sub-agents to work on each task, so the code, research, test logs, etc. stay inside the agent, with only a summary being surfaced back up to the main thread.
poopiokaka 1y ago
Make it work with gitlab
CuriouslyC 1y ago
You should just try to integrate your work with Vibe Kanban, I'm pretty sure it's going to be the winning tool in this space.
euroderf 1y ago
AI n00b here. I wonder if this workflow is possible: I point Claude to my codebase, and Claude writes up a PRD that matches/reflects/describes the codebase. Then I iteratively (a) edit the PRD to reflect where I want my codebase to go, and (b) have Claude execute on it.
gucrol 1y ago
[dead]

175 points by aroussi 1y ago

yodon 1y ago

Lots of thought went into this. It would be very helpful to see examples of the various workflows and documents. Perhaps a short video of the system in use?

aroussi 1y ago
Great idea! I'll whip something up over the weekend and post the video here and on the repo
cahaya 1y ago
I was also looking for a video. The concept sounds good, but feels like I need to learn a lot of new commands, or have a cheat sheet next to me to be able to be able to use the framework.
- aroussi 1y ago
  Cheatsheet is available via /pm:help With that being said, a video will be coming very soon.
raimille1 1y ago
Agree! I see a lot of pontential here, just hard to get a grasp.

nivertech 1y ago

Task decomposition is the most important aspect of software design and SDLC. Hopefully, your GitHub tickets are large enough, such as covering one vertical scope, one cross-cutting function, or some reactive work such as bug fixing or troubleshooting. The reason is that coding agents are good at decomposing work into small tasks/TODO lists. IMO, too many tickets on GitHub will interfere with this.

aroussi 1y ago
I agree wholeheartedly! When we break down an epics into tasks, we get CC to analyze what can be run in parallel and use each issue as a conceptual grouping of smaller tasks, so multiple agents can work on the same issue in parallel. The issues are relatively large, and depending on the feature, every epic has between 5 to 15 issues. When it's time to work on the issue, your local cloud code will break it down into minute tasks to carry out sequentially.

jdmoreira 1y ago

I'm a huge fan of Claude Code. That being said it blows my mind people can use this at a higher level than I do. I really need to approve every single edit and keep an eye on it at ALL TIMES, otherwise it goes haywire very very fast! How are people using auto-edits and these kind of higher-level abstraction?

Nizoss 1y ago
Same, I manually approve and steer each operation. I don't see how cleaning up and simplifying after the fact is easier or faster.
- CuriouslyC 1y ago
  That kills iteration speed. Carefully outline, get it to write tests first, then let it go wild and verify the tests while it's doing that. If there are test issues, tell it so without interrupting it, and it'll just queue up those fixes without having to stop and be re-routed. You want to periodically have coverage improvement -> refactor loops after implementing a few features. You can figure out the refactors you want while the agent is implementing the code, after you've sussed out any test issues, then just queue up instructions on how to refactor once the tests are passing.
allisdust 1y ago
Through multi pass development. It's a bit like how processes happen inside a biological cell. There is no structure there. Structure emerges out of chaos. Same thing is with AI coding tools. Especially Claude code. We are letting code evolve to pass our quality gates. I do get to sit on my hands a lot though which frees up my time.
- aroussi 1y ago
  Yeah, I agree. I never let the AI make any architectural decisions (and I also watch Claude Code like a hawk lol). That being said, since we started using this system, we noticed that our PRDs and implementation plans (epics) became more detailed, giving the AI a lot less wiggle room. Essentially, I'm treating Claude Code as a very fast junior developer who needs to be spoon-fed with the architecture.

swader999 1y ago

The advantage with using multiple agents is in context management, not parallelization. A main agent can orchestrate sub agents. The goal is to not overwhelm the main agent with specialized context for each step that can be delegated to separate task focused agents along the way. Test runner sub agent knows exactly how to run tests, summarize failures etc. It loads up all the context specific to running tests and frees the main agent's context from all that. And so on...

aroussi 1y ago
100%! Use agents as "context firewalls". Let them read files, run tests, research bugs, etc, and pass essential data back to the main thread.

thomask1995 1y ago

OK I need to give this a go. tbh, I've been going back to just writing stuff manually and asking ChatGPT doc questions. I talked to and extremely strong engineer yesterday who is basically doing exactly this. Would love to see a video/graphic of this in action.

aroussi 1y ago
I'm going to create a video and post it both here and on the repository over the weekend
- stronglikedan 1y ago
  And I'm going to reply here so that I remember to check back! Thanks!
  - greggh 1y ago
    Good idea. I'd love a video.

jamauro 1y ago

Looks interesting. How do you make sure that agents that need to collaborate on the solution actually collaborate if they’re working in parallel?

aroussi 1y ago
We gave up on that dream a while back lol. Instead, we analyze which tasks can be run in parallel (different files, etc) and which need to be worked on sequentially.
- robbs 1y ago
  Have you found a way to have the AI assist in analyzing?

nikolayasdf123 1y ago

when you go to their website some person immediately starts talking to you at the bottom left corner. this is hilarious, websites today got to tune it down a bit with sales

nikolayasdf123 1y ago

their website also features some shredded bold dude. got to respect their sales skills

dcreater 1y ago

This is a more advanced version of what I'm doing. I was impressed that someone took it up to this level till I saw the tell tale signs of the AI generated content in the README. Now I have no faith that this is a system that was developed, iterated and tested to actually work and not just a prompt to an AI to dress up a more down to earth workflow like mine. Evidence of results improvement using this system is needed.

aroussi 1y ago
Damn those em dashes lol Kidding aside, of course we used AI to build this tool and get it ready for the "public". This includes the README. I will post a video here and on the repository over the weekend with an end-to-end tutorial on how the system works.
- dcreater 1y ago
  Videos would be great, but what you be better are real trials using a) vibe coding b) basic CLAUDE.md c) your system P.S: And it wasnt the em-dashes, its the general structure and the recognizable bullet points with emojis.

mustaphah 1y ago

TL;DR workflow phases: - Brainstorm a PRD via guided prompts (prds/[name].md). - Transform PRD into epics (epics/[epic-name]/epic.md). - Decompose epic into tasks (epics/[epic-name]/[feature-name]/[task].md). - Sync: push epics & tasks to GitHub Issues. - Execute: Analyze which tasks can be run in parallel (different files, etc). Launch specialized agents per issue.

apwell23 1y ago
tl;dr break shit down into small chunks

apwell23 1y ago

> With multiple Claude agents running in parallel Are ppl really doing this? My brain gets overwhelmed if i have more than 2 or 3.

aroussi 1y ago
OP here. It really depends on how you use parallel agents. Personally, I don't run multiple instances of Cloud Code nor do I use multiple screens. I find it hard to focus :) That being said, if a task requires editing three different files, I would launch three different sub-agents, each editing one file, cutting down implementation time by two-thirds.

tmvphil 1y ago

Sorry, I'm going to be critical: "We follow a strict 5-phase discipline" - So we're doing waterfall again? Does this seem appealing to anyone? The problem is you always get the requirements and spec wrong, and then AI slavishly delivers something that meets spec but doesn't meet the need. What happens when you get to the end of your process and you are unhappy with the result? Do you throw it out and rewrite the requirements and start from scratch? Do you try to edit the requirements spec and implementation in a coordinated way? Do you throw out the spec and just vibe code? Do you just accept the bad output and try to build a new fix with a new set of requirements on top of it? (Also the llm authored readme is hard to read for me. Everything is a bullet point or emoji and it is not structured in a way that makes it clear what it is. I didn't even know what a PRD meant until halfway through)

jcmontx 1y ago
Waterfall is what works for most consulting businesses. Clients like the buzz of agile but they won't budge on scope, budget or timeframe. You end up being forced to do waterfall.
- dc10tonite 1y ago
  Yep. And you often end up doing waterfall with a veneer of agile that ends up being worse than either one.
  - andrekandre 1y ago
    this has been my experience too, its horrible because everyone does all the agile meetings and "planning" but its just used as progress reporting to the product managers... if thats all thats 'agile' being used for just do daily reporting and be done with it
- tmvphil 1y ago
  Waterfall might be what you need when dealing with external human clients, but why would you voluntarily impose it on yourself in miniature?

tummler 1y ago

A project management layer is a huge missing piece in AI coding right now. Proper scoping, documentation, management, etc is essential to getting good results. The people who are having the most success with “vibe coding” have figured this out, but it should really be incorporated into the process.

moconnor 1y ago

"Teams using this system report: 89% less time lost to context switching 5-8 parallel tasks vs 1 previously 75% reduction in bug rates 3x faster feature delivery" The rest of the README is llm-generated so I kinda suspect these numbers are hallucinated, aka lies. They also conflict somewhat with your "cut shipping time roughly in half" quote, which I'm more likely to trust. Are there real numbers you can share with us? Looks like a genuinely interesting project!

aroussi 1y ago
OP here. These numbers are definitely in the ballpark. I personally went from having to compact or clear my sessions 10-12 times a day to doing this about once or twice since we've started to use the system. Obviously, results may vary depending on the codebase, task, etc., but because we analyze what can be run in parallel and execute multiple agents to run them, we have significantly reduced the time it takes to develop features. Every epic gets its own branch. So if multiple developers are working on multiple epics, in most cases, merging back to the main branch will need to be done patiently by humans. To be clear, I am not suggesting that this is a fix-all system; it is a framework that helped us a lot and should be treated just like any other tool or project management system.
- datadrivenangel 1y ago
  How many feature branches can you productively run in parallel before the merge conflicts become brutal?
  - CuriouslyC 1y ago
    That depends on how decoupled your codebase is and how much overlap in the areas being worked on by your agents are. If you have a well architected modular monolith and you don't dispatch overlapping issues, it's fine.
  - aroussi 1y ago
    That's where the human architect comes in (for now at least). We'll try to think of features that would have the least amount of conflicts when merged back to main. We usually max it at 3, and have a senior dev handle any merge conflicts.

penguin202 1y ago

[dead]

brainless 1y ago

I love what is happening in this domain, so many people experimenting. Thanks for sharing this. I recently launched https://letsorder.app https://letsorder.app, https://github.com/brainless/letsorder https://github.com/brainless/letsorder. 100% of the product (2 web UI apps, 1 backend, 1 marketing site) was generated by LLMs, including deployment scripts. I follow a structured approach. My workflow is a mix of Claude Code, Gemini CLI, Qwen Code or other coding CLI tools with GitHub (issues, documentation, branches, worktrees, PRs, CI, CodeRabbit and other checks). I have recently started documenting my thoughts about user flow with voice and transcribe them. It has shown fantastic results. Now I am building https://github.com/brainless/nocodo https://github.com/brainless/nocodo as the most ambitious project I have tried with LLMs (vibe coding). It runs the entire developer setup on a managed Linux server and gives you access through desktop and mobile apps. All self-hosted on your cloud accounts. It would basically be taking an idea to going live with full stack software.

tantanu 1y ago
just out of curiousity, I tried letsorder using the demo you provided. The QR code generation seems to work ok, and then using the table specific menu I tried to put in an order, and got HTTP500 for both the quick order and the other flow. this is entirely my own opinion and may not reflect your experience but this fits in with everything else I've seen that is LLM generated. It looks complete and works for the most part, except the most business critical part. Maybe the ordering flow does work, but how much traction are you going to really get without the demo actually doing what it's supposed to? Not trying to be snarky - just trying to understand if people actually pay for mediocre or low-quality products like these
- brainless 1y ago
  You are not being snarky at all. I am sure the bug exists. There are a few out there and I still have not gotten to fix them. This is nothing to do with LLM generated. I work on about 4-5 projects at the moment, https://github.com/brainless https://github.com/brainless. All of them are to test how far LLM driven development go. This, along with time to daily reach out to people, create posts, host lessons on vibe coding: https://lu.ma/user/brainless https://lu.ma/user/brainless I will get these bugs sorted when I get some time. Let's Order is not a commercial project, it is an exercise to show what a solo founder can get done these days with LLMs.

royletron 1y ago

It still feels like the more context the agents have the worse the response becomes - and simulataneously the more money ends up being thrown at Anthropic. I have to handhold agents to get anywhere near stuff I actually want to commit with my name on.

aroussi 1y ago
That's exactly why we use separate agents as "context firewalls". Instead of having the main thread do all the work and get its context polluted, with sub-agents, each agent works on one thing, then provides a summary to the main thread (much smaller context use) as well as a detailed summary in an empty file.

Nizoss 1y ago

I'm genuinely curious to see what the software quality looks like with this approach. Particularly how it handles complexity as systems grow. Feature development is one thing, going about it in a clean and maintainable way is another. I've come across several projects that try to replicate agile/scrum/SAFe for agents, and I'm trying to understand the rationale. Since these frameworks largely address human coordination and communication challenges, I'm curious about the benefits of mapping them to AI systems. For instance, what advantages does separating developer and tester provide versus having unified agents that handle both functions?

aroussi 1y ago
The real idea is to make sure that each agent works in its own little world and documents everything. So the main thread context is occupied with the understanding of the project instead of code snippets.

linkage 1y ago

Looks like a simpler version of BMAD https://github.com/bmad-code-org/BMAD-METHOD https://github.com/bmad-code-org/BMAD-METHOD

dalore 1y ago

how to use it on an existing repo that has a few issues, a milestone, labels, etc?

aroussi 1y ago
We created a "/pm:import" command before making this project public to pull existing repo issues into local. Hopefully, this will work well. We have tested it, but this is not one of the functionalities that we use on a daily basis internally. Fingers crossed :)

blancotech 1y ago

I’m curious how any project management to code agent workflow can be successful given how messy the process is in real life. Especially discovering unknown unknowns that lead to changes in your original requirements. This often happens at each step of the process (e.g. when writing the PRD, when breaking down the tickets, when coding, when QAing, and when documenting for users). That’s when the agent needs to stop and ask for feedback. I haven’t seen (any) agents do this well yet.

CuriouslyC 1y ago
This will be a solved problem soon. With an agent wired up to slack, elastic (for all org docs) and your code base, it can iterate over high level project documents with stakeholders, clarifying things, noting codebase challenges that will need to be addressed and creating PM artifacts.

vemv 1y ago

It will increasingly become common knowledge that the best practice for AI coding is small edits quite carefully planned by a human. Else the LLM will keep going down rabbit holes and failing to produce useful results without supervision. Huge rules systems, all-encompassing automations, etc all assume that more context is better, which is simply not the case given that "context rot" is a thing.

aroussi 1y ago
The system is trying to solve: breaking down large projects into small tasks and assigning sub-agents to work on each task, so the code, research, test logs, etc. stay inside the agent, with only a summary being surfaced back up to the main thread.

poopiokaka 1y ago

Make it work with gitlab

CuriouslyC 1y ago

You should just try to integrate your work with Vibe Kanban, I'm pretty sure it's going to be the winning tool in this space.

euroderf 1y ago

AI n00b here. I wonder if this workflow is possible: I point Claude to my codebase, and Claude writes up a PRD that matches/reflects/describes the codebase. Then I iteratively (a) edit the PRD to reflect where I want my codebase to go, and (b) have Claude execute on it.

gucrol 1y ago

[dead]