Oh, I can code 55 times faster. How many hours a day do you code
as a developer? The value was not in the coding.
The value was in finding that solution, in defining that
solution. Junior engineers are more likely
to adopt AI. They are more native to the
technology. They're not too opinionated on
that yet. They're the change agents.
If you cannot experiment on a day-to-day, which means at your
job, it might be actually a good reason.
Just expand your mind, make sure that you you are aware of a
little bit of everything. This is a craft that is changing
super fast. Coding is cheap.
Software is expensive today. I'm joined by Susanna Daniels,
Chief Developer Advisor over at Microsoft, and with close to 30
years of experience, she has more than yours and mine
combined. Potentially.
We talk about the future of software engineering with tools
and a gentic, the things we have nowadays, but more specifically
how you as software engineer can navigate this and much more.
So enjoy, I think a big narrative nowadays and a trend
that really focuses on specifically productivity. 10X
engineer is something that was already a phrase in the past and
now people are saying, oh, it might be a reality.
What is your view on this emphasis on productivity
specifically? So yeah, that's a bit of, that's
an interesting question. Early days when we, when we had
AI, we were talking about mainly code completion and asking an
agent to do some work for you, right?
Task agent, human. Back then the focus was on
productivity because that was what you could achieve, right?
But that marketing was so good that we were talking about, oh,
I can code 55 times faster. How many hours a day do you code
as a developer? How how much is that?
Like 14%? You can say one hour, you can
say 2 hours. So while that is an enormous
benefit, don't get me wrong, the question is, is all there is
productivity? We learn now that with these
agents and these models becoming more powerful and us
understanding better how to operate them that we can also
talk about improving the quality.
We can also improving, talking about improving the outcomes
that we, that we would like to see.
We can talk about instead of productivity, we can talk about
the pace of innovation. So there's a lot more to it.
I think that the productivity narrative has worked really
well, but we, we are way beyond that.
I think productivity is maybe the first level of AI adoption,
right? I'm freeing up some time.
You're going to use the time to learn more, to understand more
about these agents and how they can help you.
And that way you're going to add more and more value.
But yeah, it's a it's a very, very stubborn, reminiscent of of
previous marketing, I think heartache maybe.
But yeah, this isn't it's not all story.
Yeah, No, I like your emphasis on creating value.
That's why I always had my joy. It wasn't necessarily on the the
act of creating software, although I did have a lot of
fulfilment in there. But that part is now I think the
most evolving. The outcomes I'm working
towards, I think those are still what makes me take at least as
engineers specifically. But there are different flavours
of engineers. Some people really like the the
hands on part and they really like and they hold a lot of
passion in the craft of creating code where they say this is
elegant code and we've refactored it and it's not
really nice. That fulfilment part, I think
that's impacted the most so far. Yeah, it's look, if you, if you
look at software development, at least in my opinion, what we
used to do is we would have a problem, a challenge and we
would, would start figuring out what is the algorithm to get to
a solution, AKA the coding the you know, but if you look at
overtime, software development changed a lot, right?
So for instance, gathering the right requirements, that's so
much work. It became a full time job for a
person, right? If you look at other parts of
software development that you know, that became jobs, that
became roles, that became things that other people would do.
So if you look at the essence of software development, a lot of
it was stripped away basically. Why?
Because we're humans. So if we have big things, if we
have big teams, we, we need to figure out the process, we need
handoffs to ensure that we, that, that we, that we keep that
flow going, that we satisfy the requirements of the next person
or the next rule that picks up a task.
Is that really software engineering And not to me when I
started software engineering, what I loved about, about it is
really knowing the problem, knowing who the customers are,
matching that with some ambitions coming down from
business and figuring out how I could make that all work.
And yes, I spent a lot of time coding to do that, but the
failure was not in the coding. The failure was in, in, in
finding that solution, in defining that solution in, in
getting that feedback and, and translating that in some
technical, technical solution for that.
And with, with now with AI, we, we see that we are more involved
in the beginning. This will be increasingly more I
think that the boundary between products and software
engineering will will be non existent at some point.
Maybe somebody has a role or or you know is is better at doing 1
task than another and and you know keeps the control and, and
has some some responsibilities there.
But it should be seamless. And with that, a developer is
involved, a developer is involved in the outcomes because
that is what we're actually doing.
That algorithm, algorithm that will be solved by AIAI will will
take care of that work for us. And when it doesn't work, we can
still dive into the code and do the nitty gritty.
Some things are maybe way too bleeding edge for an agent to
understand. Could be, but that is then the
more fun work, right? If you ask most developers, we
did internal internal survey and one of the things that came out
out of it is that that's actually the work that
developers enjoy doing and figuring out the the solution,
figuring out the outcomes. So yeah, it is shifting.
It is changing. I think that for the for the
coders that like to code, that's great.
We still have people also writing the Linux kernel, right?
We still have people that worry about, you know, that's writing
assembly. We have people that write COBOL,
that's all fine, that will change.
But yeah, there's something to do for everyone.
I think we're in really exciting times, as you mentioned, where
teams are kind of navigating this newer way of working.
For me, it's probably one of the first times where I've seen this
much impact on what I did as a craft.
I don't have as much years of experience as some other people,
even the people that are listening here, But for me, this
is really cool to experience this part.
There's also fear because as individuals are kind of
amplifying and creating value to a level that is different, that
is evolving. I've also seen organizations
that say, whoa, for the people that are really senior, they
know kind of the boundaries and they know they have quite some
knowledge under their belt to accelerate with this.
I saw a chart where it said that senior positions went up and
then the junior positions actually went down.
And I've also seen a narrative just now I was reading on Reddit
where someone said, well, I have my degree and I have really good
grades, four point OGPAI study from this school, but I've done
X amounts of thousands of applications and I still don't
have a job. That is a little bit concerning
when it comes to new and early in career people actually coming
to the market. I'm curious because you engaged
with a lot of engineering leadership, what your
perspective is on that? Yeah, that's interesting, right.
The research contradicts what we're seeing that what we're
seeing happening slowly. So for and this is maybe also
the positioning about AI. So no judgement there.
I think that a lot of a lot of misunderstanding is that AI can
do the job of a junior developer.
So we don't need the junior developer anymore.
There's there's a few things to that.
I think the most important one is that when you, when you look
at the skill and doing software development at skill, it doesn't
make sense. So you can't only hire senior
engineers, There's not enough of them even like with with the
projections that we see with the number of engineers that that
will be there in the following years, it will not match what is
actually needed. So that's a bit
counterintuitive. I think one other thought is
that when you look at actual AI adoption, research tells us that
junior engineers are more likely to adopt AI.
They are more native to the technology.
They are more able to go beyond the like, what some few as
classic developer work. They're not too opinionated on
that yet. They're, you know, willing to
use AI to do something beyond what is in their original job
description. They're the change agents.
So they're that's also a way to look to look at it.
And I think that makes perfect sense.
And my expectation is that what we'll see happening is that at
some point this trend will be broken and we will actually see
that the junior engineers becoming high demands because
these junior engineers are able to navigate this more perfectly.
They can handle very much the ambiguity that will certainly
certainly exist in software engineering role.
And the senior engineers can be there to as SM ES to codify
their tribal knowledge, to codify best practices so that
agents and humans can leverage that.
And also to train these junior engineers because we, we, we
need steady supply of, of people that will be able to, to become
like, you know, senior software engineers at some point in their
career. Then, then there's also the
profile. So instead of like only looking
at the T shaped engineers, we will also see M shaped engineers
that are, you know, better qualified at two different,
different areas. So yeah, it's an interesting,
interesting thing that is happening.
But if you look at everything combined to skill, culture, the
ambiguity and the role that that will be probably what we'll see
happening over the following year years, yeah.
For a lot of my career, I was the person that was early in
career. I haven't been in a position
where I actually engaged with A-Team that is quite younger
than me. I'm now 30.
And I recently had an experience where there was a whole team of
people younger than me. I was like, they actually have a
really good energy and they're experimenting on their own and
they're really wanting with a lot of drive to push this
project forward. And I was like, yeah, like I
used to be like that. I can still see people like
that. I think when you have experience
under your belt, you become a little bit more sceptical,
realistic. Maybe you burned your fingers a
few times like it's normal, but I do like that energy.
I miss that energy. And I feel like if an
organization wouldn't have that, it also doesn't inspire the
people that are there anymore to a level that they should be
inspired, I feel like as well. It's that exactly.
And remember, coding is not only about the tools, it's not only
about the people, it's also about the culture.
And that is also something that's, that's those juniors
bring in these can be your change agents to, to, to get to
that culture. Technology helps us there as
well, right? So if we, if we would see that,
let's imagine you have an A Gentile team.
In my mind, that's three people, lot of customers experimenting
with exactly that number. And that could be like 1:00 PM
and 2:00 juniors. And you know, anecdotally,
people say, oh, that's a nightmare scenario because you
will never know what they will create.
And those agents will will run riot.
And in all their enthusiasm and with their lack of knowledge,
yeah, they might create like something we would think is
suboptimal, subpar or, or whatever negative connotation.
And that doesn't need to be true.
Because if you look at like that model, and again, this is this
is a bigger change, right? This is culture.
Imagine that these SM ES codify their best practices.
We implement platform engineering in the right way.
We have that culture where where collaboration, where creativity,
embracing uncertainty, those principles where, where that
where that is where that is in in in the DNA.
Why would it get off script? Because if they're able to
define the right outcomes and have to write guard feels and
constraints in place, then neither did the human nor the
agent can can, you know, can go off script too much.
You're setting them up for success.
And I think that is a bit of the like the mind shift.
How can it make others successful?
We have a thing in Microsoft and it's it's high culture, high
performance culture. High performance doesn't mean
that one person is super cute and like, you know, wears a cake
all day. That's also the person that
enables others to be successful, that enables others to build the
next great thing. And I think that that is
something that's it just makes sense to to look at it in that
way instead of like, oh, I'm going to replace juniors with
AII think you shouldn't replace necessarily anyone without AI
unless that there's like literally no activities anymore
for a person. But yeah, the strong conventions
and the guard rails and a platform where people can
accelerate, I think those are a lot of the ingredients that
platform engineering brings to the table or also a lot of the
problems that it solves when that is not there, when there's
friction or whether there's different flavours of technology
and kind of wild spread, which really goes hand in hand.
And I feel like platform engineering now should also have
an emphasis on making this work in energetic way of working,
which is really cool, to be honest.
That might be then in this vision where seniors really make
a difference, where they say, OK, these are from what we know,
best practices, strong conventions, differentiating
factors for effectiveness. When we talk about small
incremental teams that deliver value, which can be very cool.
Are there organizations experimenting with this way of
working as you mentioned already, also with regards to
the seniority within teams? Yes, yeah, yes.
So then for people that are early in career and that are
listening, they just have to find those organizations.
Yeah. Look, hang in there.
I think it's, and this is basically advice that's that's
I'm giving to anybody that is, that is new in career.
Just expand your mind. Make sure that you, you are
aware of a little bit of everything.
This is a craft that is changing super fast.
It doesn't hurt to know about proper UX, you know, and, and
being able to understand that doesn't, you know, with, with
all of these topics, security, the product management, it, it
helps if you know a bit of that because that is the value that
you will bring extra with it and just don't give up.
I I think and I see that this will change at some point
because economics of skill tell us that this is not a
sustainable model, right? Yeah, a lot of my emphasis I
think also in the impact that I had early in career was the fact
that I'm a good communicator, collaborator and a kind of
bridge gaps. My fear is that, and this was
also just me coming into a project and being the sole
person that needed to build an integration, just get it done.
I was like I I could do it. It was a lot of fun.
I did not interact with as many people within my team because it
was kind of a one man army task. And I feel like that will or
there is the option to do that more and more.
So then there would be less inner operatings with a bigger
team. You already mentioned that 3
might be the the solid number and I see there's a good thing
and a bad thing. I still think that the soft
skills aspect of things collaborating, we will still be
a lot of interaction with people in and of it's own.
But some of the complexity also goes into and genetic work which
is amplified on a different level.
Yeah, if you were to advise people what to focus on, it
could be people that are early in career, it could be existing
software engineers. They're experimenting with
genetic work flows. What should they now looking at
first principles from software engineering focus on with
regards to knowledge from your perspective?
That is a great question in terms of knowledge, of course,
beyond coding itself and understanding these agents.
It's a good name now. Yeah.
What it what it is that I I literally see happening is that
a lot of a lot of principles, a lot of frameworks, best
practices that are older than I am, maybe even they they, they
get a Polish up. There is a lot of principles
that that have been around forever.
There's a lot of best practices and we see that with
specifically the the specification parts,
specifically the beginning of of that software, software
development life cycle. I, I it is those principles I
would. Advice to take another look at
right a, you know, if, if you really understand everything
there is about behavioural driven development, that's a
great one, right. That's valuable understanding a
bit more about systems, understanding more about, I
don't know, the SOLID principles and there's so many, like
there's an enormous list of things that you can just now
acquire in, in terms of knowledge.
It's not difficult to do. But but if, if you understand
these principles, then that will help you massively in, in
defining these specifications and defining these constraints
in making an making an actual software products instead of
codes. My manager has a nice one and I
just have to put it out there. She always says, says coding is
cheap, software is expensive. And that's just the difference
between between just like putting out some codes or being
really intentional about what you're doing, knowing your, your
heritage, knowing, knowing whatever that these researchers
have researched for years, all those best practices, leverage
them. Learn that be, be, be good at
that. Be be the one that says, but
what if we would like, instead of using this method, use
another methodology? You know, I think that's that's,
that's that would be beautiful. Yeah, I'm happy that a lot of
strong principles and like foundational knowledge, knowing
that will still help in the end. We're not really vibe coding on
enterprise skill. We're still creating software
that for the most part is going to be there hopefully for years
on end. Creating is a lot easier.
I feel like creating in the right way we're getting better
and better at, but we will go into a mode where creation is
just there in abundance. So then we have to make sure
that we create the right thing, created the wrong the right way,
and then also has the longevity component to it.
One of the reasons why I really like Go as a programming
language was that the creation process in the end, what you see
in code was quite simple. It's still on version 1 dot
something something. It's probably in the 20s now,
but it's still a one major version, which means I never had
to migrate my code. If there was a new update, it
was kind of seamless. That process was always pretty
simple. There are not many things that I
could do in different ways in Go as I could compare to other
languages, which is why I really enjoyed it now.
It has a strong readability component, which is fantastic
when we're talking about software that is generated
because if you have a language that's easy to read, you will be
reading a lot more I feel like nowadays, which is also funny
when we're talking about programming languages
specifically. I wonder if agentic software
engineering is also going to influence in the end the
language that you choose right now.
I think it will because we are doing a lot of the reviewing
work as humans still with an agent still probably like pre
reviewed, but in the end still as a final pass.
There's humans in the loop. I don't know how that's going to
evolve, which I think is still quite exciting to see how it
plays out. Is this a long intro to asking
the question? Will everything be JavaScript?
I hope not. But yeah, what?
How do you see that? Luke, I think that yes, of
course there there there will be some influence here and there
because the agent, if you don't stare at the agent, picks what
the agent will pick. Yeah, right.
On the other hand, who is defining what the agents should
build? It is us humans normally.
Yeah, still so, so I'm, I'm not too, too grim about that.
But one one thing that's this is maybe a bit too hypothetical,
but you could wonder like not if in 10 years or so the the
default programming language will be JavaScript, which we can
argue about, we can argue about this for an hour maybe.
But it is like, what is the future of software even?
And what is the future of software languages at all Like?
Is it too far fetched to think that in, I don't know, a few
years we will create applications using natural
language and that will be compiled.
Who who cares? Like what, how it is compiled,
what language it's using? And so that that's one thing.
And the other thing is what even is an application?
I work with customers that are rethinking their their apps and
they're saying, well, but my customer, yes, sure, they go to
a website right now, but if they are in an in an, in an agent,
they're using, I don't know, something like chit GPT or
clouds or whatever. And they they ask a question
like, Hey, how can I get how, how do I choose?
I don't know life insurance. So why wouldn't it just suggest
me the good life insurance and I just close it right from there?
Or even would it be too far fetched to think that when I
would a life would want a new life insurance that there would
be agents being kicked off to negotiate on my behalf And just
look which one comes back with the right offering or when I
want to do my groceries. So this is super exciting.
But yeah, there there's, there's of course a lot of beliefs about
the way that that we are looking at software development right
now. I think that will change
massively. But but yeah, I on on the
programming language. Yeah, it is of course there was
a preference to the colour purple according to some LLM
right. Oh really, if the people would
build a web app, then it would use the colour purple because
The Color Purple and then some reason, some research, I don't
know. And thus like everything becomes
purple. So if then in the next training
would take the place, then everything would be purple.
Or you know, there's there's a lot of things to to say about
that. I was reading an interview with
it was Reddit and like someone these stated, yeah everything we
say on Reddit becomes becomes the future training data.
Yeah. And I don't know if that's a
good thought or or a horrible thought, depends on, you know,
which subreddit you're on. But yeah, there, there.
There's a lot of implications with that.
Every every so now often I'm on Reddit or I'm on YouTube and I
scroll through the comments and someone makes a comment that
says all of these other comments.
They sound like bots and I'm like I have no clue who I'm
actually talking to nowadays if that is the truth or not.
Is it like with the M dash? So I.
When I see that, I'm like, that's the smell.
But so, yeah. But we think then that that's
that's a thing that an agent does.
But on the other hand, like, I always learned that I used too
many commas. Oh, yeah, yeah.
So what did I do? You removed the commas, yeah.
I moved to M Dash because I that's the way that you know,
that's that's my way of communication.
And then I had a whole period where I was like, yeah, I'm just
going to going to replace all the M dashes with a minus sign
or something maybe. But it's just, yeah, there's no
at some point, no way of telling, I think.
No, I mean, I'm fully there with you actually.
That's so funny. I saw on LinkedIn everyone
people were like, I was doing M dashes before it was cool and
now all my articles are getting rushed.
Like, this is also not a good movement, but yeah, yeah, that's
funny. As that's humans and you know,
the, the, the point of this is as humans, we, we value that
somebody communicates as a, as a, as a natural person, as a
human. Yeah, authentically.
Authentic, human, real. On the other hand, we all love
it when AI does that for us. With with coding, you know, it's
the same story. We still own the code, we are
still responsible. The human is still responsible
for what we're writing. If AI have written 80 or some
customers, even now, 90% of the code, 90%, their engineers are
still responsible. They are still the humans that
are in the loop. We're trying to remove it where
it doesn't make sense if we have enough confidence, but but
still, it's a human that's that's responsible for for what
gets out there. And if I use AI to translate my
ideas and people can actually read it, I think that's way
better than when I spend too much time on writing it myself.
And people read it and think, wow, she's unhinged.
But this doesn't make sense. I don't know.
I stopped halfway, right. So that's, that's always a bit
of the, there's always a train off there.
Yeah, yeah. I had a conversation with Gregor
Hope on the podcast as well and his stance was really OK.
The if the baseline has moved because the baseline is now you
have output with regards to AI, you still have to add value on
top because otherwise anyone can do the same.
Maybe the reasoning or the prompting is slightly different,
the flavour is a little bit different, but if you don't add
your value on top then basically anyone can do it.
Your value is really the value you add, so keep doing that and
otherwise it's useless what you're doing.
And that's an excellent remark, right?
And This is why it doesn't make sense if all people use AI to,
you know, I think the most visible thing is LinkedIn.
If it's like the 19th article that is written by AI and it's
all looks the same and it's like nothing is being added, yes.
What is the purpose? The same you can say for
software, right? And on one end, we, we with AI,
with this technology and with the right culture, we enable
everybody to, to get the most out of it.
Because the the remark of a customer, the idea of, of
somebody in the business, the the, the experience by the PM
and by the engineers that are involved that can, that can
create something great. On the other hand, we also see a
lot of software companies now struggling because they created
the product, but basically it didn't add much.
Think of the example where you have, I'm not going to name a
shame, but you have an open source product.
Monetization with open source has always been challenging.
So one of the scenarios is of course you release the premium
feature and you maintain that and the customer buys that and
with that secure that there flows money into the open source
project. I would wish that everybody
would think that way, but also somebody could just say, well, I
just used the product sheet and the recorded demo and I told AI
built this for me and I got it 90% right.
And I think that's good enough. And of course, I think that
everybody should pay for open source, but but yes, support,
support, support the makers, support the the contributors and
the companies that make the project a life, that invest time
and and resources in it and money.
But yes, you need to add something really special.
Yeah. Otherwise it's not good enough
anymore. I feel like open source is the
value of open source and kind of the monetization model.
It was always challenging. So open source projects really
nailed it and they are thriving. And the other ones that added it
like an add on that one is the, I think impacted the most in
terms of now people being able to kind of copy and and match
things. Which means if that incentive is
gone, I hope we don't get into a cycle where we have less and
less things that are open out for people to use.
Because I do love a lot of my open source software.
And I do think it is, quite frankly, one of the most awesome
things we have about this industry is the fact that people
create, they share with almost nothing in return.
Even the open source projects that have monetised, it's
typically just a fragment of it. It's not the main thing.
And the people that are maintaining it have a second
like a full time day job. This is a side thing for them.
So yeah, I I hope we don't get into a a position where we have
less and less open source, but this is a risk for sure.
Yeah, I, I, I hope the opposite. I hope that if we will see more
open source and, but yeah, it's, it's something to, to that we
need to actively work on. Yeah, the world depends on open
source. It's like that for the
foreseeable future. How many AI she'll build on top
of something and how many platforms she'll build.
Like there's still always that XKCD with that one package
maintainer in Nebraska. But that's, that's the reality,
right? And I, I see a lot of creativity
happening and I think my expectation is that open source
will still be there. It will be, will still be
booming. I don't know about the larger
projects though, because now it's easier to say, oh, well, I
wanted to in another way or, oh, I'm really specific about
something. I don't have the answer to that.
But I think that's a, that's a thing we should solve as an
industry as well. And tell people what open source
is and and why it matters to contribute to like these
projects and and work together. But.
I have one final thought and it goes into the line of I think
tooling that we now have available as software engineers
specifically. I know a lot of people in
start-ups or smaller organizations where tooling is
kind of experimented with. They might fall in love with
Cursor, for example, just to throw one out there.
And if they then move to a bigger organization, they will
no longer have access to the tool that they love.
So now they use whatever is in our organization, whether that
be something open, AI related, clawed, or get a copilot doesn't
really matter. In the end.
They have to be more flexible when they switch jobs to also
switch tools, which is pretty funny because I love my tooling.
I love mastering tools because then I feel like I can leverage
that to achieve my outcomes faster.
It was also in the IDEI love my hotkeys, my bindings to make
sure that when I actually execute code, I do that
efficiently because like to be effective in what I do.
So letting go of a tool and then mastering another one, it's not
really something I look forward to.
There are a lot of, I feel like, underlying principles when we're
talking about agentic development, the way you prompt,
the way you context manage, how you kind of parallelize agents
or how you navigate certain structures.
We're still learning and we're still evolving also with how we
structure context nowadays. There was this discussion on
skills and agents, but I'm curious from your perspective,
when you advise engineering leadership on the tooling they
make available for their department, for their teams, for
their organization, what do you make sure that is there?
Because I'm quite curious from the people that are listening,
they might not have the tooling they want, but it might be
effective for what they need to do.
So I'm curious to hear how you think.
Yeah, that's, that's a great one.
I'm a lot of the, a lot of the tools, to be very blunt here,
they're not so much different. Can you achieve 80% the same
thing with all of these tools? Probably, most likely.
I didn't do the research on it, so don't pin me down.
But look in, in general, these tools are, are different, but
but not that different. One thing that that's, and this
is regardless of the technology, we cannot just ship a tool and
give it to a developer, especially not when it's highly
sophisticated like an AI coding assistant or an an agent for
doing anything basically. So what I advise these leaders
is to at least enable the developers.
And with enablement, I do not mean like, oh, this is how you
get the license and this is where you find it.
Although that's a really good start, don't get me wrong.
And already better than like maybe like half of the
companies, you know, it's like usually it's just like, here's a
license. Good luck.
You need to train on that. You need to understand like
where do I put constraints? What are these constraints?
Like this is a lot of concepts to grasp agents.
Oh, I can write my own agent. You have to know how.
You have to know where. You need to understand the
specifics of these tools and how they process this information.
Luckily, we have more and more standards, right?
This is why we as an industry trying to figure out like, OK,
where do we put these instructions?
Let's adopt these skills. Let's look at certain protocols
that help us. MCP is a great example of a
highly fast moving, fast based industry that competes with each
other to their life. OK, we need to settle on this.
We need to find a, find a standard for that.
Whatever you think of MCP, it's a standard, right?
Yeah, but people need to learn what is MCP, how does that work?
How do we build that securely? How do we skill that?
What can't we do with MCP? Looking at the different rules?
If you are a software developer, that's really great.
There's tons of information out there.
Even then, we need to teach you to understand how you can
leverage the tool. But we also have data
scientists, we have test engineers, we have PMS, we have,
there's so many people that are involved in that whole coding
thing and they all need to be enabled and understand like how
they can get the best out of the tools that they use.
Also about the models, what happens when I pick one LLM over
another LLM? Sharing best practices
internally, making sure that you set up an inner source culture.
There's a whole, you did not need to do that all at one time,
but there, there's like this whole trajectory where you can
just mature and, and for each phase, you can add a little bit
to it to ensure that you're successful with the tools.
And then when you need to switch the tool and you're like, oh,
this is like, it feels uncomfortable because it's
different or it's in another IDE even, or it doesn't even have
it's own IDE or whatever. It's ACLI suddenly.
Look, it's the. Basically these LL Ms. and then
this is of course talking, you know, working at Microsoft, we
we can just switch the LL Ms. to whatever LLM that you use of
course. And the most popular ones are in
there and will be probably more. If the one is not in there, your
organization could edit even, right, to make sure that you can
access that. And this will be further
commoditised. We already see that, like what
we now do with GitHub. We're our platform, we're
welcoming. So if you want to use Clot as an
agent, sure. You use Clot as an agent.
If your org enables that, that's really great.
Then you only have another bit of a different interface, sure,
but your agent is still there, uses the LLM that you're used
to. It's the agent that you're used
to. And, and I think that that's,
yeah, that commoditisation will will go on and I think that
everybody will benefit of that. But yeah, you can't just give it
all to a developer. That's that's no, that's, that's
not a driving adoption. Yeah, I like, I like that you
say that an arbitrary percentage, but most tools right
now, they kind of do the same thing.
And The funny thing is, I thought of this and yeah, if
they don't do the same thing, then within a few weeks, within
a few months, they will still do the same thing because people
look at each other. If my tool has something that is
very special and other tools are out there, they are definitely
going to also adopt something very similar to achieve the same
outcome. It just makes sense.
It's good that we have competition because as consumers
we get the best products in the end that really I enjoy.
Yeah, and, and me too and I love what's happening.
I, I love looking at what's what's happening with, with
competition and of course I'm ready to, you know, and I follow
these discussions and people showing off and on YouTube and
on TikTok. It's just by looking at how they
are using a product and how they're talking about these
products and helps me understand what is what is important.
And there's some nice innovations that are being put
out there. Not everything I would say,
well, that's that's a nice implementation or that doesn't
really sound enterprise to me. But yeah, in the end,
competition is what makes software good and great and
makes it inspirational to be in this field at this at this time.
For the people that are listening and they are not
enabled to a degree where you say this is kind of the tooling,
that you should at least have at least one of the tools, do you
feel like that warrants them changing the organization that
they are in? Because I think I do almost if
it was easy to just switch organisations.
Disregarding that, I feel like now things are evolving and
accelerating so much in our craft that if you cannot
experiment on a day-to-day, which means at your job, it
might be actually a good reason. Yeah, totally.
If you if you look at at organizations and looking at
their, their strategies on on retraining and retaining talent,
there's a lot to do. Having a good culture, having a
mature tools, which goes from your day-to-day software
development to how easily can I obtain a platform?
How can I skill? How can I make these changes
during all your platform engineering implementation?
Yeah, there will be, there will be choice, There will be
choices. And you know, the more reason
for organisations to think this true really, I'm certain that we
will see more and more platform engineering conversations
popping up. I don't know if we did a great
job at defining platform engineering.
I think we crammed way too much in there with a focus on
engineering. So maybe it's time for another
iteration on on on that approach.
But there's so much in there and we need that.
We need, we need that for the agents that help your customer.
We need that for the agents that help us write codes.
We need that for the agents that deploy our stuff into production
and manage that and observe that for us.
We, we need all of that. People that are listening or
watching might think, hey, yeah, but shouldn't it always have
been that way? Yes.
But when you slap a high onto some project like that, chances
that you get the budget for it and you get the resources for it
are a bit higher as well. Yeah.
So do yourself a favour, implement platform engineering,
make sure that you have the best culture look, be creative with
with your collaboration model, your operating model experiments
a bit with that. Make sure that you celebrate
your success, that people are enabled and encouraged to use AI
and to fill. And I think if you do that
right, you'll be solid and you're you're doing probably
better than some other company and you will attract the talent.
Yeah, beautiful. Thank you so much for coming on,
Susanna. This was a blast.
Yeah, thank you. It was so fun.
Cool. If you're still here with us
listening, let me know in the comments section what you
thought of this episode and we'll see you in the next one.