Live data from Hacker News

We should be more tired than the model

vickiboykis.com

91–100 of 168 posts

Re: We should be more tired than the model

#91

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.

> What's our security story for XYZ?

lmao I hope I never use your products with anything sensitive ever

Re: We should be more tired than the model

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

Sometimes when I'm in the CLI and don't have a code editor open, I do this. Yes, it's lazy. But I also trust the model to check and update related things (tests, etc., while applying some judgement).

It's not unlike some managers who tell their teams to do something trivially easy that they could have done themselves.

(I'm not saying this is ideal and I'm not defending my laziness. It's just the current state of things.)

Re: We should be more tired than the model

#93

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

the tools are in their infancy, and very little out of the power the coding model provides has actually been tried yet

Re: We should be more tired than the model

#94

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

They do, though, through rising salaries.

Re: We should be more tired than the model

#95

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

The languages I use the IDE literally does this for you, perfectly, deterministically.

And instantly, certainly when compared to AI.

Re: We should be more tired than the model

#96
post #93

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

the tools are in their infancy, and very little out of the power the coding model provides has actually been tried yet

Agreed.

They're crude, and also implemented as a sidecar to the actual coding process. Just "hey go do this" which.. I mean... fine, it works, but it's not exactly helping with knowledge acquisition and maintenance.

Re: We should be more tired than the model

#97
post #89

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.

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-style `Parent foo(Foo f) { this.foo = f; return this; }` - I'd be surprised if there's an LSP action for that at all. (I'd love to be proven wrong though)

Re: We should be more tired than the model

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

What are some traditional automated refactoring tools that can do stuff like those tasks from the example?

https://www.jetbrains.com/help/idea/refactoring-source-code....

This has a list, but some of them that I've used extensively:

- Rename anything, can also do smart renames that apply patterns, deal with capitalization differences, pluralization, etc

- Move function, constant to a different file

- Change function signature, including adding, removing, reordering, and renaming arguments

- Turn a chunk of code into a constant, variable, or function, including replacing other similar patterns or calculations with the new constant/variable/function

- Inline any of the above.

- Replace a class with an interface, have the class implement the interface... same with field accesses

- Move functions up/down the type hierarchy

I'm sure there's others. This has all been there for at least a decade.

Re: We should be more tired than the model

#99

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.

Which languages, just out of interest?

Re: We should be more tired than the model

#100
post #99

Earlier quoted context omitted.

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

Which languages, just out of interest?

That should be most? Unless you do very weird stuff like using strings in JS to call functions, or reflection in C# and similar very special cases, any IDE can handle that.
Post reply on HN