6 ms·

We should be more tired than the model

196 points by tosh 5mo ago

Aldipower 5mo ago
> 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.
- coffeefirst 5mo ago
  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.
helloplanets 5mo ago
> 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.
trklausss 5mo ago
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?
- yondys 5mo ago
  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.
stantonius 5mo ago
> 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.
sam-cop-vimes 5mo ago
> 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?!
- mettamage 5mo ago
  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.
  - poszlem 5mo ago
    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.
    - gib444 5mo ago
      What form can that resist realistically take if lots of companies are monitoring your LLM usage, demanding more usage, and fire bottom "performers"?
  - coldtea 5mo ago
    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.
    - 5mo ago
timeisapear 5mo ago
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.
CraigJPerry 5mo ago
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.
- repelsteeltje 5mo ago
  Yes. And indeed, abstraction is not what LLMs are offering.
  - coldtea 5mo ago
    It very much is. But it's a non-deterministic, more-lossy-than-usual abstraction: english to code.
    - eikenberry 5mo ago
      2 different meanings of abstraction at work here.
      - coldtea 5mo ago
        Nope, the same single meaning. English to program is the same kind of abstraction as going from assembly to program to C to program to high level scripting to "4G languages" and so on, and hiding all kinds of details behind a much terser layer. It's just that it's a qualitative jump at it. Here's a ChatGPT provided answer asked to "define abstraction in programming, like when going from assembly to C to scripting, etc": "Abstraction in programming is the process of building layers where each layer hides the details of the layer below".
        eikenberry 5mo ago
        In math/computers abstraction has a technical meaning that requires deterministic behavior for the abstraction to work. It isn't a proper abstraction if it doesn't always do the same thing underneath. Abstraction as a layering idea without regard to how it works is like the pop-pych version in that it is "right" but misses nuance.
cautiouscat 5mo ago
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.
- mock-possum 5mo ago
  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.
wxw 5mo ago
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.
zawaideh 5mo ago
All of these posts are a replay of what Marx wrote about machinery and alienation from work and intensification of the workday.
- My_Name 5mo ago
  [flagged]
simonw 5mo ago
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.
- j_bum 5mo ago
  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.
- docheinestages 5mo ago
  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.
  - lanstin 5mo ago
    Yeah my main current work repo I have five clones of it (de1.main, de2.main etc) each with an agent in a tmux session. The main priority change I will have up in my emacs gui with editing the files and reading and so on, but the side ideas that used to just get a line in the ideas or todo section of daily.org now sometimes get a claude working on it. As POC at the least.
- 5mo ago
Npovview 5mo ago
https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf 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.
- HPsquared 5mo ago
  This kind of structure is also important when writing. You guide the reader through stages of awareness and understanding.
  - Npovview 5mo ago
    [dead]
yondys 5mo ago
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.
- the_other 5mo ago
  This sounds like something I'd enjoy. Do you have a blog post or guide on your approach?
dwa3592 5mo ago
>>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.
tolerance 5mo ago
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.
sixtyj 5mo ago
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?
- coldtea 5mo ago
  >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.
Trasmatta 5mo ago
Another option is just not using an LLM at all.
- My_Name 5mo ago
  Go to a town 1000 miles away as part of your job without using a travel device at all, like a car or a train. I mean you can, sure, and doing so will produce a journey filled with experiences, but no business would operate like that and stay in business. That is the future of jobs where thinking is the work.
  - Trasmatta 5mo ago
    Businesses are going to regret going all in on AI. It'll take a couple more years before the cracks start to show.
cmrdporcupine 5mo ago
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.
- yondys 5mo ago
  That's an interesting idea, but if the tools are really the problem, is there an actual way that we can solve this? How?
- coldtea 5mo ago
  >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?
  - cmrdporcupine 5mo ago
    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.
    - coldtea 5mo ago
      What's worse, companies might be fine with "devaluing their own IP", since companies are not deciding, execs are. And those execs will get their bonuses anyway, and will be drinking their champagne far away from their executive roles and the company by the time that's felt.
docheinestages 5mo ago
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?
nullbio 5mo ago
The solution is to move slower, not faster.
mikdan 5mo ago
[flagged]
dweekly 5mo ago
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.
paulmooreparks 5mo 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.
- tamaz_entalpa 5mo ago
  [flagged]
- ctdinjeu7 5mo ago
  [flagged]
- bluGill 5mo ago
  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.
  - seunosewa 5mo ago
    Unless you log its mistakes and how they were solved in decisions.log
    - deleted 5mo ago
      [deleted]
  - dpoloncsak 5mo ago
    > 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
    - 5mo ago
lucamark 5mo ago
[flagged]
wolttam 5mo ago
“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.
fny 5mo ago
I encourage you to crack open a dependency tree for any project and ask: how many of these do I understand? Then open one and ask: do you really understand whats happening? How much of the code there do you even use? The experience will feel uncannily similar to AI generated code. So treat slop the same way. Give it a good, well tested API, and file an issue or PR when something breaks.
soiltype 5mo ago
The point about the UI affordances strikes me as very relevant. I find that the way I want to use LLMs in coding is not available. We have chatbots in a sidebar that will just generate code for you or, more helpfully, answer your questions. We also have inline LLM code completion, which I've turned off completely because they're incredibly noisy. What I want is something between those. My ideal use of LLMs while coding would be, i start writing a function and need to act on some data. I don't know what method to use, maybe I'm in an unfamiliar language/framework and don't know what my options are. I want the AI to explain what methods I can call to do X in this specific place, no more, no less. It would need to know what outcome I want, which would be hard to do without jumping out of the code and typing into the chat, but I basically want it to function like Intellisense on steroids. Something that doesn't break my focus. Current LLMs are anti-flow. For me, that's poison.
- eikenberry 5mo ago
  I've seen editors configured similar to how you describe. Varying from simple shadow-text style completion generated on command/keybind to more complex setups where you ask an external AI agent for a solution with it generating code that appears as shadow-text in editor with chat in the sidebar giving the reasoning behind it. I agree the tools in general a big problem with current generation AI tools but there are options if you look around enough. Though you can burn a lot of time figuring out which ones are useful.
sceptic123 5mo ago
Reading all the code the model generates will tire you out pretty quickly
bozhark 5mo ago
As someone who absolutely is… Thanks for this insight and validation
K0balt 5mo ago
I honestly don’t understand what people are on about. As a dev with 40+ years behind me, I apply the same skills and tools to LLMs as I would to a small team of junior devs, except with a higher degree of rigor. I don’t feel that my skills are atrophying, in fact I’ve learned a bunch of new stuff in the process. Depending on the work, I’m producing about 4x what I would have with a small team, and it is better code, better documented, more modularity, and less bugs than I was shipping with humans. You have to keep a tight OODA loop, and write the code in specifications, protocols, interfaces, and implementation plans before the first executable line is put down. Iterate the code and docs together to minimize and document drift. Treat a context window as a session. When it’s full, you start over with a new session, bring in the onboarding documentation, and go to work. I never cross context boundaries midstream, it’s always a disaster. 1m context is critical, I burn 150k just onboarding and orienting a new session. Still shipping 4x at 1/10 the cost, and less bugs in the field (greenfield firmware development)
adamtaylor_13 5mo ago
I'll point out that this presupposes that skill retention is necessary, as opposed to something like "taste" retention. I'm not arguing against this, just pointing out that it carries a supposition that may or may not be true. I am not yet convinced that the skill loss is as bad as people make it out to be, nor am I convinced that "taste" degrades like "skill" does. After all, it's easy to teach someone a framework. It's very hard to communicate why something is not as functional or why the UX isn't as good as it could be. All this to say, I believe these are valuable questions, but we should be careful what presuppositions we bring into the equation. My value has never been my ability to write code. It's been my ability to make people's problems elegantly go away. I do not believe AI is making that worse (yet). Side-note: If it IS making my skills worse... I'll just sharpen them later. It's not like experimenting with AI for a few years is going to permanently disable me.
- xgulfie 5mo ago
  I anticipate that heavily using AI to do the dev work for you for a few years could very well be worse than just taking the years off, since you're training your brain that you can just reach for the AI
- xgulfie 5mo ago
  To your other point, skill retention is important for me, the person typing this, because we live in a society where if I don't develop my skills I become unemployed and die in a ditch
- sorentwo 5mo ago
  As a library maintainer, skill and taste are almost equally important. If I can’t recognize inefficiencies, difficult to maintain code, or generally unpleasant code smells, then people lose trust in my libraries/products and it’s no better off than some recently generated slop. Years of production experience, wisdom, and using something in anger matters for both skill and taste.
d4rkp4ttern 5mo ago
I try to counteract this "comprehension-debt" by having the code-agent quiz me, Socratic-style, about the core problems, possible solutions, why certain approaches wouldn't work, and why the specific approach was implemented. When I don't answer correctly, the agent drills down and asks more questions, until I am led to the answer myself. I find this surprisingly useful. The quiz forces me to put in effort in thinking through the problem and solutions. And this effort likely helps in learning, understanding and retention. I also find frontier LLMs are very good at this type of Socratic quiz; they give a very good semblance of having a "theory of mind". I made a Socratic Quiz skill as part of suite of code-agent productivity tools: https://pchalasani.github.io/claude-code-tools/plugins-detail/workflow/#socratic-quiz https://pchalasani.github.io/claude-code-tools/plugins-detai...
porphyra 5mo ago
Code generation isn't antithetical to high level reasoning skills and even with "vibe coding" you can still exercise way finer control than the slot machine analogy. I typically prompt the AI with a detailed plaintext description of the algorithm and have a firm grasp on the time complexity. Perhaps my low level implementation skills are atrophying, but now I have greater bandwidth to think about the higher level goals now that I don't need to worry about the nitty gritty stuff. It's kinda like how we went from handwriting machine code to programming in FORTRAN, and then going to a higher level language like Python. To me, using AI is just another level higher. Skill retention of understanding machine code and assembly went away in the majority of software engineers, but we gained a lot more than we lost.
peteforde 5mo ago
This post reminds me of a conversation I had with my dad in the late 90s when I was mostly using VB6 and he was encouraging me to learn C++. Even back then, the syntax and ceremony of the language repulsed me, and my admittedly arrogant reply was that if I ever needed C++, I'd just hire someone to do that part for me. For what it's worth, I still stand by that strategy 30 years later. Delegation is one of the most powerful tools we can use, and developers are usually really bad at it. I speculate that this is because we have egos and some part of my reptile brain feels like bringing in people who are better at something than I am is some kind of intellectual defeat. In reality, the opposite is true. The lens that folks [who are anxious about forgetting how to program when using LLMs] should use is to ask themselves if they have the same existential crisis when hiring someone or working as part of a team. Does delegation make you dumber, smarter or something else? In my case, I'm rarely as smart as when I effectively delegate things I'm less good at. In a universe where time is infinite, I could perhaps decide that it makes sense to be good at everything. In this reality, I'm more aware of how finite time is every morning when I wake up. It makes no sense for me to learn C++ for the few moments when arguably it would be handy if I knew it. Ironically, it was ultimately video games - specifically, some hobby Unity development - that led to me learning just enough C++ to embarrass myself. And my dad never approved of video games, either. Anyhow: if hiring someone to work on parts of your project doesn't make you less good at programming, I highly doubt that using an LLM makes you less good at programming either. In my experience, I'm actually feeling like a better developer these days because I'm getting so much more done in a shorter amount of time.
- gjadi 5mo ago
  You can't talk about delegation without talking about what and who you're delegating. Delegating a demo or an exploration to a junior is fine if you can help them with feedbacks and make them grow and the business is not on the line. Delegating a critical development to a senior engineer you've vetted on previous delivery is fine too. Delegating a critical development to a junior is a recipe for disaster. Now, I'm still trying to figure out what I can fully delegate to an agent and what I can't. Right now, LLM feel like a senior on technical stuff and a junior on decision/taste. One thing is sure, I can't delegate a critical development to it, not without review. For that review, I need programming skills. Maybe in the future that won't be the case, but I am not seeing that right now. (Using Claude code)
lenerdenator 5mo ago
The author is 100% right. I can feel myself just "wanting the job done" with agentic AI, and not understanding/knowing how the code works. That being said, I have deadlines I have to meet.
Natalia724 5mo ago
[flagged]
LAC-Tech 5mo ago
People are still letting LLMs generatr code for them? Clankers are for reading code, not for writing it.
k_plankenhorn 5mo ago
For people who couldn’t code at all before, AI coding tools don’t replace skill, they create access. My ability to build and retain the skills isn’t less because I didn’t have them to begin with pre-AI for coding. I can certainly say I’ve developed judgment. Knowing when the input is right, when to push back, when to rewrite. Maybe that’s the skill agentic coding builds for non-engineers?
gjadi 5mo ago
Interesting as I reach a similar pov. I just started with experimenting with the following workflow with Claude Code: - get a plan for whatever I want to do, iterating in plan mode until I am satisfied with the solution - before execution, I mark each phase that I want to do/learn about with /tutor-mode Tutor-mode is a SKILL I made to have the LLM guide and teach through questions and hints. So I delegate completely the boilerplate/build system/CI and switch to manual+aided by AI for specific implementation part of the code. I also keep a final validation step to me because I've experimented a few too many "sorry I told you I passed the test suite and I did, but the build failed and I didn't told you".

196 points by tosh 5mo ago

> 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.

coffeefirst 5mo ago
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.

helloplanets 5mo ago

> 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.

trklausss 5mo ago

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?

yondys 5mo ago
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.

stantonius 5mo ago

> 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.

sam-cop-vimes 5mo ago

> 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?!

mettamage 5mo ago
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.
- poszlem 5mo ago
  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.
  - gib444 5mo ago
    What form can that resist realistically take if lots of companies are monitoring your LLM usage, demanding more usage, and fire bottom "performers"?
- coldtea 5mo ago
  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.
  - 5mo ago

timeisapear 5mo ago

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.

CraigJPerry 5mo ago

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.

repelsteeltje 5mo ago
Yes. And indeed, abstraction is not what LLMs are offering.
- coldtea 5mo ago
  It very much is. But it's a non-deterministic, more-lossy-than-usual abstraction: english to code.
  - eikenberry 5mo ago
    2 different meanings of abstraction at work here.
    - coldtea 5mo ago
      Nope, the same single meaning. English to program is the same kind of abstraction as going from assembly to program to C to program to high level scripting to "4G languages" and so on, and hiding all kinds of details behind a much terser layer. It's just that it's a qualitative jump at it. Here's a ChatGPT provided answer asked to "define abstraction in programming, like when going from assembly to C to scripting, etc": "Abstraction in programming is the process of building layers where each layer hides the details of the layer below".
      - eikenberry 5mo ago
        In math/computers abstraction has a technical meaning that requires deterministic behavior for the abstraction to work. It isn't a proper abstraction if it doesn't always do the same thing underneath. Abstraction as a layering idea without regard to how it works is like the pop-pych version in that it is "right" but misses nuance.

cautiouscat 5mo ago

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.

mock-possum 5mo ago
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.

wxw 5mo ago

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.

zawaideh 5mo ago

All of these posts are a replay of what Marx wrote about machinery and alienation from work and intensification of the workday.

My_Name 5mo ago
[flagged]

simonw 5mo ago

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.

j_bum 5mo ago
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.
docheinestages 5mo ago
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.
- lanstin 5mo ago
  Yeah my main current work repo I have five clones of it (de1.main, de2.main etc) each with an agent in a tmux session. The main priority change I will have up in my emacs gui with editing the files and reading and so on, but the side ideas that used to just get a line in the ideas or todo section of daily.org now sometimes get a claude working on it. As POC at the least.
5mo ago

Npovview 5mo ago

https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf 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.

HPsquared 5mo ago
This kind of structure is also important when writing. You guide the reader through stages of awareness and understanding.
- Npovview 5mo ago
  [dead]

yondys 5mo ago

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.

the_other 5mo ago
This sounds like something I'd enjoy. Do you have a blog post or guide on your approach?

dwa3592 5mo ago

>>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.

tolerance 5mo ago

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.

sixtyj 5mo ago

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?

coldtea 5mo ago
>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.

Trasmatta 5mo ago

Another option is just not using an LLM at all.

My_Name 5mo ago
Go to a town 1000 miles away as part of your job without using a travel device at all, like a car or a train. I mean you can, sure, and doing so will produce a journey filled with experiences, but no business would operate like that and stay in business. That is the future of jobs where thinking is the work.
- Trasmatta 5mo ago
  Businesses are going to regret going all in on AI. It'll take a couple more years before the cracks start to show.

cmrdporcupine 5mo ago

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.

yondys 5mo ago
That's an interesting idea, but if the tools are really the problem, is there an actual way that we can solve this? How?
coldtea 5mo ago
>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?
- cmrdporcupine 5mo ago
  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.
  - coldtea 5mo ago
    What's worse, companies might be fine with "devaluing their own IP", since companies are not deciding, execs are. And those execs will get their bonuses anyway, and will be drinking their champagne far away from their executive roles and the company by the time that's felt.

docheinestages 5mo ago

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?

nullbio 5mo ago

The solution is to move slower, not faster.

mikdan 5mo ago

[flagged]

dweekly 5mo ago

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.

paulmooreparks 5mo 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.

tamaz_entalpa 5mo ago
[flagged]
ctdinjeu7 5mo ago
[flagged]
bluGill 5mo ago
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.
- seunosewa 5mo ago
  Unless you log its mistakes and how they were solved in decisions.log
  - deleted 5mo ago
    [deleted]
- dpoloncsak 5mo ago
  > 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
  - 5mo ago

lucamark 5mo ago

[flagged]

wolttam 5mo ago

“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.

fny 5mo ago

I encourage you to crack open a dependency tree for any project and ask: how many of these do I understand? Then open one and ask: do you really understand whats happening? How much of the code there do you even use? The experience will feel uncannily similar to AI generated code. So treat slop the same way. Give it a good, well tested API, and file an issue or PR when something breaks.

soiltype 5mo ago

The point about the UI affordances strikes me as very relevant. I find that the way I want to use LLMs in coding is not available. We have chatbots in a sidebar that will just generate code for you or, more helpfully, answer your questions. We also have inline LLM code completion, which I've turned off completely because they're incredibly noisy. What I want is something between those. My ideal use of LLMs while coding would be, i start writing a function and need to act on some data. I don't know what method to use, maybe I'm in an unfamiliar language/framework and don't know what my options are. I want the AI to explain what methods I can call to do X in this specific place, no more, no less. It would need to know what outcome I want, which would be hard to do without jumping out of the code and typing into the chat, but I basically want it to function like Intellisense on steroids. Something that doesn't break my focus. Current LLMs are anti-flow. For me, that's poison.

eikenberry 5mo ago
I've seen editors configured similar to how you describe. Varying from simple shadow-text style completion generated on command/keybind to more complex setups where you ask an external AI agent for a solution with it generating code that appears as shadow-text in editor with chat in the sidebar giving the reasoning behind it. I agree the tools in general a big problem with current generation AI tools but there are options if you look around enough. Though you can burn a lot of time figuring out which ones are useful.

sceptic123 5mo ago

Reading all the code the model generates will tire you out pretty quickly

bozhark 5mo ago

As someone who absolutely is… Thanks for this insight and validation

K0balt 5mo ago

I honestly don’t understand what people are on about. As a dev with 40+ years behind me, I apply the same skills and tools to LLMs as I would to a small team of junior devs, except with a higher degree of rigor. I don’t feel that my skills are atrophying, in fact I’ve learned a bunch of new stuff in the process. Depending on the work, I’m producing about 4x what I would have with a small team, and it is better code, better documented, more modularity, and less bugs than I was shipping with humans. You have to keep a tight OODA loop, and write the code in specifications, protocols, interfaces, and implementation plans before the first executable line is put down. Iterate the code and docs together to minimize and document drift. Treat a context window as a session. When it’s full, you start over with a new session, bring in the onboarding documentation, and go to work. I never cross context boundaries midstream, it’s always a disaster. 1m context is critical, I burn 150k just onboarding and orienting a new session. Still shipping 4x at 1/10 the cost, and less bugs in the field (greenfield firmware development)

adamtaylor_13 5mo ago

I'll point out that this presupposes that skill retention is necessary, as opposed to something like "taste" retention. I'm not arguing against this, just pointing out that it carries a supposition that may or may not be true. I am not yet convinced that the skill loss is as bad as people make it out to be, nor am I convinced that "taste" degrades like "skill" does. After all, it's easy to teach someone a framework. It's very hard to communicate why something is not as functional or why the UX isn't as good as it could be. All this to say, I believe these are valuable questions, but we should be careful what presuppositions we bring into the equation. My value has never been my ability to write code. It's been my ability to make people's problems elegantly go away. I do not believe AI is making that worse (yet). Side-note: If it IS making my skills worse... I'll just sharpen them later. It's not like experimenting with AI for a few years is going to permanently disable me.

xgulfie 5mo ago
I anticipate that heavily using AI to do the dev work for you for a few years could very well be worse than just taking the years off, since you're training your brain that you can just reach for the AI
xgulfie 5mo ago
To your other point, skill retention is important for me, the person typing this, because we live in a society where if I don't develop my skills I become unemployed and die in a ditch
sorentwo 5mo ago
As a library maintainer, skill and taste are almost equally important. If I can’t recognize inefficiencies, difficult to maintain code, or generally unpleasant code smells, then people lose trust in my libraries/products and it’s no better off than some recently generated slop. Years of production experience, wisdom, and using something in anger matters for both skill and taste.

d4rkp4ttern 5mo ago

I try to counteract this "comprehension-debt" by having the code-agent quiz me, Socratic-style, about the core problems, possible solutions, why certain approaches wouldn't work, and why the specific approach was implemented. When I don't answer correctly, the agent drills down and asks more questions, until I am led to the answer myself. I find this surprisingly useful. The quiz forces me to put in effort in thinking through the problem and solutions. And this effort likely helps in learning, understanding and retention. I also find frontier LLMs are very good at this type of Socratic quiz; they give a very good semblance of having a "theory of mind". I made a Socratic Quiz skill as part of suite of code-agent productivity tools: https://pchalasani.github.io/claude-code-tools/plugins-detail/workflow/#socratic-quiz https://pchalasani.github.io/claude-code-tools/plugins-detai...

porphyra 5mo ago

Code generation isn't antithetical to high level reasoning skills and even with "vibe coding" you can still exercise way finer control than the slot machine analogy. I typically prompt the AI with a detailed plaintext description of the algorithm and have a firm grasp on the time complexity. Perhaps my low level implementation skills are atrophying, but now I have greater bandwidth to think about the higher level goals now that I don't need to worry about the nitty gritty stuff. It's kinda like how we went from handwriting machine code to programming in FORTRAN, and then going to a higher level language like Python. To me, using AI is just another level higher. Skill retention of understanding machine code and assembly went away in the majority of software engineers, but we gained a lot more than we lost.

peteforde 5mo ago

This post reminds me of a conversation I had with my dad in the late 90s when I was mostly using VB6 and he was encouraging me to learn C++. Even back then, the syntax and ceremony of the language repulsed me, and my admittedly arrogant reply was that if I ever needed C++, I'd just hire someone to do that part for me. For what it's worth, I still stand by that strategy 30 years later. Delegation is one of the most powerful tools we can use, and developers are usually really bad at it. I speculate that this is because we have egos and some part of my reptile brain feels like bringing in people who are better at something than I am is some kind of intellectual defeat. In reality, the opposite is true. The lens that folks [who are anxious about forgetting how to program when using LLMs] should use is to ask themselves if they have the same existential crisis when hiring someone or working as part of a team. Does delegation make you dumber, smarter or something else? In my case, I'm rarely as smart as when I effectively delegate things I'm less good at. In a universe where time is infinite, I could perhaps decide that it makes sense to be good at everything. In this reality, I'm more aware of how finite time is every morning when I wake up. It makes no sense for me to learn C++ for the few moments when arguably it would be handy if I knew it. Ironically, it was ultimately video games - specifically, some hobby Unity development - that led to me learning just enough C++ to embarrass myself. And my dad never approved of video games, either. Anyhow: if hiring someone to work on parts of your project doesn't make you less good at programming, I highly doubt that using an LLM makes you less good at programming either. In my experience, I'm actually feeling like a better developer these days because I'm getting so much more done in a shorter amount of time.

gjadi 5mo ago
You can't talk about delegation without talking about what and who you're delegating. Delegating a demo or an exploration to a junior is fine if you can help them with feedbacks and make them grow and the business is not on the line. Delegating a critical development to a senior engineer you've vetted on previous delivery is fine too. Delegating a critical development to a junior is a recipe for disaster. Now, I'm still trying to figure out what I can fully delegate to an agent and what I can't. Right now, LLM feel like a senior on technical stuff and a junior on decision/taste. One thing is sure, I can't delegate a critical development to it, not without review. For that review, I need programming skills. Maybe in the future that won't be the case, but I am not seeing that right now. (Using Claude code)

lenerdenator 5mo ago

The author is 100% right. I can feel myself just "wanting the job done" with agentic AI, and not understanding/knowing how the code works. That being said, I have deadlines I have to meet.

Natalia724 5mo ago

[flagged]

LAC-Tech 5mo ago

People are still letting LLMs generatr code for them? Clankers are for reading code, not for writing it.

k_plankenhorn 5mo ago

For people who couldn’t code at all before, AI coding tools don’t replace skill, they create access. My ability to build and retain the skills isn’t less because I didn’t have them to begin with pre-AI for coding. I can certainly say I’ve developed judgment. Knowing when the input is right, when to push back, when to rewrite. Maybe that’s the skill agentic coding builds for non-engineers?

gjadi 5mo ago

Interesting as I reach a similar pov. I just started with experimenting with the following workflow with Claude Code: - get a plan for whatever I want to do, iterating in plan mode until I am satisfied with the solution - before execution, I mark each phase that I want to do/learn about with /tutor-mode Tutor-mode is a SKILL I made to have the LLM guide and teach through questions and hints. So I delegate completely the boilerplate/build system/CI and switch to manual+aided by AI for specific implementation part of the code. I also keep a final validation step to me because I've experimented a few too many "sorry I told you I passed the test suite and I did, but the build failed and I didn't told you".