If llms are able to write better code with more declarative and local programming components and tailwind, then I could imagine a future where a new programming language is created to maximize llm success.
This so much. To me it seems so strange that few good language designers and ml folks didn't group together to work on this. It's clear that there is a space for some LLM meta language that could be designed to compile to bytecode, binary, JS, etc. It also doesn't need to be textual like we code, but some form of AST llama can manipulate with ease.
At that point why not just have LLMs generate bytecode in one shot?
Is it possible to sue this with Cursor? If so what is the name of the model? gemini-2.5-pro-preview ? edit> Its gemini-2.5-pro-preview-05-06 edit>Cursor syas it doesnt have "good support" et, but im not sure if this is a defualt message when it doesnt recognise a model? is this a big deal? should I wait until its officially supported by cursor? Just trying to save time here for everyone - anyone know the answer?
Cursor UI sucks, it tells me to use -auto mode- to be faster, but gemini 2.5 is way faster than any of the other free models, so just selecting that one is faster even if the UI says otherwise
yeah ive noticed this too, like wtf would I use Auto?
My frustration with using these models for programming in the past has largely been around their tendency to hallucinate APIs that simply don't exist. The Gemini 2.5 models, both pro and flash, seem significantly less susceptible to this than any other model I've tried. There are still significant limitations, no amount of prompting will get current models to approach abstraction and architecture the way a person doe…
> no amount of prompting will get current models to approach abstraction and architecture the way a person does I find this sentiment increasingly worrisome. It's entirely clear that every last human will be beaten on code design in the upcoming years (I am not going to argue if it's 1 or 5 years away, who cares?) I wished people would just stop holding on to what amounts to nothing, and think and talk more about wha…
I mean, if you draw the scaling curves out and believe them, then sometime in the next 3-10 years, plausibly shorter, AIs will be able to achieve best-case human performance in everything able to be done with a computer and do it at 10-1000x less cost than a human, and shortly thereafter robots will be able to do something similar (though with a smaller delta in cost) for physical labor, and then shortly after that we get atomically precise manufacturing and post-scarcity. So the amount of stuff that amounts to nothing is plausibly every field of endeavor that isn't slightly advancing or delaying AI progress itself.
I feel like there are two realities right now where half the people say LLM doesn't do anything well and there is another half that's just using LLM to the max. Can everybody preface what stack they are using or what exactly they are doing so we can better determine why it's not working for you? Maybe even include what your expectations are? Maybe even tell us what models you're using? How are you prompting the model…
I've found, like you mentioned, that the tech stack you work with matters a lot in terms of successful results from LLMs. Python is generally fine, as you've experienced, as is JavaScript/TypeScript & React. I've had mixed results with C# and PowerShell. With PowerShell, hallucinations are still a big problem. Not sure if it's the Noun-Verb naming scheme of cmdlets, but most models still make up cmdlets that don't ex…
FWIW If you are using Github Copilot Edit/Agent mode - you may have more luck with other plugins. Until recently, Claude 3.5 Sonnet worked really well with C# and required relatively few extra commands to stay consistent to "newest tersest" style. But then, from my understanding, there was a big change in how Copilot extension handles attached context alongside changes around what I presume prompt and fine-tuning which resulted in severe degradation of the output quality. Hell, even attaching context data does not properly work 1 out of 3 times. But at least Gemini 2.5 Pro can write test semi-competently, but I still can't fathom how did the manage to make it so much worse!
Google's models are pretty good, but their API(s) and guarantees aren't. We were just told today that 'quota doesn't guarantee capacity' so basically on-demand isn't prod capable. Add to that that there isn't a second vendor source like Anthropic and OpenAI have and Google's reliability makes it a hard sell to use them unless you can back up the calls with a different model family all together.
Here's a summary of the 394 comments on this post created using the new gemini-2.5-pro-preview-05-06. It looks very good to me - well grouped, nicely formatted.
Does the code consist of many large try except blocks that catch "Exception", which Gemini seems to like doing, (I thought it was a bad practice to catch the generic Exception in Python)
Catching the generic exception is a nice middleground between not catching exceptions at all (and letting your script crash), and catching every conceivable exception individually and deciding exactly how to handle each one. Depends on how reliable you need your code to be.
Hmm, for my use case just allowing the lines to fail would have been better, (which I told the model)
> no amount of prompting will get current models to approach abstraction and architecture the way a person does I find this sentiment increasingly worrisome. It's entirely clear that every last human will be beaten on code design in the upcoming years (I am not going to argue if it's 1 or 5 years away, who cares?) I wished people would just stop holding on to what amounts to nothing, and think and talk more about wha…
I'm always impressed by the ability of the comment section to come up with more reasons why decent design and architecture of source code just can't happen: * "it's too hard!" * "my coworkers will just ruin it" * "startups need to pursue PMF, not architecture" * "good design doesn't get you promoted" And now we have "AI will do it better soon." None of those are entirely wrong. They're not entirely correct, either.
It’s always so aggressive too. What fools we are for trying to write maintainable code when it’s so obviously impossible.
> no amount of prompting will get current models to approach abstraction and architecture the way a person does I find this sentiment increasingly worrisome. It's entirely clear that every last human will be beaten on code design in the upcoming years (I am not going to argue if it's 1 or 5 years away, who cares?) I wished people would just stop holding on to what amounts to nothing, and think and talk more about wha…
> It's entirely clear that every last human will be beaten on code design in the upcoming years Citation needed. In fact, I think this pretty clearly hits the "extraordinary claims require extraordinary evidence" bar.
Trends would dictate that this will keep scaling and surpass each goalpost year by year.
Why is it inevitable? Progress towards a goal in the past does not guarantee progress towards that goal in the future. There are plenty of examples of technology moving forward, and then hitting a wall.
I agree with you it isnt guaranteed to be inevitable, and also agree there have been plenty of journeys which were on a trajectory only to fall off. That said, IMHO it is inevitable. My personal (dismal) view is that businesses see engineering as a huge cost center to be broken up and it will play out just like manufacturing -- decimated without regard to the human cost. The profit motive and cost savings are just to…
> businesses see engineering as a huge cost center to be [...] decimated without regard to the human cost
Most cost centers in the past were decimated in order to make progress: from horse-drawn carriages to cars and trucks, from mining pickaxes to mining machines, from laundry at the river to clothes washing machines, etc. Is engineering a particularly unique endeavor that needs to be saved from automation?