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.
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.
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.
>> 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.
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.
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" ??
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".
> 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.