Holy shit its done!!

Check it out on Github here

Getting to this point was a ton of work and I am so glad that it’s at point of minimum viability for release. In this post I want to go through some of the struggles, the triumphs, and what is next for the project.

🪦 The Struggles 🪦

A few things were much, much more difficult than I anticipated. In no particular order, they were:

Authenticating as a Github App

Github and git have great CLIs. You can do anything through the CLIs that you can do on the website, and Taylor takes advantage of that to clone, fork, commit, and create PRs. Doing all of this as a human is super simple- you just write gh auth login, hit enter a few times, copy/paste a short code and you’re in! To do it on the bot’s account, however, you have to auth as a bot. And that was hard!

It turns out, in the entire internet there is one useful thread discussing this issue, and markcheret, bless their heart, shared code that solved 90% of my auth problems. There ended up being no way to do this in node, so instead I tweaked the server run script to run a bash file that authenticates the session as an app first. That worked out really well but it was a complete pain to arrive at that solution.

Keeping track of my own API routes

When initially scoping this app, I thought there would be one, giant agent class that goes through the action loop and then returns an OK message. That architecture, however, is problematic for so many reasons- maintenance, debugging, speed, parallel processing are a few. So instead, I broke it out into a bunch of modular API routes that can be called by a client service whenever and wherever. Version 0.1 has these routes available:

1. Main app route for starting the process
2. FileUtils route for reading, writing, deleting files and generating a file tree
3. GithubUtils route for clone, branch, verification, commit, and PR creation
4. Task generation route to make a new task
5. Code generation route to generate code
6. Verification route to run the code and verify if the task is complete

And that’s not even all the routes I want! This first version doesn’t even touch the skills manager. And while I was developing, I have to constantly make calls from the Client service to all these routes, and those calls have to be proper, too! It would be sooooo nice if I had a nicely formatted, HTML API reference for these APIs so that I don’t have to open up each route’s source code just to see what data is expected, nor would I get surprised by an error message.

Getting the right Typescript & ESLint configs

This is my first big Typescript project. As a Python main, I was completely new to the idea of transpilation that Typescript uses. Additionally, I was used to easy Python tools like (Ruff)[https://beta.ruff.rs/docs/] that just work right out of the box.

Typescript and ESLint don’t work out of the box. At least they don’t work well. I had to do a lot of tinkering and adjusting with the settings, with my npm run script, and within my code itself just to get my server started. Yes I could have started from a template Typescript project, and in the future I will because there was much pain here.

👑 The Triumphs 👑

Good news! Software development is not always suffering! Here are the things that went surprisingly well!

Markdown Prompt Templates

Totally stolen from (smol developer)[https://github.com/smol-ai/developer] and I’d do it again 100 times over. It’s a really small change from using .txt files but the additional formatting markdown gives just makes it so much easier for me, as a human, to write and keep track of prompts.

In code, langchain gave zero fucks that my templates were markdown instead of .txt files, so there were no downsides at all to this approach.

Custom Agents

Langchain is on a hot streak here. The LLM stuff was the easiest part of this project, and that is a theme carried over from other AI projects I’ve done. I feel confident saying now that the bulk of any AI project’s inital release comes from developing the data pipelines and architecture and not from the actual model implementation- assuming you’re not training your own model of course!

Since I was just consuming an API as my LLM, I only had to focus on the langchain process, and that was just super easy. The (documentation for custom agents)[https://js.langchain.com/docs/modules/agents/how_to/custom_llm_chat_agent] only needed a few tweaks to work for my project, which made the custom agent part an absolute breeze.

Git operations on a local repo

Yes ok Github was a pain but git, the old-school CLI for working on local repos, was super easy to run. Once I figured out how to properly spawn sub-processes in the right places, running basic commands like git worktree got results on the first try. I never had problems when dealing purely with git commands.

🚀 The Future 🚀

Version 0.2 is going to contain a lot of upgrades and new features. There are cleanups. code changes, centralized configurations and more. I made a little to-do list in the readme.

The biggest thing I’m looking forward to is a code review with someone who has built node.js / express apps before. I have no clue about the best practices and I’m sure that even a 10 minute meeting now will save me hours in the future. So if you’re a dev and you want to volunteer your time, HMU.

Enjoyed that one? How about signing up for my mailing list below? You can also find another article to read in ./posts