They don't. After running, for the values in small_numbers from 0 to smlen-1 they are equivalent.
But if the last value of numbers[] is not smaller than 500, small_numbers[smlen] will contain that value for the first version whereas the second version does not write to small_numbers[smlen].
The more context an LLM gets, the more likely it will start to ignore instructions.
If the LLM runs a context compression, all bets are off. There's a reason Anthropic upped the context to 1M tokens to reduce the chance of this from happening.
Come on, now. The human writes the plan up front, which includes guidance on testing strategy, classes of tests, particular test cases to cover, etc. And just like normal, of course you don't just ship the code without doing manual verification, code review, auditing the test cases, and all the rest.
> If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
> That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
I disagree. The amount of commits is not from somebody who is carefully reviewing the new code and considering the changes done. It's from somebody who thinks they are in control and think they can guardrail the AI.
I've seen this at work as well. Maybe it's a small case of the braineater that so many tech bros get when they get older. But they talk about the AI as if it were a being that can be reasoned with and not that it's just a statistical interpolator and autocompleter.
I know when I'm vibe coding. Just last week I needed 5 colors for a green to read gradient for visualisation some states. I ended up with a script that outputs arbitray color gradients in 5 different colorspaces (including a colorspace for which AFAIK there's no support in Ruby as of now) and additionally also considers different color vision deficiencies.
Is it useful? Yes. Would I run this code in production? Hell no.
This is a common fallacy: that vibecoding is not that bad if one carefully reviews the output. It's true in a vacuum, but what happens when you're late and stressed out and can't be bothered with doing a proper job.
Humans are lazy, and the mistakes of being lazy when vibe coding are orders of magnitude larger than being lazy when you have to do the damn thing yourself. In fact in the latter case, laziness is a feature.
If the AI-powered software world depends on humans not being lazy, we're all fucked.
or more generously, replace lazy with tired. even if you have all the intention of reading all the code in detail, when you are tired you are less attentive.
finally, reading code can never achieve the same detailed understanding that you would get from writing it. reading anything in general can't achieve the same understanding as writing. our brain tries to optimize. you see something familiar, you skip over it because you recognize it, and that causes you to miss subtle details.
the one thing i wonder though is, how much would it help if i use AI to generate some code but then, instead of just copying the whole thing, i type it all in by hand. does that give me enough attention to review? does that still give me any benefit of using AI with less downsides?
At what point it’s just easier to do the whole thing yourself, perhaps prompting AI to give you guidelines and which whom to discuss the design, but never using it to code?
But then again, the day one is lazy or tired, one will choose the shortcut of having the machine just write the code.
well yes, that why i concluded that at this point using AI to help me is just not worth it. i'll wait until the reliability goes up and the level of frustration goes down.
for myself i don't even want to use it to learn because i a afraid of being told things that are false or don't exist. i already had that experience, spending hours trying to figure out why my code wasn't working until i realized that the AI told me to use a property or function that didn't exist. i hate wasting time and effort like that.
I apologize, may I ask you, do you use Bun? If yes, you probably do monitor the development of this project (I do, it sounds reasonable to track your tools/deps), probably familiar with Jared's coding style, decision making process, architecture nuances, previous choices? Do you have any issues opened/closed in Bun's repo? Were you satisfied with contributors' reaction? Do you feel you can trust devteam behind Bun?
I get it if you're trying to defend your buddy, but at the end of the day it's on software to justify itself to me. Not for me (or parent poster) to justify their refusal.
Once bitten twice shy, y'know. Maybe the first bite wasn't even from bun. If bun can't take this on the chin and come back stronger, maybe bun wasn't a good choice to begin with. I'm sure a future version of bun with a rebuilt reputation will have an easy time getting re-adopted by most projects that needed to play it safe during the transition.
the speed of the rewrite and various analyses of the resultant codebase provide ample evidence that it was vibe coded and solid SWE practices were ignored
nobody understands the Bun Rust codebase. I wouldn't risk my business on code understood by no person. who is responsible? who will take accountability?
Show me a forum or topics based platform that handle threads as good as proper mail clients? Don’t mistake the poor HTML view for how managing threads with thousands of replies look like.
Local filtering is the key to ignoring threads you are not interested in. Depending on the client with 2 or 3 keystrokes you are ignoring the whole thread or this particular sub branch of it and automatically jumping to the next interesting, unread message.
It never came to pass when we used Oracle, maybe now with Postgres I will finally have a chance at it.
reply