This is a followup to my previous post about how I tried Ambient Code.
TL;DR: I opened a PR (#specfile/508) and had to take over in the end.
Claude Code proposed a solid implementation plan to us, Stella (the staff engineer agent) approved it.
…Ambient Code is a platform (not covered here) and a collection of AI coding agents and workflows designed to help with software development. I decided to give it a shot and see how well their agents can analyze and contribute to one of our projects in Packit org. The first tool we are going to use is called agentready. It checks how well a project is maintained and suited for AI-assisted development.…
One of the daily tasks we have when developing AI agents is to review their runs. We have to read dozens of decisions so we can evaluate if the agents did the right thing. If not, we have to adjust our user prompts, system prompts, and tools.
Let’s review how Sonnet 4.5 performs while backporting a complex patch (with multiple conflicts).
…
Over the last two weeks, we’ve spent time guiding our agents to perform more advanced workflows.
It was rough. For several days I was truly frustrated, because the results were atrocious.
…
This is a follow-up to my previous post about Claude Code.
We are building a tool that can backport upstream git-commits into CentOS Stream autonomously using AI coding assistants.
…
I am writing this blog post as Claude Code is working on upsint, a tool we worked on many years back. I haven’t touched upsint’s codebase for some time. It worked just fine all those years but recently I started getting 401 and 403 while creating pull requests, probably due to my API token expiring. I have never implemented any serious error handling in the tool so it was hard to diagnose the issue quickly:
requests.exceptions.RetryError: HTTPSConnectionPool(host='api.github.com',
port=443): Max retries exceeded with url: /repos/packit/ai-workflows/pulls
(Caused by ResponseError('too many 403 error responses'))
Log Detective service is live for more than two weeks now. Running an LLM inference server in production is a challenge.
We started with llama-cpp-python’s server initialy but switched over to llama-cpp server because of its parallel execution feature. I still need to benchmark it to see how much speedup we are getting.
This blog post highlights a few common challenges you might face when operating an inference server.
…In Log Detective, we’re struggling with scalability right now. We are running an LLM serving service in the background using llama-cpp. Since users will interact with it, we need to make sure they’ll get a solid experience and won’t need to wait minutes to get an answer. Or even worse, see nasty errors.
What’s going to happen when 5, 15 or 10000 people try Log Detective service at the same time?
Let’s start the research.
…
In the last blog (Using InstructLab in Log Detective), we went through the installation and set up process for InstructLab. The post finished with knowledge preparation. We’ll continue with that and hopefully end this one with data generated by InstructLab.
We are going to continue in the Log Detective series:
This time we’ll start exploring using InstructLab in the Log Detective infrastructure.
In this first post, we’ll obtain InstructLab and start the exploration. We will use the official RHEL AI container image that got recently released: https://www.redhat.com/en/about/press-releases/red-hat-enterprise-linux-ai-now-generally-available-enterprise-ai-innovation-production
