AI doesn't lighten the burden of mastery • Hacker News Board

Re: AI doesn't lighten the burden of mastery

#41

Post by saulpw » Sun, Aug 17, 2025, 8:34 PM UTC

TrueTom wrote: post #15

gwynforthewyn wrote: post #2

I've been seeing teammates go from promising juniors to people who won't think, and I've tried hard here to say what I think they're going wrong. Like the great engineers who came before us and told us what they had learned, Rob Pike, Jez Humble, Martin Fowler or Bob Martin, it's up to those of us with a bit more experience to help the junior generation to get through this modern problem space and grow healthily. Fir…

I have to disagree. The same people who won't think existed in previous generations as well. The only difference was, they blindly regurgitated what Bob Martin et. al were saying.

There will always be people who won't think. The specific problem the OP is noticing, is "promising juniors" who then fizzle out and become these people who won't think. I think this is an interesting category to look at. Is AI making more of the non-thinkers appear promising erroneously? Or is it a comfortable but insidious offramp for the lazy-minded who previously would only think because they had to? Or are the demands of the tech industry, increasing velocity at the cost of conscientiousness, tempting/forcing juniors to use AI to preserve their jobs, but at the cost of their careers?

Re: AI doesn't lighten the burden of mastery

#42

Post by skydhash » Sun, Aug 17, 2025, 8:37 PM UTC

rafterydj wrote: post #27

hellisothers wrote: post #13

Earlier quoted context omitted.

Counterpoint: I forget where I originally read this thought but consider compilers. At one point coding was writing assembly and now it’s generally not, sometimes some people still do it but it is far from the norm. Now, usually, you “write code” in an abstraction (possibly of an abstraction) and magic takes care of the rest. While I imagine “make an app that does X” won’t be as useful as “if … else” there is a middl…

I mean that's basically all high level programming languages are, right? I would argue that as an industry we love high level programming languages, because they allow you to understand what you are writing, much easier than looking at assembly code. Excellent for the vast majority of needs. But then people go right on and build complicated frameworks and libraries with those languages, and very quickly the complexit…

Sometines you need the complexity because they make the problem simpler to solve. Especially if you have a bunch of them. Take something like a task runner, or a crude framework, or numpy… just be aware of the lower abstraction level to detect when it conflicts with the main problem.

Re: AI doesn't lighten the burden of mastery

#43

Post by renegade-otter » Sun, Aug 17, 2025, 8:40 PM UTC

In complete irony, I got back to reading actual docs for Python, React, Scala (my stacks) because I do NOT like being spoon-fed slightly-off answers.

I have a feeling that the skills for fixing up AI slop will be in-demand quite soon.

But, more to the point - AI code is legacy code.

Re: AI doesn't lighten the burden of mastery

#44

Post by skydhash » Sun, Aug 17, 2025, 8:40 PM UTC

smogcutter wrote: post #25

rafterydj wrote: post #11

Earlier quoted context omitted.

Counterpoint: a cabinet has always been a cabinet and nobody expects it to be anything but a cabinet. Rarely are software projects as repeatable and alike to each other as cabinets are. Software is codified rules and complexity, which is entirely aribtrary, and builds off of itself in an infinite number of ways. That makes it much more difficult to turn into factory output cabinetry. I think more people should read "…

But we’re way beyond templates here. There will be niches in research, high performance computing & graphics, security, etc. But we’re in the last generation or two that’s going to hand write their own CRUD apps. That’s the livelihood of a lot of software developers around the world.

Do people handwrite those? If you take something like Laravel and Rails. You get like 90% of the basics done by executing a few commands. The rest of it is the actual business logic and integration with obscure platforms.

Re: AI doesn't lighten the burden of mastery

#45

Post by __MatrixMan__ » Sun, Aug 17, 2025, 8:41 PM UTC

> Claude wrote me Go tests that passed. They were beautiful, and they were worthless. They all collapsed to true == true.

My favorite one of these is when I was having Claude write a nix derivation to package kustomize at 4.5.5 and instead of getting the correct source version and building it, it just set some build args on the latest version to override the output of the --version CLI flag.

Re: AI doesn't lighten the burden of mastery

#46

Post by 1970-01-01 » Sun, Aug 17, 2025, 8:42 PM UTC

renegade-otter wrote: post #43

In complete irony, I got back to reading actual docs for Python, React, Scala (my stacks) because I do NOT like being spoon-fed slightly-off answers. I have a feeling that the skills for fixing up AI slop will be in-demand quite soon. But, more to the point - AI code is legacy code.

>being spoon-fed slightly-off answers.

LLMs in a nutshell. They know everything because they are just guessing the answers.

Re: AI doesn't lighten the burden of mastery

#47

Post by johnea » Sun, Aug 17, 2025, 8:45 PM UTC

To me it seems it happened the other way around: a reduction in the valuation of mastery preceded, and facilitated, the acceptance of LLM output as "good enough".

What was called "move fast and break things", is one example. This development model leaves behind a trail of shit, that is poorly integrated and often, fully understood by no one.

Like vibe coding, this is all great until something doesn't work (not IF something doesn't work, but UNTIL).

This failure to appreciate mastery is illustrated in even earlier "business model" strategies, such as elimination of large corporate R&D laboratories, and the LBO raiders.

It's widely understood that every product and service in the current era is going to shit (certainly for the users, even if not for the ownership). Toasters built in the early '50s still work, toasters built today are designed for the dump. This isn't a problem with toasters, it's a problem with the business model of unrestrained capitalism.

Re: AI doesn't lighten the burden of mastery

#48

Post by sitkack » Sun, Aug 17, 2025, 8:47 PM UTC

logicprog wrote: post #38

sitkack wrote: post #35

Earlier quoted context omitted.

Jon Gjengset (jonhoo) Who is famously fastidious did a stream on live coding where he did something similar in terms of control. Worth of a watch if that is a style you want to explore. https://www.youtube.com/watch?v=EL7Au1tzNxE I don't have the energy to do that for most things I am writing these days which are small PoC where the vibe is fine. I suspect as you do more, you will create dev guides and testing guides…

> I suspect as you do more, you will create dev guides and testing guides that can encapsulate more of that direction so you won't need to micromanage it. Definitely. Prompt adherence to stuff that's in an AGENTS/QWEN/CLAUDE/GEMINI.md is not perfect ime though. >If you used Gemini CLI, you picked the coding agent with the worst output. So if you got something that worked to your liking, you should try Claude. I'm awa…

You can use Claude Code against Kimi K2, DeepSeek, Qwen, etc. The 20$ a month plan gets you access to a token amount of sonnet for coding, but that wouldn't be indicative of how people are using it.

https://gist.github.com/WolframRavenwolf/0ee85a65b10e1a442e4...

We gave Gemini CLI a spin, it is kinda unhinged, I am impressed you were able to get your results. After reading through the Gemini CLI codebase, it appears to be a shallow photocopy knockoff of Claude Code, but it has no built in feedback loops or development guides other than, "you are an excellent senior programmer ..." the built in prompts are embarrassingly naive.

Qwen has it's own agent which I haven't used https://github.com/QwenLM/qwen-code

Another is https://github.com/sst/opencode

Re: AI doesn't lighten the burden of mastery

#49

Post by lbotos » Sun, Aug 17, 2025, 8:52 PM UTC

I might half agree with the premise. I've heard some version of the phrase "make it work, then make it right" and sure, if you only vibe code, you will be left with ... vibes.

I find that when I'm reaching for AI it's because I'm actually trying to decide if I want to implement the idea I have, and need a PoC vs. expecting production ready things. For example, I was working on a UI and wanted to be able to "swap" two ul lists in JS. Not too hard of a thing to do, but I didn't remember the syntax, etc, and instead of hand writing, I asked the AI to do it.

It worked. The code was insanely overwrought and iterating over each list item 1 by 1 etc etc etc. But that's fine, I'm still not sure the "swap button" in the UI is the right UX, so I put a todo and am working on the "right problem" instead of banging out a clean list swap function. The mastery I'm seeking is not "most elegant usable list swap function, with maintainable code" but instead "Is this the best UX?" AI slop helped me stay in flow state towards that mastery.

Re: AI doesn't lighten the burden of mastery

#50

Post by lordnacho » Sun, Aug 17, 2025, 8:52 PM UTC

In recent weeks, I have made huge changes to my main codebase. Pretty sweeping stuff, things that would have taken me months to get right. Both big, architecturally important things, as well as minor housekeeping tasks.

None of it could have been done without AI, yet I am somehow inclined to agree with the sentiment in this article.

Most of what I've done lately is, in some strange sense, just typing quickly. I already knew what changes I wanted, in fact I had it documented in Trello. I already understood what the code did and where I wanted it to go. What was stopping me, then?

Actually, it was the dread loop of "aw gawd, gotta move this to here, change this, import that, see if it builds, goto [aw gawd]". To be fair, it isn't just typing, there ARE actual decisions to be made as well, but all with a certain structure in mind. So the dread loop would take a long long time.

To the extent that I'm able to explain the steps, Claude has been wonderful. I can tell it to do something, it will make a suggestion, and I will correct it. Very little toil, and being able to make changes quickly actually opens up a lot of exploration.

But I wonder if AI had not been invented at this point in my career, where I would be. I wonder what I will teach my teenager about coding.

I've been using a computer to write trading systems for a long time now. I've slogged through some very detailed little things over the years. Everything from how networks function to how c++ compiles things, how various exchanges work on the protocol level, how the strats make money.

I consider it all a very long apprenticeship.

But the timing of AI, for me, is very special. I've worked through a lot of minutiae in order to understand stuff, and just as it's coming together in a greater whole, I get this tool that lets me zip through the tedium.

I wonder, is there a danger to giving the tool to a new apprentice? If I send my kid off to learn coding using the AI, will it be a mess? Or does he get to mastery in half the time of his father? I'm not sure the answer is so obvious.