12 ms·
LLMs as the new high level language
- toprerules 8mo agoAfter working with the latest models I think these "it's just another tool" or "another layer of abstraction" or "I'm just building at a different level" kind of arguments are wishful thinking. You're not going to be a designer writing blueprints for a series of workers to execute on, you're barely going to be a product manager translating business requirements into a technical specification before AI closes that gap as well. I'm very convinced non-technical people will be able to use these tools, because what I'm seeing is that all of the skills that my training and years of experience have helped me hone are now implemented by these tools to the level that I know most businesses would be satisfied by. The irony is that I haven't seen AI have nearly as large of an impact anywhere else. We truly have automated ourselves out of work, people are just catching up with that fact and the people that just wanted to make money from software can now finally stop pretending that "passion" for "the craft" was every really part of their motivating calculus.
- eohsafya 8mo ago[dead]
- shahbaby 8mo ago> what I'm seeing is that all of the skills that my training and years of experience have helped me hone are now implemented by these tools to the level that I know most businesses would be satisfied by. So when things break or they have to make changes, and the AI gets lost down a rabbit hole, who is held accountable?
- toprerules 8mo agoThe answer is the AI. It's already handling complex issues and debugging solely by gathering its own context, doing major refactors successfully, and doing feature design work. The people that will be held responsible will be the product owners, but it won't be for bugs, it will be for business impact. My point is that SWEs are living on a prayer that AI will be perched on a knifes edge where there is still be some amount of technical work to make our profession sustainable and from what I'm seeing that's not going to be the case. It won't happen overnight, but I doubt my kids will ever even think about a computer science degree or doing what I did for work.
- mjr00 8mo agoAnd what happens when the AI can't figure it out?
- toprerules 8mo agoSame situation as when an engineer can't figure something out, they translate the problem into human terms for a product person, and the product person makes a high level decision that allows working around the problem.
- mjr00 8mo agoUh that's not what engineers do; do you not have any software development experience, or rather any outside of vibe coding? That would explain your perspective. (for context I am 15+ yr experience former FAANG dev) I don't meant this to sound inflammatory or anything; it's just that the idea that when a developer encounters a difficult bug they would go ask for help from the product manager of all people is so incredibly outlandish and unrealistic, I can't imagine anyone would think this would happen unless they've never actually worked as a developer.
- toprerules 8mo agoStaff engineer (also at FAANG), so yes, I have at least comparable experience. I'm not trying to summarize every level of SWE in a few sentences. The point is that AI's infallibility is no different than human infallibility. You may fire a human for a mistake, but it won't solve the business problems they may have created, so I believe the accountability argument is bogus. You can hold the next layer up accountable. The new models are startling good at direction setting, technical to product translation, and providing leadership guidance on technical matters and providing multiple routes for roadblocks. We're starting to see engineers running into bugs and roadblocks feed input into AI and not only root causing the problem, but suggesting and implementing the fix and taking it into review.
- 8mo ago
- asa400 8mo agoIf all you (not you specifically, more of a royal “you” or “we”) are is a collection of skills centered around putting code into an editor and opening pull requests as fast as possible, then sure, you might be cooked. But if your job depends on taste, design, intuition, sociability, judgement, coaching, inspiring, explaining, or empathy in the context of using technology to solve human problems, you’ll be fine. The premium for these skills is going _way_ up.
- toprerules 8mo agoThe question isn't whether businesses will have 0 human element to them, the question is does AI offer a big enough gap that technical skills are still required such that technical roles are still hired for. Someone in product can have all of those skills without a computer science degree, with no design experience, and AI will do the technical work at the level of design, implementation, and maintenance. What I am seeing with the new models isn't just writing code, it's taking fundamental problems as input and design wholistic software solutions as output - and the quality is there.
- apical_dendrite 8mo agoI am only seeing that if the person writing the prompts knows what a quality solution looks like at a technical level and is reviewing the output as they go. Otherwise you end up with an absolute mess that may work at least for "happy path" cases but completely breaks down as the product needs change. I've described a case of this in some detail in another comment.
- Kerrick 8mo ago> the person writing the prompts knows what a quality solution looks like at a technical level and is reviewing the output as they go That is exactly what I recommend, and it works like a charm. The person also has to have realistic expectations for the LLM, and be willing to work with a simulacrum that never learns (as frustrating as it seems at first glance).
- deleted 8mo ago
- smohare 8mo ago[dead]
- hackyhacky 8mo ago> The irony is that I haven't seen AI have nearly as large of an impact anywhere else. We are in this pickle because programmers are good at making tools that help programmers. Programming is the tip of the spear, as far as AI's impact goes, but there's more to come. Why pay an expensive architect to design your new office building, when AI will do it for peanuts? Why pay an expensive lawyer to review your contract? Why pay a doctor, etc. Short term, doing for lawyers, architects, civil engineers, doctors, etc what Claude Code has done for programmers is a winning business strategy. Long term, gaining expertise in any field of intellectual labor is setting yourself up to be replaced.
- mike_hearn 8mo ago> Why pay an expensive architect to design your new office building, when AI will do it for peanuts? Will it? AI is getting good at some parts of programming because of RLVR. You can test architectural designs automatically to some extent but not entirely, because people tend to want unique buildings that stand out (if it weren't the case architects would have already become a niche profession due to everyone using prefabs all the time). At some point an architectural design has to be built and you can't currently simulate real building sites at high speed inside a datacenter. This use case feels marginal. There's going to be a lot of cases like this. The safe jobs are ones where there's little training data available online, the job has a large component of unarticulated experience or intuition, and where you can't verify purely in software whether the work artifact is correct or not.
- hackyhacky 8mo ago> people tend to want unique buildings that stand out Just tell the LLM that you want a unique design. I've found LLMs to respond well to requests for "originality," at least in poetry, prose, and coding. No reason that can't do that in architecture as well. > At some point an architectural design has to be built and you can't currently simulate real building sites at high speed inside a datacenter. First of all, you can simulate a building site, or any physical environment. We've been doing that for years, even in games. AI companies are working towards a "world model" for precisely that reason. Second of all, even without a physical simulation, the laws of physics are deterministic and easy for an LLM to understand. > The safe jobs are ones where there's little training data available online, These cases are "safe" only in relative terms. Lack of easily-available training data is friction but not insurmountable. AI companies have bet big and they have a strong incentive to find and use appropriate training data.
- raincole 8mo ago> translating business requirements into a technical specification a.k.a. Being a programmer. > The irony is that I haven't seen AI have nearly as large of an impact anywhere else. What lol. Translation? Graphic design?
- coffeebeqn 8mo agoWriting? Education?
- _zagj 8mo ago> After working with the latest models I think these "it's just another tool" or "another layer of abstraction" or "I'm just building at a different level" kind of arguments are wishful thinking. You're not going to be a designer writing blueprints for a series of workers to execute on, you're barely going to be a product manager translating business requirements into a technical specification before AI closes that gap as well I think it's doubtful you'll be even that; certainly not with the salary and status that normally entails. > I'm very convinced non-technical people will be able to use these tools This suggests that the skill ceiling of "Vibe Coding" is actually quite low, calling into question the sense of urgency with which certain AI influnecers present it, as if it were a skill that you need to invest major time & effort to hone now (with their help, of course), lest you get left behind and have to "catch up" later. Yet one could easily see it being akin to Googling, which was also a skill (when Google was usable), one that did indeed increase your efficiency and employable, but with a low ceiling, such that "Googler" was never a job by itself, the way some suggest "prompt engineer" will be. The Google analogy is apt, in that you're typing keywords into a blackbox until it spits out what you want; quite akin to how people describe "prompt engineering." Also the Vibe Coding skillset--a bag of tricks and book of incantations you're told can cajole the model--has a high churn rate. Once, narrow context windows meant restarting a session de novo was advisable if you hit a roadblock, but now it's usually the opposite. If this all true, then wouldn't the correct takeaway, rather than embracing and mastering "Vibe Coding" (as influencers suggest), be to "pivot" to a new career, like welding? > The irony is that I haven't seen AI have nearly as large of an impact anywhere else. We truly have automated ourselves out of work, people are just catching up with that fact What's funny is artists immediately, correctly perceived the threat of AI. You didn't see cope about it being "just another tool, like Photoshop."
- redox99 8mo agoGen AI for art was different because it would just output a final image with basically 0 control for the artist. It's like if AI programming would output a binary instead of source code.
- echelon 8mo agoThese models are nothing short of astounding. I can write a spec for an entirely new endpoint, and Claude figures out all of the middleware plumbing and the database queries. (The catch: this is in Rust and the SQL is raw, without an ORM. It just gets it. I'm reviewing the code, too, and it's mostly excellent.) I can ask Claude to add new data to the return payloads - it does it, and it can figure out the cache invalidation. These models are blowing my mind. It's like I have an army of juniors I can actually trust.
- tryauuum 8mo ago> this is in Rust and the SQL is raw, without an ORM. where's the catch? SQL is an old technology, surely an LLM is good with it
- Calavar 8mo agoI'm not sure I'd call agents an army of juniors. More like a high school summer intern who has infinite time to do deep dives into StackOverflow but doesn't have nearly enough programming experience yet to have developed a "taste" for good code In my experience, agentic LLMs tend to write code that is very branchy with cyclomatic complexity. They don't follow DRY principles unless you push them very hard in that direction (and even then not always), and sometimes they do things that just fly in the face of common sense. Example of that last part: I was writing some Ruby tests with Opus 4.6 yesterday, and I got dozens of tests that amounted to this: x = X.new assert x.kind_of?(X) This is of course an entirely meaningless check. But if you aren't reading the tests and you just run the test job and see hundreds of green check marks and dozens of classes covered, it could give you a false sense of security
- hackyhacky 8mo ago> In my experience, agentic LLMs tend to write code that is very branchy with cyclomatic complexity You are missing the forest for the trees. Sure, we can find flaws in the current generation of LLMs. But they'll be fixed. We have a tool that can learn to do anything as well as a human, given sufficient input.
- TZubiri 8mo ago"Following this hypothesis, what C did to assembler, what Java did to C, what Javascript/Python/Perl did to Java, now LLM agents are doing to all programming languages." This is not an appropriate analogy, at least not right now. Code Agents are generating code from prompts, in that sense the metaphor is correct. However Agents then read the code and it becomes input and they generate more code. This was never the case for compilers, an LLM used in this sense is strictly not a compiler because it is not cyclic and not directional.
- danparsonson 8mo agoI think it's appropriate in terms of the results rather than the process; the bigger problem I see is that programming languages are designed to be completely unambiguous, whereas human language is not ("Go to the shop and buy one box of eggs, and if they have carrots, buy three") so we're transitioning from exactly specifying what we want the software to do, to tying ourselves in knots trying to specify it exactly, while a machine tries to disambiguate our request. I bet lawyers would make good vibe coders.
- tomaytotomato 8mo agoI would like to hijack the "high level language" term to mean dopamine hits from using an LLM. "Generate a Frontend End for me now please so I don't need to think" LLM starts outputting tokens Dopamine hit to the brain as I get my reward without having to run npm and figure out what packages to use Then out of a shadowy alleyway a man in a trenchcoat approaches "Pssssttt, all the suckers are using that tool, come try some Opus 4.6" "How much?" "Oh that'll be $200.... and your muscle memory for running maven commands" "Shut up and take my money" ----- 5 months later, washed up and disconnected from cloud LLMs ------ "Anyone got any spare tokens I could use?"
- cyberax 8mo ago> and your muscle memory for running maven commands Here's $1000. Please do that. Don't bother with the LLM.
- tomaytotomato 8mo agoI'm guessing you like Gradle? :)
- jatora 8mo agoIf you're disconnected from cloud LLM's you've got bigger problems than coding can solve lol
- allovertheworld 8mo agoaka a mind virus
- imiric 8mo agoI can't tell if your general premise is serious or not, but in case it is: I get zero dopamine hits from using these tools. My dopamine rush comes from solving a problem, learning something new, producing a particularly elegant and performant piece of code, etc. There's an aspect of hubris involved, to be sure. Using a tool to produce the end result gives me no such satisfaction. It's akin to outsourcing my work to someone who can do it faster than me. If anything, I get cortisol hits when the tool doesn't follow my directions and produces garbage output, which I have to troubleshoot and fix myself.
- stared 8mo agoNo, prompts are not the new source code, vide https://quesma.com/blog/vibe-code-git-blame/ https://quesma.com/blog/vibe-code-git-blame/.
- deleted 8mo ago[deleted]
- dsr_ 8mo agoIt's not a programming language if you can't read someone else's code, figure out what it does, figure out what they meant, and debug the difference between those things. "I prompted it like this" "I gave it the same prompt, and it came out different" It's not programming. It might be having a pseudo-conversation with a complex system, but it's not programming.
- echelon 8mo ago[flagged]
- happytoexplain 8mo agoI'm not sure I will ever understand the presentation of "inevitable === un-criticizable" as some kind of patent truth. It's so obviously fallacious that I'm not sure what could even drive a human to write it, and yet there it is, over and over and over. Lots of horrifying things are inevitable because they represent "progress" (where "progress" means "good for the market", even if it's bad for the idea of civilization), and we, as a society, come to adapt to them, not because they are good, but because they are.
- furyofantares 8mo agoI think I 100% agree with you, and yet the other day I found myself telling someone "Did you know OpenClaw was written Codex and not Claude Code?", and I really think I meant it in the same sense I'd mean a programming language or framework, and I only noticed what I'd said a few minutes later.
- Closi 8mo ago> It's not a programming language if you can't read someone else's code, figure out what it does, figure out what they meant, and debug the difference between those things. Well I think the article would say that you can diff the documentation, and it's the documentation that is feeding the AI in this new paradigm (which isn't direct prompting). If the definition of programming is "a process to create sets of instructions that tell a computer how to perform specific tasks" there is nothing in there that requires it to be deterministic at the definition level.
- rvz 8mo agoSo we are going to certainly see more of these incidents then [0] from those not understanding LLM written code as now 'engineers' will let their skills decay because the 'LLMs know best'. [0] https://sketch.dev/blog/our-first-outage-from-llm-written-code https://sketch.dev/blog/our-first-outage-from-llm-written-co...
- apical_dendrite 8mo agoI'm trying to work with vibe-coded applications and it's a nightmare. I am trying to make one application multi-tenant by moving a bunch of code that's custom to a single customer into config. There are 200+ line methods, dead code everywhere, tons of unnecessary complexity (for instance, extra mapping layers that were introduced to resolve discrepancies between keys, instead of just using the same key everywhere). No unit tests, of course, so it's very difficult to tell if anything broke. When the system requirements change, the LLM isn't removing old code, it's just adding new branches and keeping the dead code around. I ask the developer the simplest questions, like "which of the multiple entry-points do you use to test this code locally", or "you have a 'mode' parameter here that determines which branch of the code executes, which of these modes are actually used? and I get a bunch of babble, because he has no idea how any of it works. Of course, since everyone is expected to use Cursor for everything and move at warp speed, I have no time to actually untangle this crap. The LLM is amazing at some things - I can get it to one-shot adding a page to a react app for instance. But if you don't know what good code looks like, you're not going to get a maintainable result.
- danparsonson 8mo agoYou've just described the entirely-human-made project that I'm working on now.... at least now we can deliver the intractable mess much more quickly!
- nly 8mo agoI have a source file of a few hundred lines implementing an algorithm that no LLM I've tried (and I've tried them all) is able to replicate, or even suggest, when prompted with the problem. Even with many follow up prompts and hints. The implementations that come out are buggy or just plain broken The problem is a relatively simple one, and the algorithm uses a few clever tricks. The implementation is subtle...but nonetheless it exists in both open and closed source projects. LLMs can replace a lot of CRUD apps and skeleton code, tooling, scripting, infra setup etc, but when it comes to the hard stuff they still suck. Give me a whiteboard and a fellow engineer anyday
- jatora 8mo agoi bet i could replicate it if you showed me the source file
- prxm 8mo agoThis is one of my favourite activites with LLMs as well. After implementing some sort of idea for an algorithm, I try seeing what an LLM would come up with. I hint it as well and push it in the correct direction with many iterations but never tell the most ideal one. And as a matter of fact they can never reach the quality I did with my initial implementation.
- kranner 8mo agoI'm seeing the same thing with my own little app that implements several new heuristics for functionality and optimisation over a classic algorithm in this domain. I came up with the improvements by implementing the older algorithm and just... being a human and spending time with the problem. The improvements become evident from the nature of the problem in the physical world. I can see why a purely text-based intelligence could not have derived them from the specs, and I haven't been able to coax them out of LLMs with any amount of prodding and persuasion. They reason about the problem in some abstract space detached from reality; they're brilliant savants in that sense, but you can't teach a blind person what the colour red feels like to see.
- chasd00 8mo agoWell I think that’s kind of the point or value in these tools. Let the AI do the tedious stuff saving your energy for the hard stuff. At least that’s how I use them, just save me from all the typing and tedium. I’d rather describe something like auth0 integration to an LLM than do it all myself. Same goes for like the typical list of records, clock one, view the details and then a list of related records and all the operations that go with that. Like it’s so boring let the LLM do that stuff for you.
- kazinator 8mo agoThis is a good summary of any random week's worth of AI shilling from your LinkedIn feed, that you can't get rid of.
- OutOfHere 8mo agoThe side effect of using LLMs for programming is that no new programming language can now emerge to be popular, that we will be stuck with the existing programming languages forever for broad use. Newer languages will never accumulate enough training data for the LLM to master them. Granted, non-LLM AIs with true neural memory can work around this, as can LLMs with an infinite token frozen+forkable context, but these are not your everyday LLMs.
- spacephysics 8mo agoI wouldn’t be surprised if in the next 5-10 years the new and popular programming language is one built with the idea of optimizing how well LLM’s (or at that point world models) understand and can use it. Right now LLMs are taking languages meant for humans to understand better via abstraction, what if the next language is designed for optimal LLM/world model understanding? Or instead of an entirely new language, theres some form of compiling/transpiling from the model language to a human centric one like WASM for LLMs
- raincole 8mo agoI don't think we need that many programming languages anyway. I'm more worried about the opposite: the next popular programming paradigm will be something that's hard to read for humans but not-so-hard for LLM. For example, English -> assembly.
- slopusila 8mo agoyou can invent a new language, ask LLM to translate existing code bases into it, then train on that Just like AlphaZero ditched human Go matches and trained on synthetic ones, and got better this way
- AlexeyBrin 8mo agoThis is an exaggeration, if you store the prompt that was "compiled" by today's LLMs there is no guarantee that in 4 months from now you will be able to replicate the same result. I can take some C or Fortran code from 10 years ago, build it and get identical results.
- gnatolf 8mo agoThat is a wobbly assertion. You certainly would need to run the same compiler, forgo any recent optimisations, architecture updates and the likes if your code has numerical sensitive parts. You certainly can get identical results, but it's equally certainly not going to be that simple a path frequently.
- AlexeyBrin 8mo ago> You certainly can get identical results, but it's equally certainly not going to be that simple a path frequently. But at least I know that if I need to, I can do it. With an LLM, if you don't store the original weights, all bets are off. Reproducibility of results can be a hard requirement in certain cases or industries.
- layer8 8mo agoThe more important point is that even when you don’t get identical binary output, you still get identical observable behavior as specified by the programming language, unless there’s a compiler bug. That’s not the case for LLMs, they are more like an always randomly buggy compiler. You wouldn’t want to use such a compiler.
- ekropotin 8mo agoIDK how everyone else feel about it, but a non-deterministic “compiler” is the last thing I need.
- ChrisGreenHeur 8mo agoI may have bad news for you on how compilers typically work.
- r0b05 8mo agoElaborate please
- hndc 8mo agoDeterministic compilation, aka reproducible builds, has been a basic software engineering concept and goal for 40+ years. Perhaps you could provide some examples of compilers that produce non-deterministic output along with your bad news.
- mike_hearn 8mo agoJIT compilers.
- hndc 8mo agoCompiler artifact is still deterministic. Clearly not referring to runtime behavior that is input-dependent
- mike_hearn 8mo agoThe output of the compiler isn't deterministic. It depends a lot on timing and how that affects the profiles.
- booleandilemma 8mo agoAccount created 11 months ago. They're probably just some slop artist with too much confidence. They probably don't even know what a compiler is.
- WoodenChair 8mo agoThe article starts with a philosophically bad analogy in my opinion. C-> Java != Java -> LLM because the intermediate product (the code) changed its form with previous transitions. LLMs still produce the same intermediate product. I expanded on this in a post a couple months back: https://www.observationalhazard.com/2025/12/c-java-java-llm.html https://www.observationalhazard.com/2025/12/c-java-java-llm.... "The intermediate product is the source code itself. The intermediate goal of a software development project is to produce robust maintainable source code. The end product is to produce a binary. New programming languages changed the intermediate product. When a team changed from using assembly, to C, to Java, it drastically changed its intermediate product. That came with new tools built around different language ecosystems and different programming paradigms and philosophies. Which in turn came with new ways of refactoring, thinking about software architecture, and working together. LLMs don’t do that in the same way. The intermediate product of LLMs is still the Java or C or Rust or Python that came before them. English is not the intermediate product, as much as some may say it is. You don’t go prompt->binary. You still go prompt->source code->changes to source code from hand editing or further prompts->binary. It’s a distinction that matters. Until LLMs are fully autonomous with virtually no human guidance or oversight, source code in existing languages will continue to be the intermediate product. And that means many of the ways that we work together will continue to be the same (how we architect source code, store and review it, collaborate on it, refactor it, etc.) in a way that it wasn’t with prior transitions. These processes are just supercharged and easier because the LLM is supporting us or doing much of the work for us."
- valenterry 8mo agoWhat would you say if someone has a project written in, let's say, PureScript and then they use a Java backend to generate/overwrite and also version control Java code. If they claim that this would be a Java project, you would probably disagree right? Seems to me that LLMs are the same thing, that is, if you also store the prompt and everything else to reproduce the same code generation process. Since LLMs can be made deterministic, I don't see why that wouldn't be possible.
- WoodenChair 8mo ago
- renewiltord 8mo agoWe’re missing the boat here. There are already companies with millions in revenue that are pure agent loops of English text. They can do things our traditional software cannot.
- kristjansson 8mo agoAn example or two would go a long way here.
- renewiltord 8mo agoA natural question to ask in response, but I did not find out in each case in a way where I should say anything about their engineering so since I've said something about that I can't say who. I get how it comes off. If the Criterion of Embarrassment helps, I find myself sorely unqualified for this new world. To be honest, I shouldn't have said anything in the first place. It isn't useful as it is because you can't reasonably believe me. I just feel blindsided by the stuff that's working now.
- paulhebert 8mo agoCan you share some examples?
- QuadrupleA 8mo agoCan we stop repeating this canard, over and over? Every "classic computing" language mentioned, and pretty much in history, is highly deterministic, and mind-bogglingly, huge-number-of-9s reliable (when was the last time your CPU did the wrong thing on one of the billions of machine instructions it executes every second, or your compiler gave two different outputs from the same code?) LLMs are not even "one 9" reliable at the moment. Indeed, each token is a freaking RNG draw off a probability distribution. "Compiling" is a crap shoot, a slot machine pull. By design. And the errors compound/multiply over repeated pulls as others have shown. I'll take the gloriously reliable classical compute world to compile my stuff any day.
- kykat 8mo agoAgreed, yet we will have to keep seeing this take over and over again. As if I needed more reasons to believe the world is filled with morons.
- lofaszvanitt 8mo agoWhy using agents if there are absolutely zero need for them? It's the usual, here, we spent a shitton of money on this, now find out how we MUST include this horrible thing into our already bloated dev environment.
- anon946 8mo agoIsn't this a little bit of a category error? LLMs are not a language. But prompts to LLMs are written in a language, more or less a natural language such as English. Unfortunately, natural languages are not very precise and full of ambiguity. I suspect that different models would interpret wordings and phrases slightly differently, leading to behaviors in the resulting code that are difficult to predict.
- empressplay 8mo agoRight, but that's the point -- prompting an LLM still requires 'thinking about thinking' in the Papert sense. While you can talk to it in 'natural language' that natural language still needs to be _precise_ in order to get the exact result that you want. When it fails, you need to refine your language until it doesn't. So prompts = high-level programming.
- zekica 8mo agoYou can't think all the way about refining your prompt for LLMs as they are probabilistic. Your re-prompts are just retrying until you hit a jackpot - refining only works to increase the chance to get what you want. When making them deterministic (setting the temperature to 0), LLMs (even new ones) get stuck in loops for longer streams of output tokens. The only way to make sure you get the same output twice is to use the same temperature and the same seed for the RNG used, and most frontier models don't have a way for you to set the RNG seed.
- cubefox 8mo ago... yet.
- red75prime 8mo agoRandomness is not a problem by itself. Algorithms in BQP are probabilistic too. Different prompts might have different probabilities of successful generation, so refinement could be possible even for stochastic generation. And provably correct one-shot program synthesis based on an unrestricted natural language prompt is obviously an oxymoron. So, it's not like we are clearly missing the target here.
- DavidPiper 8mo agoOne of the reasons we have programming languages is they allow us to express fluently the specificity required to instruct a machine. For very large projects, are we sure that English (or other natural languages) are actually a better/faster/cheaper way to express what we want to build? Even if we could guarantee fully-deterministic "compilation", would the specificity required not balloon the (e.g.) English out to well beyond what (e.g.) Java might need? Writing code will become writing books? Still thinking through this, but I can't help but feel natural languages are still poorly suited and slower, especially for novel creations that don't have a well-understood (or "linguistically-abstracted") prior.
- kristjansson 8mo agoPerhaps we'll go the way of the Space Shuttle? One group writes a highly-structured, highly-granular, branch-by-branch 2500 page spec, and another group (LLM) writes 25000 lines of code, then the first group congratulates itself on on producing good software without have to write code?
- abcde666777 8mo agoAre these kinds of articles a new breed of rage bait? They keep ending up on the front page with thriving comment sections, but in terms of content they're pretty low in nutritional value. So I'm guessing they just rise because they spark a debate?
- eastbound 8mo agoThere’s barely any debate, people don’t answer each other; It’s rather about invoking the wonder and imagination of everyone’s brain. Like spatial conquest or an economic crisis: It will change everything but you can’t do anything immediately about it, and everyone tries to understand what it will change so they can adapt. It’s more akin to 24hrs junk news cycle, where everything is presented as an alert but your tempted to listen because it might affect you.
- anoplus 8mo agoI am interested in a post that will teach me how to consume only the news that really relevant for me
- sph 8mo agoHere’s one: just don’t read the news. Google what you are interested in at the moment, and dive long into what matters to you, rather than being fed engagement bait. Easier said than done, I understand that.
- kristjansson 8mo agoCode written in a HLL is a sufficient[1] description of the resulting program/behavior. The code, in combination with the runtime, define constraints on the behavior of the resulting program. A finished piece of HLL code encodes all the constraints the programmer desired. Presuming a 'correct' compiler/runtime, any variation in the resulting program (equivalently the behavior of an interpreter running the HLL code) varies within the boundaries of those constraints. Code in general is also local, in the sense that small perturbation to the code has effects limited to a small and corresponding portion of the program/behavior. A change to the body of a function changes the generated machine code for that function, and nothing else[2]. Prompts provided to an LLM are neither sufficient nor local in the same way. The inherent opacity of the LLM means we can make only probabilistic guarantees that the constraints the prompt intends to encode are reflected by the output. No theory (that we now know) can even attempt to supply such a guarantee. A given (sequence of) prompts might result in a program that happens to encode the constraints the programmer intended, but that _must_ be verified by inspection and testing. One might argue that of course an LLM can be made to produce precisely the same output for the same input; it is itself a program after all. However, that 'reproducibility' should not convince us that the prompts + weights totally define the code any more than random.Random(1).random() being constant should cause us to declare python's .random() broken. In both cases we're looking at a single sample from a pRNG. Any variation whatsoever would result in a different generated program, with no guarantee that program would satisfy the constraints the programmer intended to encode in the prompts. While locality falls similarly, one might point out the an agentic LLM can easily make a local change to code if asked. I would argue that an agentic LLMs prompts are not just the inputs from the user, but the entire codebase in its repo (if sparsely attended to by RAG or retrieval tool calls or w/e). The prompts _alone_ cannot be changed locally in a way that guarantees a local effect. The prompt LLM -> program abstraction presents leaks of such volume and variety that it cannon be ignored like the code -> compiler -> program abstraction can. Continuing to make forward progress on a project requires the robot (and likely the human) attend to the generated code. Does any of this matter? Compilers and interpreters themselves are imperfect, their formal verification is incomplete and underutilized. We have to verify properties of programs via testing anyway. And who cares if the prompts alone are insufficient? We can keep a few 100kb of code around and retrieve over it to keep the robot on track, and the human more-or-less in the loop. And if it ends up rewriting the whole thing every few iterations as it drifts, who cares? For some projects where quality, correctness, interoperability, novelty, etc don't matter, it might be. Even in those, defining a program purely via prompts seems likely to devolve eventually into aggravation. For the rest, the end of software engineering seems to be greatly exaggerated. [1]: loosely in the statistical sense of containing all the information the programmer was able to encode https://en.wikipedia.org/wiki/Sufficient_statistic https://en.wikipedia.org/wiki/Sufficient_statistic [2]: there're of course many tiny exceptions to this. we might be changing a function that's inlined all over the place; we might be changing something that's explicitly global state; we might vary timing of something that causes async tasks to schedule in a different order etc etc. I believe the point stands regardless.
- 1zael 8mo agoThere's nothing novel in this article. This is what every other AI clickbait article is propagating.
- mock-possum 8mo agoHasnt natural language always been the highest level language?
- gloosx 8mo agoNatural language is not the highest level – it is just the highest level that still needs words.
- PunchyHamster 8mo agoAt this point I'm just waiting for people claiming they managed team of 20 people, where "20 people" were LLMs being fed a prompt
- pavlov 8mo agoThis claim has been going around for a while. I know someone who has been spending $7k / month on Cursor tokens for the past six months, managing such a team of agents… But curiously the results seem to be endless PDF-ware, and every month there’s a new reason why the project is not yet quite ready to be used on real data. LLMs are very good at making you think they’re giving you what you hoped to get.
- noduerme 8mo agoThey're also very good at demoralizing people who actually code for a living. Or at least the hype surrounding them is. Up until a couple years ago I'd simply dive into a new coding assignment and be excited to solve all the problems. Some new widget? Maybe I could find a way to make the UX flow better, or add a couple neat little transitions, or heck even improve the mechanics or the business logic. I now find myself looking at assignments and thinking: Is this a waste of my time? I know how I'd do it, but I'm prone to a lot of yak-shaving and perfectionism. Should I just ask Claude to do it? So alright, let's see what Claude does. And then I get presented with a piece of code and a product that I wouldn't have chosen - but in some cases would be perfectly sufficient for minor work I shouldn't be yak-shaving. On the other hand, going beyond the simplest or most obvious is how I built my business. Bringing ideas to the table and executing them. So then I discard the Claude code and sit down to write it from scratch. It is at that exact point that I start to wonder: does anyone even care? People who take the time to think deeply through their work, and who "hammer in the extra nail" as my grandpa used to say (he was a general contractor) do so most often for their own sense of pride in a job well done, and for the trust that comes from their clients or employers knowing that they will go the extra mile and do a job well. But what happens when employers or clients don't treat the work as important - and when they would be okay with a bad or mediocre version on the cheap? That's not a new problem - usually I just won't work for those people. But I just hate the pessimistic feeling I get about doing what I always loved to do - writing bespoke code - when I constantly keep asking myself do these vibe coders know something more than I do? Should I try yet again on that route? Worse, am I just wasting my time perfecting something that no one else will appreciate? To anyone outside engineering, writing code looks like wizardry. I think the most common and most demoralizing outcome of LLM vibe coding has been to incorrectly make them think it's suddenly easier. And a new crop of vibe coders who think they don't have to think for themselves? They're not engineers. They may even be enemies of good engineering. They have more in common with the bosses and clients we've always had who said "hey, this should be a very easy request, can you just add a button to the customer app that will (fill in the blank with some wildly complicated business transaction that definitely can't be handled in one click). All of it is sapping my motivation to do what I was good at, which is, solving problems and writing well tested code. Sorry for the rant.
- geon 8mo ago> The code that LLMs make is much worse than what I can write: almost certainly; but the same could be said about your assembler Has this been true since the 90s? I pretty much only hear people saying modern compilers are unbeatable.
- dainiusse 8mo agoDoes the product work? Is it maintainable? Everything else is secondary.
- zkmon 8mo agoWhy isn't there a downvote button for the thread?
- fullstackchris 8mo ago> Using LLM agents is expensive: if they give you already 50% more productivity, and your salary is an average salary, they are not. And LLMs will only get cheaper. They are only expensive in absolute, not in relative terms. critical distinction: unless your getting paid comparable to your ouput (literally 0 traditional 9-5 software jobs I know unfortunately) this is infact the opposite - a subscription to any of these services reduces your overall salary, it doesnt make it higher... then there is the case i know the dishonest are doing is firing of claude or whatever and going for a walk
- svilen_dobrev 8mo agoso, prompt engineering it is. Happy new LLMium.
- redbell 8mo agoAs per Andrej Karpathy's viral tweet from three years ago [1]: The hottest new programming language is English ______________ 1. https://x.com/i/status/1617979122625712128 https://x.com/i/status/1617979122625712128
- DaedalusII 8mo agoThe biggest and least controversial thing will be when anthropic create a onedrive/googledrive integration that lets white collar employees create, edit, and export word documents into pdfs, referring to other files in the folder. This alone will increase average white paper employee productivity by 100x and lead to the most job displacement. For instance: Here is an email from my manager at 1pm today. Open the policy document he is referring to, create a new version, and add the changes he wants. refer to the entire codebase (our company onedrive/google drive/dropbox whatever) to make sure it is contextually correct. >Sure, here is the document for your review Great, reply back to manager with attachment linked to OneDrive
- sublinear 8mo agoYour example actually perfectly describes why it won't displace anyone. The user still has to be in the loop to instruct the LLM every time, and the tiniest nuances in each execution of that work still matters. If it didn't we'd have replaced people with bash scripts many decades ago. When we've tried to do that, the maintenance of those scripts became a game of whack-a-mole that never ended and they're eventually abandoned. I think sometimes people forget how ineffective most software is even when written as good as it can be. LLMs don't unlock any new abilities there. What this actually does is make people more available for meeting time. Productivity doesn't budge at all. :) In other words, the "busy work" has always been faster to do than the decision making, and if someone has meetings to attend they don't strictly do busy work. Maybe the more interesting outcome is that with the increased meeting time comes much deeper drinks of the kool-aid, and businesses become more cultish than they already are. That to me sounds far more sinister than kicking people out onto the curb. Employees become "agents of change" through the money and influence they're given. They might actually hire more :D
- Davidzheng 8mo agoEven if your argument is correct here, it would only mean this particular method of replacement doesn't immediately work for this job.
- 8mo ago
- titaniumrain 8mo agolol, this author doesn't even understand what llm is
- ares623 8mo agoI'll believe it when companies and projects start committing prompts into Github and nothing else. Let CI/CI regenerate the entire thing on each build. We don't commit compiled blobs in source control. Why can't the same be done for LLMs?
- kaapipo 8mo agoIf we can treat the prompts as the versionable source code artefact, then sure. But as long as we need to fine-tune the output that's not a high level language. In the same way no one would edit the assembly that a compiler produces
- imdsm 8mo agoIf we're able to produce an LLM which takes a seed and produces the same output per input, then we'd be able to do this
- layer8 8mo agoThere must be good reasons why we don’t have this. I suspect one reason is that the SOTA providers are constantly changing the harness around the core model, so you’d need to version that harness as well.
- pvtmert 8mo agoExcept that the output depends on stars' alignment. Imagine a machine that does the job sometimes but fails on some other times. Wonderful isn't it?
- pjmlp 8mo agoAlready there for anyone using iPaaS platforms, and despite their flaws, it is the new normal in many enterprise consulting scenarios.
- niobe 8mo agoUtterly brainless article. Why am I even commenting.
- matheus-rr 8mo agoThe intermediate product argument is the strongest point in this thread. When we went from assembly to C, the debugging experience changed fundamentally. When we went from C to Java, how we thought about memory changed. With LLMs, I'm still debugging the same TypeScript and Python I was before. The generation step changed. The maintenance step didn't. And most codebases spend 90% of their life in maintenance mode. The real test of whether prompts become a "language" is whether they become versioned, reviewed artifacts that teams commit to repos. Right now they're closer to Slack messages than source files. Until prompt-to-binary is reliable enough that nobody reads the intermediate code, the analogy doesn't hold.
- BudapestMemora 8mo ago"Until prompt-to-binary is reliable enough that nobody reads the intermediate code, the analogy doesn't hold." 1. OK, let's create 100 instances of prompt under the hood, 1-2 will hallucinate, 3-5 will produce something different from 90% of remaining, and it can compile based on 90% of answers 2. computer memory is also not 100% reliable , but we live with it somehow without man-in-the-middle manually check layer?
- Lwerewolf 8mo agoI wonder what ECC is for. So, unless you're Google and you're having to deal with "mercurial cores"... Also, sorry, but what did I just actually attempt to read?
- zvitiate 8mo agoOkay but if you aren’t using RAIM or a TMR system then is he really wrong? And if you weren’t being snarky I’m sure you could understand. Generate 100 answers. Compare them. You’ll find ~90% the same. Choose that one.
- whoisthemachine 8mo agoComputer memory, even cheap consumer grade stuff, has much higher reliability than 90%. Otherwise your computer would be completely unusable!
- badgersnake 8mo agoMore garbage content on the front page. It’s a constant AI hype pieces with zero substance from people who just happen to work for AI companies. Hacker news is really going downhill.
- phplovesong 8mo agoPlease stop with these rage click posts. There is so much wrong in this article i wont even start...
- BudapestMemora 8mo agoAnd sooner or later it will happen, imho. With probabalistic compiling. And several "prompts/agents" under the hood. The majority of "replies" wins to compile. Of course good context will contribute to better refined probability. Ask yourself "Computer memory and disk are also not 100% reliable , but we live with it somehow without man-in-the-middle manual check layer, yes?" Answer about LLM will be the same, if good enough level of similarity/same asnwers is achieved.
- karmasimida 8mo agoLLMs are new runtimes.
- coffeebeqn 8mo agoAlright I’m out
- MORPHOICES 8mo ago[dead]
- heikkilevanto 8mo agoIf we consider the prompts and LLM inputs to be the new source code, I want to see some assurance we get the same results every time. A traditional compiler will produce a program that behaves the same way, given the same source and options. Some even go out of their way to guarantee they produce the same binary output, which is a good thing for security and package management. That is why we don't need to store the compiled binaries in the version control system. Until LLMS start to get there, we still need to save the source code they produce, and review and verify that it does what it says on the label, and not in a totally stupid way. I think we have a long way to go!
- pjmlp 8mo agoAnyone doing benchmarks with managed runtimes, or serverless, knows it isn't quite true. Which is exactly one of the AOT only, no GC, crowds use as example why theirs is better.
- manuelabeledo 8mo agoEven those are way more predictable than LLMs, given the same input. But more importantly, LLMs aren’t stateless across executions, which is a huge no-no.
- zozbot234 8mo ago> But more importantly, LLMs aren’t stateless across executions, which is a huge no-no. They are, actually. A "fresh chat" with an LLM is non-deterministic but also stateless. Of course agentic workflows add memory, possibly RAG etc. but that memory is stored somewhere in plain English; you can just go and look at it. It may not be stateless but the state is fully known.
- manuelabeledo 8mo agoUsing the managed runtime analogy, what you are saying is that, if I wanted to benchmark LLMs like I would do with runtimes, I would need to take the delta between versions, plus that between whatever memory they may have. I don’t see how that helps with reproducibility. Perhaps more importantly, how would I quantify such “memory”? In other words, how could I verify that two memory inputs are the same, and how could I formalize the entirety of such inputs with the same outputs?
- koiueo 8mo agoThen commit your prompt to a git repository. Gosh, LLMs been a thing only for a few years, but people became stupid already. > what Javascript/Python/Perl did to Java FFS... What did python do to java?
- cess11 8mo agoWas StackOverflow "the new high level language"? The proliferation of public git repos? Because that's pretty much what "agentic" LLM coding systems are an automation of, skimming through forums or repos and cribbing the stuff that looks OK.
- omarreeyaz 8mo agoI’m not sure I buy this. GPT-5.2 codex still makes design errors that I as an engineer have to watch and correct. The only way I know how to catch it and then steer the model towards a correction is to be able to read the code and write some code into the prompt. So one can’t abstract programming language away through an agent…
- freetonik 8mo agoThere's a reason we distinguish between programmers and managers; if "LLMs are just the new high level language", then a manager is just another programmer operating on a level above code. I mean, sure, we can say that, but words become kind of meaningless at this point.
- asim 8mo agoI wouldn't call it the new high level language. It's a new JIT. But that's not doing it justice. There's a translation of natural language to a tokenizer and processor that's akin to the earliest days of CPUs. It's a huge step change from punch cards. But there's also a lot to learn. I think we will eventually develop a new language that's more efficient for processing or multiple layers of transformers. Tbh Google is leapfrogging everyone in this arena and eventually we're going to more exotic forms of modelling we've never seen before except in nature. But from an engineering perspective all I can see right now is a JIT.
- dankobgd 8mo agono
- retinaros 8mo agoAs long as SOTA is dumblooping until LLM verify some end goal and spend as many token as possible it wont be a language. At best an inelegant dialect.
- frigg 8mo ago>Following this hypothesis, what C did to assembler, what Java did to C, what Javascript/Python/Perl did to Java, now LLM agents are doing to all programming languages. What did Javascript/Python do to Java? They are not interchangeable nor comparable. I don't think Federico's opinion is worth reading further.
- niels8472 8mo agoPlus Python and Perl predate Java.
- randallsquared 8mo agoThree of Java's top application categories are webapps, banking/financial services, and big data. Node and Pyspark have displaced quite a lot of that.
- frigg 8mo agoMost serious banking apps and financial services are still written in Java, it hasn't displaced much of anything. Big data is a relatively 'new' fad that is already becoming less and less relevant.
- Verdex 8mo agoIf the LLM is a high level language, then why aren't we saving the prompts in git? Last I checked with every other high level language, you save the source and then rerun the compiler to generate the artifact. With LLMs you throw away the 'source' and save the artifact.
- andai 8mo agoThe "prompt" is a guy who wrestled with Claude Code for several hours straight.
- bwat49 8mo agoI feel so attacked right now
- dgb23 8mo agoSome people do to a degree. Just not quite in the sense that this headline suggests. There are now approaches were the prompt itself is being structured in a way (sort of like a spec) so you get to a similar result quicker. Not sure how well those work (I actually assume they suck, but I have not tried them). Also some frameworks, templates and so on, provide a bunch of structured markdown files that nudges LLM assistance to avoid common issues and do things in a certain way.
- Akef 8mo agoParadigm shift ahead, folks. What I observe in the comments—often more compelling than the article itself—is the natural tension within the scientific community surrounding the 'scientific method,' a debate that's been playing out for... what, a year now? Maybe less? True, this isn't perfect, nor does it come with functionality guarantees. Talking about 10x productivity? That's relative—it hinges on the tool, the cultural background of the 'orchestra conductor,' or the specific, hands-on knowledge accumulated by the conductor, their team, organization, and even the target industry. In essence: we're witnessing a paradigm shift. And for moments like these—I invite you—it's invaluable to have studied Popper and Kuhn in those courses. An even more provocative hypothesis: the 'Vienna Circle' has morphed into the 'Circle of Big Tech,' gatekeepers of the data. What's the role of academia here? What happened to professional researchers? The way we learn has been hijacked by these brilliant companies, which—at least this time—have a clear horizon: maximizing profits. What clear horizon did the stewards of the scientific method have before? Wasn't it tainted by the enunciator's position? The personal trajectory of the scientist, the institution (university) funding them? Ideology, politics? This time, it seems, we know exactly where we're headed. (This comment was translated from Spanish, please excuse the rough edges)
- voxleone 8mo agoOne thing I think the “LLM as new high-level language” framing misses is the role of structure and discipline. LLMs are great at filling in patterns, but they struggle with ambiguity, the exact thing we tolerate in human languages. A practical way to get better results is to stop prompting with prose and start providing explicit models of what we want. In that sense, UML-like notations can act as a bridge between human intent and machine output. Instead of: “Write a function to do X…” we give: “Here’s a class diagram + state machine; generate safe C/C++/Rust code that implements it.” UML is already a formal, standardized DSL for software structure. LLMs have no trouble consuming textual forms (PlantUML, Mermaid, etc.) and generating disciplined code from them. The value isn’t diagrams for humans but constraining the model’s degrees of freedom.
- FuckButtons 8mo agoHave you tried this? How did it go?
- gloosx 8mo agoA novice prefers declarative control, an expert prefers procedural control Beginner programmers want: "make this feature" Experienced devs want: control over memory, data flow, timing, failure modes That is why abstractions feel magical at first and suffocating later which sparks this whole debate.
- manuelabeledo 8mo agoAfter re-reading the post once again, because I honestly thought I was missing something obvious that would make the whole thing make sense, I started to wonder if the author actually understands the scope of a computer language. When he says: > LLMs are far more nondeterministic than previous higher level languages. They also can help you figure out things at the high level (descriptions) in a way that no previous layer could help you dealing with itself. […] What about quality and understandability? If instead of a big stack, we use a good substrate, the line count of the LLM output will be much less, and more understandable. If this is the case, we can vastly increase the quality and performance of the systems we build. How does this even work? There is no universe I can imagine where a natural language can be universal, self descriptive, non ambiguous, and have a smaller footprint than any purpose specific language that came before it.
- slfnflctd 8mo agoTo be generous and steelman the author, perhaps what they're saying is that at each layer of abstraction, there may be some new low-hanging fruit. Whether this is doable through orchestration or through carefully guided HITL by various specialists in their fields - or maybe not at all! - I suspect will depend on which domain you're operating in.
- onlyrealcuzzo 8mo agoYou're going to pretty hard pressed to do Rust better than Rust. There's minimal opportunity with lifetime annotations. I'm sure very small options elsewhere, too. The idea of replacing Rust with natural language seems insane. Maybe I'm being naive, but I can't see why or how it could possibly be useful. Rust is simply Chinese unless you understand what it's doing. If you translate it to natural language, it's still gibberish, unless you understand what it does and why first. In which case, the syntax is nearly infinitely more expressive than natural language. That's literally the point of the language, and it wasn't built by morons!
- manuelabeledo 8mo agoI believe the author thinks of this problem in terms of “the LLM will figure it out”, i.e. it will be trained on enough code that compiles, that the LLM just needs to put the functional blocks together. Which might work to a degree with languages like JavaScript.
- euroderf 8mo agoThe US military loves zillion-page requirements documents. Has anyone (besides maybe some Ph.Dork at DARPA) tried feeding a few to coder LLMs to generate applications - and then thrown them at test suites ?
- rco8786 8mo agoThe thing that’s always missing from these critiques isnt about code quality or LoC or slop. The issue is that if you fire off 10 agents to work autonomously for an extended period of time at least 9 of them will build the WRONG THING. The problem is context management and decision making based on that context. LLMs will always make assumptions about what you want, and the more assumptions they make the higher the likelihood that one or more of them is wrong.
- gaigalas 8mo agoBut what we really want is to cut down layers of abstraction, not increase them. I mean, we only have them because it is strictly necessary. If we could make architectures friendly to programming directly, we would have. In that sense, high level languages are not a marvelous thing but a burden we have to carry because of the strict requirements of low level ones. The less burdens like those we have, the better.
- senfiaj 8mo agoFor me LLMs feel closer to IDE with steroids. Unless LLMs produce the same output from the same input, I can't view them as compilers.
- Razengan 8mo agoIf you see magazines, articles, ads and TV shows from the 1980s (there are lots on YouTube and a fun rabbit hole, like the BBC Archive), the general promise was "Computers can do anything, if you program them." Well, nobody could figure out how to program them. Except the few outcasts like us who went on to suffer for the rest of our lives for it :') With phones & LLMs this is the closest we have come to that original promise of a computer in every home and everyone being able to do anything with it, that isn't pre-dictated by corporations and their apps: Ideally ChatGPT etc should be able to create interactive apps on the fly on iPhone etc. Imagine having a specific need and just being able to say it and get an app right away just for you on your device.
- podgorniy 8mo agoI want to see an example of the application with well written documentation which produces well working application based on those docs. I discovered that it is not trivial to conceptualize app to that extent of clarity which is required for deterministic output of LLM. It's way easier to say than to actually implement by yourself (that's why examples are so interesting to see). Backwards dynamics when you get spec/doc based on the source code does not work good enough.
- kittbuilds 8mo ago[dead]
- skaul 8mo agoProgramming with LLMs is fundamentally different than going from a lower-level to a higher-level language, even apart from the whole non-determinism thing. With a programming language, you're still writing a for-loop, whether that's in C, Java or Rust. There's language primitives that help you think better in certain languages, but they're still, at the end of the day, code and context that you have to hold in your head and be intimately familiar with. That changes with LLMs. For now, you can use LLMs to help you code that way; a programming buddy whose code you review. That's soon going to become "quaint" (to quote the author) given the projected productivity gains of agents (and for many developers it already has).
- redox99 8mo agoA programming language does not need to have a for loop. In fact many don't.
- skaul 8mo agoProgramming languages need to give the developer a way to iterate (map, fold, for-loop, whatever) over a collection of items. Over time we've come up with more elegant ways of doing this, but as a programmer, until LLMs, you've still had to be actively involved in the control logic. My point is that a developer's relationship with the code is very different now, in a way that wasn't true with previous low-to-high level language climbs.
- redox99 8mo agoI was thinking of something like SQL, which is declarative and you tell it what you want, not how to do it broadly speaking.
- freejazz 8mo agoWhen a computer programmer finally discovers English.
- notepad0x90 8mo agoThe problem is you still have to type prompts. That might require less word-count, but you still have to type it up, and it won't be short. For a small code base, your llm code might be a couple of pages, but for a complex code base it might be the size of medium-length novel. In the end, you have text typed by humans, that is lengthy. and it might contain errors in logic, contradictions, unforeseen issues in the instructions. And the same processes and tooling used for syntactic code might need to apply to it. You will need to version control your prompts for example. LLMs solve the labor problem, not the management problem. You have to spend a lot of time and effort with pages and pages of LLM prompts, trying to figure out which part of the prompt is generating which part of your code base. LLMs can debug and troubleshoot, but they can't debug and troubleshoot your prompts for you. I doubt they can take their own output, generated by multiple agents and lots of sessions and trace it all back to what text in your prompt caused all the mess either. On one hand, I want to see what this experimentation will yield, on the other hand, it had better not create a whole suite of other problems to solve just to use it. My confusion really is when experienced programmers advocate for this stuff. Actually typing in the code isn't very hard. I like the LLM-assistance aspect of figuring out what to actually code, and do some research. But actually figure out what code to type in, sure LLMs save time, but not that much time. getting it to work, debugging, troubleshooting, maintaining, those tend to be the pain-points. Perhaps there are shops out there that just crank out lots of LoC, and even measure developer performance based on LoC? I can see where this might be useful. I do think LLM-friendly high-level languages need to evolve for sure. But the ideal workflow is always going to be a co-pilot type of workflow. Humans researching and guiding the AI. Psychologically, until AI can maintain it's own code, this is a really bad idea. Actually typing out the code is extremely important for humans to be able to understand it. Or if someone wrote the code, you have to write something that is part of that code base and figure out how things fit together, AI can't do that for you, if you're still maintaining the codebase in any capacity.
- fpereiro 8mo agoHi HN! OP here. Thanks for reading and commenting -- (and @swah for posting!). It's unsettling to hit the HN front page, and even more so with an article that I hastily wrote down. I guess you never know what's going to hit a nerve. Some context: I'm basically trying to make sense of the tidal wave that's engulfing software development. Over the last 2-3 weeks I've realized that LLMs will start writing most code very soon (I could be wrong, though!). This article is just me making sense of it, not trying to convince anybody of anything (except of, perhaps, giving the whole thing a think). Most of the "discarded" objections I presented in the list were things I espoused myself over the past year. I should have clarified that in the article. I (barely) understand that LLMs are not a programming language. My point was that we could still think of them as a "higher level programming language", despite them 1) not being programming languages; 2) being wildly undeterministic; 3) also jumping levels by them being able to help you direct them. This way of looking at the phenomenon of LLMs is to try to see if previous shifts in programming can explain at least partially the dynamics we are seeing unfold so quickly (to find, in Ray Dalio's words, "another kind of those"). I am stepping into this world of LLM code generation with complicated feelings. I'm not an AI enthusiast, at least not yet. I love writing code by hand and I am proud of my hand-written open source libraries. But I am also starting to experience the possibilities of working on a higher level of programming and being able to do much more in breadth and depth. I fixed an important typo - here I meant: "Economically, only quality is undisputable as a goal". Responding to a few interesting points: @manuelabeledo: during 2025 I've been building a programming substrate called cell (think language + environment) that attempts to be both very compact and very expressive. Its goal is to massively reduce complexity to turn general purpose code more understandable (I know this is laughably ambitious and I'm desperately limited in my capabilities of pulling through something like that). But because of the LLM tsunami, I'm reconsidering the role of cell (or any other successful substrate): even if we achieve the goal, how will this interact with a world where people mostly write and validate code through natural language prompts? I never meant to say that natural language would itself be this substrate, or that the combination of LLMs and natural languages could do that: I still see that there will be a programming language behind all of this. Apologies for the confusion. @heikkilevanto & @matheus-rr: Mario Zechner has a very interesting article where he deals with this problem (https://mariozechner.at/posts/2025-06-02-prompts-are-code/#toc_1 https://mariozechner.at/posts/2025-06-02-prompts-are-code/#t...). He's exploring how structured, sequential prompts can achieve repeatable results from LLMs, which you still have to verify. I'm experimenting with the same, though I'm just getting started. The idea I sense here is that perhaps a much tighter process of guiding the LLM, with current models, can get you repeatable and reliable results. I wonder if this is the way things are headed. @woodenchair: I think that we can already experience a revolution with LLMs that are not fully autonomous. The potential is that an engineering-like approach to a prompt flow can allow you to design and review (not write) a lot more code than before. Though you're 100% correct that the analogy doesn't strictly hold until we can stop looking at the code in the same way that a js dev doesn't look at what the interpreter is emitting. @nly: great point. The thing is that most code we write is not elegant implementations of algorithms, but mostly glue or CRUDs. So LLMs can still broadly be useful. I hope I didn't rage bait anybody - if I did, it wasn't intentional. This was just me thinking out loud.
- boomlinde 8mo agoI propose that there is a different kind of "AI slop" than the one normally considered. This other category concerns ill-considered, half baked ideas relating to AI, without necessarily being conceived by it.