I agree with the article, though I will say with an agentic workflow I feel more tired at the end of it than I would doing it by hand. Maybe it’s the constant reading and digging in the generated code, or the constant context switching while waiting for it to think/generate. Or it’s both.
We should be more tired than the model
11–20 of 168 posts
Re: We should be more tired than the model
#12The struggle here for many is expectation. We can certainly be more productive with these tools.
Can we be 10x more productive though? Or is it more like 1.25x? Is it AGI or is it more like an advanced compiler?
Unfortunately the world is betting on 10x when the reality on the ground feels more like 1.25x.
Re: We should be more tired than the model
#13All of these posts are a replay of what Marx wrote about machinery and alienation from work and intensification of the workday.
Re: We should be more tired than the model
#14Something I've been trying recently for non-throwaway code is extensive refactoring, without typing any code myself but by closely directing the coding agent.
Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y".
Early indications are that this is helping a lot with the problem where it's easy to churn out thousands of lines of code and not really have it stick in my head, even if I review every line of it.
Reviewing code and actively refactoring it is less tedious and more mentally engaging than reviewing code without changes.
If this was a human collaborator I'd be worried that I'm just creating busywork for them, but I don't care about busywork for LLMs!
The goal is to produce code that I understand and that I can remember just well enough that I get an updated mental model to help me productively make future decisions about the codebase.
Re: We should be more tired than the model
#15I clearly identify with the problem the author raises, which is: the bottleneck is understanding. I don't go along with their mitigations though. In programming we have one tool for this: abstraction. Decomposition, pattern recognition, even data structures and algorithms are all down stream of abstraction. Collectively, we've never truly mastered abstraction, but it's what we have and we collectively wield it well e…
Yes. And indeed, abstraction is not what LLMs are offering.
Re: We should be more tired than the model
#16https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape...
I think this is how we should be reading code as well.
First understand the top level. Then the next level of detail and so on. I treat my understanding as graph of interconnected black boxes. If I don't understand a particular black box or a node in the graph. I click expand on it, grok the details and then collapse the node. Here's the grokking details of a particular sub-node also follows the same structure as understanding the root node. You don't need to understand everything from the get-go, expand your understanding on the need-to-know basis.
Re: We should be more tired than the model
#17Lately I've been thinking about this a lot. I've slightly shifted my use of Claude from implementing tool to scaffold generator for me to actually do the hard parts. It's frustrating at first, because the impulse always is "I could get Claude to do this in minutes", but that's just the brain trying to spare some energy.
I've found that it's much more rewarding to use LLMs as an aid to deep work instead of a substitute for it, and it's even helped me feel more optimistic about my place in this field after a couple of days of getting used to the mental friction again.
Re: We should be more tired than the model
#18>>In some ways, we’ve replaced the social media feed with a stream of tokens, and I look forward to reading those papers in ten years.
Second this. This is why zuckerberg is dying to spend as much as he can to make meta an AI company.
Re: We should be more tired than the model
#19Something I've been trying recently for non-throwaway code is extensive refactoring, without typing any code myself but by closely directing the coding agent. Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". Early indications are that this is helping a lot with the problem where i…
Interesting idea.
It’s almost like a buffer space would be useful for code.
I’ve been using tuicr for agent code reviews and have been enjoying that. I think I’ll try your idea as part of my workflow.
Re: We should be more tired than the model
#20https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape... I think this is how we should be reading code as well. First understand the top level. Then the next level of detail and so on. I treat my understanding as graph of interconnected black boxes. If I don't understand a particular black box or a node in the graph. I click expand on it, grok the details and then collapse the node. Here's the grokking details…
This kind of structure is also important when writing. You guide the reader through stages of awareness and understanding.