Verification before parallelism: checks a reviewer can actually rerun
Adding agents to an engineering change you can't verify doesn't speed it up. Every new branch adds unchecked claims, and someone still has to check all of them. Build the verification map first, then add agents.
Learning goal. For one sensor-bracket revision, write a verification map in which every claim points to a pinned source revision, an executable check or a named engineering judgment, an evidence artifact and a reviewer. Then define the branch and join rules that make parallel agents safe, and measure your current baseline before you change anything.
The pain: one bracket, five tools, three revisions in circulation
A front radar sensor gets a larger housing, so its bracket goes from rev C to rev D. That one change touches a clearance requirement, a mass budget, a frequency target, a shock-stress limit and a vibration test plan. The evidence lives in different places: a CAD clearance export, CAD mass properties, a modal model, a shock deck, a test report from the lab. Each of them was produced at a different moment, by a different person, against whatever revision was current then.
Today a responsible engineer reconciles that by hand. Is this export rev C or rev D? Was the shock deck run in the same unit system as its load case? Was the vibration test done on the new housing? The review packet goes to the change board, someone spots a stale screenshot, and the loop starts again.
Now add agents. Five agents can each produce a confident summary in minutes. If none of those summaries can be rerun against a pinned baseline, you now have five sets of unverified claims to reconcile instead of one. The reviewer is still the only verifier, and that queue just grew.
What the workshop actually shows
The supporting clips come from a Maven workshop on 12 August 2026: Lauren Tan, Member of Technical Staff at Cursor, interviewed and moderated by Colin Matthews, Head of Education at Lenny's Newsletter. She walks through how she builds skills for coding agents at Cursor and the pstack plugin she open-sourced.
Four points matter for this lesson, in her words as far as the clips go. First, a slide plots trust against the number of agents, and she says you can't spawn a hundred agents when you don't even trust the output of one. Second, she calls verification the most important skill in the toolbox: the agent has to run the code, take CPU traces or heap snapshots, or open a simulator, however your application is exposed to users, and test its own work. That doesn't guarantee good code, she says, but it lets the agent at least write correct code. Third, without a verification skill you are the verifier and the bottleneck, copying screenshots and console errors back and forth, so there is no way to parallelize. Her fix includes a feature map that teaches the agent how to reach every feature it has to check. Fourth, she built her skills by watching how agents failed and turning each failure mode into a skill, then testing skills with evals she describes as unit tests for an agent.
This is software work on a desktop app, and it's a practitioner's account, not a controlled study. Everything below that maps it onto CAD, PLM, simulation, test evidence and change boards is our proposed application. The repost that circulated on 2 November 2026 calls her a senior engineer at SpaceXAI and claims fifty agents and three PMs run her company overnight. None of that is in the workshop segments we checked, and we don't use it.
Video: Lauren Tan (Member of Technical Staff, Cursor) with Colin Matthews (Head of Education, Lenny's Newsletter), Maven workshop 'How Cursor Turned AI Agents Into Better Engineers', 12 Aug 2026. Clip as reposted on X by @aiducklabs (AI Duck) on 2 Nov 2026; timestamps refer to that repost. Original audio unchanged; the burned-in word captions were added by the reposter.
Why more agents first makes it worse
Parallel agents multiply whatever their inputs contain. If the clearance export is still rev C, five agents reading it produce five confident wrong answers, and the error now looks like consensus. If the shock load case is in SI while the deck runs in mm-t-s, the stress can come out wrong by orders of magnitude. In our exercise the summary reports 0.16 MPa as a comfortable pass; after the unit fix and re-run the illustrative result is 148.6 MPa, still under 180 MPa but with far less margin. A faster agent doesn't catch that. A check that compares unit systems does.
The workshop makes the same point from software: without verification you are the verifier, so there's no way to parallelize. In a change board that verifier is a reviewer with a two-day queue. Every unverifiable branch you add goes into that queue. The verification map is what lets a branch report 'blocked: stale revision' instead of a number, so the reviewer only looks at real decisions.
The verification map, then the branches
Our proposed application, not something shown in the workshop: before any agent fans out, the team writes a verification map. Each row is one claim the change packet will make. For each claim the map names the source and its revision, how the claim is checked (an executable check, or an engineering judgment that a named person decides), the evidence artifact the check leaves behind, and the reviewer who owns it. Only then do agents get branches, and every branch works under a contract.
Open the verification map at full size ↗
1 · Pin the baseline
- Input
- The change request ECR-0417 (illustrative): BRK-2210 rev C to rev D for a larger sensor housing.
- Action
- The responsible engineer pins part, revision, CAD configuration, simulation deck version, unit system and test plan in one baseline record.
- Output
- baseline.json: BRK-2210 rev D · deck v4 · mm-t-s (N, mm, MPa) · TP-88 v2.
- Check
- Nothing runs until the baseline is signed. Every later artifact must carry the fields that can be compared with it: part, revision, configuration, deck, unit system, test plan.
2 · Write the verification map
- Input
- The affected requirements: clearance, mass, first mode, shock stress, vibration evidence.
- Action
- One row per claim: requirement, source file, check or judgment, evidence artifact, named reviewer.
- Output
- verification_map.json with four executable checks and one engineering judgment.
- Check
- Every claim in the future packet appears in the map. A claim with no row is not allowed into the packet.
3 · Branch under contract
- Input
- The pinned baseline plus only the sources named in one map row.
- Action
- Each branch (one agent, one script, or one engineer) runs its check and writes an evidence file with the revision, unit system and numbers it actually saw.
- Output
- evidence/*.json, one file per claim.
- Check
- The branch compares part, revision, CAD configuration, deck, unit system and test plan with the baseline, field by field. Any mismatch, missing field, missing unit or undecided judgment stops that branch. The other branches carry on.
4 · Join on the pinned baseline, with an independent checker
- Input
- All evidence files.
- Action
- A checker that doesn't share the generator's context reruns every claim from the raw exports. The join accepts only evidence whose every comparison with the pinned baseline matched.
- Output
- report.md: per-claim status, reason, evidence and reviewer. JOIN OK or JOIN HELD.
- Check
- Rework is bounded: two attempts per branch, then it escalates to that row's named reviewer. Nothing loops forever.
5 · Human release gate and the learning loop
- Input
- The report and the decided judgments.
- Action
- The change board chair signs or rejects with the report attached. Every miss (a stale export, a wrong unit) becomes a new check or eval case.
- Output
- A signed decision and an updated map for the next change of this type.
- Check
- No tool can set 'approved'. The gate is a person with authority, as it is today.
The verification map
| Claim | Source and revision | Check or judgment | Evidence | Reviewer |
|---|---|---|---|---|
| Clearance to fascia stays ≥ 2.0 mm REQ-SNS-031 | CAD clearance export must be rev D (delivered export is rev C) | executable: min clearance ≥ 2.0 mm | evidence/clearance.json | Sensor integration lead |
| Mass increase ≤ 15 g REQ-MECH-112 | CAD mass properties rev D | executable: Δmass in g | evidence/mass.json | Mechanical design lead |
| First mode ≥ 120 Hz REQ-VIB-007 | Modal result, deck v4 rev D geometry, mm-t-s | executable: first mode ≥ 120 Hz | evidence/modal.json | CAE analyst |
| Peak shock stress < 180 MPa REQ-STR-020 | Shock load case + result, deck v4 rev D, both in mm-t-s (delivered load case is SI) | executable: unit systems agree, then stress < 180 MPa | evidence/shock.json | CAE analyst |
| Random vibration evidence covers rev D REQ-ENV-044 | Vibration test report TR-5531 tested on rev C hardware | engineering judgment: is the rev C test representative? | evidence/vib-similarity-decision.json | Test & validation owner |
Contracts that make branches safe
branch
Input: the pinned baseline and only the sources named in its map row. Output: an evidence file with status, a field-by-field comparison of every input against the baseline (part, revision, CAD configuration, deck, unit system, test plan), the numbers it compared, and the reviewer. Stops on any mismatch or missing field, a missing unit or an undecided judgment. Never fixes inputs silently, never reads the generator's summary instead of the raw export, never marks a judgment as passed.
join
Joins only branches whose every baseline comparison matched; a label saying 'rev D' is not proof. Holds when any branch is blocked, failed, escalated or waiting for a decision. Produces one report with every branch, its evidence and its reviewer.
checker
Independent of the generator: no shared prompt, context or summary. It reruns each claim from the raw artifacts.
rework
At most two attempts per branch, then escalate to the named reviewer of that row.
judgment
A judgment counts only as one complete record: ACCEPT or REJECT, by the reviewer named in that row, with a rationale, a date, and bound to the exact part, baseline revision, report and tested revision. Change the evidence and the decision goes stale. In the exercise this is editable JSON, so it can't prove who decided; in production, identity and signature come from PLM or e-signature records.
gate
A named person signs or rejects with the report attached. No tool, agent or field in a file can approve; a pre-set approval holds the join.
Where this lands in your industry
Automotive
Pain. A sensor or bracket revision touches requirement IDs, the PLM BOM, CAD, CAE decks and DV/PV test plans, often across OEM and tier-1 tools, and ASPICE or functional-safety work products expect traceable evidence.
Application. Map each impacted requirement to the exact export, deck and test record by revision. Branches stop on a stale export or a unit mismatch; the packet arrives at the change board with a per-claim status.
Approval. Design release owner and the change control board, plus customer sign-off on shared parts.
Evidence. Verification map, evidence files per requirement, the independent check report and decided similarity judgments.
Aerospace
Pain. Configuration control is strict: a drawing change ripples into stress reports, load-case assumptions and the verification matrix, and analysis decks live for years with their own unit conventions.
Application. Use the verification map as a pre-review of the verification matrix: each claim tied to the configuration it was produced on, with unit systems checked before any margin is quoted.
Approval. Authorised engineering reviewers and the configuration control board, plus certification review where applicable.
Evidence. Configuration-stamped evidence per claim, the checker's report and recorded engineering judgments with their owners.
Defense
Pain. Requirements, models and test records sit in separate controlled environments, and every data transfer needs approval, so stale copies are common.
Application. Run branches only inside the permitted environment; the map records which controlled source and revision each claim used, so a stale copy blocks instead of slipping through.
Approval. Programme or design authority and the configuration control board, plus security review.
Evidence. Access-scoped evidence files, the check report and an audit log of every branch run.
Manufacturing
Pain. A fixture or bracket change affects the control plan, gauge instructions, PFMEA and the first-article inspection, and measurement files often arrive in mixed units from different machines.
Application. Map each control-plan characteristic to the measurement file, its revision and unit; the checker refuses mixed or missing units before any Cpk or pass/fail is reported.
Approval. Process owner and quality owner, plus the production lead for the trial run.
Evidence. Per-characteristic evidence, the check report and the first-article decision.
Run the ECR-0417 verification exercise
Interactive browser page or Python 3 (standard library only). No CAD, CAE or PLM licence needed. All artifacts are illustrative.
Download the complete exercise ↓
Open the interactive exercise → · terminal: python3 verify.py in the exercise/ folder · README
- Run the checker as delivered (python3 verify.py, or open exercise.html). Expect JOIN HELD: one stale revision, one unit-system conflict and one open judgment. Read the evidence each branch saw.
- Explain why the summary's 0.16 MPa is a warning sign. Compare the unit systems of the shock load case and the shock result.
- Fix the inputs, not the checker: use the rev D clearance export and the mm-t-s load case with the re-run result from fixes/. Note that clearance now passes at 2.1 mm, close to the 2.0 mm limit.
- Record the vibration decision as the named test and validation owner: ACCEPT or REJECT, rationale, date, and the exact report and revisions it covers. The example rejects the rev C test, so that branch stays blocked until rev D is retested. That's a correct result. A complete ACCEPT would also be legitimate; it has to be argued, not assumed.
- Try to break it: change the mass export to another part number with the same revision, point the decision at another report, blank the reviewer, relabel the judgment as executable or pre-set approved. See what the checker holds, and note what it can't catch: a typed name is not a signature.
- Run three times without fixing anything and watch the rework limit escalate the blocked branches. Then run the 31 regression cases in tests/ to see the checker itself checked.
What the exercise can't do. The checker matches a typed reviewer name against the map. It can't prove who decided or authenticate a signature. In production, identity and signature come from your PLM or e-signature records. It's a training tool, not a security control.
Deliverable. Your own verification map for one real change type, with source revisions, checks or named judgments, evidence artifacts and reviewers, plus the branch, join and gate rules you would enforce.
Measure your baseline before you add a single agent
- Pick 5 to 10 closed change requests of similar size (for example bracket or sensor revisions).
- For each, record from tickets and calendars: hands-on hours, queue time (waiting for data, people and reviews), first-pass acceptance at the change board (yes/no) and errors found after release.
- Write a verification map for that change type and run the next changes through it, same rubric, same reviewers.
- Compare like with like. Count accepted changes, review loops and escaped errors, not agents, prompts or tokens.
We report no productivity numbers here. The point is that you can measure your own, with your own baseline and scope.
Takeaways
- Trust one agent's output before you parallelize. If a reviewer can't rerun its claims, more copies only add work.
- Every claim in a change packet needs a row: source and revision, executable check or named judgment, evidence file, reviewer.
- A stale revision or a unit conflict should stop that branch and show the evidence, not produce a confident number.
- Judgments stay judgments. The map names who decides; no checker turns them green.
- Bound rework, keep the release gate human, and turn every miss into the next check.
Sources
- Maven workshop: How Cursor Turned AI Agents Into Better Engineers (Lauren Tan, Cursor; Colin Matthews, Lenny's Newsletter) · 2026-08-12
- Workshop clip as reposted by AI Duck (@aiducklabs) on X; the repost caption's claims are not supported by the footage · 2026-11-02
- Radar lesson 01: One engineering change, through a harness · 2026-11-03