Have you experienced it already? You are working on an agentic solution and writing prompts for large language models. Where do you put your prompts? Do you write your prompt in your Python file itself? Or are you creating a separate file containing the prompt, then loading it into a variable to pass it to the model when invoking it?

As consultants, we must juggle multiple credentials, including those from Xebia. But we are also onboarded at the customers where we are hired for our assignments. I already blogged on how I separate my browser sessions for different clients. This gives me the ability to have relevant bookmarks for my assignment. This blog will continue to explain how I organize my git access and separate them per customer.

The future of AI isn’t just about smarter models—it’s about building systems that can think, act, and adapt autonomously in production environments. Moving from experimental AI prototypes to scalable, reliable agentic systems presents unique challenges that most organizations are just beginning to understand.

I built a workload using AWS Cloud Development Kit (AWS CDK), and the AWS CodePipeline stopped working at the worst moment. It was right at the end of the sprint; we had done multiple deployments before. But at this moment, the moment you might recognize. When this last PR is released, we will have met our deadline! Kaboom, the pipeline stops working, and the reason for the failure is not related to the changes you made.

Have we given up on the least privileged principle? Personally, I am a big fan of it. But let’s be honest, it can also be tough to follow the principle strictly. With the rise of AWS Cloud Development Kit (AWS CDK), it became even harder.

Ingesting data into an OpenSearch cluster looks easy if you read the documentation. The truth is it is easy, but it all depends on how much you care about the data you are ingesting. Let me go one step back. Why do we even use OpenSearch? With the rise of AI, you also need a knowledge base. These knowledge bases can be hosted in OpenSearch. However, to use the OpenSearch database, you must also fill it out with data.

Have you ever been in a situation where you want to provision or configure things cross-stack? Splitting these into logical stacks is always good when dealing with more complex environments. I already shared this in one of my previous blogs. But this also introduces a different problem!

Securing an endpoint used to be hard. Nowadays, with the cloud, it’s quite easy. You only need to know how! Assume you have files on Amazon S3 that you like to share. You could make the object publicly available. This would allow your users to download the file using their browsers simply. If you need to scale it, you can add Amazon CloudFront. This would cache the content closer to your users, making sure that your users have the best performance. But what if you want to control who can download the file? For this, you will need authentication and authorization.

Writing documentation sucks! But there are ways to make it easier and maybe even fun! In one of my previous blogs, I explained how you can embed your documentation in your pull requests and why you should consider doing it, too. In this blog, I want to go a bit deeper into the syntax you can use to improve your documentation pages on Confluence.