What one piece of writing became when I stopped treating it as a document — and what the agent never got to decide.
Reading is not a to-do list. The pile of things we mean to read grows faster than we can work through it, and most of the tools that promise to fix the problem only add to it. Shea Andrews put numbers on the problem in a Nature career column — his own figures, from his own practice: 10,000 papers over 13 years, an RSS feed of 35 journals, a chatbot first pass that surfaced 52 candidate papers, of which about half were kept and nine cited. The point is not the numbers. It is that reading is a set of decisions about purpose, relevance and depth — discovery, triage, skimming, deep reading — and decisions can be visualised, taught, and delegated in part.
This first entry in Draft & Build is the story of what happened when I took Andrews's column seriously enough to stop reading it and start building from it. The request I made was three lines long. What came back was a self-contained animated page; what came back after that was a working platform. The interesting part is not the output. It is the division of labour that produced it.
| Artefact | What it is |
|---|---|
| The funnel page corgent.aitutor.ink/bjet/andrew2026.html ↗ |
Built from the column: a self-contained page with an inline-SVG funnel, four bands, animated by a hand-rolled timeline. 24 tokens spawn per cycle and thin out 24 → 10 → 6 → 3, with live counters reading 200 → 40 → 12 → 3. No library, no images, no audio, no external requests — one file, 32 KB. |
| The platform corgent.aitutor.ink/bjet/platform/ ↗ |
The same four decisions, as software: you state a goal, the agent proposes a plan of corpus-tool calls, you edit and approve the plan, a guardrail checks it, and only then does it execute — returning a visible tool-call trace and a summary grounded in what the tools actually returned. |
The brief that produced the visual was three lines: read the file, build an HTML page that visualises the process with some animation, and note that the animation would help us build the workflow itself. That last clause is the most interesting thing in the request — the point was never the picture.
The picture was a way of thinking; the platform is that thinking made operable. The loop, stated plainly:
The design principle is the one the project works by — collaboration, not automation. In both artefacts, the human is choosing depth, and the machine is doing the narrowing.
Every entry in this series carries this ledger. Mine, on this build: that the funnel was the right metaphor; that the counters had to be real counts of tokens rather than decorative numbers; that the page should explain itself; that the platform's checkpoint would come before execution. The agent's: the layout, the easing curves, the control set, the first draft of the "behind the scenes" panel. This is the part a reader cannot get from a published paper, and it is why the series ships both halves — the draft and the build.
The three-line request was too short in a way that only showed up later: the first build produced a page that animated the funnel but never said what the reader should do differently, so the workflow the animation was supposed to help build did not exist yet. The fix was a second pass whose real content was the "behind the scenes" panel. The rule that came out of it: ask for the artefact and the account of it in the same request, because the account is what transfers.
This series is published by IEEE ProComm, where each entry also appears. Artefacts are hosted on the author's own infrastructure and linked from the ProComm page.