Bringing UX into how Red Hat builds software with AI
Red Hat's engineering teams were each building their own process for writing software with AI, and none included UX. I started a small working group that built UX skills, ready-made instructions that teach AI tools a UX task, and brought them to team after team. When Red Hat settled on one shared process, UX was already in it.
Read the diagram as text
- Skills grouped by job: Design (design reviews and handoff, design system checks, design system guidance), Research (usability reviews and testing), Prototyping (prototypes from tickets or designs), Accessibility (accessibility checks), Code (building with the design system, code review, upgrades, design system docs for AI tools), and new skills still in testing.
- They all feed ai-helpers, an open source toolkit on GitHub.
- ai-helpers runs in Claude Code and Cursor. OpenAI support is coming soon.
- In September 2026 it carried into Red Hat's one shared AI development process.
65skills
8weeks to go live
12contributors
The problem
In 2026, Red Hat made AI assistants that write and check code a primary way it builds software. Each engineering team set up its own process for working with them, in its own format, and none included UX. Once a process settles, anyone left out has to fit into decisions other people already made.
The call I made
Going deep with one team would have been safer. But the teams all needed the same UX quality checks, and only their formats differed. So the working group built the skills once and adapted them for each team.
Read the diagram as text
- UX skills are built once.
- They're adapted for each engineering team's own AI process: team A, team B, and team C.
- In September 2026, Red Hat settles on one shared AI development process for all of them.
What the team did
The working group was four people, part time. They had a working board in four weeks and were live in teams' processes by week eight. Then they went to product teams one by one and got the skills into each team's process, along with review rules that keep them safe. They built a public toolkit on GitHub and an internal one, a place where teams can browse and install skills, and support for two popular AI coding tools, Claude Code and Cursor. Five people outside the group started contributing without being asked.
Read the diagram as text
- March 2026: the team starts, four people, part time.
- Week 4: a working board.
- Week 8: live in teams' processes.
- September 2026: Red Hat settles on one shared process, and the team moves over in days.
Earning a seat
My team and I represented Red Hat's UX organization in the engineering group defining how Red Hat builds software with AI, alongside engineering leads and Red Hat's most senior engineers. I made UX's case by building what the group needed: I scored 15 pilot teams on how ready they were, across seven areas, and wrote summaries for leadership.
Result
In September, Red Hat settled on one shared AI development process, built on Red Hat AI (the company's AI products) and Fullsend, an open source project where AI assistants handle steps like writing and reviewing code. Its first stages covered the work our working group had built since March, so the group moved over in days without starting over.
I'd prepared for that. At my request, one of the toolkit's leads came from the Red Hat AI team, so their lessons shaped our skills. Red Hat AI's research lead now serves on the toolkit team.
I'm product owner of ai-helpers, the public toolkit. In its first three months, contributors added skills for research, prototyping, design review, accessibility, coding, code review, and upgrades. Each contribution gets automated security checks and a review by a person. New skills stay in a testing area until they pass quality checks.
Throughout the chaos Mike has been a steady leader who has, at every turn, helped me identify the right opportunities to connect my team into… I deeply appreciate his partnership and ability to cut through the noise to amplify the signal in these choppy times!