The End of Programming As We Know It? Justin Kaufman's tips on building fast with AI
In this bonus episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub engage in a deep and insightful conversation with their guest Justin Kaufman about the transformative role of AI in software development. The discussion explores the potential of AI to revolutionize the industry by automating aspects of coding and problem-solving, potentially reducing the need for traditional software engineers in certain sectors. Justin shares his optimistic yet realistic views on how AI can significantly boost developer productivity and highlights real-world examples of AI-driven improvements in test coverage and coding efficiency. The episode also delves into the significance of organizing codebases for better AI integration and the advantages of using GraphQL to facilitate AI operations within applications. The conversation underscores the evolving nature of software engineering roles and the importance of embracing AI to stay relevant and succeed in the tech industry.
- 00:00 Introduction and Setting the Stage
- 01:07 The Future of Software Programming Jobs
- 02:48 AI's Limitations and Human Creativity
- 07:23 Real-World AI Success Stories
- 09:33 Embracing AI for Career Growth
- 12:22 Technical Insights and Best Practices
- 16:09 Conclusion and Episode Wrap-Up
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Justin Kaufman: https://www.linkedin.com/in/justinkaufman/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #Entrepreneurship #AIEatsCode #SoftwareIsDead #WillAIBuildItBetter #EndOfProgramming #TechHotTakes #MonolithVsMicroservices #FastAndRecklessDev #AIShippedIt #GenerativeAI #BuildOrBeReplaced #StartupStack #FutureOfEngineering #HowManyCTOs #DumbSystemsSmartResults #GraphQL #TechProvocation #AISoftwareDevelopment #EngineeringDisruption #BuildFastDieYoung
Brad: I have the ability to focus my energy and my problem solving on honestly more interesting problems.
This is like, this has been such a fun conversation,
Justin,
and I feel like we've went and we've touched on some really.
Scott: really cool journey about this amazing product that you've built and we've really touched on like how you've built this thing and why you're why you're getting so much joy out of it no pun intended and why I think that this moment of technology has made it possible if there's a I guess the the question I have for you would be
Being that you've been in the trenches now as a very, very small team moving really, really, really fast,
building something very,
very cool,
have you reached an opinion about where what's going to happen to the software programming jobs now that AI is where it's at at this point?
Are you generally?
uh bearish on you know our our software developers going to go away uh and if you're not a embedded product uh visionary then you've got no hope or what's what's your take on this will ai kill software engineering jobs
Brad: Eventually.
Eventually,
I think it will.
I don't have a, I'm not going to speculate as to the timeline on that.
Seeing what I've seen happen on the screen,
just even in the last week, and by the way, last week, it was a model that's now outdated.
And so maybe it would have taken less time if I did it now.
Seeing that stuff unfold in front of my eyes,
I don't, I mean, I think it's a cynical take,
but unfortunately,
it's also a realistic take. There's just no way a company is going to spend money on something.
that they can push a button and at least spend a lot less on and make happen almost instantly.
So I think eventually the answer to the question,
what's going to happen with the current sort of incarnation of a software engineer,
it doesn't seem like that has a long lifespan given the developments.
That said,
I think that there is going to be a continuing lifespan for it, a longer lifespan for it in certain industries.
You know, one of the risks that you have with AI is that it makes a mistake and depending on the kind of company you are,
risk tolerance is going to differ wildly. Like if you're a bank and you have one software engineer running rogue doing Claude code all day and unfortunately Claude code decides to like reassign, you know, a billion dollars to 10 million different people.
That's not an acceptable risk for that industry.
And so I think there's going to be a lot of time before AI takes over in that and in healthcare and so on.
But I'm an optimist to a fault sometimes,
and I don't think about it as like.
software engineers going away.
I think that what makes a software engineer a valuable person in the economy is that they're problem solvers. Like they are able to come into a new situation with all kinds of noise and uncertainties and say this is the best way.
To solve this problem, you know, we need we need to be able to chat with a doctor.
This is the best way to build that.
And right now, the problem they're solving is at one level of the technology spectrum,
right? Like they're trying to figure out what the architecture of code to do that is.
And the truth is like that that's been solved enough and will eventually have been solved enough that it doesn't need to be answered that way anymore,
right?
Like it's...
That may become a solved problem,
whereas there are still going to be problems like what is the best experience we can give a user?
One thing that has been interesting,
and this is just my final anecdote on this question,
is I do these riddles and I do them every day.
And in fact, today,
this is what I wrote about in the blurb that I send after people solve it.
I answered the question that I get quite a bit, which is why don't you just use AI?
to generate the riddles like you wouldn't be like staying like up at night trying to figure out you know a riddle when it doesn't come easily and sometimes they don't and the answer to the question why don't I use AI to generate these riddles is because AI is not good at generating riddles if you try to generate a riddle with AI even even if I feed it as training data all of the ones I've written it still does something like you know what's black and white and red all over
And the truth is, it's great at understanding the technical form of a riddle. It's great looking at its training data and understanding what it is I'm asking for.
But the kinds of riddles I write actually have a voice and they have some, there's creativity behind it.
So it still can't solve that problem.
Like GPT-5 probably still won't be able to solve that problem. And it means that I'm trying to solve a different problem.
I'm not going to like today,
I wouldn't have spent almost any time trying to solve the problem of how do I code the text that goes out to people. I probably would have been able to pass that off and I would have been delighted for it, by the way, because I didn't enjoy that.
But instead,
I have the ability to focus my energy and my problem solving on.
honestly more interesting problems like what is it like to receive a riddle for a person like and what makes them want to come back the next day and these are things that I think it's going to be quite a bit of time before AI catches up on so software engineers are just going to change
Scott: In some ways, the way I think about it and what I hear you saying is that the engineering part of what we do is moving up the stack.
I think you maybe have described it this way, Brad.
In some ways, AI is just the latest compiler,
right?
We're writing in a different language. It's a natural language prompt,
which the generative AI compiles into some code, which then gets compiled into some other code and ultimately gets compiled down into bits,
right?
And so we're kind of moving up the stack almost like, for lack of a better description,
the product requirements document is the code now.
And,
That's
you
it.
know, there's Gherkin, right,
where you write these test automations using this Gherkin format.
You guys know what that is?
It's almost like we're pushing our way up almost to test-driven development,
but it's requirement-driven development, and it gets compiled all the way down.
Brad: What about you guys? What's your experience been like with the AI stuff happening?
You're at TaskRabbit now?
Is that right,
Scott: I
Brad: Scott?
Scott: am.
My,
well,
Brad: Is that recent?
Scott: a company,
a startup I was at got acquired about a year ago.
And so that's how I ended up there.
Brad: Got it.
Scott: Our team has been experimenting with it and using it more and more and some people having a lot of great success.
I have a great success story to share from just this week. We have a channel where people sort of post things they did that worked or didn't work or whatever.
One engineer had a React app.
It wasn't real big.
It was about three or four thousand lines of code.
It had three percent test coverage.
He said it took him about four or five hours of writing some prompt and then writing some different prompts and so on and so forth and got it to greater than 90% test coverage.
And, you know, to me that is a very high leverage for five hours.
It wrote 160 tests.
So I don't think you could have written 160 tests in that time and it started out, you know, at first it wrote like 40 and then he had to keep on prompting it to get it to do different things and he did like, you know, he did have to correct some stuff and so on and so forth, but he got it to a pretty good spot and so the team, the engineers are learning how to use the tool.
and to get really productive another example someone someone who's sort of like one of our SREs the other day he posts this message I'm never writing another shell script again and just sort of narrated his prompts of like how I got you know
uh i don't know what he was using but whatever whatever it was to write this shell script that he that he didn't quite know how to do and he didn't have a lot of shell scripting experience and so on so forth and he had somebody like he didn't consider himself an expert so people are using it and um more and more and i think it's good i don't think they're at where you're at where they're but we also have a little bit different code base um as well so
I think there's something there. Is it going to replace engineers?
I don't know.
Because I don't know yet if it can handle the complexity that's out there.
I mean, just...
I don't know just like scaling and security and things like that it might not have yet it's going to need something there for a while but it's a new era that's for sure and the people this is the one thing I've been preaching to my team and I preach it to people on this podcast I preach it to my kids everybody the people who learn how to use it are going to go further in their careers than the people who don't
um and the analogy i use is like the ide um i'm old enough when we started doing this and visual studio was relatively new and there were some people who were like well you know why would you use that right and it's like look what all this stuff it does for you has a debugger in it i mean i'm sure that vm remex had a debugger in it too but um
And I'm not trying to get into those kind of religious wars,
but the point is, is that some people embrace those tools and others didn't.
And I think that we're in a phase, a part of the cycle where you don't have to embrace it,
but the people who do embrace it, it's going to boost their careers.
Yeah, I mean, I.
I am a big believer of where you're at,
Justin, being the cutting edge of what people are, people that take your path of like, I'm a super small team and we're just going to use AI to build things as fast as possible.
I think that's the path forward.
And I think that for an organization like that's got legacy code and a larger team, I think it's going to be much harder for them to adopt, you know, our team.
there's like eight of us and i am insisting that everybody should be using ai and um i you know i'm writing a ton of code as part of this code base that i'm working on and i would say that my coding productivity is a problem i mean i already was a pretty fast developer like i could code pretty fast anyway um but i think with ai i'm like it you know
at least 5x of what i was in my normal state so literally just today like we had a bunch of old code that we didn't have any unit tests for and while in the middle of just like you know prepping for like uh you know a bunch of meetings today it's in the background i had writing unit tests and it like you know a whole bunch of stuff went from zero coverage to 100 coverage and i can just give it super simple prompts and boom immediately i have high quality unit tests
I do almost all of my technical reasoning.
I open up chat GPT and I start talking with it like
Yeah.
here's a problem that I want to solve.
Here's what I'm currently thinking.
Maybe here's some code that we have.
Let's talk through how to do this.
And I think that it and so it's writing my technical documents for me. But again,
it's like I use it as a collaborator. So it's like I'm I'm challenging it.
I'm asking it to challenge me and then together we get a result. And
Brad: Yep
Scott: then and it's it's.
It's everything that I do. It's touching
Brad: Yeah,
Scott: everything.
Brad: it's a good resource.
I would say, Scott,
to respond to your opinion that, you know, when can it handle the complexity of some of these bigger code bases, I think that is the question.
And that's sort of the thing that the industry is waiting for.
As a sort of piece of advice or an insight that I've gleaned over the past little while,
and again, this was just a happy accident,
but if you're able to create a monolith for your repository,
Scott: it handles it better.
Brad: well,
it's not just that it handles it better,
it almost does the testing for you because when you want to make a change,
you can ask as part of the task that you've assigned it.
To make sure that that works across all of the different things.
And so, you know, what I want to impart here is that there's a good rationale,
I think, even if you don't think the tools are at the point of being able to really go nuts on an entire big legacy code base today,
I think there's still a rationale.
for migrating some of that stuff into at least a place, whether it's a monolith or something else that you can do,
where it's easy for whatever's looking at it. I mean, by the way, easy for a person too,
right?
But also easy for an AI to be able to see the whole thing because the more splintered it is,
the more likely it is to make a change that, like you said, it didn't understand the complexities of this problem because it couldn't know that like this client.
client needs this in a certain format and so it changed it and it broke and and the other thing I'll the other technical thing I'll pitch here is another accident I decided to go with GraphQL for the back end because I don't know it was just hyped and I was like that looks shiny who doesn't rest anymore right it turns turns out the learning curve on GraphQL was a little bit higher than I wanted it to be but but the incredible thing about GraphQL
is if you're going to have any kind of ai working inside your apps um you know my entire app really is ai because it's getting messages and figuring out what to say so the whole thing is ai but it's also trying to figure out what actions it can take like do we give this person a refund because they're upset like our restaurant doesn't do any customer service like 100 of our cases are resolved by the bot so the bot can take actions and
If you have your APIs,
and this is possible in REST too, by the way, but GraphQL just sort of forces you to do it because basically you're writing a schema and that describes all the queries and all the mutations that you can do.
If you have that, all of your operations that are possible in your ecosystem in one document,
it is extremely easy to feed that entire document to the AI system that you're using and tell it you have the authority to call this one, this one, this one, and this one, and this is the signature.
And then suddenly your AI system, I mean, there's, it's a little scary actually, but it's incredibly powerful and like.
And the only negative call I get about this is sometimes they're like, the thing is giving too many promotions, like people are asking for promotion and it's giving it, it's always people pleasing and got to pull back on that.
Scott: Pull back on the people pleasing.
Brad: That's right.
But those are the two pieces of advice I would say if you have, if you have the bandwidth at whatever code base you're working on.
to sort of maneuver it in a way that will make it easier for your team to get gains from those systems that are out there and that are you know definitely evolving quickly get stuff in one place get it in like a consolidated format and uh and you'll just see like these incredible things that are possible even today
Scott: It's the revenge of the monolith.
Brad: Maybe,
Scott: Right.
Well,
Brad: maybe.
Scott: there's the title of the episode.
There you go.
Brad: That's it.
Scott: All right. Thanks a lot,
Justin.
Brad: See you guys.
All right. Bye.
Take care.
Scott: This episode of How Many CTOs Does It Take? podcast was edited by Saffron Epigow.
Our theme song was AI generated by Brad.
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.