On Wednesday 18 March 2026 I attended the Platform Engineering Amsterdam meetup at Tolhuistuin, one of my favorite venues in Amsterdam Noord. The theme was “Human Intelligence” — a refreshing counterpoint in a world where every event is about AI. The idea: real experiences, lessons learned, and hard-earned knowledge shared human-to-human.
The event was hosted by Darko K. and Michaela at the beautiful Zonzij room inside Tolhuistuin, sponsored by Coder and Tarmac. Around 128 attendees showed up for three talks, food, drinks, and a gorgeous sunset over the IJ.
Talk 1: Efficiency Patterns in Agentic Software Development
Michael Suchacz of Coder tackled the question every platform team is asking: How do we make AI work efficiently at scale?
His talk covered practical approaches to optimizing agentic workflows:
- Context management strategies that keep models focused and reduce token waste
- Architectural patterns like sub-agents and swarms that distribute cognitive load across multiple specialized agents
- Efficiency tradeoffs — where gains are real versus illusory
- Security considerations when giving agents more autonomy in development environments
Left: the “Subagent Tradeoffs” slide, ending with “If reasoning is tightly coupled, keep it together. Decompose only when subtasks are genuinely independent.” Right: the “Thinking Fast and Slow” slide on System 1 and System 2, which led into applying the idea to agents.
This resonated strongly with my own experience building AI-augmented infrastructure workflows. The key takeaway: throwing more compute at agents is not the answer. Smart context windowing and task decomposition matter more than model size.
For teams exploring GitHub Copilot Agent Mode or similar agentic tools, Michael’s patterns around sub-agent orchestration are directly applicable.
What Michael actually said: harness, loop and benchmarks
Going back through the clips I recorded, there was more substance than the summary above. Michael introduced himself as, until recently, head of engineering for Mux, Coder’s tool for agentic software development. Coder itself builds cloud development environments and is now adding an AI layer on top. He first listed what companies already worry about when they roll out agents: compute for the agent that can’t touch a developer’s machine, a standard roll-out, fallbacks, automatic code review, and visibility into what people do with agents and which models they may use. Then he questioned the word “efficiency”. If leadership says it will pay for whatever tokens you need, efficiency stops meaning “cheapest” and starts meaning “best possible result”.
“What Is an Agent Harness?”: the loop, tool definitions and execution, context assembly and management, guardrails and validation. “The model is the engine. The harness is the car.”
The loop. An agent gets a task, usually a prompt, and assembles context: the AGENTS.md or CLAUDE.md files and whatever else matters. That context is all the model knows about your intent, because it has no long-term memory. Every call to the LLM API sends the entire conversation again as JSON. Caching helps, but only when you hit the cache.
Programmatic tool calling. Models tend to make many small tool calls: read this file, read that file, query the database once per region. Since the model can write code, the alternative is to let it write the chain of calls itself and return only the final result. According to Michael, Anthropic offers this but runs the code in its own sandbox and bills you for the minutes it runs. Mux ran it in a local sandbox instead, to cut latency and avoid round trips to the model.
Sub-agents and System 1. For isolated pieces of work, an orchestrator can spin up sub-agents on a faster model. In Mux, the results come back as a Git patch in email format, an old Git feature that fits the job well. The “Thinking Fast and Slow” part applied the same idea to routing: a cheap, fast model (Haiku, in the benchmarks) as System 1, and a stronger model as System 2.
What the benchmarks showed. Beyond the averages in the table further down, he shared some anecdotes. On one task, the only agent that passed was Claude Code on Opus, for about 57 cents. Codex spent about 8 dollars with no result, and Mux failed too. The models all made the obvious edits but missed a value buried deep in a nested JSON file. GPT-based Codex did everything it was asked “and then some more”, editing and deleting things in other files. On another task it was the other way round: Claude timed out and got stuck. Cost accounting was hard in itself, because the providers report cached and uncached input tokens differently.
“What the Data Actually Shows”: System 1 routing is high-variance (the Haiku variant passed 33% in run 1 and 83% in run 2), cheapest is not most efficient, and brute-force token spend can work.
What lasts. His conclusion was that clever harness tricks probably won’t matter much in the long term. Every time the providers add a capability, they also pull you further into their ecosystem. What stays useful is the work around the model: benchmarks that tell you whether something actually works, security boundaries and sandboxing, audit trails, a human in the loop who can see the results, and the tools and APIs your agents use.
My take: that last list is a platform team’s job description. Sandboxes, audit trails, model allow-lists and an internal benchmark suite are the parts of an agent platform that survive the next model release. Prompt tricks don’t.
Talk 2: A Practical Guide to Inner Sourcing Your IDP
Lian Li, Cloud Native Human and experienced Developer Advocate, presented a compelling framework for treating your Internal Developer Platform as an open source project rather than just a product.
The core insight: product thinking gets you started, but inner source thinking gets you adoption. When developers can contribute to and maintain platform features, the gap between “what developers need” and “what the platform provides” shrinks dramatically.
Her concrete steps included:
- Identifying contribution opportunities — which platform components benefit most from developer input
- Setting up maintainable processes — contribution guidelines, review workflows, and ownership models
- Measuring engagement — tracking adoption, contributions, and developer satisfaction
A slide from “A practical guide to inner sourcing your IDP”: the Developer Journey Stages, Discover, Evaluate, Learn, Build and Scale.
This aligns perfectly with what I see in Backstage-based developer portals. The most successful IDPs are the ones where application teams feel ownership, not just consumption. Lian’s framework gives platform teams a roadmap to get there.
Talk 3: Escaping the Data Center — Migration Wins and Woes
Dejan Mladenovski, Principal Software Engineer at G+D Netcetera, gave the most honest talk of the evening. Three questions framed the whole presentation:
- Why did we migrate to cloud?
- Was it a good idea to migrate?
- Did I at some point want to quit and move to a farm?
The title slide of “Escaping the Data Center: Migration Wins and Woes” at Platform Engineering Amsterdam.
The answer to the third question got the biggest laugh of the night — and anyone who has led a major cloud migration knows exactly why. The reality of moving enterprise workloads to the cloud is messier than any vendor presentation suggests.
For teams considering similar moves, the lessons around cloud infrastructure strategy and understanding the true cost of migration (not just the compute bill, but the organizational change) were invaluable.
From my photos: the slides behind the talks
Going back through my phone photos from that evening, I found the slides were worth a second look. Here is what was on screen, talk by talk.
The Coder talk included an invitation to its KubeCon EU booth, 794, the following week.
The tarmac roll-up next to the stage carried the evening’s tagline, “The sky is the limit & the cloud is the playground”. Between the Coder talk and Lian’s, Michaela Herman, General Manager at Tarmac.io, introduced the company. Her slide described it as a software development partner focused on DevOps (process and cost optimisation), frontend, backend and mobile (iOS, Android and cross-platform), QA engineering and UI/UX design. A later organisers’ slide credited the meetup as “Platform Engineering Amsterdam, hosted by Coder and tarmac”.
Coder: agent benchmarks in numbers
The Coder talk included a live demo with github.com/coder/portabledesktop in the browser bar. Then came the slide I photographed several times, “Benchmarks: The Numbers”. Its header read: “Same 9 coding tasks, 6 agents. Averaged results.”
| Agent / variant | Pass rate | Avg cost | Cache read | Output | Duration |
|---|---|---|---|---|---|
| claude-code (opus) | 78% | $0.43 | 703K | 3.1K | 226s |
| codex (gpt-5.4) | 67% | $2.94 | 1.2M | 9K | 264s |
| mux – opus, default | 56% | $0.12 | 79K | 3.3K | 128s |
| mux – opus, ptc-exclusive | 67% | $0.17 | 152K | 3.5K | 160s |
| mux – opus, system1-haiku | 44% | $0.13 | 99K | 3.3K | 92s |
| mux – gpt-5.4 | 78% | $0.70 | 211K | 7K | 195s |
Six agent setups, same tasks: the pass rate only makes sense next to the cost and cache-read columns.
My take: this is the kind of table every platform team should build for its own codebase before standardising on an agent. The spread in cost and cache reads between setups with similar pass rates says more than any headline model name.
Lian: inner sourcing your IDP
Mid-row selfie during “A practical guide to inner sourcing your IDP”.
Lian’s intro slide listed 17+ years in tech, 10+ years of public speaking, and roles as Cloud Native Consultant, Developer Advocate, Platform Engineer and IDP Adoption Specialist. Her problem statement had a memorable title, “Technically Impressive Ghost Towns”. The slide gave three figures, with a Google Cloud blog link as the source: 55% of organisations have adopted platform engineering, 85% report that developers rely on the platform to succeed, and only 27% have successfully integrated best practices.
The gap between 55% adoption and 27% best-practice integration was the starting point of the talk.
From there the talk moved through a set of DevRel tools aimed at an internal platform:
- Developer Journey Stages: Discover, Evaluate, Learn, Build, Scale, credited to the DevRel Book. A later Developer Journey Map paired each stage with a question (“Is this of use to me?”, “Will it meet my needs?”, “How does it work?”, “Can I build a proof of concept?”, “Can I build to scale?”) and with touchpoints such as a dev hub landing page, docs, code samples, office hours, sandbox, changelog and an ambassador programme.
- Case Study A, then The Platform Advocacy Framework and a “Beware the trap” slide.
- The Orbit Model, with rings for Advocates, Contributors, Participants and Observers. On it, LOVE is a measure of a member’s activity in the community and REACH a measure of their sphere of influence. The slide noted that the model is open source (
github.com/orbit-love/orbit-model). - Personas on a Reach/Love grid: Influential Skeptic, Expert Multiplier (senior ICs, internal developer advocates, platform champions), Detached Observer and Independent Fan (early adopters, new joiners with previous platform expertise, individual contributors).
- A tribal leadership ladder sourced from agilecoffee.com. Its stages and shares were: “Life Sucks” 2%, “My Life Sucks” 25%, “I’m Great (you’re not)” 49%, “We are Great” 22%, “Life is Great” 2%. This led into a “Culture First” slide.
The Personas slide: four platform-user types placed on a Reach/Love grid.
Left: the Orbit Model applied to platform users. Right: the tribal leadership stages that set up “Culture First”.
She closed with a slide for Kuberoke Amsterdam, “the first and only Kubernetes karaoke community”, which held its own night during KubeCon week.
My take: treating internal developers as a community with orbits and personas, rather than as “users”, is a useful way to rethink IDP adoption. Usage numbers show who logs in. They don’t show reach: who is pulling other teams onto the platform.
Netcetera: why they left the data center
Dejan Mladenovski’s title slide read “Escaping the Data Center: Migration Wins and Woes”, with the Netcetera logo. His “Why did we migrate?” slide gave the reasons in three columns:
- Operating cost: 400k EUR/year, plus 50k EUR/year in licences
- Maintenance: monthly patching, certificate renewals, hardware, software updates
- Scalability: scaling took day(s), and global expansion was non-existent
400k EUR a year in operating cost and scaling measured in days: the business case on one slide.
Later slides walked through detailed architecture diagrams of the setup.
Two more sessions: Orcheo and an AI QA framework
After the three talks, two more sessions followed. The first was “Orcheo: From Install to Your First Live Workflow”; the title slide credited Shaojie Jiang, AI Colleagues, March 2026. The second was a walkthrough of an open-source GitHub repository called ai-qa-framework. Its description read “Autonomous AI-driven QA framework — give it a URL, get comprehensive test coverage”, under an Apache-2.0 licence, and recent commits added Ollama provider support.
Orcheo, from install to a first live workflow.
How the AI QA framework works
The ai-qa-framework session was a live demo rather than a slide talk, and my clips caught most of it. The speaker, who wasn’t named on screen, started with the idea: point it at a URL and give it a few settings, such as how deep to go and which kinds of testing to run. Then the LLM takes over. It discovers the site by scraping, makes a plan, moves from the plan into execution, gathers the results and analyses them with the evidence, and presents them to the user. He said they had open-sourced it and the audience was welcome to use it.
The ai-qa-framework repository on screen during the walkthrough.
He ran it from a terminal with python -m src.cli run against Sauce Demo, a public Shopify demo store. The log showed three stages:
- Crawl. He had set it to look at 10 pages. The crawler spidered through the store: the home page, About Us, News, account registration and login, search, the product list and two jacket product pages. The log ended with “10 pages visited, 35 total URLs seen”, in under half a minute. According to him, it also looks at previous runs, so it doesn’t keep walking a well-worn path and leave other sections undiscovered. On screen, this showed up as a gap analysis before planning: 1 untested, 4 stale, 0 low-coverage and 3 failures.
- Plan. The crawl result becomes a structured document with all the links it found. That goes to the LLM together with the kinds of testing wanted (he named functional, visual and security testing) and hints about the areas to cover, all loaded into the context. In the log, the call went to
claude-opus-4-6with a 32,000-token limit. The answer took 94.6 seconds and came back as a plan of 19 test cases, with one validation warning (a “fill” step that had no value). The plan is then translated directly into Playwright actions. - Execute. He said the tests run in parallel on four threads to keep the run reasonably fast. The first tests on screen were functional ones: registration with valid data, login with invalid credentials, a password-reset form and adding a product to the cart from a product page. A security test for XSS injection in the search field came next. Adding to the cart passed. The login and registration tests failed and were re-run with video capture for failure analysis.
The part I found most practical was how it deals with flaky tests. As a developer, he said, one of the things he hates most is a fragile automation test, because he wants results back rather than time spent debugging tests that fail for no real reason. So there is a fallback. When a test fails, the framework takes a screenshot of the failing part and passes it back to the LLM with the plan, and the LLM decides whether the test should pass or fail. In the log, these were the “Calling AI with image” calls, capped at 500 tokens each and answered in about four to five seconds.
He also explained a design choice. For quality control you want deterministic flows that cover the core paths every time, but you also want some non-determinism in there. That’s why they separated the two: rather than giving the LLM total control, they give it hints about what must be covered on every run. According to him, that’s also why they didn’t use MCP. He believed Playwright now has a tool of its own for this, which he thought would be interesting to add.
The repository’s README describes the same pipeline in four stages, adding a report stage that produces HTML and JSON reports with screenshots. According to the README, it tracks coverage between runs to target gaps, takes natural-language hints in a qa-config.json file, and can use a local Ollama model instead of the Anthropic API. It describes the screenshot step more broadly than the demo did, as AI-assisted error recovery that also fixes broken selectors.
My take: separating the paths that must be covered on every run from the parts the LLM can explore is the right call. I would still keep a small hand-written smoke suite for the critical paths, though. And when the LLM rules that a failed step is really a pass, I’d want a person to review that verdict before it counts as green in a CI gate.
Between talks, the organisers also showed an “Other Communities & Events” slide pointing to MLOps Amsterdam.
The community is the point
What I appreciate most about Platform Engineering Amsterdam is the quality of conversations that happen between and after the talks. The meetup has grown into one of the strongest PE communities in Europe, with 4.8 stars across 147 reviews — and it shows in the caliber of attendees.
Other communities got the mic too. Someone from the MLOps Community in Amsterdam, a local chapter of a global community, gave a short pitch. According to him, it has about 2,500 people on its Luma list, and its events range from 50 to 250 people: workshops, hackathons and meetups like this one. The community existed before the generative AI boom and still covers classical ML, but it now covers GenAI heavily too, including the technology behind coding assistants and how to build AI systems that are stable and scalable. Coming up, he announced an OpenClaw hackathon, plus “AI for education” and “AI for defence” specials later in the year.
The “Human Intelligence” theme was more than a catchy title. In a field obsessed with automation, the reminder that platforms are built by people, for people, was exactly right. The best platforms encode human judgment into reusable patterns — they do not replace it.
Upcoming: Platform Engineering Executive Roundtable at KubeCon
If you are heading to KubeCon Europe 2026 in Amsterdam, the Platform Engineering Amsterdam group is hosting an Executive Roundtable on March 24 at NHOW Amsterdam RAI. Worth attending if you are a CTO/CIO looking to connect with peers on platform strategy.
Building a platform engineering practice? Let us talk about developer portals, automation strategy, and making your IDP a product developers actually want to use.
