The measurement layer for human × AI engineering
Make AI engineering measurable.
AI adoption tells you what’s being used. Delivery metrics tell you what gets shipped. Ascenda measures how engineers work with AI agents, helping enterprises understand which practices improve effectiveness and which introduce additional demands.
- Steering
- Decision load
- Focus and fragmentation
- Interruptions
- Rework
- After-hours
Works with Claude Code · Codex · Cursor · Gemini CLI
- Counts, not content
- No source code leaves your Mac
- No individual view
A sample 90-day Study report. Figures are illustrative only.
For engineering and AI leaders
Know which AI engineering practices to scale.
AI coding agents are changing how software gets built. But higher adoption and faster code generation don’t necessarily mean better engineering outcomes.
Ascenda helps engineering leaders understand where AI-assisted practices are working, where they introduce additional supervision or rework, and which changes deserve further investment.
Expand
Practices associated with better engineering outcomes.
Modify
Workflows introducing unnecessary interruptions, supervision or rework.
Reconsider
Approaches that aren't delivering the expected improvement.
Make decisions using operational evidence, not adoption figures or assumed productivity gains.
The missing measurement layer
We know what goes in. We know what comes out. Ascenda measures what happens in between.
Licence counts and usage dashboards describe adoption. Delivery and cost figures describe results. Neither shows how engineers are working with AI agents, which is where a practice succeeds or adds work.
AI adoption
- Licences
- Active users
- Usage volume
- Tool expenditure
What goes in
Human–AI engineering
- Agent supervision
- Concurrent work
- Interruptions and rework
- Decision load
What Ascenda measures
Business outcomes
- Delivery speed
- Software quality
- Engineering costs
- Business value
What comes out
Ascenda measures the middle layer. Whether a practice changes a business outcome is what the 90-day evaluation investigates, against a frozen baseline and the delivery data your organisation already holds.
From data to decision
From engineering activity to better decisions.
A report follows one pattern from the record to a decision: what the team does, what goes with it, what they change, and what happened next.
01 · Observe
A team frequently runs nine agents concurrently.
02 · Investigate
Higher concurrency appears alongside additional tool failures and rework.
03 · Change
The team trials a limit of four concurrent agents.
04 · Compare
Results are measured against the original baseline.
Illustrative scenario using simulated findings. Ascenda’s working reporting technology processes real engineering activity; the example does not represent a validated customer improvement.
The 90-day evaluation
From measurement to measurable improvement.
A structured 90-day engagement that establishes a baseline, tests agreed changes and measures their effects.
- Days 1–30
Establish
Measure how engineers currently work with AI agents. Identify patterns in supervision, interruptions, concurrent work and rework.
DeliverableBaseline report and improvement opportunities.
- Days 31–60
Improve
Review the findings with engineering leaders. Agree on a targeted change to tools or working practices and implement it within the participating cohort.
DeliverableAgreed improvement plan and progress measures.
- Days 61–90
Validate
Compare results against the baseline. Relevant delivery and quality measures available from your organisation can sit beside the readout.
DeliverableEvaluation report with evidence to inform engineering and investment decisions.
- It needs
- A cohort of ten or more engineers who choose to join, Flow on their Macs or the open-source collectors, and one setup call. No source-code access, no single sign-on integration, no change to your AI tooling.
- Commercials
- Priced per engagement and quoted after the setup call.
Not ready for ninety days?
The 30-day AI Exposure & Work Composition Report is an initial diagnostic: one cohort, built from history the tools already hold, with a written baseline and a proposed measurement plan.
The Report and the Study →Help build the benchmarkBuilding
We’re building a benchmark of how engineering organisations work with AI agents, starting with scaleups. Organisations that take part see their own teams in it first, and the comparison with others grows as more contribute.
Join the scaleup benchmark →Built for environments where trust matters
Evidence about the work. Never a view of a person.
Flow reads your AI tools’ local history and live activity on your Mac. What it sends is counts, timings and tool events, never your prompts, code or model outputs. Your journal and reflections stay on your Mac unless you turn on sync.
Local-first
The reading happens on the engineer's Mac. The count is what can leave; the prompt is not sent.
Counts, not content
No prompts, code, model outputs, file paths or command lines are sent. Repository names leave only as salted hashes.
Aggregate only
Figures are shown for ten or more people and withheld below. A manager view of an individual does not exist.
Opt-in, per person
Each engineer chooses whether to join, is told exactly what each purpose shares, and can withdraw any of it on its own. The organisation never learns who joined.
The shift
Less writing code. More directing, checking and deciding.
AI made engineers faster. But somewhere along the way the job changed shape. More of the day now goes on supervising: running several agents at once, reading code you didn’t write, holding the context they keep dropping.
You’re still in the loop. The loop just looks different now. AI didn’t remove pressure. It changed where pressure lives.
Directing
Framing the task, picking the context, deciding what the agent is and isn't allowed to touch.
Dispatch. 7 sessions sent subagents
Checking
Reading output you didn't write, as fast as it arrives, and deciding whether you trust it.
Holding. Sessions waited on you more than usual on 3 days
Deciding
Approve, correct, re-prompt, abandon. A steady stream of small judgement calls, often across several sessions at once.
Vectoring. 612 prompts across the week
Glyphs drawn from example counts.
Two signal classes
The relationship is the signal.
Flow reads how much the work asked from the tools you already use. What it can’t read, it asks you: how it felt. Telemetry can tell you the shape of a day. It can’t tell you whether that day left you sharp or flattened.
The work · read from your tools
What did the work demand?
Read from your AI tools’ own activity. Counts and timings, not content.
Steering: hands-on time versus time spent supervising agents
Work in flight: how many sessions and agents are running at once
Switching: moves between tools, projects and contexts
Session shape: focus blocks, long unbroken stretches, when the day ran
Interventions: permission prompts and stalls that pull you back in
Context and compaction: how full the agent's context ran, and how often it compacted
Rework: tool failures, re-prompts and retry storms
After-hours: how much of the work spilled past the working day
The human · you tell us
How did that demand land?
A ten-second check-in, in your words.
Pressure: strained or clear, and whether the work read as challenge or threat
Clarity: how clear the task and the next step felt
Activation: drained, or activated
Recovery: for engineers who pair the phone companion; never shared with an organisation
Same workload. Different landing.
Engineer A
Four agents in flight, heavy review, a long stretch. Reports clear, activated, read as challenge.
Engineer B
The same shape of day on paper. Reports strained, drained, read as threat.
On telemetry alone, that’s the same day twice. Add what each of them told us and it’s two different problems, with two different fixes.
The machine record
The machine already contains the record.
Every AI coding tool already keeps a log of the new job. Sessions, tool calls, retries, compactions, approvals. Most people never look at it. Flow reads it on your Mac and turns it into a picture of how your work actually ran.
And it doesn’t start from zero. Flow can import the weeks you’ve already worked, so the first read isn’t a blank page. From then on it runs live.
The Reveal, at the end of Flow’s history import: months of work your tools had already recorded.
Counts, not content.
Flow reads your AI tools’ local history and live activity on your Mac. What it sends is counts, timings and tool events, never your prompts, code or model outputs. Your journal and reflections stay on your Mac unless you turn on sync. Exactly what Flow reads and sends →
The feedback loop
See it. Change it. Measure what worked.
Ascenda is built around one loop: change one thing and find out whether it helped, for one engineer or a whole team.
For the engineer
- See it
Flow reads your week back to you: how the work ran, and how you said it landed.
- Change it
You choose one thing to change, and the measure it should move.
- Measure what worked
It comes back on a set day. Flow shows what the record did next, beside your own verdict, and keeps the two separate.
For the organisation
- See it
See aggregate human × agent working patterns across a cohort of ten or more.
- Change it
Declare a change before you make it: what changes, the measure, the baseline and the window. The baseline freezes.
- Measure what worked
The readout is reported whichever way it goes. Keep it, change it or stop it on the evidence.
What a readout looks like
Before
Sessions running · a representative day, weeks 1 to 9
9 at once. One line per session in flight at the busiest quarter-hour.
After
Sessions running · a representative day, weeks 10 to 12
4 at once. One line per session in flight at the busiest quarter-hour.
The readout
- Next-day tool failures per active hour
- 1.9→1.1
- Next-day tool failures per active hour
- Declared measure
- Active hours per engineer: the same amount of work
- 13.9→13.6
- Active hours per engineer: the same amount of work
- Sessions running at the peak
- 9→4
- Sessions running at the peak
Fewer agents at once, the same hours, and less rework the next day. The measure moved in the direction the cohort declared.
The Ascenda system
Work → Human → Change → Readout.
Each time round the loop leaves a record of four things: how the work ran, how it landed, what you changed, and what happened next. Stack enough of those up and you start to see which ways of working hold up, for the work and for the people doing it.
WorkWhat actually happened?
The machine record of the human × agent loop.
HumanHow did it land?
What the engineer reported, in the moment.
ChangeWhat did the engineer or team alter?
One declared change, with its measure fixed in advance.
ReadoutWhat happened next?
To the work, and to what people told us.
Human-performance science
Software telemetry tells us what happened. Human-performance science helps us understand what it asked of the person.
Ascenda was started by a software-systems engineer and a psychologist. A team of only telemetry engineers would measure the system beautifully and the person badly.
Who builds Ascenda →Measurement
What a signal can and cannot tell you, and how to say so.
Work demand
Separating what the work asked from how the person met it.
Human state
Pressure, clarity, activation and recovery, as the person reports them.
Change
Designing a change so its result can be read honestly.
The 90-day evaluation
Learn which AI engineering practices are working.
Establish a baseline, test an agreed improvement and compare the results over ninety days.
- Establish a baseline
- Agree one change
- Compare against the baseline
- Keep what works
Machine telemetry can tell you how the work ran. Human signals can tell you how it landed. Ascenda connects the two to learn which ways of working hold up.