--- title: Levi's rebuilt its development process before it added agents description: Levi Strauss & Co. cut the build of a store app from nine months to two and a half. The agents were not the first step. The team first redrew the whole process, split what agents do from what people decide, then built 17 agents on GitHub Copilot to fit it. date: 2026-11-09 tags: AI agents, coding agents, SDLC, GitHub Copilot, MCP, software delivery --- "Don't put the new motor in the old factory." That is how Jenny Patchen closed a talk at GitHub Universe 2026. Patchen is a senior director at Levi Strauss & Co. The team first redrew its whole development process, then built 17 AI agents to fit the new one. The first app built that way took two and a half months instead of nine. Most teams do it the other way. They add a coding agent to the process they already have and wait for the gains. This talk is one of the few that shows what came before the agents. Three days in a room, a map of every step, and a rule for who decides what. The old factory comes from a story Patchen opens with. When electricity first reached factories, economist Paul David found, productivity didn't move. Owners swapped the steam engine for an electric motor and kept everything else. It took decades, and new factory floors built around electricity, before output went up. "It's the same old factory and a new motor," Patchen says. That, in the talk's view, is where most teams stand with agents today. ## Twelve handoffs, mostly waiting The team started with what was wrong, not with tools. The app was Back Pocket, which Levi's stylists use on the shop floor. It helps them serve customers, for example by ordering a size the store doesn't have. Its first version took nine months to build. Product, engineering, quality and the developer productivity team spent three days in one room, laptops mostly closed. Day one mapped the process as it was. Day two drew the future they wanted. Day three listed what they needed to get there. The map had four stages: plan, build, verify and release. It held 12 handoffs between six roles, and a change often took months from start to finish. Two steps took the longest. Writing the user story took two to four weeks, sometimes months, because of all the teams it touched. Testing and regression took three weeks, always at the end, so every problem it found meant going back. Most of that time was spent waiting. So the question changed. It was no longer "how do we make people work faster?" It became "how do we stop the waiting?"

The old process: 12 handoffs, six roles

Two steps held the work up for weeks

  1. PlanWriting the user story: two to four weeks, sometimes months.
  2. BuildThe code, once the story is written.
  3. VerifyTesting and regression: three weeks, always at the end.
  4. ReleaseOut to the stores.

Most of the time went to waiting. The new question: how do we stop the waiting?

Redrawn from the talk's current state map. The talk gives durations for the two long steps only.
## Agents do, people decide The key decision was a grid. Every step of the old map became an outcome. Each outcome got three more columns: what AI does, what a person does, and what a person decides. Take requirements. The step was "write requirements". The outcome is "requirements are clear, cross-functional and aligned". The AI writes testable requirements and lists the dependencies. A person brings the ideas and checks what the agent wrote. A person prioritises and approves. Patchen calls the split between "human does" and "human decides" one of their most important choices. Doing can be shared with agents. Deciding stays with a person, so the person stays accountable. The team's rule for it: agents carry out the work, humans make the decision. The "AI does" column then becomes the agent's job description. Before building one, the team answers five questions. What triggers it? What does it get as input? What does it do? What does it produce? And who takes over? Take the requirements agent again. A feature request arrives. The agent reads the ticket and the spec template. It writes testable requirements, and asks when something is unclear. Out comes a spec the whole team can build from. Then a person merges the pull request that approves the spec.

One outcome in the grid: requirements

Agents can do the work, only a person decides

  1. The outcomeRequirements are clear, cross-functional and aligned.
  2. AI doesWrites testable requirements and captures the dependencies.
  3. Human doesBrings the ideas, and checks what the agent wrote.
  4. Human decidesPrioritises and approves.

The "AI does" layer becomes the requirements agent.

From the talk's example. Patchen calls the grid a revised McKinsey model.
## An agent is a Markdown file Only then did the team build the platform, and it is mostly made of plain text. Developers keep the tools they already use: GitHub, VS Code and the Copilot command line. An orchestration agent routes the work to 17 specialist agents. The talk names three: requirements, testing and observability. The other 14 cover areas like security and accessibility. Each agent is a Markdown file. A short header says what it is, then plain instructions say what it may and may not do. Anyone on the team can read one and suggest a better version. The files sit in an agents folder at the level of the GitHub organisation, so every repository gets them with no setup. A change to an agent goes through a pull request like code, reviewed, versioned and traceable. The same file works on github.com, in the command line and in VS Code. The agents reach outside tools through MCP servers. MCP (Model Context Protocol) is a standard way to plug a tool into an AI model. The requirements agent uses Jira and Confluence. The observability agent uses New Relic. The testing agent drives a browser with Playwright. Figma, GitHub and Context7, a documentation service, are connected too. "When these systems change out, we change the connection," Patchen says. "We don't change the agent." Under it all runs Copilot cloud agent, GitHub's agent that works on a branch in the cloud. Patchen calls the 17 agents "fundamentally specialized prompts" that run on it. Shared skills, packaged instructions any agent can load, carry the company's standards.

Levi's agent platform, top to bottom

Seventeen agents, each one a text file

  1. Where developers workGitHub, VS Code and the Copilot command line, the tools they already had.
  2. Orchestration agentRoutes the work across the team of agents.
  3. 17 specialist agentsEach one a Markdown file in the organisation's agents folder, changed through pull requests.
  4. MCP serversJira, Confluence, New Relic, Playwright, Figma, GitHub, Context7.
  5. The engineCopilot cloud agent, with shared skills for the standards.

When a tool changes, they change the connection, not the agent.

Redrawn from the talk's architecture slide.
## Two stops for a person One agent helps, but the gain comes from chaining them. In Levi's flow, a change passes through a chain of agents and stops for a person only twice. It starts with the requirements agent. It writes the spec in EARS (Easy Approach to Requirements Syntax). EARS is a fixed sentence pattern, such as "when this happens, the system shall do that". Each line then turns into a test almost directly. The agent is told to ask whenever something is unclear. Agents tend to run ahead with full confidence and deliver something that doesn't match the intent, and a question at this point saves rework later. A person approves the spec by merging its pull request. That is the first stop. Copilot cloud agent then builds the change and opens a pull request. Optional specialists may run next; not all 17 run on every change. Then come the quality gates, which always run, in a fixed order: tests, accessibility, performance, code review and security. Security goes last on purpose, so it sees every change the other agents made. The observability agent adds the missing monitoring, so the code shows up in New Relic. An optional deployment agent suggests how to deploy. Then a person reviews and merges. That is the second stop. The video's description says every pull request is reviewed by five to eleven agents. Each one fixes what it finds and commits the fix back to the branch with a labelled commit. The reviewer gets one summary of what every agent changed, then decides.

One change, from request to merge

A person steps in twice, agents do the rest

  1. AgentSpecRequirements in EARS. It asks when something is unclear.
  2. PersonApprove specMerges the spec's pull request.
  3. AgentBuildCopilot cloud agent writes the change and opens a pull request.
  4. AgentsGatesTests, accessibility, performance, code review, security last.
  5. AgentObserveAdds the missing monitoring for New Relic.
  6. PersonMergeReads one summary of every fix, then merges.

Optional specialists and a deployment agent can join; not all 17 run every time.

Redrawn from the talk's workflow slide, with the optional steps left out.
I argued for this shape in [Review the plan, not the pull request](/notes/review-the-plan-not-the-pull-request.html). The first person in the loop reads the spec, before any code exists. It also answers my earlier note on [the agentic software factory](/notes/software-factory-2022-to-lights-off.html). There, coding agents swapped the builder box and kept every other box of the 2022 pipeline, so review became the slow part. Levi's redrew the boxes first. ## Standards as gates, not reminders The third goal was standards "built in, not bolted on". Levi's had written down what good looks like for security, accessibility, performance and monitoring. But a standard only works if every engineer remembers to apply it. So each one became an agent that checks it on every pull request and fixes what it finds. The security agent checks for the OWASP list of common web risks and known vulnerabilities, scans for secrets, and fixes by severity. The accessibility agent checks the WCAG 2.2 AA level in a real browser through Playwright. The performance agent measures Core Web Vitals, Google's page speed metrics, in the browser too. Patchen's rule for it: always measured, never estimated, before anything is fixed. The observability agent adds whatever monitoring is missing. The same idea runs through the repositories. Levi's has ten starter templates for new repositories, nine of them for languages from TypeScript to Swift. Each comes with the build pipeline, documentation, runbooks and an AGENTS.md file. So agents know the repository the moment they arrive. Every pull request also passes CI checks: dependency review, tests, coverage and a New Relic preflight. "You can only go as fast as you have good brakes," Patchen says. For older repositories, an agent compares them with the templates and opens pull requests for the gaps. Everything is shared in an internal marketplace with four shelves: agents, skills, prompts and MCP servers. It holds 24 agents, 19 skills and 15 MCP servers. The engineers who use them rate them with stars and comments, and each one installs in one click.

What the gate agents check

Every standard is checked on every pull request

StandardChecked, then fixed

SecurityOWASP risks and known vulnerabilitiesPlus a secret scan, fixed by severity

AccessibilityWCAG 2.2 AAIn a real browser, with Playwright

PerformanceCore Web VitalsMeasured in the browser, never estimated

ObservabilityMissing monitoringAdded so the code shows in New Relic

CI also runs dependency review, tests, coverage and a New Relic preflight.

From the talk's standards slides.
## The tools were the easy part "The tooling was really the easy part," Patchen says. The heavy work was helping people through a change in what their job is. The team had real worries about it. Four things helped. Before the workshop, everyone got a pre-read on what other companies were doing, with Gartner and McKinsey research. The goal was to aim for a new process, not small fixes. A principal engineer who knows AI joined the team as a player-coach: at every stand-up, on their chat, ready to help with whatever was stuck. Training used the team's own code, not exercises in a sandbox. And open office hours gave anyone a safe place to ask questions. The hardest part was for the strongest people. Patchen cites a Korn Ferry paper: high performers often struggle most with AI. The skills that made their career are the ones they now have to let go. The new habits were writing specs first and reading agent output critically. Even the stand-up changed. It is no longer about status, but about decisions and exceptions. The team also wrote four rules, "short enough to remember and sharp enough to settle arguments".

The rules Levi's team runs on

Four rules, short enough to settle arguments

RuleWhat it means

JudgmentHumans judge, agents executePeople take the unclear work that needs taste

ContextIt lives where agents can see itThe repository and the ticket last. Chat does not

One barThe same bar for agents and humansEverything passes the same gates

AuditAuditable, alwaysEvery agent action and human override is logged

The four rules as the talk states them; the one-word labels are mine.
The context rule is the one I'd copy first. A decision made in a chat thread is lost to the next agent. A decision written in the ticket or the repository is there for every agent and every person after it. Patchen expects chat to become usable context soon, but says they are not there yet, and they told the team so. ## Faster, and better too The headline number is the launch. The new Back Pocket took two and a half months against nine for the old one, 72% less time. It is now launching in Southeast Asia. The team expected throughput to drop while people learned the new way. It went up 51% instead. A pass rate rose 54%, which Patchen reads as quality going up at the same time. Speed and quality usually trade against each other, so both rising together is rare. The talk doesn't say what either figure counts: changes, stories or test runs. Patchen is careful with throughput. More output from agents doesn't always mean better outcomes. The talk's answer is the launch date: the product reached stores much sooner. Meanwhile the share of pull requests made with AI went from 26% to 69% in the same short window. The goal is 100%.

Back Pocket, old way against new

Nine months became two and a half

72%less time to build: 2.5 months against 9

+51%throughput, when the team expected a drop

+54%pass rate, read as quality going up

69%of pull requests made with AI, up from 26%

The talk doesn't say what throughput and pass rate count.

The numbers from the talk's results slide. The 72% matches 2.5 months against 9.
## What they changed on the way The flow I described isn't the one they started with. At first, each review agent worked on the pull request in parallel. That caused merge conflicts, so they ran the agents one after the other. Very recently they changed it again. Now each agent leaves comments, and one helper agent at the end reads them all and makes the fixes. It keeps most of the speed without the conflicts. The workshop changed too. Three days in the room, plus about as many hours of preparation, worked well but cost a lot. Patchen has since run it with new teams in as little as three hours, still with good results.

How the review agents share one pull request

From parallel fixes to comments and one fixer

  1. At firstAll in parallelEvery agent fixed the same pull request at once. Merge conflicts.
  2. ThenOne after anotherNo conflicts. Each agent commits its own fix.
  3. NowComments, one fixerEach agent comments. A helper agent reads them all and fixes.
From the talk's lessons. The auto-generated captions say "parallel" for the second stage too; one after another is what removing the conflicts means.
## Try it The talk runs 30 minutes. The grid of who does and who decides starts at about 6:50, the architecture at 9:46, and the lessons at 27:30. - GitHub, [17 agents, one SDLC: How Levi Strauss reimagined development on GitHub](https://www.youtube.com/watch?v=-GpxKKgoWWg), Jenny Patchen at GitHub Universe 2026. - [Review the plan, not the pull request](/notes/review-the-plan-not-the-pull-request.html), on putting the human check on the spec. - [The agentic software factory is the 2022 one with one box swapped](/notes/software-factory-2022-to-lights-off.html), the same old factory with a new motor. - [How the Claude Code team reviews code that Claude writes](/notes/claude-code-team-code-review.html), another team with many review agents on one change. Then try the grid on one step of your own process. Write its outcome, what an agent could do, what a person still does, and what a person must decide. If the last column comes out empty, tell me which step it was.