Comment by therealpygon
1 month ago
Or at least, aware that this argument continues to be made with tenuous evidence and anecdotes. And yet, people are being more productive (actually productive) with AI. Release schedules are increasing, bugs are getting fixed faster, security issues identified and patched sooner, so on and so forth.
I’m not denying (at all) that unused skills languish. I take issue with AI being characterized as a magic eraser that mystically makes people forget what they have already learned. I’ve just done a study and concluded that dogs gets dumber when I throw a ball. What’s my evidence? They stop staring at me to chase it. The ball definitely made them forget who I was, so we shouldn’t allow dogs to have balls anymore.
Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “lost” skills?
Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “lost” skills?
I would argue that's a misuse of AI. If the point of an engineer is to know how things work behind a piece of software, then shipping code without an understanding how it all works is a failure.
You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you?
So instead of focusing on AI as a productivity tool, focus on AI as a means of adding rigor and understanding to your workflow.
> If the point of an engineer is to know how things work behind a piece of software
That might be the point of an engineer in some orgs, but mostly the point of an engineer is to ship a product or release that matches someone's vision of what should come next, and doesn't cause additional noticeable problems in the next quarter or three.
> You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you?
If it was as easy to stress test/battery test/materials test/etc a bridge as it is to test code - then yes. I'd trust an engineer who vibe-engineered a bridge.
---
The problem with mapping digital problems into meat-space is that there is inherently a few orders of magnitude of cost automatically added to anything that happens in meat-space.
I can spin up an arbitrary number (10, 10k, 500k) docker instances, X with fuzzed inputs, Y with explicit edge cases, Z with tolerance testing, etc etc. And if that doesn't work - I can fix and push a button and it just happens again.
If a bridge engineer could do that with bridges - yes I'd expect them to be vibing just as hard as we are now.
Don't mechanical engineers do that with FEM simulations? Example: https://www.youtube.com/watch?v=tZspM_TvPKQ
1 reply →
That's verification. An engineer still understands the bridge and the engineering decisions that they built.
No, but I’d certainly trust an engineer to use software with in-built algorithms to design a bridge instead of using a typewriter, calculator, and a pencil. What you argue is your perception that this means everything is vibe coded and an engineer doesn’t understand any of it. My thought would be that this sentiment seems more telling of your views or how you use it than someone else. I’m not saying it isn’t possible for you to be right in circumstances, but rather you seem to assume your view fits all circumstances.
That the point of the engineer is to know how all of it works? So one must know the specific details of how every hard disk driver is implemented, with the algorithms being used, and have checked all the math and inspected all that code, just to be able to “read file”? Do you also argue that million+ line codebases should be inspected through every dependency and every file, line by line, and run through a debugger, before making a single line change anywhere?
Seems more like an extensive exercise in self-flagellation on the company’s dime than would be appropriate, but that’s just my opinion.
We all have our domains. A person can absolutely use AI within their domain and understand its output perfectly as much as having written it themselves.
The need for knowledge in those domains also changes over time. The need to understand a domain at a depth is directly proportional to the depth of the changes you are making to a stack. I don’t need to know how the hard drive spins to write a program. I don’t even need to understand that hard drives exist to write most programs these days, because it is not an area of concern. All of the implementation and efficiencies happen at a level below, or another below that, or within a trusted dependency. The people working on all those things understand those domains better than I ever could have the time to.
Maybe you could better explain where vibe-coding significantly differs from the above as another “layer” of separation?
Look, I’m not arguing vibe coding is “good” in and of itself by any means, but just basically that it’s not all vibe coding, and those of us that understand that don’t really have as much need to argue about the inevitable or that things change.
> this argument continues to be made with tenuous evidence and anecdotes.
The linked Wikipedia page has plenty of evidence and studies and you can find plenty more with a basic web search. This is not something someone just made up; if you don’t know there are a multitude of studies on the harms of social media, you haven’t looked at all. Which is fine, it’s our prerogative to not search for information, but don’t turn around and say it doesn’t exist or is anecdotal.
> And yet, people are being more productive (actually productive) with AI.
You said, ironically without providing evidence, in the same paragraph that you complained about evidence not being provided for something else which has plenty of it. Furthermore, there are several studies suggesting AI may in fact decrease productivity, but I’m not going to link to those because the more important point is AI has nothing to do with the conversation. The original poster mentioned AI, but this branched thread is exclusively about the “liking to learn” part.
[flagged]
> And yet, people are being more productive (actually productive) with AI. Release schedules are increasing, bugs are getting fixed faster, security issues identified and patched sooner, so on and so forth.
I didn't see anything in parent chain that implied this. Nor did I see it "characterized as a magic eraser"; I saw it framed as something that impedes learning, and that was tied back to constant simulation.
> Or at least, aware that this argument continues to be made with tenuous evidence and anecdotes
The arguments I read and the argument you seem to be replying to seem to be different things.