Soft Skills Engineering - Episode 476: How much help is too much help and guarding against slop

Episode Date: September 1, 2025

In this episode, Dave and Jamison answer these questions: Two junior engineers recently joined my team, and I’ve been tasked with onboarding them. This is the first time I’ve been responsible for junior devs, and I’m struggling with how to coach them up. For context, we’re a small engineering team where self-sufficiency is highly valued; processes/overhead is minimal, and we have a real bias for action. As such, when they ask me for help, my intuition is often to respond “Keep looking, figure it out!”; in my mind, walking them to the answer would be anthithetical to our culture and set the wrong expectation for how they should go about solving problems. This is especially the case when they throw their hands up and say “Help, I’m stuck, what do I do”. Though, I don’t want to be so unhelpful that it frustrates them or legitimately impedes their progress. I’ve also noticed them sometimes going “behind” me to ask others engineers for help, which makes me think that I am being too unhelpful. The number one question I ask myself is: How much help should I be giving them? How do I find the right balance here? I’m seeing more and more AI slop in my org’s code base that I fear will have meaningful impact on the integrity and maintainability of the application we deliver to customers. Everyone talks the talk of “Ultimately, it’s the implementer’s responsibility to audit and understand the code they ship,” but few seem to walk the walk. How can I best work with my team to address this, especially in a context where leadership is prioritizing velocity?

it takes more than adding just one more metric to be a great software engineer this is episode 476 of the soft skills engineering podcast i'm your host jameson dance i'm your host dave smith soft skills engineering is the weekly advice show about your non-technical questions about the technical field of software engineering like uh how many metrics is too many i guess that's fairly technical it could be philosophical too though it's kind of like the nature of truth and how many we really know anyways how many roads must a man walk down or something isn't that the hitchhiker's guide question they wondered isn't that a bob dylan song isn't that candle in the wind i don't know it's a great question but the answer was 42 and then the people were all

trying to figure out what the question was and they were like trying to come up with the questions maybe it was a bob dylan wait is candle in the wind and elton john i don't know that is elton that's not why the people want to know stuff it is interesting how i feel like metrics are always backward looking where i always add them when i encounter a problem where it would have been easily solved if i had this metric and then i very often don't look at it again if that fix the problem and then also ship a metric and then yeah it never happens again yeah some some vendor charges me just little fractions of a penny more every so often it's totally true happy to support the tech ecosystem yeah that's right dave yeah i'm i'm sponsoring data dog

by adding metrics yeah we added more nodes to help sponsor this little startup called aws they're struggling dave do you want to thank our patrons yes big thanks to those that are contributing at the level on patreon where we shout out their patreon profile name whatever you type in there here we go hey i'm new here i wonder if this is being read before the miyamix guy i made neverendingstorypointer.com without ai woke up this morning got myself a gabagool matthias my actual name on linkedin is yami debugging in the dark canny the mobile development ordinary first of his name quote or one equals one drop table miyamix jacob chandling bjorn there is a very particular smell coming from your desk please create a spike to investigate

the missing semicolon christy the world's okayest programmer noah laphart what's up soft skillet nation it's your boys j and d here to drop some dope wisdom you had a good youtuber voice when you said that did i oh man yeah not sure if compliment or insult all right okay daniel remsburg nick molyneux if the service org uses a subservice org and the controls at the subservice org are necessary pretend it's not javier gonzalez chewy ted timbrel princess simon candy cane lollipop chicken bach bach pop pop and dog blueberry pie applesauce snakes input length validator that was all one name by the way i am the null pointer dan from drone deploy chase w norton never is not just a crater on mars flamingo emoji i like chicken i like liver

miyamix miyamix please deliver trash panda swiss python summit in october how often do you fetch this took a while kyle boss can't see dodds that guy over there jenny kim the stochastic parent quinton we have not heard from you in a month please go see susan and hr asap jonathan kings and i functional beautiful functional user documentation you know what we got ai now like good one shouldn't developers become business creators this episode is sponsored by hor i think cutoff i wasn't going to pronounce that phonetically all right fair enough drone sorry i just pre-read this next one drone from dan deploy

oh no i just hit my desk so hard that my monitor turned off okay it's back someone tell will angel how to get the https redirect working for www.vibechart.net Ragnar, Brayden Keynes, John Grant Brittany Ellick, Benadryl Cabbage Patch, Wimbledon Tennis Match Thank you so much for brightening my day

Really appreciate you all I like Drone from Dan Deploy because it harkens back to a time when people just named software tools and products after themselves, be like Jameson Soft and it'd be some I don't know, desktop notification client thing

yeah we should name we should name libraries after people but not now now we should answer this question dave should i read it let's do it this is from a listener called over promise under deliverer nice uh under deliverer good yeah that's so so me i guess this is for me nice um two junior engineers recently joined my team and i've been tasked with onboarding them this is the first time i've been responsible for junior devs and i'm struggling with how to coach them up for context we're a small engineering team where self-sufficiency is highly valued processes and overhead is minimal and we have a real bias for action as such when they ask me for help my intuition is to often respond keep looking figure it out in my mind walking them to the

answer would be antithetical to our culture and create the wrong expectation for how they should go about solving problems this is especially the case when they throw up their hands and say help i'm stuck what do i do though i don't want to be so unhelpful that it frustrates them or legitimately impedes their progress i've also noticed them sometimes going behind me to ask other engineers for help which makes me think that i'm being too unhelpful the number one question i ask myself is how much help should i be giving them how do i find the right balance here great question look short answer it doesn't matter what you tell them because if you don't give them enough help they'll just go ask ai yeah i mean we've talked a bunch in the past few months about junior developers in ai

and you kind of get to see this in action like what do i do if i don't tell them but i tell them ask ai and how how does that work how does it develop their intuition and skills and context and i don't know you could play oh you have to do an experiment ask the other one and help them yeah help them very very directly and then tell the other one use it is not where i thought you were going with this but i love it i thought you were going to point them at each other Oh, no, no, no. Well, I guess that's a good idea. No, I like the A-B test.

I like it. Yeah. Yeah, and then measure the results. I mean, you got to control for variables. So yeah, tell them, okay, each of you be exactly the same in all ways. Yeah, start out by normalizing. And then check off the I controlled for all the variables box. I told them to not be different.

Done. No confounding factors here. Yep. Tell me if you notice any confounding facts. And then delete them so that they don't mess up my experiment. Yeah. And then stop. Stop those.

Then don't. Oh, man. Hmm. I had to figure out so much stuff. And I don't know if I would go back and take that experience from me. I just spent so much time tinkering. I don't know. I feel like you are depriving people if you just give them all the answers.

Although, on the other hand, I don't know. James, boy, I'm super torn on this one, too. Did you know there's a whole... Actually, this is probably killed by AI now, but there was a whole genre of YouTube channels and blog articles and stuff. They were all just summarizing popular business books. Okay.

And the idea is you don't have time to read the book. Just get the one page of insights from it. And I think those don't work because you can read the one page, but it doesn't sink into you as much. If someone just tells you, hey, the point of this is this chart. Look at this chart.

You've got the content of the book. i guess if it's a good book and it has actual content in it there's something about wrestling with the content that makes it stick in your mind more and helps you learn more where if you just see the information and it passes through your eyeballs you kind of feel like you're learning but you actually don't learn and so i think i'm arguing that you you need to have some kind of struggle whether that's talking to ai about it talking to a bunch of engineers if if you the mentor just tell them the answer to every question and tell them exactly how to figure it out and they never work at it then i think they'll feel like they know stuff but it won't sink in as much

just from the nature of learning and even though we live in the age of ai for software development i still think you you gotta learn stuff it just learning might happen as you are producing the solution if you're working with llms or or through interacting with it to examine the code base but you can't just have someone tell you the answer all the time and develop the ability to be more productive on your own, which I think is what you're going for here. It's this balance of immediate output and longer-term growth. Yeah. And I'll tell you what, the most growth I ever experienced in my professional life was when the people who would otherwise be available to help me just weren't available for whatever reason. And so it completely took that option off the table.

And that changed my mindset because I didn't file things away like, oh, I'll ask so-and-so about this later. It was like, no, there is no later and there is no so-and-so. You've got to figure this out. Yeah. I felt that way about processes of taking over a technical ownership where there was someone around who knew it and they walked me through it. And then I still didn't really get it until I was responsible for making it work or delivering the thing. isn't isn't there like a famous three-step learning process in medical yeah see one do yeah exactly yeah and i'll tell you what that for sure works for me you know like i i was at a giant

tech co some time ago and i actually went to visit the team i was no i went to visit one of the more senior engineers i think maybe before i started even and he did like this big whiteboard walk through of the architecture of the system i was working on and i was like okay got it like i felt like i got it yeah you know and then it makes sense i think i understand everything and then a few weeks later i started on the job and i realized after getting first-hand exposure to doing the job that i had completely misinterpreted some of the elements of that architecture i had mostly data flow it's like oh i thought the data went here then here then here no it's more like a hub and spoke it goes in here and then back out to the hub and then back out to another

no then back to the hub then i'm like oh then i started doing my own little like introductory sessions for new engineers where i would teach them and then i recorded a video of me doing one of those sessions and that's when i'm like okay now i actually understand this did the end of the video say now you make your own that's such a good idea it's like a chain letter yeah that's Oh, that would have been missed. I feel like we've all felt that, but also I still just write down a bunch of stuff in onboarding docs and then assume it will work

where, I don't know, it didn't work for me. Yeah. I guess it helps though. I mean, it helps to have some human context besides just the artifact the machine interprets to figure out what's going on. We're kind of dancing around what to do though. I mean, we've said you have to struggle for learning.

You have to teach people to learn. You have to do stuff. But what about this practical question? How much help is too much? yeah and how do i not look like a jerk when i'm like i'm not telling you i know the answer but i'm not gonna tell you yeah that's so bad oh okay you could not look like a jerk by pretending like it's like a riddle right if you're the sphinx in the riddle wait is the sphinx the answer or is it i don't know what are you talking about is it jameson messes up pop culture references

volume 800 i don't know i just have this image of like a mischievous trickster where someone is challenged with a task and it's like a riddle they have to figure out and you know the answer but you're not going to tell them you just give them some some clues and then say answer my riddle the riddle of what triggers this deploy job i don't know i i've never been honestly i've never really been good at teaching this kind of stuff to other developers and and i've noticed that there certainly is a category of people who are willing, well, twofold. They are both willing and able to dive into things deeply and understand them. The willingness comes because this stuff is intimidating. When you jump into a giant code base, like multiple services talking to each other

and just getting your development environment out, it's like a multi-hour frustration-filled process. Just being willing is huge. But then able, there does seem to be a certain category of people who are able to take in all this information and actually like you've said before form a working mental theory of it so i don't know like you might just push them and it's like look this person's never going to do that that's they're just not that kind of person and if you don't need to push them because they just do it on their own then you've already got your answer yeah i think it's worth articulating your philosophy here at the very least if if you are determined to let them struggle a bit or concerned about giving them the answers and

having them not learn i think you should tell that to them because at least that gives them an explanation for your actions beyond my mentor sucks or my mentor is grumpy or my mentor is unhelpful if if you can tell them hey i i want you to learn and i'm here to help you and part of the help will be giving you information and context and guidance and part of the help will be me deliberately giving you quests to go out and find that stuff out on your own or or through asking other people or whatever. I want to work with you to find the right balance, but there will be times where I might know the answer and I might not give it to you directly because I think it will be better off for you to figure it out. And it's up to you to decide if I really don't know

the answer or if I'm just helping you. Yeah. I want to be clear. I always know the answer. Sometimes I just pretend like I don't. For your benefit. To help you grow. yes another technique you could use is you could say hey look like like jameson said lay the foundation look an important part of coming up to speed as a junior engineer is learning how to work through some of these problems on your own and in order to facilitate that i'm going to set up specific times on our calendar like a 30 minute block every other day that's your time to come and ask questions about the system. So accumulate your questions, bring them to me, and we'll do a rapid fire during that time. And here's why I say that. It's not just about time efficiency. But I have

had so many times in my engineering life where I have a question, I write it down, I don't immediately get to go ask someone for the answer. And then later, in the course of doing other things, the answer comes to me anyway. And I would like to, if you set up a meeting like that, you can leave a natural opportunity for that serendipitous moment to happen to them and have them get experience gaining their own answers without even having to talk to you at all which i think ultimately is for the best yeah i we i mean we've talked a lot about what you're going to tell them and how you're going to work with them too i think it's also worthwhile to get feedback from them especially because as a senior engineer you might not have a great theory of what

is going on in their head and what they know and what they don't if if they don't know what a socket is or tcp is or something and you use grpc and i don't know maybe it's fine to use grpc without knowing where the socket is but but there might be some critical knowledge that they are lacking that makes it so it's going to be hard for them to go figure out the answer on their own and it will cease to be worth it to just go churn through it all without any guidance so it's probably going to require some feedback from them where you say hey go figure this thing out and then they need to be willing to ask you questions about background information to help them and and and for you to cease to be surprised about the stuff that they don't know i think

that's a trap i can fall into working with more junior people is oh my gosh you don't know this thing i can't believe you don't know how to exit vim yeah yeah how did you get here just follow the path out that was the that was the code to our our office what was my point was i done i think i was done i don't know yeah part of what you can do to be a helpful mentor is look at where they are struggling and identify not just what question do they have that i'll answer but is there some underlying concept that i can help point them towards that will help them put some of this stuff together yeah yes and i was gonna say building a reading list for new engineers is a really helpful way to make sure that everyone has the same shared foundation yeah yeah well

i do i want to make one more comment it is a daunting task in my opinion to consider and teach all the things that someone needs to know not only to just work on your team but to be a productive engineer. And I realized like recently I've been getting into a new code base in a new language that I've never worked in before. Of course, all powered by AI. Thanks very much. But I'm now more confident to get into it, but I can see decades of principles that I've accumulated that apply that make me correctly question AI direction. You know, it's like, oh, I want to make this code change. And I'm like, eh, I know, I know that's the wrong place. And I know exactly why you were tricked into thinking that's the right place because i don't know it's like something in

my mind from many years ago or from many years of accumulated experience just tells me it's wrong and it's hard to build that up in a in short order it's not something that comes quickly and so yeah i would say be patient with these engineers like you were saying jameson it's it's you'll get to a point where you stop being surprised how little they know because you've spent a lot more time just contemplating these things reading things and you've been along the journey and that's that's the really the last thing i'll say is that some one of the reasons it takes so much time to ramp up and by the way this isn't just my old guy bias chiming in here you know well only experienced engineers are the ones that know what they're doing yeah but it is

true that having been exposed to the journey of how we got to where we are today is very very helpful like i saw a post um today on on the social medias that showed what a modern tech stack looks like and they had categorized things you know from the very bottom level where you have like your hosting providers, all the way up to like front end frameworks and everything in between. And I realized like, I've been around for the creation of most of these things. And so they were, they were trickle fed to me over the last 20 plus years. And then I was like, imagine if you walked in off the street from a different industry or, or just starting out your career. And you look at this list, you're like, I have no idea what any of these words mean. Like what's a Kubernetes?

There's so many layers. There were like eight layers on this, on this diagram. So that was crazy. So I'm like, be patient and just know that you know pretty soon you're going to be obsolete too so have some empathy that's why you go to embedded systems where there's only one layer you and the metal bits yeah all right thank you for your question i hope that's helpful dave do you want to read our yep this comes from an anonymous listener who says i'm seeing more and more ai slop in my orcs code base that i fear will have meaningful impact on the integrity and maintainability of the application we deliver to customers everyone talks the talk of quote

ultimately it's the implementer's responsibility to audit and understand the code they ship but few seem to walk that walk how can i best work with my team to address this especially in a context where leadership is prioritizing velocity hmm ai slop should we define ai slop i mean i guess sure kind of you've probably seen it what do you think it is what does it look like i asked that question i realized i don't think i have a concise definition it's it's really verbose that's one of the things like the the information density is low so there's a lot of lines of code or if it's documentation there's a lot of words there but it's not curated in a way that concisely communicates the meaning you can just kind of squint and tell oh a neural network

made this where this didn't go through human editing yeah it's like it's lukewarm in a way where it's it's above a certain floor of quality you're not going to find a certain class of just egregious errors that would happen if you really had no idea what you're doing but there's a ceiling of it's not going to make these brilliant technical decisions that just concisely outline the problem and and solve it elegantly or at least not without a lot of guidance this is a meandering definition i know it when i see it exactly you know what i think is slop your definition of ai slop yeah it could be wait a minute was that definition generated by ai uh no but it could probably maybe it would do a better job of defining it another uh another kind

of ai slop smell i've noticed is where either because the ai didn't know about it or because the developer forgot to inform the ai about it but the ai doesn't care about finding and reusing abstractions across the code base so you'll like i i use some i use claude this week or last week to generate a bunch of code and it was like i'm like surely we've done this somewhere else in the code base before like i can't believe you just reconstructed all that sql and we've never pulled like a user record out of our database before it's like it's the first time you know so unless you unless you guide it you can end up with like a lot of duplication so that's another another telltale sign and to be clear i i think ai is great for software development and there are there

are ways to solve all these problems but i think this is it's sort of the the default output you get if you don't guide it enough or don't edit it enough yeah and i think that's the temptation that this person's team members are giving into because it's like oh it produced the code yeah it works it works the problem it's plausible it's credible just ship it instead of taking that extra time to be like because i guess here's the other temptation like you like the first one is it works so ship it but the other temptation is i don't know if i reprompt it if i'm actually going to get something that works next time you know if i try to refine it so i rolled the dice and i got lucky this is a special snowflake to be blown away in the blast furnace of the random

environment that i work in also i found that when working with agents there's there's this really strong temptation to walk away from it while it's doing its thinking you know it's like just long enough the feedback loop is just long enough that i want i get distracted and so i don't know why but that puts a lot of friction on me even though the activation energy friction is like completely gone to get started on something the like stick with it energy to be like okay i'm just watching a spinner as it generates the next iteration of this thing it's like it's painful yeah and so anyway net result you take the first thing you get and you ship it and if it works you're happy with it so that's how we got here what do we do with this in a way this is not a new problem

This was cowboy coding when it was humans, where there's always been this class of developer who writes a lot of code, solves a lot of business problems, leaves stuff kind of messy behind them. And cowboy coding is often thrown around, but really means like someone who I disagree with. My quick and dirty business code is a wise trade-off that is correct. And their quick and dirty business code is irresponsible cowboy coding that ruins our lives. but there's always been this shape of like cranks have a lot of stuff. Yeah. Maybe, maybe copy paste,

maybe adds things that already exist in other places. It solves the problem. And this has always been a struggle for businesses to deal with. It's been a struggle because it's like, there's this evolutionary pressure to get stuff done. And this person can thrive under some of that pressure. It, it,

it, it, what's the word? I don't know. It provides utility. Yeah. There's like a fitness function that is, that is pushing people in this direction to some degree.

For sure. That's true. And I think, you know we're undergoing a really big experiment here and i am resisting weighing in like i'm suppressing i'm actively suppressing the craftsman side of my personality who wants nothing but the most beautiful well-abstracted code and because the other side of my personality is i we need results right like we're selling a product we're doing a useful function for humanity it needs to be good it needs to be fast and i can't justify taking longer and i think right now we're kind

of in this experimental phase. And we're not going to find out, probably for a year or two, maybe longer, whether this was a good idea. And what's interesting is that in the past, we've all been super excited to engage in almost exactly the same experiment. It just had different names. And now we're all super like, whoa, I don't know about this. And I'll just give some examples. About more than 10 years ago, a whole bunch of front end JavaScript frameworks came out. And we just ran toward these frameworks like most most developers did it was like this is so great it was so awesome but some of them turned out to be terrible and had to be completely rewritten because they they created so much bad code and i was a victim of this multiple times actually where

i'm like holy cow this this code is awful we can't debug it it's slow now and we can't figure out what's going on with this stuff and i realized like wait a minute what's the difference between ai generating bad code and you yourself writing bad code the difference is you're excited about one because it's new wait the one you're excited about is you the one i think people were more as i look at the ai skepticism like this question asker and i compare that to the javascript framework fervor of the early teens i think back then yes there were a few people saying oh no we should slow down this isn't necessarily good but the majority of at least in the front in web development world the majority of developers were eagerly running toward these new frameworks

and the difference was how they felt about it because the result was the same you had sloppy code that was hard to debug and hard to understand i mean another difference is the volume of sloppy code can be a lot higher in the past you you might have one or two cowboy coders on your team now everybody can be a cowboy coder and probably at even a higher volume than the og cowboy coders would be so the problem shifts from writing to editing a bit more and i mean that's always been a part of software development you had to produce the output you had to modify it to be better in some way to fit business criteria better or fit your i don't know technical design better and if that producing output piece goes down to zero it won't but say it goes down to zero

you mean the cost of it goes down to zero or the or the time of it the time you take so you produce a lot more of it say say for every potential technical task you hit one button it gives you yeah but you're still going to have to review that i think there's there's maybe a maximalist view of well eventually it'll just get so good that it'll be it'll be reviewed for you we're not close to that yet. So for at least the next several years, I think we're going to be, if AI is generating a lot of code, then we become more editors and reviewers and kind of checking the hard, squishy human bits that are harder for agents or LLMs or whatever to do themselves. Everyone talks about ultimately it's the implementer's responsibility to audit and

understand the code they ship. I think this is a culture that you need to instill on your team. If you had a team of cowboy coders, you would need to change the incentives and change the practices to say, hey, this is giving us the wrong outcome, right? We're making these short-term tradeoffs for long-term pain, and we need to put more effort into reviewing the code. If it's AI, I think it's easier in a way because you don't have as many personal feelings in the way. If I cranked out this garbage, I might feel more identified with it. But if I used an agent to crank out the garbage and you say, hey, this is garbage. And I say, yeah, yeah, that agent sure made some garbage. Let's fix it.

So if you seem to walk the walk, I think it's easier to be very critical of AI generated code because you get to take away all the human bits. Yeah. All the human identification. All the ego. Yeah. You get to stand back and say, wow, yeah, it did suck. It did totally miss this thing. There's a little human ego, though, because you let it through.

Yeah. It's like, did you even read this? Yeah, but I think it's still different than if you made it all yourself. Yeah, it is. It's more about negligence and less about you are incapable of producing good ideas. Yeah. Did you even read this is a fair question, though. I think you can ask that.

Maybe the answer is no. I don't know. They tested it, and it worked. I know, right? Like, why did I bother reading it? I'll tell you, though, I have struggled my whole leadership career to help developers close the feedback loop between the code that they produce and the externalities that that imposes on others, both in the form of bugs that someone else ends up fixing or code that's hard to navigate that someone else has to deal with. And I don't know the answer to this, but I think if we could solve that problem, then this problem would be solved as well. Because imagine it's like I produced a whole bunch of slop and now some other developer is struggling through it. If I could re-internalize that pain back onto the original developer who allowed the slop to come out in the first place, then that would incentivize them to be a little bit more careful with the AI stuff that's produced.

Yeah. A dumb, obvious answer is talk about this problem as a team. Maybe it's not widely known, or maybe it's not part of your shared understanding that if you just tell the AI, solve problem for me, the output you get will solve the problem but have some weaknesses. and if you at least make sure everyone's on the same page there that feels different than saying it's the implementer's responsibility to understand the code they ship because it's more specific it's not just hey understand the code you ship it's um hey if you use ai you have to watch it yeah like it will do bad stuff or it will it will produce negative outcomes maybe maybe show a pr as an example maybe if you find some slop and you on you know that the slop committer is willing to talk about it then you can point it out and say look at what it did this is a problem right we don't want we don't want this outcome in our code base even though it solves the problem

so first be aware it happens and then there's also lots of stuff you can do to guard against it all of the tooling that helps humans helps ais because the agents can all run that tooling for linting stuff yeah you can add a bunch of context we we have way more docs in our code now that we did before ai because they scale higher now exactly it's not just humans it's the agents so you can kind of prose your way around some problems not all of them certainly but maybe we just need to stigmatize ai so bad that we all go back to the way it used to be toggling in with dip switches on the front of a panel eight eight bit words at a time yeah we've gone too far return hmm i don't know i think i gave a bunch of vague suggestions but i don't know if that will help it it's worth

is this a problem that other people are aware of i guess that's part of the question behind my suggestion to talk about it like is it just you do you feel like other people notice this i don't know i think on my on my team at least there's a range of i would say skepticism and optimism and enthusiasm for ai and the ai maximalist can still do a good job of recognizing weaknesses and pain points but often the skeptics are are a little bit more critical of the output or the weaknesses so it's useful to have everybody talk about it together i think and and get a range of perspectives on it. Yeah. Also, I just don't think this... Here's the thing. I'll tell you my bias. I have seen so much crappy code written before the age of AI that I'm kind of like,

look, is it really worse? I mean, I'll just give an example. I used AI recently to make some changes to some HTML code in our app. And I was just commenting out a few things to remove some visual stuff on the screen. And it ended up introducing a very subtle bug that only manifested when the user did certain interactions. And I thought to myself, holy cow, this HTML, which was written like seven years ago, so pre-AI, was so crappy. It had so much subtle errors in it that made it so that it was all deeply coupled with each other, where you comment out something over here and something in some other file would you know barf it was really bad and i realized like this is freaking everywhere like everyone has written code like this and the code that i

thought was quote clean unquote 10 years ago when i go revisit it i'm like this is slop this is garbage so i actually have very low faith in humanity's ability to produce clean long-term maintainable code under the best of circumstances under the best of human scrutiny and human care and craftsmanship and so when you tell me ai can produce code that's basically the same level of quality as human stuff but way way faster i'm like great this feels like a win to me yeah i think an important question to ask if your org is using ai not all of them are and might not be a good fit for you but if you are is how how can we shape our code base to make ai more effective which is I think the answer has a lot of similarities to how can we shape our code base to make engineers more effective in it. There's documentation, there's consistent patterns, there's examples, there's tooling, there's a bunch of kind of AIs or LLM specific tooling around this that isn't applicable if you're just gritting your teeth and doing it by hand with a steady hand and a needle on a spinning disc or whatever.

so so part of what you could do is is kind of talk to the team about it and tell people to be careful part of it is maybe trying to address the root problem are there abstractions that exist but aren't well understood by the team including by the agents that work on your team then you could document those you could add some context or some rules to say pull in these models when you work in these files or whatever yeah yeah i i think there's a there's a i don't know developer experience and working with a code base that's always been a class of work kind of work to make the work of engineers on the code base more effective and there's a there's a new type of that which is work to make ai that works on your code base more effective that's a long topic but do some of that

work that's the it's kind of like the same answer we give when you have a cowboy coder like you're saying before it's like we have tools to help guard against this stuff we have linting rules we have bug finders we have all kinds of static analysis tools and we have code review so you know it's okay to reject a code review be like sorry too much slop you know try again yeah yeah well have we answered the question not really because i i really believe this question is not answerable right now and i think we're gonna we're gonna understand the answer a lot better in a year or two which is why i'm kind of i'm kind of holding out you know on really having a strong opinion You know, I believe that if you're using AI effectively as a developer right now, you will go faster and the technical output will be better overall.

And there are going to be some things on the margins where stuff might be worse than it would have been if a human did it. But I think the overall impact is positive if you are using it. I agree. And yeah, if you hire 15 new engineers, some of them will ship slop some of the time also. so it's it is kind of similar in a context where leadership is prioritizing velocity i guess we didn't talk about that part yeah they're getting what they want it is going to be tough to say whoa whoa whoa we can't like stop slow down it's hard to be that uh everyone is is always trying to go faster but especially right now where i think every software shop is looking

around and saying either a all my competitors are going faster or b it's a lot easier for a new competitor to get brought into existence by someone just hanging out on their laptop in a cafe now so i don't think the push for velocity is going to go away all right i agree you can harness it that's the answer all right what can people do if they want their own questions answered go to soft skills audio and click the ask a question button where you can fill out our form and ask whatever question you want you can share your identity or not you can give us all the details you want or as little detail as you want. And we really appreciate everyone who fills out that form each week. Love it. Thank you. Thank you. Thank you for listening. We will catch you

next week.