Arjun's pipeline migration

The first attempt. Done more carefully than anything he had done in eleven months, and still generic — because the end state named the deliverables and not the people.

Planned for release phase 2. The page is complete as a draft; interactive parts run in the browser and do not yet save to an account.

In brief

This case is laid out against the eight steps of the framework. Jump to Step 1 to see how the end state was defined, or to Step 8 to see what integration caught.

  1. Define the End State

    Sunday morning, a notebook not used since college. First sentence: a deliverable list — migration complete, tests passing, docs updated, reports delivered. Then, prompted by his own questions ("who picks it up? do they nod or wince?"), three paragraphs on texture: reliable on a Monday morning, documentation that reads like Nikhil's, test reports where you can see the work.

  2. Map the Flow

    Monday. Phase A by hand: eighteen tasks, sequenced, dependencies drawn. Phase B: a photograph of the list uploaded to a conversational tool. Three gaps — a pre-migration snapshot for rollback, a compatibility check on downstream consumers, a deprecation note. Phase C: he pushes back on the compatibility audit, is shown two specific examples from his own brief, and adds it in a smaller form. Twenty-one tasks. An hour and forty minutes.

  3. Assign Tasks

    Tuesday, most of the day. Almost nothing lands cleanly first time. "Migrate the legacy integration module" gets four mixed answers and becomes four sub-tasks — identify behaviours to preserve (his), translate each (AI-assisted), run the suite (mechanical), document decisions (his voice). Three documentation tasks turn out to be one.

  4. Select the Tool

    A long-context conversational model for documentation drafts; Cursor for in-editor refactoring; a specialised one-shot tool for the decisions log after he catches himself defaulting to whatever was open.

  5. Prepare and Direct

    A three-line brief for the test report produces something fluent, generic and not what a Vantage test report reads like. He rereads two of last quarter's reports, then does Step 5 properly — readers, house style, legal constraints, expected depth — and asks the tool to refine the briefing. The second draft is in the team's voice.

  6. Execute

    By Wednesday night, sixty percent done. The proportion of thinking to doing has inverted.

  7. Evaluate

    Thursday morning: three small fixes — a renamed function referenced in docs, a test asserting on a deprecated pattern, a metric nobody tracks in the summary. Handled without panic, because he had written "small fixes are normal" in the notebook on Tuesday.

  8. Integrate and Stress-Test

    Everything works. The whole is generic. Four hours of patching produce three generic introductions and two generic summaries. He calls Vivek. "Who's it actually for?" Four audiences, none named. Friday: the end state rewritten with Karan, Sneha and Rohan, the director's office and the client each named with what they want; three framing tasks redone; nothing else touched. The migration has a centre of gravity. He writes the status update by hand.