19 ms·

After two years of vibecoding, I'm back to writing by hand

• timcobb 8mo ago
  I'm impressed that this person has been vibecoding longer than vibecoding has been a thing. A real trailblazer!
  • mossTechnician 8mo ago
    GitHub copilot was released in 2021, and Cursor was released around October 2023[0]. [0]: https://news.ycombinator.com/item?id=37888477 https://news.ycombinator.com/item?id=37888477
    • timcobb 8mo ago
      At the earliest, "vibecoding" was only possible with Claude 3.5, released July 2024 ... maaaybe Claude 3, released in March of that year... It's worth mentioning that even today, Copilot is an underwhelming-to-the-point-obstructing kind of product. Microsoft sent salespeople and instructors to my job, all for naught. Copilot is a great example of how product > everything, and if you don't have a good product... well...
      • Mashimo 8mo ago
        Is Claude through Github Copilot THAT much worse? I know there are differences, but I don't find it to be obstructing my vibe coding.
        • timcobb 8mo ago
          I haven't tried it since 9-12 months ago. At the time it was really bad and I had a lot more success copy/pasting from web interfaces. Is it better now? Can you agentic code with it? How's the autocomplete?
          • Mashimo 8mo ago
            Yes, I vibecoded small personal apps from start to finish with it. Planning mode, edit mode, mcp, tool calling, web searches. Can easily switch between Gemini, ChatGPT, Grok or Claude within the same conversation. I think multiple agents work, though not sure. All under one subscription. Does not support upload / reading of PDF files :(
          • the_af 8mo ago
            > Can you agentic code with it? Yes, definitely. I use it mostly in Agent mode, then switch to Ask mode to ask it questions. > How's the autocomplete? It works reasonably well, but I'm less interested in autocomplete.
        • yourapostasy 8mo ago
          In the enterprise deployments of GitHub Copilot I've seen at my clients that authenticate over SSO (typically OIDC with OAuth 2.0), connecting Copilot to anything outside of what Microsoft has integrated means reverse engineering the closed authentication interface. I've yet to run across someone's enterprise Github Copilot where the management and administrators have enabled the integration (the sites have enabled access to Anthropic models within the Copilot interface, but not authorized the integration to Claude Code, Opencode, or similar LLM coding orchestration tooling with that closed authentication interface). While this is likely feasible, I imagine it is also an instant fireable offense at these sites if not already explicitly directed by management. Also not sure how Microsoft would react upon finding out (never seen the enterprise licensing agreement paperwork for these setups). Someone's account driving Claude Code via Github Copilot will also become a far outlier of token consumption by an order(s) of magnitude, making them easy to spot, compared to their coworkers who are limited to the conventional chat and code completion interfaces. If someone has gotten the enterprise Github Copilot integration to work with something like Claude Code though (simply to gain access to the models Copilot makes available under the enterprise agreement, in a blessed golden path by the enterprise), then I'd really like to know how that was done on both the non-technical and technical angles, because when I briefly looked into it all I saw were very thorny, time-consuming issues to untangle. Outside those environments, there are lots of options to consume Claude Code via Github Copilot like with Visual Studio Code extensions. So much smaller companies and individuals seem to be at the forefront of adoption for now. I'm sure this picture will improve, but the rapid rate of change in the field means those whose work environment is like those enterprise constrained ones I described but also who don't experiment on their own will be quite behind the industry leading edge by the time it is all sorted out in the enterprise context.
        • kaydub 8mo ago
          Yes. Copilot sucks. Copilot is like a barely better intellisense/auto-complete, especially when it came out. It was novel and cool back then but it has been vastly surpassed by other tools.
          • Mashimo 8mo ago
            > Copilot is like a barely better intellisense/auto-complete As I have never tried Claude Code, I can't say how much better it is. But Copilot is definitely more then auto-complete. Like I already wrote, it can do Planning mode, edit mode, mcp, tool calling, web searches.
            • the_af 8mo ago
              Yeah, same. I have never tried Claude Code but use Claude through the Copilot plugin, and it's NOT auto-complete. It can analyze and refactor code, write new code, etc.
            • kaydub 8mo ago
              I just feel like using Copilot would be like early car designers trying to steer their new car with reins.
              • Mashimo 8mo ago
                Have you used it recently? Or any specific that caused this feeling
                • kaydub 8mo ago
                  Nope, haven't tried recently because the cli tools were so much better and more powerful I haven't felt like there's a reason to ever go back.
                  • Mashimo 8mo ago
                    Odd to be so confident and outspoken about a product you have not used in a while.
    • deleted 8mo ago
      [deleted]
    • vincentkriek 8mo ago
      Github copilot used to only be in line completion. That is not vibe coding.
      • the_af 8mo ago
        I wasn't an early adopter of Copilot, but now the VSCode plugin can use Claude models in Agent mode. I've had success with this. I don't "vibecode" though, if I don't understand what it's doing I don't use it. And of course, like all LLMs, sometimes it goes on a useless tangent and must be reigned in.
    • steviedotboston 8mo ago
      was github copilot LLM based in 2021? I thought the first version was something more rudimentary
      • abyesilyurt 8mo ago
        gpt-3 afaik
    • reedf1 8mo ago
      Early cursor was just integrated chat and code completion. No agents.
  • rpigab 8mo ago
    It seems the term has been introduced by Andrej Karpathy in February 2025, so yes, but very often, people say "vibe coding" when they mean "heavily (or totally) LLM-assisted coding", which is not synonymous, but sounds better to them.
• naikrovek 8mo ago
  two years of vibecoding experience already? his points about why he stopped using AI: these are the things us reluctant AI adopters have been saying since this all started.
  • SiempreViernes 8mo ago
    The practice is older than the name, which is usually the way: first you start doing something frequently enough you need to name it, then you come up with the name.
• mettamage 8mo ago
  > In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM. LLMs allow me to write code faster and it also gives a lot of discoverability of programming concepts I didn't know much about. For example, it plugged in a lot of Tailwind CSS, which I've never used before. With that said, it does not absolve me from not knowing my own codebase, unless I'm (temporarily) fine with my codebase being fractured conceptually in wonky ways. I think vibecoding is amazing for creating quick high fidelity prototypes for a green field project. You create it, you vibe code it all the way until your app is just how you want it to feel. Then you refactor it and scale it. I'm currently looking at 4009 lines of JS/JSX combined. I'm still vibecoding my prototype. I recently looked at the codebase and saw some ready made improvements so I did them. But I think I'll start to need to actually engineer anything once I reach the 10K line mark.
  • acedTrex 8mo ago
    > My way is to understand my own codebase and look at the output of the LLM. Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
    • mettamage 8mo ago
      I know what you mean but to look that black and white at it seems dismissive of the spectrum that's actually there (between vibecoding and software engineering). Looking at the whole spectrum is, I find, much more interesting. Normally I'd know 100% of my codebase, now I understand 5% of it truly. The other 95% I'd need to read it more carefully before I daresay I understand it.
      • embedding-shape 8mo ago
        Call it "AI programming" or "AI pairing" or "Pair programming with AI" or whatever else, "vibe coding" was "coined" with the explicit meaning of "I'm going by the vibes, I don't even look at the code". If "vibe coding" suddenly mean "LLM was involved somehow", then what is the "vibe" even for anymore? I agree there is a spectrum, and all the way to the left you have "vibe coding" and all the way to the right you have "manual programming without AI", of course it's fine to be somewhere in the middle, but you're not doing "vibe coding" in the way Karpathy first meant it.
• recursivedoubts 8mo ago
  AI is incredibly dangerous because it can do the simple things very well, which prevents new programmers from learning the simple things ("Oh, I'll just have AI generate it") which then prevents them from learning the middlin' and harder and meta things at a visceral level. I'm a CS teacher, so this is where I see a huge danger right now and I'm explicit with my students about it: you HAVE to write the code. You CAN'T let the machines write the code. Yes, they can write the code: you are a student, the code isn't hard yet. But you HAVE to write the code.
  • Quothling 8mo ago
    I'm an external examiner for CS students in Denmark and I disagree with you. What we need in the industry is software engineers who can think for themselves, can interact with the business and understand it's needs, and, they need to know how computers work. What we get are mass produced coders who have been taught some outdated way of designing and building software that we need to hammer out of them. I don't particularily care if people can write code like they work at the assembly line. I care that they can identify bottlenecks and solve them. That they can deliver business value quickly. That they will know when to do abstractions (which is almost never). Hell, I'd even like developers who will know when the code quality doesn't matter because shitty code will cost $2 a year but every hour they spend on it is $100-200. Your curriculum may be different than it is around here, but here it's frankly the same stuff I was taught 30 years ago. Except most of the actual computer science parts are gone, replaced with even more OOP, design pattern bullshit. That being said. I have no idea how you'd actually go about teaching students CS these days, considering a lot of them will probably use ChatGPT or Claude regardless of what you do. That is what I see in the statistic for grades around here. For the first 9 years I was a well calibrated grader, but these past 1,5ish years it's usually either top marks or bottom marks with nothing in between. Which puts me outside where I should be, but it matches the statistical calibration for everyone here. I obviously only see the product of CS educations, but even though I'm old, I can imagine how many corners I would have cut myself if I had LLM's available back then. Not to mention all the distractions the internet has brought.
    • halfmatthalfcat 8mo ago
• joomy 8mo ago
  The title alone reads like the "digging for diamonds" meme.
• simonw 8mo ago
  > Not only does an agent not have the ability to evolve a specification over a multi-week period as it builds out its lower components, it also makes decisions upfront that it later doesn’t deviate from. That's your job. The great thing about coding agents is that you can tell them "change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttling" and... they'll track down dozens or even hundreds of places that need updating and fix them all. (And the automated test suite will help them confirm that the refactoring worked properly, because naturally you had them construct an automated test suite when they built those original features, right?) Going back to typing all of the code yourself (my interpretation of "writing by hand") because you don't have the agent-managerial skills to tell the coding agents how to clean up the mess they made feels short-sighted to me.
  • disgruntledphd2 8mo ago
    > (And the automated test suite will help them confirm that the refactoring worked properly, because naturally you had them construct an automated test suite when they built those original features, right?) I dunno, maybe I have high standards but I generally find that the test suites generated by LLMs are both over and under determined. Over-determined in the sense that some of the tests are focused on implementation details, and under-determined in the sense that they don't test the conceptual things that a human might. That being said, I've come across loads of human written tests that are very similar, so I can see where the agents are coming from. You often mention that this is why you are getting good results from LLMs so it would be great if you could expand on how you do this at some point in the future.
    • simonw 8mo ago
      I work in Python which helps a lot because there are a TON of good examples of pytest tests floating around in the training data, including things like usage of fixture libraries for mocking external HTTP APIs and snapshot testing and other neat patterns. Or I can say "use pytest-httpx to mock the endpoints" and Claude knows what I mean. Keeping an eye on the tests is important. The most common anti-pattern I see is large amounts of duplicated test setup code - which isn't a huge deal, I'm much more more tolerant of duplicated logic in tests than I am in implementation, but it's still worth pushing back on. "Refactor those tests to use pytest.mark.parametrize" and "extract the common setup into a pytest fixture" work really well there. Generally though the best way to get good tests out of a coding agent is to make sure it's working in a project with an existing test suite that uses good patterns. Coding agents pick the existing patterns up without needing any extra prompting at all. I find that once a project has clean basic tests the new tests added by the agents tend to match them in quality. It's similar to how working on large projects with a team of other developers work - keeping the code clean means when people look for examples of how to write a test they'll be pointed in the right direction. One last tip I use a lot is this: Clone datasette/datasette-enrichments from GitHub to /tmp and imitate the testing patterns it uses I do this all the time with different existing projects I've written - the quickest way to show an agent how you like something to be done is to have it look at an example.
• billynomates 8mo ago
  False dichotomy. There is a happy medium where you can orchestrate the agent to give you the code you want even when the spec changes
• dv_dt 8mo ago
  I think there is going to be an AI eternal summer. Both from developer to AI spec - where the AI implements to the spec to some level of quality, but then closing the gap after that is an endless chase of smaller items that don't all resolve at the same time. And from people getting frustrated with some AI implemented app, and so go off and AI implement another one, with a different set of features and failings.
  • system2 8mo ago
    Non-ai software reality is not that different.
• altern8 8mo ago
  I think that something in between works. I have AI build self-contained, smallish tasks and I check everything it does to keep the result consistent with global patterns and vision. I stay in the loop and commit often. Looks to me like the problem a lot of people are having is that they have AI do the whole thing. If you ask it "refactor code to be more modern", it might guess what you mean and do it in a way you like it or not, but most likely it won't. If you keep tasks small and clearly specced out it works just fine. A lot better than doing it by hand in many cases, specially for prototyping.
• sailfast 8mo ago
  I felt everything in this post quite emphatically until the “but I’m actually faster than the AI.” Might be my skills but I can tell you right now I will not be as fast as the AI especially in new codebases or other languages or different environments even with all the debugging and hell that is AI pull request review. I think the answer here is fast AI for things it can do on its own, and slow, composed, human in the loop AI for the bigger things to make sure it gets it right. (At least until it gets most things right through innovative orchestration and model improvement moving forward.)
  • dylanowen 8mo ago
    But those are the parts where it's important to struggle through the learning process even if you're slower than AI. if you defer to an LLM because it can do your work in a new codebase faster than you, that code base will stay new to you for forever. You'll never be able to review the AI code effectively.
• douglaswlance 8mo ago
  unless someone shows their threads of prompts or an unedited stream of them working, it's pointless to put any weight into their opinions. this is such an individualized technology that two people at the same starting point two years ago, could've developed wildly different workflows.
  • jdauriemma 8mo ago
    That's the sad part. Empiricism is scarce when people and companies are incentivized to treat their AI practices as trade secrets. It's fundamentally distinct from prior software movements which were largely underwritten by open, accessible, and permissively-licensed technologies.
    • kaydub 8mo ago
      I don't see people treating AI practices as trade secrets. It's just the nature of a non-deterministic system.
  • deleted 8mo ago
    [deleted]
• rtp4me 8mo ago
  I never trust the opinion of a single LLM model anymore - especially for more complex projects. I have seen Claude guarantee something is correct and then immediately apologize when I feed a critical review by Codex or Gemini. And, many times, the issues are not minor but are significant critical oversights by Claude. My habit now: always get a 2nd or 3rd opinion before assuming one LLM is correct.
  • ozten 8mo ago
    It doesn’t have to be different foundation models. As long as the temperature is up, as the same model 100 times.
  • kaydub 8mo ago
    Happy to see someone else doing this. All code written by an LLM is reviewed by an additional LLM. Then I verify that review and get one of the agents to iterate on everything.
    • rtp4me 8mo ago
      Agreed. From my experience, Claude is the top-level coder, Gemini is the architect, and Codex is really good at finding bugs and logic errors. In fact, Codex seems to perform better deep analysis than the other two.
      • kaydub 8mo ago
        I just round robin them until I run out on whatever subscription level I'm on. I only use claude api, so I pay per token there... I consider using claude as "bringing out the big guns" because I also think it's the top-level coder.
• rich_sasha 8mo ago
  I came to "vibe coding" with an open mind, but I'm slowly edging in the same direction. It is hands down good for code which is laborious or tedious to write, but once done, obviously correct or incorrect (with low effort inspection). Tests help but only if the code comes out nicely structured. I made plenty of tools like this, a replacement REPL for MS-SQL, a caching tool in Python, a matplotlib helper. Things that I know 90% how to write anyway but don't have the time, but once in front of me, obviously correct or incorrect. NP code I suppose. But business critical stuff is rarely like this, for me anyway. It is complex, has to deal with various subtle edge cases, be written defensively (so it fails predictably and gracefully), well structured etc. and try as I might, I can't get Claude to write stuff that's up to scratch in this department. I'll give it instructions on how to write some specific function, it will write this code but not use it, and use something else instead. It will pepper the code with rookie mistakes like writing the same logic N times in different places instead of factoring it out. It will miss key parts of the spec and insist it did it, or tell me "Yea you are right! Let me rewrite it" and not actually fix the issue. I also have a sense that it got a lot dumber over time. My expectations may have changed of course too, but still. I suspect even within a model, there is some variability of how much compute is used (eg how deep the beam search is) and supply/demand means this knob is continuously tuned down. I still try to use Claude for tasks like this, but increasingly find my hit rate so low that the whole "don't write any code yet, let's build a spec" exercise is a waste of time. I still find Claude good as a rubber duck or to discuss design or errors - a better Stack Exchange. But you can't split your software spec into a set of SE questions then paste the code from top answers.
  • nonethewiser 8mo ago
    The hardest part of coding has never been coding. It's been translating new business requirements into a specific implementation plan that works. Understanding what needs to be done, how things are currently working, and how to go from A to B. You can't dispense with yourself in those scenarios. You have to read, think, investigate, break things down into smaller problems. But I employ LLM's to help with that all the time. Granted, that's not vibe coding at all. So I guess we are pretty much in agreement up to this point. Except I still think LLMs speed up this process significantly, and the models and tools are only going to get better. Also, there are a lot of developers that are just handed the implementation plan.
• ncruces 8mo ago
  > The AI had simply told me a good story. Like vibewriting a novel, the agent showed me a good couple paragraphs that sure enough made sense and were structurally and syntactically correct. Hell, it even picked up on the idiosyncrasies of the various characters. But for whatever reason, when you read the whole chapter, it’s a mess. It makes no sense in the overall context of the book and the preceding and proceeding chapters. This is the bit I think enthusiasts need to argue doesn't apply. Have you ever read a 200 page vibewritten novel and found it satisfying? So why do you think a 10 kLoC vibecoded codebase will be any good engineering-wise?
  • ashikns 8mo ago
    Because a novel is about creative output, and engineering is about understanding a lot of rules and requirements and then writing logic to satisfy that. The latter has a much more explicitly defined output.
    • therealdrag0 8mo ago
      Said another way, a novel is about the experience of reading every word of implementation, whereas software is sufficient to be a black box, the functional output is all that matters. No one is reading assembly for example. We’re moving into a world where suboptimal code doesn’t matter that much because it’s so cheap to produce.
    • ModernMech 8mo ago
      The lesson of UML is that software engineering is not a process of refining rules and requirements into logic. Software engineering is lucrative because it very much is a creative process.
  • mrtesthah 8mo ago
    I wrote this a day ago but I find it even more relevant to your observation: — I would never use, let alone pay for, a fully vibe-coded app whose implementation no human understands. Whether you’re reading a book or using an app, you’re communicating with the author by way of your shared humanity in how they anticipate what you’re thinking as you explore the work. The author incorporates and plans for those predicted reactions and thoughts where it makes sense. Ultimately the author is conveying an implicit mental model (or even evoking emotional states or sensations) to the reader. The first problem is that many of these pathways and edge cases aren’t apparent until the actual implementation, and sometimes in the process the author realizes that the overall product would work better if it were re-specified from the start. This opportunity is lost without a hands on approach. The second problem is that, the less human touch is there, the less consistent the mental model conveyed to the user is going to be, because a specification and collection of prompts does not constitute a mental model. This can create subconscious confusion and cognitive friction when interacting with the work.
• ChicagoDave 8mo ago
  Everything the OP says can be true, but there’s a tipping point where you learn to break through the cruft and generate good code at scale. It requires refactoring at scale, but GenAI is fast so hitting the same code 25 times isn’t a dealbreaker. Eventually the refactoring is targeted at smaller and smaller bits until the entire project is in excellent shape. I’m still working on Sharpee, an interactive fiction authoring platform, but it’s fairly well-baked at this point and 99% coded by Claude and 100% managed by me. Sharpee is a complex system and a lot of the inner-workings (stdlib) were like coats of paint. It didn’t shine until it was refactored at least a dozen times. It has over a thousand unit tests, which I’ve read through and refactored by hand in some cases. The results speak for themselves. https://sharpee.net/ https://sharpee.net/ https://github.com/chicagodave/sharpee/ https://github.com/chicagodave/sharpee/ It’s still in beta, but not far from release status.
  • ChicagoDave 8mo ago
    When using GenAI (and not), enforcing guardrails is critical. Documenting decisions is critical. Sharpee’s success is rooted in this and its recorded: https://github.com/ChicagoDave/sharpee/tree/main/docs/architecture/adrs https://github.com/ChicagoDave/sharpee/tree/main/docs/archit...
• ramon156 8mo ago
  +1, ive lost the mental model of most projects. I also added disclaimers to my projects that part of it was generated to not fool anyone
• jstummbillig 8mo ago
  The tale of the coder, who finds a legacy codebase (sometimes of their own making) and looks at it with bewilderment is not new. It's a curious one, to a degree, but I don't think it has much to do with vibe coding.
  • zeroonetwothree 8mo ago
    I have been working for 20 years and I haven’t really experienced this with any code I’ve written. Sure I don’t remember every line but I always recall the high level outlines. I admit I could be an outlier though.
• AstroBen 8mo ago
  The author also has multiple videos on his YouTube channel going over the specific issues hes had with AI that I found really interesting: https://youtube.com/@atmoio https://youtube.com/@atmoio
• couchdb_ouchdb 8mo ago
  Good luck finding an employer that lets you do this moving forward. The new reality is that no one can give the estimates they previously gave for tasks. \ "Amazingly, I’m faster, more accurate, more creative, more productive, and more efficient than AI, when you price everything in, and not just code tokens per hour." For 99.99% of developers this just won't be true.
• jrm4 8mo ago
  I feel like the vast majority of articles on this are little more than the following: "AI can be good -- very good -- at building parts. For now, it's very bad at the big picture."
• jdlyga 8mo ago
  I've gone through this cycle too, and what I realized is that as a developer a large part of your job is making sure the code you write works, is maintainable, and you can explain how it works.
• TrackerFF 8mo ago
  I wish more critics would start to showcase examples of code slop. I'm not saying this because I defend the use of AI-coding, but rather because many junior devs. that read these types articles/blog posts may not know what slop is, or what it looks like. Simply put, you don't know what you don't know.
• reedf1 8mo ago
  Karpathy coined the term vibecoding 11 months ago (https://x.com/karpathy/status/1886192184808149383 https://x.com/karpathy/status/1886192184808149383). It caused quite a stir - because not only was it was a radically new concept, but fully agentic coding had only become recently possible. You've been vibe coding for two years??
  • jv22222 8mo ago
    Very good point. Also, What the OP describes is something I went through in the first few months of coding with AI. I pushed passed “the code looks good but it’s crap” phase and now it’s working great. I’ve found the fix is to work with it during research/planning phase and get it to layout all its proposed changes and push back on the shit. Once you have a research doc that looks good end to end then hit “go”.
  • bschmidt800 8mo ago
    [dead]
  • dfajgljsldkjag 8mo ago
    The term was coined then, but people have been doing it with claude code and cursor and copilot and other tools for longer. They just didn't have a word for it yet.
    • reedf1 8mo ago
      Claude Code was released a month after this post - and cursor did not yet have an agent concept, mostly just integrated chat and code completion. I know because I was using it.
  • AstroBen 8mo ago
    The author is using the term to mean AI assisted coding. Thats been around for longer than the word vibe coding
    • andai 8mo ago
      This remains a point of great confusion every time there is such a discussion. When some people say vibe coding, they mean they're copy-pasting snippets of code from ChatGPT. When some people say vibe coding, they give a one sentence prompt to their cluster of Claude Code instances and leave for a road trip!
• coldtea 8mo ago
  He might be coding by hand again, but the article itself is AI slop
• xcodevn 8mo ago
  My observation is that vibe-coded applications are significantly lower quality than traditional software. Anthropic software (which they claim to be 90% vibe coded) is extremely buggy, especially the UI.
  • gowld 8mo ago
    That's a misunderstanding based on loose definition of "vibe coding". When companies threw around the "90% of code is written by AI" claims, they were referring to counting characers of autocomplete basing on users actually typing code (most of which was eequivalent to "AI generated" code by Eclipse tab-completion decade ago), and sometimes writing hyperlocal prompts for a single method. We can identify 3 levels of "vibe coding": 1. GenAI Autocomplete 2. Hyperlocal prompting about a specific function. (Copilot's orginal pitch) 3. Developing the app without looking at code. Level 3 is hardly considered "vibe" coding, and Level 2 is iffy. "90% of code written by AI" in some non-trivial contexts only very recently reached level 3. I don't think it ever reached Level 2, because that's just a painfully tedious way of writing code.
    • andai 8mo ago
      I mostly work at level 2, and I call it "power coding", like power armor, or power tools. Your will and your hand still guides the process continuously. But now your force is greatly multiplied.
    • xcodevn 8mo ago
      I believe Anthropic is already doing Level 3 vibe coding for >90% of their code.
      • doug_durham 8mo ago
        They have not said that. They've only said that most of their code is written by Claude. That is different than "vibe coding". If competent engineers review the code then it is little different than any coding.
• leesec 8mo ago
  OK. Top AI labs have people using llms for 100% of their code. Enjoy writing by hand tho
  • kylehotchkiss 8mo ago
    "They got more VC than me, therefore they are right". You gotta have a better argument than "AI Labs are eating their own dogfood". Are there any other big software companies doing that successfully? I bet yes, and think those stories carry more weight.
    • leesec 8mo ago
      These are the smartest people in tech lol.
  • bopbopbop7 8mo ago
    > Company that builds x says that everyone in company uses x. Have people always been this easy to market to?
    • leesec 8mo ago
      I know these people lol, they are better coders than you
      • bopbopbop7 8mo ago
        Yup, checks out, you're definitely the type of person the AI companies are marketing to.
• deleted 8mo ago
  [deleted]
• andai 8mo ago
  It probably depends on what you're doing, but my use case is simple straightforward code with minimal abstraction. I have to go out of my way to get this out of llms. But with enough persuasion, they produce roughly what I would have written myself. Otherwise they default to adding as much bloat and abstraction as possible. This appears to be the default mode of operation in the training set. I also prefer to use it interactively. I divide the problem to chunks. I get it to write each chunk. The whole makes sense. Work with its strengths and weaknesses rather than against them. For interactive use I have found smaller models to be better than bigger models. First of all because they are much faster. And second because, my philosophy now is to use the smallest model that does the job. Everything else by definition is unnecessarily slow and expensive! But there is a qualitative difference at a certain level of speed, where something goes from not interactive to interactive. Then you can actually stay in flow, and then you can actually stay consciously engaged.
• arendtio 8mo ago
  There is certainly some truth to this, but why does it have to be black-and-white? Nobody forces you to completely let go of the code and do pure vibe coding. You can also do small iterations.
• aaronrobinson 8mo ago
  I read that people just allow Claude Code free rein but after using it for a few months and seeing what it does I wonder how much of that is in front of users. CC is incredible as much as it is frustrating and a lot of what it churns out is utter rubbish. I also keep seeing that writing more detailed specs is the answer and retorts from those saying we’re back to waterfall. That isn’t true. I think more of the iteration has moved to the spec. Writing the code is so quick now so can make spec changes you wouldn’t dare before. You also need gates like tests and you need very regular commits. I’m gradually moving towards more detailed specs in the form of use cases and scenarios along with solid tests and a constantly tuned agent file + guidelines. Through this I’m slowly moving back to letting Claude lose on implementation knowing I can do scan of the git diffs versus dealing with a thousand ask before edits and slowing things down. When this works you start to see the magic.
• dudeinhawaii 8mo ago
  After reading the article (and watching the video), I think the author makes very clear points that comments here are skipping over. The opener is 100% true. Our current approach with AI code is "draft a design in 15mins" and have AI implement it. The contrasts with the thoughtful approach a human would take with other human engineers. Plan something, pitch the design, get some feedback, take some time thinking through pros and cons. Begin implementing, pivot, realizations, improvements, design morphs. The current vibe coding methodology is so eager to fire and forget and is passing incomplete knowledge unto an AI model with limited context, awareness and 1% of your mental model and intent at the moment you wrote the quick spec. This is clearly not a recipe for reliable and resilient long-lasting code or even efficient code. Spec-driven development doesn't work when the spec is frozen and the builder cannot renegotiate intent mid-flight.. The second point made clearer in the video is the kind of learned patterns that can delude a coder, who is effectively 'doing the hard part', into thinking that the AI is the smart one. Or into thinking that the AI is more capable than it actually is. I say this as someone who uses Claude Code and Codex daily. The claims of the article (and video) aren't strawman. Can we progress past them? Perhaps, if we find ways to have agents iteratively improve designs on the fly rather than sticking with the original spec that, let's be honest, wasn't given the rigor relative to what we've asked the LLMs to accomplish. If our workflows somehow make the spec a living artifact again -- then agents can continuously re-check assumptions, surface tradeoffs, and refactor toward coherence instead of clinging to the first draft.
  • kaydub 8mo ago
    You can update the spec as you go... There's nothing that makes the spec concrete and unchangeable.
  • Lerc 8mo ago
    >Our current approach with AI code is "draft a design in 15mins" and have AI implement it. The contrasts with the thoughtful approach a human would take with other human engineers. Plan something, pitch the design, get some feedback, take some time thinking through pros and cons. Begin implementing, pivot, realizations, improvements, design morphs. Perhaps that is the distinction between reports of success with AI and reports of abject failure. Your description of "Our current approach" is nothing like how I have been working with AI. When I was making some code to do a complex DMA chaining, the first step with the AI was to write an emulator function that produced the desired result from the parameters given in software. Then a suite of tests with memory to memory operations that would produce a verifiable output. Only then started building the version that wrote to the hardware registers ensuring that the hardware produced the same memory to memory results as the emulator. When discrepancies occurred, checking the test case, the emulator and the hardware with the stipulation that the hardware was the ground truth of behaviour and the test case should represent the desired result. I occasionally ask LLMs to one shot full complex tasks, but when I do so it is more as a test to see how far it gets. I'm not looking to use the result, I'm just curious as to what it might be. The amount of progress it makes before getting lost is advancing at quite a rate. It's like seeing an Atari 2600 and expecting it to be a Mac. People want to fly to the moon with Atari 2600 level hardware. You can use hardware at that level to fly to the moon, and flying to the moon is an impressive achievement enabled by the hardware, but to do so you have to wrangle a vast array of limitations. They are no panacea, but they are not nothing. They have been, and will remain, somewhere between for some time. Nevertheless they are getting better and better.
• hgs3 8mo ago
  I'm flabbergasted why anyone would voluntarily vibe code anything. For me, software engineering is a craft. You're supposed to enjoy building it. You should want to do it yourself.
  • doug_durham 8mo ago
    Do you honestly get satisfaction out of writing code that you've written dozens of times in your career? Does writing yet another REST client endpoint fill you with satisfaction? Software is my passion, but I want to write code where I can add the maximum value. I add more value by using my experience solving new problems that rehashing code I've written before. Using GenAI as a helper tool allows me to quickly write the boilerplate and get to the value-add. I review every line of code written before sending it for PR review. That's not controversial, it's just good engineering.
    • Ronsenshi 8mo ago
      Sounds like eventually we will end up in a situations where engineers/developers will end up on an AI spectrum: - No ai engineers - Minimal AI autocomplete engineers - Simple agentic developers - Vibe coders who review code they get - Complete YOLO vibe coders who have no clue how their "apps" work And that spectrum will also correlate to the skill level in engineering: from people who understand what they are doing and what their code is doing - to people who have lost (or never even had) software engineering skills and who only know how to count lines of code and write .md files.
  • kaydub 8mo ago
    It's not a craft. We're modern day factory workers.
  • wvenable 8mo ago
    Not everything can be built by one person. This is why a lot of software requires entire teams of developers. And someone has to have vision of that completed software and wants it made even if they had to delegate to other people. I hate to think that none of these people enjoy their job.
• spicymaki 8mo ago
  I think what many people do no understand is that software development is communication. Communication from the customers/stake holders to the developer and communication from with the developer to the machine. At some fundamental level there needs to be some precision about what you want and someone/something needs to translate that into a system to provide that solution. Software can help check if there are errors, check constraints, and execute instructions precisely, but they cannot replace the fact that someone needs to tell the machine what to do (precise intent). What AI (LLMs) do is raises the level of abstraction to human language via translation. The problem is human language is imprecise in general. You can see this with legal or science writing. Legalese is almost illegible to laypeople because there are precise things you need to specify and you need be precise in how you specify it. Unfortunately the tech community is misleading the public and telling laypeople they can just sit back and casually tell AI what you want and it is going to give you exactly what you wanted. Users are just lying to themself, because most-likely they did not take the time to think through what they wanted and they are rationalizing (after the fact) that the AI is giving them exactly what they wanted.
  • bofadeez 8mo ago
    It's far more insidious than that. It's tricking us into thinking it got the right answer.
• pmontra 8mo ago
  In my experience it's great a writing sample code or solving obscure problems that would have been hard to google a solution for. However it fails sometimes and it can't get past some block, but neither can I unless I work hard at it. Examples. Thanks to Claude I've finally been able to disable the ssh subsystem of the GNOME keyring infrastructure that opens a modal window asking for ssh passhprases. What happened is that I always had to cancel the modal, look for the passhprase in my password manager, restart what made the modal open. What I have now is either a password prompt inside a terminal or a non modal dialog. Both ssh-add to a ssh agent. However my new emacs windows still open in an about 100x100 px window on my new Debian 13 install, nothing suggested by Claude works. I'll have to dig into it but I'm not sure that's important enough. I usually don't create new windows after emacs starts with the saved desktop configuration.
• maurits 8mo ago
  I tell my students that they can watch sports on tv, but it will not make them fit. On a personal note, vibe coding leaves me with that same empty hollow sort of tiredness, as a day filled with meetings.
  • graydsl 8mo ago
    Last week I just said f it and developed a feature by hand. No Copilot, no agents. Just good old typing and a bit of Intellisense. I ran into a lot of problems with the library I used, slowly but surely I got closer to the result I wanted. In the end my feature worked as expected, I understand the code I wrote and know about all the little quirks the lib has. And as a added benefit: I feel accomplished and proud of the feature.
  • 0xffff2 8mo ago
    I work in an environment where access to LLMs is still quite restricted, so I write most of my code by hand at work. Conversely, after work I still have ideas for personal projects but mostly didn't have the energy to write them by hand. The ability to throw a half-baked idea at the LLM and get back half-baked code that runs and does most of what I asked for gives me the energy to work through refactoring and improving the code to make it do what I actually envisioned.
  • dyauspitr 8mo ago
    Outcomes are all that matter.
    • academic_84572 8mo ago
      In the short term, you might see better outcomes with pure vibecoding...but in the long term, when you're mentally burnt out, cynical, and losing motivation, that's a bad outcome both in terms of productivity and your own mental health. We need to find the Goldilocks optimal level of AI assistance that doesn't leave everyone hating their jobs, while still boosting productivity.
      • dyauspitr 8mo ago
• raphinou 8mo ago
  I use ai to develop, but at every code review I find stuff to be corrected, which motivates me to continuing the reviews. It's still a win I think though. I've incrementally increased my use of ai in development [1], but I'm at a plateau now I think. I don't plan to go over to complete vibe coding for anything serious or to be maintained. 1: https://asfaload.com/blog/ai_use/ https://asfaload.com/blog/ai_use/
• ecshafer 8mo ago
  I never really got onto "vibe coding". I treat AI as a better auto-complete that has stack overflow knowledge. I am writing a game in Monogame, I am not primarily a game dev or a c sharp dev. I find AI is fantastic here for "Set up a configuration class for this project that maps key bindings" and have it handle the boiler plate and smaller configuration. Its great at give me an A start implementation for this graph. But when it becomes x -> y -> z without larger contexts and evolutions it falls flat. I still need creativity. I just don't worry too much about boiler plate, utility methods, and figuring out specifics of wiring a framework together.
• sheepscreek 8mo ago
  Good for the author. Me, never going back to hands-only coding. I am producing more higher quality code that I understand and feel confident in. I tell AI to not just “write tests”, I tell it exactly what to test as well. Then I’ll often prompt it “hey did you check for the xyz edge cases?” You need code reviews. You need to intervene. You will need frequent code rewrites and refactors. But AI is the best pair-coding partner you could hope for (at this time) and one that never gets tired. So while there’s no free lunch, if you are willing to pay - your lunch will be a delicious unlimited buffet for a fraction of the cost.
• bobjordan 8mo ago
  Process and plumbing become very important when using ai for coding. Yes, you need good prompts. But as the code base gets more complex, you also need to spend significant time developing test guides, standardization documents, custom linters, etc, to manage the agents over time.
• wahnfrieden 8mo ago
  Claude Code slOpus user. No surprise this is their conclusion.
• eddyg 8mo ago
  Previous discussion on the video: https://news.ycombinator.com/item?id=46744572 https://news.ycombinator.com/item?id=46744572
• thecommakozzi 8mo ago
  [dead]
• Painsawman123 8mo ago
  In the long run, vb coding is going to undoubtedly rot people’s skills.if AGI is not showing up anytime soon, actually understanding what the code does,why it exists,how it breaks and who owns the fallout will matter just as much as it did before LLM agents showed up it'll be really interesting to see in the decades to come what happens when a whole industry gets used to releasing black boxes by vb coding the hell out of it
• flankstaek 8mo ago
  Maybe I'm "vibecoding" wrong but to me at least this misses a clear step which is reviewing the code. I think coding with an AI changes our role from code writer to code reviewer, and you have to treat it as a comprehensive review where you comment not just on code "correctness" but these other aspects the author mentions, how functions fits together, codebase patterns, architectural implications. While I feel like using AI might have made me a lazier coder, it's made me a me a significantly more active reviewer which I think at least helps to bridge the gap the author is referencing.
• shas3 8mo ago
  I don't get what everyone sees in this post. It is just a sloppy rant. It just talks in generalities. There is no coherent argument, there are no examples, and we don't even know the problem space in which the author had bad coding assistant experience.
• kaydub 8mo ago
  How were you "vibe coding" 2 years ago? There's been such a massive leap in capabilities since claude code came out, which was middle/end of 2025. 2 years ago I MAYBE used an LLM to take unstructured data and give me a json object of a specific structure. Only about 1 year ago did I start using llms for ANY type of coding and I would generally use snippets, not whole codebases. It wasn't until September when I started really leveraging the LLM for coding.
  • pc86 8mo ago
    Typical blogspam clickbait of "I knew what LLMs were 2 years, but maybe didn't know the name for them, so we'll call that vibecoding."
  • koakuma-chan 8mo ago
    GitHub Copilot came out with AI autocomplete 2-3 years ago I believe.
    • furyofantares 8mo ago
      Using autocomplete is very much not "vibe coding".
  • JimDabell 8mo ago
    Vibe coding was coined less than a year ago: https://x.com/karpathy/status/1886192184808149383 https://x.com/karpathy/status/1886192184808149383
    • kridsdale1 8mo ago
      To a describe a thing people had been doing since LLMs became available.
      • JimDabell 8mo ago
        No. That’s why he called it “a new kind of coding”.
• yawnxyz 8mo ago
  I like to use AI to write code for me, but I like to take it one step at a time, looking at what it puts out and thinking about if it puts out what I want it to put out. As a PRODUCT person, it writes code 100x faster than I can, and I treat anything it writes as a "throwaway" prototype. I've never been able to treat my own code as throwaway, because I can't just throw away multiple weeks of work. It doesn't aid in my learning to code, but it does aid in me putting out much better, much more polished work that I'm excited to use.
• dev1ycan 8mo ago
  I vibe coded for a while (about a year) it was just so terrible for my ability to do anything, it started becoming recurring that I couldn't control my timelines because I would get into a loop where I would keep asking AI to "fix" things I didn't actually understand and had no mental capacity to actually read 50k lines of LLM generated code compared to if I had done it from scratch so I would keep and keep going. Or how I would start spamming SQL scripts and randomly at some point nuke all my work (happened more than once)... luckily at least I had backups regularly but... yeah. I'm sorry but no, LLMs can't replace software engineers.
• drowntoge 8mo ago
  I always scaffold for AI. I write the stub classes and interfaces and mock the relations between them by hand, and then ask the agent to fill in the logic. I know that in many cases, AI might come up with a demonstrably “better” architecture than me, but the best architecture is the one that I’m comfortable with, so it’s worse even if it’s better. I need to be able to find the piece of code I’m looking for intuitively and with relative ease. The agent can go as crazy as it likes inside a single, isolated function, but I’m always paranoid about “going too far” and losing control of any flows that span multiple points in the codebase. I often discard code that is perfectly working just because it feels unwieldy and redo it. I’m not sure if this counts as “vibe coding” per se, but I like that this mentality keeps my workday somewhat similar to how it was for decades. Finding/creating holes that the agent can fill with minimal adult supervision is a completely new routine throughout my day, but I think obsessing over maintainability will pay off, like it always has.
• GolDDranks 8mo ago
  I feel like I'm taking crazy pills. The article starts with: > you give it a simple task. You’re impressed. So you give it a large task. You’re even more impressed. That has _never_ been the story for me. I've tried, and I've got some good pointers and hints where to go and what to try, a result of LLM's extensive if shallow reading, but in the sense of concrete problem solving or code/script writing, I'm _always_ disappointed. I've never gotten satisfactory code/script result from them without a tremendous amount of pushback, "do this part again with ...", do that, don't do that. Maybe I'm just a crank with too many preferences. But I hardly believe so. The minimum requirement should be for the code to work. It often doesn't. Feedback helps, right. But if you've got a problem where a simple, contained feedback loop isn't that easy to build, the only source of feedback is yourself. And that's when you are exposed to the stupidity of current AI models.
  • dev_l1x_be 8mo ago
    Well one way of solving this is to keep giving it simple tasks.
    • hmaxwell 8mo ago
      Exactly 100% I read these comments and articles and feel like I am completely disconnected from most people here. Why not use GenAI the way it actually works best: like autocomplete on steroids. You stay the architect, and you have it write code function by function. Don't show up in Claude Code or Codex asking it to "please write me GTA 6 with no mistakes or you go to jail, please." It feels like a lot of people are using GenAI wrong.
      • latexr 8mo ago
        > It feels like a lot of people are using GenAI wrong. That argument doesn’t fly when the sellers of the technology literally sing at you “there’s no wrong way to prompt”. https://youtu.be/9bBfYX8X5aU?t=48 https://youtu.be/9bBfYX8X5aU?t=48
    • GoatInGrey 8mo ago
      The other side of this coin are the non-developer stakeholders who Dunning-Kruger themselves into firm conclusions on technical subjects with LLMs. "Well I can code this up in an hour, two max. Why is it taking you ten hours?". I've (anecdotally) even had project sponsors approach me with an LLM's judgement on their working relationship with me as if it were gospel like "It said that we aren't on the same page. We need to get aligned." It gets weird. These cases are common enough to where it's more systemic than isolated.
• globular-toast 8mo ago
  It took me about two weeks to realise this. I still use LLMs, but it's just a tool. Sometimes it's the right tool, but often it isn't. I don't use an SDS drill to smooth down a wall. I use sandpaper and do it by hand.
• BinaryIgor 8mo ago
  I don't know whether I would go that extreme, but I also often find myself faster writing code manually; for some tasks though and contextually, AI-assisted coding is pretty useful, but you still must be in the driving seat, at all times. Good take though.
• AJ007 8mo ago
  One thing that's consistent with AI negative/doesn't work/is slop posts: they don't tell you want models they are using.
• advael 8mo ago
  I feel vindicated by this article, but I shouldn't. I have to admit that I never developed the optimism to do this for two years, but have increasingly been trying to view this as a personal failing of closed-mindedness, brought on by an increasing number of commentators and colleagues coming around to "vibe-coding" as each "next big thing" in it dropped. I think the most I can say I've dove in was in the last week. I wrangled some resources to build myself a setup with a completely self-hosted and agentic workflow and used several open-weight models that people around me had specifically recommended, and I had a work project that was self-contained and small enough to work from scratch. There were a few moving pieces but the models gave me what looked like a working solution within a few iterations, and I was duly impressed until I realized that it wasn't quite working as expected. As I reviewed and iterated on it more with the agents, eventually this rube-goldberg machine started filling in gaps with print statements designed to trick me and sneaky block comments that mentioned that it was placeholder code not meant for production in oblique terms three lines into a boring description of what the output was supposed to be. This should have been obvious, but even at this point four days in I was finding myself missing more things, not understanding the code because I wasn't writing it. This is basically the automation blindness I feared from proprietary workflows that could be changed or taken away at any time, but much faster than I had assumed, and the promise of being able to work through it at this higher level, this new way of working, seemed less and less plausible the more I iterated, even starting over with chunks of the problem in new contexts as many suggest didn't really help. I had deadlines, so I gave up and spent about half of my weekend fixing this by hand, and found it incredibly satisfying when it worked, but all-in this took more time and effort and perhaps more importantly caused more stress than just writing it in the first place probably would have My background is in ML research, and this makes it perhaps easier to predict the failure modes of these things (though surprisingly many don't seem to), but also makes me want to be optimistic, to believe this can work, but I also have done a lot of work as a software engineer and I think my intuition remains that doing precision knowledge work of any kind at scale with a generative model remains A Very Suspect Idea that comes more from the dreams of the wealthy executive class than a real grounding in what generative models are capable of and how they're best employed. I do remain optimistic that LLMs will continue to find use cases that better fit a niche of state-of-the-art natural language processing that is nonetheless probabilistic in nature. Many such use cases exist. Taking human job descriptions and trying to pretend they can do them entirely seems like a poorly-thought-out one, and we've to my mind poured enough money and effort into it that I think we can say it at the very least needs radically new breakthroughs to stand a chance of working as (optimistically) advertised
• jed_fred_lead 8mo ago
  [dead]
• heironimus 8mo ago
  > It was pure, unadulterated slop. I was bewildered. Had I not reviewed every line of code before admitting it? Where did all this...gunk..come from? I chuckled at this. This describes pretty much every large piece of software I've ever worked on. You don't need an LLM to create a giant piece of slop. To avoid it takes tons of planning, refinement, and diligence whether it's LLM's or humans writing it.
• noisy_boy 8mo ago
  Are engineers really doing vibecoding in the truest sense of the word though? Just blindly copy/pasting and iterating? Because I don't. It is more of sculpting via conversation. I start with the requirements, provide some half-baked ideas or approaches that I think may work and then ask what the LLM suggests and whether there are better ways to achieve the goals. Once we have some common ground, I ask to show the outlines of the chosen structure: the interfaces, classes, test uses. I review it, ask more questions/make design/approach changes until I have something that makes sense to me. Only then the fully fleshed coding starts and even then I move at a deliberate pace so that I can pause and think about it before moving on to the next step. It is by no means super fast for any non-trivial task but then collaborating with anyone wouldn't be. I also like to think that I'm utilising the training done on many millions of lines of code while still using my experience/opinions to arrive at something compared to just using my fallible thinking wherein I could have missed some interesting ideas. Its like me++. Sure, it does a lot of heavy lifting but I never leave the steering wheel. I guess I'm still at the pre-agentic stage and not ready to letting go fully.
• INTPenis 8mo ago
  I haven't been vibe coding for more than a few months. It's just a tool with a high level of automation. That becomes clear when you have to guide it to use more sane practices, simple things like don't overuse HTTP headers when you don't need them.
• kmatthews812 8mo ago
  Beware the two extremes - AI out of the box with no additional config, or writing code entirely by hand. In order to get high accuracy PRs with AI (small, tested commits that follow existing patterns efficiently), you need to spend time adding agents (claude.md, agents.md), skills, hooks, and tools specific to your setup. This is why so much development is happening at the plugin layer right now, especially with Claude code. The juice is worth the squeeze. Once accuracy gets high enough you don't need to edit and babysit what is generated, you can horizontally scale your output.
• legitster 8mo ago
  The author makes it sound like such a binary choice, but there's a happy middle where you are having AI generate large blocks of code and then you closely supervise it. My experience so far with AI is to treat it like you're a low-level manager delegating drudgework. I will regularly rewrite or reorganize parts of the code and give it back to the AI to reset the baseline and expectations. AI is far from perfect, but the same is true about any work you may have to entrust to another person. Shipping slop because someone never checked the code was literally something that happened several times at startups I have worked at - no AI necessary! Vibecoding is an interesting dynamic for a lot of coders specifically because you can be good or bad at vibecoding - but the skill to determine your success isn't necessarily your coding knowledge but your management and delegation soft skills.
• edunteman 8mo ago
  The part that most resonates with me is the lingering feeling of “oh but it must be my fault for underspecifying” which blocks the outright belief that models are just still sloppy at certain things
• cubanhackerai 8mo ago
  Taking crazy pills here too. I just bootstrapped a 500k loc MVP with AI Generator, Community and Zapier integration. www.clases.community And is my 3rd project that size, fully vibe coded
• aaroninsf 8mo ago
  Rants like this are - entirely correct in describing frustration - reasonable in their conclusions with respect to how and when to work with contemporary tools - entirely incorrect in intuition about whether "writing by hand" is a viable path or career going forward Like it not, as a friend observed, we are N months away a world where most engineers never looks at source code; and the spectrum of reasons one would want to will inexorably narrow. It will never be zero. But people who haven't yet typed a word of code never will.
• rglover 8mo ago
  You can do both. It's not binary.
• bovermyer 8mo ago
  Interacting with LLMs like Copilot has been most interesting for me when I treat it like a rubber duck. I will have a conversation with the agent. I will present it with a context, an observed behavior, and a question... often tinged with frustration. What I get out of this interaction at the end of it is usually a revised context that leads me figure out a better outcome. The AI doesn't give me the outcome. It gives me alternative contexts. On the other hand, when I just have AI write code for me, I lose my mental model of the project and ultimately just feel like I'm delaying some kind of execution.
  • Geste 8mo ago
    It takes some skill (that you seem to have) to learn to use those LLM. Sad that not everyone see it that way...
• erelong 8mo ago
  The impression I get from the article is of a need to develop better prompts and/or break them down more
• gary17the 8mo ago
  > In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. That's exactly why this whole (nowadays popular) notion of AI replacing senior devs who are capable of understanding large codebases is nonsense and will never become reality.
• asdfman123 8mo ago
  AI is a good tutor, helping you understand what's going on with the codebase, and also helps with minor autocomplete tasks. You should never just let AI "figure it out." It's the assistant, not the driver.
• throwawayffffas 8mo ago
  You'll never find a programming language that frees you from the burden of clarifying your ideas. Relevant xkcd: https://xkcd.com/568/ https://xkcd.com/568/ Even if we reach the point where it's as good as a good senior dev. We will still have to explain what we want it to do. That's how I find it most helpful too. I give it a task and work out the spec based on the bad assumptions it makes and manually fix it.
• wessorh 8mo ago
  An excellent example of the political utility of AI, and how long it takes to figure out that it isn't as useful as the hype might make you think.
• throwawayffffas 8mo ago
  I hear a lot of "I am not a good enough coder..." "It has all the sum of human knowledge..." That's a very bad way to look at these tools. They legit know nothing, they hallucinate APIs all the time. The only value they have at least in my book is they type super fast.
• zem 8mo ago
  I've never used an AI in agent mode (and have no particular plans to), but I do think they're nice for things like "okay, I have moved five fields from this struct into a new struct which I construct in the global setup function. go through and fix all the code that uses those fields". (deciding to move those fields into a new struct is something I do want to be doing myself though, as opposed to saying "refactor this code for me")
• charcircuit 8mo ago
  This is not my experience at all. Claude will ask me follow up questions if it has some. The claim that it goes full steam ahead on its original plan is false.
• pnathan 8mo ago
  a lot of AI assisted development goes into project management and system design. I have been tolerably successful. However, I have almost 30 years of coding experience, and have the judgement on how big a component should be - when I push that myself _or_ with AI, things go hairy. ymmv.
• aerhardt 8mo ago
  I don't predict ever going back to writing code by hand except in specific cases, but neither do I "vibe code" - I still maintain a very close control on the code being committed and the overall software design. It's crazy to me nevertheless that some people can afford the luxury to completely renounce AI-assisted coding.
  • flumpcakes 8mo ago
    > It's crazy to me nevertheless that some people can afford the luxury to completely renounce AI-assisted coding. What's the luxury? The luxury is AI-assisted coding considering how expensive it is for tokens/$.
• periodjet 8mo ago
  Great engagement-building post for the author’s startup, blog, etc. Contrarian and just plausible enough. I disagree though. There’s no good reason that careful use of this new form of tooling can’t fully respect the whole, respect structural integrity, and respect neighboring patterns. As always, it’s not the tool.
• CodeWriter23 8mo ago
  My high school computer lab instructor would tell me when I was frustrated that my code was misbehaving, "It's doing exactly what you're telling it to do". Once I mastered the finite number of operations and behaviors, I knew how to tell "it" what to do and it would work. The only thing different about vibe coding is the scale of operations and behaviors. It is doing exactly what you're telling it to do. And also expectations need to be aligned. Don't think you can hand over architecture and design to the LLM; that's still your job. The gain is, the LLM will deal with the proper syntax, api calls, etc. and work as a reserach tool on steroids if you also (from another mentor later in life) ask good questions.
  • danjl 8mo ago
    "I really hate this damn machine. I wish that they would sell it. It never does what I want it to, only what I tell it."
• gregfjohnson 8mo ago
  One use case that I'm beginning to find useful is to go into a specific directory of code that I have written and am working on, and ask the AI agent (Claude Code in my case) "Please find and list possible bugs in the code in this directory." Then, I can reason through the AI agent's responses and decide what if anything I need to do about them. I just did this for one project so far, but got surprisingly useful results. It turns out that the possible bugs identified by the AI tool were not bugs based on the larger context of the code as it exists right now. For example, it found a function that returns a pointer, and it may return NULL. Call sites were not checking for a NULL return value. The code in its current state could never in fact return a NULL value. However, future-proofing this code, it would be good practice to check for this case in the call sites.
• dudeinhawaii 8mo ago
  On the one hand, I created vibe coded a large-ish (100k LOC) C#, Python, Powershell project over the holidays. The whole thing was more than I could ever complete on my own in the 5 days it took to vibe code using three agents. I wrote countless markdown 'spec' files, etc. The result stunned everyone I work with. I would never in a million years put this code on Github for others. It's terrible code for a myriad reasons. My lived experience was... the task was accomplished but not in a sustainable way over the course of perhaps 80 individual sessions with the longest being multiple solid 45 minute refactors...(codex-max) About those. One of things I spotted fairly quickly was the tendency of models to duplicate effort or take convoluted approaches to patch in behaviors. To get around this, I would every so often take the entire codebase, send it to Gemini-3 Pro and ask it for improvements. Comically, every time, Gemini-3-Pro responds with "well this code is hot garbage, you need to refactor these 20 things". Meanwhile, I'm side-eying like.. dude you wrote this. Never fails to amuse me. So, in the end, the project was delivered, was pretty cool, had 5x more features than I would have implemented myself and once I got into a groove -- I was able to reduce the garbage through constant refactors from large code reviews. Net Positive experience on a project that had zero commercial value and zero risk to customers. But on the other hand... I spend a week troubleshooting a subtle resource leak (C#) on a commercial project that was introduced during a vibe-coding session where a new animation system was added and somehow added a bug that caused a hard crash on re-entering a planet scene. The bug caused an all-stop and a week of lost effort. Countless AI Agent sessions circularly trying to review and resolve it. Countless human hours of testing and banging heads against monitors. In the end, on the maybe random 10th pass using Gemini-3-Pro it provided a hint that was enough to find the issue. This was a monumental fail and if game studios are using LLMs, good god, the future of buggy mess releases is only going to get worse. I would summarize this experience as lots of amazement and new feature velocity. A little too loose with commits (too much entanglement to easily unwind later) and ultimately a negative experience. A classic Agentic AI experience. 50% Amazing, 50% WTF.
• JimmaDaRustla 8mo ago
  k
• ratelimitsteve 8mo ago
  2006: "If I can just write the specs so that the engineer understands them it will write me code that works." 2026: "If I can just write the specs so that the machine understands them it will write me code that works."
• oxag3n 8mo ago
  I tried vibe-coding few years back and switched to "manual" mode when I realized I don't fully understand the code. No, I did read each line of code and understood it, I understood the concepts and abstractions, but I didn't understand all nuances, even those at the top of documentation of libraries LLM used. I tried minimalist example where it totally failed few years back, and still, ChatGPT 5 produced 2 examples for "Async counter in Rust" - using Atomics and another one using tokio::sync::Mutex. I learned it was wrong then the hard way, by trying to profile high latency. To my surprise, here's quote from Tokio Mutex documentation: Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code. The feature that the async mutex offers over the blocking mutex is the ability to keep it locked across an .await point.
• geldedus 8mo ago
  Good luck. I haven't written a single line of code since 6 month ago
• toddmorrow 8mo ago
  Google Maps completely and utterly obliterated my ability to navigate. I no longer actively navigated. I passively navigated. This is no different. And I'm not talking about vibe coding. I just mean having an llm browser window open. When you're losing your abilities, it's easy to think you're getting smarter. You feel pretty smart when you're pasting that code But you'll know when you start asking "do me that thingy again". You'll know from your own prompts. You'll know when you look at older code you wrote with fear and awe. That "coding" has shifted from an activity like weaving cloth to one more like watching YouTube. Active coding vs passive coding
• h4kunamata 8mo ago
  AI can be good under the right circumstances but only if reviewed 100% of the time by a human. Homelab is my hobby where I run Proxmox, Debian VM, DNS, K8s, etc, all managed via Ansible. For what it is worth, I hate docker :) I wanted to setup a private tracker torrent that should include: 1) Jackett: For the authentication 2) Radarr: The inhouse browser 3) qBitorrent: which receives the torrent files automatically from Radarr 4) Jellyfin: Of course :) I used ChatGPT to assist me into getting the above done as simple as possible and all done via Ansible: 1) Ansible playbook to setup a Debian LXC Proxmox container 2) Jackett + Radarr + qBitorrent all in one for simplicity 3) Wireguard VPN + Proton VPN: If the VPN ever go down, the entire container network must stop (IPTables) so my home IP isn't leaked. After 3 nights I got everything working and running 24/7, but it required a lot of review so it can be managed 10 years down the road instead of WTF is this??? There were silly mistakes that make you question "Why am I even using this tool??" but then I remember, Google and search engines are dead. It would have taken me weeks to get this done otherwise, AI tools speed that process by fetching the info I need so I can put them together. I use AI purely to replace the broken state of search engines, even Brave and DuckDuckGo, I know what I am asking it, not just copy/paste and hope it works. I have colleagues also into IT field whose the company where they work are fully AI, full access to their environment, they no longer do the thinking, they just press the button. These people are cooked, not just because of the state of AI, if they ever go look for another job, all they did for years was press a button!!
• originalcopy 8mo ago
  I am still fascinated by how convincing the AI slop can be. I saw way too much code and documentation which made no sense. But it's often not obvious. I read it, I don't get it, I read it again, am I just stupid? I can grab some threads from it, but overall, it just doesn't make sense, it doesn't click for me. And that's when I often realize, it doesn't click, because it's a slop. It's obvious in pictures (e.g., generate a picture of a bike with labels). But in code? It requires more time to look at it than to actually write it. So it just slips reviews, it sometimes even works as it should, but it's damn hard to understand and fix it in the future. Until eventually, nothing can fix it. For the record, I use AI to generate code but not for "vibecoding". I don't believe when people tell me "you just prompt it badly". I saw enough to lose faith.
• nichochar 8mo ago
  Little to no evidence was presented. This is vibe argumenting.
• kshri24 8mo ago
  Accurate and sane take! Current models are extremely good for very specific kinds of tasks. But beyond that, it is a coin toss. Gets worse as the context window goes beyond a few ten thousand tokens. If you have only vibe-coded toy projects (even with the latest fad - Ralph whatever) for anything serious, you can see how quickly it all falls apart. It is quite scary that junior devs/college kids are more into vibe coding than putting in the effort to actually learn the fundamentals properly. This will create at least 2-3 generations of bad programmers down the line.
• h14h 8mo ago
  It'd be easy to simply say "skill issue" and dismiss this, but I think it's interesting to look at the possible outcomes here: Option 1: The cost/benefit delta of agentic engineering never improves past net-zero, and bespoke hand-written code stays as valuable as ever. Option 2: The cost/benefit becomes net positive, and economics of scale forever tie the cost of code production directly to the cost of inference tokens. Given that many are saying option #2 is already upon us, I'm gonna keep challenging myself to engineer a way past the hurdles I run into with agent-oriented programming. The deeper I get, the more articles like this feel like the modern equivalent of saying "internet connections are too slow to do real work" or "computers are too expensive to be useful for regular people".
• AtomicOrbital 8mo ago
  after+30 years writing code in a dozen languages building systems from scratch I love vibe coding ... it's drinking from a fire hose ... in two months I vibe coded a container orchestration system which I call my kubernetes replacement project all in go with a controller deciding which VM to deploy containers onto, agents on each host polling etcd for requests created by the controller ... it's simple understandable maintainable extendable ... also vibe coded go cdk to deploy AWS RDS clusters, API gateway, handful of golang lambda functions, valkey elasticache and a full feature data service library which handles transactions and save points, cache ... I love building systems ... sure I could write all this from scratch by hand and I have but vibe coding quickly exposes me to the broad architecture decisions earlier giving me options to experiment on various alternatives ... google gemini in antigravity rocks and yes I've tried them all ... new devs should not be vibe coding for the first 5 years or more but I lucked into having decades of doing it by hand
• huflungdung 8mo ago
  [dead]
• abcde666777 8mo ago
  This will sound arrogant, but I can't shake the impression that agent programming is most appealing to amateurs, where the kind of software they build is really just glorified UIs and data plumbing. I work on game engines which do some pretty heavy lifting, and I'd be loath to let these agents write the code for me. They'd simply screw too much of it up and create a mess that I'm going to have to go through by hand later anyway, not just to ensure correctness but also performance. I want to know what the code is doing, I want control over the fine details, and I want to have as much of the codebase within my mental understanding as possible. Not saying they're not useful - obviously they are - just that something smells fishy about the success stories.
• radium3d 8mo ago
  I actually haven't come across situation 1 2 or 3 mentioned in the attached video. Generally I iterate on the code by starting a new prompt with the code provided, with enhancements, or provide the errors and it repairs the errors. Generally it gets it within 1-2 iterations. No emotions. Make sure your prompts do not contain fluff, and are straight what you want the code to accomplish and how you want it to accomplish it. I've gone back to code months later and have not had what you described as being shocked about bad code, it was quite easy to understand. Are you prompting the AI to also write variables and function names logically and utilize a common coding standard for whichever type of code you are having it write, such as wordpress coding standards or similar? Perhaps claude isn't the best, I have been experimenting with grok 4.1 thinking and grok expert at the mid-level paid tier. I'll take it a step further and adjust the code myself, start a new prompt and provide that updated code along with my further requests as well. I haven't hit the road blocks mentioned.
• c1505 8mo ago
  It still feels like gambling to me when I use AI code assistants to generate large chunks of code. Sometimes, it will surprise me with how well it does. Other times, it infuriatingly doesn't follow very precise instructions for small changes. This is even when I use it in the way that I often ask for multiple options for solutions and implementations and then choose between them after the AI tool does the course rating. There are many instances where I get to the final part of the feature and realize I spent far more time coercing AI to do the right thing than it would have taken me to do it myself. It is also sometimes really enjoyable and sometimes a horrible experience. Programming prior to it could also be frustrating at times, but not in the same way. Maybe it is the expectation of increased efficiency that is now demanded in the face of AI tools. I do think AI tools are consistently great for small POCs or where very standard simple patterns are used. Outside of that, it is a crapshoot or slot machine.
• kcexn 8mo ago
  As people get more comfortable with AI. I think what everyone is noticing is that AI is terrible at solving problems that don't have large amounts of readily available training data. So, basically if there isn't already an open-source solution available online, it can't do it. If what you're doing is proprietary, or even a little bit novel. There is a really good chance that AI will screw it up. After all, how can it possibly know how to solve a problem it has never seen before?
• bofadeez 8mo ago
  This bubble is going to crash so much harder than any other bubble in history. It's almost impossible to overstate the level of hype. LLMs are functionally useless in any context. It's a total and absolute scam.
• bofadeez 8mo ago
  Opus 4.5 is maybe 10% better than GPT 3.5. It's a total joke and these AI lab CEOs should literally be put in prison with Bernie Maddoff
• MillionY 8mo ago
  You just give up before AI overpass human
• grimmzoww 8mo ago
  Looking for solo devs testing AI continuation tool - DM me
• angelfangs 8mo ago
  I still cannot make AI do anything with quality higher than the function level. I've been using it a lot to write some more complex functions and SQL with a quality level that I find good, but anything higher order and it's a complete clusterfuck. Cannot comprehend this world where people say they are building entire companies and whole products with it.
• animal531 8mo ago
  The funniest thing I've seen GPT do was a while back when I had it try to implement ORCA (Optimal Reciprocal Collision Avoidance). It is a human made algorithm for entities where they just use their own and N neighbours' current radii along with their velocity to calculate mathematical lines into the future, so that they can avoid walking into each other. It came very close to success, but there were 2 or 3 big show-stopping bugs such as it forgetting to update the spatial partitioning when the entities moved, so it would work at the start but then degrade over time. It believed and got stuck on thinking that it must be the algorithm itself that was the problem, so at some point it just stuck a generic boids solution into the middle of the rest. To make it worse, it didn't even bother to use the spatial partitioning and they were just brute force looking at their neighbours. Had this been a real system it might have made its way into production, which makes one think about the value of the AI code out there. As it was I pointed out that bit and asked about it, at which point it admitted that it was definitely a mistake and then it removed it. I had previously implement my own version of the algorithm and it took me quite a bit of time, but during that I built up the mental code model and understood both the problem and solution by the end. In comparison it easily implemented it 10-30x faster than I did but would never have managed to complete the project on its own. Also if I hadn't previously implemented it myself and had just tried to have it do the heavy lifting then I wouldn't have understood enough of what it was doing to overcome its issues and get the code working properly.
• lolive 8mo ago
  May be we will have at last the AI to do literate programming. So it can properly reread and connect big chunks of code it wrote magically in isolation. From that perspective, the AI is following the path of a experienced programmer: specs and docs maintained in parallel of the code will save your .ss in the long run.