> In many advanced software teams, developers no longer write the code; they type in what they want, and AI systems generate the code for them.
What a wild and speculative claim. Is there any source for this information?
What a wild and speculative claim. Is there any source for this information?
Also in a case of just prose to code, Claude wrote up a concurrent data migration utility in Go. When I reviewed it, it wasn't managing goroutines or waitgroups well, and the whole thing was a buggy mess and could not be gracefully killed. I would have written it faster by hand, no doubt. I think I know more now and the calculus may be shifting on my AI usage. However, the following day, my colleague needed a nearly identical temporary tool. A 45 minute session with Claude of "copy this thing but do this other stuff" easily saved them 6-8 hours of work. And again, that was just talking with Claude.
I am doing a hybrid approach really. I write much of my scaffolding, I write example code, I modify quick things the ai made to be more like I want, I set up guard rails and some tests then have the ai go to town. Results are mixed but trending up still.
FWIW, our CEO has declared us to be AI-first, so we are to leverage AI in everything we do which I think is misguided. But you can bet they will be reviewing AI usage metrics and lower wont be better at $WORK.
First pass on a greenfield project is often like that, for humans too I suppose. Once the MVP is up, refactor with Opus ultrathink to look for areas of weakness and improvement usually tightens things up.
Then as you pointed out, once you have solid scaffolding, examples, etc, things keep improving. I feel like Claude has a pretty strong bias for following existing patterns in the project.
If companies want to value something as dumb as LoC then they get what they incentivized
I think the difficulty is exercising the judgement to know where that productive boundary sits. That's more difficult than it sounds because we're not use to adjudicating machine reasoning which can appear human-like ... So we tend to treat it like a human which is, of course, an error.
Somethings are best written by yourself.
And this is with the mighty claude opus 4.5
All of these have a non-trivial learning curve and/or poor and patchy docs.
I could master all of these the hard way, but it would be a huge and not very productive time sink. It's much easier to tell a machine what I want and iterate with error reports if it doesn't solve my problem immediately.
So is this AGI? It's not self-training. But it is smart enough to search docs and examples and pull them together into code that solves a problem. It clearly "knows" far more than I do in this particular domain, and works much faster.
So I am very clearly getting real value from it. And there's a multiplier effect, because it's now possible to imagine automating processes that weren't possible before, and glue together custom franken-workflows that link supposedly incompatible systems and save huge amounts of time.
I've taken some pleasure in having GitHub copilot review whitespace normalization PRs. It says it can't do it, but I hope I get my points anyway.
Sounds like the extremely well-repeated mistake of treating everything like a nail because hammers are being hyped up this month.
My layperson anecdote about LLM coding is that using Perplexity is the first time I've ever had the confidence (artificial, or not) to actually try to accomplish something novel with software/coding. Without judgments, the LLM patiently attempts to turn my meat-speak into code. It helps explain [very simple stuff I can assure you!] what its language requires for a hardware result to occur, without chastising you. [Raspberry Pi / Arduino e.g.]
LLMs have encouraged me to explore the inner workings of more technologies, software and not. I finally have the knowledgeable apprentice to help me with microcontroller implementations, albeit slowly and perhaps somewhat dangerously [1].
----
Having spent the majority of my professional life troubleshooting hardware problems, I often benefit from rubber ducky troubleshooting [0], going back to the basics when something complicated isn't working. LLMs have been very helpful in this roleplay (e.g. garage door openers, thermostat advanced configurations, pin-outs, washing machine not working, etc.).
[0] <https://en.wikipedia.org/wiki/Rubber_duck_debugging>
[1] "He knows just enough to be dangerous" —proverbial electricians
¢¢
She didn't live long enough to use ChatGPT [1] (she would have been flabbergasted at its ability to understand people/situations), but even with her "normal" intelligence she would have been a master to its perceptions/trainings.
[0] "Beyond just teasing."
[1] We did briefly wordplay with GPT-2 right before she died via thisworddoesnotexist.com exchanges, but nothing conversive.
[2] Relavent example, to the best of my understanding of hers: I would never ask my brilliant engineer programmer hardwarebro for coding help on any personal project, never. Just as I don't ask lawyerbro for personal legal advice.
----
About a year later (~2023), my dentist friend experienced a sudden life change (wife sick @35); in his grieving/soul-seeking, I recommended that he share some of his mental chaos with an LLM, even just if to role-play as his sick family member. Dr. Friend later thanked me for recommending the resource — particularly "the entire lack of any judgments" — and shared his own brilliant discoveries using creative prompt structuring.
----
Particularly as a big dude, it's nice to not always have to be the tough guy, to even admit weakness. Unfortunately I think the overall societal benefits of generative AI are going to increase anti-social behaviour, but it's nice to have a friendly apprentice that knows something about almost everything... any time... any reason.
j/k don't worry I'm an idiot — but somebody else WILL.
Nothing that the LLM is outputting is useful in the hands of somebody who couldn't have done it themselves (at least, given a reasonable amount of time).
The most apt analogy is that of pilot and autopilot. Autopilot makes the job of the pilot more pleasant, but it doesn't even slightly obviate the need for the pilot, nor does it lower the bar for the people that you can train as pilots.
The benefits of LLM programming are mostly going to be subsumed by the operator, to make their lives easier. Very little is gonna go to their employer (despite all the pressure), and this is not due to some principal-agent breakdown; it's just intrinsic to the nature of this work.
How so? And in what context?
Where I am, headcount is based on "can we finish and sustain these planned and present required projects". If these automations allow a developer to burn less time, it reduces the need for headcount. As a direct result of this approach to hiring based on need, the concept of a "layoff" doesn't exist where I am.
This is exactly the fallacy, and it's very hard to see why it's a fallacy if you've never professionally written code (and even then).
Software development work fills to occupy the time allotted to it. That's because there is always a tradeoff between time and quality. If you have time available, you will fundamentally alter your approach to writing that piece of software. A rough analogy: air travel doesn't mean we take fewer vacations -- it just means we take vacations to farther away places.
Because of this effect, a dev can really finish a project in as little time as you want (up to a reasonable minimum). It just comes down to how much quality loss and risk can be tolerated. I can make a restaurant website in 1 hour (on Wix/Squarespace) or in 3 months (something hand-crafted and sophisticated). The latter is not "wasted time", it just depends on where you move the lever.
However, sometimes this is a false tradeoff. It isn't always necessary that the place you flew 3 hours will give you a better vacation than some place you could've driven to in 3 hours. You only hope it's better.
>As a direct result of this approach to hiring based on need, the concept of a "layoff" doesn't exist where I am.
LLMs or not, you could've just hired fewer people and made it work anyway. It's not like if you hired 3 people instead of 6 before the LLM era, it was impossible to do.
The gist of it is that LLMs are mostly just devs having fun and tinkering about, or making their quality of life better, or implementing some script, tooling, or different approach that they might've avoided before LLMs. There's no powertrain from that stuff to business efficiency.
This was not necessary or appropriate, and completely discredits your reply.
But if you meant it's inappropriate even as a general statement then I disagree. Some concepts are just difficult to convey or unintuitive if one hasn't actually done the thing. It's more of a disclaimer that what's to follow is unintuitive.
your boss is going to let you go home if you get all your work done early?
> Coding performed by AI is at a world-class level, something that wasn’t so just a year ago.
Wow, finance people certainly don't understand programming.
It's very useful if you have the knowledge and experience to tell when it's wrong. That is the absolutely vital skill to work with these systems. In the right circumstances, they can work miracles in a very short time. But if they're wrong, they can easily waste hours or more following the wrong track.
It's fast, it's very well-read, and it's sometimes correct. That's my analysis of it.
This sentence and the rest of the post reads like an horoscope advice. Like "It can be good if you use it well, it may be bad if you don't". It's pretty much the same as saying a coin may land on head or on tail.
Of course it is mind blowing for them.
Ref: https://blog.codinghorror.com/has-joel-spolsky-jumped-the-sh...
> disliking exceptions seemed crazy then but it's pretty normal now
Assuming that my interpretation is correct, then I assume that you are a low level systems programmer -- C, C++, Rust, etc? Maybe even Golang? If you are doing bog standard enterprise programming with Python, Java or C#, exceptions are everywhere and unavoidable. I am confused. If anything, the last 20 years have cemented the fact that people should be able to choose a first class citizen (language) that either has exceptions or not. The seven languages that I mentioned are all major and have billions of lines of legacy code in companies and open source projects. They aren't going anywhere soon. C++ is a bit special because you can use a compiler flag to disable exceptions... so C++ can be both. (Are there other languages like that? I don't know any. Although, I think that Microsoft has a C language extension that allows throw/catch!)
I'm not trying to advocate going against the stream and not using exceptions in languages based around them, but I can see it being pulled off by a competent team, which I'm certain Joel could put together.
Lots of people are outing themselves these days about the complexity of their jobs, or lack thereof.
Which is great! But it's not a +1 for AI, it's a -1 for them.
Which is great! But it's not a +1 for AI, it's a -1 for them.
" Is you, right?
Doesn't everyone work that way?
clang doesn't "understand" the hints because it doesn't "understand" anything, but it knows what to do with them! Just like codex.
But there is nothing about a compiler that implies determinism. A compiler is defined by function (taking input on how you want something to work and outputting code), not design. Implementation details are irrelevant. If you use a neural network to compile C source into machine code instead of more traditional approaches, it most definitely remains a compiler. The function is unchanged.
[1] "Faulty" hardware found in the real world can sometimes break this assumption. But a C compiler running on faulty hardware can change the assumption too.
Did you do that stupid HN thing where you failed to read the entire comment and then went off to try it on faulty hardware?
Now try it on deterministic hardware.
But what are you asking for, exactly? Do you want me to copy and paste the output (so you can say it isn't real)? Are you asking for access to my hardware? What does sharing mean here?
Symbolica is working on more deterministic/quicker models: https://www.symbolica.ai
I also wish it was that easy, but compiler determinism is hard, too: https://reproducible-builds.org
Wow. No, I actually don't want to participate in a discussion where the default is random hostility and immediate personal attack. Sheesh.
Incorrect. LLMs are designed to be deterministic (when temperature=0). Only if you choose for them to be non-deterministic are they so. Which is no different in the case of GCC. You can add all kinds of random conditionals if you had some reason to want to make it non-deterministic. You never would, but you could.
There are some known flaws in GPUs that can break that assumption in the real world, but in theory (and where you have working, deterministic hardware) LLMs are absolutely deterministic. GCC also stops being deterministic when the hardware breaks down. A cosmic bit flip is all it takes to completely defy your assertion.
It really comes mostly down to being able to concisely and eloquently define what you want done. It also is important to understand what the default tendencies and biases of the model are so you know where to lean in a little. Occasionally you need to provide reference material.
The capabilities have grown dramatically in the last 6 months.
I have an advantage because I have been building LLM powered products so I know mechanically what they are and are not good with. For example.. want it to wire up an API with 250+ endpoints with a harness? You better create (or have it create) a way to cluster and audit coverage.
Generally the failures I hear often with "advanced" programmers are things like algorithmic complexity, concurrency, etc.. and these models can do this stuff given the right motivation/context. You just need to understand what "assumptions" the model it making and know when you need to be explicit.
Actually one thing most people don't understand is they try to say "Do (A), Don't do (B)", etc. Defining granular behavior which is fundamentally a brittle way to interact with the models.
Far more effective is defining the persona and motivation for the agent. This creates the baseline behavior profile for the model in that context.
Not "don't make race conditions", more like "You value and appreciate elegant concurrent code."
We had a method for this before LLMs; it was called "Haskell".
This is a interesting take take considering that programmers are experts in communicating what someone has asked for (however vaguely) into code.
I think you're referring to is the transition from 'write code that does X' which is very concrete to 'trick an AI into writing the code I would have written, only faster', which feels like work that's somewhere between an art form and asking a magic box to fix things over and over again until it stops being broken (in obvious ways, at least).
Understandably people that prefer engineered solutions do not like the idea of working this way very much.
1. Basing on how the engineer just responded to my comment, what is the understanding gap?
2. How do I describe what I want in a concise and intuitive way?
3. How do I tell an engineer what is important in this system and what are the constraints?
4. What assumptions will an engineer likely make that are will cause me to have to make a lot of corrections?
Etc.. this is all human to human.
These skills are all transferrable to working with an LLM.
So I guess if you are not used to technical leadership, you may not have used those skills as much.
My supposition was: Many programmers that say their programming domain was too advanced and llms didn't work for their kind of code are simply bad at describing concisely what is required.
Surely that revenue is coming from people using the services to generate code? Right?
In time I’m sure it will, but it’s still early days, land grab time.
There are some ~1.5 million software developers in the US per BLS data, or ~4 million if using a broader definition Median salary is $120-140k. Let's say $120k to be conservative.
This puts total software developer salaries at $180 billion.
So, that puts $1 billion in Claude revenue in perspective; only about 0.5% of software developer salaries. Even if it only improved productivity 5%, it'd be paying for itself handily - which means we can't take the $1 billion in revenues to indicate that it's providing a big boost in productivity.
The AI companies are currently lighting dollars on fire if you pay them a few pennies to do so.
The AI models are actually accomplishing something, but the unit economics aren't there to support it being profitable
Yes. And all code is tech debt. Now generated faster than ever.
>The key is to not be one of the investors whose wealth is destroyed in the process of bringing on progress.
They are a VC group. Financial folks. They are working largely with other people's money. They simply need not hold the bag to be successful.
Of course they don't care if its a bubble or not, at the end of the day, they only have to make sure they aren't holding the bag when it all implodes.
But to say that they don't write any code at all, it's really stretched. Maybe I'm not good enough at AI-assisted and vibe coding, but code-quality always seems to drop down really hard the moment one steps a bit outside the common patterns.
Kinda like having a child "help" you cook basically.
But for the child you do it because they actually learn. llms do not learn in that sense.
But I see what you mean, there have been at least a few insane comment sections for sure.
This implies that you are an expert/seasoned programmer. And not everybody is an expert on this industry (especially the reviewing code part).
If a team has one senior/seasoned person and 3 juniors will adopting ai be a total positive move? Or the senior person will just become the bottleneck for the junior devs?
This is mission critical robotics software
It has become a standard tool, in the same way that most developers code with an IDE, most developers use agentic AI to start a task (if not to finish it).
Error bars, folks, use them.
Though I do think "advanced software team" is kind of an absurd phrase, and I don't think there is any correlation with how "advanced" the software you build is and how much you need AI. In fact, there's probably an anti-correlation: I think that I get such great use out of AI primarily because we don't need to write particularly difficult code, but we do need to write a lot of it. I spend a lot of time in React, which AI is very well-suited to.
EDIT: I'd love to hear from people who disagree with me or think I am off-base somehow about which particular part of my comment (or follow-up comment https://news.ycombinator.com/item?id=46222640) seems wrong. I'm particularly curious why when I say I use Rust and code faster everyone is fine with that, but saying that I use AI and code faster is an extremely contentious statement.
>I do thoroughly audit all the code that AI writes, and often go through multiple iterations
Does this actually save you time versus writing most of the code yourself? In general, it's a lot harder to read and grok code than to write it [0, 1, 2, 3]. For me, one of the biggest skills for using AI to efficiently write code is a) chunking the task into increments that are both small enough for me to easily grok the AI-generated code and also aligned enough to the AI's training data for its output to be ~100% correct, b) correctly predicting ahead of time whether reviewing/correcting the output for each increment will take longer than just doing it myself, and c) ensuring that the overhead of a) and b) doesn't exceed just doing it myself.
[0] https://mattrickard.com/its-hard-to-read-code-than-write-it
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[2] https://trishagee.com/presentations/reading_code/
[3] https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
To be honest, I don’t really have a problem with chunking my tasks. The reason I don’t is because I don’t really think about it that way. I care a lot more about chunks and AI could reasonably validate. Instead of thinking “what’s the biggest chunk I could reasonably ask AI to solve” I think “what’s the biggest piece I could ask an AI to do that I can write a script to easily validate once it’s done?” Allowing the AI to validate its own work means you never have to worry about chunking again. (OK, that's a slight hyperbole, but the validation is most of my concern, and a secondary concern is that I try not to let it go for more than 1000 lines.)
For instance, take the example of an AI rewriting an API call to support a new db library you are migrating to. In this case, it’s easy to write a test case for the AI. Just run a bunch of cURLs on the existing endpoint that exercise the existing behavior (surely you already have these because you’re working in a code base that’s well tested, right? right?!?), and then make a script that verifies that the result of those cURLs has not changed. Now, instruct the AI to ensure it runs that script and doesn’t stop until the results are character for character identical. That will almost always get you something working.
Obviously the tactics change based on what you are working on. In frontend code, for example, I use a lot of Playwright. You get the idea.
As for code legibility, I tend to solve that by telling the AI to focus particularly on clean interfaces, and being OK with the internals of those interfaces be vibecoded and a little messy, so long as the external interface is crisp and well-tested. This is another very long discussion, and for the non-vibe-code-pilled (sorry), it probably sounds insane, and I feel it's easy to lose one's audience on such a polarizing topic, so I'll keep it brief. In short, one real key thing to understand about AI is that it makes the cost of writing unit tests and e2e tests drop significantly, and I find this (along with remaining disciplined and having crisp interfaces) to be an excellent tool in the fight against the increased code complexity that AI tools bring. So, in short, I deal with legibility by having a few really really clean interfaces/APIs that are extremely readable, and then testing them like crazy.
EDIT
There is a dead comment that I can't respond to that claims that I am not a reliable narrator because I have no A/B test. Behold, though: I am the AI-hater's nightmare, because I do have a good A/B test! I have a website that sees a decent amount of traffic (https://chipscompo.com/). Over the last few years, I have tried a few times to modernize and redesign the website, but these attempts have always failed because the website is pretty big (~50k loc) and I haven't been able to fit it in a single week of PTO.
This Thanksgiving, I took another crack at it with Claude Code, and not only did I finish an entire redesign (basically touched every line of frontend code), but I also got in a bunch of other new features, too, like a forgot password feature, and a suite of moderation tools. I then IaC'd the whole thing with Terraform, something I only dreamed about doing before AI! Then I bumped React a few majors versions, bumped TS about 10 years, etc, all with the help of AI. The new site is live and everyone seems to like it (well, they haven't left yet...).
If anything, this is actually an unfair comparison, because it was more work for the AI than it was for me when I tried a few years ago, because because my dependencies became more and more out of date as the years went on! This was actually a pain for AI, but I eventually managed to solve it.
The METR paper demonstrated that you are not a reliable narrator for this. Have you participated in a study where this was measured, or are you just going off intuition? Because METR demonstrated beyond doubt that your intuition is a liar in this case.
If you're not taking measurements it is more likely that you are falling victim to a number of psychological effects (sunk cost, Gell-Manns, slot machine effect) than it is that your productivity has really improved.
Have you received a 5-10x pay increase? If your productivity is now 10x mine (I don't use these tools at work because they are a waste of time in my experience) then why aren't you compensated as such and if it's because of pointy haired bosses, you should be able to start a new company with your 10x productivity to shut him and me up.
Provide links to your evidence in the replies
Does Amazon pay everyone who receives "Not meeting expectations" in their perf review 0 dollars? Did Meta pay John Carmack (or insert your favorite engineer here) 100x that of a normal engineer? Why do you think that would be?
Does anyone know how much he made altogether from Meta?
If you're climbing the exec ladder your pay will scale a little bit better, but again, not 100x or even 10x. Even the current AI researcher craze is for an extremely small number of people.
For some data points, check out levels.fyi and compare the ratio of TCs for a mid-level engineer/manager versus the topmost level (Distinguished SWE, VP etc.) for any given company.
And thus help engineers get paid more in line with their “value”. Albeit with much higher variance.
Which is not to say either one is better or worse! Regular employment does come with much lower risk, as it is amortized over the entire company, whereas startups are risky and stressful. Different strokes for different folks.
I do think AI could create a new paradigm though. With dropping employment and increasing full-stack business capabilities, I foresee a rise in solopreneurship, something I'm trying out myself.
The commenter told you they suspect they save time, it seems like taking their experience at face value is reasonable here. Or, at least I have no reason to jump down their throat... the same way I don't jump down your throat when you say, "these tools are a waste of time in my experience." I assume that you're smart enough to have tested them out thoroughly, and I give you the benefit of the doubt.
If you want to bring up METR to show that they might be falling into the same trap, that's fine, but you can do that in a much less caustic way.
But by the way, METR also used Cursor Pro and Claude 3.5/3.7 Sonnet. Cursor had smaller context windows than today's toys and 3.7 Sonnet is no longer state of the art, so I'm not convinced the paper's conclusions are still as valid today. The latest Codex models are exponential leaps ahead of what METR tested, by even their own research.[1]
[1]https://metr.org/blog/2025-03-19-measuring-ai-ability-to-com...
Imagine that you've built an app with libraries A, B, and C and conceptually understand all that's involved. But now you're required to move everything to X, Y, and Z. There won't be anything fundamentally new or revolutionary to learn, but you'll have to sit and read those docs, potentially for hours (cost of task switching and all). Getting the AI to execute the changes gets you to skip much of the tedium. And even though you still don't really know much about the new libs, you'll get the gist of most of the produced code. You can piecemeal the docs to review the code at sensitive boundaries. And for the rest, you'll paint inside the frames as you normally would if you were joining a new project.
Even as a skeptic of the general AI productivity narrative, I can see how that could squeeze a week's worth of "ever postponed" tasks inside a day.
That is one of the assumptions that pro-AI people always bring. You don't read the new docs to learn the domain. As you've said, you've already learn it. You read it for the gotchas. Because most (good) libraries will provide examples that you can just copy-paste and be done with it. But we all know that things can vary between implementations.
> Even as a skeptic of the general AI productivity narrative, I can see how that could squeeze a week's worth of "ever postponed" tasks inside a day.
You could squeeze a week inside a day the normal way to. Just YOLO it, by copy pasting from GitHub, StackOverflow and the whole internet.
But yes, I do think that the efficiency gain, purely in the domain of coding, is around 5x, which is why I was able to entirely redesign my website in a week. When working on personal projects I don't need to worry about stakeholders at all.
Is it ego? Defensiveness? AI anxiety? A need to be the HN contrarian against a highly visible technology innovation?
I don't think I understand... I haven't seen the opposite view (AI wastes a ton of time) get hammered like that.
At the very least, it certainly makes for an acidic comments section.
That’s why when folks say that AI has made them 10x more productive, I ask if they did 10 years worth of work in the last year. If you cannot make that claim, you were lying when you said it made you 10x more productive. Or at least needed a big asterisk.
If AI makes you 10x more productive in a tiny portion of your job, then it did not make you 10x more productive.
Meanwhile, the people claiming 10x productivity are taken at face value by people who don’t know any better, and we end up in an insane hype cycle that has obvious externalities. Things like management telling people that they must use AI or else. Things like developer tooling making zero progress on anything that isn’t an AI feature for the last two years. Things like RAM becoming unaffordable because Silicon Valley thinks they are a step away from inventing god. And I haven’t scratched the surface.
You’ll note the pattern of the claims getting narrower and narrower as people have to defend them and think critically about them (5-10x productivity -> 4-5x productivity -> 4-5x as much code written on a side project).
It’s not a personal attack, it is a corrective to the trend of claiming 5,10,100x improvements to developer productivity, which rarely if ever holds up to scrutiny.
If I have to "prove" my productivity in a court of law - that is to say, you - I'll down-modulate it to focus on the bits that are most objective, because I understand you will be skeptical. For instance, I really do think I'm 10x faster with Terraform, because I don't need to read all the documentation, and that would have taken absurd amounts of time. There were also a few nightmarish bugs that I feel could have taken me literally hours or infinity (I would have just given up), like tracking down a breaking change snuck in in a TS minor update when I upgraded from 2.8 to latest, that Codex chomped through. But I imagine me handwaving "it's definitely 10x, just trust me" on those ones, where the alternatives aren't particularly clear, might not be an argument you'd readily accept. On the other hand, the 5x gains when writing my website, using tech I know inside and out, felt objective.
I think this is where the lede is buried. Yes, it takes time up front. But then you learn(ed) it and can apply those skills quickly in the future.
In 10 years when all sorts of new tech is around, will you read the docs? Or just count on an LLM?
That being said, I have taught myself a ridiculous amount of tech with AI. It's not always great at depth, but it sure is amazing at breadth. And I can still turn to docs for depth when I need to.
Makes sense. I’d probably be less skeptical if a/ we had a definition of AI and b/ people stopped calling LLMs “AI”
It is really neat tech. It is absolutely “artificial” and it absolutely is not “intelligent”
What makes you think one year is the right timeframe? Yet you seem to be so wildly confident in the strength of what you think your question will reveal… in spite of the fact that the guy gave you an example.
It wasn’t that he didn’t provide it, it was that you didn’t want to hear it.
It is actually a very forgiving metric over a year because it is measuring only your own productivity relative to your personal trend. That includes vacation time and sick time, so the year smooths over all the variation.
Maybe he did do 5 weeks of work in 1 week, and I’ll accept that (a much more modest claim than the usual 10-100x claimed multiplier).
Not only that, I think you're misrepresenting his claim:
> I suspect I’m likely 5-10x more productive, though it depends exactly what I’m working on
1) He didn't say 10-100x
2) He said it depended on the work he was doing
Those seem reasonable enough that I can take his experience at face value.
This isn't about you pressure testing his claim, this is about you just being unwilling to believe his experience because it doesn't fit the narrative you've already got in your head.
The trick now is deciding what code to write quickly enough to keep Claude and friends busy.
It used to be "hey I found an issue..", now it is like "here is a pr to fix an issue I saw". The net effort to me is only slightly more. I usually have to identify the problem and that is like 90% of fixing it.
Add to the fact that now I can have an AI take a first pass at identifying the problem with probably an 80%+ success rate.
I-know-what-kind-of-man-you-are.jpeg
You come off as a zealot by branding people who disagree as "haters".
Edit: AI excels at following examples, or simple, testable tasks that require persistence, which is intern-level work. Doing this narrow band of work quickly doesn't result in 10x productivity.
I'm yet to find a single person who has shown evidence to go through 10x more tasks in a sprint[1], or match the output of the rest of their 6-10-member team by themselves.
1. Even for junior level work
> I'm yet to find a single person who has shown evidence to go through 10x more tasks in a sprint[1], or match the output of the rest of their 6-10-member team by themselves.
If my website, a real website with real users, doesn't qualify, then I'm not sure what would. A single person with evidence is right in front of you, but you seem to be denying the evidence of your own eyes.
All of the work you described is essentially manual labor. It's not difficult work - just boring, sometimes error prone work that mostly requires you to do obvious things and then tackle errors as they pop up in very obvious ways. Great use case for AI, for sure. This and the fact that the end result is so poor isn't really selling your argument very well, except maybe in the sense that yeah, AI is great for dull work in the same way an excavator is great for digging ditches.
If you ever find yourself at the point where you are insulting a guy's passion project in order to prove a point, perhaps have a deep breath, and take a step back from the computer for a moment. And maybe you should look deep inside yourself, because you might have crossed the threshold to being a jerk.
Yes, my site has issues. You know what else it has? Users. Your comments about FOUC and waterfalls are correct, but they don't rank particularly high on what are important to people who used the site. I didn't instruct the AI to fix them, because I was busy fixing a bunch of real problems that my actual users cared about.
As for loading slowly -- it loads in 400ms on my machine.
I'm just calling spade a spade. If you didn't want people to comment on your side project given your arguments and the topic of discussion, you should just not have posted it in a public forum or have done better work.
I can understand to some degree it would be chafing that I described myself as working at a SF Series C startup etc. The only intent there was to illustrate that I wasn't someone who started coding 2 weeks ago and had my mind blown by typing "GPT build me a calculator" into Claude. No intent at all of calling myself a mega-genius, which I don't really think I am. Just someone who likes doing fun stuff with AI.
And, BTW, if you reread my initial comment, you will realize you misread part of it. I said that "Advanced Programming" is the exact opposite of the type of work I am doing.
The problem is that your project has basic performance issues - FOUC, render waterfalls - that are central concerns in modern React development. These aren't arbitrary standards I invented to be mean. They're fundamental enough that React's recent development has specifically focused on solving them.
So when you say I'm inventing quality standards (in your now-deleted comment), or that this is just a passion project so quality doesn't matter, you're missing the point. You can't argue from professional authority that AI makes you more productive without compromise, use your work as proof, and then retreat to "it's just for fun" when someone points out the quality issues. Either it demonstrates your workflow's effectiveness or it doesn't. You can't have it both ways.
The kids' artwork comparison doesn't work either. You're not a child showing me a crayon drawing - you're a professional developer using your work as evidence in a technical argument about AI productivity. If you want to be treated as an experienced developer making authoritative claims, your evidence needs to support those claims.
I'm genuinely not trying to be cruel here, but if this represents what your AI workflow produces when you're auditing the output, it raises serious questions about whether you can actually catch the problems the AI introduces - which is the entire crux of your argument. Either you just aren't equipped to audit it (because you don't know better), or you are becoming passive in the face of the walls of code that the AI is generating for you.
Let's talk a little about FOUC and the waterfall. I am aware of both issues. In fact, they're both on my personal TODO list (along with some other fun stuff, like SSR). I have no doubt I could vibe code them both away, and at some point, I will. I've done plenty harder things. I haven't yet, because I was focusing on stuff that my moderators and users wanted me to do. They wanted features to ban users, a forgot password feature, email notifications, mobile support, dark mode, and a couple of other moderation tools. I added those. No one complained about FOUC or the waterfall, and no one said that the site loaded slowly, so I didn't prioritize those issues.
I understand you think your cited issues are important. To be honest, they irk me, too. But no one who actually uses the site mentioned them. So, when forced to prioritize, I added stuff they cared about instead.
> You can't argue from professional authority that AI makes you more productive without compromise, use your work as proof, and then retreat to "it's just for fun" when someone points out the quality issues
You seem to have missed the point of saying "it's just for fun". My point was this: You are holding a week-long project done with AI to professional standards. Nothing ever done in a week is going to be professional level! That is an absurd standard! You are pointing at the rough edges, that of course exist because it was done on the side, as some insane gotcha that proves the whole thing is a house of cards. "This is "dull work"! You should "have done better work" if you wanted to talk with us"! For FOUC?!? C'mon.
And if it's producing an intern-level artifact for your frontend, what's to say it's not producing similar quality code for everything else? Especially considering frontend is often derided as being easier than other fields of software.
The site looks great to me. Your comment is actually offensive, despite you typing "no offence".
The combination of which, deep training dataset + maps well to how AI "understands" code, it can be a real enabler. I've done it myself. All I've done with some projects is write tests, point Claude at the tests and ask it to write code till those tests pass, then audit said code, make adjustments as required, and ship.
That has worked well and sped up development of straightforward (sometimes I'd argue trivial) situations.
Where it falls down is complex problem sets, major refactors that cross cut multiple interdependent pieces of code, its less robust with less popular languages (we have a particular set of business logic in Rust due to its sensitive nature and need for speed, it does a not great job with that) and a host of other areas I have hit limitations with it.
Granted, I work in a fairly specialized way and deal with alot of business logic / rules rather than boiler plate CRUD, but I have hit walls on things like massive refactors in large codebases (50K is small to me, for reference)
You are stuck in a very low local maximum.
You are me six months ago. You don’t know how it works, so you cannot yet reason about it. Unlike me, you’ve decided “all these other people who say it’s effective are making it up”. Instead ask, how does it work? What am I missing.
Every time I try to use AI it produces endless code that I would never have written. I’ve tried updating my instructions to use established dependencies when possible but it seems completely averse.
An argument could be made that a million lines isn’t a problem now that these machines can consume and keep all the context in memory — maybe machines producing concise code is asking for faster horses.
When people say coding is slow, that usually means they're working on some atrocious code (often of their own making), while using none of the tools for fast feedback (Tests, Linters,...).
This hits the nail on the head, IMO. I haven't seen any of the replies address this yet, unless I missed one.
I don't even like AI per se, but many of the replies to this comment (and to this sentiment in general) are ridiculous. Ignoring the ones that are just insulting your work even though you admitted off the bat you're not an "advanced" programmer... There are obviously flaws with AI coding (maintainability, subtle bugs, skill atrophy, electricity usage, etc). But why do we all spring immediately to this gaslighting-esque "no, your personal experience is actually wrong, you imagined it all?" Come on guys, we should be better than that.
1. Most of these companies are AI companies & would want to say that to promote whatever tool they're building
2. Selection b/c YC is looking to fund companies embracing AI
3. Building a greenfield project with AI to the quality of what you need to be a YC-backed company isn't particularly "world-class"
3. You are absolutely right. New startups have greenfield projects that are in-distribution for AI. This gives them faster iteration speed. This means new companies have a structural advantage over older companies, and I expect them to grow faster than tech startups that don’t do this.
Plenty of legacy codebases will stick around, for the same reasons they always do: once you’ve solved a problem, the worst thing you can do is rewrite your solution to a new architecture with a better devex. My prediction: if you want to keep the code writing and office culture of the 2010s, get a job internally at cloud computing companies (AWS, GCP, etc). High reliability systems have less to gain from iteration speed. That’s why airlines and banks maintain their mainframes.
"4.1. Generally. Customer and Customer’s End Users may provide Input and receive Output. As between Customer and OpenAI, to the extent permitted by applicable law, Customer: (a) retains all ownership rights in Input; and (b) owns all Output. OpenAI hereby assigns to Customer all OpenAI’s right, title, and interest, if any, in and to Output."
It wouldn't be OpenAI holding copyright - it would be no one holding copyright.
Can you replay all of your prompts exactly the way you wrote them and get the same behaviour out of the LLM generated code? In that case, the situation might be similar. If you're prodding an LLM to give you a variety of resu
But significantly editing LLM generated code _should_ make it your copyright again, I believe. Hard to say when this hasn't really been tested in the courts yet, to my knowledge.
The most interesting question, to me, is who cares? If we reach a point where highly valuable software is largely vibe coded, what do I get out of a lack of copyright protection? I could likely write down the behaviour of the system and generate a fairly similar one. And how would I even be able to tell, without insider knowledge, what percentage of a code base is generated?
There are some interesting abuses of copyright law that would become more vulnerable. I was once involved in a case where the court decided that hiding a website's "disable your ad blocker or leave" popup was actually a case of "circumventing effective copyright protection". In this day and age, they might have had to produce proof that it was, indeed, copyright protected.
That said, you don't necessarily always have 100% deterministic build when compiling code either.
So in my understanding (not as a lawyer, but someone who's had to deal with legal issues around software a lot), if you _save_ all the inputs that will lead to the LLM creating pretty much the same system with the same behaviour, you could probably argue that it's a derivative work of your input (which is creative work done by a human), and therefore copyright protected.
If you don't keep your input, it's harder to argue because you can't prove your authorship.
It probably comes down to the details. Is your prompt "make me some kind of blog", that's probably too trivial and unspecific to benefit from copyright protection. If you specify requirements to the degree where they resemble code in natural language (minus boilerplate), different story, I think.
(I meant to include more concrete logic in my post above, but it appears I'm not too good with the edit function, I garbled it :P)
Public domain in, public domain out.
Copyright'd in, copyright out. Your compiled code is subject to your copyright.
You need "significant" changes to PD to make it yours again. Because LLMs are predicated on massive public data use, they require the output to PD. Otherwise you'd be violating the copyright of the learning data - hundreds of thousands of individuals.
If the prompt makes the output a derivative, then the rest is also derivative.
https://www.legalzoom.com/articles/what-are-derivative-works...
If the input has copyright, so does the output.
If the input does not, then neither does the output.
A prompt is not enough to somehow claim artistry, because the weights have a greater influence. You cannot separate the sum of the parts.
Courts have decided they're new works which are not copyrightable.
Patent trolls will extort you: the trolls will be using AI models to find "infringing" software, and then they'll strike.
¡There's no way AI can be cleanroom!
I wrote 4000 lines of Rust code with Codex - a high throughput websocket data collector.
Spoiler: I do not know Rust at all. I discussed possible architectures with GPT/Gemini/Grok (sync/async, data flow, storage options, ...), refined a design and then it was all implemented with agents.
Works perfectly, no bugs.
I am personally progressing to a point where I wonder if it even matters what the code looks like if it passes functional and unit tests. Do patterns matter if humans are not going to write and edit the code? Maybe sometimes. Maybe not other times.
Well, except developers have never had to worry about code as even in the pre-compiler days coders, a different job done by a different person, were responsible for producing the code. Development has always been about writing down what you want and letting someone or something else generate the code for you.
But the transition from human coders to AI coders happened like, what, 60-70 years ago? Not sure why this is considered newsworthy now.
Is that not your understanding of how compilers work? If a compiler does not work like that, what do you think a complier does instead?
Let's get this topic back on track. What is it that you think a compiler does if not take in what you typed out for what you want and use that to generate code?
That difference - and the assumed delta in difficulty, training and therefore cost involved - is why the latter case is newsworthy.
When has a semantic "argument" ever felt like good faith? All it can ever be is someone choosing what a term means to them and try to beat down others until they adopt the same meaning. Which will never happen because nobody really cares.
They are hilarious, but pointless. You know that going into it.
It seems you're trying to call anything that transforms one thing into another a compiler. We all know what a compiler is and what it does (except maybe you? It's not clear to me) so I genuinely don't understand why you're trying to overload this terminology further so that you can call LLMs compilers. They are obviously and fundamentally different things even if an LLM can do its best to pretend to be one. Is a natural language translation program a compiler?
We have always agreed that a natural language compiler is theoretically possible. Is a natural language translation program the same as a natural language compiler, or do you see some kind of difference? If so, what is the difference?
No. Nobody here except you agrees with this. The distinction between natural languages and formal languages exists for a reason.
citation? source? Who is we?
They are if you define them as such. But there is already a silly semantic thread going on if that's what you are looking for.
> and code in high-level languages is still code in the proper sense.
Sure. As is natural language (e.g. criminal code).
> It is highly dishonest to call someone who is not a competent software engineer a "developer" even if their job consists entirely of telling actual software engineers or "coders" what to do.
Okay. But coders, as spoken of earlier, were not software engineers. They were human compilers. They took the higher level instructions written by the software engineers and translated that into machine code. Hence the name. Developer in the above referred to what you call software engineer. It seems your misinterpretation is down to thinking that software engineer and coder were intended to be the same person. That was not the intent. Once the job of coding went away it has become common to use those terms synonymously, but the above was clearly written about the past.
Again, if you're looking for a silly semantic discussion, there is already another thread for that.
If a compiler counts as AI then so does literally every other program out there (at least the ones with well-defined inputs and outputs).
>Sure. As is natural language (e.g. criminal code).
Natural language is too ambiguous and self-referential to count as a programming language, per se. While a subset of natural language can obviously be used to describe programs, we distinguish programming languages from natural languages in that they are formally defined and bound to be interpreted in one way by a machine with a relatively small amount of context (notwithstanding minor differences between implementations). Natural language has the unfortunate property of semantic drift (or whatever it's called). The sounds, spellings, meanings of words, etc. are extremely context-sensitive and unsuitable for reliably encoding computer programs or anything else over long periods of time. It is very common for a single word in a natural language to have several meanings, even contradictory meanings.
>They took the higher level instructions written by the software engineers and translated that into machine code. Hence the name. Developer in the above referred to what you call software engineer.
I am well aware of what you're trying to say, and the historical context, but I think you're applying modern terminology to old practices to draw a bad conclusion.
>It seems your misinterpretation is down to thinking that software engineer and coder were intended to be the same person. That was not the intent.
I didn't misinterpret anything. These jobs were not "intended" into existence. It just so happens that writing any kind of code is challenging enough to require its own dedicated professionals. That has always been true.
>Once the job of coding went away it has become common to use those terms synonymously, but the above was clearly written about the past.
The job of "coding" never went away. The type of code being written changed. The product is still CODE as in a procedure or specification encoded in a purpose-built, machine-oriented, unambiguous, socially neutral, and essentially eternal language.
>Again, if you're looking for a silly semantic discussion, there is already another thread for that.
It's not a silly semantic discussion, it's a serious one. You think that one can be a "software developer" merely by using natural language, and that there is historical precedent for that. But this is very wrong, especially in the historical context. By your own argument, any dumbass manager could be a "software developer" if only he found an entity to write the software for him based on natural language instructions. It matters not whether the entity generating the actual code is a human being or a machine. Since there are actual people trying to hire software developers and engineers with real skills, it is a waste of everyone's time for vibecoders to call themselves "software engineers" or "software developers" because they're not. They are JUST vibecoders. That skill set may be sufficient for... something. But stop trying to make it into something it isn't with these misleading arguments and analogies.
It is slightly hilarious that this entire "silly semantic discussion" is a product of the properties of natural language. One of the massive benefits of computer languages is that you DON'T get into stupid discussions about the meanings of things very often. When you DO, it is usually because some goofball wrote a bad spec. The ambiguities and other nonsense are hammered out in the spec, and from there on the language has a concrete meaning that is not up for debate.
You seem to be missing some context. We were talking about a system that takes a typed description of what you want as input and outputs code. There is plenty of software, even with well-defined inputs and outputs, which do not do that.
But there is a particular type of software that does exactly that. We call it a compiler in my circles. Maybe you do not in your circles, but it doesn't really matter as it was I who wrote "compiler". It was written to express my intent. Your (mis)interpretation does nothing to change my intent and is, frankly, irrelevant.
You are trying to assert an equivalence between compilers and AI systems that simply does not exist. Sure, you could abuse the English language to try to elevate "vibecoding" to the level of "software engineering", and denegrate the AI to the level of a basic compiler. But the rest of us know better and won't accept that. Your line of reasoning about historical job titles and roles also fails.
>But there is a particular type of software that does exactly that. We call it a compiler in my circles.
Compilers don't take "descriptions" as input. They take code as input. The output is perhaps a different kind of code, but it is still code. There has never really been a software engineer or developer who wrote only imprecise English. You don't legitimately get those titles without being competent at using some kind of programming language (as opposed to natural language).
>It was written to express my intent. Your (mis)interpretation does nothing to change my intent and is, frankly, irrelevant.
This is exactly why natural language is unsuitable for writing software. People like you constantly try to abuse the meaning of words to manipulate people. No amount of rhetoric is going to make a vibecoder actually be a software developer or software engineer. Even if you get people to debase the English language, they'll be forced to come up with new words to describe what they actually mean when they speak of morons using AI vs people who actually know what they are doing. I hate how much time is wasted in arguments over what is a reasonable use of words and why it is not good to constantly change the meanings of words.
I'm done with this conversation. I think you're just trolling us at this point. I've made my point and I'm done beating a dead horse.
The equivalence is between typing out what you want and having a machine produce code from that and compilers. Call that "AI systems" instead of "compilers" if you want, but "AI systems" lacks precision, so I think we can eventually come to agree that compiler is more precise. Even if we don't, it is what I chose to call it. Therefore, that's what it means in the context of my comments. That is how English works. I am surprised this is news to you.
> I'm done with this conversation.
I know you like silly semantic debates, so is talking past everyone really a conversation? The dictionary definition indicates that there needs to be an exchange, not just taking turns writing out gobbledygook.
>The equivalence is between typing out what you want and having a machine produce code from that and compilers. Call that "AI systems" instead of "compilers" if you want, but "AI systems" lacks precision, so I think we can eventually come to agree that compiler is more precise.
You are trying to assert this equivalence to ultimately assert a similar equivalence between vibecoding and software engineering. I'm not going to accept that. The analogy is about as bizarre as calling a compiler a search program. You could indeed call it that: You tell it what you are looking for, and it does something to find the matching output out of infinitely many possible outputs. But this is just as strained of an analogy. The mechanics of how each of these things works is sufficiently complex and distinct as to deserve dedicated terminology. Nothing is gained by drawing these connections, that is unless you are going to commit fraud.
>Even if we don't, it is what I chose to call it. Therefore, that's what it means in the context of my comments. That is how English works. I am surprised this is news to you.
It is not. I said it works that way in multiple comments to you. This type of shit is, as I said, exactly why natural language is a bad category of input for writing software.
>I know you like silly semantic debates, so is talking past everyone really a conversation? The dictionary definition indicates that there needs to be an exchange, not just taking turns writing out gobbledygook.
First you want to manipulate the definition of "software developer" to elevate vibecoding (the socially and industrially acceptable definition) to the same level. When I disagree with you in a series of comments, you want to redefine "conversation" to mean something else and also call my thoroughly explained rationale "gobbledygook". What you're writing isn't exactly gobbledygook, though I could easily call it that and move on. What it is is simply an incorrect argument in favor of destroying the meanings of certain well-established words. You are simply wrong from multiple angles: historical, logical, and social. We are all dumber for having heard it. You LOSE!
I don't know what vibecoding is, but from past context and your arbitrary thoughts about about using natural language for writing software that came from out the blue, I am going to guess that you are referring to the aforementioned talk about criminal code. That is the only time we said anything about natural language previously. That should have been obviously seen as a tangent, but since it appears you didn't pick up on that, what do you think criminal code and software have to do with each other?
As we both know, the AI we are talking about uses natural language as input. To address the ridiculous connections you are trying to make, I am forced to distinguish natural languages from programming languages. You might like to overlook the vast differences between programming languages and natural languages to try to support your point. But those differences are major supporting details in my arguments. You can call this additional information "getting off on a tangent" to try to throw shade on me, but you're wrong.
>what do you think criminal code and software have to do with each other?
I'm not the one that brought this up, you did. I think that although criminal law is written in a largely procedural way, there are many differences between criminal law and writing software. I would not call a law maker a "software engineer" even though both are concerned with writing procedures of some kind. The critical distinctions are that law is written in natural language and is malleable according to social factors, regardless of what it literally says. Even if we build actual machines to enforce the law and programmed them in plain English or even a programming language built for it, interpretation of the law would still necessarily be subject to social factors.
Those same differences between, say, law written in natural language and computer programs written in code, apply to practically all natural language input given to an AI or a software engineer versus actual code that a compiler or interpreter can process. Therefore, uninformed people who use AI to generate code are not "software developers" and the AI is not a "compiler". No natural language is a programming language.
And now we have come full circle. No historical or logical rationale can justify redefining "software developer" or "software engineer" to include someone who has no knowledge of computer programming in the pre-AI sense.
I'm old. I don't keep up with the kids. Maybe the kids have changed what a compiler is too. Is that the point of contention here? If so, that's pretty silly. When I write "compiler" it means what I mean it to mean, not what some arbitrary kid I've never met thinks it means. How can someone use a word in a way that they don't even know exists?
> As we both know, the AI we are talking about uses natural language as input.
That is not what I am talking about. Did you press the wrong reply button? That would explain your deep confusion.
No, this all started because you asserted that compilers are equivalent to AI. Being old is not really an excuse for pulling the rhetorical stunts you've been pulling like calling someone you've never met an "arbitrary kid"... As a matter of fact, I'm old too.
This is where I started replying to you, I think:
>It's not exactly wrong. Not since the advent of AI systems (a.k.a. compilers) have developers had to worry about code. Instead they type in what they want and the compiler generates the code for them. > >Well, except developers have never had to worry about code as even in the pre-compiler days coders, a different job done by a different person, were responsible for producing the code. Development has always been about writing down what you want and letting someone or something else generate the code for you. > >But the transition from human coders to AI coders happened like, what, 60-70 years ago? Not sure why this is considered newsworthy now.
There are multiple issues with this comment that I have outlined in my other comments. It is so wrong, like all your other replies to me, that I think you're trolling me.
>That is not what I am talking about. Did you press the wrong reply button? That would explain your deep confusion.
This whole thread and the post itself is very much about what AI is and how it's used.
I asserted that typing in what you want and feeding it into something that outputs code is that something being a compiler. Call that AI if you want, but I've always known that to be a compiler. Again, I'm old, so maybe terms are changing and I'm not in touch with that. I don't know. I'm not sure I care. Logically, "compiler" when used in my writings means what I intend it to mean. It makes no difference what others think it means.
Compilers are not equivalent to AI as, at least in my day, AI is a field of computer science, not any specific type of tool. But compilers are typically designed as rule-based “expert systems”, which traditionally has fallen under the AI umbrella. Well, unless you are in the "its only AI if I don't understand it" camp. In which case nothing is AI in any meaningful sense.
Not that it matters as "compiler" always used to refer to the functionality, not how it is implemented. If you built a C compiler that used neural nets, it would still be a compiler. If you built a C compiler based on mechanical turk it would still be a compiler. We call(ed) it a compiler because of what it does, not how it works beneath the sheets.
> There are multiple issues with this comment that I have outlined in my other comments.
It seems you found multiple issues based on the false premise of "typing in what you want" referring to natural language, but I wasn't talking about natural language. I was talking about programming languages. That is what you do with programming languages: You type in what you want, pass it to a compiler, and it generates code.
Not sure it's a wild speculative claim. Claiming someone had achieved FTL travel would fall into that category. I'd call it more along the lines of exaggerated.
I'll make the assumption that what I do is "advanced" (not React todo apps: Rust, Golang, distributed systems, network protocols...) and if so then I think: it's pretty much accurate.
That said, this is only over the past few moths. For the first few years of LLM-dom I spent my time learning how they worked and thinking about the implications for understanding of how human thinking works. I didn't use them except to experiment. I thought my colleagues who were talking in 2022 about how they had ChatGPT write their tests were out of their tiny minds. I heard stories about how the LLM hallucinated API calls that didn't exist. Then I spent a couple of years in a place with no easy code and nobody in my sphere using LLMs. But then around six months ago I began working with people who were using LLMs (mostly Claude) to write quite advanced code so I did a "wait what??..." about-face and began trying to use it myself. What I found so far is that it's quite a bit better than I am at various unexpected kinds of tasks (finding bugs, analyzing large bodies of code then writing documentation on how it works, looking for security vulnerabilities in code) or at least it's much faster. I also found that there's a whole art to "LLM Whispering" -- how to talk to it to get it to do what you want. Much like with humans, but it doesn't try to cut corners nor use oddball tech that it wants on its resume.
Anyway, YMMV, but I'd say the statement is not entirely false, and surely will be entirely true within a few years.