Albertsons Companies · Merchandising
Changing the way design reaches production.
Developing an AI-capable team: shared skills, disciplined prompting and token use, and clear contribution boundaries across UX, engineering and data science.
AI leadership noteTeach teams where an agent can contribute
Original approach
Worked with Legal, Compliance and Security on AI governance and auditability for Merchandising. Built a weekend chatbot prototype that became the Merchandising chatbot foundation. Pi Tools generated remediation prompts from detected errors, packaging diagnostic context for coding agents to investigate.
What could change today
Extend the shared repository model with a small library of reviewed skills. Product owns acceptance criteria, UX owns interaction rules, engineering owns APIs and data science owns evaluation. Train the team by shipping one change together.
Workflow excerpt. The numbered steps show the same part of the journey in each version. The full project includes work beyond this comparison.
Original workflow
- Shared intent
- Parallel contribution
- Inspect & refine
- Release responsibly
Proposed workflow with AI
- Agree on the feature, acceptance criteria and decision owners.
- Give agents scoped tasks within each discipline’s code boundaries.
- Inspect changes and test quality, cost and rework together.
- Have the accountable owner approve release and monitor the outcome.
How to test the change
Compare a similar change with and without the skill. Track time to accepted pull request, token cost and rework after review.
01 / The problem
What needed to change?
The customer need.
UX and engineering teams need to use AI in shared delivery without duplicating work or losing responsibility for quality.
The previous workflow moved from Figma designs to Figma Make output and then into an engineering rebuild. Generating an interface faster did not remove the repeated translation between tools and roles.
The opportunity was organizational: bring the people shaping the experience closer to its implementation, while retaining engineering boundaries and product-quality review. This is a scoped account of that workflow, not a universal claim about any design tool.
02 / My accountability
Scope of responsibility.
Changed the separate design-to-frontend rebuild path in the merchandising workflow. UX implemented UI and user flows directly in the application; engineers concentrated on APIs, backend services and specialized engineering.
Contributed shared standards, training, architecture guardrails and review practices. Taught teams to scope prompts, load reusable skills, manage context and token consumption, and coordinate contributions in the same repository. The objective was to expand capabilities while keeping specialized responsibilities clear.
The constraint to work through.
Faster frontend delivery must coexist with specialist engineering ownership, accessibility, responsive behavior, security review and release accountability.
03 / Evidence & discovery
What informed the work.
Examined the translation between design output and engineering implementation. Faster generation was still followed by a separate rebuild. That made the handoff and responsibility model the focus of the change.
Brought shared tokens, agent instructions, reusable skills, hooks and diagnostic tools into the workflow. UX and engineering worked against the same application while retaining explicit contribution boundaries and human review.
Shared intent
Agree on the user flow, scope, standards and contribution boundaries.
Parallel contribution
UX implements the interface; engineering builds services and APIs.
Inspect & refine
Use diagnostics, code audits and UX review to examine the result.
Release responsibly
Keep responsive and accessibility checks in the delivery process.
04 / Leadership decisions
Where my judgment mattered.
Change the handoff, then the toolchain.
UX and engineering worked in Codex and Claude Code against the application and shared components. The change removed the separate frontend rebuild step in the enabled workflow.
Leadership implication: role boundaries and review ownership still matter when more contributors can implement.Encode standards where contributions happen.
Converted UDS guidance into Markdown, reusable agent skills, tokens, themes and architecture rules, reinforced by hooks and checks. Guardrails protected architecture when non-engineers contributed and UX when engineers changed the interface.
Leadership implication: written guidance needs verification and human judgment; it cannot guarantee correct output.Develop AI leaders, alongside the delivery process.
Trained UX and engineering contributors in prompting, token and context management, automation, reusable skills and application audits. Shared Markdown design-system guidance gave the team a common reference. Mentored a backend engineer into team leadership and enabled PMs and leaders to contribute within boundaries.
Leadership implication: capability-building supports the workflow; no promotion or retention rate is inferred.Coordinate specialized contributions in one repository.
Put UX and engineering in the same Git repository with explicit ownership boundaries. UX built interface workflows; engineers focused on APIs, backend services and work requiring deeper engineering expertise. Shared rules and checks helped prevent overlapping edits and protect each other’s contributions.
Leadership implication: clear boundaries and coordination reduce conflict risk; they do not establish that conflicts or defects can never occur.Make leadership participation concrete.
A GVP contributed direction on an isolated branch and handed the work to UX for refinement without engineering assistance for that iteration.
Leadership implication: this is one scoped participation example, not proof of enterprise-wide adoption.05 / Application & people
How the work reached delivery.
Worked with Legal, Compliance and Security on AI governance and auditability for Merchandising. Built a weekend chatbot prototype that became the Merchandising chatbot foundation. Pi Tools generated remediation prompts from detected errors, packaging diagnostic context for coding agents to investigate.
The team reported working with concurrent AI prompts and daily code audits. Automated Jira ticket creation and closure, then removed Jira from that enabled workflow. This does not imply all planning or release accountability was removed, or that all Albertsons teams changed their process.
06 / Outcomes & attribution
What changed, and how to read it.
The enabled workflow delivered ahead of planned timelines and freed capacity for business priorities and additional features.
Reduced token consumption tenfold through orchestration, prompt consolidation, persistent memory and deliberate context management. Token reduction is distinct from dollar savings, which depend on model mix, workload and operating costs.
Business value.
The operating model joined AI-enabled implementation with clear contribution boundaries and review. Token efficiency and team enablement were treated as parts of the delivery system, alongside quality and specialist engineering work.
07 / Reflection
Lessons for future projects.
The meaningful change is a team developing the judgment to lead AI-assisted work together: planning bounded tasks, using the right skills, managing context, automating repeatable work and reviewing each other’s contributions. AI generation is only one part of that operating model.
To strengthen the business case, compare equivalent work cohorts, account for model and infrastructure costs, and track lead time, review effort and escaped defects together. Faster output alone is not a sufficient success measure.
Measurement notes
The 100+ team figure describes UDS adoption, not participation in the newer AI workflow. Token consumption measures usage; it does not directly establish dollar savings or a productivity multiplier.
Let’s talk about your next chapter.
Exploring Senior Director, Head of Design and VP opportunities.