33 ms·

Vibe engineering

• simonw 1y ago
  Just added this note to the end, as part of my justification for picking such an obviously stupid term for this: > I’ve tried in the past to get terms like AI-assisted programming to stick, with approximately zero success. May as well try rubbing some vibes on it and see what happens.
  • daveguy 1y ago
    Seems like most of the benefit of "vibe engineering" in your description comes from using straightforward best practices of software engineering. How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers?
    • simonw 1y ago
      The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you. Getting good results out of that team is hard, because the bottleneck is how quickly you can review their workflow and point them in new directions. Understanding techniques like TDD, CI, linting, specification writing, research spikes etc turns out to be key to unlocking that potential. That's why experienced software engineers have such a big advantage, if they choose to use it.
      • zdragnar 1y ago
        I've yet to get any quality code out of one, though I don't try particularly hard either. I'd rather spend my time actually coding, especially since all the positive stories about enhanced productivity are anecdotes, and the hard data remains far less supportive of the claim.
        • mmasu 1y ago
          While I don’t agree with you, I keep a healthily skeptical outlook and am trying to understand this too - what is the hard data? I saw a study a while ago about drops in productivity when devs of OSS repos were AI assisted, but sample size was far too low and repos were quite large. Are you referring to other studies or data supporting this? Thanks!
          • pcl 1y ago
            I, individually, am certainly much more productive in my side projects when using AI assistance (mostly Claude and ChatGPT). I attribute this to two main factors: First, and most important, I have actually started a number of projects that have only lived in my head historically. Instead of getting weighed down in “ugh I don’t want to write a PDF parser to ingest that data” or whatever, my attitude has become “well, why not see if an AI assistant can do this?” Getting that sort of initial momentum for a project is huge. Secondly, AI assistants have helped me stretch outside of my comfort zone. I don’t know SwiftUI, but it’s easy enough to ask an AI assistant to put things together and see what happens. Both these cases refer almost necessarily to domains I’m not an expert in. And I think that’s a bigger factor in side projects than in day jobs, since in your day job, it’s more expected that you are working in an area of expertise. Perhaps an exception is when your day job is at a startup, where everyone ends up getting stretched into domains they aren’t experts in. Anyways, my story is, of course, just another anecdote. But I do think the step function of “would never have started without AI assistance” is a really important part of the equation.
          • XenophileJKO 1y ago
            Ithink there are also 2 factors to this. 1. Learning curve: Just like any skill there is a learning curve on how to get high quality output from an LLM. 2. The change in capabilities since recent papers were authored. I started intensively using the agentic coding tools in May. I had dabbled with them before that, but the Claude 3.7 release really changed the value proposition. Since May with the various Claude 4, 4.1 and 4.5 (and GPT-5) the utility of the agentic tools has exploded. You basically have to discard any utility measure before that inflection point, it just isn't super informative.
      • dlisboa 1y ago
        I’d say what you’re doing is architecting, like the old term for “software architect”. Those are professional who know how to design a system from a high level and have the experience to judge a good implementation of it but they themselves do not write the code. Likewise real world architects have the skills to design a building but do not care or know how to build it, relying on engineers for that. I think it’s important to distinguish because we’re increasingly seeing a trend towards final product over production, meaning these “vibe” people want the tool in the end and consider the steps in between to be just busywork and AI can do for them. That’s closer to product design than to engineering. If I can imagine Monalisa and write that thought to paper, communicating that thought and getting a painter to paint it for me does not make me Da Vinci.
        • anthuswilliams 1y ago
          If you had developed novel techniques of sfumato and chiaroscuro, spun new theories of perspective and human anatomy, invented new pigments, and then explained all of that to a journeyman painter, with enough coaching, detail, and oversight to ensure the final product was what you envisioned, I would argue that 100% makes you Da Vinci. Da Vinci himself likely had dozens of nameless assistants laboring in his studio on new experiments with light and color, new chemistry, etc. Da Vinci was Da Vinci because of his vision and genius, not because of his dexterity with his hands.
        • alchemism 1y ago
          It might make you Andy Warhol, though.
      • arscan 1y ago
        Hmmm, I think it’s a bit paradoxical to try to come up with a fun term to encourage the spread of the concept, as the concept itself is quite dull by definition. It’s just software engineering. Boring process stuff where you do a bunch of other things around the ‘building’ part that lets you scale up with quality. Vibe is about fun and go-with-the-flow. This isn’t that. It should connote pocket protectors, not sunglasses. Right? Clearly I’m not in marketing. Regardless, I’m delighted that this has gotten people to ‘independently discover’ software engineering best practices on their own.
      • AdieuToLogic 1y ago
        >> How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers? > The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you. Funny thing is, the least time consuming aspect of making programs is encoding solutions in source form. For example, a reasonable typist can produce thousands of text lines per workday if they know what must be typed (such as transcribing documents). What takes longest when producing programmatic solutions is understanding what must be typed in the first place. After that, the rest is just an exercise in typing and picking good file/type/variable names.
  • mkozlows 1y ago
    I really wish I could like this term, because I agree the world needs a pithy, memorable one for what you're describing. But alas, I don't think this is it, either.
  • layer8 1y ago
    We can resurrect CASE: https://en.wikipedia.org/wiki/Computer-aided_software_engineering https://en.wikipedia.org/wiki/Computer-aided_software_engine... “casing”?
    • phs318u 1y ago
      CAISE? Computer Aided Intelligent Software Engineering
      • layer8 1y ago
        That would be overselling it. ;)
        • bigiain 1y ago
          CASASE? Computer Aided Spicy Autocomplete Software Engineering
          • willvarfar 1y ago
            [dead]
  • saberience 1y ago
    Question, why is it seemingly so super important for you to coin a term for this? Especially a term which comes across as so demeaning and devaluing to engineers (like me and yourself!) I absolutely do not want my non-engineer friends and colleagues think I am "vibe engineering", it sounds trivial and dumbs down the discipline. I personally believe being an engineer of some kind requires work, learning, patience, discipline, and we should be proud of being engineers. There's no way in hell I would go around and saying I'm a "vibe engineer" now. It would be like going around and saying I'm a vibe architect! Who would want to live in a skyscraper designed by a "vibe architect" ??
    • simonw 1y ago
      I don't think you should call yourself a "vibe engineer" because you use AI tooling, just like I don't think you should call yourself a "continuous integration engineer" if part of your job role occasionally involves configuring GitHub Actions. But the act of working on GitHub Actions could be referred to as "continuous integration engineering", just like the act of figuring out how best to build software engineering processes around LLM tools could be called "vibe engineering".
• anonEbWZRLG 1y ago
  Thank you for writing this, Simon. I'm using an anonymous account not tied to my main one, so if the mods want to delete it, go ahead, but I really need to rant. My company has been taking this same approach for the past two months. While the rest of the world is warning about the effects of vibe coding and AI-slop, we're fully embracing it, calling it "working smart" and "automate all things!" It's utterly ridiculous. It feels like the PMs and higher-ups have no idea how much tech debt we're creating right now. For the past few weeks, going to work has felt like going back to school, everyone's showing off their "homework", and whoever has the coolest vibecoded instructions.md or pipeline gets promoted. I'm slowly burning out, and I was one of the people who actually liked the technology behind all this.
  • rozal 1y ago
    [dead]
  • accrual 1y ago
    It's interesting to see the differences in industry adoption. My company just recently made Copilot an official tool for use. We're in a safety-oriented industry that moves more slowly. I do use it, but mostly just to tighten up existing code or get ideas for a refactor. Meanwhile, I have a client project where my counterpart is definitely senior to me and excitedly shares how AI is helping them solve novel problems each week!
  • gtsop 1y ago
    I can totally relate, very similar situation here. I am currently kind of an anti-AI black sheep in engineering department because I refuse to fully embrace the exponentials and give in to the vibes. I avoid burnout by simply switching off my brain from all this noise about vibe coding - i have thought hard and long, i know the way this is being implemented is wrong, i know they will create problems for themselves down the road (they already have, the signs are already there), i will be here to dig them out when the time comes. So far I don't see anyone shipping faster or better with AI than I can manually, so I'm good.
• grahac 1y ago
  Thank you Simon! Too many people conflate non-engineer vibe coding with engineers using ai to make themselves much more productive. We need different terms!
• eevmanu 1y ago
  I think this complements in a good way with "context engineering"[1], that's great. [1] https://simonwillison.net/2025/Jun/27/context-engineering/ https://simonwillison.net/2025/Jun/27/context-engineering/
• _jplc 1y ago
  Vibe engineering is what vibe coders think they do.
• flakiness 1y ago
  "Vibe coding" sounds too good. Catchy, ridiculous and still cool. It'd be hard to beat. It's a genius move from Andrej Karpathy.
  • vunderba 1y ago
    Different strokes I guess. I've always thought it sounded pretty stupid (right up there with asshat and awesomesauce). Conjures up an image of the Big Lebowski writing code while listening to a cheech & chong album.
    • jchanimal 1y ago
      Yes, that exactly. If you have to read the code or the manual, you’re not vibe coding. I think vibe coding is super good for the industry and people in general.
    • wilsonnb3 1y ago
      I feel like “memetic” is probably the best descriptor, you either love it or hate it but either emotion is a good way for something to stick in your brain. I am on the stupid side, personally.
  • CuriouslyC 1y ago
    Except that we're not going to be "coding" very soon. We're going to be firing off jobs that get tracked in VCS, gated through CI, then reviewed by a panel of agents with different specialties. At the end you'll have a few select sections of code that these agents flagged for human review, and thousands of lines of stuff that you don't need to worry about.
    • vibefeelsgood 1y ago
      This guy selling AI snake oil btw. In case it wasn't obvious.
      • CuriouslyC 1y ago
• worik 1y ago
  I am mildly disappointed I was hoping that "vibe engineering" was going to be designing g bridges in the same way people think they can build apps with vibe coding That would be alarming
• peteforde 1y ago
  My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code. I've used GPT to rapidly get up to speed with just about every aspect of circuit design, CAD, CNC... the list is long. Coding is often involved in most of these domains now, but if everything is assumed to be code-first, it leaves people who are doing different work with a constrained and apparently shrinking adjective namespace.
  • bigiain 1y ago
    > My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code. I'm now imagining me dying as a vibe-engineered truck has a steering/brake failure and crashes into me sending flying through the vibe-engineered papier-mâché bridge guardrails, and feeling sweet sweet release as I plummet to my doom.
    • peteforde 1y ago
      It's easy to confuse cynicism for humor. Look, if you enjoy calculating a table of dozens of resistor value combinations for a feedback network that prefers reels you have on your PnP, you keep knocking yourself out.
      • lkirkwood 1y ago
        If you're using LLMs for a large number of arithmetic calculations, you're exactly the problem GP is talking about. If you absolutely must use AI get it to generate code that will perform the calculations instead, so that you can actually verify the result.
        • peteforde 1y ago
          You're straining very hard to make your position sound reasonable, but your assumption that I both can't verify the values of the winning combination and wouldn't verify those values is simply not true. In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. It's actually so repetitive that I'm likely to have made the same kind of mistakes you're alluding to. As always, I end with encouragement: if you want to do everything the long and hard way, I'm not here to change your mind. You will have to stop being upset that others are moving much faster than you, though. It's a choice.
• citbl 1y ago
  I feel using the word 'vibe' is inherently giving it a negative connotation which goes against the idea presented here. The reality is the tools are really useful when used as tools, like a power drill vs. a screw driver. Vibing implies backseat driving which isn't what using the tools proficiently is like. The better term would be 'assisted' or 'offloaded'. Same thing with the term 'engineering'. That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise. 'LLM extended programming' is not as catchy but more relevant to what I observe people doing. It's valuable, it saves time and allows us to learn quicker, very powerful if used properly. Calling it 'vibe engineering' is a risky proposition as it may just make people's eyes roll and restrict us to a lesser understanding.
  • phildougherty 1y ago
    Same, I feel like the word vibe paints a picture of some dude ripping a bong while pressing enter.
    • sodixidjn 1y ago
      I don’t think that’s far off. There was an article awhile ago saying “you need to let go of looking at every line in a PR”.
    • jchanimal 1y ago
      If you can’t do it while you’re also singing a karaoke song, then you’re not vibing. I have fairly decent engineering credentials, but when the task fits, I prefer to vibe code.
  • gyomu 1y ago
    > That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise. Uh, speak for yourself. There are countries where being a software engineer does indeed imply that you studied engineering and hold a "real" engineering degree. Also, Hillel Wayne's "Are We Really Engineers" is worth reading: https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/
• drchaim 1y ago
  I’d just call it “coding” – it’ll be the default soon enough. For the old way: “hand-coding”
  • vunderba 1y ago
    I've definitely heard people semi-seriously refer to the old way as "artisanal coding".
    • simonw 1y ago
      Someone called it "brain coding" the other day which I quite enjoyed: https://domm.plix.at/perl/2025_10_braincoded_static_image_gallery.html https://domm.plix.at/perl/2025_10_braincoded_static_image_ga...
    • mistahchris 1y ago
      That's actually a pretty reasonable description I think. I mean, in the semi-serious way. But I was just talking to some colleagues of mine about how one can get attached to or invested in code that they hand wrote, even though that code wasn't really solving a problem that was "worth" that level of attachment. And AI assisted code generation changes the dynamic for code that fits in that category for me, and it just so happens to be a lot of the code people write for work fit into that. You only really need to be "artisinal" about the code that "really matters".
    • CuriouslyC 1y ago
      Just wait until there are artisinal software shops in Brooklyn staffed by an even higher density of bros with signature mustaches and weird side hobbies.
  • raghavtoshniwal 1y ago
    I feel a certain way when I hear about older programmers who used to program using punch cards, I guess everyone in the future will think about us in the same way?
    • 1y ago
• alganet 1y ago
  Coding++ Seriously now, I think the whole industry suffers from too many buzzwords and whacky terminology. *The job hasn't changed*. As mentioned, all those things from the past are still the most important thing (version control, being good at testing, knowing when to outsource, etc). It's just coding (which is something that was never about typing characters, ever).
• oidar 1y ago
  Vibe is just a bad word to describe anything that requires skill beyond "taste". A word play off of "AI assisted programming" is probably going to be the term that sticks. AIssisted? pAIr programming...
• Areibman 1y ago
  "Vibe coding" implies it's newbies throwing prompts and hoping some of them stick. For the experienced lot of us, I've heard many call it "hyper engineering"
  • vpShane 1y ago
    I put a lot of thought in to my prompts. I can code, definitely not as good as the AI or people here on HN; it's something I always enjoyed doing to tinker with things. The AI agent in Cursor with Gemini (I'm semi-new to all of this) is legit. I can try things out and see for myself and get new ideas for things. Mostly I just ask it to do things, it does it; for specific things I just highlight it in the editor and say "Do it this way instead" or "for every entry in the loop, add to variable global_var only if the string matches ./cfg/strings.json" I _KNOW_ I can code that. But I like my little clippy.
• m3kw9 1y ago
  I think the definition isn’t accurate, it’s more like engineering using AI.
• zer00eyz 1y ago
  It's just engineering, or coding or what every your current discipline is. We didnt stop calling them Framers or Finish Carpenters when they got electric saws and nail guns. Tooling does not change the job requirements.
  • icanprogram 1y ago
    Power tools actually increase productivity. LLMs create the illusion of increased productivity and output unworkable messes while atrophying your skills, ergo they decrease productivity. Oh and unlike power tools, for all intents and purposes you can't own them.
    • simonw 1y ago
      That's only true if you don't put effort into figuring out how best to use them. If using LLMs makes you slower or reduces the quality of your output, your professional obligation is to notice that and change how you use them. If you can't figure out how to have them increase both the speed and the quality of your work, you should either drop them or try and figure out why they aren't working by talking to people who are getting better results.
      • idontprogram 1y ago
        My professional obligation is to get hired easily when the other candidates can't write FizzBuzz without asking chat.
      • h4ny 1y ago
        GGP's sentiment resonates with me. I invest a fair bit of time into LLMs to keep up on how †hings are evolving and I do throw both small and large tasks at them. I'm seeing great results with some small task but with anything that is remotely close to actual engineering I just can't get satisfactory results. My largest project is a year old, it's full-stack JavaScript, and I consciously use patterns, structures, and diligently add documentations right from the beginning for the code base to be as LLM friendly as possible. I see great results on refactoring with limited scope, scaffolding test cases (I still choose to write my own tests but LLMs can also generate very good tests if I explicitly point to existing tests of highly related code, such as some repository methods), documenting functions, etc. but I'm just not seeing the kind of quality that people claim that LLMs can do for them on complex tasks. I want to believe that LLMs are actually capable of doing what at least a good junior engineer can do but I'm not seeing that in my own experience. Whenever we point out these issues we are encountering, we just basically get the "git gud" response with no practical details on what we can actually dp to get the results that people claim to be getting. Then people start blaming our lack of structures, patterns, problems with our prompts, the language, our stack, etc. when we complain about the "git gud" response being too vague. Nobody claiming to be seeing great results seems to want to do a comprehensive write-up or, better still, a stream of their entire workflow to teach others how to do actual, good engineering with LLMs on real-world problems either -- they all just want to give high level details and assert success. On top of that, the fact that none of the people I know in engineering working in both large organizations and respectable startups that are pushing AI are seeing that kind of results naturally makes me even more skeptical of claims of success. What I'm often hearing from them are mediocre engineers thinking that they are being productive but actually just offloading the work to their colleagues through review, and nobody seems to be seeing tangible returns from using AI in their workflow but people in C-suites are pushing AI anyway. If just about anything can be "your fault", how can anyone claiming that LLMs are great for real engineering without showing evidence be so confident that what they're claiming but not showing is actually the case. I feel like every time I comment on anything related to your blog posts I probably came across as belligerent and get down voted but I really don't intend to.
• cramsession 1y ago
  I think this is a pointless distinction tbh. Either you're getting good results from AI or you're not. If you're not, you should probably rethink your approach. I'd offer a new term: curmudgeon coding. This pre-dates LLMs and is the act of engineers endlessly clutching pearls over new technology and its branding. It's a reflexive reaction to marketing hype mixed with a conservative by default attitude. Think hating on "NoSQL". Validity of said hate aside, it's definitely "a type" of developer who habitually engages in whinging.
• rimmontrieu 1y ago
  I could never take anything seriously with the word "vibe" prefixed. "Engineering" is something hard, vigorous, fully dedicated, and commanding respect. It's just a stark contrast to "vibing something out of thin air"
• ianbutler 1y ago
  Frankly the most accurate way I would describe what I do with AI is managed programming, or being a handler for the AI. The only issue with "Handled Programming" is I don't like how it fits for a name. Vibe is much too unserious to pass my check for a way of professionally doing something and it also does not reflect the level of engagement I have with the AI and code since I'm putting together specs and otherwise deeply engaging with the model to produce the output I want.
• CuriouslyC 1y ago
  Call it autonomous engineering. Vibes are optional.
• blueone 1y ago
  I call it … using a chatbot to code. Don’t mind me, I’m just vibing.
• resters 1y ago
  Someday we will realize that using the term vibe before coding is like someone saying that today when we use GCC we are "vibe compiling" because we didn't compile the code manually. Once tooling becomes reliable and predictable enough, and the quality of the output consistent enough, using it is not a leap. Early compilers had skeptics, and GCC still has some bugs [1] 1. https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/2101084 https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/2101084
• plainOldText 1y ago
  A better term would be “Augmented Engineering” (AE). You want something to inspire engineers to do their best work. When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering. But vibing? Not so much. I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
  • therein 1y ago
    > A better term would be “Augmented Engineering” (AE). I don't think it necessarily deserves a special name. It is just engineering. You don't say book assisted engineering when you use a book as a reference. It is just engineering. > But vibing? Not so much. Just call it yolo engineering. Or machine outsourced irresponsible lmao engineering. > I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work. Oh god.
  • pacomerh 1y ago
    I wouldn't worry too much about what to call it. Assigning a distinct label separates it from traditional engineering in a way that it assumes AI-assisted coding is only for a subset of developers. At some point the unusual approach will be writing code without any AI assistance. So the transition will leave the "vibe" behind.
    • etothet 1y ago
      Hear, hear.
    • jama211 1y ago
      Well said
  • aDyslecticCrow 1y ago
    I take issue with your last sentence; > gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work. Gives you access to the power to access and {mis}understand the {most repaeted over the last 1-10 years} engineering {errors, myths, misunderstandings, design flaws}, on demand, which you then can apply to your work {to further bias the dataset for future models to perpetuate the slop}. Do NOT trust AI agents. Check their work at every level, find any source they claim to use, and check its sources to ensure that itself isn't AI too. They lie beyond their datasets, and their datasets are lying more for every minute that pass.
• bgwalter 1y ago
  I call it PEAKS: Performative Extreme Agile Kiddie Scripting
• chucknthem 1y ago
  Funny I'm a professional engineer and happily call myself "vibe coding" when writing code these days, it started as tongue in cheek, but now I've embraced it. Being good at vibe coding is just being good at coding, the best practices still apply. I don't feel we need another term for it. It'll just be how almost everyone writes code in the future. Just like using an IDE.
  • DowsingSpoon 1y ago
    If you’re looking at the AI-generated output then you’re not Vibe Coding. Period. Let’s not dilute and destroy the term just as it’s beginning to become a useful label.
    • gonzo41 1y ago
      Wait, are people not reading the AI code they use?
      • caseyohara 1y ago
        Nope. That's the "vibe" part of Vibe Coding™. > The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements. Unlike traditional AI-assisted coding or pair programming, the human developer avoids examination of the code, accepts AI-suggested completions without human review, and focuses more on iterative experimentation than code correctness or structure. https://en.wikipedia.org/wiki/Vibe_coding https://en.wikipedia.org/wiki/Vibe_coding
      • deleted 1y ago
        [deleted]
      • jrk 1y ago
        People of course often do read (and even modify) the model-generated code, but doing so is specifically not “vibe coding” according to the original definition, which was not meant to encompass “any programming with an LLM” but something much more specific: https://simonwillison.net/2025/Mar/19/vibe-coding/ https://simonwillison.net/2025/Mar/19/vibe-coding/
• stavros 1y ago
  I call it "coding". Nobody has ever cared what IDE I use, what documentation, which syntax autocompleter. I don't see why they should suddenly start to care about my tools when they're LLMs. Vibe coding is different because it's the "dictated but not read" of coding. Yes, I was around when the LLM was writing the code, and I vaguely instructed it on what to write, but I make no assurances on the quality of the output.
• didibus 1y ago
  Worse possible name to be honest.
• metadat 1y ago
  I've been all-in on vibe engineering for 4 months now and it is overall amazing. Simon missed a few key rules and practices that I follow, but every one of the points he hit is spot on. I also know for a fact the work I do has influenced some of his recent writing. Sorry to be a braggy jerk but I'm pretty proud of this! <3 The part about past management experience being a key skill surprised me but now it makes sense. I really do usually have 3 different projects in flight for at least 6 hours a day. I'd write a blog post but I keep expecting someone else will write the essential same post tomorrow. :) p.s. The first 2 months was exhausting but now it's slightly less exhausting. Make no mistake, it is an extreme transition to make.
  • simonw 1y ago
    What extra processes would you include? I'm sure my list in the post isn't exhaustive!
    • deleted 1y ago
      [deleted]
• sys_64738 1y ago
  This has to be a joke. Real engineering has a requirement of personal liability of the engineer involved. There is zero personal liability in the software which is why it's not real engineering. Until a software developer has to be held personally liable for the code they write and test, then they can call themselves an engineer. Back to vibe engineering, if ever personal liability were required then any AI slop in code would vanish instantly.
• wawaawacranta 1y ago
  [dead]
• wawaawacranta 1y ago
  [dead]
• rich_sasha 1y ago
  The headline made me think of a bridge designed by an LLM, and I think to myself: thanks, I'll pass.
  • BrutalCoding 1y ago
    You sure? I would turn around :)
• sarchertech 1y ago
  When pigeons are offered random rewards from a treat dispenser, they start doing all kinds of funny little dances and movements because they think the rewards are in response to their actions.
  • nmilo 1y ago
    Funny dances like "writing tests" and "planning"
    • sarchertech 1y ago
      Robot, you must follow the rules of the house! It is imperative that you do not kill me when delivering my breakfast! You must not make your own doors by punching holes in the wall! It is critical that you remember that humans cannot regrow limbs!
      • mock-possum 1y ago
        “You’re absolutely right…”
    • philipwhiuk 1y ago
      Or daily standups.
    • roxolotl 1y ago
      This is my favorite thing about this whole situation. I spend years trying to get teams to follow best practices. And then suddenly if you follow them the LLM is more effective so now they follow them ignoring that they could have been more effective this whole time.
  • foundart 1y ago
    gotta source or two? it's an ungooglable topic due to "see pigeon do funny dance" social media spam
    • sarchertech 1y ago
• deleted 1y ago
  [deleted]
• deleted 1y ago
  [deleted]
• XenophileJKO 1y ago
  So the only quasi disagreement I have is that "research" is one of the strengths of the models, and you should lean on them where possible. In Claude Code for example I define a research sub-agent and let it do the majority of "research" type tasks. Especially when the research is tangential to what ever my objective is. Even if it is critical, I'll usually ask to have it do a first pass.
• whacked_new 1y ago
  so the progression of human technological revolutions is looking like industrial -> information -> AI -> vibe
• zsdgl4 1y ago
  [dead]
• zsdgl4 1y ago
  [dead]
• zsdgl4 1y ago
  [dead]
• taylorlunt 1y ago
  These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs? I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
  • SeanAnderson 1y ago
    They're so nice for prototyping ideas and not becoming attached to the code due to sunken cost. I was playing around with generating intelligent diffs for changelogs for a game. I wasn't sure what approach to highlighting changes I wanted to take without being able to see the results. Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
    • taylorlunt 1y ago
      I agree, prototyping seems like a great use-case.
  • dolebirchwood 1y ago
    > Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs? No, I just put in less effort to arrive at the same point and do no more.
  • keithnz 1y ago
    I would say I get more (I've been coding 40+ years). I get pretty good results, I find a lot has to do with crafting your prompts well. I think knowing what the outcome should be, technically, makes a big difference. It's getting less and less where I have to argue with the AI / do it myself. Not to mention the amount of little productivity / quality of life scripts I get it to create. They really smooth out a lot of things. I feel like its more heading towards "solution engineering" rather than coding where I'm getting a lot more time to think about the solution and play with different ideas.
• eddiewithzato 1y ago
  vibe engineering, spending so much time writing documentation for the prompt, just to spend more time debugging the slop you get. Ill stick with writing code and just use AI for snippets/stackoverflow replacement.
• lherron 1y ago
  I would add to the list of the vibe engineer’s tasks: Knowing when the agent has failed and it’s time to roll back. After four or five turns of Claude confidently telling you the feature is done, but things are drifting further off course, it’s time to reset and try again.
• cadamsdotcom 1y ago
  A better term is agentic coding, agentic software engineering, etc. rather than being vibe based. My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was. Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup. But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that. The opposite of "garbage-in garbage-out" is quality in => quality out.
  • stpedgwdgfhgdd 1y ago
    +1
  • mystifyingpoi 1y ago
    > remind the model to use TDD I don't know how vibe coding works, but how does this work - is the agent actually engaging in the red-green-refactor loop, or does it just generate the result all at once?
    • bananapub 1y ago
      if you ask it to, claude code can definitely write tests, then write code, then try to modify one or the other to make them pass in a loop, yes. if you don't ask, it's much more likely to just one shot the whole thing, and may or may not get it right first time.
    • deleted 1y ago
      [deleted]
  • witx 1y ago
• enigma101 1y ago
  there is no such thing as vibe engineering no matter how much you want to make it up
• furyofantares 1y ago
  Centaur Coding.
• triyambakam 1y ago
  Can we please just call it model driven development? I already hated the distortion of "vibe" as it got distorted from Karpathy's original meaning.
• keeda 1y ago
  I think we should just accept that vibe-coding has now semantically shifted to mean all AI-assisted coding. Actually, it makes sense to me even when a human is interacting directly with the code, because it feels a lot like pair-programming. As such, I really am "vibing" with the AI. But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also be a lasting phenomenon. I propose "Yolo-Coding" -- It fits in nicely with the progression of No-Code, Low-Code, Yolo-Code.
  • bryzaguy 1y ago
    What about slop-coding?
    • ares623 1y ago
      Nice
    • mikepurvis 1y ago
      Nicely verbable too: “I vibed this out earlier” -> “Me and Claude slopped together this PR, ptal”
    • deleted 1y ago
      [deleted]
  • gitgud 1y ago
    Clanker Coding ™
  • novaleaf 1y ago
    I made a claude slash command `/yolo` for when I just want it to do do something without further guidance, so I agree :)
  • paool 1y ago
    Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative. I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference. It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
• makk 1y ago
  We should just call it engineering. We got better tools. Big whoop.
  • deleted 1y ago
    [deleted]
  • witx 1y ago
    But it's not engineering ...
• ares623 1y ago
  What I’d really like to see is a company that completely does away with the code review step. Because if you think about it a code review is already being done by the invoker of the LLM. That way the velocity will actually be faster. It feels like at the moment most of the velocity is blocked by the outdated notion of code review. It’s also why these tools feel great in green field projects, since these ones don’t typically have any code review in place (i.e. one dev going brrr)
  • scuff3d 1y ago
    I hope this is a joke...
    • ares623 1y ago
      Partially serious. I mean what’s the point of being able to open 100 PRs in one day if your coworkers can only reliably review 5 of them?
      • scuff3d 1y ago
        Not just that but PRs are about a lot more than syntactical correctness, it's also about design. Just this week we've had two PR catch bad design choices that came from a fundamental misunderstanding of the problem space. Even if the AI wrote perfect code the first time everytime it wouldn't matter in those cases.
  • TranquilMarmot 1y ago
    We tried this as a bit of an experiment - not quite greenfield but a fork and modification of an existing project. I was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different". Occasionally I would test changes in staging but mostly would just promote them straight to production. I went on like that for ~3 months and the product ended up getting ~75k (daily!) users in that time with *no* outages or downtime (!!!) It worked really well! Until I hit my scaling limit and we added more engineers to the team. A new hire on their second week on the job shipped a change that was also written with AI and caused a 7 hour outage before we realized something was wrong. I even *thoroughly reviewed the code* because I knew it was generated and I made a comment questioning the lines that caused the outage, but after we talked it over we decided it was fine and was only one tiny bit of a much larger change. So I guess, AI will ship bugs but so will peer-reviewed code.
• subarctic 1y ago
  I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it sounding like this is the future, I just feel discouraged because it sounds like so much work and I've tried using coding agents and they help a bit, but I find it way less fun to be waiting around for agents to do stuff and it's way harder to get into flow state managing multiple of these things. It makes me want to move into something completely different like sales
  • selcuka 1y ago
    Don't worry, it's probably only the impostor syndrome. Your development skills are still relevant. Think of agents as junior developers that assist you in coding tasks, whom you constantly need to mentor, review, and correct.
    • bluefirebrand 1y ago
      Can we all agree that "mentoring" LLMs is actually a waste of time, please? The reason we invest this time in Junior devs is so they improve. LLMs do not
      • leptons 1y ago
        "AI" has been so inconsistent. On one day it anticipates almost every line I am coding, the next day it's like we've never worked together before.
        • dotancohen 1y ago
          I see you've never dated twins.
      • simonw 1y ago
        I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this: 1. Collaborate on a detailed spec 2. Have it implement that spec 3. Spend a lot of time on review and QA - is the code good? Does the feature work well? 4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar That last step is the interesting one. You're right: humans improve, LLMs don't... but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work. I've heard similar things from a few people now: by constantly iterating on their CLAUDE.md - adding extra instructions every time the bot makes a mistake, telling it to do things like always write the tests first, run the linter, reuse the BaseView class when building a new application view, etc - they get wildly better results over time.
• tjpnz 1y ago
  Isn't that what a meth cook does?
• hilti 1y ago
  There will be times when LLMs are not accessible or working as expected and we will honor real software developers who can still think on their own, create and solve problems.
• tabbott 1y ago
  I predict that people will end up using the term "vibe engineering" to refer to development processes that involve asking an LLM to build their entire app: UI design, database schema, architecture, devops, QA, debugging, etc, without any of the careful effort to understand and be able to proudly own the resulting code that Simon is imagining. And I think that is actually the most natural meaning for "vibe engineering", actually: Parallel to "vibe coding" where you serially prompt the AI to write the code for you, "vibe engineering" should be serially prompting the AI to do the entire engineering process for you. I also predict that a precisely defined term for what Simon is describing will inevitably end up being primarily used by people who are actually doing "vibe engineering". Being disciplined and careful is hard. People and organizations love to claim/pretend they're doing expensive, mostly invisible work like "building secure software". Given nearly every organization claims they use security best practices no matter what their actual practices, I imagine it will be that way with "actually reading and verifying what the LLM generated for me". Certainly I've been disappointed how often someone presents something they've "written" in recent months that turns out, on inspection, to be AI slop that the "author" hasn't even read every sentence of carefully.
• wferrell 1y ago
  @simonw Great post. I've thought about what I want for better Vibe Engineering: Each agent needs to deliver a fully working App/URL/Build so the functionality can be tested & verified. Today AI IDEs deliver the diff + an explanation. Excellent. But give me the full build, a build I can share. A build that represents what it would be like shipped. When it comes to user facing functionality, a real build is how product owners verify a feature is complete. Learn from Vercel - A key part of Vercel’s magic is the automatic deployments for each branch. When working on a project with per branch vercel deployments - a team gets the immediate value of: Shareable work - now others can see/test/give feedback on the great new feature you’ve developed - and their only work is to click a link (not git pull a branch and attempt to run locally) No more “it works on my machine”. It either works or it doesn’t. Confidence that if released, you know exactly what the user will experience. Give me automatic deployments for each agent, for each PR. And keep them available to spin up / re-use later. I want to be able to re-launch it 3 months later and it just works. The reason we don’t do this today is the cost of the engineering - but with docker et al + AI agents, the cost of the eng work drops 99% Deliver the deployment in such a way that immediate feedback to the AI could be given. This way minor tweaks can be executed immediately by the AI meaning that I can just wait for the minor tweak, review and then merge. This means the PR gets shipped NOW.
  • energy123 1y ago
    I think a key skill is knowing what level of complexity a single run can realistically achieve, which is often only a small task and not a fully working build.
• hollowonepl 1y ago
  I’m glad to see that more and more articles and opinions about AI are focused on how it works and it works great just the process and mind thoughtfulness has to adapt and evolve to fully utilize the tool. That’s so much better than wasting time on the frustrated who just negate without a meaningful try. I share most of the experience and learning with the author, I just still don’t know how to name the whole process. The whole vibe thing has already brought negativity into terminology because of all negating. Closest thing in history of software engineering practice from the past is XP (Xstreme Programmimg) with its pair programming approach. It was a precursor of anything modern agile. Invented at the end of 90s It’s just this time, my pair programming mate is computer instead of human person, but I treat it as junior to me and review, organize, while coding, testing, documenting is delegate and we jointly do the analysis as a part of the discussion. I can agree, it’s strongly augmented experience and weird often to newcomers to adapt, but when a critical path to succeed is discovered, it works great and results are a blast!
  • tartieret 1y ago
    I agree with your analogy with pair programming. Except that now your co-developer types way faster!
• aadv1k 1y ago
  I've been thinking about AI-assisted development for a while; I've tried out Claude's pro plan, Gemini Pro and many "top models" and I must say, this is going to create a chasm for junior/intermediate developers like myself, senior engineers reached to the point they are through deliberate practice-- interrogating code, making and breaking assertions, reading through the documentation or actually comprehending the code through the debugger or mental models. I don't "need" to do any of this. I can have an AI just spoon-feed me a large codebase in "ELI5" language, I can ask an AI about the best practices, I can have an AI look something up for me, synthesize it and wrap it up nicely for my mind to consume (equivalent to how hyper-processed junk food isn't good for our bodies either) It's intellectual slop. It will get the job done (atleast for a while) but without the actual growth that comes along with it. When I use an AI to one-shot a "small one-off script" I don't learn anything from it (when as a relatively new developer I SHOULD be learning something from it) And this is unlike stack overflow or googling becuase you can turn off your mind, just become one of those drones from Wall-E. I make a point to avoid using any AI for coding (even for looking things up) when working on personal projects, at the cost of "productivty" and "efficiency" , but I get to retain my humanity and soul in programming. Sorry if this sounds cheesy, it's just I care deeply about code craftsmanship from my end, to see that skill be diminished to an random number generator? Yeah No.
• joduplessis 1y ago
  To people reading the article: replace the word "agent" with "intern". > Without tests? Your intern might claim something works without having actually tested it at all, plus any new change could break an unrelated feature without you realizing it. Test-first development is particularly effective with interns that can iterate in a loop. Vibe engineer? No, try technical manager.
  • tartieret 1y ago
    As a CTO of a small company, spending a lot of time reviewing other developers' PRs, I completely agree. I recently enabled Github Copilot Agent and use it a lot for dealing with smaller and lower priority tasks in an async workflow (e.g. while I am doing other things). A lot of developers are not very good writers, and reviewing PRs from Copilot, with access to the full "thinking process" and being able to request changes in a few comments is sometimes more pleasant and effective
• testfrequency 1y ago
  The recent jokes about “everyone is an engineer” now just feels unprovable, where as before it felt like you could still counter that argument by asking to see someone’s code. Now everyone has examples of code they’ve “written”, but nobody can explain what it does. Unless of course, their readme.md was also completely generated. I agree with some of the people here that vibe engineering has completely deflated my long successful career as a SWE, and it’s pushed me mentally into non-tech roles to feel motivated.
• maybewhenthesun 1y ago
  I think it's a good idea to make the distinction. But I don't think 'vibe engineering' is the term I'd go for. To me `vibe engineering` sounds like shoddily AI-designed suspension bridges. But then maybe I'm just an old fart programmer who thinks 'software engineering' is a term made up by programmers wanting to be as cool as bridge designers...
• jmfldn 1y ago
  Seeing all the experienced engineers on this thread who feel discouraged is really depressing. Not because I disagree with you, I don't! It's because I fear a gradual brain drain of people who actually love their craft and know how to build things properly. I fear we'll end up with worse software thats simply 'good enough', built a atop a pile of AI slop. If it's cheaper but with acceptably worse results, I fear this is good enough for a lot of companies.
• 000ooo000 1y ago
  Slapping 'engineering' on something to try and trade on the good name of real engineers is the express lane to losing all of your credibility. Guess I should get ahead of the curve and update my title to Slop Surgeon.
  • mrweasel 1y ago
    No one should be allowed to use "engineering" in the context of producing something with LLMs until they learn to say "No, I'll not help you cut corners on this, and if you persist I will report you". If you're fine with an AI designed bridge, where the builder tweaked the prompt to get the LLM to suggest cutting out all safety features, then okay, go with vibe engineering.
  • sevenseacat 1y ago
    my tongue-in-cheek job title has been 'professional string concatenator' for a long time now
• matt3210 1y ago
  I took a look at youtube but I haven't seen any real examples of AI being used to ship anything significant (as in, other than toy apps which are available as templates already or copy pastable from tutorial websites).
• huntercaron 1y ago
  > it’s surprisingly effective, if mentally exhausting! this sadly seems to sum up most of this new wave of work. hopefully we can find a better workflow that still feels as good as coding used to
• stpedgwdgfhgdd 1y ago
  I prefer: Agentic coding, inner loop, the stuff an engineer does on his laptop. Agentic engineering, outer loop, sdlc across the organization Not perfect, but good enough.
• pietz 1y ago
  Simon went quickly from not agreeing with common buzz words to making up his own.
• dash2 1y ago
  > One of the lesser spoken truths of working productively with LLMs as a software engineer on non-toy-projects is that it’s difficult. I mean, the AI companies have an incentive to make it easier, right? The next iteration of coding agents will be better at working with their human PHBs to divine intent and turn vague specifications into something workable - a key skill of human engineers. Is this really any different from how Google learned to understand search queries?
• risyachka 1y ago
  >> where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce Why would you add “vibe” then? Seasoned devs don’t vibe, they know what they do
• tkgally 1y ago
  Around the time GPT-4 was released in early 2023, a similar issue arose with another profession: translation. It was at that point that machine translation between languages like English and Japanese (the language pair I have worked with) started to approach human level for the first time. I took part in a lot of discussions then with other professional translators, and the reaction of many was similar to that of some of the commenters here: not only were they discouraged because their hard-earned language and translation skills no longer seemed needed, but using LLMs as assistants took the enjoyable challenge out of the translation process. Nearly everyone I spoke with then worked from home as a freelancer, carefully crafting one translation at a time. They didn’t like the idea of becoming managers of large-scale translation projects, even if it meant they would be able to apply their higher-order intercultural communication skills. I do only a little professional translation myself now, but I try to keep up with AI developments and I often use translation tasks to test the latest models and frameworks. Over the past few months, I have vibe-coded some multi-LLM translation systems where texts were passed through multiple models that checked, critiqued, and improved each other’s translations. For the texts I tried them on, the results were much better than any single-LLM translation, approaching the level of the very best human translation. The API calls weren’t cheap, but for high-stakes translations such a system would more than pay for itself. When designing that “vibe translation” system, I did apply my experience as a translator, similarly to what Simon is recommending programmers do now with vibe engineering. At this stage in my life (I’m sixty-eight), I am fine with that. But if LLMs had arrived when I was, say, just five or ten years into my translation career and still proud of my nuts-and-bolts skills, I might very well have looked for another career rather than becoming a vibe translator.
  • mejutoco 1y ago
    Translation is great to discuss LLMs. Thanks for sharing your experience. On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days. Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sadly just a check at the end. IMHO the only future-proof translation fields are legal (because a human can be put in prison or pay a fine) or live translation/interpretation (because a human can go in front of people, meet them at an event, etc.).
• croisillon 1y ago
  we could call it "Reasonable AI Liability" like Ruby does ;)
• deleted 1y ago
  [deleted]
• dlvhdr 1y ago
  Please stop with all this vibe bs. Seems like a desperate attempt at getting viral.
• cronquist 1y ago
  To me, “Vibe engineering” isn’t just a label — it’s a Rorschach test for identity in the AI era. >> Supporters see it as a bridge between humor and professionalism >> Critics hear it as the sound of their trade being rebranded into a meme. Both sides, though, agree on one thing: coding is no longer the same craft it was a year ago. My opinion: I believe “vibe coding” has already broadened to mean any AI-assisted coding, making “vibe engineering” redundant.
• __0x01 1y ago
  Is cost a risk here? I'm assuming that sometime in the future the price for vibe coding/engineering will go up significantly.
  • iLoveOncall 1y ago
    It already is. I saw a demo of someone spending $30 an hour on Cline to do something that would be achieved better, for free, and faster, with a framework. That's more than $5,000 a month assuming 40 hours a week. The end result didn't compile by the way.
• deleted 1y ago
  [deleted]
• pierre_vannier 1y ago
  Simon, I want to reach out since I want to express my disappointment regarding this thing you write here: "I propose we call this vibe engineering, with my tongue only partially in my cheek." Back in march 2025, you and I had a brief convo on X about this very term that came to my mind "Vibe Engineering": https://x.com/pierre_vannier/status/1904933441042317821 https://x.com/pierre_vannier/status/1904933441042317821 I also mentioned it in our podcast in April 2025: https://x.com/Flint_company/status/1909946181897044195 https://x.com/Flint_company/status/1909946181897044195 Yesterday, I pinged you on X about this "term's paternity" in your thread without any response: https://x.com/pierre_vannier/status/1975579806495293910 https://x.com/pierre_vannier/status/1975579806495293910 You and I met in AI Engineer in SF last June and we discussed for 1 hour (not about this specifically but about AI and all). At the very least, it could be cool to mention it in your post or newsletter since, I do think this little convo on X + our talk in SF might have just planted the seed in your head for this "invention" of yours... I don't want to stay in history books but I think it's cool to also credit people when you iterate on their idea instead of just make the thing entirely "yours"... Best Pierre
  • anhner 1y ago
    we gonna police naming things now?
  • 000ooo000 1y ago
    The guy is all in on the world's biggest copyright infringement machine.. good luck getting your credit
  • dak89 1y ago
    I think he should have given you credit, you were clearly first and he responded to your tweet so he must have seen it! But he might have just forgotten he had the conversation with you about this, while still being more likely to "rediscover" the term since he had heard it before. Maybe a bit aggressive to not reach out to him privately first but in any case pretty cool that you actually invented a term that is now quite likely to be popular :)
• cranium 1y ago
  I find coding agents to be a powerful throttle on the speed dimension in exchange of quality in the general sense. With tests to ensure correctness is not compromised (not a silver bullet), linter and pre-commit for code style, the byproduct of AI code is utter verbosity. Pleads to be concise don't work – no more than the "Don't be wrong/hallucinate". In that regard, I like Blaise Pascal quote "I have made this longer than usual because I have not had time to make it shorter."
• adastra22 1y ago
  No. “Vibe” is what captures the irresponsible usage. “Automated engineering” is much closer to the mark.
• zxspectrumk48 1y ago
  No, thank you.
• rckt 1y ago
  This feels like an attempt to sell vibe coding to skeptics. I don't feel there's a need to. People find their own workflows how to use AI. Some people go all in, some use it here and there, some use it to write tests, etc. I feel annoyed enough having the AI topic discussed and reviewed everywhere every day, I don't need more of this.
• sublimefire 1y ago
  I find using “Vibe” makes it sound less valuable. It also needs to fit the next frontier which is “refactoring” and tuning the codebase to work with agents to make it easier to change existing code. A suggestion to use “augmented” was great
• hollowturtle 1y ago
  I don't get the obsession some tech people have to push the idea that this stuff accelerate your coding, increase your productivity. It's all about fast and faster output. In my experience LLMs have mostly produced gibberish oververbose code, surely faster than me, but my lower speed usually produce better code. I don't like this present state of things where we need to chat faster to quickly get out results and go fast in production... that is the kind of mentality that pushed subpar products on the web for so many years. Instead of dropping names lile vibe coding/engineering whatever comes next, let's have a serious discussion why we need faster low quality and we can't just improve automation and processes. Eg I can get unit test generated very fast sure, but my question is: why do we need all these unit tests in the first place? Dont get me wrong they're useful, but I feel like we're advancing higher abstraction instead of advancing lower level tools
  • rhetocj23 1y ago
    It’ll be the greatest episode of sunk cost fallacy 5 years from now.
  • treve 1y ago
    I think the general issue with software engineering discourse is that while our tools and languages may be the same, there's a massive gradient in tolerance for incorrectness, security, compliance, maintainability. Some of us are building prototypes, and others are building software with a 10 year horizon or work with sensitive personal data. So on the one side you get people that are super efficient cranking things out, and others that read this and feel appalled anyone would be comfortable with this and see software engineering as theory building. Neither are really wrong here, but the context / risk of what people are working on always seems to be missing when people talk about this.
    • hollowturtle 1y ago
      I have yet to see in my life a prototypes that doesn't become production :) Btw my whole point wasn't on security and can't find a compelling reason to talk about it, it rather questions "faster results" as "better productivity" it isn't, and imo we should pause for a moment and focus on better tooling
• deleted 1y ago
  [deleted]
• jimguy 1y ago
  Thanks for the AI slop blog content
• harryf 1y ago
  > Good version control habits. Feel like there's more to this point (plus the documentation). By now we've all see the inverted-U-shaped performance curve when coding with LLMs within a single thread / context: the model starts strong, plateaus as the context fills up, and eventually declines as semantic drift sets in. Sometimes in this situation, it works better to throw away the current code and re-implement, using what's been learnt so far, than continue working with the current context of having new contexts try to salvage the current state of some code. Documentation is great as a reflect of the current state of some code but I've had good experiences "re-constructing" the steps taken to arrive at a current implementation by writing commit messages that are intended for an LLM, extract that later, have an LLM use it as a basis for writing a fresh "spec" for some code, that yet another LLM uses to actually write that code. Git history is a natural place to store that...
• razoorka 1y ago
  I did a several-month experiment using Claude as the only engineer on a real SaaS side project (Node.js/React, prod-quality, full feature ownership). My observations: The quality of Claude’s output strongly correlates with how explicit and detailed the specs are. Markdown checklists, acceptance criteria, and clear task structure led to far fewer corrections and surprises. Most mistakes were never “creative hallucinations” — just missed context or ambiguity in my own instructions. The whole process felt less like delegation and more like tight collaboration. There’s less of a “flow state” and more context-switching to review/test, but review fatigue is manageable if you iterate on your instructions after each lesson. No real learning from prior sessions, but persistent design docs and corrected example snippets in the prompts made a big difference. Overall, a lot of the “vibe” factor gets smoothed out by rigorous process — not unlike mentoring a junior dev on a new domain. For me, the speedup was very visible on well-scoped backend tasks and trivial CRUD/UI, and less so on broader, ambiguous work (designing APIs, coordinating many moving parts). The biggest upside: a clear process made both me and the tool better; the biggest “cost”: I spent a lot more time up front thinking through specs. Not sure it fully scales (and I’m skeptical on agent “fleets”), but for a solo dev, given patience and a bit of PM discipline, it’s a net positive.
  • computerex 1y ago
    Same experience here.
  • Kzozjj 1y ago
    > I spent a lot more time up front thinking through specs. Presumably you didn’t work like this before but now you are? Have you tried simply doing this when manually coding? It’s possible you’re getting a speed up from embracing good practices.
• throwaway984393 1y ago
  [dead]
• sarmike31 1y ago
  Engineering is in large parts about signing-off on something with you name on it, and being responsible if it fails or causes harm. Think bridges, tunnels or other infrastructure. I‘d argue that this is the same for computer engineering. That‘s why I think coining the term ”vibe engineering” can be dangerous. ”Vibe coding” is the better term and actually makes sense for what it describes. Leave ”engineering” in terms of taking responsibility for what you ”engineer” strictly to human professionals. That’s what people pay for and that is what makes it valuable.
• beernet 1y ago
  > I propose we call this vibe engineering Seriously? The term has been around in the community for as long as "vibe coding" has been around. While both sound equally cringe, the statement leaves a bad taste.
• neebz 1y ago
  All these coding agent workflows really drive home how important a solid test suite is but who’s actually writing the tests? In my case Claude Code keeps missing key scenarios and I’ve had to point out every gap myself. Also reviewing LLM generated code is way more mentally draining and that’s with just one agent. I can’t imagine trying to review code from multiple agents working in parallel. Finally I’ve shipped a bunch of features to prod with Claude writing all the code. Productivity definitely went up, but my understanding of the codebase dropped fast. Three months in I’m actually struggling to write good prompts or give accurate estimates because my grasp of the code hasn’t really grown (code reviews only help so much). Curious if anyone else has run into the same thing?
• philipwhiuk 1y ago
  I hope this term doesn't catch on - the whole point of 'engineering' is basing decisions on experience and understanding. The whole point of 'vibe' is the opposite. If this sort of term is adopted we are in 'literally not being literally' territory. Fortunately, I imagine that engineering outside software already has people vibing physical infrastructure solutions and call that vibe engineering so I don't think it will stick.
• codr7 1y ago
  These words just don't belong together, period.
• skor 1y ago
  Don't worry — if we all have access to the same tools, the playing field is level. What sets you apart are the human qualities. Employers and clients want to be at the top, same as before LLMs. The market is large, and there's room for everyone. Don't be afraid of someone without any/little engineering knowledge making something, they were already copy/pasting code from SO before LLMs.
  • wartywhoa23 1y ago
    The field is all but level with all the money behind the AI.
• mettamage 1y ago
  Didn't read the article, reacting to the title. To add as a data point: I've met founders that are business founders and are vibe coding entire businesses with React, Supabase and Netlify. LLMs allow for amazingly high fidelity interaction designs to receive funding and prove out certain PoCs. Whether his stuff will stay up in production remains to be seen.
  • deleted 1y ago
    [deleted]
• bonoboTP 1y ago
  This name makes no sense. "Vibe" means you're just vibing, just taking in vague impressions, just YOLOing, hoping it works out and just chilling and providing little input and effort. It's part pejorative and part ironic self-deprecation. "Vibe X" now means doing X by just giving vague instructions to the computer, not checking the output much and hoping it works out and it kinda does in part, at least enough times that it feels like it's a fine way to do stuff you just want to get over with anyway. Vibe engineering would mean giving access to Google Computer Use API to your engineering design software and letting it design the industrial component you're working on, without even looking at what it does and just telling it to "fix it" if it seems bump into problems.
• reassess_blind 1y ago
  I wonder if we are more like accountants at the advent of spreadsheets, who have thrived and just changed tools, or farriers at the advent of automobiles?
• guitarro 1y ago
  I don't think the issue is with the "code" part, but more with the "vibe" part. The "vibe" part indicates that's more of a "let's just see what happens" kind of approach, which I don't think is true for people using AI generated coding in their professional coding jobs, who very much know what they want to get out of AI coding tools, how to ask for it, and how to assess the quality of the outcome. Maybe something like "intent-driven development" or "AI-paired software development" might fit better?
  • sauercrowd 1y ago
    100% agree. I really think it's time we move on from vibecoding, the tools have evolved and we should have a term that attaches more quality to the function
  • imiric 1y ago
    Right. The more accurate phrase would be "tool" or "machine-assisted development". We don't need new terminology to describe something that has always existed because the tools we use have (arguably) improved. "Vibe coding" is also a misnomer. People who engage in that activity are not "coding". They're using a tool to generate software until they're satisfied with the result. That has also been possible with low-code, no-code, website builders, and other tools. The more accurate term for that would be "machine-driven development".
    • guitarro 1y ago
      I get what you're saying. Although I agree that it falls into the same category as "machine-assisted development", it's significantly different from other ways of coding that I would say it deserves its own name. AI-assisted coding is an absolute game changer, for me, but I would think for everyone who can wield it well. I feel I can direct a (sort-of) small army of junior coders, architects, qa- and req engineers, etc., way different than with e.g. CASE-tooling. It requires creativity, and lots of knowledge & experience in the whole software-development life-cycle to get it well, and it can adapt to any flow you like. That's really new and unique, and way more flexible than the rigid CASE-tooling that was already out there. "Tool" seems to broad: "What are you doing?" "I'm tooling." :) Am not highly opinionated on if "code" should be in there. The AI tools do generate code, where some low-code platforms and the likes might not. I guess "development" works as well, although "vibe developing" doesn't really have the same ring to it :) I do like to be able to differentiate between people generating code but don't care what happens under the hood, and software-professionals that incorporate AI assisted development into their daily work on any level.
• pete_b 1y ago
  Willison has an impressive record for coining terms. But feel like he may have missed it here. In the context, 'engineering' doesn't feel that different to 'coding'. The sloppy sounding part is 'vibe' and that's not been removed.
• sauercrowd 1y ago
  I really don't think we're doing the tools or the industry any favors/justice by prefixing new terms with `vibe`. Looking at vibe coding: it suggests you're coding but you only vaguely know what's going on, so the work is the same (coding) but the outcome may or may not be what you want Why dont we flip it around? We want a term that suggests that a fixed amount of work (coding) to be more efficient/leveraged. So why dont we call it something like hypercoding, dense engineering, autocode, ...
  • mejutoco 1y ago
    Some more options (I used AI with a nuanced not-too-lazy prompt, I hope it is okay): Prompt Engineering / Directed Prompting Architectural Steering Spec-Driven Development Intent-Based Coding Critical Synthesis Iterative Refinement Guided Iteration Hypothesis-Driven Coding AI-Assisted Engineering Cognitive Pair Programming Dialogic Programming Structured Prompting for Code (SPC) Code Shepherding AI-Assisted Engineering is probably the most descriptive. My favourite are Critical Synthesis and Code Shepherding. Both abbreviate to CS
• visarga 1y ago
  Is "vibe engineering" a correct term for this? It's not vibe based when you scaffold constraints around the agent: automated testing, planning in advance, comprehensive documentation, automated formatting and linting, and manual QA. Don't get me wrong, I started vibe coding after reading Karpathy's post. I got the memo - don't review every line of code, don't stop it when it stumbles, let it recover on its own, trust the process. But after some experience I realised I need to Constrain the model, it is like a karting track, those tires put around it keep the carts inside and safe. It's our job to set the constraints. So maybe it's "constrained agent work" not "vibe coding". I go as far as saying the constraint harness around the agent is the new code, we can remove the code and regen it from the constraint harness and docs. What matters now is to build tests and constraints around AI work.
  • mrzool 1y ago
    > Is "vibe engineering" a correct term for this? Anything with the word “vibe” in it sounds silly and unserious imho. What’s wrong with something neutral and descriptive like “LLM-assisted programming”? Not catchy enough?
    • simonw 1y ago
      Yes, not catchy enough. I tried to get "AI-assisted programming" to take off for a couple of years, it got no traction at all.
• ridruejo 1y ago
  This matches our experience developing with agents. In particular, as we wanted to use multiple agents in the background to do tasks, we had to really invest in different areas so they would not go in wild directions or have to ask continually for feedback, defeating the purpose of working in the background. First, we needed to provide relevant context on how to do the task (some of it is "generic" like Svelte documentation, some of it is specific to how to write tests for our particular project), be extremely detailed and specific in the prompt about what we want and how to go about it (divide it in different well defined steps) and finally provide with specific tools via MCP (like MySQL access and installing system packages). Once we consistently do all this work upfront, it really pays off because you can launch a large number of agents in parallel that don't interfere with each other (git worktrees, containerized environments) and don't require babysitting for the most part. We just open sourced the tooling we used internally for this: https://github.com/endorhq/rover https://github.com/endorhq/rover
  • redhale 1y ago
    Thanks for sharing! The problem with every single tool in the category that I've come across (e.g. Conductor, Sculptor) is that they assume a single repository. Very rarely in my career working on enterprise software have I been in a situation where all my work was constrained to a single repo. Usually a story or feature spans several repos (whether split between frontend/backend, or a repo-per-service). As an engineer in these situations I never work in isolation considering only one repo -- I work across all of them at once and then prep all the PRs together. I'm not saying this multi-repo approach is good, just that it is the state of the world right now in many cases. So imo tools like this need to work at a level above a single repo. The agent needs to start by cloning all repos needed for the task, and go from there.
    • simonw 1y ago
      I've solved this in the past using versioned dependencies. Repos get tagged releases, other repos can specify which version they depend on, then the deployment script has to resolve those dependencies and install the right release versions of everything else. You can also use GitHub submodules to implement a pattern like this, but I don't really trust them for some reason.
• Sasori7 1y ago
  Welcome to me 13 years ago when India happened. Nobody cared back then. So I just left.
• hu3 1y ago
  Can anyone suggest solution(s) to create temporary preview environments per branch or Pull Request? For example if someone creates a Pull Request "#2122 feat: User password change" Automation would deploy it to pr_2122_feat_user_password_change.mycompany.com
  • PeterStukalov 1y ago
    [dead]
  • simonw 1y ago
    Heroku and Vercel and Render all have features that can do this. You can wire up your own for other hosting providers using a lot of scripting on top of GitHub Actions. Heroku: https://devcenter.heroku.com/articles/github-integration-review-apps https://devcenter.heroku.com/articles/github-integration-rev... Vercel: https://vercel.com/docs/deployments/environments#preview-environment-pre-production https://vercel.com/docs/deployments/environments#preview-env... Render: https://render.com/docs/service-previews https://render.com/docs/service-previews
• nakamoto_damacy 1y ago
  "Vibe Technical Debt Creation" <-- either that or the AI's purpose is limited to sTimulation (getting us to think while it's spinning its wheels writing throwaway code.
• ManuelKiessling 1y ago
  As always, Simon knows what he is talking about and neatly describes the whole situation. However, it's not the "coding" part of "vibe coding" that is the (semantic) problem, it's the "vibe" part. Replacing "coding" with engineering, but keeping the "vibe" part, still conveys the meaning of not really knowing what you do, but now in an even larger surface area. It's a lot more boring, but I'm fine with "AI-assisted software engineering" as the other-end-of-the-spectrum name opposite of "vibe coding".
  • emil-lp 1y ago
    Simon is a salesman. Obviously he knows how to phrase things.
    • simonw 1y ago
      I wish I was! I'm pretty terrible at sales. It's a skill I respect and do not have.
      • GoatInGrey 1y ago
        > Sponsor me for $10/month and get a curated email digest of the month's most important LLM developments. > Pay me to send you less!
        • arresin 1y ago
          You are seeing someone asking for a completely voluntary subscription fee for very valuable (I find it at least) work that they give away completely for free—not to mention all the OSS software he has created—and yet you are construing that as being somehow greedy or money grubbing or sleazy.
        • simonw 1y ago
          Hah, yeah that's genuinely one of my more successful attempts at capitalism.
      • davidatbu 1y ago
• SecretDreams 1y ago
  Sadly, "vibe engineering" is already real, but associated with half assed engineering, rather than effective use of LLMs lol.
• chrisrickard 1y ago
  Your second point “planning in advance” could be referred to as spec-driven development… it’s a funny term in a sense (didn’t we always do that?), but I think your 7th point drives it home “a very weird form of management” - clear instructions, necessary context, and actionable feedback. As far as written words go, much more like waterfall than agile.
• cbeach 1y ago
  hi Simon - just a note to say that your link to https://tools.simonwillison.net/ https://tools.simonwillison.net/ goes to https://simonwillison.net/ https://simonwillison.net/ Think this might be a typo
  • simonw 1y ago
    Thanks, fixed that.
• __MatrixMan__ 1y ago
  If they know what they're doing, we trust the experts to select their tools rather than letting those tools define the person. Script Kiddie != Hacker Wrench Jockey != Mechanic Vibe Coder != Engineer The opposite of vibe coding is not vibe engineering, its just engineering.
• krschacht 1y ago
  Simon, I think this is a good distinction. Another possible term could be: “agent engineering management” or simply “agent managing.” I am deep in this and one important way in which managing agents is different than managing people is that micro-managing can be your friend. With human engineering colleagues, you need to allow for a healthy degree of “that’s now how I would have written the code, but it’s a reasonable way to write it.” But if my agent writes the test file in the exact same way I do, I can both review and maintain the code more easily. I have a bunch of short markdown doc files in which I give very specific instructions for how I like code organized: much stricter than I would ever do for a colleague. I’ll tell the agent, “now add tests to this model and follow @unit_tests.md” This file specifies exactly how I like tests named, what order I like them written in the file, etc. I have docs for: models.md, controllers.md, concerns.md, and fixtures.md.
• skybrian 1y ago
  It sounds like some people who are running multiple AI tasks in parallel might be risking burnout because they think they need to keep machines busy. But this is a symptom of systems that don’t run fast enough to be interactive. If compiles take ten minutes then sure, you’re going to want to do something else while waiting. If they take two seconds, you stop caring about keeping the machine busy because it’s impossible. It’s perfectly normal for computers to be idle waiting on you most of the time.
• Otek 1y ago
  What’s the point of this kind of division? Should developers who use JetBrains instead of Vim be called something different too? Or if one person uses Google and another relies on a book, are they somehow different kinds of engineers? What are we actually trying to achieve with this distinction? Vibe coder is not engineer because the person doing it doesn’t really interact with the code. But the tools a professional engineer uses for assistance shouldn’t matter at all, should they?
  • JamesSwift 1y ago
    The distinction is specifically because its not about the tooling differences, its about the mindset and workflow. "Vibe coding" is a dirty word. It comes with an assumption of YOLO'ing until something maybe kind of works. "Vibe engineering " is the complete opposite side of the spectrum - high-touch, high-engagement management of the AI agents, often with a specific plan or design in mind that you are working toward. I agree we need a different word for it but I dont like "vibe engineering".
• xg15 1y ago
  > "If you’re going to really exploit the capabilities of these new tools, you need to be operating at the top of your game. You’re not just responsible for writing the code—you’re researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review." I know this paragraph is supposed to be encouraging, but it makes me wonder again what the actual goal of this entire AI enterprise is supposed to be. "Less work" or "easier work" would make superficial sense, but in a society where people are in constant competition and derive both their self worth and their basis for living from work, both are effectively anti-goals. And so we get articles like this trying to offer comfort by saying that work will still be draining and challenging in the future. So if not less work, then "more productivity", i.e. we can produce more software in a shorter amount of time (but with the same mental load). But as others have said, this was never the bottleneck.
• voidhorse 1y ago
  I get the impetus behind the term and I think it's a good article with a lot of practical advice overall, however I am disheartened by the terminology on two fronts: 1. It is confusing in the sense that all other engineering disciplines have the form "<X> engineering" where X is the object being engineered. This makes it sound like we are engineering vibes, not software. 2. Software engineering was already only marginally worthy of the term "engineering". There is a strong subset of computational system building that I think actually meets the standard of engineering (rigorously understanding requirements and system bounds, probably showing that the system achieves stability within those bounds). This just makes that situation worse. The devil is in the details, and over-reliance on llms ultimately makes those details a black box to the designer. Before you claim it's the same as when a designer relies on a suite of humans—no. The designer can ask those humans for reverentially transparent proofs that certain conditions are upheld, there is a social accountability structure, etc etc all of which does not exist with LLMs even if they get good enough that we can just trust them. If we are going to keep calling software construction engineering, can we please at least get industry wide standards around ethics before we go off vibing? There's so much that we still sorely need in order to really make this discipline rigorous and socially accountable in the first place.
• hansmayer 1y ago
  Just reading that exhaustive list of what you supposedly need to do to "be successful" with the non-deterministic-random-text-generation tool shows clearly this is a solution in search of a problem. As engineers we need to principally reject what the disconnected billionaire class are currently pushing on us with these non-tools and this is not, I want to stress that, not because we fear "replacement" - I don't think these machines can replace even the Joe Bullshit in powerpoint generation, as evident from the recent case with Deloitte in Australia. The reason is more profound - these tools endanger the quality of not just engineering, but also outputs in other fields and as such are plain dangerous to the society. If this is supposed to be the future of engineering, then doors falling of Boeings will be but funny anecdotes of "better times" I am afraid. No, this cannot be the future of engineering and in general professional work, unless we want to become again disenfranchised and ignorant serfs.
  • voidhorse 1y ago
    Amen brother. Other engineers directly recognize the duty they owe to society beyond the duty they owe to any particular company, they have certifications boards and ethical standards for precisely this reason. It's high time software engineers do the same if they really want to be engineers and not just corporate lackeys who happen to know how to program and/or design computational systems.
• d--b 1y ago
  The corollary to that is that keeping a shitty legacy codebase will keep you employed longer, since AI won't find its way through it, and screw everything up every time it touches anything. This is making me like the written-by-math-grad-school-interns python mess I inhereted!
• dcreater 1y ago
  Please no. We already have a bunch of (human society) semantic slop from vibe coding term being misused. The last thing we need right now is another poorly developed term
• krychu 1y ago
  It’s great to read in the comments about experiences of others with vibe coding. But I also feel like lots of opinions are not coming from actual experience, or “serious” attempts at vibe coding, and more from theoretical deliberations. I might be wrong. Here are some of my own high-level experiences / thoughts: - Perhaps contrary to popular belief I think vibe coding will bring the best software / system architects. This is due to massively shortened feedback loop between architectural idea and seeing it in action, easiness with which it can be changed, and the ability to discuss it at any moment. - We’re not really coding anymore. This is a new role, not a role of a senior dev reviewing PRs of junior devs. Devs are just best suited (currently) to take on this new role. I came to realization that if you’re reviewing all generated code in detail you’re doing it wrong. You just shifted bottleneck by one step. You’re still coding. You should skim if the code is in line with your high-level expectation and then make LLM maintain an architecture doc and other docs that describe what and how you’re building (this is the info you should know in detail). You can do audits with another LLM whether the implementation is 100% reflecting the docs, you can chat with LLM about implementation at any moment if you ever need. But you should not know the implementation the way you know it today. The implementation became the implementation detail. The whole challenge is to let go of the old and embrace and search for efficiency in the new setup. - Connected to the above: reading through LLM outputs is a massive fatigue. You are exhausted after the day, because you read hundreds of pages. This is a challenge to fight. You cannot unlock full potential here if you aim at reading and reviewing everything. - Vibe coding makes you work on the problem level much more. I never liked the phrase “ideas are cheap”. And now finally I think the tides will turn, ideas are and will be king. - Devil is in the detail, 100%. People with ability to see connections, distill key insights, communicate and articulate clearly, think clearly, are the ones to benefit. Hope this is helpful for others.
• yobid20 1y ago
  These people havent deployed anything to a production environment that requires reliability and support. For that, you need a real software engineer to take apart the mess of vibe coded kludge and create real software that can actually be given to people to use. I wouldnt worry about this. Vibe coding trend is already on its way out as people discover this.
• nadis 1y ago
  I like the idea of finding an alternative name to "vibe coding" to describe this more substantive alternative. However, I personally think the name "vibe engineering" is too close to vibe coding and not sufficiently distinct. I don't have a great alternative unfortunately. I've used "agentic coding" in the past as a means of differentiating from vibe coding, but I don't think that's necessarily clear enough either. That said, maybe with defining this new approach it's just going to take time for any term to become familiar enough to be self-explanatory.
  • reaperducer 1y ago
    However, I personally think the name "vibe engineering" is too close to vibe coding and not sufficiently distinct. Funny, because when I saw that phrase I immediately thought, "They're using chatbots to design bridges now?"
• monster_truck 1y ago
  Needless country club chicanery.
• WesolyKubeczek 1y ago
  Marvelous, now all we need is "vibe civil engineering".
• moomoo11 1y ago
  Nah. Software engineer. Not vibe engineer. Not Java engineer. Not compiler engineer. You either understand the computer and then can apply any fucking tool or methodology to solve a problem, or you’re out.
• pawelhuryn 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• jcmontx 1y ago
  My thoughts: * There are actual productivity gains to Agentic Coding (my tool of preference is Claude Code) * There is a big chance of producing a lot of slop if one does not use it with care * More than ever checking mechanisms are essential (static type checking and a good unit testing suite) * Everything that was boring and tiresome about unit testing is now mandatory since you will be writing almost none of it.
• skeeter2020 1y ago
  We've already 90% killed the word "engineer" by applying the title to someone who completes a 6 week bootcamp; this should pretty much finish it off. I don't see much engineering in the list of benefits; mostly seem like administration, and it's even referenced so why not call it "vibe management"? AI seems far closer to replacing mid-senior managers than it does developers.
  • uselesswords 1y ago
    Some would say we killed the word "engineer" when we started applying it to programmers...
• jama211 1y ago
  Beautifully put. This puts into words what I was unable to say to those who claim all ai is useless and can only produce slop, if the human is TRULY in control it’s an entirely different ball game. Thank you for this.
• jama211 1y ago
  We might just have to accept that it’s software engineering. Not vibe engineering, just engineering. Proper engineering has never shied away from using smart tools, it’s about ownership, accountability, planning, etc etc and you’re still doing all that. If you sign off properly on everything, it’s yours. It’s engineering, that’s it. Smart tools have existed forever, or we’d all be coding in assembly still. As long as we take ownership of the code and the result that’s it.
• infomiho 1y ago
  I've been successfully "vibe engineering" with Claude Code for a week now on a side quest at my job. I want the result to be of high enough quality to maybe survive in our codebase long-term, but I don't want to write it myself. So I've added unit tests, e2e tests, formatting checks to help Claude to self-correct as much as possible. And I make him do a TON of self-review, after each feature I say something like: > You are a master reviewer, lots of practical experience. Read Clean Code. Great at architecture. Read Effective Typescript as well. What would you comment in a PR review? Type checking MUST PASS, unit tests must PASS, formatting must PASS. With each review, Claude catches a lot of sub-optimal choices it made which gives me more confidence in the code I get in the end.
  • drcxd 1y ago
    Do you really believe that if you miss the "Read Clean Code" or "Read Effective Typescript" part, then the output would be significantly different? No offense, but I feel this kind of talking is ridiculous. If it is a better practice, then it should be done without explicitly telling so. You do not tell them "Do not get things wrong," right? If it is a matter of choice over design patterns, for example, use functional programming or object oriented programming paradigm, then it should be said more clearly as what I have done. Now, if it is neither something that is definitely a better practice nor something you can state clearly with a known, well-defined word, how can you make sure what you have said really make a difference if you have not said it?
    • infomiho 1y ago
      It works for me and I like the results I'm getting. The results often include callbacks to rules of thumb from the mentioned books - which I find easier to agree with or dismiss when I see the suggestions it made. In a way, it's a framework for me to "communicate" with the LLMs. I think you should try finding what works for you, maybe even give my ridiculous prompt a go.
• bookofjoe 1y ago
  FWIW, from the perspective of a non-coder: the tone of the comments in the discussion here is markedly different from those on similar topics six months ago and earlier in that there is no rage and contempt for LLM/vibe coding any more, but rather a reasoned discussion.
• geldedus 1y ago
  How about : AI-assisted programming.
• fourthark 1y ago
  > It’s a lot easier than working with actual people because you don’t have to worry about offending or discouraging them But you have to worry much more about confusing LLMs by introducing contradictory ideas or talking about too many things at once. They will not call you out and they will not recover. You don’t need to reboot your coworkers.
  • simonw 1y ago
    Life would be so much easier if you could reboot your coworkers! One of the best solutions to most LLM problems is to wipe the context and go back to a clean slate.
• dogbait 1y ago
  I work at a FAANG adjacent company as an EM and the 4x engineers who’ve recently been PIPd all went off the deep end using agents to write huge amounts of convoluted or unsuitable code. One of them has decades of experience coding and even devised our onboarding training for using Cursor and Bedrock at the company but they too were called out for building a wholly unsuitable and unmaintainable service which could have been more simply solved with some common libraries and Docker micro services rather than 10k+ lines of custom code. We all receive a copy of Cursor and IntelliJ + Copilot on joining and I just keep seeing engineers (surprisingly the more experienced ones so far) footgunning themselves with these tools.
• roman-mazur 1y ago
  https://docs.vibe-coding-framework.com/ https://docs.vibe-coding-framework.com/ This seems to be in the same spirit