Hacker News Reader

Comment by emseetech | Hacker News Reader

Everyone's suggestions feel designed to frustrate me. Instructions on how to cajole and plead that seem more astrology than engineering.

This is the pattern I settled on about a year ago. I use it as a rubber-duck / conversation partner for bigger picture issues. I'll run my code through it as a sanity "pre-check" before a pr review. And I mapped autocomplete to ctrl-; in vim so I only bring it up when I need it.

Otherwise, I write everything myself. AI written code never felt safe. It adds velocity but velocity early on always steals speed from the future. That's been the case for languages, for frameworks, for libraries, it's no different for AI.

In other words, you get better at using AI for programming by recognizing where its strengths lie and going all in on those strengths. Don't twist up in knots trying to get it to do decently what you can already do well yourself.

View on HN

Same. AI is a good tool to use as a sounding board and conversation partner.

I only access claude and others using my browser - I give it a snippet of my code, tell it what exactly I want to do and what my general goal is, then ask it to give me approaches, and their pros and cons.

Even if someone wants to use AI to code for them, its still better to do the above as a first step imo. A sort of human in the loop system.

> It adds velocity but velocity early on always steals speed from the future. That's been the case for languages, for frameworks, for libraries, it's no different for AI.

Completely agree. I'm seeing this in my circle and workplace. My velocity might be a tad bit slower than the rest of my peers when you compare it per ticket. But my long tern output hasn't changed and interestingly, neither has anyone else's.

As an aside, I like your system of completely removing autocomplete unless you need it - may be something like that would finally get me to enable AI in my IDE.

This is the only approach that seems even remotely reasonable

“Prompt engineering” just seems dumb as hell. It’s literally just an imprecise nondeterministic programming language.

Before a couple years so, we all would have said that was a bad language and moved on.

A few years ago we didn't have an imprecise nondeterministic programming language that would allow your mom to achieve SOTA results on a wide range of NLP tasks by asking nicely, or I'm sure people would have taken it.

I think a lot of prompt engineering is voodoo, but it's not all baseless: a more formal way to look at it is aligning your task with the pre-training and post-training of the model.

The whole "it's a bad language" refrain feels half-baked when most of us use relatively high level languages on non-realtime OSes that obfuscate so much that they might as well be well worded prompts compared to how deterministic the underlying primitives they were built on are... at least until you zoom in too far.

I don't buy your past paragraph at all I am afraid. Coding langues, even high level ones, are built upon foundations of determism and they are concise and precise. A short way to describe very precisely, a bunch of rules and state.

Prompting is none of those things. It is a ball of math we can throw words into, and it approximates meaning and returns an output with randomness built in. That is incredible, truly, but it is not a programming language.

Eh, how modern technology works is not really the part I'm selling: that's just how it works.

Coding languages haven't been describing even a fraction of the rules and state they encapsulate since what? Punch cards?

It wasn't long until we started to rely on exponential number of layered abstractions to do anything useful with computers, and very quickly we traded precision and determinism for benefits like being concise and easier to reason about.

But also, the context here was someone calling prompting a "imprecise nondeterministic programming language": obviously their bone is the "imprecise nondeterministic" part, not distilling what defines a programming language.

I get it doesn't feel warm and fuzzy to the average engineer, but realistically we were hand engineering solutions with "precise deterministic programming languages", they were similarly probabilistic, and they performed worse.

Name a single programming language that is probabilistic in any way?

- A text prompt isn't probabilistic, the output is.

- https://labs.oracle.com/pls/apex/f?p=LABS:0:5033606075766:AP...

- https://en.wikipedia.org/wiki/Stan_(software)

- https://en.wikipedia.org/wiki/Probabilistic_programming

I explained in the most clear language possible why a fixation on the "programming language" part of the original comment is borderline non-sequitur. But if you're insistent on railroading the conversation regardless... at least try to be good at it, no?

I skimmed your comment since you were making the strange comparison that modern coding is basically probabilistic to a degree that prompting is, so I see now you weren't the one to say it's "probabilistic programming". But you are still trying to say that normal programming is basically probabilistic in some relevant way, which I think is quite ridiculous. I don't see how anything about normal engineering is probabilistic other than mistakes people make.

"I didn't do the absolute bare minimum and read the comment I replied to, so here's 100 words excusing that."

Do you mean, like, scripting languages? Are the underlying primitives C and machine language? "Might as well be well worded prompts" is the overstatement of the century; any given scripting language is far closer to those underlying layers than it is to using natural language with LLMs.

Sure doesn't seem like it. https://x.com/jarredsumner/status/1999317065237512224

And forget scripting languages, take a C program that writes a string to disk and reads it back.

How many times longer does it get the moment we have to ensure the string was actually committed to non-volatile NAND and actually read back? 5x? 10x?

Is it even doable if we have to support arbitrary consumer hardware?

You're stretching really hard here to try and rationalize your position

First of all, I pick the hardware I support and the operating systems. I can make those things requirements when they are required.

But when you boil down your argument, it's that because one thing may introduce non-determinism, then any degree of non-determinism is acceptable.

At that point we don't even need LLMs. We can just have the computer do random things.

It's just a rehash of the infinite monkeys with infinite type writers which is ridiculous

No the point was quite clear:

> A few years ago we didn't have an imprecise nondeterministic programming language that would allow your mom to achieve SOTA results on a wide range of NLP tasks by asking nicely, or I'm sure people would have taken it.

But that (accurate) point makes your point invalid, so you'd rather focus on the dressing.

We still don't have that programming language (although "SOTA" and "wide range of NLP tasks" are vague enough that you can probably move the goalposts into field goal range).

This comment is written way too adversarially for someone who doesn't know what NLP is.

> nondeterministic programming language that would allow your mom to achieve SOTA results

I actually think it's great for giving non-programmers the ability to program to solve basic problems. That's really cool and it's pretty darn good at it.

I would refute that you get SOTA results.

That has never been my personal experience. Given that we don't see a large increase in innovative companies spinning up now that this technology is a few years old, I doubt it's the experience of most users.

> The whole "it's a bad language" refrain feels half-baked when most of us use relatively high level languages on non-realtime OSes that obfuscate so much that they might as well be well worded prompts compared to how deterministic the underlying primitives they were built on are... at least until you zoom in too far.

Obfuscation and abstraction are not the same thing. The other core difference is the precision and the determinism both of which are lacking with LLMs.

It's technically deterministic, but it feels nondeterministic in chatbots since tokens are randomly sampled (temp > 0) and input is varied. Using the right prompt makes the model perform better on average, so it's not completely dumb.

I like task vectors and soft prompts because I think they show how prompt engineering is cool and useful.

https://arxiv.org/pdf/2310.15916

https://huggingface.co/docs/peft/conceptual_guides/prompting

> It's technically deterministic, but it feels nondeterministic in chatbots since tokens are randomly sampled

Are you not aware the random sampling makes something non-deterministic?

I'm saying LLMs are deterministic and because of that, prompt engineering can be effective. You knew what I was trying to say, but chose to ignore it.

You should follow the HN Guidelines. I'm trying to have a discussion, not a snarkfest.

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

I don’t believe that when he wrote that, he was using his own intelligence

At least I'm adding to the discussion.

People who disagree with you add to the discussion too

You know what else is nondeterministic? "Project Management"

You tell humans to make code, they make code.

How do you check it's correct and does what it should?

Humans have agency and accountability, duty of care, etc.

How does a random programmer have "duty of care"?

They're paid to ship a feature, why would they spend extra time making something perfect? If it breaks they just fix it - and get paid doing it.

Not everyone writing code in a corporation is a Code Artesan who handcrafts every single character with thought and precision like an old Japanese craftsman. They just write code, it does about what it should and push a PR branch. Then you grab the next task from the corporate Jira project.

> How does a random programmer have "duty of care"?

Are there jobs that don't care if you don't take due care when writing code? I'd like me one of those.

AIstrology is a term I can get behind.

I think that really captures what I find most irksome about the fanaticism. It's not prompt engineering, it's a statistical 8-ball being shaken until useful output appears.

Just as with any pseudoscience, it can offer a glimmer of usefulness by framing problems in a different way. Just be cautious of who's offering that enlightenment and how much money you may be paying for it.

> how to cajole and plead

When a new person join the team you need to tell them the local coding standard. I don't see why people expect llm to work out of the box instead. The difference is you have to do it at every exchange as llm are stateless.

But yeah I mostly agree with the rest llm work best at very low lewel method by method where you can watch like an hawk they don't introduce silent failure condutions and super high level as system design as reasoning engine, and they still do not so good job at implementing components whole.

Both human and AI should be able to understand the "way we do things around here" by reading the existing code. I could spend an hour telling someone how to write idiomatic code, and they will forget all of it until they actually do some work and see the codebase.

When Claude reads a significant portion of my codebase into context it should be suggesting idiomatic changes. Even if it doesn't initially read a bunch of the codebase to figure out a solution, it should definitely then be trained to do so explicitly to understand the coding standards. Just like a decent dev would do on their own.

if you'd be right that code is so self evident project wouldn't have a coding.md or a contributing.md

> I don't see why people expect llm to work out of the box instead

because it's not a person? because you have to do it all the time? because of the way literally all other software works?

The coding standard is quality code and one should bring it with themselves comming into the company. And if you mean linter & formatting rules then if company is not young then their elders had a fist fight to settle once and for all one standard, zip it into a file and everybody just use it

I don't think anyone would say that the LLMs will produce better code, but they can do it much faster.

I personally did not hit the wall where the use of LLMs would slow me down in the long run.

It has been smooth sailing most of the time, and getting better with newer models.

For me it comes down to "know what you are being paid for".

I'm not a library maintainer. My code will not be scrutinized by thousands of peers. My customer will be happy with faster completion that does the same thing like the more perfect hand crafted version.

Welcome to the industrial revolution in programming. This is the way of things.

Reply on news.ycombinator.com