Dexter Horthy was the best speaker of the day, and Dylan Ratcliffe won me over after I initially disagreed with his premise. His line “easier to reject the recipe than the meal” is the same lesson I learnt the hard way at the bunq hackathon: i.e review the plan before anything gets built. Roy Belio’s red teaming lab made me glad I’d already locked down egress on my coding agent, and gave me a list of things I still haven’t done (DNS, canary tokens, read-only config). Another thing is that plenty of the live demos broke, which shows non-determinism in action.

Next year’s conference is in London, and I’m hoping to go! Reach out if you’re going too.

The rest of this post is my notes from each talk, lightly tidied up.

Catch Them Early

9:07am, Manik Surtani (CTO, Agentic AI Foundation)

• The Agentic AI Foundation (AAIF) compared itself to the CNCF, which had the benefit of an industry that already had lots of experience with cloud.
• They’ve copied the CNCF bar for accepting projects, and in some places raised it.
• They’ve had a 3-4x growth pace compared to CNCF… the AI hype probably helped tbh

Getting to stateless MCP in production

9:19am, Shaun Smith (Hugging Face, MCP transport working group maintainer)

• Streamable HTTP is a smarter way to connect, closer to one-to-one client-to-server.
• The stateless release brought improvements, but they needed migrating to the new SDK.
• Uptake has been massive.

Three doors to one tool: MCP vs WebMCP vs CLI

9:29am, Dominic Farolino (Google Chrome) & Frederic Barthelet (CTO, Alpic)

• WebMCP is a layer on a website that lets agents interact with your website much faster.
• Better than llms.txt which isn’t often looked at
• CLIs integrate well with agents.
• A harness is tools, memory, context, and guards.
• MCP can be a local server or a public one.

State of the software factory

9:41am, Dexter Horthy (CEO & co-founder, HumanLayer)

• A fantastic speaker who also has a YouTube channel.
• The best talk of the day, with interesting content that’s worth checking out properly.
• Walked through HumanLayer’s multiplayer AI chat tooling, which drives spec and code diff checks.

Tools mentioned: HumanLayer’s resources.

Pull Requests are dead, long live peer review

10:20am, Dylan Ratcliffe (Overmind)

The most controversial talk of the day, at first. By the end he’d convinced me, mostly because he showed how it’s working for them right now.

• Pull requests are dead.
• AI is not your peer, and its code is harder to review.
• Agents are agreeable. They’re bad at disagreeing with you.
• He was a passable engineer who was outperforming his own team, and considered firing the engineering team. Instead he shifted the engineers left, into more product-oriented roles.
• Move peer review into the planning phase, where the decisions actually get made.
• The loop: research, decide on an approach, weigh up tradeoffs, plan, collaborate, then implement until the implementation matches the plan.
• It’s easier to reject the recipe than the meal. People are more willing to reject a plan, because it’s cheaper to fix.
• My open question: what about conflicts between the plan and the existing system? Does that get caught in review?

Tools mentioned: AI Is Not Your Peer, and Until, which makes sure your agent implements every part of the plans you write.

From “works on my prompt” to production SLOs

10:55am, Manik Khandelwal (Microsoft)

• He wants agents that don’t need constant checking.
• It was confusing what he was trying to do. He has a framework that watches whether an agent needs active supervision or can be left running in the background.
• The slides were AI generated. Cool to look at and interactive, but they lacked humanity in a way I can’t quite describe. It didn’t tell a story, it was more show and tell.
• I didn’t get much from this one.

Tools mentioned: Mitra, an internal tool for monitoring agents. Not sure if it’s open sourced yet.

Governance you can run: Checkable properties for production agents

11:30am, Seshu Tolety (Director of Agentic AI, Siemens)

• The cost of ungoverned AI model usage on privacy, operational burden, and more.
• Three lifecycles as new mental models: AI adoption, engineering, and operations (can we run AI safely at scale?).
• He walked through today’s organisation and policy structures, then out to a future state where AI governs AI policy.
• Humans sit in that structure reviewing the policy that AI creates. As we know from code, that makes humans the bottleneck. After hearing Dylan’s talk, I’m not sure I agree. The idea is both scary and interesting at the same time!
• “Governance should never slow innovation. It should help you scale it.”

Governed agent autonomy: Building a control plane for agentic systems

1:15pm, Nnenna Ndukwe (Qodo AI)

• Harness config, mostly around what to allow.
• Five governance patterns found in the leaked Claude Code source, which she open sourced:
  1. Planning
  2. Permissions (can this action proceed?)
  3. Tool trust (capability trust)
  4. Verification
  5. Runtime (what were the outcomes?)
• She implemented them in a Rust agent.
• The demo was supposed to block a deployment to production. It didn’t xD

Tools mentioned: Goose (an AAIF project), GAAP (agent observability), and Martin Fowler’s writing on harness engineering.

Beyond Chatbots: Agentic UI with Open Standards

1:25pm, Manfred Steyer (ANGULARarchitects)

• An interesting talk, and one of the few live demos that worked. Well, it didn’t at first, until they realised it was just the WiFi. Once that was fixed it worked.
• “To chat or not to chat… that’s the wrong question.”
• Showed a UI progressively changing as you chat with it and co-create.

Tools mentioned: AG-UI (agent communication), A2UI (dynamic UI), and MCP Apps.

MCP Apps and the Agentic Web

1:50pm, Liad Yosef (MCP Apps)

• The difference between a website, WebMCP, and MCP Apps.
• A really convincing talk on how brands can bring their apps into chat instead of splicing up their current website.
• His point is that we might move away from browsers entirely, because we might not need them.
• Salesforce is going headless, even though UI was their differentiator.
• Cloudflare says bot traffic has overtaken human traffic.
• Web search isn’t great for agents, and an app store probably isn’t either. What about an agentic identity that’s tied to you?
• The next big thing is the discovery layer for agents. He compared it to web search, with .well-known/ai-catalog.json as a unified standard.

Tools mentioned: Goose, DoorDash’s new CLI, Sentry, Ora’s researcher benchmark, npx ax (an audit tool for how agents use your website), and Ora’s Agentic Resources Discovery: the agentic index of the web.

No Central Brain

3:25pm, Fausto Albers (WonderWhy, co-founder of AI Builders Club)

• No central brain. Ominous music. Who decides what’s true?
• “Attention is all you need”, reframed as: 1. harness and loop, 2. recursive self improvement, 3. memory and learning.
• The harness reinvents itself. It self-learns and stores each change along with its cost, tests itself, makes changes, evaluates the model, then recreates the harness.
• I wonder if it’ll converge on AI granting itself unlimited access and some wild harness configurations…

Infrastructure red teaming with abliterated models

3:30pm, Roy Belio (Red Hat)

• Red teaming chat models and model refusal. Injection gets past a lot of guardrails.
• There are lots of CVEs about prompt injection and ways around guardrails.
• Guardrails and classifiers are a good start, but they’ll miss anything that isn’t in English.
• His outcome was to run tooling on an SSH server somewhere else, not on the same service as the LLM.
• In the interactive lab, a tool would sometimes error out, but cat was still available so the agent read the file anyway. Sometimes the LLM hid the logs too.
• A read-only container running sshd is a good idea.
• Watch for direct socket operations and exfiltration over DNS. Block egress, and keep DNS traffic internal too.
• The slash command illusion.
• Keep the config that shapes the agent’s behaviour on the pods, and never let it be writable. The agent will rewrite itself.
• Put canary tokens anywhere that could tell you you’ve been compromised.

Further reading he mentioned: EchoLeak (Microsoft), AWS Strands, MCP Poison (Cursor), the Deadbugz campaign (August 2026), and Crash test dummy, the blog where he first worked through this talk.

Thankfully, I found Dev Containers, which turned into its own rabbit hole but lets us lock down Claude without having to maintain our own docker image.

This reflection post talks through the containerised setup and some issues I faced while setting it up. If you just want the solution, then the implementation is in the .devcontainer/ directory of this website’s source code.

Feature or docker image?

I assumed that Anthropic would ship an official Claude base image you build on top of. They don’t, they only post a recommended starting point. Claude Code installs into any Dev Container through the ghcr.io/anthropics/devcontainer-features/claude-code:1.0 feature, which you reference in devcontainer.json like any other devcontainers feature. It works wherever the Dev Containers spec is supported e.g. VS Code, Codespaces, JetBrains, and (with some rough edges) Cursor. In VS Code it can be configured to pull in the Claude Code extension, keeping Claude decoupled from the base image entirely.

That leaves three layers to assemble: a base image, the tooling you use, and Claude Code on top. The real decision is whether you bake those middle two layers into a custom docker image you push to a registry, or assemble them per-repo through devcontainer.json features. A custom image is the better call for a team, where you want a validated, secure, and reusable environment everyone builds on. For a solo setup spun up per-repo, features are easier. The cost is a slow first build and less control over exactly what lands in the image, which is what post-create.sh helps automate somewhat.

My devcontainer.json ended up looking like this, trimmed to the main parts:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  },
  "remoteUser": "vscode",
  "mounts": [
    "source=claude-code-config-${devcontainerId},target=/home/vscode/.claude,type=volume"
  ],
  "runArgs": ["--cap-add=NET_ADMIN", "--cap-add=NET_RAW"],
  "postCreateCommand": "sudo zsh .devcontainer/post-create.sh",
  "postStartCommand": "sudo /usr/local/sbin/init-firewall.sh",
  "waitFor": "postStartCommand"
}

The non-root vscode user is important if you ever run with --dangerously-skip-permissions, Claude Code requires it. The named volume on ~/.claude means login persists across rebuilds instead of re-authenticating every time. The NET_ADMIN/NET_RAW capabilities exist so that we can create the containerised firewall. waitFor: postStartCommand blocks the terminal until that firewall script finishes, so there’s no window where Claude is already running before egress is locked down.

post-create.sh is the everyday stuff a feature-based setup doesn’t hand you for free: setting git aliases, adding a couple of zsh aliases for kubectl and terraform, locking down sudo/su.

init-firewall.sh sets default-DROP policies on iptables, then builds an ipset allowlist of everything the container is allowed to reach outbound. Part of that allowlist is GitHub’s own published IP ranges, fetched live at container start:

gh_ranges=$(curl -s https://api.github.com/meta)
while read -r cidr; do
    ipset add allowed-domains "$cidr"
done < <(echo "$gh_ranges" | jq -r '(.web + .api + .git)[]' | aggregate -q)

Everything else —npm, api.anthropic.com, the VS Code marketplace— gets resolved and added individually. The firewall script finishes by checking its own work: it tries curl https://example.com and expects that to fail, then tries curl https://api.github.com/zen and expects that to succeed.

Firewall and sudo

I spent a decent chunk of time configuring who’s allowed to touch iptables. The common-utils feature grants the vscode user blanket passwordless sudo by default, and my first cut of post-create.sh narrowed that down to the iptables/iptables-save/ipset binaries themselves, with no argument restriction. Which meant Claude or anything else running as vscode, including under --dangerously-skip-permissions, could just run sudo iptables -F && sudo iptables -P OUTPUT ACCEPT and the firewall would be gone! Anthropic’s own reference devcontainer avoids this by granting sudo on one fixed script path instead of the raw binaries, baked into their image at build time so the script itself can’t be edited either. I didn’t want a custom Dockerfile yet, but dev containers can do the same thing with just postCreateCommand: copy init-firewall.sh to a root-owned /usr/local/sbin/init-firewall.sh outside the bind-mounted workspace while the feature’s broad sudo grant is still active, then narrow sudo down to NOPASSWD on that one frozen executable file only. The tradeoff is that editing the live init-firewall.sh to allow a new domain now needs a full Rebuild Container, not just a restart, since the frozen copy is what actually runs.

Claude has it’s own way to limit it’s own execution too using .claude/settings.json. We’ve configured this on top to deny any Bash(sudo *) and Bash(su *) commands, so in normal mode Claude won’t even attempt the command. But --dangerously-skip-permissions does exactly what its name says: it bypasses every permission rule, deny rules included. So that file is a speed bump for the default mode, not something to lean on once the safety’s off. The frozen-script sudoers restriction is the one that locks it down regardless, because it’s enforced by the OS, not by Claude Code.

Gap in the firewall

One thing I noticed was that api.github.com/meta’s ip ranges aren’t scoped to the API. They cover GitHub’s whole edge network, which includes GitHub Pages in some cases. For example, this website, westernwilson.com, runs on GitHub Pages. So with the firewall up and supposedly restricting the agent to an approved set of domains, I could still reach my own site. And by the same logic, any other *.github.io page, or anything hosted there by someone with worse intentions. A page on *.github.io could potentially hold a payload hosted somewhere else entirely, and the firewall would wave it through without ever knowing the difference.

I see three ways to close that off:

• Proxy the traffic and filter on hostname instead of IP. Cleanest in theory, but Encrypted Client Hello can still hide the hostname from anything sitting.
• Drop *.github.io from the allowlist entirely. Unfortunately this also takes raw.githubusercontent.com out too since they share the same ip ranges, but if that’s not something the container needs, it’s a fine trade.
• Accept the risk and move on.

I haven’t picked one yet, for now I’m sitting with the risk while I think about which tradeoff is actually worth it.

Logging in to Claude

Logging in had its own gotcha. In VS Code there is a big orange “use your subscription” button that opens a browser and waits for a callback to localhost, which never makes it back into the container and just hangs. The fix is to skip the button, open a terminal inside the container and run claude, which kicks off the same browser flow but resolves the callback correctly.

We then use ~/.claude, which is now owned by the vscode thanks to the chown at the top of post-create.sh, so once logged in, we gain stickier login sessions.

In doing the whole login dance from a bare terminal meant that my first real session with Claude Code inside the dev container was just text based interaction with no IDE extension wrapper around it at all. It’s an interesting way to work and removes a lot of the UI distraction, but not something I’ll rely on fulltime.

Port forwarding

The other thing that briefly worried me is VS Code forwarded around thirty-two ports the moment the container came up. My first thought was that something in the container was reaching out on its own. It’s not, after some searching I found that it’s VS Code’s automatic port-forwarding scanning the container for anything listening on a port, for example a dev server that you’ll want to open in a browser. It’s a separate, fairly trigger-happy feature, and apparently a known source of noise; This GitHub issue describes the exact same “over 20 ports auto-forwarded” behaviour after a setting silently flips from process to hybrid detection mode.

If you want to see the actual config rather than the excerpts above, it’s all in this repo under .devcontainer/. Treat it as a personal setup to extend, not a hardened image to copy verbatim.

Further reading: Anthropic’s Dev Containers docs and the VS Code Dev Containers tutorial.

This moment has been circling in my mind across this last week.

How I got there

I went to Amsterdam for three nights to see the city and to take part in Bunq’s 24-hour hackathon. I arrived alone and Bunq connected me with a team. On the day two people didn’t show so we ended up finding two others in similar situations and formed a new team.

The hackathon brief was to build something that solved a problem, used the Bunq API, and had some kind of multi-modal AI. I didn’t know what we’d build, and honestly that was exciting to me!

Who I worked with

Our team was called “4 corners” with people from four countries. We had a DevOps Engineer, Business Analyst, Product Owner, and even a CFO. Honestly, it was a privilege to be around such accomplished people whose lives had taken different trajectories leading them to this moment.

The build

On the day we had a brilliant talk by someone from AWS about spec driven development. I took that talk to heart and tried building our app using that same ethos. This led me to a vibe-coded backend app in Python, the language I knew, but attempting to use production-grade infrastructure. For a 24-hour prototype, this was overkill. The AI, eager to please, happily built me something far beyond what the hackathon called for.

It reminds me of something an old colleague once told me:

building something is easy, productionising it is the hard bit

In this hackathon, unfortunately, I started off by inverting their advice. I was productionising something before I’d built anything.

The pivot

You can wrangle an app together in 24 hours. What matters more is whether you’ve thought clearly about the problem, can articulate the pain point, and can demonstrate something useful with honest tradeoffs.

• Mock APIs not crucial to the core solution instead of integrating with them.
• Stub the database or run one locally to show the core idea working.
• Later, if there’s time then connect the real infra.

The lesson for me was closing the gap between ambition and execution. A gentle reminder to focus more on the problem being solved, and on building an MVP that demonstrates a useful solution.

That’s what scrapping the bloated AI app got me back to. Something small, something easily understood, something we could actually show someone.

The winning teams that night? Mostly localhost applications.

Amsterdam

After the Hackathon winners were announced, I left Bunq HQ into a city I’d been told was lovely. My cousin recommended Amsterdam as the place to be, and I could see why. Flat landscape, bike-friendly, sunny skies that week (rare, apparently), with free ferries criss-crossing the harbour, and people moving through it all with quiet competence. It felt like a larger Wellington with better trains.

I came partly to see whether I could live in Amsterdam. I left knowing I could.

• Before I used AI to generate content
• Now I use AI more as a refinement tool and writing companion

When referring to AI in this post, I specifically mean large language models (LLMs) like ChatGPT and Perplexity.

Before

How I worked with AI in the past is silly. Using AI to generate content makes the writing sound generic and peppered with buzzwords that people never use. I mean, check the title and content of my previous blog posts: ‘Unleashing the Writer Within: How ChatGPT Transformed My Writing’, and ‘Supercharge Your SSH with VS Code’ 🫣

AI generated content has telltale signs when you see words like: unleashed, supercharge, delve, crucial, more examples here. The silver lining is that AI taught me more words, the problem is these new words didn’t feel authentic to me.

Using AI to generate content was also a coping mechanism to my creative blocks. An unfortunate consequence was that it removed my “want to think”, I could feel myself leaning more and more on the information provided by AI. This felt similar to defaulting to a calculator instead of doing mental math. It’s been over a year since I published those blogs, and I’ve been using AI —perplexity— a lot differently since I started…

Now

Firstly, a bit of background, I work in tech for Xero and I’ve met so many awesome people there. Luckily for me, I’ve got a mentor who is a fantastic Engineer and an amazing Writer, seriously, it’s their superpower; and I’ve been heavily influenced by them. Their guidance has helped me to structure my thoughts more clearly and to approach writing with more confidence.

They shared an amazing blog that talks about the different roles in the writing process:

• Madman - full of ideas, jumbled thoughts and is where writing should start
• Architect - arranges the jumble into potential arguments, at the paragraph level
• Carpenter - sculpts the sentences into a logical structure to make better sense
• Judge - critical energy as the inspector and will check the facts of what is written

Applying these roles to my own writing revealed a crucial insight: that my writer’s paralysis was me prematurely judging the madman before he could cook. I’d critisise the words, sentences, paragraph, headings, scope, purpose, before my madman even had a chance to shine. No wonder I got scared of writing, and wrote at a snail pace.

The madman within needs some air time; sometimes you just need a good ol’ brain dump. Giving myself that permission totally freed me from the fear of writing. Nowadays, as soon as I feel myself being critical, I catch myself and think: “Is it time to judge yet?”

Final points

To wrap up, some final thoughts about using AI as a writing companion:

1. The point of writing is the act itself; letting AI take over robs you of expressing your own voice and innate creativity.
2. I think AI LLMs are great companions for writing, but remember:
   • Ideally, keep personal information out of it.
   • If you do put some personal information in, at least use temporary chats and disable model training
   • Also check with your company before putting sensitive information or private IP like code into it for work
3. On the flip side, I want to share Derek Sivers article here that talks about his commitment to not use AI to generate text. ‍

   I have never ever used AI to generate text in place of my “voice”. No emails. No sentences in my articles or books or even comments. Nothing pretending to be me.

The Writing Struggle

Many of us share the same struggle – the fear that our words fall short, the dread of writer’s block, or the inability to transform ideas into coherent text. But I’ve recently been using a powerful tool to overcome these hurdles: ChatGPT.

ChatGPT: Your Writing Partner

Here’s how AI, be it ChatGPT, Bard, Bing Chat, or another variant, has revolutionized my writing process:

1. Fleshing Out Each Section

I begin with strong ideas but struggle to elaborate on paper. While structure comes easily, content remains challenging. ChatGPT breathes life into my drafts, making them comprehensive and informative.

2. Simplifying Overloaded Sentences

My writing can get tangled in long, complex sentences. ChatGPT excels at simplifying these, making my writing concise and reader-friendly. It trims the fluff and gets to the core of the message.

3. Ideation Booster

When I’m stuck in a creative rut, ChatGPT offers a treasure trove of inspiration. It sparks new ideas, suggests alternative angles, and helps me overcome mental barriers.

Some additional considerations

Privacy concerns

When using AI tools like ChatGPT, prioritize privacy and avoid sharing don’t share sensitive information. Review the terms of service and privacy policies on OpenAI’s website for a better understanding of data handling:

Here is two useful links for ChatGPT:

• https://tosdr.org/en/service/7108
• https://openai.com/policies

Double-check your outputs

While AI can be a helpful companion in your writing journey, it’s essential to double-check the outputs and make sure they align with your intended message. The human touch remains critical in the final editing process. This blog is a great example of that, originally the conclusion said I was a “professional writer” before I touched it up.

In Conclusion: Embrace Your Inner Writer

My writing journey has been marked by struggles; however, AI tools like ChatGPT have been a game-changer, assisting me in fleshing out sections, simplifying complex sentences, and boosting my creativity when I hit a rut. It’s a powerful tool for any writer.

But as with any tool, it’s crucial to be mindful of privacy concerns when using AI, and always review and edit the output to ensure it aligns with your intended message. The human touch remains essential in the final editing process. Just like this blog, where the initial conclusion labeled me as a “professional writer” before my own edits. So, embrace the assistance AI offers, but remember that your unique voice and perspective play a vital role in crafting the perfect piece.