When I was at Tesla, change was constant, but visibility into those changes was terribly manual. I was in a readiness meeting when a colleague, with some exasperation, asked - “Can’t you just run a diff?!”
I understood what he was asking: compare the old requirements to the new ones, see what changed, and confirm the factory was ready. But the word “just” was doing a lot of work in that statement. He thought it should be instantaneous. In reality it meant hours in a conference room going line by line through changes with a team… and that was what we were already doing. He’d built a lot of incredible software. We were in a factory.
In software, a diff is the simplest thing in the world
Every code change generates one automatically. It shows exactly what changed, and only the lines that are different, not the million that aren’t. It’s what gets reviewed before anything ships, how teams stay aligned through iteration, and how you roll back if something breaks. It’s the foundation of version control, and a core reason software developers can build and iterate so fast, stacking small (or large) improvements on top of each other with confidence they’ll work.
An example of a diff of a software change
That said, if you’ve been through Lean training or read Learning to See, this pattern isn’t new to you. You’re just used to seeing it with butcher paper and sticky notes.
A Current vs. Future State map is fundamentally a diff. It’s just manual and disconnected from the digital workstream, and difficult to see the detailed differences (hence the kaizen bursts). And it’s definitely not instantaneous.
The Current and Future State VSMs from "Learning to See", styled as a diff
In manufacturing, we’ve been doing this manually
My answer to that question at Tesla was “yeah… we have to do that in a conference room, which is why it takes so long.” There was no shared digital context to give systematic meaning to each change, just a series of handoffs between clunky systems. So - just like mapping the current vs future state - it wasn’t instantaneous. We had to get all the engineers together, pull up the bill of materials (BOM), tooling list, or processes on a spreadsheet, and go line by line to confirm what changed, fix errors, and make sure the factory was ready to execute a change.
It’s super tedious (and expensive! 10-20 people in a room going line-by-line through a spreadsheet takes a lot of resources) but in a dynamic production environment it does ‘work’. And it’s really been the only reliable way to confirm readiness.
A Diff is a fundamental enabler of agentic productivity
A diff isn’t just a tool for humans either. It’s a core enabler for AI to take take action on your behalf. That is, if I ask an AI “will this reduce defects?” or “will this improve throughput?”, the model has to know what “this” actually is, how it interacts with the rest of the system, and how it’s different from the prior state. Without a diff, the analysis is reduced to somewhat-educated guessing. It may ask clarifying questions, or even give you a plausible-sounding answer (not unlike a human who hasn’t gone through a detailed change-readiness review/manual diffing exercise). But it won’t be able to reason about the specifics of the change itself, because it doesn’t really know what changed.
In fact, this matters much more for AI in a factory than it does for humans. A team can painfully muscle through a line-by-line review in a conference room with other team members providing verbal context along the way, but an AI operating at machine-speed doesn’t have a robust equivalent. It either has structured context about what it’s working on (in this case, a change), which sharpens its context window and helps you go faster, or it’s working generally and is highly likely to give answers that sound good, but are operationally meaningless. And that’s just for analysis. Taking the right action is even harder and more critical to do right - for instance, if you were to ask an AI to rebalance a production line from 10 units/day to 100 units/day over a 6 month period in line with a build plan, it needs to be able to both see the current state, and then give you sequence of “diffs” that will get you from here to there. So if you expect an AI to handle any ongoing tasks in your factory, you’d better have a diff.
Version Control in Threaded - it’s all about the diff
Version control in Threaded is built on the diff. Your work instructions are your “code” for manufacturing, and they are built on a backbone of a value stream that connects the data of the system so every change has shared context.
This means that when you create a change request you get a diff: exactly what’s changing, and nothing that isn’t. Changes get reviewed faster, in context, with real collaboration, not on a random spreadsheet. It’s also the basis for automated readiness testing to minimize time spent in the conference room, so the team can focus more on solving problems and less on line-by-line spreadsheet reviews. Here’s what this looks like in practice:
A diff of the Current and Future material flows from "Learning to See" - clearly highlighting buffer elimination, consolidation of nodes, and implementation of Kanban to make it absolutely clear what has changed in a single picture
A Work Instruction diff, with green/red/yellow callouts for added/deleted/changed, again - making it explicitly clear what is changing for an easier, asynchronous review.
The objective of the diff is to drive objective clarity for any given change. This then becomes the subject of collaboration, where a team can review, discuss, request changes, or approve a change, without having to sit through more line-by-line reviews in a conference room.
We’d love to show you how scaling something as fundamental as a diff can help you get out of the conference room, unlock AI that actually understands your factory, and drive continuous improvement faster than you thought possible.
Schedule a call and I’ll walk you through it.
