Everyone has a coding agent now. Very few teams are measurably faster because of it. The difference is not the tool, it is the scaffolding you put around it, and that is a skill you can learn.
Four hours, half of it hands-on. You leave with a reusable skill you built yourself, and with a clear view of where agents break and what to do about it.
The five principles
The core of the workshop. Each one comes from production work, not from a vendor blog.
Know your role. The agent executes fast, cheaply, and forgets everything between sessions. You are slow, and you remember every way this went wrong before. That asymmetry decides the division of labour: you are the input architect, the agent executes against what you built. The prompt is a small fraction of what shapes the output. Repo layout, docs, tests, tooling and error messages shape far more.
Tame the iteration loop. The stronger your feedback signal, the longer an agent runs without you. Agents write tests extremely quickly and are bad at deciding what to test, so the ranking matters: end to end tests capture intent, checklists are cheap and force completeness, and adversarial review catches what both miss.
Keep the context clear. Three failure modes to design against. Context rot as the window fills. Tunnel vision, where pre-seeding locks the agent onto one solution and it defends its own assumptions while debugging. Dilution, where piling every rule into one instruction file means nothing reads as important. The answer is progressive disclosure: layer knowledge so each level loads only when it is needed.
Engineer for the lack of memory. What the agent cannot see does not exist. Slack threads, wiki pages and things in your head are invisible to it. Move them into the repo as skills, tests, linter rules and type definitions. What you say once is forgotten. What you encode is followed forever.
Iterate on the process. Every failure is two fixes: the bug, and the reason the agent did not catch it. Add the test, the rule or the skill so the next run cannot repeat it. The goal is not working code, it is a system that produces working code reliably.
Together these have a name: harness engineering. Stop optimising prompts, start designing harnesses.
Security, told honestly
The part attendees remember. We start by admitting that the three options on offer today all fail.
| Approach | Problem |
|---|---|
| Permission prompts | Slow and annoying, so you click yes anyway |
| Command sandboxes | Not actually secure, and easy to escape |
| Disable all guardrails | Fast, until it is not |
Then we show why, with a real screenshot from a real session. Approvals are granted per action, but security lives in the combination. Approving “run make” is harmless. Approving “edit the Makefile” is harmless. Approving both, in sequence, is arbitrary code execution.
The risk worth planning for is not a rogue agent. It is good faith plus too much access plus an ordinary mistake: a committed .env file, a typosquatted package, a delete in the wrong directory, malicious content in a cloned repository steering the agent.
What actually helps is unglamorous. Keep agents away from repositories holding production secrets. Do not try new tools on your work laptop. Move toward containerised runtimes as the tooling matures. Above all, review the diff rather than the bash prompts, because the diff is your real security boundary.
For colleagues who do not write code, the safer path is an agent embedded inside an application, where the boundary is the app’s own authentication, authorisation and audit trail rather than a human clicking yes.
What you build
The second half is hands-on and deliberately not a coding exercise.
You take an AI written article and ask an agent to improve it. It hands back smoother slop. Your job is to build a reusable skill that first reviews the text, catching the tells, the empty claims and the outright inventions, and only then rewrites it. At the end you present the structure you built rather than the prose it produced.
It works because the feedback loop is your own judgement, which means no test suite stands between you and the lesson. Developers who prefer something closer to home can take the alternative track and make an agent dockerise an unfamiliar project instead.
We also cover the tooling around all of this: slash commands and skills and how to write them well, sub-agents, git worktrees for parallel work, platform CLI tools so an agent can read issues and open pull requests, and spec driven workflows.
Practical
| Length | Four hours, roughly half hands-on |
| Language | English or Dutch |
| For | Developers and technical staff, any level of AI experience |
| Prerequisites | Bring a laptop. An agent installed beforehand helps but we can sort it on the day |
| Format | Short slide blocks, then you build |
| Delivered by | Frank Dekervel |
| Where | Public editions in Brussels, or in house for your team |
Over 100 people have been through our agentic AI trainings across the developer and executive editions. This one has run six times.
Book a seat
Dates for the next public edition are on the events page.
Running it in house for a whole team usually works better, since the harness you build during the session stays with your codebase. Book a slot to talk it through.