Reading all the code the model generates will tire you out pretty quickly
We should be more tired than the model
81–90 of 168 posts
Re: We should be more tired than the model
#82Earlier quoted context omitted.
> 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.
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.
Re: We should be more tired than the model
#83Earlier quoted context omitted.
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…
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 pe…
I develop with a very custom neovim using only the keyboard. Over the years I've become really fast. And yet I'm doing it less and less myself and ask the LLM even small things. In my case the switch happened naturally as I moved to local AI and fully integrated the coding harness into my tmux + neovim workflow. Neovim becomes more of a project and file explorer, together with lazygit to diff review the changes.
Re: We should be more tired than the model
#84Earlier quoted context omitted.
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 pe…
Those 11 steps would probably take me 15 minutes. There are a lot of small refactorings that I wouldn't consider to be worth 15 minutes of my time, so I wouldn't do them. Outsourcing those to an agent means I don't have to make that tradeoff, which means I can get better quality code. But yes, for a lot of my work I'm now a Claude Code / Codex first developer. I run Zed so I can navigate the code and occasionally mak…
When you make the change on an IDE, you:
1 - Find the code
4 - Move the code
10 - Change the documentation
You don't do the other steps because it's deterministic and always correct.
Re: We should be more tired than the model
#85Earlier quoted context omitted.
Those 11 steps would probably take me 15 minutes. There are a lot of small refactorings that I wouldn't consider to be worth 15 minutes of my time, so I wouldn't do them. Outsourcing those to an agent means I don't have to make that tradeoff, which means I can get better quality code. But yes, for a lot of my work I'm now a Claude Code / Codex first developer. I run Zed so I can navigate the code and occasionally mak…
When you make the change on an IDE, you: 1 - Find the code 4 - Move the code 10 - Change the documentation You don't do the other steps because it's deterministic and always correct.
Presumably you're talking about statically typed languages? I mainly work in Python and JavaScript.
I don't trust any refactors until I've seen the test suite pass.
(OK, sure, "rename method" might be OK, but most of my refactors and design changes are more interesting than that.)
Re: We should be more tired than the model
#86Earlier quoted context omitted.
>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()"?
Yes, it's copy pasting but it's tedious and it adds up fast.
Even the doFoo to performBar is tedious because you need to catch all instances and your find/replace script strategy might have unintended victims.
In this case indeed, it's just much more convenient.
Re: We should be more tired than the model
#87Earlier quoted context omitted.
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…
I used JetBrains IDEs for years. The refactoring tooling was fancy find-replace as far as I recall? Pretty cool in 2015, though.
Re: We should be more tired than the model
#88Earlier quoted context omitted.
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 fun…
Question for you, since I also use Zig 0.16: how do you get it to use Zig idioms? I use Kimi 2.6, and I feel like whenever I try to get my agent to write modern Zig based on a C reference it decides to start writing everything in a C style (doesn't use defer, doesn't use opaque enums even when I explicitly tell it to, doesn't use Zig's error unions, swallows errors instead of asserting, and some more). It's quite fru…
I don’t, it is mostly used for ideas, review, etc…
Getting the agent to grep std, example code, comments that reference inaccessible security or bugs etc.. help a little.
But for my needs, not refactoring would just be stepping over dollars to pick up pennies.
But yes it is a problem.
Re: We should be more tired than the model
#89Earlier quoted context omitted.
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()"?
Yes, it's copy pasting but it's tedious and it adds up fast. Even the doFoo to performBar is tedious because you need to catch all instances and your find/replace script strategy might have unintended victims. In this case indeed, it's just much more convenient.
don't LSPs and IDE's help with that?
Re: We should be more tired than the model
#90Earlier quoted context omitted.
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 fun…
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.
Currently, with zig 0.16 the agent has to have access to the zig compiler and std library to even produce code that will compile.
If you have zig installed, you can run ‘zig std’ to see that.
You still have the limitations of attention etc…
Even zed’s agent will leverage that built in tarball, but it doesn’t solve the problem, especially as some of the languages killer features are unavailable in C and other languages.