We're usually brought in when the house is on fire, right?
I don't think it's an automated way how you migrate code bases.
It's little pieces of of value that I add and that's how I
progress from one stage to another.
But that's intense. The right to these tests
beforehand that there's risk mitigation.
The more coverage you have, more accurate your parity checking
is, the less risk you have at the AI is a differentiator.
It empowers great software architects, software engineers
that have a strong software architect system designed
capability versus those two. Not to write great software, you
still need to be a great engineer.
That didn't change. If you're interested in system
design and modernizing and migrating software, this episode
is for you. I'm joined by Dennis Fink,
principal consultant over at Xavier, and I loved learning
from his approach how he executes on the many ideas and
projects that he has. So enjoy.
I looked at your LinkedIn and already in 2024 you landed
assignments as AI engineer. Was it all bringing AI to
production or was it more also kind of AI in way of working?
It, it, it was more companies wanting to learn more about AI
and, and the very beginnings like models were pretty
primitive back then and there was not a lot of knowledge.
What you see nowadays is that companies are much more
self-sufficient. They have a lot of knowledge
internally about artificial intelligence, so now the
assignments that you currently get are are more complex.
Gotcha. Yeah.
But it's still bringing AI and AI component to production.
Yeah, somewhere within a product, yeah.
Can you share some of the examples that you've brought to
production? For example, knowledge bases are
quite popular. So that's, that's the
interaction with with the rec system and then the interface
around how do you interact with its response times, those type
of things. But also like a Gentic data
research. So you have a big query
database, for example, with lots of data in it.
You want to get insights out of it.
How do you do that, and how do you do that responsibly?
Yeah, I know you get a lot of energy out of building things.
Can you share some of the examples of what you've built
recently? Recently I've have a lot of side
projects. One of them is Eurosso, which is
a genetic platform where you can automate business processes,
which is really fun. Another one is a very old game
that I played about 20 years back that I brought back to
life. So I converted it from a binary
and a bit of source code which was written in C and C++ to to
Rust and then a graphical user face around it so you can play
it in the web browser. Nice.
It's really fun. How?
How is your CC plus plus or or rust?
Rusty. Yeah, Rusty, very rusty, yeah.
I coded C and C++ maybe 30 years ago.
So that's that's a long time 3025 years ago, more or less.
And well, then you evil to other other languages, a a bit lower
level languages, higher level languages and it it's the
knowledge about this programme like it just disappears.
And that's not an issue with regards to bringing this piece
of software back to life. No, like I can still read it.
And while you're working on such a project like the, the, the
patterns are still familiar and you know the principles and you
can write pieces of code, you can debug it.
So it's it's like learning to bike you, you don't forget it.
Gotcha. Yeah.
So patterns, principles, those are the knowledge you need to be
able to do something like this. Or how do you see that?
Yeah, absolutely. Yeah.
Yeah, I think if you like you, you have the term fight coding,
right? It is a, a, a bit of a, there's
a bit of a smear on the term because it's, it implies being
able to create applications without, without programming
knowledge. Yes, you're able to do that, but
you're not able to exercise any control over it.
So if you, if you fight code something you have serial
knowledge, it will just go the direction that the the model
thinks is best. And you're not able to assess
quality and you are not able to give the proper direction.
What do you assess in terms of quality, especially when we're
talking about a piece of software that's written in a
specific language and you want to modernise it?
Feel like a lot of companies or maybe even people always
migrations and modernisations are always a topic.
But what fundamentals do you really need to have to be able
to do this? So you need to be familiar with
test driven development. For example, let me let me take
the the game accept. All right, so I migrated old,
very old game from from binary C++ to Rust.
But you want to ensure that the mechanics are identical.
So my approach has been to to write tests, but also to use the
code of both systems to assess whether the what it reads and
what its outputs, the actions that it does that they perform
identical when executed. So if it reads something and it
parses something in one system, it needs to be identical to the
other one, and that's how you prove parity.
And this is in an automated sense.
In an automated sense, yeah. So I I created tooling for that
to to simulate. For example, in in this game
system, you have certain actions that trigger other actions and
then wrote a simulator like we, we triggered this action.
Does it have exactly the same consequences?
And that's how you how you proceed.
So that's kind of a brute force way, but that ensures that the
end result is is identical even though the code base differs.
And these actions that you've specified in this way of
working, are those actions upfront that you're saying these
are the the set of actions we need to validate or are they
also generated or randomised or how do they come into place?
No, they so they they're the the actual code and three points in
the original game versus the the new version.
Culture interesting and looking at a perspective with regards to
test driven development. If the old code base didn't have
any tests, do you then work to mature that to a certain level
before you go modernised? Yeah, absolutely.
Yeah, Yeah. Interesting.
Because a lot of organizations that I've looked at, people that
I've spoken to when it comes to software that they want to move
away from, maybe there's a license component, maybe there's
just a knowledge gap there. Maybe they want to move to a
different platform or a specific language.
Typically those older code bases, they don't have that
level of maturity. They don't have the test
framework. That's one why they want to
modernize in the 1st place. And sometimes it's even instead
of a migration, a complete rebuild and lots of those
projects in the end fail because it's a huge effort and you need
to really have buy in from the business side because in the end
it's a very long term play. So moving away when the code
base is not really mature, that's I think also part of the
complexity typically. Absolutely, Yeah.
It's so writing these tests beforehand that there's risk
mitigation and the more the, the more coverage you have, the more
accurate your your parity checking is, the the less risk
you have at the end. Nice.
Yeah. So the parity checking that is
mainly crucial, I guess. Yeah, you start with a code
base, you make sure that maturity wise, test wise, you
have a good safety net. Then you modernize and you
modernize in an automated way, I'm assuming.
Does it matter which model or which methodology you use to
modernize? I don't think the model matters
much as long as it's a competent model like I.
I like to use open DI myself. Codex models, but you could use
cloud. It doesn't.
It doesn't really matter and methodology does matter.
You need to have the the instructions in place the parity
tooling and I think that begins before you migrate any actual
code. Gotcha.
Yeah. How'd you come into this way of
working? Is it just a lot of trial and
error experimentation, or? Like I became an enthusiast the
moment it, it's, it went from large language models to to
agentic. And I realized you could
automate a lot of tasks with it. That's when I also got very
interested in, in, in creating euro cell to, to solve, to
automate business processes because I could see the
potential of, of agentic. And so I became a enthusiast
early on and, and started experimenting and, and you see
as time progresses, these, these models get more and more more
powerful, especially with like the tool calling they can do and
the accuracy on that. Yeah, it's interesting because
ownership is always a big thing, right?
I put a lot of effort into my codebase historically with
regards to my commit message structure, the way we design
systems and thinking about software architecture and
applying patterns and keeping things simple and evolvable for
the future. And I feel like a lot of those
are kind of out of the water. And especially when we're
talking about a modernization, if I go from codebase X to
codebase Y in an automated kind of finger snap way, how much
influence do I have on the structure?
Or should I care about what the code in the end looks like from
your perspective? Yeah, I, I don't think, like you
say, in an automated way. I don't think it's, it's in an
automated way how you migrate code bases.
So how I typically approach that is how you define like user
stories that are really scoped to a specific piece of value.
And that's also how I instruct the model.
It's, it's little pieces of, of value that I add.
And that's how I progress from one stage to another.
And that's, that's intense. Like for example, the the game
server migration overall, including the the web interface
and and an editor took about a month of, of work, not full time
work, but but still a month of work of, of prompting.
It's rating how you would do it as a as an engineer as well.
You, you iterate on on the product and you add little
improvements gradually. So I don't think that that
differs much. Yeah.
Are engineers typically good at this because they have to step
out of the hands on part and more orchestrate things with
regards to, you already mentioned user stories and
that's a lot of prompting, a lot of back and forth.
Typically, that's not really what we historically have spent
most of our time on. Most of the time has really been
on actually building the thing and being in meetings to discuss
about the thing and getting a better understanding.
But that's one of the execution side of things, yeah.
Is that changing? I think that is changing and I
think you will see that engineers that are like their
philosophy is limited by, by execution will love to be able
to like zoom out a bit and have a whole overview and being able
to orchestrate on that level. And you have engineers that are
in their in their little bubble that that don't know how to do
that. You started creating code very
early on. Age wise, you were there very
early and typically those are the people that really love the
hands on part of things as well. But since the hands on thing is
evolving, are you still getting the same amount of fulfilment or
how do you see that? I think it's accelerated, yeah.
Like I have, I have a mind that is always exploding with with a
million different ideas. I have probably hundreds if not
thousands of unfinished projects.
Oh yeah. Still, yeah, absolutely.
It's never going to end. Yeah.
It's, it's never ending and I always have have have different
ideas that I don't have time for, for fleshing out.
And this type of tooling helps me finally finish something you
get from from A to C quite rapidly.
And it allows me to to have that focus to to to finish it.
For me, I think I'm, I'm the opposite compared to you.
When I start something, I really want to have the conference
confidence that I can do this and actually finish things.
So if I don't believe that I can finish something, I typically
don't start many things because I feel like what's the point?
If I start and I don't finish, I have to finish or at least see
it through to a point where I'm fulfilled.
What would you advise people that are like me or similar that
have trouble starting because starting seems effortless from
your side? How do you make starting easy?
Or does it just come automatically?
Well it it comes semi automatically so I've HDHD
brain. So that means that I start a
million things and unlikely to finish all of them.
But there's also the sense that I like the journey, like I like
the the learning journey, the experience of creating and a
project doesn't necessarily need to end with the finished
products for me. So it's also just just having
fun. Yeah.
Can we go through a scenario? You have an idea and you want to
start something. What are some of the first few
steps that you typically do with regards to starting?
First, I've I've also have a business background, so I do
some research, but this already exists.
Is it marketable? Sometimes it it could also be
just a fun project for myself, right?
Yeah, like the game migration. Like the game migration.
So typically it starts with a bit of research and then
formulating a like a high level plan, like what do I want to
achieve? What are my goals?
What is the end state? And then drill down from there
into more details, steps. And usually along the way I get
a better idea of, of what I want to build.
And sometimes that changes during the development process
as well. Like I get an, a great insight
like how this could work better. And then now it's really easy to
pivot. So in the past, if you are
working on the project and you've invested months
developing something, if you get a new insight that's requires
you to rewrite a large part of your code base, that is very
demultivating because you've invested already so much time.
So you have this, this sunk cost fallacy, which you also don't
have now. So it's lowers the the
thresholds to to pivot in that sense.
I've done since I'm prompting a lot, I've installed like speech
to text software on my laptop and I just talk a lot more with
regards to either brainstorming if I have to do something non
code related or if I have to do something software related.
Still, I feel like prompting now and typing has become my
bottleneck because of that interaction.
I want it faster and faster to get the feedback faster and to
get up and running faster. Is that something that you've
experienced as well? Partially, yeah, especially also
like due due to the speed, like agentic coding is not, it's not
instant. It's not like you prompted LLM.
You get an instant response and and and things take time.
In terms of prompting, it's it's more the the waiting for a task
to be finished, to see, to evaluate.
Did it do what I want and then re prompting or moving on to the
next bit And and it's that that wait, it is a bit of a waste.
You can mitigate it like doing parallel features, for example,
that say that don't touch each other's code base or source
files. But there's a, there's a bit of
yeah, cutting loss. Is that to say?
Do you parallelise? So when you're working on one
feature, let's talk about the modernisation example of the
game, you define your user stories, that's what you
mentioned. Do you then see, OK, if we do
these in parallel, these are not really going to touch each other
or how do you approach that, that waiting period?
If I know for sure there's no overlap, but usually like for
example in the game example, I have AI, have a game server, I
have a database layer. Yeah, I have an editor and I
have a web client and all of those four, they can, they can
use some work. So if I paralyse, it's usually
on the spread between those projects.
Gotcha. Yeah, So that's more defined
boundaries rather than very close to each other feature wise
in the same domain. Yeah.
What do you now do is what do you nowadays do while waiting?
Because I feel like I am a little bit more waiting nowadays
than actually executing. I read a lot based on the output
or I go do something else but I am more in a waiting state I
feel like. Yeah, yeah, usually.
So I follow a bit along what it's doing because it's also
shares like it's, it's AI thought process.
And sometimes that leads to new questions or new insights.
And then I go look it up, make a bit of research, for example,
format of specific Sprite library, for example, or
thinking, oh, I maybe I want to support X&Y format.
And then I go look it up if that exists and, and how do you
ingest that, for example. So it's it's reading up and if I
have nothing else to do, I will get distracted with something
else. I'd probably forget what I was
doing anyway and then come back half an hour.
Oh yeah, I was doing that and looking at the output again.
Gotcha. Yeah, I did a poll recently for
the people that are listening. It was what are your favorite
topics on the podcast? And system design was the one
that won. I think it's like 50%.
And then I had four options, so head and shoulders above the
rest. System design for me is quite
interesting. It's not something that I'm very
good at because I've always come into projects where something is
already live and now we're building on top of that.
So a lot of artefacts with regards to system design have
already been chosen and unless we're bridging a gap with
regards to a new feature that we have to do, there's not much
thinking in advance. So my experience has not been
from zero to one that often, but I know throughout your
experience you've worked and focused on cloud and also as AI
engineer, you've brought a lot of stuff to production, not just
in companies but also inside projects.
Do you think system design is still going to be one of the
most core competencies for the people building or how do you
view that? I do think it's, it's just going
to remain important for sure. It's, it's, you need to have a
strong foundation. I'm a I'm a strong believer that
you will see in the in the in the coming years.
That AI is a differentiator. It empowers great software
architects, software engineers that have a strong software
architect system design capability versus those who are
not. I believe that the the quality
of the of of what you create with with these models is
exponentially higher in great engineers versus those who are
not. Well, first, not to speak of the
new generation. I I worry for them.
Why do you worry for them specifically?
Because they will not be educating themselves in these
principles anymore. Because it's, it's like the
Fable, it's, it's take out and you don't have these learning
experience anymore. Gotcha.
What would you advise them then? Because you're saying software
architecture and design principles, those are going to
be important since you are more orchestrating rather than
executing. What would you advise the new
generation that's now learning or studying and coming up
actually? Go go through the big yeah.
Yeah, do it manually. Is that what you mean or?
Do it manually, struggle, make mistakes, preferably get from
the Internet so you have no resources to look it up and
that's that's the way how you truly learn.
Yeah, that's difficult. I feel like because the the
manual approach, it will no longer be what companies expect.
I feel like if they will hire juniors, they will expect them
to operate on a meaner level because you give AI tooling to
accelerate people to also accelerate their knowledge, but
also their execution power. So then doing the manual route,
especially on company time, I think that's going to be
challenging. It's going to be a hard bargain.
Yeah, right. Yeah, Yeah, it's.
Going to be a hard bargain. I think it's, I think great
engineers are usually interested in in, in writing software at A
at a younger age. And I think that is when you
make the investment. And I think the true cost of of
the accessibility, the availability of these models is
that new generations will have lack of understanding of how to
build software. And looking at the industry,
because I'm curious there how, how you see this a few years
back you would be able to do a boot camp or at least this is
what was out on the market. Boot camp, six weeks, two to
three months, education specifically for a core
competency, meaning front end or back end.
And then you would be marketable.
That was the boot, the boot camp kind of marketing strategy.
And some people coming out of that boot camp, they really got
kind of hooked and they found fulfilment in creating and
executing and building. And then they probably landed a
job because there was a big demand for software engineers,
for people that would be able to execute and create.
I feel like the market is kind of flipped upside down.
I don't know if it makes sense to go through a boot camp with
regards to core competencies or skills with regards to front end
and back end anymore kind of cookie cutter model as compared
to taking that same time and educating yourself and using
tooling that is now out there to self educate.
How do you see that? I think that's a good point.
You had companies like Kodish, you're right, that's educated
developers. I've also personally seen a lot
of very good people come out of there.
Also people that's that drought, that's that were not able to get
this fire started in in themselves.
And I don't know what's what. What is the difference between
these people? Like what makes one person gets
really enthusiastic and deep into into the matter and and
others not? I don't know what what the
difference is, but yeah, I don't know where we're going, but.
That's OK. But I, I do think, yeah, I'm
back on track. So I do think that people
nowadays will have way more opportunities to educate
themselves. There is a lot more information
available on the Internet and people can experiment really
rapidly. It's really, really rapidly.
So that might ignite that fire in them.
Yeah, I feel like one of the things I really underestimated
coming into this industry was the amount of collaboration that
I do within a team. Not just within the business
with regards to what are we building and why is that, But
also throughout the team. There were a lot of inter
dynamics of working together and trusting each other and then
letting things be with regards to what other people build and
giving feedback and reviews. From my perspective, that is
evolving. If I as individual have more
building power, more execution power, then maybe instead of a
team of 6, we can have a team of two or three, and that is really
shrinking. So then the focus I had on
trying to fix collaboration, I feel like we'll be much more
focused on the business side of things, trying to understand
what are we actually building and why is that?
I feel like that will be where software engineers are going to
grow, not just going deeper on the technical side, but also on
the business side, understanding outcomes more.
You already mentioned when you start a new project, one of the
first few things you do is research from the business side
and also seeing if it's marketable, which I thought was
quite funny. And I also do that.
And it's because I think I like entrepreneurship.
I like building something also in terms of outcomes, but I
don't, I, I've spoken to many software engineers that are not
like that, that also like building for the sake of
building. And then when they've built it,
that's it basically. That was the fulfilment.
It wasn't the fulfilment that comes after.
For me, it's the fulfilment that comes after and those distinct
parts, the building for the sake of building or the building for
the part that comes after. I see those as very much 2 camps
and 1:00 will be happier. I feel like with a gentic
tooling and the other one building for the sake of
building, that is the part that is rapidly evolving.
So I don't think those people will experience the same
fulfilment anymore. Which is, yeah, it's it's new.
It's never been this crazy in terms of evolution.
No, no, absolutely. I, I think you're right.
So that'll be a big differentiator as well.
But you don't know what happens when people get the headspace to
think about these things. So when you have the, the if, if
you're more an orchestrator rather than an executor, so
your, your roles change. Actually imagine you're stuck in
the old roles, but you discover a genetic tooling.
You will get more headspace to also consider other, other
things. Like I used to be someone that
was deep into my coat as well. That that was my, my whole world
at that at that time. Along the way, I, I learned the
ability to, to zoom out and look at the bigger picture and I
found I found enjoyment in that as well.
But that's something you, you, you learn.
And I think that learning process is accelerating as well.
So that might also affect people who are not there now but might
be in the future. Yeah, I'm wondering in terms of
focus, because I always see myself as software engineer, no
matter if I have the responsibility of a person that
is responsible for product. At my core, I feel like I'm
engineer, but I also feel like there is a lot to focus on or be
responsible for as software engineers in terms of knowledge.
And one of the things I didn't really look at was system
design, which I think is is going to become more important.
So I should put my time and effort into that.
But system design as a whole, it's also how do I make my
software actually run or what does it run on and what are the
underlying components of that Infrastructure wise, I feel like
infrastructure might be a good bet with regards to focus
because if building is accelerating, then yes, we will
have more build pieces of software, but it still has to
run somewhere. It still has to scale to a
certain component, still has to be in the hands of users.
And I feel like infrastructure is kind of the the core
competency there. I don't know how much innovation
has been happening in terms of a gentic solutioning for that
front or if people are still very much operating in the same
way they did two or three years ago.
Do you know? I think it's like cloud
infrastructure hasn't changed a lot in terms of core principles.
It's become more accessible so more people can easily deploy
cloud solutions. But you're, you're right, it,
it's, it is a core component, but it's also also just a small
part of the solution, right? So there is a phase where you
where you do the the infrastructure underneath your
replication, but that might be two weeks, a month and then then
you have it running in terms of like developing infrastructure
scope for example, a genetic models can help with that as
well. Yeah, yeah, yeah.
I did not do any infrastructure as code for a long, long time.
And then I came into a project where that was part of the
responsibility. And then using and leveraging A
genetic tooling because it is code, it was quite powerful for
me to just illustrate and say, well, these are the things we
need to change or what is out there in the 1st place.
It was very good actually at identifying those things
infrastructure wise. Yeah.
Yeah, what what I like about the like infrastructure scout in
general, it's a very deterministic role.
So if I have a template, if I push it to test or production or
to acceptance, it will behave identically because it's a
deterministic template. It's a declarative with AI
coding, that's that's not the case.
It'll it'll write code and if you prompt the same thing again,
it will write different code. So that's, but that, that also
has its appeal because it forces you to design the process and
the tooling to, to fall into surgical strains.
So you have predictable output. So for me, the, the allure of,
of cloud engineering was to create deterministic roles
because I believe that determinism in development
processes makes engineers happy, especially DevOps engineers who
might otherwise be cold awake at night.
And for for example for software migration or writing new
software it is I I get fulfilment about shaping the
constraints around it to produce stable code, high quality code
and scalable code. Yeah.
For people that have then, as an example, a code base that they
want to modernise, that they want to move away from, there's
a lot of vendors that kind of hook you into a certain way of
working with specific components, a specific code.
And if that is 20 years ago, you might still be building on top
of that, which can be quite substantial when we're talking
about absolute lines of code. It can be in the millions
basically. Also with regards to business
logic and the complexity that is in there, you might have teams
that are kind of maybe not even building features on top of it
anymore, but just that are there as insurance to make sure it
runs and they maintain it. Now there is an opportunity to
modernise. And I feel like that
modernisation can be accelerated with tooling.
You already mentioned that we have to make this deterministic
or close to deterministic in terms of quality and outcomes.
It can't just be a finger snap and then you have a new code
base and what is the outcome of that can be non deterministic.
So you have no clue if you can migrate or modernize or shift
safely. But do you think this approach
can work regardless of the scale of the existing code base?
Give an infinite tokens, yes. That's the constraint.
That's the constraint, yeah. Interesting.
So it gets expensive really, really fast to to give you an
impression, the amount of tokens I used for the the game server
migration runs in the billions. OK, so that's that's a huge
project, but it's also a big code base, right?
There were more than I would say about half a million of, of, of
lines of, of code lines assembly C++ and some some old Flash
clients like Flash is also from a from a previous era.
The Flash client actually ran into the millions lines, lines
of code that varies from both. That's that's huge.
So that that takes a lot of processing power to to process,
but you do it in chunks, you do it in little chunks.
I look at the specific set of functionality I want to migrate
this, this piece of of functionality, this slide and
then create a plan for it. So I have an executable plan
with with check boxes you can take off and I work on that in
conjunction with the with the parity tool.
And then when that piece is done, I archive that the
documentation for later reference and also continuously
do regression testing. So that's my new change break
something that I introduced before.
Yeah. So the general my way it's it's
not a really fast process. OK, So it's not like the snap
and you have your new code code base, but I think it's the the
the best way of working to ensure that you produce
something of value. Yeah.
Interesting. The finger snaps way, that would
scare me, right? Because if all of a sudden
there's a new code base and there's no ownership, there's no
people that are in between orchestrating the thing, but
they still have to own it. That's just as like throwing
something over the fence basically.
I don't think that would work. But this way of working, I'm
assuming the same principles with regards to a modernization
strategy would apply, right? If I have a software piece of
software code base I'm modernizing away from, I'm going
to look at my modernisation strategy.
I might want to migrate specific features first or deprecate
certain things. I might want to freeze new
functionality that comes on top of that, or figure out a way
that can build in parallel, although that has risk.
So you're going to do a lot of it's, I feel like it's a whole
risk mitigation exercise. And that still needs to happen
even though you have tools that accelerate and you might not
have to build hands on yourself as much anymore.
That would be my same approach. Still figure out what the
modernisation strategy should be, then approach it from that
way. So.
Imagine that you're building a product with an with an API,
right? And you build functionality on
top of that. Or you deprecate certain stuff
from that API. You would still have to think
about the same principles. I need to deprecate that
endpoint or I need backwards compatibility and you need to
safeguards that. That is actually built in.
So do the the actual checks, Do the API still do the same?
If I call the new API with an with old POST parameters, does
it? Does it return exactly what I
expect? And it it's easy if you have
the, the, the codes of the the old API versus the new API to
write a tool that automatically checks that like how these are
the possible input values and you can do assertions, right?
So if I post this combination of values, I expect this result.
And if not, there is an error in the API.
So you can instruct the agents to to actually leverage that.
Maybe even run simulations for combinations of both parameters
and then say does it in each instance return what I expect
and if not, revise and and fix the error?
Yeah, yeah. Interesting.
I really want to work with this in a production kind of sense
and I'm now at a client where I have the opportunity to do so.
So this is going to be fun. This is the magnitude of things
and the teams that are involved in the code base scope.
I wouldn't know where to start and we're probably going to run
experiments, but I'd like your suggestion of the code base is
not as mature in the current state.
You need to work on the maturity side of that first, so looking
into the existing flows and creating tests around that, or
at least scaffolding around that.
Absolutely. But also so not not only
maturity in the sense of tests and and priority tooling, but
also documentation which is often lacking.
Like the more the more the agent knows about the structure of the
old project and the so so the structure and the the the the
the layout the better. How much of this do you do
manually or how much do you rely on kind of your your agent to
give you input into structure and formalize that is what I'm
still wondering. So when when starting up,
there's a lot of manual input because I have a particular idea
about how these documents should be structured, what should be in
there, what is important and what is not important.
Whereas an agent does a does a wild guess based on inferring
from the from the source code. But I have a more high level
overview of what's what the scope base is and what all pain
points will be. So I make sure that the most
important points are document as well, and then have an agent
revise it once I have the base in place.
Nice. I want to talk about risks and
pick your bane on that front. I've heard a narrative, I don't
know if it was in person or online because sometimes those
blur together, but that certain agents are not as good when it
comes to specific programming languages.
You already mentioned CC Plus plus from the example of
modernizing the the game code base Flash as well.
Is that something that you've experienced in in practice that
for example Rust since it's a newer quote UN quote language,
it's not as good as? I found, I found migrations to
go to be much better than than Rust.
Like Rust. It's it would often lead to
compile errors because it's Rust.
Yeah, that's Rust. Yeah, yeah, that's Rust.
Also, if I do it manually, yeah, yeah.
Yeah, exactly. So that's that takes a few
iterations before it compiles in the 1st place.
Whereas Go I rarely have compile errors if I if I have an output
Go code, I don't think it has a lot of knowledge about Flash in
in general and the models that I use.
Also nobody uses Flash. So yeah, why?
Why makes sense, makes sense, but it could infer from most of
the principles like so my the the Flash client I migrated to
HTML JavaScript. OK, it's got the base right in
one shot, but particularly implementation details it did
not. And then I that that took quite
a few iterations to to get right.
Gotcha. And then when we're talking
about risk, I feel like hallucination is still a thing.
It's getting better and better, but how do you build around or
with hallucination in mind accommodate for that?
That's that's the test to me. That's all the scaffolding is
basically. Is it just for the non
deterministic part? I assume so, right?
Yeah, nice. The same feature parity sense I
could still do regardless of any code base, right?
Because code base will have features.
You have a structure around figuring out if the old code
base behaves the same as the new code base.
So I don't see feature parity working differently for
different pieces of software. So how do you build on top of
that? Because the existing code base
for me feature wise has everything.
It's complete. That's what you're modernizing
away from. But the new code base you're
going to incrementally build up in terms of features.
Sometimes it's just a ball of mud and features kind of are
very much interwoven. How do you accommodate for that
when you're moving to a newer code base?
So the the advantage of the the approach I described is that you
also you, you already have your tests written right in your in
your old code base because you're maturing that you already
have your parity tooling running properly.
That also means that in the new code base you will also have
tests already written and you will have regression tooling
that checks whether a change that you made, but it leads to
to a regression bug for example. So that makes it really easy to
to iterate on it. And if you are going to continue
with agentic coding on the new project as well, which I didn't
assume is the advantages, you can can use the same pipeline
and you can codify that into your documentation that that
needs to happen every time a build this room for example.
That newer way of working, if we have an existing code base, you
can structure it in a way that agentic tools work quite well.
There's a narrative online on skills versus agents and how
much documentation is too much documentation, how explicit you
need to be versus relying on implicit model knowledge.
I feel like years ago you had to be very explicit, but nowadays
there's a lot of implicit model knowledge.
The way of working that software engineers are going to go about
is very much changing. I'm on the train of I feel like
spectrum development is quite effective if I put my time and
attention in building a spec. And also a spec is quite
arbitrary. I've noticed people have
different interpretations of what it is to create a
specification, but if I have a very solid spec that actually
aligns with the feature that I'm trying to build, then the
building of things is actually quite reliable.
If I have really good conventions, that is even
better. And if I have the right
scaffolding and the right kind of safety net in testing and
resilience, that's the best, to be honest.
So I really see that as kind of at least right now how we're
going to operate in the future. What is your view on that?
Yeah, I think that's a devil evolved, right?
So absolutely. I have a have a fun anecdote. 2
weeks ago I had a session with a colleague of mine who works for
CBA and she had an idea for 10 years to create a it's it's for
the the real estate market but she's not technical and so she
asked me and another colleague to to help her out with with AI
to create this application for her.
What I did instead is show her agentic coding.
How does it work? I set up the the the base for
her like this is how you structure your projects.
Here's how you create a plan and then the first iteration I
instructed the the model to create a a plan from her.
She had a document with functional requirements, which
was quite elaborate. And then the model created a
implementation plan from those functional requirements and then
started implementing them. And within the hour there was an
like a POC application that she could already showcase to a
venture capitalist for for investment, for example.
But then I gave her the rates. I said, now you're going to do
it. She prompted the next bit of
functionality. And then I uttered the words,
you're now a developer. And she, she lit up.
She, she realized she was now she had the efficacy to, to, to
execute on, on her vision. So I think that's that's that's
a great way for her to to to to start.
And now she understands she's, she's still not technical, but
she knows how to structure her project, how to iterate on it,
how to, how to create new versions of her application to
make her vision come true. I don't know if that answered
your question, but it's something I had to think about
when you said that made. Me think of another question
because I know topics like these can be quite controversial for
different audiences, but especially the people that have
gone through education with the software or have years of work
experience under the belt, right?
If you would say she's now a developer, there are many people
that would say actually she's not because she doesn't think
about XY and Z. But I do agree that this build
process, that's the part that gets a lot easier.
So I'm very much wondering then, when do software engineers or
the people that currently are engineers come into play?
Is it when it reaches a certain level of scale?
But the people that are driving, they will never realize that,
OK, this is when you actually need certain foundational
knowledge or expertise. There was a LinkedIn article on
someone that made an app and the app was actually, people had to
upload their pictures and it was kind of a social network app.
And it was completely orchestrated and built in the
way that you exemplified. And there was a security breach
and all the images got leaked and stuff like that.
So that will definitely be concerning.
I feel like I don't have an answer for that yet.
No, we we're usually brought in when the house is on fire,
right? That's when you need real
software. Damage control, Yeah, that's it.
That's the reality. Yeah, no, So I I took the phrase
you're now developer from from Netlifi.
You're probably familiar with it.
That's, that's what you see the first time you deploy an
application to, to Netlifi. You're now developer.
And the idea is to, to, to, to empower people to make them
enthusiastic so they deep dive more.
Of course, to, to write great software, you still need to be a
great engineer. It didn't change.
Yeah. Yeah, thanks so much for coming
on, Dennis. This was a blast.
I love picking your brain on modernisations and just your
general principles on building nowadays.
You're more than welcome. Cool.
We'll round it off here. If you're still listening, let
me know in the comments section what you thought of this episode
and we'll see you on the next one.