Building Sherwood
I called it Sherwood in a nod to Robin Hood: I thought the idea of writing a trading bot that carried the name of the forest that Robin Hood himself lived in was fun.
I’d gotten interested in finance as a side project for high-frequency trading and trading on the edges of the market, like crypto. I tend to learn things by building them, so Sherwood became my way to learn by building a self-hosted trading platform that watches the S&P 500 and crypto across a few timeframes, runs strategies against live and historical data, and paper-trades the results. I wanted it to run in a Docker container on a box in my closet, for just the cost of the electricity.
Since I was using agentic tools, it came together quickly. In ten days, Sherwood went from an empty repo to ~17,000 lines of Go, a REST API, five strategies, a backtester, a paper-trading loop, real-time updates, 283 tests and proper CI. I’d describe a feature and it would show up, usually faster than I expected. Pretty awesome.
After a while, though, I started to notice that going fast was starting to slow me down. The first sign was small: I went to extend a part of the system and had to stop and re-learn how it worked. The agent had built it a few sessions back, and even though I’d reviewed it, code you’ve reviewed doesn’t lodge in your head the way code you’ve written does. I knew the system; I just no longer carried all of it in my head.
The sessions got slower, too. Each one started with me re-explaining the same context: the conventions we’d settled on, last week’s decision about how orders were stored, a bug we’d already fixed once or twice. The agent was sharp within a session and forgetful between them, so I spent the first part of each session bringing it back up to speed.
The bigger issue was drift. Small deviations slip through reviews: a convention bent one way, an abstraction that didn’t quite fit. Each looked harmless on its own. They compounded, and I usually didn’t catch a given drift until it had spread far enough that fixing it meant a long refactor instead of a quick change.
None of this sank the project, but it did start to make clear that prototyping using agentic tools is easy, but building something meatier and more significant doesn’t move nearly as quickly.
Liked this? Get new experiments by email — or grab the RSS.