Adam Coddington · Senior Staff Engineer at Airship · Chicago

Hi, I'm Adam. I'm usually the one asking what the number actually means.

Adam on a boat on the Nile, looking out over the water

Most of the teams I've worked on weren't stuck because somebody wrote bad code. They were stuck because something everybody trusted had gradually stopped being true: an estimate, a metric, a process that worked fine back when we were smaller. I've found I'm pretty good at noticing when that's happened, and that it goes down a lot better when I turn up with a replacement rather than just the bad news.

My day-to-day job is Airship, where I've spent thirteen years on a $25M ARR product used by 80 enterprise customers and about 10 million people, with one US patent granted and another pending. The rest is open source, which is where I get to try things out at a size where being wrong is cheap.

227 Public repositories
19.9k People using Recall 673k REST API downloads
Say hello GitHub Résumé

Things I believe

Mostly about feedback loops

Three things I've had to argue for more than once. They're really all the same argument: most of what goes wrong on a team is a feedback loop that's too slow, isn't closed, or has accidentally started measuring the wrong thing. I've tried to bring the receipts, since I think an argument like this is a lot less interesting without them.

Ship the valuable part first, then decide if you need the rest

Our customers wanted a way to get messages signed off before they went out, and the project came to us forecast as a big one. We built the obvious part first, and it turned out to cover 90% of customers for roughly 10% of the forecast effort. I don't think that was clever analysis so much as ordinary sequencing: go after the easy value early, get it in front of people, and then make the rest argue for itself against everything else you could be doing. Mostly, it didn't win that argument.

The bottleneck usually isn't the model, it's you being in the loop

A lot of people are finding these tools disappointing, and I think that's usually a workflow problem rather than a model problem: drop AI into a process designed around the old costs and you tend to move the work rather than remove it. Step back and look at the whole thing, and the problem often dissolves. It also changes what's worth attempting at all. Reverse-engineering iCloud's sync protocol was never worth months of my time, but with AI in the loop it was worth a few weekends, and at work I led four AI features into production on the same thinking, the first cutting journey-building time by 83%. The biggest accelerator I've found is giving the model some way to check its own answer, because Goldratt's The Goal applies here as much as it does on a factory floor: time saved anywhere but the constraint isn't really saved, and if the model has to come back to me to find out whether it got it right, the constraint is me.

A number that moves when you start looking isn't measuring anything

We had an overnight check that counted errors in our data, and every so often we'd think of a new kind of error worth looking for. The count would jump, and it always looked alarming. But those errors had been there the whole time; we simply hadn't been looking for them. The metric was meant to tell us when things were getting worse, and mostly it told us when we'd gotten more observant, the same way screening more people for a disease reliably finds more of it without anybody having gotten sicker. I argued we should only count the error types that existed when we set the metric, and I lost that one, which I think about more often than I'd like.

Almost none of these loops got designed on purpose; they accumulated, and everybody learned to work around them. The work I've enjoyed most has usually been going back and building the one that should have been there in the first place.

Products

No programming required

Things you can pick up and use. The full collection is on GitHub, but these are good places to start.

Recall for Obsidian

19.9k users

A deep integration between your browser and your notes in Obsidian. Take notes about the page you're on, or mark a link with a decision you've made ("ruled this one out", say), and the next time that link crosses your path, your earlier judgment is right there waiting for you. The idea is to make your notes actionable on the web.

inthe.am

★ 587

A hosted companion for the Taskwarrior task manager. I built it, ran it for ten years, and, when the time came, retired it gracefully. The whole life of a product, start to finish.

icloud-md

New · 2026

Your Apple Notes as plain Markdown files on any OS: diffable, greppable, and yours. iCloud's sync protocol is undocumented, so I reverse-engineered it with AI's help. The latest in a long habit of getting data back out of walled gardens.

Your recipes, out of the app and into your files: Paprika recipes as plain Markdown you can read anywhere, edit in anything, and push back.

One key, every device follows: Logitech's Flow reimplemented in software for Linux, clipboard included.

Developer tools

For people building their own things

Libraries and bridges that other projects build on top of.

Obsidian Local REST API with MCP

★ 2,805 · 673k downloads

The standard bridge between your code (and, increasingly, your AI agents) and your Obsidian notes. It's secure, local, and extensible enough that an ecosystem of plugins builds on top of it. It's the engine behind Recall for Obsidian, above.

Programmatic access to your MyFitnessPal data: the library behind a lot of personal-health dashboards and, somewhat to my surprise, a citation in published nutrition research.

markdown-patch

New · 2026

A structure-aware patch format for Markdown: target a heading, block, or frontmatter field instead of a line number. No regex, no sed.