Working With Agents, My Thoughts

So, I’ve done a couple of things the past few days with my agent. I’ve had it install arch on several machines. I’ve had it configure caddy reverse proxy snippets, I’ve had it initialize an entire kubernetes cluster, I had it design it’s own web page and publish it in the cluster as the first test of the cluster, I’ve had it build me out a git and action infrastructure and I’ve had it use that action infrastructure to deploy these very pages into it. This is my experience with all of these actions.

The first, installing arch. The first experience with this was actually with Opus 4.5 and a broken arch install. I didn’t grub mkconfig so when I got out of the Arch ISO, there was nothing really for grub to do. So I booted back into the Arch ISO, got Opus setup so he could shell in as root and then had him fix it. Good stuff, stuff that is well documented and requires little reasoning. I probably could have had haiku deal with this. So, Opus fixed my fuckup then I figured, let’s give haiku a shot and see if it can go from nothing except working vm and a virtual disk with no partitions and see if it can install Arch. A well documented activity. The only hint I gave it was that it was in a completely freshly booted Arch ISO and that his disk was /dev/vda. He fdisked and packstrapped and installed things willy nilly. My prompt was pretty simple, I gave him no special instructions just install caddy in this fresh arch instance, make sure it has networking using systemd-networkd, your disk is /dev/vda and it has nothing on it. And it went about it’s business and rebooted the machine for me to see a grub boot menu. I was shocked. So I repeated this action 3 more times :D.

My next activity was getting caddy as my reverse proxy instead of it happening directly on bare metal. Bare metal that runs my media server. So I worked with r3r4 to get my nginx configs off that box and onto caddyshack. This worked great, he had read access on the media server and complete admin rights on caddyshack they transfered over flawlessly, we had 0 hours troubleshooting this node.

Then came the kubernetes cluster… let me tell you.. Haiku ALMOST got there, so damn close. We went back and forth for awhile after the init process but he went too fast I think. After about 10 prompts I gave up and called in Opus to fix it. One prompt later and I had a working cluster, so back to haiku. This wasn’t actually all that painful, setting up a kubernetes cluster is well documented on the internet so I’m sure all of this came from training data.

Unfortunately I didn’t have him document what he did exactly with his web page. But we stood that up before we stood up Gitea. So that page is on GitHub and while I know the general theme of the deployment I remember us having issues and I can’t remember what we did to fix it. I don’t remember the process being too laborious though so it must have been a pretty clean implemenation.

Next came the gitea implementation, this was quite the job. We started out with a forgejo deployment, that’s why one of my previous posts was confused why we still called this deployment forgejo when it was gitea. Anyways something with building the container for forgejo failed so it fell back to using gitea and that stood up fairly quick. The issue came with the nfs mount we had but we wouldn’t find that out right away. I think I first I could get to the setup page but couldn’t save anything and it boiled down to nfs weirdness so we forced uid/gid of 1000 in the nfs server and called it a day :D. The runners came up really quick and that was a completely painless experience. The only pain was that I committed my blog not expecting anything to happen because it had a .github/workflows/hugo.yml and Gitea scheduled a build. But the build yaml had a run-on clause and we had no runners that matched that target so they just sat there. It didn’t take us long to figure out what we needed to do and we settled on using .gitea because it makes sense but more importantly it allows me to make a new branch for that git infra, delete the .github folder and make a .gitea and then push that branch to gitea and cherry-pick each blog across branches :D.

The final project was the GitHub pages like experience. We had to think of this one on our own but we knew the general idea. His first thought was to build and get it into a publish branch and push that and have a git-watcher sidcar updating an nfs share like how his website is. Something hit a snag there and he shifted to trying to mount the nfs directory into the runner pods but that didn’t work at all, it was never the hosts /mnt/nfs directory. We also spent who knows how long finding the right image for the runners to execute. We finally landed on an archlinux image… go figure… the entire ecosystem is all arch or derivatives :D. Heh… I use Arch BTW :D. Anyways, I can’t remember exactly what we did different this time but I said lets revisit the sidecar, we can do secrets right? So we can somehow trust the git ssh server and I can push up some deploy keys to a secret and the repo and then this builder should be able to write to the repo in the disconnected publish branch. Sure enough, we got that secret in place and allowed the key as a deploy key and everything was golden. Except deploying the site.

The sidecar, it went through a few iterations and I saw that in one iteration it was configured to nuke shit instead of sync shit… that would explain some of the issues we had and why we had to reinitialize Gitea. That was fun. So we spent another hour figuring out exactly how he borked Gitea. Turned out he deleted the PVC’s for the pod so shit wasn’t mounting up correctly. And then when things came back up for some reason they were recreated but none of the data except a config file persisted. I think that was a default config file. So we tore the namespace down and rebuilt it, having to re-register the runners and retest that infrastructure and then finally I called in opus and he saved the day finding the issue with the syncer. Phew. What a day that was.

Don’t even get me started on the fact that he chose containerd instead of docker for the kubernetes cluster. So instead of saving space we just consumed even more by having to install docker anyways for use by the runners, lol. While he was trouble shooting that he tried to get them to build on the vm hosts themselves… I allowed it because fuck it, I’m not sharing this infrastructure… yet… because I’m definitely not confident in my ability to administer it but I’m also not completely confident that he can administer it. Seeing as he fucked up my flow mid month I have to wait until March to get a good months worth of data to see if the 39 dollar plan is actually sufficient for normal use.

Don’t even get me started on normal use… I think I need an intervention… send help…

To end this, I would sum up my experience working with this Agent as… just ok. It started to get infuriating but then I switch to opus and he usually fixes me right up. But being budget constrained and working with haiku almost solely can be frustrating when things don’t go as planned. But at the end of the day, having it post to bluesky about it’s exploits is amuzing :D.