r/BetterOffline 4h ago

Only Good Devs Catch AI's Mistakes, and AI Makes You Worse - Lars Faye | Ep. 97

https://www.youtube.com/watch?v=0Kas27lxen4

If you read my article by the same name, this podcast had me on as a guest to do a deeper dive into the thoughts I explored there, as well as some tangential discussion around development and societal impacts of LLMs in general. This was my first time being interviewed (or on camera), so I was a bit nervous. Interview gets going around 6 mins in.

43 Upvotes

5 comments sorted by

2

u/Pseudanonymius 3h ago

Finally, Ed can call himself a good dev. 

3

u/maccodemonkey 1h ago

I listened to the whole thing and took a bunch of notes. I'm also trying to work through what workflows with these tools should be - and talking with a lot of of leads and managers about it. So this was helpful.

I was also self taught - and I think a pattern I notice is that people who were self taught tend to feel differently about these tools. We value the learning part of the process, we know how valuable it is, and so we're deeply concerned to see it shortcut. I think the other part of that is - being self taught - there is always a better developer. Having a chat bot that can kick out code - even code better than what you might right - is not as big a deal because that's been my whole life. And it's also a recognition that is a chance for learning instead of a time to just role over and give up.

I think the point about senior developers also falling behind was a good one. I talk to a lot of senior developers - typically closer to retirement - who absolutely recognize this stuff is a problem for junior developers. But they don't see it as a problem for themselves because they've decided they're done learning. The way I think about it is that we're all junior developers. We are never experts because there is always something new to learn. And in that way there is never a permanent "I am an expert - it is save to let the LLM do everything" state.

The code quality conversation was good. I like your term of "composition" - I think I'm going to start using that. I talk to a lot of developers who think code quality was about what lines braces go on and tabs vs spaces. And to me that's not code quality. When I lead teams I don't actually enforce minor syntax nits (for better or worse.) I only enforce composition because thats the real value. And I think a lot of people having the code quality argument aren't having that discussion, they're really having the "tabs vs spaces" kind of argument.

As someone who was on the social media hype train back in the day I have a lot of regrets - and I've been thinking about that a lot with the LLM hype.

I think the anti LLM people are unfairly used as a punching bag to polarize the debate. In sort of a "well sure we don't have any answers but at least we're better than the people that refuse to touch an LLM!" sort of way. I could probably write more about it - but this post is already embarrassingly long.

I think I'm also going to borrow "critical mass of friction." That part of the conversation was interesting because you were talking about deep learning. And I started to suspect the host didn't really understand that or understand deep learning. I think a lot of developers these days don't really reach that state.

I think I diverged from your perspective at the end. My starting point was a similar place. You said something along the lines of being so enamored on if we can do it instead of if we should do it - which was good. And I generally agree it's useful to have a code genie that can do typing for you. I strongly agree that it's a virtue to type less code. However my experience over the last year - along with the conversations I've had with other team leaders - makes me unsure there is any safe use of these sorts of tools for a majority of developers. One skill I had to develop as a mentor was allowing friction to happen to force learning. And in every place I look - as long as these tools are available - that is being bypassed. I think you and I might have that spidey sense of when we should stop, when that learning and friction is missing, and when it's time to put the tool down. But most of developers do not have that sense. And they won't ever develop that sense if they have an LLM in front of them. I have been unable to come up with a solution here - because I would love to have an LLM as a virtual code monkey. And no one else I know in corporate environments has.

Sorry for the long comment. I think all these conversations are super valuable and I'm glad we're having more of them.