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