AI-Driven Code Refactoring: Improving Legacy Codebases Automatically - Jorrik Klijnsma

Yes. Hello. Welcome here at this uh talk

about uh AI coded uh re AIdriven code

refactoring. Um as the last people uh

are still coming in. Um I'm already

guess getting started.

Um

yeah. Hi, I'm uh Yuri Kleinsma.

This is me.

Uh, this is also me. Um, this is me

looking at some nice servers.

This is me playing some saxophone.

Uh, this is me doing very uh looking

into the distance type of shoot. More

me. This is me doing actually AI

research. And this is me next year in

Hollywood. Um, yeah, as you can see, uh,

AI you can do a lot of fun stuff with

with AI. Um, but the real me is here.

So, these are all AI generated pictures

just to get started. Uh, but to know me,

you actually have to uh to be here or

see me or talk with me.

And a part of me that uh that um is

interesting is that I'm from the

Netherlands, so the other side of the

world. It's actually my first time here

in uh in Australia. So, it's really nice

uh nice being here.

I'm planning a little road trip after

this this conference at the Great Ocean

Road. So, um you probably all know that

done that. I'm not sure how that how

that goes here. Um I'm a software

engineer uh front end uh front end

engineer to be specific. Um I work at a

company called Sosteria. We're a

European company with around 60,000

people worldwide working uh working for

Soeria.

And like I said, I did a holiday uh took

a holiday after this conference uh but

also towards this conference. I traveled

from Amsterdam to Melbourne and you uh

fly past uh a bunch of countries also

some beautiful countries and I stopped

in uh in one of those countries to have

a little uh a little holiday and that

country was was Thailand and you will

see more about that uh that in a moment.

Um so enough about me. what we're going

to show what I'm going to show you

today. Um I'm going to do a little bit

of an introduction then I'm going to

talk about different phases of uh

automated code refactoring

using AI

um and then we're going to conclude with

some best practices um and some

conclusion

coming back to the Thailand uh holiday

uh trip. I was there. Um I actually um

was there at the resort and next to the

resort they had this nature uh

reservate. Um and they had some monkey

trail tracks which they called them.

These were tracks that walked past a

cliff and you could just walk there uh

towards the next beach. And this is

called the monkey trail because uh this

trail was um next to a piece of forest

where all kinds of monkeys hang out. And

these monkeys like to come over to the

trail uh annoy tourists, get food out of

their bags and um yeah, that was very

fun to walk on this trail, see some of

these monkeys.

But while I was walking there, I also

noticed something like they they built

this uh track um using bamboo wood, very

durable uh materials,

but these materials are maybe not as as

strong as some other materials that are

less durable. Um the weather can be a

bit of an issue there with storms and

not everyone being as nice to the stairs

uh as they should be. So every once in a

while some of these stairs uh break and

it was the only route uh by foot from

one beach to another. So they fix these

stairs uh quite quite quickly and

because the um amount of bamboo and wood

available. This can be done very easily.

And I was actually walking there. I'm

going to show you a little video clip.

Um what you will see over here, this is

just uh the track is how it goes. On the

left you see a part that actually has

been damaged and they just build a

section around it, just a bypass.

So here you see something uh um that

basically is some kind of refactoring or

going on. So here you see the broken

part of the previous path and they just

build the current path around it.

There was probably done very quickly

because these stairs were damaged and

they needed new stairs. But you can

actually see how they really like build

platforms and just bypass an whole

section. I found that very funny because

this feels very much like some code

where people walked into an issue and

said I can pick up this issue or I can

just go like this uh and solve it in a

different way. And that works for for

some cases. Um but it doesn't always um

work and it doesn't work always in the

long run. Sometimes um when you're using

a project for a longer time or entering

a new project um these type of code

things exist where there's legacy code

things that once made sense or they need

a fix for something and didn't follow up

and this tech depth start building up

and yeah um you might want to refactor

that. This is one example of why you

want to refactor. There are more uh

examples where you say um we are uh

using a system that's going to lose

support soon. So you might want to

refactor uh maybe there are other things

at at play. Uh but I think this is a fun

thing uh to show and to understand why

code refactoring uh can happen and why

you would want it.

um instead of all these bypasses, I

think there's a better way to do that.

And we probably all have seen code where

where you think there's a better way to

do this. Um and that's where we uh can

use AI to refactor that that that piece

of code or maybe even whole code bases.

Um,

I'm going to show you a couple things

about uh about um um refactoring using

AI. Um but I like to say that if you

have any questions, please raise your

hands. You don't have to need to wait

till the end of the presentation. Feel

free to to ask along. Um if you

understand it, I'm happy. Uh so let's go

go for that route. Um, and I think this

is also some kind of cocktail. We're

going to talk about the phases later on.

Um, and you will see that some of these

steps, some of these phases are also

useful, uh, for things you do outside of

code refactoring. They can be useful in

general. So, uh, take what you want from

it. Um, it's not always a code

refactoring that it's going to be useful

for. Um, so yeah, be aware of that as

well.

Um considering um legacy code, there are

some pain points that can be really

buggering uh bothering you. Um things

that are undocumented. Uh variables that

uh go all over your codebase. Um things

that doesn't work as intended. um

patterns that were used for a long time.

Uh but just like we see with the monkey

trail and workarounds that not that can

be manual, not always for the long run.

Um mixed responsibilities are are things

that that can h can exist in legacy

code. Um warnings uh that can be

commented instead of proper solutions.

So fix this later or these type of

things to do. um hard to maintain uh

code without breaking something stuff

you don't want to touch otherwise the

whole thing is going to set on fire um I

think we all know these these kind of

code bases or these kind of projects so

who has never had experienced one of

these pain points in their developer

life

I'm going to put my hand down but yeah I

think most most of the room almost

everyone has has at least uh met one of

these uh these pain points.

Um here's an example uh of a project I

worked on uh a project where which we

got to uh got to uh take over from

another team and this project was built

um as a PC a proof of concept and yeah

what you should do with a proof of

concept if you have made it you wrap it

up throw it in the garbage never touch

it again and just start again uh from

scratch to build it for production. Um

that's how the textbook says you need to

do it in the practice in daily life.

That's not how how it works. Uh so this

project also started as a P. Um then

became a production uh uh project and

these were one of the very clear

examples to me that there was a lot of

legacy uh code happening when I searched

for the exclamation part mark important

in the source uh folder of the project.

It was a few project. There were more

than 250

uh uses of exclamation mark importance.

As a front-end developer, this is

something you don't want to see very

often uh as it is it is most often an

example of a bad practice in in place.

Um

what even happened was they uh had the

scoped to the CSS stell often not there.

So when a component would be loaded, the

CSS for that component would count for

that whole page. So this this resulted

in some some pretty heavy issues that

that we had to to fix. And uh yeah, this

was uh this was a project where we're

not allow allowed to use AI at the

moment. So we had to do that um manually

going over all these important check out

how to solve them. Um,

but these are things I would wish I had

had an AI uh refactor at my disposal.

And actually, um, some of the things I'm

going to show you, um, are a result of

of things at the project. Um, and it was

actually one of the first things I did

using AI when CHP came to uh, uh,

existence uh, like two and a half years

ago or so. Um the first thing I did I

had created a view project website a

personal website to help people with uh

this calca to translate uh an analog

clock to how you would say it out loud.

So uh if you see the handles uh on the

clock what is the text you would say for

that time. Um I made I had made an a few

app of that but an offline app on your

iPhone uh would work also very nice in

situations where you don't have

internet. Um so what I did very early on

one of the first things I did with JPT

was take that code from that few project

and translated that into a working iOS

uh app. It took me a weekend because at

the time coding um was a bit hard using

uh using AI. it gave a lot of errors. Um

but my recent error error rate using

claw 3.7 um or the latest models like it

dropped massively like I rarely get any

adder messages uh with the code it

generates. So you see the improvement of

of AI AI code. Um and this also goes for

the for example the the refactoring

where refactoring now taking that piece

of code from one state to another um

using AI uh can can be so much different

uh than than than it used to be. It was

a very manual process refactoring going

into the code, seeing what needs to be

done and then just uh applying those

those things you figure out um to the

code to change it to the new one. Um

this results in uh a 90% drop of uh time

you spend on refactoring code. It can be

really that efficient.

uh and we were going to see some of that

that later on today.

Um so this is about um the introduction

of of AI uh refactoring and I me already

mentioned a couple times the uh four

phases of of refactoring and I'm going

to share uh them with you. These are

phases of refactoring that I turned into

uh AI steps and we're going to go over

them a little bit more into detail.

So phase one of refactoring code is to

gather some insights. You want to know

what for code base you're dealing with.

You want to know what for components,

what is the whole landscape of of of of

the thing you want to uh refactor.

And in phase one, we are we are looking

into that understanding the code before

we're going to change it.

In phase two, we're still not

refactoring or changing anything. We are

preparing preparing this the change

itself. So for the change to happen, um

we have had the insights, but now we

want to make sure the change will go as

smoothly as possible. uh mainly using

all kinds of of testing uh um tools and

uh make sure that that we have a strong

foundation a strong idea a strong uh um

plan to to make the change happen.

Then we go into actual transform phase

where we making the changes to the to

the code to the components to everything

to switch it from the old state to the

new state and see um and see the change

of the the actual refactor happening.

And then we have phase four where we

just uh have have a check have a look go

live um make use of feature flags all

these kind of things and verify if the

change happened as or the refactor

happened as we would like it to happen.

Now we're going to look into these

phases uh separately a little bit more

into detail. Phase one was the gathering

inside phase.

And here we're dealing with a sometimes

with a kind of a blackbox problem. When

you receive a code base or a component

you need to refactor,

um

you first need to understand the

project. And this can be a new project.

you're lucky if you're already for a

long time in this codebase because then

you probably already know a lot of it um

of the codebase know where where to look

at but if you're going to use AI AI

doesn't know your code base yet so AI

still for AI your codebase is still

black black box um but it can be for you

as well depends on your situation

to um to deal with that we need to

figure out what this code base is all

about you have different approaches that

that people um are common with or um

people use. These are for example line

by line reading just going over the code

uh documentation review see if there's

some documentation. Uh luckily you are

that's not always the case. Um maybe map

out some functions. Um add some

debugging steps to see how the code

behaves at certain levels. um use some

analysis tools to see what's going on.

Uh for example, code coverage. Uh all

these kind of things uh where we check

how much of the of the code is is

actually covered in the test. But also

um see how much uh relations are between

functions. Are we dealing for example

with functions that uh are exported in

the file? So can be imported elsewhere

but never used elsewhere. all these kind

of of analysis

we can we can do um and also make some

architectural diagrams or have them

these are all approaches that that you

need to take uh to get insights into

into the codebase

um and manually they they can lost cost

a lot of time especially if they are not

there. So if these uh these uh things

are not available for example the

architecture diagram if the project

doesn't have it or the codebase then

yeah might be it might take some time to

to to make that

um

I'm going to show you a little uh demo

today.

So

I've created

um a little application

as an example which we're going to um

use to

showcase the refactoring.

Close this. Um

here we have it.

Yes, we are using this uh this example

uh application.

It's a demo application. Um it's a trail

body. You can uh see uh which trails

there are, how the trails are going, uh

some more information on the on the

trails itself, some details. Um, we have

some uh dangerous tracks which we want

to know about uh why they're dangerous

and just some information on these

tracks.

If we're going to have a look at the

code base,

it is this um let me zoom in a bit.

This is how you would go to uh see how

this how this how a code base would look

and check um how does it work to get an

understanding of this this code base we

see it's an uh it's a project using vit

uh react till wind so these are things

we we now know the project users as

dependencies

um we see here stuff going on in the app

There's already some drill profider. Uh

we're dealing with some uh styling uh a

drill status. Okay. Seeing things going

on. The trail status seems to be part of

the main screen. I already see like

clicking through can be hard to to

process, see what's going on. Um and to

go over a whole codebase. This is very

small code base. It only has a couple uh

components.

But if you need to do this for a whole

code base, this can be very uh very

exhausting.

So instead of clicking around and

showing you where everything is, what

it's using, uh what does this drill

detail uh component do, we can um we can

use AI to uh

to um take some of that uh that out of

our hands. So using AI as a code archae

archaeologist to really dive into the

code base see how the code is structured

and deal with it. Um we're going to have

some analysis workflow. This workflow

exists on a uh on a couple of steps. The

first step is to get some metadata from

the project.

The next step would be uh to map out

some of the structure of the project to

understand um how the project is is

built.

Then do some file analysis for some

files. You want to have a little bit

more information. Uh for example, a

component. You want to know what's in

the component and what the component

does. And we also might want to

summarize the whole code base in a neat

overview.

going over these steps. Step one, get

some project metadata.

Um

here what you see is this. This is the

project we are using that monkey trail

project. Um here I've created a little

script and this is just a script that uh

takes uh some uh different uh project

types and it it detects it detects the

type of project and you can extend that.

Uh but I want the meta data from the

project and for a react project we are

uh going to need the um um the

package.json.

So as an input, I have the folder where

I'm hosting the project. Um, let's go to

that

there.

So,

so I'm going to run this script. Let me

remove the output file.

And the script just uh analyzes some

data. It's just regular scripting. No AI

AI happening. It just looks at different

uh files, checks what type of project it

is. Uh in this case, it finds it to be a

TypeScript project um with a

package.json and it can get some

information from the package.json.

For example, it gets the name of the

project

um some uh tools that that are being

used. It detects what uh what type of

React version that can be used later.

And it also lists some first level

directories in the source uh folder

because these are al can also be

relevant

um and just have some summary of of what

the script uh um found and when the

script was run. So with the script we

already got some first um uh steps out

of the way um to see that project uh

metadata. Next up is the project

structure and I'm going to show you that

as well. Remove this. What we here what

we do is we have the input again. Sorry.

Um

and what we do with input again is just

just the folder name. We take that file

uh we generate all the parts of the

components that are relevant for this

type of of project.

So in this case we are dealing with the

um with the react project and we are

having um to check all the files that

are relevant for example typescript

files, component files, JSON files and

we just want to list those as as uh um

like what we got from the from the uh

from scanning the the the project. This

all again just uh regular scripting, no

AI going on. Um but these are steps to

gather information on the project which

we can feed to uh to the AI.

So I'm going to run this this uh

this script. Now what this script does

like I said it outputs the project

structure uh in a readable format. So it

shows for every uh TypeScript file,

every JSON file and every uh TSX file.

Those are the components um

where they are in in the project and it

just walks uh um traverses through the

project, see which of the file types uh

which of the files it finds and if they

match the file type for the project.

um and then just adds them to this to

this uh yeah meta uh or this uh um

project structure analysis.

Now we have those two things. So we know

what kind of project we're dealing with

on a high level. Uh what what

dependencies we have to deal with and

also what kind of uh uh um files we are

dealing with

to make it a little bit easier for the

AI instead of needing to uh to parse all

these uh interesting uh um folder

structure uh um formatting. We also used

an um exported directly an output an

output with all the same files but as a

path so that's easier to handle for the

for the next step.

Next step is the analysis step. Um we're

going to analyze every file that we

found in the previous step. This is all

just gathering information to know what

project we're dealing with and to to

give that as a as um as context to to

the AI.

So let's remove the analysis folder.

We have an analysis file script. What

that does,

it takes uh information from the input.

That is the analysis we did in step one

with the meta data. In step two, we

figured out all the files that are

relevant for this for this project

by their uh by their file type and we

put that inside of this uh of this

script. What the script does, it has

different prompts for each file uh to to

get some information of that file. And

this prompt contains um a placeholder

where the content of the file gets um

gets put in and then it's it's using

that to make some some small analysis

and we're going to have a look at that.

Then for every file in that input file,

uh it's going to run uh that prompt and

um check what it's found uh what the

file looks like and just write down some

some basic analysis in a short format.

So we can feed that later on to the AI

for the relevant uh for the relevant

prompts that we're going to use.

Again, this is just just a script that

loops. The AI magic is happening here.

Let's take an example. This is the

prompt being used to analyze a tsx file.

Um, it would check the file. It would

get the file path from the uh gets

filled in in the script. Um, I want to

know some information about this uh this

component. I want to know where uh for

what it's used, what it returns, what

are the input options, all these kind of

things. And I'm then also uh using the

placeholder to to share the file files

content. And it's going to do that for

every um file type uh I define here. And

the script is just going to over that um

that input list and do that for every

file. For this I uh used a local um uh a

local um AI using Olama. I'm running

quen 3.

Um, now when I run this analyze file

script, it's going to go over every file

and run the prompt for that file.

this one.

And this is going to take a little bit

because I'm also hosting the

presentation,

but it's now talking with Ola in the

background. It's giving uh it the

prompt, for example, for the CSS.

It's going to place the file content in

there, and then it's going to return

something. You already see we got the

package.json JSON an analysis back.

So what we see here they returned some

uh information

it says the file purpose uh for the uh

package.json

it shares some uh configuration file and

if we match this to the prompt for uh an

analyzing a JSON file we see we want the

file purpose. We want to see what type

of file it is because it can be a

package uh file. It can be data. It can

be a config file. So we want to know

what's going on. If it has data, we want

to know this about the data. And if it's

another type of file, we want to know

this. So now looking at this

package.json,

I'm seeing it it the AI extracted some

uh information.

Not sure how why it

picked a number 10.

Maybe because I talked about the 10

lines. Um,

but you see here it's uh just

figuring out

what this uh what this file does, this

package.json

uh what's in there uh just relevant uh

information. It also does that for for

example tsx files. the components.

Here is that com the component analyzer

prompt.

Again, we put the code from uh this

specific

uh uh component in this prompt, send it

to the lama and um then it explains to

me what is the component about, what

input outputs it has and that results in

a nice detailed overview.

And now if I'm

displaying that here, this is way more

readable and concise than every time

sending over that component uh and all

the code to the AI to the AI. Um but if

you need uh for example have reference

to other files uh when refactoring one

component, you might want to add these

files with a more concise uh text and

more summary instead of adding all these

components with the whole uh code. So

this is just to to get the information

for every part of of the codebase to use

later on.

I think it's still running. We're going

to let it run. Um, and it does that for

for for every file that that that I've

I've given it. This is a nice way to to

get that uh get that information.

Now, using that information, we can also

um build like a um a final codebase

summary.

And we can do that for example using the

meta data from step one um the file

structure the file analysis and then we

can build a whole um analysis of the

whole uh project. To do that I'm going

to use a different AI because my lo

local doesn't have enough uh context to

um

to do that at once. So here I'm using in

this case Gemini

uh let temperature stand. Okay. So

here I'm putting in the prompt and now I

just need to replace this. This can all

be manual uh or this can all be

automated but for the demo purposes I

will be showing it how how what the

steps do. Um, so I'm taking this project

metadata from step one. Going back to

step one, that was this this

information.

I'm going to find here the project

metadata and pasting that over there.

Now I'm going to the project structure

again. That was this file. Replacing

that over there.

And I'm going to paste in here some of

these uh um analysis files. Let's do the

package JSON.

Let's do

this one.

Yeah. And

this one.

Couple more

just to give it a nice overview.

So now when we run this um

when we run this uh prompt it will start

analyze the whole codebase uh based on

the information you provide here. It

makes a nice documentation of that whole

codebase.

Also going to let this run for a while.

Um and this is the last step of that

first first phase. So here we got the

information from the codebase. We um

brought it down to different files that

we can use later on.

This example available somewhere on

GitHub.

Um it is in a private repo at the

moment. I can I can make it public but

then I need to structure it with a bit

with the with the prompts but I think

that uh um I can send it over um for

example window in the slack with the of

this room.

So here you see it um it generated um

application overview showing me what it

what the project is about. Um, and this

is some documentation that otherwise

took me maybe hours to write or to come

up with. And uh, we just did it with

some prompts in a couple of minutes.

Um,

and you see how this um, already shows

way more information that I would be

able to get in the same time clicking

around in that codebase. This actually

also very helpful information

um for the process of of refactoring

because this is context we know we need

to know when we want to refactor some

components or whole code bases you want

to know um patterns used we want to know

what components there are for example if

we are going to refactor a component and

it's referencing other components you

want to be able to know uh how to how to

approach those how to implement those.

So here we have a nice nice overview

going back. So um we are going to

refactor one of the components

and we're going to refactor the trail

list component. This component has some

issues. Uh has some poor TypeScript

usage. Um some uh class component versus

functional component is different than

the rest of the codebase. Um and I'm

going to use this component as an

example to refactor using the uh using

AI prompting.

Um I'm going to do that uh prepare that

in the next phase. So this next phase I

already said is about building um like

the road to the refactor. Uh what needs

to be done? How can we validate that the

refactor has been successful? Um how can

we make sure nothing breaks along the

way? Um and that's why we need to uh

write some tests first. Um because tests

are going to be your um steering wheel.

Know what's going on. see where things

break because with refactoring almost

every time you want to keep the same

functionality because it's not the

functionality that needs to be

refactored but your code that is like we

saw at the beginning. So we want to make

sure we kind of set in stone how how the

project or the part of the project now

works and then we can uh change it and

then we can keep seeing if it still

works in the same way.

Um this is also where you have to deal

with maybe stakeholders because

stakeholders like a test like metrics

from test. Um and yeah an example is how

test coverage it can be very useful but

also can give wrong images wrong uh ID.

So I think it's very um appropriate to

choose which test do we are we're going

to use. How do we make sure that we are

keeping the same uh um functionality um

and not testing to just uh be testing.

some um uh traditional um um testing

approaches um are end to end tests, unit

tests um and these are different for

each each project. But we're going to

also see in the prompts how we are um

using the libraries for that project.

Um um for AI testing, we want to see how

the component behaves. We done that in

the first step. want to identify test

scenarios to see what do we need for

this component to to be tested but also

edge cases maybe want to have

performance in there performance tests.

Then we want to generate a test plan to

see what do we need to do uh which tests

and which ways to uh we need to write

the test and then actually create the

test code uh to be able to run it uh for

the next steps.

I'm going to show you a bit about that

as well.

Yes. So, here we go.

Um,

we are going from phase one to phase

two.

Um, here I have a couple of different uh

prompts. Let's first start with the test

plan generation prompt. This is a prompt

that again takes some information from

the uh from the previous uh uh steps,

previous phase. Uh we add it in here and

then it creates a whole test plan and we

want different things for it to to show

uh to write edge cases uh to write

different tests

um and just be complete in in in what

you need for this. You also see um I

have some refactoring uh requirements

and herefore um I have an example. This

can be uh short des shorter description

on what do we need to be the standards

for the new uh for the new state. And

it's just a list, just a file with

information on on um what implementation

uh we would like the the the new code to

have. So I'm going to use that test plan

prompt.

Um I'm going to give it all the

information that that we just uh

gathered.

Can I clean this?

Let's start a new chat.

Okay, so like I said, we're going to use

that list component.

this one, this has some issues and I

wanted to um identify that but to make

sure that we uh have a well working

component at the end uh we first want to

get those those test results. So, I'm

pasting the the information here.

Then I'm going to give it um

the um the requirements for this uh for

this file, which are these react

requirements.

And this can be different for each each

project. It depends on which project

you're working on.

And I'm going to give it couple of um

relevant

um lost my placeholder.

Here it is. Want to give it some of

these relevant sections from from uh

phase one.

Um what it's going to be is in this case

I'm going to give it the trail context

and the trail type because that is it's

reference those two files. So I want

those files to to uh be part of the

prompt I'm uh I'm providing

the trail and the trail context.

This is the information that we got from

the trail context.

and the information we got from

the trial type

types

like this. So now I'm going to give it

this information and start uh I'm

running the prompt and it's will analyze

um the things that I fed to it and it

will come up with a testing strategy of

how we can test this this component.

And this is an example of um something

that's can be more useful than only

refactoring because this you can already

do on new components or uh components

that don't have tests but don't need

refactoring per se.

Do you generate before?

Yeah. So good question. The question

here was do you generate a test before

you refactor? Um I would say yes. Um

definitely because um you want to also

validate to the current way of working.

Um because very often with these code

refactors you want to have the end

result stay the same. So um if it works

if the tests succeed in the in the

current result you want them to uh also

succeed in the end result.

If you make them up front, you can uh

can keep that consistent consistency.

So this is a very um elaborate testing

plan with all kinds of information.

Um it made it made the analysis what

functionality to test. It wrote the test

cases.

Um um this is very detailed overview for

the component that we're uh that we're

dealing with.

So all this information

um

can be put inside your uh codebase of

course um I think it goes for itself but

it's important to always check these

codes uh don't just copy paste it and

use that in uh definitely not in

production websites uh if you're vip

coding for hobby projects

Um if your credit card is large enough

then uh be feel free to do so but it's

very good to understand what the code is

doing um so you don't so you don't end

up with um with the code do weird things

or have have leaks in there or

something.

Also this maybe also goes without saying

but giving it AI giving AIS these kind

of information it depends on the

situation if you're able to do so. um an

and a way um like writing these test

plans can also be with anonymized uh

information or you're just filling in I

have a component that does this and this

and this uh I want to write a test plan

a test schedule how would I approach

this it also goes for the next one um

these are things that that where you

don't need the actual code to send over

to the AI and it is also able to

generate just the structure or the ids

which you then code yourself. So that's

a level higher where you might be able

to use AI uh to to get a bit faster

instead of using the actual AI code.

So this is the test uh test uh result

that came up with the test plan but with

testing alone um we don't come very far.

So we also have the refactor plan and

this refactor plan uh it plans out what

needs to be refactored. It identifies um

the weaknesses of the component. What

does it need to uh what does it need to

what standards does it need to mean uh

meet

and I'm going to build the same uh f uh

of same same type of f. So here um using

somewhat of the same structure

um again going to

step one.

Let's start with the requirements.

over here. Let's pick a short one.

Please

copy.

Yes.

Um over here again those two files those

were the the trill

with the types I'm giving it that

information and I'm going to give it the

thrill context information

would be nice if you

actually

work alone. Yes.

And then we're going to paste the

component itself again. And that was the

list.

Um this is the part where it creates the

whole plan, the whole um idea of what

needs to be refactored on the on this

component to meet the new standards.

What do we need to change? And um it

analyzes that.

This uh prompt just uh takes all these

output steps you wanted to have. So a

step-by-step plan, new structure,

um code that we might want to uh send to

a new file or have in a new file. Um the

dependencies the refactor component will

have if there are new type definitions,

um maybe challenges for the refactoring

that's going on. And you already see

even if you're not allowed to use AI in

your project um to generate code maybe

this is an option to get this

information automated uh from an AI uh

run it on your codebase see how we can

um change these files or parts of these

uh parts of these files.

Um

let's see what what it came up with.

So here we see um it approaches like we

want uh from a class component to

functional component. Uh we're going to

change how we use the um use the states

of React the the hooks. Um maybe want

some uh function logic uh extracted. Um,

and here you see a whole detailed list

of how we want to refactor this uh this

code and a step-by-step plan on what to

do, how to execute it. Um, and this

would already like if you have this and

then do it manually and make these

changes that already would help you very

very much on refactoring such a comp

component and not looking into this for

every component again.

So here you see how how the new

structure would look like. Uh this is

the uh um refactored uh uh component.

Um

it adds some new uh uh utils to the uh

to the uh util file. Uh also want to uh

uh add some ex types to the to the to

the type uh definition.

Um

so this whole plan is very uh extensive,

very elaborate and uh very useful in

into uh into refactoring uh such such uh

components.

Again, if you need to write this

yourself, identify all these things uh

it's going to take some time.

Okay. So with uh phase two what we did

we built the safety net um these these

test approaches. How do we want this uh

this test to be? What do we want tested?

Um we wanted to set some uh boundaries.

What does it need to meet the new

standards, the new criteria? we

documented some of the uh behavior in

these uh in these uh doc in these

analysis.

Um this is also a part where we could

have had performance benchmarks um to

say we want to meet this this standard

of uh of performance

um which I skipped now for for time

reasons. Um now we're going actually to

the transform transform phase where we

actually start to to um to change the uh

the component itself and do the

refactoring.

So again here I have an um a prompt that

I'm going to feed with with some data.

We're going to move to step uh phase

three. Um here we're going to use the um

actually the code itself

um to refactor that. So here again I'm

using this prompt. What the prompt does

is it's going to use original uh

component code refactoring plan again

relevant struct component structures

um related descriptions of these of

these related files and the requirements

we want uh we want the code to have. Now

I hope

I did not override my

Okay

then. Um.

Nope.

I should have copy pasted the previous

output.

Let's see how um I'm going to fix that.

So again I'm giving it the requirements

to copy paste.

Somehow my keyboard is acting weird. Um

I'm going to skip the refactoring plan

for now.

Of

course, you want you want to give it

that refactory plan, but I think for

such a minimal component, it would work

without.

So let's see how it um how it how it um

how it does without the more detailed

plan. So this prompt um like I said took

all the information we we generated and

then it just going to execute it um re

refactor that code you're going to you

give it.

And here you see

um it already started to extract extract

some of these utils that it talked about

in the um in the previous uh uh phase.

Um although we did not provide it. Um it

was smart enough to see it on the

component. We need to to extract this.

Um

here we got the component itself

refactored. um added some documentation

to it or like inline comments. Um

this this would need a lot of reading

through because you want to make sure

that what happens is uh is is what you

want it to do. Um but at a first glance

it it it it looks like it did a it did a

good job. It did some of the things we

we asked it to do. It explained the

decisions. I add it to the prompt to

make sure that you that it uh thinks

about it, that it explains what it does,

so you can more easily check if it uh if

it does what you what you want it to do.

Um

and all this information. So

going from phase one to two to three uh

took us around half an hour and we're

already at a point where um you would

maybe take a day if you would uh need to

do this this manually. Um the last phase

is a phase to um um uh to yeah validate

um see if there are still bugs in your

code. So run your tests. Um maybe add

some feature flags. Um do some manual

review, do the perform performance

benchmarks if you have them, uh if

they're relevant for your for your

project. Uh maybe do some official

regression tests. Does it actually stay

and look the same on on your uh uh web

app? Um

um maybe have a deployment plan or just

follow your regular uh release uh

release structure.

Um

yeah, let's go very quickly on some of

the best practices um um with this AI

code refactoring. Um AI can work on

every project. Uh but currently I don't

think AI should be allowed to work on

every project. So be really aware uh

that you're adding AI to your project or

that you're using AI. Does it um fit the

project? If we're dealing with user data

or with sensitive data, be aware of

that.

Um, do some input validation on on your

uh test your prompts. See if the things

that you put into it are um things you

wanted to have. Um, add some error

handling. So, in your scripts, add parts

where where it allows you to see what's

going on, what messages are being sent

to the AI. um check dependencies that

are changed. So if it comes up with new

dependencies, make sure they are uh they

are useful but also they are valid

dependencies uh and meet the standards

that that your project requires.

Start small. I think it's nice to to get

used to this to um use it on smaller

personal projects maybe internal tools

just to get known how to uh use this

this this these approaches of of

refactoring using AI. It can help you

also understand it but also maybe

revisit that old project of 10 or 15

years ago that that you uh did.

Um I think that was I wanted to uh to

tell you about AI code refactoring.

um already got some questions. I also

see it's time. So, uh if you still have

some questions, I will be here or there

at the uh break we now have. So, thank

you very much.