AI-Assisted Engineering Workflows

Overview

I acted as Content Catalyst's de facto AI advocate, designing and building AI-automated Claude Code pipelines, not one-off prompts, that became standard practice across engineering and product, from day one of using these tools rather than bolted on later.

I designed and built three AI-automated pipelines, each one turning a piece of engineering or product work that used to be manual into an automated Claude Code workflow: automated frontend implementation, automated UX ideation, and an automated system-explainer. The frontend implementation automation codifies our design-system rules into a component registry that Claude Code reads from, used by every frontend developer on the team and cutting implementation time by 4x. The UX ideation automation, backed by a structured evaluation suite of test fixtures and eval cases, sped up early-stage design exploration by 5x, letting us explore directions without a Figma file for every iteration.

The foundation: a design system AI pipelines implement against

I migrated our design system out of Figma and into markdown living in the codebase itself. Folder-level routing docs cover what to read for a given area (adding a page, working in an API client, loading a dictionary), and components with real behavioural nuance get their own spec: when to use it versus its alternatives, its props and lifecycle, and its API usage. Claude Code reads the relevant docs before touching a component instead of inferring conventions from whatever code happens to be nearby, and the same specs work as onboarding material for a new engineer.

Automated pipeline: registry-first frontend implementation

This is an AI-automated implementation pipeline, not a checklist a developer follows manually: Claude Code runs every step itself. Before writing a single line of component code, it confirms which app and route the feature belongs to, then reads the team's actual house rules straight from the repo (the component registry and the design-system/principles doc) instead of pattern-matching whatever code happens to be nearby. For every piece of data the feature needs, it runs a lookup and reports back one of three outcomes: already wired to a real API, designed but not yet wired, or not built yet at all, presented as a table the developer confirms before any code gets written. Every UI element then gets matched against the component registry, reading a component's own spec file when one exists rather than guessing at its props, and even mocked or stubbed pages get built with the real production component and a placeholder handler, not throwaway markup, so swapping in the real backend later is a one-line change, not a rebuild. It finishes with a mandatory responsive/design-system checklist and reports any component that isn't yet in the registry, which is how the registry itself stays current. This is where the 4x implementation number comes from: every developer, human or agent, starts from the same source of truth instead of re-deriving conventions each time.

Automated pipeline: UX ideation, without opening Figma first

This is an end-to-end AI automation, not a template a designer fills in: Claude Code reads the actual problem context, user feedback, stakeholder notes, and screenshots from a working folder, and writes back a short confirmation of understanding before generating anything, so the direction is agreed before any ideas exist. It then automatically produces prompts for three separate AI prototyping tools in parallel, each organised into two clearly separated tracks: ideas grounded in established UX patterns from real reference products, and ideas that respond directly to specific, real feedback pulled from the actual notes, not generic best practice. Rather than stopping at prompts or a slide deck, the automation always finishes by building an interactive, clickable prototype viewer in the same conversation, itself AI-generated: each idea rendered as real UI the team can click through, paired with a short reasoning panel that traces it back to its source, a named stakeholder's quote, or the pattern and reference product it borrows from. That's what lets a team compare several real, clickable directions before a single Figma file gets opened, and where the 5x faster early-stage exploration number comes from.

Automated pipeline: explaining a system, calibrated to who's asking

The cross-discipline knowledge tool is a third automated Claude Code pipeline, run whenever someone needs to understand a system rather than build it. It opens every request with one fast calibration question, who's asking and how deep, so the same question about how a system works gets pitched differently for a backend engineer than for a product manager, not just shortened or lengthened. It then researches the real system before explaining anything, in a fixed order: internal architecture docs first, then the actual code, since docs can lag behind what's really shipped, then version-control history when the question is about how or when something changed, stopping as soon as there's enough to answer accurately and saying so explicitly whenever the docs and the code disagree. The output is sized to the question: a small question gets a one-line mental model plus a simple diagram inline in the conversation, while a big, multi-part or onboarding-scale question gets offered as a self-contained, offline HTML page instead, with its own diagrams and pointers back into the real repos, and every explanation is framed as a snapshot rather than permanent truth, since the underlying system keeps moving.