5 ms·

> Because no one would write an HTTP fetching implementation covering all edge cases when we have a data fetching library in the project that already does that.

by lmm 1y ago

> Because no one would write an HTTP fetching implementation covering all edge cases when we have a data fetching library in the project that already does that. > 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.

0x_rs 1y ago
This. Reinventing the wheel at every opportunity, forgetting about or ignoring the expected way to do something, mixing patterns, you name it. The author may call it "vibe coding", that's fine but it has little to do with LLMs. The tool has the same amount of care anyone rushing to get something done, or that hasn't build the project themselves, or maybe doesn't have enough experience would. I can only assume it's a not-very-subtle complaint about a specific person in their team, "written in a way no developer on the team would" is telling. I'd be extremely careful about applying this thinking anywhere else. There's enough baseless finger-pointing in academia and arts already.
- noodletheworld 1y ago
  > The author may call it "vibe coding", that's fine but it has little to do with LLMs. Humm. Maybe if we say that this is not an issue from vibe coding it wont be? Maybe if we pretend that maybe a naive junior would make these mistakes (true) we should be happy to accept them from senior developers (false)? LLMs are extraordinarily bad at doing these things. I’ve seen it. You've seen it. The OP has seen it. You’re in a rush so you wrote some classes in a code base in a language which supports classes but has no classes in it? Really? Did that get past code review before? Did you deliberately put up a code review that you knew would be rejected and take longer to merge as a result because you were in a hurry? Of course not. You did the bare minimum that still met the basic quality standards expected of you. I get it. We all get it. When youre in a rush you cut corners to move faster. …but thats not what the OP is talking about, and its not what I see either: Its people putting up AI slop and not caring at all what the content was. Just a quick check it compiled and the tests pass if youre lucky. Too lazy even put a “dont use classes” in their cursor rules file. Come on. The OP isnt saying dont use AI. Theyre saying care, just a little bit about your craft ffs.
Msurrow 1y ago
I have worked on such teams. Mostly, even. I would not accept any PRs with code doing any of those things (human or machine made). Small(er) teams on small to medium sized projects. Critical solutions, but small(er) projects with 2-4 devs, that’s where it’s at. I feel like it’s because then it’s actually possible to build a devteam culture and consensus that has the wanted balance of quality and deliveryspeed.
lintfordpickle 1y ago
>> No one would implement a bunch of utility functions that we already have in a different module. to be fair on this one, and while I don't flat out disagree, lots of people reinvent utility functions simply because they don't know they exist elsewhere, especially on huge code bases. This seems to get mostly rectified within the PRs, when a senior dev comments on it - the problem then is, you've only increased the number of people who now know by 1.
merelysounds 1y ago
I guess these things occur in workplaces that prioritize speed over maintainability anyway.
Cthulhu_ 1y ago
They do, but if they're on the team for a while they already should know how to find / use the established patterns; if they then submit something that they normally wouldn't, it's a problem.
elashri 1y ago
To be honest, most of these things can happen for poorly documented large codebase. I work on academic research project that have docs that tells you basically that the code is self documented. And give one or two pages about configuring CMake and build the project and another page on how to benchmark the throughout. But the internal quirks and the expected convention you will need to figure it on your own. New people contributing usually reinvent many things and change global configuration because they don't know they can use something already there. Ironically indexing the codebase and ask LLM questions about specific things is the best thing you can do. Because the only 3 people who you can ask left the project or are busy and will reply within a week.
- nosianu 1y ago
  > most of these things can happen for poorly documented large codebase. Documentation does not help beyond a point. Nobody reads the documentation repeatedly, which would be needed. When you keep working on a project, and you need a new function, you would need to check or remember every single time that such a function already exists or might exist somewhere. You may have found it when you read the docs months ago, but since you had no need for that function at the time your brain just dismissed it and tossed that knowledge out. For example, I had a well-documented utils/ folder with just a few useful modules, but they kept getting reimplemented by various programmers. I did not fault them, they would have had to remember every single time they needed some utility to first check that folder. All while keeping up that diligence forever, and while working on a number of projects. It is just too hard. Most of the time you would not find what you need, so most of the time that extra check would be a waste. Even the most diligent person would at some point reimplement something that already exists, no matter how well-documented it is. It's about that extra search step itself. The closer you want 100% perfection you get exponentially increasing effort. So we have some duplication, not a big deal. Overall architectural quality is more important than squeezing out those last not really important few percent of perfection.
  - yunohn 1y ago
    I agree with you completely, but also posit that this is exactly what agentic LLMs should solve? Claude code’s Plan mode kind of does this research before coding - but tbf the Search tool seemingly fails half the time with 0 results and it gets confused and then reimplements too…
shaky-carrousel 1y ago
Competent people don't. And if your code looks competent but your behaviour doesn't, it's a clue.
godelski 1y ago
I think you're missing the author's thesis > Is speed the greatest virtue? If speed is the greatest virtue then yeah, all that stuff will happen. But if it isn't, then that stuff will happen at a much lower frequency. Because, all the stuff mentioned is just tech debt. Debt doesn't go away, it accrues interest. If speed is all that matters then you need exponential output, as your output needs to offset the debt. If speed is a factor but isn't the only factor, then you need to weigh it against the other things. Take on debt wisely and pay it off when you can. But it does seem like there's a trend to just take on as much debt and hope for the best. Last I checked, most people aren't really good at handling debt.
- lbriner 1y ago
  I think you are misusing the phrase "tech debt" like many people do. Not everything that is not perfect is Tech Debt, some of it is just pragmatism. If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing, might never need any maintenance attention and will never be paid down before the codebase is replaced in 10 years time. Same with people writing code in a different style to others. If it is unreadable, that isn't tech debt either, it's just a lack of process or lack of someone following the process. Shouldn't be merged = no tech debt. Adding some code to check edge cases that are already handled elsewhere. Again, who cares? If the code make it unreadable, delete it if you know it isn't needed, it only took 10 seconds to generate. If it stays in place and is understandable, it's not tech debt. Again, not going to pay it down, it doesn't cost anything and worse case is you change one validation and not the other and a test fails, shouldn't take long to find the problem. Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again.
  - darkwater 1y ago
    > Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again. Thing that many people do without even realizing they are incurring in tech debt. This kind of developers are the one that will just generate more tech debt with an LLM in their hands (at least now).
shepherdjerred 1y ago
You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves
- sshine 1y ago
  It seems like people who use AI for coding need to reinvent a lot of the same basic principles of software engineering before they gradually propagate into the mainstream agentic frameworks. Coding agents come with a lot of good behavior built in. Like "planning mode" where they create a strong picture of what's to be made before touching files. This has honestly improved my workflow at programming from wanting to jump into prototyping before I even have a clear idea, to being very spec-oriented: Of course there needs to be a plan, especially when it will be drafted for me in seconds. But the amount of preventable dumb things coding agents will do that need to be explicitly stated and meticulously repeated in their contexts reveals how simply training on the world's knowledge does not capture senior software engineer workflows entirely, and captures a lot of human averageness that is frowned upon.
  - shepherdjerred 1y ago
    100% A lot has to be re-done. Using an IDE like Cursor is really a skill in its own & you likely won't see a productivity boost using agents without moderate investment, and even then there are tradeoffs. I think the real benefit comes in a few years when more engineering has been done and the tools are more polished. The way that I look at is that these tools are the worst they'll ever be.
- cardanome 1y ago
  Do those rules really work? I have added the rule to not not add comments and I still have to constantly remind the model to not add comments despite of it.
  - 1y ago
mysterydip 1y ago
I once inherited a project that had three separate classes for storing time, each with their own methods to convert between each other.
- hakunin 1y ago
  I can think of reasons for this (e.g. storing date/time as it was originally represented 100, 1000 years ago in a historical context vs storing live time for present-day time calculations vs storing non-timezone time for, say, operating hours relative to subject's location), so this statement alone doesn't show fault.
  - mysterydip 1y ago
    Fair enough. All three were for the same (live, present day) timestamp, and sometimes used within the same function, eg "timeb = timea+timec" where timea would be one class, and timeb and timec would be another.
bux93 1y ago
Not only do people do these things, they put their work on github. Which is where the LLM learns to do it!
Too 1y ago
Identifying such almost-duplicate code is an open opportunity for LLMs.
hakunin 1y ago
My entire (decades) career I worked primarily in small start up teams, and even when people didn't see eye to eye, they always maintained these kinds of basic practices. I think a lot of disagreement on these expectations is rooted in the size and "tight-knit"ness of your team.
- camdenreslink 1y ago
  I think size of the code base matters a lot too. In a multi-100k line of code application, you might not know a utility function is already defined somewhere and reinvent the wheel.
perrygeo 1y ago
I've seen developers add a second ORM library as a dependency, not because the first didn't do the job but because they just "forgot" about the first one and wanted to use the new hotness. Developers, just like LLMs, have biases that taint the solution space. The key is that we all have an intuitive sense that this behavior is wrong - building a project means working within the established patterns of that project, or at least being aware of them! Going off half-cocked and building a solution without considering the context is extremely bad form. In the case of human developers, this can be fixed on the code review level, encouraging a culture of reading not just writing code. Without proper guardrails, they can create code that's dissonant with the existing project. In the case of LLMs, the only recourse is context engineering. You need to make everything explicit. You need to teach the LLM all the patterns that matter. Their responses will always be probabilistic token salad, by definition. Without proper guardrails, it will create code that's dissonant with the existing project. Either way, it's a question of subjective values. The patterns that are important need to be articulated, otherwise you get token salad randomly sampling the solution space.
- eddd-ddde 1y ago
  Heavy agree on your first paragraph. You spend one evening removing one unnecessary dependency only to see 5 more were added by next Monday. I think soon enough we'll have a decent LLM that's capable of reviewing ALL changes to ensure they follow the "culture" we expect to see.
tom_m 1y ago
Don't be so sure about that.

by lmm 1y ago

0x_rs 1y ago

This. Reinventing the wheel at every opportunity, forgetting about or ignoring the expected way to do something, mixing patterns, you name it. The author may call it "vibe coding", that's fine but it has little to do with LLMs. The tool has the same amount of care anyone rushing to get something done, or that hasn't build the project themselves, or maybe doesn't have enough experience would. I can only assume it's a not-very-subtle complaint about a specific person in their team, "written in a way no developer on the team would" is telling. I'd be extremely careful about applying this thinking anywhere else. There's enough baseless finger-pointing in academia and arts already.

noodletheworld 1y ago
> The author may call it "vibe coding", that's fine but it has little to do with LLMs. Humm. Maybe if we say that this is not an issue from vibe coding it wont be? Maybe if we pretend that maybe a naive junior would make these mistakes (true) we should be happy to accept them from senior developers (false)? LLMs are extraordinarily bad at doing these things. I’ve seen it. You've seen it. The OP has seen it. You’re in a rush so you wrote some classes in a code base in a language which supports classes but has no classes in it? Really? Did that get past code review before? Did you deliberately put up a code review that you knew would be rejected and take longer to merge as a result because you were in a hurry? Of course not. You did the bare minimum that still met the basic quality standards expected of you. I get it. We all get it. When youre in a rush you cut corners to move faster. …but thats not what the OP is talking about, and its not what I see either: Its people putting up AI slop and not caring at all what the content was. Just a quick check it compiled and the tests pass if youre lucky. Too lazy even put a “dont use classes” in their cursor rules file. Come on. The OP isnt saying dont use AI. Theyre saying care, just a little bit about your craft ffs.

Msurrow 1y ago

I have worked on such teams. Mostly, even. I would not accept any PRs with code doing any of those things (human or machine made). Small(er) teams on small to medium sized projects. Critical solutions, but small(er) projects with 2-4 devs, that’s where it’s at. I feel like it’s because then it’s actually possible to build a devteam culture and consensus that has the wanted balance of quality and deliveryspeed.

lintfordpickle 1y ago

>> No one would implement a bunch of utility functions that we already have in a different module. to be fair on this one, and while I don't flat out disagree, lots of people reinvent utility functions simply because they don't know they exist elsewhere, especially on huge code bases. This seems to get mostly rectified within the PRs, when a senior dev comments on it - the problem then is, you've only increased the number of people who now know by 1.

merelysounds 1y ago

I guess these things occur in workplaces that prioritize speed over maintainability anyway.

Cthulhu_ 1y ago

They do, but if they're on the team for a while they already should know how to find / use the established patterns; if they then submit something that they normally wouldn't, it's a problem.

elashri 1y ago

To be honest, most of these things can happen for poorly documented large codebase. I work on academic research project that have docs that tells you basically that the code is self documented. And give one or two pages about configuring CMake and build the project and another page on how to benchmark the throughout. But the internal quirks and the expected convention you will need to figure it on your own. New people contributing usually reinvent many things and change global configuration because they don't know they can use something already there. Ironically indexing the codebase and ask LLM questions about specific things is the best thing you can do. Because the only 3 people who you can ask left the project or are busy and will reply within a week.

nosianu 1y ago
> most of these things can happen for poorly documented large codebase. Documentation does not help beyond a point. Nobody reads the documentation repeatedly, which would be needed. When you keep working on a project, and you need a new function, you would need to check or remember every single time that such a function already exists or might exist somewhere. You may have found it when you read the docs months ago, but since you had no need for that function at the time your brain just dismissed it and tossed that knowledge out. For example, I had a well-documented utils/ folder with just a few useful modules, but they kept getting reimplemented by various programmers. I did not fault them, they would have had to remember every single time they needed some utility to first check that folder. All while keeping up that diligence forever, and while working on a number of projects. It is just too hard. Most of the time you would not find what you need, so most of the time that extra check would be a waste. Even the most diligent person would at some point reimplement something that already exists, no matter how well-documented it is. It's about that extra search step itself. The closer you want 100% perfection you get exponentially increasing effort. So we have some duplication, not a big deal. Overall architectural quality is more important than squeezing out those last not really important few percent of perfection.
- yunohn 1y ago
  I agree with you completely, but also posit that this is exactly what agentic LLMs should solve? Claude code’s Plan mode kind of does this research before coding - but tbf the Search tool seemingly fails half the time with 0 results and it gets confused and then reimplements too…

shaky-carrousel 1y ago

Competent people don't. And if your code looks competent but your behaviour doesn't, it's a clue.

godelski 1y ago

I think you're missing the author's thesis > Is speed the greatest virtue? If speed is the greatest virtue then yeah, all that stuff will happen. But if it isn't, then that stuff will happen at a much lower frequency. Because, all the stuff mentioned is just tech debt. Debt doesn't go away, it accrues interest. If speed is all that matters then you need exponential output, as your output needs to offset the debt. If speed is a factor but isn't the only factor, then you need to weigh it against the other things. Take on debt wisely and pay it off when you can. But it does seem like there's a trend to just take on as much debt and hope for the best. Last I checked, most people aren't really good at handling debt.

lbriner 1y ago
I think you are misusing the phrase "tech debt" like many people do. Not everything that is not perfect is Tech Debt, some of it is just pragmatism. If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing, might never need any maintenance attention and will never be paid down before the codebase is replaced in 10 years time. Same with people writing code in a different style to others. If it is unreadable, that isn't tech debt either, it's just a lack of process or lack of someone following the process. Shouldn't be merged = no tech debt. Adding some code to check edge cases that are already handled elsewhere. Again, who cares? If the code make it unreadable, delete it if you know it isn't needed, it only took 10 seconds to generate. If it stays in place and is understandable, it's not tech debt. Again, not going to pay it down, it doesn't cost anything and worse case is you change one validation and not the other and a test fails, shouldn't take long to find the problem. Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again.
- darkwater 1y ago
  > Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again. Thing that many people do without even realizing they are incurring in tech debt. This kind of developers are the one that will just generate more tech debt with an LLM in their hands (at least now).

shepherdjerred 1y ago

You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves

sshine 1y ago
It seems like people who use AI for coding need to reinvent a lot of the same basic principles of software engineering before they gradually propagate into the mainstream agentic frameworks. Coding agents come with a lot of good behavior built in. Like "planning mode" where they create a strong picture of what's to be made before touching files. This has honestly improved my workflow at programming from wanting to jump into prototyping before I even have a clear idea, to being very spec-oriented: Of course there needs to be a plan, especially when it will be drafted for me in seconds. But the amount of preventable dumb things coding agents will do that need to be explicitly stated and meticulously repeated in their contexts reveals how simply training on the world's knowledge does not capture senior software engineer workflows entirely, and captures a lot of human averageness that is frowned upon.
- shepherdjerred 1y ago
  100% A lot has to be re-done. Using an IDE like Cursor is really a skill in its own & you likely won't see a productivity boost using agents without moderate investment, and even then there are tradeoffs. I think the real benefit comes in a few years when more engineering has been done and the tools are more polished. The way that I look at is that these tools are the worst they'll ever be.
cardanome 1y ago
Do those rules really work? I have added the rule to not not add comments and I still have to constantly remind the model to not add comments despite of it.
- 1y ago

mysterydip 1y ago

I once inherited a project that had three separate classes for storing time, each with their own methods to convert between each other.

hakunin 1y ago
I can think of reasons for this (e.g. storing date/time as it was originally represented 100, 1000 years ago in a historical context vs storing live time for present-day time calculations vs storing non-timezone time for, say, operating hours relative to subject's location), so this statement alone doesn't show fault.
- mysterydip 1y ago
  Fair enough. All three were for the same (live, present day) timestamp, and sometimes used within the same function, eg "timeb = timea+timec" where timea would be one class, and timeb and timec would be another.

bux93 1y ago

Not only do people do these things, they put their work on github. Which is where the LLM learns to do it!

Too 1y ago

Identifying such almost-duplicate code is an open opportunity for LLMs.

hakunin 1y ago

My entire (decades) career I worked primarily in small start up teams, and even when people didn't see eye to eye, they always maintained these kinds of basic practices. I think a lot of disagreement on these expectations is rooted in the size and "tight-knit"ness of your team.

camdenreslink 1y ago
I think size of the code base matters a lot too. In a multi-100k line of code application, you might not know a utility function is already defined somewhere and reinvent the wheel.

perrygeo 1y ago

I've seen developers add a second ORM library as a dependency, not because the first didn't do the job but because they just "forgot" about the first one and wanted to use the new hotness. Developers, just like LLMs, have biases that taint the solution space. The key is that we all have an intuitive sense that this behavior is wrong - building a project means working within the established patterns of that project, or at least being aware of them! Going off half-cocked and building a solution without considering the context is extremely bad form. In the case of human developers, this can be fixed on the code review level, encouraging a culture of reading not just writing code. Without proper guardrails, they can create code that's dissonant with the existing project. In the case of LLMs, the only recourse is context engineering. You need to make everything explicit. You need to teach the LLM all the patterns that matter. Their responses will always be probabilistic token salad, by definition. Without proper guardrails, it will create code that's dissonant with the existing project. Either way, it's a question of subjective values. The patterns that are important need to be articulated, otherwise you get token salad randomly sampling the solution space.

eddd-ddde 1y ago
Heavy agree on your first paragraph. You spend one evening removing one unnecessary dependency only to see 5 more were added by next Monday. I think soon enough we'll have a decent LLM that's capable of reviewing ALL changes to ensure they follow the "culture" we expect to see.

tom_m 1y ago

Don't be so sure about that.