We should be more tired than the model
vickiboykis.com63 points by tosh 2 hours ago
63 points by tosh 2 hours ago
I don't know. I find that I'm moving up a level and improving my product-management skills while delegating most of the code to the agents. I'm still very much hands-on with the design and requirements, and I'm asking questions like, "What's our security story for XYZ?", "Are we accounting for colour-blindness?", etc. Not being down in the code allows me to prairie-dog a bit more and see the landscape better.
One thing I've noticed is that LLMs have allowed middle managers trapped inside the role of a developer to finally self actualise.
I'm about 50% that way. However when the AI is done coding I then step back and review to find places the code quality is unacceptable. I also have to stop the AI once in a while because it forgets the point and does something stupid. Junior engineer learn, AI does not.
> Junior engineer learn, AI does not.
This is technically true, but lets not act like we haven't seen immense improvement of both models are harnesses for these models in the past years. They may not be learning, but they are getting better
They are getting better at historical data, not at the fundamental issue.
As a recent example, I recently had to abandon the multiple LLM reviewer/verifier model I was using because zig 0.16 was released with major changes.
I actually reverted back to full self hosted because the foundation models we’re trying too hard to revert to the older versions of the language.
It is going to be a balancing act and there is fundamentally no way for LLMs to get around this.
We will have to develop methods to do so, most likely by focusing agents on problems that are more static.
I find great success in not relying on LLM's built-in knowledge, but giving it links to necessary docs/manuals and have it read that before doing anything.
Also, add "no assumptions or guesses" and if you use a model with really strong prompt adherence (most SOTA models), they'll figure out the right version first, then look up docs, then implement.
Unless you log its mistakes and how they were solved in decisions.log
You might want to think about how that technique scales as your decisions.log accumulates more and more guidance.
Or at least maybe ask Claude what will happen when the md and log files that keep it on task start to dominate and someday even overflow its context windows.
Using AI doesn't protect you from thinking about resource constraints and algorithm tradeoffs like any other engineer might. It's just that the resource constraints and algorithms tradeoffs that you need to engineer around become those of the AI tooling rather than the project its generating.
Something 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.
>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".
There’s a lot of overlap there with the sorts of things traditional automated refactoring tools can do approximately instantly, locally, and for free.
Yea, when I read about people using AI with prompts like that, my first thought is, "Wow, that's like copy/paste, but instead of Ctrl-C/Ctrl-V, it's round-tripping to a server and using GPUs to do it." What's next? "Claude, rename the function doFoo() to performBar()"?
Here's the loop for a successful small refactor (anything beyond a rename that could be handled entirely by an IDE):
1. Find the code you want to change
2. Run the tests to confirm that test coverage is good for the starting point
3. Track down everywhere else that might call or interact with that code
4. Update the tests (red/green TDD)
5. Alter the code
6. Update the things that call the code
7. Run the tests again
8. Apply linters/formatters
9. Address any feedback from linters
10. Check to see if any documentation needs updating and do that
11. Land a commit with a descriptive commit message
I can get all of that done with a coding agent with a single sentence prompt - especially if it's already in a session where it knows that I do "red/green TDD".
... and then I can work on something else while the agent is churning through those steps.
My point is that all these steps can be done very quickly by even a junior developer who knows emacs or their IDE, in a codebase with existing lint/format/test automation, without even taking their hands off the keyboard. You're already in your IDE, you can probably do it just as fast there. I don't see the cost/benefit of spending tokens and hitting a server for this kind of work.
I guess the difference may be in people's mode of AI working: Do you primarily develop in your IDE or a bunch of terminals running vim, and occasionally fire up claude to do more complex things? Or do you primarily develop in a long-lasting claude terminal, and occasionally tab over to the IDE to watch/codereview? In other words: What dev tool is on your primary monitor and what's on your secondary monitor? It's getting hard for developers in one camp to discuss coding and see eye-to-eye with developers from the other camp.
Sure, and sometimes the coding agent will even use one of those refactoring tools on my behalf.
Getting them to run ast-grep is really fun, especially when it saves me from having to memorize that syntax myself.
Yeah I do find myself leaning back into those tools. For awhile I’d just prompt to rename something. But when it’s my own tokens I’m paying for, I prefer the fast and free option :)
What are some traditional automated refactoring tools that can do stuff like those tasks from the example?
???
Mature workflows for those kinds of tasks have been mostly ubiquitous across professional-grade engineering tools like those from JetBrains or Visual Studio itself for longee than many people here have even been working in the trade.
It's clearly not the case for simonw, but much of what many people task AI tools to do foe them are only a novelty for the "VS Code"-type users who stubbornly refused to explore more professional-grade paid tools in the past.
Yet for many tasks, those mature paid tools provided reliable and efficient features that make the AI approach look like an expensive, slow, and dangerously nondeterministic regression.
Oh I'd definitely classify myself as a "'VS Code'-type users who stubbornly refused to explore more professional-grade paid tools in the past."
I've never liked the larger IDEs - VS Code only won me over because it was indistinguishable from a lighter text editor at first, and the IDE tools then emerged slowly as I used it.
VSCode "rename symbol" is a basic example. Jetbrains products have way more and it's pretty great: https://www.jetbrains.com/help/idea/refactoring-source-code....
I think the best approach is active code review as the agent does small batches. Or letting it come up with a solution, testing if it passes or fails the desired outcome, then creating a separate fresh project and asking it to rewrite in small parts, and have it explain to you what and why it's doing to achieve each part.
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.
I 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.
The "right" abstraction seems like quite an art. Sometimes it's not obvious, or it takes multiple rounds of exploration and testing (I'm thinking here of the mental shift moving from HTML + JS, via jQuery, Backbone, Knockout and up to React/Vue or Angular). At all points, we thought we had reasonable abstractions for a while. Vue and Svelt, or NextJS, now are so far from the mental model of early 00s "DHTML".
And I'm not sure how this relates to TFA's point. Are you saying we collectively need to get better at abstraction so that LLMs get better at abstraction (either by training, or our prompting), so that their code is easier to read?
Yes. And indeed, abstraction is not what LLMs are offering.
It very much is. But it's a non-deterministic, more-lossy-than-usual abstraction: english to code.
> 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?!
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.
In general without unions and workers saying "that's enough", any productivity savings never go back to workers.
But of course AI is also making union/worker pressure matter even less, since it's function is to cheapen the cost/leverage of workers.
So the only solution is fighting that at the political/legal/social level. Which I ain't see happening anytime soon.
There's only one way to eat an elephant: one bite at time. Putting some energy into organizing, even if only on the level of deliberately building solidarity with your coworkers and never mentioning the word "union", can and will pay dividends to somebody down the road -- possibly even you -- and also has immediate benefits in that it feels better than looking over your shoulder all the time.
>There's only one way to eat an elephant: one bite at time.
Maybe, but to eat it you need to kill it first or it will stomp you. And this can only happen all at once :)
Choosing speed today is going to cost you tomorrow. Leaning on these tools degrades your actual abilities. You are making yourself less valuable to future employers. So while it might be in the best interest of the company to force you to work faster it is in your own best interest to resist that.
I'm not convinced jobs will be axed in the long-term - All the big tech companies frequently staff teams on projects that basically go nowhere to spread bets on multiple projects in case one has legs. Once LLMs reach the point of commoditization and drop in price, it seems like the natural next step is more teams with smaller structures to spread bets even more. A 5 person team that is LLM-assisted is going to move faster and be more cohesive than an 10 person team that ends up stepping all over each other.
>Weren't these tools supposed to make our lives easier?
In a late stage capitalism market economy, their only actual requirements were to make profit for the shareholders and VCs.
If that means making our lives harder, firing most of us, making us stupider, being addictive, being used for surveillance to sell us shit or control us, or even being used to kill people, all of those are fine, if they fulfil that requirement.
> 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.
https://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.
This kind of structure is also important when writing. You guide the reader through stages of awareness and understanding.
>>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.
Lately 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.
This sounds like something I'd enjoy. Do you have a blog post or guide on your approach?
> 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.
Not a programmer, but I'm beginning to discover a rhythm similar to the author's that doesn't save time and effort as much as it fragments and redistributes them both.
Being conscious of what type of memory you're working in (or need to engage) may be the trick to building rhythm or flow, or whatever. Depending on the case the LLM may not even be necessary. Use something else.
The trap could be in trying to depend on and work with a model the same way we would work by ourselves, as the author describes, letting every type of memory unconsciously operate.
Skill atrophy is a real issue when it comes to creative skills. But I argue that not all of what we call coding belongs to these skills. I consider lots of it chores due to inefficiency of the languages and abstraction layers. Problem solving, hypothesizing, researching, running experiments, and designing solutions all require critical thinking and creative skills. If you're worried about losing coding skills, ask yourself this question: what are you trying to achieve?
> 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.
This 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?
Not the author, but one way you could mitigate some of the LLMs problems while learning (authoritatively stating wrong facts, reward hacking, ...) is to have it give you testable code exercises to teach you facts. So you can get the benefits of the LLM AND deterministically verify its claims. I've been trying this lately and recovering some of the lost joy of learning CS nowadays.
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.
I’ve been noticing the same thing. I’m getting roughly 2-3x more done, but I’m also at least 1.5x more exhausted at the end of the day.
“Using the agent after trying for 20 minutes”
This made me chuckle a bit.
There’s no point in fooling ourselves about our own skill retention if this is the case.
OP’s approach is one in a thousand.
Imho most of professional coders trade their time for oblivion.
The problem is that you really don’t remember anything about the code. It is not your creation.
It’s like a monkey in front of a slot machine, just pulling the lever and waiting to see if it hits the jackpot.
At the end of the day, it remembers that it pulled the lever. And how many times it won :)
Agentic-based coding with /goal and multiple agents coding together is another level…
But the issue remain imho - if there is an error, who is going to repair it?
>The problem is that you really don’t remember anything about the code. It is not your creation.
The next problem is few care about that, at any level: coders, managers, execs. Just want their feature churn.
The even worse problem (or maybe, a positive) is that most of that code and the products powered by it aren't needed either.
For human in the loop to be effective, the human needs to actually be performing some substantive action, giving real guidance and critique and pushback. If the human only ever accepts the default plans then not only is there no understanding but the agent should learn to stop asking. It is not learning anything from the human, after all.
One thing that I look at is pushback rate: what percentage of the agent's proposals are rejected or critiqued? If it's below 5% I have found I have gotten too credulous and I am no longer closely following. Danger! If it's above 50%, I have clearly not given the agents sufficient context to perform the task and need to update my harness and instructions.
Who watches the watchers? I can imagine a guard dog process that halts the session to yell at the human if it detects complacency: if the human is providing too few tokens per minute of new context relevant to the task.
All of these posts are a replay of what Marx wrote about machinery and alienation from work and intensification of the workday.
The solution is to move slower, not faster.
I 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.
The 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.
So many efforts out there to alter the usage of the tool to regain control, when it's clear to me that the tool is the problem?
By which I mean, we should -- as software engineers -- be insisting on tools that put us in the driver's seat more.
Instead we're letting the agent drive. (I'm as guilty as this as anybody). But really we're letting Dario, Sam, Boris, etc. drive. And it should be clear from their public pronouncements and emissions that they don't have the best interests of our profession -- or the quality of software engineering generally -- in mind.
Yes, certainly, alter how you use the tools. But we need to fix the tools themselves.
>By which I mean, we should -- as software engineers -- be insisting on tools that put us in the driver's seat more.
And the company says "fuck you then, I'll fire you, and keep fewer coders, willing to keep the AI dance".
The role of AI as a tech is to put you out of the drivers seat as much as possible. All the way to job elimination.
Solution?
And by doing that said companies are devaluing their own IP and creating an organizational knowledge debt. Companies that work that way will in long run get outcompeted by shops that figure out (I don't know how) how to manage this better.
That's an interesting idea, but if the tools are really the problem, is there an actual way that we can solve this? How?
Another option is just not using an LLM at all.
[flagged]
[flagged]