7 ms·

I know when you're vibe coding

353 points by thunderbong 1y ago

gronglo 1y ago
I think this should be renamed "I know when you're vibe coding with a last generation LLM". Claude 4 Opus would not make any of the mistakes mentioned, because it knows and understands everything in your codebase. It would know when there's an existing utility function for that particular task, or that you prefer a functional rather than OOP approach. You say you want developers to care about the code they write, well, this is the next best thing; I believe it's as close as we'll see to a machine being able to "care" in my lifetime.
parpfish 1y ago
> No one would write a class when we’re using a functional approach everywhere. do people really think functional coding shouldn't involve writing classes? i can't imagine writing what i think of as code in a "functional programming style" without tons of dataclasses to describe different immutable records that get passed around. and if you're feeling fancy, add some custom constructors to those dataclasses for easy type conversions.
- bublyboi 1y ago
  I think he’s referring to classes vs functions in React
- williamstein 1y ago
  In the context of react codebases, people typically use either functional components everywhere or class components. Mixing the two approaches is frustrating and painful, eg you can’t use any of the hooks in your codebase in a class component. Perhaps the OP was talking about this, but just being really vague.
atleastoptimal 1y ago
This is all true. The best way to treat LLM's as they are now is one step above the abstraction offered by compiled languages over assembly. You can describe something in plain english, note its explicit requirements, inputs and outputs, and an LLM can effectively write the code as a translation of the logic you are specifying. Using LLM's, you are best served minimizing the entropy they have to deal with. The transformer is essentially a translation engine, so use it as a translator, not as a generator. That being said, every few months a new model comes out that is a little less encumbered by the typical flaws of LLM's, a little more "intuitively" smart and less needing of hand-holding, a little more reliable. I feel that this is simply a natural course of evolution, as more money is put into LLM's they get better because they're essentially a giant association machine, and those associations give rise to larger abstractions, more robust conceptions of how to wield the tools of understanding the world, etc. Over time it seems inevitable that providing an LLM any task it will be able to perform that task better than any human programmer given it, and the same will go for the rest of what humans do.
- voxl 1y ago
  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 Internet and are still useless. Where the fuck is the rest of the data going to come from? All these emails from people wanting high quality data from PhDs only for them to be scammy. People only want to train these things on easily stolen garbage, not quality input, because quality is expensive. Go figure! This optimistic horeshit hype is embarrassing.
  - atleastoptimal 1y ago
    >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.
    - otabdeveloper4 1y ago
      No they haven't. The hallucinate exactly as much as they did five years ago.
      - atleastoptimal 1y ago
        Absolutely untrue. Claiming GPT-3 hallucinates as much as o3 over the same token horizon on the same prompts is a silly notion and easily disproven by the dozens of benchmarks. You can code a complete web-app with models now, something far beyond the means of models so long ago.
        otabdeveloper4 1y ago
        > caveats and weasel words > "benchmarks" Stop drinking the coolaid and making excuses for LLM limitations, and learn to use the tools properly given their limits instead.
subarctic 1y 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 as they can just run whatever command you tell them to check for issues and/or fix them if possible.
- arduanika 1y ago
  I believe you that these tools help a lot, but they would not prevent ~any of the examples listed in the article (under "The smell of vibe coding").
  - dkdbejwi383 1y ago
    With cursor at least it recognises linter errors and failing tests and attempts to correct its own problems, with varying levels of success
  - Cthulhu_ 1y ago
    Probably not, but that's where code review comes in. Which can also partially be done by AI, ironically.
  - helloplanets 1y ago
    Most of those look like context issues to me. Repo map (using Tree-sitter, etc) and documentation would already do wonders. Feeding 32-64kTok of context directly into a model like Gemini Pro 2.5 is something that more people should try out in situations like this. Or even 128kTok+.
- antihero 1y ago
  This just masks the problem.
raggi 1y ago
This is a story of a bad LLM user (in this context), which is perhaps implied by “vibe coding” but folks should be aiming higher. Making people review slop is lazy, rude and disrespectful.
- QuantumNoodle 1y ago
  You just claimed reviewing slop is not pleasant (and I agree). So the LLM user has to review the slop, and then the team has to review the iterated-until-not-slop final commit(s). Where in this scenario does anyone _write_ code - the most enjoyable part of the job? Job satisfaction is going to plummet (mine has) and the next generation of software engs is going to be incompetent. Just look at the generation that grew up with ipads/phones. Many of them do not know what a "file" is in college (source, colleagues who are professors).
Zanfa 1y ago
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 example, even if LLMs pick up a pattern to follow (which they often don't), it's a coin flip whether they pick the right one or not.
- anshumankmr 1y ago
  That would assume a commit message is implemented correctly, and isn't like "Updated this file" or "Bugfix"
  - wldlyinaccurate 1y ago
    I think the parent comment means "commits" in the sense of the actual changeset; not just the message.
    - anshumankmr 1y ago
      That is also problematic, cause a git diff will probably require an exponential gain in context length AND also the ability for the LLM to use said context effectively. That being said, a context length problem could be potentially be solved but it will take a bit of time, I think Llama4 had 10M context length (not sure if anyone tried prompting it with that much data to see how effective it really is)
      - tayo42 1y ago
        Do all of the diffs need to be included? Can't you include like a summarized version of a few changes? Like I don't memorize the last 20 commits, but I know generally the direction things are going by reading those commits at some point
        1y ago
occz 1y 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.
- guappa 1y ago
  What productivity gains? https://hackaday.com/2025/07/11/measuring-the-impact-of-llms-on-experienced-developer-productivity/ https://hackaday.com/2025/07/11/measuring-the-impact-of-llms...
thenoblesunfish 1y ago
The author is undermining their own point by calling the vibe code "maintainable", when the whole point of the post is that it's not.
- manmal 1y ago
  The main gripe seems to be duplication of semantics across the codebase, and loss of centralized configurability. Makes sense, since LLMs can’t fit a whole codebase into their context and are not aware of shared behavior unless you tell them it exists.
kazinator 1y ago
> I don’t care how the code got in your IDE. The legal department may have a different idea there.
palata 1y ago
A risk with vibe coding is that it may make a good developer slightly faster, but it will make bad developers waaaay faster. Resulting in more bad code being produced. The question then is: do the bad developers improve by vibe coding, or are they stuck in a local optimum?
- woolion 1y ago
  So, I was wondering when I would see that... from my experience, I would say it also makes mediocre developers bad ones very fast. The reason being a false sense of confidence, but mostly it's because of the sheer volume that is produced. If we want to be more precise, I think the main issue is that the AI-generated code lacks a clear architecture. It has no (or very little) respect for overall information flow, and single-responsibility principle. Since the AI wants you to have "safe" code, so it will catch things and return non-results instead. In practice, that means the calling code has to inspect the result to see if it's a placeholder or not, instead of being confident because you'd get an exception otherwise. Similarly, to avoid problems the AI might tweak some parameter. If for example you were to design an program to process something with AI, you might to gather_parameters -> call -> process_results. Call should not try to do funky things with parameters because that should be fixed at the gathering step. But locally the AI is always going to suggest having a bunch of "if this parameter is not good, swap it silently so that it can go through anyway". Then tests are such a problem it would require an even longer explanation...
  - palata 1y ago
    To echo the article, I don't want to know it was written with an AI. Just like I don't want to see that it was obviously copy-pasted from StackOverflow. The developer can do whatever they want, but at the end, what I review is their code. If that code is bad, it is the developer's responsibility. No amount of "the agent did it" matters to me. If the code written by the agent requires heavy refactoring, then the developer has to do it, period.
    - woolion 1y ago
      100% agree. However, you'll probably get an angry answer that it's management fault, or something of the sort, that is to blame (because there isn't enough time). Responsibility would have to be taken up before in pushing back if some objectives truly are not reasonable.
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.
nojs 1y ago
In my experience pretty much all of these issues stem from a combination of short context windows and suboptimal “context engineering”. If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. The biggest challenge is how to construct the right context for each request, and keep it clean until the feature is finished. I expect we will see a lot of improvements in this area the coming months (sub-agents being an obvious example).
- frizlab 1y ago
  > If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. STOP! The agent does not exist. There are no agents; only mathematical functions that have an input and produce an output. Stop anthropomorphizing LLMs, they are not human, they don’t do anything. It might seem like it does not matter; my take is it’s primordial. Humans are not machines and vice-versa.
  - Sebalf 1y ago
    Frankly, this take is so reductionistic that it's useless. You can substitute "mathematical functions" with "biochemistry" and apply the exact same argument to human beings. What I'd like is for people to stop pretending we have any idea what the hidden layer of an LLM is actually doing. We do not know at all. Yes, words like "statistics" and "mathematical functions" can accurately describe the underlying architecture of LLMs, but the actual mechanism of knowledge processing is not understood at all. It is exactly analogous to how we understand quite a lot about how neurons function at the cellular level (but far from everything, seeing as how complicated and opaque nature tends to be), but that we have no idea whatsoever what exactly is happening when a human being is doing a cognitive task. It is a fallacy to confuse the surface level understanding of how a transformer functions, to the unknown mechanisms that LLMs employ.
  - johnisgood 1y ago
    We have used the term "agent" in AI for some time. > The main unifying theme is the idea of an intelligent agent. We define AI as the study of agents that receive percepts from the environment and perform actions. This is from Artificial Intelligence: A Modern Approach by Stuart J. Russell and Peter Norvig.
buserror 1y ago
I personally treat the LLM as a very junior programmer. He's willing to work, will take instructions, but his knowledge of the codebase, and patterns we use is lacking strongly. So it needs a LOT of handholding, very clear instructions, description of potential pitfalls, and smaller, scoped tasks, and reviewed carefully to catch any straying off pattern. Also, I make it work the same way I do: I first come up with the data model until it "works" in my head, before writing any "code" to deal with it. Again, clear instructions. Oh another thing, one of my "golden rule" is that it needs to keep a block comment at the top of the file to describe what's going on in that file. It acts as a second "prompt" when I restart a session. It works pretty well, it doesn't appear as "magic" as the "make it so!" approach people think they can get away with, but it works for me. But yes, I still also spend maybe 30% of the time cleaning up, renaming stuff and do more general rework of the code before it comes "presentable" but it still allows to work pretty quickly, a lot quicker than if I were to do it all by hand.
- _def 1y ago
  I agree. Brings me to the question though, how to deal with team members that are less experienced and use LLMs. Code review needs much more work then to teach these principles. And most of the time people won't bother to do that and just rubber stamp the working solution.
  - buserror 1y ago
    In my experience, this is a problem without LLM anyway; many times you cannot just tell coworkers (junior, or not) to completely trash their patch and do it again (even using nicer words). Very often it comes down to HR issues in the end, so you end up having to take that code anyway, and either sneakily revert it or secretly rework it...
- pulse7 1y ago
  The difference between LLM and a very junior programmer: junior programmer will learn and change, LLM won't change! The more instructions you put in the prompt, the more will be forgotten and the more it will bounce back to the "general world-wide average". And on next prompt you must start all over again... Not so with junior programmers ...
globular-toast 1y ago
This matches my experience. And I do mind the unnecessary comments. I always tell juniors that every line is important and the presence of a comment is a powerful tool for communicating with future developers. Think of it like labelling circuits on a fusebox. Now these garbage code generators are putting comments on everything because they don't understand anything and can't tell what it's redundant. But this is only scratching the surface of what's wrong, as the article elaborates. The thing is people claim these things are making them faster. I don't believe it. What I believe is they are faster at generating shit. I know that because a baby can coax an LLM into producing shit too. I do not believe you can spend that much time writing the correct prompt - use this exact function, follow this pattern, add a comment here, don't add one there, no, not like that - and still be quicker than just writing it yourself directly in the language. It's like if I speak French fluently but only communicate through a translator that I instruct in English but constantly have to correct when they miss the nuance in my speech. I'd just speak French! So, no, I don't believe it. What I believe is that many, many software developers have been manually writing boilerplate, repetitive and boring code over and over again up until this point. I believe it because I've seen it. LLMs will obviously speed this up. But some of us already learnt how to use the computer to do that for us. What I also believe is developers exist who don't understand, or care to understand, what they are doing. They will code using a trial and error approach and find solutions based purely on perceived behaviour of the software. I believe it because I've seen it. Of course LLMs will speed up this process. But some of us actually think about what we're writing, just like we don't just randomly string together words in a restaurant and then just keep trying until we get the dish we want.
chilldsgn 1y ago
heck, I'm sitting in a team with a code base so full of slop that was written by humans, the AI can't even fix it and I'm burned out from trying to make it better. and I get told to be quiet about code standards because the team is still learning.
- scrapheap 1y ago
  I hope you responded with "The team is still learning, which is exactly why I shouldn't be quiet about code standards."
  - chilldsgn 1y ago
    I wish I did, what a great response.
imiric 1y ago
> I want people to care about quality, I want them to care about consistency, I want them to care about the long-term effects of their work. Yeah, that's not happening. LLMs enable masses of non-technical people to create and publish software. They enable scammers and grifters who previously would've used a web site builder to also publish native and mobile apps, all in a fraction of the time and effort previously required. They enable experienced software developers to cut corners and automate parts of the job they never enjoyed to begin with. It's remarkable to me that many people who have been working in this industry for years don't enjoy the process of creating software, and find many tasks to be a "chore". A small part of this group can't identify quality even if they cared about it. The rest simply doesn't care, and never will. Their priorities are to produce something that works on the surface with the least amount of effort, or, in the case of scammers, to produce whatever can bring them the most revenue as quickly and cheaply as possible. LLMs are a perfect fit for both use cases. Software developers who care about quality are now even a smaller minority than before. They can also find LLMs to be useful, but not the magical productivity booster that everyone else is so excited about. If anything their work has become more difficult, since they now need to review the mountains of code thrown at them. Producing thousands of lines of code is easy. Ensuring it's high quality is much more difficult.
agile-gift0262 1y ago
I don't think that it's people no caring. I think many (most?) of us are biased to accept what we already have that's working. I noticed that of myself when I tried programming with an LLM "agent". After all the fuzzing around, many iterations of novels I had to write as many prompts, once the LLM produced something that worked, I had to fight with my instinct of just pushing that for review. I also noticed that the time I had to spend on reviews from some of my colleagues increased by 9 times (time tracked). So I don't know how much faster they are being at producing that code, but I think it's taking longer overall to get that ticket closed.
nesk_ 1y ago
> we still need to build software, not productionize prototypes. Can't agree more.
deleted 1y ago
[deleted]
philipp-gayret 1y ago
All major AI assistants already come with ways to not have any of these issues. Claude Code has /init, Cursor comes with /Generate Cursor Rules, and so on. It's not even context engineering: There are out of the box tools you can use not to have this happen. And even if they do happen: you can make them never happen again, with these same tools, for your entire organization - if you had invested the time to know how to use them. It is interesting how these tools split up the development community.
- croes 1y ago
  The issue isn’t in the tool but in the vibe „coder“. They care like they code: not.
- woolion 1y ago
  Serious question: I'm currently re-evaluating if Cursor can speed up my daily work. Currently it is not really the case because of the many subtle errors (like switching a ":" for a ","). But mostly the problem I face is that the code base is big, with entirely outdated parts and poorly coded ones. So the AI favors the most common patterns, which are the bad ones. Even with basic instructions like "take inspiration from <part of the code that is very similar and well-written>" it still mostly takes from the overall codebase (which, by the way, was worsened by a big chunk of vibe-coded output that was hastily merged). My understanding is that a rule should essentially do the same as if it is put in the prompt directly. Is there a solution to that?
  - philipp-gayret 1y ago
    I recently switched to Claude Code, I much prefer it (I end up less in cycles of Cursor getting stuck on problems). Before I used Cursor for some months. > My understanding is that a rule should essentially do the same as if it is put in the prompt directly. Is there a solution to that? Yes from my understanding Cursor Rule files are essentially an invisible prefix to every prompt. I had some issues in the past with Cursor not picking up rule files until I restarted it (some glitch, probably gone by now.). So put something simple like a "version" or for your rules file and ask it what version of the rules are we following for this conversation just to validate that the process is working. For Cursor with larger projects I use a set of larger rule files that always apply. Recently I worked with Spotify's Backstage for example and I had it index online documentation on architecture, build instructions, design, development of certain components, project layout. Easily 500+ lines worth of markdown. I tell Cursor where to look, i.e. online documentation of the libraries you use, reference implementations if you have any, good code examples and why they are good, and then it writes its own rule files - I don't write them manually anymore. That has been working really well for me. If you have a common technology stack you or way of working you can also try throwing in some examples from https://github.com/PatrickJS/awesome-cursorrules https://github.com/PatrickJS/awesome-cursorrules For a codebase containing both good and bad code; maybe you can point it to a past change where code was refactored from bad to good, so it can write out what why you prefer which style and how to manage the migration from bad to good. That said; the tools are not perfect. Even with rules the bad output still can happen but larger rule files describing what you'd like to do and what to avoid makes the chance significantly smaller and the tool more pleasant to work with. I recently switched to Claude Code because Cursor tended to get "stuck" on the same problem which I don't really experience with Claude Code but YMMV.
scotty79 1y ago
> I know the code was generated because it was written in a way no developer on the team would. > It works, it’s clear, it’s tested, and it’s maintainable. It would be super funny if he ended his blogpost there.
clauderoux 1y ago
I love how so many people are eager to criticize LLM code, when in fact, according to my experience it is pretty superior to anything I have seen produced by human programmers, most of the time. It is documented, the code is explained at each step of its creation, and it is pretty readable when you dig into it. I have 30 years of experience in coding, and I have been playing with these LLM for 3 years. Yeah!!! Of course, sometimes they produce very bad code. But in average, the code they produce is largely on par with my fellow humans. And since, they produce the whole explanation of it, it takes a couple of minutes to understand it. And if you don't understand the main points of the code, the LLM will tell you all about it. When did you have a colleague that was eager to explain his/her code to you??? When did you have a colleague that did produce a code you could understand in a few minute??? I really think these tools are quite useful, no need to wrap yourself into the mantel of expertise and look down on these LLM, because sometimes they will produce a code you don't like.
grim_io 1y ago
These problems read like they are a product of outdated ai assisted practices. I can imagine stuff like this happening when copy pasting from/to ai online chat interfaces, but not in a properly initialized project. The agent will read all the crappy, partly outdated documentation all over the project and also take the reality of the project into consideration. It's probably a good idea to also let it rewrite the programmer facing docs. Who else is going to maintain that realistically?
bubblyworld 1y ago
Personally I think caring is the resource in extremely short supply here and I don't think vibe coding has much to do with it causally. AIs are just tools - basically all of the issues the author has raised are present with human juniors too, and can be resolved quite easily with a little more guidance/interaction in both cases. I don't think AIs are universally causing people to care less about quality output, although that may be true for some people who didn't care much in the first place. The common counter-argument here is that you miss out on training juniors, which is true, but it's not always an option (we are really struggling to hire at my startup, for instance, so I'm experimenting with AI to work on tasks I would otherwise give to a junior as a stop-gap). Another aspect to consider is that what we used to consider important for software quality may change a lot in light of AI tooling. These things aren't absolutes. I think this is already happening, but it's early days, so I'm not sure what will play out here.
raduan 1y ago
I think people should care more about the adherence of code to a specific spec. And by definition of this, you should care about the spec. How code looks like, doesn't matter that much, as long it adheres to the spec.
lvturner 1y ago
I want to care, but I also want money to eat, and the guy that isn't caring and doing a fifth as much work as me, is making more than me and getting promoted ahead of me. Welcome to enterprise, it's not shit because people don't care. People don't care because they are incentivised not to, and those that do care, burn out.
dankobgd 1y ago
nobody cares about anything in this industry
jongjong 1y ago
I like vibe coding. I've always hated bloated code bases with too many files, too many unnecessary abstractions, too many unnecessary utility functions... The AI is now dishing out punishment; giving people a taste of their own medicine. Complex codebases lead to complex buggy LLM code completions. If I come across a fugly code base, I don't bother reading it, I just ask Claude what it's doing and I ask Claude to fix it. To me this is a huge advantage because my OCD prevented me from producing fugly code by hand but now I wield Claude like an automatic complexity gun. Producing that kind of complexity when you know there exists a simpler way is demoralizing, but it's not demoralizing when an LLM does it because it's so low effort. I just hated thinking about all this mind-numbing nonsense.
amelius 1y ago
From keyboard sound I can tell the difference between my colleague typing code and him typing prose. Since AI he is typing more prose.
CompoundEyes 1y ago
I’ve been working with Claude Code subagents for the first time this week and I have one that purposefully goes through code analyzing it for human maintainability, over-architecting, too many clever one liner tricks, meaningful variable names, ease of debugging, cognitive load, class sizes and so on. It had some interesting analysis about a few of the classes being heavy in requiring domain knowledge and suggested documentation / onboarding for that particular area. I’m interested to see where this goes. The code will be in production this aspect is important to me. Gold plating is in reach with LLMs why not?
mns 1y ago
> But people want a good cup of coffee, even if they have to wait a little bit for it. I think the author is vastly underestimating what the majority of people actually want. It took me a lot to get this, but for many people, quick/cheap will always trump quality.
- 0_____0 1y ago
  the ubiquity of keurig machines really does speak to this.
sreekanth850 1y ago
You can provide proper context, what is required, what is not required, patterns, structure, and ask to add comments too. So its not about vibe coding, its about common sense and involvement.
pinoy420 1y ago
[dead]
Kim_Bruning 1y ago
You can take my "EngliSH"[1] when you pry it from my cold dead hands. But just because it's a powerful way to work, doesn't mean you get to be irresponsible with it! (Quite the opposite: Think table-saw) [1] English SHell (Claude Code in my case), who says I need to be Bourne Again?
lofaszvanitt 1y ago
The article has the unique linkedin smell to it.
ok123456 1y ago
> No one would write a class when we’re using a functional approach everywhere. They're not orthogonal. Closures and classes are dual forms of the same thing. There are cases where one is better than the other for a given problem.
ashutosh-mishra 1y ago
You can generate code without understanding it, but you can't generate judgment, taste, or the kind of long-term thinking that prevents technical debt from metastasizing. Those come from giving a shit about the work itself, not just shipping it.
_iobt 1y ago
I know human coders who do all of things with or without AI. Everyone's output has increased but tendencies still depend on the operator.
Chinwe888 1y ago
[dead]
8thcross 1y ago
Once you on it, you are hooked bru.

353 points by thunderbong 1y ago

I think this should be renamed "I know when you're vibe coding with a last generation LLM". Claude 4 Opus would not make any of the mistakes mentioned, because it knows and understands everything in your codebase. It would know when there's an existing utility function for that particular task, or that you prefer a functional rather than OOP approach. You say you want developers to care about the code they write, well, this is the next best thing; I believe it's as close as we'll see to a machine being able to "care" in my lifetime.

parpfish 1y ago

> No one would write a class when we’re using a functional approach everywhere. do people really think functional coding shouldn't involve writing classes? i can't imagine writing what i think of as code in a "functional programming style" without tons of dataclasses to describe different immutable records that get passed around. and if you're feeling fancy, add some custom constructors to those dataclasses for easy type conversions.

bublyboi 1y ago
I think he’s referring to classes vs functions in React
williamstein 1y ago
In the context of react codebases, people typically use either functional components everywhere or class components. Mixing the two approaches is frustrating and painful, eg you can’t use any of the hooks in your codebase in a class component. Perhaps the OP was talking about this, but just being really vague.

atleastoptimal 1y ago

This is all true. The best way to treat LLM's as they are now is one step above the abstraction offered by compiled languages over assembly. You can describe something in plain english, note its explicit requirements, inputs and outputs, and an LLM can effectively write the code as a translation of the logic you are specifying. Using LLM's, you are best served minimizing the entropy they have to deal with. The transformer is essentially a translation engine, so use it as a translator, not as a generator. That being said, every few months a new model comes out that is a little less encumbered by the typical flaws of LLM's, a little more "intuitively" smart and less needing of hand-holding, a little more reliable. I feel that this is simply a natural course of evolution, as more money is put into LLM's they get better because they're essentially a giant association machine, and those associations give rise to larger abstractions, more robust conceptions of how to wield the tools of understanding the world, etc. Over time it seems inevitable that providing an LLM any task it will be able to perform that task better than any human programmer given it, and the same will go for the rest of what humans do.

voxl 1y ago
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 Internet and are still useless. Where the fuck is the rest of the data going to come from? All these emails from people wanting high quality data from PhDs only for them to be scammy. People only want to train these things on easily stolen garbage, not quality input, because quality is expensive. Go figure! This optimistic horeshit hype is embarrassing.
- atleastoptimal 1y ago
  >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.
  - otabdeveloper4 1y ago
    No they haven't. The hallucinate exactly as much as they did five years ago.
    - atleastoptimal 1y ago
      Absolutely untrue. Claiming GPT-3 hallucinates as much as o3 over the same token horizon on the same prompts is a silly notion and easily disproven by the dozens of benchmarks. You can code a complete web-app with models now, something far beyond the means of models so long ago.
      - otabdeveloper4 1y ago
        > caveats and weasel words > "benchmarks" Stop drinking the coolaid and making excuses for LLM limitations, and learn to use the tools properly given their limits instead.

subarctic 1y 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 as they can just run whatever command you tell them to check for issues and/or fix them if possible.

arduanika 1y ago
I believe you that these tools help a lot, but they would not prevent ~any of the examples listed in the article (under "The smell of vibe coding").
- dkdbejwi383 1y ago
  With cursor at least it recognises linter errors and failing tests and attempts to correct its own problems, with varying levels of success
- Cthulhu_ 1y ago
  Probably not, but that's where code review comes in. Which can also partially be done by AI, ironically.
- helloplanets 1y ago
  Most of those look like context issues to me. Repo map (using Tree-sitter, etc) and documentation would already do wonders. Feeding 32-64kTok of context directly into a model like Gemini Pro 2.5 is something that more people should try out in situations like this. Or even 128kTok+.
antihero 1y ago
This just masks the problem.

raggi 1y ago

This is a story of a bad LLM user (in this context), which is perhaps implied by “vibe coding” but folks should be aiming higher. Making people review slop is lazy, rude and disrespectful.

QuantumNoodle 1y ago
You just claimed reviewing slop is not pleasant (and I agree). So the LLM user has to review the slop, and then the team has to review the iterated-until-not-slop final commit(s). Where in this scenario does anyone _write_ code - the most enjoyable part of the job? Job satisfaction is going to plummet (mine has) and the next generation of software engs is going to be incompetent. Just look at the generation that grew up with ipads/phones. Many of them do not know what a "file" is in college (source, colleagues who are professors).

Zanfa 1y ago

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 example, even if LLMs pick up a pattern to follow (which they often don't), it's a coin flip whether they pick the right one or not.

anshumankmr 1y ago
That would assume a commit message is implemented correctly, and isn't like "Updated this file" or "Bugfix"
- wldlyinaccurate 1y ago
  I think the parent comment means "commits" in the sense of the actual changeset; not just the message.
  - anshumankmr 1y ago
    That is also problematic, cause a git diff will probably require an exponential gain in context length AND also the ability for the LLM to use said context effectively. That being said, a context length problem could be potentially be solved but it will take a bit of time, I think Llama4 had 10M context length (not sure if anyone tried prompting it with that much data to see how effective it really is)
    - tayo42 1y ago
      Do all of the diffs need to be included? Can't you include like a summarized version of a few changes? Like I don't memorize the last 20 commits, but I know generally the direction things are going by reading those commits at some point
      - 1y ago

occz 1y 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.

guappa 1y ago
What productivity gains? https://hackaday.com/2025/07/11/measuring-the-impact-of-llms-on-experienced-developer-productivity/ https://hackaday.com/2025/07/11/measuring-the-impact-of-llms...

thenoblesunfish 1y ago

The author is undermining their own point by calling the vibe code "maintainable", when the whole point of the post is that it's not.

manmal 1y ago
The main gripe seems to be duplication of semantics across the codebase, and loss of centralized configurability. Makes sense, since LLMs can’t fit a whole codebase into their context and are not aware of shared behavior unless you tell them it exists.

kazinator 1y ago

> I don’t care how the code got in your IDE. The legal department may have a different idea there.

palata 1y ago

A risk with vibe coding is that it may make a good developer slightly faster, but it will make bad developers waaaay faster. Resulting in more bad code being produced. The question then is: do the bad developers improve by vibe coding, or are they stuck in a local optimum?

woolion 1y ago
So, I was wondering when I would see that... from my experience, I would say it also makes mediocre developers bad ones very fast. The reason being a false sense of confidence, but mostly it's because of the sheer volume that is produced. If we want to be more precise, I think the main issue is that the AI-generated code lacks a clear architecture. It has no (or very little) respect for overall information flow, and single-responsibility principle. Since the AI wants you to have "safe" code, so it will catch things and return non-results instead. In practice, that means the calling code has to inspect the result to see if it's a placeholder or not, instead of being confident because you'd get an exception otherwise. Similarly, to avoid problems the AI might tweak some parameter. If for example you were to design an program to process something with AI, you might to gather_parameters -> call -> process_results. Call should not try to do funky things with parameters because that should be fixed at the gathering step. But locally the AI is always going to suggest having a bunch of "if this parameter is not good, swap it silently so that it can go through anyway". Then tests are such a problem it would require an even longer explanation...
- palata 1y ago
  To echo the article, I don't want to know it was written with an AI. Just like I don't want to see that it was obviously copy-pasted from StackOverflow. The developer can do whatever they want, but at the end, what I review is their code. If that code is bad, it is the developer's responsibility. No amount of "the agent did it" matters to me. If the code written by the agent requires heavy refactoring, then the developer has to do it, period.
  - woolion 1y ago
    100% agree. However, you'll probably get an angry answer that it's management fault, or something of the sort, that is to blame (because there isn't enough time). Responsibility would have to be taken up before in pushing back if some objectives truly are not reasonable.

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.

nojs 1y ago

In my experience pretty much all of these issues stem from a combination of short context windows and suboptimal “context engineering”. If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. The biggest challenge is how to construct the right context for each request, and keep it clean until the feature is finished. I expect we will see a lot of improvements in this area the coming months (sub-agents being an obvious example).

frizlab 1y ago
> If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. STOP! The agent does not exist. There are no agents; only mathematical functions that have an input and produce an output. Stop anthropomorphizing LLMs, they are not human, they don’t do anything. It might seem like it does not matter; my take is it’s primordial. Humans are not machines and vice-versa.
- Sebalf 1y ago
  Frankly, this take is so reductionistic that it's useless. You can substitute "mathematical functions" with "biochemistry" and apply the exact same argument to human beings. What I'd like is for people to stop pretending we have any idea what the hidden layer of an LLM is actually doing. We do not know at all. Yes, words like "statistics" and "mathematical functions" can accurately describe the underlying architecture of LLMs, but the actual mechanism of knowledge processing is not understood at all. It is exactly analogous to how we understand quite a lot about how neurons function at the cellular level (but far from everything, seeing as how complicated and opaque nature tends to be), but that we have no idea whatsoever what exactly is happening when a human being is doing a cognitive task. It is a fallacy to confuse the surface level understanding of how a transformer functions, to the unknown mechanisms that LLMs employ.
- johnisgood 1y ago
  We have used the term "agent" in AI for some time. > The main unifying theme is the idea of an intelligent agent. We define AI as the study of agents that receive percepts from the environment and perform actions. This is from Artificial Intelligence: A Modern Approach by Stuart J. Russell and Peter Norvig.

buserror 1y ago

I personally treat the LLM as a very junior programmer. He's willing to work, will take instructions, but his knowledge of the codebase, and patterns we use is lacking strongly. So it needs a LOT of handholding, very clear instructions, description of potential pitfalls, and smaller, scoped tasks, and reviewed carefully to catch any straying off pattern. Also, I make it work the same way I do: I first come up with the data model until it "works" in my head, before writing any "code" to deal with it. Again, clear instructions. Oh another thing, one of my "golden rule" is that it needs to keep a block comment at the top of the file to describe what's going on in that file. It acts as a second "prompt" when I restart a session. It works pretty well, it doesn't appear as "magic" as the "make it so!" approach people think they can get away with, but it works for me. But yes, I still also spend maybe 30% of the time cleaning up, renaming stuff and do more general rework of the code before it comes "presentable" but it still allows to work pretty quickly, a lot quicker than if I were to do it all by hand.

_def 1y ago
I agree. Brings me to the question though, how to deal with team members that are less experienced and use LLMs. Code review needs much more work then to teach these principles. And most of the time people won't bother to do that and just rubber stamp the working solution.
- buserror 1y ago
  In my experience, this is a problem without LLM anyway; many times you cannot just tell coworkers (junior, or not) to completely trash their patch and do it again (even using nicer words). Very often it comes down to HR issues in the end, so you end up having to take that code anyway, and either sneakily revert it or secretly rework it...
pulse7 1y ago
The difference between LLM and a very junior programmer: junior programmer will learn and change, LLM won't change! The more instructions you put in the prompt, the more will be forgotten and the more it will bounce back to the "general world-wide average". And on next prompt you must start all over again... Not so with junior programmers ...

globular-toast 1y ago

This matches my experience. And I do mind the unnecessary comments. I always tell juniors that every line is important and the presence of a comment is a powerful tool for communicating with future developers. Think of it like labelling circuits on a fusebox. Now these garbage code generators are putting comments on everything because they don't understand anything and can't tell what it's redundant. But this is only scratching the surface of what's wrong, as the article elaborates. The thing is people claim these things are making them faster. I don't believe it. What I believe is they are faster at generating shit. I know that because a baby can coax an LLM into producing shit too. I do not believe you can spend that much time writing the correct prompt - use this exact function, follow this pattern, add a comment here, don't add one there, no, not like that - and still be quicker than just writing it yourself directly in the language. It's like if I speak French fluently but only communicate through a translator that I instruct in English but constantly have to correct when they miss the nuance in my speech. I'd just speak French! So, no, I don't believe it. What I believe is that many, many software developers have been manually writing boilerplate, repetitive and boring code over and over again up until this point. I believe it because I've seen it. LLMs will obviously speed this up. But some of us already learnt how to use the computer to do that for us. What I also believe is developers exist who don't understand, or care to understand, what they are doing. They will code using a trial and error approach and find solutions based purely on perceived behaviour of the software. I believe it because I've seen it. Of course LLMs will speed up this process. But some of us actually think about what we're writing, just like we don't just randomly string together words in a restaurant and then just keep trying until we get the dish we want.

chilldsgn 1y ago

heck, I'm sitting in a team with a code base so full of slop that was written by humans, the AI can't even fix it and I'm burned out from trying to make it better. and I get told to be quiet about code standards because the team is still learning.

scrapheap 1y ago
I hope you responded with "The team is still learning, which is exactly why I shouldn't be quiet about code standards."
- chilldsgn 1y ago
  I wish I did, what a great response.

imiric 1y ago

> I want people to care about quality, I want them to care about consistency, I want them to care about the long-term effects of their work. Yeah, that's not happening. LLMs enable masses of non-technical people to create and publish software. They enable scammers and grifters who previously would've used a web site builder to also publish native and mobile apps, all in a fraction of the time and effort previously required. They enable experienced software developers to cut corners and automate parts of the job they never enjoyed to begin with. It's remarkable to me that many people who have been working in this industry for years don't enjoy the process of creating software, and find many tasks to be a "chore". A small part of this group can't identify quality even if they cared about it. The rest simply doesn't care, and never will. Their priorities are to produce something that works on the surface with the least amount of effort, or, in the case of scammers, to produce whatever can bring them the most revenue as quickly and cheaply as possible. LLMs are a perfect fit for both use cases. Software developers who care about quality are now even a smaller minority than before. They can also find LLMs to be useful, but not the magical productivity booster that everyone else is so excited about. If anything their work has become more difficult, since they now need to review the mountains of code thrown at them. Producing thousands of lines of code is easy. Ensuring it's high quality is much more difficult.

agile-gift0262 1y ago

I don't think that it's people no caring. I think many (most?) of us are biased to accept what we already have that's working. I noticed that of myself when I tried programming with an LLM "agent". After all the fuzzing around, many iterations of novels I had to write as many prompts, once the LLM produced something that worked, I had to fight with my instinct of just pushing that for review. I also noticed that the time I had to spend on reviews from some of my colleagues increased by 9 times (time tracked). So I don't know how much faster they are being at producing that code, but I think it's taking longer overall to get that ticket closed.

nesk_ 1y ago

> we still need to build software, not productionize prototypes. Can't agree more.

deleted 1y ago

[deleted]

philipp-gayret 1y ago

All major AI assistants already come with ways to not have any of these issues. Claude Code has /init, Cursor comes with /Generate Cursor Rules, and so on. It's not even context engineering: There are out of the box tools you can use not to have this happen. And even if they do happen: you can make them never happen again, with these same tools, for your entire organization - if you had invested the time to know how to use them. It is interesting how these tools split up the development community.

croes 1y ago
The issue isn’t in the tool but in the vibe „coder“. They care like they code: not.
woolion 1y ago
Serious question: I'm currently re-evaluating if Cursor can speed up my daily work. Currently it is not really the case because of the many subtle errors (like switching a ":" for a ","). But mostly the problem I face is that the code base is big, with entirely outdated parts and poorly coded ones. So the AI favors the most common patterns, which are the bad ones. Even with basic instructions like "take inspiration from <part of the code that is very similar and well-written>" it still mostly takes from the overall codebase (which, by the way, was worsened by a big chunk of vibe-coded output that was hastily merged). My understanding is that a rule should essentially do the same as if it is put in the prompt directly. Is there a solution to that?
- philipp-gayret 1y ago
  I recently switched to Claude Code, I much prefer it (I end up less in cycles of Cursor getting stuck on problems). Before I used Cursor for some months. > My understanding is that a rule should essentially do the same as if it is put in the prompt directly. Is there a solution to that? Yes from my understanding Cursor Rule files are essentially an invisible prefix to every prompt. I had some issues in the past with Cursor not picking up rule files until I restarted it (some glitch, probably gone by now.). So put something simple like a "version" or for your rules file and ask it what version of the rules are we following for this conversation just to validate that the process is working. For Cursor with larger projects I use a set of larger rule files that always apply. Recently I worked with Spotify's Backstage for example and I had it index online documentation on architecture, build instructions, design, development of certain components, project layout. Easily 500+ lines worth of markdown. I tell Cursor where to look, i.e. online documentation of the libraries you use, reference implementations if you have any, good code examples and why they are good, and then it writes its own rule files - I don't write them manually anymore. That has been working really well for me. If you have a common technology stack you or way of working you can also try throwing in some examples from https://github.com/PatrickJS/awesome-cursorrules https://github.com/PatrickJS/awesome-cursorrules For a codebase containing both good and bad code; maybe you can point it to a past change where code was refactored from bad to good, so it can write out what why you prefer which style and how to manage the migration from bad to good. That said; the tools are not perfect. Even with rules the bad output still can happen but larger rule files describing what you'd like to do and what to avoid makes the chance significantly smaller and the tool more pleasant to work with. I recently switched to Claude Code because Cursor tended to get "stuck" on the same problem which I don't really experience with Claude Code but YMMV.

scotty79 1y ago

> I know the code was generated because it was written in a way no developer on the team would. > It works, it’s clear, it’s tested, and it’s maintainable. It would be super funny if he ended his blogpost there.

clauderoux 1y ago

I love how so many people are eager to criticize LLM code, when in fact, according to my experience it is pretty superior to anything I have seen produced by human programmers, most of the time. It is documented, the code is explained at each step of its creation, and it is pretty readable when you dig into it. I have 30 years of experience in coding, and I have been playing with these LLM for 3 years. Yeah!!! Of course, sometimes they produce very bad code. But in average, the code they produce is largely on par with my fellow humans. And since, they produce the whole explanation of it, it takes a couple of minutes to understand it. And if you don't understand the main points of the code, the LLM will tell you all about it. When did you have a colleague that was eager to explain his/her code to you??? When did you have a colleague that did produce a code you could understand in a few minute??? I really think these tools are quite useful, no need to wrap yourself into the mantel of expertise and look down on these LLM, because sometimes they will produce a code you don't like.

grim_io 1y ago

These problems read like they are a product of outdated ai assisted practices. I can imagine stuff like this happening when copy pasting from/to ai online chat interfaces, but not in a properly initialized project. The agent will read all the crappy, partly outdated documentation all over the project and also take the reality of the project into consideration. It's probably a good idea to also let it rewrite the programmer facing docs. Who else is going to maintain that realistically?

bubblyworld 1y ago

Personally I think caring is the resource in extremely short supply here and I don't think vibe coding has much to do with it causally. AIs are just tools - basically all of the issues the author has raised are present with human juniors too, and can be resolved quite easily with a little more guidance/interaction in both cases. I don't think AIs are universally causing people to care less about quality output, although that may be true for some people who didn't care much in the first place. The common counter-argument here is that you miss out on training juniors, which is true, but it's not always an option (we are really struggling to hire at my startup, for instance, so I'm experimenting with AI to work on tasks I would otherwise give to a junior as a stop-gap). Another aspect to consider is that what we used to consider important for software quality may change a lot in light of AI tooling. These things aren't absolutes. I think this is already happening, but it's early days, so I'm not sure what will play out here.

raduan 1y ago

I think people should care more about the adherence of code to a specific spec. And by definition of this, you should care about the spec. How code looks like, doesn't matter that much, as long it adheres to the spec.

lvturner 1y ago

I want to care, but I also want money to eat, and the guy that isn't caring and doing a fifth as much work as me, is making more than me and getting promoted ahead of me. Welcome to enterprise, it's not shit because people don't care. People don't care because they are incentivised not to, and those that do care, burn out.

dankobgd 1y ago

nobody cares about anything in this industry

jongjong 1y ago

I like vibe coding. I've always hated bloated code bases with too many files, too many unnecessary abstractions, too many unnecessary utility functions... The AI is now dishing out punishment; giving people a taste of their own medicine. Complex codebases lead to complex buggy LLM code completions. If I come across a fugly code base, I don't bother reading it, I just ask Claude what it's doing and I ask Claude to fix it. To me this is a huge advantage because my OCD prevented me from producing fugly code by hand but now I wield Claude like an automatic complexity gun. Producing that kind of complexity when you know there exists a simpler way is demoralizing, but it's not demoralizing when an LLM does it because it's so low effort. I just hated thinking about all this mind-numbing nonsense.

amelius 1y ago

From keyboard sound I can tell the difference between my colleague typing code and him typing prose. Since AI he is typing more prose.

CompoundEyes 1y ago

I’ve been working with Claude Code subagents for the first time this week and I have one that purposefully goes through code analyzing it for human maintainability, over-architecting, too many clever one liner tricks, meaningful variable names, ease of debugging, cognitive load, class sizes and so on. It had some interesting analysis about a few of the classes being heavy in requiring domain knowledge and suggested documentation / onboarding for that particular area. I’m interested to see where this goes. The code will be in production this aspect is important to me. Gold plating is in reach with LLMs why not?

mns 1y ago

> But people want a good cup of coffee, even if they have to wait a little bit for it. I think the author is vastly underestimating what the majority of people actually want. It took me a lot to get this, but for many people, quick/cheap will always trump quality.

0_____0 1y ago
the ubiquity of keurig machines really does speak to this.

sreekanth850 1y ago

You can provide proper context, what is required, what is not required, patterns, structure, and ask to add comments too. So its not about vibe coding, its about common sense and involvement.

pinoy420 1y ago

[dead]

Kim_Bruning 1y ago

You can take my "EngliSH"[1] when you pry it from my cold dead hands. But just because it's a powerful way to work, doesn't mean you get to be irresponsible with it! (Quite the opposite: Think table-saw) [1] English SHell (Claude Code in my case), who says I need to be Bourne Again?

lofaszvanitt 1y ago

The article has the unique linkedin smell to it.

ok123456 1y ago

> No one would write a class when we’re using a functional approach everywhere. They're not orthogonal. Closures and classes are dual forms of the same thing. There are cases where one is better than the other for a given problem.

ashutosh-mishra 1y ago

You can generate code without understanding it, but you can't generate judgment, taste, or the kind of long-term thinking that prevents technical debt from metastasizing. Those come from giving a shit about the work itself, not just shipping it.

_iobt 1y ago

I know human coders who do all of things with or without AI. Everyone's output has increased but tendencies still depend on the operator.

Chinwe888 1y ago

[dead]

8thcross 1y ago

Once you on it, you are hooked bru.