A hypothesis is just an unexamined limiter
Fred Dupriest's career at ExxonMobil turned on a discipline most engineers never develop: after you remove one limiter, you don't celebrate, you go looking for the next one. Mechanical Specific Energy didn't give him a single answer. It gave him a sequence. Remove the limiter governing rate of penetration, and a new one, invisible until the first was gone, becomes the thing that governs your ceiling. The gains compounded across 270 rigs and 1,700 wells not because the first fix was magic, but because each removal exposed the next constraint with more clarity than the last.
I wrote the first essay with a clean hypothesis: the delimiter for software product teams is the sequential trap. Design, then build, then test, then secure, then document, then go to market, each phase waiting on the one before it. Remove that, run the phases in parallel, and the ceiling lifts by an order of magnitude.
Then we drilled a well. And the well taught us something the hypothesis didn't contain.
The first well
Our first deployment was a construction workforce platform, a real codebase, real compliance requirements, and a real internal engineering team. Scott and I went in with the methodology and a simple promise: we'd compress the delivery cycle by running the phases in parallel instead of in sequence.
On the technical axis, the hypothesis held. Two of us, working with the orchestration layer, delivered in eight weeks what the internal roadmap had budgeted ten people and six months to ship. Modules in production. Compliance patterns baked into the code from the first commit. The CEO's own words: "We're operating at the equivalent of a 50-person team, with two people."
The sequential trap was real, and removing it produced exactly the category shift the framework predicted.
But Dupriest's discipline kicked in almost immediately. Because the moment we removed the technical limiter, a different one surfaced, and it wasn't in the architecture. It was in the people.
The limiter we didn't expect
Here is the thing nobody tells you about removing the sequential trap: when creation stops being the bottleneck, the organization around the creation becomes the bottleneck. And organizations are not codebases. They don't refactor on command.
Lowman Harley's original essay named this exactly. Every organization has a maximum rate at which it can absorb change. We had spent all our diagnostic energy on the delivery speed limit and almost none on the organizational one. We were about to learn that the second is harder, slower, and far more human than the first.
What we found at the first well wasn't a tooling problem. It was five distinct human limiters, each one a person doing something completely rational from inside their own incentives.
The review ceiling. The code review process had been designed for a world where pull requests arrived slowly, one or two a day, maybe a handful in a sprint. That cadence shaped everything: how many reviewers were needed, how deep the review habit went, how much context a reviewer was expected to hold. When generation accelerated, the review architecture didn't. Work piled up not because anything was wrong with the work, but because the approval process had been built around the assumption that creation was always the bottleneck. Once it wasn't, the gate became the constraint.
The design workflow built for craft. The design process had been structured around the idea that producing polished work took time, that the hours spent were part of what justified the output. Mockup cycles, revision rounds, sign-off rituals: all of it assumed that slowing down was how you got quality. When the generation step collapsed to near-zero, none of that surrounding process changed. The calendar still assumed the same lead times. The review loops still ran the same number of rounds. The workflow had been built for a constraint that no longer existed, and it kept behaving as if it did.
The compliance and handoff ceremony. Compliance documentation, security sign-offs, runbooks, API docs: these don't come after the code, they gate the deployment. In a traditional delivery cycle, they get written sequentially, reviewed by people who weren't part of the build, and cleared through an approval chain designed for a world where code arrived slowly. When generation accelerated, that approval chain didn't. The compliance queue became the deployment gate. This is exactly the dynamic the Govern layer of the methodology exists to solve: keeping compliance evidence, security documentation, and handoff artifacts on the same clock as the build, instead of treating them as a ceremony you perform after the real work is done. When they're bolted on at the end, they don't just slow delivery. They introduce the exact kind of sequential bottleneck that compresses every gain the parallel build produced.
The fluency gap. The assumption built into most AI rollouts is that handing someone access to a tool is the same as enabling them with it. It isn't. The gap between having AI and extracting consistent value from it is real, uneven across teams, and doesn't close on its own. Workflows that assumed uniform fluency quickly concentrated all the hard work on the people who already knew how to prompt, which meant the leverage wasn't distributed, it was centralized. The bus factor didn't shrink. It just moved.
The interpretation habit. The team had built their process around human-mediated information flows: someone attends the call, interprets what was said, and produces a summary. That interpretation step was load-bearing, it was where context was filtered, priorities were read, and institutional knowledge was applied. When the workflow moved to transcript-first, it wasn't the data that felt wrong. It was the absence of that interpretation step. Decades of process had embedded the assumption that a human reading the raw source and deciding what mattered was how trust got established. Skipping it felt like skipping quality control, even when the output was demonstrably better.
Five constraints, one pattern
Step back and the five constraints collapse into a single diagnosis. None of them were failures of intent. Every one was a process built for a slower world, a review architecture sized for scarce output, a design workflow optimized for craft-as-constraint, a compliance and handoff process sized for sequential delivery, a rollout that assumed fluency was uniform, and an information flow that had made human interpretation load-bearing. The people operating inside those processes were doing exactly what the process asked of them.
That's the organizational speed limit, observed in the wild. It isn't a motivation problem you fix with a pep talk. It's a structural problem: the speed of the tooling outran the rate at which the organization could re-author its own roles, incentives, and identities. We had removed the delivery limiter and run straight into the human one underneath it, exactly the way Dupriest ran into a new constraint every time he cleared the last.
To be clear: the engagement worked. The modules shipped, the compliance held, the 50-person-equivalent output was real. None of this is a story about a team that failed. It's a story about what becomes visible after you succeed on the technical axis, and these constraints would have surfaced in any company on earth, because none of them are unique to this engagement. They're structural, not personal. Every organization that adopts AI seriously will hit its own version of the review ceiling, the craft-optimized workflow, the approval ceremony, the fluency gap, and the interpretation habit. The only question is whether leadership diagnoses them as process problems or absorbs them as mysterious "AI didn't stick" disappointment.
And here's the part that should reframe how every leader thinks about an AI bet.
The technical limiter is the easy one. You cannot remove the human limiter with architecture alone.
A 100x improvement in generation that lands on a team whose review capacity, incentives, and identities are sized for the old speed doesn't produce 100x output. It produces a pile of unreviewed pull requests, a defensive specialist, a documentation queue, and a quiet decision to route the hard work back to the few people fluent enough to do it.
Gartner predicts over 40% of agentic AI projects will be canceled by 2027. After this engagement, I don't read that as a prediction about models. I read it as a prediction about organizations, specifically, about leaders who buy the generation capability and never design for the human limiter that governs whether any of it compounds.
What Dupriest actually solved
It's easy to remember Dupriest for the metric. His real achievement was harder, and it's the part nobody quotes.
Mechanical Specific Energy was elegant, but a number on a chart changes nothing by itself. Dupriest's actual problem was 270 rigs full of veteran drillers who had spent entire careers applying weight to the bit slowly, because that's how they were trained, what the manual said, what felt safe. He was telling them that the habit they trusted most was the thing destroying the equipment. He was, in effect, telling a thousand experts that their expertise was the limiter. That is precisely the wall we hit on this engagement, and it's where most engineers, and most consultants, lose. They arrive with the better answer, mandate it from above, and watch the organization quietly route around them. Being right is not the same as being adopted.
Dupriest knew that. So he didn't mandate, he instrumented. He put MSE on the screen in front of the driller, in real time, while the bit was still turning. And that single move did what a directive never could: it made the limiter visible to the person who actually had to change. The waste stopped being an engineer's opinion and became a reading off the rock. The driller wasn't being corrected by a superior; he was watching the formation tell him, second by second, where the energy was going. The number depersonalized the threat. Nobody had to confess they'd been wrong for thirty years, they just had to respond to what the dial now showed.
And here is the part that mattered most: the diagnostic didn't replace the driller. It promoted him. The veteran once valued for a steady hand on the brake was now valued for reading MSE, hunting the limiter, and out-diagnosing the rig next door. Dupriest didn't strip the experts of their identity, he handed them a better one, and made it higher-status than the habit he was asking them to drop. Resistance became ownership, because the people most threatened by the change were made the operators of it.
That's the move, and it's the whole template: not a better answer imposed from outside, but a measurement placed in the hands of the person who has to change, one that makes the limiter undeniable and makes the human more essential, not less. Dupriest didn't win the human limiter by overpowering it. He won it by re-routing the expert's pride from the old habit onto the new diagnostic.
What this changes about the solution, and what we built
Translate Dupriest's move out of the oil field and it stops being a story and becomes a design spec. In the first essay I argued the answer had to break the sequential trap, run phases in parallel, orchestrate existing tools, and compound. All still true. But the field, and the rig floor, taught us a fifth requirement the hypothesis missed:
It has to manage the organization's rate of absorption, not just the team's rate of production.
This is the principle we built Modulaa around. Modulaa isn't a code generator and it isn't another assistant bolted into an IDE, it's an orchestration layer that runs the full delivery lifecycle in parallel while keeping a human at every gate. We started building it to remove the technical limiter. The first well taught us it has to remove the human one too, and that changed the design. Concretely, that means a few things we under-weighted before we drilled, and now treat as core to the methodology:
- Instrument the gatekeeper; don't flood him, and don't mandate. This is Dupriest's MSE move, ported into software. Human-in-the-loop approval gates aren't bureaucracy; they're the screen in front of the driller. The reviewer has to feel like the orchestrator reading the diagnostic, not the bottleneck drowning under it or the casualty being automated past. The system has to make the senior human more essential at a higher altitude, not redundant at the old one. If the lead dev experiences AI as a flood, you've lost. If he experiences it as leverage, as a better dial on a harder problem, you've won the only battle that matters.
- Redesign the value layer, not just the workflow. When a process built around craft gets accelerated, the people inside it need a new definition of where their expertise creates value, judgment, taste, system design, client trust, before the old one feels obsolete. Migration of the human's value layer is a deliverable, not an afterthought.
- Keep compliance on the same clock as the build. Collapsing code delivery is worthless if the compliance review, security sign-off, and handoff documentation still run sequentially at the end. The sequential trap lives in the governance layer too, and that is where Govern sits.
- Close the fluency gap as part of the engagement. Handing someone a tool is not enablement. The capability gap is itself a limiter, and it has to be removed deliberately, or all the work quietly re-concentrates on the few fluent operators, and you've built a bus factor, not a platform.
- Make the trusted source of truth feel like augmentation, not surrender. The transcript only wins if the human still owns the judgment on top of it.
In Modulaa, these aren't slogans, they're where the human-in-the-loop gates live. Every phase produces a finished artifact and routes it to a person for approval, so the senior reviewer spends their time on judgment instead of generation, and the role moves up the value layer instead of being flooded at the old one. The orchestration connects the tools the team already uses, Figma, GitHub, Jira, Confluence, so adoption doesn't ask anyone to abandon the surface they trust. And because the system encodes the delivery expertise into the workflow, the fluency gap stops being a single point of failure: the capability is in the process, not trapped in the two people who already know how to prompt.
None of this is in the architecture diagram. All of it is in whether the architecture survives contact with a real organization. That's the difference between selling generation speed and delivering outcomes, and it's the part most AI tools leave as the customer's problem.
One well, two limiters
We drilled one well. On the technical axis, the framework validated cleanly: remove the sequential trap, and output lifts by an order of magnitude. That part is settled.
But the well's more valuable lesson was the one we didn't go in looking for. Underneath the delivery limiter sits the organizational one, and it is human, structural, and far more stubborn. Lowman Harley was right the first time. The organizational speed limit isn't a metaphor for the technology problem. It's the deeper problem, and removing the technology limiter is precisely what exposes it.
That's not a reason to stop. It's the next limiter in the stack. Dupriest didn't quit when the second constraint appeared, he measured it, named it, and built a dial that made it impossible for the people on the rig to keep ignoring it. So will we. The second well won't just test whether we can compress delivery. It will test whether we can help an organization absorb the compression without the humans inside it quietly strangling the result.
The framework held. The first limiter fell. The one underneath it is the real work.
If you've read this far, you've probably recognized your own organization somewhere in those five constraints, the review queue that assumes code arrives slowly, the design process optimized for craft, the compliance approval chain sized for sequential delivery, the fluency gap, the interpretation habit. That recognition is the diagnosis. The question is what you do with it.
Here's what Dupriest would tell you not to do: don't mandate it. Don't send a memo announcing the team is now "AI-first" and wait for the org to comply. The drillers didn't change because a vice president told them to. They changed because the dial was right there in front of them, second by second, turning an argument they'd have resisted forever into a number they couldn't look away from. The limiter only moved once it became visible to the person who had to move it.
So that's the offer, and it's deliberately small and measurable, a dial, not a directive. We deliver two or three production modules inside your codebase, in four to six weeks, running the full lifecycle in parallel with your people at every gate. You measure the result against your own team, on speed, cost, and quality, and, just as importantly, you watch where your organizational limiter shows up: which gate backs up, which expert digs in, which ceremony refuses to die. One well. Your codebase. Real numbers on the screen.
Because that was always Dupriest's real insight. The rock wasn't the enemy and the bit wasn't the hero. The breakthrough came the moment the energy being wasted stopped being invisible, the moment someone could finally watch the limiter on a dial and decide, on their own, to remove it. We're building that dial for software delivery. We've drilled one well with it. The reading was unmistakable.
Now we'd like to watch the needle move in yours.