AI is making software development accessible to more people than ever. The next challenge is helping all those individual solutions become something greater than the sum of their parts.
Part 5 — The final article in the series: When Building Becomes Easy, What Becomes Hard?
A business specialist builds an AI assistant to speed up reporting.
A customer service team creates an application to classify incoming requests.
A project manager develops a tool to extract action items from meeting notes.
A developer prototypes a new customer-facing feature in an afternoon.
Each initiative solves a real problem. Each team is excited about the possibilities. And each solution might be genuinely useful.
This is exactly the kind of innovation organizations have been trying to encourage for years.
But imagine that these initiatives are happening simultaneously across dozens of teams.
Some applications use the same data. Others solve similar problems. Several need access to the same business systems. Different teams choose different AI models, platforms and integration approaches.
Nobody necessarily knows what everyone else is building.
And sooner or later, someone asks:
Who is looking after the whole?
The end of development as a bottleneck
For a long time, access to software development capacity was one of the main constraints on digital innovation.
Business teams had ideas, but implementing them required developers, budgets, prioritization and time.
That constraint was frustrating, but it also created a natural point of coordination.
Ideas typically passed through some form of portfolio management, IT planning, architecture review or development backlog before they became software.
Those processes were often too slow. Sometimes they prevented useful innovation altogether.
AI-assisted development changes the equation.
A business specialist with sufficient curiosity and technical confidence can now build something useful without waiting for a traditional development project.
This is a remarkable opportunity.
But it also means that the mechanisms organizations previously relied on to maintain visibility and coordination may no longer work as expected.
The challenge is not that people outside IT are suddenly building software.
They have been doing that for decades, using spreadsheets, databases, macros, low-code tools and automation platforms.
What’s changing is the speed, sophistication and reach of what they can create.
A spreadsheet might support a local calculation.
An AI-assisted application can potentially process sensitive information, call external services, modify business data and influence decisions across multiple systems.
The consequences of an individual experiment can extend far beyond the team that created it.
Local optimization is not the same as organizational improvement
Let’s return to the example of meeting notes and action items.
One team builds an AI assistant that summarizes meetings and creates tasks.
Another team develops something similar using a different platform.
A third team purchases a commercial product with almost the same functionality.
All three may improve productivity locally.
But what happens when the organization wants to share tasks across teams, report on project commitments or connect the solutions to its customer relationship management system?
Now it has three different approaches to a similar business capability.
Each may require its own integrations, support, security arrangements and ongoing costs.
The individual decisions were not necessarily wrong.
The problem is that nobody evaluated them together.
A solution can be successful for one team and still create unnecessary complexity for the organization.
This is not an argument against local innovation.
It is an argument for making organizational context available when people make local decisions.
If teams can easily discover existing services, data sources, integrations and previous experiments, they can make better choices without losing their independence.
Architecture is becoming more important, not less
There is a tempting argument that AI-generated software makes traditional architecture less relevant.
If applications can be built and rebuilt quickly, why invest so much effort in designing systems and their relationships?
The answer depends on what we mean by architecture.
If architecture means producing extensive documentation before anyone is allowed to experiment, then yes, we should question its value.
But architecture is not fundamentally about diagrams or technology standards.
It is about understanding how capabilities, information, systems and responsibilities fit together.
That becomes more important when software creation is decentralized.
Consider an AI application that needs customer information.
Where should that information come from?
Which system is authoritative?
Is there already a supported API or data product that provides it?
What happens when the information changes?
Who is responsible for its quality and permitted use?
AI can help generate code to connect to a database or call an API.
It cannot independently determine which source the organization has agreed to trust, what data may be shared for a particular purpose or which integration approach is sustainable across the enterprise.
Those decisions depend on organizational knowledge, business context and accountability.
When everyone can build, architecture must help people make good decisions — not simply approve what they have already built.
From architecture as a gate to architecture as a service
This suggests a different role for enterprise architecture and shared technology teams.
Instead of primarily reviewing individual solutions, they can make good solutions easier to create.
For example, an organization might provide:
- A discoverable catalogue of business capabilities, existing applications, APIs, data products and reusable components.
- Approved environments for different types of experiments, with appropriate access controls and cost limits.
- Reusable patterns for identity management, integrations, AI model access, logging and monitoring.
- Practical guidance for handling different types of data and assessing risks.
- Clear paths for getting help when an experiment needs to become a dependable service.
The important word is usable.
A hundred-page architecture policy is not particularly helpful to someone trying to test an idea this afternoon.
A searchable catalogue, a working example, an accessible expert or a ready-to-use integration can be.
And AI itself could help people navigate this information.
Imagine an internal assistant that can answer:
“Has anyone already built something for this problem?”
“Which system should I use to get customer information?”
“Can I test this with real data?”
“What would it take to make this application available to other teams?”
The assistant wouldn’t need to make every decision.
Its value would be helping people find the right information, existing capabilities and responsible experts before they create unnecessary dependencies.
In this model, architecture becomes an enabling capability rather than a separate checkpoint.
Reuse has to be easier than rebuilding
Organizations often tell teams to reuse existing solutions.
But reuse is not always the easiest option.
Perhaps nobody knows the existing solution exists.
Perhaps its documentation is difficult to understand.
Perhaps the team that owns it is overloaded.
Perhaps getting access takes weeks, while building a new prototype takes an afternoon.
In that situation, asking people to reuse more is unlikely to change their behavior.
AI-assisted development makes this tension sharper.
The cost of building an alternative has fallen dramatically. The effort required to discover, understand and adopt an existing capability may not have fallen nearly as much.
If organizations want reuse, they need to improve the experience of reuse.
That means making existing capabilities easy to find, evaluate, access and integrate.
It also means recognizing that reuse is not always the right choice.
An existing system might not meet the need. A new experiment might reveal a better approach. Some duplication is acceptable during learning.
The important distinction is between temporary duplication for experimentation and permanent duplication in the operational environment.
Reuse should be a practical advantage, not a moral obligation.
Not everyone needs to become a software engineer
AI-assisted development also changes the skills organizations need.
Business specialists can now contribute much more directly to creating digital solutions.
That’s a positive development.
But it doesn’t mean everyone needs to become an expert in software architecture, cybersecurity, integration design or production operations.
Nor does it mean those specialisms are becoming unnecessary.
Instead, the relationship between business and technology expertise needs to evolve.
A business specialist may be best placed to understand the problem, test a hypothesis and evaluate whether the result is useful.
A developer may help turn the experiment into reliable software.
An integration specialist may identify existing APIs or data flows that should be reused.
A security or privacy expert may help determine how information can be handled appropriately.
A product or service owner may decide whether the capability justifies ongoing investment.
These people don’t all need to participate in every experiment.
But the organization needs a way to bring their expertise together when the situation requires it.
This is particularly relevant to AI ambassador programs.
The most valuable ambassadors may not be those who build the most agents.
They may be the people who help colleagues recognize opportunities, ask better questions, connect with existing capabilities and understand when additional expertise is needed.
They become bridges between business needs and organizational capabilities.
Governance should follow consequences, not tools
One mistake would be to introduce a single approval process for everything described as an AI application.
A personal productivity experiment using synthetic data does not carry the same consequences as a customer-facing service that processes confidential information or makes operational decisions.
The relevant distinction is not whether something uses AI, low-code, Python or a commercial platform.
It is what the solution does, what information it handles, who depends on it and what happens if it fails.
This suggests a proportional approach.
Low-risk experiments should be easy to start, with clear boundaries and limited commitments.
Experiments involving real business data or operational integrations need appropriate safeguards before those capabilities are introduced.
And when a solution becomes a shared or permanent service, its ownership, quality, support and lifecycle need to be established.
These are not necessarily separate bureaucratic stages.
They are changes in the level of responsibility the organization is taking on.
The goal is to preserve freedom where the consequences are limited and establish clarity where they are not.
As I argued in the previous article:
Design experiments to be disposable. Design services to be dependable.
Someone still has to own the whole
There is one final challenge that no amount of automation can fully solve.
Who is accountable for the overall direction?
An individual team can decide whether a tool improves its work.
But it cannot necessarily decide whether the organization should maintain five overlapping customer data services, introduce another integration platform or support dozens of independently developed AI applications.
Those are organizational decisions.
They require visibility across initiatives, an understanding of shared capabilities and a willingness to make trade-offs.
This doesn’t mean every decision should be centralized.
Quite the opposite.
The more decisions teams can make independently within clear boundaries, the less need there is for central coordination of individual activities.
But some responsibilities remain shared:
Ensuring that critical information is trustworthy.
Making common capabilities available.
Managing dependencies between services.
Understanding the cumulative costs and risks of the technology landscape.
And deciding which experiments deserve long-term investment.
The organization needs to know not only what people are building, but also what it is collectively becoming responsible for.
Decentralized innovation works best when shared capabilities and accountability are deliberately designed.
From controlling development to enabling good decisions
Throughout this series, I’ve used the metaphor of software development changing from a hill into a valley.
Traditionally, implementation formed a significant peak in the effort required to create a digital solution.
AI-assisted development is flattening that peak.
But the work on either side remains.
Before implementation, we need to understand the problem, identify existing capabilities, evaluate alternatives and decide what is worth testing.
After implementation, we need to validate the result, integrate it into real workflows, establish service ownership and ensure it can be operated responsibly.
And now, as more people become capable of building software, another dimension becomes increasingly important:
How do all those individual decisions fit together?
That question cannot be answered by a better coding assistant alone.
It requires organizational knowledge, accessible architecture, reusable capabilities, collaboration and clear responsibility.
AI can help with all of these.
It can make knowledge easier to discover, reduce the cost of integration, support validation and help people navigate complex technology environments.
But the organization still needs to decide what it wants to enable, what it wants to share and what it is willing to own.
The real opportunity
I don’t believe the future of AI-assisted development should be one where every idea needs permission from a central authority.
Nor should it be one where everyone independently builds whatever they need and the organization deals with the consequences later.
The opportunity is something more interesting.
A world where people closest to business problems can experiment freely.
Where existing capabilities are easy to discover and reuse.
Where technical specialists help others succeed rather than simply controlling access.
Where experiments produce learning, whether or not they become permanent services.
And where the decision to create a new organizational capability is conscious, informed and supported.
That requires more than faster software development.
It requires a better system for turning ideas into lasting value.
When everyone can build, the competitive advantage is no longer just the ability to create software. It’s the ability to make all that creativity work together.
Closing the series: When Building Becomes Easy, What Becomes Hard?
Across these five articles, I’ve explored how AI-assisted development is changing the economics and responsibilities of digital innovation.
The central argument is simple:
When building becomes easier, deciding what to build, how it fits together and what we’re prepared to own becomes more valuable.
The hill of implementation may be turning into a valley.
Our opportunity is not merely to cross it faster.
It’s to become much better at deciding where we’re going.
Previous articles in the series:
Part 1 — From Hill to Valley: How AI Is Moving the Software Development Bottleneck
Part 2 — Ten AI Experiments. One Business Problem.
Part 3 — Not Every Problem Needs an AI Agent