so i kept pushing on shap and ended up spending days slowly working on finegling the ai to refactor the monstrous mess it had made into something organized and simple. it would have been much quicker to start over with the knowledge i had gained. but it was mostly a recreational thing so i just went at it. the current state is in the path-surface-unification branch. now i am out of money (it costs $6 to replenish anthropic and i hit the button so much that i now don't even have $6 in my account. this will change come next month.) and out of compute on github codespaces where i was running their free in-browser vscode that can run cline.
things i learned: - cline is for people new to coding or people with psychological disorders involving using corporate AI needlessly. it would be relatively easy for a coder emotionally free to do so to make something better that is much cheaper or free. most of the cline work is on making a great UI. they also have tuned prompts in their source that are designed to work well with how the Claude model was trained. - it's really good to stay involved with it, to observe it as it functions and advise it whenever it does something one doesn't want. this prevents things from compounding. honestly the moment you don't do this and let it run on its own, is the moment the codebase turns into a big mess. - anthropic is both cheaper than openrouter as well as higher quality. openrouter seems to be engaging poor sampling settings. - if you started with a free model at the start, you'd get more used to the severe quirks associated with doing so and could find paths that engage that situation more successfully. it's still challenging though. - it seems it would be good to focus on really powerful core parts of a project, deleting cruft files, until the basics of the architecture are really solid. this then gives it a good environment to build off of, which it might respond better to than requests or prompts around coding standards. - it's quite useful to direct it to work with documents that describe what it is doing, this lets one cut the context short and handle crashes well - i had other things to write here but don't remember them so just expanded upon the bits i did, maybe wasn't best time to write this yup! free lightweight (could implement from a cell phone) approaches might focus around [automated] prompt tuning for each task involved - writing commit messages based on portions of information - updating single files to meet small requests - summarizing or portioning information in ways that are useful for other tasks note that wiring these things together effectively looks similar to designing an overall learning architecture. prompt tuning for one thing that impacts many other things might want success/failure metrics to propagate up, etc ... a prompt tuner could also be a model selector. it was fun but it's not cheap enough yet to be a sustainable addiction for a homeless chap. it leaves me feeling confused ... how did i feel satisfied without writing code? where are my coping attempts for still trying to write code myself ...? still waiting on those products that powerfully influence on their own the user to become skilled and independent
