That's the frustrating thing. LLMs don't materially reduce the set of problems where I'm running against a wall or have trouble finding information.
I think of it as making the top bar of the T thicker, but yes, you're right, it also spreads it much wider.
* To catch passive voice and nominalizations in my writing.
* To convert Linux kernel subsystems into Python so I can quickly understand them (I'm a C programmer but everyone reads Python faster).
* To write dumb programs using languages and libraries I haven't used much before; for instance, I'm an ActiveRecord person and needed to do some SQLAlchemy stuff today, and GPT 4o (and o1) kept me away from the SQLAlchemy documentation.
OpenAI talks about o1 going head to head with PhDs. I could care less. But for the specific problem we're talking about on this subthread: o1 seems materially better.
Do you have an example chat of this output? Sounds interesting. Do you just dump the C source code into the prompt and ask it to convert to Python?
def linear_ctr(target, argc, argv):
print("Constructor called with args:", argc, argv)
# Initialize target-specific data here
return 0
def linear_dtr(target):
print("Destructor called")
# Clean up target-specific data here
def linear_map(target, bio):
print("Mapping I/O request")
# Perform mapping here
return 0
linear_target = DmTarget(name="linear", version=(1, 0, 0), module="dm_mod")
linear_target.set_ctr(linear_ctr)
linear_target.set_dtr(linear_dtr)
linear_target.set_map(linear_map)
info = linear_target.get_info()
print(info)
(A bunch of stuff elided). I don't care at all about the correctness of this code, because I'm just using it as a roadmap for the real Linux kernel code. The example use case code is an example of something GPT 4o provides that I didn't even know I wanted.I do feel like someone who skipped like 8 iPhone models (cross-referencing, EIEIO, lsp-mode, code explorers, tree-sitter) and just got an iPhone 16. Like, nothing that came before this for code comprehension really matters all that much?
Tangentially related, a comic on them: https://existentialcomics.com/comic/557
I can't think of many situations where I would use them for a problem that I tried to solve and failed - not only because they would probably fail, but in many cases it would even be difficult to know that it failed.
I use it for things that are not hard, can be solved by someone without a specialized degree that took the effort to learn some knowledge or skill, but would take too much work to do. And there are a lot of those, even in my highly specialized job.
As you step outside regular Stack Overflow questions for top-3 languages, you run into limitations of these predictive models.
There's no "reasoning" behind them. They are still, largely, bullshit machines.
It often fails even for those questions.
If I need to babysit it for every line of code, it's not a productivity boost.
It's shit across the whole "AI" spectrum from ChatGPT to Copilot to Cursor aka Claude.
I'm not even talking about code I work with at work, it's just side projects.
As for "using LLMs wrong", using them "right" is literally babysitting their output and spending a lot of time trying to reverse-engineer their behavior with increasingly inane prompts.
Edit: I mean, look at this ridiculousness: https://cursor.directory/
You underestimate the opportunity that exists for automation out there.
In my own case I've used it to make simple custom browser extensions transcribing PDFs, I don't have the time and wouldn't of made the effort to make the extension myself, the task would of continued to be done manually. It took two hours to make and it works, that's all I need in this case.
Perfection is the enemy of good.
Where exactly did I write anything about perfection? For me "AIs" are incapable of producing working code: https://news.ycombinator.com/item?id=41534233
Your example is perhaps valid, but there are other examples where it does work as I mentioned. I think it may be imprecise prompting, too general or with too little logic structure. It's not like Google search, the more detail and more technical you speak the better, assume it's a very precise expert. Its intelligence is very general so it needs precision to avoid confusing subject matter. A well structured logic to your request also helps as it's reasoning isn't the greatest.
Good prompting and verifying output is often still faster than manually typing it all.
No. It either doesn't work, or works incorrectly, or the code is incomplete despite requirements etc.
> Your example is perhaps valid, but there are other examples where it does work as I mentioned.
It's funny how I'm supposed to assume your examples are the truth, and nothing but the truth, but my examples are "untrue, you're a perfectionist, and perhaps you're right"
> the more detail and more technical you speak the better
As I literally wrote in the comment you're so dismissive of: "As for "using LLMs wrong", using them "right" is literally babysitting their output and spending a lot of time trying to reverse-engineer their behavior with increasingly inane prompts."
> assume it's a very precise expert.
If it was an expert, as you claim it to be, it would not need extremely detailed prompting. As it is, it's a willing but clumsy junior.
To the point that it would rewrite the code I fixed with invalid code when asked to fix an unrelated mistake.
> Good prompting and verifying output
How is it you repeat everything I say, and somehow assume I'm wrong and my examples are invalid?