[oneeyedpigeon]

You cannot just reduce programming to "deliver working things", though. For some tasks, sure, "working" is all that matters. For many tasks, though, efficiency, maintainability, and other factors are important.

You also need to take into account how to judge if something is "working" or not — that's not necessarily a trivial task.

[lukan]

That is part of "deliver working things".

A car hold together by duct tape is usually not considered a working car or road save.

Same with code.

"You also need to take into account how to judge if something is "working" or not — that's not necessarily a trivial task."

Indeed, and if the examiner cannot do that, he might be in a wrong position in the first place.

If I am presented with code, I can ask the person what it does. If the person does not have a clue - then this shows quickly.

[jaggederest]

Completely agree. I'm judging the outputs of a process, I really am only interested in the inputs to that process as a matter of curiosity.

If I can't tell the difference, or if the AI helps you write drastically better code, I see it as no more nor no less than, for example, pair programming or using assistive devices.

I also happen to think that most people, right now, are not very good at using AI to get things done, but I also expect those skills to improve with time.

[oneeyedpigeon]

Sure, but the output of your daily programming work isn't just the code you write for the company. It's also your own self-improvement, how you work with others, etc. For the record, I'm not just saying "AI bad"; I've come around to some use of AI being acceptable in an interview, provided it's properly assessed.

[jaggederest]

> Sure, but the output of your daily programming work isn't just the code you write for the company. It's also your own self-improvement, how you work with others, etc

Agreed, but I as the "end user" care not at all whether you're running a local LLM that you fine tune, or storing it all in your eidetic memory, or writing it down on post it notes that are all over your workspace[1]. Anything that works, works. I'm results oriented, and I do care very much about the results, but the methods (within obvious ethical and legal constraints) are up to you.

[1] I've seen all three in action. The post-it notes guy was amazing though. Apparently he had a head injury at one point and had almost no short term memory, so he coated every surface in post-its to remind himself. You'd never know unless you saw them though.

[oneeyedpigeon]

I think we're agreeing on the aim—good results—but disagreeing on what those results consist of. If I'm acting as a 'company', one that wants a beneficial relationship with a productive programmer for the long-term, I would rather have [ program that works 90%, programmer who is 10% better at their job having written it ] as my outputs than a perfect program and a less-good programmer.

[jaggederest]

I take epistemological issue with that, basically, because I don't know how you measure those things. I believe fundamentally that the only way to measure things like that is to look at the outputs, and whether it's the system improving or the person operating that system improving I can't tell.

What is the difference between a "less good programmer" and a "more good programmer" if you can't tell via their work output? Are we doing telepathy or soul gazing here? If they produce good work they could be a team of raccoons in a trench coat as far as I'm aware, unless they start stealing snacks from the corner store.