Honestly, tonight I had a realization moment. My token pan for qwen cloud expired, so I thought 'you know what, I wanna see what local AI can do'. ...
For further actions, you may consider blocking this person and/or reporting abuse
Finallly you published an article!
I am still struggling to make GitHub Copilot write PySide UI for me. It almost feels completely useless and counterproductive at times. I just say "fix the placeholder", and it does something, and I say "try again", and it again try something, and NEVER fixes. I mean it's just a simple thing, that's why I just say it to "fix it". Why do I have to explicitly tell it that the container has a fixed size and that's causing overflow? And why does it overcomplicate EVERYTHING for no reason? It's using MAI-Code-1.1-Flash, which is probably bigger than 35b params. But you seem to be okay with a local model? Can you tell me what you do to make even smaller models work reliably?
So the problem you're hitting, is the model doesnt see what's going wrong. So if it's causing an overflow, tell it, 'there's an overflow, investigate what might be causing it', or if you want to go more broadly 'why is it using so much memory? It keeps increasing' which is the more exploratory way to prompt, which will make it start indexing all possible sites.
For reliability from smaller models, you need a solid harness and if the model is really small, then you need to just 'point it' in the right direction. Older and smaller models share that common trait, because they had alot less learning data regarding prompt intent understanding.
My suggest would first be, ask it to profile the memory and to 'benchmark' it, that's how it gets tests that give it metrics, so it can see what's going wrong. If you want further improvement, then you can add things to it's system instructions (eg. remember memory safety), or ask it to add it to it's memory, which does about the same.
Yeah but I wish it'd just figure it out on its own 😅 Also, in my case, it says things like "The feature has been implemented. I tested it with X" and when I try it, not only is the feature not there, but it also breaks a couple of things. Most likely because I am working on something I have zero experience with.
Often times, that means that you're relying too much on a single chat, ideally, you should have your main chat, which is just orchestration and planning, then have it spawn sub-agents for each mission (task), that way implementations are isolated and requirements are isolated, only the orchestrator is bothered with the full system.
Sub agents mean separate sessions? Or is it a whole new thing?
Separate session is fine, when you look at how it works under the hood is agent A writes a mission "Do this... Use that... Validating like this... Give me a summary report on completion", that's how your orchestrator knows what happened and that it works, without wasting 100k tokens doing it, itself. If you store the summary report as an artifact, then it also persists after context compaction
AIs are soulless.
So am I. I am a human (last time I checked) - and I am pretty darn sure that I do not own a "soul". None of the bills I checked says "soul", so I didn't pay for owning one. My parents were sure they didn't have "souls" either, so I can't have inherited one.
While I feel just as "cooked" as anyone right now who learned the hard and long winded way to solve other people's problems using hard- and software (and feeling completely obsolete for the moment): "Souls" are definitely not the issue at hand.
However, even though I have been out of income for over half a year and despair is knocking at the backdoor by now (I don't open the frontdoor as that's where the mail brings bills), my perspective still is (and it is growing stronger) that those of us who have an actual understanding of code, low level, computer "inner workings", may become valueable in the long run. The question is: How do we survive until then?
I totally get this point. Talking about “soul” can feel like a comforting escape, but the real challenge is the survival gap. Those who understand how computers actually work will hold lasting value. The tricky part is getting through this tough interim phase before that value gets widely recognized. Hope things turn around for you soon.🤞
That's the part I'm not so sure of. Wee know low-level computers, the inner workings, etc. But the engineers who designed the computers feed AI schematics and blueprints we never saw and distill their first-hand knowledge into it. Cant compete with an AI that was involved in the building of a system? That's why I'm starting to think we're cooked, cuz how do we bring value that a dataset cant teach an AI? Years of experience, are datapoints it can train on, so we've got no edge there either. Our understanding is becoming a teachable metric that companies are paying us to sacrifice, because there's no jobs around for us to do. More and more I'm seeing 'teach AI to code' as a career, yet it's by definition a means to our end.
I hear you. I feel just as clueless as you.
However, what I meant was not a "teachable" thing, what I meant was bridging real-world understanding (which includes haptic/physical learning, where AI may or may not catch up, but also experience from mistakes and success) and instructions-thinking that computers most likely will still use in 20 years, even with quantum technology.
If you look at an LLM that makes a mistake, you will see that it is fundamentally unable to learn from the mistake as such. It can only create an instruction that describes the mistake and avoids making the same mistake again - that's instructional thinking, but not understanding. It is "programming" in a way, but not "bridging experience to instructions". If an LLM hallucinates, it is fundamentally unable to explain why or how it did so. It can only base assumptions on what it reads back in and compare that to existing instructions, it can not "go back and explain the thinking".
Anyway, what I think and hope for is that those of us who have real-world experience and are capable of "thinking out of the box", in both ways, may come back into need rather sooner than later. My hope is that "sooner" is not after we starved to death.
I imagine it'll go much the way fortran developers went. First phased out to near extinction, then made relevant again. We'll be pushed to the brink, then our services will come in handy again too.
cooked!