The Demo That Passed Every Test
One of the more interesting things about working with AI coding agents is how quickly they can convince you that something is finished.
You describe a feature. The agent writes the code, builds the application, runs the tests, and reports that everything passed.
You open the application, click through the new functionality, and sure enough, it works.
So we're finished, right?
Not necessarily.
There's a difference between proving that the software does what we asked and discovering whether we asked for the right thing.
And that difference has become increasingly important in my own development work.
Everything Worked
Think about a typical business application.
Suppose we ask an AI agent to build a screen for entering customer orders.
We describe the fields, the validation rules, the calculations, and the database operations.
The agent implements everything.
It verifies that required fields are enforced, calculations produce the expected totals, and records are saved correctly.
We examine the results and find that everything works as specified.
That's a successful implementation.
But now imagine sitting down with a real order and trying to process it from beginning to end.
You discover that you need information from another screen, so you navigate away and come back.
Then you realize the customer wants to change something, but the application doesn't provide a convenient way to make the adjustment.
Perhaps you need to enter the same information twice.
Or maybe you find yourself clicking through several screens to perform an operation that should have required one.
The software isn't necessarily broken.
It's doing exactly what we asked it to do.
The problem is that we didn't ask all the right questions.
The Tests Weren't Wrong
This is an important distinction.
When a test verifies that a calculation is correct, it isn't supposed to determine whether the user should have needed that calculation in the first place.
When a test verifies that a button saves a record, it doesn't necessarily establish whether that button belongs on that screen.
And when an AI agent reports that all tests passed, it isn't claiming to have validated every assumption behind the design.
At least, it shouldn't be.
Tests are valuable because they verify defined expectations.
But if our expectations are incomplete, successful tests can coexist with a poor experience.
That isn't a failure of testing.
It's a failure to recognize what the tests were actually proving.
The Missing Test Was the Experience
This is where I think realistic demonstrations become particularly valuable.
Instead of demonstrating individual features, we need to demonstrate complete activities.
Don't just show that an order can be entered.
Process an actual order, including the ordinary interruptions, changes, and exceptions that happen in the real world.
Don't just demonstrate that a report can be generated.
Start with the question the user is trying to answer, find the information, generate the report, and see whether the result is actually useful.
Don't just show that a document can be edited.
Try to complete the work that required editing the document in the first place.
The difference sounds subtle.
It isn't.
A feature demonstration begins with the software and shows what it can do.
A realistic demonstration begins with the user's objective and discovers whether the software helps accomplish it.
Those are two very different starting points.
AI Makes This More Important, Not Less
Before AI-assisted development, the cost of implementing a feature often forced us to spend considerable time thinking about what we wanted before we started writing code.
That didn't guarantee good design, of course.
But it created a natural incentive to question the requirements.
Now we can describe a feature and have an AI agent produce a working implementation in a fraction of the time.
That's an extraordinary improvement in productivity.
It also creates a temptation.
Because the agent can build something so quickly, we may spend less time questioning whether it should be built that way.
And once we see a polished, working interface, it's easy to become attached to it.
We start improving the implementation rather than reconsidering the underlying design.
The danger isn't that AI produces bad code.
The danger is that AI can produce perfectly reasonable code for an idea that wasn't sufficiently thought through.
And it can do that repeatedly, at remarkable speed.
A Different Kind of Review
I've become increasingly interested in separating two questions during AI-assisted development.
The first is whether the agent correctly implemented the requested functionality.
That's a technical review.
We examine the code, the tests, the behavior, and the results.
The second question is whether the requested functionality actually creates the experience we intended.
That's a design review.
It requires us to step away from the implementation details and look at the application from the user's perspective.
Both reviews matter.
But they shouldn't be confused with each other.
An application can pass the first and fail the second.
And when that happens, asking the AI to fix a few isolated problems may not be enough.
Sometimes we need to reconsider the workflow itself.
What We Should Be Asking
The more I work with AI-assisted development, the more convinced I become that the questions we ask are at least as important as the instructions we give.
It's easy to ask an agent to create another screen, add another control, or implement another option.
It's harder to ask whether the user should have needed that screen, control, or option at all.
And that's where human judgment becomes particularly valuable.
AI can help us explore alternatives.
It can implement revised approaches quickly.
It can help identify inconsistencies and test different behaviors.
But someone still needs to understand what the software is supposed to accomplish and recognize when the implementation misses the point.
That's not something we should delegate away simply because the agent can write the code.
A Passing Grade Isn't the Finish Line
A successful build is good news.
Passing tests are good news.
A working demonstration is good news.
But none of those things, individually or together, establishes that we've created the right experience.
We still need to use the software in realistic circumstances.
We need to challenge our assumptions.
And we need to be willing to change something that works perfectly when we discover that it doesn't work the way it should.
The most important test may be the one we never wrote: Can someone actually accomplish what they came here to do?
Related Guide: The Demo Is Part of the Design examines how realistic demonstrations can help us discover design problems before they become permanent parts of an application.