Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arxiv.org

Post reply on HN
Print view View original

161–170 of 230 posts

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

#161

Post by cess11 »

coldtea wrote: post #152
sdevonoes wrote: post #141

Earlier quoted context omitted.

> how long does it take me to ship something that is useful in production and solving a real problem But that’s only half of the problem. What about “and how easy it is to maintain long-term”. If you say that maintenance can be done via LLM, I would argue that there is zero guarantees that LLMs are backwards compatible and that the markdown you wrote now will work just as fine in 1,2,3 years

> I would argue that there is zero guarantees that LLMs are backwards compatible and that the markdown you wrote now will work just as fine in 1,2,3 years That this would be the case is even more guaranteed than some programming language being backwards compatible and the code we wrote working just as fine in 1,2,3, years. Languages do get non-backwards compatible changes, dependencies break, stuff is deprecated, etc…

"Languages do get non-backwards compatible changes, dependencies break, stuff is deprecated, etc."

Sure, but they're deterministic and sometimes you can even do automatic rewrites through AST inspection and writing back to the files instead of scripting string substitutions on them directly.

"But the job of LLMs will remain to generate something from a prompt, and the markdown we wrote, as it's high level and not tied to language versions, APIs, and implementation details, will be just as good a prompt for that in 2050 as it is in 2026."

Your organisation is keeping version control on the LLM:s you use? It's all local, old copies of these databases are kept in secure storage together with the querying and harnessing software?

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

#162

Post by deadbabe »

tcoff91 wrote: post #140
sdevonoes wrote: post #138

Earlier quoted context omitted.

> At some point this starts to look like we're all just moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language. This is the problem nobody is talking about. I see codebases growing in MD files with instructions and guidelines and requests that are also LLM generated… and it’s all piling up. No one is reviewing it 100% , a…

This is why you need to be generating more linter rules instead of just having things be in markdown files. I had never written an eslint rule until i started having agents pump them out for me and now I've encoded a bunch of important rules as lint rules that will fail CI if violated.

Who lints the linters

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

#163

Post by Geezus_42 »

AmazingTurtle wrote: post #59

So my finding is: planning is worth it. For a little complex changes, I always run codex (5.5-high) in planning mode first. I have linked various docs/{ARCHITECTURE,BACKEND-GUIDELINES,NESTJS-DI,..}.md etc. from AGENTS.md so they can quickly discover relevant docs at planning time, only if they are needed. No need to know react specific stuff when it's dealing with a backend problem for example. I typically blindly ap…

Sounds like you want something like this. https://github.com/tremtec/maestro

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

#164

Post by Npovview »

ethin wrote: post #102
Npovview wrote: post #33

Earlier quoted context omitted.

Do you also happen to remember what you ate last thrusday?

Do you have a point? Because last time I checked, AIs were supposed to be better than us fragile faulty humans, and weren't designed to emulate us and all our faults.

If you have been following the news, harness is also a scaling direction now. Prompt your AI better not to forget relevant stuff or write them in a file which it can refer later. This way context can be refreshed, this is cached facts method or rolling window method of refreshing your memory just like you would ask a colleague to explain a concept again. These are solved problems.

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

#165

Post by kang »

guhcampos wrote: post #93

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,…

hehe, this is by design. next model needs to eat your natural language

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

#166

Post by phantompeace »

dominotw wrote: post #110
guhcampos wrote: post #93

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]

Source?

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

#168

Post by sirsinsalot »

coldtea wrote: post #154
dominotw wrote: post #110

Earlier quoted context omitted.

[flagged]

I don't think you understand how LLMs work. They're not merely re-arranging pre-existing blocks of code. And they have been shown to develop emergent properties that weren't in their training set time and again. They generate novel things as much as the average programmer (which works after himself having practice, exposure to codebases, and training, and reading API documentation, and such) generates novel things.

Not to be pedantic but the emergent properties are in the training set, and thus the model and algorithm. There's no magic coming from the universe.

What makes the behavior emergent is that it can't be predicted at training time.

The emergent and unpredictable output is the result of massive vector complexity being encoded.

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

#170

Post by rco8786 »

gib444 wrote: post #132
qsort wrote: post #22

Earlier quoted context omitted.

I think it's downstream of "you can't optimize for two different objectives". If you only have functional requirements, then in effect you're doing some form of program synthesis, and RL can optimize that very hard. If you have a mixture of functional and non-functional requirements, you are basically giving the model an incomplete specification, and it must in some way guess at the user's intent to fill in the blank…

> ... This is also why adding to the prompt examples of the style of code you want ... You could take it a step further and put the example code into source code files...and be like, super comprehensive with your examples ... ;)

Well yes, ideally. But real world codebases aren't clean enough to be used as the example ideal. Styles change over time, there are always code migrations and refactors in flight, legacy code exists, etc. Using specific examples of what you expect the LLM (and humans) to do now is necessary.
Post reply on HN