Rediscovering the Joy of Coding through AI with Paul Brown
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub are joined by Paul Brown to delve into the misplaced fears of AI supplanting engineers, highlighting instead its potential to enhance productivity. Paul shares his journey from skepticism about AI's capabilities to recognizing its strengths, drawing parallels to the historic shift from mainframes to personal computers. They discuss the importance of writing and critiquing implementation plans, effectively utilizing AI tools, and managing resistance to AI integration in engineering teams. The dialogue is rich with insights on evolving AI models and the future of AI in coding.
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Paul Brown: https://www.linkedin.com/in/paulrbrown/
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #AI #AIRevolution #ArtificialIntelligence #AICoding #AIProgramming #AIAssistedProgramming #EngineeringManagers #AITools #AIDebate
Guest
Paul: You know, the resistance is due to a sense of, you know, disempowerment or some kind of hypothesis that the AI is going to somehow supplant, you know, the engineer.
I think that's misplaced.
Brad: Welcome, everybody, to another episode of the How Many CTOs Does It Take podcast.
My name is Brad Hefta-Gaub and my co-host is.
Scott: Scott Porad.
Brad: And today we have a very special guest with us, Paul Brown.
Paul,
how would you like to introduce yourself and tell us a little bit about what brought you here?
Paul: Gosh.
Well, I guess I'm fresh off 10 years at Salesforce.
was a lot of fun to work there through some really interesting parts of the company's journey.
When I joined 10 years ago,
we were all first party with a little bit of Azure and maybe a little bit of AWS and some of that company knew about,
some of that company didn't know about at the time, but got to, you know, ride shotgun and drive the stagecoach some and had a...
really good time on the journey to being all in on public cloud and you know to a certain extent being all in on AI as well so saw that over the past couple years you know prior to that I was an entrepreneur did that twice didn't learn my lesson the first time I guess did a really brief stint at Amazon back in the early days of AWS
In way, way back,
I was a math professor,
but I gave up that vow of poverty when the internet was young and went the entrepreneurial way.
Brad: Love it. Welcome to the pod.
Paul,
you and I have known each other for a couple years and I know that we often spend time talking with each other on the skin track about various challenges that we face as upper management leadership in engineering organizations. And so I know that you've got lots of thoughts to share and lots of wisdom to share with us. But recently you posted on your link.
LinkedIn about you personally diving into vibe coding and kind of trying to sort of see what this this whole beast is all about and I thought it was interesting what you had to share about that so why don't we get started what do you maybe give us a little bit of a what got you into the idea that you were going to explore this space you know kind of in a more intimate way and what have you learned
Paul: Oh, gotcha. Well,
I think, you know, I heard from a number of folks and not just technical folks that AI was magic.
And I'll admit,
I started out as a bit of a skeptic. I remember I went and asked ChatGPT in the early days some hiking question and got a completely ridiculous and wrong answer.
You know, and had the Nelson months,
you know, ha ha finger point,
you know, see this isn't magic moment.
But lots of other people did experience the magic, and I related one experience in that blog post on LinkedIn from a friend who had started a marketing analytics function at his company,
you know, on the back of Python and SQL and other things emitted from ChatGPT.
And it was wonderful for him because he had 100% more software,
100% more knowledge about his business.
And maybe it's not all perfectly right,
but 100% more than he had before.
And that kind of, that inflection point between not having something and having something,
you know, it makes me think about the old days.
mainframes and mini computers and then the shift to personal computing and this is kind of that like is this a shift to personal software you know can we kind of all have whatever we want so I wanted to explore that and there were some things that I wanted so I've set about you know trying to build them and just sort of bumbled my way through it
Brad: Yeah.
Yeah,
that's so cool.
Actually, it's so interesting that you describe it as like the transition from mainframes to personal computers.
Only reason I think there's something about the way you said that was like reminds me I've heard this recently on a couple podcasts,
some some VCs and founders I listen to on podcasts,
and one of them has been comparing really trying to say that what the what the product of
the LLM chat interface is it's not really a chat bot what it is is a computer right and so thinking of that space of sort of like generative AI as as if it was a computer that you can ask to do anything that you want it to do I think that's an interesting framing I don't know if that's exactly how you you meant it but like for sure there's there feels like there's some parallels there
Paul: Oh, you know, I think that's definitely there,
you know, and had lots of discussions along those lines,
like, at what point does the catwalk ripple,
you know, eat the rest of user experience?
You know, should I build a UI?
Should I create a, you know, a more rigid but directed user experience or should I, you know, throw the door open?
just have a conversation with the computer you
Brad: Yeah.
Paul: know the and the conversational aspect I think is really compelling especially if you're in a mood where you want to iterate quickly like if you know like if yes it's a binary thing if it's on off like I don't have a conversation with my light switch if it does the right thing it's very simple it's
I guess it can't go wrong, well they can,
right,
but probably won't go wrong, but there are a lot of things that are more subtle, you know, and can be, you know, much more personal without having to do all the work of stacking up abstractions and figuring out where this button goes and that button goes and everything else.
There you go.
Scott: Can you tell us briefly,
I guess, you know, you talked about this little in your blog post, you started out by trying to make a solver for the New York Times tips game.
Brad: Yeah.
Scott: This is a game I play from time to time.
If you could answer this for us, and maybe it's not an interesting answer,
but maybe there was a mindset or a frame of mind you went into trying to solve it, and then did you learn along the way that using an AI bot to solve it, they actually had to take a different approach to it?
Like we have a frame of reference for how we've done computer programming all these years,
and I would assume if you jumped into it, you jumped in with that frame of reference.
Did it change at all or was that it?
just to learn a new way.
Paul: So it's a little bit of both.
Like I think I took a practitioner's approach the first time. So I wrote a spec. The spec included a data model.
The spec included an expectation for how the solver was actually going to be implemented.
I worked through things enough that I knew that a backtracking style solver was what I wanted it to build.
You know, I knew I wanted it to write in Rust,
which with the language that I was interested in learning about that,
you know, the lots of my programming chops atrophied, you know, over the time that I was in management at Salesforce.
I read a lot of code, but I didn't write almost any.
You know, and I got some of what I asked for.
So the.
You know, the AI did a good job of interpreting my data model,
you know, I got a working Rust program at the end.
There were things that I didn't get that I did initially ask for.
Like I asked for an idiomatic functional implementation.
And I got the, you know, all of the AI is actually their first version of the recursion past mutable collection.
you know not remotely what I was after but yeah so so I think you know I did get questions from some friends afterwards which is like well why didn't just point the guys at the game and say write me a solver for this you know here's here's the input here's the output I desire let the magic happen
You know, and that can actually work really well and it can actually work really poorly,
you know, with with a couple of the other experiments like pulling avalanche data to add to Strava.
There were a couple spots where that,
you know, like letting the AI do all the work went sideways.
You know, a couple of interesting ones,
Claude kind of got itself in a twist trying to scrape out information like geo-geason boundaries and zones for avalanche forecasts and full information.
And, you know, at some point I got tired of watching things scroll by and, you know, went and figured it out myself and told it what I wanted it to do.
And then it was.
You know, back to work after that.
That was great.
Gemini 3,
when I went back to do some improvements, actually completely made up a Strava API feature.
Brad: Ha, ha,
ha.
Paul: which which was awesome is it hey for so i asked it for you try to provide constrained prompts for these things give me three improvements like three areas where this can be better and i have an idea we should implement this x drop a signature header on the web hook and you do this hmac 256 signature and it's it's better it's more secure so i'm like hey great let's do that
um and then the whole thing stopped working and well it stopped working because the web hook was returning 400 because this header wasn't being supplied let alone a correct signature and so then i asked like hey would you mind starting your source for the x value signature header because i couldn't find anything about it when i looked myself
And like,
oh,
yeah, sorry.
Apparently I made that up.
Let's back it out.
Scott: That is really interesting because this is something we've discussed many times, which is you have to have some expertise.
You have to be the QA person in this stuff, and that makes it a little bit harder.
It makes me worry about your friend who set up the whole marketing analytics program not knowing anything,
because what if it's wrong?
Brad: You know what I think, though?
Let's explore this.
Is it the QA person or is it the engineering manager?
Like the more I.
play with like paul your story is so on point like how i you know i've got hundreds of stories that are exactly the same and it feels to me like the role i'm almost always playing with with the ai coding agents is i feel like an engineering manager i feel like i'm helping give them make sure that the ticket is well enough described uh kind of
a little bit like, do I know what you're good at doing that I don't have to get super specific about?
Or do I know what you're bad at doing that I need to get more specific about?
That feels like I'm managing an engineer.
Like, you know, you know, different engineers are good or better at different things.
And then I'm paying attention to it. And when it starts to spin out of control, I say,
hey, stop, stop for a second.
Give me a status report.
What are you doing?
What are you stuck on?
What can I help
Scott: Yep
Brad: you with?
And like literally those are the prompts I'm giving.
Like literally the prompts are pause.
I see you appear to be stuck.
Please give me a summary report of what you're working on and what are your challenges and let me let me talk to you about it. And it comes back and it says, you know, oh, I I've been trying to figure out how to do geo fencing around the perimeter of the avalanche forecast zone,
and I'm currently struggling on getting something that, you know, works and passes the test,
you know.
OK,
let's talk about that.
Paul: Yeah,
one where I could like click the 100 emoji for that.
Yeah, I mean, unknown unknowns are not limited to AI,
right?
And it is the engineering manager's instinct for, you know, the smell of, you know, something being unknown.
Maybe we don't understand that. I'd like to dive in there.
I'd like to hear more, you know, stop.
I mean, I do think, by the way, I'd love to come back to your question too,
Scott,
which is I think like, what if it's wrong,
you know, is an interesting one too,
but I think it kind of loops back to what Brad was saying too.
Scott: Back to the original question,
it sounds like you started by treating the AI as kind of like a...
programming team or a programmer that was going to follow your spec and then you evolved a little bit to just you you went from being a product manager who gave a the programmer a spec to a stakeholder who just said I want a thing that does this and it got hung up from time to time and you'd have to stop it or as Brad was saying start to interact with it so
It changed a little,
it sounds like, your process along the way, but it didn't, you still kind of treated it, well,
no, that sounds like it definitely changed, I guess is what I'd say.
Paul: Yeah, one,
and,
you know, I'm still experimenting, you know, I have more tools to play with now,
you know, like Keyro won the $20 for you this month.
lottery which in by the way it's like all the different little bits of opinionation and capabilities in all these different tools you know the features and sub features and different capabilities of Claude versus Gemini or anti-gravity versus
um hero or you kind of the list goes on and on and there just so many like different interesting ideas and perspectives in there um and like steve yegi's beads is on my list of things to play with too which i haven't gotten a chance to try out yet
Scott: The question for you, Paul,
but also you, Brett, is it your view with all these tools and how they all have different
looks you know different angles on it and the landscapes are evolving so rapidly you can see two ways that people approach this one is to say look i'm just picking this tool i'm going to call this the cold fusion way if you guys remember cold fusion which is i'm picking this tool it might not be the best tool but the i'm going to learn it i'm going to know it frontwards and backwards right versus
you know you started out your butterfly approach then which is like we're going to jump from like you said twenty dollars a month here twenty dollars a month there what do you think if someone's just getting into this what do you think the right approach is to try a bunch of different things or to pick one and try to figure out how to make it work for you
Paul: Do you want to go first, Brad, or I have an
Brad: No,
Paul: opinion.
Brad: I've shared my opinion on this multiple times on the pod.
Paul: Okay.
Brad: So Scott better know what my opinion is, but I want to hear you. I want to hear from listening to you either,
Scott.
Okay,
tell us, Paul,
what's your opinion on this one?
Paul: So I think like Markdown is the new code.
Right. So those those specifications that you hone kind of that top level description, you know, if it expands out to an implementation plan or a set of documents,
right,
that's what's actually portable.
And that first experiment that I took the same stack and gave it successively to Gemini and then Claude and then Codex and that was Gemini 2.5.
pro got it first and then Gemini 3 got it later you know I had them critiquing each other's implementations I still do that I had CoPilot GitHub reviewing some code changes from Gemini today and then poking Gemini to ask what it thought of CoPilot's feedback but it's it's the natural language
artifacts the top level artifacts that are you know the new code if you will and you know what we used to think of as the code you know is much less important right it's like the the output of the compiler from 40 years ago
Brad: I like Paul's answer.
My answer is similar but slightly different.
And what I've been saying.
uh scott to your question is absolutely i do not think people should be focusing on a tool and trying to get deep on that tool i think that is a fool's errand and i think that you it just is moving too fast and so getting good at one tool is the wrong approach um instead i think the right approach is get really good at
working with all of them and understanding how to be that engineering manager like it's it's learn how to read read the code that it generates learn how to
read the markdown that it generates,
right?
Like my current working style is I go into plan mode, like all the tools I'm using now all have plan mode.
So I don't write the markdown anymore.
I give them the problem statement and expect them to give me the markdown of their plan.
Then I read that plan as if I'm an engineering manager to say, does this engineer understand the problem that I've given to them? And I critique their plan. So I critique the markdown.
And then once I've had the conversation with the agent,
the agent about their markdown and i'm satisfied with their markdown then i ask then i say build right and all of the all of the modern tools anti-gravity cursor you know all of them now have plan mode and
And so that the skill that I'm focusing on, I must say this, please,
please,
please, if you're an engineer listening to this podcast,
absolutely get good at describing problems and reading implementation plans. Now, this is something you already should have been good at before AI existed is reading implementation plans of your fellow developers and learning how to critique them. That is a skill that every engineer needs to have.
have and it's that much more important now in the in the age of AI coding agents
Scott: It's fascinating because advice I've given to engineers earlier in their career,
Brad,
when they say,
how do I get ahead and so on and so forth,
I say,
look,
get good at writing and implementation.
Paul: You plan.
Brad: Yep.
Scott: Like once that's to me, that's like the key thing.
If you can make a plan,
if you can understand. So to write a plan, you got to know what is being asked of you and you got to understand how your system works so that you can know how to build it.
And if you can write a plan,
then you're at a fork in the road.
You can get leverage from other people and inviting other people in essentially you're becoming a leader or manager or you can be you can write more and more sophisticated plans and become more and more.
more of a climb up the engineering track,
right?
And it's interesting what you say there is it shifts from writing the plan to being able to evaluate the plan.
Paul: Yeah.
Yeah.
Well, and to think about that, like if you were going to write a plan,
before you could write a plan, you have to be able to also evaluate your own plan.
Right.
Like, how do you know that your plan's a good plan is you're effectively self-evaluating your plan.
And to your point, Scott,
like self-evaluating your plan,
you have to understand,
do you understand the thing you're being asked to do? So you've got to get really good at understanding how to ask things,
how to understand what you're being asked for. Right.
That's like that's one of the important skills. And then the other important skill that you described is understanding enough about your system.
To be able to just to think about how to mutate that system.
Right.
Scott: Mm
Paul: And
Scott: -hmm.
Paul: so this is this is like job one of the first time, the first week of every engineer on a new on a new team is they better focus on do I understand the system I'm about to start working on and how quickly can I get up to speed on learning this system, learning its learning its architecture,
learning the data model.
uh learning potentially learning its quirks and weaknesses and strengths and then i have the ability to start writing code right like if i don't understand the system i'm working on i can't think about it about how to mutate i can't reason about how to mutate it and so i you know more more than ever i'm thinking like that that
That's how you that's how I believe you have to interact with this AI is it's like another developer on your team. And so how would you evaluate?
How would you participate in assisting another developer building a feature on your code base?
Scott: I want to riff for a second on understanding the code. In the last couple of weeks, someone in our company hooked up an AI chatbot into Slack,
which...
However they get it has awareness of our code base.
And so now we're seeing people ask questions like this.
Where can I find the name for the partner in invoices?
And it responds with some answer like here's where it is in the coder. What are the definitions of user suppression levels and where can I find them?
And that's pretty interesting.
Both of those questions were asked not by engineers.
by other people in the company who needed that information for something um but we're giving engineers you said okay you start on a new team you go and try to understand the code we've abstracted that away now we're abstracting it away from even the engineer needing to understand the code and now the folks outside of engineering can do it which is pretty cool okay let me let me let me pose another question deal
Paul, you were a manager of engineers at Salesforce for a long time.
There is, it seems like in the field, pockets of apprehension, if not downright resistance.
And I can understand that.
I think it was Upton Sinclair who once famously said it's hard to get someone to understand something when their salary depends upon not understanding it.
And that's what a lot of these engineers feel like.
What's your take on as engineering leaders,
engineering managers,
if we should be mandating, basically forcing people to use these tools?
That's a question I've been struggling with for the last, say, three to six months.
Should I just, I don't know how I would make my team do it, I can't force their fingers to type certain things, but I've been pondering that question.
What's your take on that?
Paul: Gotcha.
Well, there's there's the Spotify memo,
right,
which is,
Scott: Mm
Paul: you
Scott: -hmm.
Paul: know, before you come and ask me for money or a headcount, you know, be prepared to provide an argument for why you couldn't get this done with with AI.
So I think.
You know, the resistance is due to a sense of, you know, disempowerment or some kind of hypothesis on that the AI is going to somehow supplant, you know, the engineer.
And I think that's, I think that's misplaced, right?
It's a new tool.
It's a way to magnify your impact,
right? To multiply your effort.
Um,
and I think people really need to, um,
go into it with the mindset of how do I make this work versus why didn't it work when I tried something?
Um,
Scott: Mm
Paul: because
Scott: -hmm.
Paul: it definitely can be made to work and the potential gains are significant.
Um,
and it's not that it's going to replace you, it's that it's going to multiply you.
It's going to exponentiate you.
you know if you're starting at zero you can get to one if you're starting at one two starting at two four um so i think you know this like you didn't like typing up giant yaml documents to feed to something great get the ai to do that right but the person who's in charge of figuring out what the ai should do you know how to connect that to the business and what's supposed to happen
and that's you um so yeah grab grab that tool and get busy
Scott: Another bit of resistance I get, here's a quote I just got this week in a Slack message.
AI-generated code isn't good enough yet for complex business logic.
Paul: They're just wrong,
Scott.
Yeah.
They're just wrong.
Would you mandate it? And if so,
how?
I, well,
okay,
so here's my quick answer.
I have not mandated it in the teams that I'm working with,
but I do say to every single person, both in team meetings and one-on-ones, you know, look, man,
we got to move fast.
We got to move fast.
Right. I work in startups, so it's all about moving fast.
We got limited runway.
We got to like make something happen,
you know, and so it's like, we got to move fast and I need you to be moving as fast as you possibly can.
And, you know, I mean, there's, you know.
a bunch of my teams that i work with like they see me doing it like i i'm a i'm a player coach right i'm i'm actually also writing code and they see that it's like i already was a fast developer and they just see me easily 10 times faster and so it's like look we got to move fast and so i feel like if you don't see other people being productive if you see other people and you don't see that they're being more productive with it
And you genuinely are missing out on that, like you're missing that you're it's it's not apparent to you what is happening to the rest of the team making great strides on this.
then you're probably not a good fit for the team already right like that you're already sort of signaling that you're not a good fit for the team right so i don't think it's about mandating it's more like this is what we're doing we're moving fast we're a team we gotta we gotta we got we're burning daylight let's move right so that's my take
I agree with like burning daylight is a great.
you know a great analogy like we've got some place to go we need to get there with the foods we have on the ground um you know i think it's useful to you know pivot back and forth between the why and the how like i was saying and when you find somebody with an objection like that i've chatted with some friends who work on like legacy c++ code base
And the comment was like, oh, my God, no,
like,
don't don't let, you know, anything near that code.
Why do you say that? Well,
there are so many undocumented invariants and so much tribal knowledge. And so that actually like, wow,
I would love to.
itemize that technical debt i would love to find a way to burn it down like i've got you know 50 headcount like like let's throw some money at some of these tools and start doing those things to rein in you know those areas of unknown
But I think just a little bit of back pivoting back and forth between, you know, why and how, why not? Well, how do we solve that?
You know, and enough application to that will get you somewhere where you can be productive.
Yeah.
And I'll just say like, you know,
we, I think that was.
on one of the earlier episodes of the podcast that we did when um we talked to i don't remember who it was but they made the point like if you if you tried this you know at the time it was like if you tried this six months ago and you didn't like the results of it then try it again right and i like it's just getting so much better at hard stuff man i i had this bug i had to fix uh last week
And it was like it was an obscure race condition.
I it was hard to reproduce,
you know, and but I knew the subsystem that it was in and I had data about like when it fails, this is the these are the signals that I have to know that it's failing.
And I threw anti-gravity. I threw this at anti-gravity and basically it came back and it absolutely identified the race condition.
It had full flow graphs saying here's exactly the race condition that will exist.
If this timing happens this way,
this is going to happen, you know, and it came back with a proposed fix and I was like,
okay,
I believe you, that's plausible.
my code reviewers aren't going to accept it unless I give them a working example of forcing the race condition.
So go back and modify the code,
add in the appropriate like delays and timers to cause the race condition to happen.
And then they'll believe me that we fixed it because this has been haunting us for like six months,
you know, and it did it and it did it in like.
30 minutes and this is a bug that has been haunting us for six months and it's it's one of the most complex things that you can deal with like race conditions in asynchronous systems and it nailed it so
Scott: That's pretty impressive.
Paul: keep trying
And don't be surprised when it gives you something completely hallucinated like making up an API call that doesn't exist because it's still going to do that.
Yeah, interesting I'm somewhere under the hood is something stochastic so but
Yeah, yeah, it's still probabilistic. It's not actually deterministic.
Scott: I have a technical question for you Brad
You know, you were talking a few minutes ago about how you were interacting with I don't know which model it was and it was telling you what it was thinking.
I actually don't know how it does that part of it,
how it how it has awareness of what it's what it's doing.
Paul: This this I don't know how much you've you've looked into this yourself,
Paul,
and jumping into this. So I feel like I'm a little bit of a naive outsider on this, but this is my this is my understanding. So one of the biggest advances that I've seen that's happened in the last, I'll say year,
is that.
This is what we talk about the latest models are.
agentic friendly right that's kind
Hmm
of the language that you hear in the in the frontier model development community and the sort of like vc space and sort of like what are we doing here and so they say basically like the models are more agentic friendly and what i understand that to be and you can see it in cursor and you can see it in anti-grab you can basically see it in these ides is they started like exposing this i think to those power users like us that wanted to like see it
see it thinking and what it is is basically that the llms that are agentic friendly they have they they basically you can you can hook them with if you need to run a tool this is a tool that does the following right so for example
In essentially the setup of the LLM, they say,
here's a tool that will list code for you.
Here's a tool that will do a diff for you. Here's a tool that and they basically pre give the LLM access to a bunch of tools and the tool and the LLMs are good at going,
ah,
I understand the I doesn't really understand it, but it's like.
If I get to the stream of tokens that say,
I should compare two files,
then
Mm-hmm.
run this tool and look at the results and expect it to be this way. And so it's this combination of the LLMs happen to be agentic friendly in that their training and their post training allows them to be good at.
knowing to instantiate a tool and knowing how to read the results of that tool and in the ides nowadays they're basically blurring that stuff past you really quickly as it's working so you'll literally like i just like uh i've got this race condition bug i know it's in this code right
It says, you'll see, like blink on the screen real quick,
the user wants me to find a fix to a asynchronous race condition bug.
I am going to analyze the code in the modules that they said. Let me search for this keyword that the user used.
I'm now searching for this keyword.
I've now found it in this file.
Let me read that file.
I am reading that file.
I'm comparing that file to the last version that they said the race condition didn't exist in.
You know, it's basically spinning all that.
And it's just the model kind of like eating its own tail, feeding
Scott: It's
Paul: on it.
Scott: like narrating itself
Paul: It's narrating itself.
Yeah.
So
Yeah,
that's
just fascinating to me.
what I mean when I say it's thinking through.
And Paul,
you mentioned that same thing. You could see when your avalanche app was trying to do it, you could see it was spinning out on trying to solve a piece of the problem.
Yeah,
I'm doing this, I'm doing that.
And there's that aspect of recursion, you know, back in the first days of, you know, the generative approaches,
right,
that was strictly input and output.
And then people started kind of looping it back. It's like, OK, well,
generate a plan based on the prompt and then kind of work your way down, generate,
generate this like gradual escalation of capability until you get to something that you know how to do.
Like, OK, I know how to read a file and I'll look up something in a database.
um you know those those things can kind of take you sideways right if you don't have the right set of tools at your disposal you can do something like read the entire database instead of writing a query to get the information that you need um but yeah the that that whole space and the fact that it works sort of interesting and really magic
And there's so many cool,
like, I have yet to spend much time exploring multimodal AI and really curious about things like ternary LLMs, right,
the possibility to compress this sort of approach to problem solving down.
To places where you don't need a GPU anymore and it's suitable for you put in your light switch.
Yeah, smart light switch.
Yeah, totally
So yeah,
I think there's so much cool stuff out there.
totally yeah
Well,
Brad,
should we end with our AI game?
I'm going to bring up Hacker News.
Don't look at don't look don't look ball
Oh,
It only works, the game only works if you don't look at Hacker News yourself.
okay.
Yeah, not that kind of looking.
Okay,
I'm not looking.
I am looking at Hacker News.
How many of the top 10 articles are about AI?
Oh, 10.
I'm taking the under.
I'm taking the under on that.
Taking
Let's
the under.
see.
Well,
I'm trying to think like what has happened recently.
You know, there's there's been no big cloud flare outage sky volute is weeks ago.
Netflix is buying Warner Brothers.
That's probably not going to build on Hacker News unless there's some show that people won't be able to watch that they really like.
Yeah, I think my guess is still going to be high.
You think 10 is wrong?
That's too high.
I'm going to go with – wait,
I'm going to go – here's my guess.
I'm taking the under.
But
Scott: Yep.
Paul: I'm going to be even old,
so we'll see how much this read. I'm going to go four.
Four of the top ten articles are about AI.
Scott: Okay,
number one,
Netflix to acquire Warner Brothers.
Paul: Look at that.
Scott: Number two,
Loud Flare outage on December 5th.
Paul: There you go.
So far, no AI.
Scott: Number three, Gemini 3 Pro,
the frontier of vision AI.
Paul: There we go. That's
an Cool,
AI.
That's
cool.
one.
Scott: Number four,
item potency keys for exactly once processing.
Paul: No, not AI might
Yeah.
Scott: Number five,
perpetual futures.
I don't know what it's about,
but the URL is bitsaboutmoney.com.
So I'm going to say no AI.
Paul: be crypto related.
Scott: Could be.
Number six,
Frank Geary has died.
Paul: Age 96.
Scott: Not a party.
Paul: I hadn't heard that, but there you go.
Scott: pardon me number seven feels buzz in css that's almost like the opposite of ai
Paul: BizBuzz in CSS,
that's awesome.
That's really cool.
I want to see that program.
So I have to comment though so the last time I got a chance to go back to programming which was nearly 20 years ago
Fizz Buzz was all the rage,
you know, wrote Fizz Buzz in Haskell before writing some other stuff in Haskell, but it's just hilarious to me that Fizz Buzz is still out there.
By the way, I think we both are at this point. There's no chance that it's even four,
right?
Because you're at you're at seven and we got one.
Yeah, yeah, the price is wrong.
Scott: Yep.
Number eight.
useful for you Paul patterns for defensive programming in Rust
Paul: Wow,
like it?
I thought, wait, Jose,
I thought the whole point of Rust was you didn't need defensive programming because the language guaranteed you couldn't screw up.
No,
no, no. The language with the right idiom and flag will do that. But it's like Scala,
right?
There's plenty of rope to tie yourself up if you want.
All
Scott: Where
Paul: right,
Scott: are you?
Paul: number 10.
Scott: Oh, we're on number nine.
Paul: Okay,
number nine.
Scott: Framework sponsors catchy OS.
I had to look that I had to click on that link because I didn't even know what that meant.
Hey,
catchy OS community,
we have some massive news to share today framework,
the company behind the modular and repairable laptop.
Paul: Lucian is now sponsoring Catchy OS.
Brad: Okay.
Paul: So I don't really know what that's about.
Number 10 should almost be the entire theme of this entire podcast in its entirety from since we started,
Brad.
Brad: Okay.
Paul: Most technical problems are people problems.
Brad: Yep.
Accurate.
Maybe AI,
there might be some AI in there.
Paul: A blog post by a guy named Joe Schrag,
who I've never heard of before,
writes about that.
So there you go.
That's the AI game for today.
Apparently,
Brad: my only
Paul: AIs go and bust.
Brad: one out of ten well you're you i i should have i definitely should not have taken your money on this one because i i i knew right out of the gate that you were a rookie at this game when you said 10 like it's
Paul: Oh, it's not based on the game.
That's okay.
Brad: The rules are clear.
You guess how many articles in the top 10 are about AI.
Well, Paul,
thanks for coming on the pod.
Thanks for talking to us about this.
I actually feel like...
uh i'm you know in in the in the camp of like using ai to speed up developers and to to build software faster and more reliably i am quite bullish and i love that you kind of decided to dive in and kind of like learn for yourself like really kind of test it and experience it and i love that you kind of
came with these, you know, the approach that you took.
And it's pretty exciting that you're out there attacking this.
And so thanks for sharing your experience.
Paul: Thank you. Thank you for having me. Thank you for having me on. I mean, this is just so fun.
And I feel like, you know, there's kind of some of that giddy joy of.
making software again.
So yeah, thank you very much.
Brad: Cool. So how do we summarize this?
Everybody,
if you're skeptical about AI code,
just discover the giddy joy of writing software again.
That's the words of wisdom from Paul Brown.
Paul: Right.
And then smash rate and subscribe.
Brad: Smash that subscribe button.
Rate and review.
And tune in next week to another episode of the How Many CTOs Does It Take podcast.
Paul: Bye-bye.
Brad: This episode of How Many CTOs Does It Take podcast was edited by Saffron Efigab.
Our theme song was AI-generated by Brad.
Scott: Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok and Patreon or at our website at HowManyCTOsPod.com.
And remember to rate, review and subscribe on the podcast platform of your choice.
Brad: How many CTOs
Scott: Thanks for listening.