21–30 of 178 posts
LLMs would also need to use historic commits as context, rather than just the current state of the codebase in isolation. Most codebases I've worked with go through migrations from a legacy pattern A to a newer and better pattern B, used across different parts of the codebase. Rarely can these migrations be done in a single go, so both patterns tend to stick around for a while as old code is revisited. Like the HTTP…
LLMs would also need to use historic commits as context, rather than just the current state of the codebase in isolation. Most codebases I've worked with go through migrations from a legacy pattern A to a newer and better pattern B, used across different parts of the codebase. Rarely can these migrations be done in a single go, so both patterns tend to stick around for a while as old code is revisited. Like the HTTP…
I once worked on a massive codebase that had survived multiple acquisitions, renames and mergers over a 20 year period. By the time I left it had finally passed into the hands of a Fortune 500 global company.
You would often find code that matched an API call you required that was last updated in the mid-2000s, but there was a good chance that it was not the most recent code for that task, but still existed as it was needed for some bespoke function a single client used.
There could also be similar API calls with no documentation, and you had to pick the one that returned the data fields that you wanted.
The legal department may have a different idea there.
Earlier quoted context omitted.
No, LLMs are not an "abstraction" like a compiler is. This is bullshit. LLMs are stochastic token generators. I have NEVER met someone in real life that has produced something I wouldn't throw in the trash using LLMs, and I have had the displeasure of eating cookies baked from an LLM recipe. No, LLMs will not get better. The singularity bullshit has been active since 2010s. LLMs have consumed the entire fucking Inter…
>No, LLMs will not get better. What makes you so sure of this? They've been getting better like clockwork every few months for the past 5 years.
The hallucinate exactly as much as they did five years ago.
I've noticed this as well. I've also noticed that the effort to de-slop the shit-code is quite significant, and many times eats the productivity gains of having the LLM generate the code.
> No one would implement a bunch of utility functions that we already have in a different module.
> No one would change a global configuration when there’s a mechanism to do it on a module level.
> No one would write a class when we’re using a functional approach everywhere.
Boy I'd like to work on whatever teams this guy's worked on. People absolutely do all those things.
The question then is: do the bad developers improve by vibe coding, or are they stuck in a local optimum?
Earlier quoted context omitted.
>No, LLMs will not get better. What makes you so sure of this? They've been getting better like clockwork every few months for the past 5 years.
No they haven't. The hallucinate exactly as much as they did five years ago.
Setting up a linter, formatter and having a lot of strict type checking are really helpful when using an llm to generate code, just like they are when you start receiving contributions from people who don't know or don't agree with the style rules that you implicitly follow. As are tests. Basically anything automated that helps ensure the right style and behaviour of your code becomes very useful with coding agents a…
LLMs would also need to use historic commits as context, rather than just the current state of the codebase in isolation. Most codebases I've worked with go through migrations from a legacy pattern A to a newer and better pattern B, used across different parts of the codebase. Rarely can these migrations be done in a single go, so both patterns tend to stick around for a while as old code is revisited. Like the HTTP…