> It's super addicting and gives you an illusion of productivity
Why is it an illusion of productivity if you work faster with it than without it?
> It has never been a competitive advantage to write code fast but writing the right code. If you could also do that fast you are golden.
Who decides whether or not the code is right? You, no?
> The same foundamentals that makes software stable, robust and good haven't changed. Writing software has always been constrained by thinking, design, trade-offs and understanding/mapping real world problems into proper systems.
I don't believe this to be true at all. I believe a significant portion of what writing software has been constrained by is the priority of the work in proportion to the amount of effort to perform the work. Yes, systems thinking also has a place in programming, but it has never been the constraint.
> It's very tempting to replace that flow with automation so you can get some hard earned sleep. But what happens when the agent(s) can't figure out what's wrong. What happens when you have to dig through an ungodly amount of unfamiliar code because you are the one responsible.
Hasn't this always been a possibility when using dependencies that you didn't write. And if anything, AI's "Build It In House" attitude has made debugging deep in the stack a much easier stack than it was when you were debugging someone else's code that's been published on some dependency registry.
> Add to this that these tools are nondeterministic. It was likely the tool that introduced the bug in the first place, how confident are you that it will actually fix the bug.
How confident are you in yourself fixing the bug if you wrote the buggy code? About the same, no?
> He might be an extreme case of this. But it happens if you are not consistently monitoring/watching these things to a point where you might as well write it yourself. The productivity gain is gone, atleast in the form that I read the commonly made arguments from Big AI.
> if you are not consistently monitoring/watching these things to a point where you might as well write it yourself
Why get any help with anything if you could take the full burden on yourself? Probably because with code it's much faster to verify than to produce.
> Add to this, that it seems like these models are performing worse after their initial release suggesting that we can't trust we get the same quality output for the same amount of money, since the providers are incentivised to make it cheaper to run them, i.e. slow use a less quantized version.
Well, you could just stop paying and write the code yourself, that seems to be the main alternative in this situation. But I don't hear of anyone doing that.
> You might still prefer the role of being an agent manager compared to being a developer but I thin the discourse around it making you automatically faster needs to change. Faster to what end? 92-95% uptime?
This has turned pretty quickly into an AI Bad post.
Also,
ridiculas => ridiculous
foundamentals => fundamentals
thatI => that (also double win because the font looks like an L not an I until copied into HN)
"and is lobster project" => and his* lobster project
incentivised => incentivized
Did people stop checking their writing for typos? Just throw the text into google docs, it's really not that hard.
love2read•1h ago
Why is it an illusion of productivity if you work faster with it than without it?
> It has never been a competitive advantage to write code fast but writing the right code. If you could also do that fast you are golden.
Who decides whether or not the code is right? You, no?
> The same foundamentals that makes software stable, robust and good haven't changed. Writing software has always been constrained by thinking, design, trade-offs and understanding/mapping real world problems into proper systems.
I don't believe this to be true at all. I believe a significant portion of what writing software has been constrained by is the priority of the work in proportion to the amount of effort to perform the work. Yes, systems thinking also has a place in programming, but it has never been the constraint.
> It's very tempting to replace that flow with automation so you can get some hard earned sleep. But what happens when the agent(s) can't figure out what's wrong. What happens when you have to dig through an ungodly amount of unfamiliar code because you are the one responsible.
Hasn't this always been a possibility when using dependencies that you didn't write. And if anything, AI's "Build It In House" attitude has made debugging deep in the stack a much easier stack than it was when you were debugging someone else's code that's been published on some dependency registry.
> Add to this that these tools are nondeterministic. It was likely the tool that introduced the bug in the first place, how confident are you that it will actually fix the bug.
How confident are you in yourself fixing the bug if you wrote the buggy code? About the same, no?
> He might be an extreme case of this. But it happens if you are not consistently monitoring/watching these things to a point where you might as well write it yourself. The productivity gain is gone, atleast in the form that I read the commonly made arguments from Big AI.
> if you are not consistently monitoring/watching these things to a point where you might as well write it yourself
Why get any help with anything if you could take the full burden on yourself? Probably because with code it's much faster to verify than to produce.
> Add to this, that it seems like these models are performing worse after their initial release suggesting that we can't trust we get the same quality output for the same amount of money, since the providers are incentivised to make it cheaper to run them, i.e. slow use a less quantized version.
Well, you could just stop paying and write the code yourself, that seems to be the main alternative in this situation. But I don't hear of anyone doing that.
> You might still prefer the role of being an agent manager compared to being a developer but I thin the discourse around it making you automatically faster needs to change. Faster to what end? 92-95% uptime?
This has turned pretty quickly into an AI Bad post.
Also,
ridiculas => ridiculous
foundamentals => fundamentals
thatI => that (also double win because the font looks like an L not an I until copied into HN)
"and is lobster project" => and his* lobster project
incentivised => incentivized
Did people stop checking their writing for typos? Just throw the text into google docs, it's really not that hard.
mbvisti•18m ago