One of the genuinely positive things about tools like Copilot and ChatGPT is that they empower people with minimal development experience to create their own programs. Little programs that do useful things - and that’s awesome. More power to the users.
This guy didn't just make a small program, he made a product that is attuned to some very stringent requirements. If you gave this project to experienced software developers it would be heavy on process and light on impact, take forever to make, and stupid expensive.
Yeah, the most important part of that video is where he says: "it works well enough". I think there's lots of room for this kind of bespoke software that's fundamentally unmaintainable -- and not something anyone could reasonably afford to make with professionals -- but good enough for purpose. This seems like a great, life-changing example, but it's still subject to the same thing the article is talking about.
I've had some free time recently so I've been trying to use the various AI tools to do a greenfield project with Rails. I know the stack intimately, so it's been a useful exercise as a check against hype. While I can occasionally trust the tooling to make big changes, most of the time I find that even the small changes are wrong in some important, fundamental way that requires re-writing everything at a later time. Asking the models to fix whatever is broken usually results in an endless cycle of (very junior-like!) random changes, and eventually I just have to go in and figure out the fundamental restructure that fixes the issue.
Would this be good enough for someone writing a one-time-use, bespoke piece of software? Maybe. Would they be able to maintain this code, without having a truly senior-level ability to work with the code itself? No [1].
I'm less fearful of LLM taking experienced programmers' jobs [2], because I fundamentally think this kind of stuff plays in the same end of the market as knockoff designer goods, Ikea furniture, and the like. It makes custom software available to an entire customer segment that couldn't have afforded it before, but nobody is going to confuse it with a product made by a team of skilled professionals [3,4].
[1] But to a really inexperienced developer, it looks the same.
[2] I am more fearful of clueless business types, who think this technology obviates the need for programmers.
[3] ...but will unskilled professionals be under pressure? Maybe!
[4] ...and what about skilled people, using the same tools? My current hypothesis is they're beneficial, but ask me again in six months.
As you said, I think also the key differences between skilled and unskilled devs in the context of AI tooling are :
1°) Know how to diagnose and fix critical problems by themselves, because there will be bugs in production for which AI won't be any help
2°) Write maintainable code, AI doesn't care at all of maintainability of code while devs should (must imho) consider pasting AI code as a merge/pull request.
For 2°) IIRC, I read somewhere that more and more code published on i.e. github is AI-generated. While this means the quality of code is decreasing, i.e. Copilot is also trained on more and more % of AI-generated code. So the quality of AI-generated code is decreasing globally.
As time passes, I think skilled devs will become more skilled and unskilled will become more unskilled.
I love this so much. It's hacky, janky, and absolutely phenomenal and life changing. This is like perfectly in the spirit of the hacker ethos. This dude scraped together pieces around him and made a useful product that solves the problems he wants to solve, the way he wants to solve them.
The code is probably garbage. You can tell the UI is weird and jumpy. He's using timed delays to manipulate the browser with keyboard keys. The whole thing would be absolutely shredded here. But it's beautiful. It's crafted for function over form with duct tape and bubble gum but it's the difference between his brother being locked helplessly alone in his body, or being able to express himself and have some level of autonomy. It's just awesome.
LLMs rule for this kind of stuff. Solve your problems and move on. The code is not so precious. You'll learn many things along the way and will be able to iterate quickly with a tireless and semi competent but world knowledgeable assistant.
I didn't look at this video, but be vigilant when seeing one, as I was also surprised by someone demonstrating what they can do with Cursor and I went so far to install the exactly the same version of the app, use the same model and everything (prompt, word capitalization...) I could gather from the video and the results were nowhere near what was demonstrated in the video (recreating mobile web page from screenshot).
I know that LLMs are not deterministic machines, but IMO there is a lot of incentive to be "creative" with marketing of this stuff.
For the reference, this was less than two months ago.
The funny thing is someone somewhere will find a way to make millions off a vibe coded project. I just suspect it will be the outlier and they will be well positioned to make that happen.
And for the rest of the companies that embrace the 30%~ efficiency spike, it will just accelerate our work goals faster.
I like to use it on stuff that we wanna do to enhance the UX but rarely sees the light of day. Plus my wrists have never felt so good since replacing boring syntax choirs with LLMs.
Hence why software developers are out of job, eventually.
The day of only a few people around the factory floor to babysit the robots will come, but lets keep celebrating the day they start unloading them from the delivery trucks for installation.
It's not clear if the overall number of needed software developers will decrease or simply stop growing. The amount of software necessary in the future will only keep growing. Using the same folks to produce more is a large possibility. I imagine it will take decades to see a shrinking workforce that meaningfully displaces many existing software developers.
Why do you not read the article? What you are saying is just total nonsense if you had actually read the article.
>If you gave this project to experienced software developers it would be heavy on process and light on impact, take forever to make, and stupid expensive.
No, it wouldn't. Every single software developer knows how to make programs which "work well enough". This claim is totally ridiculous, it also is not a "product" in any meaningful sense.
What the article is pointing out is that you can not sell software like this. It is not a "product" at all, it is a hobby project. And you can not develop a hobby project like you would develop a commercial product.
Just think for a second what it would take to sell this.
>they empower people with minimal development experience to create their own programs.
The author goes out of their way to play up the toy aspect of the LLMs when driven by the inexperienced. No mention is made of them being used by experienced developers, but I get the impression he feels they aren't useful to the experienced.
I'm just playing with a small client/server tool (rsync but for block devices), and vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?) I would never have done that before because of the sheer amount of time it would take, I'd have picked what I thought was best and then lived with the sunk cost falacy until I had no other choice. It did a pretty good job of catching reasonable exceptions in the communication code which I probably would have just let throw a traceback until I got a bug report. It did a great job of adding logging and debugging options. And I had it take 4 attempts at making a "fancy" --progress display and picked the one I liked the best.
LLMs give a level of exploration to software development that we haven't seen since the good old days when HP set up several groups to each build their next generation workstation environment, and then picked the best one.
IMHO, the experienced software developers stand at a unique position to take advantage of these LLMs that far outstrip what an inexperienced developer can do.
> vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?”
This doesn’t fall under my understanding of the phrase “vibe coding”. In the tweet from Karpathy which many point to for coining the phrase, he says that when vibe coding you essentially “forget the code exists”. I think it’s distinct from regular ol LLM-assisted development
I surely did a hybrid approach, but for a large swath of it I was pretty purely "vibe coding", where I wasn't looking at the produced code at all.
I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination problems so I asked for some different async and threaded implementations, but ultimately they went off into the weeds in ways I couldn't really reason about, so I went back to a straight select/procedural implementation and had it start tracking outstanding blocks, which got something working reliably. Then I asked for fancy progress displays, tried several attempts at that. Then at this point I started cleaning up the code some, had it add type annotations, etc...
Big swath of pure or nearly pure vibe coding in the middle there.
You can examine the code at any time, ask for an explanation, and even make changes yourself. In other words, you get out of it exactly what you put into it.
If you choose to let the AI do all the coding and never dig into the actual code, you'll learn more about how to communicate with an LLM than you will about how to write code.
I agree they may not and that’s very interesting. As an experienced developer myself I’m starting to think these tools are likely going to increase our market value not decrease it.
That is a question that is very near and dear to my heart right now because my son is 15 and very interested in programming. I don't have any good answers yet, but you definitely need to know so many of the core concepts to be able to steer the LLM around pitfalls.
If I wanted to open a large world class fast food chain, I wouldn't be cooking home meals then. That would be silly.
Copilot can help me cook the equivalent of a McDonalds special in terms of software. It's good, I think McDonalds is delicious.
But it cannot help me cook a home meal software. It will insist that my home made fries must go in a little red box, and my fish sandwich needs only half a slice of cheese.
Deeply into that metaphor, maybe someone who has only worked for fast food chains might forget that a lot of good industrial dishes are variations of what previously were home cooked meals.
I am glad that copilot can help young cooks to become fast food workers. That really looks like something.
Well, I take pleasure in cooking home meal software. Can you make a copilot that helps with that?
You know what, nevermind. I don't need a copilot to cook home meals. I have a bunch of really good old books and I trust my taste.
It's not like some big company is going to be interested in some random amateur dish, is it? It was definitely not cooked for them.
I am in the middle of my third AI assisted project. I disagree ~90%.
If you prompt an LLM like an architect and feed it code rather than expecting it to write your code, both ChatGPT 4o and Claude 3.7 Sonnet do a great job. Do they mess up? Regularly. But the key is to guide the LLM and not let the LLM guide you, otherwise you'll end up in purgatory.
It takes some time to get used to what types of prompts work. Remember, LLMs are just tools; used in a naive way, they can be a drain, but used effectively they can be great. The typing speed alone is something I could never match.
But just like anything, you have to know what you're doing. Don't go slapping together a bunch of source files that they spit out. Be specific, be firm, tell it what to review first, what's important and what is not. Mention specific algorithms. Detail exactly how you want something to fit together, or describe shortcomings or pitfalls. I'll be damned if they don't get it most of the time.
> Be specific, be firm, tell it what to review first, what's important and what is not [...] Detail exactly how you want something to fit together [...]
You mean like in a fast food chain?
I know how to use it. All of that was already implied in my original comment. Sometimes though, I want to cook without a rigid mindset.
Asking the LLM for something is like doing an "Ask the Audience" in Who Wants to be a Millionaire. You're basically polling the consensus answer to the question you're asking.
I found one of my license texts for a hobby project[0] in a Microsoft product[1]. I have no idea how they use it.
Copilot is very poor at understanding how the DSL arrangement of the project works or how to assemble validator trees. Before Copilot many other "enterprise" stuff like JetBrains IDEs had problems auto-completing it. But it was always good enough for me, for my own things.
It obviously have value. Maybe they're lazy and using it for something unrelated like the TLD list. I really don't know. What I know is that something of my amateur dish ended up being served in what I consider to be a fast food chain.
No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset. That's exactly the point against "vibe coding" they push. MS seems to despise anything that doesn't follow that.
Look, I love typescript and all that stuff. As I said, McDonalds meals are delicious.
But I don't want that approach for everything I code. This project is not the only one with that issue. I noticed the same in a portable shell compatibility layer, it can only help if I make it to look like other script languages.
"You're asking too much, how can copilot help with a language it was not trained on?"
I am not asking it to be good at that. Just don't make asshole posts saying anything other than MS pasteurization is "vibes".
If they paid me, then that would be another story. But they didn't, and used my "vibe" project anyways.
I am not complaining about software I released for free, before anyone tries to go for that.
I am making an observation about kinds of software that copilot can't help with. My kind of software development, in which I might take months to decide a name or redo everything several times just to try a new kind of sauce.
> Copilot can help me cook the equivalent of a McDonalds special in terms of software. It's good, I think McDonalds is delicious.
No. The likes of Copilot help you cook the meal you'd like, how you'd like it. In some cases it forgets to crack open eggs, in other cases it cooks a meal far better than whatever you'd be able to pull together in your home kitchen. And does it in seconds.
The "does it in seconds" is the key factor. Everyone heard of the "million monkeys with a typewriter" theorem. The likes of Copilot is like that, but it takes queues and gathers context and is supervised by you. The likes of Copilot is more in line with a lazy intern that you need to hand-hold to get them to finish their assignment. And with enough feedback and retries, it does finish the assignment. With flying colors.
Cook a meal, yes. "How you'd like it", no. You have to use the languages that have a large enough presence in its training set that it knows them well, and ditto for frameworks and libraries. Once you step out of that zone, quality rapidly plummets.
"Does it in seconds" is kinda true if you ignore the "supervised by you" part. That part - reading through the generated diffs to catch (sometimes very subtle) errors - can take a while.
And sure, you'd have the same problem with the intern. But the intern learns from you. The LLM will make the same mistakes again in the same circumstances. Yes, I know they do have memory now, but it my experience that RAG-based stuff is not particularly reliable. I suspect this might improve once hardware is fast enough that you can use a (smallish) helper LLM for RAG with reasonable perf, but we aren't quite there yet.
My main takeaway from vibe-coding is that nobody cared enough to fill that niche and expectation. And it was really frustrating, yet we're getting there through convolutated, inefficient and borderline barbaric means.
People are still lamenting after HyperCard. Automation on windows or macos didn't go anywhere. Shortcuts were a better step into that direction but I feel it got stuck in the middle as Apple wasn't going to push it further. Android had more freedom yet you won't see a "normal" user do automation either.
If we're going to point the middle finger at vibe-coding, I wish we had something to point to as a better tool for the general population to quickly make stuff they want/need.
(Doing it as a professional dev is to me another debate, still with nuance in it IMHO. I'd also love better prototyping tools to be honest.)
Python is not exactly a hard language to learn. But the truth is that people generally don’t like to devote time to what they deem unimportant even if the end result would be useful. I’ve seen smart people go though dense mathematics and physics books, but refuses to take an introductory course in programming.
Yeah this is how I interpret it. Type text into the chatbot, copy and paste the outputted code. If it fails to compile, paste the error message and get the resulting code. Similar if it fails at runtime. Supply the LLM with additional code files where necessary but don't really look at the code, just copy and paste in, copy and paste out.
It throws away decades of software engineering principles in favour of unchecked AI output by clicking “accept all” on the output.
You would certainly NOT use ‘vibe coded’ slopware that powers key control systems in critical infrastructure such as energy, banking, hospitals and communications systems.
The ones pushing “vibe coding” are the same ones who are all invested in the AI companies that power it (and will never disclose that).
An incident involving using ‘vibe coded’ slopware is just waiting to happen.
‘OUTSOURCING’ isn’t software engineering.
It throws away decades of software engineering principles in favour of CHEAP output by clicking “I AGREE” on a contract.
You would certainly NOT use ‘OUTSOURCED’ slopware that powers key control systems in critical infrastructure such as energy, banking, hospitals and communications systems.
An incident involving using ‘OUTSOURCED’ slopware is just waiting to happen.
I mean that's not a great counterexample because outsourcing is famously difficult to get right, and from my own experience often results in exactly the kind of terrible code quality GP is talking about.
It’s implied that programs are personal but product code goes through peer review, checking the premise of the change as well as the implementation.
When someone reviews vibe coded patches and gives feedback, what should the reviewer expect the author to do? Pass the feedback onto their agent and upload the result? That feels silly.
How has code review changed in our brave, vibey new world? Are we just reviewing ideas now, and leaving the code up to the model? Is our software now just an accumulation of deterministic prompts that can be replayed to get the same result?
With the Altair you had switches to input bits of CPU instructions. Then punchcards. Then Telex. Then assembly in a terminal. Then C, Pascal and Smalltalk. Then Java, C++, Python, PHP. Then the mountains of libraries and frameworks, realtime indexers, linters, autocomplete, suggestions.
The next step seems that we will write programs in prompts. Maybe we will get a language that is more structured than the current natural language prompts and of much higher order than than our current high level programming constructs and libraries.
You can’t eliminate formalism in programming. You can only abstract it away by creating a metaprogramming layer for the current one. And prompt isn’t that. Prompting is a blind shot hoping to hit something good.
The real problem with "vibe coding" (or any coding, or with any product what so ever) is that the end user probably is not a programmer, and therefore cannot have professional judgement on the quality of the implementation. The only thing typical end user care is the perceived behavior, not the implementation details.
As it is easier and cheaper to do anything, the result is low-quality products. This of course serves well for the real professionals, who can now sell premium quality products at premium pricing for those who know and want the quality.
It depends. Market has demonstrated time and again that premium quality is a rather niche product. Is the niche large enough for all the existing "real professionals" to fit into it?
I am happy that there will be work in security for good while. They might first pass run LLMs on that too. But it will miss things and that is where I can come in...
Readit News
I've changed my outlook on vibe coding after seeing the results of this wholesome vibe coding: https://www.youtube.com/watch?v=4pJUXocn7aE .
This guy didn't just make a small program, he made a product that is attuned to some very stringent requirements. If you gave this project to experienced software developers it would be heavy on process and light on impact, take forever to make, and stupid expensive.
I've had some free time recently so I've been trying to use the various AI tools to do a greenfield project with Rails. I know the stack intimately, so it's been a useful exercise as a check against hype. While I can occasionally trust the tooling to make big changes, most of the time I find that even the small changes are wrong in some important, fundamental way that requires re-writing everything at a later time. Asking the models to fix whatever is broken usually results in an endless cycle of (very junior-like!) random changes, and eventually I just have to go in and figure out the fundamental restructure that fixes the issue.
Would this be good enough for someone writing a one-time-use, bespoke piece of software? Maybe. Would they be able to maintain this code, without having a truly senior-level ability to work with the code itself? No [1].
I'm less fearful of LLM taking experienced programmers' jobs [2], because I fundamentally think this kind of stuff plays in the same end of the market as knockoff designer goods, Ikea furniture, and the like. It makes custom software available to an entire customer segment that couldn't have afforded it before, but nobody is going to confuse it with a product made by a team of skilled professionals [3,4].
[1] But to a really inexperienced developer, it looks the same.
[2] I am more fearful of clueless business types, who think this technology obviates the need for programmers.
[3] ...but will unskilled professionals be under pressure? Maybe!
[4] ...and what about skilled people, using the same tools? My current hypothesis is they're beneficial, but ask me again in six months.
1°) Know how to diagnose and fix critical problems by themselves, because there will be bugs in production for which AI won't be any help
2°) Write maintainable code, AI doesn't care at all of maintainability of code while devs should (must imho) consider pasting AI code as a merge/pull request.
For 2°) IIRC, I read somewhere that more and more code published on i.e. github is AI-generated. While this means the quality of code is decreasing, i.e. Copilot is also trained on more and more % of AI-generated code. So the quality of AI-generated code is decreasing globally.
As time passes, I think skilled devs will become more skilled and unskilled will become more unskilled.
[0] https://manuel.kiessling.net/2025/03/31/how-seasoned-develop...
The code is probably garbage. You can tell the UI is weird and jumpy. He's using timed delays to manipulate the browser with keyboard keys. The whole thing would be absolutely shredded here. But it's beautiful. It's crafted for function over form with duct tape and bubble gum but it's the difference between his brother being locked helplessly alone in his body, or being able to express himself and have some level of autonomy. It's just awesome.
LLMs rule for this kind of stuff. Solve your problems and move on. The code is not so precious. You'll learn many things along the way and will be able to iterate quickly with a tireless and semi competent but world knowledgeable assistant.
I would strongly disagree on this count. Hacker ethos, at least as traditionally understood, emphasizes grokking and elegance.
And for the rest of the companies that embrace the 30%~ efficiency spike, it will just accelerate our work goals faster.
I like to use it on stuff that we wanna do to enhance the UX but rarely sees the light of day. Plus my wrists have never felt so good since replacing boring syntax choirs with LLMs.
The day of only a few people around the factory floor to babysit the robots will come, but lets keep celebrating the day they start unloading them from the delivery trucks for installation.
Even before AI much of software development was managing overseas teams.
>If you gave this project to experienced software developers it would be heavy on process and light on impact, take forever to make, and stupid expensive.
No, it wouldn't. Every single software developer knows how to make programs which "work well enough". This claim is totally ridiculous, it also is not a "product" in any meaningful sense.
What the article is pointing out is that you can not sell software like this. It is not a "product" at all, it is a hobby project. And you can not develop a hobby project like you would develop a commercial product.
Just think for a second what it would take to sell this.
firefox("find cats") -> gimp ("carton filter cats")-> gimp("compose into partypic") -> google drive ("upload to cat folder")
The author goes out of their way to play up the toy aspect of the LLMs when driven by the inexperienced. No mention is made of them being used by experienced developers, but I get the impression he feels they aren't useful to the experienced.
I'm just playing with a small client/server tool (rsync but for block devices), and vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?) I would never have done that before because of the sheer amount of time it would take, I'd have picked what I thought was best and then lived with the sunk cost falacy until I had no other choice. It did a pretty good job of catching reasonable exceptions in the communication code which I probably would have just let throw a traceback until I got a bug report. It did a great job of adding logging and debugging options. And I had it take 4 attempts at making a "fancy" --progress display and picked the one I liked the best.
LLMs give a level of exploration to software development that we haven't seen since the good old days when HP set up several groups to each build their next generation workstation environment, and then picked the best one.
IMHO, the experienced software developers stand at a unique position to take advantage of these LLMs that far outstrip what an inexperienced developer can do.
This doesn’t fall under my understanding of the phrase “vibe coding”. In the tweet from Karpathy which many point to for coining the phrase, he says that when vibe coding you essentially “forget the code exists”. I think it’s distinct from regular ol LLM-assisted development
I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination problems so I asked for some different async and threaded implementations, but ultimately they went off into the weeds in ways I couldn't really reason about, so I went back to a straight select/procedural implementation and had it start tracking outstanding blocks, which got something working reliably. Then I asked for fancy progress displays, tried several attempts at that. Then at this point I started cleaning up the code some, had it add type annotations, etc...
Big swath of pure or nearly pure vibe coding in the middle there.
If you choose to let the AI do all the coding and never dig into the actual code, you'll learn more about how to communicate with an LLM than you will about how to write code.
If I wanted to open a large world class fast food chain, I wouldn't be cooking home meals then. That would be silly.
Copilot can help me cook the equivalent of a McDonalds special in terms of software. It's good, I think McDonalds is delicious.
But it cannot help me cook a home meal software. It will insist that my home made fries must go in a little red box, and my fish sandwich needs only half a slice of cheese.
Deeply into that metaphor, maybe someone who has only worked for fast food chains might forget that a lot of good industrial dishes are variations of what previously were home cooked meals.
I am glad that copilot can help young cooks to become fast food workers. That really looks like something.
Well, I take pleasure in cooking home meal software. Can you make a copilot that helps with that?
You know what, nevermind. I don't need a copilot to cook home meals. I have a bunch of really good old books and I trust my taste.
It's not like some big company is going to be interested in some random amateur dish, is it? It was definitely not cooked for them.
If you prompt an LLM like an architect and feed it code rather than expecting it to write your code, both ChatGPT 4o and Claude 3.7 Sonnet do a great job. Do they mess up? Regularly. But the key is to guide the LLM and not let the LLM guide you, otherwise you'll end up in purgatory.
It takes some time to get used to what types of prompts work. Remember, LLMs are just tools; used in a naive way, they can be a drain, but used effectively they can be great. The typing speed alone is something I could never match.
But just like anything, you have to know what you're doing. Don't go slapping together a bunch of source files that they spit out. Be specific, be firm, tell it what to review first, what's important and what is not. Mention specific algorithms. Detail exactly how you want something to fit together, or describe shortcomings or pitfalls. I'll be damned if they don't get it most of the time.
You mean like in a fast food chain?
I know how to use it. All of that was already implied in my original comment. Sometimes though, I want to cook without a rigid mindset.
McDonald’s is a system for delivering food fast and cheap at scale. It breaks down when making one burger.
If you’re not a trained chef, you will not pump out Michelin star meals, even using the same recipe.
I found one of my license texts for a hobby project[0] in a Microsoft product[1]. I have no idea how they use it.
Copilot is very poor at understanding how the DSL arrangement of the project works or how to assemble validator trees. Before Copilot many other "enterprise" stuff like JetBrains IDEs had problems auto-completing it. But it was always good enough for me, for my own things.
It obviously have value. Maybe they're lazy and using it for something unrelated like the TLD list. I really don't know. What I know is that something of my amateur dish ended up being served in what I consider to be a fast food chain.
No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset. That's exactly the point against "vibe coding" they push. MS seems to despise anything that doesn't follow that.
Look, I love typescript and all that stuff. As I said, McDonalds meals are delicious.
But I don't want that approach for everything I code. This project is not the only one with that issue. I noticed the same in a portable shell compatibility layer, it can only help if I make it to look like other script languages.
"You're asking too much, how can copilot help with a language it was not trained on?"
I am not asking it to be good at that. Just don't make asshole posts saying anything other than MS pasteurization is "vibes".
If they paid me, then that would be another story. But they didn't, and used my "vibe" project anyways.
I am not complaining about software I released for free, before anyone tries to go for that.
I am making an observation about kinds of software that copilot can't help with. My kind of software development, in which I might take months to decide a name or redo everything several times just to try a new kind of sauce.
[0]: https://github.com/Respect/Validation [1]: https://support.microsoft.com/en-us/office/microsoft-teams-t...
Dead Comment
No. The likes of Copilot help you cook the meal you'd like, how you'd like it. In some cases it forgets to crack open eggs, in other cases it cooks a meal far better than whatever you'd be able to pull together in your home kitchen. And does it in seconds.
The "does it in seconds" is the key factor. Everyone heard of the "million monkeys with a typewriter" theorem. The likes of Copilot is like that, but it takes queues and gathers context and is supervised by you. The likes of Copilot is more in line with a lazy intern that you need to hand-hold to get them to finish their assignment. And with enough feedback and retries, it does finish the assignment. With flying colors.
"Does it in seconds" is kinda true if you ignore the "supervised by you" part. That part - reading through the generated diffs to catch (sometimes very subtle) errors - can take a while.
And sure, you'd have the same problem with the intern. But the intern learns from you. The LLM will make the same mistakes again in the same circumstances. Yes, I know they do have memory now, but it my experience that RAG-based stuff is not particularly reliable. I suspect this might improve once hardware is fast enough that you can use a (smallish) helper LLM for RAG with reasonable perf, but we aren't quite there yet.
My main takeaway from vibe-coding is that nobody cared enough to fill that niche and expectation. And it was really frustrating, yet we're getting there through convolutated, inefficient and borderline barbaric means.
People are still lamenting after HyperCard. Automation on windows or macos didn't go anywhere. Shortcuts were a better step into that direction but I feel it got stuck in the middle as Apple wasn't going to push it further. Android had more freedom yet you won't see a "normal" user do automation either.
If we're going to point the middle finger at vibe-coding, I wish we had something to point to as a better tool for the general population to quickly make stuff they want/need.
(Doing it as a professional dev is to me another debate, still with nuance in it IMHO. I'd also love better prototyping tools to be honest.)
I think what the target demographics want is that level of modularity and block building.
Is it:
- just pressing tab and letting copilot code whatever?
- asking an llm to do everything that it can and falling back on your own brain as needed or when its easier.
I guess probably more like the latter. I was just surprised to hear there was a special term for it. I thought everyone was doing that.
Copilot anticipating based off what you’re typing? An explicit prompt about what you want?
Dead Comment
It throws away decades of software engineering principles in favour of unchecked AI output by clicking “accept all” on the output.
You would certainly NOT use ‘vibe coded’ slopware that powers key control systems in critical infrastructure such as energy, banking, hospitals and communications systems.
The ones pushing “vibe coding” are the same ones who are all invested in the AI companies that power it (and will never disclose that).
An incident involving using ‘vibe coded’ slopware is just waiting to happen.
You would certainly NOT use ‘OUTSOURCED’ slopware that powers key control systems in critical infrastructure such as energy, banking, hospitals and communications systems.
An incident involving using ‘OUTSOURCED’ slopware is just waiting to happen.
... oh, wait...
When someone reviews vibe coded patches and gives feedback, what should the reviewer expect the author to do? Pass the feedback onto their agent and upload the result? That feels silly.
How has code review changed in our brave, vibey new world? Are we just reviewing ideas now, and leaving the code up to the model? Is our software now just an accumulation of deterministic prompts that can be replayed to get the same result?
Quit his job or stop contributing. Nobody is helped by people blindly commiting code they don't understand.
The next step seems that we will write programs in prompts. Maybe we will get a language that is more structured than the current natural language prompts and of much higher order than than our current high level programming constructs and libraries.
As it is easier and cheaper to do anything, the result is low-quality products. This of course serves well for the real professionals, who can now sell premium quality products at premium pricing for those who know and want the quality.