I will never as long as I live understand the argument that AI development is more fun. If you want to argue that you’re more capable or whatever, fine. I disagree but I don’t have any data to disprove you.
But saying that AI development is more fun because you don’t have to “wrestle the computer” is, to me, the same as saying you’re really into painting but you’re not really into the brush aspect so you pay someone to paint what you describe. That’s not doing, it’s commissioning.
Fun is a feeling, so one can't really have an argument that something is fun or not - that would be a category error no?
You've got a good analogy there though, because many great and/or famous painters have used teams of apprentices to produce the work that bears their (the famous artist's) name.
I'm reminded also of chefs and sous-chefs, and of Harlan Mill's famous "chief surgeon plus assistants" model of software development (https://en.wikipedia.org/wiki/Chief_programmer_team). The difference in our present moment, of course, is that the "assistants" are mechanical ones.
(as for how fun this is or isn't - personally I can't tell yet. I don't enjoy the writing part as much - I'd rather write code than write prompts - but then also, I don't enjoy writing grunt code / boilerplate etc., and there's less of that now, - and I don't enjoy having to learn tedious details of some tech I'm not actually interested in in order to get an auxiliary feature that I want, and there's orders of magnitude less of that now, - and then there are the projects and programs that simply would never exist at all if not for this new mechanical help in the earliest stages, and that's fun - it's a lot of variables to add up and it's all in flux. Like the French Revolution, it's too soon to tell! - https://quoteinvestigator.com/2025/04/02/early-tell/)
If you have to work in a language or framework with a lot of arbitrary-seeming features, ugly or opaque translation layers, or a lot of boiler-plate, then I absolutely understand the sentiment.
Programming a system at a low-level from scratch is fun. Getting CSS to look right under a bunch of edge cases - I won't judge that programmer too harshly for consulting the text machine.
This is especially true considering it's these shallow but trivia-dominated tasks which are the least fun and also which LLMs are the most effective at accomplishing.
One can have fun with all manner of things. Take wood-working for example. One can have fun with a handsaw. One can also have fun with a table saw. They're both fun, just different kinds
> I will never as long as I live understand the argument that AI development is more fun
AI is more fun for programmers that should've gone into management instead, and prefer having to explain things in painstaking detail in text, rather than use code. In other words, AI is for people that don't like programming that much.
Why would you even automate the most fun part of this job? As a freelance consultant, I'd rather have a machine to automate the whole boring business side so I could just sit in front of my computer and write stuff with my own hands.
And the thing I don't get about how excited people are is that if what LLMs really do is change software development from coding to code review, which is the part of software development that is universally hated.
I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different experience than I do.
• LLMs generate junk
• LLMs generate a lot of junk
I've been a software engineer professionally for over two decades and I use AI heavily both for personal projects and at work.
At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things).
AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly.
Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter.
It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on.
And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why.
It works amazingly well if you work with it as a peer.
"Our ability to zoom in and implement code is now obsolete
Even with SOTA LLMs like Opus 4.5 this is downright untrue. Many, many logical, strategic, architectural, and low level code mistakes are still happening. And given context window limitations of LLMs (even with hacks like subagents to work around this) big picture long-term thinking about code design, structure, extensibility, etc. is very tricky to do right."
If you can't see this, I have to seriously question your competence as an engineer in the first place tbh.
"We already do this today with human-written code. I review some code very closely, and other code less-so. Sometimes I rely on a combination of tests, familiarity of a well-known author, and a quick glance at the code to before saying "sure, seems fine" and pressing the green button. I might also ask 'Have you thought of X' and see what they say.
Trusting code without reading all of it isn't new, we're just now in a state where we need to review 10x more code, and so we need to get much better at establishing confidence that something works without paying human attention all the time.
We can augment our ability to write code with AI. We can augment our ability to review code with AI too."
Later he goes onto suggest that confidence is built via TDD. Problem is... if the AI is generating both code and tests, I've seen time and time again both in internal projects and OSS projects how major assumptions are incorrect, mistakes compound, etc.
I suspect that lots of developers who are sour on relying on AI significantly _would_ agree with most of this, but see the result of that logic leading to (as the article notes) "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated" and really don't like that outcome so they try to find a way to reject it.
"The skillset you've spend decades developing and expected to continue having a career selling? The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant, and it's your job to speed that process along" isn't an easy pill to swallow.
I don't care that AI development is more fun for the author. I wouldn't care if all the evidence pointed toward AI development being easier, faster, and less perilous. The externalities, at present, are unacceptable. We are restructuring our society in a way that makes individuals even less free and a few large companies even more powerful and wealthy, just to save time writing code, and I don't understand why people think that's okay.
> If you’re not reading your output, then why does skill level even matter?
Few thoughts here.
Experience helps you "check" faster that what you asked for is actually what was delivered. You "know" what to check for. You know what a happy path is, and where it might fail. You're more likely to test outside the happy path. You've seen dozens of failure modes already, you know where to look for.
Experience also allows you to better define stuff. If you see that the output is mangled, you can make an educated guess that it's from css. And you can tell the model to check the css integration.
Experience gives you faster/better error parsing. You've seen thousands of them already. You probably know what the error means. You can c/p the error but you can also "guide" the model with something like "check that x is done before y". And so on.
Last, but not least, the "experience" in actually using the tools gives you a better understanding of their capabilities and failure modes. You learn where you can let it vibe away, or where you need to specify more stuff. You get a feeling for what it did from a quick glance. You learn when to prompt more and where to go with generic stuff like "fix this".
The definition of 'vibe code' is somewhat nebulous at the moment. For many it means "only look at the end product (website) and use prompts to fix it" but for others it means "mostly don't hand-code anything, but check the diffs".
AI development for me is not fun. It may be faster and more productive, jury still out on that. But typing code and understanding each line has its advantages. AI also takes out a lot of creativity out of programming and climbing the abstractions isnt for everyone.
Do we want everyone to operate at PM level? The space for that is limited. Its easy to say you enjoy vibe coding when you are high up the chain but for most devs we are not as experienced or lucky to be able to feel stable when workflows change every day.
But I dont feel I have enough data to believe whether vibe coding or hand coding is better, I am personally doing tedious task with AI, and still writing code by hand all the time.
Also the author presents rewriting Numpy in rust as some achievement but the AIs most probably trained on Numpy and RustyNum, AI are best at copying the code so its not really a big thing.
Re audio, I have been working on a nice little tool called Claudio[0] which adds sounds to Claude Code in a nice configurable sort of way. It's still pretty new but it's a lot better than directly hooking to avplay :)
The more I use AI, the more I think about the book Fooled By Randomness.
AI can take you down a rabbit hole that makes you feel like you are being productive but the generated code can be a dead end because of how you framed the problem to the AI.
Engineers need enough discipline to understand the problems they are trying to solve before delegating a solution to a stochastic text generator.
I don’t always like using AI but have found it helpful in specific use cases such as speeding up CI test pipelines and writing spec; however, someone smarter than me/more familiar with the problem space may have better strategies that I cannot of think of, and I have been fooled by randomness.
Rather than spending iterations crafting precise permissions, why not just run with
--dangerously-skip-permissions
If run in a devcontainer[1][2], the worst thing that can happen is it deletes everything in the filesystem below the mounted repo. Recovery would entail checking out the repo again.
> "I will never as long as I live understand the argument that AI development is more fun."
What I always find amusing are the false equivalences, where one or several (creative) processes involving the hard work that is a fundamental part of the craft get substituted by push-to-"I did this!1!!" slop.
How's the saying go? "I hate doing thing x. The only thing I hate more is not doing thing x". One either owns that, or one doesn't. So that is indeed not mysterious. Especially not in a system where "Fake it till you make it" has been and is advertised as a virtue.
None of these articles address how we'll go from novice to expert, as either self-taught or through the educational system, and all the bloggers got their proverbial "10k hours" before LLMs were a thing. IMO This isn't abstractions, the risk is wholesale outsourcing of learning. And no, I don't accept the argument that correct and LLMs errors is the same as correcting a junior devs errors because the junior dev would (presumably) learn and grow to become a senior. The technology doesn't exist for an LLM to do the same today and there's no viable path in that direction.
Can someone tell me what the current thinking is on how we'll get over that gap?
I can tell you the current thinking of most of the instructors I know: teach the same fundamentals as always, and carefully add a bit of LLM use.
To use LLMs effectively, you have to be an excellent problem-solver with complex technical problems. And developing those skills has always been the goal of CS education.
Or, more bluntly, are you going to hire the junior with excellent LLM skills, or are you going to hire the junior with excellent LLM skills and excellent technical problem-solving skills?
But they do have to be able to use these tools in the modern workplace so we do cover some of that kind of usage. Believe me, though, they are pretty damned good at it without our help. The catch is when students use it in a cheating way and don't develop those problem-solving skills and then are screwed when it comes time to get hired.
So our current thinking is there's no real shortcut other than busting your ass like always. The best thing LLMs offer here is the ability to act as a tutor, which does really increase the speed of learning.
Thanks for the response, I appreciate it. I absolutely agree with you about CS education. I went to school to learn how to learn. So, the best-case outcome is everyone has A Young Lady's Illustrated Primer available to them. At that point I suppose to really does live with the individual as to whether they want to see how much potential they really have.
You spent the proverbial 10k hours like before. I don't know by AI has to lead to the lack of learning. I don't find people stop learning digital painting so far, even digital painting, from my perspective, is even more "solved" than programming by machines.
I heard that Pixar had a very advanced facial expression simulation system a decade ago. But I am very willing to bet that when Pixar hires animators they still prefer someone who can animate by hand (either in Maya or frame-by-frame on paper).
> I don't accept the argument that correct and LLMs errors is the same as correcting a junior devs errors because the junior dev would (presumably) learn and grow to become a senior. The technology doesn't exist for an LLM to do the same today and there's no viable path in that direction.
But the technology does exist. The proof is in the models you can use today, on two lines:
First, what you describe is exactly what the labs are doing. We went from "oh, look, it writes poems and if you ask for code it almost looks like python" 3 years ago. Since then, the models can handle most programming tasks, with increasing difficulty and increasing accuracy. What seemed SF 3 years ago is literally at your fingertips today. Project scaffolding, searching through codebases, bug finding, bug solving, refactorings, code review. All of these are possible today. And it all became possible because the labs used the "signals" from usage + data from subsidising models + RL + arch improvements to "teach" the models more and more. So if you zoom out, the models are "learning", even if you or I can't teach them in the sense you meant.
Secondly, when capabilities become sufficiently advanced, you can do it locally, for your own project, with your own "teachings". With things like skills, you can literally teach the models what to do on your code base. And they'll use that information in subsequent tasks. You can even use the models themselves for this! A flow that I use regularly is "session retro", where I ask the model to "condense the learnings of this session into a skill". And then those skills get invoked on the next task dealing with the same problem. So the model doesn't have to scour the entire code base to figure out where auth lives, or how we handle migrations, and so on. This is possible today!
The linked Claude generated script for giving more control over permissions in tool use is… typically Claude.
The code interleaves rules and control flow, drops side effects like “exit” in functions and hinges on a stack of regex for parsing bash.
This isn’t something I’ve attempted before but it looks like a library like bashlex would give you a much cleaner and safer starting point.
For a “throwaway” script like this maybe it’s fine, but this is typical of the sort of thing I’m seeing spurted out and I’m fascinated to see what people’s codebases look like these days.
Don’t get me wrong, I use CC every day, but man, you do need to fight it to get something clean and terse.
"AI development is more fun. I do more of what I like (think, experiment, write) and less of what I don't like (wrestle with computers).
I feel both that I can move faster and operate in areas that were previously inaccessible to me (like frontend). Experienced developers should all be doing this. We're good enough to avoid AI Slop, and there's so much we can accomplish today."
If frontend was "inacessible" and AI makes it "accessible", I would argue that you don't really know frontend and should probably not be doing it professionally with AI. Use AI, yes but learn frontend without AI first. And his "Experienced developers should all be doing this" is ridiculous. He should be honest and confess that he doesn't like programming. He probably enjoys systems design or some sort of role involving product design that does not involve programming. But none of these people are "developers".
I'm so completely over these types of articles. Just as the AI techbros want to convince people that "the genie is out of the bottle" and that these services & practices are inevitable, it is also the case the the cohort of people who explicitly eschew using genAI is significant and growing. Nobody is being convinced reading this…like "wow, I vowed never to use genAI as a software developer, and then suddenly I read this article and now I've seen the light!"
>>I get it, you’re too good to vibe code. You’re a senior developer who has been doing this for 20 years and knows the system like the back of your hand.
>> [...]
>>No, you’re not too good to vibe code. In fact, you’re the only person who should be vibe coding.
All we have to do is produce more devs with 20 years of experience and we'll be set. :)
AIs don't generate junk. Engineers with little experience _think_ they generate junk. Or engineers on that bandwagon, which in my opinion is driven by denial or naivety
If you know what the fuck you're doing, they're incredible. Scary so.
The author presents a false dichotomy when discussing "Why Not AI".
... there are some serious costs and reasonable
reservations to AI development. Let's start by listing
those concerns
These are super-valid concerns. They're also concerns that
I suspect came around when we developed compilers and
people stopped writing assembly by hand, instead trusting
programs like gcc ...
Compilers are deterministic, making their generated assembly code verifiable (for those compilers which produce assembly code). "AI", such as "Claude Code (or Cursor)" referenced in the article, is nondeterministic in their output and therefore incomparable to a program compiler.
One might as well equate the predictability of a Fibonacci sequence[0] to that of a PRNG[1] since both involve numbers.
> That being said, there are some serious costs and reasonable reservations to AI development.
Neither this nor the discussion here so far mentions ethics. It should.
According to latest reports AI now consumes more water than the global bottled water industry. These datacenters strain our grids and where needs can't be met they employ some of the least efficient ways to generate electricity generating tons of pollution. The pollution and the water problems are hitting poorer communities as the more affluent ones can afford much better legal pushback.
Next, alas, we can't avoid politics. The shadow that Peter Thiel and a16z (who named one of the two authors of the Fascist Manifesto their patron saints) casts over these tools is very long. These LLMs are used as a grand excuse to fire a lot of people and also to manufacture fascist propaganda on a scale you have never seen before. Whether these were goals when Thiel & gang financed them or not, it is undeniable they are now indispensable in helping the rise of fascism in the United States. Even if you were to say "but I am using code only LLMs" you are still stuffing the pockets of these oligarchs.
The harm these systems cause is vast and varied. We have seen them furthering suicidal ideation in children and instructing them on executing these thoughts. We have seen them generating non-consensual deepfakes at scale including those of children.
I think this take doesn’t take into account the slope of improvement we have seen from AI. Take Claude opus 4.5, I’ve seen dramatic improvements in the models ability to handle large context windows
53 comments
[ 4.4 ms ] story [ 51.1 ms ] threadBut saying that AI development is more fun because you don’t have to “wrestle the computer” is, to me, the same as saying you’re really into painting but you’re not really into the brush aspect so you pay someone to paint what you describe. That’s not doing, it’s commissioning.
You've got a good analogy there though, because many great and/or famous painters have used teams of apprentices to produce the work that bears their (the famous artist's) name.
I'm reminded also of chefs and sous-chefs, and of Harlan Mill's famous "chief surgeon plus assistants" model of software development (https://en.wikipedia.org/wiki/Chief_programmer_team). The difference in our present moment, of course, is that the "assistants" are mechanical ones.
(as for how fun this is or isn't - personally I can't tell yet. I don't enjoy the writing part as much - I'd rather write code than write prompts - but then also, I don't enjoy writing grunt code / boilerplate etc., and there's less of that now, - and I don't enjoy having to learn tedious details of some tech I'm not actually interested in in order to get an auxiliary feature that I want, and there's orders of magnitude less of that now, - and then there are the projects and programs that simply would never exist at all if not for this new mechanical help in the earliest stages, and that's fun - it's a lot of variables to add up and it's all in flux. Like the French Revolution, it's too soon to tell! - https://quoteinvestigator.com/2025/04/02/early-tell/)
The “lone genius” image is largely a modern romantic invention.
Programming a system at a low-level from scratch is fun. Getting CSS to look right under a bunch of edge cases - I won't judge that programmer too harshly for consulting the text machine.
This is especially true considering it's these shallow but trivia-dominated tasks which are the least fun and also which LLMs are the most effective at accomplishing.
I've coded professionally for 30 years (ergh!). I'm ok at it.
But I love building things with AI. I haven't had this much fun since the early 2000s.
AI is more fun for programmers that should've gone into management instead, and prefer having to explain things in painstaking detail in text, rather than use code. In other words, AI is for people that don't like programming that much.
Why would you even automate the most fun part of this job? As a freelance consultant, I'd rather have a machine to automate the whole boring business side so I could just sit in front of my computer and write stuff with my own hands.
At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things).
AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly.
Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter.
It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on.
And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why.
It works amazingly well if you work with it as a peer.
"Our ability to zoom in and implement code is now obsolete Even with SOTA LLMs like Opus 4.5 this is downright untrue. Many, many logical, strategic, architectural, and low level code mistakes are still happening. And given context window limitations of LLMs (even with hacks like subagents to work around this) big picture long-term thinking about code design, structure, extensibility, etc. is very tricky to do right."
If you can't see this, I have to seriously question your competence as an engineer in the first place tbh.
"We already do this today with human-written code. I review some code very closely, and other code less-so. Sometimes I rely on a combination of tests, familiarity of a well-known author, and a quick glance at the code to before saying "sure, seems fine" and pressing the green button. I might also ask 'Have you thought of X' and see what they say.
Trusting code without reading all of it isn't new, we're just now in a state where we need to review 10x more code, and so we need to get much better at establishing confidence that something works without paying human attention all the time.
We can augment our ability to write code with AI. We can augment our ability to review code with AI too."
Later he goes onto suggest that confidence is built via TDD. Problem is... if the AI is generating both code and tests, I've seen time and time again both in internal projects and OSS projects how major assumptions are incorrect, mistakes compound, etc.
"The skillset you've spend decades developing and expected to continue having a career selling? The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant, and it's your job to speed that process along" isn't an easy pill to swallow.
This simply is a mediocre take, sometimes I feel like people never actually coded at all to have such opinions
Embedded in this, is the assumption that many SWEs can actually do those roles better than existing specialists.
If they can't - end of the line
Experienced engineers can successfully vibe code? By definition it means not reading the output.
If you’re not reading your output, then why does skill level even matter?
Few thoughts here.
Experience helps you "check" faster that what you asked for is actually what was delivered. You "know" what to check for. You know what a happy path is, and where it might fail. You're more likely to test outside the happy path. You've seen dozens of failure modes already, you know where to look for.
Experience also allows you to better define stuff. If you see that the output is mangled, you can make an educated guess that it's from css. And you can tell the model to check the css integration.
Experience gives you faster/better error parsing. You've seen thousands of them already. You probably know what the error means. You can c/p the error but you can also "guide" the model with something like "check that x is done before y". And so on.
Last, but not least, the "experience" in actually using the tools gives you a better understanding of their capabilities and failure modes. You learn where you can let it vibe away, or where you need to specify more stuff. You get a feeling for what it did from a quick glance. You learn when to prompt more and where to go with generic stuff like "fix this".
Do we want everyone to operate at PM level? The space for that is limited. Its easy to say you enjoy vibe coding when you are high up the chain but for most devs we are not as experienced or lucky to be able to feel stable when workflows change every day.
But I dont feel I have enough data to believe whether vibe coding or hand coding is better, I am personally doing tedious task with AI, and still writing code by hand all the time.
Also the author presents rewriting Numpy in rust as some achievement but the AIs most probably trained on Numpy and RustyNum, AI are best at copying the code so its not really a big thing.
[0]: https://claudio.click
AI can take you down a rabbit hole that makes you feel like you are being productive but the generated code can be a dead end because of how you framed the problem to the AI.
Engineers need enough discipline to understand the problems they are trying to solve before delegating a solution to a stochastic text generator.
I don’t always like using AI but have found it helpful in specific use cases such as speeding up CI test pipelines and writing spec; however, someone smarter than me/more familiar with the problem space may have better strategies that I cannot of think of, and I have been fooled by randomness.
1. (conventional usage) https://code.visualstudio.com/docs/devcontainers/containers
2. (actual spec) https://containers.dev/
What I always find amusing are the false equivalences, where one or several (creative) processes involving the hard work that is a fundamental part of the craft get substituted by push-to-"I did this!1!!" slop.
How's the saying go? "I hate doing thing x. The only thing I hate more is not doing thing x". One either owns that, or one doesn't. So that is indeed not mysterious. Especially not in a system where "Fake it till you make it" has been and is advertised as a virtue.
Can someone tell me what the current thinking is on how we'll get over that gap?
To use LLMs effectively, you have to be an excellent problem-solver with complex technical problems. And developing those skills has always been the goal of CS education.
Or, more bluntly, are you going to hire the junior with excellent LLM skills, or are you going to hire the junior with excellent LLM skills and excellent technical problem-solving skills?
But they do have to be able to use these tools in the modern workplace so we do cover some of that kind of usage. Believe me, though, they are pretty damned good at it without our help. The catch is when students use it in a cheating way and don't develop those problem-solving skills and then are screwed when it comes time to get hired.
So our current thinking is there's no real shortcut other than busting your ass like always. The best thing LLMs offer here is the ability to act as a tutor, which does really increase the speed of learning.
You spent the proverbial 10k hours like before. I don't know by AI has to lead to the lack of learning. I don't find people stop learning digital painting so far, even digital painting, from my perspective, is even more "solved" than programming by machines.
I heard that Pixar had a very advanced facial expression simulation system a decade ago. But I am very willing to bet that when Pixar hires animators they still prefer someone who can animate by hand (either in Maya or frame-by-frame on paper).
But the technology does exist. The proof is in the models you can use today, on two lines:
First, what you describe is exactly what the labs are doing. We went from "oh, look, it writes poems and if you ask for code it almost looks like python" 3 years ago. Since then, the models can handle most programming tasks, with increasing difficulty and increasing accuracy. What seemed SF 3 years ago is literally at your fingertips today. Project scaffolding, searching through codebases, bug finding, bug solving, refactorings, code review. All of these are possible today. And it all became possible because the labs used the "signals" from usage + data from subsidising models + RL + arch improvements to "teach" the models more and more. So if you zoom out, the models are "learning", even if you or I can't teach them in the sense you meant.
Secondly, when capabilities become sufficiently advanced, you can do it locally, for your own project, with your own "teachings". With things like skills, you can literally teach the models what to do on your code base. And they'll use that information in subsequent tasks. You can even use the models themselves for this! A flow that I use regularly is "session retro", where I ask the model to "condense the learnings of this session into a skill". And then those skills get invoked on the next task dealing with the same problem. So the model doesn't have to scour the entire code base to figure out where auth lives, or how we handle migrations, and so on. This is possible today!
The code interleaves rules and control flow, drops side effects like “exit” in functions and hinges on a stack of regex for parsing bash.
This isn’t something I’ve attempted before but it looks like a library like bashlex would give you a much cleaner and safer starting point.
For a “throwaway” script like this maybe it’s fine, but this is typical of the sort of thing I’m seeing spurted out and I’m fascinated to see what people’s codebases look like these days.
Don’t get me wrong, I use CC every day, but man, you do need to fight it to get something clean and terse.
https://gist.github.com/mrocklin/30099bcc5d02a6e7df373b4c259...
I feel both that I can move faster and operate in areas that were previously inaccessible to me (like frontend). Experienced developers should all be doing this. We're good enough to avoid AI Slop, and there's so much we can accomplish today."
If frontend was "inacessible" and AI makes it "accessible", I would argue that you don't really know frontend and should probably not be doing it professionally with AI. Use AI, yes but learn frontend without AI first. And his "Experienced developers should all be doing this" is ridiculous. He should be honest and confess that he doesn't like programming. He probably enjoys systems design or some sort of role involving product design that does not involve programming. But none of these people are "developers".
>> [...]
>>No, you’re not too good to vibe code. In fact, you’re the only person who should be vibe coding.
All we have to do is produce more devs with 20 years of experience and we'll be set. :)
If you know what the fuck you're doing, they're incredible. Scary so.
One might as well equate the predictability of a Fibonacci sequence[0] to that of a PRNG[1] since both involve numbers.
0 - https://en.wikipedia.org/wiki/Fibonacci_sequence
1 - https://en.wikipedia.org/wiki/Pseudorandom_number_generator
Easy to implement -> can talk to ElevenLabs or OpenAI and it's a pretty delightful experience
Neither this nor the discussion here so far mentions ethics. It should.
According to latest reports AI now consumes more water than the global bottled water industry. These datacenters strain our grids and where needs can't be met they employ some of the least efficient ways to generate electricity generating tons of pollution. The pollution and the water problems are hitting poorer communities as the more affluent ones can afford much better legal pushback.
Next, alas, we can't avoid politics. The shadow that Peter Thiel and a16z (who named one of the two authors of the Fascist Manifesto their patron saints) casts over these tools is very long. These LLMs are used as a grand excuse to fire a lot of people and also to manufacture fascist propaganda on a scale you have never seen before. Whether these were goals when Thiel & gang financed them or not, it is undeniable they are now indispensable in helping the rise of fascism in the United States. Even if you were to say "but I am using code only LLMs" you are still stuffing the pockets of these oligarchs.
The harm these systems cause is vast and varied. We have seen them furthering suicidal ideation in children and instructing them on executing these thoughts. We have seen them generating non-consensual deepfakes at scale including those of children.