karl3ļ¼ writeme.com wrote:
> 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 ended up having a strategy of using the highest quality model at the start
of a task, and then reducing the model quality farther in to reduce costs and
such. This leaves the higher-quality responses in the context of the prompts
used for the lower quality model, which gives them more intelligent and robust
completion patterns. they still don't quite compare though.
> - 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
