161–170 of 234 posts
Earlier quoted context omitted.
My C compiler has been generating assembly code for me for 30 years. And people were saying the same thing even earlier about how compilers and HLLs made developers dumb because they couldn't code in asm.
C compilers are deterministic. You don't have to inspect the assembly they produce to know that it did the right thing.
On the other hand, I am finding LLMs increasingly useful as a moderate expert on a large swath of subjects available 24/7, who will never get tired of repeated clarifications, tangents, and questions, and who can act as an assistant to go off and research or digest things for you. It’s mostly decent rubber duck.
That being said, it’s so easy to land in the echo chamber bullshit zone, and hitting the wall where human intuition, curiosity, ingenuity, and personality would normally take hold for even a below average person is jarring, deflating, and sometimes counterproductive, especially when you hit the context window.
I’m fine with having it as another tool in the box, but I rather do the work myself and collaborate with actual people.
Earlier quoted context omitted.
LLMs don't create an abstraction. They generate code. If you are thinking about LLMs as a layer of abstraction, you are going to have all kinds of problems.
This is a disingenuous critique of what was said. The point is LLMs may allow developers to write code for problems they may not fully understand at the current level or under the hood. In a similar way using a high level web framework may allow a developer to work on a problem they don’t fully understand at the current level or under the hood. There will always be new tools to “make developers faster” usually at a t…
It's simply not the same thing as a high level web framework.
If you have an intern, or a junior engineer - you give them work and check the work. You can give them work that you aren't an expert in, where you don't know all the required pieces in detail, and you won't get out of it the same as doing the work yourself. An intern is not a layer of abstraction. Not all divisions of labor are via layers of abstraction. If you treat them all that way it's dumb and you'll have problems.
Earlier quoted context omitted.
LLMs don't create an abstraction. They generate code. If you are thinking about LLMs as a layer of abstraction, you are going to have all kinds of problems.
My C compiler has been generating assembly code for me for 30 years. And people were saying the same thing even earlier about how compilers and HLLs made developers dumb because they couldn't code in asm.
I heard about the term 'vibe coding' recently, which really just means copying and pasting code from an AI without checking it. It's interesting that that's a thing, I wonder how widespread it is.
Earlier quoted context omitted.
I'm giving a programming class and students uses LLMs all the time. I see it as a big problem because: - it puts focus on syntax instead of the big picture. Instead of finding articles or posts on Stack explaining things beyond how to write them. AI give them the "how" so they don't think of the "why" - students almost don't ask questions anymore. Why would they when an AI give them code? - AI output contains notions…
Job market will verify those students, but the outcome may be potentially disheartening for you, because those guys may actually succeed one way or another. Think punched cards: they are gone along with the mindset of "need to implement it correctly on first try".
the teachers still need to figure out how to teach with LLMs around
We've seen this happen over and over again, when a new leaky layer of abstraction is developed that makes it easier to develop working code without understanding the lower layer. It's almost always a leaky abstraction, because sometimes you do need to know how the lower layer really works. Every time this happens, developers who have invested a lot of time and emotional energy in understanding the lower level claim t…
We've seen this happen over and over again, when a new leaky layer of abstraction is developed that makes it easier to develop working code without understanding the lower layer. It's almost always a leaky abstraction, because sometimes you do need to know how the lower layer really works. Every time this happens, developers who have invested a lot of time and emotional energy in understanding the lower level claim t…
Leaky abstractions is a really appropriate term for LLM-assisted coding. The original "law of leaky abstractions" talked about how the challenge with abstractions is that when they break you now have to develop a mental model of what they were hiding from you in order to fix the problem. (Absolutely classic Joel Spolsky essay from 22 years ago which still feels relevant today: https://www.joelonsoftware.com/2002/11/1…
I do see a time where I could use copilot or some LLM solution but only for making stuff I understand, or to sandbox high level concepts of code approaches. Given that I'm a graphic designer by trade, I like 'productivity/automation' AI tools and I see my approach to code will be the same - I like that they're there but I'm not ready for them yet.
I've heard people say I'll get left behind if I don't use AI, and that's fine as I'll just use niche applications of code alongside my regular work as it's just not stimulating to have AI fill in knowledge blanks and outsource my reasoning.
Why would one work without one?