your app's infrastructure should fix itself.

So, right now I'm on the Rayway dashboard and I have a bunch of services that are deployed and all of these services have one thing in common.

They all have bugs and problems.

So, for example, this service has a memory leak.

If I click on it, go to metrics, we can just see memoryization keeps growing high and very quickly.

This is just a sign of a memory leak and pretty sure the service would eventually crash.

If I look over at the amount of requests, we have a high number of 500s.

So, the server is failing to respond. We have a high request error rate of 94%.

And we also have an extremely high response time of like multiple seconds uh for like the service to respond, which is not ideal.

Like if this was a service running in production, everything would be on fire. You'd be getting paged and you just try to bring back the service up back quickly.

But the thing is not all problems are this obvious.

For example, this service all it does just queries a postcrist database.

And if we go to metrics, we'll just see that well CPU utilization seems fine. Memory usage is also fine.

Sure, it's a bit spiky, but okay, whatever.

We have some fails, but okay, nothing too alarming.

request error rate is somewhat high. So that also should make us kind of like want to investigate, but the response time is extremely high.

The thing is this is because the service makes queries that are super slow.

And the thing is if you're an end user that's trying to use this experience, you would just suffer.

You would need like 30 seconds for like a page to load, which would be a nightmare.

So the thing is when you deploy your app to production maybe some you know bugs or issues make their way to production things happen.

and kind of like the typical way of dealing with these things is maybe you set up a bunch of thresholds and when these thresholds are met for let's say CPU or memoryization maybe uh you want to have a threshold for the request error rate it shouldn't exceed a certain amount well what will happen is You're going to get alerted and you'll be aware that there is an issue.

but you still have to do the investigation yourself.

You have to dig through logs, metrics, and traces to try to paint a picture in your head and try to piece things together so that you can ship a fix.

Now, what I'm proposing is you should have a coding agent that monitors the state of your project and your application's infrastructure.

And if any issue is detected, so you know any of the thresholds we define are met, we should just have a fix shipped, right?

So like instead of, you know, getting the alert and investigating, you just review a pull request and you're like, uh, looks good to me.

You ship it and then everything is good and crisis averted.

So today I'm going to show you what I have in terms of demo that kind of paints a picture of how this could be achieved.

So at a high level I want to have a series of workflows that will kick in that will help me go from issue detected in on railway my deployment provider to a pull request being open in my GitHub repo.

And this is what I have in mind.

Uh the first workflow that I want to have is a workflow that runs on a schedule.

So let's say it runs every 10 minutes, 15 minutes, 30 minutes.

And what this workflow will do is one, it should fetch the application's architecture.

We should have an understanding of what services are deployed, which you know like frontends, backends, crons, cues are live in my project.

And I then want to fetch each services resource metrics, so CPU and memory utilization.

And I also want to fetch each services HTTP metrics. I want to see the request error rate, the number of failed requests for, you know, 500 400 errors.

And once that's done, I will want to then see which services have exceeded which thresholds.

And then I just want to return a list of the affected services.

So this would be essentially the goal.

Now you might be wondering, well, why not make this an alertbased system?

So maybe we configure something like web hooks for alerts and then that would kick off uh essentially this workflow instead.

I would argue that it's probably better to be able to analyze a slice of time rather than just having a threshold being met because it can get pretty noisy.

Like imagine you have a spiky workload uh and you know you reach the 80% resource utilization for like your CPU but things are still fine.

and that's not like in my mind this is enough to be investigate but it might not like it might mean that there just aren't issues when we try to look at like the bigger picture and all the details.

Now once we have this list of impact that is impact services we essentially want to pull in even more context for them.

So like at a high level we want to see project health all the services is everything operating as expected.

Oh we have this thing that we're suspicious about.

Let's actually pull all of you know additional context for the service because imagine again you have like high resource utilization.

Maybe you're just successful. You have high usage.

Uh but then when you pull the logs it's like oh everything seems fine. there aren't any errors.

Well, you're good.

And you can imagine that we can even pull even more context.

Like imagine maybe we scan the code in the repo and based on that we infer the upstream providers that the repo relies on.

and then we can automatically check the status pages of these services.

Imagine like a payment processor goes down. Well, that's kind of how you can know and then the coding agent will be able to maybe tell you like, hey, you should just like wait out this issue.

And once we have all this information, we can just write a detail plan.

So like we can look at, oh, we have a high number of 500 requests. We see that we have very high resource utilization for memory.

and we see that we have you know um just errors specifying that a specific endpoint is failing.

Well, this is enough information that we can write a detailed plan of hey this is my application's architecture. These are the affected services.

We just then give this plan to an agent and then the agent will just follow the process of hey let me clone this repo. I'll just create a to-do list based on the plan you gave me. I'll implement all the fixes and I'll just create a pull request.

And this is kind of how we go from issue detected to an open pull request.

So let's actually see this in practice.

So because we have the idea of workflows, what I want to do is actually use what is known as durable execution.

So the idea of durable workflows has been around for a while and it's really one of my favorite abstractions because it can help you simplify complex logic while making it more reliable.

So for example here we have this workflow.

So this actually is ingest but there are lots of solutions out there that pretty much do the same thing.

and we have this function that you know called process video upload.

It listens on an event of video uploaded and we essentially want to do three things.

We first want to generate a transcript and we do this by making an API call to a third party API.

Once we get that transcript, we want to generate a summary by also making a request to an LLM provider.

And once we have the transcript and the summary, we want to store them in the database.

The thing is all of these steps, they are not 100% guaranteed to work. Uh they are prone to failure.

And what's neat about this pattern is by default, these steps will be automatically retried. You don't even have to think about it.

But if you let's say want to modify this behavior, maybe you want the retry to happen uh like on a certain schedule like you know exponential back off uh maybe you want to define another thing that should happen in the case of failure you'll be able to do it.

But what's neat is each step when it succeeds uh the result is cached.

So if for example we are able to transcribe the video correctly, we summarize the transcript correctly, but we failed to write to the database.

If we were to retry this workflow, we just continue where we left off.

Uh we don't we won't really repeat any work, which is one awesome because it's faster, but also it's more cost effective.

So at a high level, this is the thing that I'll be relying on in my code because I'll be making API calls to the railway API to be able to fetch the project architecture, all the resource metrics um as well as you know the HTTP metrics and whatnot.

So yeah, uh this is kind of like the first thing that um we need to talk about.

The second thing is the coding agent.

And for the coding agent, I'll be using Open Code. Open code is an AI agent that's built for the terminal.

You can think of it as an alternative to something like cloud code, but the main difference is open code is fully open source and you can choose any LLM provider or uh you know model that you like, which is pretty nice.

Uh you have this nice terminal UI, but honestly what's so cool about the project is how it's architected.

So if you go to their docs, they actually have a server implementation.

you can have a a a headless server that runs that exposes an API for you to essentially interact with an agent.

So the way it works is when you run the command open code, which is what starts up the agent in your terminal, it doesn't just run a single app.

It actually starts a terminal UI and a server.

And because the terminal UI here is the client, we can essentially bring our own client and talk to the server, which is awesome.

uh because now we can run open code on a server in this case would be on railway and we can just have this server have all the tools that the agent would need.

So we'd install all of the necessary you know tools we can configure git and then the agent will be able to open pull requests and you know go through the file system and do everything.

Let me show you what how easy it is to essentially have this deployed on right away.

So if you go to the code uh here right now this is my project it's called railway autofix I know great name uh I have essentially two directories one is for my API the other one is for open code.

I have essentially two directories one is for my API the other one is for open code.

and open code really we just have a single server running using bun and all we're doing is we're just calling a function uh that is called create open code server.

so if I actually stop this here you can see it runs on port 4000 9496 and this is pretty much all we need.

and I have a docker file and in this docker file we're essentially defining that environment.

So, we're installing a bunch of tools.

You can see we're installing curl, jq, bash, all the other tools, even git.

Uh, we're installing the GitHub CLI, which is what will allow us to open pull requests against a given repo.

We're then installing open code in the environment.

We're configuring git and at the end, we're just exposing the port and we're just authenticating the GitHub CLI, which is pretty neat.

Uh, by the way, the code will be linked somewhere down below.

But that's really it for open code.

And when it comes to the actual API, let me actually run it.

So now the this is the open code server that's running.

And if I go here, I have my actual API running on localhost 3000.

And I have a UI that is provided by ingest, which is very useful for debugging.

So if I go here and I go to functions, essentially each function here is a workflow and it has a bunch of steps.

So let's actually try to run it to see what happens.

Um now in production when this is live this monitor project health workflow should run on a schedule and if an issue is detected we will call the pool service context and then pull service context will call the workflow for generating a fix.

So if we actually just kick things off this is how the flow of things will happen.

So if I actually have now I have this function run.

We called moderate project health. Then we called pull service context and now we're actually calling generate fix because we detected an issue.

and we're just setting um like the railway specific variables as environment variables.

And all of these are actually available uh on railway. They're just set automatically which is pretty neat.

So if I actually go to monitor project health you'll see we have a bunch of steps.

Uh the first one is getting the project architecture and this step right here this is we can actually see its output.

So we can see all of the databases that I have in my project. I just have one.

Uh we can see also a list of all the services as well as their configuration.

We can see which like where's the repo for them and we just now have a highle overview of our applications infrastructure.

Uh we also see that we have any kind of like volumes that are there which is cool.

And then we have a series of steps that are actually running in parallel.

So like you know things are efficient.

So we're getting the database resources.

We can see on average well what's the max CPU?

Uh and it's like 0.9 CPU.

Okay.

Same thing for memory.

And we actually have a summary.

And this summary essentially is us formatting these results so that we can then pass it to the coding agent.

So you can see CPU usage average 0.93 vcpu and you know this is the max and memory usage as well.

Now this is actually high uh and we'll be able to kind of understand that because it's like oh memory usage here is 31.96 GB out of a max which is 32 gigs.

Uh and then we just pull even more um like resources.

So like because we have multiple services we will call each step for it. Right?

So like we will pull the HTTP metrics for each of the three services that we have deployed for example.

But also for this one for the HTTP metrics we can see the error rate percentage for 400s for 500s.

We see like the latency um and we just have like a status count.

So we can also have a summary and then we can say hey these this is the rate of um like request error rates. This these are the latencies.

and this way when we actually at the end of like this workflow so I go to runs go here again towards the end we will actually give this uh pull service context function just all of this information in a nicely formatted way.

So if I actually go now to this function run, we will see here that we're fetching the HTTP logs, the build logs, the deployment logs for like all the services that are affected.

And we can see here like this is the function payload.

Uh so this is the stuff that we passed from the other function.

And we can see we just have all this info.

We also have an architecture summary.

So this actually we can expand this.

Uh the architecture summary is just a nicely formatted uh text saying like this is the project architecture.

We have three services we are running in the production environment.

We have one database.

We have all these volumes and we just have all of this information.

It's just harder to read cuz like in one line but for the um coding agent we'll just give it to it as like markdown.

So now that we have that go to runs again.

Now that we have that, we are just going to make a call to another workflow which is generate fix.

And for this one, what it does is one, it will analyze with AI.

So this is the actual output in terms of like the input. It's a bit large to render here.

Uh but we analyze it with AI.

So like you can imagine we give a large language model saying like hey this is my project architecture. This is the data. This is how things are performing.

And then we take all of this information and now we actually come up with a plan.

So you can see here debugging steps.

We want to see reproduce locally with the same load.

Maybe we want to run it.

We want to see what will happen if we see that the agent is like oh I ran into an error.

Then it's going to fix it.

And then we have like recommendations.

So like this is the plan that we'll then just pass to our coding agent.

And then we have a step to create a session.

So on the coding agent you can imagine each session being its own chat.

So this will run like imagine you have multiple repos each repo will have its own session.

The coding agent will work and then at the end it should you know if as expected it should open a pull request.

So yeah that's pretty much it.

This is how it works.

Now if everything works as expected we should see a pull request on the project.

And here we go. We have a pull request that is open with all of our changes.

If we go to the conversation, we actually be able to see that we have a summary of all the changes, uh, an analysis summary, the root causes, what was fixed.

So, we should be able to just review this.

If everything looks good, we merge and we're good to go.

And that's it.

I hope you enjoyed this talk as much as I enjoyed making it.

If you have any questions, feel free to reach out to me on X or Twitter.

This is where I mostly hang out.

Also, the repo for this project will be available somewhere down below.

So, make sure to check it out.

And with that, thank you so much for watching and I'll see you in the next