Let more people build, without taking the rails off
More people are about to start building in your systems, with tools that make producing code cheap and reviewing it expensive. This session is about the rails: everything as code, a preview per branch, automated checks that answer factual questions, and an evidence trail that is collected rather than reconstructed.
- €2,000 per workshop
- One day
- Up to 12 people
- English or German
Review is the bottleneck now
When one engineer wrote one change, review was a conversation. When several agents produce changes against the same brief, review is the whole job, and it cannot be done by reading diffs carefully.
What makes review tractable is that there is something to review against: a journey, a constraint list, labelled examples, decision records, and checks that answer factual questions automatically so humans only argue about the things that are genuinely judgement calls[8].
The platform side is the same argument. A branch that gets its own preview environment, created and destroyed automatically, turns business acceptance into something that happens on the actual artefact. That removes an entire category of rework, and it is what makes it safe to let a product person build[6][7].
And once it runs, an AI system fails in ways your load balancer cannot see. Step-level traces, token cost and error rates have to be visible from day one, not added after the first incident[10].
The column you own, and what arrives from the other two
The model is the same in every track. What changes is which column you own and what you are expected to hand over.
The technology
“Can it be built, run and defended?”
- Architecture, data access, the layer decision
- Everything as code, previews per branch
- Checks that answer factual questions
- Traces, cost and on-call reality
In the room: You, platform, data, security, operations
The user
“Who is this for, and what does their day look like afterwards?”
- A named user and a journey
- The step AI may change
- The line it may not cross
- Good enough, as a number
In the room: Product owners, business analysts, designers
The business
“What is it worth, what is in the way, and who signs?”
- Constraints that eliminate architectures
- The budget the running cost has to fit
- The measure you are building against
- Certification and audit obligations
In the room: Finance, legal, compliance, leadership
What you take back to the repo
Everyone leaves with both. The optional results are built against your actual repository.
Repository templateIncluded
The directory structure, decision-record format and ownership map, adapted to your stack, so the next project starts with the rails already there.
Quality gate and check designIncluded
Which checks run automatically, what each one blocks, and where a human judgement is genuinely required.
Branch preview designOptional
How a preview environment per branch works in your setup, what it costs, and how it gets torn down.
Observability plan for AI workloadsOptional
What to trace, what to alert on, and how to answer "why did it do that" a week later[10].
What a machine should answer before a human reads the change
The rule is simple: if a question has a factual answer, a machine should answer it before a human reads the change. Humans are for the rest.
| Check | What it blocks | Why automatic |
|---|---|---|
| Tests and contract checks | Changes that break a promise something else depends on | Factual, fast, and nobody enjoys finding this by hand |
| Security and dependency scanning | Known-vulnerable dependencies and leaked credentials | Required evidence anyway under most certification regimes[2] |
| Policy as code | Infrastructure that violates a rule the organisation already agreed | The alternative is remembering, which does not scale past three people |
| Cost estimate on the change | Architecture that is fine at demo volume and ruinous at real volume | The number is knowable before the merge, so it should be there before the merge |
| Evaluation on labelled examples | AI behaviour changes that quietly get worse | Prompt and model changes have no compiler; the evaluation set is the compiler |
| Human review | Nothing automatic can decide | Design, trade-offs, and whether the thing is the right thing at all |
Written tutorials rot; the SDK keeps moving
A real example from a workshop I maintain: four instructions stopped doing what they said, because two libraries moved underneath them. Code has a compiler to catch that. Prompts and agent behaviour do not, which is the whole argument for an evaluation set.
One day, spent on your own repository
Bring a real project. We use it rather than a sample one, and what we build stays with you.
The substrate
The repository: journeys, constraints, sample and labelled data, decision records, infrastructure, evidence. What lives where and who owns it.
The rails
Branch previews, the automated check set, and what business acceptance looks like when it happens on a preview instead of a screenshot.
The agents
Working with parallel implementation safely: what agents need in the repo to be reviewable, and what to trace once it runs[10].
One workshop, the results you choose
Same model as every other workshop: €2,000 for the session, €1,000 per written result. Net, plus VAT.
AI for engineering teams workshop
Pre-session intake, the live workshop with up to 12 people, written results within 5 business days.
€2,000 each, 3 to 4 hours, remote or on-site
Delivered within 5 business days after the last session.
AI for engineering teams
What people ask before booking.
Is this a Kubernetes workshop?
No. The principles are platform-agnostic; the worked examples are on AWS and on Red Hat OpenShift because those are what I run. Bring whatever you actually use.
We already do CI/CD. Is there anything here?
The delta is usually two things: the non-code artefacts in the repository, and the evaluation set for AI behaviour. Teams with good pipelines often have neither.
Do you write code in the session?
Yes, where it is faster than talking. The repository template is built live against your project.
What about agent frameworks?
Covered as far as the architecture needs. The framework matters less than whether the thing can be reviewed and traced afterwards.
Can product people attend?
Yes, for the morning especially. The repository argument lands much better when both sides are in the room.
Linda Mohamed
I design and build AI and cloud systems on AWS and hybrid platforms, and I teach how they work. I have organised the AWS User Group Vienna for more than seven years, co-organise AWS Community Day DACH, teach AI architectures at Hochschule Burgenland, speak at conferences in Europe and the US, and maintain ai-solutions.wiki. Based in Vienna. Remote or on-site, in English or German.
Where the facts come from.
Prices, service names and limits change. The linked official pages are the reference; figures on this page were checked in September 2026.
- ISO/IEC 42001:2023, AI management systems
- ISO/IEC 27001, information security management
- ISO 9001, quality management
- Regulation (EU) 2024/1689, the EU AI Act
- NIST AI Risk Management Framework
- CNCF TAG App Delivery: Platforms White Paper
- CNCF TAG App Delivery: Platform Engineering Maturity Model
- DORA: DevOps Research and Assessment
- AWS Well-Architected Framework
- Amazon Bedrock AgentCore: observability
- AWS: AI services overview
- ai-solutions.wiki: from AI proof of concept to production
- ai-solutions.wiki: build vs buy for AI
- ai-solutions.wiki: total cost of ownership for AI
- Training Magazine: 2025 Training Industry Report
Start with one conversation.
30 minutes to look at your idea, your data and the right starting point. Or book 15 minutes if you only have a question.
- What is missing from your current rails
- Whether branch previews are realistic in your setup
- How to make agent output reviewable
- What to trace once it runs
Vienna, Austria · remote across Europe · [email protected]
