Live data from Hacker News

Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

arxiv.org

121–130 of 230 posts

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#121

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

Most code written are not novel. Actually most code written should not be novel. Eg: the number of lines of code written isn't spent on writing git, it's spent on writing that landing page no one ever sees.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#122

I think someone is going to figure out a framework for using LLMs for coding. A framework would use static code checking tools to force an architecture on to LLMs instead of trying to do so in markdown. I don't know exactly what it will look like but for example I could imagine a Java Framework where the LLM could only create subclasses of certain classes.

A lot of us have been doing this for over a year now.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#123
post #78
post #50

Earlier quoted context omitted.

Critiques like this tend to focus very hard on what models can't do. It's true, they have limitations. But they're also superhuman in so many other ways. It's valid to point out limitations, but that doesn't support the conclusion that models are not incredibly powerful and capable of the functional equivalent of reasoning at human or superhuman levels in many scenarios.

They may be better than humans at reasoning but they are substantially worse than the first generation logic programs from the 1950s.

These types of comments help demonstrate first-hand how human reasoning stacks up against what an LLM would say in this situation.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#124

Earlier quoted context omitted.

I don't know if you're being factitious or not but that was not what I meant. Picasso being a great painter is an example of "having taste"; "create an artistic image generation model with Picasso-level performance" is a valid problem statement we could attack with RLHF, but not with RLVR, because "taste" is not amenable to modeling with a reward function. "Write this code in a way that is readable and maintainable"…

https://futurism.com/artificial-intelligence/real-monet-ai-c...

The first paragraph ends with "[...] unleashing a flood of ill-informed reactions and muddled discourse. So, you know, it was just another day online."

It's almost as though it's not about the Monet.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#125

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

> moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language

It's like using a compiler that generates semantically different code every time you run it. Basically like compiling a program that's full of UB but "seems to work" most of the time.

> business sees this as productivity gains

Back to LoC/s as a measure of "productivity."

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#126

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

If we were doing novel things, we’d be scientists. I’m an engineer though. I don’t think I’ve been writing slop for 30 years.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#127

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

they can take novel things. so my novel

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#128

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

> moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language It's like using a compiler that generates semantically different code every time you run it. Basically like compiling a program that's full of UB but "seems to work" most of the time. > business sees this as productivity gains Back to LoC/s as a measure of "producti…

> Back to LoC/s as a measure of "productivity."

IMO this doesn’t follow from what OP wrote. I personally measure it with a more abstract “how long does it take me to ship something that is useful in production and solving a real problem” and the increase in speed there has been massive for me. But of course I’m not a bigbrain 10x coder that is doing bleeding edge novel stuff like most people here, so gains might be more obvious for me than for others.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#129

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

Unless you mean remixing the alphabet / tokens, this is mathematically false. 2^256 gets you to unique very fast, and that’s like 252 bytes or like 80 tokens. Remember almost all numbers are irrational. Complexity is infinite.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#130

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

> you are merely remixing whats out there

So basically 90% of programming in an enterprise environment? lol. Sounds useful to me...

Post reply on HN