Rate Limiter on AI Adoption Is Organizational

TL;DR

• The claim: enterprise AI adoption isn't stalling because the technology doesn't work — it stalls on process, culture, and a skills gap. All the frontier research showcased at the summit only pays off if people inside thousands of ordinary companies can turn it into value.
• The diagnosis started with an experiment: two engineers gave wildly different estimates for the same feature. The gap tracked neither seniority nor codebase familiarity — one engineer was AI-pilled and knew how to steer the technology; the other used AI mostly as a chatbot while believing they had already mastered it.
• Why people misjudge themselves: with mobile or cloud, errors were obvious and the technology pushed back, forcing you to learn. AI's natural-language interface makes conversation feel like competence, and hides the fact that both outputs and outcomes need validation. It requires a genuinely different mental model.
• Enabling only engineers is myopic: most large companies start there, which unblocks one function while creating bottlenecks everywhere else. Ironclad deliberately enabled engineering, product, and design at the same time.
• Then they hit Amdahl's Law: fluency arrived, but product velocity didn't follow, because the process hadn't changed. They were still running waterfall — product research, hand-off to UX, hand-off to engineering — and engineers finished fast, then waited on answers.
• Three fixes: education as infrastructure (shared lexicon, shared tooling and harnesses, one system for context management, RAG, and memory); moving specification to the front (the right people convene early, argue the problem out, and memorialize the solution as markdown or a Notion page before handing it to an agent); and tooling and guardrails (code-review agents plus a library of skills that enforce output quality).
• It generalizes: a Fortune 100 customer asked Ironclad to run the same program for them; the outcomes were very similar, and the customer saw the same acceleration.

Key Points

The claim: the bottleneck isn't the technology (~00:01)

She put the conclusion on the table immediately: AI adoption in enterprises is not stalling because the technology is missing or broken — it stalls for other reasons, chiefly process and culture. The follow-up question is why anyone in the room should care, and her answer is that all the excellent work presented at the summit has to deliver value or it was for nothing. The eventual users of this technology are the people inside the thousands of companies around us.

The starting point: two engineers, two very different estimates (~00:02)

About a month or two after joining Ironclad — nine months before the talk — she ran a deliberate experiment during a feature discussion, asking two engineers separately what it would take to build the same thing. The estimates diverged enough to give her pause.

Digging in, the difference was not seniority and not familiarity with the codebase. One engineer was AI-pilled — they understood how to work with the technology and steer it. The other was using AI mainly as a chatbot while feeling they had already mastered it.

That left her with a choice. Given how fast the technology was moving, the gap would compound: she could accept a two-speed engineering organization, or do something about it.

Why people believe they've mastered it (~00:03)

Her explanation is that the interface creates the illusion. With previous technology waves — mobile, cloud — errors were obvious. The technology pushed back, and you had to learn what was going wrong before you could make progress. With AI, the interface is natural language, so simply talking to it makes you feel you know what you're doing, without realizing that the outputs need to be validated and the outcomes need to be validated. It is a very different mental model.

She also noted that many people in the audience would say they already knew this — but a huge workforce out there does not share that mindset, and getting the technology adopted by that group requires doing something deliberate.

Enabling everyone at once (~00:05)

Talking to other companies — Fortune 500 and larger — she found that most say some version of "we'll enable our engineers." She considers this myopic: you enable one function and manufacture bottlenecks elsewhere in the organization.

Ironclad did the opposite from the start: everyone gets enabled simultaneously. Some people were already AI-native and felt they didn't need it; the company was nevertheless clear that engineering, product, and design would be enabled together. The goal she set: be a company where building with AI, and building AI, is not a bespoke act reserved for certain people.

Three principles:

1. There will be no halo group doing AI off to one side and dragging everyone else along.
2. The hard parts — outcome validation, evals, eval harnesses — get delivered through tooling, so everyone benefits at once.
3. It isn't that only top people get to use AI: everybody has to, and everybody will.

Execution: a 20-day program before the December hackathon (~00:06)

She used an event already on the calendar — the company hackathon in December 2025, when she was three months into the job. She wanted the team to arrive AI-ready and the hackathon to produce AI-built outcomes, so she designed a 20-day program to run beforehand.

Day one, she taught the classes herself, open to anyone in the company: LLM fundamentals, how LLMs work under the hood, how to think about context, in-context learning, prompt optimization, tuning, and evaluations. For the remaining days, one engineer per day presented what they had built with the technology, how they built it, what problems they ran into, and what they learned. Momentum was sustained through Slack channels and impromptu get-togethers the engineers organized themselves.

Participation at the hackathon was very high, and the team built capabilities she hadn't thought they could — a positive surprise. On fluency, the company had arrived.

Hitting Amdahl's Law (~00:09)

By January 2026, feature development still hadn't accelerated the way she expected. Experimentation had taken off; shipping into the product hadn't.

The diagnosis was Amdahl's Law: you update one part of the process, and the parts you didn't touch become the bottleneck. Every function was building AI and building with AI, but the process itself had not shifted at all. They were still running a waterfall — product does research, hands off to UX, hands off to engineering — and engineers would finish quickly, then spend most of their time waiting on answers from product.

The three fixes (~00:10)

Education as infrastructure. Beyond classes: a shared lexicon, shared tooling, shared harnesses, and common systems for context management, RAG, and memory — pulling organizational memory into a single system.

Move specification to the front. Now, when building something, the relevant people convene early: they discuss the problem, debate it, propose a solution, iterate on it, and memorialize the result as a markdown doc or a Notion page. Only then is that fleshed-out work handed to an agent to execute.

She tied this to Ion Stoica's talk the previous day: a major reason AI outcomes disappoint is under-specification of requirements. Getting everyone together at the front of the process is how you flesh those requirements out first. She was careful not to claim perfection, but clearly specifying the constraints, the boundaries, and the solution space before handing work to an agent has produced good outcomes.

Tooling and guardrails. Beyond code-review agents, they built a library of skills that ensure agent output — especially code — meets company standards, so nobody has to wonder whether their agent is doing the right thing.

Where they are now (~00:12)

• Agent framework: lets anyone create an agent quickly. Built on OpenAI's Agents SDK and Vercel's AI SDK, connected to the frontier models; they have also started tuning their own models, which are hooked up behind these agents. Around it sits infrastructure for continuous context optimization, memory management, continuous evals, and prompting.
• Automated evals across large parts of the system: LLM judges evaluate agent output, then an evaluation agent compares it against a rubric and keeps iterating until the eval comes close enough to the rubric. It runs continuously without pulling engineers in — once something is built, reviewed, and checked in, it flows into this evaluation process automatically.
• Their own code-generation harness: they evaluated what was available — the Codex harness, Claude's harness — and none matched what they wanted, so they used those (and open-source ones) as benchmarks and substrate and built their own on top, running on Temporal. Anyone, including product managers who now code, can hand the harness a job: a UI, a backend service, any piece of code. The harness spins up a VM, sets up an environment close to production inside it, generates the code there, tests it there, and produces a review-ready PR for a human or a review agent. It is in dogfood and producing very good results.

Results and generalization (~00:15)

Ironclad is a commercial legal-tech product; nearly every Silicon Valley company is a customer, including the frontier labs. Agents live in the product today, acting on live contracts carrying billions of dollars of value. Engineering statistics show a very different execution velocity than a year ago (she flagged that the drop at the end of the curve is incomplete data, not regression).

None of this is proprietary to Ironclad. A Fortune 100 customer asked to run the same program; although it hadn't been designed for external use, they ran it, and the outcomes were very similar — that customer is also seeing acceleration.

She closed by connecting to Andrew Ng's fireside chat the day before: Ng worries that people building AI under-invest in education, and that this becomes a barrier to adoption. Her talk, she said, is a data point from experience in support of that claim.

Quotes

"The adoption of AI in enterprises is not stalling because the technology is not working or is not there. It's stalling because of other reasons. And one of the other reasons tends to be processes, culture and so on." (~00:01:30)

The whole talk rests on this: the bottleneck is organizational, not architectural.

"We want to make sure we are a company where building with AI and building AI is not a bespoke act for certain people." (~00:05:38)

Her stated reason for refusing a two-speed organization.

"It's actually Amdahl's law … you update one part of the process, but now the parts of the process that you didn't touch actually become the bottleneck." (~00:09:11)

Closing the skills gap was only the first segment; without process change, the bottleneck just moves.

"Education is an important component of getting AI deployed in enterprises." (~00:17)

Her closing line, and an echo of Andrew Ng's concern from the previous day.