Hamish FriedlanderHost
Alaina LuxmooreHost
What are the top-performing implementation methods of AI for a team of software development engineers? Also, if the question sounds dumb and you don't understand it, or it's not gonna be fun to answer, just, like, we can yeet them.
It's, it's a bit weirdly f- or, uh, there, there's a bunch of different interpretations of the phrasing, so I might be getting the interpretation wrong.
I'll explain what we do with software engineers and AI, um, and hopefully that will answer the question.
Um, the first is a sort of, um, rubber duck second-person chat, um, system, where the engineer is still much more in direct control of the code that's being written, but you use the AI as a ever-present, uh, soundboard.

If we were doing, uh, a video, that would be really funny to, to make happen with AI.
So, uh, we use it as, like, an ever-present, uh, sounding board that we can bounce ideas off and sort of get help in the conversation.
This is how I use AI for development a lot, right? So on a little personal home project, I'm ending up having to do a lot of really weird bit math for integers 'cause I'm working on this tiny little constrained CPU.
Um, and it's been great 'cause I can just, like, bounce, um, ideas for something that might be optimizing the code, and it can go off and think about it and then say, "Yep, that works.
Awesome," or, "Nah, that doesn't work because of X or Y or Z that you didn't think of at the time," right? So this is really convenient second or third person that I can just send off and do some research or validate an idea against or, you know, check is my logic sound here or whatever.
Even before AI, there was this method of programming called rubber duck coding, where you would explain to, like, an actual physical rubber duck or an imaginary rubber duck what your code did, and just by explaining it through, you would often find errors or bugs in your code.
Um, and then the other, uh, method we use, uh, sometimes is spec-driven development, where, um, we will, um, build out a set of, um, product information elements, so specs and decision registers and other sort of components that are, um, human-readable but designed to feed into an AI to give it, like, a, a reminder of its context and a reminder of the business context for why code was produced.
And that's, if you're working in an agent mode or if you're working in a vibe coding mode, it's a really effective way of trying to control the AI from going off too far on a tangent or going through edit storms, where it will just change everything for a simple request because it's forgotten why any of that stuff existed.

What are the top-performing implementation methods of AI for a team of software development engineers? Also, if the question sounds dumb and you don't understand it, or it's not gonna be fun to answer, just, like, we can yeet them.
It's, it's a bit weirdly f- or, uh, there, there's a bunch of different interpretations of the phrasing, so I might be getting the interpretation wrong.
I'll explain what we do with software engineers and AI, um, and hopefully that will answer the question.
Um, the first is a sort of, um, rubber duck second-person chat, um, system, where the engineer is still much more in direct control of the code that's being written, but you use the AI as a ever-present, uh, soundboard.

If we were doing, uh, a video, that would be really funny to, to make happen with AI.
So, uh, we use it as, like, an ever-present, uh, sounding board that we can bounce ideas off and sort of get help in the conversation.
This is how I use AI for development a lot, right? So on a little personal home project, I'm ending up having to do a lot of really weird bit math for integers 'cause I'm working on this tiny little constrained CPU.
Um, and it's been great 'cause I can just, like, bounce, um, ideas for something that might be optimizing the code, and it can go off and think about it and then say, "Yep, that works.
Awesome," or, "Nah, that doesn't work because of X or Y or Z that you didn't think of at the time," right? So this is really convenient second or third person that I can just send off and do some research or validate an idea against or, you know, check is my logic sound here or whatever.
Even before AI, there was this method of programming called rubber duck coding, where you would explain to, like, an actual physical rubber duck or an imaginary rubber duck what your code did, and just by explaining it through, you would often find errors or bugs in your code.
Um, and then the other, uh, method we use, uh, sometimes is spec-driven development, where, um, we will, um, build out a set of, um, product information elements, so specs and decision registers and other sort of components that are, um, human-readable but designed to feed into an AI to give it, like, a, a reminder of its context and a reminder of the business context for why code was produced.
And that's, if you're working in an agent mode or if you're working in a vibe coding mode, it's a really effective way of trying to control the AI from going off too far on a tangent or going through edit storms, where it will just change everything for a simple request because it's forgotten why any of that stuff existed.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.