Case studies.

Dr. Gabriel Salzman, a hematology and oncology fellow at Stanford, works with spectral flow cytometry, which measures dozens of markers across millions of cells. Datasets that rich are still usually analyzed with the same manual gating used for classical flow cytometry. Computational methods that explore far more of the data are published, but implementing even one well is real work, and each method sees the data its own way.

Gabriel chose the questions and decided how we would know an answer was right: any population the analysis flagged had to be reproducible by hand in FlowJo from the same raw data. With that rule in place, we directed AI agents to search the literature for suitable clustering and population-discovery approaches, implement and tune each one, and build a dashboard for comparing what they found. Agents also helped train a model that draws gates automatically.

Along the way, a custom view built during the analysis showed that a population of interest was being blurred together with phenotypically distinct cells, something the summary statistics hadn't revealed. That pushed us to broaden the set of methods, and together they surfaced clearer hypothesis candidates than any single one. Early on I steered the agents. Over time Gabriel took the controls, and today he extends the analysis himself.

The work became a poster, “Dynamic AI Agent-Built Visualization Tools for Scientific Inquiry,” at the New York Scientific Data Summit (NYSDS) 2026, which I presented as first author.

The analytics team at the Center for the Helping Professions needed to categorize a large body of written records. Reviewing them by hand limited which questions they could ask, and the data had to stay in a highly secure environment.

We started with discovery: what each category actually meant, and how we would know a label was right. With those definitions agreed and expert-labeled examples as the reference, we built a workflow that classified the records with language models inside the secure environment, at a scale that hadn't been possible in their work before.

Comparing the models against the expert labels proved useful in both directions. Some disagreements were model errors to fix. Others led the team to rethink how they had been labeling, which helped them understand their own research questions in a new way.

Over six months the work moved from my hands to theirs. Dr. Elizabeth Riley, the team's Chief Analytics Officer, took it over and has continued to extend it for the team's needs.

A program management leader ran a planning and reporting process that senior leadership reviewed every month. It lived in a spreadsheet touched by dozens of teams, held together by hand-pasted updates and constant shepherding. Migrating to a real tool had been “next quarter” for over a year, stuck behind budget and tool-consolidation debates.

They came in trying to get AI to do the task. The turning point came early: stop automating the spreadsheet and build its replacement. We started by proving the foundation: that they could stand up and share a working application inside their company at all, before investing in any real functionality. With that settled, a long spoken interview became the spec. I asked how the process actually worked and what good would look like, played my understanding back to them, and we shaped that conversation into a plan we reviewed and refined together.

From there they built in phases, their hands on the keyboard the whole time. Each phase ended the same way: try it, react to it, fold the feedback into the plan, checkpoint, and move on. When a path was painful the first time through, we distilled it into a reusable skill so it never had to be painful again. Between sessions they shipped improvements on their own, and my role shifted to the moments that benefit from experience: catching a wrong turn early, structuring context, and weighing in on the few decisions worth being opinionated about.

Within ten days of the first session they had a working tool they were showing colleagues and preparing to bring to leadership as the replacement for the process, including answering an executive's wish to simply ask an AI assistant for a team's status update. In their own words, the shift was simple: they stopped asking AI to do the task and started asking it to build the tool that does it.

An update they sent after the sessions ended: “Thanks to you, I launched my app to production and migrated and provisioned my own standalone service, despite Claude and at least three different engineers telling me I wasn't going to be able to do it solo.”

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.