The usage of the word "reasoning" in the context of LLMs, just like the "I" in "AI", that's more marketing than a technical reality. I know it can be confusing.
Regardless of semanthics, LLMs + tooling can do impressive things.
For example I can tell LLMs to scan my database schema and compare to code to detect drift or inconsistencies.
And while doing that it has enough condensed world knowledge to point to me that the code is probably right when declaring person.name a non-nullable string despite the database column being nullable.
And it can infer that date_of_birth column is correct in being nullable on the database schema and wrong in code where the type is a non-nullable date because, in my system, it knows date_of_birth is an optional field.
This is a simple example that can be solved by non-LLMs tooling also. In practice it can do much more advanced reasoning with regards to business rules.
We can argue semanthics all day but this is reason enough to be useful for me.
There are many examples I could give. But to the skeptics I recommend trying to use LLMs for understanding large systems. But take your time to give it read only access to data base schema.
Note: this is not directed at the commenter or any person in particular. It is directed at various patterns I've noticed.
I often notice claims like the following:
- human intelligence is the "truest" form of intelligence;
- machines can't reason (without very clearly stating what you mean by reasoning);
- [such and such] can only be done by a human (without clearly stating that you mean at the present time with present technology that you know of);
Such claims are in my view, rather unhelpful framings – or worse, tropes or thought-terminated clichés. We would be wise to ask ourselves how such things persist.
How do these ideas lodge in our brains? There are various shaky premises (including cognitive missteps) that lead to them. So I want to make some general comments that often lead to the above kind of thinking.
It is more important than ever for people to grow their understanding and appreciation. I suggest considering the following.
1. ... recognize that one probably can't offer a definition of {reasoning, intelligence, &c} that is widely agreed upon. Probably the best you can hope for is to clarify the sense of which you mean. There are often fairly clear 'camps' that can easily be referenced.
2. Recognition that implicitly hiding a definition in your claims -- or worse, forcing a definition on people -- doesn't do much good.
3. Awareness that one's language may be often interpreted in various ways by reasonable people.
4. Internalize dictionaries are catalogs of various usage that evolve over time. Dictionaries are not intended to be commandments of correctness, though some still think dictionary-as-bludgeon is somehow appropriate.
3. Acknowledge confusing terminology in AI/LLM in particular. For example, reasonable people can recognize that "reasoning" in this context is a fraught term.
5. Recognition that humanity is only getting started when it comes to making sense of how "intelligence" decomposes, how our brains work, the many nuanced differences between machine intelligence and human intelligence.
6. Recognize one's participation in a social context. Strive to not provide fuel for the fires of misunderstanding. If you use a fraught term, be extra careful to say what you mean.
7. Hopefully obvious: sweeping generalizations and blanket black-or-white statements are unlikely to be true unless you are talking about formal systems like logic and mathematics. Just don't do it. Don't let your thinking fall into that trap. And don't spew it -- that insults the intelligence of one's audience.
8. Generally speaking, people would be wise† to think about upping their epistemic game. If one says things that are obviously inaccurate, you are wasting your intelligence refined over millions of years by evolution and culture. To do so is self-destructive, for it makes oneself less valuable relative to LLMs who (although they blunder) are often more reliable than people who speak carelessly.
† Because it benefits the person directly and it helps culture, civilization, progress, &c
It would help if I had a better understanding of what you mean by "that".
I generally write to liberate my consciousness from isolation. When doing so in a public forum I am generally doing so in response to an assertion. When responding to an assertion I am generally attempting to understand the framing which produced the assertion.
I suppose you may also be speaking to the voice which is emergent. I am not very well read, so you may find my style unconventional or sloppy. I generally try not to labor too much in this regard and hope this will develop as I continue to write.
Honestly the scary part is that we don’t really even need one more Opus. If all we had for the rest of our lives was Opus 4.5, the software engineering world would still radically change.
It's a not very exciting C# command-line app that takes a PDF and emits it as a sprite sheet with a text file of all the pixel positions of each page :)
lol, I probably don't have any, actually. If I recall, I would just write comments when my question differed slightly from one already there.
But it's definitely the case that being able to go back and forth quickly with an LLM digging into my exact context, rather than dealing with the kind of judgy humorless attitude that was dominant on SO is hugely refreshing and way more productive!
One of Rust's core guarantees is that a race condition in safe code will never cause UB. It might return a nondeterministic result, but that result will be safe and well-typed (for example, if it's a Vec, it will be a valid Vec that will behave as expected and, once you have a unique reference, is guaranteed not to change out from under you).
When talking about the kind that lead to torn memory writes, no it doesn't have those. To share between threads you need to go through atomics or mutexes or other protection methods.
USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks
You've linked to a bug that was unintentional and was fixed.
Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed.
Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
I think this is starting to wander rather far afield from where this thread started...
But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.
Ok, if you have such insight into development, why not leverage agents to type for you? What sort of problems have you faced that you are able to code against faster than you can articulate to an agent?
I have of course found some problems like this myself. But it's such a tiny portion of coding I really question why you can't leverage LLMs to make yourself more productive
