Vibe coding and agentic engineering are getting closer than I’d like
31 points by dustyweb
31 points by dustyweb
I can't say I find the conclusion that there isn't much distinction after all suprising, but it's interesting to see @simonw hit that conclusion too. This has seemed pretty clear to me since early on as the incentives always funnel that way: if you have a machine that creates high volume output but say the goal is to have experienced engineers review that work, you're both asking for a draining situation for those more senior engineers and also are making them the bottleneck. But I think it's worth highlighting that, since the distinction raised was originally Simon's, and so seeing that Simon doesn't think so either right now is worth looking at.
(Side note, it's awkward writing commentary here that maybe sounds somewhat critical since I am near certain @simonw will read it. My actual opinion is that @simonw is the best pro-AI writer out there, so I read everything he says with interest. If I had a critique, it's that @simonw is thoughtful enough that his writings give a lot of cover for a bunch of hucksters who are far less thoughtful than he is.)
Hmm, I get what the author is saying, but here's a slightly different way of looking at it:
A newly coined euphemism which relies on a neologism/poorly defined terms ends up being used in poorly defined ways. Was this unexpected? I thought it was the point of the expression.
If you cared about a precise use of your neologism you would probably need to build on well-understood terms. (Not that it would guarantee success.)
What I see being advertised as "agentic engineering" in the wild I would call "bot-driven development", because "bot" is a relatively well understood term* and you have "test-driven development" as a predecessor. Not an actual proposal, just an example of how I would personally try to coin an expression.
(*) Unless you're talking about social media/political discourse, where it has become a generic slur for "people I disagree with online".
I have plenty more to say about coining terms, it's a bit of a hobby.
In this case one of the things I like about "agentic engineering" is that it's really difficult for someone who typed a prompt and got an app out without any understanding of how it works to claim they were "agentic engineering", especially when "vibe coding" is right there and already quite well established.
I just realized it's the thing I said earlier about how I only want to use your side project if you've used it for a few weeks. The enterprise version of that is I don't want a CRM unless at least two other giant enterprises have successfully used that CRM for six months.
Whilst I think this is the right overall angle, I think the way it's playing out on the ground is different -- these big systems are often customized to the hilt. Salesforce, SAP, Workday, are usually incredibly bespoke. There is a cost to maintaining this. Plus he platforms themselves can be rigid in quite unhelpful ways. Nobody loves Workday, and yet it's everywhere in enterprise-land.
There is definitely room for a different approach. I'm not sure "vibe coded from scratch" is it. Maybe it's on top of these platforms, but I'm increasingly thinking it's a vibe-coded assembly of other "enterprise-grade products/services".
The other effect will be agentic approaches "hollowing-out" these systems. They've resisted just being a "database" for so long, but that's where agentic pushes them.
So I don't think "I vibe coded Salesforce" is a thing, but they're fighting a battle on numerous fronts.
Salesforce themselves just started talking about "headless" software, which effectively means that they provide an API and customers vibe code their own perfect custom interface in top of that API.
I think that makes a lot of sense for big SaaS, which has always been heavily customized anyway.
It seems like that's what JIRA becomes too. I haven't seen any company over 100 people that doesn't end up with at least one custom dashboard using the API and a bunch of custom workflows.
Plus, the JIRA UI is just truly awful, so slow and clunky with baffling oversights galore. In a way, maybe that pattern gives users more control over their experience. I wonder what happens when someone decided to vibe code a replacement backend, though? Smells like lawsuits.
I'm not completely sure how to interpret this post. Based on several things it says, I want to rephrase the point as "the difference between vibe coding and agentic engineering isn't whether you read the code." The idea would be that the practices that you're using are more important than whether you read the code.
Of course, many people are dreaming of a world where there really is no difference--as a non-programmer user, you'll ask for what you want, and the agent will build something with the appropriate level of robustness without you having to specify practices to make that true. But I don't think we're there yet, and I don't think the article is saying we are.
However, I'm not sure if that's fair or not. @simonw, what do you think?
Note: I'm personally not close to the point where I'll put code into production without reading it. My own experience says that for me, in my context, the process just isn't yet reliable enough. I'm just trying to understand the perspective in the article.
It's a lot less well structured than my usual writing because it's direct transcript from a podcast conversation, with minimal edits (removing "like..." a bunch, mainly).
I continue to believe that there is a WORLD of difference between professional software engineers using AI to strengthen and accelerate their work and non-programmers using vibe coding to create systems that solve their problems without any deep understanding of how they work.
What's changed for me is that I've realized I'm starting to ship code that I trust and would put my name to that I haven't reviewed on a line-by-line basis - which feels closer to the original vibe coding definition than I'd like.
I'm still trying to come to terms with what this means and how to talk about it.
