We should be more tired than the model
vickiboykis.com
We should be more tired than the model
1–10 of 168 posts
Re: We should be more tired than the model
#2> Using the agent to keep asking questions about pieces of the code I don’t understand instead and pull up relevant documentation and PRs.
I like to do the opposite, asking the LLM to give me relevant follow-up documentation, like the actually docs, where I can read and understand things myself. Data structures, techniques, etc. I still like to read that from the authors, much easier and trustworthy to grasp.
Re: We should be more tired than the model
#3> Using the agent to keep asking questions about pieces of the code I don’t understand instead and pull up relevant documentation and PRs. I like to do the opposite, asking the LLM to give me relevant follow-up documentation, like the actually docs, where I can read and understand things myself. Data structures, techniques, etc. I still like to read that from the authors, much easier and trustworthy to grasp.
I do this too. LLMs are amazing at finding weird trivia deep in the docs. But you have to go check the original. The machine is often correct-ish.
Re: We should be more tired than the model
#4This is how I treated LLMs from the beginning, maybe because of my impostor syndrome of not knowing if my understanding of _anything_ is correct, and going down the rabbit hole of the concepts that are presented there...
Now the question to the round: in your opinion, are LLMs ok to learn in this way? At least on the theoretical side of things?
Re: We should be more tired than the model
#5> adding friction back into development
I'm really trying to do this too. The problem is it's *so easy* to let your standards slip, even for just a moment, and that piece of code suddenly becomes foreign.
I find more mental energy is spent on restraint than execution these days.
Re: We should be more tired than the model
#6> We should be more tired than the model
I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools supposed to make our lives easier?!
Re: We should be more tired than the model
#7> particularly because its UX affordances are reminiscent of a slot machine’s: you pull the lever, you get a reward (a solution to your coding problem.)
I hope the field moves out of the TUI with prompt + pull the lever paradigm soon‚ when it comes to agentic programming. And the Markdown paradigm too, tbh.
There hasn't been anything that really sticks yet for a shift to happen.
Re: We should be more tired than the model
#8> We should be more tired than the model I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools s…
That’s only true if companies give some of the productivity gains back to the employee, but most companies don’t do that. They keep the profits purely for themselves. There are some exceptions.
Re: We should be more tired than the model
#9I don’t know about being more tired than the model, but when I’ve had a particularly productive session, I feel more tired (brain fog) than during a coding session. Probably because I’ve replaced brainless typing with the cognitive load of decision-making and weighing plan approaches.
Re: We should be more tired than the model
#10I 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 enough that it's usually somewhat effective.
We are in dire need of a better abstraction.