There is no Vibe Engineering(serce.me)
serce.me
There is no Vibe Engineering
https://serce.me/posts/2025-31-03-there-is-no-vibe-engineering
71 comments
> This is why programmers are employed: it is always a R&D job, if it existed under relevant constraints, it would be purchased and installed.
Clearly you've never had the pleasure of working at a NIH (not invented here) syndrome culture company. At one company, we didn't have budget to buy a ticketing system, but somehow we prioritized engineering building one from scratch. Another time I was talking with an engineer at Roblox and the engineer interviewing me was building a config scanning and management system from scratch for pretty generic linux installs. I can think of at least two companies that offer a product that did everything they needed and more, plus it was a full featured, stable production ready system, vs theirs which had serious teething issues and was obvious they were struggling to scale it. There's no shortage of these kinds of config management systems out there but they decided to build their own anyways.
At another company our "staff" infra guy wrote 40,000 lines of bash because he didn't like how Jenkins worked for deploys. These are all very standard things that keep getting coded over and over for whatever reason. I haven't tried it yet but I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test. I've certainly done it for some throw-away prometheus exporters to get some crude visibility into third party services we have to use.
Clearly you've never had the pleasure of working at a NIH (not invented here) syndrome culture company. At one company, we didn't have budget to buy a ticketing system, but somehow we prioritized engineering building one from scratch. Another time I was talking with an engineer at Roblox and the engineer interviewing me was building a config scanning and management system from scratch for pretty generic linux installs. I can think of at least two companies that offer a product that did everything they needed and more, plus it was a full featured, stable production ready system, vs theirs which had serious teething issues and was obvious they were struggling to scale it. There's no shortage of these kinds of config management systems out there but they decided to build their own anyways.
At another company our "staff" infra guy wrote 40,000 lines of bash because he didn't like how Jenkins worked for deploys. These are all very standard things that keep getting coded over and over for whatever reason. I haven't tried it yet but I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test. I've certainly done it for some throw-away prometheus exporters to get some crude visibility into third party services we have to use.
> I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test.
oh man, just think of the security implications of a "vibe coded" CI system, holy shit I'm going to have to get into consulting because there is going to be SO MUCH MONEY to be made digging organizations out of self-created holes like this one.
Jira too, considering the importance of RBAC there, if you tried to replace that in a couple of days, inevitably that's a lawsuit waiting to happen.
Lol I love also that I got a downvote before I was done editing this comment. Love it. Be mad, I'll be rich.
This is a whole new category of "I could build that in a weekend," lol, no you couldn't.
oh man, just think of the security implications of a "vibe coded" CI system, holy shit I'm going to have to get into consulting because there is going to be SO MUCH MONEY to be made digging organizations out of self-created holes like this one.
Jira too, considering the importance of RBAC there, if you tried to replace that in a couple of days, inevitably that's a lawsuit waiting to happen.
Lol I love also that I got a downvote before I was done editing this comment. Love it. Be mad, I'll be rich.
This is a whole new category of "I could build that in a weekend," lol, no you couldn't.
Off topic, perhaps, but this is the thing that stuck out to me in the OP
> When the tornado comes whipping through your neighborhood and your house gets blown down and somehow you didn’t have insurance and you lose everything, you can’t control that. But you can certainly control how you’re gonna react to that situation.
Neither of these two things are really true. It sounds like it should be true, but it really isn't. Why didn't you have insurance? Why are there more destructive tornadoes? If my house is trashed, at a reflexive simple human level, I'm pissed, depressed, anxious - take your pick of emotions. No amount of stoicism, short of super maximum foo level is going to change that. Nor, should it. That stuff isn't a movie about overcoming obstacles, as an individual with super-human fortitude. It's a trashed house and a whole boat load of expense, and more.
Why is that quote in the piece? I don't get the analogy.
> When the tornado comes whipping through your neighborhood and your house gets blown down and somehow you didn’t have insurance and you lose everything, you can’t control that. But you can certainly control how you’re gonna react to that situation.
Neither of these two things are really true. It sounds like it should be true, but it really isn't. Why didn't you have insurance? Why are there more destructive tornadoes? If my house is trashed, at a reflexive simple human level, I'm pissed, depressed, anxious - take your pick of emotions. No amount of stoicism, short of super maximum foo level is going to change that. Nor, should it. That stuff isn't a movie about overcoming obstacles, as an individual with super-human fortitude. It's a trashed house and a whole boat load of expense, and more.
Why is that quote in the piece? I don't get the analogy.
> Why is that quote in the piece? I don't get the analogy.
I liked the quote because what it conveys is that you can't control everything. You can't control the way people freak out about things on Twitter. You can't control an influx of new tools. But what you can control is the way you react to them – not giving in to the chaos, but instead approaching the changes with a cool head. And the Netflix show it's from, Midnight Gospel, is pretty good. I do agree that the house analogy could be better though.
I liked the quote because what it conveys is that you can't control everything. You can't control the way people freak out about things on Twitter. You can't control an influx of new tools. But what you can control is the way you react to them – not giving in to the chaos, but instead approaching the changes with a cool head. And the Netflix show it's from, Midnight Gospel, is pretty good. I do agree that the house analogy could be better though.
It should be called "vape coding", as the outcome is almost always a vapor-ware like abandoned project.
(for those mixing up "vape coding" with AI coding, they are absolutely not the same.)
(for those mixing up "vape coding" with AI coding, they are absolutely not the same.)
The flip side of all of this is that so many products fail because development on new features becomes unbelievably slow. Either because of a kind of process paralysis or because things are over-engineered.
Don't get me wrong - there are absolutely critical path parts of software and engineering projects that can become enormous liabilities if not handled correctly. Further, the whole nature of software means that sometimes it's not even clear what will be a vulnerability at the outset – people find ways to exploit even the most benign-seeming aspects of a piece of software.
So, I'm not suggesting that the warnings raised here are without merit. But, it's worth understanding that despite all of that – AI or not – disruption happens constantly because a startup that isn't big enough to worry about a lot of these issues can come in and upset the established player by moving fast.
Again, this isn't a moral judgement either way – just pointing out a reality.
I personally think 'vibe coding' should be thought of as a kind of prototyping tool. A scaffolding to quickly validate an idea and see if it has legs.
Don't get me wrong - there are absolutely critical path parts of software and engineering projects that can become enormous liabilities if not handled correctly. Further, the whole nature of software means that sometimes it's not even clear what will be a vulnerability at the outset – people find ways to exploit even the most benign-seeming aspects of a piece of software.
So, I'm not suggesting that the warnings raised here are without merit. But, it's worth understanding that despite all of that – AI or not – disruption happens constantly because a startup that isn't big enough to worry about a lot of these issues can come in and upset the established player by moving fast.
Again, this isn't a moral judgement either way – just pointing out a reality.
I personally think 'vibe coding' should be thought of as a kind of prototyping tool. A scaffolding to quickly validate an idea and see if it has legs.
I don't see it working on anything outside the most popular of frameworks and libraries which have the most example code to ingest. Vibe coding will have hard time creating novel solutions by definition. It devalues the already lowest common denominator and lets people create more buggy CRUD applications.
I agree, but I think the reason so many people are on edge is because people are just now realizing that they don't do actual engineering or R&D work. They are essentially doing what LLMs are doing, and adapting already known solutions for business problems.
I'm having some success using it on Elixir and Phoenix. Not the most common stack. It works better on Javascript but it does save time having it do basic stuff (with me checking the changes).
Do you want a vibe engineered pacemaker?
This is the kind of thing that comes to mind every time I read about vibe coding. I work on systems that are generally considered critical, there's no way we'd use vibe coding to develop and maintain them. When our systems go wrong, people can die, and very expensive infrastructure can fail (and would cost billions to repair/replace).
I always wonder what kind of things people would want to use vibe coding for because there's no way it could be for anything serious, I'd hope.
I always wonder what kind of things people would want to use vibe coding for because there's no way it could be for anything serious, I'd hope.
some responsible yet still "serious" uses would include:
1) throwaway code where the "work product" is not a software system, but rather the outputs of the code which you can verify yourself.
the classic example for me is producing plots. I can easily verify that data is loaded correctly, and that the end result is correct, I just don't want to learn the complex API to make all the ticks and colors and fonts look perfect.
2) prototypes, mockups
3) simple tools (often with a web interface) for your own use
1) throwaway code where the "work product" is not a software system, but rather the outputs of the code which you can verify yourself.
the classic example for me is producing plots. I can easily verify that data is loaded correctly, and that the end result is correct, I just don't want to learn the complex API to make all the ticks and colors and fonts look perfect.
2) prototypes, mockups
3) simple tools (often with a web interface) for your own use
> 2) prototypes, mockups
Any time I have taken shortcuts because "it's just a prototype" I have always come to regret it later. This may not be the "serious" use that it initially feels like.
Any time I have taken shortcuts because "it's just a prototype" I have always come to regret it later. This may not be the "serious" use that it initially feels like.
> prototypes
Only there exist no prototypes, in the sense of throwaway. Prototypes become the product, as rarely something is really build up again from the ground to account for best setup.
Only there exist no prototypes, in the sense of throwaway. Prototypes become the product, as rarely something is really build up again from the ground to account for best setup.
I agree this is true (for mainly political/interpersonal reasons) if you’re writing code inside a typical software engineering organization, which orients itself to producing software products.
But lots of people write computer programs outside such contexts. Then it’s perfectly possible to prototype something and actually rewrite the full version.
But lots of people write computer programs outside such contexts. Then it’s perfectly possible to prototype something and actually rewrite the full version.
Honestly, I don't even want a pacemaker "engineered" by standard pre-"vibe" software engineering practices as I've seen them in the real world.
The worst outcome of all of this stuff could be that instead of dealing with exploding complexity and coming around to best practices that reduce it, we'll just let complexity and resulting confusion multiply because "the machines" will be the ones "thinking" about it, and not us.
The worst outcome of all of this stuff could be that instead of dealing with exploding complexity and coming around to best practices that reduce it, we'll just let complexity and resulting confusion multiply because "the machines" will be the ones "thinking" about it, and not us.
How about vibe-engineered autotargeting on the nuclear warhead? There is a movie about something like it
For every critical system out there, there are thousands of trivial ones. The vast, vast majority of programmers aren't writing code for fighter jets, spacecraft, surgery robots, pacemakers, and what have you.
Can you give examples of software that actually makes money and people are okay with it failing?
If it had a serious QA process behind it, sure, I don't care how the code is generated.
But I wouldn't trust an AI to design the QA process.
But I wouldn't trust an AI to design the QA process.
You cannot and should not vibecode things that are “out of distribution” vs your model’s training set. For those you need to constrain the amount of novelty, generating things in small incremental steps. It’s not much different to how humans constrain software development to one PR at a time.
Part of the skill of coding with LLMs is knowing what's likely out of distribution so knowing “how much rope” to give the model.
These problems with present-day LLMs can and will be mitigated in future with synthetic data providing more examples, and with even more inference time compute, and with intelligent fetching of docs, and with realtime ingestion of relevant dependency code, and with larger context that give models larger working memory.
Coding models have so much potential value that it pretty much has to happen.
Part of the skill of coding with LLMs is knowing what's likely out of distribution so knowing “how much rope” to give the model.
These problems with present-day LLMs can and will be mitigated in future with synthetic data providing more examples, and with even more inference time compute, and with intelligent fetching of docs, and with realtime ingestion of relevant dependency code, and with larger context that give models larger working memory.
Coding models have so much potential value that it pretty much has to happen.
Imagine if you will, a team tasked with building widgets. That means designing the widget, the mechanisms to fabricate widgets from input materials, and building those mechanisms to then build the widgets.
You could do this with a team of two people, the engineer and machinist. The engineer spends their time at the drawing board and handing designs to the machinist to fabricate. The machinist is probably going to run into problems, or there are problems with what is fabricated and the engineer needs to go back to the drawing board. It's an iterative process.
Now imagine those widgets are software. Historically we call both the engineer and machinist "software engineers" or "developers" and might call the first one "senior" or "architect" or something like that. Since we don't need a human being to physically operate machinery it seems like using AI agents would be the an ideal place to replace the software machinist.
However there's a problem - the engineer/machinist duo works not because the machinist is an engineer but somehow worse; they have different skillsets and the engineer is going to get immediate feedback from the machinist that a design is going to work or not. The engineer/machinist divide works because the machinist can say "nah."
AI agents today don't have that ability. You can tell them to do things that are impossible, or they will make shit up. Without the ability to check for validity or preemptively avoid mistakes, vibe coding is just shitty software development. If and when that problem is cracked then the concept of a software machinist will be obsoleted.
You could do this with a team of two people, the engineer and machinist. The engineer spends their time at the drawing board and handing designs to the machinist to fabricate. The machinist is probably going to run into problems, or there are problems with what is fabricated and the engineer needs to go back to the drawing board. It's an iterative process.
Now imagine those widgets are software. Historically we call both the engineer and machinist "software engineers" or "developers" and might call the first one "senior" or "architect" or something like that. Since we don't need a human being to physically operate machinery it seems like using AI agents would be the an ideal place to replace the software machinist.
However there's a problem - the engineer/machinist duo works not because the machinist is an engineer but somehow worse; they have different skillsets and the engineer is going to get immediate feedback from the machinist that a design is going to work or not. The engineer/machinist divide works because the machinist can say "nah."
AI agents today don't have that ability. You can tell them to do things that are impossible, or they will make shit up. Without the ability to check for validity or preemptively avoid mistakes, vibe coding is just shitty software development. If and when that problem is cracked then the concept of a software machinist will be obsoleted.
Vibe Coding and the environments that enable it are the Turkish Hair Transplant of programming.
Providing accessible life changing and affirming quality of life improvements to millions?
Ostensibly.
This is the third post that I have seen about the issues with "vibe coding" and it is not a surprise to see a gradual backlash from it; because it is NOT software engineering in the first place.
This is also what happens when the VC hype brigade just listens to AI researcher influencers who are excellent with research, but instead creating throw away code and encouraging "slopware" because it is gluing code up without maintenance, testing and verifying that the code works.
Vibe coding is yet another way in promoting the proliferation of more slopware rather than creating robust and mature software that lasts for years.
It has zero place in areas of high risk like defense systems or healthcare.
This is also what happens when the VC hype brigade just listens to AI researcher influencers who are excellent with research, but instead creating throw away code and encouraging "slopware" because it is gluing code up without maintenance, testing and verifying that the code works.
Vibe coding is yet another way in promoting the proliferation of more slopware rather than creating robust and mature software that lasts for years.
It has zero place in areas of high risk like defense systems or healthcare.
Calling it rapid prototyping doesn't sound as cool as it used to, now that there is vibe coding. Especially when its pure shiny 100% AI.
It seems like such a hippy thing to do.
It seems like such a hippy thing to do.
> When might this future arrive? It's uncertain. A good indicator, however, might be when engineers confidently say "yes" to the question: "Would you happily go on-call for a system of fully AI-generated services?".
I dare say there are already people saying this, but I don't know of any SWEs (or anyone who has maintained a significant codebase) who would be willing to go on-call for such a system. But I would hesitate to go on-call for even an entirely human-built system unless I'd done some in depth review of its architecture and playbook.
Maybe there's a middle ground here, like willingness to update the codebase of a vibe-coded application. Do that enough times and maybe the confidence in the system increases enough to be willing to on-call for it.
I agree with the position that the value of an "engineering" role in this context should be judged by those who have held that position, moreso than the opinions of management or media in that regard, anyway.
I dare say there are already people saying this, but I don't know of any SWEs (or anyone who has maintained a significant codebase) who would be willing to go on-call for such a system. But I would hesitate to go on-call for even an entirely human-built system unless I'd done some in depth review of its architecture and playbook.
Maybe there's a middle ground here, like willingness to update the codebase of a vibe-coded application. Do that enough times and maybe the confidence in the system increases enough to be willing to on-call for it.
I agree with the position that the value of an "engineering" role in this context should be judged by those who have held that position, moreso than the opinions of management or media in that regard, anyway.
I think being "on call" is a sign you're not doing engineering in your role, but that's not absolute and kind of a deeper discussion about what "software engineering" even means.
I swear I'm not trying to take your bait, but I did want to point out that I want to live in a world where developers are responsible for running the products that they produce, otherwise the incentives are not aligned and then -- relevant to this vibe discussion -- tossing slop over the wall becomes Situation Normal
You can certainly run the product, but engineered solutions should fail so infrequently that the idea of being "on call" becomes ridiculous.
Of course, there are tradeoffs that come with that. You might not need engineering in your product.
Of course, there are tradeoffs that come with that. You might not need engineering in your product.
I am always wary of "should" sentences. As best I can tell, it's only ridiculous if every human in the whole chain executes flawlessly. I am cognizant that very few space shuttles blew up, but the amount of development and testing time that went into them is similarly impressive
> but the amount of development and testing time that went into them is similarly impressive
Absolutely. As before, there are tradeoffs to be made. Not all software needs engineering, and it may even be detrimental to it. But if you have proclaimed engineers working on your product...
Absolutely. As before, there are tradeoffs to be made. Not all software needs engineering, and it may even be detrimental to it. But if you have proclaimed engineers working on your product...
> running the products that they produce
Awesome, products who live what? 1 year tops.
One of last month fun bugs I got from a 10 year old ecosystem was due to some backend calling an API which (aside from fetching info from an API provided by the backend) needed data from some third system generating it using a CRON run mon-thu at 13h. The original input in this third system was done on thursday around 17h so it was not available on friday (date of the ticket) nor monday morning (which led to this treasure hunt) but things were automagically resolved around 13h15. Gotta love the world of in-house legacy applications.
Awesome, products who live what? 1 year tops.
One of last month fun bugs I got from a 10 year old ecosystem was due to some backend calling an API which (aside from fetching info from an API provided by the backend) needed data from some third system generating it using a CRON run mon-thu at 13h. The original input in this third system was done on thursday around 17h so it was not available on friday (date of the ticket) nor monday morning (which led to this treasure hunt) but things were automagically resolved around 13h15. Gotta love the world of in-house legacy applications.
Well, 1 year is still made up of a lot of 5 minute increments in which some node.js app is spewing 500s as fast as computers can go
[deleted]
[deleted]
[deleted]
Vibe coding is functionally equivalent to drunken coding. It all seems to make sense ... until next morning when you try to run it.
There is no "vibe coding" either. It's just idiots playing around with copypasta by a different name.
There is no vite testing or debugging.
There most definitely is. You can ask Cursor to do both those things, for example. It's often faster at it than a person. That said, "vibe coding" implies a hands-off approach that definitely doesn't work.
There’s vibe rewrites though!
While AI undeniably impacts the way we write code, it hasn't fundamentally changed our role as engineers.
True, but it changes the way that management and investors see us. I, for one, am planning to go back to school in order to move into patient-facing healthcare. I'd love to hear others' ideas on fields that are intellectually stimulating and where the human touch is valued.
True, but it changes the way that management and investors see us. I, for one, am planning to go back to school in order to move into patient-facing healthcare. I'd love to hear others' ideas on fields that are intellectually stimulating and where the human touch is valued.
Okay. But. Don’t leave the field completely.
Keep building things even if it’s just vibe coding and reading the code. This AI coding caper is moving fast!
Patient facing healthcare will see you spend years getting trained only to hop on the bottom rung of a system hamstrung by onerous regulation (understandable) and severe labor shortages (complex). You’ll be moving all day and have sore feet by the end of the day. The human touch is valued only by the subset of the population who deign to be polite. Your management values metrics.
My prediction is you’ll be shocked and dismayed and come running back to your relatively unregulated, keyboard driven, non body destroying current career.
Keep building things even if it’s just vibe coding and reading the code. This AI coding caper is moving fast!
Patient facing healthcare will see you spend years getting trained only to hop on the bottom rung of a system hamstrung by onerous regulation (understandable) and severe labor shortages (complex). You’ll be moving all day and have sore feet by the end of the day. The human touch is valued only by the subset of the population who deign to be polite. Your management values metrics.
My prediction is you’ll be shocked and dismayed and come running back to your relatively unregulated, keyboard driven, non body destroying current career.
I mean, I'm not planning to become a nurse. There are a lot of patient-facing roles in healthcare that don't involve being on your feet all day.
Tech feels like it’s been hijacked by enterprise-minded tinkerers obsessed with uptime and type safety, yet utterly allergic to soul. No one’s making beautiful or weird things anymore, just pipelines and SDKs for more pipelines. It’s like watching jazz musicians only play scales. So tired of this industry.
How long would it take?
Always amusing to see how powerful both sides of the debate feel. On this side you have all the “slop coding” comments from “supreme” engineers and on the other side you have AI does everything correctly folks.
Such a weird take for both because there does seem to be a sweet middle ground.
Such a weird take for both because there does seem to be a sweet middle ground.
> Such a weird take for both because there does seem to be a sweet middle ground.
Having been burned by Copilot in the past I started researching and using alternatives. Continue was nice for a while because it allowed using Claude and at that time was better at feeding the LLM good context from your codebase. I started using Cursor + Claude 3.7 not too long ago and, while a definite upgrade from Copilot, I still saw glaring issues with what it generated. Writing project rules has helped immensely with this and has crystallized what I believe the SOTA of LLM-assisted development to be for the foreseeable future (i.e. if the assumptions about the limitations of current LLM architectures hold true). To your point, I think
> a sweet middle ground
will end up involving developers bootstrapping LLM-read rules according to project architecture and specifications while they build out the foundation and initial features. This will then allow devs to crank out bounded contexts while they spend the long tail stitching them together as they focus on the problem domain. "Vibe coding" as practiced by influencers is nothing more than a quicker, sexier version of the StackOverflow copy/paste programmer archetype that's been around for the last 20 years. Similarly, "agentic" platforms that allow an LLM to regurgitate whatever it wants while it throws spaghetti at a terminal to debug are just automatic versions of developers that paste entire stack traces into Google. Developers on the opposite end of the spectrum who care enough to review the LLM's work and, more importantly, refine it as they go will be rewarded handsomely.
Either way it's safe to say that Microsoft has gotten a good kick in the pants over the last year or so as the tooling in this space has improved. I'm pretty optimistic about the future after having seen such large dividends from my efforts to go beyond just tabbing and Cmd+I'ing my way through LLM assistance.
Having been burned by Copilot in the past I started researching and using alternatives. Continue was nice for a while because it allowed using Claude and at that time was better at feeding the LLM good context from your codebase. I started using Cursor + Claude 3.7 not too long ago and, while a definite upgrade from Copilot, I still saw glaring issues with what it generated. Writing project rules has helped immensely with this and has crystallized what I believe the SOTA of LLM-assisted development to be for the foreseeable future (i.e. if the assumptions about the limitations of current LLM architectures hold true). To your point, I think
> a sweet middle ground
will end up involving developers bootstrapping LLM-read rules according to project architecture and specifications while they build out the foundation and initial features. This will then allow devs to crank out bounded contexts while they spend the long tail stitching them together as they focus on the problem domain. "Vibe coding" as practiced by influencers is nothing more than a quicker, sexier version of the StackOverflow copy/paste programmer archetype that's been around for the last 20 years. Similarly, "agentic" platforms that allow an LLM to regurgitate whatever it wants while it throws spaghetti at a terminal to debug are just automatic versions of developers that paste entire stack traces into Google. Developers on the opposite end of the spectrum who care enough to review the LLM's work and, more importantly, refine it as they go will be rewarded handsomely.
Either way it's safe to say that Microsoft has gotten a good kick in the pants over the last year or so as the tooling in this space has improved. I'm pretty optimistic about the future after having seen such large dividends from my efforts to go beyond just tabbing and Cmd+I'ing my way through LLM assistance.
The "middle ground" is a junior dev with just a couple of years of experience using a chatbot as a faster copypasta delivery mechanism than an old school google search.
Vibe coding is simply a failed attempt to undo the stigma of this.
Vibe coding is simply a failed attempt to undo the stigma of this.
Respectfully disagree. 95% of engineering roles are fairly trivial. It’s all copy pasta to some degree but for some reason there are always a handful that want to gatekeep it.
Slop coding can become popular only because of poor testing and low standards.
Slop coders are easily inpressed.
Slop coders are easily inpressed.
Whenever I see someone talk about "vibe coding", I take it as a tacit admission of "I don't know how to program". No idea why you would otherwise subject yourself to the horrible quality of AI-produced code.
it really should be spelled inpress...
See? I don’t use autocorrect! It’s AI’s revenge upon me.
A lot of the criticism around "vibe" coding / engineering / etc. focus on the current state - which is fair, but things are moving so fast. Just three years ago, it wasn't even a thing. Now you have people pumping out simple products by just feeding the models prompts.
Where will we be in 5-10 years (or more?) if this progress keeps up.
Where will we be in 5-10 years (or more?) if this progress keeps up.
Why would I need a developer when I can build everything for my app WYSIWYG in Visual Studio?
Why would I need someone who specializes in databases when I can just build it in Access?
Why can't we just build our site in squarespace and not have any resources at all?
There's always something that is supposed to come around and replace engineers but it never comes to fruition. These attempts are good to build shallow products and MVPs. For "vibe" coding, the product will not be serviceable if the person who implements it does not understand what the code is doing. This is the equivalent of rote learning and expecting the implementer to be an expert
Why would I need someone who specializes in databases when I can just build it in Access?
Why can't we just build our site in squarespace and not have any resources at all?
There's always something that is supposed to come around and replace engineers but it never comes to fruition. These attempts are good to build shallow products and MVPs. For "vibe" coding, the product will not be serviceable if the person who implements it does not understand what the code is doing. This is the equivalent of rote learning and expecting the implementer to be an expert
[deleted]
The irony being all these people making these things are rote learning experts
I don’t think this is how it works. By the same logic, since cars were invented a hundred years ago (give or take), by today we should have flying cars at the speed of light, and yet we don’t.
AI development will plateau. It’s not like it *must* improve with each iteration.
AI development will plateau. It’s not like it *must* improve with each iteration.
I don't think you're going to see 10 years of linear progress increasing the complexity of generated code, the same as you're not going to see a steady march towards factually correct LLM answers. We've had a step improvement towards producing certain types of text output, and people are racing to throw more resources at it for diminishing returns.
Producing code has got to be the best case scenario for LLMs because there's a lot of boilerplate and examples of simple applications, and people aren't out here criticizing the structure of a TODO list app.
Producing code has got to be the best case scenario for LLMs because there's a lot of boilerplate and examples of simple applications, and people aren't out here criticizing the structure of a TODO list app.
There are often diminishing returns to naive scaling, but nobody knows whether we’re at the point of diminishing returns for machine learning research, broadly defined. Who knows what new tricks will be discovered? We don’t have any physical limits to guide us.
We've had low code, no code stuff for a long time, and there are people employed full time to use those systems.
Other than excel, end users aren't great at creating their own solutions
Other than excel, end users aren't great at creating their own solutions
This is so true, I think a lot of the hype conveniently leaves out the fact that there are many low- or no-code solutions which are quite succesful in their niches (like complex form builders forgoverment tax forms, insurance etc).
Can you suggest some examples?
That is a big "if".
That is a big "if".
With only a few dimensions of constraints there are zero relevant examples in training data, with only a few more, there are zero similar examples. This is why programmers are employed: it is always a R&D job, if it existed under relevant constraints, it would be purchased and installed.
The art of vibe coding, such as it can be developed as an art, is in segregating system design to localise (constraint-induced) novelty. There are certain applications of genAI where it makes sense to give up on a plan, and take good-enough. Software "in the large" is not such a place.
It's no accident its data scientists who began vibe coding -- it's a fundamentally "in the small" activity with no hard constraints: much like the throw-away exploratory programming of data science. Hence, I suppose, the alarm and confusion amongst software engineers -- perhaps they just aren't aware they're speaking to a radically different kind of "throw away programmer" that exists in the AI space, they've always been vibe programmers.