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

AI doesn't lighten the burden of mastery

playtechnique.io

Post reply on HN
Print view View original

31–40 of 77 posts

Re: AI doesn't lighten the burden of mastery

#31

Post by rafterydj »

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.

I don't really disagree with you about handwriting CRUD apps. But I'm not sure that having an off-the-shelf solution, from AI output or not, that would spin up CRUD interfaces would _actually_ erase software as an industry.

To me it's similar to saying that there's no need for lawmakers after we get the basics covered. Clearly it's absurd, because humans will always want to expand on (or subtract from) what's already there.

Re: AI doesn't lighten the burden of mastery

#32

Post by jrflowers »

TrackerFF wrote: post #4

There used to be a time when you needed to be very skilled woodworker in order to make nice cabinets. There still are, but the number of machine / CNC made cabinets outnumber artisanal 100% hand-made cabinets by some incredible number. For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there... And that's how I believe software engineering will end up. Hand crafted co…

> For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there

Minimalist design isn’t the result of minimal effort. It actually takes quite a lot of time and skill to design a cabinet that can flat pack AND be assembled easily AND fit cost constraints AND fit manufacturing and shipping and storage constraints AND have mass market appeal.

IKEA stuff exists because of hundreds or thousands of people with expertise in their roles, not in spite of them.

Re: AI doesn't lighten the burden of mastery

#33

Post by dimal »

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…

There’s always been this draw in software engineering to find the silver bullet that will allow you to turn off your brain and just vibe your way to a solution. It might be OOP or TDD or pair programming or BDD or any number of other “best practices”. This is just an unusual situation where someone really can turn off their brain and get a solution that compiles and solves the problem, and so for the type of person that doesn’t want to think, it feels like they found what they’re looking for. But there’s still no silver bullet for complexity. I guess there’s nothing to do but reject the PR and say “Explain this code to me, then I’ll review it.”

Re: AI doesn't lighten the burden of mastery

#35

Post by sitkack »

logicprog wrote: post #26
rafterydj wrote: post #19

Earlier quoted context omitted.

Interesting. Would you mind elaborating a bit on your workflow? In my work I go back and forth between the "stock" GUIs, and copy-pasting into a separated terminal for model prompts. I hate the vibe code-y agent menu in things like Cursor, I'm always afraid integrated models will make changes that I miss because it really only works with checking "allow all changes" fairly quickly.

Ah, yeah. Some agentic coding systems try to force you really heavily into clicking a loud. I don't think it's intentional, but like, I don't think they're really thinking through the workflow of someone who's picky and wants to be involved as much as I am. So they make it to that, you know, canceling things is really disruptive to the agent or difficult or annoying to do or something. And so it kind of railroads you…

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 that can encapsulate more of that direction so you won't need to micromanage it.

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.

Re: AI doesn't lighten the burden of mastery

#37

Post by westurner »

logicprog wrote: post #9

This is a really good post. I'm a naturally controlling person, and I care about my craft a lot, so even in my recent dabbling (on a ~3000 LOC project) with agentic coding, one of the things I naturally did from the start was not just skim the diffs that the AI generated, but decide for myself what technologies should be used, describe the logic and architecture of the code I wanted in detail — to keep my mental mode…

Having read parts of e.g. the "Refactoring" and "Patterns of Enterprise Architecture" books and ThoughtWorks and Fowler web pages and blog posts, and "The Clean Coder", and about distributed computing algorithms; I've been working with a limited set of refactoring terms in my prompts like "factor out", "factor up", "extract an interface/superclass from".

TIL according to Wikipedia, the more correct terms are "pull up" and "push down".

How should they learn terms for refactoring today? Should they too train to code and refactor and track customer expectations without LLMs? There's probably an opportunity to create a good refactoring exercise; with and without LLMs and IDEs and git diff.

System Prompt, System Message, User, User Prompt, Agent, Subagent, Prompt Template, Preamble, Instructions, Prompt Prefix, Few-Shot examples; which thing do we add this to:

First, summarize Code Refactoring terms in a glossary.

Code refactoring: https://en.wikipedia.org/wiki/Code_refactoring

"Ask HN: CS papers for software architecture and design?" (2017) https://news.ycombinator.com/item?id=15778396

"Ask HN: Learning about distributed systems?" (2020) https://news.ycombinator.com/item?id=23932271

Would methods for software quality teams like documentation and tests prevent this cognitive catch-up on so much code with how much explanation at once?

Generate comprehensive unit tests for this. Generate docstrings and add comments to this.

If you build software with genai from just a short prompt, it is likely that the output will be inadequate in regards to the unstated customer specifications and that then there will need to be revisions. Eventually, it is likely that a rewrite or a clone of the then legacy version of the project will be more efficient and maintainable. Will we be attached to the idea of refactoring the code or to refactoring the prompts and running it again with the latest model too?

Retyping is an opportunity to rewrite! ("Punch the keys" -- Finding Forrester)

Are the prompts worth more than the generated code now?

simonw/llm by default saves all prompt inputs and outputs in a sqlite database. Copilot has /save and gemini-cli has /export, but they don't yet autosave or flush before attempting to modify code given the prompt output?

Catch up as a human coder, Catch up the next LLM chat context with the prior chat prompt sequences (and manual modifications, which aren't but probably should be auto-committed distinctly from the LLM response's modifications)

Re: AI doesn't lighten the burden of mastery

#38

Post by logicprog »

sitkack wrote: post #35
logicprog wrote: post #26

Earlier quoted context omitted.

Ah, yeah. Some agentic coding systems try to force you really heavily into clicking a loud. I don't think it's intentional, but like, I don't think they're really thinking through the workflow of someone who's picky and wants to be involved as much as I am. So they make it to that, you know, canceling things is really disruptive to the agent or difficult or annoying to do or something. And so it kind of railroads you…

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 aware actually lol! I started with OpenCode+GLM 4.5 (via OpenRouter), but I started burning through cache extremely quickly, and I can't remotely afford Claude Code, so I was using qwen-code mostly just for the 2000 free requests a day and prompt caching abilities, and because I prefer Qwen 3 Coder to Gemini... anything for agentic coding.

Re: AI doesn't lighten the burden of mastery

#39

Post by benreesman »

TrackerFF wrote: post #4

There used to be a time when you needed to be very skilled woodworker in order to make nice cabinets. There still are, but the number of machine / CNC made cabinets outnumber artisanal 100% hand-made cabinets by some incredible number. For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there... And that's how I believe software engineering will end up. Hand crafted co…

Anything adversarial is going to be the best people using the best assist: military drones, trading, anything performance hot pathed (AI inference itself), thats all too competitive to be anything but hybrid.

But by a similar argument, most anything with healthy competition and a discerning market can only lag that standard by some amount.

It's easy to conflate a once-in-a-generation orgy of monopolistic consolidation with the emergence of useful coding LLMs, but monopolies always get flabby and slack, and eventually the host organism evicts the parasite. It's when, not if.

And we'll still have the neat tools.

Re: AI doesn't lighten the burden of mastery

#40

Post by [deleted] »

TrackerFF wrote: post #4

There used to be a time when you needed to be very skilled woodworker in order to make nice cabinets. There still are, but the number of machine / CNC made cabinets outnumber artisanal 100% hand-made cabinets by some incredible number. For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there... And that's how I believe software engineering will end up. Hand crafted co…

[deleted]
Post reply on HN