13 ms·

Breaking the spell of vibe coding

• altcunn 8mo ago
  [dead]
  • fnordpiglet 8mo ago
    Fascinating - I find the opposite is true. I think of edge cases more and direct the exploration of them. I’ve found my 35 years experience tells me where the gaps will be and I’m usually right. I’ve been able to build much more complex software than before not because I didn’t know how but because as one person I couldn’t possibly do it. The process isn’t any easier just faster. I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement. However one thing I definitely identify with is the trouble sleeping. I am finally able to do a plethora of things I couldn’t do before due to the limits of one man typing. But I don’t build tools I don’t need, I have too little time and too many needs.
    • ncruces 8mo ago
      > I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement. AI is really good to rubber duck through a problem. The LLM has heard of everything… but learned nothing. It also doesn't really care about your problem. So, you can definitely learn from it. But the moment it creates something you don't understand, you've lost control. You had one job.
      • fnordpiglet 8mo ago
        If you’ve worked on a code base built by more than you, you don’t understand and you don’t have control. Part of being an experienced engineer is understanding how to deal with that effectively at scale.
  • thehamkercat 8mo ago
    > when I lean too heavily on LLM-generated code, I stop thinking about edge cases and error handling I have the exact same experience... if you don't use it, you'll lose it
• mathgladiator 8mo ago
  Ive come to the realization after maxing the x20 plan that I have to set clear priorities. Fortunately, I've retired so I'm going focus on flooding the zone with my crazy ideas made manifest in books.
• Kerrick 8mo ago
  > However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled, Domain-Driven Design, Implementing Domain-Driven Design, Design Patterns, The Art of Agile Software Development, 2nd Edition, Clean Architecture, Smalltalk Best Practice Patterns, and Tidy First?. I'm a far better software engineer than I was in 2024. I've also vibe coded [1] a whole lot of software [2], some good and some bad [3]. You can choose to grow in both areas. [0]: https://kerrick.blog/articles/2025/kerricks-wager/ https://kerrick.blog/articles/2025/kerricks-wager/ [1]: As defined in Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge, wherein you still take responsibility for the code you deliver. [2]: https://news.ycombinator.com/item?id=46702093 https://news.ycombinator.com/item?id=46702093 [3]: https://news.ycombinator.com/item?id=46719500 https://news.ycombinator.com/item?id=46719500
  • bikelang 8mo ago
    Of those 3 DDD books - which did you find the most valuable?
    • pipes 8mo ago
      I was going to ask the same thing. I'm self taught but I've mainly gone the other way, more interested in learning about lower level things. Bang for buck I think I might have been better reading DDD type books.
    • skydhash 8mo ago
      Not GP, but the most impactful one I read was Learning DDD from O’Reilly https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131 https://www.amazon.com/Learning-Domain-Driven-Design-Alignin... It presents the main concepts like a good lecture and a more modern take than the blue book. Then you can read the blue book. But DDD should be taken as a philosophy rather than a pattern. Trying to follow it religiously tends to results in good software, but it’s very hard to nail the domain well. If refactoring is no longer an option, you will be stuck with a non optimal system. It’s more something you want to converge to in the long term rather than getting it right early. Always start with a simpler design.
• theYipster 8mo ago
  Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.
  • LPisGood 8mo ago
    I really disagree with this. I don’t think you can be a good software engineer without being a good product manager and a good architect.
    • AnimalMuppet 8mo ago
      You can - but you have to work with a good product manager and a good architect. You have to actually listen to them and trust them.
  • bitwize 8mo ago
    You're doing architect/designer/manager work while being treated, and paid, like a code monkey. This is by design.
    • ozozozd 8mo ago
      It’s also much faster that way. We cut so many corners and make wise bets in what to test a lot and what not to bother with compared to spec-driven development with an LLM.
  • asdff 8mo ago
    The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.
    • 8mo ago
• daxfohl 8mo ago
  I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astounding that CEOs haven't made that connection yet). The latter, you may be less productive than optimal, but might the hands-on training and fundamental understanding of the codebase make up for it in the long run? Additionally, I personally find my best ideas often happen when knee deep in some codebase, hitting some weird edge case that doesn't fit, that would probably never come up if I was just reviewing an already-completed PR.
  • _se 8mo ago
    Very reasonable take. The fact that this is being downvoted really shows how poor HN's collective critical thinking has become. Silicon Valley is cannibalizing itself and it's pretty funny to watch from the outside with a clear head.
    • daxfohl 8mo ago
      I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.
      • fao_ 8mo ago
        I don't think this is the case, because the AI companies are all just shuffling around the same 300 million or trillion to each other.
      • koolba 8mo ago
        More like they’re leasing away deeply discounted steam shovels at below market rates and somehow expecting to turn a profit doing so. The real profits are the companies selling them chips, fiber, and power.
• tjr 8mo ago
  I see AI coding as something like project management. You could delegate all of the tasks to an LLM, or you could assign some to yourself. If you keep some for yourself, there’s a possibility that you might not churn out as much code as quickly as someone delegating all programming to AI. But maybe shipping 45,000 lines a day instead of 50,000 isn’t that bad.
  • written-beyond 8mo ago
    You need to understand the frustration behind these kinds of posts. The people on the start of the curve are the ones who swear against LLMs for engineering, and are the loudest in the comments. The people on the end of the curve are the ones who spam about only vibing, not looking at code and are attempting to build this new expectation for the new interaction layer for software to be LLM exclusively. These ones are the loudest on posts/blogs. The ones in the middle are people who accept using LLMs as a tool, and like with all tools they exercise restraint and caution. Because waiting 5 to 10 seconds each time for an LLM to change the color of your font, and getting it wrong is slower than just changing it yourself. You might as well just go in and do these tiny adjustments yourself. It's the engineers at both ends that have made me lose my will to live.
  • CoinFlipSquire 8mo ago
    I can't believe we're back to using LoC as a metric for being productive again.
    • ozozozd 8mo ago
      Sounds like something who can’t even churn out a measly 10k per day would say. /s
• cmrdporcupine 8mo ago
  "they don’t produce useful layers of abstraction nor meaningful modularization. They don’t value conciseness or improving organization in a large code base. We have automated coding, but not software engineering" Which frankly describes pretty much all real world commercial software projects I've been on, too. Software engineering hasn't happened yet. Agents produce big balls of mud because we do, too.
  • Barrin92 8mo ago
    which is why the most famous book in the world of software development pointed out that the long term success of a software project is not defined by man hours or lines of code written but by documentation, clear interfaces and the capacity to manage the complexity of a project. Maybe they need to start handing out copies of the mythical man month again because people seem to be oblivious to insights we already had a few decades ago
• jackfranklyn 8mo ago
  [flagged]
  • deleted 8mo ago
    [deleted]
  • zozbot234 8mo ago
    > LLMs are good at writing individual functions but terrible at deciding which functions should exist. Have you tried explicitly asking them about the latter? If you just tell them to code, they aren't going to work on figuring out the software engineering part: it's not part of the goal that was directly reinforced by the prompt. They aren't really all that smart.
    • fatata123 8mo ago
      Injecting bias into an already biased model doesn’t make decision smarter, it just makes them faster.
      • e12e 8mo ago
        I think this continued anthropomorphism "Have you tried asking about..." is a real problem. I get it. It quacks like a duck, so seems like if you feed it peas it should get bigger ". But it's not a duck. There's a distinction between "I need to tell my LLM friend what I want" and "I need to adjust the context for my statistical LLM tool and provide guardrails in the form of linting etc". It's not that adding prose description doesn't shift the context - but it assume a wrong model about what is going on, that I think is ultimately limiting. The LLM doesn't really have that kind of agency.
  • mettamage 8mo ago
    > Architecture decisions and domain knowledge are still entirely on you. The typing is faster though. Also, it prevents repetitive strain injury. At least, it does for me.
• lazystar 8mo ago
  i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN... idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.
  • ozim 8mo ago
    idk what you’re doing but proper IDE was doing that for me for past 15 years or more. Like I don’t remember syntax or linting or typos being a problem since I was in high school doing Turbo Pascal or Visual Basic.
    • lazystar 8mo ago
      emacs-nox for 8 years :-)
  • CBarkleyU 8mo ago
    With all due respect, but if you actually wasted hours (multiple) each (!) day on those issues, then yeah, I can fully believe that AI assisted coding 10 or even 100x'd you.
    • habinero 8mo ago
      I uncharitably snarked that AI lets the 0.05X programmers become 0.2X ones, but reading this stuff makes me feel like I was too charitable. I've never had problems with any of those things after I learned what a code editor was.
      • skydhash 8mo ago
        Yep, it may be an issue in notepad, which does not have helper like syntax highlighting, auto indent, and line numbers. But I started with IDLE which has all those things. So my next editor was notepad++ and codeblock.
• deleted 8mo ago
  [deleted]
• samename 8mo ago
  The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace myself.
  • logicprog 8mo ago
    Isn't struggling to get enough sleep or shower enough and so on because you're so involved with the process of, you know, programming, especially interactive, exploratory programming with an immediate feedback loop, kind of a known phenomenon for programmers since essentially the dawn of interactive computing?
    • samename 8mo ago
      Using agents trigger different dopamine patterns, I'd compare it to a slot machine: did it execute it according to plan or did it make a fatal flaw? Also, multiple agents can run at once, which is a workflow for many developers. The work essentially doesn't come to a pausing point.
      • logicprog 8mo ago
        > did it execute it according to plan or did it [have] a fatal flaw? That's most code when you're still working on it, no? > Also, multiple agents can run at once, which is a workflow for many developers. The work essentially doesn't come to a pausing point. Yeah the agent swarm approach sounds unsurvivably stressful to me lol
    • matwood 8mo ago
      Sort of, but the speed at which I can see results and the ability to quickly get unstuck does pull me in more than just coding. While I find both enjoyable, I'm more of a 'end result' person than a 'likes to the type in the code' person. There was a conversation about this a month or so ago referencing what types of people like LLMs and which do not.
• nkmnz 8mo ago
  > A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times! It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.
  • regular_trash 8mo ago
    Can you elaborate? This seems like a simple mistake if they are incorrect, I'm not sure where 33% or 50% come from here.
    • nkmnz 8mo ago
      Their math is 120%-80%=40% while the correct math is (80-120)/120=-33% or (120-80)/80=+50% It’s more obvious if you take more extreme numbers, say: they estimated to take 99% less time with AI, but it took 99% more time - the difference is not 198%, but 19900%. Suddenly you’re off by two orders of magnitude.
    • jph00 8mo ago
      It's not a mistake. It's correct, and is a excellent way to present this information.
  • piker 8mo ago
    I get caught up personally in this math as well. Is a charitable interpretation of the throwaway line that they were off by that many “percentage points”?
    • nkmnz 8mo ago
      That would be correct, but also useless. It matters if 50pp are 50% vs. 100%, 75% vs. 125% or 100% vs. 150%.
  • softwaredoug 8mo ago
    Isn't the study a year old by now? Things have evolved very quickly in the last few months.
• strawhatguy 8mo ago
  Speaking just for myself, AI has allowed me to start doing projects that seemed daunting at first, as it automates much of the tedious act of actually typing code from the keyboard, and keeps me at a higher level. But yes, I usually constrain my plans to one function, or one feature. Too much and it goes haywire. I think a side benefit is that I think more about the problem itself, rather than the mechanisms of coding.
  • strawhatguy 8mo ago
    Actually, I wonder how they measured the 'speed' of coding, maybe I missed it. But if developers can spend more time thinking about the larger problems, that may be a cause of the slowdown. I guess it remains to be seen if the code quality or feature set improves.
• nkmnz 8mo ago
  tl;dr - author cites a study from early 2025 which measured developer speed of “experienced open source developers” to be ~20% slower when supported by AI, while they’ve estimated to be ~20% faster. Note: the study used sonnet-3.5 and sonnet-3.7; there weren’t any agents, deep research or similar tools available. I’d like to see this study done again with: 1. juniors ans mid-level engineers 2. opus-4.6 high and codex-5.2 xhigh 3. Tasks that require upfront research 4. Tasks that require stakeholder communication, which can be facilitated by AI
  • h05sz487b 8mo ago
    > which can be facilitated by AI I’d be thrilled if that AI could finally make one of our most annoying stakeholders test the changes they were so eager to fast track, but hey, I might be surprised.
    • nkmnz 8mo ago
      It can facilitate that, certainly. Idk about the background of that stakeholder, but AI can help drafting communication with the right tone to show the necessity. It can help to write a guide on how to properly test the specific feature. It can write e2e tests that the stakeholder could execute from their environment. Of course, all of that can be done by humans, too. But this discussion is about average speed of a developer, and there’s a reason many companies employ product owners for the stakeholder communication.
• abcde666777 8mo ago
  It's astonishing to me that real software developers have considered it a good idea to generate code... and not even look at the code. I would have thought sanity checking the output to be the most elementary next step.
  • paulryanrogers 8mo ago
    I wonder if this phenomenon comes from how reliable lower layers have become. For example, I never check the binary or ASM produced by my code, nor even intermediate byte code. So vibers may be assuming the AI is as reliable, or at least can be with enough specs and attempts.
    • userbinator 8mo ago
      I have seen enough compiler (and even hardware) bugs to know that you do need to dig deeper to find out why something isn't working the way you thought it should. Of course I suspect there are many others who run into those bugs, then massage the code somehow and "fix" it that way.
      • paulryanrogers 8mo ago
        Yeah, I know they exist in lower layers. Though layers being mostly deterministic (hardware glitches aside) I think they are relatively easy to rely on. Whereas LLMs seem to have an element of intentional randomness built into every prompt response.
  • deleted 8mo ago
    [deleted]
  • jascha_eng 8mo ago
    I think people got fatigued by reviewing already. Most code is correct that AI produces so you end up checking out eventually. A lot of the time the issue isn't actually the code itself but larger architectural patterns. But realizing this takes a lot of mental work. Checking out and just accepting what exists, is a lot easier but misses subtleties that are important.
• atleastoptimal 8mo ago
  That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code: https://fortune.com/2026/01/29/100-percent-of-code-at-anthropic-and-openai-is-now-ai-written-boris-cherny-roon/ https://fortune.com/2026/01/29/100-percent-of-code-at-anthro... Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via the products they are now giving almost entirely to coding agents.
  • reppap 8mo ago
    One thing I like to think about is: If these models were so powerful why would they ever sell access? They could just build endless products to sell, likely outcompeting anyone else who needs to employ humans. And if not building their own products they could be the highest value contractor ever. If you had midas touch would you rent it out?
    • atleastoptimal 8mo ago
      Well there are models that Anthropic, OpenAI and co. have access to that they haven't provided public API's for, due to both safety, and what you've cited as the competitive advantage factor. (like Openai's IMO model, though it's debatable if it represented an early version of GPT 5.1/2/3 or something else) https://sequoiacap.com/podcast/training-data-openai-imo/ https://sequoiacap.com/podcast/training-data-openai-imo/ The thing however is the labs are all in competition with each other. Even if OpenAI had some special model that could give them the ability to make their own Saas and products, it is more worth it for them to sell access to the API and use the profit to scale, because otherwise their competitors will pocket that money and scale faster. This holds as long as the money from API access to the models is worth more than the comparative advantage a lab retains from not sharing it. Because there are multiple competing labs, the comparative advantage is small (if OpenAI kept GPT-5.X to themselves, people would just use Claude and Anthropic would become bigger, same with Google). This however may not hold forever, it is just a phenomena of labs focusing more on heavily on their models with marginal product efforts.
    • 8mo ago
• claudeomusic 8mo ago
  I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively. The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatically more efficient than the previous era? 1000%. Some of the things I’ve done in the past month I really didn’t think were possible. I was skeptical but I think a new era is upon us and everyone should be hustling to adapt. My favorite analogy at the moment is that for awhile now we’ve been bowling and been responsible for knocking down the pins ourselves. In this new world we are no longer the bowlers, rather we are the builders of bumper rails that keep the new bowlers from landing in the gutter.
  • skydhash 8mo ago
    What are such new ways? You’re being very vague about them.
    • Kye 8mo ago
      A post I saw the other day from someone in a similar situation who did share what changes were made: https://bsky.app/profile/abumirchi.com/post/3meoqzl5iec2o https://bsky.app/profile/abumirchi.com/post/3meoqzl5iec2o
    • claudeomusic 8mo ago
      To be a little less vague - I think the biggest difference I’ve seen is where time is spent. In the past since I know what I’m doing I’d go straight into dev mode pretty quickly . Going straight into dev mode with an LLM pretty much always goes wrong - a lot more time is spent in planning and in setting up constraints for how an agent can operate before letting it loose so that once you set it free it can run.
    • claudeomusic 8mo ago
      It’s a crude comparison but it’s a lot more similar to what I’ve done in my management roles than what I’ve done as a dev.
• atleastoptimal 8mo ago
  I think most of the issues with "vibe coding" is trusting the current level of LLM's with too much, as writing a hacky demo of a specific functionality is 1/10 as difficult as making a fully-fledged, dependable, scalable version of it. Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional demo of a saas product, but they are far from being able to one-shot the entire engineering effort of a company like slack. However, I don't see why the rate of improvement will not continue as it has. The current generation of LLM's haven't been event trained yet on NVidia's latest Blackwell chips. I do agree that vibe-coding is like gambling, however that is besides the point that AI coding models are getting smarter at a rate that is not slowing down. Many people believe they will hit a sigmoid somewhere before they reach human intelligence, but there is no reason to believe that besides wishful thinking.
  • mdavid626 8mo ago
    Of course - and autonomous driving is 1 year away.
    • dummydummy1234 8mo ago
      As an aside, I wonder if automated driving would be one year away if we did not need to worry about it killing people. Like if the only possible issues were property damage, I kind of think it would be here. You just insure the edge cases.
    • atleastoptimal 8mo ago
      I have ridden in a Waymo dozens of times with no issues. I've also used Tesla's self-driving to similar efficacy. That's the nature of all tech, it keeps not being good enough, until it is, and then everything changes.
• egedev 8mo ago
  [dead]
• somewhereoutth 8mo ago
  "Hell is other people's code" Not sure why we'd want a tool that generates so much of this for us.
  • charcircuit 8mo ago
    It can be told just as easily to delete code. It can generate instructions to remove lines.
• maplethorpe 8mo ago
  I think tech journalism needs to reframe its view of slot machines if it's to have a productive conversation about AI. Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.
  • shinryuu 8mo ago
    At the expense of other people. Slot machines is a negative sum game.
    • danny_codes 8mo ago
      Not for the house
• vibe101 8mo ago
  I’ve learned the hard way that in coding, every line matters. While learning Go for a new job, I realised I had been struggling because I overused LLMs and that slowed my learning. Every line we write reflects a sense of 'taste' and needs to be fully controlled and understood. You need a solid mental model of how the code is evolving. Tech CEOs and 'AI researchers' lack the practical experience to understand this, and we should stop listening to them about how software is actually built.
• danielrhodes 8mo ago
  Articles like this amount to a straw man. People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years. Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.
  • h05sz487b 8mo ago
    Of course people think that, because that is exactly how those agents are being sold. If you tell management that this speeds up the easy part, typing the code, they are convinced you are using it wrong. They want to save 90% of software development cost and you are telling them that’s not possible.
  • krater23 8mo ago
    Thats exactly the thing what the term vibecoding describes.
• VerifiedReports 8mo ago
  Step 1. Stop calling it "vibe coding."
• charcircuit 8mo ago
  >Anthropic CEO Dario Amodei predicted that by late 2025, AI would be writing 90% of all code Was this actually a failed prediction? A article claiming with 0 proof that it failed is not good enough for me. With so many people generating 100% of their code using AI. It seems true to me.
• wittlesus 8mo ago
  [dead]
  • CoinFlipSquire 8mo ago
    My gripe with "developer accepts bad code without reading it" is two fold. 1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved. 2. Where exactly is the skill to know good code from bad code supposed to come from? I hear this take a lot I don't know any serious engineer that can honestly say that they can recognize good code from bad code without spending time actually writing code. It's makes the people asking for this look like that meme comic about the dog demanding you play fetch but not take the ball away. "No code! Only review!" You don't get one without the other.
    • RsAaNtDoYsIhSi 8mo ago
      "Where exactly is the skill to know good code from bad code supposed to come from?" Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Also Teaches you how to convert procedures into analytic solutions into numerical solutions aka a single function that gives you an answer through determining the indeterminate of an inductive reasoning (converting a series, procedure or recursive function into an equation that gives you an answer instead of iterating and being dumb.) Networking. (error checking techniques, P2P stuff) Compilers. (Dragon book.) Math. Linear Algebra. (Rocket science) Abstract Algebra (Crypto stuff, compression) Theory of Equations (functional programming). Statistics (very helpful). Geometry. (Proofs). Taking all these classes makes you smart and a good programmer. "Programming" without them means you're... well. Hard to talk to. I don't think you need to write any code to be a good programmer. IMHO.
      • 8mo ago
• throwaway7783 8mo ago
  Everyone seems to have different ways to deal with AI for coding and have different experiences. But Armin's comment quoted in the article is spot on. I have seen a friend do exactly the same thing, vibe coded an entire product hooked to Cursor over three months. Filled with features no one uses, feeling very good about everything he built. Ultimately it's his time and money, but I would never want this in my company. While you can get very far with vibe coding, without the guiding hands and someone who understands what's really going on with the code, it ends up in a disaster. I use AI for the mundane parts, for brainstorming bugs. It is actually more consistent than me in covering corner cases, making sure guard conditions exist etc. So I now focus more on design/architecture and what to build and not minutea.
  • fragmede 8mo ago
    What disaster befell your friend after those three months?
    • throwaway7783 8mo ago
      Several, but I can't quite say it here. And I meant it for the codebase, not the person themselves
• gaigalas 8mo ago
  For most people, blackjack is gambling. There are non-gamblers who play it though. You can just count cards and eventually beat the odds with skill. I wonder if there's something similar going on here.
• JSR_FDED 8mo ago
  Twice I’ve used Claude Code for something important and complex. Stunning initial speed and time savings, all given back eventually as it became apparent that some fatally flawed assumptions were baked into the code right from the beginning. The initial speed is exactly what the article describes, a Loss Disguised as a Win.
  • ozozozd 8mo ago
    Your wording painted the picture of a drug high in my mind, probably an upper. Requiem for Dream style, amazing “Summer”, followed the brutal come down that is “Winter.” Thank you for not using an LLM.
  • EagnaIonat 8mo ago
    I've found Claude works so much better if you build a CLAUDE.md and tell it that you want it to be an interactive design process. It helps formalise your plan, then creates some code, you review, talk about what you believe to be wrong or asking it why it took that approach, or even telling it to take the approach that you want. The end result a world of difference, and I feel I have a better grasp of what is going on in the whole application.
• wazHFsRy 8mo ago
  I think right now a good approach can be using AI everywhere where it helps us in doing the hard work. Not taking the hard work over, but making the task easier in a supporting role. Few things that work really well for me: - AI creating un-opinionated summaries of PRs to help me get started reviewing - AI being an interactive tutor while I’ll still do the hard work of learning something new [1] - AI challenging my design proposal QA style, making me defend it - boilerplate and clear refactorings, while I’ll build the abstractions [1] https://www.dev-log.me/jokes_on_you_ai_llms_for_learning/ https://www.dev-log.me/jokes_on_you_ai_llms_for_learning/
• bob1029 8mo ago
  The #1 predictor of success here is being able to define what success looks like in an obnoxiously detailed manner. If you have a strong vision about the desired UI/UX and you constantly push for that outcome, it is very unlikely you will have a bad time with the current models. The workflow that seems more perilous is the one where the developer fires up gas town with a vague prompt like "here's my crypto wallet please make me more money". We should be wielding these tools like high end anime mech suits. Serialized execution and human fully in the loop can be so much faster even if it consumes tokens more slowly.
  • deleted 8mo ago
    [deleted]
  • mettamage 8mo ago
    That's how I'm using it :) I have like 15 personalized apps now, mostly chrome extensions
• matheus-rr 8mo ago
  The part about "dark flow" resonates strongly. I've seen this pattern play out with a specific downstream cost that doesn't get discussed enough: maintenance debt. When someone vibe-codes a project, they typically pin whatever dependency versions the LLM happened to know about during training. Six months later, those pinned versions have known CVEs, are approaching end-of-life, or have breaking changes queued up. The person who built it doesn't understand the dependency tree because they never chose those dependencies deliberately — the LLM did. Now upgrading is harder than building from scratch because nobody understands why specific libraries were chosen or what assumptions the code makes about their behavior. This is already happening at scale. I work on tooling that tracks version health across ecosystems and the pattern is unmistakable: projects with high AI-generation signals (cookie-cutter structure, inconsistent coding style within the same file, dependencies that were trendy 6 months ago but have since been superseded) correlate strongly with stale dependency trees and unpatched vulnerabilities. The "flow" part makes it worse — the developer feels productive because they shipped features fast. But they're building on a foundation they can't maintain, and the real cost shows up on a delay. It's technical debt with an unusually long fuse.
• nathias 8mo ago
  this is quite literally just coping and seething
• localhoster 8mo ago
  Agent assisted coding is just vibe-coding in disguise. You still only glance over the code "just so it won't be considered vibe-coding", but at the end of the day, if you invest a proper amount of time reading and reasoning with the generated code - than it would take the exact same time, as if you would have wrote it by hand. By not going through this process, you loose intent, familiarity, and opinions. It's the exact same as vibe-coding.
• kittbuilds 8mo ago
  [dead]
• JanneVee 8mo ago
  My little anecdote of breaking the spell. Really I might not been truly under the spell, but I had to go far in to my project to loose the "magic" of the code. The trick was simply going back to a slower way of using it with a regular chat window. Then really reading the code and interrogation everything that looks odd. In my case I saw a .partial_cmp(a).unwrap() in my rust code and went ahead an asked is there an alternative. The LLM returned .total_cmp(a) as an alternative. I continued on asking why it generated the "ugly" unwrap, LLM returned that it didn't become available later version of rust with only a tiny hint of that it .partial_cmp is more common in the original trainingsets. The final shattering was simply asking it why it used .partial_cmp and got back "A developer like me... ". No it is an LLM, there is somewhere in the system prompt to anthropomorphize the responses and that is the subtle trick beyond "skinner box" of pulling the lever hoping to get useful output. There are a bunch of subtle cues that hijacks the brain of treating the LLM like a human developer. So when going back to the agentic flow in my other projects I try to disabling these tricks in my prompts and the AGENTS file and the results are more useful and I'm more prone to realizing when the output has sometimes has outdated constructs and be more specific on what version of tooling I'm using. Occasionally scraping whole branches when I realize that it is just outdated practices or simply a bad way of doing things that are simply more common in the original training data, restarting with the more correct approaches. Is it a game changer... no but it makes it more like a tool that I use instead of a developer of shifting experience level.
• jackfranklyn 8mo ago
  [flagged]
  • rafaelmn 8mo ago
    > Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review. How is that different from handwritten code ? Sounds like stuff you deal with architecturally (auditable/with review/rollback) and with tests.
    • kamaal 8mo ago
      >>How is that different from handwritten code ? I think the point he is trying to make is that you can't outsource your thinking to a automated process and also trust it to make the right decisions at the same time. In places where a number, fraction, or a non binary outcome is involved there is an aspect of growing the code base with time and human knowledge/failure. You could argue that speed of writing code isn't everything, many times being correct and stable likely is more important. For eg- A banking app, doesn't have be written and shipped fast. But it has to be done right. ECG machines, money, meat space safety automation all come under this.
      • rafaelmn 8mo ago
        Replace LLM with employee in your argument - what changes ? Unless everyone at your workplace owns the system they are working on - this is a very high bar and maybe 50% of devs I've worked with are capable of owning a piece of non trivial code, especially if they didn't write it. Realiy is you don't solve these problems by to relying on everyone to be perfect - everyone slips up - to achieve results consistently you need process/systems to assure quality. Safety critical system should be even better equipped to adopt this because they already have the systems to promote correct outputs. The problem is those systems weren't built for LLMs specifically so the unexpected failure cases and the volume might not be a perfect fit - but then you work on adapting the quality control system.
• KronisLV 8mo ago
  > However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. Consider the case where you don’t grow your software engineering or problem-solving skills, yet the forecasts of AI coding agents being able to handle ever expanding complexity don’t come to pass. Where does this leave you? The current Claude Code setup with Opus 4.6 and their Max subscription (the 100 USD one was enough for me, don't need the 200 USD one) was enough for me to do large scale refactoring across 3 codebases in parallel. Maybe not the most innovative or complex tasks in absolute terms, but it successfully did in one day what would have taken regular developers somewhere between 1 and 2 weeks in total. I hate to be the anecdote guy, but with the current state of things, I have to call bullshit on the METR study, there is no world in which I work slower with AI than without. Maybe with the Cerebras Code subscription where it fucked some code up and I had to go back to it and fix it twice, but that's also because Vue had some component wrapping and SFC/TypeScript bullshit going on which was honestly disgusting to work on, but that's because you really need the SOTA models. The current ones are good enough for me even if they never improved further. I never want to go back to soul sucking boilerplate or manual refactoring. It works better than I can alone. It works better than my colleagues can. I think I might just suck, maybe I'm cooked because at this point I mostly just guide and check it and sometimes do small code examples for what I want and explore problems instead of writing all of it myself, but honestly a lot of work was done in JetBrains IDEs previously where there's also lots of helpful snippets, autocomplete, code inspections and so on, so who knows - maybe it doesn't matter that I write everything line by line myself.
  • fcantournet 8mo ago
    Do you think your organisation as a whole is doing more ? Is the more being done actually useful ? i.e: is the outcome better ?
    • KronisLV 8mo ago
      Not an org where everyone uses the tech to such a degree: also were late adopters of Docker for example, in large part got around to it due to my initiative (100-200 people org, so small). But personally: yes and to an immense degree. The excuse “we don’t have the time for this” has pretty much evaporated when it comes to me. I do more than colleagues do and have gotten enough automation working that the AI will be made to iterate and fix its code to my desires before I ever see a line of it. I’ve added tests to entire systems thanks to it, fixed bugs across the codebase, added a bunch of additional quality control scripts and tools, improved CI, built and shipped not only entire features but systems. I can now work on about 3 projects in parallel, even if it can be super tiring. But hey, I’m also working more on side projects outside of work and nice utilities I never had time for. I don’t really build in public sadly, but it very much is a force multiplier and makes me hate my job less sometimes (everyone has a horrible brownfield codebase or two).
• big-chungus4 8mo ago
  There are different kinds of coding - web dev, low level coding, software, research, data science. There are some kinds of coding where carefully designing the architecture is important, and AI might not produce satisfactory code. Some kinds of coding, on the other hand, can benefit very strongly from AI. I suspect that many people who specialize in a particular area of coding form opinions based on how useful AI is in that area, and those opinions are perfectly valid for what coding means to them, but don't generalize to other people with different specializations.
• kachapopopow 8mo ago
  I don't know this feels extremely wrong I've put out more things (including open source for the first time in a long time) that I still feel proud of since at the end of the way I manually review everything and fix whatever I don't like. But I think this only works is because I have a decade of experience in basically every field in the programming space and I had to learn it all without AI. I know exactly what I want from AI where opus 4.6 and codex 5.3 understands that and executes on it faster than I could ever write.
• deleted 8mo ago
  [deleted]
• anvevoice 8mo ago
  [dead]
• d-j-k 8mo ago
  [dead]
• jeffrallen 8mo ago
  > Vibe coding is the creation of large quantities of highly complex AI-generated code, often with the intention that the code will not be read by humans. She unfortunately lost me at the first sentence. I cannot get business value out of that, so I don't do that at work. What I can do is design a situation where I can get business value out of having the AI agent do one thing where the details are too annoying/boring for me to do. Then I read the PR and I decide if the parts about where the data comes from, how it is massaged, etc are right. Then I scan over the HTML and CSS templating garbage I have no interest in and then I post the PR for review. This is exactly the opposite of what she's talking about, and it's working great for me and my colleagues.
• intellirim 8mo ago
  [dead]
• EagnaIonat 8mo ago
  2017 GPT could generate text that looked factual and well written but was total garbage. Compare that to 2023. The technology is accelerating. Hard projects from early last year are now trivial for me. Even AI related tools we are using internally are being made redundant from open source models and new frameworks (eg. OpenClaw). It feels like we are in the AI version of "Don't look up". Everyone is on borrowed time, you should be looking at how to position yourself in an AI world before everyone realises.
• chrisjj 8mo ago
  > “People who go all in on AI agents now are guaranteeing their obsolescence. If you outsource all your thinking to computers, you stop upskilling, learning, and becoming more competent” Likewise those people are guaranteeing "AI"s obsolesence. The parrots need humans to feed them.
• linsomniac 8mo ago
  >Should you gamble your career? [...] Consider the case where [you let your skills stagnate and AI falls flat]. Sure. But the converse is true as well: consider the case where you don't learn the AI tooling and AI does improve apace. That is also gambling your career. Are you ready for pointed questions being asked about why you spent 2 days working on something that AI can do in 15 minutes, so be prepared with some answers for that.
  • written-beyond 8mo ago
    "Learn AI tooling" What is there to learn, honestly? People act like it's learning to write a Linux driver. The maximum knowledge you need how to write a plan or text file. Maybe throw in a "Plz no mistakes" There's no specific model, a better one comes out every month, everything is stochastic.
    • linsomniac 8mo ago
      >What is there to learn, honestly? With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this. Things to learn: - What agent are you going to use? - What skills are you going to use? - What MCPs are you going to use? - What artifacts are you going to provide beyond the prompt? - How are you going to structure it so the tooling can succeed without human interaction? - Are you going to use agent orchestration and if so which? - Are you going to have it "ultrathink" or not? - Are you going to use a PRD or a checklist or the toolings own planning? - Which model or combination of models are you going to use today? (Yes, that changes) - Do you have the basic English (or whatever) skills to communicate with the model, or do you need to develop them? (I'm seeing some correlations between people with poor communication skills and those struggling with AI) Those are a few off the top of my head. "Plz no mistakes" is not even a thing.
      • written-beyond 8mo ago
        I can bet that a single standard instance of existing tool like codex and Claude Code to do whatever someone with a convoluted setup like that can. It could be marginally slower if you but it's all literally just English language text files. I use codex almost everyday, none of that is necessary unless you're trying to flatten up your resume. It's micro services all over again, a concept useful for some very select organisations, that should've been used carefully turned into a fad every engineer had to try shoe horn into their stack.
• injidup 8mo ago
  Fuck vibe coding. If you want a system that actually stays stable, use OpenSpec (or something like it) to build a closed-loop rig where your requirements drive the code and the code proves it met the requirements. In one weekend, I built a system that processes OpenSpec requirements into IMGUI automatic testing scripts. It captures screenshots, compiles them into a report, and assigns each image a prompt—essentially a requirement snippet—that tells a multimodal LLM exactly what to look for. Claude is incredible at stitching these types of tools together. Once you have that closed loop, you can let an agent loose on features and just let the code it writes converge on the spec. The golden rule: If you don't like the results, change the spec. Don't shortcut or "vibe code" a bug away. This keeps the guardrails on. For every feature you add, you have to think about how to validate it automatically. Even a basic smoke test that raises a flag for human review is better than nothing. Think about the workflow: capture screenshots of all your app workflows and commit them to Git as a baseline. On the next commit, run fast smoke tests. If the images match, you’re good. If they differ, the LLM analyzes the diff against the requirements and proposes a fix for either the code or the spec. Rigs like this used to take teams years to build; now you can build them in a few days with a coding assistant. It’s simple, it’s stable, and it actually scales.
• signatoremo 8mo ago
  Reading the blog, I can’t help thinking about the saying “It is difficult to get a man to understand something, when his salary depends on his not understanding it”. HN often bring up that quote pretty quickly whenever author of an article is perceived to be bias one way or another. I’m surprised it hasn’t been mentioned in the comments here.
• Ronrey 8mo ago
  50 years writing software. I use AI heavily — it collapsed my build cost by 40-60x and I run 56 microservices as a solo founder. But I read every line. I design every boundary. AI is the best junior engineer I've ever worked with, and like every junior engineer, it needs supervision. The problem isn't the tool — it's people skipping the decades of judgment that tell you when the tool is wrong.
• dpitkevics 7mo ago
  Great discussion. I've been building in this space and think the truth is somewhere in the middle. The real value isn't in "vibe coding" everything from scratch - it's in having the right architecture and patterns that AI can work within. That's why I built VCSK (Vibe Coding Starter Kit) - it gives you a solid NextJS foundation with proven patterns, then you can vibe code features on top of that foundation. The difference is architectural discipline. When you start with proper auth, DB setup, deployment pipeline, and component structure, AI becomes incredibly productive for building features. When you ask AI to architect everything from scratch, you get the dead-end architectures you mentioned. I still write the critical business logic by hand, still review every PR, and still understand the codebase deeply. But for UI components, API endpoints that follow established patterns, and data transformations? AI is genuinely faster than manual coding now. The key insight: "vibe coding" isn't a replacement for engineering judgment - it's a force multiplier when you have the foundation right.