Boston · June 2026

The gap between AI that works for one person and AI that works for a team

Every engineer in the room has a private AI workflow that makes them faster. The team has not caught up. The org has not caught up. Individual productivity gains are real, but they are making shared context more fragmented, not less. One person's prompt library is invisible to the next. One person's agent setup assumes context that nobody else has. The question is not whether to adopt AI. It is how to make the gains portable across a team without the workflow changes killing the gains. Two practitioners at this month's event are tackling exactly this: Nirmal Jingar on embedding AI into engineering workflows at Wayfair, and Ananya Shah on the patterns for collaborative AI that work for whole teams, not just individuals.

Anonymous

The question from the room

Everyone on my team is using AI differently. How do I standardize without killing the thing that makes each person productive?

Collected anonymously from practitioners in the room.

Ananya Shah, Cartesian

A practitioner answers

The tension is real: standardize too early and you flatten the individual workflows that are actually producing results. But leave it alone and you end up with ten people building ten private knowledge bases that never connect. The mistake most teams make is starting with shared tools. They pick one IDE plugin, one chat interface, one set of approved models, and mandate it. That kills the gains because the gains come from each person adapting the tool to their own patterns. Start instead with shared context artifacts. A shared prompt library that anyone can contribute to and pull from. A shared eval set that tests what matters to the team, not just what matters to one person. These artifacts travel between people without forcing identical workflows. Someone using Cursor and someone using Claude Code can both reference the same eval criteria and the same prompt patterns. The goal is shared signal, not uniform process.
Subscribe