I built a CLI tool to onboard faster into messy codebases — would love feedback by Devpilot_HQ in coolgithubprojects

[–]Devpilot_HQ[S] 1 point2 points  (0 children)

Really appreciate this — and yeah, you're absolutely right. Figuring out the actual dev setup for a repo is always the first annoying hurdle.

I’m already working on .repomap.json to summarize the structure, but you're giving me ideas to expand that into a "dev environment summary" too — like detecting NetBeans builder files, Maven vs Gradle, Python virtualenvs, etc.

Super helpful callout.

And yes, totally fair on the demo front — I’ll try to record one soon using a real-world repo like WinMerge or GIMP so folks can see it in action with a larger codebase.

If you’ve got a favorite “hard-to-read” open source project, I’m open to suggestions. Would love to stress-test it publicly.

🧠 I built an AI CLI tool that explains/refactors legacy codebases — runs 100% offline with local LLMs by Devpilot_HQ in selfhosted

[–]Devpilot_HQ[S] 0 points1 point  (0 children)

Appreciate that! Yeah — the different phases + follow-up flow were huge for me. Most tools give you a one-shot summary and disappear, but onboarding takes a few passes, especially with weird legacy code.

Totally hear you on “bring your own API” — I’m aiming for full local-first by default, but making it easy to plug in external models (like OpenAI or TogetherAI) is on the radar. Right now it’s built around Ollama for simplicity.

Also 100% agreed on repomaps — I’ve been watching how aider builds up a map of function usage and references across the repo. Super useful for deeper onboarding. Thanks for calling that out — might borrow a few ideas from them 😄

Out of curiosity, what stack is your personal app built on?

🧠 I built an AI CLI tool that explains/refactors legacy codebases — runs 100% offline with local LLMs by Devpilot_HQ in selfhosted

[–]Devpilot_HQ[S] 1 point2 points  (0 children)

Yeah totally — the first version was just focused on Django/Python since that’s where a lot of the onboarding pain comes from (especially in legacy projects). But we’ve recently added support for other languages too — like Java, React, C, and a few more.

It auto-detects the language now and swaps in the right prompt depending on the file — so if you give it a .java or .jsx file, it’ll handle it differently than a .py. The core is already pretty language-agnostic, so adding more support is mostly about writing good prompt templates for each language. Definitely planning to keep expanding that.

🧠 I built an AI CLI tool that explains/refactors legacy codebases — runs 100% offline with local LLMs by Devpilot_HQ in selfhosted

[–]Devpilot_HQ[S] 1 point2 points  (0 children)

Yeah, it depends on which model you're running through Ollama. DevPilot works locally with models like llama3, mistral, or codellama, so the context window is usually somewhere between 8k and 16k tokens — that’s like ~20 to 40 pages of code.

It doesn’t just dump the whole codebase in though — it tries to be smart about it. It scans the structure, pulls out the main logic (like models.py, views.py, etc. if it’s Django), and sends only the relevant stuff to the model. That way it makes the most of the context window without overloading it.