AI for coding on a large codebase with a big team, so far

Everyone’s dealing with the introduction of AI into the wild at this point. Either explicitly by going all-in and pushing people to use it as much as possible, or it being outright banned and there’s a significant portion of people using it in the shadows in unideal ways.

Where we are today

We’ve landed somewhere in the middle at ShipHero (in June 2025, I’m sure this will be out of date in like 2 weeks!). We’ve adopted an official AI code assisting tool (SourceGraph Cody) and signed up for the enterprise plan so we’re fully in compliance, and made it available to everyone in the company. People use it for both auto-completion and agentic coding (chatting with it and having it output code until it looks like what you want).

Intro

Recently my daily routine changed a bit as I assumed a different role within the organization. Among my new daily interactions is the chance to have technical conversations with one of our main Architects about various design matters of the software. This gave me the chance to reflect on the usefulness of some tools I have not used in a long time: software patterns.

But, what are patterns

A Software design pattern, as defined in wikipedia is:

Intro

At ShipHero, we try to give back to the community as much as we can. Every time we build an internal tool that we know could benefit other devs outside the company, we package it in a way that can be shared. Sometimes it ends up being useful, sometimes not, but it’s important for us to make those available to leave that door open.

As with any company with some years behind it, we have a variety of code that ranges from new and up-to-date with the latest good practices to ancient and in need of improvement. Being a live company with a product that is very much alive and constantly evolving, we are quite sure that most of our code gets updated over time (we actually check this, and when something is not scheduled to be modified relatively soon and we think it doesn’t meet a minimal quality standard, we do ad-hoc refactors).

Long story short, at ShipHero we’ve moved away from using logs to debug our software and are all-in on using metrics — Honeycomb, OpenTelemetry-based specifically!

It’s one of those things that in hindsight seems easy to do, something that we should have done years ago, and that’s a no-brainer for any new project. But if you’ve been around software long enough you’ll understand why so many things seem easy in hindsight and super hard at the time.