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
I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them".
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
While this is true, I definitely find that the style of the work changes a lot. It becomes much more managerial, and less technical. I feel much more like a mix of project and people manager, but without the people. I feel like the jury is still out on whether I’m overall more productive, but I do feel like I have less fun.
I appreciate what you're trying to do, but for myself, I'm not depressed because my skills are less valuable. I enjoyed the money but it was never about that for me. I'm depressed because I don't like the way this new coding feels in my brain. My focus and attention are my most precious resources and vibe coding just shatters them. I want to be absorbed in a coding flow where I see all the levels of the system and can elegantly bend the system to my will. Instead I'm stuck reviewing someone/something else's code which is always a grind, never a flow. And I can feel something terrible happening in my brain, which at best can be described as demotivation, and at worst just utter disinterest.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
I don't think OP thinks his skills are useless per se now, but that the way to apply those skills now feels less fun and enjoyable.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
But does anybody really care about what you like? What about all those other professions that got replaced by technology, did anybody care what they liked? The big question is how is software going to be build most efficiently and most effectively in the future and how do you prepare yourself for this new world. Otherwise you’ll end up with all those other professions that got replaced, like the mineworkers, hoping that the good old days will someday return.
Spec-Driven Development treats the spec as the source of truth and the code as an artifact. As you develop, you modify/add to the spec and the codebase gets updated to reflect it.
Personally I'm doubtful it can compete with traditional artisanal software engineering, as it's (IMHO) boils down to "if only you can spec it precisely enough, it'll work" and we've tried this with 5GL and (to some extent) BDD, and it doesn't get you to 100%.
I do think it's interesting enough to explore, and most of us could use a bit more details in our Jira tickets.
The "manage a fleet of massively parallelized agents" gets me uneasy too. It sounds uber powerful on its face. And where all the nerd interest lies.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Absolutely this. LLM assistance means we can work faster, and that we can build things that previously weren't feasible given the available time and resources.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
Keep your head up, the gravy train is not gonna run forever, and they will need serious engineers to untangle the piles of bullshit creates in these past few years.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
I don't really agree. The writing is on the wall, if not now then in 2 years or 4 years. I arrive at this view not so much based on the capabilities of the tools right now, but based on the property of software being verifiable, which like mathematics, makes it amenable to synthetic data pipelines, with only relatively small remaining details needing to be worked out (such as how to endow architectural taste). This is not nearly the first industry where 'artisans' have been initially augmented by innovation, only to be eventually replaced by it, which in my view will occur likely within my own career-span.
If you're genuinely already good at coding, use the LLM to go horizontal into other complementary verticals that were too expensive to enter prior. Do the same thing that the other professions would do unto yours.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
> It makes me want to move into something completely different like sales
I'm feeling the same. The moves I'm considering are
1. Landscaping
2. Carpentry
3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
Do not worry, I am mentoring a young engineer in my team. It is painfully hard to get him to improve his code, because it works. It is badly structured, lot of small "impedance mismatches", lot of small security issues, all that in 3 Python files.
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
You word quite well how I feel about it.
On top of not really liking babysitting an AI , I'm also very afraid of the way this whole AI coding business normalizes needing an account with some nebulous evil empire to even be able to do your work. Brrr.
I can relate with you. I love programming and building things, gives a different kind of rush when you finally figure out something. I've done vibe coding and don't enjoy it at all. I always thought my love for coding gives me an edge over other engineers who just want to get the job done. Now it's holding me back and I'm not sure if I should continue working in this field or if start doing wood working or something.
100%. Imagine how young people feel. When they’re still trying to figure things out, their parents and teachers just as clueless as they are, and at the same time the expectations of them are infinitely higher. “You’re pretty good, but chatgpt is still better. Try harder.”
Don't worry, it's probably only the impostor syndrome. Your development skills are still relevant. Think of agents as junior developers that assist you in coding tasks, whom you constantly need to mentor, review, and correct.
I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this:
1. Collaborate on a detailed spec
2. Have it implement that spec
3. Spend a lot of time on review and QA - is the code good? Does the feature work well?
4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar
That last step is the interesting one. You're right: humans improve, LLMs don't... but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work.
I've heard similar things from a few people now: by constantly iterating on their CLAUDE.md - adding extra instructions every time the bot makes a mistake, telling it to do things like always write the tests first, run the linter, reuse the BaseView class when building a new application view, etc - they get wildly better results over time.
Totally agree on this. It has delivered a substantial value for me in my projects. The models are always going to give back results optimized for using minimal computing resources in the provider's infrastructure. To overcome this I see some using/suggesting, running the AI in self correction loops, the pro being least human intervention.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
AGENTS.md is just a place to put stuff you don't want to tell LLMs over and over again. They're not magical instructions LLMs follow 100% of the time, they don't carry any additional importance over what you put into the prompt manually. Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are. Somewhere around 100k tokens AGENTS.md might as well not exit, I constantly have to "remind it" of the very first paragraph there.
Go start a conversation and contradict what's written in AGENTS.md half way through the problem. Which of the two contradicting statements will take preference? The latter one! Therefore, all the time you've spent curating your AGENTS.md is the time you've wasted thinking you're "teaching" LLMs anything.
Whether the tokens are created manually or programmatically isn't really relevant here. The order and amount of tokens is, in combination with the ingestion -> output logic which the LLM API / inference engine operates on. Many current models definitely have the tendency to start veering off after 100k tokens, which makes context pruning important as well.
What if you just automatically append the .md file at the end of the context, instead of prepending at the start, and add a note that the instructions in the .md file should always be prioritized?
I’m finding that whether this process works well is a measure (and a function) of how well-factored and disciplined a codebase is in the first place. Funnily enough, LLMs do seem to have a better time extending systems that are well-engineered for extensibility.
That’s the part which gives me optimism, and even more enjoyment of the craft — that quality pays back so immediately, makes it that much easier to justify the extra effort, and having these tools at our disposal reduces the ‘activation energy’ for necessary re-work that may before have just seemed too monumental.
If a codebase is in a good shape for people to produce high-quality work, then so too can the machines. Clear, up-to-date, close-to-the-code, low redundancy documentation; self-documenting code and tests, that prioritizes expression of intent over cleverness; consistent patterns of abstraction that don’t necessitate jarring context switches from one area to the next; etc.
All this stuff is so much easier to lay down with an agent loaded up on the relevant context too.
Edit: oh, I see you said as much in the article :)
> Can we all agree that "mentoring" LLMs is actually a waste of time, please?
Sorry, we can't. While it's true that you can't really modify the underlying model, updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring.
> It makes me want to move into something completely different like sales
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
It is just a new way of coding. And indeed what the blog post said, if you are experienced, you will benefit the most as the AI agent will make similar mistakes as a junior and you will be able to recognize them.
But indeed, the fun part of coding a couple of routines is gone. That is history.
The experience you have is something most youngsters won't ever get, because they won't have the time. You've become more valuable than you used to be, because you know exactly what works when and what doesn't. The hard part is being able to find the joy in making agents do what you want achieved instead of building it yourself. I think it actually isn't too hard once you get up to speed with managing multiple agents - efficiently juggling them feels like an art performance sometimes.
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.
At $enterprise, we were just looking for a proper term that sets "responsible vibing" apart from "YOLO vibe coding". We landed on "agent assisted coding".
It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.
> now semantically shifted to mean all AI-assisted coding.
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote.
- The code created hasn't been reviewed in any way to look for possible future issues.
- Technical debt from the get go.
- Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
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.
“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.”
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?
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.
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.
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.
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.
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.
Yeah I couldn't put it better myself. It's obscene how much more productive you become in new domains. And sure, you eventually hit a wall where you gotta understand it for real. But now you have a working example of your project, plus a genius who will answer unlimited questions and clarifications.
Anything that's been done before. Otherwise we'd probably start with making nuclear fusion work, then head off into the stars...
You've always been able to read books. What you're talking about is skipping the slow learning step and instead generating a mashup of tons of prior art. I don't think it helps you learn. It sounds like it's for things you specifically don't want to learn.
Congrats, you now have a job similar to a factory worker turning a handle every day. Gone is that feeling of growth, that feeling of "getting it" and seeing new realms of possibility in front of you. Now all you can do is beg for more grease on your handle.
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.
> My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
At this point I'd say that I'm 1000% more productive in the aspects that I use it for. I rarely hit any walls, and if I do its absolutely always down to an unclear or incomplete thought progress or lack of clarity in prompting.
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.
Indeed, Codex CLI is quite useful even for demanding tasks. The current problem is that it might gather context for 20 minutes before doing the actual thing. The question is whether this will be sped up significantly.
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?
OP is one of the co-creators of Django (for which I am eternally grateful, having built my first company on top of it) and one of the most prolific writers in the space. I also happen to strongly agree with his assessment, though as he said getting that amount of value out of current tools is real work.
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.
That the tools do this kind of thing? They do, they’ll go through pretty long multi step processes to find things and edit them. They run tests, check output, see it’s wrong and go and add debug statements, rerun, try and fix things, rerun, then remove the logging.
There's a lot of annoying stuff it can do fairly well without many guardrails. It's a minor productivity boost but it's nice not to have to do.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...
All I've found is the LLM just makes me work more. It's hard to talk about % boost when you're just simply working more hours.
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
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.
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.
You're straining very hard to make your position sound reasonable, but your assumption that I both can't verify the values of the winning combination and wouldn't verify those values is simply not true.
In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. It's actually so repetitive that I'm likely to have made the same kind of mistakes you're alluding to.
As always, I end with encouragement: if you want to do everything the long and hard way, I'm not here to change your mind. You will have to stop being upset that others are moving much faster than you, though. It's a choice.
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...
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.
I think a key skill is knowing what level of complexity a single run can realistically achieve, which is often only a small task and not a fully working build.
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).
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.
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 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).
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.
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.
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.
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.
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)
We tried this as a bit of an experiment - not quite greenfield but a fork and modification of an existing project.
I was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different".
Occasionally I would test changes in staging but mostly would just promote them straight to production. I went on like that for ~3 months and the product ended up getting ~75k (daily!) users in that time with *no* outages or downtime (!!!)
It worked really well! Until I hit my scaling limit and we added more engineers to the team. A new hire on their second week on the job shipped a change that was also written with AI and caused a 7 hour outage before we realized something was wrong. I even *thoroughly reviewed the code* because I knew it was generated and I made a comment questioning the lines that caused the outage, but after we talked it over we decided it was fine and was only one tiny bit of a much larger change.
So I guess, AI will ship bugs but so will peer-reviewed code.
Not just that but PRs are about a lot more than syntactical correctness, it's also about design. Just this week we've had two PR catch bad design choices that came from a fundamental misunderstanding of the problem space. Even if the AI wrote perfect code the first time everytime it wouldn't matter in those cases.
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.
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.
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.
I love programming, but it turns out I love building useful stuff even more than I love programming. Agentic coding helped me fall in love with development all over again. If a team of junior engineers suddenly showed up at my door and offered to perform any tasks I was willing to assign to them for the rest of my life, I'd love that too.
Agentic coding is just doing for development what cloud computing did for systems administration. Sure, I could spend all day building and configuring Linux boxes to deploy backend infrastructure on if the time and budget existed for me to do that, and I'd have fun doing it, but what's more fun for me is actually launching a product.
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?
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.
In some ways slower feedback loops might be useful. Having to think and reason if your code is correct and actually works because you only get output next day...
Instead of just vibing something out, pushing it to prod and seeing the problems. Or not even checking...
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.
Haha - cool that you made a throwaway insult account just for this.
I meant punch cards as a placeholder for programming in a bygone era, about how it feels so different, distant and detached, and that I don't relate to it.
I can see a plausible future where if we go down this route, what I call coding right now will feel the same.
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.
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]
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 can totally relate, very similar situation here.
I am currently kind of an anti-AI black sheep in engineering department because I refuse to fully embrace the exponentials and give in to the vibes.
I avoid burnout by simply switching off my brain from all this noise about vibe coding - i have thought hard and long, i know the way this is being implemented is wrong, i know they will create problems for themselves down the road (they already have, the signs are already there), i will be here to dig them out when the time comes.
So far I don't see anyone shipping faster or better with AI than I can manually, so I'm good.
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 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.
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.
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’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!
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.
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.
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.
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.
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.
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).
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!
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.
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
I’ll find the link in the morning, but I kinda joke - it’s vibe coding for people who know how to define a problem and iterate on it.
I’ve got a project reimplementing a service I want to make more uniform. Claude has produced a lot of stuff that would have taken me weeks to do.
Spec-Driven Development treats the spec as the source of truth and the code as an artifact. As you develop, you modify/add to the spec and the codebase gets updated to reflect it.
Personally I'm doubtful it can compete with traditional artisanal software engineering, as it's (IMHO) boils down to "if only you can spec it precisely enough, it'll work" and we've tried this with 5GL and (to some extent) BDD, and it doesn't get you to 100%.
I do think it's interesting enough to explore, and most of us could use a bit more details in our Jira tickets.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
This is where we should be. Using computers to solve problems. Not just "doing programming".
Raise your head, look towards the horizon.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
I'm feeling the same. The moves I'm considering are
1. Landscaping 2. Carpentry 3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
The reason we invest this time in Junior devs is so they improve. LLMs do not
1. Collaborate on a detailed spec
2. Have it implement that spec
3. Spend a lot of time on review and QA - is the code good? Does the feature work well?
4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar
That last step is the interesting one. You're right: humans improve, LLMs don't... but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work.
I've heard similar things from a few people now: by constantly iterating on their CLAUDE.md - adding extra instructions every time the bot makes a mistake, telling it to do things like always write the tests first, run the linter, reuse the BaseView class when building a new application view, etc - they get wildly better results over time.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
https://gingerhome.github.io/gingee-docs/docs/ai-disclaimer.... https://gingerhome.github.io/gingee-docs/docs/ai-transcript/...
AGENTS.md is just a place to put stuff you don't want to tell LLMs over and over again. They're not magical instructions LLMs follow 100% of the time, they don't carry any additional importance over what you put into the prompt manually. Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are. Somewhere around 100k tokens AGENTS.md might as well not exit, I constantly have to "remind it" of the very first paragraph there.
Go start a conversation and contradict what's written in AGENTS.md half way through the problem. Which of the two contradicting statements will take preference? The latter one! Therefore, all the time you've spent curating your AGENTS.md is the time you've wasted thinking you're "teaching" LLMs anything.
What if you just automatically append the .md file at the end of the context, instead of prepending at the start, and add a note that the instructions in the .md file should always be prioritized?
That’s the part which gives me optimism, and even more enjoyment of the craft — that quality pays back so immediately, makes it that much easier to justify the extra effort, and having these tools at our disposal reduces the ‘activation energy’ for necessary re-work that may before have just seemed too monumental.
If a codebase is in a good shape for people to produce high-quality work, then so too can the machines. Clear, up-to-date, close-to-the-code, low redundancy documentation; self-documenting code and tests, that prioritizes expression of intent over cleverness; consistent patterns of abstraction that don’t necessitate jarring context switches from one area to the next; etc.
All this stuff is so much easier to lay down with an agent loaded up on the relevant context too.
Edit: oh, I see you said as much in the article :)
Sorry, we can't. While it's true that you can't really modify the underlying model, updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring.
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
But indeed, the fun part of coding a couple of routines is gone. That is history.
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 a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
Hmm another idea is "extreme vibe coding" as opposed to "extreme programming",
but those who did "extreme vibe coding" wouldn't know what it meant
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote. - The code created hasn't been reviewed in any way to look for possible future issues. - Technical debt from the get go. - Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
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
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.
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 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.
And you can do this for anything
Anything that's been done before. Otherwise we'd probably start with making nuclear fusion work, then head off into the stars...
You've always been able to read books. What you're talking about is skipping the slow learning step and instead generating a mashup of tons of prior art. I don't think it helps you learn. It sounds like it's for things you specifically don't want to learn.
Congrats, you now have a job similar to a factory worker turning a handle every day. Gone is that feeling of growth, that feeling of "getting it" and seeing new realms of possibility in front of you. Now all you can do is beg for more grease on your handle.
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.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
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.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
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.
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.
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.
In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. It's actually so repetitive that I'm likely to have made the same kind of mistakes you're alluding to.
As always, I end with encouragement: if you want to do everything the long and hard way, I'm not here to change your mind. You will have to stop being upset that others are moving much faster than you, though. It's a choice.
You have not met my cow orkers...
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...
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.
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.
> 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.
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.
> 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.
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
> 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.
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'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.
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 was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different".
Occasionally I would test changes in staging but mostly would just promote them straight to production. I went on like that for ~3 months and the product ended up getting ~75k (daily!) users in that time with *no* outages or downtime (!!!)
It worked really well! Until I hit my scaling limit and we added more engineers to the team. A new hire on their second week on the job shipped a change that was also written with AI and caused a 7 hour outage before we realized something was wrong. I even *thoroughly reviewed the code* because I knew it was generated and I made a comment questioning the lines that caused the outage, but after we talked it over we decided it was fine and was only one tiny bit of a much larger change.
So I guess, AI will ship bugs but so will peer-reviewed code.
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.
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.
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...
Agentic coding is just doing for development what cloud computing did for systems administration. Sure, I could spend all day building and configuring Linux boxes to deploy backend infrastructure on if the time and budget existed for me to do that, and I'd have fun doing it, but what's more fun for me is actually launching a product.
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 :)
Instead of just vibing something out, pushing it to prod and seeing the problems. Or not even checking...
I can see a plausible future where if we go down this route, what I call coding right now will feel the same.
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
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!
I am currently kind of an anti-AI black sheep in engineering department because I refuse to fully embrace the exponentials and give in to the vibes.
I avoid burnout by simply switching off my brain from all this noise about vibe coding - i have thought hard and long, i know the way this is being implemented is wrong, i know they will create problems for themselves down the road (they already have, the signs are already there), i will be here to dig them out when the time comes.
So far I don't see anyone shipping faster or better with AI than I can manually, so I'm good.
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.
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.
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.
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!
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.
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.
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.
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
I am on the stupid side, personally.