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

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.

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.

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

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.

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.

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

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.

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

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?

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.

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?

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.

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.

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.

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?

We should just call it engineering. We got better tools. Big whoop.

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.

No. “Vibe” is what captures the irresponsible usage. “Automated engineering” is much closer to the mark.

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.

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.

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.

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

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.

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, ...

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.

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.

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

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.

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.

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

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.

Simon went quickly from not agreeing with common buzz words to making up his own.

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.

@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.

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.

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

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.

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.

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

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.

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

I also mentioned it in our podcast in April 2025: 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

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

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

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.

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.

I’d just call it “coding” – it’ll be the default soon enough. For the old way: “hand-coding”

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.

I call it … using a chatbot to code.

Don’t mind me, I’m just vibing.

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.

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

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)

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.

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

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?

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).

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.

> 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

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.

I think this complements in a good way with "context engineering"[1], that's great.

[1] https://simonwillison.net/2025/Jun/27/context-engineering/

Is cost a risk here? I'm assuming that sometime in the future the price for vibe coding/engineering will go up significantly.

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

Needless country club chicanery.

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.

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.

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.

I call it PEAKS: Performative Extreme Agile Kiddie Scripting

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

Call it autonomous engineering. Vibes are optional.

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

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.

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.

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"

there is no such thing as vibe engineering no matter how much you want to make it up

No, thank you.

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

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.

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.

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

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.

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.

so the progression of human technological revolutions is looking like industrial -> information -> AI -> vibe

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

>> 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

we could call it "Reasonable AI Liability" like Ruby does ;)

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!

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.

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!

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.

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.

These words just don't belong together, period.

The headline made me think of a bridge designed by an LLM, and I think to myself: thanks, I'll pass.

Sadly, "vibe engineering" is already real, but associated with half assed engineering, rather than effective use of LLMs lol.

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

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).

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!

Vibe engineering is what vibe coders think they do.

Please stop with all this vibe bs. Seems like a desperate attempt at getting viral.

Centaur Coding.

Isn't that what a meth cook does?

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.

hi Simon - just a note to say that your link to https://tools.simonwillison.net/ goes to https://simonwillison.net/

Think this might be a typo

I think the definition isn’t accurate, it’s more like engineering using AI.

Worse possible name to be honest.

Thanks for the AI slop blog content

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.

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

Welcome to me 13 years ago when India happened. Nobody cared back then. So I just left.

Marvelous, now all we need is "vibe civil engineering".

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.

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.

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.

"Vibe coding" sounds too good. Catchy, ridiculous and still cool. It'd be hard to beat. It's a genius move from Andrej Karpathy.