5 ms·

There is no Vibe Engineering

71 points by todsacerdoti 2y ago

rambojohnson 2y ago
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.
peterlada 2y ago
Vibe coding is functionally equivalent to drunken coding. It all seems to make sense ... until next morning when you try to run it.
cadamsdotcom 2y ago
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.
sublinear 2y ago
There is no "vibe coding" either. It's just idiots playing around with copypasta by a different name.
indigoabstract 2y ago
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.
revskill 2y ago
There is no vite testing or debugging.
- ohgr 2y ago
  There’s vibe rewrites though!
- dtagames 2y ago
  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.
  - Rooster61 2y ago
    Cursor can write end to end, black box system tests?
    - mdaniel 2y ago
      Write them? Unquestionably. Have them be the basis for "is my vibe coded app doing what the product owner expects?" is where reasonable people have differing opinions
kristjank 2y ago
Vibe Coding and the environments that enable it are the Turkish Hair Transplant of programming.
- kridsdale1 2y ago
  Providing accessible life changing and affirming quality of life improvements to millions?
  - throwaway314155 2y ago
    Ostensibly.
127 2y ago
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.
- NewsaHackO 2y ago
  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.
- victorbjorklund 2y ago
  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).
tpae 2y ago
How long would it take?
kevindamm 2y ago
> 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.
- duped 2y ago
  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.
  - mdaniel 2y ago
    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
    - deleted 2y ago
      [deleted]
    - 9rx 2y ago
      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.
mjburgess 2y ago
The more hard constraints one imposes on generative AI output, the more that it becomes exponentially harder to constrain that output to those constraints: so much for "embracing the exponentials" -- constraint-exponentials dominate vibe-exponentials. 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.
- hadlock 2y ago
  > 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.
satisfice 2y ago
Slop coding can become popular only because of poor testing and low standards. Slop coders are easily inpressed.
- readthenotes1 2y ago
  it really should be spelled inpress...
  - satisfice 2y ago
    See? I don’t use autocorrect! It’s AI’s revenge upon me.
- bigstrat2003 2y ago
  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.
infecto 2y ago
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.
- sublinear 2y ago
  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.
  - infecto 2y ago
    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.
- alexjplant 2y ago
  > 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.
TrackerFF 2y ago
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.
- skwee357 2y ago
  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.
- hbsbsbsndk 2y ago
  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.
  - skybrian 2y ago
    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.
- graemep 2y ago
  Can you suggest some examples? That is a big "if".
- ilikecakeandpie 2y ago
  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
kayo_20211030 2y ago
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.
- SerCe 2y ago
  > 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.
duped 2y ago
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.
porter 2y ago
Do you want a vibe engineered pacemaker?
- Jtsummers 2y ago
  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.
  - currymj 2y ago
    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
    - 9rx 2y ago
      > 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.
    - mentalgear 2y ago
      > 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.
      - currymj 2y ago
mentalgear 2y ago
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.)
snozolli 2y ago
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.
- cadamsdotcom 2y ago
  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.
  - snozolli 2y ago
    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.
rvz 2y ago
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.
gdubs 2y ago
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.

71 points by todsacerdoti 2y ago

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.

peterlada 2y ago

Vibe coding is functionally equivalent to drunken coding. It all seems to make sense ... until next morning when you try to run it.

cadamsdotcom 2y ago

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.

sublinear 2y ago

There is no "vibe coding" either. It's just idiots playing around with copypasta by a different name.

indigoabstract 2y ago

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.

revskill 2y ago

There is no vite testing or debugging.

ohgr 2y ago
There’s vibe rewrites though!
dtagames 2y ago
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.
- Rooster61 2y ago
  Cursor can write end to end, black box system tests?
  - mdaniel 2y ago
    Write them? Unquestionably. Have them be the basis for "is my vibe coded app doing what the product owner expects?" is where reasonable people have differing opinions

kristjank 2y ago

Vibe Coding and the environments that enable it are the Turkish Hair Transplant of programming.

kridsdale1 2y ago
Providing accessible life changing and affirming quality of life improvements to millions?
- throwaway314155 2y ago
  Ostensibly.

127 2y ago

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.

NewsaHackO 2y ago
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.
victorbjorklund 2y ago
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).

tpae 2y ago

How long would it take?

kevindamm 2y ago

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

duped 2y ago
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.
- mdaniel 2y ago
  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
  - deleted 2y ago
    [deleted]
  - 9rx 2y ago
    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.

mjburgess 2y ago

The more hard constraints one imposes on generative AI output, the more that it becomes exponentially harder to constrain that output to those constraints: so much for "embracing the exponentials" -- constraint-exponentials dominate vibe-exponentials. 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.

hadlock 2y ago
> 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.

satisfice 2y ago

Slop coding can become popular only because of poor testing and low standards. Slop coders are easily inpressed.

readthenotes1 2y ago
it really should be spelled inpress...
- satisfice 2y ago
  See? I don’t use autocorrect! It’s AI’s revenge upon me.
bigstrat2003 2y ago
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.

infecto 2y ago

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.

sublinear 2y ago
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.
- infecto 2y ago
  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.
alexjplant 2y ago
> 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.

TrackerFF 2y ago

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.

skwee357 2y ago
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.
hbsbsbsndk 2y ago
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.
- skybrian 2y ago
  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.
graemep 2y ago
Can you suggest some examples? That is a big "if".
ilikecakeandpie 2y ago
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

kayo_20211030 2y ago

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.

SerCe 2y ago
> 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.

duped 2y ago

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.

porter 2y ago

Do you want a vibe engineered pacemaker?

Jtsummers 2y ago
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.
- currymj 2y ago
  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
  - 9rx 2y ago
    > 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.
  - mentalgear 2y ago
    > 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.
    - currymj 2y ago

mentalgear 2y ago

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

snozolli 2y ago

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.

cadamsdotcom 2y ago
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.
- snozolli 2y ago
  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.

rvz 2y ago

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.

gdubs 2y ago

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.