If AI makes coding 10× faster, why doesn’t the whole company become 10× faster?
Suppose a feature takes seventeen days from “we should build this” to “it actually works.” Ten of those days are coding.
An AMUI interactive interpretation inspired by Andrew Ng. The 10× speedup and project numbers are hypothetical, not a measured productivity claim.
Even if coding took no time at all, understanding, deciding and checking would still take seven days.
7-day floorDrag the build step down to one day and the whole project falls from seventeen days to eight.
Ten times faster at coding. Just over twice as fast overall.
And that changes the expensive mistake.
Yesterday, a weak idea could waste ten engineering days. Tomorrow, AI can help you build the same weak idea before lunch.
If building gets cheap, choosing badly gets expensive.
Imagine our team runs an online shop.
Customers keep abandoning checkout. The team can ship one change tomorrow.Customers repeatedly leave when shipping cost appears for the first time at the end.
Support messages ask why the final price is higher than the cart total they saw earlier.
No current evidence shows customers asking for product recommendations during checkout.
Suppose the team chooses well.
They decide to fix another expensive problem: refund requests that bounce between customers and support staff because nobody has the right information at the right moment.
The first version of the assistant is ready almost immediately.
A customer asks for a refund. The assistant answers perfectly.
There is only one problem.
It made the refund policy up.
The last version is different.
It can look things up. It can inspect real business state. It can follow a fixed procedure. And when the procedure stops fitting the case, it can choose what to do next.
That is the point where the word agent becomes useful.
Now the system works in the demo.
One customer asks for a refund. The assistant checks the policy, checks the order, follows the procedure, and stops exactly where it should.
One green case proves the assistant can work. It does not tell us where it stops working.
Once the rest of the cases appear, the interesting result is not just the pass rate.
The failures cluster.
Conflicting information causes trouble. Missing data makes the assistant overconfident. Adversarial inputs push it away from the intended process. Strange order states break assumptions the happy path never exposed.
A demo asks, “Can this work?” Evaluation asks, “When does it stop working?”
And once the system can act, there is one more trap.
It checked the wrong definition of success.
The action succeeded. The outcome did not.
The agent checked the action it took.
Verification checks the state the world ended up in.
That is the deeper answer to the original question.
AI can make one part of building software astonishingly cheap.
But useful software was never just the code.
If coding becomes cheap, what becomes valuable next?
Choosing what deserves to exist. Understanding the system well enough to see how it can fail. And proving that the result is true outside the model that produced it.
BUSINESS FOCUS → choose the right problem
DELIVERY → make the result hold up
From the lecture: rapid AI progress, faster AI-assisted software development, growing importance of product judgment, depth, business focus, delivery, agents and responsible deployment. Our teaching examples: the 17-day project, online-shop decision, refund assistant, evaluation matrix and refund-verification incident are invented examples used to expose those ideas. They are not quotations from Andrew Ng or Laurence Moroney.
What this means for your next product.
Before accelerating a build, choose one user task and define a result you can observe. Map the information the system needs, the actions it may take, and the cases that require human review. Faster implementation earns its value when the whole workflow works.
A hypothetical AMUI project: imagine an online shop considering a refund-support assistant. We would evaluate resolution accuracy: did it apply the current policy to the actual order and reach the correct outcome? We would also evaluate escalation behavior: did it hand uncertain, conflicting, or sensitive cases to a person before taking action, with enough context for that person to help? Compare those results with the shop’s existing support process. Faster coding makes the prototype easier to build; evidence about correct resolutions and appropriate escalation tells us whether it deserves to ship. This is an invented example, not a client case study or a measured result.
Explore web application development ↗