141–150 of 234 posts
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…
Earlier quoted context omitted.
Yeah … but That has some amount to do with the level abstraction but almost everything to do with inexperience. The lower level you get, the harder the impact of inexperience. New web developers are still sorting themselves out and they are at a stage where they’ll suck no matter what the level of abstraction.
I get what you say but I must insist. Abstractions don't properly surface the underlying causes when they break. This creates a barier in gaining experience on the topic that matters in order to solve your problem. Let me try to give an example (please don't neat pick, it is just an example): A front-end dev who has never bundled an app like we did in the old days (manual scripts or manual gulp, grunt, webpack pipeli…
"Abstractions" in the abstract neither do nor do not do this, as it is orthogonal to what an abstraction is; concrete implementations of abstractions can either swallow or wrap information about the underlying cause when they break, both are valid approaches.
> but their current level of working isn't exposing those details directly so they can't gain experience
This isn't really true. They absolutely can gain experience; they don't pay a (very high) extra effort with the side benefit of maybe gaining some experience on routine tasks where nothing breaks, and tend to gain experience only if they expend extra effort in situations where things fail or their are unusual challenges to resolve.
Earlier quoted context omitted.
I don’t enjoy writing unit tests but fortunately this is one task LLMs seem to be very good at and isn’t high stakes, they can exhaustively create test cases for all kinds of conditions, and can torture test your code without mercy. This is the only true improvement LLMs have made to my enjoyment.
except they are not good at it. the unit tests you'll have written will be filled with (slow) mocks with tautological assertions, create no reusable test fixtures, etc.
"Some people might not enjoy writing their own code. If that’s the case, as harsh as it may seem, I would say that they’re trying to work in a field that isn’t for them." I've tolerated writing my own code for decades. Sometimes I'm pleased with it. Mostly it's the abstraction standing between me and my idea. I like to build things, the faster the better. As I have the ideas, I like to see them implemented as efficie…
The only reason I got suckd into this field was because I enjoyed writing code. What I "tolerated" (professionally) was having to work on other people's code. And LLM code is other people's code.
An LLM is a tool. It's your choice how you use it. I think there are at least two ways to use it that are helpful but don't replace your thinking. I sometimes have a problem I don't know how to solve that's too complex to ask google. I can write a paragraph in ChatGPT and it will "understand" what I'm asking and usually give me useful suggestions. Also I sometimes use it to do tedious and repetitive work I just don't…
I think the issue is that a lot of orgs are systematically using the tool poorly. I’m responsible for a couple legacy projects with medium sized codebases, and my experience with any kind of maintenance activities has been terrible. New code is great, but asking for fixes, refactoring, or understanding the code base has had an essentially 2% success rate for me. Then you have to wonder, how the hell orgs expect to ma…
How have you been using LLMs to help understand existing code?
I have been finding that to work extremely well, but mainly with the longer context models like Google Gemini.
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…
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.
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…
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.
I would consider it as a tool to teach and learn code if used appropriately. However LLMs are bullshit if you ask it to write something, pieces yes, whole code... yeah good luck having it maintain consistency and comprehension of what the end goal is. The reason it works great for reading existing code is that the input results into a context it can refer back to but because LLMs are weighted values it has no way to visualize the final output without significant input.
Earlier quoted context omitted.
I wish I had an LLM as a student because I couldn’t afford a tutor and googling for information was tedious. It’s the college’s responsbility now to teach students how to harness the power of LLMs effectively. They can’t keep their heads in the sand forever.
I had this realization a couple weeks ago that AI and LLMs are the 2025 equivalent of what Wikipedia was in 2002. Everyone is worried about how all the kids are going to just use the “easy button” and get nonsense that’s in-checked and probably wrong and a whole generation of kids are going to grow up not knowing how to research, and trusting unverified sources. And then eventually overall we learned what the limits…
Earlier quoted context omitted.
I get what you say but I must insist. Abstractions don't properly surface the underlying causes when they break. This creates a barier in gaining experience on the topic that matters in order to solve your problem. Let me try to give an example (please don't neat pick, it is just an example): A front-end dev who has never bundled an app like we did in the old days (manual scripts or manual gulp, grunt, webpack pipeli…
> Abstractions don't properly surface the underlying causes when they break. "Abstractions" in the abstract neither do nor do not do this, as it is orthogonal to what an abstraction is; concrete implementations of abstractions can either swallow or wrap information about the underlying cause when they break, both are valid approaches. > but their current level of working isn't exposing those details directly so they…
Not sure where you are getting with this. Yes, literally speaking they can, but what matters is if they actually do, in general, in the real world. My admitedly biassed opinion, based on personaly observating other colleagues, shows that in general, they don't learn and they give up.
Have you noticed an other trend in your circles?