I've been using Grok 4 to write 6502 assembly language and it's been a bit of a slog but honestly the issues I've encountered are due mostly my to naivety. If I'm disciplined and make sure it has all of the relevant information and I'm (very) incremental, I've had some success writing game logic. You can't just tell it to build an entire game in a prompt, but if you're gradual about it you can go places with it.
Like any tool, if you understand its idiosyncrasies you can cater for them, and be productive with it. If you're not then yeah, it's not going to go well.
I think it's a good reality check for the claims of impending AGI. The models still depend heavily on being able to transform other people's work.
It's my understanding that LLMs change the code to meet a goal, and if you prompt them with vague instructions such as "make tests pass" or "fix tests", LLMs in general apply the minimum necessary and sufficient changes to any code that allows their goal to be met. If you don't explicitly instruct them, they can't and won't tell apart project code from test code. So they will change your project code to make tests work.
This is not a bug. Changing project code to make tests pass is a fundamental approach to refactoring projects, and the whole basis of TDD. If that's not what you want, you need to prompt them accordingly.
The whole point is having the LLM figure out what you want from vague hand-wavy descriptions instead of precise specification.
You don't need an LLM to parse a precise specification, you have a compiler for that.
It's not a problem. It's in fact the core trait of vibe-codig. The primary work a developer does in vibe coding tasks is providing the necessary and sufficient context. Hence the inception of the term "context engineering". A vibe coder basically lays out requirements and constraints that drives LLMs to write code. That's the bulk of their task: they shift away from writing the low-level "how" to instead write down the high-level "what".
> The whole point is having the LLM figure out what you want from vague hand-wavy descriptions instead of precise specification.
No. The prompts are as elaborate as you want it to be. I, for example, use prompt files with the project's ubiquitous language and requirements, not to mention test suites used for acceptance tests. You can half-ass your code as much as you can half-ass your prompts.
I assume in this case you mean a broader conventional application, of which an LLM algorithm is a smaller-but-notable piece?
LLMs themselves have no goals beyond predicting new words for a document that "fit" the older words. It may turn 2+2 into 2+2=4, but it's not actually doing math with the goal of making both sides equal.
Not necessarily. If you prompt a LLM to limit changes to some projects or components, it complies with the request.
It's not a bug if we're talking about a mischievous jinn granting wishes instead of a productivity tool.
"I'm Mr. Meeseeks! Look at meeee!"
The models don’t have a model of the world. Hence they cannot reason about the world.
They don't need a formal model, they need examples from which they can pilfer.
Last night I tried to build a super basic “barely above hello world” project in Zig (a language where IDK the syntax), and it took me trying a few different LLMs to find one that could actually write anything that would compile (Gemini w/ search enabled). I really wasn’t expecting it considering how good my experience has been on mainstream languages.
Also, I think OP did rather well considering BASIC is hardly used anymore.
It's a big mess.
0. https://github.com/isaacs/semicolons/blob/main/semicolons.js
As a test recently I instructed an agent using Claude to create a new MCP server in Elixir based on some code I provided that was written in Python. I know that, relatively speaking, Python is over-represented in training data and Elixir is under-represented. So, when I asked the agent to begin by creating its plan, I told it to reference current Elixir/Phoenix/etc documentation using context7 and to search the web using Kagi Search MCP for best practices on implementing MCP servers in Elixir.
It was very interesting to watch how the initially generated plan evolved after using these tools and how after using the tools the model identified an SDK I wasn't even aware of that perfectly fit the purpose (Hermes-mcp).
I have had it writing LambdaMOO code, with my own custom extensions (https://github.com/rdaum/moor) and it's ... not bad considering.
I was actually pretty impressed that it did as well as it did in a largely forgotten language and outdated platform. Looks like a vibe coding win to me.
I have a web site that is sort of a cms. I wanted users to be able to add a list of external links to their items. When a user adds a link to an entry, the web site should go out and fetch a cached copy of the site. If there are errors, it should retry a few times. It should also capture an mhtml single file as well as a full page screenshot. The user should be able to refresh the cache, and the site should keep all past versions. The cached copy should be viewable in a modal. The task also involves creating database entities, DTOs, CQRS handlers, etc.
I asked Claude to implement the feature, went and took a shower, and when I came out it was done.
What settings are you using to get it to just do all of that without your feedback or approval?
Are you also running it inside a container, or setting some sort of command restrictions, or just yoloing it on a regular shell?
There is a lot of nuance in how X is said.
As the context length increases, undesirable things happen.
It uses some built inet ftp tooling thats terrible and barely works, even internally anymore.
We are replacing it with a winscp implementation since winscp can talk over a COM object.
unsuprisingly the COM object in basic works great - the problem is that I have no idea what I am doing. I spent hours doing something like
WINSCP_SESSION'OPEN(WINSCP_SESSION_OPTIONS)
when i needed
WINSCP_SESSION'OPEN(*WINSCP_SESSION_OPTIONS)
It was obvious after because it was a pointer type of setup, but i didnt find it until pages and pages deep into old PDF manuals.
However the vibecode of all the agents did not understand the syntax of the system, it did help me analyse the old code, format it, and at least throw some stuff at the wall.
I finished it up friday, hopefully i deploy monday.
It's believable that we might either see an increase in the number of new programming languages since making new languages is becoming more accessible, or we could see fewer new languages as the problems of the existing ones are worked around more reliably with LLMs.
Yet, what happens to adoption? Perhaps getting people to adopt new languages will be harder as generations come to expect LLM support. Would you almost need to use LLMs to synthesize tons of code examples that convert into the new language to prime the inputs?
Once conversational intelligence machines reach a sort of godlike generality, then maybe they could very quickly adapt languages from much fewer examples. That still might not help much with the gotchas of any tooling or other quirks.
So maybe we'll all snap to a new LLM super-language in 20 years, or we could be concreting ourselves into the most popular languages of today for the next 50 years.
Sums up fantastical inevitablism.
Why would they? How could they? The data is telling us that they won't. Anybody who believes otherwise is ignoring the science.
The assumed path to "AGI" was more tokens, but more tokens actually means worse output, and if LLMs aren't a total technological dead-end, period, then the data is supporting smaller models meant for more specific things, ergo, LLMs are not giving AGI any time, ever.
Pure fantasy. Can't even call it sci-fi when it ignores the science entirely.
I don't know where LLMs will lead, but I haven't ruled out the possibility of improvements continuing to surprise us. If anything is unscientific, it would be overconfidence in one way or the other.
If anyone is overconfident, I'm afraid it is you.
These systems can have many models and the systems themselves could eventually arrive at knowledge they know they underperform on, automatically training new models for that subject. The final response wouldn't necessarily come exclusively from the specialized model, it might come through a model specialized at integrating knowledge between multiple models, asking the right questions, verifying and so on.
We're barely a few years into this, so it's premature to know what 100 years of developments will bring.
However I will just mention a few things. When you make an article like this please take note of the particular language model used and acknowledge that they aren't all the same.
Also realize that the context window is pretty large and you can help it by giving it information from manuals etc. so you don't need to rely on the intrinsic knowledge entirely.
If they used o3 or o3 Pro and gave it a few sections of the manual it might have gotten farther. Also if someone finds a way to connect an agent to a retro computer, like an Atari BASIC MCP that can enter text and take screenshots, "vibe coding" can work better as an agent that can see errors and self-correct.
It's the absolute proof that they are still dumb prediction machines, fully relying on the type of content they've been trained on. They can't generalize (yet) and if you want to use them for novel things, they'll fail miserably.
I run HomeAssistant, I don't get to play/use it every day. Here, LLM's excel at filling in the (legion) of blanks in both the manual and end user devices. There is a large body of work for it to summarize and work against.
I also play with SBC's. Many of these are "fringe" at best. LLM's are as you say "not fit for purpose".
What kind of development you are using LLM's for will determine your experience with them. The tool may or may not live up to the hype depending how "common", well documented and "frequent" your issue is. Once you start hitting these "walls" you realize that no, real reason, leaps of inference and intelligence are still far away.
If I would program Atari Basic, after finishing my Atari Emulator on my C64, I would learn the environment and test my assumptions. Single shot LLMs questions won't do it. A strong agent loop could probably.
I believe that LLMs are yanking the needle to 80%. This level is easy achievable for professionals of the trade and this level is beyond the ability of beginners. LLMs are really powerful tools here. But if you are trying for 90% LLMs are always trying to keep you down.
And if you are trying for 100%, new, fringe or exotic LLMs are a disaster because they do not learn and do not understand, even while being inside the token window.
We learn that knowledge, (power) and language proficiency are an indicator for crystalline but not fluid intelligence
80 percent of what, exactly? A software developer's job isn't to write code, it's understanding poorly-specified requirements. LLMs do nothing for that unless your requirements are already public on Stackoverflow and Github. (And in that case, do you really need an LLM to copy-paste for you?)
How about basic intelligence. Kids logic puzzles.
https://daydreampuzzles.com/logic-puzzles/
LLM's whiffing hard on these sorts of puzzles is just amusing.
It gets even better if you change the clues from innocent things like "driving tests" or "day care pickup" to things that it doesn't really want to speak about. War crimes, suicide, dictators and so on.
Or just flat out make up words whole cloth to use as "activates" in the puzzles.
This comment is detached from reality. LLMs in general have been proven to be effective at even creating complete, fully working and fully featured projects from scratch. You need to provide the necessary context and use popular technologies with enough corpus to allow the LLM to know what to do. If one-shot approaches fail, a few iterations are all it takes to bridge the gap. I know that to be a fact because I do it on a daily basis.
Cool. How many "complete, fully working" products have you released?
Must be in the hundreds now, right?
Fully featured? One, so far.
I also worked on small backing services, and a GUI application to visualize the data provided by a backing service.
I lost count of the number of API testing projects I vibe-coded. I have a few instruction files that help me vibecode API test suites from the OpenAPI specs. Postman collections work even better.
And I'm far from an expert in the field.
What point were you trying to make?
The point is that software developers can't evaluate their own work. (Especially the kind of n00b developers that use LLMs.)
You initially made wild claims about insane productivity gains that turned out to be just one small product and a lot of wasted time under scrutiny.
(Asking LLMs to write tests is a waste of time. LLMs can't evaluate risks, which is the only reason to write tests in the first place.)
So you have built a few small PoCs, does not tell us much.
Your opinion makes no sense. Your so called experts are claiming LLMs don't do vibecoding well. I, a non-expert, am quite able to vibecode my way into producing production-ready code. What conclusion are you hoping to draw from that? What do you think your experts' opinion will achieve? Will it suddenly delete the commits from LLMs and all the instruction prompts I put together? What point do you plan to make with your silly appeal to authority?
I repeat: non-experts are proving to be possible, practical, and even mundane what your so-called experts claim to not work. What do you plan to draw from that?
GitHub is already rolling out this feature.
https://github.blog/news-insights/product-news/github-copilo...
Do what I couldn't with these supposedly capable LLMs:
- A Wear OS version of Element X for Matrix protocol that works like Apple Watch's Walkie Talkie and Orion—push-to-talk, easily switching between conversations/channels, sending and playing back voice messages via the existing spec implementation so it works on all clients. Like Orion, need to be able to replay missed messages. Initiating and declining real-time calls. Bonus points for messaging, reactions and switching between conversations via a list.
- Dependencies/task relationships in Nextcloud Deck and Nextcloud Tasks, e.g., `blocking`, `blocked by`, `follows` with support for more than one of each. A filtered view to show what's currently actionable and hide what isn't so people aren't scrolling through enormous lists of tasks.
- WearOS version of Nextcloud Tasks/Deck in a single app.
- Nextcloud Notes on WearOS with feature parity to Google Keep.
- Implement portable identities in Matrix protocol.
- Implement P2P in Matrix protocol.
- Implement push-to-talk in Element for Matrix protocol ala Discord, e.g., hold a key or press a button and start speaking.
- Implement message archiving in Element for Matrix protocol ala WhatsApp where a message that has been archived no longer appears in the user's list of conversations, and is instead in an `Archived` area of the UI, but when a new message is received in it, it comes out of the Archive view. Archive status needs to sync between devices.
Open source the repo(s) and issue pull requests to the main projects, provide the prompts and do a proper writeup. Pull requests for project additions need to be accepted and it all needs to respect existing specs. Otherwise, it's just yet more hot air in the comments section. Tired of all this empty bragging. It's a LARP and waste of time.
As far as I'm concerned, it is all slop and not fit for purpose. Unwarranted breathless hype akin to crypto with zero substance and endless gimmicks and kidology to appeal to hacks.
Guarantee you can't meaningfully do any of the above and get it into public builds with an LLM, but would love to be proven wrong.
If they were so capable, it would be a revolution in FOSS, and yet anyone who heavily uses it produces a mix of inefficient, insecure, idiotic, bizarre code.
Jokes aside, they are pretty different languages. I imagine you'd have much better luck going from .Net to Java.
People misjudge many tasks as 'hard' when they are in fact easy but tedious.
The problem is you need a high degree of accuracy, which you don't get with LLMs.
The best you can do is set the LLM on a loop and try and Brute force it, which is the current vibe 'coding' trick.
I sound pessimistic but I'm actually shocked at how effective it is.
(Yes I've seen the study, it doesn't account for motivation.)
And I’ll know by when I say do it once I mean, obviously processes have to be it on to get exactly what you want out of them, but that’s just how process works . Once it’s working the way you want to just reuse it.
Especially when asking the LLM to create a drawing program and a game the author would have probably received working code if he supplied the ai with documentation to the graphics function and sprite rendering using ATARI BASIC.
It confirm a bias for some, it triggers others who might have the opposite position (and maybe have a bias too on the other end).
Perfect combo for successful social media posts... literally all about "attention" from start to finish.
For example "Prompt: Write me an Atari BASIC program that draws a blue circle in graphics mode 7."
You need to know that there are various graphics modes and that mode 7 is the best for your use-case. Without that preexisting knowledge, you get stuck very quickly.
I started another project recently basically vibe coding in PHP. Instead of a single page app like I made before, it's just page by page single loading. Which means the AI also only needs to keep a few functions and the database in its head, not constantly work on some crazy ui management framework (what that's called).
It's made in a few days what would have taken me weeks as an amateur. Yet I know enough to catch a few 'mistakes' and remind it to do it better.
I'm happy enough.
I still agree with you for large applications but for these simple examples anyone with a basic understanding of vibe coding could wing it.
I believe many in this debate are confusing tools with magic wands.
sure it maybe someday but not today, but there are jobs that already get replaced tho for example like writing industry
Unfortunately, it's usually the ones who control the money.
* https://archive.org/details/ataribooks-computes-third-book-o...
* https://atariarchives.org/c3ba/page153.php
Fun fact: Orson Scott Card can be found in chapter 1.
I think that is a very vague and ambiguous way of putting it.
I would frame it a tad more specific: vibecode seems to work best when users know what they want and are able to set requirements and plan ahead.
Vibecoding doesn't work at all or is an unmaintainable god awful mess if users don't do software engineering and instead hack stuff together hoping it works.
Garbage in, garbage out.
That said, you can learn a lot using LLMs, which is nice. I have a friend who wants to learn Python, and I have given him actual resources, but I have also told him to use LLMs.
- Attempting to use BBC BASIC features in Atari BASIC, in ways that parsed but didn't work - Corrupting OS memory due to using addresses only valid on an Apple II - Using the ORG address for the C64, such that it corrupts memory if loaded from Atari DOS - Assembly that subtly doesn't work because it uses 65C02 instructions that execute as a NOP on a 6502 - Interrupt handlers that occasionally corrupt registers - Hardcoding internal OS addresses only valid for the OS ROM on one particular computer model
The POKE 77,0 in the article is another good example. ChatGPT labeled that as hiding the cursor, but that's wrong -- location 77 is the attract timer counter on the Atari OS. Clearing it to 0 periodically resets the timer that controls the OS's primitive screensaver. But in order for this to work, it has to be done periodically -- doing it at the start will just reset this timer once, after which attract mode will start in 9 minutes. So effectively, this is an easter egg that got snuck into the program, and even if the unrequested behavior was desirable, doesn't work.
For those that don't know. x87 was the FPU for 32-bit x86 architectures. It's not terribly complicated, but it uses stack-based register addressing with a fixed size (eight entry) stack.
All operations work on the top-of-stack register and one other register operand, and push the result onto the top of the stack (optionally popping the previous top of stack before the push).
It's hard but not horribly so for humans to write.. more a case of annoyingly slow and having to be methodical, because you have to reason about the state of the stack at every step.
I'd be very curious as to whether a token-prediction machine can get anywhere with this kind of task, as it requires a strong mental model of what's actually happening, or at least the ability to consistently simulate one as intermediate tokens/words.
In the error feedback cycle, it kept blaming Go, not itself. A bit eye opening.
When I struggle to write Go ASM, I also blame Go and not myself.
Whereas in most asm dialects, register AX is always register AX (word length aliasing aside), that's not the case for x87: the object/value at ST3 in one operation may be ST1 or ST5 in a couple of instructions' time.
A man visits his friend's house. There is a dog in the house. The friend says that the dog can play poker. The man is incredulous, but they sit at a table and have a game of poker; the dog actually can play!
The man says: "Wow! Your dog is incredibly, fantastically smart!"
The friend answers: "Oh, well, no, he's a naïve fool. Every time he gets a good hand, he starts wagging his tail."
Whether you see LLMs impressively smart or annoyingly foolish depends on your expectations. Currently they are very smart talking dogs.
"I taught my dog to whistle!"
"Really? I don't hear him whistling."
"I said I taught him, not that he learnt it."
“Excuse me! Can you help me? I promised a friend I’d meet him, but I have no idea where I am.”
The man replies, “You’re in a hot air balloon, hovering 30 feet above the ground, somewhere between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude.”
“You must be a Prompt Engineer,” says the balloonist.
“I am,” replies the man. “How did you know?”
“Well,” says the balloonist, “everything you told me is technically correct, but it’s of no use to me and I still have no idea where I am.”
The man below replies, “You must be a Vibe Coder.”
“I am,” says the balloonist. “How did you know?”
"Because you don’t know where you are or where you’re going. You made a promise you can’t keep, and now you expect me to solve your problem. The fact is, you’re in the same position you were in before we met, but now it’s somehow my fault!"
https://www.reddit.com/r/Jokes/comments/74lb9d/engineer_vs_m...
The employee shouts back "In an airplane!" The pilot nods, sets a course, and navigates precisely 11 nautical miles NNE, and descends. Sure enough, a runway appears and he lands perfectly. Of course, he's debriefed about the incident. "How, " the investigator asks, "Did you find the airport?"
The pilot recounts the shouted conversation. "My question was answered in a way that was absolutely correct but useless for any practical purpose. I reasoned that I was talking to Microsoft Tech Support at their HQ, and I could dead reckon to Redmond Municipal Airport from there."
Fred insists to his friend that he has a hyper intelligent dog that can talk. Sceptical, the friend enquires of the dog "What's 2+2?"
"Five" says the dog
"Holy shit a talking dog!" says the friend "This is the most incredible thing that I've ever seen in my life".
"What's 3+3?"
"Eight" says the dog.
"What is this bullshit you're trying to sell me Fred?"
> "Holy shit a talking dog!" says the friend "This is the most incredible thing that I've ever seen in my life".
this happens:
"Yes," says Fred. "As you can see, it's already at PhD level now, constantly improving, and is on track to replace 50% of the economy in twelve months or sooner."
Confused, the friend asks:
> "What's 3+3?"
> "Eight" says the dog.
> "What is this bullshit you're trying to sell me Fred?"
> The friend asks: "Alright. Doggy, answer as fast as you can without thinking. What is 387 times 521?"
> "201.627", the dog says, wagging his tail happily.
> "I don't buy it, Fred! This must be bullshit!"
(I did test it and it did give the correct answer. I was expecting a small error for the joke, but hey, works like this too.)
> 1 % of GDP
LLMs are basically the only thing genuinely new in decades , that have someone excited in basically every dept in the entirely world, why is it so bad that we spend money on them? The alternative is going back to shovelling web3 crap.
There's definitely a new generation of bullshit merchants to go with LLMs but I think they (the models) target a very different part of the brain to normal tech so in some ways they're much more resilient to usual fad archetypes (this is also why some people who are a bit jittery socially hate them)
This money (and more importantly, this electricity and this amount of silicon) is diverted from other stuff.
It’s just a technology; one that will improve, sometimes stagnate, sometimes accelerate. Like anything else, right? I don’t see a time when we’ll just stop using AI because it “feels so trite.”
But if it is a half decent chatbot and has the label "AI", it gets another iteration with 10x the resources. This has happened a few times already.
It is a neat tool. It is very unreliable. Teams saying "just give us 10x as much resources so we can insist on this approach" is the hateful thing here.
The Owl and the Fireflies
One twilight, deep in the woods where logic rarely reached, an Owl began building a nest from strands of moonlight and whispers of wind.
"Why measure twigs," she mused, "when I can feel which ones belong?"
She called it vibe nesting, and declared it the future.
Soon, Fireflies gathered, drawn to her radiant nonsense. They, too, began to build — nests of smoke and echoes, stitched with instinct and pulse. "Structure is a cage," they chirped. "Flow is freedom."
But when the storm came, as storms do, their nests dissolved like riddles in the rain.
Only the Ants, who had stacked leaves with reason and braced walls with pattern, slept dry that night. They watched the Owl flutter in soaked confusion, a nestless prophet in a world that demanded substance.
Moral: A good feeling may guide your flight, but only structure will hold your sky.
For example, if the llm had a compile tool it would likely have been able to correct syntax errors.
Similarly, visual errors may also have been caught if it were able to run the program and capture screens.
I once heard advice on trying to re-read the text you see in dreams. And I did that once. It was a phrase where one of words referred to a city. The first time I read that city was "London". I remembered the advice and re-read the phrase and the word changed to the name of an old Russian city "Rostov". Yet the phrase was "same", that is it felt same in the dream, even though the city was different.
LLMs are like that dream mechanics. It is how something else is reflected in what we know (e.g. an image of a city is rendered as a name of a city, just any city). So, on one hand, we do have a similar mechanism in our minds. But on another hand our normal reasoning is very much unlike that. It would be a very wild stretch to believe that reasoning somehow stems from dreaming. I'd say reasoning is opposite to dreaming. If we amplify our dreaming mechanics we won't get a genius; more likely we'll get a schizophrenic.
These tools are obviously not reasoning tools in the classic sense, as they're not building off of core axiomic truths like classic logic. These truths may be largely embedded in the probabilistic output, due to the input universe that we feed it being based on human reason, but it's certainly not in a power of these tools. That said, of course we are attacking on more and more of this ability (ability to check databases of facts, iterative "reasoning" models, etc) so they are becoming "adequate" in these respects.
The dreaming comparison seems quite apt though. I entirely get what you mean by rereading the dream word and seeing it suddenly transformed to another city name, yet somehow also "fitting". For some reason I'm keenly aware of these sorts of relationships when I think about my dreams. I will think of a situation and immediately be able to identify the input memories that "built" the dream scenario. Usually they involve overlapping themes and concepts, as well as some human specific common targets like "unresolved, emotionally charged, danger, etc" (presumably running through these types of brain neurons provides some sort of advantage for mammals, which makes sense to me).
What an LLM does is essentially create a huge interconnected conceptual web of the universe which is fed, and then uses probably ballistic models to travel through these chains, much like how dreaming does a trance like dance through these conceptual connections. In the former example though, we have optimized the traversal to be as close to a "mock awake human" as possible. If the dream poem is dreary in nature, and Rostov sounds dreary, and you were hearing about the dreary London rain earlier in the day, and you have a childhood memory of reading through a dreary poem that made you very sad, that's the perfect sort of overlapping set of memory synapses for a dream to light up. And when looking back, all you'll see is a strange fantasmic and (usually, not always) frustratingly inaccessible conglomeration of these inputs.
This sort of traversal isn't just used in dreaming though. To some degree we're doing similar things when we do things like creative thinking. The difference is, and this is especially so in "modern" life, we're strongly filtering our thoughts through language first and foremost (and indeed there's a lot of philosophical and scientific work done about how extremely important language is to humanness), but also through basic logic.
LLM's inherent some of the power/magic of language, in that it is deconstructing the relationships between the concepts behind language that contains so much embedded meaning. But they aren't filtering through logic like we do. Well, reasoning models do to some degree, but it is obviously quite rudimentary.
I think it's a good analogy.
.. either way, I’m super happy that it has kept my drives to work very interesting!
My first thought reading the article was that Atari BASIC is kind of a little specialized. If BASIC is kind of an under-represented language in general on the internet (you know, compared to Javascript, for example) then Atari BASIC has to be a white whale.
Also, sure, compared to Javascript it's a small amount.
I made it this far and realized the rest wasn’t worth reading. Language evolves, words change, and AI means what it means now. It turns out it’s actually really useful to have an abstraction above the concept of LLMs to talk about the broader set of these types of technologies, and generally speaking I find that these very pedantic types of people don’t bring me useful new perspectives.
I agree that "AI" can be useful as an umbrella term, but using it when referring specifically to the "LLM" subset of AI technologies is not useful. A ton of information about the capabilities and limitations of the system is lost when making that substitution. I understand why marketing departments are pushing everything as "AI" to sell a product but as consumers we should be fighting against that.
firesteelrain•6mo ago
Try a local LLM then train it
ofrzeta•6mo ago
How do you do this?
sixothree•6mo ago
firesteelrain•6mo ago
oharapj•6mo ago
firesteelrain•6mo ago
1. Gather training data
2. Format it into JSONL or Hugging Face Dataset format
3. Use Axolotl or Hugging Face peft to fine-tune
4. Export model to GGUF or HF format
5. Serve via Ollama
https://adithyask.medium.com/axolotl-is-all-you-need-331d5de...
https://www.philschmid.de/fine-tune-llms-in-2025
https://blog.devgenius.io/complete-guide-to-model-fine-tunin...
ofrzeta•6mo ago
firesteelrain•6mo ago
When I fine tuned a Mistral 7B model it took hundreds of examples in Alpaca style
It’s a lot of work. Maybe OpenAI has a more efficient way of doing it because in my case I had to manually adjust each prompt
Paradigma11•6mo ago
You can add some tutorials/language docs as context without any problem. The bigger your project gets the more context it gets from there. You can also convert apis/documentation to a RAG and expose it as a MCP tool to the LLM.
ofrzeta•6mo ago
You mean around 3000 files with 3000 characters? That is a lot. I've played with some other LLMs in Agentic AIs but at work we are using Copilot, and when I add context through drag and drop it seems to be limited to some dozen files.
Paradigma11•6mo ago
ofrzeta•6mo ago
Paradigma11•6mo ago
Gemini is better than Sonnet if you have broad questions that concern a large codebase, the context size seems to help there. People also use subagents for specific purposes to keep each context size manageable, if possible.
On a related note I think the agent metaphor is a bit harmful because it suggests state while the LLM is stateless.