> 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.
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.
> 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.
> "It would be silly to attribute consciousness to a room".
And regardless of whether you think that's an interesting rebuttal or not, it's safe to say that people who properly accept anthropomorphism of llms are content to be silly in this way.
> At the slightest touch of the reins, he felt a familiarity that shook him...
Ah... Some good, old, pre-AI journalism slop.
Oh the countless times a universities press release has been turned into four pages describing the smell of coffee some scientist inhales on their way through campus...
Not sure if this is the right abstraction: The recall seems to need a search term.
But would it not be more sensible to assume that the full conversation (+ system parts) CAN inform the recall and some neural network picks the right memory bits?
So my fear would be that something like this, if adapted, drags the development into a local optimum that is hard/impossible to get out of.
Out of interest: Was this still before CoT/thinking-mode became the norm?
reply