From DevOps to Hackathon Winner

I'm David Aparicio, senior DevOps at Eudonet in the Wojo office. I did a double degree in INSA de Lyon and also in Brazil at Unicamp.

And last year, my team won the first place at the Dust Quanto AI Adjunct Academy. And tonight, I will share what we built and what I learned.

The Problem: Small Fixes Stuck in the Backlog

we were four guys from different companies and even different nationalities regarding the issue we at the start during almost half hour we didn't have idea how to to make this hackathon regarding agent agentic also so we start

We started discussing about our companies, and we found one issue. It was regarding our backlog. Every company has a big backlog, and it is organized by priorities.

And if it is not a very big picture, very critical, as we are not so many, we started started to tackle only the big feature and the button correction, the typo. It wasn't done by developers because it is not very interesting and we don't have time to work on it.

So it was our idea, sometimes can file the ticket normally, wait for the sprint and as it is already started it will be on the next sprint and the developer have the choice to pick up and we have to to wait sometimes for a minute fix maybe one full sprint so one month and we

An Agent for Quick, Low-Risk Fixes

we think it is a good idea to use adjunct at the start during the hackathon we don't we didn't have MCPs and the cloud code was at the start. We used SONNET 3 .5 so it wasn't the best model for coding but really good for this kind of fix.

So we let no technical user to discuss with our agent and tell what is an issue and the AI will work on this aspect, take some minutes, and open a pull request on GitHub.

So after a human in the loop, the developer will review so we can tackle these quick fixes with the help of Asone 3 .5.

Building the Hackathon Solution

So, it was our proposal for this hackathon to describe in French or in English your problem. It was with Dust.

Why Dust? Because it was one of the organizers, but also because Dust can create agents and can interact with Notion, for example. So everything regarding the code style, regarding the functionalities of your project, regarding some features for example, was in Notion as a knowledge base. And the agent will contact after that our coding agent with a big prompt to perform the fix.

What I learned, it was decided to very don't create a very rocket science application. It was very useful for fixing typo, but also for some very simple feature. And it was what we made in less than one day.

Human Review and Preview Deployments

And as I told you, it is not directly deploying in production. We use GitHub previews, so every time you have a PR, the developer can check, and maybe a non -functional member can check, a PO, a customer support can check if the fix is really really applied.

And as a WhatsApp, it wasn't so big. It was only 100 of prototype team and present it.

Demo Setup and Open Source Code

But today I don't have this. I am not lucky because I think coming in by back maybe I broke my network on my Linux subsystem and I try to use cloud but I think it is totally broken my Nix so I will do the demo with our presentation as for the backup

but all the code is available in github so you can clone and put your anthropic key and play with it.

So let's go to for the demonstration type

Demo: Fixing a Broken Booking Button

pause fixing button that doesn't work that kind of stuff so in this example website there is a book now button that's supposed to bring us to the booking page but if I click on it it will just refresh the page. So it's a bug that will report to the dust agent that we have been building.

So if I go on dust I can call our functional fix agent and for example the external visit pros book now button does not work. I will send that and the dust agent is going to

gather data from our knowledge base which is in Notion that contains all the details about our product and how things are supposed to behave.

We'll see that it's currently thinking.

From Product Knowledge to Pull Request

Once it has the data and the information about the feature, it will call our functional agent, which is an external agent built using HuggingFace, the small agent framework from HuggingFace, and once the agent...

so the agent is going to get the requirement, is going to pull the code base, it's going to write the code, edit the code, and it's going to push the code onto the repository and once everything is done it's going to report back to the test agent in order to inform the user that the deployment is done.

Nowadays we have a faster model.

Verifying the Fix

The code has been pushed and that has been reported to the test agent and so we'll see that there is a push that has just been done, the code has been written by the agent here And we see the changes that bring back the features that were expected.

Once the deployment is done, we can open the website that's sent by the agent, and we can see that the Book Now button now works and brings us back to the bottom of the page instead of reloading.

Architecture and End-to-End Workflow

Here is the architecture. So we have the Dust agent that's going to get the data from Notion. It's going to send the detail and context to our engine, which is using the small agents, which is going to write the code, push it to GitHub, deploy and host the hosting and report back to the user that everything went great.

And we have a bug in production without any engineers involved. Everything is happy about it.

Lessons, Limitations, and Next Steps

So before 2 came, I asked for my agent to fix some issue. For example, it was regarding the privatization. The web page wasn't taking into account, as you can see. So I asked my agent, the EPR was made as myself, and Github said you can use, oh, internet not working. I think today the demo god don't want to have me, but I have already opened.

It is made totally by our agent, so no technical user can let developers tackle a very big feature on the product. And this kind of small things can be handled totally by, for the existing example, it was with Sone 3 .5. so nowadays with Opus we can make better things and other example I don't remember what I change I only add the year so this kind of example of typo can be handled by the agent our limits for this hackathon it was regarding the code

Managing Codebase Context

base because we are giving with small agent all the code so cloud can pick up inside but it is not very because you have to give a very big context it's better to have a tool like code graph or this kind of to very synthesize and help Claude to not take so much context.

Triage Between Automated Fixes and Jira Tickets

But as it was a hackathon, we made this and nowadays what we can add, I think Jeff can be a good solution before to call our agent because Jeff can do the triage. So, maybe if it is a very small fix, let's use our agent. If it is a bigger feature, for example, let's call the Jira MCP and create a ticket. What does the agent understand about the request? And let's fill the Jira ticket. So, it could be a very good idea.

I asked for the waiting list, but it's still closed since today, so I didn't make this feature work. But maybe tomorrow, if I have a Javaccess, I will update the website regarding this. That's it.