If a company lays off developers, it means they don't
have enough ideas to feed a development engine, that's now
five times more productive. Product is a bottleneck.
In a lot of companies, the product management needs to keep
the developers developing. The features become shallow just
to keep developers working. But now with AI, this is
breaking down. Today's guest is Stephan
Schmidt, a CTO coach and the author of The Amazing CTO's
Missing Manual. With 45 years of software
engineering experience, he specializes in transforming
organizations into AI first teams and helping CTOs navigate
the challenges of AI adoption. How do you think will be a good
strategy for organizations to start rolling out AI
effectively? Business is not focusing enough
on AI usage for strategy, vision, features, and KPIs
before it gets to a developer. You need to have a vision where
you want to be and how AI helps you in that vision.
Not just being reactive and say, okay, let's lay off 20% of
people. That's not a strategy.
Do you think a software development team needs to convey
something different to the executives?
Business expects everything to be twice as fast, or 10 times as
fast, which is the kind of difficult to deliver.
And then the CTO needs to somehow create a structure and
also managing the expectations. If you're only thinking about
generating code, you're doing it wrong.
The struggle that the CTOs have for creating five time more
output is the architecture is not in place.
The processes and the control structures are not in place.
AI is a great opportunity for CTOs to shine in the top
management. You could do things earlier than
other people. And that's a way to shine.
Having five prototypes for great ideas per week that wasn't
possible before. That's now possible with AI.
Hey, quick pause. My goal with Tech Lead Journal
is simple. Learn from the best in tech so
we can all grow together. If this resonates with you, hit
subscribe to follow the channel. It's the biggest way for you to
support the show and help us keep bringing great guests and
insights to you. Thanks for being here, and let's
get back to it. Hello everyone.
Welcome back to another new episode of the Tech Lead Journal
podcast. Today I have with me a repeat
guest, uh, Stephan Schmidt. Um, so if you still remember,
it's about a year, maybe a few months ago, that we talk about
The Amazing CTO's the Missing Manual, from Amazing CTO, right?
So Stephan today is coming back to continue the theme of talking
about how to become amazing CTO. But this time I'm sure all of us
know that what is happening these days is about AI.
So probably today's topic will be predominantly about AI based.
Welcome back Stephan to the show.
Looking forward for this exciting conversation.
Thank you, Henry. Looking forward for this ex, uh,
to this, conversation and thanks for having me again.
Right. So Stephan, I think like one
year ago, if you still remember, we talk about the missing manual
for amazing CTO. So what made you wanna come back
this time? Uh, is there something else
still missing from your manual? I'm rewriting parts of it and
especially I'm adding a chapter on AI because that's the
elephant in the room, obviously. And that's from my CTO coaching
also one of the biggest challenges currently, how to
structurally introduce AI and transform software development
organizations into AI-first organizations.
That's a challenge for a lot of people.
So maybe if you can share a little bit from your customers,
what are some of the main theme that they are talking about,
they're asking you, or they're confused about, I guess?
Their situation is basically, they get a lot of pressure from
the CEO, from business to introduce AI, uh, and to push
really hard. Then they have developers who
are experimenting with AI. Uh, they are using Cursor or
Claude Code or Copilot, something.
And then the CTO in the middle needs to somehow create a
structure from the engineers that experiment and do stuff on
different speeds. Some are very, very fast, some
are very, very slow. And the business pressure to
deliver and also managing the expectations.
Like business expects everything to be twice as fast or 10 times
as fast, uh, which is the kind of difficult difficult to
deliver. So this is where they find
themselves in. Yeah.
So I guess if we still remember back then when we talk about
the, one of the role for CTO is actually to become a bridge
between business and tech, right?
Um, so I guess this time, I would imagine the leaders, the
executives seeing all the news, the crazy thing that, you know,
a lot of AI vendors are kind of like promising.
So I guess the pressure is kind of real, right?
We, they expect the development to be, I dunno, twice, 10x
faster. So first of all, do you think
this is something that is, you know, true, that development can
actually be that much faster? Um, yes and no.
Uh, sorry for that answer. Like I'm currently, I'm also
doing a lot of AI stuff on my own, in private, not being a
coach. But I write myself, for example,
a coaching operating system to make my coaching smoother and
the operations of that smoother. And I don't look at the code for
some time now and just let Claude Code write the code.
And I feel like, yeah, I think it's five times faster or even
more. I'm very, very, very productive
on one hand. On the other hand, there are two
things. First, um, it's very, very
straining. I feel like as an engineer,
doing like four features a day or something compared to one
feature a day and that's, that has a high cognitive load and a
lot of stress. And also managing AI is kind of
stressful on one hand and the other.
I think it works for me because I have the right guardrails in
place in my new project. And the architecture of the
project is also done in a way that works for AI because it was
built, kind of built with AI in mind.
The struggle that the CTOs have by for creating five times more,
five times more output, is the architecture is not in place.
And also the processes and the control structures are not in
place. You know, the, so control is
also very, very, challenging thing with AI.
So business needs to also adapt. Yeah, you mentioned something
very interesting, right? So when we have kind of like the
process, the guardrails, maybe the rules, right, the
architecture in place. Probably AI can be a good
leverage, but I would imagine it's not.
I mean, it's, it could be a luxury in so many software
development team to have all these in place, right?
People are still expecting the development team to actually
still speed up no matter what the situation.
So do you think, um, software development team needs to be
able to convey something different to the executives?
And if so, how should they actually communicate it back
about, you know, the managing the expectations?
So first, yes, I think they should communicate differently.
And what they should do is... I'm a big fan of framing.
You know, there is this book, Don't Think of an Elephant.
I think that framing is a very, very important skill for
managers to have. And the frame would be, for me,
would be our architecture is not yet AI ready and we need to get
it AI ready. And we are not a greenfield
project. We are, we have a existing code
base and we need to put stuff in place.
So yes, we can benefit from AI and from generating code faster
and more features, but we need to get into position.
That's one thing. And the other thing there is
stuff that can be done. One thing you can do is have
much more prototypes. That's something like, people at
Google called, I think called, prototype first.
There's been discussion about this on LinkedIn, on other, in
other places. Don't do requirements first or
don't do ideation first. Go for prototype first.
And I think this is something where CTOs can deliver already
if you have a pipeline of prototypes and also MVPs.
Um, you can show the benefit of like having, I dunno, having
five prototypes for great ideas per week.
That's something that wasn't possible before.
That's now possible with AI. So you can deliver on some
promises of AI to the business and keep them happy until your
architecture is more in place to enable this boost in
productivity. Yeah, so definitely I think
everyone needs to be kind of like be trained, I guess like in
terms of how to use AI because there are so many spectrum of
experience in terms, for example, senior, juniors, right?
They all could benefit differently, I would think,
right? And especially if you mentioned
there's no guardrail, then it becomes, uh, much more important
for the seniors or maybe the executives, the CTO to actually
put them in place. But talking aside from coding
for a moment, right? So what do you think are some of
the other use cases? I know that people are talking
to ChatGPT or Gemini, you know, asking some questions.
Are there some other use cases that you think in, you know, in
your client situation that they could benefit from AI.
Yes. I tell all my clients, uh, if
you only think about generating code, you're doing it wrong.
And I also do a lot of workshop, AI workshop, helping in the
transition. Mostly helping with the
motivation of developers and motivating developers to use AI
because there are some who don't, a group of developers who
don't want to use AI and a group who are very eager.
And so most of my workshops are around motivating people.
And I show a lot of examples. You can do a lot of security
scanning, bug scanning. You can use prompting to get
into a new code base to understand things.
I think, um, Claude is very good at finding bugs with the right
prompts and the right guardrails.
So there's a lot of stuff that, and some stuff that was been,
has been tedious before for developers, that's now much
easier. Like sometimes fixing a bug or
some, some other stuff. Creating some documentation,
creating some tests. If you do it right, I think
Claude Code is good at, even better at creating tests than
developers are, if you're doing it the right way.
So there's a lot of things that developers can do and
engineering can do besides generating code.
And on the other hand, I show a little, it's very naive perhaps
example, but if I connect GitHub issues, Zendesk with MCP into
Claude and the code and everything, and I ask Claude
Code what features should I develop, you know?
And then it looks at Zendesk and customer requests and bugs and
issues and all of these things. And, perhaps a strategy document
in, uh, in Notion, and then it comes up with a list of features
that you should implement. Or you can say, well, this is my
strategy, this is my roadmap. Does the strategy map to the
roadmap or not? Or does the roadmap fulfill the
strategy? So that, I think that's where
business needs to adapt. They obviously adapt in
marketing and sales, but that's where business needs to adapt in
product development. Uh, where I know something
about, I dunno, about sales or marketing.
But, um, I think in product development, business is not
focusing enough on AI using or AI usage for strategy, vision,
features and KPIs. Finding KPIs that if we build
this, how can we find out if it works?
This kind of stuff that's pre-development.
Um, I think there is a huge potential for business to use AI
in product development before it gets to a developer.
And just focusing on generating code and saying, okay, we want
to use developers to generate more code with Claude.
With Claude, I think that's too narrow focused.
Yeah, so I think even like for me, when you mentioned about,
you know, checking your strategy, vision.
Even communicating that strategy and vision itself can benefit
from using AI to maybe structure your sentence, make sure it
aligns with your strategies, your KPIs, like you mentioned,
right? I think definitely it's, um, up
to your creativity on how you use AI.
Uh, sometimes definitely it can give you some hallucination or
something that is totally wrong. But it's really up to you at the
end to actually criticize or maybe accept the suggestions
done by AI. You mentioned about MCP and I
think many people might benefit a lot from using MCP, right?
So even I read, like I think Shopify mentioned about, you
know, the usage of AI everywhere within the company and they
connect everything through MCP internally.
So tell us what kind of power that someone can leverage in an
organization if let's say they have so many MCP available
systems or sources that they can connect to.
So first of all, I think integrating systems with MCP is
a low hanging fruit. Introducing, uh, MCP servers or
MCP bridges proxies, API proxies, is a low hanging fruit.
It's a low effort, low effort, big gains.
So that's the first thing. The second about MCP is there
are a lot of use cases that also my clients use.
The very first one is just connect your data warehouse with
MCP to a chat bot or to Claude Code, and then show the CEO that
he can ask questions about the data and about what's the best
customer and what should we do, how can we upsell things.
And so there's a huge benefit of connecting your data sources
with MCP. But then there are also some
other things like, simple, very simple example, but if you
connect GitHub, perhaps not for MCP but you can also use it for
MCP, GitHub to Claude Code. A build process fails, you can
just say, okay, the build process fails.
What would we need to do to fix it?
And then if Claude Code comes up with the right plan, you say,
okay then execute the plan. So you can also do a lot of
operational things, um, with MCP and integrating into Claude.
And something that some of my clients do is also do a lot of
compliance work with MCP. Like you connect, uh, various
sources, your processes, your implementations, code and all of
these things. And then you can pre-screen for
compliance before your audit and say, okay, am I compliant or am
I not compliant? And then probably, the AI agent
will come up with a list of stuff that you're not compliant.
There is a ticket that is not approved, there is this and this
and this. So, uh, it really helps you stay
compliant if you do this iteratively and fast or
continuously. Yeah.
So I think some good tips there, right?
So I like the one that you mentioned connecting your data
warehouse or maybe even database, a simple database,
right? That lets the non-technical
users to query it using so-called natural language,
right? And this is something that I
think maybe some people realize it or not, right?
So by leveraging MCP combined with the chat interface, right?
Actually you can kind of like execute a lot of things through
natural language and AI would somehow be able to translate
that to kinda like the API calls, maybe summarizing and
making inferences and all that. So definitely MCP is a good
thing, especially for non-technical users, I think.
Because previously maybe it's difficult to actually get the
data source, analyze, use the tools and all that, but probably
now it's getting much, much easier.
So I think one mention, one mention you, uh, initially said
is you have some jobs to motivate developers to using AI.
So I'm a bit intrigued by this, because I would assume many
developers would love to use AI to help them, you know, maybe
writing some code and things like that.
Tell us the case why some developers are not motivated?
There are several reasons I, so I don't know.
You know, I'm not in the head of the, of developers.
I'm not... I can't read the mind of people,
but from what I see and from what...
I've been writing code for 40 years.
So from what I see and what I see in people, I have some
ideas. One idea is the company comes to
the developer and says, use more AI so you can have a more
stressful job, produce five times the features and kicker,
same salary. So you know that, you know,
that's where reticent makes sense.
In which world does this make any sense?
I don't know. I think it doesn't make any
sense. So that's one thing.
The other thing is look, because everyone benefits.
The product manager benefits, the CTO benefits, the CEO
benefit, everyone benefits basically from the simple
generate code setup. The developer does not.
And so that's one thing. The other thing is, the other
thinking is if your value proposition is you're a senior
developer with five years or 10 years of React - I hope React is
that old but I guess - so if you have 10 years of React
experience, and then you should use AI and Claude Code is quite
good at, if you tell it to read this source and this
documentation, this documentation, it's quite good
at doing some hooks and components and all of that stuff
that you thought, that distinguished you.
The knowledge has distinguished you from other developers and
that's taken away. So AI is taking a lot of things
away that distinguishes you from other developers.
So why should you like AI? It's leveling the game, the
playing field. And if you're at the top, that
does not make a lot of sense either, you know?
And the third thought is, that's how I see it is.
There are coders and there are creators.
When I was a kid, probably, uh, I told you last time, but when I
was a kid, I wanted to write video games.
So I learned, I teach myself programming in a department
store as a tool to write video games.
I didn't want to be a coder. I want to create a, be a creator
of video games. And over time I like coding, I
liked the puzzles, I liked the intrinsic beauty of code.
That's all the things I like. But nevertheless, I'm a creator.
I want to create things with tools.
And if you define yourself, I think if you define yourself as
a creator who's using tools to create things, you flourish with
AI. But if you define yourself as a
coder who writes code and you're in the business because you
like, love writing code, you don't care too much about what
you create. You care a lot about the beauty
of the code. And I like a little bit beauty
of the code, but mostly I'm a creator.
But if you're a coder, then I think that's a challenge for you
to, uh, to accept AI as a new tool.
So these are three reasons that I see that developers resist AI
adoption. Yeah, very, very interesting,
uh, reasons that you mentioned there.
I think it could also be, like a threat, like when you mentioned,
right? It could be seen as a threat to
their kind of like skillset, existence, job existence, I
mean. We know that a lot of people are
saying, you know, we need lesser developers, right?
Team size is gonna shrink. We see a lot of layoffs.
Personally, what do you think? Would, um, developers, a lot of
developers lose their jobs? Or something else could happen
with the usage of AI? So a little bit, I'm a little
bit gloom and doom. Uh, so I think developers will
lose their job. The reason is not AI per se, but
what I've been saying for last 20 years that product is kind of
a bottleneck. In a lot of companies I've seen,
product is a bottleneck and that manifests in a way that product
creates very shallow features. They always need to...
The most important thing in a lot of companies I see is that
product management needs to keep the developers developing.
That's a primary goal, you know. The product fails if developers
have nothing to do when the Scrum, when the sprint starts,
you know. So so there are a lot of work
that product does to keep developers typing.
And so they are already, I think seeing product management is
already thinned. They don't have deep thoughts
and great features. The features become shallow just
to keep developers working. That's what I see.
So in this way, product management has been a
bottleneck. And I tell startups, you need
more product managers, not more developers.
You know, you need to have higher better ideas, not faster
development. But it worked.
But now with AI, this is breaking down, you know, so the
product is becoming a bottleneck.
The number of good ideas that they're coming up with ideas is
the bottleneck. And I say if a company lays off
developers, it means they don't have enough ideas.
You know, it's not like we are going, we become more efficient.
Yes, but bottom line is you don't have enough ideas to feed
a development engine that's now five times, two times, five
times more productive. Um, so the doom and gloom in me
thinks, yeah, there will be layoffs, but the reason is not
AI by definition, but because companies are limited on great
ideas. Very interesting because I
rarely hear this kind of perspective, right?
So I think it kinda makes sense in a way, right?
Because if you don't have too much so-called innovation,
product development, like good features to build, right?
Obviously, if we can automate lots, like big parts of our
software development, you probably won't need a lot of
developers, right? So I think, um, definitely it's
very interesting perspective. And I find that a lot of
developers actually think that AI is also taking a lot of their
jobs in terms of, you know, like now, you know, I don't need so
many juniors anymore. Or now I don't need to hire like
different stack developers anymore.
So what do you think? Is this something that is valid
and what do you think should juniors do then if let's say
that's the case? I think there is a huge
opportunity for juniors. Why?
Some of my clients and I think parts of the industry are moving
to a product engineering role, which means taking on
engineering, managing AI but also understanding product and
coming up with features and all the minor decisions yourself
without a product manager. Because I wrote a large article
about Amdahl's Law and how it relates to product and AI, but
that comes into play as a driver, uh, as one of the
drivers that we might see the industry moving to a product
engineering role. And I think like that's, I see
it more like, you know, when I...
I've been doing this for 40 years or 45 years.
I've seen so many transformations in our industry.
Not as big as AI, but like moving from machine language to
C, moving from C to Java, moving perhaps from Java to Python,
though for me it was more Perl, Python, Java, not the other way
around. It's just like these ancient
Fortran developers, they don't change.
It's not Fortran developers who jump into Java.
It's basically, if you look at it, it's junior Java developers.
It's juniors coming from university who want to demand to
jump into Java, who want to use Java jobs.
Whereas senior C developers had a great resistance moving to
Java. So there was always an
opportunity for juniors to jump into new technologies to get a
headstart in new technologies, because the incumbents, mostly a
lot of incumbents resist the change.
So I think there is a huge opportunity for juniors, to
become proficient in AI, to know about AI, to become product
engineers. And then they will become
senior. They will not become senior Java
developers or senior Python developers, but they will
become, senior product engineers.
So I think there is a huge opportunity for juniors.
Yeah, I think that, that's, again, very another unique
insight, right? So I think the key message for
juniors is don't get discouraged, right, about this
AI. They can actually become a much
better AI native engineers. And in fact, in some random
posts or articles that I've seen, right?
And even personally myself, I've seen some of my juniors actually
leverage AI differently than what I could think about.
Simply because, you know, they are trained using AI in the
first place, right? Like they are exposed to AI.
I always think of it like the social media era, right?
Sometimes, when you are not exposed from the very beginning
about social media versus the youngsters who are very savvy
with social media, the way that you can leverage on social media
is so much different than, you know, the older people.
So I think, don't get disheartened, uh, use AI to the
best of what you can do, actually.
I think again, this is a great insights.
So speaking about leveraging AI a lot for developers, right?
I personally, myself, feel that, after a few time, right?
I get addicted myself and I feel every time I wanna start work, I
would just leverage on AI first. My worry is that a lot of people
fall into this same trap, and I think the portion of thinking
becomes lesser and lesser, and we kind of like outsource a lot
of thinking and decisions to AI. So do you think this is a valid
concern? Uh, will there be any issue with
our critical thinking going forward?
I think on one hand, critical thinking is, um, is important.
You should think about what you're doing and especially why
you're doing things. I'm a huge proponent in asking
why you do things. That said, I think, yes, you're
losing. Like as I just mentioned, I made
a transition. I started in a little bit in
dabbling in BASIC, but then I did most of my programming was
in machine code or in Assembler and partially in machine code.
And then, on 8-bit and 16-bit CPUs.
And when I moved to C, I forgot all of that.
All of the really, really cool stuff that you could do with
registers and address modes and all of these really cool skills
I had. Optimization machine code and
Assembly optimization skills in my head.
I lost this, but I learned new things and C enabled me to do
things I could not do in Assembler.
Same thing with Java. And I think with AI, we see the
same thing. My decisions move one, one step
up. So I do not make the decision,
should I create a caching layer here or should I do this here or
there, you know? But I think it comes, like, I
just move one level up. Uh, it's just one meta level.
I'm meta, making meta decisions and then I'm making meta meta
decisions. So I think I just move up the
food chain. And I make different decisions
and have different kind of thinking.
And not just when I need to write C code, I have a different
kind of thinking than compared to writing Assembly code.
So that's how I see it. We just move up the food chain.
It's not like some people say they become dumber.
Yeah, I, yes. I mean, I can't remember, um,
phone numbers. Does it make me dumber?
I don't know, perhaps, but I can do so much more with my phone
and do so much more thinking and I think it enabled me a lot so I
can live with that. I don't remember any phone
numbers except that of my parents.
So that's, uh, yeah. Yeah.
I also don't remember a lot of phone numbers, uh, a lot of
birthdays, a lot of mathematics operations.
So I think, uh, in one sense, yeah, you could say a little bit
dumber, but at the other end, like what you mentioned, there
are a lot of possibilities, how you can leverage the technology.
I like that you mentioned that we are moving one level up,
right moving to more the, like, higher level abstraction, right?
So thinking about, you know, not just the code itself, the
programming language, but thinking maybe about design,
architecture and maybe features, outcomes, tests, and all that.
But I think one of the counterargument is like some
people into this vibe coding. So, you know, you just type your
thing and, uh, AI create the code for you without even
looking at the code itself. So what do you think about vibe
coding? Have you tried vibe coding?
Is it a feasible way of building software, do you think?
I mean some of my insights, it might be shallow one or deeper
one, but some of my insights on vibe coding.
So I recently wrote an article line which says I no longer look
at code, at source code. But there are a lot of things
that enables me, I think enables me to do this because the
projects are small. I'm doing on one hand, but I'm
also like 45 years developers. So I know probably how to prompt
things because I know how where Claude Code could derail or
where there are challenges around caching, caching, cache
consistency, where to store data.
And so a lot of stuff that I know can go wrong, I put in my
prompting. So I think I'm a good vibe coder
on one hand, so it works. But I need to be a good coder to
be a good vibe coder because your prompting is very
different. And I'm happy with the outcome.
It's like the application that I'm currently writing is 35,000
lines of code. And I'm not looking at the code
and I'm happy. It's, um, when, so.
Works great. Lot of tests and stuff.
So that's one thing. The second thing about vibe
coding, I think if you start from scratch, there is a danger
if you start from scratch. I think people do not understand
what an AI is or what an LLM is. AI is this big thing, LLM and
neural networks. LLM is a part of that one.
And I think LLMs, they don't understand what LLM is that,
it's just a non-deterministic probability machine.
And a very, very important input to this is your existing code.
And LLM is not a senior developer who looks at bad code
and says, oh, that code is bad. You want that feature?
I need to first, A, refactor this one, and B, build the
feature in a great way. But people think like they, all
the talking about how an AI is trained on GitHub code, it's bad
because it's trained on bad code and all of these things.
I think that's a mis, a gross misunderstanding on how LLMs
work. I think it's much more useful to
think of LLMs like they take your code as input, they take
your prompt as input, and based on their training and
probabilities, they create the most likely code that fulfills
the prompt and your existing code base.
So if your code base is bad, the added code would also be bad.
It's not like, it's not, oh, I read some real great code on
GitHub so I apply this here. No.
If your code base is bad, it will create bad code.
So I think it's very, very important to start from a great
code base with a great template on one hand.
And I think it's also important that at some point you need to
refactor it. From getting it from here to
here, and then you're happy. But if you stay here, it gets
worse and worse and worse. And I think this is something,
these two things are reasons why vibe coding goes bad, you know?
So, um, if you are doing it right, I think it can be great
for small right architecture that I mentioned before, uh, it
can work. But it's easy to shoot yourself
in the foot if you don't know what you're doing.
It's really dangerous, I think. Yeah.
So that's why I think we hear and see a lot of different
outcomes when people vibe coding, right?
So I think definitely the few key things that you mentioned.
First, you need to be a good coder, right?
You really need to know how a good design, good coding looks
like because, otherwise when AI suggests you a lot of code
suddenly in one go, right? Uh, you would be able to
understand whether it's going in the right way or in the wrong
direction, and you kind of like tweak along the way, right?
And the danger here is like, let's say many, many people sell
this promise that now non-technical people can
actually write code simply by vibe coding.
And a lot of such tools are built, you know, like Lovable,
Bolt and things like that. Uh, but I think for prototype,
simple things that you mentioned, uh, maybe it would
work. But to make it something that is
more robust, enterprise ready, secure, and all that, probably
needs a lot more engineering fundamentals, right?
Yeah. So definitely, I agree with, uh,
your approach, right? So speaking about the approach
here, I think you mentioned, that you have been around for 45
years, right? So a lot of people don't have
this luxury in their career. So what do you think will be a
good advice, thinking about your head as a CTO coach, what would
be a good advice for maybe, you know, five years, 10 years of
experienced coders, right? How should they approach AI?
What kind of things that should maybe learn more or upskill more
in terms of leveraging AI the best way?
I think it's important. I think the industry for various
reasons will move towards to this product engineering role.
I think that's, it just is a sweet spot for, it solves a lot
of problems or several problems. Uh, so I would upskill myself
more on product and product thinking and business thinking.
Uh, then I would upskill on algorithms, you know, so that's
what I would look into. And the second thing is you need
to work with AI and see its deficits and see its benefits
and learn about it. If you want to be a great
prompter, you need to do a lot of prompting.
If you want to be a great coder, you need to write a lot of code.
So that's how I see it and what people should do.
Just experiment and see what's happening and what's not
happening. It's kind of a transitional
problem because I really believe that today, as I said, I, for
vibe coding, you need to have a good developer background to
create a positive outcome. I'm not so sure about what
happens in five years. I'm giving talks to companies,
universities, which is one of them is called Beyond Software
or AI is Not Software. That's one of the talks I'm
giving. And some months ago, one example
is playing tic-tac-toe. Because I believe that in the
future, code generation is a transitional technology.
You know, there will be no code, there will be no software, no
code. There will just be AI in some
years, I dunno when, but in some years, you know.
And some months ago, I wanted to play tic-tac-toe, uh, with
ChatGPT as an example to, there is no tic-tac-toe game in
ChatGPT. What is ChatGPT able to do?
And I played tic-tac-toe and it didn't work.
You know, it made mistakes and there were very, very, a lot of
handholding. Because I have a conference talk
coming up this week. I tried the same tic-tac-toe
example with Claude and there was no problem.
So I was just saying, let's play a game of tic-tac-toe and Claude
played a game of tic-tac-toe with me.
Um, made no mistakes. And so we had, I've seen some
progress on that. Very, very low difficulty level
obviously. Tic-tac-toe is a very simple
thing but I've seen some progress on can't play to I
don't need to write a tic-tac-toe game, I can just go
to the AI and say, let's play tic-tac-toe.
And because I do a lot of these experiments, I did a minesweeper
experiment some time ago where, um, I vibe coded from one
prompt, prompt shotting Minesweeper, worked, and now I
thought, okay, let's play Minesweeper with Claude Code or
ChatGPT. That did not work yet.
So as of yesterday, that's not there.
But I believe we are moving to a no-source-code set up in the
future. So for a transition, very long
talk, sorry. But for a transition, I think
moving, taking on more product understanding is something I
would go. In the long term, I think source
code is not that important anymore.
So don't worry as a junior. It's just, it's a transition.
Yeah. So definitely there could be a
possibility where we can kind of like, uh, write software by
leveraging on a lot of natural language, just like vibe coding
in this case, right? So maybe in the future, the AI
could be much smarter, right? In terms of writing better
design as to what we want it to be.
So definitely looking forward for that future.
And I think a lot of organizations these days
definitely want to roll out AI, right?
So maybe as part of your experience as well, how do you
think would be a good strategy for organizations to start
rolling out AI or making sure that they get the most effective
benefits from using AI? First, I think you mentioned it.
First, I think you need strategy, you know.
And the strategy and... Do we want to lay off 20% of
people uh, so we make more profit and we use AI for this?
That's not a strategy. That's not an AI strategy.
I think you need to have a vision where you want to be and
how AI helps you in that vision or how AI is part of that
vision. And then from that drive a
strategy and then say, okay, we need to do this and this and
this, and this needs to be in place.
Like my example for strategy is, which shows I have no clue about
Mount Everest, but my example is about Mount Everest.
For a strategy, you need to have two things: things you want to
achieve and things that you have as capabilities.
For example, if you want to climb Mount Everest, there is
Base Camp One and Base Camp Two and the North Col, Ridge, and
then The Summit. That's the things you need to
achieve. And then there are things you
need to have like an ice pick and a tent and an oxygen mask
and check it and stuff that you need.
And that's what for me is a strategy and that maps to AI.
What are the things that I need to have in place and what are
the things that I need to achieve?
And that would be part, for example, you need to
re-architecture probably your code base, you need to change
your processes, you need to add the deep prototyping.
So you need to have a lot of changes in place and say, I need
to do this, this, this, this, this, this.
And that's part of my strategy, you know.
Whatever you want to climb, if it's Mount Everest or do
something else, cross the world or you know.
Whatever you want to do with AI, but you need to have a strategy
that shows that you can leverage AI to get there.
That's what I think is important.
Not just being reactive and say, okay, let's lay off 20% of
people so we increase profits and that's not a strategy.
Right. I still remember back then when
we discussed part of the role of CTO is to come up with a
strategy, right? And you mentioned that a good
strategy enables people to make better and easier decision,
right? Um, so I think the same thing
here, right? If you can lay out a good AI
strategy, definitely you can help people make good decision
on how to leverage AI or benefit with AI.
Maybe if you can give some examples, I don't know whether
you have something in mind, right?
What are the typical good AI strategy that people can adopt,
you know, especially for software development team?
A lot of the stuff that I mentioned.
I think you need to have uh Move to prototype first.
Um, have a product funnel of prototypes, MVPs, PMF, and use
AI to drive all of that to a certain point before you take
over the source code. I think that's very important
part of an AI strategy today. Second, for the whole company,
that's not CTO, but mostly CIO stuff.
But you also should have a strategy on how you want to
automate, what you want to automate, who owns this?
It's also part of the strategy, who owns AI is like everyone
owning their own AI? Is there an AI officer who makes
sure efforts are coordinated and compliant and secure?
So that's part of the strategy. That's a decision to be made, I
think. I think, re-architecture, I
mentioned several times. That's a part to to of your
strategy. Also part of the strategy, how
do you get developers, all developers to adopt this?
Two of my clients just made, uh, the decision to re... to have a
new position, which is product engineer.
And if you want to become product engineer, you need to do
A, B, C, which is part of that is creating prototypes, doing
AI. So that creates a natural push
for everyone to adopt AI and to think about how to use it so
they become product engineers. It's just not only a relabeling,
which is something I would've done, I would relabel the titles
which would not be the best thing.
I think this is something to earn is greater.
But the strategy needs to be explained how you get these
people on AI. But also like how do you do AI
training and security that ties into do I have an AI officer or
not? But nevertheless, what's the
strategy about data? I think part of the strategy
could also be do you want to build your own models?
Is there a benefit in owning your own models, training them
or not? Are you a prompting company?
Are you using prompts for 25, 26, and then move to your own
model? So what are your...
I think a lot of these things need to be decided and put in
place so you, so that you can believe you make it to your
vision. Yeah.
So definitely a few things are very interesting.
I wanna pick up first thing first, right?
Because these days there are so many AI tools available, and
even, for example, model, right? We know there's a Claude Code,
there's a Codex, OpenAI, right? There's a Gemini, open model as
well, Chinese model. And I remember back then, we
talked about tech zoo, you know, having a lot of tech, in your,
uh, stack, right? I think is it the case?
Same thing that will happen, AI tech zoo?
And what will be your strategy? Because these tools are just
gonna be, you know, exploding, right?
Yeah, yeah, yeah, yeah, yeah. Totally, totally with you.
Didn't, I didn't make that connection.
It's, I will use that in the future.
Thank you for coming up with that.
Yeah, I think we have a model zoo.
There is a slew of models and tools, uh, like if I talked to
my clients, they have a license for Copilot because that comes
with their Microsoft stuff. Some developer prefer IntelliJ
so they have June, uh, Junie, then some have Claude Code.
So, yeah, that's a challenge. And also model drift is a
challenge. Like models change.
So it's something that works now, does not work with the next
model. Like stuff that works in a
certain way with Opus 3.x then suddenly stops working with
four. So there is a new dimension on,
um, on this. So managing models I think is
important and everything that part of your strategy, yeah.
What I would do is because I personally, I'm using ChatGPT,
Claude, and Gemini. And I feel they are different.
So I think, still think Claude personally, personal opinion,
uh, not a scientist, Claude is the best coding agent, I feel.
Uh, Sonnet 4.5 is really great, I think.
But I use, also use Gemini because it's part of my Pixel
phone, integrates great with Pixel.
But I think they are different. And what I would do is really
pay someone in my company to experiment with different models
on coding tasks and on other tasks, and to find out what's
the best model for us. Because I feel like a little
bit, when I talk to my clients, they think there is no
difference. You know, if I talk to my
clients, they think there is no difference.
It's no difference if we use Copilot or Claude or Climax or
something, you know. But I feel there is a huge
difference between models. And, um, a very minor thing
which has nothing to do with software development, but if I
argue with a model, I fair found ChatGPT is I found, yeah,
ChatGPT and Claude are very good at arguing and taking my
arguments and going back to sources and arguing with me.
Whereas I feel Gemini is very, very bad at arguing.
It's not arguing, it just says, no, no, you're wrong.
I'm right. Because this is this.
And I say, I bring another argument and says, no, no.
Yeah, I know why you think this, but you're wrong because, so
it's not taking any input. Gemini, I feel that's how I use
it. Non-native speaker, doing a lot
of English in Gemini. I feel Gemini is bad at arguing
and thinking, whereas Claude and ChatGPT are much better.
So I would pay someone to have a great understanding about tools,
what's there, how they differ. If I think this is a competitive
advantage, I would want to know what to use.
And quite frankly, the belief of my clients that all the tools
are the same, all the models are the same, I think that's not
true. Yeah, so I personally think it's
not true as well. Uh, I think we can tell the
difference. And especially if you layer it
on top with agentic AI, right? That becomes much more
different, right? So maybe if you use Cursor
versus either Windsurf or Junie and all that.
I think the difference could be really, really huge because some
could do more plan-based thing. They can reverify the task
before they hand it over to you. I think, yeah, definitely there
are a lot of things that could change and even the upgrade of
the model itself could introduce a new behavior.
Maybe some are more credit, like more credit consumption.
Uh, you know, they will do and some will be lesser.
So I think these are, I think, forever changing.
Uh, and don't forget to always keep researching on that.
So speaking about data privacy, security, I think this is one of
the major concerns, especially for, you know, CISO, the InfoSec
people. As the CTO coach, uh, what would
you advise people in order not to neglect this part of data
privacy and security? I have a mental, mental model,
which might be right, might be correct, might be incorrect, but
at least, I think it makes sense.
It makes sense to me. AIs have a very, are very, very
good at broad knowledge. So they know about zip codes in
China. I don't.
Probably Chinese developers don't know about zip codes in
Germany. So that's something, this kind
of broad knowledge is something that AIs are very, very good at.
It's like these on Hacker News. I'm a vivid Hacker News reader.
There's always these threads about, uh, I think
misconceptions developers have about money, about addresses,
about, like this is where the people are very bad, broad
knowledge. This is where AIs are very good.
Where you as a person are very, very good in a company is a very
deep knowledge about your problem domain of your company.
And AI companies, the most precious thing you have is this
deep knowledge that they don't have, you know.
About perhaps, TSMC might have very special knowledge about how
to produce chips with a, with the newest node.
Other companies are struggling. Something is behind that
interest, behind that. So other fabs are behind that.
That's very, very deep knowledge only they have.
But also you as a startup might have, because you're doing a lot
of research, you have some very, very deep knowledge on
something. And I would be concerned that
beside regulations, compliance, GDPR, and all of these things, I
would be concerned that this deep knowledge that only I as a
company have, is getting out. Because that's what the AI
companies want their very broad knowledge, but they want to have
also very deep knowledge. And um, yeah, that is something
I would be concerned about. Yeah, I think that's a valid
mental model, I would say, right?
So, um, but one of the challenge, for people, right?
'Cause these tools are so easy to access, right?
And sometimes we kind of like inadvertently, uh, leak out
something that is not supposed to be.
And do you think just by subscribing maybe more like an
enterprise or business plan, where they say we have zero
retention of your data, should you still be worried with such
a, I dunno, like an agreement or clause?
Or if not, should everyone now start thinking about running
model in-house? It depends on what you believe.
I think if it depends what you believe as a CTO, how paranoid
you are. Yeah, I think it's more on a
paranoid your scale than on science.
But if they say, what I would not do if they say we use your
data and your source code for training, then probably I would
not. And I have some deep knowledge.
If I'm just a, I dunno. If I have a very, if I have no
deep knowledge, I might not care too much.
Like this coaching operations thing, I'm right.
I don't care if Claude Code is training on that code because
there is no really, really deep insights that I have.
So it depends on your business and on your paranoia level.
But on this very, we use your data to train our model, that's
probably what I would not do, uh, as a company.
And then it depends again on your paranoia.
If you think, okay, you trust the company that they don't
train if they tell you this. Or you say, I don't trust them,
I run my own models. Currently, I probably would not
run my own models because in the trade off between being
competitive and running my own models, I would rather be more
competitive, you know, and use better models than the ones I
can run on my own. But perhaps I'm not sure where
this is going and how programmer... like before Sonnet
4.5, I would say like Opus 4.1, I think.
I thought like the models kind of plateaued.
I think Sonnet 4.5 is a big jump forward again for coding.
So it's not plateauing. But if it starts plateauing, I
would think more about using my own models.
But I'm interested in running own models.
It seems no one else is really interested in.
There are no benchmarks. Like if I look at, on the
internet, there are gazillion benchmarks for games like this
hardware is running this games at 105 FPS, you know.
But I'm not seeing a lot of benchmarks of this hardware is
running this model at this size with 50 token per second.
You know, that's not what I, there are here and there are
some benchmark, but I don't see a lot of them.
So I think there is not a lot of interest currently to do this.
So for now, probably I would use better model than, uh, running
stuff on my own. If I, but I have some clients or
talk to people at conferences and clients who work, uh, in the
defense industry. And, uh, well, they don't, they
don't have that option. So it also depends on your
business case, perhaps. Yeah, so I think we have to
understand our own trade-offs, right?
Our own situations and contexts. So yeah, I think what you
mentioned the benchmark probably is not a lot available, right?
Probably it's also like running the benchmark itself could be
expensive, right? Plus you have to run a lot of,
you know, like context, tokens, and all that in order to produce
a meaningful result. So we're probably looking
forward one day when we have all this available.
I wanna go to the next thing, um, which kind of like ties back
to the role of CTO itself, right?
So definitely we can see the impact of AI to the software
development team and organizations, but I wanna
understand from you what is the impact of AI to a CTO, right?
And again, I remember back then when we had this conversation,
you said that AI has the potential of making CTO feel
more creative and innovate, right?
And maybe one year ahead after that, you know, conversation.
What do you think is the impact of AI to a CTO, right?
Is it something that CTO should leverage a lot more?
And should CTO be hands-on coding again, with something
that you didn't actually agree back then?
You can write code as a CTO if you have some time.
Like if everything works, like if all the operations works and
you have great business impact as an executive and you have
time left, well, and you enjoy coding, do write some code.
So I don't have something against coding by itself.
But usually I think you need to do a lot of other stuff before
you can come back to coding again.
Yes, I think I've discussed this with several clients.
One, uh, One challenge of the CTO role is that you have not
enough opportunities to shine. So if everything is well, no one
recognizes you. If things go bad, everyone is up
your neck. So that's I, uh, see the CTO
role. And that's often the case
because sometimes CTOs confuse their role with that of the, of
a VP of engineering. You know, they see themselves as
an execution machine which is more like being the VP of
engineering. Whereas the CTO should have
business impact and have visibility in the board.
And everyone should be able to answer the question, why do we
have a CTO on the board? You know, that that's, or in the
management board. And I think AI is something, if
you go into AI, if you do prototyping, if you also as a
CTO, if you especially prototyping or show you can do a
lot of like also the stuff like I said before, um, tying AI to
your data warehouse and then asking the AI why are our best
customers our best customers or something like this?
You know, and they showed that to the CEO or to the top
management board because you're the CTO, because you have a
technical understanding of what is possible.
You could do things earlier than other people, perhaps.
And that's a way to shine. I think AI is a great
opportunity for CTOs to shine in the top management.
Something that was difficult from the time when, uh, tech and
product was split in two and the shining things were taken away
from the CTO, from that point on I think it was difficult to
shine for a CTO. But I think AI brings it back.
And you can easier shine. And I think, uh, rise and shine
is something that's important for a CTO and for your career
and for your success and for all of these things.
So that's where AI is really helpful.
Yeah, I think it's a great point, right?
Because naturally if you're a good CTO yourself, right?
So you would have a good understanding of the business,
right, the business impact and also the potential of tech,
right? And by having the ability to
kind of like, I would say a creative thinking where you
think which area that AI can help you and tie it back to the
business impact. Yeah, probably you have a good
chance to actually, uh, rise and shine within your organization
to show something that would never be possible before, I
guess. Like, because, uh, now AI simply
can open up a lot of rooms for innovations and potential things
that could be easily done. Before, probably we would worry
about how we execute that, right?
Because you probably need to develop code, you need more
people to help. So I think that's a very good
point. Are there other things that you
think a CTO would be able to leverage AI, uh, maybe day to
day from your conversation with your clients or maybe what
you've seen in the industry so far?
Otherwise, I haven't seen too much.
Um, we would need to talk again in a year, I think.
Currently, most of my, really as I laid out in the beginning,
most of my clients, which is also to be sure, um, to be
clear, my clients are from like five to a hundred developers.
So that's my kind of expertise and that's where I'm working
with. So I don't have insights into
companies with 500 developers. So the dev of 5,000.
So these have different setups. And so there might be something
true that I don't know. So just to be clear, it's,
that's where I have expertise. But in this area, they are just
struggling to adopt AI in a meaningful way with a lot of
chaotic things going on from developers and demand from
developers, faster, slower business like that's where they
currently are, most of my clients are currently with AI.
Yeah, I think that sums up a very good situation for
everyone, right? Scrambling to adopt AI, but at
the same time also trying to rationalize the benefits of
using AI. Some people talk positive about
AI, some talk about negative. I think, yeah, we are in this
like midst of chaos, I would say, like, try to rationalize
AI. So we have talked a lot about,
you know, AI. Are there any other things that
you think, uh, we should also, um, discuss before we move on to
the last questions that I have? I really, I mean, there are all
these stuff on CTO things. Uh, they, a lot of the stuff
that's, that has been there is not going away.
So AI is getting on top of a lot of these other things, and makes
some things more difficult. Like, um, most of my clients
have also struggled with the proper organization and roles
and accountability and all of these topics that my clients
struggle with. And I feel like AI is just
making it more complicated and more, sorry, there is a sun now
shining in a window on the opposite house and it's shining
directly in the face. Um, um, so, so it makes things
more difficult what the role looks should look like, what the
organization should look like. So it's, so that's, but it's
really, really about a lot about AI and strategy.
Um, so I don't have anything more interesting than what we
discussed last time, I think, beside AI.
So yeah, definitely what you mentioned is valid, right?
So for people who wants to become a good CTO, I would still
highly suggest, uh, reading your book, right, the Amazing CTO's
Missing Manual, right? Because a lot of stuff I think
would still be relevant, if not more relevant because like AI,
yeah, we could amplify certain things where you can get more
things done probably. But there are other aspects that
AI currently is not able to leverage.
So things like what you mentioned, accountability,
providing good strategy, and not to be swamped into the
day-to-day tasks, right? So always thinking strategically
and helping people to grow. So I think that's still kind of
like part of the big responsibility of the CTO.
So Stephan, uh, it's been a great conversation.
Um, before we wrap up, I would like to ask you the same
question I asked last time, which I call the three technical
leadership wisdom. So maybe, uh, after this
conversation, do you have some version of, uh, wisdom that you
would like to convey this time? Yeah, I have three.
Two are about AI and one is not about AI.
The first one is, be a leader. Just today or yesterday, I read
something on LinkedIn, which is people make, sometimes make it
very complicated, the concept of leadership, sometimes people
make it very complicated. I think leadership is simple and
hard at the same time, but it's simple in a way that you want
to, you think people should move somewhere, organizations should
move somewhere, and then you get people to get there, you know,
to move there. That's I think, is a leader.
You decide we should go there, let's go there.
That's leadership. Um, and, uh, and something that
a lot of CTOs fall into trap, uh, CTOs fall into is this, uh,
servant leader. They identify as servant leader,
which is kind of fine if they would not concentrate on being a
servant instead of being a leader.
So that's a trap. Uh, I think servant leader is a
trap. Uh, so be a leader.
That's important. Uh, the second thing is AI is
not software. We're going to move towards...
I strongly believe we're going to move to a setup that favors
AI without source code. And, uh, you should, as a
leader, a tech leader, you should think today what that
means for you and what you can already, what microservices you
might already be able to replace from code to AI.
The third one is not a leadership thing per se, but
something I think you should push in every developer, because
it's, I think the biggest prompting mistake people make is
you should iterate on the plan and not iterate on the prompt.
I use Claude Code. Probably it's the same in other
tools. Uh, you can have plan mode and
then you go into plan mode and click plan mode.
And then you plan and plan and plan and plan, until you tell
the Claude also check, recheck the documentation, recheck the
code if your plan works. And then after some iterations
on the plan, you tell Claude Code to go.
Whereas what I see is people iterating on the prompt.
They say, do this, and then the outcome is not what they expect.
They say, no, don't, don't do this, do that.
And then it's still not working. And then they say, do this.
So they iterate on the execution, and then that's not
working. You know, they just get deeper
and deeper and deep in the woods, to a point where the
agent can't find out anymore and they're lost in the, lost in the
woods. So iterate on the plan, but
don't iterate on the prompt. That's the third one.
Nice tips, right? So for people who still fiddle
with the prompt, uh, including myself, right?
Sometimes I just try to make the prompt better.
Uh, but yeah, I think, uh, making the plan better sounds
better because you iterate on the small thing, right?
You break down the things that you wanna do in chunks, right?
And making sure that you know the plan for those, uh,
iteration looks good. And, you know, you let AI tries
to solve that one by one. So definitely pro tips for using
AI. So Stephan, if people want to
continue, uh, this conversation, they would like to ask you more
things or they expect an updated version of your book, where they
can find you online? They should search for me on
LinkedIn. They can find me on LinkedIn.
Then they can connect and ask me whatever they want or tell me
their opinion or whatever share. Uh, I'm very open.
So the primary method would be going to LinkedIn.
The other thing is I have a website, which is called
amazingcto.com. People can also go there.
Right. Thank you again for your time,
Stephan. I'm very excited, you know,
having this possibility to learn about possibilities of using AI,
and especially for those CTOs out there who still are
struggling how to adopt AI successfully, on how to think
about using AI much more effectively.
So I hope this conversation inspires you.
So thanks again, Stephan. Thanks.
Thanks, Henry, for having me. And I hope I can be back in a
year. Looking forward for that.