Vibe Coder vs. Software Engineer

https://yusufaytas.com/vibe-coder-vs-software-engineer

by yusufaytas • 1 month ago

81 34 1 month ago

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.

apsurd• 1 month ago

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.

manuisin• 1 month ago

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.

trollbridge• 1 month ago

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.

nicce• 1 month ago

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.

analogpixel2• 1 month ago

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.

happytoexplain2• 1 month ago

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.

analogpixel2• 1 month ago

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.

sroerick• 1 month ago

Just call it vibe coding. You can still be an engineer.

0gs• 1 month ago

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)

Garlef2• 1 month ago

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.

sublinear2• 1 month ago

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.

stephth• 1 month ago

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.

Garlef2• 1 month ago

To comment on the two sibling responses to my post here in parallel.

I think it gives very valuable insights to tackle the question: "What if we wanted to apply 'vibe-coding' as an SWE technique?"

There's a lot of interesting nuance to cover:

- How can we ensure that agents produce the codebases we want?

- How can we reduce the cognitive burden of code review?

- Do we actually need to review everything?

- How can we safely vibe-code in regulated environments (ISO 27001)?

- How can we use vibe-coding to safely evolve production-grade systems?

- ... etc, etc

I find this approach much more interesting than dismissing vibe-coding as non-SWE.

sublinear2• 1 month ago

We really do need to review everything. Whether that's actually being done in practice with enough competence was already a significant risk before LLMs.

LLMs today can reduce cognitive load, but only when it gets it right (about half of the time). They're better than nothing if you don't have anyone else to help review. They still have a very long way to go compared to two or more human reviewers that know the project well.

I don't have answers for the other questions. They seem irresponsible, not because "vibe code bad", but because there should already be very restrictive templates in place for production and regulated environments. Wanting to vibe anything in there implies those environments are already broken enough to allow shenanigans.

appstack• 1 month ago

Claude is smart enough now to transition a vibe coder into a software engineer if you provide access to SDLC pipeline.

__natty__• 1 month ago

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.

zxspectrum19822• 1 month ago

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.

latentsea• 1 month ago

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?

dmackerman• 1 month ago

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.

theshrike792• 1 month ago

A massive PR written by ANYONE produces cognitive load and technical debt.

Why are you allowing massive PRs at all, fix your process first.

paool• 1 month ago

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.

happytoexplain2• 1 month ago

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.

mandeepj• 1 month ago

Different times, different comparisons! This is from back in the day https://www.hanselman.com/blog/am-i-really-a-developer-or-ju...

contingencies• 1 month ago

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.

demorro• 1 month ago

These comparisons are tricky, because software in particular has always been a bit weird about what it means by "engineer". The article gestures at this, the majority of the people with the title are not actually engineers at all, although I couldn't prove it, because we don't have a definition.

The best I have is that engineering is the real-world, practical application of the scientific method deployed in service of human values. (The human values bit is important to my mind, as I don't believe experimentation over disconnected, stochastically generated hypothesis counts as science.)

By this definition, vibe-coding does introduce a wrinkle because it becomes more difficult to experimentally verify hypothesis as you have reduced how much you are observing, but it's not a hard impossibility or anything like that.

telesilla• 1 month ago

My definition of an engineer is someone who has a dedicated education as such. We have the same definition for doctor, lawyer, pilot, teacher - why not software engineer?

OutOfHere• 1 month ago

A software engineer maintains ownership and responsibility over the code. A vibe coder delegates ownership and responsibility to the AI.

Vibe Coder vs. Software Engineer

Related Stories