Agentic Engineering Workshop

Every engineer on your team uses AI differently.

One engineer writes every line by hand and distrusts AI. The next one pastes entire files into a chat window. And another one lets an agent run wild and ships code nobody has reviewed.

And then there's a fourth group - maybe the most dangerous one: They use Cursor or Claude Code, they already looked at spec-kit, they already wrote specs, ... But somehow they didn't get the promised result and decided it's not worth the effort.

The result in all four cases looks the same: inconsistent quality, unreviewable pull requests, no shared practice, no shared vocabulary, no measurable productivity gains.

Without a harness, without a shared system, without a shared definition of "what is good enough," what feels like progress is often just faster chaos.

The tools are powerful. The way most teams use them — including the ones who think they've already figured it out — is chaos.

Chaos is usually a missing system.

Agentic engineering draws a clean line.

Agents do the implementation. Engineers own the architecture, the spec, and the correctness.

That means you start with a plan. You build a spec with the agent and iterate until it's ready to build. You break work into well-defined pieces. You build reusable skills so the agent gets better at your codebase over time, instead of starting from zero every session.

It's not a trick collection. It's a workflow your whole team can share, review, and improve.

Day 1 — The System

We build a real tool together, from scratch, the agentic way.

• Where everyone stands: a quick calibration of how your team works with AI today
• What agentic engineering is, and where the line to vibe coding runs
• Live build: brainstorm four epics, iterate the spec, then implement epic by epic
• Extracting skills as we go, so reusable agent instructions become a byproduct of real work

By the end of day one, everyone has run the full loop: spec, implement, review, extract.

Day 2 — Your Reality

No demo project. Your code.

• Brownfield skills: making agents useful in an existing, grown codebase
• Teams and individuals work on their own projects, with me coaching across the room
• Presentations and lessons learned: what worked, what broke, which tools you keep

You leave with skills built against your actual repositories, not a toy app you'll never open again.

• A shared vocabulary and workflow for spec-driven development across your team
• Working skills, built during the workshop, against your own code
• A reference playbook you can use Monday morning
• An honest idea of where agents help and where they don't

That last point is deliberate. I run a tech organization. I have to live with the code that gets shipped. I won't sell you the story that agents replace engineering judgment. They amplify it, if the system is right.

Most AI workshops end with a greenfield demo and a good feeling. Then Monday comes, the real codebase is messy, and everything learned falls apart.

That's why half of this workshop happens inside your reality: your repos, your legacy decisions, your constraints. The skills you extract on day two are the ones that survive contact with actual work.

Teams of up to 12 people who already have access to an agentic coding tool (Claude Code, Cursor, or comparable) and want a shared, disciplined way of working with it — whether that's an engineering team on its own, or engineers working alongside product owners and leadership. A group of engineers works just as well.

A Product Owner belongs at that table just as much as the engineers do. When agents take over implementation, the real work moves earlier — to the spec. A vague user story costs a human one follow-up question. It costs an agent a wrong implementation that looks finished. A PO who understands how specs turn into agent prompts doesn't become redundant — they become the most important quality gate in the process, long before any code exists. Skip that shift, and you end up running refinements built for a world that no longer exists, wondering why your estimates and your outcomes stopped lining up.

Engineering leaders are welcome for the same reason: not to sign off on the workflow, but to understand it, because agentic engineering changes how specs, reviews, and ownership get distributed across the team.

Smaller groups are welcome too — reach out and we'll find a setup that fits.

You should bring: laptops, a working dev environment, and at least one real project per group for day two. I'll send a setup checklist a week before so we spend the first morning building, not installing.

This is not an intro to AI. It's for teams that are past "should we use this" and stuck at "how do we use this well, together."

I'm Daniel Hauck. At Europe's largest music retailer, I don't just lead engineering teams — I'm responsible for the company's entire AI transformation, from first pilot to organization-wide rollout. On the side, I build and ship products solo, using agentic workflows daily. I've run this workshop eight times so far, each time with a different team, different disciplines, a different codebase, different constraints. What's on this page is the system that actually held up — not theory I collected.

Format: 2 days, on-site at your office or remote

Group size: Up to 12 people, to keep the workshop hands-on. Smaller groups welcome — reach out and we'll find a setup that fits.

Investment: €7,500 (net; VAT added where applicable), plus travel. Preparation and setup checklist included.

Languages: German or English

One offer, no tiers. If the format doesn't fit your team, we talk and adjust it before you commit.

The workshop gets your team through the loop once, together. Making agentic engineering the default in your company is the actual goal — and that starts with a deliberate decision, not something that happens on its own.

From there, the work is building common standards: a shared way to get everyone to the same level of agentic fluency, not five different approaches living side by side.

If you enjoyed the workshop, I can help you make that happen inside your company. That usually works best by starting with one team and going from there.