Live data from Hacker News

AI doesn't lighten the burden of mastery

playtechnique.io

21–30 of 77 posts

Re: AI doesn't lighten the burden of mastery

#22
I'm a 20+ years programmer working with my colleagues who are 2-5 years of experience. I could see they had accepted AI generated tests which are testing solely the mocks. This is quite annoying, because for me, when I want to finish a task properly, I have to write tests from scratch. I'm also using the same AI tool, but I want to use it differently, as a "copilot" and not the "main pilot"

Re: AI doesn't lighten the burden of mastery

#23
post #5

AI will hopefully humble so of the people I work with. The people who understand nothing about business, yet you can't talk to because they think gifted for being able to write instructions to a computer. The people spin out new frameworks every day and make a clusterf*ck of hyped and over-engineered frameworks. The people who took a few courses and went into programming for money.. I went into software because I enj…

I wouldn't put too much hope into this because now, AI can help these people go from really vague thoughts to something that sounds even more fluent.

My sense is we really have to raise everyone's critical thinking abilities in order to spot bullshit.

Re: AI doesn't lighten the burden of mastery

#24

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…

I understand the analogy, but code is so much more fungible. It is the stuff of thought. Rather than a physical thing with hard limits.

I think software will remain much more artisan because, in some sense, software is a more crystallized form of thinking, yet still incredibly fungible and nebulous.

Re: AI doesn't lighten the burden of mastery

#25

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…

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.

Re: AI doesn't lighten the burden of mastery

#26

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…

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 into letting the agent do whatever it wants, and then trying to clean up after, which is a mess.

Typically, I just use something like QwenCode. One of the things I like about it, and I assume this is true of Gemini CLI as well, is that it's explicitly designed to make it as easy as possible to interrupt an agent in the middle of its thought or execution process and redirect it, or to reject its code changes and then directly iterate on them without having to recapitulate everything from the start. It's as easy as just hitting escape at any time. So I tell it what I want to do by usually giving like a little markdown formatted you know paragraph or so that's you know got some bullet points or some numbers maybe a heading or two, explaining the exact architecture and logic I want for a feature, not just the general feature. And then I let it kind of get started and I see where it's going. And if I generally agree with the approach that it's taking, then I let it turn out a diff. And then if I like the diff after reading through it fully, then I accept it. And if there's anything I don't like about it at all, then I hit Escape and tell it what to change about the disc before it even gets to merge it in.

There are three advantages to this workflow over the chat GPT copy and paste workflow.

One is that the agent can automatically use grep and find and read source files, which makes it much easier and more convenient to load it up with all of the context that it needs to understand the existing style architecture and purpose of your codebase. Thus, it typically generates code that I'm willing to accept more often without me doing a ton of legwork.

The second is that it allows the agent to automatically of its own accord, run things like linters, type checkers, compilers, and tests, and automatically try to fix any warnings or errors in that result, so that it's more likely to produce correct code that adheres to whatever style guide I've provided. Of course, again I could run those tools manually, manually and copy and paste the output into a chat window, but that's just enough extra effort and friction after I've gotten what's ostensibly something working that I know I would be likely to be lazy and not do that at some point. This sort of ensures that it's always done. Some tools like OpenCode even automatically run LSPs and linters and feed that back into the model after the diff is applied automatically, thus allowing it to automatically correct things.

Third, this has the benefit of forcing the AI to use small and localized diffs to generate code, instead of regenerating whole files or just autoregressively completing or filling in the middle for things, which makes it way easier to keep up with what it's doing and make sure you know everything that's going on. It can't slip subtle modifications past you, or, and doesn't tend to generate 400 lines of nonsense.

Re: AI doesn't lighten the burden of mastery

#27

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 "…

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 complexity (albeit presented much better for reading) comes back into a project.

Re: AI doesn't lighten the burden of mastery

#28

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 "…

No Silver Bullet — Essence and Accident in Software Engineering : https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

Thanks for adding the link!

Re: AI doesn't lighten the burden of mastery

#29
post #5

AI will hopefully humble so of the people I work with. The people who understand nothing about business, yet you can't talk to because they think gifted for being able to write instructions to a computer. The people spin out new frameworks every day and make a clusterf*ck of hyped and over-engineered frameworks. The people who took a few courses and went into programming for money.. I went into software because I enj…

I'm probably one of the people you're talking about.

I'm feeling basically mostly fulfilled in life, and don't feel my life is being wasted.

I didn't understand the thing about "AI made sure they knew as well", or maybe I'm not actually who you're describing.

But I definitely get into language, syntax, frameworks, parsing, and blah blah blah.

Plenty of people still play chess. Plenty of people still run. Machine performance has surpassed humans long ago in both disciplines. Are those people stupid also?

Post reply on HN