Skip to content

Build notes #1: why I'm writing this, and what's on the bench

The first issue of Build notes. What this newsletter is, what it is not, and what I am building right now: an AI coding agent for VS Code and my studio's website.

mutheejj 3 min read agents career laravel

Hi, I'm John. I'm a full-stack engineer in Nairobi, and most of what I build these days is either an AI agent or the software that agents run inside.

This is the first issue of Build notes. Here is the deal.

What this is#

Roughly once or twice a month, I will send a short email about what I shipped, what broke, what I learned from it, and what I am trying next. Real code, real decisions, and the mistakes that led to them.

What it will not be: a roundup of AI news, a list of "10 tools you need", or anything I would be embarrassed to read back in a year. If I have nothing worth saying in a given month, I will skip the month.

I am writing it for three reasons. Writing forces me to finish my thinking. It gives the people I work with a way to see how I approach problems before we talk. And a lot of what I learn building agents in Kenya, especially around mobile money and local infrastructure, is not written down anywhere else.

What I shipped#

My studio's website. I run a small AI engineering studio, Mutex AI. The site is built in Laravel, and the part I am proudest of is not visible yet: an assistant that will answer visitor questions and route them to the right page. More on that once it is live, because the interesting parts (spend limits, fallbacks, how it learns) deserve a proper write-up.

A lot of Laravel housekeeping. Better test coverage on the platforms I maintain, and CI that runs on every push. Unglamorous, and it pays for itself the first time a deploy goes wrong.

What I'm building#

An AI coding agent for VS Code. I have been using coding agents daily and kept wanting something that lived in my editor, could see the whole workspace, write files as it streamed, and run commands with my approval. So I am building one. It is called Andor, it is open source, and it supports several model providers, including free ones, so anyone can try it without a credit card.

The early lessons are already interesting:

  • Context assembly is most of the work. Sending the whole repo is too much, sending one file is too little. Scoring files by relevance and including the file tree turned out to matter more than the choice of model.
  • Live file writes need an undo. Writing files as the model streams feels great until it writes the wrong thing. Checkpoints that let you revert a whole turn are not optional.
  • Destructive commands need a human. rm and git push go through an approval step. Everything else can be allowlisted.

What I learned#

The main lesson of the last month: most agent failures are not model failures. They are tool failures (vague names, useless error messages) or context failures (the model never saw the file that mattered). I will write a longer post on designing tools that agents use well, because I keep relearning it.

What I'm reading and trying#

  • The Model Context Protocol spec, properly this time, start to finish. I want the agents I build to share tools instead of each having its own copy.
  • Running two agents on the same repository at once. So far the result is mostly conflicts, which tells me I need better isolation. Git worktrees look like the answer.
  • Re-reading my old ALX C projects (a Unix shell and a bytecode interpreter). It is humbling, and surprisingly relevant. An agent loop is a REPL.

A question for you#

What is the one thing you wish an AI coding agent did better in your daily work? Not in a demo, in the actual work. Reply to this email and tell me. I read every reply, and the answers will shape what I build next.

Thanks for subscribing. See you next issue.

John