Live data from Hacker News

We should be more tired than the model

vickiboykis.com

131–140 of 168 posts

Re: We should be more tired than the model

#131
post #85

Earlier quoted context omitted.

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

Use the Python type hints. You don't need to be specific, they help a lot even when you have some 'anys' inside composed types.

Anyway, Python tools are usually capable of refactoring any code that isn't reflective or self-rewriting. There are places for those two, but those are very few and the AI won't have any idea how to work at those places either.

JavaScript is a problem.

Re: We should be more tired than the model

#132
post #46

Earlier quoted context omitted.

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

Pretend? I don't have to pretend, I haven't seen any real improvement. I wouldn't let the models of today write code one bit more than the models of several years ago, because they still suck at it.

Re: We should be more tired than the model

#133

Earlier quoted context omitted.

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, et…

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.

Re: We should be more tired than the model

#134
post #127

Earlier quoted context omitted.

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.

Sure it does. IntelliJ will do that just fine.

Re: We should be more tired than the model

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

> traditional automated refactoring tools any recommendations?

Whatever the most popular IDE is for any given language, probably.

Re: We should be more tired than the model

#136
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…

I've found that for super large but simple refactors, codex and Claude struggle and will just quietly stop doing what you asked it if it's a long running task.

I actually had better luck asking codex to write temporary sed scripts based on the requirements then apply them.

Re: We should be more tired than the model

#137

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

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

Re: We should be more tired than the model

#138

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

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

Re: We should be more tired than the model

#139

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

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.

Re: We should be more tired than the model

#140

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.

Funnily enough, my LinkedIn feed is full of managers who are ecstatic at being able to "code" again, so it applies to developers trapped in the role of a manager as well!
Post reply on HN