The Eventually Consistent Codebase

Published ....
Last modified ....
From Boston, MA

Share this post on BlueskySee discussion on Bluesky

The widely prevalent mindset around how to maintain codebases since at least the 2010s could be roughly described as:

• keep main green
• improve the codebase quality with every change

I think these concepts still hold true in the agentic engineering era we find ourselves in at the moment, but the tools we have at our disposal to keep those true have changed and we need to accept that change more willingly.

Importantly, usually both of these criteria were kept in check manually, either via code review from another engineer on the team or through manual checks throughout the process (e.g. reviewing the status of CI after merging in your changes).

This workflow that we used up until now was very short term sighted, we optimized for each individual unit (PR/commit to the main branch) being “perfect” and not the longer term state of the codebase.

With the availability of agents, we need to flip this workflow on its head and instead take a longer term view of the codebase - something I’ve been calling the “Eventually Consisitent Codebase”.

We need to start looking at the codebases that we maintain and evaluate them on the longer term time horizon, this means we should lean in on:

• Agents reviewing PRs and shipping them to production without requiring additional human oversight
  • Honestly this is something that should have been true before we had coding agents - when I hear that a team requires another engineer to review a change to the codebase (don’t even get me started on requiring two approvals) that tells me that you lack trust in the engineers contributing to it!
• Iterating on the codebase with each individual change