Live data from Hacker News

We should be more tired than the model

vickiboykis.com

111–120 of 168 posts

Re: We should be more tired than the model

#111

The point about the UI affordances strikes me as very relevant. I find that the way I want to use LLMs in coding is not available. We have chatbots in a sidebar that will just generate code for you or, more helpfully, answer your questions. We also have inline LLM code completion, which I've turned off completely because they're incredibly noisy. What I want is something between those. My ideal use of LLMs while codi…

I've seen editors configured similar to how you describe. Varying from simple shadow-text style completion generated on command/keybind to more complex setups where you ask an external AI agent for a solution with it generating code that appears as shadow-text in editor with chat in the sidebar giving the reasoning behind it.

I agree the tools in general a big problem with current generation AI tools but there are options if you look around enough. Though you can burn a lot of time figuring out which ones are useful.

Re: We should be more tired than the model

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

Shift-F6 (rename refactor) is my goto, and what I miss most in a code editor (maybe LSPs support that today for most languages).

It also takes away the mental tax burden of thinking up good names for things when writing out code quickly on the first pass.

Works very well with PHP (in PHPStorm), and I'd expect somewhat similar reliability in PyCharm on a Python project with some type annotations (or maybe even with none?).

With the advent of LSPs and treesitter parser approach I wished to see higher level refactorings possible by now, but innertia in tooling space died down as most focus switched to LLMs.

Re: We should be more tired than the model

#113
post #38

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

I think the opposite, as agents approach human levels of coding and multiple agents work together as a team to code, and check that code in an adversarial manner, companies that do not adopt them will put out less code, of lower quality, for far more money.

There is no mitigation for that situation which would allow human coders to retain their place in the ecosystem.

A man can dig a ditch in a week for £500. 7 men can dig a ditch in a day for £700. 1 man and a digger can dig a ditch in a day for £250.

"But I use knowledge and my brain to do my job, my job is special!"

Not any more it isn't...

Re: We should be more tired than the model

#114

Earlier quoted context omitted.

The "right" abstraction seems like quite an art. Sometimes it's not obvious, or it takes multiple rounds of exploration and testing (I'm thinking here of the mental shift moving from HTML + JS, via jQuery, Backbone, Knockout and up to React/Vue or Angular). At all points, we thought we had reasonable abstractions for a while. Vue and Svelt, or NextJS, now are so far from the mental model of early 00s "DHTML". And I'm…

>> I’m losing control over the code I write when I work with agentic code generation > Are you saying we collectively need to get better at abstraction so that LLMs get better at abstraction (either by training, or our prompting), so that their code is easier to read? No - our current abstraction for coding agents is a loop where we express some freeform specification of a goal, then a sub loop kicks off where an llm…

[flagged]

Re: We should be more tired than the model

#115

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.

Re: We should be more tired than the model

#116
post #93

Earlier quoted context omitted.

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.

Ultimately, what is the point of knowledge acquisition and easy maintenance?

To make the work easier for humans to do.

What is the point of knowledge acquisition by humans and easy maintenance if an AI is doing the work?

Some people paint, but if you want to record a scene instantly you press a button on a camera. You don't need to know what the camera does to record the image, you don't need to know how to paint, or anything to do with image manipulation. The tool takes care of that for you. Humans have always offloaded work to machines any chance they get. Other humans have always cried that those tools are the end of human ability, from just writing in 370BC to the smartphone in 2007.

Re: We should be more tired than the model

#117
post #73

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

100% agreed

Re: We should be more tired than the model

#118
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. It's very hard to communicate why something is not as functional or why the UX isn't as good as it could be.

All this to say, I believe these are valuable questions, but we should be careful what presuppositions we bring into the equation. My value has never been my ability to write code. It's been my ability to make people's problems elegantly go away. I do not believe AI is making that worse (yet).

Side-note: If it IS making my skills worse... I'll just sharpen them later. It's not like experimenting with AI for a few years is going to permanently disable me.

Re: We should be more tired than the model

#119

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.

Yeah, VSCode will rename functions and vars perfectly, using the language semantics. It'll handle changing imports in python if you change file names.

Like you said, it's basically instant.

Re: We should be more tired than the model

#120
post #89

Earlier quoted context omitted.

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

Perhaps, but do they handle all the other aspects of refactoring, too?

Yes, LSPs can supply a variety of refactoring commands (rename, extract to, inline, etc.) that the LSP server can implement directly, deterministically, locally.
Post reply on HN