From what I have seen in practice, DevOps engineers are among the biggest beneficiaries of AI so far. Rather than replacing us, AI has amplified our effectiveness. It has increased our output, shortened iteration cycles, and made our impact more visible. In many cases, this increased leverage actually makes it easier for organizations to justify expanding platform and DevOps headcount rather than reducing it.

1. IAC and CI/CD Have Become Much Easier

A large part of DevOps work is writing Infrastructure as Code using tools like Terraform and Ansible. We also spend a lot of time defining CI/CD workflows in systems such as GitHub Actions or Azure DevOps. These are mostly declarative languages. They are structured, opinionated, and designed to catch errors early.

This structure works very well with AI.

Most Terraform modules, pipeline definitions, and configuration files follow common patterns. There is usually a recommended way to solve a problem. The documentation is clear, and thousands of public examples exist. Because of this, AI models can generate useful and often correct configurations with relatively simple prompts.

Even smaller models can produce solid results. In many cases, the generated Terraform code or CI workflow works with only small adjustments. Unlike complex application code, you are not dealing with deep business logic or unpredictable edge cases. The surface area is smaller and more constrained. This reduces the time spent on boilerplate and syntax.

Instead of searching documentation or copying examples from multiple sources, you can generate a starting point instantly and refine it. The real value then shifts from writing YAML or HCL to designing better systems, improving reliability, and enabling other teams.

2. Delegating Boring Work to AI

Unlike application developers, DevOps engineers spend a large portion of their time on tasks that do not require deep infrastructure expertise. These tasks are necessary, but they are repetitive and time-consuming. AI has been especially useful here.

Creating and managing tickets. Writing Jira tickets with proper descriptions, acceptance criteria, and story point estimates used to take more time than it should. Now, a short prompt is often enough to generate a well-structured ticket. With MCP integrations, the ticket can even be created automatically. I also include the ticket context when working on a task and ask the AI to draft status updates as progress is made. Instead of seeing Jira as overhead, I now treat it as structured memory that AI tools can reference and maintain.

Maintaining documentation. Platform teams usually own many internal tools and services. Keeping documentation accurate is important, but it often gets postponed because it feels secondary to delivery. AI reduces that friction. After completing a task, I provide the relevant documentation context and ask the model to update it. What used to take an extra hour at the end of a task now takes minutes. The result is more consistent and up-to-date internal documentation.

Communication and announcements. DevOps work involves constant communication with stakeholders, vendors, and internal teams. Writing clear Slack messages, emails, or internal announcements requires effort and context switching. AI helps structure the message quickly. I focus on the key points and let the model refine the wording. The result is usually clearer than a rushed draft written between meetings.

Presentations and data visualization. Platform engineers frequently need to explain costs, reliability metrics, or architectural decisions. AI tools make it easier to analyze vendor bills, summarize large datasets, and generate simple graphs for understanding trends. When preparing demos or internal presentations, I can provide bullet points and generate a clean HTML slide deck in a short time. This reduces preparation time and allows me to focus more on the substance of the discussion.

In all of these cases, AI does not replace DevOps expertise. It reduces the time spent on operational overhead and frees up attention for higher-value engineering work.

3. Versatility and Adaptability as a Core Strength

Another important factor is the versatility of the DevOps skill set. Over the years, we have had to adapt continuously to new tools, platforms, and paradigms. Configuration management tools replaced shell scripts, containers reshaped deployment models, Kubernetes changed orchestration, GitOps redefined delivery workflows, and cloud-native architectures altered infrastructure design. None of these shifts were optional. DevOps engineers learned to evaluate new technologies quickly, understand their trade-offs, and integrate them into existing systems without disrupting production.

This constant adaptation has trained us to think in terms of systems, abstractions, and automation rather than specific tools. We are used to reading documentation, experimenting in controlled environments, and moving from zero to working implementation in a short time. AI is simply another major shift in the tooling landscape. Companies now face rapid changes driven by AI capabilities, new platforms, and evolving best practices. The ability to assess, integrate, and operationalize these technologies is critical. DevOps engineers already operate at that intersection of infrastructure, automation, and developer enablement. That adaptability is not being replaced by AI, it is becoming more valuable because of it.

4. Higher Productivity Across Teams Increases the Need for Stronger Platforms

AI has increased productivity across almost every technical role. Software engineers are producing more code. Designers are iterating on concepts faster. Architects can evaluate and refine system designs in a fraction of the time it previously required. The overall pace of development has accelerated.

But higher output creates new pressure on the underlying systems.

More code means more builds, more deployments, and more infrastructure changes. Faster iteration cycles mean pipelines need to be reliable and scalable. Rapid experimentation increases the risk surface, which requires stronger security controls, better observability, and tighter governance. When teams move faster, instability compounds faster as well.

This acceleration does not reduce the need for DevOps. It increases it. If application teams can ship features at twice the speed, the platform must be able to support that speed without becoming a bottleneck. That requires well-designed CI/CD pipelines, resilient infrastructure, automated policy enforcement, and mature monitoring and incident response processes.

In short, AI amplifies development capacity. DevOps is what makes that capacity sustainable.

Conclusion

AI is changing how we work, but for DevOps it has mostly acted as a force multiplier. It reduces time spent on repetitive tasks, speeds up infrastructure work, and increases the overall pace of software delivery. That faster pace creates stronger demand for reliable platforms, secure systems, and scalable pipelines.

As AI accelerates development across teams, the need for engineers who can operationalize, secure, and stabilize that output becomes even more critical. The role is evolving, not shrinking.

For transparency, this article was edited with the help of AI to improve grammar and wording. The ideas and opinions are based on my own experience.

Before that, I did what most people do:

Ask for a feature → let the agent write code → fix the mess afterward.

The results were as expected:

• Over-engineered implementations

• Scattered edits across the repository that were hard to review

• Code that technically worked but slowly turned into a black box

Then I discovered plan mode.

Instead of jumping straight into implementation, the agent was forced to slow down, analyze the codebase, ask clarifying questions and produce step-by-step instructions. The output became drastically better, and maintainable.

I assumed plan mode made the model think harder. It doesn’t. It simply removes the ability to act. That constraint forces analysis first. Understanding this distinction is the key to using AI coding agents effectively. Let’s break it down

Plan mode works by changing three things.

• The system prompt

• Allowed tools

• Execution context

System Prompt

Every coding agent runs with a system prompt that defines its role, rules, and constraints. On each step, the model combines this with the user prompt, current workspace state, and tool outputs to decide what to do next. Because it has highest priority, it enforces safe, consistent behavior and overrides conflicting instructions.

In build mode, the objective is execution. The agent is encouraged to modify files, run commands, and complete the task as quickly as possible. (Interestingly, Codex is designed to be more autonomous and Claude is designed to collaborate more with user. That is an interesting topic for a separate blog post)

In plan mode, the objective shifts to analysis. The agent is instructed to read the codebase, ask clarifying questions, and produce a step-by-step plan without making changes.

You can find a reverse engineered system prompt for claude code plan mode here. The interesting part in that system prompt is,

=== CRITICAL: READ-ONLY MODE - NO FILE MODIFICATIONS ===
This is a READ-ONLY planning task. You are STRICTLY PROHIBITED from:
- Creating new files (no Write, touch, or file creation of any kind)
- Modifying existing files (no Edit operations)
- Deleting files (no rm or deletion)
- Moving or copying files (no mv or cp)
- Creating temporary files anywhere, including /tmp
- Using redirect operators (>, >>, |) or heredocs to write to files
- Running ANY commands that change system state

Your role is EXCLUSIVELY to explore the codebase and design implementation plans. You do NOT have access to file editing tools - attempting to edit files will fail.

Similarly, you can find the exact plan mode system prompt for opencode in their open source codebase here.

Another interesting part from the prompt that I really like is

**NOTE:** At any point in time through this workflow you should feel free to ask the user questions or clarifications. Don't make large assumptions about user intent. The goal is to present a well researched plan to the user, and tie any loose ends before implementation begins.

This is the key part that makes plan mode more powerful. It doesn’t make assumptions, and provides a questionnaire to the user to come up with a concrete plan. The same model produces very different output simply because the goal defined in the prompt is different.

Tool restrictions

In claude code, the plan mode is not just a system prompt, but also a permission model. A list of available tools is sent along with the system prompt to the model. Then the model returns instructions for the agent to execute the tools and send the output in next step. The coding agent makes sure that only the allowed tools are executed, irrespective of what the model asks to do.

Opencode also behaves in a similar way. Here is the source where it defines the default permissions for plan mode. It resolves to something like below,

 "plan": {
      "model": "<default>",
      "tools": {
        "write": false,
        "edit": false,
        "bash": false
      }
  }

Because it cannot modify anything, it is forced to reason first. This constraint has a larger impact on output quality than any prompt wording. Removing the ability to act naturally encourages the model to analyze.

The role of the plan artifact

The plan itself is not just documentation. It is an execution artifact. In most plan-based agents, the plan becomes the input to the next phase. How this handoff happens has a big impact on behavior.

Claude code

In Claude Code, plan mode produces a detailed markdown file with explicit, step-by-step instructions. This file is saved to a special directory (usually in ~/.claude folder) and treated as the single source of truth for the next phase.

When switching from plan → build:

• the session context is cleared

• a fresh agent starts

• only the markdown file is provided as input

Effectively, plan → plan.md → prompt for build

Because the steps are already concrete, you can often allow edits and execute the entire change in one pass. In practice, this works well. I frequently iterate on the plan first, refine it until it’s precise, and only then switch to build. Once the plan is solid, implementation becomes mostly mechanical.

Sometimes I keep the plan inside the project directory instead of the default location so I can review and tweak it manually before execution.

Cursor

Cursor follows a similar model. It also generates a plan artifact and treats it as the basis for execution. Since it’s an IDE, you can inspect and edit the plan directly before building. The behavior is effectively the same: clear context and execute from the plan.

Opencode

OpenCode handles this differently. There is no dedicated plan file by default.

The model produces a plan conversationally, but when switching to build:

• the session context is preserved

• only the system prompt changes

• edit tools become available

So the same conversation continues with more permissions. It uses the build-switch system prompt to indicate that model is now allowed to use edit tools (source).

Because context is not reset and there is no explicit plan artifact, execution is less deterministic. The model still carries earlier assumptions and exploratory reasoning, which sometimes leads to premature edits. In my experience, this makes one-shot execution less reliable compared to Claude’s “plan → clean build” workflow. This is much less of an issue if you are using a high reasoning model though.

To get similar behavior, I explicitly ask OpenCode to write a plan.md, refine it manually, then start a fresh session and feed that file as input myself. That recreates the same “compiled prompt” approach.

Summary : When to Use Plan Mode vs Build Mode

Most official docs explain plan vs build in abstract terms. I found that too vague. After using these agents daily, I follow a simple rule of thumb.

Build mode

Use build when the task is simple and deterministic.

• easy, one-shot changes

• straightforward implementation

• only one obvious way to do it

• I already know exactly how I’d code it myself

• writing documentation, RFC or specs

Most people assume docs or RFCs belong in plan mode. In practice, they’re iterative editing tasks. It’s faster to write, tweak, and refine directly in build mode.

Plan mode

Use plan when thinking matters more than typing.

• changes that affect multiple files

• unclear or open-ended problems

• I’m not sure how to implement it yet

• I want the agent to propose steps first

• brainstorming or exploring a codebase

• I don’t want the agent touching files yet

If I have to think, I use plan. If I already know the solution, I use build.

Final takeaway

Plan mode doesn’t make the model smarter. It makes the instructions clearer. Clear instructions produce better code. Most developers don’t naturally write detailed prompts for an LLM. Plan mode does that for you. It turns vague intent into a concrete specification, and that specification becomes the prompt for the build agent.

Once you understand this, the workflow becomes simple: plan first, then execute.

That shift alone dramatically improves reliability.

TL;DR

• €400 total cost

• 4TB mirrored storage

• TrueNAS + Docker apps

• Offsite backups to Hetzner

• Handles Photos, Media, Kubernetes backups

The Case and CPU

Disks and backups matter far more than CPU for a NAS. Even an old i5 is overkill unless you're trans-coding or running many containers. I wanted something which can run a few docker containers and is also extensible. That’s how I came across this used PC - HP EliteDesk 800 G2 on ebay. It was perfect for my use case due to following reasons,

• I5 6th Gen is power efficient and can easily run a few docker containers in additional to NAS server components. The whole setup consumes around ~25W on moderate load with a few containers.

• There is slot for 3 Hard disk drives and SSDs. There are 5 Sata ports available.

• Highly extensible with 3x4 PCIE lanes and a x16 PCIE lane

• Supports 64GB of RAM. The item came with 8 GB included (2x4GB) which was enough for a start.

• It supports Intel QuickSync for video transcoding

The Motherboard and CPU doesn’t support ECC memory. But it was a trade-off that I was willing to take.

Cost: 70 Euros

Hard Disks

This is where I made my first mistake. I went for really cheap SSDs from Aliexpress. I bought 2 4TB hard-disks from a seller named KANDA Store here. 4TB SSDs for 40$ was obviously too good to be true. These drives are usually fake firmware + tiny flash chips.

Lesson learned: Never trust suspiciously cheap storage.

Learning from my mistake, I ordered a couple of WD Red Plus 4TB from Digitec. There is little to no noise, and the performance was better than I expected. It also came with a 5 year warranty.

This was the most expensive component of the NAS build. As someone who takes backups seriously, it was well worth to spend on reliable hard-disks.

I had a 120GB SSD from an old laptop laying around. I decided to use that as the boot disk.

The layout I was planning for was pretty simple. Just 2x4TB disks in mirrored pool (RAID1) with 120GB ssd as boot drive. This setup cuts the capacity in half but protects against a single drive failure, providing about 3.6TB of usable storage space.

Remember: RAID is not backup - it only protects against disk failure, not deletion or corruption.

Cost: 220 Euros

Memory

The PC came with 8GB of RAM included. I did the initial build with that and it was more than enough. Then I decided to run more apps like Jellyfin, Immich and Minio on the NAS. Then it made sense to add more RAM.

The motherboard was 4 slots available for installing RAM. So I bought two 16GB memory sticks from Aliexpress here. This gave me 32GB of RAM with room for expansion later if needed.

Cost: 54 Euros

Total Cost

The minimal version of the NAS was ready for ~290 Euros. The additional RAM and a few other components (lan cables, switch, SATA cables etc.) the total cost came to over 400 Euros. But I was able to cut down my cloud spending on backups and google storage to compensate this.

Services I run

Here is a screenshot of my storage layout.

Below is the list of important services my NAS runs,

• NFS server used by my homelab kubernetes cluster for PVC backups

• Storage for Immich, an alternative to google photos for storing my photos and videos

• Samba server studio, used for video editing across devices

• NFS server for tv. It hosts my home videos as well as content I download through *arr stack

I will make a separate post to go in depth about the services I’m running in the Homelab.

Data Protection

By moving my digital life to a self maintained NAS server, I also bear the risk of losing everything in the event of a catastrophic failure (as it already happened when I bought the SSDs from Aliexpress and both SSDs failed at the same time). So it is important to have a offsite or cloud backup for the entire NAS where we can restore from.

Hetzner Storage box was the perfect solution for this. 1 TB of storage only costs ~3.8 Euros per month. It comes with SSH and Rsync access. I just had to setup rsync cronjobs in my NAS to backup periodically.

Another important part is to setup alerts correctly. TrueNAS has a sensible default configuration for alerting. I used telegram alerts in addition to email notifications. I already had a homelab channel setup in Telegram which I use for alert-manager notifications, so it made sense to re-use it for NAS as well.

Running Apps

I was hesitant to use the hypervisor from TrueNAS to run apps, as VMS are more resource intensive than docker containers. Then I came across this cool project named Jailmaker. By following the tutorial provided on the readme, I was able to quickly set it up along with Docker and Dockge

Dockge is a UI on top of docker and docker-compose. It lets you create and manage docker stacks through UI. It was quite handy given the limited shell access from Truenas (and the additional pain of exec-ing into the Jails)

I run the following services in Dockge

• Handbrake -> Batch video transcoding before archiving

• Immich -> Alternative to Google photos. It has almost all the features google photos has, and very similar UI.

• Jellyfin -> For media playback across devices. I was able to setup hardware transcoding using Intel QuickSync by setting up GPU passthrough in Docker.

• MinIO -> Alternative to Amazon S3. I use it for restic backups from my PC and a few apps running on k8s

• Nginx Proxy Manager -> A graphical front-end to Nginx. I use it as a reverse proxy and certificate manager for the above apps

Monitoring and Uptime checks

So I have alerts setup if something is wrong with the regular operation of NAS. What about Apps which are running in docker? What if the whole NAS is down or network is down?

For this, I have 2 more things setup.

• Healthchecks → Whole server dead?

• Uptime Kuma → Specific service dead?

Healthchecks.io

healthchecks.io is a dead-man-switch service which notifies you if a service is down. The way it works is quite simple. The server has to ping the health-check endpoint in a predefined interval (I set it to 1 min in my case). If it fails to do so, the service will notify you by email or any other means. This is quite handy to notify when the network itself is down or the whole NAS has stopped responding.

Uptime Kuma

Uptime Kuma can ping your services on regular intervals and notify if the service is down. It even gives a nice status page summarizing the uptime of various services.

I’m running Uptime kuma in my kubernetes cluster. So unless both k8s and NAS apps fail at the same time, this should work as expected. If both NAS and K8s die at the same time, I probably have bigger problems.

Conclusion

Was it worth the effort and money? Absolutely! Setting up everything and configuring the automations, backups etc. took quite a long time. For €400 I now have full control over my data, lower monthly cloud costs, and a setup I can expand anytime. For me, that trade-off was easily worth it.

In this post, I would like to share my journey of embracing Nix as a long-time Arch Linux user. Hopefully I can inspire a few people to get curious about Nix and even start using it.

This is Part 1 of the series, where I’ll cover how I got started and the background that led me here. Future posts will dive deeper into the technical side.

Where I come from

I was using Arch Linux as my daily driver for nearly 5 years. It was surprisingly stable and easy to use. The Ubuntu system I used before had more issues than the so-called “unstable” Arch Linux. I was using I3 window manager and Vim as my editor of choice. I used to update packages quite frequently. Arch Linux is usually the first to receive package updates. The AUR (Arch User Repository) had almost every package I needed. Arch wiki is great and any kind of issues were easy to fix with a bit of googling, thanks to a huge community of users.

However, there were a few quirks which annoyed me a little. I had to reinstall the OS a few times, due to a broken hard disk, migrating to a different laptop etc. Every time I reinstalled, it took me over a day to install and set everything up. I still ended up with a slightly different configuration. Each time I fix an issue (for example, getting Bluetooth to work), I end up forgetting how it was done and next time I had to research and figure it out again. I ended up documenting the list of packages I install, fixing common issues etc. But it became quite messy over time.

Declarative Programming

I was quite fascinated by the idea of declarative programming. From Wikipedia

Declarative programming is a non-imperative style of programming in which programs describe their desired results without explicitly listing commands or steps that must be performed

I was working heavily on Terraform at that moment. So the idea of declaratively configuring an entire OS sounded really interesting to me. To explain what a game-changing concept this is, here is a simple example of the difference between these two:

Imagine, you want to create a user in your system. In imperative style, it would be:

1. Create new user - jayadeep

2. Assign group for the user - net-admins

3. Create home directory - /home/jayadeep

4. Assign home directory permissions

You just instruct the system to do these in order. The system blindly accepts the instructions and executes it. In declarative style, it would be:

Make sure following user exists with the given configuration:

name: jayadeep
groups: [net-admins]
homeDir: '/home/jayadeep'

Then the corresponding program will run the logic to ensure that the system has the users created with the given attributes. Here is a more detailed explanation of the difference between these two.

In short, declarative syntax makes our life easier by hiding the implementation details.

Hearing about Nix, and getting started

Nix is a package manager, a build system, an operating system (NixOS), and much more. Before getting to the complexity of nix ecosystem, let me explain where I started. At first I heard about how nix can configure an entire OS declaratively. So I downloaded a NixOS ISO, booted into a VM and started tinkering with the configuration.

Here is a sample configuration of NixOS

{ config, pkgs, ... }:
{
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  users.users.alice = {
    isNormalUser = true;
    extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
    initialPassword = "test";
  };

  environment.systemPackages = with pkgs; [
    cowsay
    lolcat
  ];

  system.stateVersion = "23.11";
}

Although the syntax is a bit weird (looks like JSON, but isn’t), the configuration is easy to read and understand. What it does is the following,

• Enable systemd bootloader (alternative to grub)

• Add a user named alice, with initial password test

• Install cowsay and lolcat packages

With a bit of Googling, I came up with a basic configuration that I can install and boot with. I still didn’t have much clue about the inner workings of Nix though. Once the configuration is ready, I just had to run the following command and it immediately applies the changes

sudo nix-rebuild --switch

First working configuration

Here is my first commit on Git: Nixdots

This was my first working configuration after days of tinkering with config, restructuring, following various tutorials etc.

One clear advantage NixOs has compared to other OSes is that, the nix package ecosystem is really huge. It has over 80k+ packages available the repositories, which is much more than AUR or any other package managers out there. So I was confident that I would be able to configure the system to be able to completely switch from Arch Linux.

My first impressions

Declaring the list of packages like this was life changing for me. It allowed me to discard the messy notes. At every point of time, I know what packages are installed in the system by looking at this file. This made it really easy to reproduce the system in case of a reinstall.

Look how easy it is to enable Bluetooth in NixOS!

hardware = {
  bluetooth = {
    enable = true;
    settings = {
      General = {
        # Show battery percentage of bt headset
        Experimental = true;
      };
    };
  };
};

This small snippet did all the magic. Since NixOS forces us to manage everything declaratively, once we fix an issue and persist it in code, it is fixed forever! Every package and every configuration is versioned and hashed. Nix goes to great lengths to ensure that the configuration is highly reproducible, byte by byte, no matter where or when we apply the configuration.

Summary and Upcoming posts

You can find my current NixOS config on GitHub: https://github.com/kmjayadeep/nixdots. In the upcoming posts, I will explain more about Nix package manager, Flakes, Devshells and more.

So what makes it interesting? Here’s why I switched:

Markdown + Local Files

Like Obsidian, SilverBullet stores everything as Markdown files. That means I can keep using all my existing plain-text tools.

I run a cron job that automatically creates Git commits, so I can easily revert or browse history. I also use Syncthing to sync across multiple devices. And when I need heavy editing or bulk reorganization, I just open the folder in Neovim.

If I ever want to leave SilverBullet, I simply copy the files and move on. No vendor lock-in.

Web interface with PWA

This might sound counter-intuitive: why choose a web app over a native app?

Portability.

I host SilverBullet on a cheap $5 Hetzner cloud server that I already use for other projects. Then I install it as a PWA on my phone and tablet. Now my notes are available everywhere.

SilverBullet caches the entire space using web workers, so it works fully offline too. It honestly feels like a native app on every platform.

Here is my Podman Compose definition for SilverBullet

  psuite-wiki:
    image: docker.io/zefhemel/silverbullet:2.3.0
    container_name: psuite-wiki
    hostname: psuite-wiki
    restart: always
    environment:
      - SB_FOLDER=/psuite-data/psuite-wiki/data
      - SB_NAME=Wiki
      - SB_DESCRIPTION=Jayadeep's personal Wiki
      - GUID=1000
      - PUID=1000
      - SB_USER=wiki:${WIKI_PASSWORD}
    volumes:
      - /opt/podman-compose/mounts/syncthing/data:/psuite-data
    ports:
      - "3000:3000"
    networks:
      - psuite-network
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:3000"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

Programmable notes

SilverBullet comes with a built-in embedded language called Space Lua. You can add scripts directly inside your notes and render dynamic content in real time. This is a powerful feature that lets you extend your notes, for example:

• Query your notes like a database. Filter using tags or attributes and show them as a table or in any format you like.

• Run Network calls, execute Bash scripts. I have a script that runs git commit as a cron job, written in Space Lua

Here is an example from my notes. The MindMap page contains a custom command that can create a new MindMap page based on today’s date. Then there is a Lua query that lists all MindMap pages in a table.

The corresponding query is

${ template.each(query[[
  from index.tag "mindmap"
]], templates.fullPageItem)}

If you are interested in my setup, all my Homelab and cloud config are open source. You can find the Ansible playbook for SilverBullet and related services here