Vibe Coder vs. Software Engineer
yusufaytas.com
yusufaytas.com
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.
> 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 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.
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.
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.
The Software Engineer will know what decision to make even without looking at the code.
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.
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.
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.
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.
Ideas are cheap. The execution matters and you need to polish it at least until certain level.
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 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.
Unrelated: The phrase is "flesh out". You "flush out" unwanted elements, like rodents.
No, it's just a tool. Like a spoon, or a pen, or a piece of paper, or a vehicle, or a gun.
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.
Sorry but this is demonstrably false. For starters, see the "R's in strawberry" meme.
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.
Why are you allowing massive PRs at all, fix your process first.