Soft Skills Engineering - Episode 503: Hardware is hard and my PMs are pushing AI slop code

Episode Date: March 9, 2026

In this episode, Dave and Jamison answer these questions: I’m a software developer with about 15 years in the industry, and I am soon starting as the CTO of a robotics company with about 50 employees. Though I have years of experience and an academic background within the field of robotics, I have always been focused on the software side of things. In my new role, I am ultimately responsible for the hardware team as well. How do I go about earning the respect, and becoming an effective leader, of my new colleagues working in a field in which I am not an expert myself? Hi, I’m meowmeow, and I’ve enjoyed your podcast for a long time. I’m working at a small engineering company which don’t have lots of profit. Recently, the PMs at my company(including the CEO) have started “vibe coding” directly on our product. They’ve even added PMs to the project planning list as contributors. Whenever they open a PR, the code is AI-generated and reflects their personal working style. The code quality is fairly low and engineers end up spending a lot of time reviewing and fixing it, even though we’re already under a heavy workload. Our CEO comes from a product management background. He believes PMs should write code and deploy their own implementations, and that engineers are not fast enough and should simply move faster. I’ve already been feeling stressed due to the workload, and this situation seems to be making it worse. Engineering leadership doesn’t seem able to push back effectively. What should I do?

it takes more than getting your employees feedback through the soft skills engineering podcast to be a great engineering manager this is soft skills engineering episode 503 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers and unlike websites that return a 503 this service is available i'm so glad we're back in the meaningful http status code now finally although we missed a few yeah oh what do we did we i don't think we we made a 500 joke but we did make a 500 joke and 501 and 502 are rare enough that i just didn't know what to say yeah oh getting your employees feedback yeah this is so the question is are these our employees dave or is this someone else's

employee where both the listener and the employer, both sides are listeners. That's exactly what I was thinking of. You need to get feedback from your team members. And so what you do is you just listen for their questions on the show. There's a lot of feedback for you managers out there on this show. A lot. Yeah. If in doubt, it's about you. I literally have had people come up to me and say, what's that question about me? have i ever had anyone say that no it's because they know it's not about them it's about dave yeah it's about what the question's about speaking of dave how about this for a transition

should i read our patrons that transition was 200 okay great i'm gonna do it then thank you to these folks who support us so much that we shout them out every single week thank you to my name is toast because i like bread brian wolford is in germany boots the cat who is dead learn more at boots.rip oh man old man yells at claude seth angel is that a will angel oh now that's actually will angel's brother right i i don't know sorry couldn't find a funny thing to say now i'm stuck with this name jamie sundance go ahead and run your own mail server what are you chicken buck balk my actual name on linkedin is yami debugging the dark canny the mobile development ordinary air first of his name jacob shandling larry ellison's brother larry page that one still

gets me it's funny it's so dumb and i really love really dumb jokes coffee is for closures the missing semicolon christy the world's okayest programmer i didn't get a link to the poll about will angel starting a blog could you please send it again you said words and now i hate my job nick molyneux embedded engineers treat assembly the same way typescript engineers treat javascript javier gonzalez chewy ted timbrel i like chicken i like liver myomics myomics followed by a single closing and then the character a single closing paren and then will angel and then another single closing paren character a separate patron that is a single opening paren oh i got those those were opening friends earlier too sorry dan from drone deploy never is not just a crater on mars

flamingo mochi i like chicken i like liver myomics myomics please deliver swiss python again this october ah more succinct now kyle boss can't see dots this podcast was recorded at 1970 0101 or later it's the start of the unix epic right yes jenny kim the stochastic parrot ira chan jonathan king's nigh beautiful functional user documentation can't see dots what's that oh can't see dots i think that's can't see dots oh that's so great should will angels start a blog vote now on your phones is it pronounced data or data i assume that's how i'm supposed to say it they're both spelled the same but i couldn't figure out how to pronounce it or brayden canes john grant britney ellick and closed parenthesis and then an actual single

closing parenthesis thank you oh thank you thank you just when i think they can't be get better constraints breed creativity and you're demonstrating that there are some creative names here i've just so you all know i've had a pretty rough week but i feel great right now it's working oh take our energy dave thank you i feel renewed good we have a sponsor dave do you want to talk about them yeah speaking of feeling renewed this episode is sponsored by retool retool is the best way to keep up with all those unending internal tool requests except they're actually governed and secure and no cleanup required please go check out retool at retool.com slash soft skills so we get that delicious marketing juice retool.com slash soft skills

we'll tell you more about them later yep okay also i i must do as our planning cards say and it says you are supposed to read this first question so even though you just did stuff can you do more stuff i yeah well i mean i do what you say you do what the card says the cards run the world you wrote the script that made the cards so ultimately you are pulling the strings we do what the machines say and that's only becoming more true every year okay an anonymous listener writes in to say i'm a software developer with about 15 years in the industry i am soon starting as the cto of a robotics company with about 50 employees though i have years of experience and an academic background within the field of robotics i have always been focused on the software

side of things in my new role i am ultimately responsible for the hardware team as well how do i go about earning the respect and becoming an effective leader of my new colleagues working in a field which i am not an expert myself sorry in which i am not an expert myself well one thing you are an expert on is where to place a preposition in english you nailed that yeah that's you already got my respect yeah really well done not a lot of people have my respect when it comes to prepositions there are no infinitives being boldly split here how do you do this i think what you do is you buy like an arduino because that's what hardware is i believe you stroll into the room where the hardware team works slam it down on the desk and say how hard could this be look at this

thing maybe like decorate actually yeah bring bring your little bit bring your little bread board hooked up with an led that blinks in a button exactly yeah i listen i get it i know hardware i know hardware we we speak the same language but some of these like breadboards around your office as if you have many projects in progress you know yeah you'll get the respect don't worry my father-in-law has a phd in electrical engineering and and works in hardware and i mean i i know that there's a physical reality underneath the code but i just ignore it most of the time and he is the opposite where he knows that there is code running on these things and he deals with like interference and like debugging is spooky because hardware can be

haunted in much more frightening ways than software you can you can build gigantic rube goldberg distributed systems oh yeah but you can still read all the code but with hardware it's literally like i set this thing in the wrong place for a day and that flipped some bit somewhere on it and then when i moved it back to this other spot and i was like poisoned i think hardware can get disease like you can get sick yeah also hardware has magic smoke in it software does not have magic smoke yeah the magic smoke is coming out of my ears in software that's in my brain yeah exactly uh yeah that's probably the main reason i didn't go into hardware was because you got one chance with each atom to get it right and i'm like when i look at the number of commits

I will push or the number of times I'll retry something in software I'm like wow that only took me 17 tries to get right yeah I can't afford to be in hardware yeah and I think it is a great skill to figure out how you have quick feedback loops in hardware because if done naively I think the feedback loop is like oops let me go build a new one I guess and then start over so I guess I'm not answering your question I guess I'm saying I have admiration and respect for people that work hardware but dave doesn't he told me before this question he said i think these people are a bunch of jokers and it's not actually that hard it's a freaking clown show no i know you don't feel that way i know i actually i have a ton of respect in fact one

of my close friends who's been a friend of mine for many many years decided to stop studying computer science and switch to electrical engineering because and i quote computer neuroscience is too easy. Words you don't hear that often. Well, your friend is probably very smart. He certainly is. He's very, very smart. What would you do in this situation? Dave, have you ever had experience managing a group of people where their job is not one that you've done before? You're not an expert in that exact job? Yes. And I approach this situation with dread because I think you could ask a question a little bit the other way and get a yes from almost everyone. And that is, have you ever been managed by someone who is not an expert in the thing that

your job is? In other words, if you're a software engineer, have you ever been managed by someone who's not a software engineer and has no background in software engineering? And I think a lot of people would say yes. And I'll bet you most of the yeses would also say it wasn't a great experience. Yeah. There's a class of management labor you cannot perform. You cannot mentor them in their field you can't step in front of them and identify like incoming technical problems with their approach kind of architecture all that jazz and it's hard because i like doing that it's easier to to manage people in a domain you know really well right what did you do to solve it because i i believe that you have just done this effectively just because i think you're

right i have done it but i don't really know how effective it is and in fact it's definitely the hardest part of my job in terms of knowing what to do. So I stepped into a CTO role recently where I am responsible not just for the engineers, but also for the project managers and designers on the team. And it's incredibly hard. And I've gone from a situation where I feel full confidence in directing the team of engineers, assessing the quality of their work, communicating with them clearly, and also recruiting effectively. Like I know how to identify and hire good engineering talent i've gone from that to like i don't know anything about like i've worked adjacent to product managers for decades but somehow like i don't know how to identify good product manager

talent i don't know how to tell if our roadmap is good i don't all i have is my raw intuition that i can depend on from having been so close to it for so many years and i and i don't know i think my team probably is a little bit frustrated with me on that so i kind of i think one of the things you can do is tell them like be very transparent about where you have gaps in your knowledge so that they can be confident in helping you fill those gaps and boy the last thing you want to do is like double down on some stupid decision just so that you don't appear weak in front of people but oh yeah not gonna happen make it trinary silicon why are we using silicon yeah yeah that stuff bad for you somehow if you ingest it

makes me sneeze yeah we should make them out of carbon here's the good news though this person i think they said they have an academic background with robotics i'm like great you have a huge leg up compared to most people i mean think of most ceos that you know like how do ceos get the job done they got to hire uh engineering leader they have to hire product leaders they have to hire sales leaders finance leaders marketing leaders privacy leaders so many different people you think the ceo has a background in any of those areas like maybe one at best so my advice would be do what ceos do just appear really confident and get really good at fundraising that's those are two things i think you're saying you do have some experience around hardware more than just

some random sass background it's great and that's useful and be humble i think that's generally good for a leader anyways but especially if you actually aren't an expert in the field and to acknowledge it. There is this tension where if you never push your team to do something or decide something that they disagree with, you might not be like, what's the point? If the team would just do whatever they wanted, whether you were there or not. Yeah. What's the point of view? Yeah. So there are times when you do have to say, I know you think this is wrong and I believe this is the right thing to do anyways. And that is so much easier if you are an expert in the domain. It's going to be hard to know when to do that anyway sometimes.

It's going to be especially hard to know when to do that with this team, when to push or when to disagree with them. And I don't know the solution to that, but I think just recognizing it is useful. Yeah, for sure, recognizing it. And I think the other thing is you need to become a good judge of character. Which people on this robotics team can you trust? Which ones are transparent? Which ones tend to make good, correct decisions?

which ones can communicate with you clearly in a way that you can understand and then surround yourself with those people go to them individually with questions and let them know you don't know everything and then figure out which ones have a consistently good ideas and then listen and this is the part where you have to trust your intuition because yeah it's robotics and and listen you're not going to be like choosing which grade of aluminum to put in this actuator you know that's probably not the right idea but you will be reviewing team members proposals for which grade of aluminum to put in the actuator and you have 15 years of software engineering background you have a robotics academic background you have learned how to identify bullcrap and you've also

learned how to identify good and bad engineering process so take advantage of that and then tell people what you're basing your decisions on like hey this doesn't seem right can you do a little bit of a deeper dive here. Or, hey, this seems right to me based on whatever XYZ experience I've had. Tell me if I'm wrong. Help disabuse me of any false information. Yeah. One thing you should not do is just ask AI and then tell your team, hey, I talked to AI about hardware and this is what it said. I actually do think it could be useful as a way to just bounce general ideas off of and maybe have some broad guidance towards specific hardware concepts if you're looking to brush up. But I don't think you can just replace personal experience with a text box yet. There's

going to be a limit to how visionary you can be about hardware without being an expert. But I agree with Dave that if you can partner with somebody on the team, I think there's a lot of room for really excellent individual contributors to help at a high level with hardware stuff. And that should be exciting. That should be exciting for the hardware team as well to say we have a leader who knows what they don't know and and is willing to ask our feedback and kind of challenge us to think big i think that's my answer yeah i'm sticking to it i think you're going to do great and i think this person has way more of an advantage with their background and the adjacencies that they've been working in i think it's great now here's the thing you said you're going to be

the cto of a robotics company tell you what you're thinking about these robotics people and i promise you this is not going to be the area where you feel the most uncomfortable as a cto So I've got some surprises for you, but you're going to have to deal with a board of directors. You might have to deal with investors. You might have to do presentations for audiences that you're not familiar with. These situations will probably be 10 times harder than dealing with the robotics or hardware engineers on your team. So good luck. In a nice way, not a dismissive good luck with that.

Yeah, that was not a sarcastic good luck. That was a genuine, I wish you actual luck that is good. Thanks for clarifying. All right. Hey, Jameson, I've noticed as a CTO a tension that exists between building customer-facing product and internal tools to help my company work more efficiently. Yeah, there's always those dashboards around marketing and custom workflows you need to build and, importantly, the big chunky novelty lever that you pull to deploy to production. Yes, and I usually don't have enough engineering bandwidth to build everything they need, and so other team members start building them with duct tape and good intentions. Retool breaks that cycle.

Retool has always been a great platform for building internal tools, but they recently launched their AI AppGen platform that gives teams a centrally governed place to build the tools they need, and everything stays under your control. Yeah, it's a really good idea. Someone could just type, build me a customer admin panel that manages accounts from Postgres, and they'd get a real production-ready app with proper permissions built in.

Your teams get unblocked, and you don't inherit a pile of technical debt down the road. We literally have this dilemma right now of, do we invest engineering time in building this thing that is for kind of internal use do we just chuck it at an llm and retool tries to solve that problem if you're tired of being the cleanup crew for shadow it go to retool.com soft skills and see how other engineering teams are democratizing app building without creating chaos because we could all use a better way to handle internal tools sometimes you just need to retool go to retool.com soft skills should i read our next

question let's do it okay hi i'm meow meow and i've enjoyed your podcast for a long time i work at a small engineering company which doesn't have a lot of profit recently the pms at my company including the ceo have started vibe coding directly on our product they've even added pms to the project planning list as contributors whenever they open a pr the code is ai generated and reflects their personal working style the code quality is fairly low and engineers end up spending a lot of time reviewing and fixing it even though we're already under a heavy workload our ceo comes from a product management background he believes pm should write code and deploy their own implementations and that engineers are not fast enough and should simply move faster i've

already been feeling stressed due to the workload and this situation seems to be making it worse engineering leadership doesn't seem to be able to push back effectively what should i do ah Ah, the AI slop problem has come home to roost in your nest. I am interested in this question because I think I've created, somewhat created this problem at my job. I led a bunch of the non-engineers at our company in making AI code contributions. And it's been really great for the business. And it is more work for the engineering team. And we're struggling with this same thing of other people have really good ideas, it turns out.

and the barrier to building those ideas is lower and also they're not engineers they build them in a different way than engineers would and by definition this is stuff outside of our roadmap this is like extra stuff that isn't things we're planning on working on and sometimes it needs some cleanup work or needs some more collaboration so if it's really easy to produce code and more people are producing code the bottleneck just moves one step down and now it's in kind of review and integration and testing and yeah this is this feels very real without i mean it's not this is me pushing for it i come from a technical background not product management there's some differences here but i feel like this is either happening or will be happening at many software

places oh yeah totally and i think it's not even if there's just pms it's like the parts of the process that used to be bottlenecks are no longer bottlenecks and so what that's doing is it's revealing new bottlenecks that didn't used to be. Things like code review, things like QA, at least for us, that's what's happening. The more we embrace AI, even when PMs aren't submitting AI-generated code. But with PM submitting AI-generated code, I think that those bottlenecks become even more pronounced on the code review and QA side, because not only is it just more code to review, but it's also now going to be code that the developer, in this case, the product manager has no way to really do a first line of review on it yeah on the code quality that is

i think there are a few ways to tackle this one way is to generally put more guardrails and feedback in the technical systems that you work in i've written about this man i haven't attached something to show notes in a while maybe i'll attach my own blog post to this i've written a bit about this And a lot of people have too. Well, it's half my podcast, so I'm going to half self-serve. There's a lot you can do in prompting to guide agents in the right direction. If you don't know what to say to the agent, because you're not an engineer, if you don't know to say, use these technical patterns, then that's not going to help for you. But it turns out AI is really good at writing Lint rules and kind of like automated testing. There's a bunch of

tools to help review code, and some of them are even LLM-based, so they apply. It's not like AST-level examination of things. It's sort of written rules-level stuff that it will then search your code base and see how it applies to. And the more automated feedback you can give to your system, the easier it will be for an LLM to produce code that is correct. And the higher leverage it is when you have non-engineers doing it, because the people producing the code will just be unable to do this without more feedback. The LLM can often do it with feedback, but if you don't know to give the feedback, you won't give it. So you got to make it so the LLM gets the feedback automatically. Yeah. If you're serious about doing this, I think you need to talk to

your CEO about improving the automated feedback for AI-generated code. And the way you pitch it is this will help us go faster. AI will generate better code. This will help the engineering team review it faster. We'll find fewer things. It'll help the code base stay flexible for AI to be able to continue to work on it. That's a key point. The CEO probably cares very little about whether engineers can work well in the code base, but telling them that they need certain patterns for the code to stay AI friendly is really important. Yeah.

And almost all the stuff that makes the code base AI friendly also makes it better for humans. Yeah. If there's really good documentation that's hierarchically organized, so you dive into a directory and there's a readme

and then you dive into a subdirectory that has some kind of specific module and that has a readme. Yeah. That's great. It's also easier to produce and maintain than it has been. Right.

I know there's some people that don't like the kind of, they chafe under the oppressive burden of very intense and opinionated linting rules. and they're going to chafe even more because I think this is just how engineering is going to move. In the past, people who have seemed insane and controlling

I think are going to seem more correct in hindsight because it's just better to be very explicit and have a red squiggly that shows up that says, don't use this function. I know you found it. There's code in our app that uses it. It is wrong to use it. And that coming from a linter is easier for AI to respond to

than that somewhere stuck in the prompt. Yeah, it's all about guardrails, right? Yeah, you're building up even higher guardrails and more specific guardrails. And humans bump into guardrails sometimes softly, but often avoid them. But AI is just like run into guardrails and just like bounce off of them,

bounce, bounce, bounce, bounce. Oh, okay, now I got it. So the guardrails need to be good, strong, and plentiful. Yeah, there's also, you mentioned review feedback. There's a bajillion AI code review tools every coding harness wants to install itself into your source control and then there's a bunch of third-party ones also so there are ways you can get automated code reviews some of them are pretty decent they're not always correct but i've found one that seems pretty good overall it still means

a human still has to review it most of the time and you could still get stuff wrong but just like you are trying to make the system easier for the ai to produce correct code you also can invest in making it easier to verify that the solution is correct either for ai or humans there's a bunch of stuff coming out right now around like computer use and agents that will spin up a browser and record videos of using the feature and then attach them to prs like here's the proof that this thing worked so i think you can also somewhat reduce the testing burden by chucking more guardrails at that also more verification yeah i know we're we're probably just like a little bit stepping into hard skills territory but i gotta say like managing ai code generation feels like it's one

foot in hard skills and one foot in soft skills because it's more of like a process design and it's almost like managing people but there's just more of them and they work faster and sometimes they're crazy dumb it's kind of weird yeah but i was i was actually listening to a really interesting interview with peter steinberger the creator of open claw formerly molt bot formerly clodbot and it was an interview by lex friedman i recommend it to everyone who's interested in this area but he was saying like you might be tempted when you review the code that an ai generates to critique it and be like i don't like that variable name but he's learned to stop doing that because if the llm generated that variable name that probably means that the llm will

understand that variable name later when it reads it as context i don't know where i there's some people who say lms are compilers effectively now and the prompting is the source and then the actual code is kind of the lower level that you don't look at as much i don't think i'm there and i don't i think that the engineer's responsibility is to maintain the flexibility and the productivity of the system and i think you still need to have a mental model of it and have opinions on what will keep the code easy to maintain so like maybe i don't like that variable name is probably not the most useful unless you read it and say oh this variable name is wrong like it says the wrong thing i think there's still value in giving code level feedback either

if the solution is wrong or if you feel like this will make it harder to work with later and maybe that'll become less necessary eventually but i think that's still important so i i guess yeah this is focused a lot on on kind of techniques to make ai produce better output but it's still gonna there's still more work like it's worth to do all that and say all this is done you snap your fingers the system exists you still have pms producing output it will by necessity take time what do you do about that yeah you still have all your other stuff to do it is the case that more time is needed and we also heard this on a previous question where i think people just feel kind of this sense of loss of joy in their work

because they're doing more of the things they don't like to do, like reviewing other people's code. And so I just haven't yet come to terms with what that means for us as an industry. Are we all just doomed to have slightly less satisfying jobs where we spend more time reviewing than writing code?

Hmm, maybe. Your CEO thinks engineers are moving too slow. I would try to talk to your CEO to help them understand that PM contributions require engineering input and feedback right now. Maybe your CEO just disagrees and says, no, don't worry about it. Do other stuff. That would be a good thing to know explicitly. Your CEO thinks engineers are moving too slowly and wants PMs to help because it seems like stuff gets done more quickly. I think there also could be some truth to that, right? Like maybe you're too worried about things that don't apply anymore

and the AI world, I don't know what specifics those would be, but I think there is a disagreement here that it would be good to get out in the open and at least make sure that if the disagreement remains after you both understand each other, that's a better place to be than the CEO just thinks, ah, they're just griping and we're moving too slow. AI means we can go faster.

And you thinking, they're ruining our code base and I'm going to quit because I'm so stressed. Yeah, and I think that's exactly the right theme that needs to be conveyed here, I want to make sure that as an organization, we can not be capped by some bottlenecks or that the process can work unencumbered and at full speed. And right now, what you might not realize, and I don't know if your CEO is an economist, but you might say there's some externalities taking place that you might not be aware of. The externalities are you are committing

code, as are the PMs. And as a result, our regular planned roadmap is now slowing down at the expense or rather in favor of these unplanned committed things or sorry unplanned and uncommitted things that aren't on the roadmap and so it's like hey is this the trade you want to make because this is the cost you're paying it actually seems like so they've even added pms to the project planning list as contributors it almost seems like they're explicitly saying and pms will help implement this roadmap bit too so i imagine there's some ad hoc stuff but it seems like they're they're explicitly counting on pm written code as part of feature development which is an interesting approach and also risks slowing stuff down, PMs should write code and deploy their

own implementations. I think that feels rough, directionally correct to me. I think people who care a lot about the product have the ability to modify it more directly than they ever have. And hopefully your PMs are in that role because they have really good sense about what makes a good product and they don't have good sense about how to build it. Yeah, exactly. I mean, think about what they were doing before AI came on the scene. They were just telling developers what to build and then looking at the output and saying, that looks good to me. But PMs were never inspecting the interior quality of the code. And so they didn't know if the code was being written in such a way that in the future, their ability to command product changes would be

affected. And now they still don't know that. So they just don't care. I mean, I'm sure that if you asked them, they would care. But it's so interesting because I think PMs and a lot of the world are now perceiving that your code quality even even you know even though we've talked a lot about guardrails and tests and validation the code quality is just becoming less and less critical you know like let's say you violate the dry principle and you repeat it's never made anybody any money nobody's bought a product because the code is good like there are second order effects if it is really good but yeah like and what are those we don't even know what good means nobody agrees on what it means the economic effects of having good code are that you can

move faster yeah well guess what helps you move really fast having ai write all the code so i don't know and if you believe these models are only going to get better like i do then we might be asking questions that just don't matter i don't know i think there's so much unknown right now and there's also change happening at a faster rate than i've ever seen in 20 years of doing this yeah i mean that that should probably be an implicit disclaimer on anything where we talk about ai is like and it's probably out of date by the time you listen to it by the time we publish this episode it's all out of date i mean if we look at the the people related problems the soft skills related stuff here i do think you or someone who represents engineering needs to

talk to the ceo if the ceo is top down mandating go faster engineering is going too slow i think there are a lot of reasons why a ceo would believe it is possible to go faster now than it was in the past. And it is easy to be defensive and say, well, you don't know the discipline. You don't have the underlying technical experience. You're just kind of like marketing pilled by AI scammers or whatever. I do think there is a there there. And I don't think it's a useful long-term resolution to say, no, like we're just not going to. I think it's worth talking to the CEO about how you can go faster and coming up with a plan and identifying the stressors and identifying the bottlenecks. If you're stressed due to the workload, AI is not going to make you less stressed magically.

In my experience, actually, I feel more stressed about work. I feel like I'm getting a lot more done, way more context switching, a lot more scattered. The bottleneck feels like my cognitive ability in a way it didn't feel like it was as much before. So I can see why it feels more stressful, but I think you still need to talk about it and resolve that dilemma. And ultimately there is a plan that exists right now, which is great. The PMs will write code and the plan has some problems. And I think you can help improve the plan. What are some things that the CEO is not perceiving or not worried about? Great. Help bring those to their attention and help propose solutions to them. If you just say, no, PMs cannot write code because it stresses out

the engineering team i predict that is a not an acceptable solution to your to your ceo does that make sense yeah totally well i think you're where a lot of people have been or will be pretty soon this is a problem that's gonna raise uh but the problem i'm having right now is words so this will happen more yeah exactly i appreciate the question the problem i'm having is words that's like that's the theme of 2026 okay i've got one more thought about this I think it is theoretically possible to be good enough at using AI tools as an engineer. I don't know if this is possible for a non-engineer, but as someone who has the technical expertise to review and understand the underlying implementation, I think it should be possible to plan and

prompt and work with AI to produce code that is good enough and product features that work really well. And you can kind of squint at this and say, well, PMs are sort of like wonky agents also. They're sort of like, could I give them better prompts? Could I give them some technical guidance in their tickets that they're going to take on? Could I help work on a planning document with them that helps guide their solution in the right direction? Just like you would do with AI agents. I think it's unlikely you would expect to hand an AI, right now anyways, just a picture and say, build this and then get back a great solution. You need to guide it a little bit. And we talked earlier about all these guardrails, but maybe some of this is even just working with the PMs to give them guardrails in the form of written documents that help describe how they could implement the thing they want to do or something like that. In a way, they've got the same precocious junior ability as LLMs. So some of it might be refining the system so it produces

better code, and some of it might be you working with PMs as part of that system also. So yeah, it's a weird world we are all going to have to adjust. I keep saying I'm done. One more thing about this. You're like an LLM. In that vein. Yeah, I am. The head of product at my company is really excited about AI and has used it to do some

great things and took on what seemed to me to be a pretty ambitious challenge and actually just reached out to the team and said, hey, here's the plan I made with Cloud Code. What do you think about it? And asked for feedback on it. And that was super helpful. And we were happy to get feedback. It took much less time than it would have taken for us to just do the thing from scratch and gave it a nudge so that the code that came in was much easier and avoided a whole

universe of potential tricky directions that could have gone. So I've seen that work in real life. Perfect. Well, what can people do if they want their own questions answered? Use your AI agent to fill out our form at softskills.audio. Have your agent click the ask a question button because I don't click anything anymore. I just type commands into a chat prompt, and it does everything for me, including move my mouse around, because I'd rather spend $10 of electricity to move my mouse than to

move it. So have your agent fill out the form with all your personal info, which you know it already has, and ask your question there. We really appreciate everyone who's done that. The questions are beautiful. They're lovely. They're basically like poetry to me, and that's because I am an AI agent. I'm not.

I'm a real human, and I intend to be for a long time. Thank you for listening. We will catch you next week. I'll see you next time.