We are in a unique point in time where people have an opinion on
people's personal productivity. When it comes to software
engineers, they have quite a valuable skill set and there's
no alternative. Now there is an alternative.
It works now because you have senior developers, they lift the
pain of developing. They know object, object
orientated programming, they know functional programming.
Now if you Fast forward to 20 years and we freeze in
technology and you do exactly the same, the person driving
that large language model doesn't understand the lower
level concepts of object orientated programming because
he never had to do that in the past.
Are you a programmer who writes code or are you a software
engineer that you design software architectures and that
you write applications? You are the author of the
application. You're only using a tool to
build it for you. Joining me today is my friend
and colleague Joris Konang, AWSCTO over here at CBR and we
talk about automation, agentic workflows and the impact on the
software development life cycle. Really fun conversation and
it'll definitely make you think. So enjoy.
I looked at your LinkedIn and you've done a lot.
I saw sys admin, I saw software engineer, cloud engineer,
trainer, and now CTO. I'm wondering what nowadays
still gives you energy that might be different from how it
used to be. Still the same things.
Yeah, yeah, yeah. So next to be the CTO, I'm still
doing consultancy work. So I'm still engaged with, with
an engagement at a client. And then when you have that
particular heart problem that you're actually trying to solve,
and the moment when you actually solve it, that that moment, that
spark is like, yes. And it doesn't matter what that
problem is. Well, the bigger the problem,
the bigger it impacted, the nicer the yes is.
But. Yeah.
And then does it matter if they are long term problems that you
solve bit by bit or they're more the shorter kind of instant
satisfactory ones? Well, it could be both.
Yeah, yeah. That's nice.
But it needs to be stay fun, right?
You need to enjoy your work. You need to go back to your work
and say, yes, I'm excited to go and I feel like it and I want to
make a difference. If you do that, then you're in
the right job. How do you keep it fun?
Well, you have to make it fun. So also within CBO, we also
shape our own assignments sometimes and that's gives you
the opportunity to make it fun for yourself.
So of course you can go to a client and ask them their
problems and then let them drive the assignment that you they
want you to be doing. But if you as a consultant say
hey, but I think I will excel in this area, can I help you with
that, then you're shaping it more towards you to make sure
it's fun for you as a person. Do you have an example of that?
Something that you came in to solve and then turned out there
was a different problem that needed solving.
You actually fixed that. Well, if you, if you talk a
little bit earlier about when landing zones were hot and
happening, I would say there the governance.
Well, I, I don't really like governance, but I do like
security. And I do know that it's, it's
goes hand in hand. So it, it's, it is important to
have that together with each other.
But I really like figuring security challenges.
Don't be the department of no, but make sure that you say no,
you cannot do this this way. But let me help you figure out a
way how I, how you can do this. And in in that sense, I was more
or less like, OK, put me in that position where I can not block
people, but actually help them unlock themselves and then see
what the impact on the organization is.
That's nice. Yeah, I got a new kind of
viewpoint on things like risk, privacy, security specifically,
and it was mainly because I was talking to a person that's quite
senior at Databricks. They also worked at Google and
they said it's like you're engineering but at a different
level, on a higher level because the margin for error is a lot
smaller, right? If you're at risk security wise,
then when something big actually hits, then could be detrimental.
So you have to make sure you got all your bases covered.
Same with risk, right? If you get sued, you're kind of
screwed. So if you're responsible as an
engineer, you're playing on a different level.
It's like you're playing Champions League instead of like
smaller league. Definitely, yeah.
And with security, it's also fun, but I've never been
responsible for I think those bigger topics.
I do feel like when things are quite risky, those topics go to
the people that the organization trusts the most to actually make
sure that this works well. Yeah.
And more and more people are involved making that decision
and they're, it becomes slow and bureaucratic and nobody wants to
bear the the risk of going wrong.
And then they postpone. And then you get the typical
enterprise behaviour that you would see in organisations.
Yeah. Yeah.
Have you found yourself in a position like that and how do
you handle that? Well, usually finding the person
who is responsible in the end and just confront him with what
the well, what the the downside is of not tackling this is for
instance, you can deny people from using AI because you're
afraid for the risk what it brings.
So you don't allow AI within your company.
But what people will then do is they will use ChatGPT on their
personal accounts for a free version and they will use it
where it was intended for. And you can upload excel sheets
there as well. And then you're then you have a
bigger risk of losing data into places that you don't want your
data to be be app. Yeah, I've seen two types of
people. Then the people that really try
and prevent that from happening, people going shadow IT personal
stuff or people that then say indeed, let's fix this because
this is an ask, so let's make sure it's in a mature way and we
can actually accommodate. People will find a way, Yeah,
right. So and either it's through the
way that you pay for them or you they will find a way that works
for them. It's interesting because I, I
only know this industry, which is the tech industry, but I do
feel like the engineers are quite influential, right?
Within a product team, A-Team can just say we're not going to
work on this feature. I believe we should not work on
this feature. We need to work on tech depth
for at least two weeks. And then a product person can be
like, oh, what am I like, what can I do?
My engineers are not going to work.
They're like, and on a strike, it's like a mini strike.
Sometimes they can even hold an organization completely, like in
a in a stranglehold when they say I want to work with this
certain technology, even though it might not be the best for the
organization, but there's quite some power in there, which I
think is fascinating. Yeah.
The interesting thing with those kind of things, especially if
you're trying out new things, is, well, I think the fundament
below that is already wrong if you're in a situation like that.
Because in the end, it's a lack of trust there already.
Because typically when that happens, you say to your
developers like, no, you have to work on this feature, that
feature, and no, we don't have time for technical debt.
And you just make it happen. And then at one point your
developers will go on a strike because.
It's too much. It's too much and they're
postponing and postponing and postponing.
That's why I always say you should embed the technical depth
that you want to solve into the features that you're developing.
So for instance, if you want to change the logo, but you need
to, well, you know that it touches some areas, where is
some technical depth, then you say, yes, we can change that
logo, but first we need to fix this.
And if we fix this, then I can change your logo more
efficiently and that will help the team grow and excel in their
job. Yeah, I think it's fun to zoom
in on that because the trend that I've seen now, especially
with agentic tooling, is that people all of a sudden have a
tool that will magically fix this for you.
You want to change the logo? I can do that.
So when you as an engineer say it's going to take me a couple
days because I'm, we're going to work on the stick there, someone
else might say, well, why, right?
Because I can do this with a snap of my fingertips basically.
And it's fixed. Which all of a sudden now people
have an opinion on how engineers solve problems and they really
want the problems to be solved with agentic tooling, which has
pros. I love it from a usage
perspective, but it can also definitely have cons.
Yeah. I would say in the end, as a
developer, you're responsible for the work that you do for the
product that you're delivering, regardless on how you built the
software. Either you do that through a
terminal with FI or you do that with the nice and shiny Kieros
or cursors or cloud code, for instance.
It's, it's still tools. So whatever the tool produced,
you're responsible for that as a developer.
So yes, you can change the logo, but you have no idea what else
it does and what kind of impact it has on the rest of the the
application that you do potentially.
And that becomes a very interesting dialogue then,
because yes, you can change this.
And of course we can do that over and over and over again.
But that will cascade into a world where you no longer
understand your code base. You don't understand what the
implications are of changing this one property.
For instance, Yeah. And then it becomes troublesome
I would say. Yeah, I, I think we're going to
learn a lot and hopefully this year, because there's two trains
of thoughts, right that I have either teams still have that
ownership, but they lose some form of instant, oh, I know this
or I know that and they have to rely on agentic exploration to
actually figure things out. And there are pros, pros and
cons there. Or they go a little bit slower,
a little bit more, I think consciously trying to understand
their code base. And they might still very much
be hands on, not fully reliant on agentic tooling.
And I think they have pros and cons.
It's quite interesting how things are going to accelerate
and evolve. I see some people are all on the
bandwagon that say, OK, does not make sense to write code by hand
anymore already, like not even in the future, but already,
yeah, yeah, yeah. And I think that's quite
interesting. It's interesting, but also,
well, a risk I would say, because why does that work
nowadays? I would say it works now because
you have senior developers, but actually know they, they lift
the pain of developing. They know object, object
orientated programming, they know functional programming.
They know what the changes are. So if a large language model
proposes some changes to the code base, they understand it.
Now if you Fast forward to 20 years and we freeze in
technology and you do exactly the same, the person driving
that large language model doesn't understand the lower
level concepts of object orientated programming because
he never had to do that in the past.
So how can that person make an objective choice whether that is
a good or a bad chance in the context of the code base, which
you probably don't know because the majority is generated
anyway. Yeah, this is where like the
lines of code is, is kind of a challenge, right?
Because if I pick up a new programming language, I don't do
that often. And now I don't think it makes
sense anymore because I can orchestrate in a specification
feature wise what I think we should do.
And I can look at the architecture flow and be like,
OK, this is the entry point for an API.
This is where it goes in the database.
Oh, it actually is decoupled through an event at a queue
there. So I can see that even though
it's not a language I'm comfortable in, that's from a
readability perspective. If I don't know any of that, my
assumption is that whatever gets generated you should try and
understand. And I feel like, but this is a
hunch, you can get quite far through pattern recognition
where you can read a lot of code and if you don't understand you
have to consciously make it a learning opportunity.
If you don't do that, then you're lost.
Then you're the same as the people that copy paste from
stack overflow. But I do feel like this can
really accelerate your learning if you use it wisely.
Yeah, definitely. And not only that, let's take it
one step further. So the question is, does it
still matter that you fully understand the code that is
being generated when you, I think that is important when you
have in, in this hybrid situation where you have an
existing code base written by humans and then you introduce an
AI coding assistant, then it becomes very important that you
actually know from each other what you're doing to, to have a
good confidence that you're building the right thing.
Well, if you start with a Greenfield application, does it
really matter that you really understand the full code base?
Still, as long as all the specs are in the correct format and
has the right requirements and and all those things are right,
then a large language model is probably the better developer to
actually implement that in such a way.
So what is the added value of a human in that that regard?
Yeah, I think it's the the orchestration, right?
Because this is this is treating it like a black box.
We say on the edge, these are the requirements.
We can have edge cases or we have all those edges actually
also validated in integration tests, smoke tests, unit tests,
all of that which we can read as another specification and be
like, does this make sense? I know what happens in between.
You can actually kind of blindly trust it if you make sure that
that process is in order. And we've, and we've done this
in the past. So if you look at object
orientated programming where you have a clause where you say,
hey, I threw in an apple in this parameter and I expect a banana
out of it, then you don't care how that happens within the
clause. Because if you do, then you're
creating a test that actually understands the inner workings
of the class, which you shouldn't do because then when
you change the clause or you or you refactor it, then all your
tests are broken. So in a way that is exactly what
we're already learned to do from object orientated programming,
but now we apply it more on a higher level, more on an
application level. So having good end to end test,
having good integration tests and having the ability what,
what kind of what kind of patterns really need to work
well before we can say, hey, this application is actually
working as intended. That becomes way more important
now than ever. Yeah, it's interesting because
just due to working in a lot of teams, I know that the logic is
abstracted away and you test around and you don't change it
because otherwise your test fail.
It's just comparing it to this situation.
This situation is like on a next level scale, which is pretty
cool to be honest, But it also brings opportunities.
Like I've had recent conversations of technologies
where we have quite heavy license fees in certain
organizations with certain technologies and those companies
might have quite a stranglehold on certain organizations, right.
If you're all in on a certain technology and it's very hard to
migrate away. And yeah, you're kind of, if the
vendor then says, well, the license fees are up 20% this
year, just you have to deal with it basically you can't easily
migrate, but maybe now you can, which is quite interesting,
except then the ownership becomes quite a challenge, I
would say. Yeah.
If you move away and build something on your own using AI,
then you need to own that as well.
It comes with responsibility of owning and hosting the the
application, the security implications of that.
So it is a little bit more than just saying, OK, let's build it
ourselves. There is more to it.
But if the license fee are high enough and you have a
organization that can actually run these implications
yourselves, then it becomes easier and easier to start doing
that you. Have quite a business case on
your hand? Yes, yeah, yeah.
I, I hope that we get some, some good examples of where that is a
success and then also kind of learning from how they do that
because right now I have a lot of assumptions and I can't wait
to test those and validate those assumptions.
But they're still assumptions. Like we're kind of on the on the
front end of this, which is quite cool.
I know you're a fan of automation in general.
And for me, this is like automation, the automation on
the side of writing code. But if I look at the software
development life cycle, anything from researching, planning,
refining, actually building, reviewing, testing, running,
deploying, documenting, for me that's kind of the whole life
cycle. There are a lot of aspects with
the genetic tooling that we can now play around with automation
and it's a scary amount to be honest.
You might be able to do a whole lot there.
What have you done so far? What?
What have you experimented with that you'd like to share?
Oh yeah. So actually ACBIA has a platform
which is called Cbas, and that's actually doing that.
So it's brings a holistic view to the software development life
cycle, which is quite a cool tool.
So in essence, what it does, for instance, if you want to develop
a new feature, usually it happens between two people
having a conversation, maybe 3, maybe 4.
Like we need to add this feature.
What if you record that session that you have, usually on Teams,
it will give you a transcribe. So how cool would it be if you
can feed that transcription into a system and then extract all
the requirements from that? And then from the requirements,
you can actually validate that with the right people.
Are these the requirements that we've set and then use that as a
process to guide it towards a software development life cycle?
Because when you have the requirements, you can, well, a
human used to create user stories out of that.
Well, you can use AI for that. So having the requirements, you
can generate your user stories. When you have user stories, you
need to plan that. So you can do Sprint planning.
All that stuff can be automated. And to be honest, that's the
most boring part of, of doing software development.
So I really, I'm, I'm really pleased to see this development,
especially in that area as well, that you can actually focus more
on the creative side on having the discussion with each other.
What does the application needs to do and how do we ensure that
it works for our business instead of doing administrative
tasks like creating stories and that kind of stuff or writing
Confluence pages? So.
That really excites me at least. Yeah, it's, it's funny, I
actually had a conversation in this morning actually prior to
our recording. And there I shared that I know
at Veed, which is this online video editing browser tool, they
do a lot with regards to customer interviews.
And there they capture the transcript.
It all goes on a drive. A lot of people within that
team, all within product have to do 1 conversation like that
weekly talking to end users. And they have this very rich
database in the end of transcripts, which are all
interviews and discovery talks. And there they look for
commonalities through AI and they look for patterns of
features or problems or symptoms that they want to solve in their
tooling. And I felt like that
conversation that I had this morning was about developer
experience. I am now in a position where I
can do something similar. And I really want to experiment
with that. But this is very interesting as
well. When you're talking to
stakeholders or when you're aligning with your team, when
you're doing refinement. I, I pride myself in being able
to type fast. But yeah, I'm kind of out of it.
We have to have a lot of sessions, a lot of back and
forth, a lot of, didn't we actually discuss this already or
what was said again. And yeah, if you can capture all
of that in transcript, it just makes sense that we can use that
and then leverage that and go even beyond with regards to kind
of refining and figuring out what to do.
Yeah, not only that. So I don't know if you ever
looked at the transcription and then looked at the meeting
meeting report that's getting generated by an AI tool.
Yeah, I want that as well. It's.
It fills in the blanks as well. So it's, I always see a large
language model as a, a, a child that learned a lot of things
along his way. And now you, you could think
about it as a human being, a mind of a human being.
But it's primed. Well, we, we have control over
how the mind was primed. So it has a way of thinking on
its own a little bit based on the knowledge that it was
trained on. So reading the transcription and
then writing a meeting report out of that, it fills in blanks
based on assumptions and those assumptions come from the way
how it was trained. So if you do that with all the
meeting reports automatically it fills in the blanks.
And then if you as a team review that that meeting report, you
will actually see I didn't look looked at it from that angle.
And especially when you generate requirements out of that, then
it is an assumption of the model that you meant at the time when
you in the context that you were discussing it.
So either that is spot on or it's, yeah, maybe we need to add
another requirement based on this answer.
So it also helps you develop and strengthen the requirements on
its own as well, which I found very interesting as well.
That is also a skill that people have.
I've seen when people are having a dialogue.
I'm I'm new in an organization right now started in January.
People are having a talk and I ask a question because they're
like not addressing this part and I'm not sure if they know,
but it needs to be explicit, right?
Then I can have an equal level of dialogue, which is then
interesting because that's what one of the people used as a
word. When they actually answered me,
they were like, yeah, we are working on the dis implicit
knowledge that you don't have, so let's make it explicit.
I feel like that's a really cool skill to have that you figure
out what this conversation is, where there are gaps, and then
make those explicit. Those can be right.
Well, they can be wrong, but if they're wrong, we have to change
them. Yeah, indeed, I have a great
example of that. What happens today when I was in
a refinement session. So the the the obvious thing
happened, we were working on too many epics at the same time.
So and and we agreed upon not doing 3 epics at the same time a
long, long time ago. But somewhere it's.
When it always happens. It always happens every every
now and then. You need to remind yourself from
that. So we sat down with the team and
we said, look, the the column of the epics already has a maximum
of three and if you have 4, it turns rat.
So it's just a matter of looking at that board and seeing, hey,
it's rat. We need to make a choice here
which one will go out. And then you get an interesting
discussion because you can ask the product owner which one is
important because we direct the 4th one in on your request.
Which one of the other has to go has to go by making it explicit,
you sync the whole team, you recalibrate all the priorities
because if somebody is sick that day or whatever, he doesn't get
that context. But if the epic is actually
moved into an on hold status or all the the stories got removed
from the Sprint because any new important thing was added, then
he will have. Questions, of course.
If you leave it in, he will come back to work and he will start
continue working on other things, on the things that he
was working on. Yeah.
So by making it this explicit, you actually sync with the team
a lot better as well. Yeah, I feel like it's, it's
quite a mature approach. Yeah, in some teams I've been
in, when something new pops up, it's just added work and nothing
goes. And I'm like, well, that's not
really healthy. Well, especially well as long as
there is no downside at the end of the Sprint that you did not
complete all the work. If you don't have that
consequence in there, then it's easy to accept, okay, we will do
that and we're all adults, right?
So we all understood if you add this to the Sprint, then we
cannot deliver that. If you're in A-Team that works
that way and you have a understanding product owner that
also sees it that way and the share the stakeholders above
that also understand that, then there's no problem.
But if you look at why Agile was created, it's not for that.
It's for having control over the philosophy and making sure that
you have all those those insights so that you can give a
reliable planning towards the business.
When will this feature ship? And that will not never happen
if you work that way. So it's a control thing.
That's how you see it. And I think that's quite
interesting. Like I, I like working in agile
teams, but I've never viewed it as a control thing.
Some people go above and beyond with regards to when is what
done and how much is story point in days.
And I'm like, it really defeats the purpose.
In essence, when I was responsible for product, I kind
of got, I took ownership of that and I was like, I want to work
with story points and teams were like, well, do our people asking
for deadlines and plans. I said no, we can throw away the
story points in the end, I don't care.
I want to know that when someone says an 8 and someone says a
three, I want that dialogue to happen.
Yeah, I think that's very interesting.
That's where the value is, yeah, for me.
Do we have the same understanding of what this
means? If you say 8 and I say 3,
clearly there is something wrong.
You're thinking of things that should be in there and I'm just
neglecting the thing, the things that you're thinking of
potentially. So that's what I wanted.
And then I said then we don't even need to capture the stories
in the end. I do know that if we have a
magnitude of eights, I'm only going to get one or two of them
that are actually going to be finished.
So it will help us from a planning perspective, but if
it's in the way for you, I don't need that.
I can read the story and figure out kind of how big it is
myself. Technical background helps, but
I want that dialogue to happen. That's the only reason.
And then teams were like, oh, no problem.
This I can get on board with because they see the value
there. Yeah, definitely.
So I from an agile perspective, I'm yes, I'm kind of agreeing
that agile is needed in this world to, to be a little bit
successful in developing Solver. But on the other hand, having
more trust in the group of people that are actually
developing also helps. And agile is, for my experience,
what I've seen is it's not really helping the trust there,
I would say because like you mentioned, if you do story,
story points, philosophies and over X amount of sprints and
then we know this is an T-shirt size L, which is roughly X
amount of velocity, then we can ship this feature.
If it's used that way, then you're neglecting the fact that
there is technical depth, that there are other things that can
pop up. And that's why deadlines are
usually not made. And if they're made, we did
shortcuts adding on to the technical depth, which is no
time for because the next big thing is already scheduled, of
course. Is on the finish line.
Yes, well, if you, well, if you turn it around and make the
developers responsible for the the road map as well and have to
dive dialogue with the developers itself, they clearly
understand what's needed to deliver those features by
removing all the overhead of doing X amount of meetings and
scrum meetings etcetera, you can also develop stuff in that area
in that time. So I'm a bit in between, like
where is the balance? But the problem with the
approach of the trust is without doing Scrum is, is that you need
a hell of a team that is high quality and can trust each other
completely. And if you have that.
Everything's fine. Everything is fine.
It's like the A-Team. Yeah, like 10X developers,
right. The team of 10X developers, you
do, you just say these are the the the things that we need to
deliver this year. And they will say, OK, let's do
this feature before that feature because this has a lot of
building blocks that the other feature can help for.
And if we do it the other way around, they are specific to
this feature and we cannot reuse it for that, for instance.
That's the team I want to work in and operate in.
And I feel like the people that really want to kind of manage
deadlines and manage expectations in that way, maybe
they've been burned a little bit too much in the past because
developer state, they do hold a lot of power, right?
If I want to work with a specific agentic tool and it's
not in the org, some people might be like, well, I'll just
do that personally, or I might leave the organization.
Then you lose a really good person because you didn't enable
them to do what they want to. It's a very interesting power
dynamic. Oh, it's like I mentioned in the
beginning, right? You need to go to work enjoying
your time to be there. And if you're being, you're
working in an organization that doesn't allow you to do that, at
one point they will leave. Yeah, Yeah.
I think that's in the end it's fair, right?
Because that's also the relationship.
If I can be my best at work and I go Sprint after Sprint in no,
in no other industry do we go Sprint after Sprint after
Sprint. Like 50 sprints back-to-back.
If I then don't enjoy what I'm doing and I'm still doing 50
sprints back-to-back, you're going to get burned out quite
quickly. And I've seen different
approaches on how you can do this right.
You do X amount of feature sprints and then you do 1
technical depth Sprint for instance.
So there are a lot of ways on how you can how you can deal
with this. But I think having the dialogue
with your developers is the most important to to to solve this
problem. Now hopefully AI will help us
with solving all that technical depth.
Yeah, let's see, let's. See, I want to get back into
that because when I really worked well with the genetic
tooling was when I focused on having really good
specifications. And those really good
specifications came down from really good distilled user
requirements. A vision of where we want to go,
what we're going to do in order that makes sense, deliver value
as fast as possible, then test assumptions and build on top of
that rather than going for a moon shot.
In the end, I just had a lot of specs and I could run them in
parallel and I built features that way.
And I loved it to be honest. And then the outcomes of that, I
reviewed it. I reviewed it again with the
agent fresh context and then put up a pool request and people
reviewed it. And from those review marks, I
made skills to even do better pool requests.
That whole life cycle was a lot of fun.
And if you're talking about going from a transcript from
conversations with the business or from within the team and then
creating user stories, an additional or and a step even
beyond that would be to create the specifications for then an
agent to pick that up. Yeah.
So that's reality already within Cbas that is already being done.
So I just hinted on the first area of of the solution, but it
goes all the way of running the application into production and
writing the code can be done based on the specification.
Like I mentioned, you get the requirements, you get the story,
so you get the smaller tasks that need needed to be executed.
Although an agent would go faster through the sprints and
the stories as a as a human would be, but still the same
steps are being taken. And from that, you can generate
a very rich spec that you can feed into these, these
development tools to actually build the application as well.
And so, so just curious, because you mentioned you did somewhat
similar for yourself. How did you share that with the
team that you were working on? Because usually what I see is,
is that yes, developers are experimenting with AI.
They're doing what is cool and, but it's very local orientated.
And if you're lucky, they're sharing it with the development
team that they're working with, like help your your neighborly
developer, but across that the team, there are multiple
development teams in organizations.
So how do you scale that up? That is an interesting.
This is the. Challenge I'm trying to solve.
Actually it's a new assignment, but back when I was doing hands
on that was at a startup. So very much I came in to do
kind of a one man army assignment and I got to do that.
I don't think we ever we, we like to share knowledge with
regards to our IDE usage or how we manage kind of on the
keyboard versus turn men all get commands and stuff like that.
But it was never something that we shared.
It's still very much personal productivity and I feel like
this is again similar to personal productivity, except
there is a lot more benefits in sharing that, right?
If I share with you that if I do command shift Y, my terminal
opens, it's not as beneficial to you as it is to me because
that's my heart. That's like finger muscle
memory. That works for you.
That works for me. But if I share with you that
actually the value that I've seen in this life cycle, for me
it was very much in how well I do the specification.
And I would actually go through the specification and they would
ask the agent to change things and I would review it again
until I really thought that if all of this is good, then I'm
good. Then I could just execute it and
work on the next specification. I was like working out
specifications back-to-back. That's how I did it in the end.
And I don't know if that's going to scale to a certain point.
I feel like it's going to be interesting to try and make that
scale to also feel to also figure out where there is then
code based drift versus what you have captured in specifications.
But I do feel like we will solve those newer engineering
problems. I know we can fly.
Yeah. So relating to the the personal,
how do you call it, productivity gains?
So in the assignment that I currently working in, I also
created an agent, but I actually stored it in the git repo.
I'm using Copilot there. So if you use the dot GitHub
folder slash agent, you can actually store the agent there
and you can actually use that on your code base.
And what this agent particularly did was it had very specific
instructions to, when you ask it to update the documentation, it
will actually scan the, the, the code base that that it was
living in and actually had some very specific instructions on
how to update the documentation. So you can just change your code
base and then ask it to hey, update my documentation.
And then all the documentation pages were reflecting based on
the changes that you did. Having that checked into the
repository actually helped the whole team to actually reuse
that agent as well. But beyond that, how to scale
that across organizations, that becomes a a bit more
challenging. And that's what I really liked
about the a solution that we had it it's, it's, it's kind of
forces you in a workflow kind of working, which is more
organizational driven. It's a no code solution where
you actually work with normal interaction with, with human
language and you, you change specs and it gives out specs.
But regardless of what project you're using, the, the, the base
instructions, the system prompts are all the same for all the
teams. So if you change something
there, it applies to all the teams from a scalability
perspective. I found that very interesting
and I'm curious how that will scale in larger organizations as
well. Yeah.
I've seen a conversation on, OK, are we going a multitude of
agents or are we going with one general purpose agent and then a
multitude of skills that it can apply.
And I think that conversation is still ongoing.
But whatever it is, I feel like offering, if you're talking
about multiple teams, an organization with 1000
engineers, so hundreds of engineering teams having
something central that is kind of a baseline template with some
general purpose things and some very specific things, I think is
always valuable. And then if people take that and
they say, well, our conventions are XY and Z and we make
something very specific for our repository of use case, I think
that's phenomenal. I feel like that's the way it's
heading. And I I don't know if I see any
other alternatives other than kind of teams managing it
themselves. I don't think it's sustainable
to let teams manage themselves because especially in bigger
organizations, you have certain quality aspects that need to be
met. Some, to be honest, some teams
find it's not needed to scan, for instance, with Sonar Cube or
Sneak or whatever kind of tool you have to do security
scanning. And they found that one example
that I used to have. From my experience, if you use
Sonar Cube to scan your code base and it says OK, this is not
a Safeway of using it, then the first developer response that
I've tended to see was yeah, but it cannot do any harm in this
particular situation. Not in this case.
OK, so there is a security
hotspot now in this dashboard, it says 1, OK.
And then the next thing pops up and then it says 2.
And then if you have a good secure security practice, you
would actually review those hotspots.
And then you would say, OK, it's safe to use here because of this
reason. You do an annotation there.
But if you review that regularly, or at least in a
fixed cadence, could be 6 months, could be 3 months, could
be once a year, but at least once a year, worst case
scenario, I would say you would review this list and see, Oh
yeah. Is it still OK to use this?
And you're spending with 2-3 people like 5 minutes debating.
Oh, yeah. What was this about?
Oh, yeah, yeah, yeah, yeah. It's still still valid.
Still valid. So there was 1515 minutes.
So. But the fix for that problem was
probably like 2 minutes. Now if you do this on a regular
basis, these reviews, then you're spending 5 minutes every
time discussing it will cost you a lot of time in the end.
And that is just one issue. So I'm tend to be more of just
use those tools, fix the fix the problems right away.
If it's a fix of one minute, yeah, don't be that lazy that
you don't want to do those kind of fixes so.
The problems is they, they compound in a very interesting
way, right? You can say, well, in this
linear way that we have right now, this, this moment in time,
it's fine, but things compound, knowledge gets lost, right?
I, I really try and put as much as I can in my commits, in my
pull requests, in my descriptions, because that's for
future me and for future colleagues that I will never get
to meet. In the end, that's as much
context as I can do right now for the future.
And if you don't do that, then things will compound.
We're not necessarily building a system.
Sometimes it's like an Organism and problems can just emerge
because we have a few hotspots and all of a sudden they form a
triangle and they mess with your system.
Well, too bad, that's just how it goes.
Definitely. So to come back to the point, so
do you want to have your developers responsible for
arranging all those work flows, some teams, maybe other teams,
maybe not. So from that perspective, you
probably for the bigger organizations, you do want to
have some control, some governance over how your
developers are are working. And again, not as a department
as no, but how can we actually use this technology to to help
you excel in your business in a safe and secure manner.
Also from the cases that you didn't thought off of or don't
have experience with. I feel like we are in a unique
point in time where people have an opinion on people's personal
productivity when it comes to software engineers.
Before software engineers are scarce, they are highly
intellectual people, they have quite a valuable skill set and
there's no alternative. Now there is an alternative.
It is the first I think ever to disagree that there is an
alternative. So people have opinions and I
think it's very interesting because some people are not
budging. They're like, this is a hype,
this is a bubble, it's going to fade.
Some people are kind of in the middle or they feel that this is
definitely something they need to jump on.
But there may be hesitant, there's maybe a lack of
knowledge. They may, they might not get as
much room working. And then you have the the
complete opposite. That is like all in that says if
you do not use this, then you will become obsolete.
There is no point in writing by hand anymore.
Which I think is so fascinating. Never before have we had this.
And then if that side wins, if the latter side wins, that says
you have to do this, you cannot write by hand anymore.
Then that. That might just be an
organizational policy where the fact that you're writing by
hand, even though you enjoy that, you should not do that in
the organization anymore. You should do that in hobby
projects, get your fulfilment from that.
But this is a business and this is a very interesting trend.
Yeah. But again, that really depends
on how you define a developer or a software engineer or a
programmer. So I I saw somewhere on the
Internet. In a podcast.
In a podcast or in a book, I don't know where I saw it, I saw
something like are you a programmer who writes code or
are you a software engineer that you design software
architectures and that you write applications.
Writing application can also be that you define how the
architecture works, that you review that.
So the tools, how you built the software just changes.
So I really need to find joy in the developments process of how
you actually shape and build the application versus actually
writing the lines of code and figuring out what a semi colon
got lost and that you have a parse error.
So what is the thing that you gives you enjoy and hopefully
for the majority of the software engineers, I would say it is in
the designing part. Then your job is still safe
because you still need to review the, you need to make up your
requirements. You need to review the
requirements, you need to review the architectural decisions from
large language models. And of course they will get
better and there will be less errors, but still, you are the
author of the application. You're only using a tool to
build it for you. It's not let's take a different
approach. It's would be the same as me as
a manager asking hey this is how the application should work like
right? Fully specced developers go
build. That would be exactly.
The magical world. For me, for my, my, how I see
the world, then whether I ask this from a developer to create
or an enlarged language model to create and I the end result will
probably be the same or even better with with an coding
assistant. It's yeah, it's.
What do you call it? It's.
I think it's how you look at it in the you can do more I think
even now. So if you really enjoy the
problem solving aspect of it, I felt quite empowered to solve
problems faster because I didn't have to do it hands on in the
code. Sometimes I've been in
refinement where we discuss a problem and then in this team
specifically, they want the solution or the solution
described in the ticket as well. So then the only thing the
person has to do is read, they understand the context and
execute. And that I don't have to do
anymore. So I don't have to do the
execute anymore. I still have to do the thinking.
I still have to do the reasoning, maybe not on a code
level, but yeah, I do enjoy that part a lot more.
And I would say that trend was already there before AI, because
if you look at monolithic applications and micro services
and then going cloud native or in AWS, for example, that's
sparks your, your, your creativity to think of problems
in a different way. Because if you're writing a
program, a command line program in C, then the solution would be
very different than you would use micro services, for
instance. So you architect your problems
or you architect your solutions differently from your problems
using the technologies that are at hand.
For example you can use an APIAPI gateway and with with
micro services behind it. Or you can create one monolithic
application so that the whole design phase goes more into how
will I use these components Or it will be in a monolithic
application, how will I organise my classes to be somewhat
similar but then with different technology, it's just it's a
shift and and now it's a shift again.
So the tools are just changing, evolving.
It's just right now it's quite quickly that's that's evolving
in the very space Skynet is coming.
Yeah, I have one final question which I think is interesting to
get your perspective on. I do Q&A's.
So in Q&A's people send me their questions and they ask me from
my perspective. This question I thought was very
interesting and I I might have even struggled answering this
because there is no right answer.
They said I have a product background, but I'm trying to
teach myself software engineering.
But even without the product engineering background or
product background at all, how would you nowadays, if you're
responsible as a mentor or as a teacher, teach people about
software engineering? What would they focus on?
My answer was a lot less about actually the creating of code.
I do think understanding is is still there, but I'm curious
what your perspective is. I think it would be more in
system thinking like these are all, are there multiple systems
interacting with each other and how do would they interact with
each other? Who's responsible for what
system? So it's more slicing dice, those
areas like what are the responsibilities for for this
particular entity within the application and have that
understanding on what it does. And then you have, you don't
need to know how it's built. You don't need to know who's
written. It could be written by a human,
could be written by AI, but you know what it's responsible for
and what it's core task is. And if you know that from the
majority of the things, then you have a good understanding on
what's what the application is, what it does, and what the
capabilities are. Yeah.
So you go one level above actually the the software
creation part itself. And look.
At the system as well. Yeah.
And then, then regardless if it's written in PHP, go, Rust,
whatever, it's a system, Yeah, it interacts with something.
Yeah, I like that a lot. Thanks for coming on and sharing
yours. This was really fun.
Yeah, thanks. I really enjoyed it.
If you're still with us, let me know in the comments section
what you thought of this episode and we'll see you on the next
one.