# The Theory of Constraints as Applied to AI Integration

By David Jiang · https://dj.theory-a.com/theory-of-constraints · 8 min read

AI tools and processes are a rapidly evolving technology. This creates a difficult situation for companies. The changes are far too disruptive to ignore, but must also be integrated real-time into existing workstreams with minimal disruption to existing and future commitments while also adapting to the effects on morale, culture, and organizational efficiency.

It is common for individuals to *feel* the power and potential of AI but without it manifesting as tangible improvements in hard metrics like revenue growth, time-to-completion stats, as well as soft metrics like career growth and employee satisfaction.

The primary reason for this lies in the [Theory of Constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) developed by Eliyahu Goldratt which can be summarized as:

This essay builds on [Tiago Forte’s original Theory of Constraints series](https://fortelabs.com/blog/theory-of-constraints-101/), which applies these ideas to modern knowledge work.

> Local improvements everywhere do not automatically translate into the global improvement of the organization.

This is because organization output, like an engineering system, is driven primarily by bottlenecks. In a coffee shop, if the cash register is the limiting constraint, no improvements to any other part of the system will make a difference. Not better customer service, not better food or coffee, not faster wifi, not cleaner bathrooms.

![New projects queue at a bottleneck, limiting the work that reaches completed throughput.](https://dj.theory-a.com/theory-of-constraints/figure-1.webp)

**Any improvement that is not at the bottleneck has no effect and often actually makes things worse! **Broad mandates to “Improve productivity using AI!” can actually have a negative effect on organizational efficiency if done so without awareness of organizational constraints.

For example, if the engineering department is the bottleneck (the most scarce resource), then organizational throughput is limited by developer output. Excess capacity in marketing and product departments actually make the bottleneck worse because it takes away productive capacity from the bottleneck via effects like requests for estimation.

This makes the bottleneck even smaller, reduces organizational throughput, and gives the upstream work centers even more spare capacity which creates more requests for estimates which makes the bottleneck even worse and so on. In one [case study](https://fortelabs.com/blog/theory-of-constraints-106-dbr-at-microsoft/) at Microsoft, an innocuous policy to provide time-estimates within 24 hours caused a 40% reduction in bottleneck capacity!

![Upstream marketing and product requests crowd the engineering bottleneck; estimation consumes 40 percent of its capacity.](https://dj.theory-a.com/theory-of-constraints/figure-2.webp)

Even downstream work centers can affect the bottleneck because they may require decision touchpoints with engineering.  This creates *more* overhead, *more* meetings, *more* phone calls, *more* email, *more* blocked decisions and so forth.

![Upstream and downstream teams direct new projects and decision requests toward the engineering bottleneck.](https://dj.theory-a.com/theory-of-constraints/figure-3.webp)

At this point, the mandate to “increase productivity” has drastically reduced total throughput. Everyone is mad at the bottleneck and the bottleneck is mad at everyone else. 

The solution? “Increase productivity even more!”.

![AI speeds up work around an unchanged engineering bottleneck, creating more requests and longer queues.](https://dj.theory-a.com/theory-of-constraints/figure-4.webp)

Breaking out of the cycle requires internalizing the unintuitive realization that a company where everyone is busy optimizing their own productivity is incredibly inefficient if it comes at the expense of the bottleneck. In order to have maximum throughput, all other parts of the system that are not the bottleneck must have *spare capacity.*

Without organization trust or awareness of this dynamic, managerial mandates can be interpreted as “Everyone stay busy!” which makes the problem worse and generates organizational dysfunction and resentment as everyone optimizes for their own performance at the cost of the bottleneck.

## Unique Issues with AI

The Toyota Production System used in car manufacturing and the Agile Scrum systems used in software engineering systems both revolve around the idea of visualizing “Work In Progress” in order to figure out where the bottleneck is. (Car parts or work tickets end up piling in front of it.)

This allowed the bottleneck to be constantly tracked and improved upon.

Integrating AI creates new unique challenges! In some domains AI can perform at superhuman levels where specifying what to build takes about as much time as actually building it. In other domains, it can fail completely. The non-intuitive boundary between these tasks is known as the [“jagged frontier”](https://www.oneusefulthing.org/p/centaurs-and-cyborgs-on-the-jagged). This frontier is constantly changing and can make keeping up with and integrating AI capabilities a full time job.

Imagine a car assembly line where one work unit could suddenly 10x its output and another had a 50% chance to either 5x or halve its output.

Integrating these new capabilities with a positive effect on margin, revenue, culture, and morale requires a bottleneck-aware high trust culture.

### The Bottleneck Can Move

Engineering is one possible constraint, not a permanent one. Even within engineering, understanding requirements, writing code, reviewing changes, integrating systems, and operating the result are different activities. AI can accelerate them unevenly. A team may produce implementations much faster without a comparable improvement in its ability to verify and safely deliver them.

This is already visible in practice. [DORA’s March 2026 analysis](https://dora.dev/insights/balancing-ai-tensions/) of feedback from 1,110 Google engineers describes time saved generating code being spent on verification, alongside difficulties moving prototypes into production. [Anthropic reported](https://claude.com/blog/code-review) that review had become a bottleneck as its code output increased. These observations illustrate a possible shift, rather than establishing that every organization has the same constraint. Review is not a permanent endpoint either: AI can improve testing, review, and integration, allowing the constraint to move again.

**AI can make engineering faster and still make its queue worse. **Suppose effective delivery capacity doubles, but the ease of proposing and prototyping projects triples the incoming workload. Engineering has improved in absolute terms while becoming more overloaded relative to demand. The earlier illustration’s “same capacity” assumption is not necessary for the problem to occur: requests only need to grow faster than capacity.

AI also changes where work enters the system. Someone who once needed engineering to build a prototype may now build it themselves. The request becomes “help me integrate, secure, and maintain this.” The queue reappears later, carrying different work and often a stronger commitment to an existing solution. In other settings, the limiting factor may move outside engineering altogether: deciding what is worth building, reaching customers, or helping people adopt what has already been delivered.

Does the bottleneck change faster? It can, but on different timescales. A new model, better tests, or improved access to internal documentation can quickly change which technical task takes longest. Organizational constraints may persist much longer: unclear priorities, slow approvals, or one person holding essential context. A faster tool does not automatically remove those conditions, and a temporary queue does not necessarily mean the system’s underlying constraint has changed.

The practical response is to make identifying the constraint a recurring practice. Track where valuable work waits, how long it waits, and how much returns for correction. Reassess after meaningful changes in tools or workflow, without reorganizing around every temporary backlog. Improvements elsewhere can help when they reduce errors, interruptions, or unnecessary work reaching the constraint. The measure of success is useful outcomes delivered at acceptable quality—not the volume of code, proposals, or prototypes produced.

## Solutions

A unique issue that arises with AI capability is that all roles are shifted towards a more technical role. When everyone can create their own tools, they are engaged in the process of software engineering whether they know this or not. Instead of rediscovering best practices from first principles it is better to draw on the experience and battle-tested processes of the industry.

As a silicon valley engineer with over a [decade of experience](https://dj.theory-a.com/) working at large and small companies I am uniquely qualified to debug systemic bottlenecks at both the macro organization level (mapping the value stream through interviews & shadowing) as well as providing mentorship and feedback at the level of raw code. The primary focus would be to evaluate and improve broad organizational AI literacy.

Examples of questions I’d focus on discovering the answer to:

### **Value Stream Mapping**

- How does value creation move throughout the organization? 
- Where does it pile up and create bottlenecks? 
- How does communication flow through the various work units? 
- Are there disruptive deadlocked cycles where people feel blocked by decisions from each other?
- How much overhead is created for each work unit by their upstream and downstream units?
- Do work units have projects that can absorb spare capacity to provide organizational value without affecting the work-in-progress of other units?

### **AI Tooling Integration**

- How much work is de-facto software engineering? 
- Are the right software development practices in place?
- What mix of internal and external software and AI tools should be used?
- What are the costs and opportunities of internal vs external?
- How to evaluate and integrate new tools given the speed at which the industry cahnges?
- Should there be production customer facing software systems such as dashboards? 
- Would there be on-call rotations and service level agreements? 
- Would the value add justify engineering roles? 

### **Cultural**

- Are there opportunities to mentor and be mentored within the company?
- What are the effects of AI on employee morale?
- Do the existing roles and responsibilities make sense or have they been disrupted by AI?
- Are there on and off ramps for new roles and are they clear enough so that everyone knows what is expected of each other?
- Is there enough organization trust to create “spare capacity” or does work accrue at the bottleneck as a convenient scapegoat?