> A vibe coder is someone who wants to test an idea by generating software as a prototype. A software engineer is someone who thinks about the entire software development lifecycle.
I don't think it's such a simple dichotomy; And dismissing the possibilites of agentic coding as inherently non-SWE is rather short-sighted: You CAN use agents as a software engineering tool.
It's just that it's often misaligned with the processes we're used to. But that does not mean that LLM-agents a bad tool.
> dismissing the possibilites of agentic coding as inherently non-SWE is rather short-sighted
The author does not. I recommend reading the whole article, IMO it shows rare (but growing) maturity about software development during this current age of AI tools (I mean in terms of practical day to day use, eg. ignoring (like everybody in tech) the environmental costs). But you might have been misled by how many people have adopted “vibe coding” to mean any use of ai in software dev.
From the article:
> A vibe coder gives the model a goal, but a software engineer gives the model a bounded task. The bounded task is where the engineering happens. Use this interface. Do not touch this layer. And so on. A good prompt is not magic here. It is usually evidence that the engineer already understands the boundary.
> The difference is where the responsibility starts and where it ends.
I think you're missing the point. The post is agreeing with you about using the right tool for the job.
When there's a responsibility to fully understand, demonstrate, and discuss the code at length with various stakeholders, using an LLM can get in the way. There's nobody stopping you from hammering a screw. It's just... cringe.
Yes - the idea of "not knowing what you don't know" is, in my opinion, one of the most important concepts missing from modern programmers (and probably everybody), especially in the age of LLMs. It's the concept that, personally, most occupies my mind every day, and seems to never come into the minds of many of the innumerable contractors with whom I work.
but there is not going to be an inherited and largely non-discardable codebase at every company, right?
and maybe not a team that looks anything like the teams that built and maintain the large codebases that are out there.
the distinction in this article makes all the sense in the world to me, and definitely helps as i try to figure out what term i use to describe my current status as a thing-producer, but part of why i just call myself nothing is it is entirely unclear to me what the new configurations of infra + product vision > actual v0.1.0 launch > new feature development "teamlines" are going to end up looking like.
if i had to guess, one such config might be "the 0.1% of vibe coders who took the HN crickets in response to their projects to figure out how to learn how to do what a product engineering team needs to do end to end to make a self-sustainable product."
(self being that one person, not the product itself)
The analogy I was thinking of as I read this was: an architect that designs a beautiful building as opposed to the workers that take that design and then follow building codes to frame the house, or install the electrical.
The Vibe Coder is the one building prototypes to flesh out ideas, and once they flushed out the idea, they hand if off to the workers to follow standards to implement.
Although at the end of the article he does say that people should fall into both vibe/eng. and that is probably a good place to be to stay relevant in the future.
This doesn't follow at all - architects are much more aware of standards than you are implying. They are not just clueless artists saying "please make it look like this". It's insulting to compare them to vibe-coders.
Unrelated: The phrase is "flesh out". You "flush out" unwanted elements, like rodents.
You're still missing a gap in the middle, where someone knows standards & specifications like "this material in a building this tall will collapse when it gets over 12 stories".
In big enough projects this is the job of a civil engineer. The architect vs engineer fight that ensues is widely memed. This is of course mostly an issue in one-off projects with ambitious architects.
There are priorities here which are not mutually exclusive. If you are building the next big thing in your garage, polishing it before establishing it's in fact the next big thing is a waste of time. If it really is, early adopters / investors will seize on it like they did on AI. Once that is established, yes there is space for adults in the room to adopt proper procedures for large scale production. I do believe AI can help with establishing the next big thing, and if other's don't, it's a irreconcilable difference of opinion.
Agreed. I really don’t think this is worth arguing that AI can be a huge help. I was skeptical until April even after hearing many friends tell me how good Opus 4.5 was last year.
Not working on the “next big” thing but I only recently started finding that AI could solve complex problems for me starting around ChatGPT 5.5. Working on a game engine. Some of the quite isolated modules I’ve had it build are not good code by my own standards. The code has way too many indirections to say the least. But they work without bugs and perform well too (i have a very good CPU and memory management harness for my frame loop). My velocity on the project has doubled at least cause now stuff that I wanted to do down the line is already done. I’m definitely a bit careful with setting up isolated guardlines about which files I let a certain feature touch but with models like Fable even found that unnecessary.
Working code that performs exactly how I want on an outer level is valuable. It can be refactored and rearchitected or reimplemented better by just the virtue of having something to compare against and having the edge cases accounted for.
One of the first things I do before spending time with a coding agent on generating something is having a pretty long reasoning session where I pressure the agent to find out if the problem I'm solving has been solved before, at all, in any way. Most of the time, it has, and it probably doesn't have utility beyond my own personal education in solving it again.
That seems to be what most of these projects that get accused of being "vibe coded" are doing. Incidentally - there's nothing wrong with writing your own useful utilities, and educational to package these up for distribution/release, but don't be surprised if not another soul in the world finds the particular need you had to be one they share.
On one hand, it's very good advice to be clear about PMF. If you have to ask your product doesn't have it. It'll be servers-on-fire obvious when you reach product-market-fit.
On the other hand two things stick out: 1) for every example that proves polishing doesn't matter, there's a successful exception that broke every rule and succeeded anyway. The founder of Figma for example, said he worked on its foundation for something like 4 years before launching. 2) Internet, consumer tech, mobile, sass are all mature markets and the quality bar is very high at this point. It's not obvious that some novel concept will be enough to overcome sheer inertia of status-quo incumbents.
I disagree. At least from my experience it still hallucinates a lot of times - it's just better at hiding that. That causes issues and it's hard to believe for me inexperienced person can spot this problems.
It only hallucinates if you use it wrong. Give it enough requirements, context, keep an eye on all it does (like it were a junior developer), and you will get awesome results. AI code assistants are a fantastic tool that can make you 10-100x more productive provided that you know how to use them.
Most of the people saying the kind of things you say don't know how to properly use an AI code assistant.
That's a very lackluster argument. Even if everything you said was true (and to be clear: it absolutely isn't; LLMs will hallucinate no matter what as it's in their very nature), that's still a flaw in the tool. A good tool must not require convoluted dances to make it work halfway decently.
AI code assistants are lazy junior developers (so you need to keep an eye on everything they do, e.g. make sure they don't forget or ignore to do some parts of the work you tell them to do) with the ability to do research as in-depth as a senior developer. Now make your mind about it. When driving an AI code assistant, you must act like you are a softare development manager managing a team of junior developers.
Giving it access to JIRA doesn't make the code it produces more mergable, or reduce the cognitive load and technical debt a massive PR written by AI introduces into complex codebases.
> A vibe coder is someone who wants to test an idea by generating software as a prototype. A software engineer is someone who thinks about the entire software development lifecycle.
I don't think it's such a simple dichotomy; And dismissing the possibilites of agentic coding as inherently non-SWE is rather short-sighted: You CAN use agents as a software engineering tool.
It's just that it's often misaligned with the processes we're used to. But that does not mean that LLM-agents a bad tool.
> dismissing the possibilites of agentic coding as inherently non-SWE is rather short-sighted
The author does not. I recommend reading the whole article, IMO it shows rare (but growing) maturity about software development during this current age of AI tools (I mean in terms of practical day to day use, eg. ignoring (like everybody in tech) the environmental costs). But you might have been misled by how many people have adopted “vibe coding” to mean any use of ai in software dev.
From the article:
> A vibe coder gives the model a goal, but a software engineer gives the model a bounded task. The bounded task is where the engineering happens. Use this interface. Do not touch this layer. And so on. A good prompt is not magic here. It is usually evidence that the engineer already understands the boundary.
From the article:
> The difference is where the responsibility starts and where it ends.
I think you're missing the point. The post is agreeing with you about using the right tool for the job.
When there's a responsibility to fully understand, demonstrate, and discuss the code at length with various stakeholders, using an LLM can get in the way. There's nobody stopping you from hammering a screw. It's just... cringe.
The vibe coder doesn't know what they don't know, so they rely on the LLM to make decisions.
The Software Engineer will know what decision to make even without looking at the code.
Yes - the idea of "not knowing what you don't know" is, in my opinion, one of the most important concepts missing from modern programmers (and probably everybody), especially in the age of LLMs. It's the concept that, personally, most occupies my mind every day, and seems to never come into the minds of many of the innumerable contractors with whom I work.
Different times, different comparisons! This is from back in the day https://www.hanselman.com/blog/am-i-really-a-developer-or-ju...
but there is not going to be an inherited and largely non-discardable codebase at every company, right?
and maybe not a team that looks anything like the teams that built and maintain the large codebases that are out there.
the distinction in this article makes all the sense in the world to me, and definitely helps as i try to figure out what term i use to describe my current status as a thing-producer, but part of why i just call myself nothing is it is entirely unclear to me what the new configurations of infra + product vision > actual v0.1.0 launch > new feature development "teamlines" are going to end up looking like.
if i had to guess, one such config might be "the 0.1% of vibe coders who took the HN crickets in response to their projects to figure out how to learn how to do what a product engineering team needs to do end to end to make a self-sustainable product."
(self being that one person, not the product itself)
The analogy I was thinking of as I read this was: an architect that designs a beautiful building as opposed to the workers that take that design and then follow building codes to frame the house, or install the electrical.
The Vibe Coder is the one building prototypes to flesh out ideas, and once they flushed out the idea, they hand if off to the workers to follow standards to implement.
Although at the end of the article he does say that people should fall into both vibe/eng. and that is probably a good place to be to stay relevant in the future.
This doesn't follow at all - architects are much more aware of standards than you are implying. They are not just clueless artists saying "please make it look like this". It's insulting to compare them to vibe-coders.
Unrelated: The phrase is "flesh out". You "flush out" unwanted elements, like rodents.
The analogy, not the 1 to 1 translation, is that the architects come up with the ideas and pass them off to the workers to implement.
You're still missing a gap in the middle, where someone knows standards & specifications like "this material in a building this tall will collapse when it gets over 12 stories".
In big enough projects this is the job of a civil engineer. The architect vs engineer fight that ensues is widely memed. This is of course mostly an issue in one-off projects with ambitious architects.
There are priorities here which are not mutually exclusive. If you are building the next big thing in your garage, polishing it before establishing it's in fact the next big thing is a waste of time. If it really is, early adopters / investors will seize on it like they did on AI. Once that is established, yes there is space for adults in the room to adopt proper procedures for large scale production. I do believe AI can help with establishing the next big thing, and if other's don't, it's a irreconcilable difference of opinion.
Agreed. I really don’t think this is worth arguing that AI can be a huge help. I was skeptical until April even after hearing many friends tell me how good Opus 4.5 was last year.
Not working on the “next big” thing but I only recently started finding that AI could solve complex problems for me starting around ChatGPT 5.5. Working on a game engine. Some of the quite isolated modules I’ve had it build are not good code by my own standards. The code has way too many indirections to say the least. But they work without bugs and perform well too (i have a very good CPU and memory management harness for my frame loop). My velocity on the project has doubled at least cause now stuff that I wanted to do down the line is already done. I’m definitely a bit careful with setting up isolated guardlines about which files I let a certain feature touch but with models like Fable even found that unnecessary.
Working code that performs exactly how I want on an outer level is valuable. It can be refactored and rearchitected or reimplemented better by just the virtue of having something to compare against and having the edge cases accounted for.
One of the first things I do before spending time with a coding agent on generating something is having a pretty long reasoning session where I pressure the agent to find out if the problem I'm solving has been solved before, at all, in any way. Most of the time, it has, and it probably doesn't have utility beyond my own personal education in solving it again.
That seems to be what most of these projects that get accused of being "vibe coded" are doing. Incidentally - there's nothing wrong with writing your own useful utilities, and educational to package these up for distribution/release, but don't be surprised if not another soul in the world finds the particular need you had to be one they share.
It's much, much more nuanced than that.
On one hand, it's very good advice to be clear about PMF. If you have to ask your product doesn't have it. It'll be servers-on-fire obvious when you reach product-market-fit.
On the other hand two things stick out: 1) for every example that proves polishing doesn't matter, there's a successful exception that broke every rule and succeeded anyway. The founder of Figma for example, said he worked on its foundation for something like 4 years before launching. 2) Internet, consumer tech, mobile, sass are all mature markets and the quality bar is very high at this point. It's not obvious that some novel concept will be enough to overcome sheer inertia of status-quo incumbents.
> If you are building the next big thing in your garage, polishing it before establishing it's in fact the next big thing is a waste of time.
Ideas are cheap. The execution matters and you need to polish it at least until certain level.
The tool user is <x>, the tool user is <y>.
No, it's just a tool. Like a spoon, or a pen, or a piece of paper, or a vehicle, or a gun.
Just call it vibe coding. You can still be an engineer.
Claude is smart enough now to transition a vibe coder into a software engineer if you provide access to SDLC pipeline.
I disagree. At least from my experience it still hallucinates a lot of times - it's just better at hiding that. That causes issues and it's hard to believe for me inexperienced person can spot this problems.
It only hallucinates if you use it wrong. Give it enough requirements, context, keep an eye on all it does (like it were a junior developer), and you will get awesome results. AI code assistants are a fantastic tool that can make you 10-100x more productive provided that you know how to use them.
Most of the people saying the kind of things you say don't know how to properly use an AI code assistant.
> It only hallucinates if you use it wrong
Sorry but this is demonstrably false. For starters, see the "R's in strawberry" meme.
That's just you being pedantic and asking a language model things it can't do.
Ask it to create a program that counts the R's in any text. Now ask it to do it in 20 different languages. It'll get them right immediately.
It's like me asking you who was the proposed King for Finland and calling you a bad programmer because you don't know.
> It only hallucinates if you use it wrong.
That's a very lackluster argument. Even if everything you said was true (and to be clear: it absolutely isn't; LLMs will hallucinate no matter what as it's in their very nature), that's still a flaw in the tool. A good tool must not require convoluted dances to make it work halfway decently.
AI code assistants are lazy junior developers (so you need to keep an eye on everything they do, e.g. make sure they don't forget or ignore to do some parts of the work you tell them to do) with the ability to do research as in-depth as a senior developer. Now make your mind about it. When driving an AI code assistant, you must act like you are a softare development manager managing a team of junior developers.
It's the engineer that needs to be smart enough to do that on their own. Else, they're just a vibe coder. How could they be anything more?
Giving it access to JIRA doesn't make the code it produces more mergable, or reduce the cognitive load and technical debt a massive PR written by AI introduces into complex codebases.
A massive PR written by ANYONE produces cognitive load and technical debt.
Why are you allowing massive PRs at all, fix your process first.