Mahesh Rijal - Blog

Coding with Agents

Unknown — Sat, 07 Feb 2026 00:00:00 +0000

AI agents have changed how I approach, deliver, and solve problems at a fundamental level. Over the last year, I have spent a lot of time with agentic tools and frameworks. From the early days of Copilot, to Claude Code, and now Cursor, Codex, and many others. Code, now more than ever, feels replaceable, and how I build and run applications has changed drastically in the last year.

Interfaces and Tools

I was not a regular user of Copilot when it launched, but I remember trying it a couple of times. I used to work on Infrastructure Ops (think Ansible, Jenkins, Linux, etc.) back then and didn't write code regularly. But Copilot came in handy when I had to write a shell script or Ansible playbook. It felt magical at the time.

Claude Code

When Claude Code launched, I received a few hundred dollars in free credits to try it out. I burned through the credits in a month.

This was a completely new approach to coding. The terminal is where I lived (and still do). So having a terminal tab dedicated to answering questions, running ops, writing new code was a game changer. I would delegate something boring/menial that I didn't want to spend time on to Claude. Things like checking if a new release for a Terraform provider was out, or upgrading dependencies in an application. I remember using it to create manifests to provision a new EKS cluster by looking at what I had already done in the past in another repository. Basically, at a higher level, I was delegating tasks that I already knew how to do.

It did make mistakes, which was expected. This was my first rodeo with agentic interfaces and since it was not part of my core workflow yet, when the credits ran out, I stopped using claude and it didn't bother me the slightest.

Then, when working on a client engagement through my employer, I got access to Claude Code, which meant cost was no longer a concern. I began to use it more liberally. It became more like an assistant helping with documentation, bug fixes, upgrading dependencies, and writing Terraform modules. These were tasks I knew how to do, but I wasn't completely aware of the approach I would take to solve the problem. This was something I would figure out by talking to the agent. I also became more comfortable with delegation and often had multiple terminals running Claude sessions in parallel.

Cursor

VS Code, but with wings.

When I joined People Inc I started working heavily on infrastructure and platform engineering. I also got access to Cursor. I was building things in record time. I remember deploying something new to the platform every other day. Things like EKS, ArgoCD, Traefik, and Cert Manager, External DNS all of these I rolled out in record time. I liked the planning aspect, and its understanding of the codebase. I have found that the editor+agent interface is good for quickly walking through the codebase, asking focused questions on specific functions or files and trying to understand how different pieces of a large codebase fit together.

One quirk around Cursor that I've found is that it's not super easy to see or work with it while you actively run terminal commands (aws, kubectl, argo, etc.). Also, the UI does not feel suited towards for terminal-first operations.

Cursor does have issues. It consumes too much memory and makes my system slow when I open multiple windows. It has gotten much better in the last 2 months, and I've had fewer problems with it now. But I still prefer a terminal-native workflow over a code editor.

I now use the Cursor CLI more than I use the editor. It's faster than the GUI, but it's not as polished as the other options out there.

Codex

For me, Codex has really been a journey. I've seen the harness evolve over time. In its early days, Codex was just trying to keep up with Claude Code. I like my tools fast. And Codex definitely is fast, but the models historically have not been. In my experience, OpenAI’s models are generally more capable at long-running and focused tasks, but the speed of the model has been too slow. Although that has not stopped me from using it for most of my day almost every day.

Codex is the tool I have used the most and it has gotten a lot better, especially in the last couple of weeks as I am writing this blog with the new gpt-5.3-codex release and other new features added to Codex CLI. The new Codex app is really good as well.

Codex excels at gathering context both locally and remotely (through aws, kubectl, helm commands). It is also the best at troubleshooting. I often point it to a failing deployment, or an issue in AWS. It can map out dependencies well and its review system is also good at catching issues early. I typically ask Codex to look around and once it has context, ask it to work on a specific task.

Codex is my agent harness of choice. I have become so comfortable that I typically have three or more terminal tabs open with different Codex sessions all working on different things. I do have a robust AGENTS.md and require it (codex) to seek approval for commands that mutate state, so I don't have to worry about it nuking something important accidentally.

Others

Thoughts on Amp, Cline, Droid

Out of all of these, I like Amp the most. I like what they are doing with the advertisement model. Amp can one-shot most simple tasks, but it is the most expensive of all of these tools because it is not subsidized via a subscription. I use it from time to time and assign it specific focused tasks. Over time I have learned the kind of tasks that would fit within a $10 budget window and only use it on those tasks. If the task is more complex or time consuming, I hand it off to Codex.

On Cline and Droid, I felt that Cline has the same problems Cursor does, and it is far less capable at what it can do. It is also the slowest of the bunch, at least for the things that I have tested it on. It's one of my least used tools.

I used Droid CLI for two weeks. It definitely had an edge over codex & the cursor CLI in the past, but the other two have caught up. I don't use droid because I already pay 20$ for Claude Code. I use Cursor agent when I need to with models not supported by Codex CLI.

Writing Code

Writing code was not my forte. But, that has changed. Now that I don't have to go in depth into every single line of code, I find myself using agents to write more and more code.

At work, I find myself using agents to bootstrap things I need quickly. Recently, I used Codex to build a documentation site on top of Starlight that aggregates documentation for all of the internal tools we have. It uses Agent Skills and Argo Workflows under the hood, to generate documentation for our internal platform. I probably wouldn't have worked on this project if I had to write all of the code by hand. And this was implemented in a few hours.

On the personal front, I have been building tools and automations. A Few weeks ago, built F1Recap. A website for gathering Formula 1 recaps & schedule, built an Invoice generator for my dad's business, and even a CLI to place orders for water cans.

The pace at which I build things both at work and in personal life has increased multifold. I have been reading various blogposts which tend to express the idea that code is replaceable and I think I agree. But, this is just the early days and I'm excited to see what lies ahead.

Learning New Skills

Last week, I started learning about Crossplane and used it to automate Grafana provisioning at work. Crossplane is a completely new tool for me. My approach to learning this tool has been different from how I learned other tools in the past.

In the past, I would find YouTube videos, tutorials, and maybe watch a demo on how the tool works, what its capabilities are.

This time around, I asked Codex about it. It showed me examples, use cases, created a sample codebase for me to explore, and I feel this approach is going to stick. Having an agent on the terminal that can run the same commands as me feels like a game changer now.

Terminal based access to AI Agents has become a fundamental part of my workflow. Something I cannot imagine working without. I'm excited to see what's ahead in this space.

I did read this interesting article by Anthropic on how using agents impact our skills. It does make me worry a little. But, I have yet to think deeply about this topic.

Exciting times are ahead of us. We are witnessing a shift in the software paradigm right under our eyes. I am glad I am in some way able to take part in this, and excited to see what lies ahead.

What the future holds, I don't really know. I eagerly wait for new releases, constantly get new ideas and try to build something, and always try to find & optimize my workflow around agents. I'm constantly learning from many others who have shared similar experiences.

Using IaC to Manage DNS Records

Unknown — Thu, 13 Jun 2024 00:00:00 +0000

Organizations like to manage their DNS records using Infrastructure as Code (IaC) tools. This approach helps streamline approval processes, makes changes easy to track, and simplifies rollbacks in case of failure. I came across this idea^[1] recently and wanted to try it out for the DNS records of my domain maheshrijal.com. This blog outlines the process.

NS records for my domain are in Cloudflare. They already have a terraform provider. It was quite easy to get started.

Initialize the provider

First step was initializing the Cloudflare provider for Terraform and creating a Cloudflare API token with edit access to the DNS zone.

// providers.tf

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "4.33.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

Next, I defined the variables.tf file and created terraform.tfvars file in which the actual API token will be assigned. This file will not be comitted to GitHub.

I then initialized the provider with terraform init.

What to do with the state file?

Terraform uses a state file to keep track of the current state of the infrastructure. I initially thought storing the state file locally would be a good idea and relatively simple. But, if I stored the state file locally, I would not be able to edit my DNS records if I did not have the device that stored the state. This was a no-go. I looked at other options.

Store the state file in Cloudflare R2?

R2 is is a object storage service privded by Cloudflare. It is compatible with S3 which means it can use the terraform provider for S3 it also has a generous free tier.

I was already using the Cloudflare provider for terraform anyway, so one would think using R2 would be straightforward right?

Welp, initializing the provider for R2 is not straightforward because terraform does not support R2 officially. But, given that R2 is compatible with S3, I could use the S3 backend to configure R2.

However, another issue I ran into was that the backend block(backend.tf) does not support variables. This is unlikely to be ever fixed in the terraform core repository given the incentive hashicorp has with terraform cloud. But, there is still hope as a similar issue is open in the recently forked OpenTofu. There is a workaround to the issue using -backend-config but, I was worried about credential leak

Store the state file in Terraform Cloud

I could use AWS S3, but my free tier on AWS just ended, and I didn't want to pay for bucket storage. So, I settled on using terraform cloud. I defined the backend and logged in with terraform login.

// backend.tf

terraform {
  cloud {
    organization = "xyz"

    workspaces {
      name = "abc"
    }
  }
}

Importing existing DNS records

Since I already have existing DNS records for my domain in Cloudflare, it is not ideal to start creating new records. First, I will have to import these records into my terraform state. There is a CLI utility called cf-terraforming that does just this.

I installed the tool and exported the Cloudflare API token & Zone ID.

export CLOUDFLARE_API_TOKEN='abc'
export CLOUDFLARE_ZONE_ID='xyz'

Then, I ran the tool to generate the main.tf file. This will create the terraform code for all the existing DNS records and write it to main.tf.

cf-terraforming generate --resource-type "cloudflare_record" > main.tf

Next, we can get to importing the current state into our state file. Without this, terraform would think these are new DNS records.

cf-terraforming import --resource-type "cloudflare_record" --modern-import-block > import.tf

Together, the above 2 files will generate the state file by importing existing resources rather than creating new ones.

In our current main.tf file the zone_id is hard-coded. I want to store it in a variable so that it is not pushed to Github. I converted the zone_id assignment to a variable.

var.zone_id

Then, created a variable for zone_id. The zone_id variable also needs a value which will be passed from terraform.tfvars.

// variables.tf

variable "cloudflare_api_token" {
  description = "The API token for Cloudflare"
  type        = string
}

variable "zone_id" {
  description = "The zone ID for the Cloudflare domain"
  type        = string
}

Before completing the import, I wanted to have a clear naming scheme for all the records. To achieve this, I renamed the records in main.tf and changed the import destination accordingly in import.tf.

Now, I was ready to apply the changes. Just to be safe, I exported my DNS records from the Cloudflare dashboard incase something went wrong.

Yay! 🎉 I'm able to see the state in terraform cloud, and no records were changed in Cloudflare. Which is a success. Now, to make it work with Github actions.

Integrate with Github actions

Since the code is on Github, I wanted a workflow to run terraform plan whenever a pull request is created and terraform apply to run when change merged to main branch. To do this, I used Github actions.

To authenticate with Terraform workspace, we need to create a secret for our terraform workspace called TF_API_TOKEN & and add it to github repository as actions secret.

Until now, I was running the terraform plan & apply locally so, the variables defined in terraform.tfvars were being passed to terraform cloud on each run. Now, the plan is to run Terrafrom straight from github so, I added the zone_id and cloudflare_api_token as sensitive variables in terraform workspace.

I also created a personal access token called GH_TOKEN and added it to the github repo. This token has the permission to comment on a pull request. This will be required to output changes of the terraform plan command.

After these changes are pushed, once a pull request is created, github actions should run the terraform plan workflow which runs terrafrom plan in terraform cloud using the API. The output of the plan is shown as a comment. When merged into main, the terraform apply workflow runs, which creates the DNS records.

With this approach, it is critical to make sure the branch protection rules are strong to prevent accidental pushes into main branch.

With this, the project is ready. Now, whenever I need to create/change a DNS record I create a pull request on the repo and I can easily track changes or rollback in case of failure. This also helps me keep track of provider documentation that I might have referred for DNS configuration.

Future Scope

Few things in this project are still not ideal. For starters, the Terraform organization and workspace name are public in the GitHub repo, which is probably a concern. Also, it would be great to have the ability to query DNS records after they are configured to verify if they are set correctly.

Overall, that's where I feel like leaving this project now. I might get back to it in the future.

If you're interested, the code is public on my github repository.

I started working on this after reading through Alex's blog. ↩

Trying the Zed code editor on Windows

Unknown — Mon, 29 Apr 2024 00:00:00 +0000

This page has been updated to highlight my experience using Zed on Linux.

Intro

Atom was my favourite code editor until it was sunset. I then switched to using VSCode which is good, but I found its performance subpar on my old laptop.

A few months ago, I heard of a new text editor called Zed. Interestingly, the creators of Zed have worked on Atom as well. Sadly, Zed was not yet available on Windows at release. Well, it still isn't but now it can be compiled from source.

Compiling from source for Windows

The instructions listed in the repo were fairly straightforward. But it did take me around 25 minutes to build it all. I don't have experience building rust apps from scratch, so I'm not sure if this is an ideal time or just a result of aging hardware on my laptop.

Look and Feel

On first glance, I felt it was similar to atom. The UI isn't something completely new and follows a similar layout to almost all the text editors out there today, which is to be expected because developers are not just going to learn their way around a new layout for a new text editor.

Performance

Zed was fast. Extremely fast. Files and large directories opened in a snap. I did see the performance benchmark comparison listed on their website, but I was still surprised at the quickness with which it operated. Now I get why Rust can be huge for software.

Here is a quick comparison of app launch times.

Features

Given that it is in active development, the overall editor is quite bare bones which I like. I don't think a code editor needs a lot of features. The theme selection is pretty decent, and it supports keymaps for all the popular editors out there. It also has support built in for vim mode. It has a bunch of other features that are not yet available on Windows.

On Linux

At the time of writing this blog, I was on windows. But, now I have migrated to Linux and Zed recently released native support for linux. My experience on Linux has been really good. It's simple, fast and easy to use. Although, I have used Zed more like text editor rather than a code editor it has been a good expereince using Zed on Linux. I feel it is less bloated compared to VSCode but, that could be because it's still a new kid on the block.

Conclusion

Zed looks quite promising, but it is still in its infancy. While the code is open source, Zed requires contributors to sign a CLA and they also have raised private funding. As an end-user, this makes me concerned about the long term revenue prospects for the code editor. This is probably because I have seen plenty of venture-backed projects shut down, get acquired, or both. Only time will tell if Zed can live on.

Quick and easy directory navigation using CDPATH

Unknown — Sat, 14 Oct 2023 00:00:00 +0000

Traversing through multiple directories in Linux often takes time and can be inefficient when multiple sub directories are involved. To easily move to directories in Linux, we can use the CDPATH variable.

I store all my code in the /home/mahesh/code directory. But, every time I want to go into one of the sub directories inside /home/mahesh/code, I have to cd into Code and then switch to the sub directory I am interested in.

However, if I set the CDPATH variable to /home/mahesh/code I can directly jump to any of the sub directories under Code without having to traverse the full path. This can be a lifesaver when the directories are nested deep inside.

Syntax for CDPATH: export CDPATH=/home/mahesh/code/

Let's see how this works practically. Initially, if I attempted to change into the dotfiles directory without CDPATH, I'd encounter an error due to the incomplete path.

mahesh@workstation:~$ cd dotfiles
bash: cd: dotfiles: No such file or directory

However, once the CDPATH variable is exported, I'm able to cd into dotfiles directory directly without having to type the complete path.

mahesh@workstation:~$ export CDPATH=/home/mahesh/code/
mahesh@workstation:~$ cd dotfiles
/home/mahesh/code/dotfiles

Additionally, all directories under /home/mahesh/code/ will also show up as suggestions in bash.

The CDPATH variable can also contain multiple colon : separated directories just like the PATH variable.

$ export CDPATH=/home/mahesh/code:/home/mahesh/Documents

Something to keep in mind is that, the order in which you define the directories with CDPATH determines where you end up. So there could be issues if subfolders across exported CDPATH's have the same name.

While CDPATH is easy effective but it does run into issues. While changing directories, it can jump into unexpected directories and it writes text to the standard output, which is bad for shell scripts.

I have my CDPATH exported in ~/.bashrc so that the the change is applied only in interactive shells.