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
Don't worry, it's probably only the impostor syndrome [1]. 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.
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.
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.
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)
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.
Literally all of the results for "pigeon random rewards" answer your question and those are the obvious keywords from parent's comment. Have people forgotten how to use search engines too?
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
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.
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.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
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.
My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
I don’t think people are good at self-reporting the “boost” it gives them.
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
> They choke on anything that isn’t a greenfield project and consistently produce unwanted results.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
I think the thing people have to understand is how fast the value proposition is changing. There is a lot of conversation about "plateauing" model performance, but the actual experience from the combination of the model and tooling changes is night and day in the last 3 months. It was beginning to be very useful with Claude 3.7 in the spring this year, but we have just gone through a step function change.
I was decomissioning some code and I made the mistake of asking for an "exhaustive" analysis of the areas I needed to remove. Sonnet 4.5 took 30 minutes looking around and compiling a detailed report on exactly what needed to be removed from this very very brownfield project and after I reviewed the report, it one shot the decommisioning of the code (in this case I was using CLaude in the Cursor tooling at work). It was overkill, but impressive how well it mapped all the ramifications in the code base by greping around.
I guess we just have to take your word for this, which is somewhat odd considering most of your comments link back to some artifact of yours. Are you paid by any of these companies?
I'm not paid by any of them, but I occasionally get preview access to models or invites to events. I attended OpenAI's DevDay on Monday for free, for example.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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!
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.
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.
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.
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.
>> 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.
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.
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.
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.
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/
> 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.
likewise, for a lot of frontend I "vibe code" it. I mostly don't look at the code anymore while doing it either, after I get where I want, I will look through the code and maybe clean stuff up. But a lot of the code is fine. Works really well I find. (using Augment Code with Claude Sonnet 4.5).
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.
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.
It will certainly be the default for cases where it's easier to read code than to write code, but this is far from universally true. AFAIK, Joel Spolsky was the first to discuss this at length 25 years ago [0], but numerous people have echoed his sentiment [1, 2, 3, ...]
One of the most underrated skills in effectively using gen-AI for coding is knowing ahead of time whether it will take longer to carefully review the code it produces, versus writing it from scratch yourself.
Sadly the times where people joined software engineering for passion are way behind. People nowadays join just for the money or because it has lot of jobs available.
It is very easy to notice at work who actually likes building software and wants to make the best product and who is there for the money, wants to move on, hard code something and get away with the minimal amount of work, usually because they don't care much. That kind of people love vibe coding.
I don't like the kind of programming that an LLM can easily accomplish.
For instance, I recently had to replace a hard-coded parameter with something specifiable on the command line, in an unfamiliar behemoth of a Java project. The hard-coded value was literally 20 function calls deep in a heavily dependency-injected stack, and the argument parser was of course bespoke.
Claude Code oneshotted this in about 30 seconds. It took me all of 5 minutes to read through its implementation and verify that it correctly called the custom argument parser and percolated its value down all 20 layers of the stack. The hour of my time I got back from having to parse through all those layers myself was spent on the sort of programming I love, the kind that LLMs are bad at: things like novel algorithm development, low-level optimizations, designing elegant and maintainable code architecture, etc.
wait you were unfamiliar with a behemoth Java project to the point of dreading making the change yourself, and yet only spent 5 minutes reviewing "someone else's" PR?
Yup. Replacing a single hard-coded parameter with a command line argument is hardly an earth shattering change. It's trivial to verify that the argument properly gets passed down the stack (and that passing it has no side-effects), but figuring out that stack in the first place would have taken a much longer time. Think of it like an NP-complete problem: hard to solve, but easy to check that a solution is correct.
For more complex modifications, I would have taken the time to better internalize the code architecture myself. But for a no-brainer case like this, an LLM oneshot is perfect.
Sorry if I haven't been clear: it's one variable, used exactly once at the very bottom of the call stack. The change only required adding a corresponding extra argument or class member to all of the functions/classes upstream. In fact, there were other variables in the caller of the bottom function that get passed down from the command line, a pattern that the LLM likely picked up on (and exactly what clued me in to the fact that the LLM would likely make this change very easily, a hunch that proved correct).
You raise a good point: an important skill in effectively using LLMs for coding is both being able to recognize ahead of time that cases like this are indeed simple, but also recognizing after the fact that the code is more complex than you initially realized and you can't easily internalize the (side) effects of what the LLM wrote, warranting a closer look.
I dunno, I feel lately like we are right at the tail end of the honeymoon era and about to enter the era where the blog topic du jour is “use LLMs, not too much, mostly on a short leash”.
Not much to base that on other than vibes, though :)
As much as I dislike the ecosystem around AI and don't enjoy using them as tools: this is the answer. We don't need a word for "doing the job properly with new tools".
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".
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.
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?
You don't "program" with punch cards any more than you "program" with text files. They were just the mechanism to get your code into the computer before hard drives and compilers existed.
I feel a certain way when I work with older programmers who used to program using punch cards, and debug actual core dumps, i.e. the main memory of the computer printed out in hex. They have incredible attention to detail, and can reason about why their programs didn't do what they expected.
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]
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.
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.
> 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:
I agree with both of you. Some coding is part of a real engineering process. That's why I don't like using "engineering" to refer to coding broadly - because it loses that specificity and connotation.
As "coders" or "programmers", some of us should answer the question "are you an engineer?" with a proud "of course not!" (That's me.) And some of us should answer, equally proudly, "of course I am!"
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.
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.
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!
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.
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"
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.
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...
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.
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.
Then it turns out that your CI gates are green because your tests are all subtly broken, the code you've been reviewing doesn't matter and the code you haven't been reviewing is what's broken in production. You learn from that and rebuild the universe, but now you're compute-limited from rebuilding your agents to deal with the underlying issue in your tooling and you have to dig yourself out of a hole you dug with a large derrick using nothing but a shovel.
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.
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.
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.
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.
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.
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!
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).
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.
[1] https://en.wikipedia.org/wiki/Impostor_syndrome
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.
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.
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)
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!
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
https://en.wikipedia.org/wiki/B._F._Skinner
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.
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.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
Have you isolated if you're properly honing in on the right breadth of context for the planned implementation?
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
I was decomissioning some code and I made the mistake of asking for an "exhaustive" analysis of the areas I needed to remove. Sonnet 4.5 took 30 minutes looking around and compiling a detailed report on exactly what needed to be removed from this very very brownfield project and after I reviewed the report, it one shot the decommisioning of the code (in this case I was using CLaude in the Cursor tooling at work). It was overkill, but impressive how well it mapped all the ramifications in the code base by greping around.
I have a disclosures section on my blog here: https://simonwillison.net/about/#disclosures
No, I just put in less effort to arrive at the same point and do no more.
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.
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.
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.
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.
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.
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.
> 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.
“casing”?
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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
How does "vibe coding" embody "best practices" as the industry generally defines the latter term?
As I understand the phrase "vibe coding", it implies focusing solely on LLM prompt formulation and not the specifics of the generated source.
> It'll just be how almost everyone writes code in the future. Just like using an IDE.
The flaw with this analogy is that a qualified developer does not require an IDE in order to be able to do their job.
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.
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.
One of the most underrated skills in effectively using gen-AI for coding is knowing ahead of time whether it will take longer to carefully review the code it produces, versus writing it from scratch yourself.
[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[1] https://mattrickard.com/its-hard-to-read-code-than-write-it
[2] https://trishagee.com/presentations/reading_code/
[3] https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
[...] https://www.google.com/search?q=it%27s+harder+to+read+code+t...
It is very easy to notice at work who actually likes building software and wants to make the best product and who is there for the money, wants to move on, hard code something and get away with the minimal amount of work, usually because they don't care much. That kind of people love vibe coding.
For instance, I recently had to replace a hard-coded parameter with something specifiable on the command line, in an unfamiliar behemoth of a Java project. The hard-coded value was literally 20 function calls deep in a heavily dependency-injected stack, and the argument parser was of course bespoke.
Claude Code oneshotted this in about 30 seconds. It took me all of 5 minutes to read through its implementation and verify that it correctly called the custom argument parser and percolated its value down all 20 layers of the stack. The hour of my time I got back from having to parse through all those layers myself was spent on the sort of programming I love, the kind that LLMs are bad at: things like novel algorithm development, low-level optimizations, designing elegant and maintainable code architecture, etc.
For more complex modifications, I would have taken the time to better internalize the code architecture myself. But for a no-brainer case like this, an LLM oneshot is perfect.
It's not so trivial to verify that the change doesn't cause problems elsewhere, where it also should have been propagated.
You raise a good point: an important skill in effectively using LLMs for coding is both being able to recognize ahead of time that cases like this are indeed simple, but also recognizing after the fact that the code is more complex than you initially realized and you can't easily internalize the (side) effects of what the LLM wrote, warranting a closer look.
Today: 'code is cheap, show me the talk'
Not much to base that on other than vibes, though :)
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
For the experienced lot of us, I've heard many call it "hyper engineering"
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.
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.
I have fairly decent engineering credentials, but when the task fits, I prefer to vibe code.
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/
As "coders" or "programmers", some of us should answer the question "are you an engineer?" with a proud "of course not!" (That's me.) And some of us should answer, equally proudly, "of course I am!"
Hillel Wayne's series is great.
Just don't capitalize it in Oregon.
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.
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.
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!
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.
[1] https://simonwillison.net/2025/Jun/27/context-engineering/
Don’t mind me, I’m just vibing.
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.
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.
I am on the stupid side, personally.
We didnt stop calling them Framers or Finish Carpenters when they got electric saws and nail guns.
Tooling does not change the job requirements.
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.
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).
Ill stick with writing code and just use AI for snippets/stackoverflow replacement.
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