AI Makes It Easy to Build Software. But Who's Going to Maintain It?

There’s something exciting happening in organizations right now. People who have never written a line of code are building applications to solve real business problems. AI-powered development tools are making it possible for employees to turn ideas into working software in hours or days rather than weeks or months.

And I think that’s fantastic.

We’re seeing people take initiative, identify gaps in existing systems, and create solutions without waiting for traditional development teams. That’s exactly the kind of innovation organizations should encourage.

But as someone who comes from a software development background, I can’t help thinking about what happens next.

What happens when building software becomes incredibly easy, but owning and maintaining it doesn’t?

Are We Creating the Next Generation of Shadow IT?

Imagine an organization that gives its employees AI tools that let anyone build applications.

Someone needs a better way to track customer relationships, so they build a CRM. Another person needs to manage contracts, so they build a contract management application. Someone else creates a project tracking system because the existing tools don’t quite meet their needs.

Each application solves a real problem. Each creator deserves credit for taking initiative.

But over time, we could end up with multiple applications storing customer information, managing business processes, and making decisions based on different versions of the same data.

And that’s where I start to worry.

Not because people shouldn’t be building software, but because we’re potentially creating enterprise systems without the enterprise architecture that should support them.

We’ve spent decades trying to address the challenges of disconnected systems, fragmented data, inconsistent processes, and shadow IT.

Are we about to recreate those same problems, only much faster with AI?

The Cost of Building Software Is Going Down. The Cost of Ownership Isn’t Disappearing.

One of the biggest changes AI brings to software development is how dramatically it reduces the effort required to create something functional.

But there’s an important distinction between building an application and operating one sustainably.

An application that takes two days to build may need to be supported for the next five years.

Who maintains it when the original creator moves on? Who handles security vulnerabilities? What happens when an integration breaks? Who ensures sensitive business data is protected? Who manages access when employees change roles? And who decides when the application should be retired?

These aren’t new software engineering questions.

What’s new is that we’re dramatically increasing the number of people who can create software without necessarily increasing our organizational capacity to manage it.

And the challenge isn’t just technical debt. It’s organizational debt.

Every application introduces potential dependencies, data ownership questions, operational responsibilities, and long-term costs.

Individually, these may seem manageable. Collectively, they can become significant.

We could end up with a graveyard of applications that were easy to create, difficult to maintain, and too embedded in business processes to retire.

Maybe We’re Solving the Wrong Problem

I wonder if we’re focusing too much on making it easier to build applications and not enough on making it easier to build the right kinds of applications.

Take CRM as an example.

If someone builds a CRM because their team needs a better way to manage customer relationships, they’ve identified a legitimate business need.

But is the best solution really to build another CRM?

Or should we be investing in shared customer data, integrations, and workflow orchestration so that teams can build experiences around existing systems?

The same question applies to contract management, project tracking, approvals, reporting, and many other common business functions.

There’s a difference between creating a specialized workflow that adds value and rebuilding foundational business capabilities that already exist elsewhere.

The real opportunity may not be to help everyone build their own systems, but to help everyone build on top of shared organizational capabilities.

What If We Invested in AI Development Harnesses Instead?

This is where I think organizations have a much bigger opportunity.

Rather than treating AI app-building tools as simply a way for employees to generate applications, what if we treated them as an enterprise development platform?

Imagine an environment where the AI already understands the organization’s architecture, technology standards, security requirements, approved integrations, and development practices.

When someone wants to build a customer-facing application, the AI knows which customer system to connect to.

When someone needs an approval workflow, the AI can use an existing orchestration capability.

When an application needs authentication, permissions, or data access, those capabilities are already available.

And when someone is ready to move an application into production, the platform can help with testing, documentation, security checks, deployment, and monitoring.

This is what I mean by investing in AI development harnesses.

Not just better prompts or more powerful models, but an environment that surrounds AI with the tools, context, constraints, and automated processes needed to produce reliable software.

Of course, a harness doesn’t eliminate the need for engineering judgment or human oversight. But it can make good development practices accessible to people who aren’t software engineers.

Instead of every employee having to understand enterprise architecture, we can embed much of that expertise into the environment itself.

Embedding Organizational Expertise Into AI

This idea extends beyond software development.

Many companies already build products this way, embedding deep domain expertise into software so that customers can make better decisions without needing to become experts themselves.

Why wouldn’t we take the same approach to software development?

Organizations have accumulated years of experience around architecture, security, integrations, operations, and maintaining systems.

That expertise is valuable.

What if we could make it available through AI so that employees could benefit from it automatically?

A person building an application shouldn’t need to know every security policy, integration pattern, or architectural decision the organization has made.

The AI development environment should help guide those decisions.

And when it encounters something that requires deeper expertise, it should know when to bring a human into the process.

The goal shouldn’t be to eliminate engineering expertise. It should be to scale its impact.

Innovation and Governance Don’t Have to Be Opposites

One concern I have with conversations like this is that they can quickly turn into arguments about control.

Engineering wants standards. Business teams want speed. IT wants security. Employees want the freedom to solve their own problems.

But I don’t think those goals are mutually exclusive.

We should absolutely encourage experimentation.

Someone building a prototype to test an idea shouldn’t have to go through the same process as someone deploying a system that manages customer contracts or sensitive business information.

The level of oversight should match the level of risk.

A personal productivity tool, a team workflow, and a business-critical enterprise application have very different operational implications.

The answer isn’t to slow everyone down with approvals.

It’s to create a paved path where the easiest way to build something is also the most sustainable way.

Shared integrations, reusable components, automated testing, secure deployment patterns, and clear ownership can actually accelerate innovation.

Good architecture shouldn’t become a barrier to experimentation. It should make experimentation easier to scale.

We Also Need an Organizational Strategy for Build vs. Buy vs. Integrate

AI is changing the economics of software development, and I think organizations need to revisit how they make technology investment decisions.

Just because we can build something doesn’t mean we should.

Before creating a new application, we should be asking:

• Does this capability already exist somewhere in our organization?
• Is this a differentiated business process or a common enterprise function?
• Could we solve the problem through integration or orchestration rather than building another system?
• Who will own and maintain the application over time?
• What is the total cost of ownership, not just the initial development cost?

These decisions shouldn’t have to be made independently by every employee building an application.

Organizations need a shared architectural direction, even if the implementation remains decentralized.

That doesn’t mean every application needs a committee.

It means providing enough guidance, reusable infrastructure, and organizational visibility that teams can make informed decisions.

The Next Phase of AI Development

I believe we’re still in the early stages of understanding what AI-powered software development means for organizations.

Right now, much of the excitement is around how quickly we can go from an idea to a working application.

And that excitement is justified.

But I suspect the organizations that benefit most from this technology won’t necessarily be the ones that build the most applications.

They’ll be the ones that figure out how to turn all that creativity into sustainable, connected business capabilities.

That requires investment beyond AI models and app-building tools.

It requires architecture, integration, orchestration, governance, and the ability to embed organizational expertise into the development process.

Most importantly, it requires us to think beyond the initial excitement of creating something new.

We shouldn’t measure the success of AI app-building tools by how many applications people build. We should measure it by how much lasting business value those applications create.

Because ultimately, the goal isn’t to democratize software creation alone.

It’s to democratize the ability to create software that is useful, secure, maintainable, and sustainable.

And I think that’s a much more exciting opportunity.