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

The rise of judgement over technical skill

notsocommonthoughts.com

Post reply on HN
Print view View original

71–80 of 176 posts

Re: The rise of judgement over technical skill

#71

Post by thrwthsnw »

dgb23 wrote: post #35
ben30 wrote: post #6

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…

I want to add something to this which is rarely discussed. I personally value focus and flow extremely highly when I'm programming. Code assistance often breaks and prevents that in subtle ways. Which is why I've been turning it off much more frequently. In an ironic way, using assistance more regularly helped me realize little inefficiencies, distractions and bad habits and potential improvements while programming:…

Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents. Could also write really polished example code to communicate the style and architectural patterns and add full test coverage for it.

I do notice the same lack of flow when using an agent since you have to wait for it to finish but as others have suggested if you set up a few worktrees and have a really good implementation plan you can use that time to get another agent started or review the code of a separate run and that might lend itself to a type of flow where you’re keeping the whole design of the project in your head and rapidly iterating on it.

Re: The rise of judgement over technical skill

#72

Post by numpad0 »

prmph wrote: post #60
ben30 wrote: post #6

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…

What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…

Last week I was like, I might as well vibe code with free Gemini and steal his credit than researching something destined to be horrible as Android Camera2 API, and found out that at least me using this version of Gemini do better if I prompt it in a... casual language.

"ok now i want xyz for pqr using stu can you make code that do" rather than "I'm wondering if...", with lowercase I and zero softening languages. So as far as my experience goes, tiny details in prompting matter and said details can be unexpected ones.

I mean, please someone just downvote and tell me it's MY skill issue.

Re: The rise of judgement over technical skill

#73

Post by skydhash »

sokoloff wrote: post #66
prmph wrote: post #60

Earlier quoted context omitted.

What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…

I don’t think AI marks the end of software engineers, but it absolutely can grind out code for well specified, well scoped problem statements in quarter-minutes that would take a human an hour or so. To me, this makes my exploration workflow vastly different. Instead of stopping at the first thing that isn’t obviously broken, I can now explore nearby “what if it was slightly different in this way?” I think that gets…

> Instead of stopping at the first thing that isn’t obviously broken, I can now explore nearby “what if it was slightly different in this way?”

What? Software engineering is about problem solving, not finding the first thing that works and called it a day. More often than not, you have too many solutions and the one that's implemented is the result of a list of decisions you've taken.

> If it can make a dev team of 7 capable of making the thing that used to take a dev team of 8, that's around 15% less human coordination needed overall to get the product out.

You should really read the mythical man month.

Re: The rise of judgement over technical skill

#74

Post by stopthe »

overfl0w wrote: post #40

This reminds me of Asimov's Jokester story where the same themes are explored - there is an all-knowing computer but someone needs to ask the correct questions. "Early in the history of Multivac, it had become apparent that the bottleneck was the questioning procedure. Multivac could answer the problem of humanity, all the problems, if it were asked meaningful questions. But as knowledge accumulated at an ever-faster…

That chess metaphor didn't age well

Re: The rise of judgement over technical skill

#75

Post by [deleted] »

ben30 wrote: post #6

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…

[deleted]

Re: The rise of judgement over technical skill

#76

Post by lazide »

coffeefirst wrote: post #65
prmph wrote: post #60

Earlier quoted context omitted.

What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…

Indeed. All this “productivity” has not resulted in one meaningful open source PR or one interesting indie app launch, and I can’t square my own experience with the hype machine. If it’s not all hat and no cattle, someone should be able to show me some cows.

Why do that when they can ignore you and keep living in their bubble?

Re: The rise of judgement over technical skill

#77

Post by chasd00 »

Fr3dd1 wrote: post #10

Today, if someone uses LLMs for code generation, he/she will probably question the generated code and will put his own judgement above it. I am curious how fast that will change, especially for juniors. When will they start to question their own judgement and just go with the generated code becuase its "more safe"?

LLMs are very good at sounding right. I’m sure the code generated from them are rarely reviewed by junior developers. Even if they did question it i bet they give the LLM the benefit of the doubt. “Well the computer said this so it must be right otherwise it would be a bug and I bet Anthropic has caught all the bugs…”

Re: The rise of judgement over technical skill

#79

Post by AndrewKemendo »

steveBK123 wrote: post #62
ben30 wrote: post #6

This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…

So really the same two skills that a senior engineer needs to delegate tasks to juniors & review the results..

This is exactly how to use it and exactly why it’s a huge deal

In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling

All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc…

Re: The rise of judgement over technical skill

#80

Post by strgcmc »

steveBK123 wrote: post #70
skydhash wrote: post #69

Earlier quoted context omitted.

Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.

Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.

I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025).

Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.

Post reply on HN