Maybe it's time to leave LLM to manage the whole project behind? #261

New Issue

2026-10-27T15:46:29+01:00

adam commented

2026-10-27 15:46:29 +01:00

Ahoj,

dear @dabeani, I am really grateful for your work.

But I read one comment that prompts me for another "LLM rant". I think the project has reached a complexity now that makes using LLM for overall development more standing in the way than beeing of any help (see also the facts that same functions seemed to have been implemented several times independently, which surfaces on some UI inconsistencies, and the amount of other vibe coding typical bugs).

Maybe it's time to somehow shift more to manual code development and using LLM only for drafting some general new frameworks (if needed), then continuing by hand, and never use LLM to touch the whole project anymore?

I know that software development is not your main profession, so, what to do? Hm ...

(Please don't get me wrong that I want to rant about you. That not, I appreciate the effort you put into here. I have a very strong opinion on most of vibe coding, and to me it seems that in the longer run it generates more problems here than it solves.)

Since the firmware is getting bigger, its quite a lot of work to keep it in the correct path.

Well, this "prompts" me for another LLM rant.

Seems it is hard for the LLM to keep things together, but LLMs are not good at coding complex things that go beyond general frameworks or so.

Well architectured software should not get problems in part A if things in part B are changed or added.

needed to remove the persistency of messages

You mean that they are saved over reboot? Maybe I am "leaning out of the window" here too far, but I suspect it is also just the incapability of the LLM: Storing a lot amount of data on storage and reading only on demand and only what is needed by a constraint CPU into constraint memory is a solved problem.

Regards 💚!

Ahoj, dear @dabeani, I am really grateful for your work. But I read one comment that prompts me for another "LLM rant". I think the project has reached a complexity now that makes using LLM for overall development more standing in the way than beeing of any help (see also the facts that same functions seemed to have been implemented several times independently, which surfaces on some UI inconsistencies, and the amount of other vibe coding typical bugs). Maybe it's time to somehow shift more to manual code development and using LLM only for drafting some general new frameworks (if needed), then continuing by hand, and never use LLM to touch the whole project anymore? I know that software development is not your main profession, so, what to do? Hm ... *(Please don't get me wrong that I want to rant about you. That not, I appreciate the effort you put into here. I have a very strong opinion on most of vibe coding, and to me it seems that in the longer run it generates more problems here than it solves.)* > *[Since the firmware is getting bigger, its quite a lot of work to keep it in the correct path.](https://github.com/dabeani/meshcoreterm/issues/245#issuecomment-4382934628)* Well, this "prompts" me for another LLM rant. Seems it is hard for the LLM to keep things together, but LLMs are not good at coding complex things that go beyond general frameworks or so. Well architectured software should not get problems in part A if things in part B are changed or added. > *[needed to remove the persistency of messages](https://github.com/dabeani/meshcoreterm/issues/253#issuecomment-4484532168)* You mean that they are saved over reboot? Maybe I am "leaning out of the window" here too far, but I suspect it is also just the incapability of the LLM: Storing a lot amount of data on storage and reading only on demand and only what is needed by a constraint CPU into constraint memory is a solved problem. Regards 💚!

adam closed this issue

2026-10-27 15:46:29 +01:00

adam commented

2026-10-27 15:46:30 +01:00

Hi,

Thank you for your time and motivation to support the community, and me, and my project.

I really appreciate for the investigation into the issues and errors - even, when a bunch of you are not happy with my method of development what i use.

I really want to answer to your message but, its a better choice (for me and my project) to leave your message with your thoughts as it is, and everyone can have his opinion about it.

As far as i know, and as far as i can read through different stories and channels, this project brings value to the community. I understood there are a-lot of people out there who would like to see more "hand-made" projects and more Open Source.

Its up to me :)

Dont get me wrong, it makes me kinda upset when i saw your post today and i lost way too much thoughts about it - you are also passionate with this stuff, thats great, thats how it should be and therefore keep it going :).

All the best,
Bernhard

Hi, Thank you for your time and motivation to support the community, and me, and my project. I really appreciate for the investigation into the issues and errors - even, when a bunch of you are not happy with my method of development what i use. I really want to answer to your message but, its a better choice (for me and my project) to leave your message with your thoughts as it is, and everyone can have his opinion about it. As far as i know, and as far as i can read through different stories and channels, this project brings value to the community. I understood there are a-lot of people out there who would like to see more "hand-made" projects and more Open Source. Its up to me :) Dont get me wrong, it makes me kinda upset when i saw your post today and i lost way too much thoughts about it - you are also passionate with this stuff, thats great, thats how it should be and therefore keep it going :). All the best, Bernhard

adam commented

2026-10-27 15:46:31 +01:00

Dear Bernhard,

I feel sorry for causing upset-ness in you.

❤️

Dear Bernhard, I feel sorry for causing upset-ness in you. ❤️

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshcore#261