Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should be more tired than the model

vickiboykis.com

Post reply on HN
Print view View original

21–30 of 168 posts

Re: We should be more tired than the model

#21

Post by coldtea »

repelsteeltje wrote: post #15
CraigJPerry wrote: post #10

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

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.

Re: We should be more tired than the model

#22

Post by tolerance »

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.

Re: We should be more tired than the model

#23

Post by sixtyj »

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?

Re: We should be more tired than the model

#25

Post by cmrdporcupine »

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.

Re: We should be more tired than the model

#26

Post by docheinestages »

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?

Re: We should be more tired than the model

#27

Post by coldtea »

sam-cop-vimes wrote: post #6

> We should be more tired than the model I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools s…

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

Re: We should be more tired than the model

#28

Post by poszlem »

mettamage wrote: post #8
sam-cop-vimes wrote: post #6

> We should be more tired than the model I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools s…

That’s only true if companies give some of the productivity gains back to the employee, but most companies don’t do that. They keep the profits purely for themselves. There are some exceptions.

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.

Re: We should be more tired than the model

#30

Post by yondys »

trklausss wrote: post #4

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.
Post reply on HN