Levi's rebuilt its development process before it added agents

"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?"

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.

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.

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.

I argued for this shape in Review the plan, not the pull request. The first person in the loop reads the spec, before any code exists. It also answers my earlier note on the agentic software factory. 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.

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 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%.

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.

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, Jenny Patchen at GitHub Universe 2026.
• Review the plan, not the pull request, on putting the human check on the spec.
• The agentic software factory is the 2022 one with one box swapped, the same old factory with a new motor.
• How the Claude Code team reviews code that Claude writes, 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.

Plain text: levi-strauss-rebuilt-the-process-before-the-agents.md · Atom feed · All notes