One of the more impressive things about AI-assisted software development is how quickly you can go from an idea to a working screen.
Describe a customer maintenance window, explain the fields, identify the validation rules, and ask the AI to build it.
Before long, you have something that looks and behaves like a real application.
You can enter information. You can save it. You can retrieve it. The buttons work. The validation works. The tests pass.
That's impressive.
Now build another screen.
And another.
And another.
Eventually, you have a reasonably substantial application with dozens of screens, each doing its job.
That's impressive, too.
But I think there's a question we ought to be asking long before we get that far.
What happens when we need to change something that affects all fifty screens?
And there's another question that's becoming increasingly important as we use AI agents to develop larger applications.
Do those fifty screens even look and behave like they belong to the same application?
Because that's when we begin to discover whether we've been building an application or simply accumulating working screens.
The First Screen Proves Very Little
The first screen demonstrates that we can implement a particular piece of functionality.
That's valuable, but it's a fairly limited test.
We haven't yet discovered whether the approach will work consistently across the application.
We haven't discovered how easily it can accommodate different requirements.
We haven't discovered whether a change to something fundamental can be made in one place or whether we'll have to revisit every screen that depends upon it.
Most importantly, we haven't yet paid the cost of maintaining what we've created.
AI can make that cost remarkably easy to overlook.
When writing another implementation takes only a few minutes, creating one more variation doesn't seem particularly expensive.
A screen needs a slightly different validation message? Have AI change it.
Another screen needs a different keyboard behavior? Have AI implement that.
A third screen needs its own approach to displaying errors? That's easy enough, too.
Each decision looks reasonable when considered by itself.
The problem becomes apparent when we consider them together.
We've allowed the application to accumulate different implementations of behavior that may really represent the same underlying requirement.
And eventually, we're going to want to change that requirement.
Now Change the Rule
Consider a business application with fifty data-entry screens.
Suppose we decide that validation messages need to behave differently.
Perhaps users have been complaining that error messages disappear too quickly.
Maybe we want the application to identify the first invalid field automatically.
Perhaps we discover that keyboard navigation needs to be improved.
None of these changes is particularly exotic.
They're ordinary refinements that happen as software matures.
If the application has a well-defined, shared approach to validation and user feedback, the change may be reasonably straightforward.
We modify the responsible component or service, verify the new behavior, and test the applications that depend upon it.
But suppose every screen has accumulated its own variation.
Now we have a different problem.
We need to find every implementation.
We need to understand how each one behaves.
We need to distinguish legitimate differences from accidental ones.
We need to update the implementations without introducing new inconsistencies.
And we need to test the results.
AI can certainly help us do all of that.
In fact, it may do much of the work considerably faster than a human programmer could.
But that doesn't eliminate the underlying problem.
We've made one change into fifty changes.
The code may have been inexpensive to generate, but we've created a maintenance obligation that didn't necessarily have to exist.
Fifty Working Screens Are Not Necessarily One System
This is the distinction I find increasingly important.
AI is very good at producing individual implementations.
Give it a well-defined problem, enough context, and appropriate tools, and it can often produce an excellent solution.
But fifty excellent individual solutions don't automatically form an excellent architecture.
A system needs more than features that work independently.
It needs consistent behavior.
It needs clear responsibilities.
It needs shared capabilities where sharing makes sense.
It needs well-defined places where individual screens are allowed to be different.
And it needs a way to accommodate change without having to reconstruct its own foundations.
None of these ideas is new.
Software developers have been discussing reusable components, separation of concerns, and architectural consistency for decades.
What's changed is the economics.
When writing code was expensive, duplication carried an obvious cost.
You could see the additional work accumulating.
When AI can generate another implementation almost immediately, that cost becomes less visible.
The duplication still exists.
The maintenance obligation still exists.
But the initial investment is so small that we may not recognize what we're creating.
We can accumulate architectural debt at a speed that would have been difficult to achieve when we were writing everything ourselves.
The Fiftieth Screen May Have a Different Author
There's another complication we need to consider, and it's particularly relevant to AI development.
There's a very good chance that the fiftieth screen wasn't developed in the same AI session as the first one.
In fact, on a substantial project, those fifty screens may have been developed by dozens of different AI sessions over a period of weeks or months.
Each session may have had different context.
Each may have been given a slightly different assignment.
And each may have made perfectly reasonable decisions about how its particular screen should look and behave.
Unfortunately, those reasonable decisions don't necessarily add up to a consistent application.
One screen puts Save and Cancel in a particular order. Another reverses them.
One screen validates a field immediately. Another waits until the user saves.
One screen remembers the user's column widths and selections. Another doesn't.
One screen responds to the Escape key in a familiar way. Another behaves differently.
And perhaps one screen simply looks a little different because the AI session that created it chose different spacing, fonts, or button placement.
Every screen may work.
Every screen may pass its individual tests.
But the application doesn't feel like one application.
This is a distinction worth making because there are really two kinds of consistency involved.
Visual consistency means that the application has a common look and feel. Similar controls have similar appearances. Navigation follows recognizable patterns. Buttons, dialogs, messages, and layouts feel as though they belong together.
Behavioral consistency means that familiar actions work the same way throughout the application. A user who learns how to search, select, edit, save, or cancel on one screen doesn't have to relearn those actions on the next.
And there's a third dimension we've already been discussing.
Architectural consistency means that those shared behaviors are implemented through common mechanisms rather than reproduced independently in every screen.
All three matter.
A mature component library can help considerably with the first two.
Established controls already have conventions for appearance, interaction, keyboard navigation, and other everyday behaviors.
But even that isn't the complete answer.
A common toolkit can provide consistent controls. It can't automatically decide whether every screen should save, cancel, validate, navigate, and report errors according to the same application-wide rules.
Those decisions still need to be part of the application's design.
And if we're using multiple AI agents, those decisions need to be reflected in shared components, established patterns, and tests rather than depending upon every new session remembering what the previous sessions did.
The user doesn't care how many AI sessions built the application. The user expects it to behave as though one thoughtful designer was responsible for the whole thing.
Reuse Doesn't Mean Making Everything Identical
There's another mistake we need to avoid.
The answer isn't to force every screen through one enormous, highly configurable component.
That's simply a different way to create trouble.
Some screens really are different.
An order-entry screen may have requirements that don't apply to customer maintenance.
A reporting interface may need very different navigation from an ordinary editing form.
A specialized workflow may justify custom behavior.
Those differences are legitimate.
The architectural question is where the differences belong.
If every screen handles validation differently because each was developed independently, that's probably a problem.
If screens share the same validation behavior but display different fields and enforce different business rules, that's a reasonable design.
The same distinction applies to navigation, data access, permissions, presentation, and other common capabilities.
We don't necessarily want one screen.
We want a consistent foundation from which many different screens can be constructed.
The objective isn't identical screens. It's consistent behavior where consistency matters.
Test the Fiftieth Screen Before You Build It
We don't actually need to create fifty screens to discover whether we're heading in the right direction.
We can test the architecture much earlier.
Suppose we're developing a new application.
Instead of building twenty similar screens and evaluating the results, we might begin with three deliberately different ones.
A straightforward maintenance screen.
A complex browse with filtering and selection.
A transaction screen with validation and multiple steps.
These give us enough variation to start challenging our assumptions.
Then we introduce a change that affects all three.
Change the way validation errors are displayed.
Change a shared keyboard interaction.
Change a common presentation rule.
Change how user permissions affect available actions.
Now observe what happens.
Does the change have a natural home?
Can we make it without understanding and modifying every screen individually?
Do the screens behave consistently afterward?
Can we identify which differences are intentional?
Can we verify the change without depending entirely on visual inspection?
Those are much more interesting architectural tests than simply asking whether each new screen works.
And we can take this experiment one step further.
Have a different AI session build another screen using the same established components and application rules.
Don't ask it to invent a new design.
Give it the architecture and the requirements, just as we would when assigning work to another developer.
Then see whether the resulting screen fits naturally into the application.
Does it follow the existing conventions?
Does it use the shared behaviors?
Does it introduce unnecessary alternatives?
Can we make an application-wide change without having to modify its new implementation separately?
If the answer is yes, we're beginning to establish something more valuable than a collection of working demonstrations.
We're establishing a system that can grow.
And AI makes these experiments practical.
We can ask agents to explore alternative designs, implement representative examples, and compare how each approach handles the same change.
We can experiment before committing to a structure that will eventually support hundreds of features.
That's a tremendous advantage.
But we have to ask the questions that make the experiment worthwhile.
Sometimes the Best Component Is One We Don't Build
There's another consideration.
Why are we building every component ourselves in the first place?
A developer creating a modern business application may need sophisticated data grids, editors, charts, navigation, and other interface elements.
AI can help create all of them.
But creating them isn't necessarily the best use of our time.
There are mature components and libraries that have already accumulated years of development and experience.
They may support complicated interactions, accessibility requirements, unusual data conditions, internationalization, and many other capabilities that won't appear in our first demonstration.
They can also provide something that's particularly useful when multiple AI sessions are involved.
A common foundation.
When every agent works with the same established controls, there are fewer opportunities to independently invent the appearance and behavior of familiar interface elements.
That doesn't mean every third-party component is appropriate.
Licensing matters.
Integration matters.
Long-term support matters.
Performance matters.
And sometimes our requirements genuinely justify building something ourselves.
But the decision should be deliberate.
The question isn't simply whether AI can build an alternative.
It's whether owning and maintaining that alternative creates more value than using something that already exists.
This is where inexpensive code generation should actually make us more selective.
We can afford to evaluate several approaches.
We can prototype with existing components.
We can test integration requirements.
We can identify limitations before committing.
AI gives us more freedom to make informed architectural decisions.
We shouldn't use that freedom merely to generate more code.
The Real Measure Is the Cost of Change
I think this brings us to a useful way of evaluating software architecture.
Rather than asking only how quickly we can build a feature, we should ask how easily the application can evolve after the feature is built.
What happens when the rules change?
What happens when users discover a better workflow?
What happens when a component needs to be replaced?
What happens when something that worked well in one application needs to behave consistently across several?
Can we make the change in the place where it belongs?
Or do we have to chase its consequences through dozens of independent implementations?
And when another AI session adds the fifty-first screen, will it inherit the application's established behavior or invent another variation?
These are the questions that reveal the quality of the architecture.
They also expose the difference between software that was assembled quickly and software that was designed to grow.
AI helps enormously with both.
But it doesn't automatically make them the same thing.
The Question Worth Asking
The next time an AI produces an impressive new screen, enjoy the result.
That's genuine progress.
But before asking it to build the next forty-nine, try something different.
Ask what happens when the behavior of that screen needs to change.
Ask which parts should be shared.
Ask which differences are intentional.
Ask whether we're creating a reusable capability or another independent implementation.
Ask whether another AI session could build a compatible screen without inventing its own conventions.
And ask how we'll know that an improvement made tomorrow reaches everything that depends upon it.
The first screen tells us whether we can build something.
The fiftieth screen tells us whether we built something worth building upon.
That's the test I think we should be designing for.
Related Field Note: The Component We Didn't Need to Build looks at why an existing software component may be more valuable than another custom implementation, even when AI makes that implementation easy to create.