Agentic engineering training at Ravago

On 23 October we spent a full day round the table with a group of developers at Ravago for the agentic engineering kata. Everyone worked on their own laptop, with their own AI assistant. Theory, demos and exercises took turns.

How an agent really works

In the morning we started with the basics: what happens to your question, what the agent actually reads and what that costs. Once you see that, there is a lot you can do yourself to work better with an agent. A few of the tips we shared:

• your prompt: name the goal, the files that matter and what is off limits
• your context: give the agent only what it needs for this task, because more context makes it more expensive and less reliable
• your session: start a new one for every task, because everything in it goes along again with every question
• your model: try a cheaper model on a well-scoped task and check the result

Working with agents

In the afternoon we learned to set up a repository for agents. What an agent needs every time goes into files: short instructions, skills for what you do often and hooks for what must always happen. You commit them, so the whole team works to the same agreements.

Quality gates got a lot of attention. An agent writes code faster than you can read it, so the checking goes to gates it runs itself after every step: tests, a coverage floor and mutation testing. The same checks also run before every merge, so the agent cannot quietly lower the bar. What gets built and when it goes to production, you decide yourself.

Let a machine check what a machine can check.

Loop engineering came up too: the agent shows the bug in a real development environment, pins it down in a test and works until that test passes.

Then we looked at how to get several agents working together: a builder and a critic checking each other's work, or agents working side by side, each in its own worktree.

What this does to our work

We closed with an open conversation about how our work is changing and how we deal with it. If you write less yourself, you read and test more. Management sometimes expects ten times the output, while typing was never the bottleneck. And if you doubt whether you are good enough at this yet: nobody has been doing it for long. You are still the engineer.

The participants keep the repository with the course, so they can go back over everything later. Thanks to Ravago for having us.

Want a day like this for your developers? Take a look at the kata or get in touch.