Daniel Tao

Daniel Tao led engineering for Bitbucket Cloud during its move to AWS, when his team migrated more than 50 million repositories. His work at Atlassian later shifted from leading individual products to the infrastructure Atlassian’s own engineers use: AI Engineer Code 2026 listed him as Lead Principal Engineer for Developer Infrastructure.

Dan studied philosophy at Duke, spent a year in Namibia with WorldTeach, and went on to graduate study in software engineering at Carnegie Mellon’s Silicon Valley campus. Before Atlassian, he worked in algorithmic trading, consulted at ThoughtWorks, worked at the startup Cardpool, and joined Google’s Ads Review team. He also created Lazy.js, a JavaScript library that does only as much work on a sequence as the caller needs. To return the first five lines of a long string, for instance, it can stop at the fifth line without splitting the whole string into an array.

Keeping Bitbucket responsive

During the 2021 migration, a slowdown exposed how much Bitbucket Cloud’s Git traffic depended on disk access. Automated builds repeatedly checked repositories for changes, competing for resources with developers cloning or fetching code. Dan’s team began serving cached Git packfiles, allowing some requests to bypass the file system and freeing capacity for operations that still needed it. Dan explained the fix to customers and later announced the completed migration.

Dan also led engineering for Confluence, DevOps Products, and Compass, where he oversaw the Compass beta launch. Compass gave developers a software component catalog: an engineer working with an unfamiliar service could find the team responsible for it and its documentation in one place.

What a reviewer needs to see

Dan’s 2026 session proposal starts from a limit of human attention: when AI makes code faster to write, a reviewer still has to decide whether the change does what it should. He proposes running automated checks locally to flag patterns the team wants to avoid or changes that break expectations other code relies on. For a change that reaches a reviewer, a tool such as Taro can start a live environment, simulate a user interaction, and produce a narrated recording of the change running. The video shows what happened in one run. Test results, automated evaluations, and risk scores can help the reviewer decide which parts of the code need a closer look.

The proposal also questions the convention of one small pull request per ticket. Dan sees that convention partly as a consequence of how long it used to take people to write code. When writing gets faster, the question is how to organize changes so reviewers can spend their time judging what the software does and where it might fail.