The Studio Model for Agentic Engineering

I visited the de Young museum for the first time this weekend with an old high school friend. While walking around the Hudson School wing of the museum, I came across a study that Albert Bierstadt created for his painting “The Last of the Buffalo”, which I had previously seen in the National Gallery of Art in DC while visiting this same friend.

This painting was the only one that struck me enough to pause and take a photo with while visiting the National Gallery. I’ve always been enamored by the setting of the West, and Bierstadt’s “The Last of the Buffalo” does a great job of capturing the sweeping, epic narrative both from a natural and human perspective.

What I never realized until seeing the study at the de Young was that it’s common for artists, especially from the Hudson School like Bierstadt and Cole, to work incrementally towards a final piece by creating a number of “studies”. Here’s an excerpt of a conversation I had with Claude about it:

For Bierstadt specifically, studies were essential to his whole practice. He’d travel west on expeditions, sketching and painting small oil studies on site, capturing the actual light, geology, weather, and animals he saw. Then he’d return to his studio in New York and use those studies as raw material for the enormous, dramatic canvases he became famous for. The studies were truth-gathering. The finished paintings were composition and theater built from that truth. “The Last of the Buffalo” exists in multiple versions and was developed from numerous on-site studies of buffalo, plains landscapes, and Indigenous figures Bierstadt had observed and sketched over years.

This really resonated with me because I’ve been trying to be more intentional about approaching my work as a software engineer in this tumultuous era of AI as more of an artist (deliberate intentional practice is a great blog post from Geoffrey Huntley about this).

Authoring code is effectively a solved problem as of this writing, but the act of exploring the solution space to a problem is still a core part of the “taste” that defines a great engineer. Artists do this through studies, software engineers do this through spikes:

A spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions.

In a pre-AI era, spikes were considered a luxury good, a treat for an engineer to get to hack on some code without the drudgery of producing production-ready code. But with LLMs, we can kick off as many parallel spikes on a subject as we’re willing to allocate tokens.

When exploring the solution space to building a CLI tool for example, you can now ask an LLM to implement it in Go, TypeScript, and Rust, let it rip for a few hours in a sandbox, run the same evaluation script across all the builds, and get a sense of the tradeoffs between each implementation.

I think this is a perfect example of where LLMs can actually enable us to be more creative, despite the prevailing narrative outside of the SF bubble that AI is antithetical to creativity. Imagine the resources that would have taken just a few years ago! Now you can run that entire process from your phone while out on a walk in the park and check out the results when you get home.