# AI development workflow assessment: method and interpretation

Version 1.0, October 15, 2026. This is Hamed's practice-based discussion tool for teams considering the playbook. It is not a validated maturity scale, benchmark ranking or forecast of gains. The categories and interpretation rules are editorial choices, not weights learned from research.

## Why six areas

| Area | Questions | Useful evidence |
|---|---|---|
| Delivered work | Comparable monthly output; expected additional output | Accepted tasks per developer-month, work class, human time, repairs |
| Usable AI capacity | Allowance use; main constraint | Provider meter basis, ready work, waiting reasons, limit events |
| Full task cost | Accounting coverage; enforced limits | Prep, failures, work, reviews, retries and coordination; subscription allocation and unknowns |
| Shared coordination | Cross-tool state; safe claims | Stable identities, current ownership, decisions, handoffs, version conflicts and recovery |
| Planning to delivery | Grooming/assignment; accepted-plan-to-production time | Readiness, dependencies, timestamps, stage waits, separate release evidence |
| Acceptance and quality | Completion evidence; follow-up and human burden | Exact-revision acceptance, relevant checks, repairs, reverts, incidents, human time and feedback |

These areas connect to the playbook practices and to two measurement principles: productivity has multiple dimensions (SPACE), and delivery throughput needs to be considered with instability and context (DORA). This assessment does not reproduce or validate either research instrument. It is narrower than a full developer-experience assessment.

References, copyable URLs:

- SPACE, Forsgren and colleagues, 2021: `https://queue.acm.org/detail.cfm?id=3454124` (DOI `10.1145/3454122.3454124`).
- DORA software delivery performance metrics: `https://dora.dev/guides/dora-metrics/`.

## How the profile is produced

Each answer carries a visible finding, a next action and a measurement suggestion. Unknown answers produce measurement gaps; partial practices produce improvement opportunities; reported established practices produce verification/observation prompts. Expected-output answers are ambitions and do not improve the profile. The result uses no overall score, arbitrary weighted multiplier or developer ranking.

A group's label follows its selected answers: unanswered questions mean Not complete; otherwise an unknown evidence answer means Measure first; otherwise a reported gap means Worth testing a change; otherwise Keep verifying. Ambition answers do not alter this label. The stated main constraint supplies a starting point. It does not prove a root cause or rank financial return.

The complete report is available only after all 12 questions have answers. It contains every selected answer and the corresponding interpretation, actions and measures. Participants should review it together, choose one change and track its effect. Answers are self-reports until checked against records. The form does not submit answers to Hamed or a backend; copying, downloading and sharing are actions the reader chooses.

## Numeric comparisons and targets

Optional observed values are rates of accepted tasks per developer-month for comparable work, acceptance and developer time. Their ratio is the AI-assisted rate divided by the baseline rate. A zero baseline has no defined multiplier. Missing, negative or non-finite inputs never become zero or a claimed improvement. Even with comparable inputs, the count ratio is descriptive; changes in work mix, process, staffing and quality can explain it.

The expectation question asks for additional output: +0.1× means 10% extra, or 1.1× total; +1× means 100% extra, or 2× total. These are hypotheses. Commits, PRs and tasks are different units and cannot be converted into developer-months or market value by selecting a target.

Plan-to-production time here starts at an accepted plan. DORA change lead time starts at a code commit and ends at production. Keep them distinct. A short delivery range or fuller allowance use is not automatically a better outcome. Observe quality, human burden, cost and valuable accepted work together.

## Scope of help

The playbook can help a team test task preparation, ready queues, agent roles, shared state, handoffs, evidence-based review and complete cost visibility. It does not promise 10× output, a fixed task price, a savings percentage or a fleet size. Use the profile to prepare a specific workflow discussion, not to sell or buy an outcome guarantee.