The way I see it you should calibrate the way you work with LLMs based on how confident you are on that specific area, and if it's your responsibility to own/understand it. Here's how it feels for me:
* Learning stage: 0.5x - 1x. I change my system prompt to teacher mode, taking the productivity hit for actually learning the system/tool pays off dividends later. I change my system prompt to "teacher mode" and slowly loosen it as I get more confident.
* Working-knowledge: 2x - 3x. Once I am ramped up enough I feel like I can get a decent productivity boost. Most of the time is spent at the planning stage. This is my mode for areas I don't really own or care about, just need to get work done.
* Mastered: 10x+ I have been doing web front end for 12+ years, I can quickly review plan/implementations and for my initial prompt I already know most of what I want built.
1x == my speed before AI
gashad 22 minutes ago [-]
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 argument was that agentic coding speeds up that coding part a bunch. So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.
whateveracct 15 minutes ago [-]
> So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.
Amdahl's Law should be familiar to anyone with a 4y computer science/engineering degree. Why aren't they applying it to their own throughput?
steveBK123 12 minutes ago [-]
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 examples of this.
leoedin 7 minutes ago [-]
The quality of my bash scripts is 100x what they used to be. Proper help messages, flag parsing, functions, internal variables, using sed all the time (I could never wrap my head around that).
Of course, the main issue is that they’re completely undebbugable now. My bash scripts used to be a sequential list of commands, now they’re 500 lines of variable laden functions.
Is my life any better? Dunno. But it’s satisfying (until there’s a bug)
nasretdinov 1 minutes ago [-]
> the main issue is that they’re completely undebbugable now
Well, that means the quality actually dropped then :). Looking impressive isn't equal to quality, understandability and reliability is
deergomoo 21 minutes ago [-]
> As for documentation, I've found this simple instruction to vastly improve LLMs' output:
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
This is quite validating as I came to the exact same conclusion myself. We’re required to use an LLM for every task at work that touches code†, and I was really struggling to get Claude to stop with the long waffly comments that reiterate the next few lines of code in 3x as many characters, making contextless references to subtasks in whatever harness du jour we’re using this week.
No amount of examples or explanation of what I wanted would make it stop. And then I realised of course, I’m asking something which has no concept of meaning (or, indeed, anything) to only add meaningful comments. More fool me I guess.
Of course, it’s ultimately pointless given all of my colleagues are regularly opening PRs with more comments than code anyway. 80% of my code review responses these days are just increasingly exasperated “pointless comment, please remove”.
† This is just as infantilising as it sounds, by the way
sync 9 minutes ago [-]
You can create a PostToolUse hook [0] which will automatically chastise Claude to shrink comments to one line. It's not perfect but better than the sea of prose it tends to generate by default. Bonus is that it would apply to your colleagues as well!
> We’re required to use an LLM for every task at work that touches code
Why not just write the code in the prompt so LLM can paste it.
troupo 4 minutes ago [-]
> Never write READMEs, docstrings, or comments.
I found that latest codes don't write comments in code by default. And when they do, they write stupid shit like "This was code that did X, it was now removed".
You have to explcitly prompt them to write comments in code. They are still useful for you, the user. But are arguably useful for the model, too, given how many of them (especially Claude) only reads small chunks of files. So I'd rather have code comments than it reproducing a picture from incomplete data.
imoverclocked 5 minutes ago [-]
... the official return of pair programming! The best part: LLM's save you from having to argue with a human. Added bonus: now you get to master two tools instead of one.
iLoveOncall 26 minutes ago [-]
Even this is overstating it IMO.
I already convert from multipliers to percentage of increase, so when someone claims 10x they very likely mean +100% productivity, and here 2x means +20% productivity, which seems about right. Nobody that was normally productive before LLMs has suddenly 10x'ed their output now.
The problem is that 20% productivity when it comes to generating code, really doesn't translate in 20% productivity increase overall, when you take into account the fact that the code quality is worse, the fact that writing code is actually not the majority of your time spent, and that people get burnt out from the usage.
dan_gee 6 minutes ago [-]
[dead]
what_hn 25 minutes ago [-]
Does a 60x speedup count? Are you still copying and pasting from chatgpt, because if so your definitely doing it wrong.
forlorn_mammoth 10 minutes ago [-]
Wait, how about an infinite speedup? A friend of mine couldn't code, and now he can. So he is infinity-x better at coding thanks to LLMS!
Take that, you mere 10x-ers! Your days are toast!
iLoveOncall 23 minutes ago [-]
[flagged]
Rendered at 19:39:42 GMT+0000 (Coordinated Universal Time) with Vercel.
* Learning stage: 0.5x - 1x. I change my system prompt to teacher mode, taking the productivity hit for actually learning the system/tool pays off dividends later. I change my system prompt to "teacher mode" and slowly loosen it as I get more confident.
* Working-knowledge: 2x - 3x. Once I am ramped up enough I feel like I can get a decent productivity boost. Most of the time is spent at the planning stage. This is my mode for areas I don't really own or care about, just need to get work done.
* Mastered: 10x+ I have been doing web front end for 12+ years, I can quickly review plan/implementations and for my initial prompt I already know most of what I want built.
1x == my speed before AI
- 25% planning & aligning with other teams
- 25% coding
- 25% testing/verifying
- 25% code review/rework
One argument was that agentic coding speeds up that coding part a bunch. So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.
Amdahl's Law should be familiar to anyone with a 4y computer science/engineering degree. Why aren't they applying it to their own throughput?
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 examples of this.
Of course, the main issue is that they’re completely undebbugable now. My bash scripts used to be a sequential list of commands, now they’re 500 lines of variable laden functions.
Is my life any better? Dunno. But it’s satisfying (until there’s a bug)
Well, that means the quality actually dropped then :). Looking impressive isn't equal to quality, understandability and reliability is
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
This is quite validating as I came to the exact same conclusion myself. We’re required to use an LLM for every task at work that touches code†, and I was really struggling to get Claude to stop with the long waffly comments that reiterate the next few lines of code in 3x as many characters, making contextless references to subtasks in whatever harness du jour we’re using this week.
No amount of examples or explanation of what I wanted would make it stop. And then I realised of course, I’m asking something which has no concept of meaning (or, indeed, anything) to only add meaningful comments. More fool me I guess.
Of course, it’s ultimately pointless given all of my colleagues are regularly opening PRs with more comments than code anyway. 80% of my code review responses these days are just increasingly exasperated “pointless comment, please remove”.
† This is just as infantilising as it sounds, by the way
[0] https://github.com/chrisvariety/branch-fiction/blob/deb37f2b...
Why not just write the code in the prompt so LLM can paste it.
I found that latest codes don't write comments in code by default. And when they do, they write stupid shit like "This was code that did X, it was now removed".
You have to explcitly prompt them to write comments in code. They are still useful for you, the user. But are arguably useful for the model, too, given how many of them (especially Claude) only reads small chunks of files. So I'd rather have code comments than it reproducing a picture from incomplete data.
I already convert from multipliers to percentage of increase, so when someone claims 10x they very likely mean +100% productivity, and here 2x means +20% productivity, which seems about right. Nobody that was normally productive before LLMs has suddenly 10x'ed their output now.
The problem is that 20% productivity when it comes to generating code, really doesn't translate in 20% productivity increase overall, when you take into account the fact that the code quality is worse, the fact that writing code is actually not the majority of your time spent, and that people get burnt out from the usage.
Take that, you mere 10x-ers! Your days are toast!