AI is making platform engineers faster—but can we keep up with the pace of context switching

There are so many different areas that AI is involved in, it's impossible to cover everything in this blog post, but I'd like to try and highlight the good and the bad from a real use case from my own personal experience.

Context switching and idea exhaustion

These days, an AI model can see an idea through from planning to implementation very easily, with steering and input of course. I find the challenge is to sit down and take a moment to really think about what I want to tackle first, and why.

So many key areas remain at the forefront of any platform engineering strategy, this is not an exhaustive list, but to name a few:

• Security - such as supply chain attacks and secrets management
• Observability - obtaining genuinely useful alerts and reducing noise, and being able to trust the systems you have in place to find the problems before the make a substantial impact
• Automating the hell out of everything possible, without also making lots of 'black box' solutions which other engineers will never understand

The irony is that having such a powerful tool at our fingertips, which can be used to brainstorm and steer us, can sometimes feel very counterproductive. I find my priorities change from one week to the next, sometimes one day to the next. This is nothing new, but now we're able to be more productive and get things done at pace and in parallel, I still feel the need to slow down to get a real grasp of it. Sometimes, my head really spins...

Deliberately go slower sometimes

Having spoken to a lot of people I work with about this, and reading other online content, it feels like the focus is shifting from being coding experts to trusting (but verifying) AI agents work, and instead allow us to shift our focus to a higher level - know what to implement. I think it will make such a difference to step back and look at exactly what pain points can be addressed, and produce the most returns in terms of saving developer time (part of Dev Ex), which ultimately has a knock on effect with Platform teams - if developers are able to get things done much more efficiently, they will need less support from platform to get things done.

A Real world example

Back in early 2025 I thought to myself, at my organisation we're lacking an internal developer platform - an area for developers to self serve, reducing the cognitive overhead and additional knowledge they might need, to understand the likes of Terraform, Kubernetes, and CI workflows. They should be able to produce boilerplate code for whatever they're building without much hassle at all and even better, it remains consistent with our architecture approach and of course - secure.

So I spent a few days researching ready made IDPs (internal developer platforms), and began to deploy quite a well known framework and free solution - 'Backstage'. This product was originally developed in house by Spotify and then open sourced. It has a big community of maintainers and integrates with all the core components you would expect from a platform perspective. It looked great, although the caveat was, I'm not a react dev expert, either way I cracked on and provisioned a working platform (with the help of AI, of course!), so I was up and running quite quickly and started building out workflows and templates, to automate all the steps that I would expect to occur or at least be checked, including things such as ensuring app databases are added to backup workflows, adding security testing and so on.

A few months passed and I started to think, with all the new AI models and chat bots, why do developers need yet another internal platform to log into and navigate? Why not build a bot that gives them the information they need there and then? Or even better, generate the example code and send in the chat response, as it integrates with Slack? So I did that, and turned my attention away from Backstage. The bot had access to vector embeddings of all the GitHub README data I had produced over the years — great: fewer questions to me, more time for me to do other work.

A few months of use proved the bot was okay for general help and direction for developers. But it wasn't always correct, as you would expect, this is a known downside to AI, and with the multiple 'hats' I wear in my role, I didn't have the time to spend developing this to its full potential. Although some improvements have been made, it's still only correct around 90% of the time!

Context is everything

Recently I arrived on the latest idea. The bot was fine for answering simple questions about how something should be set up, but it still lacked the context of the overall infrastructure, our apps and our CI/CD pipelines; how we provision things, how we secure them, and all of the pieces in between.

This is where Claude Code and CLAUDE.md files came in nicely, and the larger context windows with their latest models really help bring it all together.

I won't take credit for this idea, as it stemmed from conversations within the business with colleagues, but the concept of a 'parent' GitHub repo, which would then contain symlinks on the local engineer's machine to ALL code repos and infrastructure/gitops/CI workflow repositories, was a perfect shift from just looking at README content, to really helping our agentic coding agents flourish.

At a high level, this is how it looks:

my-platform-agent-repo/
├── CLAUDE.md # explain the repos included, overall architecture of org
├── README.md 
└── repos/
    ├── terraform-repo -> /Users/dev/repos/infra-terraform
    ├── gitops-repo -> /Users/dev/repos/gitops-workflows
    └── actions-repo -> /Users/dev/repos/github-actions

There is an initial one-time setup step detailed in the README in the parent repo that developers need to do to set up the symlinks, and if they ensure that all 'child' repos have CLAUDE.md files too, this further reduces noise in the context window and gives the coding agent what it needs to understand what each repository is responsible for (and any coding standards etc).

After that, a developer can clone this repo along with the platform-related repos and use Claude code to generate platform related code, following our structure and standards as they please.

This removes the need for a self-serve portal. It does, of course, depend on AI adoption within the organisation and it doesn't remove all risks. Making sure developers receive a PR review from a subject matter expert will always be a good guardrail to ensure teams are not introducing security issues or creating components that do not follow usual standards.

Conclusion

It's been a whirlwind of a journey over the past two years. I can imagine I'm not the only one suffering from context switch fatigue! I have confidence that slowing down the thought process and tracking the gains of the latest shift to more context-aware agentic workflows will definitely help.

With my security hat on, my biggest concern will be keeping pace with AI-generated malware or supply chain attacks, as they become all the more frequent. This is my next challenge in making sure we're as protected with defence in depth and a good security posture. This will likely be the topic of my next blog post!