231–240 of 291 posts
>> what if we treated prompts as the actual source code? And they probably will be. Looks like prompts have become the new higher-level coding language, the same way JavaScript is a human-friendly abstraction of an existing programming language (like C), which is already a more accessible way to write assembly itself, and the same goes for the underlying binary code... I guess we eventually reached the final step in…
Earlier quoted context omitted.
To me, LLMs are just a different kind of social interaction I mostly don’t want, tedious and frustrating.
But it is not a social interaction. An LLM is a machine. I think there is also a big difference between being forced to use an LLM in a certain way, and being able to completely design your interaction with the LLM yourself. The former I imagine can be indeed tedious and frustrating, the latter is just miraculous.
> Reading through these commits sparked an idea: what if we treated prompts as the actual source code? Imagine version control systems where you commit the prompts used to generate features rather than the resulting implementation. Please god, no, never do this. For one thing, why would you not commit the generated source code when storage is essentially free? That seems insane for multiple reasons. > When models ine…
I'm the first to admit that I'm an AI skeptic, but this goes way beyond my views about AI and is a fundamentally unsound idea. Let's assume that a hypothetical future AI is perfect. It will produce correct output 100% of the time, with no bugs, errors, omissions, security flaws, or other failings. It will also generate output instantly and cost nothing to run. Even with such perfection this idea is doomed to failure…
Earlier quoted context omitted.
But it is not a social interaction. An LLM is a machine. I think there is also a big difference between being forced to use an LLM in a certain way, and being able to completely design your interaction with the LLM yourself. The former I imagine can be indeed tedious and frustrating, the latter is just miraculous.
No one is forcing me to use LLMs, so that’s not it. The interaction is social in the sense that it is natural-language based and nondeterministic, and that LLMs exhibit a certain “character”. They have been trained to mimic certain kinds of human social interaction.
Earlier quoted context omitted.
Because if the LLM is a black box and its output must ultimately be verified by humans, then you can't treat conversion of prompts into code as a simple build step as though an AI agent were just some sort of compiler. You still need to persist the actual code in source control. (I assume that isn't what you're actually arguing against, in which case at least one of us must have misread something from the parent chai…
Right, you definitely can't do that. People do talk as if the question was whether we could stick LLM calls into Makefiles. Nobody would ever do that, at least not with the technology we have at hand.
Earlier quoted context omitted.
The idea as stated is a poor one, but a slight reshuffling and it seems promising: You generate code with LLMs. You write tests for this code, either using LLMs or on your own. You of course commit your actual code: it is required to actually run the program, after all. However you also save the entire prompt chain somewhere. Then (as stated in the article), when a much better model comes along, you re-run that chain…
Means the temperature should be set to 0 (which not every provider supports) so that the output becomes entirely deterministic. Right now with most models if you give the same input prompt twice it will give two different solutions.
Earlier quoted context omitted.
You’re sounding like a religious zealot recruiting for a cult. No, it is not possible to prompt every feature, and I suspect people who believe LLMs can accurately program anything in any language are frankly not solving any truly novel or interesting problems, because if they were they’d see the obvious cracks.
> I suspect people who believe LLMs can accurately program anything in any language are frankly not solving any truly novel or interesting problems, because if they were they’d see the obvious cracks. The vast majority of problems in programming aren't novel or interesting.
Earlier quoted context omitted.
That’s not true at all. Apple’s OS by default have smart punctuation enabled and convert -- (two hyphens) into — (“em-dash”; not an “en-dash”, which has a different purpose), " " (dumb quotes) into “ ” (smart quotes), and so forth. Furthermore, on macOS there are simple key combinations (e.g. with ⌥) to make all sort of smart punctuation even if you don’t have the feature enabled by default, and on iOS you can long p…
> assuming a single character immediately means they used an LLM is just plain wrong I don't see anyone doing that here. LLM writing was brought up because of the writing style, not the dash. It just reinforces the suspicion.
Earlier quoted context omitted.
> I feel like using a compiler is in a sense a code generator where you don't commit the actual output Compilers are deterministic. Given the same input you always get the same output so there's no reason to store the output. If you don't get the same output we call it a compiler bug! LLMs do not work this way. (Aside: Am I the only one who feels that the entire AI industry is predicated on replacing only development…
Why does it matter to you if the code generator is deterministic? The code is. If LLM generation was like a Makefile step, part of your build process, this concern would make a lot of sense. But nobody, anywhere, does that.
Top level comment of this thread, quoting the article:
> Reading through these commits sparked an idea: what if we treated prompts as the actual source code? Imagine version control systems where you commit the prompts used to generate features rather than the resulting implementation.
These posts are funny to me because prompt engineers point at them as evidence of the fast-approaching software engineer obsolescence but the years of experience in software engineering necessary to even guide an AI in this way is very high. The reason he keeps adjusting the prompts is because he knows how to program. He knows what it should look like. It just blurs the line between engineer and tool.
The argument is that this stuff will so radically improve senior engineer productivity that the demand for junior engineers will crater. And without a pipeline of junior engineers, the junior-to-senior trajectory will radically atrophy Essentially, the field will get frozen where existing senior engineers will be able to utilize AI to outship traditional senior-junior teams, even as junior engineers fail to secure em…
What makes people think that an increase in senior engineer productivity causes demand for junior engineers to decrease?
I think it will have the opposite effect: an increase in senior engineer productivity enables the company to add more features to its products, making it more valuable to its customers, who can therefore afford to pay more for the software. With this increase in revenue, the company is able to hire more junior engineers.