[Ntrails]

> Programming is just shifting to a language that looks more like Jira tickets than source code.

Sure, but now I need to be fluent in prompt-lang and the underlying programming language if you want me to be confident in the output (and you probably do, right?)

[lordnacho]

No, you have to be fluent in the domain. That is ultimately where the program is acting. You can be confident it works if it passes domain level tests.

You save all the time that was wasted forcing the language into the shape you intended. A lot of trivial little things ate up time, until AI came along. The big things, well, you still need to understand them.

[majormajor]

> You can be confident it works if it passes domain level tests.

This is generally true for things you run locally on your machine IF your domain isn't super heavy on external dependencies or data dependencies that cause edge cases and cause explosions in test cases. But again, easier to inspect/be sure of those things locally for single-player utilities.

Generally much less true for anything that touches the internet and deals with money and/or long-term persistent storage of other people's data. If you aren't fluent in that world you'll run software built on old versions of third party code with iterations to make further changes that have to be increasingly broad in scope against a set of test cases that is almost certainly not as creative as a real attacker.

Personally I would love to see stuff move back to local user machines vs the Google-et-al-owned online world. But I don't think "cheap freeware" was the missing ingredient that prevented the corporate consolidation. And so people/companies who want to play in that massively-online world (where the money is) are still going to have to know the broader technical domain of operating online services safely and securely, which touches deep into the code.

So I, personally, don't have to be confident in one-off or utility scripts for manual tasks or ops that I write, because I can be confident in the domain of their behavior since I'm intimately familiar with the surrounding systems. Saves me a TON of time. Time I can devote to the important-to-get-correct code. But what about the next generation? Not familiar with the surrounding systems, so not even aware of what the domains they need to know (or not know) in depth are? (Maybe they'll pay us a bunch of money to help clean up a mess, which is a classic post-just-build-shit-fast successful startup story.)

[hnlmorg]

I think the GP is correct.

You can get some of the way writing prompts with very little effort. But you almost always hit problems after a while. And once you do, it feels almost impossible to recover without restarting from a new context. And that can sometimes be a painful step.

But with learning to write effective prompts will get you a lot further, a lot quicker and with less friction.

So there’s definitely an element of learning a “prompt-lang” to effective use of LLMs.

[GrowingSideways]

> Sure, but now I need to be fluent in prompt-lang and the underlying programming language if you want me to be confident in the output (and you probably do, right?)

Using a formal language makes the problem space unambiguous. That is just as much a benefit as it is a barrier to entry. Once you learn this formal language, the ability to read code and see the surface area of the problem is absolutely empowering. Using english to express this is an exercise in frustration (or, occasionally, genius—but genius is not necessary with the formal language).

Programs are not poetry!