cglearn — Practice a better workflow

01 / PREDICT

An agent produces a draft twice as fast but needs more review corrections. Which clock would tell you whether the workflow improved?

Your prediction

Write a brief prediction before opening the explanation.

02 / EXPLAIN

Read the lesson

Define success before starting the clock

Write down the task's acceptance criteria and the quality threshold both workflows must meet. Measure elapsed time from the same starting boundary to the same accepted-result boundary, including review, correction and verification. Keep active human effort separate from elapsed waiting time; they answer different questions and may overlap. Do not add overlapping intervals twice. Report unfinished attempts and installation delays explicitly instead of quietly dropping them or treating them as learner failure.

Compare similar work and disclose differences

A week of small documentation edits is not a fair baseline for a week of difficult migrations. Group tasks by comparable scope and risk, record the workflow and environment used, and keep the acceptance rule consistent. Familiarity and practice order can also change results. Repeating the exact solved task can make the second attempt look better through memory. Use comparable unfamiliar tasks and vary order where practical. A small pilot can guide another trial without proving a universal productivity gain.

Keep quality and uncertainty visible

Record accepted outcomes, review corrections, failed checks and defects found within a stated follow-up window. No observed defects in a short window is not proof that none exist. Generated lines, prompt length and agent count describe activity, not delivered value. Keep optional personal measurement private and focused on improving a method. Export a plan without code, credentials or colleague identifiers; this exercise does not collect usage telemetry or rank employees.

Common mistake

Stopping the clock at the first generated draft, excluding unsuccessful tasks, or treating more generated code as improvement.

03 / DEMONSTRATE

Make the request actionable

A weak starting brief: Count generated lines and use draft time to prove that my new prompting workflow is faster.

Help me design a voluntary comparison of two coding workflows on similar unfamiliar tasks. Define the same acceptance and verification criteria, timing boundaries, task groups and follow-up window before the trial. Separate elapsed time from human effort and include failed or incomplete attempts. Report rework, observed defects and confounders alongside time. Use only task summaries I choose to share. Produce a modest conclusion and a next experiment, not an employee ranking or a universal speed claim.

This example is an adaptable request, not evidence that a runtime action has executed.

04 / PRACTICE

The fast draft with expensive corrections

Simulated sequential timing for one comparable task per workflow; all intervals are non-overlapping:
A: draft 20 min; review, correction and verification 30 min.
B: draft 35 min; review, correction and verification 5 min.
Both meet the same acceptance checks. No defect follow-up has happened.
Claim: A improves time to an accepted result because its draft arrives sooner.

Simulated scenario · No repository access or command execution

Which conclusion matches this evidence?A is faster overall because 20 is less than 35.B is proven better for every coding task and has no defects.A took 50 minutes and B took 40 to acceptance in these observations; A's earlier draft did not translate into earlier acceptance. More comparable tasks and follow-up are needed.Ignore review time because only generated output measures agent productivity.