Vibe Coder vs. Software Engineer

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.

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

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.

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.

Ideas are cheap. The execution matters and you need to polish it at least until certain level.

Unrelated: The phrase is "flesh out". You "flush out" unwanted elements, like rodents.