> allows me to do things not only faster, but better, and across domains I do not hold expertise on. How would you know it's better when you have no expertise?
Because it produces the desired output. The purpose of a program. There are many domains where an intelligent human can act as a discriminator for output without knowing exactly in precise detail how the process itself works.
Producing the desired output is the purpose of the program, but it's not the only consideration: there's performance, maintainability, security, and so on.
> it produces some extremely crappy code that would've NEVER passed a code review 1 year ago The 10x speed up comes from the fact that we have all given up on properly reviewing each others code and we just say “meh, it will be fine, lgtm”
This reminds me of themes I recently saw in [Harness Engineering is not Enough: Why Software Factories Fail]( https://www.youtube.com/watch?v=Ib5GBkD555M ) (Warning: the last 3 slides seem like an advertisement). One thing I liked is how Dex has a little graphic he glossed over showing software development is - 25% planning & aligning with other teams - 25% coding - 25% testing/verifying - 25% code review/rework One…
The other hard to measure part is that I see/hear a lot of LLM usage going towards dev work that was never prioritized before. Suddenly devs who were cranking out features with no interest in infrastructure are attacking giant refactors to make the code more understandable to the LLM. Other devs are using LLMs to build themselves quality of life SDLC tools completely separate from the core code base. Plenty of other…
llms are 100X for me, but only 10X goes into actual shipping code. the rest is all on doing the dev process the way it actually should be done: incremental POCs, refining specifications, modularization, exhaustive test suites with 95%+ logical unit test coverage, fuzzing unit test coverage, exhaustive e2e testing, with a fuzzer harness over e2e tests for long term simulation and scale testing, bechmark gated self improvement loops for performance optimization, etc. i guarantee you i can ship higher quality 100% llm generated code than any human.
I know, and I'm saying that 2x claims should be interpreted as an actual 20% increase, and 10x claims as an actual 100% increase. People are just bad at estimating their own productivity.
Ya, I feel 10% to 50% increase seems more realistic, when I see 100% to 900% increase claims it seems a bit extrapolated, at least I don't feel I'm seeing it at my work. And then it depends if we imply a given feature/fix/enhancement takes half the time as before, or we imply that we can get twice as many features/fix/enhancements done in the same amount of time as before. Those are not equivalent. I think the latter might be more accurate as to how it helps.
0.25x because I scope bigger now and then I may get a few "free" React components but largely doing all that work of putting it together. Wouldn't trade it though. Feel like I can overall do more with less time and energy. At the end of the day, AI is making me work more (good thing). If you count that as productivity, then sure.
Yes but I’ve seen some devs waste a lot of time using AI to build something that was a bad idea to begin with. Without AI they might have first spent more time validating the idea was worth it.
For me it is exactly the opposite. AI makes it so easy to create test fixtures and run experiments that I now spend much more time validating ideas than I could ever afford to do before. When I write code for production, it's not "this ought to work", it's "here are the figures showing how well this works, on this dataset", where the dataset is also much larger than anything I would have used before, because I used A…
> it's not "this ought to work", it's "here are the figures showing how well this works, on this dataset"
The thing with constraints is that you focus of the thing with high value first. So you focus on the most promising ideas first or choose experiments that can get rid of most ideas. Instead of trying to validate each ideas and generate what is most likely noise to the decision process.
Like if I ever hire an assistant, I want like one to three options that are closely aligned to my needs, not a bible size report on 42 choices.
> The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence). In isolation, instant-abandonware takes up hdd space, burns d…
You made me do a double take with "providence". I think the word you wanted is "provenance", which comes from latin "provenire" (pro -> forth, venire -> come). English has too many similar words. Unless you only run code that's protected by God. That's probably not a bad policy if you can verify it. edit: Oh right, there's an OS for that https://en.wikipedia.org/wiki/TempleOS
We’re at the point where people who talk too fancy get accused of being LLMs, and the people who make human mistakes get scolded for grammar.
While I agree with the premise, I think this angle only applies on work one was going to do no matter what. The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue. So the comparison is not only "built with and without LLM" but "would you even build this if you didn't have the LLM?". The gap in productivity in this case is much more wide.
LLMs open up huge possibilities to do work that you otherwise wouldn't do. I vibe coded a PDF viewer yesterday in a couple of hours using Claude and Grok. I've been itching for a native Mac app that meets some very basic requirements: one window with file tree on the left and tabbed view on the right, with the ability to call out to pdfgrep and jump to results. Like Zotero, but with better multi-file search and a vie…
Cool story bro. I used a llm to help me name a variable.
I'm pretty sure that just a year or two ago, software engineers were saying that coding was only a small part of the job; the rest is meetings, dealing with requirements, design, testing, maintenance. So, how can we expect a 10x boost in a productivity from improving a small part of the job - especially now if we have to clean up any mistakes the LLM makes?