Seven diagrams in parallel, and the two defects only a person caught

Every technical diagram on this site was drawn wide, for a desktop screen. On a phone each one sat in a sideways-scrolling frame, and the part that made the point (the rules engine, the human gate, the red findings) was always off-screen. Seven diagrams needed a second, vertical drawing each. This is how that work was done, what it cost, and where the humans had to step in.

Splitting the work

The job divided cleanly: one diagram per component file, no two components sharing code. That made it a good fit for our engineering system, which runs bounded tasks in parallel, each in its own isolated copy of the repository, each allowed to write only the files it was given.

Each of the seven lanes got the same brief shape:

• The pattern to follow. Two diagrams on the site already had phone versions; read those first and match them.
• Hard rules. A fixed width of 340 units, every label inside the frame, the same labels and meaning as the wide version, unique ids for accessibility, and the scroll frame removed.
• A test to write. Structural checks on the component: both versions present, the right width, unique ids, every label within bounds, and the same labels in both drawings.

Before anything ran, a planning check looked for overlapping write scopes, missing acceptance criteria and budgets that couldn't cover a lane's worst case. Nothing was spent until the plan passed.

What came back

Seven lanes ran, five at a time. Each engineer's change went to an independent reviewer. Six were approved; one came back as "approve with fixes". Together they added 55 tests. The whole run cost 19.5 cents.

Five of the seven diagrams were right the first time on a real phone screen. Two were not, and this is the interesting part.

What no reviewer could see

In one diagram, a rotated label for a rework loop sat on top of a hatched box. In another, a vertical flow line ran straight through the label "Human merge". Both passed every test. Both were approved by an independent reviewer. Neither is visible in the code: they only exist once the SVG is rendered at 390 pixels wide.

They were caught the way we catch visual defects on every project: an engineer took screenshots of every diagram at phone width and looked at them. The fixes took minutes: the loop moved to the empty right side of the column, the label moved beside its marker.

What this says about AI in engineering

• Parallel, bounded work is where it shines. Seven careful drawings with tests, in the time and at the cost of one.
• Tests and review catch what text can show. Missing ids, labels outside the frame, a phone drawing that drifted from the desktop one: all caught, and later the same tests caught a human's mistake too.
• Someone still has to look. Visual correctness needs eyes on the rendered result. On this site that is a person with a screenshot, every time a diagram changes.

That split, machines doing the bounded work in parallel and engineers owning what ships, is how we work on client systems too.