Most of Andrew Ng's thirty-two minutes at LangChain's Interrupt 26 is the material you have heard from him before, delivered well. Two passages are not, and both are unusually concrete: a procurement policy he states as his own practice, and a worked example that explains the gap between an AI project that saves an hour and one that changes what the business sells.
The advice with a number attached
Asked about vendor selection, Ng gives a policy rather than a principle, and is careful to frame it as description, not prescription.
"I'm actually not at all sure what would be the leading coding agent a year from now. And so in moments of uncertainty like this, optionality is very valuable. So candidly, many vendors are coming to all of our businesses and offering 20%, 30% discounts, but signing a three-year contract... Not giving any advice, just saying what I do. I personally almost never signed longer than a one-year contract, regardless of the discounts offered, because I value that optionality to work with whatever vendor would be the best in the year's time that I don't know about."
The part worth sitting with is what he applies the same test to next — not contracts, but people:
"When you have a handful of FDEs from one company in your company, how much does letting them embed everything with one AI model or whatever, reduce your optionality one or two years from now?"
Forward deployed engineers are usually discussed as a delivery model. Ng is asking what they cost you in switching ability, which is a question you can actually put to a vendor before signing.
A three-year deal at 30% off is only a saving if the tool is still the one you would pick in year two. If the field moves the way the last eighteen months moved, the discount is buying you the right to stay on something you would otherwise leave — and the migration you deferred gets more expensive as more of your codebase assumes it. Ng's rule is a way of refusing to price that risk at zero.
He extends the same reasoning to open weights, where his concern is unusually current:
"Over the last two weeks, I've been concerning noises out of the White House about inspecting models before their release. I'm actually quite concerned about that... if we can all protect open source, open weight, it will make the world much richer, and also help all of us preserve optionality."
His practical read on open models: "persistently... maybe six to nine months behind the frontier models, but the frontier models are expensive enough that for many use cases" his teams use open weights, fine-tuned or not.
Why most enterprise AI lands as a rounding error
This is the most transferable thing in the conversation. He takes loan underwriting — market the product, take the application, review and approve, final diligence, execute — and points at the step everyone automates first.
"A number of teams have noticed that the step in the middle of loan approval, we could use AI to do that. And if we could automate that, then instead of a human spending an hour reviewing the loan application, we could have AI do it... But it turns out that if your entire process underwriting the loan stays the same except for automating what was previously one hour of human time. That's a small incremental efficiency gain."
The alternative is not a better model. It is a different product:
"So what a number of banks have said is, you know what, instead of doing this efficiency gain, which is worthwhile, let's rethink the entire workflow and market a get approved in 10-minute loan product. Because rather than waiting around for a week for a human to be free for an hour, we can send the loan application, the AI right away for a decision."
And the reason this is rare is organisational, not technical:
"The challenge with implementing this in a lot of businesses is, this takes someone with a broader scope to rethink and redesign the entire workflow... So marketing data infra needs to be involved. Then yes, AI can make the initial decision. And then final diligence execution probably needs to scale up as well."
His conclusion is that bottom-up experimentation generates the ideas but cannot cash them: it "has to be complemented with a top-down motion of having someone with the broader scope to change how all of these steps operate to then create growth."
| What you automate | What you get |
|---|---|
| The slowest single step, workflow unchanged | An hour of human time back per application |
| Every step re-timed around an instant decision | A product that did not previously exist |
The knowledge-cutoff problem, stated plainly
On why coding agents stumble on anything recent:
"One challenge that coding agents have is a lot of building blocks are so new that the coding agents do not know how to use them."
His example is a model released after the leading agents' training cutoff, so the agent does not know the API exists — and his response is Context Hub, a project he describes as "kind of a stack overflow for AI agents," serving current documentation to agents and taking their feedback on it. Treat that as an interested party describing his own project; the underlying problem is real and you have hit it.
The framing around it is the LEGO argument he has used before — mastery of many building blocks makes what you can assemble grow "combinatorially" — which is fine but not new.
The database aside
Buried at the end and easy to miss, an argument that agents should change your storage choice:
"We've all had that, one in a hundred times that we asked AI to do a database migration and did something clever like, erase my whole database instead... Almost never happens. But the fact that it almost never happens but doesn't never happens is a little bit annoying."
His answer is schema-on-read for iteration speed, moving to relational at production scale. Note this is an argument about iteration velocity, not safety — a NoSQL store does not stop an agent erasing anything. If the one-in-a-hundred wipe is your worry, the fix is backups and permissions, not a document store.
Where to push back
The optionality argument has a cost he does not price. Refusing multi-year commitments means re-running procurement annually, keeping abstraction layers you might not need, and declining real savings. For a team that has found a tool that works, the discount may simply be worth taking. He says as much implicitly — "not giving any advice, just saying what I do" — and that hedge is doing more work than it appears.
The loan example is also told from the winning side. "Rethink the entire workflow" is what every transformation deck has said for twenty years; the reason firms automate one step instead is that the whole-workflow version requires authority across marketing, risk, and ops that almost nobody has. Ng names this as the challenge but does not say how the banks who did it got that authority, which is the only part that is hard.
And this is a fireside chat at a conference hosted by a vendor whose product he praises from the stage. Nothing here is dishonest, but the format rewards agreement over argument, and it shows.
Worth watching
Thirty-two minutes, and the density is uneven. The vendor-optionality passage runs from about 24 minutes and the loan example from about 15; those twelve minutes are the ones to watch. If you take one thing to work, make it the table above — most AI proposals crossing your desk are the first row wearing the language of the second.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)