[HN Gopher] The rise of judgement over technical skill
___________________________________________________________________
The rise of judgement over technical skill
Author : kohlhofer
Score : 217 points
Date : 2025-06-01 21:02 UTC (1 days ago)
(HTM) web link (notsocommonthoughts.com)
(TXT) w3m dump (notsocommonthoughts.com)
| crabl wrote:
| As the marginal cost of writing code decreases, the opportunity
| cost associated with writing the "right" code increases
| dramatically
| mehulashah wrote:
| I would argue that this is already true in roles where one
| supervises the work of another person with skill. Great leaders,
| for example, were once practitioners. Over time their skills may
| fade, but their judgment makes them effective and able to the
| scale their impact.
| drewcoo wrote:
| In software, we promote good engineers to management,
| effectively accelerating the Peter Principle.
|
| It doesn't have to be that way. Management skills are not an
| outgrowth of the skills of the managed, but orthogonal to them.
| This is similar to the lesson many PhD candidates I've known
| learn: expertise in their field is not pedagogical expertise.
| Companies who promoted from within used to provide training for
| new managers.
| apwell23 wrote:
| > In software, we promote good engineers to management
|
| i've not seen this. Infact its the opposite.
| paulluuk wrote:
| You've seen good managers promoted to engineers? ;) I have
| seen this happening, usually the engineers with the best
| technical AND people skills are first made lead developer,
| and eventually "team lead". After team lead they can climb
| the corporate ladder with titles like "junior vice
| president" or "senior director".
| bravesoul2 wrote:
| Does the technical skill give you better judgement though? Can a
| masterchef make better Star Trek replicator meals?
| kusokurae wrote:
| I think the reality is that, this notion of "democratising"
| various technical mediums is used to gloss over that, as
| countless studies have now evidenced, humans primarily learn
| and remember well thing by doing things, not merely passively
| consuming them. Fine-precision decision-making will likely
| always be the domain of dedicated tooling designed to better
| correspond with the particular medium or task -- that is,
| manual testing and experimentation, not relying on logocentric
| prompt idolatry.
|
| When we get into literature, visual art etc. it becomes more of
| a problem. You can't get Cormac McCarthies or Mars Voltas from
| software designed to give you perfect statistical 50% grey, and
| people who try and hack it without doing the reading, are going
| to end up writing gibberish. People who actually enjoy and like
| art, music whatever are going to grow Very bored with the
| overwhelming majority of work reliant of primarily generative
| methods, save for those who already have discretion learned
| through experience of many tools and other means of expression.
| 12112521312 wrote:
| Yes, really good pianist often compose music that is
| interesting, that other composers don't make ( e.g. Listz,
| Alkan ).
|
| In jazz, nothing can replace practicing your improv skills.
| drewhk wrote:
| Also, judgement alone might not be enough. Judgement can take
| you to "something is off", but not necessarily further. I mix
| music as a hobby and it takes a good amount of practice to
| step up from recognizing the presence of a problem to
| actually know where and how to fix it. If you don't know
| where you should look, you just aimlessly try various things,
| and it is not unusual to make the problem worse.
|
| Eventually you learn to properly recognize the problems, not
| just their presence, but their actual nature and
| implications. But this takes practice.
| ben30 wrote:
| 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 deep understanding of the domain, the
| codebase, and good software engineering principles. Ironically,
| while I can use AI to help with these tasks too, they remain
| fundamentally human judgment problems that sit squarely on the
| critical path to quality software.
|
| The technical skill of writing code has been largely
| commoditized, but the judgment to know _what_ to build and _how_
| to validate it remains as important as ever.
| gherkinnn wrote:
| That matches my experience.
|
| Decomposing a problem so that it is solvable with ease is what
| I enjoy most about programming and I am fine with no longer
| having to write as much code myself, but resent having to
| review so much more.
|
| Now, how do we solve the problem of people blindly accepting
| what an LLM spat out based on a bad prompt. This applies
| universally [0] and is not a technological problem.
|
| 0 - https://www.theverge.com/policy/677373/lawyers-chatgpt-
| hallu...
| ben30 wrote:
| Agreed on the review burden being frustrating. Two strategies
| I've found helpful for managing the cognitive load:
|
| 1. _Tight issue scoping_ : Making sure each issue is narrowly
| defined so the resulting PRs are small and focused. Easier to
| reason about a 50-line change than a 500-line one.
|
| 2. _Parallel PR workflow_ : Using git worktrees to have
| multiple small PRs open simultaneously against the same repo.
| This lets me break work into digestible chunks while
| maintaining momentum across different features.
|
| The key insight is that smaller, well-bounded changes are
| exponentially easier to review thoroughly. When each PR has a
| single, clear purpose, it's much easier to catch issues and
| verify correctness.
|
| Im finding these workflow practices help because they force
| me to engage meaningfully with each small piece rather than
| rubber-stamping large, complex changes.
| davnn wrote:
| > The key insight is that smaller, well-bounded changes are
| exponentially easier to review thoroughly.
|
| I am not sure if that is the real insight. It appears to me
| that most people prefer small, well-bounded changes, but
| it's quite tricky to break down large tasks into small but
| meaningful changes, isn't it? To me, that appears to be the
| key.
| dgb23 wrote:
| 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:
|
| I mean that in a very broad sense, including mindset, tooling,
| taking notes, operationalizing, code navigation, recognizing
| when to switch from thinking/design to programming/prototyping,
| code organization... There are many little things that I could
| improve, practice and streamline.
|
| So I disagree with this statement at a fundamental level:
|
| > The technical skill of writing code has been largely
| commoditized (...)
|
| In some cases, I find setting yourself up to get into a flow or
| just high focus state and then writing code very effective,
| because there's a stronger connection with the program, my
| inner mental model of how it works in a more intricate manner.
|
| To me there are two important things to learn at the moment:
| Recognizing what type of approach I should be using when and
| setting myself up to use each of them more effectively.
| thrwthsnw wrote:
| 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.
| bluefirebrand wrote:
| > 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
|
| This doesn't work because you still have to read and verify
| all of the stuff your agents produce
|
| So the new workflow is: Move up an abstraction level to use
| an agent to produce code Then move down an abstraction
| level to review the code it produces
|
| This sounds like way more cognitive overhead and way harder
| (and therefore probably slower) to do than just writing the
| code by hand in a good flow
| dgb23 wrote:
| There's something fundamentally different between writing
| the program directly that you visualize in your head versus
| staying one level away and reviewing someone else's code.
| I'm really talking about the former.
| prmph wrote:
| 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 some magic sauce for
| prompting, they should post a session or chat that can be
| verified by other (even if not exactly repeatable).
|
| Yesterday almost my whole day was wasted because I chose to
| attack a problem primarily by using Claude 4 Sonnet. Having to
| hand hold it every step of the way, continually keep correcting
| basic type and logic errors (even ones I had corrected
| previously in the same session), and in the end it just could
| solve the challenge I gave it.
|
| I have to be cynical and believe those shouting about LLMs
| taking over technical skill must have lots of stock in the AI
| companies.
| coffeefirst wrote:
| 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.
| lazide wrote:
| Why do that when they can ignore you and keep living in
| their bubble?
| DontchaKnowit wrote:
| I find this hard to believe- how would you even know if
| someone used AI in producing a PR or indie product? Are you
| omniscient?
|
| Further, there are articles here on HN all the time about
| people using AI for actual serious work. Heres a pretty
| significant example :
|
| https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-
| cve-...
| tonyedgecombe wrote:
| >I can't square my own experience with the hype machine.
|
| Me neither. My gut feeling is it's the inexperienced who
| gain the most from generative AI. That does seem to be
| confirmed by papers like this:
|
| https://mitsloan.mit.edu/ideas-made-to-matter/workers-
| less-e...
|
| At most I've found it helps with some of the routine work
| but saving a few minutes typing doesn't offset the problems
| it creates.
| PeterStuer wrote:
| I find it hard to believe the inexperienced would benefit
| at all. Ai assisted coding requires serious general
| experience in all matters software to get good value out
| of it.
| azeirah wrote:
| I dunno, as an engineer who likes to make side projects, I
| can say with high certainty that LLMs have helped me
| compensate for things I'm worse at when coding a product.
|
| I'm good at the engineering side of things, I'm good at UI,
| I'm good at UX, I'm good at css, I'm just not good at
| design.
|
| So I tell the LLM to do it for me. It works incredibly
| well.
|
| I don't know if it's a net increase in productivity for me,
| but I am absolutely certain that it is a net increase in my
| ability to ship a more complete product.
| coffeefirst wrote:
| That makes perfect sense to me. I'm finding real value in
| natural language search for code and docs, and "remind me
| how to do X."
|
| It's the extraordinary claims of 10x speed and crazy
| autopilot that have me looking around for missing cows.
| sokoloff wrote:
| 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 to a better outcome faster in perhaps
| 10-25% of software engineering work. That's huge and today is
| the least capable these AI assistants will ever be.
|
| Even just the human/social/mind-meld aspects will be
| meaningful. 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. (This might even turn out to be half the benefit of
| productivity enhancing tools.)
| skydhash wrote:
| > _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.
| sokoloff wrote:
| I credit my understanding of the incredible costs
| relating to the increased need for coordination and the
| sharply decreasing return on productivity for additional
| people to _The Mythical Man Month_.
|
| I don't take credit for the value of being able to do
| with 7 what currently takes 8, but rather ascribe it to
| the ideas of Fred Brooks (and others).
| numpad0 wrote:
| 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.
| schindlabua wrote:
| I totally just verbalize my inner monologue, swearing and
| everything. Sometimes I just type "weeeeeeeelllllll" and
| send it, to get more LLM output or to have it provide
| alternatives.
|
| It might sound weird but I try to make the LLM comfortable.
| Because I find you get worse results when you point out
| mistake after mistake and it goes into apologetic mode.
| Also because being nice puts me in a better mood and it
| makes my own programming better.
|
| vibe coding as it were :p
| sgarland wrote:
| > Yesterday almost my whole day was wasted because I chose to
| attack a problem primarily by using Claude 4 Sonnet
|
| I have been extremely cynical about LLMs up _until_ Claude 4.
| For the specific project I 've been using it on, it's done
| spectacularly well at specific asks - namely, performance and
| memory optimization in C code used as a Python library.
| ofjcihen wrote:
| It's interesting that your point about wasting time makes a
| second point in your favor as well.
|
| If you don't have the knowledge that begets the skills to do
| this work then you would never have known you were wasting
| your time or at least how to stop wasting time.
|
| LLM fanboys don't want to hear this but you can't
| successfully use these tools without also having the skills.
| whatarethembits wrote:
| Honestly, its mind boggling. Am I the worst prompter ever?
|
| I have three python files (~4k LOC total) that I wanted to
| refactor with help from Claude 4 (Opus and Sonnet) and I
| followed Reed Harper's LLM workflow...the results are
| shockingly bad. It produces an okay plan, albeit full of
| errors, but usable with heavy editing. In the next step
| though, most of the code it produced was pretty much
| unusable. It would've been far quicker for me to just do it
| myself. I've been trying to get LLMs on various tasks to help
| me be faster but I'm just not seeing it! There is definitely
| value in it in helping to straighten out ideas in my head and
| using it as StackOverflow on roids but that's where the
| utility starts to hit a wall for me.
|
| Who are these people who are "blown away" by the results and
| declaring an end to programming as we know it? What are they
| making? Surely there ought to be more detailed demos of a
| technology that's purported to be this revolutionary!?
|
| I'm going to write a blog post with what I started with,
| every prompt I wrote to get a task done and responses from
| LLMs. Its been challenging to find a detailed writeup of
| implementing a realistic programming project; all I'm finding
| is small one off scripts (Simon Willison's blog) and CRUD
| scaffolding so far.
| schindlabua wrote:
| I think you're supposed to let the AI write the bad python
| code and then do the refactoring yourself. No way I'm
| letting the AI make changes to 150 files with tons of
| cross-concerns when I don't even fully understand it all
| myself unless I dig into the code.
|
| That being said copilot and chatgpt have been a 40%
| productivity boost at least. I just write types that are as
| tightly fitting as possible, and segregate code based on
| what side effects are going to happen, stub a few function
| heads and let the LLM fill in the gaps. I'm so much faster
| at coding than I was 2-3 years ago. It's like I'm designing
| the codebase more than writing it.
| prmph wrote:
| I couldn't agree more. This has been my exact experience.
|
| Like you I'll probably write a blog post and show, prompt
| by prompt, just how shockingly bad Claude frequently is.
| And it's supposed to be one of the best at AI assisted
| coding, which mean the others are even worse.
|
| That'll either convince people, match their experiences, or
| show me up to be the worst prompter ever.
| nyarlathotep_ wrote:
| > I have to be cynical and believe those shouting about LLMs
| taking over technical skill must have lots of stock in the AI
| companies.
|
| I'm far from being a "vibe" LLM supporter/advocate (if
| anything I'm the opposite, despite using Copilot on a regular
| basis).
|
| But, have you seen this? Seems to be the only example of
| someone actually putting their "proompts" where their mouth
| is, in a manner of speaking.
| https://news.ycombinator.com/item?id=44159166
| prmph wrote:
| Edit for the parent comment:
|
| > in the end it just could NOT solve the challenge I gave it.
| steveBK123 wrote:
| So really the same two skills that a senior engineer needs to
| delegate tasks to juniors & review the results..
| skydhash wrote:
| 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.
| steveBK123 wrote:
| 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.
| strgcmc wrote:
| 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.
| skydhash wrote:
| > _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_
|
| That's when experienced developers are a huge plus. They
| know how to cut corners in a way that will not hurt that
| much in the long term. It's more often intern level that
| are proposing stuff like next.js, kubernetes, cloud-
| native,... that will grind you to a halt once the first
| bugs appear.
|
| A very small team of good engineers will get you much
| further than any army of intern level coders.
| steveBK123 wrote:
| Yeah "actually good engineers" are like a 10:1 ratio with
| intern/new college hire/junior consultant level.
|
| Not to generalize too much but if you are contracting out
| to some agency for junior levels, you are generally
| paying markup on coders who couldn't find better direct
| hire jobs to start with. At least with mid/senior level
| you can get into more of a hired-gun deal for someone who
| is between gigs/working part time/buy a share of their
| time you couldn't afford full-time.
|
| In fact most junior consultants you are basically paying
| for the privilege to train other peoples employees who
| will then be billed at a higher rate back to you when
| they improve.. if they don't move on otherwise.
| lolinder wrote:
| > but OTOH "never improve much" seems unrealistic, given
| the insane progress of the field in the last 3ish years
|
| The point is that no one should hire an intern or a
| junior because they think it will improve their team's
| productivity. You hire interns and juniors because
| there's a causal link between "I hired an intern and
| spent money training them" and "they joined my company
| full time and a year later are now productive,
| contributing members of the team". It's an investment in
| the future, not a productivity boost today.
|
| There _is no causal link_ between "I aggressively
| adopted Claude Code in 2025" and "Claude Code in 2026
| functions as a full software engineer without
| babysitting". If I sit around and wait a year without
| adopting Claude Code that will have no measurable impact
| on Claude Code's 2026 performance, so why would I adopt
| it now if it's still at intern- or junior-level skill?
|
| If we accept that Claude is a junior-level contribution
| then the rational move is to wait and watch for now and
| only adopt it in earnest if and when it uplevels.
| steveBK123 wrote:
| Precisely - AI getting better or not has nothing to do
| with my burning cycles using it. My juniors do improve
| based on my effort. I can free ride on AI getting good
| enough later (wait) whereas I cannot with my own team of
| juniors.
|
| > 1 technical founder and a team of contract labor,
| trying to build that first MVP or cranking out early
| features in a huge rush
|
| Having worked in environments with a large number of
| junior contractors... this is generally a recipe for a
| lot of effort with resulting output that neither works
| technically nor actually delivers features.
| PeterStuer wrote:
| "hired an intern and spent money training them" and "they
| joined my company full time and a year later are now
| productive"
|
| Why would I do that if I can have sombody else pay for
| the training then poach them when they are ready?
| lolinder wrote:
| Which is exactly why no one's hiring juniors anymore. It
| made sense back when the market for hiring engineers was
| super competitive and it was easier to gamble on being
| able to keep a junior than it was to try to snag a
| senior. But now that there are seniors galore on the
| market who would bother with a junior?
| ironman1478 wrote:
| What are you doing to actually keep them at your company?
| I left a company after they invested a lot in training
| me. They gave me very little raises and already paid
| poorly, no guaranteed bonus, bad vacation hours, and no
| opportunities for promotion. They were shocked when I
| left, even though I had asked for very modest raises and
| was way more productive than the "seniors" at the
| company.
|
| Most companies outside of FAANGs treat their talented
| juniors like crap, so of course they'll leave.
| skydhash wrote:
| > _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._
|
| And mostly their output is not really about incorrect
| code, but more likely incorrect approaches. By reviewing
| their code, you find gaps in their knowledge which you
| can then correct. They're here to learn, not to produce
| huge amount of code. The tasks are more for practice and
| evaluation than things you critically need.
|
| I don't want to work with a junior, but I'm more than
| happy to guide them to be someone I can work with.
| AndrewKemendo wrote:
| Disagree. Some learn, not all and decreasing numbers career
| to learn
|
| Also most juniors have no idea how to write tests, plan for
| data scale, know which IPC-RPC combo is best for
| prototyping vs production
|
| Etc...
|
| 90% of software is architecture and juniors don't architect
| macNchz wrote:
| > Disagree. Some learn, not all and decreasing numbers
| career to learn
|
| This is an organizational issue then--someone who is
| operating at a junior level who demonstrates that they
| don't care to learn should be let go.
| AndrewKemendo wrote:
| We're saying the same thing
|
| The business threshold (willingness to pay for something)
| for the worst automation will eventually beat the
| marginal expert.
|
| So there becomes no business differentiation between a
| junior and a middle engineer
|
| "Architecture" becomes the entry-level job
| PeterStuer wrote:
| But they are so cheap, and they increase the headcount on
| my pfiefdom chart.
| steveBK123 wrote:
| Yes, a combination of empire building and "but $X exceeds
| the $Y cap set by HR for Z role! / we can hire XX juniors
| for this price!" type of mega corp thinking.
| CodeMage wrote:
| Bingo! Not to mention that "dealing with juniors" is one of
| the critical ways for a senior engineer to grow.
| AndrewKemendo wrote:
| 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...
| coldpie wrote:
| > 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...
|
| Hm, interesting. As someone who has found zero joy and
| value in using LLMs, this rings true to me. Setting aside
| the numerous glaring errors I get every time I try to use
| one, even if the tools were perfect, I don't think I would
| enjoy using them. I enjoy programming, thinking about how
| to break down a problem and form abstractions and fit those
| into the tools the language I'm writing in gives me. I
| enjoy learning and using the suite of Unix tools like grep
| and sed and vim to think about how to efficiently write and
| transform code. The end product isn't the fun part, the fun
| part is _making_ the end product. If software engineering
| just becomes explaining stuff in English to a machine and
| having some software pop out... then I think the industry
| just isn 't for me anymore. I don't want to hand the fun
| part over to a machine.
|
| It's like how I enjoy going to my wood shop to build tables
| instead of going to Ikea. It would be cheaper and faster
| and honestly maybe even better quality to go to Ikea, but
| the joy is in the knowledge and skill it takes to build the
| table from rough lumber.
| AndrewKemendo wrote:
| Software at scale is a business function
|
| You're describing a hobby/artistry process
|
| You can still do all that, the same way that you can
| still build a table at your house.
|
| But the number of number of handmade table builders is
| going to drop to effectively zero for the majority of
| table building going forward
| coldpie wrote:
| I'm not sure I agree that _will_ happen, but if it does,
| then yeah like I said, it 's probably my cue to exit the
| industry. If the fun goes out of the job, there's other
| things I'd rather do than sit inside alone and stare at a
| screen all day.
| PeterStuer wrote:
| "As someone who has found zero joy and value in using
| LLMs"
|
| I love programming but find zero joy in front-end coding.
| For me LLM's solved that bit nicely. I'm sure a real
| webdev would do better, but I can't afford it for my
| personal projects and the LLM helped me to get it done
| more than good=enoug for my needs.
| CodeMage wrote:
| > 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...
|
| How will you make new senior, staff, and principal
| engineers without "having to deal with a junior"?
| AndrewKemendo wrote:
| You don't in the long term
|
| It's just like "calculator" used to be a manual human job
| in engineering
|
| Los Alamos, NASA etc... literally had 100s of individual
| humans running long calculations that computers didn't
| have the memory to handle
|
| There are no more human computers
| PeterStuer wrote:
| You hire seniors from other companies ofc.
| TaupeRanger wrote:
| That's a narrow view of the issue described in the blog post.
| You're coming at this from the perspective of a software
| engineer, which is understandable given the website we're
| posting on, but the post is really focusing on something higher
| level - the ability to decide whether the problems you're
| decomposing and the code you're reviewing is for something
| "good" or "worthwhile" in the first place. Claude could
| "decompose problems" and "review code" 10x better than it
| currently does, but if the thing it's making is useless,
| awkward, or otherwise bad (because of prompts given by people
| without the qualities in the blog post), it won't matter.
| eweise wrote:
| "these require deep understanding of the domain, the codebase,
| and good software engineering principles" Most of this AI can
| figure out eventually, except maybe the domain. But essentially
| software engineering will look a lot like product management in
| a few years.
| virgilp wrote:
| As a (very good I would say) product manager once told me -
| the product vision and strategy depends very much on the
| ability to execute. The market doesn't stand still, and what
| you _can_ do defines very much what you _should_ do.
|
| What I mean to say here is that not even product management
| is reduced to just "understand the domain" - so it kinda'
| feels that your entire prediction leans on overly-simplified
| assumptions.
| bcrosby95 wrote:
| This would be at least the third time in history we've tried to
| shunt writing code to low paid labor. We'll see if it's
| successful this time.
|
| The problem tends to be that small details affect large details
| which affect small details. If you aren't good at both you're
| usually shit at both.
| mlinhares wrote:
| The problem wasn't low paid labor, it was just incompetent
| labor. You can find competent developers in all these
| countries offering lower pay, India, Brazil, Romania, Poland,
| China, Pakistan, its just that they would already be hired by
| other higher paying companies and what is left for the ones
| that are looking for the lowest paid possible workers are the
| incompetent ones.
| Suppafly wrote:
| >its just that they would already be hired by other higher
| paying companies and what is left for the ones that are
| looking for the lowest paid possible workers are the
| incompetent ones
|
| Reminds of me working in IT. One company tried to outsource
| my job to India five different times before they were
| mostly successful at it. The companies that are successful
| aren't the ones that assume it'll cost 1/10th the price,
| they are the ones that know it'll cost 60+% of the price
| and still require some handholding.
|
| If you're hiring on price alone, you're already selecting
| the pool that doesn't contain the most competent labor.
| wvoch235 wrote:
| IMO attempts to make it low paid work will fail, just like
| almost every STEM profession. But... the number of engineers
| that we need who operate as "power multipliers" on team will
| continue to decrease. Many startup and corporate teams
| already aren't needing junior/mid level engineers any longer.
|
| They just need "drivers", senior/lead/staff engineers that
| can run independent tracks. AI becomes the "power multiplier"
| in the teams who amplify the effects of the "driver".
|
| Many people pretend that 10x engineers don't exist. But
| anyone who has worked on an adequately high performing team
| at a large (or small) company knows that skill, and quite
| frankly intelligence, operate on power laws.
|
| The bottom 3 quartiles will be virtually unemployable. Talent
| in the top quartile will be impossible to find because
| they're all employed. Not all that unlike today, though which
| quartile you fall into is largely going to depend on how
| "great" of an engineer you are AND how effectively you use
| AI.
|
| As this happens, the tap of new engineers who are learning
| how to make it into the top quartile, will cutoff for
| everyone except for those who are passionate/sadistic enough
| to programming without AI, then learn to program WITH AI.
|
| Meanwhile the number of startups disrupting corporate
| monopolies will increase as the cost of labor goes down due
| to lower headcount requirements. Lower head counts will lead
| to better team communication and in general business
| efficiency.
|
| At some point the upper quartile will get automated too. And
| with that, corporate moats evaporate to solo-entrepreneurs
| and startups. The ship is sinking, but the ocean is about to
| boil too. When economic formulas start dividing by zero, we
| can be pretty sure that we can't predict the impact.
| esafak wrote:
| You still need to be able to code to recognize when it's done
| poorly, and to write the technical specification.
| smitty1e wrote:
| Grok3: "The phrase "There is no royal road to geometry" is
| attributed to the ancient Greek mathematician Euclid. According
| to historical accounts, particularly from the philosopher
| Proclus, Euclid reportedly said this to Ptolemy I Soter, the
| ruler of Egypt, when the king asked if there was a shorter or
| easier way to learn geometry. Euclid's response emphasized that
| geometry, like any rigorous discipline, requires effort and
| dedication, with no shortcuts even for royalty."
|
| You can use AI as a royal road, but it may or may not prove an
| effective substitute for the learning required to provide
| judgement.
| monero-xmr wrote:
| Nothing stopped anyone from hiring 10 to 100 offshore devs for
| every American software dev for the last 20 years. Yet Google,
| Amazon, Microsoft, and so on paid top dollar for the Americans.
|
| And American business still pays top dollar. Even more than
| before. The judgement was always the problem. If the issue was
| bodies in seats the problem was already solved.
|
| The #1 cause of layoffs in America is offshoring caused by Zoom
| and other telework tools perfected during COVID. AI is a
| convenient excuse.
|
| Pop music is mostly _not_ about music quality - hits are always
| passable - but about celebrity. The rare song that elevates a new
| artist quickly converts them into celebrity, which converts
| future songs in their style into further hits 100,000x easier
| than before. Maybe even 1 billion times easier than before given
| the amount of songs created every year. Yet AI is supposedly an
| expert at generating music, and images, and video, and code, and
| on and on.
|
| I'm not seeing the evidence of layoffs from AI. I'm seeing
| evidence of better productivity from existing employees, which is
| the same result of every groundbreaking technology since all
| time.
| MangoToupe wrote:
| > Pop music is mostly not about music quality - hits are always
| passable - but about celebrity.
|
| Interesting and bold statement. How do you distinguish the two?
| kusokurae wrote:
| Worth mentioning here that historically a lot of the famous
| pop hits have had plenty of interesting technical decisions
| typically only a mature composer would come up with. Weird
| short bars, time signature stuff, temporary key changes,
| weird jazz chords etc. You don't notice them because they're
| refined choices.
| monero-xmr wrote:
| Whatever schlock Taylor Swift manufactures next will be a
| global hit. Doesn't matter the quality
| triceratops wrote:
| It would be an interesting experiment to have a global
| music star do a Richard Bachman.
| simianwords wrote:
| Empirically: by randomly asking N participants to rate pop
| music made by a celeb and by an indie band and observing if
| these participants were able to identify the celeb
| statistically.
| CuriouslyC wrote:
| The thing that stopped people from hiring 10-100 offshore devs
| per American dev lead/architect was communication primarily,
| with quality floor being an additional factor. Plenty of
| American companies have "hired 10-100 offshore devs" per
| American lead/architect, but they call it a foreign office,
| they solve the communication problem by having on-site managers
| that can serve as proxies, and they solve the quality floor
| problem by having the office in countries where the locals have
| strong expertise.
|
| If AI can solve the communication and quality floor problems
| (it's pretty close), having 100 agents per dev lead/architect
| becomes perfectly viable.
| aleph_minus_one wrote:
| > they solve the communication problem by having on-site
| managers that can serve as proxies, and they solve the
| quality floor problem by having the office in countries where
| the locals have strong expertise.
|
| I think this problem goes deeper: there exist lots of
| countries where people are strong in programming, but from my
| work experience, the whole "programming culture" (how to
| approach problems; how to structure the program; ...) differs
| quite a bit between countries. So, from other countries you
| can get great programs, but the style can differ quite a bit
| from what you are used to.
| Fr3dd1 wrote:
| 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"?
| kusokurae wrote:
| At present, when juniors do this at my company, they usually
| get fired within the month. The onboarding docs now explicitly
| state that though code review is a joint-responsibility
| process, you as the submitter are responsible for understanding
| it, ensuring it all works, and being aware of the broader scope
| and consequences. Maybe many companies have placed more
| responsibility on the reviewier to catch problems in the past?
| Fr3dd1 wrote:
| I would go a step further and dont let juniors use LLMs for
| code generation. The purpose and your role as a junior is to
| not only work but also to learn. When using genrated code,
| you miss a lot of opportunities to do so. Of course you could
| learn of some other methods or stuff from the frameworks you
| are using but imho thats not that big of an advantage.
| Animats wrote:
| Probably when the generated code is, on average, better than
| human-generated code. Somewhere between 1 and 10 years out.
| chasd00 wrote:
| 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..."
| roenxi wrote:
| Human judgement is like a house built on sand, it is basically
| provably feeble [0]. I've literally never in practice seen a
| human update their beliefs using Bayes' formula. I suspect we'll
| find that at some point fairly soon AIs will just have better
| judgement than us because they can be programmed to incorporate
| formal statistical concepts while humans have to rely on evolving
| grey goop which we haven't quite mastered. I imagine it'll be
| almost comical watching human experts going up against a system
| that can actually intuit the difference between a 60% and 70%
| chance of something happening in their risk calculations.
|
| Humans will still have a role expressing preferences and
| subjective questions though. Questions like "how much risk do you
| want your investments to take?" or "does this look good?"
| ultimately can't be answered by AIs because they depend on the
| internal state of a human.
|
| [0] See also, the academic field of psychology
| bsder wrote:
| > I've literally never in practice seen a human update their
| beliefs using Bayes' formula.
|
| Then you've never debugged anything genuinely difficult.
|
| Moving from "Where did I screw up in my code?" to "Is this
| library broken?" to "Wait, that's not possible. Let's look at
| the compiler output on Godbolt." to "Are you kidding me? The
| SPI system returns garbage in the last bit for transactions of
| 8n+1 bits?" (BTW, Espressif, please fix that in the C6.
| Kthxbye.) is all about establishing ground truth and adjusting
| your Bayesian priors as you gather evidence.
| Corey_ wrote:
| Humans may not update like Bayesians, but we read context,
| shift priorities, and act under pressure. Judgment isn't just
| math -- it's lived experience, intuition, and meaning in
| motion. That's still hard to replicate.
| CleverLikeAnOx wrote:
| This blog post shows how not to use AI. The author would have
| been unlikely to write such a uselessly redundant conclusion if
| they had to type it themselves.
|
| Edit: I like the post, but it didn't need to be padded with
| fluff.
| Veen wrote:
| We shouldn't be too quick to jump to "AI did it." People write
| redundant paragraphs and sentences in articles all the time
| because they're led to believe that every article needs a
| conclusion that sums up what's already been said. Ironically,
| including one in this article showed a lack of good judgment,
| which isn't confined to AIs.
| QuadmasterXLII wrote:
| It does show an interesting second order downside of publicly
| using an LLM for anything: it raises everyone else's
| suspicion that the rest of your work is LLM generated.
| SoftTalker wrote:
| A certain amount of redundancy can be helpful. If you explain
| the same thing two different ways, one way might make more
| sense than the other to a particular reader. The judgement
| comes in because you should not just be doing this by rote or
| because you were "lead to believe" it was necessary, but in
| consideration of who you are writing for.
| wiseowise wrote:
| Where do you think LLMs learn to write "uselessly redundant
| conclusion"?
| westcoast49 wrote:
| Music was never an issue of skill. You might have _needed_ skill
| in order to get to the point where you could use your judgement,
| but skill was never the deciding factor. So, I don 't agree with
| Brian Eno's point that there has been some kind of seismic shift
| when it comes to this. Rather, it's just a matter of a shift in
| the _type of skill_ that you need to have. The same is probably
| true when it comes to AI tools within the field of programming.
| drewcoo wrote:
| Getting a seat in a symphony involves skill. Brian Eno didn't
| just do rock.
| Tarq0n wrote:
| Ever seen a photoshop expert at work? Every human endeavor
| has a skill distribution. Hammering in a nail takes skill.
| westcoast49 wrote:
| I'm just arguing that there has been no qualitative shift.
| The skills you need to produce pop music today are different
| than the skills that you needed before. Now you need to be
| able to operate a MIDI sequencer or a program like Ableton,
| which is not necessarily easier in and off itself, than for
| instance learning how to play a guitar. I think it's the same
| with AI tools and programming. We're just talking about a
| different set of skills that you need in order to be
| competitive. I don't think there has been any real shift from
| "skill needed" to "judgement needed". I think this
| relationship remains the same, both for pop music and
| programming, but also for the example of playing an
| instrument in a symphony orchestra.
| physicsguy wrote:
| A similar debate has happened in education where people seem to
| think that having ability to critically analyse texts is more
| important than knowledge. and to some degree that's true but
| personally I think that without building on some decent level of
| foundational level of knowledge and having a mental model of a
| subject, you can't tackle thorny questions because you don't have
| enough to draw upon as examples and counterpoints about how to
| proceed.
|
| My current employer is currently going on a top down driven "one
| tech" mission and trying to rationalise the technology stacks
| across diverse product lines. Which is all fine but the judgement
| is a poor one because the biggest developer bottleneck that comes
| up in internal developer surveys is the corporate mandated IT
| things and a relatively hostile setup without even local admin
| rights, which make sense for general office workers and don't
| make sense at all for software developers.
| Wololooo wrote:
| Reminds me of that concept that I saw pop up in HEP in recent
| years between "users" and "experts".
|
| This distinction in that case is so dumb I cannot wrap my head
| around it: You first encounter the code, are unfamiliar with it
| but very quickly you become expert in order to solve your
| problem and advance the thing forward.
|
| It does not matter which codebase you start on, what matters is
| that you understand what the actual stack does and what is
| involved in there because people are supposed to understand
| deeply what they are doing.
|
| But this comes from the "corporatisation" of every single
| entity, where random metrics are used in order to assess
| performance instead of asking the simple question of "does it
| work" or "does it need fixing" or "will this thing break".
|
| There is a clear disconnect between the manager type people
| that are removed from the work and the managers still doing
| things practically, which understand what the stressors are and
| where some work of deep understanding and extra
| contextualisation of the systems, is required, in order to not
| mess the whole thing up.
|
| This being said, this is coming from a very peculiar
| perspective and with a very specific tech stack which is and is
| not industry standard at many levels...
| kragen wrote:
| High-energy physics?
| Wololooo wrote:
| Yes, sorry I should not have abbreviated that...
| Professional deformation...
| kragen wrote:
| Pas de probleme, merci beaucoup!
| mihaaly wrote:
| Education itself is supposed to teach us learning, not the mere
| facts/methods, not just the hard knowledge. Hard knowledge
| comes with it anyway as some sort of 'side product'. You cant
| learn on nothing, something will be used for it, that something
| forms the hard knowledge eventually. Typically broad set but
| shallow hard knowledge.
|
| Ironicly, this is what I feel chipping away in modern
| collaborative developments. The appreciation of learning
| capability. In the self interest of the organization (short
| term self interest, long term is too unpredictable, so does not
| exists in the practice) specific technical knowledge parcticed
| individuals are sought out for the purpose of easy replacement:
| not to be dependent on personnel, have it like a plug and play
| component. The ability to learn is not valuable while inside
| the organization. Should be practiced enough for years
| beforehand and applied intensely after joined. For the sake of
| claiming evolving organization the teaching may be outsourced
| in a very limited time to some sort of external enterprise
| making money on disseminating hard knowledge with made up
| examples or generic (artificial) applicability, instead of
| doing it in the actual context of the organization. Be part of
| the organization. Daily. Application of the new hard knowledge
| in the specific context of the organization will be casual by
| the random enthusiast. If they can break through of the company
| policy and established ways of management. Eventually the
| policies and practicies must be rigid as well, shouldn't they,
| so the personnel working in the management could be as easily
| replacable as the foot soldiers of code. For the sake of the
| organization. Call this approach the Organization Oriented
| Development.
| physicsguy wrote:
| > You cant learn on nothing, something will be used for it,
| that something forms the hard knowledge eventually. Typically
| broad set but shallow hard knowledge.
|
| As a counterpoint though, the way things have gone in the
| U.K. is to go deep on niche topics without building up
| appreciation of the broad strokes. To give an example,
| there's a GCSE History course for 14-16 year olds where the
| syllabus is effectively "medicine through time" and "the
| American West" without ever going near the British Empire,
| colonialism, the Tudor or Elizabethan periods, the
| reformation, the Industrial Revolution, Irish home rule and
| independence, etc. etc. any one of which gives much more
| insight into the formation of the state and cultural affairs
| as it stands today.
|
| To my mind it's too narrow a focus at too young an age when
| teaching a subject that a lot of children take. It also means
| there are constantly "we don't even teach that at school"
| debates.
| dsjoerg wrote:
| > a relatively hostile setup without even local admin rights
|
| Taking a diversion into this -- how about local admin rights to
| a virtual VM / sandboxed machine? I imagine that would allow
| developers to be productive, while protecting everything that
| IT wants to protect.
|
| Once you do that, I imagine everyone will discover the issue
| isn't actually _local_ admin rights, but having admin rights to
| a machine that's on the internal network and can access
| internal company resources. Which might mean that IT has taken
| a strategy that once you're inside the local network, you have
| access to lots of valuable goodies. Which is a scary strategy.
| wg0 wrote:
| The problem is - you can't judge if you're not skilled.
|
| So still, get skilled. Learn everything first hand. Try to master
| it.
|
| That's how our species prevailed in the first place.
| hinkley wrote:
| CERT advisories are evidence that skill is necessary but
| insufficient. There's a lot of code. We get ping ponged between
| various sections of the code every few weeks. Other people are
| contributing. There's a ton of ways code can look like it's
| probably correct and not be. There are non obvious bugs
| everywhere, and there's an element of luck to whether you're in
| the right headspace to catch them all.
| TrackerFF wrote:
| AI works great for providing you a starting point, and giving a
| big picture view of how certain things work, and how you should
| structure them.
|
| Sometimes, even if you're a really seasoned software engineer,
| you'll encounter something you haven't seen before. Maybe to the
| point that you don't really even know what to search for to get
| started. So instead of spending half a day scrounging various
| forums, e-books, etc. you can ask the model, in somewhat vague
| terms, what you're looking for - and some of the LLMs are quite
| good at just that.
|
| Now, the implementation of such things, not quite there yet. My
| experience has been that the more obscure the problems you deal
| with, the more obsolete code the model will spit out - with dead
| and unsupported libraries etc.
| dwoldrich wrote:
| AI enables me to gold plate _everything_ I do, which feels
| exhilarating, if a bit exhausting. Having decent taste and being
| able to continuously test and verify my work allows me to smooth
| over the occasional hallucinations and elicit towering, mind-
| bending solutions.
|
| AI's no replacement for experience; garbage in-garbage out.
|
| When AI gets too good, I figure people will cloister to stop
| feeding the beast. It can only lead to ignorance and misery, I
| fear.
| kragen wrote:
| Can you elaborate? What kinds of things are you doing, maybe
| something related to programming? What part of the job do you
| delegate?
| dwoldrich wrote:
| Not delegating, just tricking everything I develop out far
| more than I would have in the past. I'm on yet another
| hodgepodge project in a looong, decades long series of hodge
| and podge. AI is letting me begin to answer to my own
| satisfaction, "what does it look like to do everything to the
| best of my ability?"
|
| In my current gig, I have an on-prem database and legacy
| application that is human-powered software, where parts of
| the business process never touch the computer and a human
| does the work (mostly support stuff), (and for no good reason
| other than this system never had real engineering support.)
| So, I joined the team, and started to wrangle the system.
|
| First thing I was asked to do was get their database code and
| schema into source control with managed releases. The gold
| plating process that I never would have entertained in the
| past led me to get a migration tool installed, get a unit
| test engine installed in the database and writing new code
| with tests, figure out even how to refactor the big ball of
| mud and coming up with patterns there, doing github workflows
| to run the tests and deploy to multiple environments,
| linters, Slack alerts.
|
| It's not that I wasn't aware of all these things, I just
| never would have done all of them _to the extent_ that I did
| because the time needed to research it all traditionally and
| spike the solutions would have been too great. And I
| documented it all!
|
| After the databases were basically under control and I had
| gained the team's trust, I moved the team to start automating
| the human-powered parts of the software. We started an admin
| console webapp project. Again, I was heavy into AI all along
| the way, even during requirements elicitation. Our data is a
| rube goldberg machine of cloud and on-prem, but the majority
| of what we need to get under control is legacy/on-prem. We
| want the webapp to eventually be hosted in the cloud, but to
| be close to our databases and not have to fuss with private
| links, we decided for starters to deploy the webapp on-prem
| next to them.
|
| So, that meant figuring out how to get our github builds
| deployed on-prem. There was this huge saga in figuring out
| how to provision an on-prem GitHub Runner and use Powershell
| Remoting to fan out our deployments from there to all of the
| on-prem servers. Never EVER would I have been able to figure
| out the permissions and powershell provisioning steps needed
| to pull that off. It's all very gross, Windows is gross, but
| what we've built works dependably and is secure. I probably
| would have just used Samba or some other cheesy way to move
| files around and trigger deployments if I didn't have AI to
| bounce all these ideas off of.
|
| Another example: we wanted our BFF microservices to
| eventually deploy as Azure Functions, so gold plating meant
| we had to figure out how to build and deploy functions on-
| prem. It ended up being very productive, but again I would
| have never entertained doing such a thing unless I could
| bounce my ideas off AI and get credible directions on how to
| proceed. Instead, I would have written the service as
| trusty/crusty old Express 4.x and ported the code to
| Functions once we made the jump to cloud. I am saving future
| me a ton of work and heartburn!
|
| At every step AI is giving me the latitude to ask, given
| whatever nasty situation I'm in, what would be the best
| code/most secure/nicest architecture in that case? It's
| arduous to continually pepper it with questions and spend
| many days zeroing in on a final solution with it. But, it
| beats the guessing game of searching DuckDuckGo,
| StackOverflow, and software vendors' documentation - those
| are now the _last_ places I look for answers. (For ill, I'm
| sure.)
| layer8 wrote:
| What do you mean by gold-plating? What does _not_ gold-plating
| look like?
| overfl0w wrote:
| 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 rate, it became ever more difficult to locate those
| meaningful questions. Reason alone wouldn't do. What was needed
| was a rare type of intuition; the same faculty of mind (only much
| more intensified) that made a grand master at chess. A mind was
| needed of the sort that could see through the quadrillions of
| chess patterns to find the one best move, and do it in a matter
| of minutes."
| stopthe wrote:
| That chess metaphor didn't age well
| Jensson wrote:
| That is the goal post moving, its done by AI optimists that
| thinks "we just need something that can solve X and it will
| be as smart as a human expert".
|
| Wasn't true for chess, wasn't true for Go, we will see when
| its true, but they are constantly moving the goalposts and
| then arguing its others who are moving it.
| layer8 wrote:
| When your judgement tells you "this is wrong", you may need the
| technical skill to know what instead is right.
|
| The real question is when AI will surpass the average human in
| both judgement and technical skill.
| k__ wrote:
| I think, the argument would make more sense if software like
| Cubase came with unlicenced samples from all songs out of the
| box. Artists sued and won when someone used their samples without
| permission.
|
| If you use AI to create art, it's like that.
| CuriouslyC wrote:
| There's a difference between a sample and something inspired by
| something but also significantly different. The copyright laws
| around music are kind of draconian so it's not a good analogy
| for code anyhow, imagine a world where a fundamental do while
| loop had 90 year copyright protection, and that's the sort of
| world we'd be living in if code copyright was like music
| copyright.
| k__ wrote:
| If you see the generated content as "the music that's created
| with unlicenced samples" that's true.
|
| However, if you see the trained models as "the music that's
| created with unlicenced samples" it isn't true.
| lordnacho wrote:
| Judgement and technical skill go hand in hand. Technology merely
| moves the boundary of what is considered judgement, and what is
| considered technical skill.
|
| I know someone who wrote programs in the punch-card era. Back
| then, technical skill meant being diligent and thoughtful enough
| that you avoided most bugs when writing the program. If you
| screwed this up, you had to wait for another time slot. What does
| this mean for the complexity of programs you could write? Well,
| it means you are quite limited. You can't build judgement about
| things above what is now considered a very basic program.
|
| I learned to program before the AI era that seems to be nascent.
| Technical skill means things like being able to write programs in
| python and c++, getting many computers to work together, being
| able to find hints when something goes wrong, and so on.
| Judgement now covers things like how a large swarm of programs
| interact, which was not really in scope for punch-card guy.
|
| Now AI arrives, and it appears that we are free from technical
| skill problems. Indeed, it does fix a lot of my little syntax
| issues, but actually it just moves the goalposts. There's soon
| going to be no excuse for spending time working out the syntax
| for a lambda function, you'll be expected to generate a much more
| complicated product, for which you will need an even higher
| overview to say you are providing judgement.
| 4b11b4 wrote:
| Yeah but, you can't make a judgement in these technical areas
| without the technical skill... No?
| red_admiral wrote:
| And what is that judgement based on? Jobs that an AI can't do
| yet, like designing a system architecture and drawing boundaries
| (which features go in the same service), need someone with
| experience.
|
| We can apply this to all points in the Future of Work section.
| Even the conclusion "What should you do, and why?" is basically a
| disguised "What domain-specific knowledge do you have to make an
| informed opinion on the 'why' anyway?"
| giordanol wrote:
| The tooling problem is 90% solved. The new technical bottleneck
| is human judgment.
| somewhereoutth wrote:
| "Anyone with access to AI tools can now produce work that, _at
| least superficially_, resembles professional output."
|
| Key quote, emphasis mine.
| z3t4 wrote:
| It takes skill to see the beauty
| 0x445442 wrote:
| Writing musical notation doesn't strike me as technically
| difficult but I'm unaware of any musical composers who weren't
| proficient in at least one instrument.
|
| Good judgement is only accessible to those who've invested
| considerable time in the rudiments.
| financypants wrote:
| Have people noticed the ai-assisted code "creep"? Cursor now by
| default applies its changes before you've even hit accept, and
| the tab autocomplete is getting out of control. Sometimes I'll
| have my cursor resting on some block of code, then suddenly
| Cursor suggests I delete the whole thing.
| tingle wrote:
| Chap. CCCLXIV. -- On the Judgment of Painters.
|
| When the work is equal to the knowledge and judgment of the
| painter, it is a bad sign; and when it surpasses the judgment, it
| is still worse, as is the case with those who wonder at having
| succeeded so well. But when the judgment surpasses the work, it
| is a perfectly good sign ; and the young painter who possesses
| that rare disposition, will, no doubt, arrive at great
| perfection. He will produce few works, but they will be such as
| to fix the admiration of every beholder.
|
| Leonardo da Vinci, "A Treatise on Painting.", p. 225
|
| https://archive.org/details/davincionpainting00leon/page/224...
| gavmor wrote:
| > Nobody tells this to people who are beginners, I wish someone
| told me. All of us who do creative work, we get into it because
| we have good taste. But there is this gap. For the first couple
| years you make stuff, it's just not that good. It's trying to
| be good, it has potential, but it's not. But _your taste, the
| thing that got you into the game, is still killer. And your
| taste is why your work disappoints you._ A lot of people never
| get past this phase, they quit. Most people I know who do
| interesting, creative work went through years of this. We know
| our work doesn't have this special thing that we want it to
| have. We all go through this. And if you are just starting out
| or you are still in this phase, you gotta know its normal and
| the most important thing you can do is do a lot of work. Put
| yourself on a deadline so that every week you will finish one
| story. It is only by going through a volume of work that you
| will close that gap, and your work will be as good as your
| ambitions. And I took longer to figure out how to do this than
| anyone I've ever met. It's gonna take awhile. It's normal to
| take awhile. You've just gotta fight your way through. (Ira
| Glass)
| ChrisMarshallNY wrote:
| I like to do a good job on small stuff.
|
| It works nicely for me, but doesn't really bring accolades
| (but a hell of a lot of folks actually rely on stuff I
| authored; they just don't know it, or care -which is just
| fine).
| bluefirebrand wrote:
| We cannot build great things on poor foundations
|
| If your small stuff contributes to a strong foundation for
| other people, then they should care
|
| It's a shame people lose sight of the ground beneath their
| feet when reaching to the sky
|
| I'm very guilty of this too, partly because any time I try
| to look down the people I work with rush in to discourage
| me from doing that - it's not part of the sprint, after all
|
| Anyways, I am not sure what stuff you build, but thank you
| for being the sort of person that builds strong
| foundational stuff that helps other people. We need more
| people like you. I should try and be more like you
| ChrisMarshallNY wrote:
| No problem!
|
| You can always check my HN account page, for more info. I
| deliberately tend to be a bit shy about discussing some
| of that stuff in public forums.
| analog31 wrote:
| >>> But your taste, the thing that got you into the game, is
| still killer. And your taste is why your work disappoints
| you.
|
| This is why it's so hard for good classical musicians to
| learn jazz improvisation, even if they love jazz.
| Suppafly wrote:
| >For the first couple years you make stuff, it's just not
| that good.
|
| Sadly, that's why I don't start a lot of things that would
| interest me. You need to get into things when you're a kid
| and don't realize how junk your work is, because as an adult
| you just don't have time to dedicate to producing a lot of
| junk to get good at something. The are shortcuts and more
| directed learning you can do in a lot of areas to reduce some
| of the undirected learning you do as a child, but it's till
| time consuming when time is a rare commodity.
| nomel wrote:
| To put it simply, "it's easy to do well with tasks that are
| easy for you."
|
| This is how you make sure to produce good work while
| simultaneously halting the development of your skills.
| mjklin wrote:
| "The reason the gentleman is called worthy is not that he is
| able to do everything that the most skillful man can do. The
| reason the gentleman is called wise is not because he knows
| everything that the wise man knows. When he is called
| discriminating, this does not mean that he is able to split
| hairs so exhaustively as the sophists. That he is called an
| investigator does not mean that he is able to examine
| exhaustively into everything that an investigator may examine.
| He has his limit.
|
| In observing high and low lands, in judging whether fields are
| poor or fertile, and in deciding where the various grains
| should be planted, the gentleman is not as capable as a farmer.
| When it is a matter of understanding commodities and
| determining their quality and value, the gentleman cannot vie
| with a merchant. As regards skill in the use of the compass,
| square, plumb line, and other tools, he is less able than an
| artisan. In disregarding right and wrong, truth and falsehood,
| but manipulating them so that they seem to change places and
| shame each other, the gentleman cannot compare with Hui Shih
| and Teng Hsi.
|
| However, if it is a question of ranking men according to their
| virtue; if offices are to be bestowed according to ability; if
| both the worthy and the unworthy are to be put in their proper
| places... if all things and events are to be dealt with
| properly; if the charter of Shen Tzu and Mo Tzu are to be
| suppressed; if Hui Shih and Teng Hsi are not to dare to put
| forth their arguments; if speech is always to accord with the
| truth and affairs are always to be properly managed -- it is in
| these matters that the gentleman excels."
|
| -- Hsun-tzu, Chinese (300-235 B.C.)
| smithkl42 wrote:
| This doesn't actually sound encouraging. Judgment is not actually
| independent of skill, and the sort of music that this approach
| produces (i.e., nearly everything you hear on the radio these
| days) is a pretty solid proof of that.
| metalrain wrote:
| I think what and how are so tightly linked, you need to know how
| to make a thing so you better know what thing to make.
|
| Let's say you want to build worlds fastest car. You can order the
| pieces and maybe build a car from someones instructions. But to
| know what makes car fast and how to build it you need to know
| more and more intricate details. Physics, material science, 3D
| printing, engineering. How do you measure traction? What shapes
| increase downforce?
|
| That is how I see AI tools. You can get "off the shelf" ideas on
| different things, even complete small things, but you really need
| to be or grow to match the challenge you are facing.
| nluken wrote:
| A side note to the general point of the article, but I hate how
| the tech industry uses the word "democratization" to mean
| "lowering the barrier to entry". These concepts differ from each
| other but many use the former term because in doing so they
| justify their actions as driven by some sort of moral imperative
| when in reality, the development of LLMs is morally neutral, not
| inherently bad by any stretch, but as much a wealth and power
| play as any other technology of the last 25 years.
| scj wrote:
| AI can draw blueprints of a house. The house may look
| aesthetically pleasing, but if it can't hold it's own weight, the
| design is flawed.
|
| There's a difference between an executed image and a display-only
| image.
|
| At a certain point, judgment requires technical knowledge.
| keybored wrote:
| Very thin article. The thesis might as well be that technical
| competence is gone and judgement is all that's left.
|
| I file this under the category of AI musings on the inevitable
| massively changed landscape that AI has wrought.[1] I get the
| feeling that the content itself is secondary (again: the thesis
| is thin) to the motivation of writing about how AI has supposedly
| changed everything forever. In this case: now technical
| competence is dead, hail the king (judgement or whatever).
|
| [1] "I'm learning that every topic that people read should be
| about AI." : https://news.ycombinator.com/item?id=44082683
| dcre wrote:
| The Eno quote is good, but the post adds nothing to it! If
| anything, I think the sections after the quote make the post
| worse. This shows poor judgment on the part of the author.
| catigula wrote:
| I love these little anecdotes because they always pre-suppose
| that everyone - the writer, of course, but also the reader -
| themselves are the people who don't lack judgment, which is a
| role they relegate to, perhaps, a particularly incompetent co-
| worker, or even unknown and faceless "drudge".
|
| Which is to say that there's an obvious affliction of narcissism
| at work that precludes good judgment.
| gwd wrote:
| I agree with the premise; but the lists sound suspiciously AI-
| like.
|
| "Understanding what's worth making in the first place": Pretty
| good
|
| "Evaluating quality": Could be a lot better.
___________________________________________________________________
(page generated 2025-06-02 23:01 UTC)