Live data from Hacker News

We should be more tired than the model

vickiboykis.com

121–130 of 168 posts

Re: We should be more tired than the model

#121
post #35

Earlier 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()"?

It is indeed. At individual level thinking folks like yourself can think and do better of course. But all these AI companies are now heavily leaning on enterprises. And there I see function renaming via AI, or extracting column from excel sheet is not rhetorical but normal day to day task.

Re: We should be more tired than the model

#122
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-detai...

Re: We should be more tired than the model

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

Re: We should be more tired than the model

#124
post #89

Earlier quoted context omitted.

don't LSPs and IDE's help with that?

I'm right there with you - prefer classic, deterministic tools wherever possible - but there's a limit. E.g. it's easy to rename a single getter from classic enterprise java `Foo getFoo() {..}` to a modern style `Foo foo() {..}` ... but to rename dozens of getters/setters across hundreds of classes is still tedious. Even harder would be to update your setters from `void setFoo(Foo f) { this.foo = f; }` to fluent-styl…

Not sure about LSP, but IntelliJ has had a "structural search and replace" feature for many years, and it can easily handle changes like the one in your second paragraph. It's conceptually like a regex search, but it matches language-specific AST subtrees instead of character sequences.

Re: We should be more tired than the model

#125

Another option is just not using an LLM at all.

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.

Businesses are going to regret going all in on AI. It'll take a couple more years before the cracks start to show.

Re: We should be more tired than the model

#126
post #35

Earlier 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()"?

> What's next? "Claude, rename the function doFoo() to performBar()"?

As an engineer: of course not, keyboards are more efficient.

Also as an engineer: of course, “tea, Earl Grey, hot”, or what are we even working for?

Re: We should be more tired than the model

#127

Earlier quoted context omitted.

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.

The languages I use the IDE literally does this for you, perfectly, deterministically. And instantly, certainly when compared to AI.

That doesn't update documentation or comments referring to the function. I prefer search-and-replace.

Re: We should be more tired than the model

#128
post #35
post #14

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 i…

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

> traditional automated refactoring tools

any recommendations?

Re: We should be more tired than the model

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

Re: We should be more tired than the model

#130
post #21

Earlier quoted context omitted.

It very much is. But it's a non-deterministic, more-lossy-than-usual abstraction: english to code.

2 different meanings of abstraction at work here.

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

Post reply on HN