Case studies

A cancer researcher had collected a dataset and needed to analyze it. The established path leans on published, widely cited software packages and the historical methods the field has standardized on. It's proven, but built around how this analysis has been done.

Rather than starting from those methods, we started from the science. Working together, the researcher defined what meaningful biology actually meant for this dataset, and we used that definition to inform the statistical and mathematical methods we reached for. Coding agents let us move quickly from a scientific question to working analysis and plotting code, so the conversation could stay focused on the biology instead of the code or tooling.

I paired with the researcher throughout, steering the coding agents and translating scientific intent into analysis code: implementing approaches, iterating on visualizations, and helping surface potentially meaningful signal in the data they had collected.

A trader at a hedge fund had an idea for a backtesting framework. We started with an extensive conversation about how the framework would function and the data it would include. That covered how it needed to stay extensible as new datasets were added, and how it had to support data from different sources like CSV, Excel, API calls, and proprietary stores.

This collaborative interview became the starting point from which we produced a technical spec with the help of an agent. We refined this spec together until it captured how the system should actually work. From there, we turned back to the agent for an implementation and shipped a first version of the tool.

My role was to run the interview that pulled the design out of the trader's head, shape it into a spec we could both stand behind, and drive the implementation, keeping extensibility across data sources and providers a first-class concern from the start.

The CTO of an early-stage technology company was classically trained in engineering and had experimented with agents but hadn't adopted them heavily in their day-to-day coding. We paired together on their actual work for the day.

We started with a conversation about what they needed to accomplish that day, which became the raw context we used to build a technical plan with an agent that we reviewed and refined. That plan was the spec for the implementation. We pushed this first pass implementation PR, reviewed it together in GitHub, and left feedback as comments. The agent processed the feedback and made the changes.

Throughout, I helped this engineer and leader externalize their thought process and turn their domain expertise into the context the agent needed to produce a satisfactory implementation. I introduced processes, like voice-to-text for capturing context and a planning-first approach, while keeping them as hands-on with engineering as they wanted, so the code ended up the way they intended and they didn't feel like they were giving up control of the parts they felt were important.

A senior engineer at a big tech company already used coding agents day to day. We worked together on two separate items that contributed to their work.

The first was a review of a project they were midway through, with some PRs already merged and the rest in progress. We recorded the conversation as I interviewed them about it: the motivations for the project, how it would be carried out and why, the possible edge cases, how it would be rolled out and de-risked, and what success would look like. With that context captured, we prompted the agent to investigate the state of the project alongside the direction we had articulated, grounding its exploration in the code and asking it to raise anything we had missed. It surfaced an element they hadn't accounted for, which proactively saved them roughly two weeks: an override applied elsewhere in the system meant the experiment's treatment wouldn't have reached all of the intended users, so the results couldn't have justified a rollout. Left uncaught, the work would have produced inconclusive metrics and needed to be repeated.

The second was personal-productivity work. We discussed their development workflows in depth, shaped by the constraints and tools they used at work: when they rebased, squashed commits, or added commits on top of what had already been squashed, and why. We codified these as a set of personal skills for their agents, so the agents would default to the workflow the engineer had already been applying by hand rather than needing to be steered toward it each time.

Over several sessions across many months, I worked with a designer to help them build a personal agent, before today's off-the-shelf personal-agent products existed. They run it on their own computer and reach it through a number of different chat interfaces, and they build features for it entirely from their phone.

When we started, they had no coding experience and no experience with coding agents or language models. We worked up from fundamentals: how to effectively steer language models, how to manage context windows, and how to get the most out of models while avoiding pitfalls.

From there we moved on to coding agents. Today they independently build complex applications: the personal agent itself as well as design productivity tools for their professional role.

A designer and retouching expert, fluent in professional image-editing tools, was intimidated by coding agents. For a campaign, they had been spending extensive time manually generating image assets with an AI image model, and they had a vision for moving faster: create assets in bulk, then filter down, tweak, and iterate. From there the ideas kept coming, like using the image models to stage the items, make lighting adjustments, and more.

We discussed the idea together and built their first prototype with me driving, since they were apprehensive about using a coding agent themselves. With that foundation, I introduced them to making their own changes and managing the coding lifecycle with git through the agent, using it to make checkpoints they could revert to when they wanted a stable state. Repeating that process built their confidence that they wouldn't break what was already working, and freed them to do more ambitious experimentation.

When those attempts didn't work, I helped them develop persistence and strategies to approach a problem from multiple angles and to use the agent to drive the debugging. Today their professional role has evolved from purely creative to design and engineering: they build and maintain tools used by their entire design organization, and they keep pushing the boundaries of the role.

An operations professional worked at a company with a mandate that everyone builds and contributes to the production codebase. Their background was in operations, with some familiarity with SQL but no software engineering experience.

The task was to build a feature that one of the clients they supported needed in their company's operational portal, adding it to the production codebase in a way engineering would approve. First, we had to get a local development setup working, resolving local database and login flow issues, to provide a foundation to test our changes. We then discussed how to scope the pull request, deciding what belongs in the change and what to leave out, to give it the best chance of being approved, and built a working understanding of the development-to-staging-to-production promotion process: how it enables safe testing and keeps bad code from reaching customers.

My role was to help them contribute real production software despite coming in without an engineering background, turning their operational knowledge of what the client needed into a change that could move through the team's review and release process on its own merits.