[cschneid]

I have been playing with plandex off and on for a bit now, and I like it's approach. It's not trying to be a fully automated developer, but it does a lot more than copilot does.

The biggest use I have used it for was to wrap unit tests around a large class that isn't currently tested. I did it slowly, a few functions at a time, and sometimes with followup prompts to fix oversights or clean up a bit, or add extra test cases that it missed with a basic 'write tests for ...' prompt.

The workflow I ended up liking was: * plandex does large edit * vscode + copilot to tweak and edit.

Combined it was pretty quick to do useful work on a complex established codebase, although limited in scope. There's no way it would implement real features, but it's great at backfilling tests, making skeletons of new pages, and similar things.

[danenania]

Thank you for the post--it's really interesting to hear that feedback about your workflow.

> There's no way it would implement real features

Could you say more about this? While Plandex certainly does have limitations, I've been using to add some fairly complex features to Plandex itself. That said, I know there are conditions that can make it not perform well. Could you maybe talk a bit more about what kind of code base this is and what problems you tend to run into? Thanks again.

[cschneid]

I work on a codebase that's at least 10 years old, and has thousands of files. Aider by comparison can't even load files into context due to its slowness with this many files.

There's too much subtlety and home-grown weirdness at this point to build "real" code, although I haven't really pushed it either. We're an internal application that mostly is consumed by other parts of our company, and so most of our problems are nitpicky workflow issues more than technical coding.

I think where Plandex is great is the mundane junk around the edges of a large system like this. Something I haven't tried but am pretty sure would work well is building a new API connector by loading a current API client into context, the docs for a new API to implement, and then iterating a bit to generate the new one in the right style.

I could also probably get further by having a 'style guide' markdown document I load into context too. Something like that would be handy for basically any LLM based coding assistant.

[danenania]

Thanks for explaining! It does make sense that working with a project that large would be a challenge.

> Something I haven't tried but am pretty sure would work well is building a new API connector by loading a current API client into context, the docs for a new API to implement, and then iterating a bit to generate the new one in the right style.

Yeah, that should work well--it's quite similar to how I generally build features with Plandex myself. Having a a model (like the current API client) for the LLM to work from definitely improves results.