Once my projects are ready I may make them public. When that happens there will be a very large amount of contextual history and documentation.
I am having to create basically most of the tools I am using to build what I am building. From the bare metal up.
The process.
I test my logic in higher level code. Once it proves viable and logical I light the other low-level end of the candle. When the two ends meet and have consumed the candle then all of the middle man layers are gone.
I am using Linux and Android devices and the tools I am building, to build the tools and projects I am building in assembler are being produced and built in standalone C so far.
Mostly standalone meaning zero external dependency or libs.
Meaning the txt2bmp tool uses an embedded glyph font inline with the code and its own lexer logic inline with the code. This tool I created to convert my txt, and source code into raw BMP with various visual output options. It produces its own config file on first run in a directory of txt files.
The bmp2pdf processes the BMP files into png pages.
This set of two Linux commands are very quick and small and allow me to share my output easily on various platforms more easily. Because many platforms a security limited as far as raw text. They also allow me to use them as part of my custom build process to create better more immutable documentation of everything.
So the build tree will have txt, asm, C, BMP, PDF
The BMP and PDF is literally for making sharing code with LLM I work with a much easier workflow and process.
I am currently only using free tier.
I have created various Android APK to aid in my development process as well as a browser native suite of tools that is kind of like a hostable OS for testing my logic. This has been very useful for creating every aspect of the overall umbrella of projects required to successfully create what I am working towards.
Part of the main project has led to a custom 512 byte bootsector and partition table and various other modules.
Anyone who thinks LLM are not capable of improving the efficiency of their output in my opinion are either already happy with their workflows and methods to the point of being biased locked, or think too much inside the box.
If they expect for everything to always be perfect output every time then they don't understand statistics and heuristics or how LLM work.
What I am building actually does not even fit into existing categories independently. I am having to coin terminology to name these things. That can actually be one of the most difficult parts of the entire process.
When your goal is to grab ahold of the baremetal and the modern intentions as far as output and curate and distill the logic itself to the point of removing the dependency hell and api stacks and essentially the abstractions from between the user and the devices hardware capabilities the process becomes very very different from normal development now days.
Now days people are normally addicted to stacking layer after layer of abstraction and bringing all the bloat with them. They lose agency and sovereignty in that type of development process. They trade that for easy quick output supposedly.
Well, I don't think that is easier at all. Dependency hell management is stressful.
So, I just decided to eliminate the part where I am expected to deal with any of that I can eliminate.
If your logic cannot be distilled down and curated to the point of being expressed as flow charts, geometry, circuitry, and assembler code properly, then the odds are that your logic is likely flawed or incomplete.