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.

A highlight has been hearing the difference between Germanic, Slavic, and Romance languages up close. Back home in NZ I mostly heard English, some Cantonese, and a little Māori, so all these new sounds have been a great for my brain.

The food everywhere has been amazing too, nothing crazy adventurous, but plenty to satisfy the palate.

• Greece: Island hopping was fantastic, friendly people, and such a rich history. We toured the major islands and timed Mykonos perfectly, just before party season kicked off. We had room to walk and explore without the crowds. Saw a lot of churches and heard about the various empires that occupied these parts.
• Denmark: Beautiful but expensive. Everyone wears gorgeous, sustainable, layered clothing. This makes sense given how much colder it is than NZ. Metro made it so easy to get around. Bikes everywhere.
• Amsterdam: Visited to explore Amsterdam and also for a bunq hackathon (reflection here). I loved the vibe, though getting around without a bike was slow. So a bike is the first thing I’m getting once I live there. Free ferries were fantastic!
• Italy: Five days in Rome. It felt like you could walk in any direction and stumble onto a grand church or building. The food here was the best I’ve had anywhere, once we found one particular shop’s tiramisu we ate three in a single day. Also saw Michelangelo’s Creation of Adam on the Sistine Chapel ceiling, the scale of it is hard to describe. I guess it was well over 4 years of his life!
• Croatia: Some of the best scenery I’ve seen outside of New Zealand. We hired a car and drove from Zagreb to Split, stopping at the Plitvice Lakes National Park in between for some incredible waterfalls. Driving on the opposite side of the road took adjusting (NZ left-side and Croatia right-side), but having a car unlocked so many random stops for our journey.
• Serbia: A taxi driver suggest Burek to me and I ate it most days. I learnt about Belgrade’s hectic history, even up until recently. I’m in awe of what people there have survived, over four passport changes in the last 25 years and across many different occupations. We were told it’s because of Belgrade is positioned on the Danube and Sava rivers, prime real estate with a fortress that holds the high ground.

Scrolling through job listings this past month, I noticed roles titled DevOps Engineer or Platform Engineer or Infrastructure Engineer that were listed with almost identical responsibilities.

I know innately that these roles have some differences, but the titles are often used interchangeably by hiring teams.

Where DevOps came from

DevOps is a word created from the combination of the words Developer and Operations. To understand why that portmanteau word became a job title, you need to understand the problem it was trying to solve.

Traditionally, software teams were split in two. Developers wrote code in one room, and an Operations team —sometimes called Ops— deployed and ran that code in production. Each group had different incentives e.g. devs wanted to ship fast whilst ops wanted stability. That tension caused friction, slow releases, and potentially a blame culture when things broke.

The DevOps movement, popularised in part by The Phoenix Project (Kim, Behr, Spafford, 2013) and The DevOps Handbook, proposed a cultural fix to tear down that wall. If developers owned their code all the way to production, they’d build with operability in mind. They’d care about deployment pipelines, alerting, and recovery because those things would become their problem too.

DevOps is meant to be a shared practice of principles across teams, and not a single person’s role. But organisations found it easier to spin up a DevOps teams or hire someone with the DevOps title who embodied that DevOps mindset to show some adoption of “DevOps” when it was first cool.

What a DevOps Engineer actually does

In practice, the DevOps Engineer tends to be embedded within a product team, sometimes as the only person with that focus. Their job is improving the speed and safety of getting code from a developer’s machine into production.

That means CI/CD pipelines (think GitHub Actions, TeamCity, CircleCI, or similar), automated testing, deployment automation, monitoring and alerting, and security gates. If a developer is waiting too long for a build, or a deployment is a manual, error-prone process, the DevOps Engineer is the one called on.

My own experience working in this role felt exactly like that: a solo DevOps expert embedded in a development team, focused on making the production path faster and more reliable. In smaller companies you will probably get the opportunity to pick up other development tasks outside of the usual job description. This helps you experience the pain that engineers go through to build better solutions.

Platform Engineering

Platform Engineering has similar tools and similar outcomes, but from what I’ve seen, the scope and audience are different.

Where a DevOps Engineer typically serves one team, a Platform Engineer serves many. This role, I think, is oriented around building an Internal Developer Platform (IDP). An IDP is a curated set of tools, templates, and standards that every engineering team in an organisation can use. The CNCF communities often describe this as building golden paths: opinionated, well-maintained routes that make the right thing the easy thing for developers to do.

Think of it as the difference between solving a problem for your team versus building the infrastructure so any team can solve that problem themselves. Platform teams treat internal developers as their customers. They build self-service tooling —things like standardised deployment workflows, observability stacks, or secrets management patterns— so that product teams don’t have to reinvent those wheels independently.

This tends to appear at larger organisations, where inconsistency across teams becomes a bigger cost. At a company with ten engineers, one strong DevOps person can handle everything informally. At a company with five hundred, the absence of shared standards can create chaos.

The tradeoff here is somehow creating efficient standards to keep things stable, but also giving optionality to engineers so they have autonomy over the tooling they choose.

A good tool to know about is Spotify’s open source Backstage tool: https://backstage.io/

Infrastructure Engineering

Infrastructure Engineering overlaps with both DevOps and Platform, but sits slightly further from application code in my experience.

An Infrastructure Engineer is typically focused on the foundations: cloud architecture, networking, access management, and the security controls that sit beneath the application layer. They’re thinking about VPCs, subnets, firewall rules, load balancers, DNS, and how services communicate across boundaries. Often this involves deep expertise with IaC tools like Terraform and close familiarity with the cloud provider’s lower-level primitives.

A DevOps Engineer might spend their day modifying a GitHub Actions workflow or adjusting a Dockerfile. An Infrastructure Engineer might spend theirs designing the network topology that those pipelines eventually deploy into.

That said, in my experience, in any organisation you have problems to solve and there is never a clean separation. So you’re owning all of it, and carrying all three titles simultaneously whenever something is required.

Why the roles overlap

There are more than the three role titles I’ve talked about too, e.g. Systems Engineer, Site Reliability Engineer, Integration Engineer, and many others that cover similar responsibilities with decent overlap.

Part of it is because fashionable titles shift over time; DevOps was the go-to term but now it feels like Platform Engineering is. This is probably because it better captures the product-focused, team-of-teams thinking that scales for devops/platform teams.

Each organisation decides on responsibilities differently depending on team size, product maturity, culture in the industry, and even the background of whoever’s hiring. So the title they’re given is essentially a best guess based on responsibilities required at the start of the role, which often morphs into different roles as projects progress.

A startup with five engineers often doesn’t have the headcount for specialisation. The person managing Terraform, building the deployment pipeline, and configuring the VPC is doing DevOps, platform, and infrastructure work all at once.

At larger companies, the separation becomes more meaningful. A Platform team with a product mindset and a roadmap looks very different from a DevOps Engineer embedded in a squad, even if both are deep into Kubernetes on any given Tuesday.

Read the job description

After reading many applications, the practical lesson is to read past the title and into the responsibilities. A “Platform Engineer” role at a thirty-person startup will look nothing like the same title at an enterprise company. A “DevOps Engineer” role at a bank might be closer to what a Platform team does at a tech company.

The questions worth asking in an interview: Are you embedded in a product team or sitting in a centralised infrastructure group? Are you building tooling for developers, or helping productionise a single product app? What does ownership look like when something breaks at 3am?

I like that DevOps Engineering is broad; I like having the option to do whatever is required to get the job done.

So, I’m refreshing my understanding and reflecting on it here.

Important terminology and tools

An important distiction is the difference between Authentication and Authorisation. Authentication asks “are you who you say you are”, while Authorisation says “I know you, but are you allowed to do what you’re trying to do”.

Infrastructure-as-code (IaC) is self-explanatory, it allows you to codify your infrastructure changes. Letting you track infra changes over time, and efficiently keep the infra actually deployed in line with your intentions. When there is drift between intentions and actual, IaC helps it realign.

Terraform is a great tool for IAC, and is the focus for this reflection.

There are many other tools that help with IaC including CloudFormation and Ansible. CloudFormation is AWS’s solution for the IaC giving declarative provisioning, but its locked to AWS. Ansible is more focused on configuration management and orchestration once infrastructure exists, though there is some overlap with IaC.

CI/CD is Continuous Integration / Continuous Delivery. It is a mindset with many tools that helps our code build, test, and deploy safely for our users. GitHub Actions our CI/CD tool of choice. There are others like TeamCity, Circle CI, Jenkins, Octopus Deploy, GitLab CI etc.

When mentioning MacBook it could be any developer machine enabling you to make infra changes by running Terraform.

Given all of this, there are two main use cases:

• Human to machine - Connecting MacBook to AWS
• Machine to machine - Connecting GitHub Actions to AWS

Both use cases need to authenticate and authorise, but they do it using different methods. We’ll explore that difference in the upcoming sections.

Human to machine

When running Terraform from your laptop, the industry standard is to authenticate with AWS SSO (rebranded as AWS IAM Identity Center in 2022, though the CLI commands remain the same).

From the terminal you run an aws cli command that opens your browser, asks you to log in using your identity provider (or aws creds), and grabs a short-lived credential for use during your AWS terminal session. It normally expires after 8 hours, but this is configurable. Terraform picks up that short-lived credential and uses it to configure the infrastructure however you’ve defined.

# day to day example (assumes sso roles are setup)
aws sso login --profile terraform
export AWS_PROFILE=terraform

terraform apply

These commands work because there’s a human in the loop. Developers can login to AWS, click a button, and complete an MFA prompt. It’s verifiable that you are the person at the keyboard.

This is not possible the moment you’re out of the loop.

Machine to machine

A GitHub Actions CI/CD pipeline can’t easily open a browser or tap an allow button on your phone. It needs to authenticate to AWS without a person in the loop, securely, and without any of the interactive trust mechanisms that make SSO work locally.

The old answer was to generate an AWS access key pair, paste it into GitHub as a secret, and let the pipeline use that to authenticate with AWS. This still works, but it’s a liability and no longer recommended. Long-lived access keys, if leaked, can grant authentication to whoever gets them. Unfortunately, because infra work requires a broader set of permissions, losing these keys is a bigger security risk.

Long-lived keys should also be rotated frequently (i.e. rotating means to update the keys). That requires additional reminder scheduling, and if the key is used in many places, the work to update might require a bit more effort.

The better answer is Open ID Connect (OIDC). To understand OIDC, you have to understand JWTs first.

JWTs

JWT stands for JSON Web Token. It’s a compact, self-contained token for passing claims between parties.

A claim is a key-value assertion about a subject, e.g. "sub": "user_123" or "email": "john@example.com". The issuer party (AWS or GitHub) is saying: I assert these properties are true about the subject of this token (and that it is valid for the stated audience and time window)

What might be at first surprising, is that a signed JWT isn’t encrypted and anyone can read it. Paste a JWT string into jwt.io and you’ll see everything inside (with real tokens, keep them out of public tools!).

The point of JWT tokens isn’t secrecy, it’s integrity. If you trust the issuer’s public key, and the signature checks out, then you can trust the claims.

Think of it like a driver’s licence, it’s contents are not a secret (anyone who physically holds it has the info), but it’s validity is trusted because it was created by a trusted authority. Other parties (police, security, the supermarket cashier) recognise it and trust what it claims.

A JWT is a string with three parts separated by dots. Header, payload, and signature.

<header>.<payload>.<signature>

The header says how it was signed. The payload is a set of claims or facts about whoever the token is describing. The signature is the issuer’s cryptographic stamp.

E.g.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjdXJpb3VzX3JlYWRlciIsIm5hbWUiOiJZb3UsIHRoZSBjdXJpb3VzIG9uZSIsIm1lc3NhZ2UiOiJUaGV5IHNheSBjdXJpb3NpdHkga2lsbGVkIHRoZSBjYXQsIGJ1dCBpdCB3b24ndCBraWxsIHlvdS4gU3RheSBjdXJpb3VzLiIsImlhdCI6MTc0NjY2MjQwMCwiZXhwIjo5OTk5OTk5OTk5fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can read more detail here: https://www.jwt.io/introduction#what-is-json-web-token

OIDC

OIDC (OpenID Connect) is how JWTs get used for authentication. An identity provider mints a signed JWT about who someone is or what it’s doing, and a relying party verifies the token and decides what to do.

Back to the analogy of a JWT and a drivers license. The issuing authority is whoever grants drivers licenses, in New Zealand this would be NZ Transport Agency (NZTA or Waka Kotahi). The relying party, again, could be police, security, or the supermarket cashier.

For your CI/CD, GitHub is the identity provider and AWS is the relying party. GitHub publishes its public keys at a well-known URL. AWS knows where to find them and when the workflow pipeline runs, GitHub mints a JWT describing that specific job (the repo, git branch, the workflow file) and signs it. The pipeline hands the token to AWS, AWS verifies the signature, reads the claims, and decides whether to issue short-lived credentials.

There’s no shared secret and no pre-arranged handshake. You declare in your AWS account that you trust GitHub’s issuer URL and from that moment, AWS knows how to verify any token GitHub signs.

This grants you authentication, and next it’s important to look at the policies that grant authorisation to make changes.

The trust policy

With the authentication and JWT verification mostly handled by AWS & GitHub, you can focus more on deciding which GitHub claims you’ll accept.

For example, every JWT GitHub mints contains a sub claim, i.e. the subject

repo:my-org/my-repo:ref:refs/heads/main

That string identifies exactly which repo, branch, or trigger produced the token. Your trust policy in AWS is a set of conditions on those claims. So if you pin the sub claim to a specific repo and your main branch (like the above example), then only that combination can assume the role.

Set up the AWS trust policy too loosely and you replace one risk with another. The biggest mistake is wildcarding the subject repo:*, which means that any repository on GitHub could potentially assume your role. The fix is to only give access to specific repositories that need it, following least privilege access. Most tutorials highlight this point too.

Using GitHub environments

Many tutorials suggest the use of GitHub Environments for production deploys. So you can pin the trust policy to repo:my-org/my-repo:environment:production. You then set up your repo to require manual approval on production deployments, thus adding another layer of protection. Now even a workflow on main can’t deploy until a human clicks a button.

For an enterprise team, this makes sense. Multiple people merging code, the reviewer and the deployer might not be the same person. So the approval gate gives you a real second pair of eyes.

For a solo project without actual customers it’s optional, but worth knowing the pattern exists for when the team grows.

Relearning

Coming back to OIDC after a year of travel, I noticed new details since the first time round. Especially in terms of trust policies, and why the sub claim specificity matters. Going back to first principles about JWTs and OIDC before touching any config gave that stronger mental model.

If you want to see how someone might configure all of this, check out my repositories here:

• AWS Foundation SSO & OIDC setup: https://github.com/wjkw1/aws-foundations
• Demo Application: https://github.com/wjkw1/devops-profile-coffee-card-app-demo

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.

Naming convention decision

Final name: tfstate-{AccountId}-{GitHubRepo}

Example: tfstate-123456789012-aws-foundations

Why this name

The convention earns its structure because I’m committing to one terraform state bucket per project.

So, the three pieces of information communicated in the bucket name:

The convention scales cleanly: every future infrastructure repository gets tfstate-{AccountId}-{GitHubRepo}, with no naming decisions to revisit.

Options considered and why they were rejected

tfstate-aws-foundations

Not globally unique, and almost certainly already taken thanks to the known limitation of S3. It also encodes the github project name in a bucket originally conceived as potentially holding all account state. Once my intent changed, the name became misleading.

tfstate-{AccountId} (original)

Unique and future-proof, but loses the repo link. Fine if one bucket holds state for many projects; less good when the bucket is scoped 1:1 to a single repo, where the link has real navigational value.

{AccountId}-aws-foundations

Globally unique, still links to the repo. But without a tfstate indicator, anyone browsing S3 has no immediate signal about what the bucket is for. The AccountId prefix also groups infrastructure buckets together when sorted, at the cost of reading unnaturally left-to-right.

aws-foundations-{AccountId}

More readable than the account-first example, same repo link. Still missing the tfstate indicator.

tfstate-{AccountId}-aws-foundations (chosen)

Purpose is obvious. Guaranteed to be unique. The 1:1 GitHub mapping is perfect. The tradeoff: twelve digits in the middle makes the name long and not great to say out loud. That cost is low because this string gets typed approximately twice in the bucket’s lifetime – at creation and in versions.tf – so conversational readability is not important.

Convention going forward

tfstate-{AccountId}-{GitHubRepo}

Other projects I create that require aws infra will each get their own S3 state bucket following this pattern.

This gives me state isolation between projects; a terraform mistake in one project cannot affect another, and state files stay small and fast.

I think that’s only half the story.

Chasing threads is about following inspiration when it strikes.

During my induction week as a graduate engineer, over seven years ago, I was told a story about our CEO. It’s where I first felt encouraged to be curious at work.

The CEO had a planned visit to one of our front-line Telco stores. All staff were prepped with questions and had a stacked agenda for photos and content capture. When the boss arrived, he spotted a staff member off to the side, absorbed in something (repairing a device, restocking a shelf) I can’t quite remember.

He walked over and simply asked: “Hey what are you doing?”

Whoever this person was, they spoke about what they were doing with such genuine passion and joy that the CEO scrapped the rest of the agenda entirely. He spent the whole visit just talking with this one person about technology, about their goals, about what they loved about the job.

That conversation turned into a friendship. They kept in touch across the year. And eventually, that staff member grew into a role back at headquarters. All because the boss saw someone doing something that looked interesting, and went and spoke to them.

Do you know the feeling? You’re reading something and a word catches you, you look it up, and suddenly you’re twenty minutes deep into the history of something you never knew you cared about.

The conventional wisdom says to ignore that. To get back on task and stay on track.

But what if the thread is the track?

Here’s the reframe I often come back to: life is distractions. It’s the distractions the give life meaning. Not in the doom-scrolling-at-2am sense. In the sense that the interesting stuff, the stuff that actually shapes who you are, rarely arrives through the front door. It sneaks up on you. It’s the thing you weren’t supposed to be doing that ends up mattering most.

Steve Jobs is probably the most famous example of this. In his 2005 Stanford commencement speech, he talked about dropping in on a calligraphy class at Reed College out of pure curioisty, with no practical application in mind. A decade later, that class became the foundation for the beautiful typography of the first Macintosh.

He didn’t chase calligraphy because it was strategic. He chased it because it pulled at him. Same instinct as a CEO who walks past a stacked agenda to talk to someone doing something interesting. Same instinct as anyone who follows a word into a twenty-minute rabbit hole and comes out knowing something they didn’t expect to care about.

But I have to be honest with myself, because this idea has a dark twin. Something a colleague of mine introduced me to because I was chasing the latest technologies all the time.

There’s a concept called Shiny Object Syndrome. The idea that some people —especially curious, creative, entrepreneurial types— get so drawn to the next interesting thing that they never actually go deep on anything. They bounce from project to project, tool to tool, always chasing novelty, never building something real.

I’ve been there. Most curious people have. You pick up a thread and it leads you to another thread, and another, and before you know it you’ve spent a whole day falling down rabbit holes and nothing is finished.

The shiny ball of yarn is real. And if you’re not careful, chasing threads becomes a sophisticated-sounding excuse for avoiding the hard, slow, unglamorous work of actually finishing things.

The difference between a thread worth chasing and a shiny object isn’t obvious in the moment; but it becomes clear with a bit of distance. If you park an idea for a few days and it’s still pulling at you, it’s probably a thread worth chasing. If you forget about it, then it probably wasn’t worth following anyway.

So go chase your own threads. Not all of them and not recklessly. But when something tugs at you, don’t immediately dismiss it as a distraction.

Linting and formatting code

Recently, while working on a personal DevOps project, I spent some time looking into linting tools. They amazingly save your brainpower for the actual problem, instead of code styling. Whether it’s two spaces or four per indent, single quotes or double, I don’t mind. Other people have thought deeply about these trade-offs, landed on reasonable answers, and codified them. I’m happy to piggyback on that.

I aim to write code that works, and let the styling happen automatically.

There’s a side benefit too: when a codebase consistently uses a popular linting tool, anyone familiar with it can scan the code and immediately know where to look. It’s like how headings in a research paper let you scan before you commit to reading.

Three touchpoints that matter

Good linting hygiene should show up at meaningful points in your development lifecycle:

1. In your IDE (or text editor), as you write
2. Locally, before you commit
3. In CI/CD, before code merges

Each layer serves a different purpose. Together, they make code quality essentially automatic. (Tools like SonarQube go deeper —security, coverage, and code smells at a project level— but that’s a reflection for another time.)

In the IDE (or text editor), I use VS Code with the relevant extensions installed and Format on Save enabled. It does what it sounds like: when the file saves, the formatter runs. Sometimes this needs dev dependencies installed to work properly; check the official docs and you’ll figure it out quickly, I’ll go into Ruff for Python specifically later in this post.

Locally, before committing, is where things get interesting. At various companies I’ve seen the same pattern repeat: developer forgets to format, pushes code, CI fails, they fix locally, force-push, CI reruns. This adds ten minutes to the dev cycle, minimum. Multiply that across a team and it adds up quickly.

Git’s pre-commit hooks solve this cleanly. When you attempt a commit, a hook runs your formatting and linting checks first. If they fail, the commit doesn’t go through. This means no broken CI and no annoying formatting fix commits. This enables the code to validate itself before it ever leaves your machine.

The one catch: developers can skip the setup step entirely, which is exactly why the third layer exists.

In CI/CD, the pipeline enforces what the pre-commit hook encourages. Even if someone bypasses local hooks, nothing merges unless the linting passes. This is your actual quality gate and is what you rely on.

Why Ruff instead of Black and Flake8

Three or more years ago, I used Black for formatting and Flake8 for static analysis. Two tools, two configs, two things to install and maintain. It was a minor friction, but that friction compounded and was a little naff.

Ruff replaces both with a single tool. It’s faster, simpler, and opinionated enough that you don’t have to make many decisions. For a project where the point is less thinking about styling and formatting, that’s exactly what I wanted.

The Setup (Python / FastAPI)

Three things to configure, in roughly this order:

Step 1: VS Code + Ruff extension

Install the Ruff extension from the VS Code marketplace — the official one is published by Astral (charliermarsh.ruff). Once installed, add this to your .vscode/settings.json:

{
  "[python]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  }
}

Committing .vscode/settings.json to the repo is intentional. Anyone who clones the project and opens it in VS Code gets the same formatting behaviour automatically. No extra knowledge required.

No separate Ruff installation is needed as the VS Code extension ships its own binary, and the pre-commit hook (added in Step 2) bundles its own too. You just need to add your Ruff config to ruff.toml:

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "I"]

The select block opts into pycodestyle errors (E), Pyflakes (F), and isort import sorting (I). This covers what you’d previously have needed Black, Flake8, and isort to do separately.

Step 2: Pre-commit hooks

First, install the pre-commit package:

pip install pre-commit

Then create a .pre-commit-config.yaml in the root of your repo. Here’s exactly what’s in the project:

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.11.4
    hooks:
      - id: ruff
        args: [--fix]
        files: ^api/
      - id: ruff-format
        files: ^api/

A few things worth noting here. The files: ^api/ pattern scopes the hooks to the API directory only — the frontend has its own linting story (ESLint + Prettier), so there’s no point running Ruff across the whole repo. The ruff hook handles lint checks and the --fix flag means it’ll auto-fix what it can rather than just reporting issues. The ruff-format hook handles formatting, equivalent to what Black would have done. Once the file is in place, install the hooks:

pre-commit install

This wires the hooks into your local .git/hooks/pre-commit. From this point, every time you run git commit, Ruff runs first. If it finds issues it can’t auto-fix, the commit is blocked and the problems are printed to the terminal. Fix them, stage the changes, and commit again. You can also run it manually across all files at any point:

pre-commit run --all-files

Useful for a first run after setting up, or after pulling in changes from someone else who hasn’t had the hooks installed.

That’s it. Once it’s done, your automatic project linting works in the background. Which is perfect.

What is the C4 Model?

The C4 Model is a structured, uniform approach to describe the architecture of a software system at different level of detail. Instead of throwing everything onto a single diagram and hoping people get it, it organises abstractions in a way that mirrors how developers or software architects tend to think about systems.

The 4 levels are:

1. System Context - the big picture: your system and how it interacts with users and other systems.
2. Containers - the applications and data stores that make up your system.
3. Components - the building blocks of each of our containers.
4. Code - the classes, interfaces, and functions that implement each component. The official definition explains it best:

   A software system is made up of one or more containers (applications and data stores), each of which contains one or more components, which in turn are implemented by one or more code elements (classes, interfaces, objects, functions, etc). And people (actors, roles, personas, named individuals, etc) use the software systems that we build. Source: https://arc.net/l/quote/kvovhsbn Visit the official website to read more detail about this framework.

The map is not the territory

A book called The Great Mental Models: General Thinking Concepts has a chapter called “the map is not the territory”. The idea being that the granularity of Google Maps, does not show the same level of detail as someone walking around on the ground. This is a similar line of reasoning useful when thinking about the C4 diagram. For most intents and purposes, the maps context is enough to be useful at a high-level. But sometimes, we need more detail to understand what is going on under the hood. That’s why we have these layers of abstraction, and at each abstraction we are targeting a different audience.

The caveat at the code level

The creator of this framework, Simon Brown, recommends never manually building the lowest level C4 class diagram. It’s not worth the effort of building, and definitely not worth keeping updated; especially with the pace at which software changes nowadays. The level of detail is normally so closely related to code that it can (and should) be generated automatically. This is a pragmatic acknowledgement that diagrams are tools, not artefacts to be maintained for their own sake. If a diagram can’t keep pace with reality, it quickly becomes a source of confusion rather than clarity.

Examples from a personal project

I’ve been applying this framework in a recent pet project. If you’d like to see the diagrams in action, head over to the demo project here: devops-profile-coffee-card-app-demo.

Context

Containers

Components TBD

Coming soon…

“a website containing a writer’s or group of writers’ own experiences, observations, opinions, etc., and often having images and links to other websites.”

A reflection has many meanings, but the two I latch onto are:

• a fixing of the thoughts on something; careful consideration.
• a thought occurring in consideration or meditation.

The word reflections carries a quieter, more inward energy for me. It implies that you’re writing for the process of thinking, not for an audience or an outcome. I love that there is no implicit pressure to grow a following, monetise, or be consistent on a schedule.

My perception of blogs is that they come loaded with baggage nowadays. It asks for SEO optimisation, calls to action, newsletter signups, and the hustle of content creation. That’s a very different thing from sitting down and genuinely processing your thoughts on paper.

This is why I choose to use reflections, to give me freedom of thought while writing thoughts on a page.

meta – Posts about this site itself – announcements, changes, meta type entries. Use when: the post is about the website or process specifically, not a topic within it.

ai – Artificial intelligence, large language models, and how I’m using them in work or writing. Use when: the post is primarily about AI tools, AI tech, or AI behaviour

career – Work, professional growth, team dynamics, and lessons from the industry. Use when: the post reflects on the people side of software – roles, culture, collaboration.

communication – Explaining ideas about communicating, for example to non-technical audiences, across teams, or in documentation. Use when: the post is about how we convey information to other people.

conference – Notes and reflections from conferences I attend. Any conference I go to gets written up here. Use when: the post is about a conference or event I attended, its talks, and what I took away from it.

definitions – Posts that define how I use a specific term, phrase, or concept – personal vocab entries. Use when: the post is structured around explaining what something means to me.

devops – Platform engineering, infrastructure, CI/CD, and the operational side of software. Use when: the post is about systems, pipelines, or keeping things running.

devtools – Tools that shape how I work - editors, CLIs, SSH, local setup. Use when: the post is hands-on with a specific tool or workflow.

writing – Reflections on the writing process, publishing, and finding my voice. Use when: the post is about writing itself, not just a post that happens to be well-written.

1. Start that “thing” today—not tomorrow, and not next week.
2. Getting started doesn’t require structure, an official tutorial, or any special gear.

‍Setting the scene

I’ve got no idea what I’m doing. I don’t know what software to use, but I do know that I don’t want to pay for anything—at least not until I’m sure making music is something I actually want to pursue.

First things first, I set out to find the “best” software to experiment with, without breaking the bank. For me, “best” meant: no cost, offline mode, a UI that isn’t ugly or archaic, easy-ish to experiment with, and something with learnings that transfer to a more advanced product later on.

In the past I tried Spotify’s web UI music creation tool, but it was only online so could only be used while I had internet, the lag wasn’t fun and it cost money quite quickly after the trial.

I like Fred again’s music, so I wondered what software he uses - apparently he’s a Logic Pro pro. Perplexity reckons Logic Pro is basically an overpowered and extended version of GarageBand. GarageBand comes for free with Macbook’s OS…so I went with GarageBand.

‍Getting started

At this point, I would normally pause there and think “job done”, lets continue tomorrow. I have two reasons why I didn’t want to pause:

1. Recent content I’ve been consuming has encouraged more personal agency. Books like 4-hour workweek or Modern Wisdom’s podcast interview with Naval Ravikant.
2. I read numerous articles of people starting with the only the simplest tools, making music only off their phone

So, using Atomic Habits tricks, I told myself to make music for 5 minutes. Without needing to even downloaded the software, I spend over an hour, hopping around the interface, trying to make a simple beat with the software MIDI controller.

No theory, no structured learning, no tutorials, just dive in and try it out. This worked well for me, and here is the first beat I made:

https://soundcloud.com/westernwilson/music-day-1

Before this, I didn’t know what a MIDI controller was or what a DAW was. (MIDI stands for Musical Instrument Digital Interface and DAW is what GarageBand is, and it stands for Digital Audio Workstation). Now I kinda do???

Honestly, taking a course or chatting with someone more experienced might be a good idea soon. I’ve thought about reaching out to Dera Meelan—someone I’ve enjoyed since hearing his track “Fire Sale” with Church & AP.

A few days past and here was my second beat:

https://soundcloud.com/westernwilson/music-day-2 ‍ If you have any pointers, reach out on any socials or at kiaora@westernwilson.com 🙏

‍Final note

There are many successful podcasters whose early podcasts sounded like they were recorded in a bedroom closet, sounding unpolished with bad scripts/questions. But no shade, I think that’s how it should be, that’s how you should start.

Point is, you can start today, and you can bootstrap it with minimal investment. Don’t spend on the best equipment if you’re not even remotely sure you’ll want to stick with it in a year; heck, you might quit after a couple of weeks.

Persevere with whatever you’ve got going on. Good luck, and stay curious!

Setting the scene

First a bit of background, I’m a copious note-taker. I’ve been this way ever since I was a wee boy. Writing notes helped me focus on the speaker better, even when my notes tended to be more of a gibberish scribble and mostly illegible for future Western. With physical note taking however I would consistently forget my notebooks and have to write on spare paper. Then I’d lose the spare paper and the state of my notes was a mixed bag. So, I shifted to digital notes to try solve this problem. What have I tried? Google Docs and Drive, OneNote, BookStack, Wiki.js, Confluence, Notion, Evernote, Obsidian, Google Keep, and others.

Unfortunately, no tool was perfect; they all missed one aspect of my requirements, or felt clunky, or had features locked behind paywalls, or couldn’t be used while travelling without Internet access (Notion, I’m looking at you!). My requirements:

1. Offline notes with online sync
2. Free with no paywall
3. Cross-platform – Windows, Mac & Android
4. The Notion-like block WYSIWYG text editing
5. Configurable to use PARA to organise notes (recent ~5yr old requirement)
6. Markdown export so I’m not locked into a tool
7. Great security
8. (optional) Graph view to show linkage between notes, so you can see grouped ideas
9. (optional) Import function or API to script the import
10. (optional) Collaboration with other note takers

Introducing AnyType

AnyType hits every requirement above and took them further; open-source, offline first, free forever, online peer to peer sync between cross-platform devices, block editing with Markdown text shortcuts, AnyType Gallery to share and use community templates, great security first, imports and exports, graph view, API and basic collaboration features. The app is positioning itself as a web3 everything app built on freedom and trust. They’re building something special here and since it’s inception has consistently improved month on month. It’s much more polished than it used to be, it’s a joy to work with nowadays. I’ll explain some of the features below, but honestly the best way to get a feel for it is to download and try it yourself: https://download.anytype.io/ The main concepts in AnyType to understand are:

1. ‍Objects - all things are objects in AnyType ‍
2. Types - categorise the Objects you create to have a Type ‍
3. Properties - attach metadata to Types and create relations between them ‍
4. Query - List view showing a single Object/Type
5. ‍Collections - Folder-like collection of different Objects/Types
6. ‍Templates - speed up your workflow with pre-defined templates for object creation

For example, to create a Book tracking system, you could define:‍

1. Book type with the properties: Title, GoodreadsUrl, and links to an Author
2. Author type with the properties: name & bio‍
3. Quote type with a property that links to our Book

Now, when you create a new Book, you can link it to a new or existing Author and write whatever notes about the book that you want. Then when inspired by a Quote, you can create a Quote and link it to your Book. The note taking is flexible, linkage can happen anywhere organically, and you can write whatever you want from within the Author, Book or Quote types. AnyType allows and in fact encourages these relationships between Types.

Quickly explaining PARA

If you’re new to Tiago Forte’s PARA methodology, you’re in for a treat. PARA is a simple yet powerful system to organise your digital life—whether that’s notes, projects, or files—into four clear categories. It stands for:

• ‍P - Projects: Active tasks or outcomes you’re currently working on. ‍
• A - Areas: Ongoing responsibilities or spheres of activity without a specific end date. ‍
• R - Resources: Useful reference materials or topics of interest.
• ‍A - Archives: Inactive items you want to keep but don’t need right now. As you use this system over time, you’ll develop an intuitive sense for where each note belongs. The key mindset shift for me was letting go of the need to choose the “perfect” category and remembering that it’s easy to move things around later.

How I use PARA within AnyType

Using PARA inside AnyType means you can create custom Types and Properties for each category, linking notes, tasks, and references easily. You can quickly switch between your active Projects, Areas and Resources, while your Archives keep everything tidy but accessible. I created a Template Space that should be available to copy from the AnyGallery thanks to my approved github submission. I’ll explain how it works below.

Key features‍

• PARA Dashboard is a Query of type Queries with a custom property PARA Type set to PARA
• Projects, Areas and Resources are a Query of Collection objects with the PARA Type set to Project, Area, or Resource respectively.
• A collection with an Is Archive property checked will show as Archived on the various dashboards.

1. ‘PARA Type’ Classification

• Introduces a dedicated “PARA Type” property that allows you to specify whether a Collection is a Project, Area, Resource, or **PARA.**‍
• When a Query’s PARA Type is set to PARA it will show on our PARA Dashboard.
• When a Collection’s PARA Type is set to Project, Area or Resource, they will display on their respective Query of Collections dashboard i.e. Projects, Areas, or Resources
• This structure makes it easy to filter, group, and view your content according to the PARA methodology.

2. ‘Is Archive’ Property

• Every Collection includes an Is Archived property.
• Easily mark items as archived to declutter your active workspace without permanently deleting anything.
• Archived items are automatically filtered out from main views but remain accessible for future reference.
• See all archived Projects, Areas and Resources both on the Archived query view, and also within their respective Projects, Areas, or Resources query views.

3. Manual Link Management via Templates

• Every Collection also has a “PARA Linked to” property, this overcomes a limitation I noticed where Queries were not showing on the Graph view for Collections created from their Query view.
• Templates automatically create this manual link property for each of our Projects, Areas , or Resources
• This linkage can be removed at any time, giving you control over what appears in the Graph view.
• Declutter your visual workspace by removing unnecessary connections, while still maintaining essential relationships.

How it all works together

• ‍Creating New Projects, Areas or Resources: Templates are used by default to add new Projects, Areas, or Resources. Each template ensures the correct PARA Type and properties are set when creating an object from each dashboard.
• ‍Change PARA Type: Updating the PARA Type property on a given collection will move it between Projects, Areas or Resources as needed. This is especially helpful if, for example, a Resource evolves into a Project later on.
• Creating New Objects: Within any specific Project, Area, or Resource, you can add any object—the default is a Page—and it will be created with the appropriate properties. You can link any type, such as Tasks, Bookmarks, Books, Quotes, literally any Type.
• ‍Manually Link to PARA: Use AnyType’s “Link to Collection” feature to link any object newly created to a specific Project, Area or Resource yourself. This is particularly useful in Graph view if you like to see clusters of related information.
• ‍Archive Projects, Areas or Resources: Archiving is handled with a simple checkbox field on Collections that have relevant PARA Types.

Shared Gallery

There’s a wide variety of community-created templates available for AnyType, giving you plenty of options to explore and enhance your workflow.

It’s easy to import and play with them too, simply go to the gallery and import it into a new space. While you can import templates into existing spaces, be mindful that this may introduce extra Types and Properties, potentially cluttering your setup and making cleanup tedious. So my advice is to first verify the new Types and Properties in a new, isolated space before merging them it into your main spaces.

Conclusion & Next steps

If you’ve made it this far, congratulations! Hopefully, you’ve picked up something new and feel inspired to try out AnyType or the PARA system for your own daily organisation.

Bonus note on AnyType’s API & MCP server

Recently AnyType added an official API and Model Context Protocol (MCP) server. This advancement allows AI agents and assistants to interact with and update your documentation directly. In the docs here they highlight RayCast.ai for seamless AI Chatbot integration and workflows.

With these tools, RayCast turns your AnyType knowledge base into an even more powerful resource—ready to answer your questions and automate parts of your note-taking system.

My website has gone through many iterations and frameworks:

1. Static site using html, css & JavaScript
2. Gatsby.js React framework
3. Quick attempt at using Next.js React
4. Nuxt.js Vue.js framework
5. Now Webflow

My goal was to get something that worked easily, let me update a blog quickly, and didn’t require too much maintenance. Finally, I’ve achieved that vague and ambitious goal with Webflow.

Bit of historical context

Basic static site

While at University, near 2015 I was first learning software development as a main focus. I felt like I needed an online personal profile, but I didn’t really know how to do it. So across 4 years I managed to cobble something together, though it wasn’t pretty and I haven’t got any screenshots to show it off. My first profile website used basic html and css. Honestly, not enjoyable… the css process took so much time and tweaking that eventually it caused longer and longer procrastination breaks (gaming). I finally understood the devs struggling with css memes. Skip ahead to my first graduate job, I learnt there are other ways to develop and I trusted that there had to be an easier way than crying over css (joking). So, with the internet at my disposal, I searched for a modern framework to build and deploy my site.

GatsbyJS

The many rabbit-holes I ventured figuring out what the “best” framework was, watching YouTube, doing tutorials of each framework and creating starter programs. Eventually I realised I was thinking about doing, but not actually getting anywhere, so I just leapt into one of them. Introducing GatsbyJS, which at the time was a new React framework that helped build static sites quickly from templates, it even had blog plugins to make the whole process easier, so this was exactly what I was looking for… or so I thought. My basic knowledge of html, css, and javascript helped, but I had to learn React, JSX syntax, Webpack, and how to deploy my site. They had docs, but it wasn’t super polished so there was a lot of time spent figuring it out on my own. On a grad salary I was looking for the cheapest (free) options for hosting; there were two options: GitHub Pages and Netlify. First, I tried GitHub Pages and succeeded in deploying it, but the workflow was tacky, it required me to run a command from my local machine to deploy it, which didn’t feel right. I learnt about Git Flow and wanted it to deploy when I pushed up my code up to master (I know that’s not entirely correct, and am now aware that PRs and merges offer a nicer dev workflow flow, but at the time pushing to master was the way). So I moved to Netlify, which watched your repository for changes on a specific branch, and deployed whatever was there for you. This worked great for me, and allowed me to iterate with development on Gatsby quickly. However… as it was early on, the framework and plugins were changing often. Updating the npm packages caused the website to break so much that I gave up making changes to the website altogether. I resigned to allowing my website to exist in it’s current state. Until I got inspired by a front-end engineer at another company I worked at. For added context, my career was taking me down the DevOps Engineer pathway, but I still enjoyed playing around with front-end development. So I’d chat to other engineers about what they were doing and what they enjoyed using. This inspired my next framework choice that I thought would surely be easier.

NuxtJS

Inspired by my teammate, and with an expert to back me should I fall into any of the traps. I started building a Nuxt website. I gave up on designing a website and though, “lets just get something working”. Following through the docs I cobbled together a very basic website that used their content module to generate pages from markdown. This allowed me to at least write blogs using markdown text and the pages would generate on deployment. The deployment was done through GitHub Pages and I eventually got it deploying using GitHub Actions, which I was using more at work. This was great and Nuxt v2 was working well. Then the Nuxt v3 update happened, and all my shit broke. So I spend another weekend tweaking and figuring out why the content renderers wouldn’t load my blog pages from Markdown. Turns out the interface changed for how we loaded content, so the old method didn’t work. With that fixed, I happily added a blog about using ChatGPT or Perplexity to support my writing style. Woohoo!

Time skip to now

I’m taking a break from work, travelling asia (see /blog/now-june-2025), I decided to attempt to write blogs to capture my learnings while creating music. Looking ahead to writing 10 or more blogs, I realised how much of a hassle my Nuxt stack would be for updating and posting blogs. Changes required markdown updates pushed to a git branch and merged into main, I could immediately see this adding friction that would stop me from doing the actual blog writing. Also because of how I was loading blog images, it made the whole /public/img/ directory structure ugly, and in the future I would have a huge dump of images that were difficult to update. Honestly, I might not even write so many blogs that this becomes a problem, but this future problem was enough to distract me from making music. I didn’t want to create a big mess that I had to clean up later so I looked for another solution. I looked into WordPress quickly, which a couple older colleagues of mine used for their personal blogs and another colleague who built the company websites using WordPress. It would’ve worked, and been cheap, but I didn’t want to touch it. It felt old, and I knew there were better tools out there.

So, why Webflow?

I was on LinkedIn one day and saw a post from Nikolai teaching people how to use Webflow. Nikolai actually introduced me to webflow way back in 2017 and it’d been swirling in my brain ever since, it seemed like a great tool. It’s fantastic for Web Designer to build websites without worrying about the nitty gritty of maintaining a website with code. It still requires fundamental understandings of website development and html & css, but it’s mostly no-code. After the whole Nuxt Vue major update I thought I cbf with this, lets try Webflow out. I don’t want to pay for Webflow yet, thats why my site is only available on https://westernwilson.webflow.io, in the future I intend to upgrade it so I can use my personal website url under https://westernwilson.com

What is the development process like?

I kind of cheated a bit, I used their AI tool to design and kick-start my new and improved personal profile website, then I tweaked the required bits and here we have it, a new website! The tweaking of Webflow was much easier for me than the frameworks. Everything you need to understand is in their docs, and to publish is very easy. No updating of packages under the hood, and it all just works. To be honest, the Webflow structure I currently have could probably be improved, but I’ll leave it as is for now since it works. The major learning was configuring the Content Management System (CMS) that comes in-built with Webflow to store my blogs. Couple searches on the web and Perplexity helped me figure this out over a day or so. So now, I have a blog website that gets updated from a CMS. I’m stoked! Adding links or audio files is a lot easier than before too. You still need some understanding of how web development html tags are structured and how they pair with css styling, but for me this solution is perfect.

Final words

I’m happy with Webflow, because now I can focus on playing around making music and writing blogs instead of constantly upgrading and tweaking my website.

What do I want to do? Where do I want to be? Why am I doing whatever I’m doing? I don’t have a perfect answer to this, but I know that I can’t let perfection stop the process. So let’s focus on what I know:

• I love technology, devops, and coding, but I should diversify into other creative stuff
• I want to lead myself toward some form of creative expression
• I have a proven capability to learn
• The internet grants me unlimited access to learning resources & community
• In this age of “AI”, I can reduce feedback loops, fail-fast and experiment quickly
• I’ve always had an interest in music

With that list, I reckon it’s time to learn how to make beats.

Ideally I would have documented my progress on social media (Instagram, TikTok, or other), but I fear opinions that might stop me from committing long-term, especially in the early stages.

So, I’m going to quietly post updates on here, mostly for me, but also for anyone who finds it!

Good luck on your journey, and welcome to mine.

• 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.

Overview

VS Code is renowned for its versatility and has extensions for all types of development activities. This guide will show you how to harness its power as an SSH client, giving you a seamless development experience on remote servers.

What is VS Code?

Before we get started, let’s quickly clarify what VS Code is. Visual Studio Code, often referred to as VS Code, is a free, open-source code editor developed by Microsoft. It’s widely used in the software development industry and is known for its robust features and extensibility.

What is SSH?

SSH stands for Secure Shell, and it’s a network protocol used for secure data communication, remote command-line access, and other network services. It’s a fundamental tool for connecting to remote servers securely.

Official VS Code Tutorial

For a detailed, step-by-step guide on setting up VS Code as your primary SSH tool, please visit the official VS Code tutorial.

In a Nutshell

In a nutshell, here’s a brief overview of what you’ll find in the official tutorial:

• Installing the required VS Code packages on the SSH box.
• Installing the Remote Developer extension on your local machine’s VS Code.
• Setting up your SSH config file for VS Code for easy reconnection.
• (Optional) Creating an SSH key for effortless logins.

By enabling VS Code’s ssh capabilities you can centralise the tool you use for development. Happy coding!

Types of Developers in the Workplace

In a dynamic and collaborative workplace, you’ll encounter various types of developers, each driven by different motivations and approaches to their work. Understanding these developer archetypes can help foster a more effective and harmonious team environment.

1. The Detective

Drive: Detectives love to investigate. They thrive in messy situations, dissecting problems, and fixing them. Their analytical minds excel at uncovering the root causes of issues and implementing solutions. They’re the team’s problem-finders, and a lot of the time, problem-solvers.

2. The Cowboy / Go-getter

Drive: Cowboys or Go-getters are known for their speed. They push code out the door quickly, often impressively so. However, they might leave a bit of a “dirty sink” behind, sacrificing some cleanliness for speed. They’re the team’s high-velocity coders.

3. The Artist or Creative

Drive: Artists or Creatives focus on the aesthetics of code. They’re meticulous about making sure their code is not just functional but also visually appealing and highly readable. While they may code more slowly, their work introduces less technical debt. They’re the team’s code beautifiers.

4. The Mad Scientist

Drive: Mad Scientists are tech enthusiasts. They eagerly embrace the latest technologies and enjoy experimenting with new libraries and features. Their adventurous spirit leads to innovation and pushing the boundaries of what’s possible. They’re the team’s tech trailblazers.

In a balanced development team, these diverse types of developers can complement each other, fostering creativity, efficiency, and problem-solving. Recognizing and valuing these different approaches can lead to a more well-rounded and successful team.