becausecurious's Shortform

becausecurious

becausecurious's Shortform — LessWrong

becausecurious's Shortform

28th Mar 2026

1 min read

2

This is a special post for quick takes by becausecurious. Only they can create top-level comments. Comments here also appear on the Quick Takes page and All Posts page.

becausecurious's Shortform

5 comments, sorted by

top scoring

Click to highlight new comments since: Today at 12:41 AM

[-]becausecurious6mo91

I am trying to resolve the paradox around Claude Code. On the one hand it definitely speeds up many smallish tasks - it often implements stuff in 1-2 minutes, which would normally take me 30-60 min. On the other hand, I don't see this speed up in the macro sense. So far my best hypothesis is Jevons Paradox. Without Claude Code I knew that work takes me substantial time, so I was incentivized to prioritize. As a result I was doing just the core required work. With Claude Code any small idea I have feels cheap - I can just tell Claude to do it, but it ends up not being cheap. First, it often does require multiple iterations and I ultimately have to review the result. Second, it adds complexity to the system, making AI agents less efficient long-term; it also increases the surface area of something going wrong. Third, it increases context switching.

[-]silentbob6mo60

Two more points I'd add:

Diminishing returns in code produced. When code production is limited, one naturally works only on those pieces of code that are most useful. But if you can create 10x more code, you likely don't reap 10x the benefits. I notice this a lot in private projects, I just quickly run out of ideas of what to even code because finding anything that has more value than the time it would even take to prompt it becomes non-trivial relatively quickly. Maybe somewhat of a skill issue, but I this effect will always be present to some degree.
Code doesn't live in isolation. It often requires changes outside of the code to go along with it. So, often you can't just speedrun the code to its final form, but many things around it are keeping it in place to some degree, or have to slowly advance alongside the code. Things like user expectations & knowledge, deployment, code in other projects that may depend on it and are outside of your control, general project planning / decisions, and so on. It reminds me of my observation about parameter updates during gradient descent here:

While most parameters have "settled down" after the first few hundred epochs, clearly some of them are still on a mission, though. I was also a bit surprised how smoothly many of them are moving. [...] many parameters are systematically drifting into one direction, albeit now in a more noisy fashion. It gives me "just update all the way bro!" vibes - but perhaps this is a bit of a coordination problem: multiple parameters have to move more or less in unison, and none of them can reasonably update further even though the longer term trajectory is clear.

[-]Viliam5mo52

Yeah. I vibecoded a few games, the new bottleneck was editing levels. I also vibecoded a level editor, the new bottleneck was coming up with good ideas for the levels.

[-]silentbob6mo62

Some related observations I've made over the last months:

most new projects start out fast and easy with simple prompts leading to swift progress; but after a few iterations, I usually end up in situations where just explaining my ideas for the next marginal improvement becomes more and more time-consuming, and then many projects usually stall, as even with vibe-coding I reach that point where investing the effort to think about & explain the next steps becomes so complex it's not worth it, given the expected payoffs (this, of course, depends greatly on the project; if it's a product that thousands or millions of people use, the equation is different than if it's just some gimmick for personal use)
back when I actually wrote code, there was kind of two-way communication between "product level" and "code level" - sometimes, certain abstractions in the code just made it very worthwhile to add certain features that otherwise maybe wouldn't have occurred to me. This "code -> product" communication channel almost entirely disappeared now. I'm not sure how important this is, but it certainly makes me a little sad, because these "oh I can write the code in this way and then this opens all kinds of doors and naturally allows us to do X!" moments used to be very nice.
Even a few years ago, in my software job I think I spent maybe ~40%, often less, on actual coding tasks, and the rest was happening somewhere outside of my IDE. While some of these other tasks can be done via Claude Code as well via MCPs, that hasn't had a big impact yet on most of my activities. So, while the 40% of my prior work are now sped up by some considerable factor, much of the rest is still just as slow as before.
Other activities indeed have become somewhat more than before, because other people are using Claude Code as well and increase their output. If more happens in my organization, then more coordination is needed. To some degree that's code reviews (although this is somewhat sped up by AI tools as well), but also just the process of having to refine & understand more tickets if we are working through them more quickly.
I suspect that some of that coordination is less efficient than before, because our developers have a less well-rounded theory of the code now, meaning they're less quick to provide informed judgment on the fly. I don't have much evidence of this besides personally having this impression of myself and having a reasonably strong prior that many others will have a similar experience.

[-]FlorianH6mo10

CC does speed my coding up on absolute net level, but indeed, in addition to a first step of crazy speedup gain, there's a second, countering effect:

CC makes 10-fold* speed gain with first elements in a new project
As because of CC I'm not as fully intimate with my code, over time, as project code grows, not knowing all of the code so well inside-out, this lack of close familiarity with the code base reduces efficiency in growing, debugging and communicating about the code. Eventually reducing overall speed anything from 2-5 fold*

*Numbers wholly made up; I cannot quantitatively pin down the effect; it depends too much on specifics

Moderation Log

More from becausecurious

Curated and popular this week

5Comments

5 comments, sorted by

top scoring

Click to highlight new comments since: Today at 12:41 AM

[-]becausecurious6mo91

[-]silentbob6mo60

Two more points I'd add:

Diminishing returns in code produced. When code production is limited, one naturally works only on those pieces of code that are most useful. But if you can create 10x more code, you likely don't reap 10x the benefits. I notice this a lot in private projects, I just quickly run out of ideas of what to even code because finding anything that has more value than the time it would even take to prompt it becomes non-trivial relatively quickly. Maybe somewhat of a skill issue, but I this effect will always be present to some degree.
Code doesn't live in isolation. It often requires changes outside of the code to go along with it. So, often you can't just speedrun the code to its final form, but many things around it are keeping it in place to some degree, or have to slowly advance alongside the code. Things like user expectations & knowledge, deployment, code in other projects that may depend on it and are outside of your control, general project planning / decisions, and so on. It reminds me of my observation about parameter updates during gradient descent here:

While most parameters have "settled down" after the first few hundred epochs, clearly some of them are still on a mission, though. I was also a bit surprised how smoothly many of them are moving. [...] many parameters are systematically drifting into one direction, albeit now in a more noisy fashion. It gives me "just update all the way bro!" vibes - but perhaps this is a bit of a coordination problem: multiple parameters have to move more or less in unison, and none of them can reasonably update further even though the longer term trajectory is clear.

[-]Viliam5mo52

Yeah. I vibecoded a few games, the new bottleneck was editing levels. I also vibecoded a level editor, the new bottleneck was coming up with good ideas for the levels.

[-]silentbob6mo62

Some related observations I've made over the last months:

most new projects start out fast and easy with simple prompts leading to swift progress; but after a few iterations, I usually end up in situations where just explaining my ideas for the next marginal improvement becomes more and more time-consuming, and then many projects usually stall, as even with vibe-coding I reach that point where investing the effort to think about & explain the next steps becomes so complex it's not worth it, given the expected payoffs (this, of course, depends greatly on the project; if it's a product that thousands or millions of people use, the equation is different than if it's just some gimmick for personal use)
back when I actually wrote code, there was kind of two-way communication between "product level" and "code level" - sometimes, certain abstractions in the code just made it very worthwhile to add certain features that otherwise maybe wouldn't have occurred to me. This "code -> product" communication channel almost entirely disappeared now. I'm not sure how important this is, but it certainly makes me a little sad, because these "oh I can write the code in this way and then this opens all kinds of doors and naturally allows us to do X!" moments used to be very nice.
Even a few years ago, in my software job I think I spent maybe ~40%, often less, on actual coding tasks, and the rest was happening somewhere outside of my IDE. While some of these other tasks can be done via Claude Code as well via MCPs, that hasn't had a big impact yet on most of my activities. So, while the 40% of my prior work are now sped up by some considerable factor, much of the rest is still just as slow as before.
Other activities indeed have become somewhat more than before, because other people are using Claude Code as well and increase their output. If more happens in my organization, then more coordination is needed. To some degree that's code reviews (although this is somewhat sped up by AI tools as well), but also just the process of having to refine & understand more tickets if we are working through them more quickly.
I suspect that some of that coordination is less efficient than before, because our developers have a less well-rounded theory of the code now, meaning they're less quick to provide informed judgment on the fly. I don't have much evidence of this besides personally having this impression of myself and having a reasonably strong prior that many others will have a similar experience.

[-]FlorianH6mo10

CC does speed my coding up on absolute net level, but indeed, in addition to a first step of crazy speedup gain, there's a second, countering effect:

CC makes 10-fold* speed gain with first elements in a new project
As because of CC I'm not as fully intimate with my code, over time, as project code grows, not knowing all of the code so well inside-out, this lack of close familiarity with the code base reduces efficiency in growing, debugging and communicating about the code. Eventually reducing overall speed anything from 2-5 fold*

*Numbers wholly made up; I cannot quantitatively pin down the effect; it depends too much on specifics

Moderation Log