Benchmark – Ascenda

What founding teams get

Early access to Ascenda Flow

Give your engineers visibility into their own AI coding activity and working patterns (macOS). Using Flow doesn't require contributing to the study.

Your team's working patterns

Understand concurrency, steering, review and how work changes across the week, in aggregate across the team.

Compare with your peers

See how your team compares with other AI-native engineering teams as the benchmark develops.

Founding cohort access

Receive early findings and help shape which questions Ascenda investigates next.

Your engineers install the collectors once, then use their tools as they normally would. After a one-time setup call, there are no meetings or surveys, and nothing changes in how you work.

Taking part is free, and each engineer chooses what to contribute. Your benchmark arrives once the cohort has enough teams comparable to yours. Founding teams also get preferential terms on paid team studies later, if you want to measure the effect of a specific change.

Try the technology

See what your AI tools are telling us.

Curious how it works? Try Waterline, our free screensaver that turns live AI coding activity into a moving water level.

A small glimpse of the signals behind Ascenda Flow.

Try Waterline, it's free →

What we're investigating

Some we can answer from day one. Others need outcome data, which comes in phase two.

Measured from day one

Concurrency: How many agent sessions do people run at once? When they run more, does more get done, or does more of their time go to supervising agents?
Who carries the review load: As agent output grows, is the work of checking it shared across the team, or does it fall on one or two people?
Steering: How often do engineers correct or redirect an agent, and does that change as a team gets more experienced with them?
Long sessions and context: How long do agent sessions run before context limits set in, and how do teams deal with it?
Out-of-hours work: Is agent work moving into evenings and weekends, because agents can keep going when people stop?
Rework inside agent sessions: How often does agent work get undone before it leaves the session, and does that change with concurrency or session length?
Commit and merge rhythm: Do teams working with agents commit and merge in small, frequent steps, or in large batches?

Phase two

Which ways of working hold up: Which patterns produce work that lasts, meaning it isn't reverted or heavily reworked in the days after it ships?
Review latency: How long does agent-written work wait for review, and does the wait grow as output grows?
Over to you: What do you want to measure?

How it works

1
Connect your tools
Each engineer installs Ascenda's open-source collectors for the tools they use: Claude Code, Codex, Cursor, VS Code, Windsurf or Gemini CLI. Each takes one command.
2
Explore your own data
Each engineer sees their own working patterns in Flow first, and chooses what to contribute.
3
Compare your team
Once the cohort has enough teams comparable to yours, you'll get a benchmark showing how your team's working patterns compare.

Setup details

Platforms: Flow is macOS-only today. The collectors aren't, so if your team mostly works on Windows or Linux, apply anyway and we'll follow up about how taking part works for you.
History import: Existing agent history can be imported, so your comparison starts from months of data rather than from day one. Importing needs its own consent.
GitHub collector: One GitHub Actions workflow, which we set up with you during onboarding. Each engineer's pull requests and reviews are recorded under their own identity, and review data isn't collected until that's in place.
Consent: Editor and agent data, and pull-request and review data, are separate consents. Each engineer gives them individually and can withdraw either at any time.

Your code stays yours

The collectors are open source, so you can inspect exactly what they record.
The study receives activity metadata: timestamps, event types, counts and classifications.
Source code, prompts, agent responses, file paths and review comments are never sent.
Each engineer chooses whether to take part, and can withdraw at any time.
Founders receive aggregated team results. Groups too small to hide an individual are suppressed, and there is no view of any one person.

Tests in the collectors confirm the excluded fields are never sent. View the collectors on GitHub · Wire contract · Trust

Exactly what the collectors send

Sent to the study

Event types and timestamps, e.g. "agent tool call started", "correction prompt", "review given".
Counts and classifications, such as which kind of work an event belongs to.
The kind of git action an agent ran (commit, push, revert), not the command itself.
Your local time-zone offset, so after-hours work is judged against your hours.
An 8-character hash in place of the repository name, so "is this the same repo?" can be answered without naming it.
The version of the collector that sent it.

Never sent

Source code.
Prompts or agent responses.
File names, file paths or branch names.
Repository names, pull request titles or numbers.
Review comments.
Terminal output.
Anyone else's GitHub username.

Methodology

We're starting with observable working patterns: concurrency, steering, review activity and rework. As the cohort grows, we'll investigate which patterns go with better engineering outcomes. Every comparison includes its sample size and data coverage.

Read the methodology

Phase one measures working patterns. Phase two examines outcomes.: We can see how teams work with agents, but not yet whether one way of working leads to better results. We'll announce when phase two starts.
Teams are compared, not ranked.: Activity counts aren't a measure of anyone's value or performance, and the study doesn't assess individuals.
The cohort is self-selected.: Findings describe small, AI-native teams who chose to take part, not the industry as a whole.
Coverage depends on setup.: We only see the tools each engineer has connected, and only GitHub repositories with the collector added. Rework is only counted when an agent ran the git command.
Missing activity is treated as missing data, not inactivity.: There is no "didn't review" event, and quiet periods aren't scored.
Every comparison includes its sample size.: Where too few teams can be compared, we report that instead of a number.

How are small teams actually working with AI agents?