[7777777phil]

If you look at the survey it's not only about productivity it's also about usage, model choice etc. But I agree with you self reported productivity gains is to be taken with a grain of salt. But then what else would you propose? The goal is to not only rely on benchmarks for model performance but develop some kind of TIOBE Index for LLMs.

[direwolf20]

The ever-present rebuttal to all LLM failure anecdotes: you're using the wrong model, you're prompting it wrong, etc. All failures are always the user's fault. It couldn't possibly be that the tool is bad.

[peteforde]

Of course, your logic could also be equally allied to the opposite position.

Quite a few of us are tired of being told that we're imagining doing what used to take weeks multiple times in an evening.

[anonymous908213]

If it generated something that saved you weeks, I think it's almost certainly because it was used for something you have absolutely zero domain understanding for and would have had to study from scratch. And I, at least, repeatedly do note that LLMs lower the barrier to entry for making proof-of-concepts. But the problem is that (1) people treat that instant gratification as a form of productivity that can replace software engineers. At most, it can make something extremely rough that is suited to one individual's very specific use case, where you mostly work around the plentiful bugs by knowing the landmines are there and not doing the behaviour that trips them; and (2) people spam these low-effort proof-of-concepts, which have no value to other people on account of how rough and lacking in ability to be extended to cover more than one person's use case they are, and this drowns out the content people actually put effort into.

LLMs, when used like this, do not increase productivity on making software worth sharing with other people. While they can knock out the proof-of-concept, they cannot build it into something valuable to anyone but the prompter, and by shortcircuiting the learning process, you do not learn the skills necessary to build upon the domain yourself, meaning you still have to spend weeks learning those skills if you actually want to build something meaningful. At least this is true for everything I have observed out of the vibe-coding bubble thus far, and my own extensive experiences trying to discover the 10x boost I am told exists. I am open to being shown something genuinely great that an LLM generated in an evening if you wish to share evidence to the contrary.

There is also the question of the provenance of the code, of course. Could you have saved those weeks by simply using a library? Is the LLM saving you weeks by writing the library ""from scratch"", in actuality regurgitating code from an existing library one prompt at a time? If the LLM's productivity gain is that it normalized copying and pasting open-source code wholesale while calling it your own, I don't think that's the great advancement for humanity it is portrayed as.

[peteforde]

I find your persistent, willful bullheadedness on this topic to be exhausting. I'd say delusional, but I don't know you and you're anonymous so I'm probably arguing with an LLM in someone's sick social experiment.

A few weeks ago I brought up a new IPS display panel that I've had custom made for my next product. It's a variant of the ST7789. I gave Opus 4.5 the registers and it produced wrapper functions that I could pass to LVGL in a few minutes, requiring three prompts.

This is just one of countless examples where I've basically stopped using libraries for anything that isn't LVGL, TinyUSB, compression or cryptography. The purpose built wrappers Opus can make are much smaller, often a bit faster, and perhaps most significantly not encumbered with the mental model of another developer's assumptions about how people should use their library. Instead of a kitchen sink API, I/we/it created concise functions that map 1:1 to what I need them to do.

I happen to believe that you're foolish for endlessly repeating the same blather about "vibe coding" instead of celebrating how amazing what you yourself said about lowering the barrier to entry for domains that are extremely rough and outside of their immediate skillset actually is and the incredible impact it has on project trajectory, motivation and skill-stacking for future projects.

Your [projected] assumption that everyone using these tools learns nothing from seeing how problems can be solved is painfully narrow-minded, especially given than anyone with a shred of intellectual curiosity quickly finds that they can get up to speed on topics that previously seemed daunting to impossible. Yes, I really do believe that you have to expend effort to not experience this.

During the last few weeks I've built a series of increasingly sophisticated multi-stage audio amplifier circuits after literal decades of being quietly intimidated by audio circuits, all because I have the ability to endlessly pepper ChatGPT with questions. I've gone from not understanding at all to fully grasping the purpose and function of every node to a degree that I could probably start to make my own hybrids. I don't know if you do electronics, but the disposition of most audio electronics types does not lend itself to hours of questions about op-amps.

Where do we agree? I strongly agree that people are wasting our time when they post low-effort slop. I think that easy access to LLMs shines a mirror on the awkward lack of creativity and good, original ideas that too many people clearly [don't] have. And my own hot take is that I think Claude Code is unserious. I don't think it's responsible or even particularly compelling to get excited about making never looking at the code as a goal.

I've used Cursor to build a 550k+ LoC FreeRTOS embedded app over the past six months that spans 45 distinct components which communicate via a custom message bus and event queue, juggling streams from USB, UART, half a dozen sensors, a high speed SPI display. It is well-tested, fully specified and the product of about 700 distinct feature implementation plan -> chat -> debug loops. It is downright obnoxious reading the stuff you declare when you're clearly either doing it wrong or, well, confirmation of the dead internet theory.

I honestly don't know which is worse.