asadjb

I tried out Codex over the past few days. It's good, and the one feature that I really liked was the ability to review the diff inside the app and leave inline comments. No more referring to code by file name and line number, or saying "change this variable inside this function."

But I like using Amp Code more. So I built review-for-agent: a local web UI that shows your uncommitted changes as a diff, lets you leave inline comments, and exports a structured Markdown file you can paste straight back into your agent's chat.

It's a single Go binary that runs locally and works with any agent.

Unfortunately I have started to feel that using AI to code - even with a well designed spec, ends up with code that; in the authors words, looks like

> [Agents write] units of changes that look good in isolation.

I have only been using agents for coding end-to-end for a few months now, but I think I've started to realise why the output doesn't feel that great to me.

Like you said; "it's my job" to create a well designed code base.

Without writing the code myself however, without feeling the rough edges of the abstractions I've written, without getting a sense of how things should change to make the code better architected, I just don't know how to make it better.

I've always worked in smaller increments, creating the small piece I know I need and then building on top of that. That process highlights the rough edges, the inconsistent abstractions, and that leads to a better codebase.

AI (it seems) decides on a direction and then writes 100s of LOC at one. It doesn't need to build abstractions because it can write the same piece of code a thousand times without caring.

I write one function at a time, and as soon I try to use it in a different context I realise a better abstraction. The AI just writes another function with 90% similar code.

I've been an oh-my-zsh user for many years now, being very happy with the very small set of features I use from it. Previously I could never think of trying to figure out how to replicate the features I need without the other features from oh-my-zsh, which does make the shell noticeably slower.

Just now, after reading this article, I used Claude code and have removed the OMZ config within 5 minutes. Here's my prompt - maybe others could find it useful. I ran this from `~/.oh-my-zsh`.

``` Here's my zsh config - I'd like to remove oh-my-zsh and replace the provided functionality with just raw zsh. i use starship for my prompt so i don't need any help there.

  can you explore the oh-my-zsh codebae and see what it would take to replicate the features it currently provides me in the shell?

  my zsh config below:

  export ZSH="$HOME/.oh-my-zsh"
  ZSH_THEME=""
  DISABLE_AUTO_TITLE="true"
  plugins=(direnv fzf)
  source $ZSH/oh-my-zsh.sh

--- CLAUDE RESPONSE --- Minimal Raw Zsh Replacement

  Since you use starship and have DISABLE_AUTO_TITLE=true, you can skip prompt and title-related code. Here's what you'd need:

  # Completions
  autoload -Uz compinit
  compinit

  zstyle ':completion:*' menu select
  zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'  # case insensitive

  # History
  HISTFILE=~/.zsh_history
  HISTSIZE=50000
  SAVEHIST=10000
  setopt extended_history hist_expire_dups_first hist_ignore_dups
  setopt hist_ignore_space hist_verify share_history

  # Directory navigation
  setopt auto_cd auto_pushd pushd_ignore_dups pushdminus

  # Key bindings (emacs mode)
  bindkey -e
  bindkey '^[[H' beginning-of-line      # Home
  bindkey '^[[F' end-of-line            # End
  bindkey '^[[1;5C' forward-word        # Ctrl-Right
  bindkey '^[[1;5D' backward-word       # Ctrl-Left
  bindkey '^[[3~' delete-char           # Delete

  # Colors
  autoload -Uz colors && colors
  export CLICOLOR=1  # macOS ls colors

  # Plugins replacement
  eval "$(direnv hook zsh)"
  eval "$(fzf --zsh)"

```

Granted I've only done this like 5 minutes ago and might be missing functionality I'll realise later, but a quick few checks give me hope I have all the functionality I want.

Thanks for responding and your thoughts! Generally agreed with all you said.

However, I feel like maybe a different approach could be to store all the app state in the DB, and then export to this text only format when needed; like when interacting with LLMs or when someone wants an export of their data.

Breaking the file into smaller blocks would necessarily need a cache system I guess, and then maybe you're implementing your own DB engine in the cache because you still want all the same functions of being able to query older records.

There's no easy answer I guess, just different solutions with different tradeoffs.

But what you've built is very cool! If I was still doing text based accounting I would have loved this.

Love this! I haven't used Beanhup, but was a user of text based accounting systems (beancount, hledger) for many years to track personal expenses. I stopped doing it when I realized I wasn't getting much out of it, but the knowledge of double-entry accounting still helps me to this day when I keep track of my business expenses in Xero.

One thing which I disagree with in this article is the focus on file based data storage:

> That makes it 10 times harder because you need to parse the text file, update it accordingly, and write it back. But I am glad I did. That guarantees all my accounting books are in the same open format.

This quote captures my issues with it. It just makes things so much more difficult; and it makes the whole process slower as the file grows. I remember that when I used hledger for tracking my expenses over 3 years, I had to "close books" once a year and consolidate all the transactions for the past year into 1 entry in a new ledger file to keep entry/query operations fast.

I get the sentiment; you want open data formats that remain even after your app is shutdown. But you can get the same by using open formats; maybe a sqlite DB is good enough for that?

The only thing that would be more complicated with a DB is versioning & reviewing commits like this app does; which does seem like a very exciting feature.

My somewhat limited understanding of this is that from your perspective, an increase in your asset/cash account would be a debit.

A big confusion for me initially was that my banks always talked about crediting my account whenever money was deposited/added to my account.

I finally understood it when I realized that from the banks perspective, an increase in my account is an increase in their liability towards me; they now owe me more money. Which is why they call it crediting my account.

So now I think of it like this: an increase in an asset is always a debit, an increase in liability is always a credit.